ERD보고 간단히 정규화여부 판단하기

데이터베이스의 중요성 
IT 개발자들 중에는 비전산 출신들이 많다.  한마디로 말해서 대학교 때 전산과목을 이수하지 않은 사람들이다.  더구나, 최근에는 전산관련학과 출신인데도 불구하고 데이터베이스론을 수강하지 않은 개발자도 많다. 
(내가 신입사원을 면접할 때, 전산관련학과인데도 불구하고 데이터베이스론을 수강하지 않은 지원자들이 많다는 것을 알고 놀랐다!!)

불행히도, 시스템을 구축하려면 데이터베이스에 대해서 잘 알아야 한다. IT 개발자는 데이터베이스와 친하게 지내야 하고, 특정한 애플리케이션을 위한 데이터베이스가 어떤 구조로 이루어져 있는지 설명하는 데이터모델을 이해해야한다. 이해하지 못하면, 프로그램을 작성할 수 없거나, 이상한 코드를 만들어 낸다. 

ERD 표기법
IT 개발을 처음 시작하는 사람들이 처음 만나는 문제 중 하나는, 데이터베이스에 대한 구조에 대한 정보를 ERD(Entity Relationship Diagram)로 받는다는 것이다.  

데이터베이스론을 들을 사람들은 "ERD 쯤이야  학교에서 배웠지" 라고 생각하고, ERD를 받아 본 순간 당황하지 않았는지 모르겠다. 왜냐하면, 국내 대학교에서 사용하는 교재 중 다수가 피터 첸(Dr Peter Chen) 표기법을 따르기 때문이다.  http://www.edrawsoft.com/chen-erd.php  내 자신도 대학교를 갓 졸업하고 첫번째 프로젝트에서 피터 첸 표기법에 따라 ERD를 그리다가 속성(attribute)이 많은 경우에 표기하기도 힘들었고, 관리해 주는 툴도 많지 않아서 결국은 포기했었던 기억이 난다. (피터 첸의 표기법은 관계에 중점을 둔 표기법이라고 할 수 있는데..  실무에서는 복잡한 관계를 선호하지 않는 것 같다)

최근에는 ERD 표기법으로는 정보공학(Information Engineering) 표기법과 바커(Richard Barker) 표기법을 주로 사용한다. Barker 표기법은 오라클 문서에서 자주 찾아 볼 수 있고, 엔코아(http://www.en-core.com/)에서 만든 DA# 툴에서 기본 표기법으로 사용되고 있다. DAP 자격증 관련 교재에서도 볼 수 있다.  

정보공학 표기법은 ERWin 을 사용하는 개발자에게 가장 익숙한 표기법일 것이다. 사실 ERWin 툴에서는 디폴트로 IDEF1x(Integration Definition for Function Modeling) 표기법으로 설정되어 있는데.. 대부분의 분석/설계자들은 옵션에서 정보공학 표기법으로 바꿔서 사용한다.

그렇다. 실제 프로젝트에서 개발을 한다면 정보공학 표기법에 따른 ERD나 바커 표기법이 좀 더 실용적인 것이다.

데이터 모델의 적합성
개발자가 ERD를 받았을 때, 이를 이해하는 문제는 개발자 자신의 역량에 관한 문제다.  이 첫 번째 문제를 지나면, ERD로 주어진 모델이 얼마나 적합한지 판단해야 하는 두 번째 문제에 부딪치게 된다.

ERD 모델이 얼마나 적합하진 판단해야 한다고? 무슨 이야긴가?  

베테랑 분석/설계자와 같이 일하면 데이터 모델이 깔끔하다. 관리할 대상을 누락시키지도 않고, 개발자가 너무 복잡한 조인을 하지 않도록 성능을 고려하여 적절한 반(역)정규화도 해 준다. 한마디로 개발자가 복 받은 거다.  

하지만...  초보 분석/설계자와 같이 일을 하면... 원하지 않은 정신적인 수양을 해야 한다. 이들이 만든 데이터모델에 따라  개발하면 누락되거나 이상현상이 발생하여, 프로그램을 수시로 고치거나 고난이도의 SQL문장을 작성해야 하는 일이 잦아질 수 있다.  같이 밥먹는 것은 물론 쳐다보기도 싫어질 수 있다.  

중급이상 개발자라면 초보 분석/설계자를 적절히 리딩하는 센스가 필요하다.  이런 경우, ERD를 보고
1) 이상현상을 최소화하기 위하여 정규화를 진행시키고,  
2) 자주 사용하고 중요한 질의 속도를 향상시키기 위하여 적절한 반(역)정규화를 수행시켜야 할 것이다. 

기존 정규형의 설명방식
그렇다면 ERD를 보고, 어떻게 정규화를 진행시킬 것인지 알아보자.

불행히도 데이터베이스론에 관한 많은 책들이 정규화 및 정규형을 설명할 때, 간단한 예제 테이블을 가지고 설명한다.
예를 들면, http://en.wikipedia.org/wiki/1NF, http://en.wikipedia.org/wiki/2NF  이런 식으로 설명한다.
대충 이해는 된다.  그런데.. 이거 가지고는 부족하다.  좀 더 친절한 설명을 찾아 보면   http://kb.devgear.co.kr/pages/viewpage.action?pageId=3637484  에 나와 있다.
정규화의 과정은 아래의 URL에 그림으로 설명되어 있다. http://yuhani.springnote.com/pages/916900

그런데.. 실무자들이 보기에는 너무 어렵지 않은가? 


ERD를 보고 간단히 정규형 판단하기
좀 쉽게 할 수는 없을까? 도대체 함수적 종속, 부분함수적 종속, 이행적 함수 종속 이런 내용을 어떻게 이해해야 하는가?
개발 실무자들이 ERD를 보고 쉽게 판단하는 요령에 대해서 적어 보도록 하겠다.

1) 일단 ERD는 논리 모델을 보고 작업하는 것이 바람직하다. 물리 모델을 보고 작업하면, 해당 테이블의 컬럼명을 보고 관계를 추정해야 하므로 작업이 어려워 진다.  (논리모델에서는 속성명이 한글로 표현되므로 이들 간의 관계를 파악하기 쉽다)
2) 함수적 종속이란 하나의 속성이 변하면 다른 속성이 변하는 관계라고 쉽게 생각하자.



제1정규형의 판단
제1정규형은 테이블 형태(Relation)이며, 중복된 행(Repeating Groups)이 없어야 한다. 모든 속성은 원자값(atomic value)를 가져야 한다. 
http://en.wikipedia.org/wiki/1NF
http://ko.wikipedia.org/wiki/%EC%A0%9C_1_%EC%A0%95%EA%B7%9C%ED%98%95
라고 설명하고 있다.

실무적인 관점에서 보면 다음과 같이 판단하면 될 것이다.
1) 대부분 RDBMS를 기반으로 하고 있으므로 ERD의 엔터티들은 표형태로 된다고 볼 수 있다.

2) 어차피 RDBMS에 들어 가는 값은 정해진 데이터 타입에 따를 수 밖에 없으므로 원자값이 들어간다고 볼 수 있다.  다만, 문자열 데이터 유형에 리스트 형태로 데이터를 저장해 달라는 요구만 없으면 된다. 이것은 ERD만 보고는 속성이 집합형태인지 하나의 값인지 판단하기 힘들다.  

3) 1)과 2)는 기본 사항이고, 엔터티가 주식별자(또는 PK(Primary Key))를 가지면 1차 정규형이라고 보면 된다.  

제1정규형인지 판단하는 것은 쉽다. ERD에 있는 모든 엔터티들이 주식별자(또는 PK)가 표시되어 있는지 확인하면 된다. 


제2정규형의 판단
제2정규형은 부분적 함수종속의 제거 해야 한다고 나와 있다.
말이 어렵다.

1) 주식별자(또는 PK)가 하나의 속성(또는 컬럼)으로 되어 있으면 무조건 2차 정규형이다.
   이것은 부분적 함수종속성 정의가 주식별자가 합성키(2개이상의 후보키)로 이루어져 있는 경우에, 합성키의 일부분과 식별자가 아닌 속성이 종속관계가 있으면 안된다고 정의했기 때문이다. 

2) 주식별자가 2개 이상의 속성로 이루어져 있으면, 주식별자의 부분집합이 되는 속성들이 주식별자 아닌 속성이 종속관계가 없어야 한다.  

 사실 2)는 2차 정규형의 정의와 같다. 글로 이해하는데 시간이 걸릴 수 있으므로, 쉽게 그림을 보고 이해하자. 

그림에서 주식별자는 상품코드와 고객코드이다.  상품코드만 변한다고 해서 고객명, 주문일시, 주문수량 속성이 변하는가?  아니다. 안변한다.  그러므로 상품코드속성과 주식별자가 아닌 속성들 사이에는 종속관계가 없다.
그런데, 고객코드 속성이 변하면 고객명 속성이 .. 변한다.. 이런...  종속관계가 있다.  따라서, 이런 종속관계가 있는 속성들을 따로 모아서 별도의 엔터티로 분리해야 한다.

다음과 같이 변하면 된다. 

따라서, ERD에 있는 엔터티들이 2차 정규형을 만족하는 지 보려면, 주식별자가 2개 이상 속성으로 이루어진 엔터티를 찾고, 주식별자를 이루는 속성과 나머지 속성들이 종속관계가 있는지 일일이 체크해야 한다.


 
제3정규형의 판단
제3정규형은 이행적 함수종속의 제거 해야 한다고 나와 있다.
이것도 어려운 이야기다.

1) 제1정규형 확인-> 제2정규형 확인을 한 후에
2) 주식별자가 아닌 속성들 사이에 종속관계가 있는지 확인하면 된다.

3차는 쉽다. 위의 글미에서 주식별자가 아닌 속성들은 사원명, 부서코드, 부서명 이다. 이들 간에 종속관계를 보는 것이다. 이들 중...  부서코드가 변하면 부서명이 변할 것이다.  종속관계가 존재하는 것이다. 이런 경우는 종속관계가 있는 속성들을 별도의 엔터티로 분리해야 한다.

부서코드에 종속된 부서명 속성을 별도로 부서 엔터티로 분리하였다.  

제3정규형인지 판단하려면 엔터티의 주식별자가 아닌 속성들 중에서 종속관계가 있는지 일일이 체크하면된다.



그런데.. 2차 정규형과 3차 정규형이 헷갈리는가?  이 부분은 다음과 같은 방법으로 기억하면 절대로 잊혀지지 않는다. 

2차 정규형을 생각할 때, 2라는 숫자에 주목해 보자.  전체 주식별자를 겉으로 보고, 이를 구성하는 속성들은 안에 있는 이중구조로 생각하면 기억하기 쉽다.  2차 정규형은 주식별자의 안에 있는 속성과 주식별자가 아닌 속성들간의 종속을 제거하는 것이다. 

그렇다면 3차 정규형은?  3이라는 숫자에 주목해 보자. 일반적으로 제3자는 관계없는 사람이다. 그렇다. 주식별자와 관계가 없는 속성들은 제3자로 보는 것이다. 이런 놈들끼리 종속관계가 있는 것을 제거하자는 것이 제3정규형이다. 


쉽게 설명하려고 하였는데...  과연 도움이 되었는지 모르겠다.  

실습을 해보자. DBGuide.net 에서 다음 URL을 따라가 보면 증권-계정계-채권관리 데이터모델이 나온다.
http://www.dbguide.net/db.db?cmd=view2&boardUid=135035&boardConfigUid=58&boardStep=0&categoryUid=288&boardIdx=1141

여기서 일부 엔터티가 2차, 3차 정규형이 아니다.  물론, 2차와 3차 정규형으로 만들지 않은 이유가 분명히 존재할 것이다. 이 모델이 잘못되었다는 것이 아니다. 위의 글을 읽고 쉽게 찾을 수 있는지 체크해 보라는 의미이다. 

출처 : http://tobewiseys.tistory.com/98

IT와 삶 블로그