정규화
DB를 다루는데 있어 정규화는 필수입니다.
정규화는 릴레이션간의 잘못된 관계로 인해 데이터 베이스 이상현상을 해결하거나,
저장 공간을 효율적으로 사용하기 위해 릴레이션을 여러개로 분리하는 과정입니다.
그렇게 어려운 개념도 아니고 1,2,3, BCNF 정규화 부터 여러 정규화가 있지만.
넘어가면 넘어갈 수록 어플리케이션 단에서의 비용이 더 많은 경우가 있어
보통 3 정규화 혹은 BCNF 정규화 까지만 진행하는 경우가 많습니다.
여기선 제 3 정규화 까지만 설명하려고 합니다.
제 1 정규화
제 1 정규화는 릴레이션의 모든 도메인이 더이상 분해될 수 없는 원자값으로 구성되어 있어야 하는 조건입니다.
예를 들어 아래와 같은 테이블이 있다고 가정해봅시다.
| 학번 | 이름 | 과목 |
| 201911111 | 고지훈 | 데이터베이스, 자료구조 |
| 201911112 | 홍길동 | Python |
여기서 과목은 하나의 컬럼이지만 id 값인 1 Row에선 두가지의 데이터를 갖고 있습니다.
이는 원자값 형태가 아니라고 할 수 있다 데이터가 ,로 구분되어 있기 때문에 한 속성에 두가지 값을 갖고 있기에 추후에 비용이 많이 들게 됩니다.
이를 해결하기 위해선
| 학번 | 이름 | 과목 |
| 201911111 | 고지훈 | 데이터베이스, 자료구조 |
| 201911112 | 홍길동 | Python |
| 201911111 | 고지훈 | 자료구조 |
이렇게 로우를 새로 생성하거나 테이블을 따로 생성하여 관리해야 합니다.
제 2 정규화
제 2 정규화는 제 1 정규형을 만족하면서 부분함속 종속성을 제거하는 과정입니다.
정확하게는 Partial Dependency를 제거하는 과정입니다.
※ Partial Dependeycy
- Partial Dependeycy를 이해하기 전에 Composite primary key라는 것을 알아야 합니다.
- Composite primary key란 pk와 조합하여 새로운 후보키로 생성이 가능한 key 입니다.
- 위 테이블의 경우 학번을 pk로 가정하였을때 과목과 합하면 중복되는 값이 없는 후보키가 될 수 있습니다.
- 그럼 Partial Dependeycy란 뭐냐 이 Composite primary key에 종속되는 것을 뜻합니다.
- 만약 해당 테이블에 수강료 컬럼이 붙게 된다면 이는 학번이 아닌 과목에 종속되는 것이기 때문에 Partial Dependency를 갖고 있다고 볼 수 있습니다.
부분 함수의 종속성이란 데이터가 기본키(PK)가 아닌 다른 속성에 종속되거나, 기본키가 여러 속성으로 구성되어 있는 경우 기본키를 구성하는 속성중 일부만 종속되는 경우입니다.
완전 함수 종속적이란 것은 테이블의 PK값이 다른 필드 값을 결정하는 관계를 함수 종속이라고 하는데 기본키를 제외한 나머지 속성이 모두 기본키에 종속적인 것을 뜻합니다.
쉽게 말해 해당 Row의 모든 데이터는 PK 값을 기준으로 구분이 되어야지 다른 속성으로 인해 결정 혹은 구분되면 안된다는 것입니다.
만약 아래와 같은 테이블이 존재한다고 합시다.
| 학번 | 이름 | 과목 | 수강료 |
| 201911111 | 고지훈 | 데이터베이스 | 5000 |
| 201911112 | 홍길동 | Python | 1000 |
| 201911111 | 고지훈 | 자료구조 | 5000 |
해당 테이블의 경우 수강료는 과목으로 결정 되는 부분 함수 종속성이 존재합니다.
만약 데이터베이스의 수강료가 7000원으로 올랐다고 가정하게 되면
과목으로 데이터베이스를 갖고 있는 모든 컬럼들을 찾고 이를 수정해야 합니다.
만약 Row가 10000개, 100000개가 넘어가는 등의 상황에선 DB엔 엄청난 부하를 줄 것입니다.
뿐만 아니라 버그, 실수 등의 여러가지 상황이 발생할 수 있기에 이를 해결해야 합니다.
이를 해결하는 방법은 간단합니다.
| 과목 | 수강료 |
| 데이터베이스 | 5000 |
| Python | 1000 |
| 자료구조 | 5000 |
| 학번 | 이름 | 과목 |
| 201911111 | 고지훈 | 데이터베이스 |
| 201911112 | 홍길동 | Python |
| 201911111 | 고지훈 | 자료구조 |
위와 같이 과목 테이블을 따로 만들고 이를 FK로 연결 시키거나 하는 등의 작업을 하여 보다 효율적으로 관리할 수 있게 됩니다.
제 3 정규화
제 3 정규화는 제 2 정규형을 만족하고 기본키가 아닌 모든 속성이 이행적 함수 종속을 만족하지 않는 상태를 뜻합니다.
쉽게 이야기 하자면 PK 컬럼이 아닌 일반 컬럼에 종속된 컬럼을 다른 테이블로 분리시키는 것입니다.
만약 과목 테이블에서 교수, 출신 대학이라는 컬럼이 추가되었다고 가정해봅시다.
| 과목 | 수강료 | 교수 | 출신 대학 |
| 데이터베이스 | 5000 | 김응용 | 서울대 |
| Python | 1000 | 이영을 | 고려대 |
| 자료구조 | 5000 | 이지원 | 연세대 |
여기서 출신 대학은 과목과 아무상관이 없습니다.
교수에게 종속되는 컬럼인거죠
교수는 심지어 후보키도 될 수 없습니다.
그렇다면 이를 어떻게 해야할까요 교수와 출신대학을 다시 다른 테이블로 분리합니다.
| 과목 | 수강료 | 교수 번호 |
| 데이터베이스 | 5000 | 1 |
| Python | 1000 | 2 |
| 자료구조 | 5000 | 3 |
| 교수 번호 | 교수 | 출신 대학 |
| 1 | 김응용 | 서울대 |
| 2 | 이영을 | 고려대 |
| 3 | 이지원 | 연세대 |
이렇게 되면 추후에 수정, 삭제시에 원활하고 버그를 최소한으로 줄일 수 있습니다.
이러한 정규형은 물론 장점도 있지만 단점도 있습니다.
벌써 고지훈이 듣는 과목 중 데이터베이스의 교수를 찾으려면 3번을 거쳐야 확인할 수 있게 됩니다.
이는 대용량 트래픽, DB의 경우엔 시간이 오래걸리거나 등의 비용이 추가적으로 발생할 수 있게됩니다.
이때문에 보통 제 3 정규화 까지만 진행하게 됩니다.