개요 : DB 설계에 있어서 중복을 최소화 하기 위해 데이터를 구조화 하는 작업.
방법 : 문제가 있는 릴레이션이나 관계를 재구성
목표 : 작고 잘 조직된 관계를 생성하는 것
목적 :
- 하나의 테이블(릴레이션)에서의 데이터 삽입/삭제/변경이 이미 정의된 관계들로 인하여 DB의 나머지 관계된 테이블로 잘 전파되게 하는 것
- 하나의 테이블은 하나의 의미만 가지고 있다
장점 :
- 자료의 저장공간 및 불일치 최소화 → 자료 구조 안정화 → 이상(Anormal)현상 방지
결론 : 테이블을 잘 분해하자.
○ 1정규화 : 원자성(Atomicity), 모든 도메인이 원자값으로만 되도록 설계하는것
* 조건 :
ㆍ중복 데이터가 없다
ㆍ튜플과 컬럼이 교차되는 데이터는 복수 데이터를 가지지 않는다.
(예 : 전화번호라는 컬럼에 010-XXX-XXXX, 02-XXX-XXXX과 같은 구분이 가능한 데이터를 가지지 않는다.)
ㆍAll occurrences of a record type must have the same number of fields.
<..정리하기 귀찮으니까 이제 대충할거다...용서해라 미래의 나..>
○ 2정규화 : 키가 아닌 다른 속성들은 키에 대해 완전 종속적이어야 한다.
* 조건 :
ㆍ제1정규화가 되어 있어야 한다.
ㆍ엔티티는 한가지 내용만을 가진다.
ㆍ키에대해 완전 종속적이지 않은 속성값은 다른 테이블로 분리되어야 한다.
ㆍEach non-key field in a record should be information about what is uniquely identified by the key field
예를 들어 하나의 엔티티에 A, B, C, D, E 속성이 있고 이 중 A, B가 KEY라고 하자.
A와 B를 따로 놓고 봤을때 [C,D] --> A에 대해, [E] --> B에만 완전 종속적(=대충 관련이 있다)이라 하자.
그럼 KEY인 A, B에 대해 C, D, E는 완전 종속적이라고 봐야 할까? 아니다. 부분 종속적이라 해야한다.
따라서 테이블을 분리하여 각 속성이 KEY에 대해 완전 종속적일수 있게 분리하는 작업을 제 2정규화라고한다.
아래 테이블은 제2정규화를 거치지 않은 상태의 테이블이다.
위 그림을 참조하면, 학부, 등록금은 학번과 관련이 있지만 성적은 과목코드와 학번이 같이 있어야 연관성을 가진다. 즉,
"[학부, 등록금] --> 학번"
"[성적] --> 학번, 과목코드 "
학부와 등록금은 학번에 대해 완전 종속적이고 성적은 학번과 과목코드에 대해 완전 종속적이다. 따라서 1개 테이블을 종속적인 형태 끼리로 분리할 필요성이 있다. 그 분리된 그림은 아래와 같다.
○ 3정규화 : 제 2 정규형에 속하면서, 기본키가 아닌 모든 속성이 기본키에 이행적 함수 종속이 되지 않는다
뭔소린가 하면, 나도 잘 모르겠다. 한쿸말 너무 어려훠효
'이행(移行)' 이란 다른 상태로 옮아가거나 변해 감을 말한다. 따라서 이행적 함수 종속이란 함수 종속이 옮아가거나 변해감을 말하지 않을까 싶다.
예를 들어 늑대, 개, 여우는 개과 동물이다. 그리고 개과 동물은 포유류 이기도 하다 이를 종속관계로 표현하자면
- 동물이름(늑대, 개, 여우) --> 동물종류(개과 동물) --> 동물범위(포유류)
∴ [ 늑대, 개, 여우 --> 포유류 ]라는 결과도 도출 될수 있다.
이 3개 속성들이 한 테이블 안에 있고 동물 이름이 KEY라고 하자(이중에선 Unique하니깐).
이 때, 늑대,개,여우는 굳이 말하면 포유류라고 할 수는 있지만 Hierarchy적으로는 개과동물이라고 하는게 맞다.
다른말로 동물범위는 동물이름에 대해 동물종류라는것이 사이에 있어야 하는 이행적 함수종속 관계라고 볼수 있는 것이다.
위 그림의 학생 릴레이션을 살펴보자. 학생이 자신이 선택한 학부에 대해 지불하는 것이 등록금이다.
즉 1차원적인 관계만을 생각했을 때, 등록금은 학부에 대한것이지 학생에 대한 것이 아니고 학부 또한 학생이 선택하지 않으면 저 릴레이션에 생성조차 되지 못한다. 따라서 위 학생 릴레이션을 학생/학부, 학부/등록금 으로 나누는 작업이 필요하다.
(설명 못하먹겠다..)
그림참조 : yaboong.github.io/database/2018/03/09/database-normalization-1/