[ DB ] Chapter 7. Relational Database Design

해당 게시물은 건국대학교 김욱희 교수님의 데이터베이스 강의와

DATABASE SYSTEM CONCEPTS 7th 원서를 참고하여 작성하였습니다. 

---

 

1. Features of Good Relational Designs

 

위 table은 {ID, name, salary, dept_name}과 {dept_name, building, budget}이 합쳐진 table이다. table를 잘 보면 {dept_name, building, budget}의 정보가 굉장히 중복이 많아 데이터가 낭비되고있다.

Decomposition

위 테이블처럼 자원을 낭비하지 않기 위해서는 table을 분해하는 것이 좋다.

table을 어떻게 나눌지 고민될 때는 functional defendency를 보면된다. 위 테이블에서는 dept_name→building, budget으로 building, budget은 건물이름의 의존적이다. 즉 부서만 알면 building, budget 정보를 알아낼 수 있다. 하지만 dept_name은 table의 candidate key가 아니다. 따라서 우리는 {dept_name, building, budget}으로 table을 나눌 수 있다.

하지만 잘못 분해하면 lossy decomposite가 될 수 있다

직원 정보 table에서 (ID, name, street, city, salary) 를 (ID, name)와 (name, street, city, salary)로 나눴다고 생각해보자.

이때 이름이 같은 사람이 있다면 두 테이블을 비교했을 때 누가누군지 알 수 없다.

또 다시 natural join을 했을때 원하지도 않고 맞지도 않은 정보가 생길 수도 있다.

 

Lossless Decomposition

우리는 하나의 데이블을 분해했다가 다시 natural join을 했을 때 원래 테이블과 동일하다면 lossless decomposition했다고 한다.

Normalization Theory

정규화를 하면 데이터의 중복과 불일치를 최소화할 수 있다. 이는 다음과 같은 단계로 이루어져 있다.

1. R이 good form인지 판단한다.
2. R이 good form이 아니라면 분해한다. 이때 분해한 table은 good form이어야하고 데이터손실이 있으면 안된다.

---

 

2. Decomposition Using Functional Dependencies

 

Functional Dependencies

functional defendency는 한 attribute가 다른 attribute에의해 값이 정해진다고 보일때 쓰는 용어이다. a→b 즉 b가 a에 의존적이라면, a의 값이 b의 값을 정한다고 할 수 있다.

R(A,B)의 table이라고 해보자.

이 경우에는 A→B는 성립하지 않지만 B→A는 성립한다.

 

functional defendency는 key개념의 일반화이다. 이는 relation과 attribute의 종속성을 나타내는데 사용된다. 만약 K → R 이라는 함수적 종속성이 성립한다면, K는 R의 Superkey이다. 이는 K의 모든 값들이 R의 각 튜플을 유일하게 식별할 수 있음을 의미한다.

반면에, K가 R의 Candidate Key가 되려면 K → R이어야 하며, K의 subset→R은 성립하지 않아야한다.

만약 모든 relation이 다 만족된다면 이는 tivial하다고 표현한다. x,y→x / x→x과 같은 경우이고, x→y가 trivial하다면 y는 대부분 x의 subset이다.

clousure란 추론규칙을 이용하여 논리적으로 유도할 수 있는 모든 functional dependencies 집합을 의미한다. 이는 +를 표기하여 표현한다. F의 clousure은 F+이다. F+는 F를 포함하는 집합이다.

추론규칙은 다음과같다.

• Y가 X의 부분집합이면 X→Y
• X→Y,이면 XZ→YZ
• X→Y 이고 Y→Z이면 X→Z
• X → Y 이고 X → Z,이면 X → YZ
• X → YZ 이면X → Y 이고 X → Z
• X → Y 이고 WY → Z 이면 WX → Z

 

---

 

3. Normal Form

 

The First Normal Form

Domain is atomic if its values are indivisible

Boyce-Codd Normal Form

이는 결정자가 candidate key가 아닌 attribute가 없어야 만족한다. 즉 중복을 모두 제거한다. F+안에 모든 functional dependency들이 다음 두 조건 중 하나가 성립해야 BCNF라고 할 수 있다.

• a→b 가 trivial 해야한다 (b는 a의 subset)
• a는 R의 superkey여야한다.

 

table중에 위 조건을 만족하지 않는 \alpha->\beta가 있다면 다음과 같이 decomposing 해주면 BCNF를 만족한다.

 

예를 들어 위에 table을 보면 lab_id→ lab_name이 성립하지만 lab_id는 super key가 아니다. 따라서 이 table은 BCNF를 만족하지 않는다.

lab_id→ lab_name으로 두고 공식으로 decomposing해주면 위쪽 table과 같이 두개로 나뉘게 된다. 두 table을 보면 둘다 BCNF를 만족하는 것을 알 수 있다.

 

하지만 한번 분해했다고 BCNF가 다 성립하는 것은 아니다. 분해 후 또 조건을 만족하지 않는 table이 있다면 다시 분해해줘야한다. BCNF는 조건이 제한적이기 때문에 여러번 분해해야하는 상황이 생길수도있다. 또, BCNF는 다중 종속을 보존해주지 못한다.

 

 

Third Normal Form

BCNF는 종속성 보존을 보장하지 않아 FD위반이 일어날 수도 있다. 이를 해결하기 위해 3NF가 나오게 되었다. 이는 일부 중복을 허용하고 종속을 보존한다. 3NF는 모든 F+가 다음 조건중 하나를 만족하면 충족된다.

• a→b 가 trivial 해야한다 (b는 a의 subset)
• a는 R의 superkey여야한다.
• b-a가 R의 cadidate key 중 일부여야한다.

위에 두 조건은 BCNF와 같기 때문에 BCNF를 만족하는 R이라면 3NF도 만족한다. 세번째 조건은 BCNF에서 종속성을 보존하기 위한 최소한의 완화조건이라고 볼 수 있다.

이를 사용하면 종속성은 보존할 수 있지만, 중복된 데이터가 있을 수도 있고 null value가 필요하게 될 수도 있다. 이는 저장장치를 더 사용하게 된다.

 

만약 3조건을 모두 만족하지 못하는 종속 요소가 있다면 왼쪽 공식과 같이 decomposing해주면 된다.

 

Goals of Normalization

• 사용하는 저장공간 줄이기 ( 중복이 줄어들기 때문)
• 업데이트 속도 늘리기 (table이 크다면 고려해야할 것들이 많고, 용량을 많이 차지한다면 memory에 저장될 수도 있다)
• 정보 불일치 줄이기 (table이 클수록 고려해야할 요소들이 늘어나 inconsistence가 일어날 가능성이 있다)
• 깔끔한 table
• 데이터 추가 용이
• 유연한 구조

우리는 E-R 다이어그램에서 table로 변환할 때 정규화를 수행한다. 다이어그램이 완벽하게 설계되어있지 않았을 때 정규화를 하면 더 좋은 디자인으로 개선할 수 있다.

하지만 가끔 다른 목적에 따라 정규화되지 않은 table을 원하는 경우도 있다.

Design Goals

• BCNF
• join했을 때 잃는 정보 없기
• 종속성 지키기

하지만 위 목적 을 달성하기 힘들다면 보존성을 포기하거나 중복을 허용하며 3NF를 사용할 수 있다.

SQL은 superkey외의 functional dependencies를 지정해주는 방법을 제공하지 않는다. 또, 우리가 분해를 수행했다고 하더라도 종속성을 효율적으로 검사할 수 없다.

Dpendency Preservation

R table을 Ri로 나눴다고 가정해보자. 이때 각 Ri의 F들끼리 합집합을 수행했을 때 그 집합이 R의 F+와 같다면 이는 종속성이 보존되었다고 볼 수 있다.

이는 매우 비싼 연산이지만 3NF까지는 정보손실이 없다는 것을 보장해준다.