데이터베이스 정규화

* 정규화: 데이터베이스의 릴레이션이나 튜플을 불필요한 중복없이, 수정할 때 의도치 않은 불필요한 사실이 추가, 삭제, 갱신 되는 것을 방지하도록 DB를 재구성화는 과정 

 

현실 세계의 데이터베이스 디자인이 주는 스키마 릴레이션과 무결성 제약조건[1]은 최종 데이터베이스 설계를 위한 좋은 출발점으로 여겨진다. 이러한 초기 디자인은 반드시 정제과정이 이루어져야 하는데, 무결성 제약조건을 통해 ER 모델이 작성되는것과 데이터베이스의 성능 기준과 작업량을 고려할 수 있게 해준다. ER 모델 설계로 릴레이션의 집합을 번역함으로써 생성되는 현실 세계의 스키마를 무결성 제약조건을 통해 정제할 수 있는 방법에 대해 이야기해보겠다.

데이터의 중복 저장은 가장 기본적인 문제점이다. 중복 저장시 다음과 같은 문제가 발생한다.

 

데이터 중복성 문제

데이터를 중복 저장한다는 것은 한개 이상의 데이터베이스에서 저장한다는 소리이다

1. 중복 저장: 어떤 정보가 반복 저장되는 것

2. 갱신 이상: 데이터 복제본이 계속 업데이트가 되어 일관성이 깨지는 것

3. 삽입 이상: 역시 삽입이 안되는것

4. 삭제 이상: 삭제할 때 다른자료까지 같이 소실될 수 있는 문제

결국 이러한 모순을 막기 위해 중복을 제거해야하며, 이러한 과정을 정규화라 한다. 정규화를 위해서는 하나 이상의 릴레이션을 두 개 이상의 릴레이션으로 분해(decompositions)를 시키는 과정이 포함되게 된다. 이론적으로 정규화를 적용하려면 속성들간의 관련성을 파악해야 하는데, 이 속성들간의 관련성을 함수적 종속성이라고 한다.

 

함수적 종속성(Funtional Dependencies)

 

어떤 릴레이션 R에서, X와 Y를 각각 R의 애트리뷰트 집합의 부분 집합이라 하자. 애트리뷰트 X의 값 각각에 대해 시간에 관계없이 항상 애트리뷰트 Y의 값이 오직 하나만 연관되어 있을 때 Y는 X에 함수 종속이라 하고, X → Y라고 표기한다.

다시 말해, R 내의 애트리뷰트의 집합 X와 역시 R 내에 있는 또 다른 애트리뷰트의 집합 Y에 대해, 각각의 X 값에 대해 최대 한 개의 Y 값에 연관되어 있을 때, 애트리뷰트의 집합 X를 함수 결정(to functionally determine)하다고 한다.

X를 결정자(determinant set)이라 하고, Y를 종속자(dependent attribute)라고 한다.

 

a) 완전 함수적 종속성

어떤 릴레이션 R에서 속성 X가 집합일 때, 속성 Y가 속성 A에 함수적으로 종속하면서, 속성 X의 어떤 진부분집합에도 함수적으로 종속하지 않으면, 속성 Y가 속성 X에 완전하게 함수적으로 종속한다. 여러개의 속성이 모여서 하나의 기본키를 이룰 경우 기본키 전체가 있어야하지만 어떤 속성이 결정될 때 완전 함수적 종속이다.

 

* 진부분집합 ex) 집합 A={1,3} 의 진부분집합은 "공집합, {1}, {3}"으로 모두 3개이다

 

b) 부분 함수적 종속성

완전하게 함수적으로 종속하지 않으면 부분 함수적 종속성을 갖는다. 여러개의 속성이 모여서 하나의 기본키를 이룰 경우, 기본키를 구성하는 부분 속성만으로도 결정되어지면 함수적 종속이다.

 

c) 이행 함수적 종속성

X->Y 이고 Y->Z일때 X->Z를 만족하는 관계를 이행적 함수 종속이라 한다. 

'학번' -> '지도교수' 이고 '지도교수' -> '학과' 일때 '학번' -> '학과'

 

정규형 (Normal Forms)

앞서 정규화를 위해서는 릴레이션들을 분해시키는 과정이 포함된다고 했다. 분해의 결과가 궁극적으로 지향하는 형태가 바로 정규형이라고 할 수 있다. 제 1 정규형, 제 2 정규형, 제 3 정규형, 보이스-코드 정규형 등이 있다.

 

제 1 정규형 (1NF, first normal form) [2]

테이블(Relation)이 제 1정규형을 만족했다는 것은 아래 세 가지 조건를 만족했다는 것을 의미한다.

1. 어떤 Relation에 속한 모든 Domain이 원자값(atomic value)만으로 되어 있다.
2. 모든 attribute에 반복되는 그룹(repeating group)이 나타나지 않는다.
3. 기본 키를 사용하여 관련 데이터의 각 집합을 고유하게 식별할 수 있어야 한다.

위의 그림을 보면 전화번호가 여러개를 가지고 있기 때문에 이는 atomic하지 않게 되고, 이는 1 정규형을 위반한 것이 된다.

위의 그림은 전화번호 그룹이 반복되는 경우이다.(2번 조건를 위반한 사례)

위의 Relation은 ID가 더 이상 고유하게 식별할 수 있는 키가 아니란 것을 확인할 수 있다. 따라서, 3번 조건을 만족하기 위해 아래와 같이 테이블을 나누어 디자인 하는 것이 좋다.

위의 디자인은 Customer Name과 Customer Telephone Number가 One-to-Many의 관계를 형성하는 것을 알 수 있다.

 

제 2 정규형 (2NF, Second Normal Forms)

제 2정규화를 수행 했을 경우 테이블의 모든 컬럼이 완전 함수적 종속을 만족한다.

위에서 Model과 Manufacturer를 알면 Model Full Name 필드를 아예 유지하지 않거나 참조하지 않아도 결정되기 때문에, {Model, Manufacturer} -> Model Full Name 이라고 할 수 있다. 하지만 {Model, Manufacturer} -> Manufacturer Country에서 Model과 Manufacturer Country는 아무런 연관 관계가 없기 때문에, Manufacturer Country는 Manufacturer와만 종속관계에 있게 되고 이를 부분 함수 종속이라고 하게 되는 것이다.

제 2 정규형을 만족한 테이블

제 3 정규형 (3NF, Third Normal Forms)

테이블(Relation)이 제 3정규형을 만족한다는 것은 아래 두 가지 조건을 만족하는 것을 의미한다.

1. Relation이 제 2정규화 되었다.(The relation is in second normal form)
2. 기본 키(primary key)가 아닌 속성(Attribute)들은 기본 키에만 의존해야 한다.

위 테이블에서 {Tournament, Year}가 후보키가 된다. 하지만 Winner Date of Birth은 기본키가 아닌 속성인 Winner를 거쳐 {Tournament, Year}에 의존하고 있는 것을 알 수 있는데, 이는 3NF를 위반한 것이 된다. 

제 3 정규형 만족

보이스-코드 정규형(BCNF, Boyce-Codd Normal Forms)

NF 를 만족하는 릴레이션 R의 후보키가 1개 밖에 없고, R의 후보키가 기본키가 되고, 3NF를 만족하면 항상 BCNF 를 만족한다. 하지만 후보키가 여러개인 경우에는 3NF를 만족시키지만 이상현상이 발생하는 경우가 있는데, 이를 해결하기 위한 정규형이 보이스 코드 정규형이다. 제3정규형보다 조금 더 엄격한 제약조건을 가지기 때문에 Strong 3NF 라고도 한다. 쉽게 말해 테이블에 존재하는 식별자가 여러 개 존재할 경우 식별자가 중복되어 나타나는 현상을 제거 하는 것이다. 

 

REFERENCES

[1] 무결성 제약조건 : 데이터베잇에 저장된 데이터 값과 그것이 표현하는 현실 세계의 실제 값이 일치하는 정확성을 의미한다

 크게  3가지 조건이 있는데, 개체무결성, 참조무결성, 도메인 무결성이 있다.

1. 개체무결성: 기본키와 관련된 제약조건으로 한 릴레이션의 기본키를 구성하는 어떠한 속성값도 절대 null값이나 중복값은 가질 수 없다는 제약조건이다. 

2. 도메인무결성: 주어진 속성의 값이 그 속성에 정의된 도메인에 속한 값이어야 한다는 제약조건

3. 참조무결성: 외래키와 관련된 제약조건으로, 예를 들어 릴레이션 R1에서 저장된 튜플이 릴레이션 R2에 있는 튜플을 참고하려면, 참조되는 튜플이 반드시 R2에 존재해야 한다는 제약조건이다. 릴레이션은 참조할 수 없는 외래키 값을 가질 수 없으며, 외래키 값은 참조 릴레이션의 기본값으로 존재해야한다. 또한 외래키의 속성들은 참조 릴레이션의 기본키와 도메인이 동일해야하고, 외래키의 속성 개수와 참조 릴레이션의 기본키의 속성 개수는 같아야 한다. 

[2] https://wkdtjsgur100.github.io/database-normalization/