이번 포스팅에서는 테이블 설계에 있어, 데이터베이스 이론가들이 확립시켜 놓은 일종의 규칙,
즉, 정규화 단계가 무엇이 있는지 살펴볼 것이다.
우선 이러한 정규화를 하는 목적에 대해 먼저 살펴 보자.
정규화 목적
- 중복 데이터를 최소화하여 테이블 불일치 위험을 최소화한다.
- 수정, 삭제 시 이상 현상을 방지함으로써, 데이터 구조의 일관성을 최대화한다.
- 데이터 삽입 시 릴레이션의 재구성에 대한 필요성을 줄인다.
- 효과적인 검색 알고리즘을 생성하도록 돕는다.
그럼 데이터베이스 이론가들이 확립시켜 놓은 정규화 단계가 어떻게 구성되는 지 살펴보자.
1. 제 1정규화 (1NF, 1st Normal Form)
: 비정규형 -> 1NF로 바꾸는 것을 말하며, 테이블 내의 속성값이 모두 원자값(Atomic Value)만으로 구성되어야 한다는 원칙을 가지고 있다.
여기에서 원자값이란, 더 이상 쪼개질 수 없는 단위를 말하며, 다음과 같은 조건을 만족한다.
- 각 속성은 하나의 값만을 가진다.
- 하나의 속성은 같은 종류나 타입(type)을 가져야 한다.
- 각 속성은 유일(unique)한 이름을 가져야 한다.
- 각 속성 간의 순서가 상관이 없어야 한다.
비정규형의 [학생] 테이블
학번 | 지도교수 | 학과 | 수강 과목 | 성적 |
100 | 이상철 | 컴퓨터공학과 | 데이터베이스개론, 자료구조 | A, B |
200 | 박종인 | 컴퓨터공학과 | 클라우드 | B |
300 | 안주은 | 전자공학과 | 통신공학 | A |
400 | 김유이 | 수학과 | 미적분학 | C |
위 테이블은 '100'이라는 학번을 가진 학생의 '수강 과목'이 '데이터베이스개론, 자료구조'로 2개의 값을 가지고 있기 때문에, 원자값을 가져야 한다는 1NF의 조건을 만족하지 못한다. 따라서 다음과 같이 테이블을 분리해주어야 한다.
학번 | 지도교수 | 학과 | 수강 과목 | 성적 |
100 | 이상철 | 컴퓨터공학과 | 데이터베이스개론 | A |
100 | 이상철 | 컴퓨터공학과 | 자료구조 | B |
200 | 박종인 | 컴퓨터공학과 | 클라우드 | B |
300 | 안주은 | 전자공학과 | 통신공학 | A |
400 | 김유이 | 수학과 | 미적분학 | C |
2. 제 2정규화 (2NF, 2nd Normal Form)
: 1NF -> 2NF로 바꾸는 것을 말하며, *부분 함수 종속을 제거한다는 원칙을 가지고 있다. 그리고 2NF는 1NF의 조건도 반드시 만족해야 한다.
제 1정규형까지만 정규화할 경우, 위에서 언급한 삽입이상, 삭제이상, 갱신이상이 발생할 수 있게 된다.
Case 1. 학생이 새 과목을 수강 신청할 때는 반드시 학생의 지도교수까지 알아야 한다. (과목이랑 지도교수는 연관성이 없는 데이터인데, 하나의 데이터를 삽입하기 위해 불필요한 정보를 알아야 한다.)
=> 삽입 이상
Case 2. '300'번 학생이 '통신공학' 과목을 취소하면, '300'번 학생의 레코드가 사라질 수 있다.
=> 삭제 이상
Case 3. '100'번 학생이 지도교수를 변경할 때, 위 테이블의 예시에서는 2개의 레코드 값을 모두 변경해주어야 한다.
=> 갱신 이상
이러한 이상 현상이 발생하는 이유는, 기본키('학번'과 '수강과목')가 아닌 속성들이 기본키에 *완전 함수 종속되지 못하고, 부분 함수 종속되어 있기 때문이다.
* 완전 함수 종속 : 종속자가 기본키에만 종속되며, 기본키가 여러 속성으로 구성되어 있을 경우, 기본키를 구성하는 모든 속성이 포함된 기본키의 부분집합에 종속된 경우
* 부분 함수 종속 : 테이블에서 기본키가 복합키일 경우,종속자가 기본키를 구성하는 속성 중 일부에게만 종속된 경우
위 예시로 보면 다음과 같이 테이블을 분리하는 것이다.
[학생] 테이블
학번 | 지도교수 | 학과 |
100 | 이상철 | 컴퓨터공학과 |
100 | 이상철 | 컴퓨터공학과 |
200 | 박종인 | 컴퓨터공학과 |
300 | 안주은 | 전자공학과 |
400 | 김유이 | 수학과 |
[성적] 테이블
학번 | 수강 과목 | 성적 |
100 | 데이터베이스개론 | A |
100 | 자료구조 | B |
200 | 클라우드 | B |
300 | 통신공학 | A |
400 | 미적분학 | C |
3. 제 3정규화 (3NF, 3rd Normal Form)
: 2NF -> 3NF로 바꾸는 것을 말하며, *이행 함수 종속을 제거한다는 원칙을 가지고 있다.
위 예시를 다시 살펴보면, 2NF를 만족하는 [학생] 테이블에서 이행 함수 종속이 생기는 것을 볼 수 있다.
즉, '학번' 데이터를 알면, '지도교수' 데이터를 알고, 그에 따라 '학과' 데이터도 알 수 있게 된다.
*이행 함수 종속 : 한 테이블 내에서 X, Y, Z 라는 3개의 속성이 있을 때, X->Y, Y->Z 란 종속 관계가 있고 X->Z가 성립한다면, 이를 이행 함수 종속이라고 말한다. 즉, X를 알면, Y도 알고 그를 통해 Z도 알 수 있는 경우를 말하는 것이다.
위 예시처럼 이행 함수 종속이 생기면, 다음과 같은 문제가 발생한다.
Case 1. 신설 학과가 생성되었는데, 아직 학생(학번)이 없으므로, 신설 학과에 대한 데이터를 추가할 수 없다.
=> 삽입 이상
Case 2. 기존 학과가 다른 학과로 통폐합되었는데, 지도교수와 학생은 여전히 학교에 존재한다. 이럴 경우, 기존 학과 데이터를 삭제하면 학생과 지도교수 데이터가 모두 사라지게 된다.
=> 삭제 이상
Case 3. 기존 학과 이름이 바뀌었는데, 이럴 경우 해당 학과에 속하는 학생들의 모든 '학과' 데이터를 변경해야 한다.
=> 갱신 이상
따라서 2NF만을 만족하는 테이블은 3NF도 만족하도록 테이블 설계를 업그레이드(?) 해야 한다. 위 예시의 [학생] 테이블을 다음과 같이, [학생] 테이블, [지도교수] 테이블로 나누면, 이행 함수 종속을 탈피할 수 있다.
[학생] 테이블
학번 | 지도교수 |
100 | 이상철 |
200 | 박종인 |
300 | 안주은 |
400 | 김유이 |
[지도교수] 테이블
지도교수 | 학과 |
이상철 | 컴퓨터공학과 |
박종인 | 컴퓨터공학과 |
안주은 | 전자공학과 |
김유이 | 수학과 |
3.5 BCNF (Boyce and Codde Normal Form)
: 3NF를 조금 더 강화시킨 개념으로, 강한 제3 정규형이라고도 한다. 모든 결정자는 항상 *후보키가 된다는 원칙을 가지고 있다.
*후보키 : 각 행을 유일하게 식별할 수 있는 최소한의 속성들을 가진 집합으로, 기본키가 될 수 있는 후보들이다. *슈퍼키 중 더 이상 줄일 수 없는 형태이기 때문에, 유일성과 최소성을 동시에 만족한다.
*슈퍼키 : 각 행을 유일하게 식별할 수 있는 속성들의 집합으로, 유일성은 만족하나, 최소성은 만족하지 못한다.
BCNF는 왜 필요할까? 다음과 같이 3NF를 만족하는 [학생수강] 테이블이 있다고 가정하자.
이런식의 테이블 설계는 왜 문제일까?
Case 1. 새로운 교수가 특정 과목을 담당하게 되어, 데이터를 추가하려고 하면, 아직 수강 학생이 없기 때문에, 새로운 교수 및 과목에 대한 레코드 삽입이 불가하다.
=> 삽입 이상
Case 2. 학번 '100'이 '자료구조' 과목을 취소하면, '이상철' 교수가 '자료구조'를 담당한다는 정보도 삭제되어 버린다.
=> 삭제 이상
Case 3. '이상철' 교수의 과목이 '자료구조'에서 '알고리즘'으로 바뀐다면, 담당교수가 '이상철'인 레코드를 모두 바꿔야 하는 문제가 생겨 버린다.
=> 갱신 이상
이러한 이상현상은 결국 결정자가 후보키로 취급되고 있지 않기 때문에 발생한다. 다음과 같은 테이블 구성을 통해 (학번, 과목명), (담당교수)의 집합을 기본키로 지정하면, 위와 같은 이상현상을 해결할 수 있다.
보통 실무에서는, BCNF 단계까지만 수행하는 경우가 많다.
대부분의 릴레이션의 경우, BCNF까지만 수행하여도 5NF의 요건을 만족하게 되기 때문이다.
4NF, 5NF로의 정규화는, 릴레이션 내의 모든 속성이 키에 해당되는 릴레이션일 경우에만 진행한다.
즉, 릴레이션 내에 존재하는 후보키가 복합키일 때만 필요한 것이다.
BCNF 이상으로 정규화를 수행하여 테이블을 쪼개놓으면, 장점보다는 단점이 더 많이 작용할 수 있다.
특히 *연결의 함정(Connection Trap)이 발생할 여지가 다분하다.
그래도 개념은 알아두면 좋으니, 제 4정규화와 제 5정규화까지 뭔지 살펴보도록 하자!
4. 제 4정규화 (4NF, 4th Normal Form)
: 3NF(or BCNF) -> 4NF의 과정으로, *다치 종속(Multi-valued Dependency)이 없어야 한다는 원칙을 가지고 있다.
아래와 같은 다치 종속을 만족하는 [학생] 테이블을 살펴보자.
*다치 종속(Multi-valued Dependency) : 어떠한 조건을 만족하는 튜플이 릴레이션 안에 있을 것을 요구하는 일종의 제약조건. 함수적 종속성에 속하는 것이 아닌, 별도로 구분되는 개념으로 본다.
'학과'와 '동아리'는 서로 관계가 없는 독립적인 관계인데, '학번'에 따라 결정되는 특성이 있다.
Case 1. 학번 '100' 학생의 경우, 컴퓨터공학과 전자공학 복수전공을 하고 있는데, 동아리도 2개를 가입하고 있다. 이런 상황에서, 학번 '100' 학생이 동아리 하나를 더 가입하면, '100' 학생에 대한 레코드를 의미없이 2개나 더 추가해야 하는 상황이 생겨버린다.
=> 삽입 이상
이렇게 서로 연관이 없는 여러 컬럼들이 결정자에 대해서 종속자의 관계를 가지고 있다면, 다음과 같이 결정자와 종속자가 1:1 관계가 되도록 테이블을 분해해주면 4NF를 만족한다.
참고로, [학생학과] 테이블은 복수전공을 한 학생은 학번 데이터가 2개 이상일 수 있으며, [학생동아리] 테이블은 한 학생이 동아리를 여러 개 가입했다면 학번 데이터가 2개 이상일 수 있다.
5. 제 5정규화 (5NF, 5th Normal Form)
: 4NF -> 5NF의 과정으로, *JOIN 종속을 제거한다는 원칙을 가지고 있다.
위에서 예시로 나온 4NF 형태의 [학생학과] 테이블과 [학생동아리] 테이블을 '학번'을 기준으로 JOIN 연산하면, 다음과 같은 테이블이 생성된다.
*JOIN 종속 : 하나의 테이블을 여러 개의 테이블로 분해하였다가, 다시 조인했을 때 데이터 손실은 없지만, 필요없는 데이터가 생기는 것을 말한다. 다치 종속의 개념을 더 일반화시킨 것이라 볼 수 있다.
위 테이블과 같이 중복된 데이터가 많아지면, 하나의 튜플이 가지는 특별한 의미도 없고, DB에서의 불필요한 연산도 증가하게 된다. 따라서 아래와 같이 3개의 테이블로 분해하여 JOIN 종속을 없앨 수 있다.
참고
https://velog.io/@wisdom-one/%EC%A0%95%EA%B7%9C%ED%99%94Normalization
https://www.sunny-son.space/MySQL/RDBMstart04/
'DB' 카테고리의 다른 글
[RDBMS] RDB 정규화와 이상(Anomaly)현상의 개념 및 예시 (0) | 2024.01.03 |
---|---|
[DB공통] OLTP vs OLAP 개념, 용도, 차이점 등 (0) | 2022.06.20 |
[DB공통] DB 성능을 위한 모니터링 지표 10가지 (0) | 2022.01.18 |
최근댓글