Database Normalization
관계형 데이터베이스 이론에 엄청난 공헌을 한 영국의 컴퓨터 과학자인 Edgar F. Codd 는 표를 논리적으로 만들 수 있는 몇가지 방법을 만들어 냈습니다. 그 방법이 바로 데이터베이스 정규화 (Normalization) 입니다. 정규화란 관계형 데이터베이스 설계에서 데이터 중복을 최소화 시키는 과정을 가리킵니다. 저희가 고려해야할 수준은 제 3 정규형까지 (1NF, 2NF, 3NF) 인데, 그것들 모두 Edgar F. Codd 가 정립시킨 데이터 정규형입니다. 그 이후에 몇가지( BCNF, 4NF, 5NF 등)가 더 나왔지만 그것들은 보통 산업에서 쓰기엔 너무 까다롭고, 학술적으로 더 많이 쓰인다고 합니다. 다음은 정규화의 종류들과 충족 요건들입니다.
위 그림을 보시면, UNF (정규화가 되지 않은 상태) 부터 6NF (제 6 정규형) 까지 점점 더 충족요건이 많아집니다. 물론 제 6 정규형인 데이터가 가장 이상적이고 논리적이겠지만 산업에서 보통 쓰이는 데이터는 제 3정규형까지 충족시키면 충분합니다. 그리고, 일반적으로 제 3정규화(3NF)까지 만족하는 테이블들을 보고 ‘정규화가 되었다’라고 말합니다. 그러한 제 3정규화(3NF)까지 만족하는 테이블들은 보통 삽입, 변경, 삭제 이상이 없습니다. 그럼 이제 정규화 과정을 보시겠습니다.
목적
Edgar F. Codd 는 데이터베이스 정규화의 목적을 다음과 같이 명시했습니다.
- 데이터베이스의 변경시 이상 현상(갱신, 삽입, 삭제 이상) 제거
- 데이터베이스 구조 확장시 재 디자인 필요성 최소화
- 사용자에게 데이터 모델을 더욱 의미있게 만들기
- 다양한 질의 지원
정규화 과정
1NF => 2NF => 3NF
앞서 언급한 것처럼 테이블이 ‘정규화 되었다’ 라고 말하는 것은 보통 제 3정규형인 상태를 말합니다. 그러기위해선 제 1, 제 2정규형의 충족요건들을 먼저 충족시켜야 합니다.
1. 1NF 만족시키기
제 1 정규형(1NF) 충족요건
- 개별 테이블에서 다중값을 가지면 안됨
- 개별 테이블에서 반복 그룹을 가지면 안됨
- 기본 키를 사용하여 각 관련 데이터 세트 식별가능
- 각 관련 데이터 집합에 대해 별도의 테이블 생성
쉬운 이해를 위해 그림을 참고하겠습니다.
위 테이블은 고객의 이름과 전화번호를 저장하는 테이블입니다 (기본 키 : 고객 ID). 전화번호 컬럼에 여러개의 값을 가지는 고객이 있으므로 제 1 정규화 기준(1번)에 어긋납니다. 하지만 여러개의 전화번호를 가지는 일부 고객들을 위해 모든 전화번호 유지해야하는 요구사항이 있는 경우 어떻게 해야할까요?
한 컬럼에 다중값을 가지는 문제는 열을 하나 추가하는 방법으로 해결할 수 있습니다! 하지만 어떤 또다른 문제가 생기는지 아래 그림으로 보시죠!
위 테이블은 다중값을 제거했지만 여전히 큰 문제를 야기합니다. 바로 반복 그룹(전화번호 1열, 전화번호 2열 … 전화번호 n 열)에 대한 것입니다(2번기준 충족못함). 만약 어떤 고객이 전화번호를 30개 가지고 있다면 그 일부 고객을 위해서 전화번호 컬럼을 30개 만들어야하고 다른 대부분의 고객들은 29개의 컬럼에 null 값을 가져야합니다. 또한, 그 30개 전화번호열을 모두 검색해야 그 고객의 모든 전화번호를 알 수 있다는 것도 문제입니다.
그렇다면 하나의 행을 추가해서 다중값과 반복 그룹에대한 문제를 해결할 수 있지않을까요?? 그럴 수 있지만, 아쉽게도 여전히 1NF 기준을 만족시키지 못합니다.
위는 완벽한 해결책이 되지못합니다. 왜냐하면 기본키인 고객 ID 가 더이상 행을 고유하게 식별할 수 없기때문입니다(3번 기준을 충족못함). 즉, 각 관련 데이터 집합에 대해 별도의 테이블을 생성(4번기준)해서 제 1 정규화기준을 모두 만족시켜 보겠습니다.
위 그림처럼 별도의 테이블을 생성하여 제 1정규화 기준을 모두 충족시킬 수 있습니다. 위 두 테이블은 ‘고객 ID’ 를 키로 1:N 관계를 가집니다.
이제 제 2 정규화 방법에 대해 알아보겠습니다.
2. 2NF 만족시키기
제 2 정규형(2NF) 충족요건
- 제 1정규형 충족요건을 모두 충족
- 모든 속성은 반드시 모든 후보키에 종속되어야 함 (부분 종속성이 없어야 함)
다음으로 보실 예시 테이블은 1NF 는 충족하지만 2NF 는 아닙니다. 여기선 하나의 기본키가 아닌 후보키 (Manufacturer, Model) 가 있습니다.
위 테이블의 ‘Manufacturer country’ 은 후보키중 ‘Manufacturer’ 에만 종속되기때문에 ‘Manufacturer’ 에 따라 중복되는 문제가 있습니다. 즉, 이 테이블은 ‘Model Full Name’ 만 후보키 모두에 종속되므로 이것을 남기고 ‘Manufacturer country’ 를 따로 빼서 별도의 테이블을 만들면 부분 종속성문제를 해결할 수 있습니다.
3. 3NF 만족시키기
제 3 정규형(3NF) 충족요건
- 제 1, 2정규형 충족요건을 모두 충족
- 속성간에는 서로 종속될 수 없다
다음으로 보실 예시 테이블은 1NF, 2NF 는 충족하지만 3NF 는 아닙니다. 아래 테이블의 각 행은 특정 해에 특정 토너먼트에서 누가 우승했는지 알려야 하기 때문에, 행을 고유하게 식별할 수 있는 최소한의 속성 집합인 [‘Tournament’, ‘Year’] 를 후보키로 사용합니다.
위 테이블의 ‘Winner’s date of birth’ 속성은 ‘Winner’ 라는 다른 속성에 종속되는 것을 보실 수 있습니다. 이 테이블의 형식에선, 동일인물이 여러번 우승할 경우 그 사람의 생년월일은 계속 중복될 것이기 때문에 다음과 같이 둘로 나눠 줄 필요가 있습니다.
마치며..
테이블을 정교하게 만들어 데이터중복을 피하려면 점점 더 많은 충족요건을 만족시켜야 합니다. 이것은 우리가 테이블을 정말 잘 관찰해야 한다는 것을 의미하는데요, 위 예시처럼 몇개없는 컬럼들의 관계를 파악하기도 쉽지않다는 것을 느꼈습니다. 이 과정은 까다롭지만, 이상 현상(갱신, 삽입, 삭제 이상) 제거, 구조 확장시 재 디자인 필요성 최소화 등 다양한 이점들이 있기때문에 꼭 필요한 과정이라고 생각합니다!
