BCNF
BCNF
Boyce-Codd Normal Form
BCNF는 관계형 데이터베이스의 정규화 과정에서 중요한 단계로, 데이터의 중복을 줄이고 무결성을 향상시키기 위한 규칙이다. BCNF는 제 3 정규형 (3NF) 의 강화된 형태로 볼 수 있다.
BCNF는 데이터 베이스 설계에서 매우 중요한 개념으로 데이터의 중복을 줄이고 무결성을 높이는데 기여한다. 데이터베이스 설계를 할 때 BCNF를 고려하면 나중에 발생할 수 있는 여러 문제를 예방 가능하다.
시작하기 전에
후보키와 슈퍼키 라는 개념을 알아보자
- 후보키와 슈펴키는 관계형 데이터베이스에서 데이터의 무결성을 유지하고 각 레코드를 유일하게 식별하기 위한 중요한 개념이다.
슈퍼키
슈퍼키는 테이블의 모든 튜플(행)을 유일하게 식별할 수 있는 속성의 집합이다.
슈퍼키는 하나 이상의 속성으로 구성될 수 있으며 이 속성의 조합을 통해 테이블 내의 각 레코드를 구별할 수 있다.
특징
1.슈퍼키는 유일성만 보장하면 되며 필수적으로 최소성을 요구하지 않는다.
2.동일한 테이블에서 여러 개의 슈퍼키가 존재할 수 있다.
예시
사람ID 이름 이메일
1 | 철수 | AAAA@SSSS.COM |
2 | 금수 | BBBB@DDDD.NET |
이 테이블에서 가능한 슈퍼키
- {사람ID}
2.{이메일}
3.{사람ID,이름}
4.{이메일,이름}
5.{사람ID,이메일}
이 모든 조합이 유일성을 갖기 때문에 모두 슈퍼키이다.
후보키
후보키란 테이블에서 튜플(행)을 유일하게 식별할 수 있는 최소한의 속성 집합이다.
후보키는 슈퍼키의 질종이지만 최소성을 만족해야 한다. 즉 , 후보키에서 어떤 속성을 제거할 경우 유일성을 잃는 경우에만 후보키로 인정된다.
특징
1.후보키는 유일성과 최소성을 모두 만족해야한다.
2.하나의 테이블에 여러개의 후보키가 존재할 수 있으며 이중에서 하나를 기본키(Primary Key)로 선택할 수있다.
예시
위 테이블에서 가능한 후보키
1.{사람ID}
2.{이메일}
여기서 사람ID와 직업은 각각 유일성을 가지며 더이상 속성을 줄일 수 없기 때문에 후보키이다.
반면 {사람ID,이름} 은 최소성을 만족하지 않기 때문에 후보키가 아니다.
요약
슈퍼키 : 유일정을 보장하는 속성의 집합(최소성 요구 없음)
후보키 : 유일성과 최소성을 모두 만족하는 속성의 집합
BCNF의 정의
- 모든 결정자(Functional Dependency의 왼쪽부분)는 후보키여야 한다. 즉 만약 속성 A가 속성 B를 결정한다면 A는 반드시 후보키 여야만 한다. 후보키가 아닌 속성이 결정자일 경우 BCNF를 만족하지 않게 된다.
Functional Dependency (함수 종속성)
관계형 데이터베이스의 설계에서 중요한 개념으로 하나의 속성 또는 속성 집합이 다른 속성 또는 속성 집합을 결정하는 관계를 나타낸다. 즉 , 어떤 속성 A가 속성 B 를 결정한다는 것은 A의 값이 주어졋을 때 B의 값이 유일하게 결정 된다는 의미이다.
Functional Dependency의 정의
A → B (A가 B를 결정한다) : A의 값이 주어지면 B의 값이 유일하게 결정된다. 여기서 A는 결정자 (Determinant)라고 하고 B는 종속 속성 (Dependent Attribute) 라고 한다
예시
사람ID 이름 직업
1 | 금수 | 개발자 |
2 | 은수 | 디자이너 |
3 | 동수 | 프로게이머 |
이 같은 테이블이 있다고 가정해보자
여기서 다음과 같은 함수 종속성이 존재한다.
- 사람ID → 이름
- 사람ID → 직업
이 경우 사람 ID 가 주어지면 해당 사람의 이름과 직업이 유일하게 결정된다.
함수 종속성의 종류
- 완전 함수 종속(Full Functional Dependency)
- A가 B를 결정하는데 A부분의 집합이 B를 결정하지 않는 경우 ex) 사람ID,능력ID→월급 사람ID만으로는 월급을 결정할 수 없고 능력ID도 필요하다. 만약 사람ID만으로 월급을 결정할 수 있다면 이는 완전한 함수 종속이 아니다. 예시에서는 능력ID가 없이는 월급을 알 수 없으므로 완전 함수 종속이다.
- 부분 함수 종속(Partial Fucntional Dependency)
- A의 부분 집합이 B를 결정할 수 있는 경우 ex) 사람ID , 능력ID (필요없음)→ 사람이름 사람ID만으로도 그 사람의 이름을 결정할 수 있다. 즉, 사람ID가 주어지면 해당 사람의 이름을 알 수 있으므로 사람ID(A)의 부분 집합이 사람이름(B)를 결정할수 있으므로 부분 함수 종속이다.
3.이행적 함수 종속
- A→B,B→C가 성립할 경우 A→C가 성립하는 경우를 말한다. ex)사람 ID → 회사ID ex)회사ID → 직업 여기서 사람 ID가 주어지면 회사ID를 알 수 있고 회사ID가 주어지면 직업을 할 수 있다. 따라서 학생ID가 주어졌을때 학과명도 알 수 있게 되므로 A(사람ID)→C(직업) 으로 이어지는 이행적 함수 종속이 성립한다.
요약
1.완전 함수 종속: A의 모든 속성이 B를 결정해야한다.
2.부분 함수 종속 : A의 일부 속성이 B를 결정할 수 있다.
3.이행적 함수 종속 : A가 B를 결정하고 B가 C를 결정한다면 A가 C를 결정할 수 있다.
BCNF의 필요성
- 중복 데이터 : 비정상적인 종속성으로 인해 데이터가 중복될 수 있다. BCNF를 적용하면 중복을 줄일 수 있다.
- 갱신 이상 : 중복된 데이터로 인해 데이터 수정 시 일관성 문제가 발생할 수 있다. BCNF를 통해 이러한 문제를 예방할 수 있다.
- 삭제 이상 : 특정 데이터를 삭제할 때 원하지 않는 데이터가 함께 삭제되는 문제를 줄일 수 있다
예시
고객 , 주문 , 제품 , 정보를 포함하는 OrderTable이 있다고 가정해보자
주문ID 제품ID 고객ID 제품이름 고객이름
1 | A | C1 | 제품A | 철수 |
1 | B | C1 | 제품B | 철수 |
2 | A | C2 | 제품A | 금수 |
2 | C | C2 | 제품C | 금수 |
Functional Dependency
- 주문ID , 제품ID →고객ID,제품이름,고객이름
- 고객ID →고객이름
위 예시에서 두번째 종속성인 고객ID→고객이름이 문제를 일으킬 수 있따. 고객ID는 후보키가 아니기 때문에 이 테이블은 BCNF를 만족하지 못한다.
BCNF로 변환
이 문제를 해결하기위해 OrderTable 테이블을 두개의 테이블로 나눌 수 있다.
1.주문 테이블
주문ID 제품ID 고객ID
1 | A | C1 |
1 | B | C1 |
2 | A | C2 |
2 | C | C2 |
2.고객 테이블
고객ID 고객이름
C1 | 철수 |
C2 | 금수 |
이렇게 나눈다면 두개의 테이블 모두 BCNF를 만족하게 된다.