지난 포스터에서 이야기했던 이상과 함수 종속성에 이어 마지막으로 정규화에 대해 이야기해보려고 합니다

이상을 치료하는 방법인 정규화는 치료 스케일에 따라 그 규약이 더욱 빡빡해 집니다

즉 정규화 숫자가 올라갈수록 더 어렵다는 이야기가 되겠습니다.

먼저 제 1 정규화(1NF)에 대해서 이야기해봅시다

제 1 정규화는 테이블에 있는 모든 속성의 레코드 값이 원자값을 가지고 있는 형태를 말합니다.

여기서 새로운 개념이 등장하네요 바로 원자값이란 개념이죠

여기서 말하는 원자값이란 쉽게 설명하자면 최소한으로 쪼갤 수 있는 데이터의 한계입니다.

예를들어 주민등록번호를 생각해보면 주민등록번호를 앞자리와 뒷자리로 나누어 저장 할 수도 있는 것입니다.

<주민등록번호> -> <주민번호 앞자리, 주민번호 뒷자리>

사실 원자값은 설계자가 원자값이 있다고 판단되면 설계자 입장에서는 원자값이 있는것입니다. 약간 애매한 해석의 여지를 담고 있는것이지요

예제 하나 더 보고 가보도록 합시다

어떤 헬스장에서 회원정보를 아래와 같은 테이블에 넣어 보관하고 있다고 해봅시다

그런데 여기서 철수 회원이 업무 때문에 전화번호가 하나 더 생겼습니다.

그러면 아래와 같은 테이블이 됩니다.

이렇게 되면 똑똑한 개발자는 전화번호라는 하나의 속성에 두개의 값을 지니고 있는 것은 원자값을 가지고 있지 않다는 것을 알아차리게 될 것입니다.

따라서 개발자는 다음과 같이 테이블을 분리했습니다.

이렇게 반복되는 속성을 기준으로 기본키 속성과 함께 새로운 테이블을 만드는 것입니다.

(참고로 🗝️는 외래키입니다.)

다음은 제 2 정규화(2NF)입니다.

제 2 정규화는 제 1 정규화를 만족하면서 완전 함수 종속인 테이블이 되었을 때 제 2 정규화라고 합니다.

여기서 이전에 포스트에서 봤던 내용인 완전 함수 종속이 나오네요

잘 상기하면서 예제를 보도록 합시다.

여기서 잘보면

생년월일은 굳이 앞자리 뒷자리 둘다 쓸 필요 없이 앞자리만으로 정보를 알아낼 수 있죠

이를 표현하면 다음과 같이 됩니다.

주민번호 앞자리*주민번호 뒷자리 -> 생년월일     ---------   완전함수종속 위반

주민번호 앞자리 -> 생년월일    

즉 주민번호 앞자리 말고 생년월일 정보를 알아낼 수 있는 다른 최소 속성 조합은 존재하지 않기 때문에 주민번호 앞자리 -> 생년월일 이라는 정보를 바탕으로 다음과 같이 테이블을 분리합니다.

제 3 정규화(3NF)는 제 2정규화를 만족하고 후보키가 아닌 속성들에서 이행 종속이 없는 테이블을 말합니다.

이번에도 이전에 포스트에서 봤던 내용인 이행 종속이 나오네요

잘 상기하면서 예제를 보도록 합시다.

여기서 학과 건물은 학과와 연관이 있습니다 그리고 학과는 학번과 연결되어 있죠

학번-> 학과

학과-> 학과건물

이러한 이행종속은 다음과 같이 풀어줍니다.

마지막 BCNF는 제3정규화를 만족하고 모든 결정자는 후보키여야 합니다.

여기서 결정자란 테이블의 나머지 속성을 모두 결정할 수 있는 속성을 말합니다.

예를들어 학번을 알고 있으면 이름과 주소 성별을 알 수 있겠네요 그러면 학번이 결정자가 됩니다.

학번 -> (이름, 주소, 학년, 성별)

예를 들어보죠

위 테이블을 분석해보면 학번과 과목으로 교수를 결정할 수 있습니다. 그러나 교수가 한학기당 한 과목을 맡게되면 교수라는 속성으로 다시 과목을 결정할 수 있게 됩니다.

함수 종속 표현으로 표현하면 다음과 같이 되는거죠

학번,과목-> 교수

교수-> 과목

이렇게 되면 교수라는 속성은 현재 후보키가 아니기 때문에 BCNF를 만족하지 않게 되는군요

따라서 교수를 후보키로 하는 새로운 테이블을 만들어 줘야합니다.

이렇듯 정규화까지 알아봤습니다. 이러한 정규화는 데이터의 중복을 낮춰주지만 반대로 조인 연산 비용이 증가하여 지나친 정규화는 시스템에 큰 부담이 됩니다. 따라서 정규화를 사용할려면 데이터 안정성과 시스템 부하에 적절한 트레이드 오프를 잘 정해야합니다.