[자료퍼옴] DB 정규화의 중요성 (1,2,3 차 정규화 종합 예시)

제1 정규형 : 필드에는 최소 데이터만 입력해야만 필드 자료의 중복여부가 명확해진다. 
제2 정규형 : 필드들은 기능적으로 종속관계를 가져야 한다. 따라서 기본키/고유키와 관련되지 않는 자료는 따로 분리한다.
제3 정규형 : 다른 필드(정보)에서 파생되거나 계산해서 얻어낼 수 있는 필드는 제거한다.(각 필드의 데이터를 독립적이어야 한 필드의 값을 변경했을 때 다른 필드에 영향이 미치지 않게 된다.)


데이터베이스에서 가장 중요한 이론이 무엇인가? 라고 질문한다면 단연 정규화 이론이 될 것입니다. 정보가 안정적으로 구성이 되고 사용자 요구사항을 정확하게 처리하며 효율적으로 관리될 수 있는 근간 이론이기 때문에 정규화 이론은 매우 중요하다고 할 수 있습니다. 

데이터베이스 전문가로 현장에 있으면서 많이 답답한 것 중에 하나는 우리가 학교에서 또는 전문가과정을 통해 배웠던 정규화 이론이 도무지 실질적으로 적용되어야 할 현장에서는 아무런 도움이 안되게 적용된다는 점입니다. 잘못된 설계, 데이터의 중복, 결정자의 이상한 구성 등 여러 가지 불합리한 요소가 있음에도 불구하고 마치 정상적인 설계가 된 것 처럼 데이터베이스를 생성하고 그것을 통해 어플리케이션을 구현하는 사례가 너무나 많이 있습니다. 

정규화의 이론은 분석/설계를 하는 DBA뿐만 아니라 분석/설계자 개발자 모두 이해해야 하는 아주 중요한 이론입니다. 업무를 분석하고 설계하는 사람이 DBA가 아니고 보통 분석/설계자(개발자)가 많이 하기 때문이지요….. 

그런데 IT를 구축하는 업무현장에 가보면 첫 번째는 정규화의 이론을 정확하게 모르는 경우가 대다수 이고,, 두 번째는 정규화의 이론을 알기는 알아도 대학에서 배우는 학사관리 정도의 샘플을 이해하는 수준이 대다수 이다는 데 문제의 심각성이 있습니다. 

아시겠지만, 데이터베이스는 한번 구축하여 운영환경에서 기동이 되면 그 구조를 전면적으로 교체하는 것은 불가능에 가깝지요… 구조를 바꾼다는 것은 새로운 프로젝트를 의미하고 그것은 곧 엄청난 돈이 반영되어야 하기 때문에 운영 중 구조 변경을 할 수가 없는 것입니다. 

그래서 분석/설계단계에서부터 정확한 정규화를 반영하고 성능과 단순화 전략에 따라 정규화된 모델을 반정규화(역정규화)하여 적용하는 체계화되고 기술적인 데이터모델링이 필요합니다. 

분석/설계자, 개발자, DBA모두 이 분야에 대해서는 체계적인 교육을 받으시고 설계 때 그것을 정확하게 디자인할 수 있는 능력을 꼭 확보하시기 바랍니다. 

다음은 실전 프로젝트에서 나타난 사례 한가지를 통해 1차, 2차, 3차 정규화가 어떻게 수행되었는지를 보여주도록 하겠습니다. 

첫 번째 그림은 회원이라는 테이블을 디자인한 사례입니다. 이 모델을 보고 잘된 테이블 또는 잘못된 테이블이라 이야기할 수 있을까요?(물론 간단한 업무의 이해는 필요합니다. 상식적인 업무이해를 바탕으로 한번 해 보시지요^^) 
 

만은 경우 이 모델이 왜 잘되었는지? 왜 개선이 필요한지 잘 설명하지 못하지요…. 그냥 감각적으로 ‘한 명의 회원이 카드를 두 번 이상 분실 할 수 있으니 한 테이블에 둘 수 없겠네....’ 라고 생각할 수 있는 정도일 것입니다. 

사실 위 모델의 경우 한명의 회원이 여러 번의 카드를 분실 할 수 있기 때문에 Repeating Value가 발생합니다. 결정자이면서 PK인 회원번호에 대해 여러 개의 값이 존재하는 1차 정규형을 위반한 경우에 해당하지요…. 이 경우 입력/수정/삭제이상(Anomaly)이 발생되어 분실정보 데이터입력시 원하지 않는 회원의 회원명, 전화번호등을 입력해야 합니다. 또한 회원정보를 수정할 때 분실한 수만큼 수정해야 하고 분실정보를 삭제하는데 원하지 않은 회원정보까지 삭제하는 이상현상이 발생됩니다. 

바로 1차 정규화를 해야 하는 이유에 해당하지요… 이런식으로 논리적으로 접근할 수 있는 근간이론이 있기 때문에 이 근거를 이용하여 이 테이블이 개선이 필요하다 이렇게 접근해야 합니다. 바로 그것이 전문가로서 우리가 해야 할 일이지요… 

또한 한명의 회원에 대해서도 여러 개의 카드를 소지할 수 있기 때문에 이 또한 1차 정규화의 대상이 될 수 있습니다. 

따라서 위 테이블은 다음과 같이 1차 정규화를 할 수 있습니다… 

1차 정규화 - 1
 

1차 정규화 - 2
 

1차 정규화가 완료된 위 모델에서 보면 다시 상품카드번호와 상품카드명 사이에 부분함수종속성이 발생되어 입력/수정/삭제의 이상이 모두 발생됩니다. 2차 정규화가 필요한 경우에 해당합니다. 

 

2차 정규화를 했지만, 역시 접수자사번 -> {접수자직위, 접수자명} 이렇게 그리고 접수자부서 -> 접수자부서명 이렇게 함수종속관계를 가져 3차 정규화가 필요한 규칙이 포함되어 있습니다. 이것을 판단하는 근거는 결정자와 종속자를 판단하는 것이기도 합니다. 

 

위 사례는 프로젝트에서 발생한 한 가지 사례에 대해서 샘플로서 보여준 것입니다. 

보통은 일부러 정규화를 하지 않더라도 우리가 논리적으로 생각하는 바가 이런 정규화된 구조로 생각이 됩니다. 그래서 따로 정규화 이론에 근거하여 설계를 하지 않아도 되는데요.. 문제는 완벽하지 않게 설계가 되는 것이 문제입니다. 바로 그 때 검증의 방법으로 그리고 설계의 수준을 높이는 방법으로 정규화 이론에 입각하여 다시 한번 데이터모델을 디자인하는 것이 필요합니다. 

정규화 이론을 완벽하게 이해하는 것도 어려운 일이기는 합니다. 그렇기 때문에 전문가로 있는 사람은 더 많은 학습과 훈련이 필요하다고 할 수 있습니다. 

과거와 다르게 이제는 건물도 정교한 고층건물 그리고 다양한 기능을 가진 기능성 건물로 지어지고 있습니다. IT시스템도 더 정교해지고 많은 기능을 가지는 시스템이 계속 개발이 되고 있지요… 이럴 때 일수록 핵심이론에 충실하면서 체계화된 설계적 기법이 적용되어야 훌륭한 시스템을 만들어 낼 수 있습니다. 

DB 가이드넷 자료. http://www.dbguide.net/knowledge.db?cmd=specialist_view&boardUid=166051&boardConfigUid=82&boardStep=&categoryUid=