[데이터베이스] DB의 기본 및 정규화
데이터 베이스의 기본
엔터티
여러 개의 속성을 지닌 명사
현실 세계의 사물이나 개념을 데이터베이스에 표현한 것
= 쉽게 말하면 DB에서 관리해야 할 대상(thing)
| 구분 | 설명 | 예시 |
|---|---|---|
| 강한 엔터티 (Strong Entity) | 독립적으로 존재 가능 | 고객(Customer), 상품(Product) |
| 약한 엔터티 (Weak Entity) | 다른 엔터티에 의존해야 존재 가능 (PK가 독립적이지 않음) | 주문 상세(Order Item, 주문에 의존) |
관계
위에서부터
- A는 1개의 B로 구성
- A는 1개 이상의 B로 구성
- A는 0 또는 1개의 B로 구성
- A는 0 이상의 B로 구성
1:1 관계
1:N 관계
N:M 관계
키
기본키(Primary Key, PK)
유일성과 최소성을 만족하는 키
- 자연키
- 현실 세계에 이미 존재하는 의미있는 값
- 실제 데이터 속성 자체가 키 역할(주민번호, 학번 등)
- 인조키
- DB에서 인위적으로 만든 키(AUTO_INCREAMENT, UUID 등)
외래키(Foreign Key, FK)
다른 테이블의 기본키를 그대로 참조하는 값
개체와의 관계를 식별하는데 사용
후보키(cadidate key) 기본키가 될 수 있는 후보들, 유일성&최소성 만족
대체키(alternate key) 후보키가 두개 이상일 경우, 어느 하나를 기본키로 지정하고 남은 후보키들
슈퍼키(super key) 각 레코드를 유일하게 식별할 수 있는 유일성을 갖춘 키
용어
- 유일성: 테이블 안에서 키 값은 절대 중복될 수 없다는 성질
- 최소성: 키를 구성하는 속성 집합은 꼭 필요한 속성만 포함해야한다는 성질
ERD와 정규화 과정
ERD (Entity Relationship Diagram)
릴레이션 간의 관계들을 정의한것
정규화 과정
이상 현상을 최소화하기 위해
저장 공간을 효율적으로 사용하기 위해
릴레이션을 여러개로 분리하는 과정
정규화를 하는 이유
- 데이터 중복 최소화 → 저장공간 절약, 불필요한 중복 제거
- 데이터 무결성 보장 → 잘못된 데이터 삽입, 수정, 삭제 방지
- 이상현상(Anomaly) 방지
- 삽입 이상: 어떤 데이터를 넣으려면 다른 불필요한 데이터도 넣어야 하는 문제
- 갱신 이상: 데이터 중복 때문에 한 곳만 수정하면 불일치 발생
- 삭제 이상: 어떤 데이터를 지우면 원치 않는 데이터까지 손실되는 문제
제1정규형
- 모든 속성 값은 원자값(Atomic Value)만 가져야 함
- 한 칸(속성)에 여러 값이 들어가면 안 됨
제2정규형
- 1NF 만족
- 부분 함수 종속 제거(복합키 일부에만 종속된 속성 제거)
제3정규형
- 2NF 만족
- 이행적 종속 제거(transitive FD기본키가 아닌 속성이 또 다른 속성에 종속이 된 경우 제거)
보이스/코드 정규형(BCNF)
- 3NF의 강화된 형태
- 모든 결정자(Determinant)가 수퍼키여야 한다
- 실무에선 후보키를 전제로 함.
- BCNF 정의
기존 테이블에서의 후보키 : {학번, 수강명}, {학번, 강사}
-> 강사 속성이 결정자이지만, 후보키가 아님(여러 튜플이 가능하므로 유일성 보장이 안되어있음)
결정자가 후보키가 되도록 테이블 나누기
->꼭 성능을 보장하는가? 아니다…! 좋아질수도 나빠질수도 있음
테이블을 나누게 되면 어떠한 쿼리는 조인을 해야하는 경우도 발생해서 오히려 느려질 수도 있음.
서비스에 따라 정규화 또는 비정규화 과정을 진행해야함
3NF와 BCNF의 예시가 궁금하다
[Vincent, M. W. and B. Srinivasan. “A Note on Relational Schemes Which Are in 3NF But Not in BCNF”.]
주제: 3NF (Third Normal Form)를 만족하지만 BCNF (Boyce–Codd Normal Form)를 만족하지 않는 릴레이션 스키마들의 특성과 이런 경우 언제 발생하는지 탐구
- 3NF 조건을 만족하더라도, 결정자가 수퍼키가 아닌 경우가 있을 수 있음.
- 공통적인 패턴:
- 겹치는 복합 후보키(Overlapping Composite Candidate Keys)가 여러 개 존재
- 후보키가 두 개 이상 있고, 서로 일부 속성을 공유하는 경우
- 예: 후보키가 {A, B}, {B, C}라면 B가 겹치는 속성
- 겹치는 속성을 통해 함수적 종속성이 발생
- 예: {A, B}와 {B, C}가 모두 후보키일 때, FD: A → C 또는 C → A 같은 게 생김
- 이때 결정자 A는 후보키가 아님 (최소성 충족 안 함), 그러나 종속성에 의해 3NF는 통과할 수 있음
- 3NF 조건 덕분에 통과
- 3NF는 “X → Y에서 Y가 prime attribute(후보키 속성)이라면 허용” 규칙이 있음
- 그래서 결정자 X가 수퍼키가 아니어도 3NF 만족
- BCNF는 위배
- BCNF는 “모든 결정자 X는 반드시 수퍼키여야 한다”
- 따라서 이런 경우에는 BCNF에 위배됨
- 겹치는 복합 후보키(Overlapping Composite Candidate Keys)가 여러 개 존재
사례: “과목–교수–교실” 관계
| 과목 | 교수 | 교실 |
|---|---|---|
| DB | 홍길동 | 101호 |
| DB | 홍길동 | 102호 |
| 운영체제 | 이영희 | 201호 |
| 운영체제 | 이영희 | 202호 |
- 릴레이션 : 강의(과목, 교수, 교실)
- 규칙 (함수적 종속성):
- 각 교수는 오직 하나의 과목만 담당한다. → FD: 교수 → 과목
- 한 과목은 여러 교수가 가르칠 수 있다.
- 하나의 교실에는 여러 과목 수업이 배정될 수 있다.
- 이 릴레이션의 후보키는 {교수, 교실}.
- 3NF 조건 충족
- FD: 교수 → 과목
- 결정자 X = 교수 (슈퍼키 아님)
- 종속 Y = 과목 (후보키 {교수, 교실}의 일부 → 프라임 속성)
- BCNF 불만족
- 교수는 슈퍼키가 아님