정규화(NORMALIZATION)
데이터베이스에서 테이블들을 설계시 여러 테이블들로 분할해서 데이터를 저장하고 있구나 하는 것을 알게 될 것이다. 그러면 왜 그런 형식으로 설계를 할까? 그것은 데이터를 논리적이고 비반복적인 형태로 분리하기 위함이다. 이것이 바로 정규화이다. 정규화는 관계형 데이터베이스의 개념과 같이 시작이 되었다.

테이블은 행(row)들과 열(column)들로 구성된 하나의 실체이며 데이터의 컬렉션인 엔티티(entity)이다. 하나의 테이블은 다른 테이블들과의 관계(relationship)를 맺을 수 있다. 이 관계 구성의 논리화가 바로 정규화로써 이루어지게 된다.
  정규화는 6차를 거쳐서 진행이 된다. 하지만 3차까지 만을 알아 보겠다. 왜냐하면 나머지 단계들은 실무에서는 거의 사용되지 않고 학계에서의 고려 대상이 되고 있기 때문이다. 정규화에서 중요한 것은 바로 기본 키가 된다. 모든 열들이 바로 기본 키에 대해서 존재의미를 갖는 3차 정규형식에 대해서 알아본다.

설계의 출발은 데이터 저장 매체인 엔티티(테이블)들을 구성하는 것이다. 일단은 서비스 흐름에서 찾아지는 기본적인 엔티티를 찾아서 그 엔티티로부터 정규화를 거치는 예를 들어 보도록 한다. 전자제품 대리점에서 고객이 물건을 주문하면 그 고객의 주문 정보가 생성이 된다. 바로 첫번째 엔티티가 생성이 되는 것이다. 그러면 ‘주문’이라는 엔티티에는 어떠한 항목들(필드 설정)이 들어가야하는지 다음의 테이블로 구현을 했다.

1차 정규형식(1NF, first normal form)
: 반복(중복)되는 데이터(그룹)를 분할하고 각 필드 값은 원소성(atomicity)이 되도록 한다.
  (여기서 분할의 설정이 고정 데이터인가, 가변적 데이터인가도 생각)

중복된 데이터를 찾아보기 위해 ‘주문’테이블에 다음처럼 발생 가능한 데이터를 입력해 보자. 이 테이블에는 하나의 주문에 대한 모든 정보가 다 들어 있다. 고로, 중복된 데이터가 있을수 있는 것이 된다.

이 테이블은 주문에 대한 자세한 정보가 들어가 있다고 했다. 그러면 왜 이테이블을 분할해야 하는가? 그 이유는 다음과 같다.

ㄱ. 데이터를 여러 번 저장하는 것은 공간 낭비

ㄴ. 반복적인 데이터가 존재한다는 것은 데이터의 이동량이 더 크게 된다. 따라서 데이터 버스나

    네트워크 대역폭에 더 많은 부담이 생긴다. 이는 전반적인 성능에 상당한 악영향을 미친다.

ㄷ. 반복 데이터들 간의 서로 모순된 데이터를 저장할 수 있다. 이것은 데이터 무결성이 깨져버린 

    것이다.

ㄹ. 결합된 데이터를 가진 열에 대해 어떠한 쿼리 명령을 내릴 경우  그 열 안에서 원하는 정보를

    분리시키는 과정을 거쳐야 하기에 속도가 떨어지게 된다.

1차 정규화를 시작하자. 이 테이블에서의 문제는 다음과 같다.
ㄱ. 고객 정보 부분은 데이터의 중복이 되어있다. 이 부분을 다른 테이블로 분할을 하게 된다.
ㄴ. 주문 상품 필드는 복합적인 데이터를 가지고 있다. 이 필드를 개별적인 필드들로 분할을 하게

    된다.

ㄱ.

고객 정보 부분을 다른 테이블로 분할을 할 때 생각을 해야할 것이 있다. 주문 테이블에서 떼어

   낸 후 연결을 할 매개체를 지정해야 하는 것이다. 그 연결은 ‘고객번호’필드로써 설정을 했다.

   그러므로 주문 테이블에서 고객번호 필드만을 남겨두고 고객 정보 모두를 제거 한다.

고객 정보는 다음과 같이 테이블을 구성한다.

이렇게 테이블을 분할함으로써 왕관의 데이터가 한번만 존재하게 되었다. 이것이 바로 중복 데이터의 제거이다. 이러므로 공간 절약과 중복 값들 사이의 모순을 방지할 수 있게 된 것이다.

ㄴ.
주문 테이블의 주문상품 필드가 갖는 복합적 데이터를 원소성이 유지되도록 분할을 해야 한다. 이 주문상품 필드엔 다음의 여러 정보가 들어 있음을 알수 있다.
1. 상품번호(모델번호)
2. 상품명(모델명)
3. 가격

이 항목들을 따로 존재하는 독립적인 정보로 만드는 것이 원소성을 유지하는 것이된다.
다음의 결과가 원소성을 위한 필드 분할 테이블이다.

결과 테이블을 보면 상품의 분할이 이루어져 원소성을 유지함을 알 수 있다. 그런데 기본 키 필드인 ‘주문번호’가 기본 키의 유일성이 깨져있다. 결과를 위한 각각의 행들은 고유한 데이터로써 분할은 했으나 기본 키 설정이 부적절하게 되어 데이터 식별이 어렵다. 이를 해결하기 위해서는 기본 키 추가 필드를 하나 더 만들도록 하자(다른 방법이 없는 것은 아니지만 지금으로써는 최선이라고 본다). 바로 복합 키를 설정하겠다는 뜻이다. 고객이 상품 주문 순서에 따른 필드를 하나 추가 하여 주문번호 필드와의 복합으로 기본 키 설정을 해 보면 다음의 테이블과 같이된다.

위 결과와 같이 각 주문에 대한 순서를 정하여 두개의 필드를 기본 키 설정으로 하게 되면 각 행들을 고유하게 식별할 수 있게된다.
이렇게 해서 1차 정규화를 거쳤다. 중복 되는 데이터도 없고 각각의 필드들은 원소성을 유지하고 있다.(가변적인 데이터는 중복 데이터가 아니다. 표현 그대로 선택시 마다 발생한 데이터일 뿐이다. 이것이 우연히 다른 데이터와 같을 수가 있는 것일 뿐이다.)

2차 정규형식(2NF)
: 2차 정규 형식은 다음의 규칙을 따르게 된다.
ㄱ. 1NF의 규칙을 만족해야 한다.
ㄴ. 모든 열은 반드시 키 전체에 의존 해야 한다. 키의 일부에만 의존한다면 정규화에 어긋나는 테이블이 되는 것이다.

그러면 위 1NF의 결과로 만들어진 ‘주문’ 테이블을 보자. 여기에서 복합키로 설정된 기본 키 전체에 의존하는 것이 아니라 하나의 필드에 의존하는 필드들이 있다. 바로 주문날짜와 고객번호이다. 이 필드들은 주문순서와는 상관이 없이 반복되며 오직 주문번호에만 의존하고 있다. 이것을 해결하려면 새로운 테이블로 분할을 해야한다.

주문 테이블을 2차 정규형식에 의해 분할을 한 결과이다.

3차 정규형식(3NF)
: 이제 정규화의 마무리 단계이다(이후의 형식들은 학계 이외에서는 별로 쓰이지 않는다). 3차 정규형식은 다음의 규칙을 따른다.

ㄱ. 2NF의 규칙 만족해야 한다.
ㄴ. 키가 아닌 필드에 의존하는 필드가 없어야 한다.
ㄷ. 필드 연산에 의한 결과값을 가지는 필드가 없어야 한다.

[주문상세] 테이블을 보면 기본 키가 아닌 상품번호에 의존하는 필드들이 있다. 바로 상품명과 단가 필드들인데 이 필드들은 다른 테이블로 분할을 해야 한다.

이렇게 해서 3차 정규형식중 ‘키가 아닌 필드에 의존하는 필드가 없어야 한다’를 만족 시켰고 나머지 하나인 필드연산에 의한 결과값을 가지는 필드는 아예 만들질 않았다. 그러면 결과값 필드 라는 것이 무엇일까? 다음의 예제 테이블에서 이것을 알아보자
(예제테이블)

위 예제 테이블에서 보면 바로 합계 필드가 필드들의 연산에 의한 결과값 저장 필드가 되는 것이다. 하지만 이경우는 데이터 검색 속도 향상을 위해 나누는 경우가 종종 있다.
이유는 WHERE 합계 > 5000 이 WHERE 수량 * 판매가격 > 5000 보다 빠르게 수행이 된다. 이런 경우를 ‘역정규화’라 한다. 실제로 실무에서는 이렇게 혼합된 방식을 사용하기도 한다. 이런 경우들이 존재하긴 해도, 원칙은 당연히 정규화를 거치는 것이다. 관계형 데이터베이스라는 것 자체가 정규화를 염두에 두고 설계된 것이기 때문이다. 정규화에 어딘가가 맞지 않는다는 것은 데이터 무결성에도 오류가 있을 수 있고 관계형 데이터 베이스 환경에서의 성능 면에서도 문제가 될 수 있는 것이다.

지금까지의 정규화로써 생성된 테이블들은 다음과 같다.
[주문]
[고객]
[주문상세]
[상품]

이 테이블들을 관계 형성을 하는 다이어그램으로 나타내 보자

실습을 위해서 EM에서 ‘shop’ 이라는 데이터베이스를 생성을 한다(3M).

다이어그램을 실행후 다음의 테이블들을 생성하고 관계설정을 한다.

[주문상세]
주문번호   int
주문순서   tinyint
상품번호   varchar(10)

[상품]
상품번호   varchar(10) PK
상품명      varchar(20)
단가         money
설명         varchar(50)