14장 데이터 베이스 함수적 종속성, 정규화 (Dependencies and Normalization)
본 포스팅의 내용은 Fundamentals of Database System (Pearson) 책의 내용을 참고하여 작성되었습니다.
이번 시간에는 데이터 베이스 정규화에 대해서 살펴보도록 하겠습니다.위키피디아에 따르면, 데이터 베이스 정규화란 다음과 같습니다.
관계형 데이터베이스의 설계에서 중복을 최소화하게 데이터를 구조화하는 프로세스를 정규화라고 한다. 데이터베이스 정규화의 목표는 이상이 있는 관계를 재구성하여 작고 잘 조직된 관계를 생성하는 것에 있다. 일반적으로 정규화란 크고, 제대로 조직되지 않은 테이블들과 관계들을 작고 잘 조직된 테이블과 관계들로 나누는 것을 포함한다. 정규화의 목적은 하나의 테이블에서의 데이터의 삽입, 삭제, 변경이 정의된 관계들로 인하여 데이터베이스의 나머지 부분들로 전파되게 하는 것이다. (출처: 위키피디아)
A functional dependency, denoted by X -> Y, between two sets of attributes X and Y that are subsets of R specifies a constraint on the possible tuples that can form a relation state r of R. The constraint is that, for any two tuples t1 and t2 in r that have t1[X] = t2[X], they must also have t1[Y] = t2[Y].
위에 정의를 한국말로 번역하여 간단하게 설명하면, 어떤 릴레이션 R의 상태 r에서 어떤 속성 X가 속성 Y를 고유(functionally)하게 한정한다는 뜻 입니다. 이를 다시 해석하면, Y는 X에 함수적으로 종속된다고 표현할 수 있습니다. 더 쉽게 표현하면 X를 키값으로 Y에 모든 원소를 구분할 수 있다는 뜻 입니다. 어떤 릴레이션 R의 상태 r이란 뜻이 조금 어렵게 느껴지실 수도 있을것 같아서 풀어서 설명하자면, 만약 하나의 컬럼이 추가되거나 지워지면, 릴레이션 R이 변경된 것이고, 데이터 하나가 추가되거나 지워지거나, 하나의 cell이 업데이트 되었을 때는 상태 r이 변화된 것입니다. 데이터가 계속 변경되면 R은 그대로이지만 그 상태 r은 계속해서 변화하는 것이지요. 그래서 책에서는 primary key는 null 이면 안되기 때문에 이러한 조건을 짧은 정의에 담기 위해서 릴레이션의 임의의 상태(state of R)이라는 표현을 사용한 것 같습니다. candidate-key는 미래의 Key가 언제든지 될 수 있는 후보 키를 말합니다. 함수적 종속성은 데이터 스키마에서 화살표로 표시하고, 정규화 과정에서 계속해서 등장합니다. 왜냐하면 정규화 과정과 이러한 함수적 종속성은 매우 매우 매우 연관이 깊기 때문이죠.
제 1 정규화
제1 정규화는 데이터의 값으로 오직 atomic value 만을 허용하는 것입니다. 데이터에 릴레이션 혹은 배열이 올 수 없다 입니다. 예를들어 아래(a)와 같은 데이터가 존재한다면 이는 제1 정규화를 만족하지 못한다고 할 수 있습니다. 왜냐하면 첫번째 행에 있는 김땡땡의 핸드폰 번호가 2개이기 때문이지요. 이런 상황을 "데이터가 원자적(atomic)이지 않다." 라고 표현합니다.
ID | 이름 | 핸드폰 | 나이 |
20000001 | 김땡땡 | {010-0000-0000, 010-1111-1111} | 20 |
20000002 | 이땡땡 | 010-9999-9999 | 24 |
이 Relation이 제 1 정규화를 만족하게 하기 , 아래 설명할 3가지 방법중에 한가지를 선택해서 해결할 수 있습니다.
여러개의 값을 가지는(제 1정규화를 위배하는) 속성을 따로 분리해서 새로운 테이블을 만든다.
(a-1) 핸드폰
ID
핸드폰
20000001
010-0000-0000
20000001
010-1111-1111
20000002
010-9999-9999
(a-2) 연락처
ID
이름
나이
20000001
김땡땡
20
20000002
이땡땡
24
중복해서 튜플을 만든다.
ID
이름
핸드폰
나이
20000001
김땡땡
010-0000-0000
20
20000001
김땡땡
010-1111-1111
20
20000002
이땡땡
010-9999-9999
24
중복해서 튜플을 만드는 방법도 나쁘지 않지만 redundancy(필요하지 않은)데이터의 중복이 발생하게 된다.
해당 속성을 여러개의 속성으로 펼친다.
ID
이름
핸드폰1
핸드폰2
나이
20000001
김땡땡
010-0000-0000
010-1111-1111
20
20000002
이땡땡
010-9999-9999
null
24
이 방식은 매우 간편한 해법 같지만, 테이블에 많은 null과 버려지는 공간을 발생하므로 좋은 방법이 아니다.
제 2 정규화 (partial dependency 없애기)
제 2 정규화는 조금 복잡하기 때문에 책에 쓰여있는 정의를 잠시 살펴보도록 하겠습니다.
A relation schema R is in second normal form (2NF) if every nonprime attribute A in R is not partially dependent on any key of R.
A 에 존재하는 모든 nonprime 속성들이 R의 모든 키와 부분종속관계를 만족하지 않는다면, A는 2NF를 만족한다고 하는데 이것이 어떤 뜻일까요. 우선 부분 종속관계라 함은, 어떠한 속성X가 다른 속성Y를 결정짓는 함수적 종속성 관계에 있을 때 (X -> Y) X의 임의의 속성을 삭제하여도 (X->Y)가 성립하는 것을 말합니다. 조금더 쉽게 설명하면 어떤 Relation의 '키'가 최소한의 속성들로 이루어진 키가 아닐 때, 다른 속성들은 이 키에 부분적으로 종속되어 있다고 표현합니다. nonprime 속성은 prime 속성(후보키 또는 기본키의 원소)가 아닌 속성을 뜻합니다. 해당 릴레이션에 prime속성이 알짜배기만 존재할 때 제2 정규화를 만족한다고 할 수 있습니다.
EMP_PROJ 테이블의 Ename 속성은 nonprime이고 {Ssn, Pnumber}라는 기본키 의해서 구분될 수 있지만, 그것 보다 더 작은 Ssn이라는 하나의 속성만으로도 구분될 수 있기 때문에 이 PK와 Ename은 부분종속 관계를 가진다고 할 수 있으므로 제2 정규화의 정의에 어긋납니다. 따라서 Ename과 이 속성을 한정 지을 수 있는 가장 작은 키인 Ssn과 함께 따로 추출해서 EP2라는 테이블을 만들고 Pname, Plocation도 똑같은 이유로 새로운 테이블을 생성할 수 있습니다. 위의 세 종류의 테이블로 분할함으로서, 제2 정규화를 만족하도록 Relation을 수정하였고, 특별한 점이 있다면 2정규화를 만족하면 1정규화 또한 만족한다는 점 입니다. 왜냐하면 숫자가 높아질 수록 더 엄격한 규칙이면서 동시에 하위 규칙을 포함하기 때문입니다. 다만 햇갈릴 수 있는 부분은 과연 3정규화의 정의가 1,2 정규화를 포함하는가 입니다. 여기서 혼동해서 안되는 점은 역사적으로 3정규화는 2정규화를 테스트 했다는 전제 하에 정의었고, 따라서, 2정규화를 먼저 적용한 뒤에 3정규화의 규칙을 적용해야 한다고 책에 나와있습니다.
제 3 정규화 (transitive dependency 없애기)
제 3정 정규화도 제 2 정규화와 마찬가지로 꽤나 복잡하기 때문에 책에 쓰여있는 정의를 가져오도록 하겠습니다. 정규화 파트가 양이 상당히 많아서 힘들 수 있지만, 데이터베이스 설계시 매우 중요한 요소라고 합니다. 거의 다 왔으니 조금만 더 집중해주세요.
A relation schema R is in third normal form (3NF) if, whenever a nontrivial functional dependency X->A holds in R, either (a) X is a superkey or R, or (b) A is a prime attribute of R.
3 정규화는 말 그대로 X->A를 만족하는 X가 super-key 이거나 혹은 A가 prime attribute 일 경우에 만족합니다. 예제를 보면서 이해하는 것이 가장 빠를 것 같군요. 아래 예제를 보면 Ssn은 Dnumber를 결정하는데, Dnumber는 Dname과 Dmgr_ssn을 결정합니다. 따라서 Ssn은 Dnumber를 통해 Dmgr_ssn을 결정합니다. 마치 3단논법처럼 Dnumber라는 일반 어트리뷰트가 중간다리 역할을 하고 있는 이 상황을 transitive dependency가 존재한다고 표현합니다. 그리고 이 중간다리를 분리해내는 것이 3NF(3rd normalize form)를 구현하는 방법입니다. 그렇지만 이 중간다리 역할을 하는 attribute가 superkey이거나 혹은 마지막에 가리키는 속성이 prime 속성일 경우는 3NF를 만족한다는 사실을 반!드!시! 명심해야 합니다.
1정규화 -> 2정규화 -> 3정규화 과정
BCNF(Boyce-Codd Normal Form) 정규화
BCNF 정규화는 제 3 정규화와 거의 비슷하지만, 조금더 엄격한 규칙을 가지고 있습니다. 바로 제 3 정규화의 정의에서 (b)규칙을 뺀 것 입니다. 즉 만약 X->Y라는 FD(Functional Dependency)에서 X가 Super-key 가 아니고 Y가 Prime 속성인 경우 3정규화 에선, 통과지만 BCNF에선 탈락입니다. 책에 나와있는 BCNF의 정의는 아래와 같습니다.
A relation schema R is in BCNF if whenever a nontrivial functional dependency X -> A holds in R, then X is a superkey of R.
제 3 정규화의 정의와 거의 80퍼센트 일치하죠? 하지만 차이점은 분명히 존재하고 BCNF가 조금더 엄격한 정규화 규칙이라는 점을 꼭 기억해야 합니다. 책에 나와있는 예제를 통해 확실하게 알아보아요!
3정규화를 만족하는 LOTS1A에서 BCNF 정규화를 거친 LOTS1AX에서 FD2만 사라졌다는 점을 확인할 수 있습니다.
데이터베이스 함수적 종속성과, 정규화 포스팅을 마치겠습니다. 감사합니다.
'컴퓨터 공학 > 데이터 베이스' 카테고리의 다른 글
| The Google File System -Google 인트로 (0) | 2019.04.24 |
|---|
