4장. 데이터 모델링(Data Modeling)

4장. 데이터 모델링(Data Modeling)

데이터 모델링을 하는 이유가 무엇일까요? 그 이유는 현실에 불규칙하게 흩어져 있는 데이터를 현실세계와 컴퓨터세계에 모두 표현하기 위함입니다. 즉, 데이터 모델링은 현실세계에 불규칙하게 흩어져 있는 데이터들을 정리하여 컴퓨터 세계에 표현하기 위한 중간 과정이라고 할 수 있습니다. 물론 데이터베이스를 구축하는 이유도 데이터 모델링을 하는 이유를 포함하기도 합니다. 데이터 모델링은 건물을 지을 때 설계도 수준보다도 정밀한 청사진 수준에 비유를 하기도 합니다. 그 만큼 객관적인 판단에 의거한 구체적인 것이어야 한다는 뜻입니다.

 

데이터 모델링을 위한 도구로는 현재 가장 널리 쓰이고 있는 ERD(Entity Relationship Diagram)을 사용할 것입니다.(독자분들은 “데이터 모델링 = ERD”라는 등식이 맞다고 단정짓지는 말아야 겠습니다.) 3장에서 이미 데이터 모델링을 하기 위한 관점과 개념에 대해서 설명하였습니다. 우리는 이를 기초로 데이터 모델링하고, 검토를 거친 후 관계형 모델로 전환하여 컴퓨터 세계(물리적인 데이터베이스 설계)를 할 것입니다.

 

일반적으로 자료 및 요구사항 분석/조사 과정을 마치고, 데이터 모델링을 하게 됩니다. 데이터 모델링은 사람의 뼈대와 같은 구실을 하며, 데이터 모델링에서 사용자의 정보 요구사항을 포함하지 못한다면 성공적인 정보시스템 구축을 할 수 없습니다.

 

1장, 2장, 3장에서는 데이터 모델링에서 필요한 개념을 알아보았습니다. 이러한 개념을 바탕으로 데이터 모델링 기법을 알아보고, 좀더 기능이 많은 DB 설계 툴인 Power Designer 9.0으로 실습을 해보도록 하겠습니다. 4장의 앞부분에 파워디자이너의 사용 방법을 간단히 소개합니다. 어차피 데이터베이스의 기초 이론에서 만들어진 툴이므로 개념만 있으시다면 사용법에 대해서는 걱정하지 않으셔도 될 것입니다. 앞에서 정보공학적 방법론에 대한 것을 언급했었는데 이 부분은 정보공학적 방법론 중 일부의 과정입니다.

 

4장에 들어가기 전에 Power Designer 9.0 과 Oracle9i DataBase를 셋업하셔야 합니다. 꼭 9i 버전을 사용하지 않으셔도 됩니다. 다만 필자의 실습환경은 윈도우용 오라클9i 버전을 사용하고 있습니다.

 

<참고>

 

Oracle9i DataBase 다운로드 받는 곳

http://otn.oracle.co.kr

 

그냥 다운 받으면 시간이 꽤 오래 걸립니다. Flash Get 같은 다운로드 툴을 이용해서 받으시면 빠를 것입니다.

</참고>

 

<쉬어가기>

 

Setup의 공부효과

 

필자가 처음으로 컴퓨터를 접했을 때는 16bit XT 컴퓨터 였습니다. 5.25인치 디스켓을 넣고 MS-DOS를 부팅해서 사용했습니다. 게임을 하려고 디스켓을 조심히 들고 다니고 3.5인치 디스크 드라이브가 그렇게 가지고 싶은데 돈이 없어서 엄두도 못냈습니다. 그때가 중학교 때의 일입니다. 그 후 다시는 컴퓨터라는 것을 접하지 않겠다는 각오를 했었습니다. 그러나 98년도 여름에 다시 컴퓨터를 구입했습니다. 그때 당시는 완전히 컴맹이 였습니다. 16비트 컴퓨터와 팬티엄급 컴퓨터 사이의 공백이 너무 컸었습니다. 사운드 카드가 안잡혀서 6시간 걸려서 잡았습니다.  지금도 저의 옆에서 아주 큰 역할을 하고 있는 처음이나 마찬가지의 컴퓨터입니다. 그 컴퓨터는 저 때문에 너무 많은 고생을 했습니다. 이틀 동안 윈도우 NT4.0을 20번 가량 셋업하는 고문을 당하고, 한 달 동안  솔라리스 셋업의 고통을 받는 등의 저의 만행을 모두 받아 주었습니다. 한 동안은 저를 보는 사람마다 “또 깔어??” 라고 물어볼 정도로 포멧과 셋업을 반복했습니다. 그러나 이 만행들은 모르는 사이에 많은 지식을 가지게 했습니다. 네트웍 환경 설정이라든지 파티션의 개념 같       은 기본적인 공부를 할 수 있는 것이죠. 우리가 리눅스나 다른 OS를 처음 셋업할 때 그 과정은 많은 것을 알 수 있게 해줍니다.

 

오라클 DBMS를 셋업하실 때도 리눅스나 유닉스 환경에서 셋업해보는 것을 권장합니다. 만약 리눅스나 유닉스를 접해보시지 않은 분들이 리눅스나 유닉스 환경에서 오라클 DBMS 셋업에 성공하신다면 그는 아마도 리눅스, 유닉스에 초보자라고는 하지 않을 만큼의 실력(OS운용에 대한 실력)을 갖출 수 있다고 장담합니다.

 

필자는 웬만한 시리얼 넘버는 다 외워질 정도로 다 많은 만행을 저질렀습니다. 컴퓨터를 이용하는 공부를 시작하시는 분들은 반드시 이런 만행을 저질러 줘야 할 것입니다. 이것이 필자가 생각하는 컴퓨터에 대한 공부의 빠른 시작이라고 생각합니다. 필자는 한 때 OS를 7개까지 멀티부팅을 한 적이 있습니다. 7개의 멀티부팅을 성공했을 때의 기쁨이란 이루 말할 수 없었습니다. 여러분도 이러한 기쁨을 누리게 되면 컴퓨터를 공부하는 기본적인 지식을 갖추리라 장담합니다.    

 

</숴어가기>

 

1. 데이터 모델링(Data Modeling)이란?

데이터 모델링이란 현실의 불확실한 데이터를 정보모델링을 통해 사용자의 정보요구사항을 조사하고, 이를 최대한 데이터베이스에 반영하기 위한 하나의 가시화하는 것이라고 할 수 있습니다. 다음 그림을 먼저 살펴봅시다.

<그림 4_1.jpg> 데이터 모델링

 

그림에서 보는 바와 같이 현실세계의 흩어져 있는 데이터를 정보모델링을 통하여 개념을 구조화 시킵니다. 개념세계는 시스템을 사용하고자 하는 사용자들이 보는 관점입니다. 이를 데이터 모델링을 통하여 컴퓨터 세계의 논리적 구조와 개념 세계의 정보구조를 Mapping시킵니다. 결국 데이터의 구조화를 통해서 데이터는 저장장치(비휘발성 저장장치)에 저장됩니다. 이렇게 구축된 최종 시스템은 최대한 현실을 반영하고 이는 컴퓨터 세계와 현실 세계의 일치성을 가지게 합니다. 즉, 데이터 모델링은 현실세계를 컴퓨터세계로 표현하기 위한 중간 과정이라고 볼 수 있습니다.

 

<용어>휘발성과 비휘발성

컴퓨터에서 휘발성이라고 하면 전원을 껐을 때 저장되어 있던 데이터가 삭제되느냐 삭제가 되지 않고 남아 있느냐의 문제입니다. 즉, 디스크로부터 메모리나 캐쉬에 올려지는 데이터는 휘발성 데이터이고, 디스크에 저장된 데이터는 비휘발성 데이터입니다. 데이터베이스에서 다루는 데이터란 비휘발성 데이터를 의미합니다. 그러나 DBMS는 하나의 소프트웨어입니다. DBMS가 돌아가기 위해서는 OS가 있어야 하고, 일반적으로 많은 메모리(휘발성 데이터를 담는 곳)를 필요로 합니다.

 

이러한 휘발성 데이터와 비휘발성 데이터를 어떻게 다루느냐가 시스템의 성능을 좌우한다고 해도 과언이 아니라할 만큼 중요합니다. 여러 DBMS 제품들은 휘발성 데이터와 비휘발성 데이터를 다루는 기법이 서로 비슷합니다. 이에 대해서는 DBMS를 다룰 때 좀더 자세히 언급하겠습니다.

</용어>

 

이러한 현실세계를 컴퓨터세계에 표현하기 위해서는 무엇보다도 현실에 흩어져 있는 데이터를 구조화(여기서 말하는 구조화는 방법론이나 패러다임이 아님) 시키는 것이 중요합니다. 우리는 이미 1장에서 “데이터베이스는 최대한 현실을 반영해야 한다” 라는 것을 살펴보았고, 현실을 잘 반영하기 위한 구조로써 “3단계 스키마구조” 를 살펴 보았습니다. 3단계 스키마 구조는 개념단계에서 각각의 사용의 관점을 표현 했었고, 논리적인 단계는 모든 사용자의 관점을 나타내는 것이 였습니다. 데이터 모델링은 삼단계 스키마 구조 중 개념단계와 논리 단계를 표현하는 단계입니다. 즉, 자료 및 요구사항 조사/분석을 통해서 각각의 사용자가 필요한 정보가 무엇인지 파악하고 이를 통합시키는 과정이 데이터 모델링입니다.

 

2. 개체-관계 다이어그램(ERD)의 표기법

ERD는 수작업 방식에서 출발하는 데이터 관리기법에서 데이터베이스라는 개념이 출현하기 전까지는 없었지요. 그러나 계층형, 네트워크형 데이터 모델이 나오고, 이들 데이터 모델을 개선한 관계형 모델이 나오면서 발전된 데이터모델링 도구입니다.

 

데이터 모델링은 개념적인 표현입니다. (요즘은 개념적 ERD, 논리적 ERD, 물리적 ERD등으로 물리적으로 표현하기 전까지의 ERD를 모두 말합니다. 이 책에서는 개념적인 것과 논리적인 것을 딱 잘라서 구분하지는 않겠습니다. 이유는 모델러마다의 개념과 논리의 선이 약간씩 다르기 때문에 혼돈의 여지가 있기 때문입니다.) 개념적인 것을 논리적인 모델(관계형 모델)로 표현하는 것이 편리한 것이 ERD이기 때문에 ERD와 관계형 모델은 같이 발전 했다고 봐도 과언이 아닙니다. 초기에 ERD를 표현 하는 방법은 다음과 같이 단순했었습니다.

<그림 4_2.jpg> 초기 ERD의 모습

 

이러한 ERD 표기법은 사용자의 정보욕구를 표현하기에 부족하였습니다. 그래서 지금 많이 사용하는 표기법으로 우리가 3장에서 사용한 툴의 표기법을 사용하게 되었습니다.

 

또한 ERD는 사용자와 DB 개발자와의 의사소통 수단으로 많이 이용됩니다. 왜냐하면 표기법과 그 개념이 쉬운 편에 속하기 때문에 사용자의 관점에서 현실을 표현하기 쉽기 때문입니다. (RAD 기법 중 JRD에서도 많이 사용)사용자와의 의사소통은 데이터베이스 설계에서 많은 부분을 차지하고 있기 때문에 ERD의 역할은 실로 엄청난 것입니다. ERD는 현실의 개념세계를 표현하고, 이를 컴퓨터세계로 표현하기 위한 다리역할과 사용자와의 의사소통 수단으로 아직까지 각광을 받고 있습니다.

 

사실 초기의 ERD표기법보다는 많은 표현을 할 수 있지만 툴의 표기법도 약간은 부족합니다그러나 개념만 확실히 정립되어 있다면 표기법은 문제가 되지 않습니다. 그럼 툴에서 사용되고 있는 ERD 표기 법에 대해서 자세히 알아보도록 하겠습니다. 복습도 할 겸 엔티티 집합, 속성, 관계에 대해서 툴을 이용해서 그려보고 개념을 좀더 다른 각도에서 살펴보겠습니다.

<그림 4_3.gif> 엔티티 집합의 표현

우리는 앞에서 데이터 모델링에 대한 정의를 알아보았습니다. 이러한 데이터 모델링을 위한 도구가 지금 하고 있는 ERD입니다. 도구라는 의미에서 꼭 눈에 보이는 삽, 호미 등의 이러한 것만이 아닙니다. ERD는 개체와 개체들 간의 관계로 보는 관점에서 현실을 표현하는 즉, 모델링을 위한 하나의 툴인 것입니다. 이러한 ERD라는 도구의 특성에서 우리는 엔티티와 엔티티 집합의 개념을 확실히 알아야만 합니다. 데이터 모델링은 앞에서 언급했듯이 현실세계와 컴퓨터 세계를 연결하는 구실을 하고 있습니다. 이러한 모델링 도구로써 ERD를 사용하는 것이고 ERD의 핵심 개념 중에 하나인 개체(Entity)는 위의 그림처럼 네모 박스로 표현합니다.   

<그림 4_4.gif> 엔티티 집합간의 관계 표현

 

위의 그림은 엔티티 집합들 간의 관계를 설정한 것입니다. ERD는 현실을 개체와 관계로 표현하는 데이터 모델링의 기법이기 때문에 엔티티 집합 간에는 반드시 관계가 있어야 하는 것입니다. 관계가 맺어지지 않는다면 그것이 과연 엔티티 집합인가를 고려해 봐야 합니다.

 

각각의 엔티티는 속성을 가집니다. 엔티티는 속성을 가짐으로써 스스로 의미를 가질 수 있습니다. 즉, 속성은 엔티티의 특성을 나타내어 엔티티 집합을 이루며 다른 엔티티 집합과의 관계를 통해서 사용자의 정보욕구를 충족시켜줍니다. 속성의 표현은 초기 ERD 표기법에서 쓰는 것과 같이 하는 방법도 있고, 다음과 같이 조그마한 동그라미로 표현하기도합니다.

<그림 4_5.jpg> 발전된 ERD의 모습

위의 그림은 ERD의 일부이며, 초기의 ERD에서보다 발전된 모습을 보이고 있습니다. 주식별자의 표시로 속성을 표현한 조그마한 동그라미에 검은 색으로 채워진 것입니다. 속성의 표기법으로 큰 타원형을 쓰는 것보다는 조금은 덜 복잡한 그림이 되었습니다. 혹자는 전문가가 복잡성을 따지고 있냐라고 할 수도 있습니다. 그러나 ERD는 사용자와의 의사소통 수단이 될 수 있으므로(꼭 ERD를 이용해서 실 사용자와의 의사소통을 할 필요는 없습니다.) 최대한 복잡성이 없는 ERD를 만들어야 할 것입니다. 여기서 말하는 최대한의 복잡성을 없애는 것은 사용자가 원하는 정보를 만족시키는 범위 안이라는 것은 당연하고, 표기법상의 복잡성을 이야기 하는 것입니다.

 

그러나 요즘은 ERD를 손으로 그리는 것이 아니라 툴을 많이 사용합니다. 이것은 정보공학의 방법론과도 관련이 있으며, 어느 정도 자동화도 이루어져 있습니다. 보통의 많이 사용하는 표기법은 우리가 사용하는 DeZign for database와 같은 표기법입니다.

<그림 4_6.bmp> DeZign for database의 속성의 표기법

 

<참고>

사실 우리가 처음에 툴을 다루기 시작할 때 DBMS(DataBase Management System)를 오라클로 선택하고 들어왔습니다. 이것은 특정 DBMS에 종속적인 DB 설계를 하게 됨을 의미하는 것입니다. 즉, 논리적인 설계를 한 것이지요. 기본적으로는 개념적인 설계단계에서는 특정 DBMS에 종속적이지 않아야 합니다. DBMS의 선택은 기업의 환경에 맞추어야 하는데 실제로 그렇지 않습니다. 실무에서는 4가지 정도의 DBMS 선택 방법이 있다고 합니다. 이런 문제로 옛날에 제가 어느 사이트에 질문을 올렸던 적이 있습니다. 다음은 그 답변의 내용입니다.

 

우선 첫번째로 RFP(제안서)에서부터 고객이 DBMS를 지정한 경우가 있고, 두번째로는 RFP를 보고 제안서 작성시 특정 DBMS가 적합하겠다고 판단하여 제안에 포함시키는 경우, 세 번째는 제안팀에서 가장 자신 있는 DBMS를 제안하여 프로젝트를 수행하겠노라고 제안서를 작성하는 경우, 네 번째는 알고 계신 것처럼 고객의 요구사항과 환경 등을 분석하고 개념적 설계를 거쳐 최적의 시스템 솔루션을 결정하는 경우로 정리해 볼 수 있습니다.

 

위에서 정리한 네 가지 경우 중 대부분은 첫번째, 두 번째가 많다고 합니다. 첫번째와 두번째 방법은 프로젝트 발주단계에서 고객이 이미 DBMS를 결정해서 프로젝트 발주를 하거나 고객사의 특수한 내부사정으로 특정 DBMS가 결정이 되거나, 또는 고객사에서 이미 그 DBMS를 사용 중인 경우도 있습니다. 이 경우에 이미 DBMS가 결정되어 있기 때문에 제안서는 당연히 그 DBMS에 맞춰서 작성될 것이고, 이것이 실제 구현 시 프로젝트에 적합치 않으면 프로젝트 팀원들이 무척 애를 먹는 경우가 많다고 합니다. 세 번째는 비교적 흔치 않고, 네번째 경우는 실제로 가장 바람직하지만 모든 것이 제로베이스에서 시작하여 구축해가는 장기 프로젝트에서 가끔 볼 수 있습니다. 어떤 경우건 제출된 제안서를 고객사는 검토하여 받아들이게 되고, 그 후에는 프로젝트팀은 프로젝트 성공을 위해 최선을 다하겠지만 그 DBMS가 과연 올바른 선택이었나 하고 훗날에 후회하는 상황이 발생한다면 그건 공동의 책임이라 생각합니다. 아주 가끔 이런 문제로 분쟁이 발생하거든요.

</ 참고 >

 

ERD를 그리기 전에는 많은 작업이 필요로 합니다. 우리는 2장에서 요구사항 분석에 관련된 사항을 살펴보았습니다. 정보공학은 데이터와 프로세스를 수직으로 분할하고 이 두 부분을 수평적으로 접근해 나아가는 방법을 사용하고 있습니다. 이 부분에서는 요구사항 조사/분석과 관련된 부분이 이미 끝났다는 가정하에 이루어 지는 것입니다.

 

3.  약엔티티 집합과 Power Designer 9.0의 시작

약엔티티란 혼자 존재할 수 없는 엔티티를 말합니다. 즉, 다른 엔티티 집합(부모)에 의해서 엔티티(자식) 집합이 생겨나고, 그 자식은 부모 엔티티가 없어지면 자식도 따라서 사라지는 경우를 말합니다. 즉, 다른 엔티티 집합이 존재함으로 해서 자신이 존재할 수 있을 때 이를 약 엔티티라고 합니다. 3장에서 “사원”과 “특기”와 관계를 맺어 준 것을 봐주시기 바랍니다.

여기서 “이재학” 사원이 퇴사를 한다면 “사원” 에 종속적인 “특기”에 있는 “이재학” 사원에 대한 항목은 없어져야 할 것입니다. 크게 생각해 본다면 “사원” 엔티티 집합이 없어진다면 “특기” 엔티티도 존재할 수 없는 것이지요. 즉, “특기” 엔티티 집합은 이렇게 혼자 존재할 수 없는 약한 엔티티 집합이고 이를 줄여서  약엔티티 집합이라고 합니다. 보통은 다른 엔티티 집합에서 온 외부식별자를 포함하고 그 외부식별자가 주식별자의 일부가 되었을 때를 보면 됩니다. 약엔티티 집합에 대한 정의는 딱 정해지지 않았습니다. 책마다 학자마다 서로 약간은 다른 의견을 보이고 있습니다. 필자는 위에서 이야기한 개념으로 약 엔티티 집합을 설명할 것입니다.

 

3장에서 우리는 약엔티티 집합에 대한 표현을 하지 못했었습니다. DeZign for database툴의 기능이 이를 뒷받침해주지 못하고 있었기 때문입니다. 이제 여러 가지 많은 기능이 포함된 Power Designer 9.0으로 실습을 하겠습니다. Power Designer 9.0은 아래의 URL에서 다운로드 하여 사용하시기 바랍니다.

<박스>

SyBase Power Designer 9.0 다운 받는 곳

 

Documentation - http://download.sybase.com/eval/pdesigner/PowerDesigner90_Doc.exe

Web Documentation - http://sybooks.sybase.com/pd.html

Application - http://download.sybase.com/eval/pdesigner/PowerDesigner90_Trial.exe

</박스>

 

툴을 새로 익혀야 하는 부담감이 있을 수 있습니다. 그러나 기본개념이 확실히 정립되어 있다면 툴의 사용법 익히는 것은 아주 쉬울 것입니다.

다음은 Power Designer 9.0를 셋업하고 처음으로 만나는 화면입니다.

<그림 4_7.bmp>

 

도구바의 New를 클릭하거나 [File] à [New...]를 선택합니다.

<그림 4_8.bmp>

 

<그림 4_9.bmp>

 

[New]를 선택하면 <그림 4-9> 와 같은 폼을 만나게 됩니다. 여기서 Conceptual Data Model을 선택 후 OK 버튼을 클릭합니다. 그러면 아래와 같은 화면을 만나게 될 것입니다. 우리는 Palette에 보는 것들을 이용해서 개념적인 데이터 모델을 생성할 것입니다. Power Designer 9.0 의 사용법은 셋업한 후 도움말과 매뉴얼이 같이 셋업이 되므로 여기서 설명한 부분을 벗어나는 것은 도움말과 매뉴얼을 참고하시면 될 것입니다.

 

<그림 4_10.bmp>

 

이제 Power Designer 9.0 사용 시작을 했으니 50%의 사용법을 익힌 것이나 마찬가지입니다. <그림 4-9>에서와 같이 파워디자이너에서는 개념적인 데이터 모델과 물리적인 데이터 모델을 구분해서 데이터 모델링 작업을 할 수 있습니다. 먼저 사용한 DeZign for database는 물리적인 데이터 모델을 사용하였습니다. 앞서서 언급했듯이 설계 초기단계는 특정 DBMS를 대상으로 데이터 모델링 작업을 수행하지 않습니다. 이런 면에서 DeZign for database는 가벼운 설계를 할 때 아주 편한 툴입니다. 호미로 해결될 것을 포크레인까지 동원할 필요는 없는 것이겠지요.

 

앞에서 DeZign For DataBase를 이용해서 구현하지 못한 부분이 있었다는 것을 기억하시는지요? 구현 못한 부분은 다중값 속성에 관한 것이였습니다. 다중값 속성을 가지는 “사원” 엔티티 집합을 파워디자이너를 이용해서 해보겠습니다.

 

1) 파워디자이너를 구동하면 위의 그림과 같은 작업공간(WorkSpace)를 만나게 됩니다. 우측에 Palette에서 Entity를 클릭한 후 작업공간에 적절히 배치합니다.

<그림 4_11.bmp>

 

2) 작업 공간에 배치한 엔티티 집합에서 표시된 엔티티 집합을 더블클릭을 합니다.

<그림 4_12.bmp>

 

3) 엔티티를 더블 클릭하면 다음과 같은 화면을 만날 수 있습니다. General  탭에서 Name에 “부서”를 입력하고, Entity_2도 같은 방법으로 Name에 “사원”을 입력합니다.

<그림 4_13.bmp>

 

4) 확인 버튼을 누르면 다음과 같은 엔티티 집합의 모습을 볼 수 있습니다. Relationship을 선택하고 “부서”에서 “사원”으로 마우스 왼쪽키를 누른 채 연결해 줍니다.

<그림 4_13.bmp>

 

5) “부서”와 “사원”간의 관계를 연결시켜 주면 다음과 같이 기본으로 카디날리티가 설정된 연결 모습이 보입니다. 연결된 관계를 더블 클릭하여 관계에 대한 설정을 해줍니다.

<그림 4_15.bmp>

 

6) 관계를 더블 클릭하면 다음과 같은 화면을 만날 수 있으며, General 탭의 Name에 “소속” 이라고 넣어 줍니다.

<그림 4_16.bmp>

 

7) 현재 상태에서 Detail 탭으로 이동한 후 Mandatory에 체크를 해줍니다. 그러면 “각각의 사원은 하나의 부서에 속한다” 라는 관계를 가지게 되고, “ 각각의 부서는 반드시 한명 이상의 사원이 소속된다”라는 관계를 가지게 됩니다.

 

<그림 4_17.bmp>

 

8) [확인] 버튼을 누르면 두 엔티티와 관계의 설정된 모습이 보입니다.

<그림 4_18.bmp>

 

9) 이제 <그림 4-13> 에서 본 엔티티의 속성을 나타내는 화면을 불러옵니다. Attribute 탭을 선택합니다. 우리는 이미 “부서”의 주 식별자는 “부서번호”이고, “사원”의 주 식별자는 “사원번호”라는 것을 알고 있습니다. 각 엔티티 집합의 주 식별자를 결정했으니, 삽입하여 줍니다.

<그림 4_19.bmp>

<그림 4_20.bmp>

주식별자에 체크한 후 Idnetifiers 탭으로 이동하여 “부서번호”를 등록하여 줍니다.

 

다음은 “부서”와 “사원”의 속성명과 데이터 타입입니다.

사원                데이타 타입

-------------   -------------

사원번호    NUMBER(4)

이름                       VARCHAR2(10)

주소                       VARCHAR2(40)

 

부서               데이타 타입

-------------   -------------

부서번호    NUMBER(2)

부서이름    VARCHAR2(14)

 

<그림 4_21.bmp>

 

10) 다음은 “사원”의 순환(recursive)관계를 맺어 줍니다. Palette에서 Relationship을 선택하고, 사원에서 출발하여 사원으로 끝을 맺어 줍니다.

<그림 4_22.bmp>

여기서 “관리”라는 관계를 맺어 줬는데 불구하고, 다른 속성이 하나 생기지 않은 것에 대해서는 의아해하지 마시길 바랍니다. 파워디자이너에서 개념적 모델에서는 외부키의 표현을 하지 않기 때문입니다. 구체적인 것은 물리적인 모델로 변환했을 때 나타나게 됩니다.

 

<참고>

Power Designer 의 버전의 차이

 

필자는 Power Designer 7.5를 주로 사용합니다. 파워 디자이너의 엔티티 집합에서 주식별자의 표현은 다음과 같이 밑줄로 표시합니다.

 

<그림 4_23.bmp>

 

필자의 경우는 7.5 버전의 표현력이 좋다고 생각하고 있는데, 독자분들은 어떨지 모르겠습니다. 사실 초보자 분들은 (0, 1) 같은 최대/최소 카디날리티에 대해서 저 그림을 보면 무지 해깔려 하시더군요. 그러나 관계에 대한 선의 표현을 본다면 전혀 헤깔리지 않습니다. 다른분은 최대/최소 카디날리티의 수치적인 표현을 기준으로 하고 있을지도 모릅니다. 만약 지금 저 그림이 헤깔리셨다면 아직 기초가 정립되지 않은 것입니다. 이것은 제가 앞에서 언급했던 비, 바람 과도 같습니다. 뿌리가 깊은 나무는 이런 비, 바람에 흔들리지 않습니다.

저는 책을 쓰면서 처음으로 9.0 버전을 접했습니다. 그러나 전혀 불편함이 없이 아주 재미있게 쓰고 있습니다. 그렇다고 제가 그렇게 뿌리 깊은 나무는 아닙니다. 그저 아주 작은 비였고, 아주 작은 바람이였기에 흔들리지 않았을 뿐입니다. ^^;

 

</참고>

 

11) 이제 문제의 다중값 속성인 “특기”에 대해서 살펴보겠습니다. “특기”는 “사원”의 다중값 속성입니다. 다중값 속성을 다루는 것은 논리적 설계단계(관계형 모델로의 적용)에서 할 일이라고 생각해도 됩니다. 그러나 툴을 이용하므로 “특기”까지 완성되면 물리적 ERD를 자동으로 생성시킬 수 있습니다. 일단 개념적 ERD를 그려본 후에 단계적으로 사용해 보겠습니다. 실전에서는 단계적인 사고방식에 의해서 다중값이라는 표시만 하고, 상세 ERD를 그리는 과정에서 표현하면 되는 것입니다. 이렇게 단계적인 개발 방법을 사용하는 이유는 개발 초기부터 복잡성에 빠지지 않기 위해서 입니다. 안그래도 처음에 데이터베이스 설계를 한다고 하면 뜬구름 잡는 것 같은데 처음부터 너무 복잡성에 빠져들게 되면 제대로 된 설계가 이루어지기 힘들죠.

 

여기서는 데이터 모델링 기법을 익히는 것이기 때문에 약엔티티에 대한 해결을 해보겠습니다. 앞에서도 언급했듯이 약엔티티 집합은 약엔티티 집합이 생겨나게 한 부모 엔티티 집합에 종속적입니다.

 

다음과 같이 “특기”라는 엔티티 집합을 만들고 생각해 보겠습니다.

<그림 4_24.bmp>

 

12) “사원”과 “특기” 간의 관계를 더블클릭 한 후 General 탭의 Name에 “보유”라고 입력하고, Detail 탭으로 이동하여 다음 그림에서와 같이 설정하여 줍니다. 주의해야 할 것은 Dependency에 꼭 체크를 해야 한다는 것입니다.

<그림 4_25.bmp>

 

13) 확인 버튼을 누르면 다음과 같이 종속적이 표현이 된 것이 보입니다.

<그림 4_26.bmp>

 

14) 마지막으로 “특기”에 대한 속성을 넣어 줍니다. 3장에서 “특기” 엔티티 집합에 대한 속성으로 “특기”, “사원번호”가 있었습니다. 그러나 “특기”라는 것이 엔티티 집합과 속성에 존재하므로 혼돈의 여지가 있습니다. 엔티티 집합의 이름을 바꾸던지 속성의 이름을 바꾸어 주어야 합니다. 여기서는 엔티티 집합의 이름을 “사원_특기”로 하겠습니다.

 

<그림 4_27.bmp>

 

Power Designer 9.0 에서는 엔티티 집합을 표현할 때 3간으로 나누어서 맨 위는 엔티티 집합의 이름, 두번째 칸에는 속성, 세번째 칸에는 주식별자를 표시합니다. 여기서 주식별자의 이름은 나중에 물리적 ERD에서 사용되는 Primary Key의 제약조건 이름이 됩니다. 일단은 그렇게 알고 계시면 되겠습니다. 나중에 물리적 설계를 설명할 때 다시 설명하도록 하겠습니다.

 

<참고>

 

약엔티티 집합의 모호성

약엔티티 집합을 다른 개체에 의해 존재여부가 좌우되는 개체로 정의한다면, 다른 엔티티 집합에 대해 최소카디날리티가 1인 관계에 있는 어떤 개체도 모두 약한 엔티티 집합이 됩니다. 위의 “부서”와 “사원”에서의 예에서 “부서”는 최소 카디날리티가 1입니다. 이런 의미로 따져볼 때  “사원” 엔티티 집합은 약엔티티 집합이 됩니다. 즉, 한명의 사원이 반드시 하나의 부서를 가져야 한다면 “사원”은 약한 엔티티 집합이 됩니다. 왜냐하면 “사원”이 소속되어야 할 “부서”가 존재하지 않는다면 저장될 수 없기 때문입니다. 이 책에서는 이러한 의미를 가지는 약엔티티 집합을 설명하고 있는 것이 아니라 다른 엔티티 집합에 논리적으로 정확하게 종속(약엔티티는 종속되는 엔티티 집합에 부분집합)되는 것을 말합니다.

 

</참고>

 

15) 위에서 생성한 개념적 ERD를 물리적 ERD로 변환했을 때 어떠한 모습을 보이고 있을 까요? 메뉴에서 [Tool] à [Generate Physical Data Model] 을 선택합니다.

 

<그림 4_28.bmp>

Generate new Physical Data Model 을 선택한 후, DBMS에서 해당 물리적 데이터 모델로 변환될 타겟 DBMS를 선택해 줍니다. 여기서는 그림에서와 같이 ORACLE Version 9i를 선택했습니다.

 

16) 확인을 누르면 물리적 데이터 모델로 변환됩니다.

<그림 4_29.bmp>

 

그림을 보면  화살표의 화살촉이 있는 부분이 1 측이고, 화살촉이 없는 부분은 다측입니다. 개념적 데이터 모델에서는 보이지 않던 것들이 많이 보입니다. 다른 것은 나중에 살펴보고 여기서는 “사원_특기” 엔티티 집합의 “사원번호+ 특기”가 PK로 잡혀 있는 것이 보입니다. 의미상으로 볼 때 주식별자는 Primary Key(PK)로 보고, 외부식별자는 Foreign Key(FK)로 보면 됩니다. 앞서서 약 엔티티 집합에 대한 설명을 했었습니다. 위의 그림과 같이 “사원_특기”는 사원번호가 FK가 되고, 또한 PK의 일부가 되어 있는 것이 보입니다.

 

17) 최종적으로 완성된 모습입니다.

<그림 4_30.bmp>

 

독자분들 중에는 사원  중 특기가 없는 사람은 어떻게 하는가? 에 대한 고민을 하시는 분이 있으리라 생각합니다. 그러나 전혀 고민할 필요가 없습니다. 그림에서 보는바와 같이 “사원_특기”의 기본키는 “사원번호 + 특기” 입니다. 즉, 특기가 없는 사원은 입력이 안됀다는 뜻이지요. 특기가 없는 사원의 특기를 괜시리 “없음” 등으로 표현한다는 것도 쓸때없는 짓을 시스템에게 시키는 것과 같은 일입니다.

 

만약 “사원_특기”에 “특기번호”라는 설계속성을 추가하여 “특기번호”를 주식별자로 대치하면 어떨까요? 여기에서 고려해봐야 하는 것은 어떤 정보를 사용자가 원하냐는 것입니다. 사용자는 아마도 “사원이 가지고 있는 특기 “ 일 것입니다. 즉, 데이터베이스에서 특정 사원에 대한 “특기”를  조회할 때는 검색조건으로 사원번호가 필히 들어간다는 뜻입니다. 또한 특기만 검색할 수도 있습니다. 여기서 특기를 사원이 보유한 어떤 특별한 기술을 뜻한다면 특기에 따라서 프로젝트에 대한 작업을 배정할 수도 있는 것입니다. 이것은 데이터에서 처리과정을 거쳐서 정보를 뽑아내어 이 정보를 이용해서 의사결정을 하는데 도움을 주는 것이지요. 이렇게 살펴볼 때 “특기번호”라는 설계속성을 추가할 이유가 없습니다. 만약 이와 같은 상황이라면 “특기번호”를 추가한다면 시스템에 부담을 더 주는 것뿐 별로 이득이 없습니다.

 

4.  서브타입(Sub Type)과 슈퍼타입(Super Type)

 

서브타입과 슈퍼타입은 초기 ERD 모델에서는 찾아 볼 수 없던 확장된 모델입니다. 서브타입이란 선택적으로 취할 수 있는 속성의 집합을 말합니다. 선택적이라는 것은 여러 개의 엔티티집합이 모여서 하나의 통합적인 집합을 이룰 수 있을 때, 그 통합된 집합에서 선택적(부분적) 집합을 포함한다는 뜻입니다. 요즘에 무료로 홈페이지 계정을 준답시고 3MB 주고 홈페이지를 운영하라고 합니다. 즉, 무료로 회원가입을 받고, 3MB의 계정용량을 받고, 돈을 주면 프리미엄 회원으로 등록되고 더 많은 용량을 제공하는 것을 볼 수 있습니다. 여기서 통합적인 개념으로 살펴본다면 프리미엄 회원과 무료 회원은 “회원”이라는 것을 통합 할 수있습니다.

<그림 4_34.jpg> 프리미엄회원과 무료회원의 통합

 

즉, 회원의 분류는 돈을 냈느냐 내지 않았느냐의 기준으로 나뉘게 되고, 회원은 선택적으로 프리미엄 회원이 되든지 무료회원이 되어야 하는 것입니다.

 

여기서 더 깊이 생각해야 할 것은 무료회원이 돈만 내면 프리미엄 회원이 될 수 있다는 것입니다. 또한 회원이 처음부터 프리미엄 회원과 무료회원으로 즉, 오직 하나의 서브타입에 속해야 하느냐(회원의 부분집합인가?)를 따져봐야 합니다. 만약 이런 부분을 따져 보지 않는 다면 일부 속성을 적용할 수 없을 것입니다. 예를 들면 남자와 여자를 통합하여 사람이라는 하나의 집합으로 통합했을 때 남자의 일부 속성은 여자에는 의미가 없을 수 있다는 것입니다.

 

위의 그림을 좀더 살펴보도록 하겠습니다. 아마도 독자분들 중에는 그림이 조금 이상하다고 느끼시는 분들이 계실 겁니다. 일반적으로 웹에서 홈페이지 계정을 얻으려고 무료회원가입을 한 뒤 계정용량을 더 받으려면 돈을 지불합니다. 즉, 무료회원이란 의미가 별로 없는 것입니다. 또한 회원 가입 당시 프리미엄 회원으로 등록할 수도 있을 수도 있습니다.  다른 측면을 살펴본다면 대부분의 회원들은 무료 회원이며, 무료회원에 비해서 프리미엄 회원의 숫자가 매우 적으므로 회원이라는 통합적인 집합에서 따로 관리해야 할 대상이 되는 것은 프리미엄 회원일 뿐입니다. 이러한 측면에서 볼 때 <그림 4-34>의 서브타입과 슈퍼타입의 관계는 의미가 없다는 뜻입니다. 그럴 리는 없겠지만 회원가입 당시에 돈을 지불하지 않으면 영원히 무료회원으로 남는다면 <그림 4-34>의 서브타입과 슈퍼타입이 관계는 성립될 수도 있습니다. 그러나 위의 그림에서는 “회원”의 속성으로 “회원등급”으로 프리미엄 회원과 무료회원을 관리하는 것이 더 낳은 방법이라 할 수 습니다. 또는 특별히 “프리미엄 회원”만 따로 관리할 수 있을 것입니다. 즉, “프리미엄 회원”은 “회원”의 부분집합이 되는 것이죠.

 

그렇다면 어떠한 기준으로 슈퍼타입과 서브타입으로 분리를 해야 할까요? 일단 명확하게 슈퍼타입가 서브타입으로 나눌 수 있는 “남자”와 “여자”를 예로 이야기를 해보겠습니다. 아래 그림의 왼쪽 그림을 보면 남자와 여자가 통합적인 집합으로 사람이 되며, 반대로 사람을 남자와 여자의 부분집합으로 나눌 수 있습니다. 이때 사람을 슈퍼타입이라고 부르며, 남자와 여자를 서브타입이라고 합니다. 전체집합인 사람에서 생각해 볼 때, 어떤 기준으로 남자와 여자를 나눌 수 있을까요? 먼저 우리나라에서는 병역의무, 신체적인 특징, 주민등록 번호등으로 나눌 수 있습니다. 이 기준도 어떤 관점에서 바라보는가에 따라서 슈퍼타입과 서브타입의 성격이 틀려집니다.

 

<그림 4_35.jpg> 일반화와 적용범위

 

먼저 병역의무를 기준으로 본다면 국가에서 강제적으로 시행하는 신체검사를 받고, 면제를 받은 사람을 포함한 병역의무를 가진 사람을 남자로 볼 수 있습니다. 그러나 독자분들 중에는 신체검사를 받지 않은 미성년자들은 어떻게 처리를 해야 할까? 라고 생각할 수도 있습니다. 만약 병역의무를 위한 신체검사가 기준이 된다면 남자와 여자의 적용범위는 위의 그림에서와 같이 사람의 전체집합에서 한부분이 됩니다. 즉, 적용범위는 전체 집합인 사람에서 “신체검사를 받지 않은 사람”을 제외한 부분이 적용범위가 되는 것입니다.

<그림 4_36.jpg> 부분적인 일반화 적용

 

두 번째 기준인 신체적인 특징으로 살펴보겠습니다. 아시디시피 남자와 여자는 신체적인 특징이 확연히 구분됩니다. 신체적인 특징으로 남자와 여자를 구분한다면 트랜스젠더들도 여자로 볼 수 있는 것입니다. 마찬가지로 주민등록번호의 기준도 확실히 구분지을 수 있는 기준이 됩니다. 주민등록번호의 7번째 자리가 1이면 남자, 2이면 여자로 구분될 수 있습니다. 그러므로 트랜스젠더들은 주민등록번호의 기준으로 본다면 남자의 집합에 속하게 되는 것입니다.

 

이처럼 슈퍼타입과 서브타입을 나눌 때는 명확한 범위에서의 명확한 기준이 필요합니다. 서브타입은 명확한 범위와 기준에 의해서 슈퍼타입에 포함됩니다. 이 포함관계는 배타적인가 또는 중첩(Overlap)되는가를 판단해야 합니다. 남자와 여자를 주민등록번호의 기준으로 판단했을 때 남자는 절대 여자가 될 수 없으며(물론 동사무소에서 재신고를 하지 않는다는 가정하에), 여자도 절대 남자가 될 수 없습니다. 이것은 사람이라는 전체 집합에서 남자의 부분집합과 여자의 부분집합이 서로 배타적으로 결합하여 하나의 전체집합을 이루는 것입니다. 즉, 사람은 두개의 서브타입 중 오직 하나의 서브타입에 속해야 함을 뜻합니다. 이 의미는 일부 속성은 다른 부분집합에 적용이 불가능함을 나타내는 것입니다.

 

<그림 4-35>의 오른쪽 그림을 살펴보도록 하겠습니다. 동아리라는 전체집합은 학과내의 동아리를 나타냅니다. 제가 속한 정보통신공학과 내에는 COMBI, INTERFACE, LUG라는 동아리가 존재합니다. 여기서는 관리의 대상이 COMBI와 INTERFACE라고 가정하겠습니다. 또한 COMBI의 회원은 INTERFACE의 회원이 될 수 있고, 그 반대의 경우도 허용됩니다. 그러므로 이 서브타입과 슈퍼타입의 적용범위는 부분적이고, 중첩(Overlap)된 범위를 가집니다. 만약 관리하고자 하는 것이 COMBI, INTERFACE, LUG 모두가 되고, 모든 동아리에 중복 회원이 될 수 있다면 전체적이고, 중첩된 범위를 가집니다.

 

공부를 하거나 일상 생활을 보나 분류하는 것을 많이 볼 수 있습니다. 일반화는 어떤 특별한 기준에 의한 분류를 말합니다. 우리는 3장에서 이미 “데이터 모델링의 원칙: 추상화” 단원에서 일반화에 대한 개념을 살펴보았습니다. 데이터베이스의 정의에서 “관리하고자 하는 것”이라는 부분이 있었습니다. 일반화는 우리가 관리하고자 하는 것이 특정한 기준에 의해서 분리해서 관리하고자 할 때 사용합니다. 이미 3장의 [5.3 단일식별자, 복합식별자] 단원에서 살펴본 증명서에 대한 것입니다. 5.3에 나타난 예를 개념적 ERD로 표현하면 다음과 같습니다.

 

<Table_P>

 이름                          

 ------------------------

 SEQ           --> 제어번호                  

 STUDENT_CD  --> 학번                  

 NM            --> 성명                  

 ID_NUM        --> 주민번호                  

 SCHOOL_NM   --> 학교명                   

 DEPT_NM      --> 학과명                  

 ENT_YEAR     --> 입학년도                  

 GDT_YEAR     --> 졸업년도                  

 GDTCTF_NUM  --> 졸업증서번호                  

 GDT_SEQ      --> 횟수                  

 

<Table_A>

 

 이름                          

 ------------------------

 SEQ         --> 제어번호                  

 IMAGE       --> 학적부                  

 

<Table_B>

 

 이름                          

 ------------------------

 SEQ         --> 제어번호                  

 IMAGE       --> 성적증명서

<그림 4_31.bmp>

 

이 슈퍼타입과 서브타입의 관계는 물리적인 요소까지 고려한 것입니다. 이미지들은 다중값 속성에 해당됩니다. 설계속성으로 “이미지 구분”을 넣어서 하나의 테이블로 표현할 수도 있습니다. 이때 주 식별자는 “제어번호 + 이미지 구분”이 되겠지요. 그러나 하나의 테이블의 로우(Row, 행)이 2배로 늘어납니다. 그렇기 때문에 성능상의 이유로 슈퍼타입과 서브타입의 관계를 맺어 주었습니다. 물론 “이미지 구분”에 따라서 이미지가 결정되므로 이미지는 “이미지 구분”에 종속적입니다. 그러므로 나중에 언급될 2차 정규화에 거리게 되어 분리되고, 분리된 엔티티 집합은 “자식” 엔티티 집합이 되는 것입니다. 물론 엔티티 집합이 분리되어도 “자식” 엔티티 집합은 “부모” 엔티티 집합보다 2배의 데이터 양이 됩니다. 그러므로 슈퍼타입과 서브타입의 관계로 두는게 좋습니다.

 

물리적 ERD로의 표현은 다음과 같습니다.

 

<그림 4_32.bmp>

 

그렇다면 일반화 말고는 다른 방법이 없을까요? 물론 있습니다. 일반화 관계에 있는 Table_A와 Table_B를 합치고, 여기기 “증명서구분”이라는 설계속성을 추가하는 방법입니다.

 

3장에서는 Table_P에서 하나의 테이블로 하는 설명을 했었습니다. 그러나 다른 관점에 볼 때 “Image”라는 속성은 2개로 한정된 다중값 속성에 해당하기도 하고, 만약 성적증명서, 학적부를 따로 관리한다면 증명서는 두개로 나누어 지는 일반화 관계에 있기도 합니다. 이것은 설계자의 관점에 따라서 틀린 것입니다.

 

3장의 5.3은 아주 옛날에 학교를 다녔던 즉, 데이터가 거의 삽입되거나 갱신되는 일이 없다는 현실에서 설계한 것입니다. 만약 증명서 관리를 하는데, 이렇한 현실이 아니라 전체 학생을 대상으로 한다면 어떻게 해야 할까요?

 

일단 학생에 대해서 “재학생”, “휴학생”, “졸업생” 으로 나누어서 관리를 해야 할까요? 아니면 “졸업증명서”, “재학증명서”, “성정증명서” 등의 증명서 별로 관리를 해야 할까요? 상향식의 관점에서 살펴볼 때 “재학생”, “휴학생”, “졸업생”의 각각의 엔티티 집합이 모여서 하나의 “학생”이라는 공통의 집합이 될 수 도 있습니다. 이렇게 데이터베이스 설계는 종합적이고도 객관적인 판단을 요하는 것입니다.

 

학술적인 면에서 살펴볼 때 서브타입과 슈퍼타입은 일반화와 세분화로 나눌 수 있습니다. 위에서는 상향식의 관점이건 하향식의 관점이건 모두 일반화라고 칭했었습니다. 그러나 아래의 그림과 같이 여러 개의 서브타입 들이 모여서 하나의 “학생”이라는 통합적인 개념을 이룰 때 “일반화”라고 하며, 이 반대의 경우를 “세분화”라고 합니다.

<그림 4_33.jpg> 일반화와 세분화

 

일반적으로 데이터 모델링을 할 때 일반화와 세분화를 구분 짓지는 않습니다. 다만 위의 그림처럼 화살표로써 일반화와 세분화를 구분지어 주기도 합니다. 그러나 일반화와 세분화 과정을 거칠 때는 그만한 이유가 있을 때입니다. 만약 학생이라는 엔티티 집합을 도출했다고 하면, 위의 그림과 같이 졸업생, 재학생, 휴학생 나누어서 관리할 필요성이 충분하다면 이 과정은 세분화 과정이 됩니다. 여기서 관리할 필요성이란 다음 그림과 같이 졸업생이 다른 엔티티 집합과 관계를 맺고 있을 때 세분화 과정이 필요하게 되는 것입니다. 물론 자료의 양이 많아서 분리하여 관리할 수도 있습니다.

<그림 4_37.jpg>

 

그림에서 학생이라는 세분화되어 서브타입 중 오직 “졸업생”만이 직장이라는 엔티티 집합과 관계를 맺고 있습니다. 즉, 재학생, 휴학생 서브타입은 “직장” 엔티티와는 전혀 관련이 없기 때문에 세분화 과정을 거친 것입니다. 직장이라는 엔티티 집합은 “졸업생”에게만 종속된 엔티티(경우에 따라서 속성이 될 수도 있습니다.) 입니다. 이것은 약 엔티티 집합으로 볼 수 있습니다.

 

그렇다면 세분화의 반대의 경우(상향식의 슈퍼타입과 서브타입 관계) 즉, 일반화는 어떤 경우에 하는 것일까요? 일단 기본적으로 여러 개의 엔티티 집합이 하나의 개념(클래스)로 추상화 될 수 있을 때 일반화가 가능합니다. 여기서 여러 개의 서브타입들은 서로 성질이 틀리지만 하나의 엔티티 집합에 포함되는 경우를 말합니다. 앞서서 언급했던 남자와 여자의 경우도 추상화 레벨을 좀더 높여보면 사람이라는 하나의 엔티티 집합으로 표현할 수 있습니다.

 

이렇게 상향식의 슈퍼타입과 서브타입은 “일반화 계층(Generalization Hierarchy)라고도 하며, 이러한 관계를 “IS-A” 관계라고 합니다. “IS-A” 관계는 엔티티들이 동일한 사물의 서로 다른 하나의 측면 또는 관점을 나타내기 때문에 동일한 식별자를 갖습니다. 또한 일반화 관계는  상속(Inheritance)라는  특수한 성질을 갖습니다. 즉, 슈퍼타입의 성질이 서브타입의 성질로 그대로 적용이 된다는 뜻입니다. (여기서 말하는 성질은 엔티티의 속성을 의미) 물론 세분화와 일반화는 동일한 표현이기 때문에 표현이라든지 제약조건이 모두 동일합니다. 다만 설계상의 이유로 또는 현실에 존재하는 이유로 나누어지고 통합화되는 과정일 뿐입니다.

 

슈퍼타입에서 서브타입으로 나누어 질 때 또는 통합될 때 앞서서 언급한 것처럼 배타적인 것과 중첩되는 것이 있습니다. 이것을 어떻게 표현해야 이러한 현실이 ERD에 표현할 수 있을 까요? 두 가지 방법이 있습니다. 첫 번째로 배타적인 것은 설계속성에서 “~구분” 이라는 설계속성을 두는 방법이고, 두 번째는 사용자로 하여금 결정하도록 합니다.

 

먼저 설계속성 “~구분”이라는 것을 두어서 확실한 멤버쉽(Membership)을 가지도록 하는 것입니다. 다음의 그림을 보면 “직원구분”이라는 설계속성을 두어서 어느 서브 타입에 속하는지 정확하게 정의하는 경우입니다.

 

<그림 4_38.jpg>

 

즉, 직원을 관리하는데 “직원구분 = 임시직원” 인 직원은 임시직원이고, “직원구분 = 정직원”인 직원은 정직원이 되는 것입니다. 즉, 조건을 만족하면 해당 서브타입에 속하는 것이 됩니다. 물론 위의 그림처럼의 현실이라면 “직원구분”이 가질 수 있는 값은 두 가지가 되는 것입니다. 그러므로 미리 개발팀들과 정하여 “직원구분 = 1” 이면 임시직원이고 “직원구분 =0” 이면 정직원을 나타내는 수도 있습니다. 이러한 방법은 자칫 개발자간의 의사소통이 안돼어서 문제를 일으킬 수 있으니 확실하게 팀간의 의사소통을 이룬 뒤 개발이 되어야 할 것입니다.

 

두번째 방법은 어떤 엔티티가 어떤 서브타입에 속해야 되는가를 사용자가 알아야 한다는 것입니다. 즉, 조건을 주기 위한 속성을 추가하지 않고 사용자가 자신이 어느 서브타입에 속해야 하는가를 결정하는 것입니다. 이 방법 역시 중첩과 배타성을 모두 표현 할 수 있습니다. 그러나 데이터베이스 관리 시스템에서 중첩과 배타성을 고려해 주어야 합니다. 만약 이러한 사항을 고려치 않는다면 데이터베이스의 무결성이 깨지는 것입니다. 이러한 중첩과 배타성에 대한 것은 물리적 설계단계에서 할 “트리거”라고 하는 것을 이용해야 합니다. 트리거는 한 작업이 일어났을 때 연쇄적으로 일어나는 작업이라고 할 수 있습니다. 일단은 트리거란 것이 이런 의미를 가지고 있다고 생각하시고 트리거에 대한 자세한 사항은 나중에 언급하도록 하겠습니다.

 

세분화이든 일반화이든 슈퍼타입과 서브타입의 관계는 현실의 동일한 사물의 서로 다른 측면을 나타내는 관계이기때문에 슈퍼타입과 서브타입의 주식별자는 같아야 합니다. 슈퍼타입은 서브타입의 공통된 속성을 모두 가지고 통합된 관점에서의 엔티티 집합입니다. 즉, 슈퍼타입에 존재하는 엔티티는 서브타입에도 존재해야 하는 것입니다. 반대로 생각하면 슈퍼타입에 존재하지 않으면 서브타입에도 존재하지 않아야 한다는 뜻도 됩니다. 그러므로 슈퍼타입의 한 엔티티(개체 = 인스턴스 = 어커런스)가 삭제되거나 변경, 입력된다면 당연히 서브타입도 삭베되거나 변경되고 자기기 속해야 하는 서브타입에 입력이 되어야 한다는 것입니다.

 

앞서서 우리는 중첩(Overlap)과 배타적이라는 용어를 사용했었습니다. 이것은 설계속성과 관련된 이야기 입니다. 만약 배타적이라면 위의 그림에서와 같이 하나의 서브타입에 속해야만 할 때 단일값의 조건을 부여 했었습니다. 단일값의 조건이란 “직원구분=정직원” 같은 조건을 말합니다. 그렇다면 중첩일 때는 어떤 처리방법을 가져야 할까요? 중첩의 의미는 다른 서브타입에도 중복되어 존재하는 것을 의미합니다. 즉, “직원구분 = 정직원 or 직원구분 = 임시직원”이 될 수 있다는 것입니다. 물론 이렇게 슈퍼타입에 설계속성을 두지 않는 방법이 사용될 수 있습니다. 그러나 추가적인 무결성 제약을 만들어 주어야 하므로 대부분의 경우는 설계속성을 슈퍼타입에 추가해 주는 것이 바람직한 방법이라고 할 수 있습니다.

 

세분화는 또한 계층을 이룰 수 있습니다. 즉, 하나의 슈퍼타입과 서브타입의 관계에서 또다른 서브타입과 슈퍼타입의 관계가 존재할 수 있다는 것입니다. 즉, 3장에서 살펴보았던 관점에 따른 추상화 레벨의 차이 그림에서와 같이 여러 계층이 존재할 수 있다는 것입니다. 

 

<쉬어가기>

 

CASE 툴의 이용에 관하여

필자가 CASE 툴이라는 것 있다는 것을 알게 된 것은 아주 초보 시절이 였습니다. 그래서 툴이 어떤 것이 있나 웹을 방황하면서 결국을 파워디자이너, ER-WIN등이 있다는 것을 알았습니다. 매뉴얼을 보고 그 툴의 사용법을 익혔지만 얼마 가지 못해 잊어버리기 일쑤였습니다. 왜 그랬을까요? 물론 제가 머리가 좀 나쁜 것도 있었지만, 지금 와서 생각해보면 아무것도 모르는 상태에서 툴의 사용법을 익히니 자꾸 잊어버릴 수 밖에요. 결국 “낫은 벼를 베는데 쓰는 거다” 라는 사용법만 알고, 벼를 베지 않을 때는 낫을 쓰지 않는 격이 된 것입니다. 우리는 USE를 하는 것이 아니라 MAKE를 해야 합니다. 즉, 벼를 베기 위해서 낫을 개발해야 하는 것이죠. 툴을 사용하는 목적은 단지 빠르게 편리하게 정보시스템을 구축하기 위함입니다. 툴이 없어도 정보시스템을 구축이 가능합니다. 그러니 툴 자체의 사용법을 익히는 공부는 하지 말아야 겠지요.

 

모델링 툴을 이용하는 것은 데이터베이스에 대한 기본지식이 있어야 합니다. 왜냐하면 이러한 툴들은 데이터베이스의 이론을 바탕으로 만든 것이기 때문입니다. 필자는 웬만하면 초보시절에는 조금 어렵더라도 툴의 이용을 자제하는 것이 좋다고 생각합니다. 이론을 꿰어 차고 있다면 어떤 툴이건 표현방법의 차이만 날 뿐이지 익히는 것은 너무나도 쉽습니다.

 

</쉬어가기>

 

5.  M:N관계의 해소

 

데이터 모델링을 하다 보면 M:N 관계가 자주 등장합니다. 제가 처음에 “M:N 관계를 새로운 엔티티 집합 및 2개의 1:N 관계로 분리하라” 라는 말을 접했을 때는 무조건 그렇게 했었습니다. 설계의 단순화를 위해서 또는 현재에 존재하는 DBMS가 M:N관계를 허용하지 않기 때문에 2개의 1:N 관계로 분리한다고 했습니다. 여러분은 이것이 이해를 할 수 있습니까? 보다 근본적인 이유가 설명되어야 하겠지요. 저같이 머리 나쁜놈은 절대 여기서 멈출 수 없습니다. 왜? 단순화와 왜? DBMS가 M:N 관계를 허용하지 않는다는 것일까요? 다음 그림을 살펴봅시다. (필자는 이거 하나씩 연결하느라고 상당히 힘들었습니다. ^^;)

<그림 4_39.jpg>

 

이 관계는 “ 한명의 교수(왼쪽)가 여러 명의 학생(오른쪽)을 지도한다”, “한명의 학생은 여러 교수에게 지도 받는다” 라는 M:N의 관계를 나타내는 것입니다. 그림은 제가 한명의 교수가 지도할 수 있는 경우의 수와 한명의 학생마다 지도 받을 수 있는 경우의 수를 모두 합한 것입니다. 즉, 카테시안 곱이 되는 것입니다. 여기서 카테시안 곱이란 양쪽 엔티티들 같에 일어날 수 있는 관계의 모든 경우의 수의 집합을 이야기 합니다. 관계형 데이터 모델에서는 엔티티 집합을 릴레이션(Relation)이라고 부른다고 했습니다. 이러한 릴레이션을 수학자들은 도메인들의 카테시안 곱의 부분집합으로 정의하고 있습니다. 즉, 카테시안 곱이 수학적으로 따져본다면 두 관계의 전체집합이 되는 것입니다.

 

사실 카테시안 곱의 무서움을 느끼려면 DBMS를 다뤄봐야 합니다. 제가 4장을 시작할 때 오라클 DBMS를 셋업하라고 했습니다. SQL을 모르시더라도 한번 느껴보도록 하겠습니다.

 

<박스>

오라클의 SQL*Plus를 띄우시고 scott 사용자로 tiger라는 패스워드를 넣고 접속합니다.

다음의 코드를 입력합니다.

 

SQL> create table a (id number(10));   -- a라는 이름을 가진 테이블 생성

 

테이블이 생성되었습니다.

 

SQL> create table b (id number(10));   -- b라는 이름을 가진 테이블 생성

 

테이블이 생성되었습니다.

 

SQL> set timing on

 

SQL> declare

  2     i number(10) := 0;

  3  begin

  4     for i in 1..1000 loop  -- 필자는 여기에 100000 이라고 했다가 상당히 짜증스러웠습니다.

  5         insert into a values(i);

  6     end loop;

  7  end;

  8  /

 

PL/SQL 처리가 정상적으로 완료되었습니다.

 

경   과: 00:00:00.01

SQL> declare

  2     i number(10) := 0;

  3  begin

  4     for i in 1..1000 loop

  5         insert into b values(i);

  6     end loop;

  7  end;

  8  /

 

PL/SQL 처리가 정상적으로 완료되었습니다.

 

경   과: 00:00:00.01

 

SQL> set pagesize 1000

SQL> select a.id, b.id

2      from a, b;

.

.

.

.

 

996       1000

997       1000

998       1000

999       1000

1000       1000

 

1000000 개의 행이 선택되었습니다.

 

경   과: 00:16:18.03

SQL>

 

</박스>

 

제 컴퓨터가 AMD 1.33 GHz에 RAM이 1Gbyte입니다. 이것을 처리하는데 무려 16분의 시간이 걸렸습니다. 백만분의 1초 또는 천만분의 1초 단위로 행해지는게 컴퓨터의 세계인데 현실에서 16분이라면 기다리기도 지루합니다. 필자는 지금 각 테이블에 100000 개의 행을 삽입하고, 카테시안 곱을 실행했었습니다. 기다려도 답이 안 나오길래 중지하고 다시 1000개의 행만 삽입했습니다. 카테시안 곱의 무서움을 실감하셨는지요? 다:다의 관계는 이렇게 무섭습니다.

 

이 책은 현실을 엔티티와 엔티티들간의 관계로 정의하는 패러다임을 가지고 있습니다. 즉, 정보는 한 개의 엔티티 집합에서만 나오는 것이 아니라 엔티티 간의 관계에 의해서도 정보를 산출한다는 것입니다. 현실에는 다:다의 관계가 존재하고, 실제로 시스템을 구현하는 단계에서는 다:다의 관계를 해소시켜야 합니다.

 

<참고>

카테시안 곱은 1:다의 관계에서도 할 수 있습니다. 여기서는 다:다의 관계를 설명하기 위한 예로 보면 되겠습니다. 다:다 관계를 해결하기 위한 구체적인 이유는 바로 아래에서 설명합니다.

</참고>

 

앞의 교수와 학생의 관계에서 “교수가 지도하는 학생은 누구인가?” 라는 정보를 만들기 위해서는 카테시안 곱이 필요합니다.  이것은 주식별자들 사이에 다:다의 연결이 존재하고 있는 경우, 어느 한 쪽의 주식별자만으로는 식별될 수 없기 때문에 카테시안 곱을 선택할 수 밖에 없던 것입니다. 꼭 각각의 교수가 모든 학생을 지도하지 않아도 된다는 가정이 있는 경우는 더욱 분명히 비효율적이라는 것을 알 수 있습니다.

 

그러면 이러한 문제점을 가지고 있는 다:다의 관계를 어떻게 해소하면 될까요? 문제점은 한쪽의 주식별자만으로 식별될 수 없는 것입니다. 그렇다면 두 엔티티 타입의 주식별자를 합친 것을 식별자로 가지면 주식별자의 역할을 할 수 있으므로 다:다의 관계는 해결되는 것입니다. 즉, 다음 그림과 같이 해소 시켜 줍니다.

<그림 4_40.jpg>

 

파워디자이너를 이용해서 표시해보겠습니다. 아래 그림의 위쪽은 개념적 모델링을 한 것이고 이것을 [Tool] à [Generate Physical Data Model...]을 눌러 오라클9i 를 기준으로 물리적 모델로 변환한 것입니다. 파워디자이너는 자동화도구이기 때문에 자동으로 다:다 관계를 해결하는 것이 보입니다.

<그림 4_41.bmp>

 

이것을 개념적 모델에서 해결하려면 다음과 같이 수행합니다. (이제까지 사용법을 익히셨으니 개념을 익히도록 하겠습니다.) 일단 아래 그림에서 “부서_사원”은 연관(Association) 엔티티 집합입니다. 두개의 엔티티 집합사이에 연관되어 있다는 의미를 가집니다. 거의 연관 엔티티 집합은 다:다 관계의 해결을 위해 많이 사용됩니다.

 

아래의 그림에서 Association Link를 클릭하고 관계를 연결해주듯이 연관된 엔티티 집합에 연결해도 아래의 결과와 같습니다.

 

<그림 4_42.bmp>

 

이것은 다:다 관계를 해결하는 기본적인 방법입니다. 다른 방법은 주식별자를 통합하거나, 업무규칙상 제한된 다:다(정확히 말하면 다: 3 또는 다: 2등으로 확실한 카디날리티가 결정된 경우)의 관계는 카디날리티가 결정된 속성을 결정되지 않은 다측에 외부식별자로 넣어주는 방법이 있습니다. 그러나 이러한 경우는 특정한 경우이고, 기본인 다:다의 해결방법을 사용하는 것이 일반적으로 좋습니다.

 

만약 다음과 같이 사원과 관리자(직원의 상사)간의 순환관계로 다:다의 관계를 맺고 있다면

물리적(논리적)으로 어떻게 구현이 될까요?

<그림 4_44_bmp>

 

물리적 데이터 모델로 변환해 보겠습니다.

<그림 4_45.bmp>

 

위의 그림에서 사원_사원번호를 “관리자”로 바꾸어 주고, “관리하다” 라는 엔티티 집합의 이름을 “상사_직원” 으로 고쳐줍니다.

<그림 4_47.bmp>

 

이제 그림이 그럴싸 했졌습니다.

 

<참고>

 

파워디자이너 9.0에서 개념적 데이터 모델과 물리적 데이터 모델의 용어 Mapping

 

Entity set   à Table

Attributes   à Columns

Identifiers   à Keys( 주식별자 à Primary Key, 외부식별자 à Foreign Key)

<그림 4_46.bmp>

</참고>

 

6.  1:1 관계의 고려

 

1:1의 관계를 가진다는 것은 하나의 개체(Entity)에 다른 유형의 하나의 개체에 대응된다는 소리이다. 예를 들어, 한 회사에서 한명의 사원에 한나의 IP가 할당된다고 하면, 다음과 같은 ERD를 가질 수 있습니다.

 

<그림 4_43.jpg>

 

이런 경우는 외부식별자를 어느 쪽에 두어도 상관없음을 의미합니다. 다만 한쪽 방향으로 질의가 훨씬 더 많이 일어난다면 둘 중에 어느쪽에 외부식별자가 포함될 때 성능이 우수하다는 것이 있을 수 있다. 이럴 때는 당연히 성능이 우수한 방향으로 외부식별자를 두는 것이 좋을 것입니다. 또한 아무래도 주식별자로 검색하는 것이 일반적으로 외부식별자로 검색하는 것보다 빠를 수 있습니다. 물론 위의 경우는 컴퓨터를 사용하는 사원에 한에서를 가정한 경우이므로 IP를 할당 받는 사원은 모두가 아니라 일부입니다.

 

위의 경우에서 보듯이 1:1의 관계이어도 동일 주식별자를 같는 엔티티 집합이 되는 것이 아닙니다. 그러나 양쪽의 최대, 최소 카디날리티가 min(1,1), max(1,1)이라면 동일한 개체를 두개의 개체로 나누어 생각한 것이 아닌가를 의심해야 할 것입니다. 물론 설계상의 이유로 적게 쓰이는 데이터의 그룹과 많이 쓰이는 데이터의 그룹의 나눌 수도 있습니다. 당연히 분리하는 것이 성능상의 이유로는 정당화 될 수 있습니다. 그러나 이런 이유가 없이 “사원”과 “직원”이라는 엔티티 집합으로 나눌 필요는 없는 것입니다.

 

만약 한 회사 안에 도서관이 있는데, 그 도서관을 이용할 수 있는 사람은 그 회사의 사원들 입니다. 그런데 “사원”이라는 엔티티 집합이 존재하고 “대출자”라는 엔티티 집합이 하나의 ERD에 같이 포함되어 있다면 맞는 것일 까요?  (회사 안의 도서관에 대한 ERD만 가지고 하는 이야기가 아닙니다. 회사 전체의 ERD) 당연히 지금 상황으로서는 틀리다고 할 수있습니다. 왜냐하면 도서관에서 책을 대출받는 사람도 그 회사의 사원이며, 대출을 해주는 사람도 그 회사의 사원이기 때문입니다. 즉, 동일한 개체의 또 다른 표현을 한 것입니다. 물론 설계상의 이유로 분리를 할 수도 있지만 현재 상황으로는 잘못된 ERD라고 할 수 있겠지요.

 

또, 같은 개체를 보안상의 이유로 분리할 수도 있습니다. 연봉제를 아시는지요? 제대로된 연봉제라면 자신의 연봉은 다른 사람이 몰라야 합니다. 그러나 데이터베이스는 전체의 조직이 공유하는 것입니다. 그렇기 때문에 다른 사람이 자신의 연봉이 얼마나 되는가를 몰라야 한다면 테이블을 분리하거나 뷰를 통해서 접근하거나 프로시저화하여 접근할 수 없도록 해서 유지를 해야합니다.

 

7.  1:다 관계의 고려

 

일반적인 개체들간의 관계는 1:다의 관계입니다. 보통은 1측을 부모, 다측을 자식이라고 합니다. 그러나 부모와 자식간의 관계는 엔티티 집합이 탄생되고, 탄생의 열쇠를 쥐고 있는 관계를 말합니다. 그러니 꼭 1:다의 관계라고 해서 부모 – 자식간의 관계가 되는 것은 아닙니다. 이러한 관계는 “주식별자 종속 관계”라고도 합니다. 왜냐하면 1측의 주식별자가 다측에 외부식별자로 다측의 엔티티 집합에 속성으로 추가되기 때문입니다.

 

<참고> 개념적 모델과 논리적 모델의 고려

 

이 책에서는 개념적 모델과 논리적 모델의 경계를 크게 두지 않습니다. CASE 툴에서도 마찬가지로 논리적(Logical) 데이터 모델을 지원하지 않는 것이 보입니다.(사실 지원하지 않는 것이 아니라 DBMS가 지향하는 논리적 데이터 모델을 따라 갑니다.) 이것은 논리적 데이터 모델이 특정 DBMS와 관계를 맺고 있기 때문입니다. 옛날에는 논리적 모델로 계층형, 네트워크형, 관계형이 모두 많이 쓰였기 때문에 특정 DBMS에 종속되지 않기 위해서 개념적 데이터 모델과 논리적 데이터 모델을 나누었으나, 요즘에는 관계형 모델이 거의 주류를 이루고 있으므로 개념적 모델에서 보통 관계형을 고려한 데이터 모델을 만들고 있습니다. 실제로도 개념적 설계이후 특정 DBMS를 채택하여 논리적 모델을 따로 작성하는 사례는 별로 없습니다. DeZign for Database 툴은 개념적인 요소와 물리적인 요소가 많이 결합된 형태로 볼 수 있습니다. 독자 여러분은 이에 혼동하지 마시고, 3단계 스키마 구조에서 살펴보았듯이 개념적인 요소와 논리적인 요소, 물리적인 요소의 개념을 잡고 있다면 이는 상관이 없으리라 봅니다. 또한 개념적 모델과 논리적 모델과 물리적 모델에서 쓰이는 용어에 대한 맵핑을 잘 하셔야만 다른 데이터베이스론 책을 보시는 데에 크게 영향 받지 않을 것입니다.

 

</참고>

 

8.  3원 관계의 해소

 

가끔 데이터 모델링을 할 때 3원관계가 나타날 때가 있습니다. 3원 관계가 나타나면 DBMS의 적용에도 문제가 있고, 모델링 자체가 상당히 복잡해 집니다. 다음은 3원 관계성 집합과 그 해소방법을 나타내고 있습니다. 해소 방법은 다:다의 관계 해소법과 아주 비슷합니다.

<그림 4_47.jpg> 박영사, 데이터베이스 관리, 서길수 저

 

납품업자(납품업자번호, 전화)

제품(제품번호, 가격)

창고(창고번호, 위치)

선적(납품업자번호, 제품번호, 창고번호, 수량)

 

위에서 밑줄이 있는 부분은 주식별자를 나타냅니다. 만약 선적에 단순화를 위해서 설계속성을 추가하여 “선적번호”라는 속성을 추가해 준다면 나머지 납품업자번호, 제품번호, 창고번호는 외부식별자가 되겠지요. 3원 관계의 해소는 주의 할 점은 그림처럼 3원 관계를 2원 관계로 전환할 때 정보의 손실이 없어야 한다는 것입니다.

 

그렇다면 파워디자이너에서는 어떻게 처리가 될까요?

<그림 4_48.bmp>

 

물리적 데이터 모델로 변환하면 다음과 같습니다. 지금은 3원 관계 집합이 어떻게 해결되는 것인가를 확인해 보는 것이기 때문에 속성의 도메인이나 데이터 타입은 넣어주지 않았습니다.

 

<그림 4_49.bmp>

 

9.  주 식별자의 선택

 

엔티티 집합을 도출하고 엔티티 집합간의 관계를 도출하면, 일반적으로 주 식별자를 선택해야 합니다. 각각의 엔티티는 자신을 구분할 수 있는 하나의 속성 또는 여러 개의 속성이 모여서 구분할 수 있어야 합니다. 주 식별자의 선택은 반드시 정보시스템을 구축하는 범위 안에서 정보시스템을 사용하는 사용자의 관점이어야 합니다. 예를 들면 학교에는 “학생” 이라는 엔티티 집합이 존재합니다. “학생”을 구분할 수 있는 속성은 학번, 주민등록번호가 될 수 있습니다. 그러면 학번과 주민등록번호 중 어떤 것을 주 식별자로 선택을 해야 할까요? 여기서 고려할 사항은 “어떤 것이 해당 조직에서 더 의미가 있는가?” 입니다. 당연히 학교에서는 학번이 더 의미가 있는 것입니다. (3장에서 이야기 했던 “제어번호”와 “학번” 같은 경우는 특수한 경우이므로 여기서는 일반적으로 모든 학생이 학번이 존재한다는 가정 하에 설명하겠습니다. 또한, 학교 안의 예비군대대 같은 곳에서는 주민등록번호가 더 의미가 있을 수 있으나 이런 것은 생각치 않겠습니다.)

 

앞서서 주 식별자의 선택은 정보시스템을 구축하려는 조직의 범위를 벗어나서는 안됀다고 했습니다. 만약 동사무소 직원의 관점에서 “학번”과 “주민등록번호” 를 두고, 주 식별자를 선택하라면 무엇을 선택할까요? 당연히 “주민등록번호” 이겠지요. “학번”은 동사무소 직원 에게는 전혀 쓸모없는 것이 됩니다. 즉, 속성의 자격조차 안돼는 것입니다.

 

만약 자동차 판매원과 동사무소 직원이 같은 사람을 놓고, 본다면 “주민등록번호”가 주식별자가 될 수 있을까요? 아마도 “고객번호” 라는 것이 주식별자가 될 것입니다.

 

<그림 4_50.jpg>사용자의 관점에 따른 주식별자의 선택

 

위 그림은 단지 주식별자에 대한 의미만을 포함하지 않습니다. 좀더 크게 생각하면 “관점의 차이” 라는 울타리를 의미합니다. 학교직원은 학번이 몇 번이며, 휴학을 몇 번했으며, 수업료를 냈는가, 수강신청을 제대로 했는가 등에 관심을 가지고 있을 테고, 자동차 판매원 같은 경우는 몇 년식의 차량을 보유하고 있으며, 또 다른 자동차 회사의 차량을 보유하고 있는지, 차의 디자인을 중시하는지 실용성을 중시하는지 등에 관심이 있을 것입니다.

 

주 식별자는 꼭 “학번”, “주민등록번호” 처럼 단일 속성이 주식별자가 되지는 않습니다. 다음과 같이 한명의 고객이 여러 개의 전화번호를 가지고 있다면, 주 식별자는 어떤 것이 될까요?

 

<표>

고객번호	전화번호	주소
1234-1234	017-233-8xxx	대전광역시 대덕구...
1234-1234	011-420-2xxx	대전광역시 대덕구...
. . .	. . .	. . .

</표>

 

이런 경우는 “고객번호”가 주 식별자가 될 수 없습니다. 유일하게 구분할 수 있는 것은 “고객번호 + 전화번호”가 되겠지요. 물론 추가적으로 “전화번호” 이외에 다른 속성이 있어서, “고객번호”와 “전화번호” 이외의 속성이 결합하여 주 식별자가 될 수 있으나, 여기서 의미를 두고자 하는 것은 “고객별 전화번호” 입니다.

 

이렇게 주 식별자를 구분하는 이유는 의미와 대표성입니다. 다시 말해서 하나의 엔티티 집합은 엔티티 들이 어떤 하나의 주제에 묶여 있기 때문에 엔티티가 존재할 수 있는 의미를 부여하고, 각각의 엔티티를 구분하기 위해 주 식별자를 선정하는 것입니다.

 

 

10. 다중 값 속성에 대한 고려

 

3장에서 우리는 다중값 속성에 대해서 살펴 보았습니다. 3장에서는 업무 형태에 따라서 슈퍼타입과 서브타입으로 나누어야 할 수도 있고, 다중값 속성을 해당 엔티티 집합에 종속적인 새로운 엔티티 집합으로 만들어서 다중값 속성에 대한 해결을 했었습니다. 만약 다중값 속성이기는 한데 속성의 값이 몇 개의 값으로 고정적이라면, 슈퍼타입과 서브타입의 관계가 되는가를 살펴보아야 합니다. 만약 다중값 속성을 전체 집합으로 해서 어느 한 부분집합이   다른 엔티티에 영향을 준다면 이것은 슈퍼타입과 서브타입으로 나누는 즉, 세분화 과정을 가져야 합니다. 어떻게 보면 슈퍼타입과 서브타입의 관계가 다중값 속성처럼 보이기도 합니다. 그러나 다중값 속성은 하나의 다중값 속성을 가지는 엔티티 집합에서 떨어져 나와 그 하나의 또 다른 엔티티 집합이 되고, 자신의 탄생되게 한 즉, 부모 엔티티 집합에만 종속적인 것입니다. 즉, “사원” 엔티티 집합을 전체 집합으로 봤을 때 “특기”란 것은 하나의 부분집합이 되는 것입니다. 파워디자이너를 이용해서 다중값 속성에 대한 모델링을 할 때는 다음과 같이 노트를 해주어야 합니다. 그래야 나중에 헤깔리지 않으니까요.

 

<그림 4_51.bmp>

 

만약 다중 값 속성의 해결과 세분화 과정에 혼돈을 느끼신다면 필자는 다음의 기준을 제시합니다. 다중 값을 가지는 속성값이 고정적일 때는 세분화가 될 수 있다는 것입니다. 이 부분은 혼돈의 여지가 있을 수 있습니다. 그러나 한가지 구분 지을 수 있는 것은 설계속성으로 “~~구분” 이라는 것이 들어가야 엔티티가 성립될 수 있다면, 그것은 다중값 속성으로 고려를 하는 것이 아니라 세분화의 고려를 해야 한다는 것입니다.  

 

<참고>

 

잠시 목차를 보세요...

 

이제까지 필자가 주로 이야기 한 것은 무엇에 관한 것일까요? 물론 데이터베이스에 관한 얘기입니다. 그러나 조금 더 깊이 살펴본다면 엔티티, 관계, 속성에 관한 이야기가 거의 전부입니다. 이렇게 ERD를 그리고, 여러 가지 고려를 하는 것은 모두 데이터베이스의 정의에 어긋나지 않는 데이터베이스를 설계하고 구축하기 위한 것입니다. 이제까지 필자가 얘기한 것을 데이터베이스의 정의에 어긋나지는 않는지 여러 사람과 토론을 해보시는 것도 좋겠습니다. 데이터베이스는 정답이 없습니다. 즉, 어떤 범위(조직) 내에서만 통용되는 개념이 있다는 것입니다. 환경적인 요인이 적절한 데이터베이스 설계를 만든다는 소리입니다.

 

</참고>

 

11.  복합속성에 대한 고려

 

복합속성은 하나의 속성이 다시 여러 개의 의미 있는 속성으로 쪼개질 수 있는 속성을 말합니다. 예를 들면, “주소”와 같은 속성은 시, 도, 군 등으로 나뉘어 질 수 있습니다. 복합속성은 사용자의 경우에 따라 어떤 경우는 전체의 속성을 참조하고, 어떤 경우는 일부만 참조하는 경우 사용하는 것이 좋습니다. 어떤 기업에서 만약 여러 지역별로 지점이 있는데, 사원의 주소에 따라서 지역별 지점에 사원을 배정한다면, 주소를 시, 군, 동 등으로 나누어서 사용해야 합니다. 동사무소 같은 경우는 주소의 시, 군, 동 등으로 나누어야 겠지요. 다음은 “각각의 사원은 반드시 하나 이상의 주소를 가지고 있다.” 와 “ 각각의 주소는 반드시 한명의 사원에 종속된다” 라는 관계를 가지고 있는 예입니다.

 

<그림 4_52.bmp>

 

물리적 데이터 모델로 변환하면 다음과 같습니다.

<그림 4_53.bmp>

 

이런 설계가 맞는 것일까요? 가만히 속성들을 들여다 보시기 바랍니다. 사원번호에 의해서 이름과 시도, 구, 동, 번지가 결정되는 것이 보일 것입니다. 만약 그림에서 보다시피 사원번호는 주식별자이며, 주 식별자는 엔티티 집합에서 엔티티를 유일하게 구분할 수 있는 기능을 하는 속성입니다. 이렇게 특정의 속성에 다른 속성들이 종속되는 것을 ‘데이터 종속성’ 이라고 합니다. ‘데이터 종속성’ 에 대한 이야기는 ‘정규화’ 에서 다시 자세히 언급하겠습니다. 이럴 경우는 다음과 같이 설계하는 것이 적당하겠지요. 복합속성이 계층적인 구조를 가진다는 의미를 일반화나 부모 엔티티 집합의 자식 엔티티 집합으로 표현하는 것과 혼동하지 마시길 바랍니다.

 

<그림 4_54.BMP>

 

여기서 독자분들은 “주소” 테이블이 시도, 구, 동, 번지로 나뉘었는데 나뉜 속성을 각각 사용하는 것을 문제가 안돼겠지요. 포인트는 어떻게 이것들을 합쳐서 사용할 것인가를 생각해야 합니다. 만약  SQL을 조금 다뤄보신 분이라면 그런 걱정은 없을 테지요. SQL에 대한 것은 9장에서 다룰 것입니다. 참고할 부분은 문자열을 연산하는 부분입니다. 그러나 SQL을 다룰 줄 알고 데이터베이스를 설계하는 거와 SQL을 모르고 설계하는 것과는 많은 차이가 있으므로 필자는 SQL부분을 공부하고 다시 이 부분을 보는 것을 권합니다. 

 

12. 설계속성과 유도속성의 고려

 

설계속성은 시스템 구현상 필요하다고 생각하여 설계자에 의해 임의로 들어간 속성을 이야기 합니다. 설계속성은 원래 업무에는 존재하지 않는 것을 말합니다. 엑세스를 다뤄 보셨는지요? 엑세스에 보면 테이블을 만들고 나서 기본키 지정을 하지 않으면 ‘팅~’ 하는 소리와 함께 기본키를 주지 않았다고 만들것이냐고 묻습니다. 이 물음에 예라고 엑세스에게 전달해주면 엑세스는 기본키(물리적으로는주 식별자)로 하나의 일련번호를 만듭니다. 이러한 경우는 데이터베이스 상에 많이 나타납니다. ‘학번’, ‘주민등록번호’ , ‘사원번호’ 등과 같이 “~~번호”라고 들어간 것이 없으면 주식별자가 없는 줄 알고 설계자가 임의로 ID라는 속성을 추가하여 일련번호를 부여하는 경우가 자주 있습니다. 이것은 불필요한 데이터를 집어 넣는 일이 될 수 있습니다. 앞서서 언급했듯이 주식별자는 각각의 엔티티를 대표할 수 있는 의미를 가지고 있어야 합니다. 만약 여려 개의 속성이 합쳐져서 프로그램상의 구현이 복잡해 진다면 설계속성으로 일련번호등과 같은 설계속성을 추가합니다. 설계속성은 데이터의 저장공간을 차지하고, 자칫 잘못하면 엔티티 집합의 의미와는 전혀 상관없는 방향으로 흘러 갈 수 있으므로 조심해야 합니다.

 

또한, “~~구분”이라는 것이 많이 들어간 설계도 볼 수 있습니다. “~~구분”이 많이 들어간 데이터베이스는 무언가가 부족하다는 뜻이 됩니다. 뭐가 그리 구분할 것이 많은지 모르겠습니다. 이렇게 “~~구분”이라는 것이 많이 들어간다는 것은 어플리케이션에서 IF ~ ELSE 등의 조건절에서 사용하기 위한 용도로 사용되는 즉, 절차적인 요소가 데이터 모델링에 많이 들어갔다는 것입니다. 이것은 설계 초반에 복잡성에 빠져서 미리 어플리케이션에서 처리할 사항까지 집어 넣은 결과라고 볼 수 있습니다. 물론 이런 경우는 단지 하나의 단면을 이야기 한 것이고, 꼭 필요에 의해서 만든 것일 수도 있는 것이지요. 그러나 모델러가 진짜 그렇게 생각을 하고 데이터 모델링에 임했었는지는 다시 돌아봐야 할 것입니다.

 

데이터베이스는 답이 없으니 어떤 책이든지 정답이라고는 할 수 없는 노릇입니다. 심지어 기사 시험에서 조차 이러한 사항들을 생각해 보면 4지선다형의 시험에서 몇 가지 답이 나올 수가 있습니다. (필자는 그래서 기사시험을 안 본답니다.  --;;;)

 

얼마 전 필자가 웹을 통해서 어떤 분의 데이터베이스를 봐준 적이 있습니다. 그런데 하나의 테이블에 떨렁 주식별자와 “합계” 라는 속성 밖에 없는 테이블이 보이더군요. 그래서 이 합계는 머냐? 라고 물어봤더니 “구현이 어려워서 그냥 저렇게 해놓았다” 라고 하더군요. 그럼 합계가 유도되는 속성에서 값이 바뀌면 어떻게 하냐? 라고 물어 보았더니 특별한 조치를 취하지 않았다고 하더군요. 여러분은 어떻게 생각하십니까?

 

유도속성은 이렇게 다른 속성에 의해 영향을 절대적으로 받기 때문에 “정합성”을 유지해야 합니다. 유도속성은 다른 속성에 의해서 계산되어지거나 유도된 속성을 말합니다. 예를 들면, 합계, 또는 부가세포함가 등 입니다. “정합성”은 유도된 속성이 원래의 속성값이 변함에 따라서 같이 변해야 하는 것입니다. 만일 컴퓨터 가격이 100만원 이였다면 부가세포함가는 100만원의 10%를 더한 110만원입니다. 만약 컴퓨터의 가격이 200만원으로 오른다면 특별한 조치를 취하지 않은 경우 유도된 속성은 그대로 110만원을 유지하고 있을 것입니다. 이것은 데이터의 무결성이 깨지는 아주 위험한 것입니다. 즉, 유도속성은 시간 축상에서 변하기 때문에 관리가 필요합니다. 거의 대부분 이렇게 계산에 의한 유도속성은 현재의 날짜(경우에 따라서 시간 포함)로 관리하는 것이 편합니다. 또한 부가세포함가 자체도 다른 속성에 의해 영향을 받는 속성이므로 변경해서는 안돼는 속성입니다. 즉, 읽기 전용이라야 하는 것입니다.

<그림 4_55.jpg>

 

유도 속성은 업무상의 중요한 의미를 가질 때 고려되어야 합니다. 개념적 데이터 모델의 설계 목적은 불필요하거나 중복되는 요소가 없는 최소한의 데이터 모델을 개발하는 것인데, 유도 속성은 불필요한 중복으로 인한 복잡성을 야기할 수도 있으므로 유도 속성을 추가할 때는 많은 고려를 해야 합니다. 어떤 측면에서 보면 유도 속성도 하나의 설계속성으로 볼 수도 있고, 중복속성이라는 측면에서 볼 때는 간접적인 데이터의 중복 저장으로 볼 수 있습니다. 여러분이 유도 속성을 추가할 때는 영향을 받는 내용 즉, 공식 등을 반드시 문서화를 시켜야 합니다.

 

13. 도메인 관리

 

도메인은 속성이 가져야 할 영역을 말합니다. 도메인 역시 정보시스템을 구축하고자 하는 조직은 범위 내에서 통용되는 범위를 갖습니다. 어떤 기업에서는 고객번호가 8자리로 관리될 수가 있고, 또 다른 기업에서는 고객번호가 12자리로 관리될 수 있습니다. 이러한 도메인 관리는 체계적으로 이루어져야 하며, 우리가 다루는 Power Designer에는 이러한 도메인 관리를 비교적 체계적으로 할 수 있게 구성되어 있습니다. 보통은 도메인 관리에 대해서 소홀할 수가 있습니다. 그러나 하나의 도메인을 설정하면 같은 도메인을 가지는 속성은 그 도메인을 사용함으로 해서 데이터 타입과 도메인의 일치성으로 무결성을 간단히 강화할 수가 있는 것입니다.

 

도메인은 속성이 가질 수 있는 값의 집합을 말하는 것입니다. 즉, 엔티티 집합에 나타난 속성은 해당 도메인의 부분집합이지 전체집합이 아닙니다. 속성에 나타난 값들은 다시 나타날 수 있다는 의미를 가집니다. 또한 도메인은 같은 도메인을 가지는 두 속성의 비교에서 의미있는 것인지를 판단할 수 있는 기준을 제공합니다. 

 

일단 각 속성들이 가질 수 있는 값의 집합이 무엇인지 파악해 보도록 하겠습니다. 오라클의 SQL*Plus를 기동시키고 scott/tiger로 접속합니다. (모르시는 분은 9장 참조하세요.)

 

<그림 4_56.bmp>

<그림 4_57.bmp>

 

<그림 4_58.bmp>

 

<참고>

 

EMP 테이블은 사원에 관한 것이고 DEPT 테이블은 부서에 관련된 것입니

다. 사원 테이블을 보면, 사원번호, 이름, 직무, 상사직원, 입사일, 월급, 커미션, 부서

번호 순으로 되어 있습니다. 부서는 부서번호, 부서이름, 위치입니다. 사원 테이블에서

 

</참고>

 

먼저 도메인을 정의할 때는 데이터 타입, 길이, Foramt/Mask,  허용범위, 의미, 유일성, 널값허용 여부, 기본값등이 정의되어야 합니다. 이런 것들이 어떤 식으로 관리되고 있는지 보겠습니다. 

 

간단히 데이터 타입부터 살펴보겠습니다. EMPNO 같은 경우는 NUMBER(4)와 NOT NULL로되어 있는 것이 보입니다. 사실 여기서 보이지는 않지만 EMPNO는 주식별자 역할을 하는 것입니다. 다음은 EMPNO에 대한 도메인의 정의입니다.

 

<박스>

 

속성명: EMPNO (사원번호)

데이터 타입: NUMBER

길이: 4

형식: [0-9] [0-9] [0-9] [0-9]

허용범위: 0000 ~ 9999

의미: 사원엔티티 집합에서 각각의 사원을 구분지을 수 있는 역할을 하는 주 식별자

유일성: UNIQUE

널값허용: NOT NULL

기본값 : 없음

 

</박스>

 

나머지 것들은 독자분들이 이와 같은 방법으로 종이에 써보시기 바랍니다. 중요한 것은 이렇게 도메인이 관리되는 기법이라든지 방법이 아닙니다. 도메인이 가지는 의미와 구지 이런식으로 도메인이 관리되어야 하는 필요성에 대한 것이 중요한 것입니다.

 

다른 것은 그냥 보아도 알 수 있을 것입니다. 단지 약간 의아해 할 만한 것은 형식과 허용범위일 것입니다. 형식은 ‘[0-9] [0-9] [0-9] [0-9]’ 와 같이 표현했는데 만약 사원번호의 중간에 ‘-‘ 기호가 들어간다면 형식은 ‘[0-9] [0-9] - [0-9] [0-9]’ 와 같이 되겠지요. 형식은 정보시스템의 대상이 되는 조직의 범위에서 통용되는 형식을 말합니다.

 

앞에서 “엔티티 집합에 나타난 속성은 해당 도메인의 부분집합이지 전체집합이 아니다.” 라고 하였습니다. 허용범위에서도 보듯이 EMP 테이블에 나타난 사원번호는 0000 ~ 9999 사이에 들어있는 부분집합입니다.

 

도메인의 관리는 구축하는 사람마다 틀린 방법을 가질 수 있습니다. 딱 이런 형식으로 도메인의 관리를 하면 좋다라는 식입니다. 이 책에서는 파워디자이너를 이용하고 있으므로 파워디자이너의 도메인 관리 기법에 종속적으로 설명하도록 하겠습니다.  일단 파워디자이너의 [File] à [Open]을 하여, 파워디자이너의 홈 디렉토리 밑에 있는 Tutorial 로 가서 cdmbefore.cdm 를 열어 봅니다. 다음으로 [Model] à [Domains]를 누르면 다음과 같은 그림을 만날 수 있습니다. 이 윈도우에서 도구버튼들 중 가장 왼쪽에 있는 [Properties] 버튼을 누르면 각각의 도메인에 대한 자세한 정보를 볼 수 있습니다. 

<그림 4_59.bmp>

 

또한 다음의 그림처럼 왼쪽에 나타나는 브라우저를 이용하셔도 됩니다.

<그림 4_60.bmp>

 

우리는 이제까지 속성의 도메인을 정해주지 않았었습니다. 속성에 도메인을 정해주지 않았다는 것은 특정 도메인에 종속적인 속성을 만들어 주지 않았다는 뜻입니다. 그러므로 특정한 범위를 가지는 속성이 설계시 잘못 정의되어 무결성을 깨뜨릴 수 있는 위험성을 잠정적으로 포함하고 있다는 것이 됩니다. 결론적으로 이것은 “문제점 자체가 일어나지 않는 환경”을 만드는 데이터베이스의 기본철학을 반영하지 못하는 것입니다.

 

이제 우리는 속성을 정의하기 전 도메인을 먼저 정의한 후 정의한 도메인에 속하는 속성들도 각각 정리하는 과정을 파워디자이너로 실습해 보겠습니다.

 

도구버튼에서 [New]를 클릭한 후 Conceptual Data Model을 선택한 후, “학생” 엔티티를 하나 생성합니다.

 

[Model] à [Domains]를 클릭합니다. 그러면 다음과 같은 폼을 만날 수 있으며, “학생” 엔티티에 대한 도메인을 정의해 줍니다. 이것은 “학생” 엔티티의 속성에 대한 도메인을 먼저 정의하고 속성을 정의하는 과정입니다.

<그림 4_61.bmp>

기본적으로 도메인의 Name, Data Type, Length/Precision과 의미를 정의합니다. 의미는 Precision옆의 공간에 의미를 적어 줍니다.

 

다음으로 학번에 대한 좀더 자세한 범위를 지정해 주기 위해서 학번을 선택한 후 Properties 단추를 클릭합니다.

<그림 4_62.bmp>

학년 도메인의 속성에서 Standard Checks 탭에서 다음과 같이 정의해 줍니다.

<그림 4_63.bmp>

이것은 학년이 1 ~ 4 학년까지 밖에 없으므로 (의대가 없다는 가정..) 최소 1이고, 최대 4의 값의 들어갈 수 있으며, 1학년이 제일 많다는 가정하에 기본값을 1로 설정해준 것입니다. 이제 도메인을 정의하였으니, 엔티티의 속성을 정의해 보도록 하겠습니다.

 

“학생” 엔티티를 클릭하여 학번, 이름, 학년을 입력합니다. 그런 후 다음 그림처럼 도메인을 선택해 줍니다. 그러면 Data Type이 도메인에 맞게 고쳐지는 것이 보입니다.

<그림 4_64>

 

이러한 과정은 각각의 속성이 어느 한 도메인에 속해져(도메인은 전체집합이고 해당 도메인에 속하는 속성은 부분집합이다.) 있다는 것을 말해 줍니다. 여기서 “이름” 같은 경우는 꼭 “학생” 엔티티 집합을 위한 도메인은 아닐 것입니다. 이러한 경우 속성이름은 “학생이름”, “직원이름” 등으로 주고, 도메인을 “이름”으로 두면 될 것입니다. 파워디자이너에서는 이런 형태로 도메인 관리를 하고 있습니다.

 

사실 아무리 자동화된 툴이라도 직접 코딩을 통해서 만드는 것은 따라갈 수가 없습니다. SQL문을 이용하는 것은 툴에 의존하는 것보다 훨씬 더 현실을 잘 표현할 수 있습니다. 중반 이후부터는 SQL문을 이용해서 테이블을 만들고, 현실의 제약사항 등을 표현할 것입니다. 그때 열심히 해두시면 툴을 다루는 것이 우스워 보일 수도 있습니다.

 

14. 순환 관계와 Bill-Of-Material 관계와 계층적 관계의 고려

우리는 이미 Bill-Of-Material(BOM) 관계에 대한 것을 다루어 봤습니다. BOM 관계란 동일한 엔티티 집합의 속성 사이에서 생기는 관계를 말합니다. 즉, 앞서서 다루었던 관리자와 사원의 관계(다:다)입니다. 또 다른 대표적인 예를 든다면 “부품”에 관련된 것입니다. 자동차를 생각해보면 자동차는 여러 가지 부품으로 구성되며, 또한 부품은 여러 부품이 모여서 하나의 부품을 이루기도 합니다. 이렇게 “부품”은 자신의 속성간에 다:다의 관계를 맺고 있습니다. 이것을 표현하려면 어떻게 할까요? 이런 경우는 앞에서 언급했던 “카테시안곱”의 수 만큼 즉, 모든 경우의 수를 어플리케이션에서 나타내어야 하는 무시무시한 결과를 가져올 수 있습니다. 그러나 현실이 변화를 하면 관련 어플리케이션 로직을 모두 뜯어고쳐야 하는 짜증나는 일이 일어날 수 있습니다. 이러한 개발방식은 시스템의 생명을 단축시키는 일입니다. 어떻게 하면 간단하게 처리를 할 수 있을까요? 이미 알고 계시듯 순환관계(BOM)를 맺어주면 되는 것입니다.

 

<참고>

순환 관계와 Bill-Of-Material 관계

순환 관계는 BOM 관계를 포함하는 전체집합으로 보면 되겠습니다. 즉, BOM 관계는 순환관계의 특별한 경우로 순환관계가 다:다의 관계를 이루고 있을 때 BOM 관계라고 합니다. 그러나 우습게도 책마다 그냥 순환관계와 BOM 관계를 특별히 구분짓고 있는 책도 있고, 그렇지 않은 책도 있습니다. 이 책에서도 마찬가지로 선을 딱 그어서 구분짓지는 않겠습니다. 독자분들은 이를 염두해 두시고 책의 내용을 중심으로 이해를 하시기 바랍니다.

</참고>

 

여러분은 그러한 문제를 순환관계를 맺어주면 단순화할 수 있다는 것을 이미 알고 있습니다. 그렇다면 어떻게 해서 단순화되는 것일까요? 문제에 대한 답만 알고 있다면 그것은 단순한 암기에 불과한 것입니다. 독자분들은 항상 “왜?” 라는 생각을 가지고 있어야 합니다. 그럼 이제부터 그 “왜?” 에 대한 답을 찾아보도록 하겠습니다. 또한 계층구조를 가지는 엔티티 집합간의 관계를 살펴보도록 하겠습니다.

 

여러분이 동문회 관리 시스템을 구축하려고 하고, 사용자들이 원하는 정보는 대학의 캠퍼스, 단과대학, 학과별로 동문에 대한 정보를 알고 싶다고 한다면 여러분은 ERD를 어떻게 그리겠습니까? 캠퍼스, 단과대학, 학과는 계층구조를 이루고 있습니다. 즉, 각각의 캠퍼스에는 여러 개의 단과대학이 소속되어 있고, 각각의 단과대학은 여러 개의 학과를 포함하고 있습니다. 이러한 관계를 그대로 나타낸다면 아래 그림의 왼쪽과 같은 모양이 나오겠지요. 사실 관계의 이름을 정하는 것도 중요합니다. 그러나 여기서는 관계의 이름을 같게 만들었습니다. 파워디자이너에서는 같은 관계의 이름을 허용하고 있지 않습니다. 저는 그래서 마침표를 하나 추가해서 관계의 이름에 적용하였습니다. 여기서는 중요한 것이 관계의 이름이 아니라 위에서 서술한 것과 같은 엔티티 집합과의 관계를 어떻게 나타내야만 효율적인 모델링인가를 판단해야 합니다.

 

<그림 4_65.bmp>

 

또한 순환관계를 맺어 줄 때 계층적인 모습이라고 해서 무조건 순환관계를 맺어주는 것은 아닙니다.

<쉬어가기>

고정관념을 버리고 현실을 직관적으로 바라보자.

 

제가 요즘에 후배한 명을 데리고 데이터베이스를 살짝 가리켜 주고 있습니다. 얼마전 후배게 인라인뷰(InLine View)를 초보자에게 가르쳐줬더니 아주 쉬운 것도 인라인뷰를 써서 해결하고 무진장 노력하는 것을 보았습니다. 한참 고생하고 있는 후배에게 인라인뷰를 쓰지 않아도 결과를 낼 수 있다라는 것을 보여줬더니 인라인뷰가 머리에 밖혀서 그것밖에 생각나지 않는다고 하더군요. 제가 왜 이런 이야기를 하냐면 계층구조를 가진다고 해서 무조건 순환관계를 맺어주지 말라는 이야기를 하기 위해서입니다. 필자도 처음에 순환관계를 보고서 계층구조를 갖는다면 무조건 순환관계를 맺어줘야 하는 줄 알았습니다. 이런 고정관념은 어서 빨리 탈피를 해야합니다. 기본적인 모델링 방법이야 어떤 모델러가 모델링을 하건 같겠지만 그런 방법에 치우치지는 말아야 한다는 것입니다. 기업마다 조직마다 환경이 틀리고, 업무규칙이 틀린데, 정보시스템의 구축이 되는 대상의 환경은 생각치 않고 고정관념에 사로잡혀서 모델링을 하는 것 나중에 어떠한 결과가 개발자를 괴롭힐지 모르기 때문입니다.

 

</쉬어가기>

 

그림에서는 캠퍼스 : 단과대학 = 1(선택) : 다(필수) , 단과대학 : 학과 = 1(필수) : 다(필수)로 표현하였습니다. 이러한 표현을 다른 방식으로 몇가지를 예를 들어서 효율성과 문제점을 파악해보도록 하겠습니다. 사실 이러한 문제는 뒤에서 다룰 정규화 과정을 안다면 더 확실히 알 수 있지만 여기서는 정규화라는 틀에서 생각하지 않고 직관적으로 생각해 보도록 하겠습니다.

 

먼저 학과를 생각해보면 학과에는 각각의 학과를 구분할 수 있는 주식별자가 존재할 것입니다. 만약 각 학과의 이름이 고유하다면 “학과명”은 주식별자가 될 수 있는 자격을 갖추고 있는 것입니다. 그러나 캠퍼스가 있다면 “학과명”은 고유하지 않고, 각 학과를 구분할 수 없으므로 주 식별자가 되지 못합니다. 그렇다면 주 식별자를 두기 위해서 설계 속성을 둘 수 있을 것입니다. 일반적인 설계 속성은 “학과코드”일 것입니다. 학과코드는 각각의 학교마다 그 범위내에서 통용되는 의미를 가진 “번호”로 구성되었거나 하이폰(-)이 섞여 있을 수도 있을 것입니다. 이럴 경우는 반드시 데이터 형에 대한 고려를 해줘야 합니다. 물론 어플리케이션에서 어떤 데이터형으로 접근하는 것도 반드시 명시를 해줘야만 나중에 비참한 일이 벌어지지 않습니다.

 

만약 데이터 모델링의 대상이 되는 학교의 학과에 대한 코드가 캠퍼스와 단과대학의 의미를 내포할 수 있게 만든다면 위와 같은 ERD는 필요없이 단순한 “학과코드” 만으로도 위의 관계를 단순화 할 수 있을 것입니다. 그러나 학과의 명칭이 바뀐다든가 학과가 학부제로 바뀐다던가 할 때는 코드체계에 문제가 생겨 관련 어플리케이션에 대한 수정을 하려면 상당히 고달플 겁니다. 그것도 그냥 속성이 아닌 주식별자 역할을 하는 속성이기 때문에 그 여파는 시스템의 상당히 많은 부분에 미칠 것입니다. 그러므로 이러한 경우는 변화가 예상되지 않는 경우에 쓸 수 있는 방법이라고 할 수 있습니다.

 

두번 째로 위의 ERD대로 데이터베이스를 설계한다는 가정을 생각해보도록 하겠습니다. 일반적으로 대학의 캠퍼스는 2~3개정도로 그 수가 아주 적습니다. 또한 “단과대학”은 외부 식별자로 “캠퍼스”의 주식별자를 가지고, 또한 이 외부식별자는 주식별자의 일부가 되어야 할 지도 모릅니다. 아래로 갈수록 “캠퍼스”에 대한 주식별자는 카디날리키의 수만큼 늘어납니다. 즉, 물리적으로 구현을 했을 때는 결국에는 “캠퍼스” 와 “단과대학”에 있는 데이터가 모두 중복되는 결과가 나타나게 됩니다. 물론 설계속성을 두어서 설계를 한다면 데이터의 중복은 감소할 것이나 논리적으로 따져볼 때는 필요없는 데이터의 중복을 피할 수는 없습니다.

<그림 4_66.jpg>

 

이번에는 엔티티의 자격에 대해서 살펴보도록 하겠습니다. “캠퍼스”만 따져볼 때 “캠퍼스”가 과연 우리가 관리하고자 하는 즉, 엔티티 집합이 될 자격이 될까요? 앞서서 언급했듯이 엔티티 집합의 자격요건은 두개 이상의 속성과 두개 이상의 엔티티가 존재해야 한다고 했습니다. 그렇다면 캠퍼스에 대한 속성으로 캠퍼스명과 또 무엇이 있을까요? 설계속성을 넣는다고 “캠퍼스 번호”라고 속성명을 지어주고 넣는 것이 좋을까요? 이러한 언뜻 보기에도 별로 좋은 생각은 아닌 듯한 느낌이 들겁니다. 이러한 기준을 빼놓고도 “캠퍼스” 자체만으로 어떤 정보를 사용자에게 줄 수 있을까요? 해당 대학교는 캠퍼스가 어디에 있으며, 몇 개가 있는가가 정보가 될 수 있을까요?

 

통신이론의 범위에서의 정보공학에서는 정보의 정량적 분석을 근간으로 정보이론을 말하고 있습니다. 이러한 정보이론에서 발생확률이 1인 것은 정보의 양을 “0”으로 보고 있습니다. 즉, “내일은 해가 동쪽에서 뜰 것이다. “라는 것은 정보의 양을 “0” 취급하고 있습니다. 만약 “내일 전쟁일 일어난다.” 라는 말을 들었을 때는 이는 정보의 양이 많은 것이죠. 이러한 관점으로 볼 때 과연 동문회에 가입한 사람들이 학교의 캠퍼스가 어디에 몇 개 있는지 모르는 사람이 있을까요? 아마도 이것을 모르는 사람은 없을 겁니다. 즉, 캠퍼스는 엔티티가 될 수 없음을 의미합니다. 물론 단과 대학도 마찬가지 입니다.

 

이렇게 미루어 볼 때 위의 설계는 잘못되어 있음을 알 수 있습니다. 그렇다면 여러분은 어떻게 표현을 해야 좋은 ERD를 그릴 수 있을까요? 필자는 다음과 같은 방법을 선택하였습니다. 가만히 살펴보면 대학의 캠퍼스는 2~3개이고, 각각의 캠퍼스 별로 단과대학과 단과대학에 포함된 학과가 있기 때문입니다. 우리는 3장에서 “데이터 모델링의 원칙: 추상화” 에서 일반화, 분류화, 집단화를 살펴보았습니다. 즉, 캠퍼스를 구분할 수 있는 기준을 캠퍼스명 또는 지역 등으로 할 수 있고, 또한 각각의 학과_캠퍼스에 단과대학의 속성을 두어 각각의 학과가 속한 단과대학을 알 수 있게 하였습니다. 물론 일반화 관계를 맺어주지 않고 그냥 하나의 엔티티 집합으로 구현할 수 있으나 물리적인 측면을 생각해 볼 때 일반화 과정을 거쳤을 때보다 접근하는 데이터의 양이 많아지므로 성능상의 이유로 일반화 관계를 맺는게 좋습니다.

 

<그림 4_67.bmp>

 

이제 2번째 그림인 “상사직원”과 “직원”의 관계를 살펴보도록 하겠습니다. 우리는 이미 이 관계는 순환관계로 맺어 주는 것이 좋다는 것을 알고 있습니다. 왜 위에서 나온 바와 같이 1:다의 관계를 맺어 주지를 않았을까요? 상식적으로 생각해 보아도 상상직원도 직원이고, 상상직원으로부터 관리를 받고 있는 부하직원도 직원입니다. 즉, 같은 엔티티의 다른 표현을 한 것 밖에 안됍니다. 그러므로 상사직원과 직원 엔티티는 통합되어야 하며, 직원과 직원사이의 순환관계가 되는 것입니다. 이처럼 순환관계는 같은 엔티티들 사이에 일어나는 관계를 말합니다.

 

일반적으로 순환관계는 1(선택) : 다(필수)의 관계를 가집니다. 만약 1(필수) : 다(필수)라면 어떨까요?  상사직원(1, 필수) : 직원(다, 필수)라면 각각의 직원은 반드시 한명 이상의 직원을 관리하고, 각각의 직원은 반드시 한명의 직원으로 관리된다면 이것은 무한루프인 것입니다. 그러므로 순환관계는 반드시 선택적인 관계이어야 하는 것입니다. 그렇다면 위에서 나온 상사직원(1, 필수) : 직원(다, 필수)의 관계는 잘못된 관계라고 볼 수 있는 것입니다. 반드시 한 쪽이 선택적(Optional)이어야 하는 것입니다.

 

다:다의 순환관계는 반드시 해소되어야 합니다. 앞서서 벌써 해소방안을 제시하고 이유를 설명하였으니 여기서는 “부품”에 관한 예를 들고 넘어가도록 하겠습니다. 앞서서 이 책은 개념적인 것과 논리적인 것을 딱 잘라서 구분하지 않는다고 했습니다. 개념적 데이터 모델을 물리적 모델로 변환하는 과정은 논리적인 요소가 포함된 것입니다. 논리적인 부분과 물리적인 부분의 구분은 내용상의 문제입니다. 물리적 데이터 모델로 변환을 했다고 해서 정확히 물리적 데이터 모델이 되었다고는 하지 마시길 바랍니다.

 

 

<그림 4_68.bmp>

 

마지막으로 한가지 예를 더 들어보고 “순환 관계와 Bill-Of-Material 관계와 계층적 관계의 고려 단원”을 마치도록 하겠습니다. 아래 그림은 예전에 제 친구와 함께 열심히 생각했던 것인데 테이블 2개 가지고 밤을 샜던 적이 있었습니다. 우습죠? 아래 그림은 MS-SQL Server 2000에서 작업 했던 것입니다. 시나리오는 메신저에 관련된 것입니다. 즉, 회원가입을 받고 그 회원은 메신저를 사용하는데 회원들끼리 서로서로 친구추가를 하고, 각 회원은 자신이 추가한 회원을 그룹을 지어주고 관리하는 시나리오입니다.

 

회원과 회원사이에는 다:다의 순환관계를 맺어주고, 관계에 대한 속성으로 group_name을 추가해줬습니다. 처음에는 제 친구가 다른 DB전문가가 하나의 속성에 속성값을 “회원, 그룹, 그룹구성원” 으로 하라고 했다고 해서 실무의 경험이 별로 없던 저에게 DB전문가의 말은 거의 고정관념으로 박히려고 할 찰나... 정신을 차리고 보니 1차 정규화도 안됀 솔루션을 친구에게 알려 주었던 것입니다. 결국은 아래와 같이 했지만 기억에 남는 경험이였습니다. 독자분들은 주관적인 생각을 하지 마시고, 좀더 통합적이고 객관적인 판단으로 모델링을 해야 할 것입니다.

 

<그림 4_69.bmp>

 

 

15. 중복관계의 제거

 

데이터 모델링을 하다보면 간혹 중복관계가 설정될 수 있습니다. 이것은 관계의 이름을 잘못 정해준 문제도 있으며, 또 팀으로 나누어서 프로젝트를 진행하다보면 설계자간의 관점의 차이로 중복관계가 생길 수도 있습니다. 이러한 중복관계는 반드시 제거되어야 합니다. 데이터베이스의 정의에서도 이야기 하듯이 중복관계는 불필요한 것이며, 또한 데이터 모델을 복잡하게 만듭니다.

 

중복관계인가 중복관계가 아닌가의 판단은 의미론적으로 판단하는 방법이 있습니다. 사원과 부서의 관계에서 “소속된다” 와 “포함된다”와 같이 의미가 같다는 것을 판단할 수 있지만 간혹 애매모호한 경우가 있습니다. 이럴때는 어떤 것을 기준으로 중복관계인가 아닌가를 판단해야 할까요? 다음 그림을 살펴보도록 하겠습니다. 그림에서 나타난 관계의 카디날리티는 정확하다는 가정하에 그림을 보도록 하겠습니다.

 

<그림 4_70.bmp>

 

관계의 이름인 “지도한다”와 “가르친다”는 의미상으로 판단하기가 매우 어렵습니다. 이럴 때는 중복관계인가를 판단하기 위한 기준으로 앞서서 이야기 했던 “카디날리티”를 가지고 판단하면 되겠습니다. 그냥 보아도 최소카디날리티에서 틀리다는 것을 알 수 있습니다. 최소카디날리티가 틀리다는 것은 2개의 관계가 서로 독립적이라는 것을 의미합니다.

 

그렇다면 만약 최소카디날리티가 모두 같은 아래의 그림과 같은 업무규칙이 있다면 어떻게 중복관계의 판단기준을 마련해야 할까요?

<그림 4_71.bmp>

 

예상하신분들도 계시겠지만 최대카디날리티로 판단의 기준을 마련합니다. 여기서 말하는 최대카디날리티는 정확한 수치에 의한 것입니다. 한명의 교수가 1학년(예: 100명)을 지도하고, 총 200명을 가르친다면 이것은 중복관계가 아님을 알 수 있는 것입니다. 사실 이러한 부분은 계획에 의해서 단계적으로 행해져야 하는 것입니다. 설계 초기단계부터 이러한 부분을 염두해두고 설계를 한다면 복잡성에 빠질 우려가 있기 때문에 점진적인 방식을 사용하는 것을 필자도 추천하고 다른 저자분들이나 실무자분들이 추천하는 방식입니다.

 

16. 정규화

 

우리는 이제까지 데이터베이스의 설계를 위한 여러가지를 살펴보았습니다. 위에서 다룬 것은 현실을 어떻게하면 가장 근접하게 표현하는가에 대한 고려사항들이였습니다. 이것들은 현실을 직관적으로 바라보고, 논리적으로 어떻게 하면 현실을 제대로 데이터베이스에 반영할 것인가에 대한 것이였습니다.

 

데이터베이스의 설계에서 가장 중요한 것은 현실을 제대로 반영하는 것이며, 이를 어떻게 논리적으로 구성하는가를 결정하는 것입니다. 특히 관계형 데이터 모델에서는 데이터 값들이 2차원의 평면 테이블 형태로 표현하므로 어떤 릴레이션들이 필요하고, 어떤 애트리뷰트가 필요한가를 결정하는 것이 중요합니다. 

 

이젠 앞서서 직관적으로 바라보았던 것들을 ‘정규화’라는 원리를 도입할 것입니다. 정규화는 관계형 데이터 모델에서 아주 중요한 역할을 하고 있습니다. 학자마다 정규화는 튜닝의 도구 또는 설계 검증의 도구이다라고 의견이 약간씩은 다르지만 결국은 같은 의미를 가지고 있습니다. 현실을 제대로 반영하는 것은 튜닝과 검증이라는 것을 모두 포함하고 있기 때문입니다.

 

데이터베이스 설계를 할 때 우리는 단계적인 사고방식을 가져야한다고 했습니다. 단계적인 사고 방식에서 윗 단계를 생각해 봅시다. 대부분은 설계의 초기단계에서 복잡한 생각을 하지 않는다고 나중에 누락되지는 않을까 하고 생각하는 분들이 많습니다. 그러나 이러한 것들은 정규화 과정이나 앞의 단계를 거치면서 데이터 모델링은 멋있게 틀을 잡아갑니다. 이렇게 틀을 잡아가는 것중 정규화는 그야말로 아주 큰 역할을 하는 것입니다. 앞에서 행했던 설계를 검증하고, 데이터의 중복을 없앤다 것 자체가 정보의 질을 높이고, 설계의 튜닝을 하는 것이니까요.

 

정규화란 속성이 제위치에 제대로 찾아가게끔 하는 것입니다. 정규화의 목적은 당연히 데이터의 중복의 최소화와 여러가지 이상(Anomaly)들을 제거함에 있습니다. 데이터가 중복되어 있으면 여러 문제를 일으킬 수 있습니다. 삽입, 삭제, 변경에서 나타는 이상들이 개발자를 괴롭히는 것입니다. 이것은 결국 속성이 제자리에 있지 않기 때문에 발생하는 중복의 문제점 때문이라고 할 수 있습니다.

 

정규화 과정은 속성간에 관계성, 데이터 종속성, 성능, 데이터베이스의 일관성 유지등을 고려해야합니다. 정규화를 검증도구라고 하는 것도 설계가 잘못되면 일어날 수 있는 여러가지 문제점을 예방하는 차원이기 때문입니다. 또한 데이터의 중복을 없앤다는 자체가 엄청난 튜닝의 효과를 가지는 것입니다. 일단 데이터의 중복이 많은 설계는 먼가가 문제가 있는 설계입니다. 데이터베이스의 정의에서도 언급했듯이 데이터베이스는 중복의 최소화로 기존의 파일처리방식이나 수작업 방식에서 오는 정보의 질을 떨어뜨리는 문제점을 없애는 것입니다. 이러한 문제점을 좋은 정보의 질을 유지하기 위한 하나의 정형화된 도구 즉, 정규화를 통해 해결을 하게 되는 것입니다.

 

정규화는 데이터의 중복으로 인한 문제를 해결하기 위해서 속성들간에 종속성(Dependency)을 분석해서 기본적으로 하나의 릴레이션(테이블)에 표현하도록 분해를 하는 것입니다. 어떻게 보면 테이블을 무작정 쪼개는 것으로 보일 수도 있습니다. 그러나 테이블을 쪼개는 기준은 “함수적 종속”이란 개념으로 쪼개는 것입니다. 즉, 함수적 종속성을 파악한 다음 그 함수적 종속을 기본으로 해서 속성들을 하나의 테이블로 그룹짓는 것입니다.

 

16.1 함수적 종속

 

그럼 “함수적 종속” 이란 것이 무엇인가 살펴보도록 하겠습니다. 일단 함수라 하면 다음의 그림과 같이 나타낼 수 있습니다.

 

<그림 4_72.jpg>

 

이것을 테이블로 표현한다면 다음과 같겠지요.

<그림 4_73.jpg>

 

감이 약간 오시나요?? 일단 함수적 종속이란 말에서 함수라는 것에 대해서 살펴보도록 하겠습니다. 함수가 무엇인가요? 다름의 그림을 보고서 설명을 하도록 하겠습니다.

<그림 4_74.jpg>

 

그림처럼 왼쪽은 2라는 원소가 두개가 들어 있습니다. 2를 어떤 함수에 집어 넣어야지 4가 될까요? 일반적으로 생각해 보면 2의 제곱을 구하는 함수에 값을 집어 넣는다면 4가 되겠지요. 그러나 역으로 4를 집어 넣는다면 16이 되버리는 것입니다. 즉, 2와 –2는 4가 되기 위해서 함수적으로 종속되어 있는 것입니다. 결국 4는 2와 –2가 4가 되기 위한 함수에 종속적이기 때문에 2의 제곱이라는 함수에 종속적이게 만드는 4는 “결정자”라고 부릅니다. 또한 2와 –2를 “종속자”라고 합니다.

 

사실 이렇게 수학적으로 함수적 종속을 설명하였으나 정규화는 시스템을 구축하고자하는 조직내의 의미에 함수적 종속을 설명해야 합니다. 즉, 정규화는 관계형 모델에서 표현하고자 하는 주제가 동일한 속성들끼리 뭉쳐져 있는 것입니다. 그러므로 설계의 초기부터 나타내고 자하는 정보를 의미론적으로 묶는다면 정규화라는 과정의 설계의 검증도구가 되는 것입니다.

 

위의 예에서 2를 Y로 하고 4를 X라 한다면 함수적 종속의 표현은 “X à Y” 로 표기합니다. 이러한 표현을 실제의 예를 들어서 살펴보겠습니다.

<박스>

학생 릴레이션에서 ...

 

학번 à 이름

학번 à 학과

학번 à 학년

 

</박스>

 

위에서 보는 바와 같이 학번은 이름, 학과, 학년을 결정하고 있습니다. 즉, 학생 릴레이션에서 각각의 학생을 유일하게 구분지을 수 있는 속성은 학번으로 학번은 기본키의 역할을 하는 속성입니다. 즉, 이름만 가지고는 각각의 학생을 알 수 없다는 것입니다. 제가 옛날에 휴학을 하려고 했는데 시간이 없어서 조교님께 휴학 신청을 대신해달라고 한 적이 있었습니다. 그런데 저와 같은 이름을 가진 다른 사람이 있었는데 그 사람으로 휴학을 한적이 있어서 상당히 난감했던 적이 있습니다. 즉, 저의 이름인 “이재학” 만 가지고는 정확성이 있는 정보가 될 수 없던 것입니다. 만약 교수님께서 “이재학”을 불러오라 라고 한다면 이미 과에 “이재학”이란 이름을 가진 사람이 2명이라는 것을 아는 사람은 학번을 교수님께 되물을 것입니다. 이렇듯 이름은 학번에 종속되어 있다는 것입니다. 이름이 이재학이고, 학과가 정보통신공학과이고, 4학년인 학생은 저 말고도 한명이 더 있습니다. 즉, 이것들은 학번에 종속적이라는 것입니다.

 

테이블로 표현한 것을 가지고 좀더 살펴보도록 하겠습니다.

<그림 4_75.jpg>

 

9555023, 이재학, 4학년, 정보통신공학과 라는 것은 한명의 학생에 대햔 데이터입니다. 학번, 이름, 학년, 학과중에 대표성을 띄고 있는 것은 학번이고, [9555023, 이재학], [9555023, 4학년], [9555023, 정보통신] 이라고 해야지만 정확한 정보를 표현할 수가 있는 것이죠. 앞에서 언급했듯이 [이재학, 4학년, 정보통신]이라고 해서 정확한 정보가 되는 것일까요? 당연히 학번이 9555023인 학생과 학번이 9839011인 학생을 구별하지 못하는데 문제가 있습니다.

 

이렇듯 학번은 이름, 학년, 학과를 결정하고, 이름, 학년, 학과는 학번에 종속적입니다. 이렇게 데이터에 대한 의미를 표현한 것을 함수적 종속이라고 합니다.

 

<참고>

함수 종속에 대한 증명된 추론 규칙 (R à 릴레이션)

(데이터베이스시스템, 이석호, 정익사)

 

R1: (반사규칙) A Ê B 이면 A à B 이다.

R2: (첨가규칙) A à B 이면 AC à BC 이고 AC à B 이다.

R3: (이행규칙) A à B 이고 B à C 이면 A à C 이다.

R4: (분해규칙) A à BC 이면 A à B 이다.

R5: (결합규칙) A à B 이고 A à C 이면 A à BC 이다.

 

</참고>

 

정규화는 이러한 “함수적 종속”을 기본 원칙으로 하나의 의미를 가지는 집합으로 나누는 작업입니다. 정규화는 1차 정규화, 2차 정규화, 3차 정규화, 보이스/코드 정규화, 4차 정규화, 5차 정규화, 도메인/키 정규화가 있습니다. 이 순서가 높아지는 단계의 정규화일수록 무결성은 강화되나 과도하게 테이블이 쪼개지므로 쓸 때 없는 부하가 걸릴 수 있습니다. 그러므로 현실을 감안해서 어느 정도 수준의 정규화까지 행해야 하는가를 결정해야 합니다. 보통 실무에서는 3차 정규화와 보이스/코드 정규화까지 합니다. 기본으로 3차 정규화까지는 해야 하며, 3차 정규화 과정을 마치고도 사용자의 요구사항에 의해서 여러가지 이상들이 발생할 요지가 있다면 더 높은 차원의 정규화를 해야 합니다. 이제 각 단계별 정규화에 대해서 설명하도록 하겠습니다.

 

16.2 1차 정규화

 

하나의 릴레이션은 어떤 도메인의 집합입니다. 각각의 속성은 해당 도메인에 속하는 단지 하나의 값을 가져야 합니다. 이것이 1차 정규화 이며, 실제로 1차 정규화도 거치지 않은 테이블이 많이 존재합니다. 예를 들면 다중값 속성들이 그대로 표현될 때 정규화된 테이블이 아닌 즉, 비정규화 테이블인 것입니다. 사원테이블에 사번, 이름, 보유기술, 월급의 속성이 있는데 보유기술은 여러 개를 가질 수 있다는 현실을 생각해 보도록 하겠습니다. 일반적으로 문서를 만들면 다음과 같은 문서가 나올 수 있습니다. 보유기술에서 하나의 속성값에 여러 개의 값이 들어간 것을 볼 수 있습니다. 이러한 표현은 비정규화 된 테이블입니다. 여기서 기본키는 사원번호입니다. 

<그림 4_76.jpg>

 

그렇다고 다음과 같이 보유기술을 옆으로 펼친다고 해서 달라지는 것은 없습니다. 이도 역시 1차 정규화된 테이블이 아니라고 볼 수 있습니다. 의미상으로 보유기술1, 보유기술2, 보유기술3는 그냥 보유기술의 종류일 뿐입니다. 그러니 하나의 속성에 여러 개의 값을 다른 표현으로 한 것 뿐입니다.

<그림 4_77.jpg>

 

어떤 독자분은 보유기술 속성에 속성값을 넣는데 콤마로 구분하면 어떻겠냐? 라는 생각을 가질 수도 있습니다. 만약 사원번호 1111 인 사원의 보유기술을 하나더 추가하려면 기본키가 “사원번호” 이므로 “사원번호”가 1111 인 사원이 추가되지 못하는 것을 알 수 있습니다.

즉, 다음과 같은 그림이 되어 삽입을 할 수 없는 형태가 되는 것입니다.

<그림 4_78.jpg>

 

이제 본격적인 정규화에 대해서 알아보겠습니다. 아래의 테이블은 각각의 학생에 대해서 각각의 속성마다 단일값을 가지고 있으므로 1차 정규화된 테이블이 입니다. 여기서 독자분들은 함수적 종속관계를 찾아보아야 할 것입니다. 여러분은 찾아낸 함수적 종속성을 바탕으로 데이터가 많이 중복되어 있고, 그 데이터의 중복으로 인한 여러가지 문제점(이상)들을 찾아내어야 합니다.

 

<그림 4_79.jpg>

 

이 테이블의 함수적 종속 다이어그램의 다음과 같습니다.

<그림 4_80.jpg>

 

함수적 종속 다이어그램에서 보는 바와 같이 학번은 학생명과 학년을 결정하고, 학번은 학과를 결정합니다. 또한 수강코드는 담당교수와 과목명을 결정합니다. 각각의 학생은 자신이 수강신청한 과목의 성적등급을 알기 위해서 학번과 수강코드가 필요합니다. 담당교수는 학과를 결정합니다. 여기서 자칫 잘못하면 학과가 담당교수를 결정할 수 있다고 볼 수 있는데 하나의 학과에 소속된 교수는 여러명인 것이 보입니다. 즉, 지도교수가 학과를 결정하는 것이지 학과가 교수를 결정하는 것이 아닙니다.

 

이제 1차정규화된 테이블을 가지고 나타나는 문제점을 살펴보도록 하겠습니다. 이러한 문제점은 함수적 종속과 관련하여 찾아보아야 합니다.

<그림 4_81.jpg>

 

이 테이블은 학번만 가지고는 어떤 과목의 성적의 등급이 얼마인지를 모릅니다. 그러므로 이 테이블의 기본키는 학번 + 수강코드입니다. 여기서 주의할 것은 수강코드라는 속성의 이름이 수강을 해야만 하는 코드가 아니라는 사실입니다. 즉, 수강할때 그 과목을 나타내는 과목의 고유번호응 나타내는 것입니다.

 

16.3 2차 정규화

 

앞서서 삽입, 삭제, 갱신 이상들이 일어 날 수 있다는 것을 보았습니다. 1차 정규화된 테이블에서 이러한 문제점이 일어나는 원인이 무엇일까요? 원인은 바로 기본키가 아닌 각각의 속성들이 기본키에 종속적이지 않고, 부분적으로 함수 종속이 되기 때문입니다. 즉, 기본키를 제외한 모든 속성이 기본키에 함수적 종속이 아니기 때문입니다. 이러한 문제를 해결하기 위해서는 기본키에 함수 종속을 시킨 것 끼리 따로 테이블을 만들어야 합니다. 2차 정규화된 테이블은 다음과 같습니다. ( 테이블 밑은 점(...)은 생각치 않도록 하겠습니다. )

 

<그림 4_82.jpg>

 

2차 정규화의 결과로 위와 같은 3개의 테이블이 나왔습니다. 학생과 수강과목은 다:다의 관계를 맺고 있기 때문에 학생의 학번과 수강과목의 수강코드가 합쳐진 것을 기본키로 하여 학생 테이블과 수강과목 테이블을 연관지어 주고 있습니다. 사실 데이터 모델링의 초기단계부터 차근 차근 진행해 오면서 엔티티만 제대로 도출해 냈다면 이와 같은 2차 정규화 작업은 필요가 없습니다. 그러나 이와 같은 검증된 원리를 알고 있다면 애매모호 함이 없어지고,  좀더 정확한 정보를 산출하는 정보시스템이 만들어 질 수 있는 것입니다.

 

학생 테이블과 수강과목 테이블에 학과라는 속성이 중복되어 존재하는 것이 보입니다. 이것은 어떤 다른 엔티티 집합이 더 존재한다는 것을 의미합니다. 즉, “학과” 엔티티가 “학생”과 “수강과목”과 관계를 맺고 있다는 것입니다. 위의 테이블을 볼 때 학과와 관련된 엔티티와 학생, 수강과목은 1:다의 관계를 맺고 있음을 알 수 있습니다. 즉,

 

학과 : 학생 à 1 : 다

학과 : 수강과목 à 1 : 다

 

의 관계입니다. (사실 더많은 객관적인 업무규칙이 파악되어야 정확히 알수 있습니다.) 그러므로 속성의 이름은 학과보다는 “학과명”이라고 하는 것이 더 명확하겠지요. 그러나 이 단원에서는 다른 엔티티 집합은 생각치 않고, 이에 대한 고려는 다음 단원에서 하겠습니다.  단지 이것은 정규화를 위한 예제라는 것을 염두해 두시기 바랍니다.

 

이제는 어느정도 속성들이 자신이 있어야 할 곳에 배치된 것으로 보입니다. 그러나 이러한 2차 정규화 테이블에도 이상들이 존재합니다. 이러한 이상들을 살펴보도록 하겠습니다.

 

2차 정규화된 테이블에서 이상이 일어나는 이유는 기본키가 아닌 다른 속성들 간에 함수적 종속이 일어나기 때문입니다. 이렇게 기본키가 아닌 속성들끼리의 종속성을 가지는 것은 이행 종속(Transitive Function Dependency) 라고 합니다. 이러한 개념으로 위의 테이블에서 일어날 수 있는 문제점을 찾아보록 하겠습니다. 먼저 문제의 이행 종속이 일어나고 있는 테이블을 추려내야 합니다. 앞서서 그려본 함수적 종속 다이어그램에서와 같이 이행 종속이 일어나고 있는 테이블은 수강과목 테이블입니다.

 

<박스>

 

삽입이상:

각 과목을 담당하는 교수가 특정 학과에 속한다는 사실을 삽입하려 할 때 과목이 존재하지 않는다면 이 사실을 삽입할 수 없습니다. 즉, 각각의 행을 구분할 수  있는 대표성을 지닌 속성(기본키)가 존재하지 않으므로 삽입이 불가능하다는 것입니다. 기본키는 수강과목 테이블에서 반드시 들어가야만 하는 것인데 이를 무시한채 다른 속성값을 삽입하려 한 것이 문제입니다.

 

삭제이상:

만약 해당 학과의 커리큘럼이 바뀌어 오상훈 교수가 담당하고 있는 과목인 “자료구조”라는 과목이 없어진다면 오상훈 교수가 정보통신공학과에 소속된다는 사실도 없어지게 됩니다. 오상훈 교수가 정보통신공학과에 소속된다는 사실은 이행종속이 일어나고 있다는 것이며, 역시 2차 정규화된 테이블에서 일어나는 삭제이상도 이행 종속때문이라는 것을 알 수 있습니다.

 

갱신이상:

만약 박덕규 교수의 소속 학과가 정보통신에서 다른 학과로 변경된다면 박덕규 교수에 해당되는 학과에 대한 속성값을 모두 변경시켜 주어야 합니다. 역시 이행종속이 일어나서 일어나는 이상현상입니다.

 

</박스>

 

16.4 3차 정규화

 

2차 정규화된 테이블에서 이행 종속에 의해서 여러 가지 이상현상이 발생되는 것을 보았습니다. 이러한 여러 이상현상을 제거하려면 어떻게 해야 할까요? 당연히 이상현상의 원인이 되었던 이행종속을 없애면 됩니다. 어떻게 없애야 할까요? 당연히 이행종속을 일으키는 속성들을 묶어서 그룹지어 주면 문제는 해결됩니다.

 

<그림 4_83.jpg>

 

이렇게 이행 종속성을 제거한 테이블은 3차 정규화된 테이블입니다. 만약 독자분들 중에 여기까지 대충 읽어 보신분들은 아마도 정규화란 것이 테이블을 쪼개는 것이구나 라고 생각하시는 분들도 계실겁니다. 그러나 테이블을 쪼갠다는 개념을 갖지 말고, 좀더 세부적으로 관련성이 많은 것끼리 새로운 그룹을 만드는 개념으로 정규화를 생각하셔야 합니다.

 

<쉬어가기>

 

자존심...

여러분은 느껴보셨는지요? 공대인이 마음이 닫혀있다는 것을... 얼마전 웹상에서 알게된 친구가 저에게 메신저로 호출을 하더군요. 그래서 왜 그러느냐고 했더니 지금 큰일났다고 하더군요. 다시 왜 그러냐고 물었더니 지금 자기가 하고 있는 프로젝트가 원래 D사 의 프로젝트인데 하청으로 받아서 하고 있는데, D사 사람이 와서 DB설계 개판(?)으로 했다고 하면서 엄청 깨졌다고 하더군요. 그러더니 이거 DB 설계 다시해서 그쪽 사람과 협상해야 한다고 하소연을 했습니다. 그래서 한번 보자고 했습니다. ㅡㅡ;;;

 

저는 그 DB설계 해논 것을 보고 이게 도대체 머냐? 그럴만 하다 라고 했습니다. 그랬더니 자기자신도 모르는 상태에서 했기 때문에 그럴만 하다라는 것을 인정하면서도 너무나도 화가 난다고 하는 것이 였습니다. 왜 화가 나는 것일까요? 자신이 해논 것에 대한 쓸 때 없는 자존심 때문일까요?

 

이상스럽게 이쪽 분야에서 일하는 사람이나 공부하는 사람들은 지는 것을 싫어합니다. 사실 게임도 아닌데 많은 사람들이 자신이 제시한 솔루션이 가장 옳다라고 우겨서(?) 이기고자하는 경향이 있습니다.(물론 필자도 그런 경향이 매우 짙게 나타납니다. 모르는 것도 전에 알던 지식을 이용해서 논리적으로 엮어서 아는 척하는 합니다. ㅡㅡ;;;) 정보기술분야는 너무나도 빨리 발전하고 있습니다. 거의 대부분의 사람이 따라가기 바쁘지요. 물론 필자도 따라가기가 너무 힘듭니다. 그래서 매일 꾀죄죄한 모습으로 학교에서 중국음식에 길들여지면서 고생하는 이유일지도 모르겠습니다. 다음 그림을

 

여러분은 마음을 열고 다른 사람의 것을 받아들일 수 있어야합니다. 너무나도 빨리 발전하고 있는 기술을 따라가는데 가장 빠른 지름길은 사람과 사람이 나누는 Communication 일것입니다.

 

</쉬어가기>

 

16.5 보이스/코드 정규화

 

3차 정규화도 여러가지 이상이 존재합니다. 그렇다면 이상이 발생하지 않는 정규화 과정은 어떤거냐고 의문을 가지는 분도 있을 겁니다. 이상이 발생하지 않는 정규화는 키/도메인 정규화입니다. 이것은 증명은 되었으나, 키/도메인 정규화 테이블을 만드는 구체적인 방법을 발견하지 못했기 때문에 실무에서 직관적으로 사용되는 방법이기도 합니다. 그러나  보통 실무에서는 3차 정규화과정이나 다음에 할 보이스/코드 정규화까지 합니다. 그 이유는 일반적으로 4차 정규화나 5차 정규화 과정을 거쳐야 하는 상황은 거의 발생하지 않기 때문입니다. 이 책에서는 보이스/코드 정규화 과정까지만 언급하겠습니다. 만약 보이스/코드 정규화 과정을 거쳤으나 사용자가 원하는 작업을 수행할 때 이상이 발생한다면 4차 정규화 과정을 거쳐야 할 것입니다. 4차, 5차 정규화는 다른 책을 참고하셔야 할 것입니다.

 

이제 위의 3차 정규화를 거친 테이블에 대한 이상현상이 발생하는 원인을 분석하고 보이스/코드 정규화에 대해서 언급하도록 하겠습니다.

 

3차 정규화 과정을 거치 테이블에서 이상현상을 발생시키는 원인은 후보키들이 중첩되어 있다는 것 때문입니다. 후보키는 기본키가 될 수 있는 자격이 있는 속성 또는 속성들입니다. 즉, 하나의 릴레이션에 여러 개의 후보키가 존재하는데 하나 또는 여러 개의 속성이 중첩되어서 후보키될 때 이상현상이 발생할 수 있다는 것입니다. 보이스/코드 정규화 과정은 바로 이러한 문제점을 해결하는 것입니다. 이러한 의미에서 볼 때 보이스/코드 정규형은 엄격한 3차 정규형이라고도 합니다.

 

보이스/코드 정규형은 릴레이션의 모든 결정자가 후보키이면 보이스/코드 정규형이라고 보는 것입니다. 결정자라는 개념은 어떤 속성을 함수적으로 완전히 종속시키는 속성을 의미합니다. 만약 다음의 업무 규칙이 존재하는 테이블이 있다고 가정 한다면

 

<박스>

 

-. 하나의 과목을 여러 교수가 담당할 수 있다.

-. 각 교수는 하나의 과목만을 담당한다.

-. 각각의 학생은 같은 과목명을 가진 다른 과목을 수강하지 못한다.

 

</박스>

 

<그림 4_84.jpg>

 

앞서서 언급한 3차 정규화의 문제점인 후보키의 일부가 되는 속성인 “학번”이 중첩되어 있는 것이 보입니다. 즉, 수강_교수 릴레이션의 후보키는 “학번 + 과목명” , “학번 + 담당교수” 입니다. 이 후보키중 “학번 + 과목명”을 기본키라고 가정하겠습니다. 함수 종속 다이어그램에서 보는 바와 같이 “학번 + 과목명”은 “담당교수”를 결정하고, “담당교수”는 “과목명”을 결정합니다. 이런 구조를 가지고 있는 릴레이션의 문제점을 파악해 보도록 하겠습니다.

 

<박스>

삽입이상:

만약 이현태 교수도 자료구조를 담당하게 되었다면 수강신청을 한 학생이 있어야만 이와 같은 사실을 입력할 수 있습니다. 만약 “담당교수”의 의마가 해당 과목을 담당하고, 또한 그 학생에 대한 생활지도 등의 “지도”를 할 수 있다면(여기서는 담당과목을 수강하지 않은 학생도 지도할 수 있다는 가정), 과목을 수강하지 않은 학생은 지도교수가 누구인지 결정을 할 수 없게 됩니다.

 

삭제이상:

학번이 “9655032” 인 학생이 자료구조의 수강 취소를 한다면 오용선 교수가 자료구조를 담당하고 있다는 사실도 함께 삭제됩니다. 이 뿐만 아니라 다른 과목들도 마찬가지로 수강하는 학생이 수강을 취소한다면 과목에 대한 담당교수도 같이 삭제되므로 이상현상이 일어납니다. 만약 다른 수강 신청자가 있다면 이와 같은 사실은 같이 삭제되지 않으나 현재 상황으로 볼 때 어떤 교수가 어떤 과목을 담당하고 있는지를 나타내는 것이 한 개의 투플(행)뿐이기 때문에 이러한 문제를 해결되어야 합니다.

 

갱신이상:

만약 이현태 교수가 “DB” 에서 “네트웍 프로그래밍”으로 담당과목이 바뀌었다면 3개의 투플(행)을 모두 변경해주어야 합니다.

 

</박스>

 

이러한 문제점은 보이스/코드 정규화 과정을 거치면 해결되는 문제입니다. 즉, “모든 결정자가 후보키” 가 되게 하면 되는 것입니다. 다음은 보이스/코드 정규화의 결과입니다.

 

<그림 4_85.jpg>

 

이제 여러분은 1차 정규화에서 3차 정규화 까지를 종합적으로 살펴볼 필요가 있습니다. 즉, 이러한 원리만 알고 있다면 바로 3차 정규화 또는 보이스/코드 정규화까지 직접 도출이 가능합니다.  직접 도출하는 예를 들어 보겠습니다. 다음과 같은 스키마가 존재하다고 가정하겠습니다.

 

대출 (대출번호, 고객명, 지점명, 지점위치, 자산, 대출합계)

 

이 스카마는 어떤 은행은 대출에 관련된 스키마입니다. 이 스키마를 가지고 함수적 종속만 파악한다면 나머지 보이스/코드 정규형을 도출하는 과정은 간단합니다. 다음은 이 스키마에 대한 함수적 종속을 나타내는 것입니다.

 

<함수적 종속>

지점명 à 자산

지정명 à 지점위치

대출번호 à 대출합계

대출번호 à 지점명

 

<그림 4_86.jpg>

 

도출한 R1, R2, R3, R4, R5는 모두 보이스/코드 정규형을 만족합니다. 각각의 릴레이션의 모든 결정자가 후보키입니다. 그러나 이렇게 너무 불필요한 정규화는 결과적으로 성능을 떨어뜨릴 수 있습니다. 그러므로 다음과 같은 통합작업을 거쳐야 합니다.

 

결과적으로 R1(지점명, 자산),  R2(지점명, 지점위치),  R3(대출번호, 대출합계),  R4(대출번호, 지점명), R5(대출번호, 고객명)으로 일단은 테이블을 최대한 분해하였습니다. 그러나 R1과 R2는 기본키가 같으므로 통합할 수 있습니다. 그러므로 R1_2 (지점명, 자산, 지점위치) 로 통합되고, R3와 R4, R5가 기본키가 같으나 R3, R4와 R5는 은행(R3, R4)과 고객(R5)으로 서로 다른 것을 나타내므로 R3와 R4는 통합되고, R5는 독립적으로 존재하게 됩니다. 즉, (R3, R4)와 R5는 표현하려는 정보가 틀리기 때문에 통합이 불가능합니다. 마지막에 나온 R5는 원래 정규화되기 전의 원래 테이블의 기본키가 됩니다. 결과적으로 다음과 같이 보이스/코드 정규화가 이루어졌습니다.

 

R1_2 (지점명, 자산, 지점위치)

R3_4 (대출번호, 지점명, 대출합계)

R5 (대출번호, 고객명)

 

결과적으로 정규화라는 과정은 함수적 종속이라는 하나의 원칙으로 관련성으로 속성들을 묶어서 데이터의 중복을 없애고, 데이터의 중복에 의한 여러가지 이상현상을 없애는 유용한 도구입니다. 데이터의 중복이 최소화되는 자체는 시스템이 가장 가벼운 데이터를 가지고 처리하기 때문에 전체적인 시스템의 성능이 높아지기도 하는 것입니다.

 

16.6 키/도메인 정규화

 

'정규화란것은 '함수적 종속'관계를 파악하는 것입니다. 이 종속관계를 파악하여 속성이 원래 갈 자리에 가게 하는 것입니다. 즉, 주제에 맞는 한 객체가 관련된 업무에 관한 속성들이 있어야 할 곳에 있게 하는 것입니다. 우리는 1차 정규화에서 보이스/코드 정규화까지 알아보았습니다. 보통 실무에서는 3차 정규화나 보이스/코드 정규화 때에 따라서는 아주 가끔씩 4차정규화를 행합니다.

 

그러나 검증은 되었으나 그 방법이 찾아지지 않은 키/도메인 정규화를 이 글에서 이야기하고자 합니다. 키(key)라는 것은 객체를 유일하게 구별할 수 있는 속성중에 가장 관련된 대표적인 것을 이야기 합니다. 이 키에 함수적으로 모두 종속되고, 속성의 도메인이 맞다면 즉, 모든 제약이 키와 도메인의 정의에 따른 논리적인 결과인 것은 모두 키/도메인 정규화인 것입니다.

이것은 완벽한 정규화입니다. 3차 정규형은 기본키에 모두 함수적 종속적인 것들로 테이블을 분리하고, 기본키가 아닌 속성들끼리의 종속성 즉, 이행종속을 일으키는 속성들을 다른 테이블로 옮기고 그 테이블에 기본키를 정의할 수 있으면 됩니다. 이와 같이 분리된 테이블은 기본키를 가지게 됩니다. 이러한 개념으로 테이블을 봤을때 데이타가 중복되어 나타나는 것들 잘 살펴보면, 왜 중복이 일어났는지 알수 있을 것입니다.

 

정규화의 해법들이 키/도메인 정규화 빼고는 모두 나와있습니다. 그러나 직관적으로 바라본다면 해법이 나와 있지는 않지만 키/도메인 정규화가 더 쉽습니다. 또한 초기에 엔티티를 선정할때 우리가 시스템화 하고자하는 관련된 것들끼리 모인 즉, 엔티티를 잘 선정한다면 직관적인 관점에서 3차정규화는 충분히 할 수 있으리라 생각합니다.

그렇다고 정규화 과정을 무시해서는 안됩니다. 이렇게 직관적으로 설계를 하면서 나갈때는 정규화는 검증도구가 되는 것입니다. 학자에 따라서 정규화는 검증도구다 또는 튜닝도구다라고 하는 의견들이 분분합니다. 그러나 정규화는 반드시 필요한 것이 틀림이 없습니다.

 

도메인/키 정규화에서 중요한 단어는 제약, 키, 도메인입니다. 한가지 주의할 것은 제약에 시간의 개념을 뺏다는 것입니다. 엑기스만 뽑는다면 키와 도메인에 대한 제약을 준수시켰을때 모든 제약이 준수되는 릴레이션은 키/도메인 정규형입니다.

 

다시 핵심단어 키, 도메인, 제약 이 세가지의 관점에서 살펴보겠습니다. 키라는 것은 객체들을 유일하게 구분지어 주는 속성입니다. 즉, 속성들중 대표하는 것을 말합니다. 이 속성들이 가질수 있는 값들의 범위를 정의한 것이 바로 도메인입니다. 독자들중에 아시는 분이 별로 없으시겠지만 푸리에변환 같은 것을 보면 시간 도메인에서 주파수도메인으로 주파수 도메인에서 시간 도메인으로 변환을 할 수 있습니다. 시간 도메인에서 본다면 이 값들은 절대로 변환과정을 거치지 않고는 시간이라는 단위밖에 가지지 못하는 것입니다. 실제로 주민번호를 본다면 생년월일 담에 오는 1이란 숫자는 남자밖에 가지지 못하는 숫자입니다. 이 도메인을 벗어난다면 현실에 맞지 않게 되는 것입니다. 누누히 얘기하지만 데이타베이스는 현실을 최대한 반영하는 것입니다.

 

정리하자면 키라는 것은 “unique + not null + 대표성” 입니다. 도메인은 앞에서 얘기한 것처럼 속성이 가질수 있는 값의 범위이고 가질수 있는 꼭 그것을 가져야만 하는 의미입니다.

이것은 현실의 제약이라고 볼수 있으며, 이러한 제약이 지켜진다면 이것은 완벽한 이상이 없는 정규형입니다.

16.7 정규화의 정리

 

이제 앞에서 살펴보았던 정규화에 대해서 의미로만 따져도록 하겠습니다. 필자의 경우는 정규화 과정은 검증도구로 사용하는 편입니다. 사실 함수적 종속이란 것이 조직의 범위내에서 통용되는 의미에 따라 틀려집니다. 그러므로 모델링을 하기전 단계에서부터 정보시스템을 구축하려는 조직에서 사용되는 정보의 의미를 파악하는 것이 더 중요하다고 합니다.

 

3차 정규화된 테이블을 보면 테이블마다 어떤 정보들을 나타내기 위해서 데이터 들이 뭉쳐있습니다. 즉, 각각의 속성들이 뭉쳐서 어떠한 하나의 정보(의미)를 만들어 내기 때문에 그 의미만 잘 파악한다면 앞에서 행했던 것처럼 바로 보이스/코드 정규화까지 직접 도출이 가능한 것입니다. 그냥 어떤 “의미”를 나타내기 위해서 그룹짓는 과정이라고 하기엔 너무 애매모호 합니다. 그래서 함수적 종속이란 개념을 도입하여 누구나 고개를 끄덕이게 만든 것이 정규화입니다.

 

독자가 파악해야 할 것은 사용자의 정보가 무엇인지 정확하게 판단하여야 할 것입니다. 만약 사용자의 요구사항이 정확하게 파악되면, 그 요구사항을 정확히 반영하기 위해서 엔티티를 도출하고, 각각의 속성들을 배치해야 합니다. 엔티티는 속성의 집합이기도 합니다. 하나의 엔티티가 다른 엔티티와 관계를 맺고, 어떠한 정보를 만들어 낼 수 있습니다.

 

일반적으로 데이터 모델링은 하향식(Top-Down)의 방식으로 설계를 하고, 정규화를 통한 하향식(Bottom-up) 방식으로 검증을 하는 방법론을 사용합니다. 이제 속성을 가지고 다음 그림을 살펴보도록 하겠습니다.

 

<그림 4_87.jpg>

 

제일 먼저 파악해야 할 것은 “관련성” 입니다. 릴레이션이란 것이 속성들이 어떠한 관련성에 묶여서 있는 모습입니다. 그러니 관련성이라는 의미는 매우 중요한 것입니다. 이것은 기본키와의 관련성입니다. 하나의 개체( 학생으로 하였을 경우 학번이 9555023인 학생 하나는 인스턴스입니다.)를 대표하는 것이 기본키이기 때문입니다.

 

두번째는 파악해야 할 것은 속성의 도메인입니다. 각각의 속성은 가질 수 있는 값의 범위 즉, 도메인을 가지고 있습니다. 이 도메인에서 표현할 수 있는 속성값들을 대표할 수 있는 것들을 찾는 것입니다. 이 도메인도 관련된 엔티티의 범위를 가지기 때문에 관련성이라는 것은 매우 중요합니다.

 

의미상으로 볼 때 학번과 학생명이 같은 객체의 다른 표현인 것을 알 수 있습니다. 그러나 한 학년에 속하는 학생이 여러명인 것을 알 수 있지만, 학년자체는 독립적으로 존재할 수 있는 즉, 엔티티가 아니라 속성이라는 것입니다. 결과적으로 이 릴레이션은 “학생” 엔티티 집합이 포함된 것입니다. 

 

이러한 방식으로 속성값을 살펴보면 위의 그림이 나올 수 있습니다. 그림에서 학과명과 관련된 것을 살펴보면, 일단 학번이 이름과 학년을 결정하는 것은 앞에서 체크었으므로 이 두 속성은 제외하고 학번으로만 생각해보도록 하겠습니다. 학번이 학과명을 결정하나요? 이 부분은 상당한 혼돈의 여지가 있습니다. 그러나 좀더 원천적으로 생각하면 데이터베이스 시스템을 개발하려는 도메인이 무엇인가요? 바로 “학교”입니다. 즉, 학교에는 기본적으로 “학생”과 “학과”가 존재해야 “학교”가 존재할 수 있는 것입니다. 즉, 학과와 학생은 기본엔티티 집합인 것입니다. 이렇게 “닭이 먼저냐? 달걀이 먼저냐?” 라고 따지는 상황이 온다면 이것은 기본엔티티 집합입니다. 그러므로 학과명은 “학과” 엔티티 집합의 속성입니다. 그러므로 이것은 외부키인 것입니다. 그렇다면 다른 속성은 어떨까요? 당연히 다른 속성들도 따져볼 것이 못되는 것입니다. 만약 관련이 있다면 그것은 외부키로 의 기능을 하는 속성입니다.

 

결과적으로 이 테이블에서 도출할 수 있는 엔티티 집합은 “학생”, “수강(또는 과목)”, “학과”, “교수” 입니다. “학생” 과 “수강” 은 다:다의 관계를 맺고 있으므로 “수강코드, 학번, 등급” 은 이 다:다의 관계를 해소한 것이 되는 것입니다.

 

이렇게 엔티티와 속성과 관계를 도춣하는 것은 데이터 모델리의 핵심입니다. 이와 같은 기본적인 것만 확실히 파악이 된다면 정규화는 데이터 모델링의 검증의 도구와 튜닝의 도구로 써 훌륭한 역할을 할 것입니다.

 

17. 데이타 모델의 통합

 

우리는 앞에서 데이터 모델의 통합에 대한 것도 간단히 살펴보았습니다. 앞에서는 단지 직관적인 방법에 의한 데이터 모델의 통합을 하였습니다. 그것도 일부분이지요. 이제 데이터 모델의 통합이라는 것을 좀더 자세히 살펴보도록 하겠습니다.

 

데이터베이스는 다수의 사용자가 공용하는 것입니다. 여기서 “사용자의 공용” 이라는 것은 모든 사용자의 관점에서 통합된 데이터 모델이 필요하다는 뜻입니다. 이것은 VIEW의 통합을 의미합니다.

 

앞서서 학교에서 필자를 바라보는 관점과 자동차 판매 영업사원이 필자를 바라보는 관점을 틀리다고 했습니다. 이것은 도메인이 틀린 상황에서의 관점이였습니다. 시스템을 구축하는 것은 하나의 전체 도메인을 가집니다. 그 도메인 내에서 사용자는 또한 각각의 다른 관점과 개념을 가지고 있습니다. 이렇듯 각 사용자마다 관점이 틀리므로 데이터 모델은 같은 엔티티의 다른 표현이 나올 수 있습니다.

 

엔티티의 다른 표현은 사용자로부터 반드시 확인이 필요하며, 여기서 “확인” 과정에서는 각각의 사용자간의 합의에 의한 통합적인 개념이 필요합니다.

 

데이터모델을 통합할 때는 다음과 같은 항목에 주목하고 통합에 임해야 합니다.

 

<박스> 데이터 모델 통합의 착안점

-. 공통으로 갖고 있는 엔티티와 관계는 어떤 것인가?

-. 각 엔티티, 속성, 업무규칙(운영규칙)은 어떤 유사성이 있는가?

-. 이제까지 문서화하고 자료사전에 기록한 표현중 모순과 불일치되는 것이 있는가?

-. 빠뜨린 운영규칙이 있는가?

</박스>

 

이러한 생각을 가지고 데이터 모델의 통합작업이 이루어져야 하며, 다음 그림은 아주 일반적인 사용자 뷰의 통합과정을 나타냅니다.

 

<그림 4_88.jpg> 데이터 모델의 통합 과정

 

데이터 모델의 통합과정은 하나의 관점에서 고려한 데이터 모델이 아니라 통합된 관점에서의 데이터 모델을 만드는 과정입니다. 이렇게 여러 사용자의 관점이 통합되기 때문에 데이터 모델의 통합과정에서 많은 문제점이 있을 수 있습니다. 즉, 통합의 대상이 되는 후보 엔티티 집합끼리의 도메인과 업무 규칙이 서로 맞지 않는다면 최대한 현실을 반영한다는 데이터베이스의 정의에 점점 멀어지게 되는 수가 있습니다. 또한 데이터가 한곳에 집중되게 되어서 시스템의 성능이 저하되는 경우도 발생할 수 있습니다.

 

데이터베이스는 현실에 존재하는 규칙만 제대로 반영해서는 질 좋은 정보를 산출해 낼 수 없습니다. 즉, 성능이 뒷받침되어야 한다는 뜻입니다. 물론 데이터베이스 뿐만 아니라 컴퓨터로 적용하는 모든 것은 궁극적으로 성능은 높이고 비용은 낮추는 것입니다. 물론 정보의 정확성, 관련성, 일관성이 보장되어야 한다는 것은 기본사항입니다.

 

데이터베이스의 장점중 가장 높이 평가되는 장점은 현실이 변화함에 크게 영향을 받지 않는다는 것입니다. 이러한 장점이 데이터베이스를 다른 데이터 처리 방식에 비해 높이 평가하는 부분인데 데이터 모델의 통합은 업무의 확장이나 변화에 대처하지 못하는 상황이 발생할 수 있습니다. 이럴 때는 다시 구현된 데이터베이스 시스템의 구조를 변경해야하고, 변경이 불가능한 상황이라면 복잡한 어플리케이션 로직이 필요하게 될 수 있습니다. 그러므로 데이터 모델의 통합과정은 데이터의 중복을 줄이고, 정보의 질이 떨어지는 것과 미래에 예상되는 변화를 고려해서 이루어져야 합니다.

 

동일한 기본키를 가진 엔티티는 일단 엔티티의 다른 표현이라고 의심해봐야 합니다. 여기서 동일하다는 의미는 기본키가 나타내는 의미가 같고, 논리적으로 동등한 도메인을 가졌다는 것입니다. 예를 들어 두 엔티티의 기본키가 년도라고 하면, 어떤 엔티티는 1976, 1977, 1978 의 식으로 되어 있고, 또 다른 엔티티는 76, 77, 78 의 식으로 되어 있다면 이것은 형식은 틀리지만 의미와 논리적인 범위는 같은 도메인을 나타내는 것입니다. 이렇게 기본키의 의미가 같고, 논리적으로 동등한 도메인을 가진 엔티티들이 존재한다면 이것을 통합의 대상이 되는 것입니다.

 

그러면 어떠한 점에서 기본키의 의미와 논리적으로 동등한 도메인을 가지고 있다는 것을 따져야 할까요? 이것은 기본키의 정의에서 출발합니다. 기본키는 각각의 개체를 구별하고, 대표할 수 있는 속성 또는 속성들을 의미합니다. 기본키는 기본적으로 “UNIQUE + NOT NULL + 대표성”의 3박자를 갖춰야 합니다.

 

먼저 직관적으로 따져보도록 하겠습니다. 다음은 한 도서관리 시스템에 대한 ERD입니다. 이것은 한 기업내에 존재하고 있는 도서관을 대상으로 한 것입니다. 기업 외부까지 개방해 놓은 도서관이 아니고, 단지 기업내의 범위에서만 운영하는 도서관에 대한 ERD 입니다.

 

<그림 4_89.jpg> 도서관리 시스템의 예(일부)

 

이것은 “1:1 관계의 고려” 단원에서 언급했었던 적이 있는 것입니다. 여기서 살펴보아야 할 것은 “직원” 과 “대출자” 입니다. 위에서 설명한 바와 같이 전체 도메인은 회사내입니다. 회사내에 도서를 대출하는 사람을 누굴까요? 당연히 “직원” 입니다. 그렇다면 “대출자”가 엔티티일까요? 아닙니다. 대출자는 “대출 + 자” 입니다. 즉, “자”는 “직원”이 되는 것입니다. 그러므로 “직원”과 “대출자”는 동일한 개체의 다른 표현입니다. 그러므로 이것은 통합의 대상이 되는 것입니다.

 

이제는 기본키가 되는 속성의 논리적인 범위를 따져서 데이터 모델을 통합해 보도록 하겠습니다. 다음의 그림에서 “고객” 과 “회원”은 통합됩니다.

<그림 4_90.jpg> 기본키와 도메인이 동등한 엔티티의 통합

 

여기서 주의해야할 사항은 두 엔티티 집합간의 데이터 양이 차이가 나느냐입니다. 만약 두 엔티티 집합간의 데이터양이 차이가 난다면 이유를 명확히 밝혀야 할 것입니다. 명확한 이유가 밝혀지면, 다른 시스템의 요소에 미치는 영향을 고려하고, 제대로 현실을 반영하는지 등의 전체적인 입장을 고려하여 통합작업이 이루어져야 합니다. 통합된 엔티티 집합의 이름은 조직내에서 더 의미있는 것으로 또는 두 엔티티 집합간에 전체집합이 되는 것을 엔티티 집합의 이름으로 지어줍니다.

 

앞에서 살펴본 일반화 과정도 이러한 관점으로 보면 통합과정이라고 볼 수 있습니다. 또한 세분화 과정도 마찬가지 입니다. 만약 “휴학생” 이라는 엔티티 집합과 “재학생” 이라는 엔티티 집합을 다음과 같이 일반화하였다면 결과적으로 3개의 테이블로 나누어지니 성능과 정보취득이 더 불리하지 않느냐라는 생각을 가지시는 분도 계실겁니다. 그러나 이는 잘못된 생각입니다. 나중에 질의문 작성시 조인을 해야하지만 이것은 문제가 되지 않습니다.

 

재학생이 7000명이고 휴학생이 3000명이라고 가정해 봅시다. 특정한 한명의 학생이 재학중인가 휴학중인가를 알아보고자 하는데 10000명 중에 그 한명의 학생을 찾는 것이 유리할까요 아니면 3000명 중에 그 학생을 찾는 것이 빠를까요? 당연히 3000명 중에 한명을 찾는 것이 훨씬 유리하겠지요. 그러므로 테이블이 많이 쪼개진다고 해서 무조건 불리해지는 것이 아니라는 것을 염두해 두시기 바랍니다.

 

이렇게 동등한 도메인을 가진 기본키를 기준으로 통합을 할 때를 좀더 생각해 보도록 하겠습니다. 우리가 기본키를 정할 때 어떠한 과정을 거쳐 최종적으로 기본키를 선정하였나를 생각해 봅시다. 기본키를 선정하기 전에는 후보키가 선정되어야 합니다. 즉, 기본키도 하나의 후보키였다는 것입니다. 만일 두 엔티티의 후보키가 동등한 도메인에 있다면 이것은 통합의 대상이 되는 것입니다. 이러한 조건으로 엔티티의 통합작업이 이루어졌다면 후보키가 가지고 있던 운영규칙도 그대로 유지되어야 합니다. 물론 통합된 후보키중 하나는 없어져야 하겠지요.

 

관계의 통합작업에 대해서는 앞서서 업급한 단원이 있으므로 여기서는 통합작업에 대한 고려사항만 업급하도록 하겠습니다.

 

통합작업이 이루어지면 간혹 관계의 카디날리티가 변경되는 경우도 있습니다. 다른 것은 문제가 안돼나 앞서서 언급한 다:다의 관계가 문제가 됩니다. 이러한 다:다의 관계는 앞의 단원에서 언급한데로 두개의 1:다 관계로 만들어 줘야 합니다. 또한 관계의 의미가 서로 다른 경우는 관계의 의미를 모두 표기해 주어서 현실을 모두 표현할 수 있어야 합니다. 또한 중복된 관계가 있는지를 살펴보고 이를 제거해주어야 합니다.

 

엔티티 집합의 통합작업에서 주의해야 할 것은 통합작업이 이루어지고 나서도 통합작업이 이루어지기 전의 의미를 가지고 있으며, 또한 무결성에 영향을 미치는가를 세심히 관찰하여야 합니다. 만약 이와 같은 것이 변경이 되었다면 무엇인가가 문제점이 있는 통합작업이라고 볼 수 있습니다.

18. 이력 관리

 

정보시스템을 구축하는 것은 반드시 개발범위가 정해집니다. 그 개발범위는 그 조직안에서의 통용되는 개념입니다. 기업은 항상 시간에 따라 변화합니다. 그러나 데이터 모델링 작업은 정적인 성질을 가지고 있습니다. 즉, 하나의 시점을 두고서 모델링을 하는 것입니다. 이것은 데이터베이스의 큰 약점이기ㄴ도 합니다. 그러나 시간에 대해서 정적이지만 시간에 대해서 사건을 표시할 수는 있습니다.

 

동전을 던져서 앞이 나올 확률은 얼마인가요? 당연히 1/2 입니다. 그러나 현실에서 동전을 100번 던졌을 때 앞면이 정확히 50번 나올까요? 그것은 매우 힘든 일입니다. 1/2이라는 확률은 동전을 무한이 던졌다고 생각할 때 비로소 앞면이 나올 확률이 1/2이 되는 것입니다. 여기서 무한이 동전을 던졌다는 것은 하나의 선을 의미하고 동전을 한번 던지 사건은 선에 무한한 점들중에 하나를 의미합니다.

 

데이터 모델링을 할 때 어떠한 관리의 대상이 되는 것은 분명히 시작을 언제 했는가를 알 수는 있습니다. 보통은 1년단위 5년단위등의 끝을 알 수 있는 것들과 기업이 언젠가는 끝날 진행중인 사업이 있을 것입니다. 만약 1년에서 5년 사이에 하나의 상품에 대한 매출에 대해서 그래프를 그린다고 생각해 보겠습니다. 여러분이라면 어떻게 그릴 것인가요? 당연히 분기단위 또는 월단위 더 자세히는 일단위로 그리겠지요.

 

데이터베이스이 이력 관리는 이러한 개념을 토대로 합니다. 즉, 점과 선분의 원리를 이용하는 것입니다. 사건은 전체집합에서 하나의 원소일 뿐입니다. 그 사건이 일어난 시기와 끝을 알 수 있다면 시간에 따라 관리하려는 대상이 어떻게 변했는지를 알 수 있습니다.

 

<그림 4_91.jpg> 점, 선을 이용한 이력관리

 

<참고>사건에 대해서

하나의 정의된 시행으로부터 나타낼 수 있는 모든 결과의 집합을 그 시행의 표본공간(Sample Space)라고 한다. 따라서 각 시행의 결과는 표본공간의 원소가 된다. 표본공간의 부분집합을 사건(Event)라고 한다. 집합론에서 말하는 부분집합의 정의에 딸, 사건은 하나의 원소로 표현되는 결과(outcome)와 공사건(empty event) 및 전체 사건(certain event)까지를 포함한다. 시행의 결과는 표본공간의 점으로 표시되는데 이것을 Sample Point라고 한다.

(진영사, 정보공학, 강창언, 오용선, 강민구 저)

 

</참고>

 

여러분들은 웹에서 한달 동안의 날짜별, 월별, 년별 접속자수가 나오는 것을 보았을 것입니다. 이러한 것은 고정적인 단위로 나눌 수 있기 때문에 접속날짜와 시간만 알 수 있다면 가능한 통계입니다. 그러나 언제 동시접속자가 1000명을 넘었는지를 알고 싶다면 접속날짜와 시간만 가지고는 모를 것입니다. 이러한 것은 위의 그림과 같은 원리를 적용해야만 가능한 것입니다. 즉, 이렇게 불규칙한 사건에 대해서 이력관리를 하는 것은 사건의 시작과 종료만 알 수 있다면 간단히 해결되는 문제입니다. 기업에서 사건의 시작이란 업무의 시작을 의미합니다. 이와 같은 방법들은 역시 상황에 맞게 선택해서 사용해야 할 것입니다.

 

그렇다면 이력관리가 왜 필요할까요? 이것은 우리가 역사를 배우는 것과 동일한 의미를 가집니다. 역사를 왜 배울까요? 역사를 배우는 이유는 잘못된 혹은 올바른 역사가 미래와 또는 현재를 더 좋게 가꾸어 줄 수 있는본보기가 되기 때문입니다. 그 나라의 역사는 그 나라를 지켜주는 재산입니다. 기업도 마찬가지입니다.

 

통계에 의하면 캔맥주가 가장 잘 팔리는 진열의 배치가 아기의 분유 옆에 진열해 놓는 것이랍니다. 이것은 아기의 분유를 사러온 아빠들이 분유를 사러 왔다가 분유 옆에 진열된 맥주를 보고 같이 사가는 효과를 본 것이라고 합니다. 이런 것을 어떻게 알았을까요? 일정기간동안 물건의 배치를 계속 바꾸어보고(업무 시작) 일정 기간의 매출통계를 냅니다.(업무 종료) 다시 배치를 바꾸는(업무 시작) 방식을 사용해서 소비패턴을 알아내고 더 많은 매출을 올리는 것입니다.

 

이것이 바로 이력관리의 필요성입니다. 이와 같은 정보는 기업이나 조직의 경쟁력 있는 무기로 작용합니다.

 

<요약>

4장에서는 데이터 모델링의 정의와 데이터 모델링을 하기 위한 도구 ERD에 대해서 알아보았습니다. 데이터 모델링은 데이터베이스를 구축하기 위해서 한정된 범위내의 개념을 특정한 도구(ERD)를 사용하여 개념적이고 논리적인 표현을 한 것입니다.

 

ERD를 그리기 위한 툴의 사용법을 익혔으며, 여러가지 상황에서 현실을 정확히 표현하기 위한 방법을 살펴보았고, ERD의 검증 및 튜닝도구인 정규화에 대해서 살펴보았습니다. 이렇게 정규화된 테이블에서 여러 사용자의 관점에서 표현된 데이터 모델의 통합에 대한 개념을 알아 보았고, 마지막으로 이력관리에 대해서 알아보았습니다.

 

이렇게 설계된 데이터 모델은 정보시스템의 뼈대가 될 것입니다. 정보시스템의 뼈대가 부실하다면 정보시스템의 수명은 당연히 짧을 수 밖에 없습니다. 여러분은 이제 현실을 바라볼 때 데이터베이스의 관점에서 바라보아야 할 것입니다.

 

우선 자신의 근처에 있는 작은 조직을 대상으로 데이터 모델링을 해보도록 하세요. 학생이라면 자신이 속한 과나 학부를 대상으로 데이터 모델링을 해보고, 여러 사람과 토의해보는 것도 상당히 좋습니다. 데이터 모델링은 많이 해보면 해볼수록 좋습니다.

 

데이터 모델링은 모델러의 주관적인 관점이 데이터 모델에 표현될 수 있습니다. 여기서 말하는 주관적인 관점은 자신만의 생각이 아닙니다. 자신이 가지고 있는 그 개념을 명확히 제시를 한 것입니다. 즉, 그럴만한 충분한 이유가 있어야 한다는 뜻입니다. 여러분은 자신만이 보이는 것을 토대로 모델링을 하지 말아야 합니다. 누가 보아도 고개를 끄덕끄덕할 만큼 객관적인 근거에 의한 모델링을 하여야 할 것입니다.

 

</요약>