1 관계에 대한 이해

2 관계와 4차 정규화

3 결론

거의 대부분 사용되는 DBMS는 관계형DBMS(이하 RDBMS)다. 물론 오라클이나 PostgreSQL과 같은 경우는 객체관계형DBMS(이하 ORDBMS)이지만 거의 관계형답게 사용되고 있다. 어쨌든 '관계'라는 단어가 들어가는 것을 보면 관계가 매우 중요한 키워드임에는 틀림이 없다. 관계란 개체집합간의 관련이 생기게 되는 업무적인 이유다. 모델링에서는 개체집합 양방향에 대한 업무규칙으로 표현된다. 관계를 가짐으로써 개체집합간의 새로운 정보를 만드는 것이 관계의 존재이유다. 가령 다음과 같은 일상적인 글에서도 관계가 가지는 정보창출 능력을 알 수 있다.

• 이 세상에서 가장 향기로운 커피는 당신과 함께 마시는 커피입니다. – 맥심
  
• 법이 이불 속까지 들어와선 안 돼 – 중앙일보 뉴스기사 제목
  
  

첫 번째 광고카피는 ‘나’와 ‘당신’과 ‘커피를 마시는 관계’를 설정함으로써 맥심커피가 사랑스런 맛을 가졌다는 의미를 가지게 했다. 두 번째는 ‘법’과 ‘이불’을 연결하여 법이 어느 선까지 제약을 가할 수 있는지 알 수 있도록 하였다. 분명히 ‘나’와 ‘당신’은 연인 관계쯤 되겠지만 각각이 커피를 마시면 그저 향기로운 커피이겠지만 관계를 맺음으로써 가장 향기로운 커피가 된 것이다. 또한 ‘법’과 ‘이불’은 각각 배타적인 영역이 있다. 그러나 이들에게 관계를 맺어줌으로써 새로운 정보를 창출했음을 알 수 있다. 실제로는 나와 당신은 사람으로 순환관계를 가졌으나 커피가 끼어들어 아래와 같은 모델이 되었다. (아마도 대충 이럴 겁니다.)

관계의 중요성은 4차 정규화에서도 나타난다. 4차 정규화는 다치(Multi value)종속을 제거함으로써 없앨 수 있다. 예를 들어 다음과 같은 관계가 있다고 하면..

• 각각의 부서는 하나 이상의 사원을 배정받을 수 있다.
  
• 각각의 사원은 반드시 하나의 부서에 소속되어야 한다.
  
  

부서의 관점에서 보면 사원은 Multi Valued Fact이고, 사원의 관점에서 보면 부서는 Single Valued Fact다. 여기서 중요한 것은 부서와 사원간에 ‘관계’를 가짐으로써 Single Value, Multi Value가 의미가 있는 것이지 사원, 부서의 각각의 단일 관점에서는 의미가 없다는 것이 핵심이다. 4차 정규화는 대부분 3개의 개체집합 사이에서 나타난다. 이럴 경우 3개의 개체집합이 관계가 있는지 없는지 살펴봄으로써 해결을 할 수가 있다. 일단 4차 정규화의 정의를 내리자면 다음과 같다.

Multi Valued Dependency(MVD), X ->> Y (X Multi-Determines Y)

EX) 
Relation R(X, Y, Z): X, Y는 다치종속이면서 Y, Z가 서로 독립(관계없음)
이럴 경우는 R(X, Y, Z)를 R1(X, Y), R2(X, Z)로 분해하면 된다. 
만약 Y, Z가 독립이 아니면 4차 정규화의 대상이 아니다. 

구체적인 예를 들어보자. 다음 그림은 프로그래머, 자격증, 언어(C++ 등)와 관계를 나타내고 있다.

비정규화된 릴레이션은 다음과 같다. 자격증과 언어(프로그래밍언어)와는 관계가 없다.

프로그래머	자격증	언어
이재학	MCDBA OCP	C언어 Erlang
홍길동	MCSE OCP PMP	C# JAVA Perl Ruby
...	...	...

그림을 보면 프로그래머, 자격증, 언어의 관계에서 프로그래머와 자격증, 프로그래머와 언어는 관계가 있으나 자격증과 언어는 관계가 없음(서로 독립)을 알 수 있다. 그러므로 다음과 같이 모델링을 해서는 안 된다.

자격증과 언어는 서로 독립이므로 다음과 같이 해야 한다.

만약 자격증과 언어가 관계를 가진다면(독립이 아니라면) <그림3>과 같이 모델링하는 것이 맞다. 만약 자격증과 언어가 다:다의 관계를 가진다면 5차 정규화를 해야 한다. (아.. 그림다 지웠는데..하다보니 5차 정규화도 나와버리네요.. 또 그림 그려야 하네요..귀찮아 죽겠습니다.)

뭐 이따위로 해야 된다고 한다. 데이터양이 많지 않으면 대충해도 될 듯하다. 요즘은 S/W, H/W가 워낙 좋아서 양이 적으면 대충해도 잘 돌아간다. 요즘 같아서는 시스템 생명주기에 영향을 주지 않는다면 대충 빨리빨리 하여 시간 아끼는 것이라 가장 비용을 줄일는 일이라 생각된다. 누구에게나 시간은 평등하게 주어졌지만 같은 결과를 더 빨리하는 것이 앞서가는 일이 아닌가 싶다. 물론 엔지니어의 양심에 털이 삐죽삐죽 나겠지만..허허