4. 정규화
❏ 이상(Anomaly)
- 데이터의 중복과 종속으로 인해 발생되는 문제점이다. 이상현상 은 릴레이션을 처리하는데 여러가지 문제를 초래한다
- 삭제이상 / 삽입이상 / 갱신이상
1. 삭제 이상(Deletion Anomaly)
- 하나의 테이블에서 하나의 행을 삭제하는데 또 그 행 안에 내용이 어디선가 필요한 내용이다.
원하지 않는 정보가 손실되는 문제점.
2. 삽입 이상(Insertion Anomaly)
- 삽입하는 과정에서 원하지 않는 자료가 삽입된다든지.. 자료가 부족해 삽입이 되지 않는 문제점들.
B, C, D 를 입력하고 싶은데 테이블에는 A, B, C, D 속성이 있고. A는 기본키라.. 어쩔수없이 울면서 값을 넣어야한다.
3. 갱신 이상(Update Anomaly)
- update 로 자료를 갱신하는데 일부의 튜플만 갱신됨으로 인해 정보가 모호해지거나 일관성이 없어지는 문제점
속성이 제품명, 단가 가 있는데 제품명 속성에서 마우스 행이 몇개 있다. 그런데 한 행만 마우스의 단가를 수정하면
다른 행에도 마우스 있는데 이금액이 맞는건지 저금액이 맞는건지... 일관성이 없어진다..
❏ 함수적 종속(Functional Dependency)
- 종속 ..? 어떤 관계에서 속성 A, B가 있다. A의 값을 알면 B의 값을 알 수 있거나 A의 값에 따라 B의 값이 달라진다면
B는 A에 함수적으로 종속되었다고 하고, 기호로는 A -> B 로 표기한다.
한마디로.. A 가 주도권 있고 B가 끌려가는 모습(종속 당함). 기호로 봐도 A 가 밧줄로 B한테 던져서 주도적으로 끌고갈려고 하는 기호?..;;;
A를 결정자 라고 하고, B를 종속자 라고 한다.
- 종속당하는애의 종류로는 완전함수종속 / 부분함수종속 / 이행적함수종속 등이 있다.
1. 완전함수종속
- 속성이 오직 기본키에만 종속되는 경우. 무조건 기본키.
[학번(기본키), 성명, 수강과목, 학년]
성명, 수강과목, 학년 은 학번 에 완전 함수 종속되었다.
2. 부분함수종속
- 속성이 기본키가 아닌 다른 속성에 종속되거나.. 기본키가 2개 이상 합성키로 구성된 경우. 이 중 일부 속성에 종속이 되는 경우
[고객번호(기본키), 제품번호(기본키), 제품명, 주문량]
주문량 속성은 기본키인 고객번호와 제품번호를 둘다 알아야 구분할 수 있다.
주문량 은 기본키에 완전 함수 종속되었다.
제품명 은 고객번호, 제품번호 를 둘다 알아도 구분할 수 있지만. 제품번호만 알아도 제품명을 알 수 있다.
제품명은 기본키에 부분 함수 종속되었다.
3. 이행적 함수 종속
- A, B, C 세 가지 속성 간의 종속이 A->B, B->C 이면 A->C 가 성립이 되는 경우.
A->B, B->C, A->C
[제품번호(기본키), 제품명, 단가]
제품번호를 알면 제품명을 알 수 있다.
제품명을 알면 단가를 알 수 있다.
결국 제품번호를 알면 단가를 알 수 있다.
❏ 정규화(Normalization)
- 아까 위에서 설명했던 이상 현상의 문제점을 해결하기 위해!
속성 간의 관계를 분석해서... 여러개의 테이블로 분해 하는 과정!
- 1정규형 / 2정규형 / 3정규형 / BCNF / 4정규형 / 5정규형
❏ 1정규형 (1NF)
- 도메인이 원자값만으로 구성되도록 한다.
예)
초보 디자이너가 고객의 이름과 전화번호를 기록하고자 한다. 그는 아래와 같이 테이블을 정의하였다:
| Customer ID | First Name | Surname | Telephone Number |
|---|---|---|---|
| 123 | Robert | Ingram | 555-861-2025 |
| 456 | Jane | Wright | 555-403-1659 |
| 789 | Maria | Fernandez | 555-808-9633 |
디자이너는 이후에 어떤 고객들은 전화번호를 여러개 가지고 있다는 사실을 알게 되었다.
그는 아래와 같이 단순히 가장 간단한 방법을 생각하여 "전화번호"항목에 여러 개의 값을 두었다:
| Customer ID | First Name | Surname | Telephone Number |
|---|---|---|---|
| 123 | Robert | Ingram | 555-861-2025 |
| 456 | Jane | Wright | 555-403-1659 555-776-4100 |
| 789 | Maria | Fernandez | 555-808-9633 |
하지만 전화번호 행에는 전화번호가 아닌 전화번호와 유사한 도메인(12개의 길이를 가지는 문자열)이 정의되게 된다.
1NF 는 행 도메인에서 정확하게 한 개의 값만을 허용하기 때문에 위의 테이블은 1NF가 아니다.
그럼 1NF 를 충족하는 디자인은 뭘까?
2개의 테이블을 이용하는 것이다: 고객 명 테이블과 고객 전화번호 테이블이다.
| Customer ID | First Name | Surname |
|---|---|---|
| 123 | Robert | Ingram |
| 456 | Jane | Wright |
| 789 | Maria | Fernandez |
| Customer ID | Telephone Number |
|---|---|
| 123 | 555-861-2025 |
| 456 | 555-403-1659 |
| 456 | 555-776-4100 |
| 789 | 555-808-9633 |
❏ 2정규형 (2NF)
- 부분 함수 종속을 제거하고 모든 속성이 기본키에 완전 함수 종속이 되도록 한다
종업원들의 기술을 나타내는 테이블을 가정하자
| 종업원 | 기술 | 근무지 |
|---|---|---|
| Jones | Typing | 114 Main Street |
| Jones | Shorthand | 114 Main Street |
| Jones | Whittling | 114 Main Street |
| Bravo | Light Cleaning | 73 Industrial Way |
| Ellis | Alchemy | 73 Industrial Way |
| Ellis | Flying | 73 Industrial Way |
| Harrison | Light Cleaning | 73 Industrial Way |
{종업원} 이나 {기술}은 둘다 이 테이블의 후보키는 아니다.
{종업원}은 다수의 기술을 가지고 있으면 테이블에 한 차례 이상 나타나기 때문이고,
{기술} 또한 다수의 종업원이 같은 기술을 보유하고 있을때 테이블에 한 차례 이상 나타나기 때문이다.
오직 복합 키 {종업원, 기술} 이 이 테이블의 후보 키이다.
그런데 남은 속성인 {근무지}는 후보 키의 일부분인 {종업원}에만 영향을 받는다.
그래서 이 테이블은 2NF가 아니다. {근무지}에 중복이 있다는 점을 주목하자.
Jones는 114 Main Street에 3번, Ellis는 73 Industrial Way에 2번의 중복이 있다.
이 중복은 테이블을 취약하게 만들며 갱신이상의 원인이 된다.
예를 들어 Jones의 근무지를 변경시에 "Typing" 과 "Shorthand" 레코드는 변경했는데 "Whittling" 레코드는 변경하지 않았다고 하자.
이럴 경우 "Jones 의 근무지는 어디인가" 질의에 혼동된 답을 얻게 될 것이다.
이 디자인을 2NF로 표현하는 방법은 같은 데이터를 2개의 테이블로 표현하는 것이다
{종업원} 후보 키를 갖는 "종업원" 테이블과 {종업원,기술} 후보 키를 갖는 "종업원의 기술" 테이블이다.
| 종업원 | 근무지 |
|---|---|
| Jones | 114 Main Street |
| Bravo | 73 Industrial Way |
| Ellis | 73 Industrial Way |
| Harrison | 73 Industrial Way |
| 종업원 | 기술 |
|---|---|
| Jones | Typing |
| Jones | Shorthand |
| Jones | Whittling |
| Bravo | Light Cleaning |
| Ellis | Alchemy |
| Ellis | Flying |
| Harrison | Light Cleaning |
위의 테이블들은 더 이상 갱신 이상이 없다.
❏ 3정규형 (3NF)
- 이행적 함수 종속 관계를 제거한다.
A->B, B->C, A->C 이런 관계 없애장
| 대회 | 연도 | 우승자 | 우승자 생년 월일 |
|---|---|---|---|
| Des Moines Masters | 1998 | Chip Masterson | 14 March 1977 |
| Indiana Invitational | 1998 | Al Fredrickson | 21 July 1975 |
| Cleveland Open | 1999 | Bob Albertson | 28 September 1968 |
| Des Moines Masters | 1999 | Al Fredrickson | 21 July 1975 |
| Indiana Invitational | 1999 | Chip Masterson | 14 March 1977 |
이 테이블은 2NF이지만 3NF는 아니다. 이것을 3NF로 변형하면 다음과 같다:
| 대회 | 연도 | 우승자 |
|---|---|---|
| Des Moines Masters | 1998 | Chip Masterson |
| Indiana Invitational | 1998 | Al Fredrickson |
| Cleveland Open | 1999 | Bob Albertson |
| Des Moines Masters | 1999 | Al Fredrickson |
| Indiana Invitational | 1999 | Chip Masterson |
| 우승자 | 우승자 생년 월일 |
|---|---|
| Chip Masterson | 14 March 1977 |
| Al Fredrickson | 21 July 1975 |
| Bob Albertson | 28 September 1968 |
❏ 보이스-코드 정규형 (BCNF)
- 3정규형 만족 + 모든 결정자가 후보키가 되도록 한다
후보키가 아님에도 결정자 역할을 하는 애들.. 을 다 분해시켜버리자!
❏ 4정규형 (4NF)
- 다치종속 관계가 성립되는 경우 분해하는 정규형
테이블의 속성이 3개 이상이여야 한다. 다치종속 표기는 A ->> B 이렇게 한다.
❏ 5정규형 (5NF)
- 조인 종속이 후보키를 통해서만 성립이 되도록 하는 정규형
도(메인...) -> 부(분함수종속..) -> 이(행적함수종속..) -> 결(정자관계..) -> 다(치종속..) -> 조(인종속..)
❏ 역정규화
- 정규화는 분해한다면 역정규화는 다시 반대로 중복을 허용하더라도 통합시키는 것
1. 릴레이션 역정규화
- 두 릴레이션(테이블)을 합하거나 하나의 릴레이션을 분할하는 방법이 있다.
1-1. 릴레이션 병합
- 두 릴레이션간의 잦은 데이터 참조.. 왔다갔다.. 차라리 너네 병합해서 한 테이블에서 써라!
1-2. 릴레이션 분할
- 속성의 수가 많거나 튜플의 수가 많은 테이블의 경우 분명히 자주 안쓰는 튜플이나 속성이 있을 수 있다.
이런것까지 다 스캔하면 성능이 저하된다. 자주 사용하지 않는 속성이나 튜플을 분해하면 성능을 향상시킬 수 있다.
2. 속성 역정규화
- 속성 단위로 추가하거나 필요한 속성을 추가하는 것
❏ 파생속성