[DB] 데이터베이스

포키·2023년 5월 22일
0

국비과정

목록 보기
63/73

<면접 대비 지식>

  • 용어
  • 무결성

DB

  • DB - Database와 DBMS의 차이
  • 표준 DB언어 = SQL
    하지만 프로그램간(MySQL, 오라클 등) 경쟁 과정에서 표준 언어를 그대로 쓰는 곳은 없어짐
  • 데이터를 영속적으로 저장하는 방법 = 파일
  • 논리적 구조로 데이터베이스를 여러 개 만들 수 있다.
    데이터베이스는 테이블로 이루어진다.
    실제 데이터는 테이블에 적는다.
    데이터베이스를 파일에 적는다.

    기존 파일 작성시 유의점 : CRUD에서의 데이터 관리(중복검사 등 데이터 검증) 등

  • DB = 데이터관리프로그램
    주 역할 : 무결성 관리,
  • 프로그램에서 데이터베이스로 연결되는 케이스.

배울 것

  • SQL : DB에 CRUD 명령 내리기 (read 제일 많이 씀)
  • JDBC(Java Database Connectivity) : 자바로 sql문 질의 요청하고 받아오기
  • ★★★읽기 : 멱등 성립...........★★★

    정보와 데이터의 차이
    정보 -> 가공 -> 데이터

모델링

  • 객체 모델링(자바), 데이터베이스 모델링
  • 현실 - 논리 - 물리
  • 프로그램 성능에 가장 큰 영향을 미치는 것 중 하나가 데이터베이스 설계
  • 객체 모델링, DB 모델링

용어 정리

  • 도메인 : 한 속성에 나타날 수 있는 값들의 범위 (종류, 범위, 크기)
  • entity : 실체, 개체

논리세계

  • 릴레이션 : 표
  • 튜플 : row
  • 속성 : column

물리세계

  • 테이블 : 표
  • 레코드, row : row
  • column : column

데이터베이스의 성질

  • 계속 늘어난다.
  • key - 복수개의 데이터를 다루므로 식별자 = key 필요
    (저장한 데이터를 필요에 따라 찾을 수 있어야 하므로)

Key

  • 참고
  • DB의 식별자 = 식별성이 필요함
  1. 후보키
  • 주 식별자가 될 수 있는 키
  1. 주키 (pk)
  • 후보키 중 최소성을 만족하여 주 식별자로 선택된 키
  • 데이터를 찾을 때 사용(=인덱스), 노출될 수밖에 없음 = 공개할 수 있어야 함!
    (때문에 학번, 주민번호 중에 선택해야 한다면 학번을 선택)

    마땅한 게 없으면 인위적으로 키를 새로 만들기도 함 = id

  • 인덱스가 되어 데이터가 정렬됨
    (최소성을 만족해야 하는 이유 - 주키가 복합키일 경우 검색 소요 시간 증가)
  • 주키는 수정 안됨 <- 의존성 존재
  • 보통 밑줄 그어둠
  1. 복합키
  • 하나 이상의 열로 구성된 주키
  • 당연히 최소성을 만족해야 함
  1. 대체키
  • 주키 대신 사용 가능한 키
  1. 슈퍼키
  • 최소성 만족 안하고 식별성만 만족하는 모든 키조합
  • 식별성을 가진 모든 열들의 부분집합
  1. 외래키 (fk)
  • 외부 테이블(릴레이션)의 주키인 키
  • 테이블간 참조가 목적
    (A 테이블의 주키가 B 테이블의 외래키로 지정된 경우, 목적은 B 테이블에서 A 테이블을 참조하기 위함)
  • 질의문 서브쿼리에서 사용

유니크

  • column 중복방지용 (식별x)
  • 중복값이 존재하면 안되지만, 값으로 null은 허용
    (pk는 중복값이 존재하면 안되고, 값으로 null도 안됨)

무결성

  • 결점 없는 데이터
  • 데이터를 쓰려면 무결성을 지켜야 함
  1. 개체무결성
  • 개체 무결성은 기본 테이블의 기본키를 구성하는 어떤 속성도 Null 값이나 중복값을 가질 수 없다는 규정이다.
  • 개체가 아무리 많아도 내가 원하는 개체를 찾을 수 있어야 함
    = 모든 테이블에는 주키가 있어야 함
  1. 도메인무결성
  • 각 속성 값은 반드시 정의된 도메인에 속한 값이어야 한다.
    = 속성의 값이 도메인의 제약(type, 크기, 범위)을 벗어나서는 안 됨
  • 유효값 내에 있어야 함
  1. 참조무결성
  • 존재하지 않는 값을 참조해서는 안 됨
    (외래키는 참조 테이블을 찾아갔을 때 반드시 존재하는 값이어야 한다.)
    NullPointException과 비슷한 느낌

정규화

  • 45차는 대용량, 일반테이블에서는 적용x 3차까지만 알면 됨
  • 목적 : 중복 제거
  • 하지 않으면 '이상(Anormaly) 현상'이 생김

1차 정규화 (1NF)

  • 열은 원자적 값만 포함한다 (atomic)
  • 같은 데이터가 여러 열에 반복되지 말아야 한다
  • 동등한 두 개의 값이 연속적으로 나열되거나(열), 하나의 항목으로 들어가는 경우(칸)

    데이터베이스에서 연산의 효율도 중요하지만 유지 비용이 크므로 저장하는 법도 중요.
    관리를 위해서 값이 일관성을 유지해야 함. 중복 없애야 함.
    주소를 시군구로 나눈다고 해서 원자성을 충족하는 게 아님.
    데이터를 쪼개는 것은 '목적'에 따라서. 정규화의 목적은 중복 제거라는 것.

2차 정규화 (2NF)

  • 완전 함수 종속 구현 (= 부분 함수 종속 제거)
  • 1차 정규화 만족 + pk가 복합키일 때 발생

삽입 이상

  • 특별한 예비 공급자의 정보를 저장하는 것이 불가 (일부만 저장 불가)

갱신 이상

  • 중복값의 존재로 인해 값의 일관성을 잃기 쉬움 (잃은 경우 발생)

3차 정규화 (3NF)

  • 이행적(추이적) 함수 종속 제거
    (= 모든 테이블의 열은 주키에 대해 종속적이어야 한다.
    = 주키에 대해 '직접' 종속적이지 않은 열이 있어서는 안 된다.)

삽입 이상

  • 특정 도시의 운송거리 저장 불가 (일부만 저장 불가) (공급자 정보가 없을 경우)

삭제 이상

  • a-b-c의 이행적 함수 종속이 존재할 때 이를 분리하지 않으면,
    a(->b) 튜플을 삭제하는 과정에서 b(->c)의 정보 또한 사라지게 된다.

갱신 이상

  • 운송거리 변경으로 인한 일관성을 잃을 가능성 존재
profile
welcome

0개의 댓글