❒ Description
정규화(Normalization)는 관계형 데이터베이스의 설계에서 데이터 중복을 줄이고 데이터 무결성을
개선하기 위해 데이터 정규형(Normal-form)에 맞도록 구조화하는 프로세스를 뜻한다.
1NF ~ 6NF 까지 있는데 보통 3NF까지 만족하면 정규화 됐다라고 한다. 그리고 정규화를 이해하기
위해서는 FD(Functional Dependency)를 잘 이해하고 있어야 한다.
❒ FD (Functional Dependecny)
한국어로 함수 종속이라고 하는 Functional Dependency는 데이터베이스의 릴레이션(relation)에서
두 개의 애트리뷰트(attribute) 집합 간 제약의 일종이다.
X의 값에 따라 Y 값이 유일하게 결정될 때
- X가 Y를 함수적으로 결정한다. (Functional Determine)
- Y가 X에 함수적으로 의존한다. (Functional Defendent)
라고 말할 수 있고, 두 집합 사이의 이런한 제약 관계를 Functional Dependency라고 하며
`X → Y` 라고 표기한다. 여기서 X는 결정자, Y는 종속자 라고 부른다.
그리고 FD는 테이블의 스키마를 보고 의미적으로 파악해야 하지 state를 보고 판악하면 안된다.
❒ FD의 종류
1. Trivial Functional Dependency
X → Y 에서 Y가 X의 부분집할 일 때, 이를 Trivial FD라고 한다.
{ A, B, C } → { A }
{ A, B, C } → { A, B }
{ A, B, C } → { A, B, C }
2. Non-Trivial Functional Dependency
X → Y 에서 Y가 X의 부분집합이 아닌 경우, 이를 Non-Trivial FD라고 한다.
만약 X와 Y가 하나도 겹치지 않을 경우에는 Completely Non-Trivial FD라고 한다.
// Non-Trivial FD
{ A, B, C } → { A, D }
{ A, B, C } → { A, E }
// Completely Non-Trivial FD
{ A, B, C } → { D, E }
3. Partial Functional Dependency
X → Y 에서 X의 일부 속성(proper subset)으로도 Y를 결정할 수 있는 경우, 이를 Partial FD라고 한다.
이는 주로 후보키가 여러 속성으로 이루어졌을 때 발생한다.
다음과 같이 X의 집합으로 Y를 결정할 수 있다.
{ user_id, user_name } → { user_birth }
하지만, 아래와 같이 user_id로 만으로도 user_birth를 결정할 수 있다.
{ user_id } → { user_birth }
여기서 집합 X의 proper subset은 X의 부분집합이지만, X와 동일하지 않은 집합을 의미한다.
X = { A, B, C }
proper subset O = { }, { A }, { A,B }
proper subset X = { A, B, C }
4. Fully Functional Dependency
X → Y 에서 X의 모든 속성이 Y에 영향을 미치는 경우, 이를 Fully FD라고 한다.
즉, X의 부분집합 중 어느 하나라도 제거하면 더 이상 Y를 결정할 수 없는 것이다.
X = { std_id, class_id }
집합X로 Y(grade)를 결정할 수 있지만,
{std_id, class_id} → {grade} (O)
집합X의 proper subset으로 Y를 결정할 수 없다.
{class_id} → {grade} (X)
5. Transitive Dependency (이행적 함수 종속성)
X → Y이고 Y → Z 인 경우, 이를 Transitive FD라고 한다. 즉, X가 Z에 간접적으로 영향을 미치는 경우다.
그리고 Transitive FD 에서는 Y 또는 Z가 어떠한 키의 부분집합이여서는 안된다는 제약사항이 있다.
위 그림이 가장 좋은 예시인데, 다음과 같은 관계를 갖는다.
- account_id → class, class → bank_name
- account_id → bank_name
{ account_id }와 { bank_name, account_num } 은 모두 key에 속하는데, 여기서는 account_id가
bank_name을 결정짓고 있다. 즉, Z가 키의 부분집합이여서는 안된다는 제약사항을 위배하고 있기 때문에
Transitive FD라고 정의할 수 없다.
❒ Normal Form
1NF | 각 속성의 값은 반드시 나눠질 수 없는 단일한 값이어야 한다. |
2NF | 모든 non-prime attribute는 모든 key에 Fully FD 해야 한다. |
3NF | 모든 non-prime attribute는 어떤 key에도 Transitive Dependenet하면 안된다. ( = non-prime attribute와 non-prime attribute 사이에는 FD가 있어선 안된다.) |
BCNF | 모든 유요한 non-trivial FD X → Y는, X가 super key여야 한다. |
💬 Demormalization (역정규화)
DB를 설계할 때 과도한 조인과 중복 데이터 최소화 사이에서 적정 수준을 잘 선택할 필요가 있다.
💬 2NF는 key가 composite key가 아니라면 2NF는 자동으로 만족한다?
테이블에 composite key가 존재하지 않는다면, 당연히 partially FD가 생길 수 없으기 때문에
위와 같은 명제가 등장한 것이다. 보통은 이 설명이 맞지만 edge case가 존재한다.
예를 들면 테이블의 컬럼이 어떤 경우에도 항상 같은 값이라면 아래의 관계가 성립된다.
• { } → { filed_name }
이 뜻은 filed_name이 partially FD 하다는 뜻이고, 이는 2NF를 위반하는 것으로 해석할 수 있다.
이런 경우는 거의 발생하지 않아서 위 명제가 옳지만, 100% 항상 그런 것은 아니다! 라고 기억하자.
'CS > Database' 카테고리의 다른 글
Lock을 활용한 concurrency control (0) | 2024.10.02 |
---|---|
Isolation 레벨과 이상 현상들 (0) | 2024.09.26 |
DB Transaction & Concurreny Control (2) (0) | 2024.09.20 |
DB Transaction & Concurreny Control (1) (0) | 2024.09.12 |
B-tree와 DB 인덱스(index) (0) | 2024.09.01 |