데이터 모델 목적

데이터 모델은 데이터베이스 설계에 대한 계획 또는 청사진이다. 설계자와 개발자, 사용자 등 모든 관련자들은 데이터 모델을 통해 구축될 시스템의 데이터 구조에 대한 형상을 이해하고, 요구 사항의 구현과 변경 등에 대해 원활한 의사소통을 도모하게 된다. 예를 들어, 건물을 지을 때 건축설계 회사는 건물 공사 이전에 그 건물을 위한 계획이나 청사진을 작성하게 되는데, 만일 계획 단계에서 어떤 방이 너무 좁거나 불편한 곳이 있다면 단순히 설계 도면의 선을 다시 그림으로써 청사진이 변경될 수 있지만 건물이 완공된 후에 변경이 필요하게 되면 벽, 상하수도, 전기 등 모든 것을 다시 시공해야만 하기 때문에 비용이나 시간 측면에서 많은 손해를 보게 될 것이다. 이와 같이 완공된 건물을 변경하는 것보다는 계획 단계에서의 변경이 훨씬 쉽고 간결하며 비용 면에서도 저렴하기 때문에 설계자는 시공에 앞서 조감도, 평면도, 입체도 등 다양한 논리 도면을 통해 건물주(사용자)가 건물의 논리적인 형태를 쉽게 이해하고 의견을 제시하거나 확정을 할 수 있도록 유도한다. 이때 사용된 도면들은 설계자와 시공자, 건물주 등이 짓고자 하는 건물에 대해 동일한 논리적 모습을 공유하게 함으로써 원활한 의사소통의 수단이 되었다고 할 수 있다.

이러한 논리는 건축 공사뿐만 아니라 시스템 개발도 동일하게 적용될 수 있다. 데이터 모델링 단계에서 업무를 잘못 이해했거나 관계를 잘못 정의한 것이 발견되었다면 해당하는 다이어그램과 일부 관련된 문서만 변경하면 된다. 그러나 데이터베이스와 응용 프로그램 개발이 완료된 후 이러한 오류를 발견하여 수정하려면 이와 관련된 많은 프로그램과 SQL문이 변경되어야 할 뿐만 아니라 데이터가 새로운 구조로 옮겨져야 하는 등 이러한 변경을 반영하는 데 많은 비용과 시간이 필요하게 되기 때문에 가능하면 설계 단계에서 조기에 오류들이 발견되고 정정되도록 원활한 의사소통이 필요하게 되고, 이러한 목적을 달성하는 데 데이터 모델은 최적의 수단으로 활용될 수 있다.

개체-관계 모델 기법(Entity-Relationship Modeling)

개체-관계 모델은 1976년에 피터 첸(Peter Chen)에 의해서 최초로 제안되었으며 그의 논문을 통 해 이 모델의 기본적인 구성 요소가 정립되었다. 그 후 데이터 모델을 만들어 주는 많은 도구와 기법 이 소개되었는데 계층적 데이터 모델, 네트워크 데이터 모델, ANSI/SPARC 데이터 모델, 개체-관 계 데이터 모델, 의미 객체 모델 등을 예로 들 수 있다. 이 가운데에서 개체-관계 모델은 표준적인 데이터 모델로 부상했는데 이 모델이 지니고 있는 단순성 때문에 현재 개념/논리 데이터 모델링에서 가장 일반적으로 사용되고 있다. 이 모델에 서브타입이 추가되면서 확장된 개체-관계 모델 (Extended Entity-Relationship model)이 만들어졌으며 이제 일반적으로 개체-관계 모델이라고 하면 이 확장된 개체-관계 모델을 의미한다.

개체-관계 모델은 다음과 같은 목적으로 사용되고 있다.

• 데이터에 대해 관리자, 사용자, 개발자들이 서로 다르게 인식하고 있는 뷰들을 하나로 통합할 수 있는 단일화된 설계안을 만들 수 있다.
• 서로 다른 뷰를 충족시킬 수 있는 데이터 처리와 제약 조건 등의 요구 사항을 정의하기 위해서 이다.
  개체-관계 모델은 개체-관계 다이어그램(ERD, Entity Relationship Diagram)으로 표현된다.
  개체-관계 다이어그램은 최종 사용자의 관점에서 데이터 구조를 그림 형태로 묘사하기 위해 개체, 관계, 속성이라는 세 개의 기본 요소를 사용하며, 엔터티와 이들간의 관계를 미리 약속된 도형을 사 용하여 알기 쉽고 일목요연하게 그림으로 표시한 것이라 정의할 수 있다.

본 절에서는 이들 각 요소들을 구체적으로 살펴본다.

개체-관계 모델 구성 요소

개체-관계 데이터 모델링은 일반적으로 개발 방법론에 의하여 논리 모델링(논리 데이터 모델링)과 물리 모델링(물리 데이터 모델링)으로 나눌 수 있을 것이다. 논리 데이터 모델이란 각 기업에서 업무를 수행하기 위해 필요한 개체(엔터티)가 무엇이며, 개체의 유일성을 보장해주는 식별자(Unique identifier)가 무엇이며, 각 엔터티 간에는 어떤 상관관계가 있고 필요한 속성이 무엇인지를 설명해주는 그림이다. 즉, 업무 담당자와 IT 시스템 설계자 사이의 의사소통이라 할 수 있다. 여기에서 중요한 것은 논리 데이터 모델링은 데이터베이스나 하드웨어 등과 같은 시스템과 아무런 상관없이 업무에서 필요한 데이터를 그림으로 그려놓고 이를 검증하는 방법으로, 주로 개체-관계 다이어그램을 사용한다는 것이다. 따라서 외래키(FK, Foreign Key), 기본키(PK, Primary Key), 액세스 성능, 분산 시스템 등의 물리적 시스템 환경은 고려하지 않는다. 이 때문에 논리적 모델의 특징은 초기에 엔터티와 엔터티의 관계에서 M:M 관계, 순환 관계(Recursive), 슈퍼/서브 타입(Super/Sub Type), 배타적(Arc) 관계 등을 갖고 있는 개체(엔터티)가 많이 보인다는 점이다. 잘 설계된 논리 데이터 모델은 비록 업무 방식이 바뀌어도 업무 영역이 바뀌지 않는 한 설계 변경이 거의 발생하지 않는다. 이러한 이유 때문에 많은 시스템 설계자는 프로세스 중심의 설계보다 데이터 중심 방식의 설계를 주로 사용한다. 논리 데이터 모델에서 하나의 엔터티는 반드시 물리적으로 하나의 테이블이나 세그먼트가 되지는 않으며, 하나 이상 또는 테이블 한 개의 일부가 될 수도 있다. 물리 데이터 모델링은 논리 데이터 모델링을 기초로 현재의 시스템 환경(네트워크, 하드웨어, 운영체제, 미들웨어, 데이터베이스, 디스크 용량, 분산 등)을 고려하여 최고의 성능 향상을 목적으로 한다.

논리 데이터 모델링에서 물리 데이터 모델링 단계로 넘어오면서 고려해야 하는 작업의 사례는 다음과 같다.

• Super/Sub 관계의 엔터티를 몇 개의 테이블로 만들 것인가
• 배타적(Arc) 관계 엔터티의 외부키(Foreign Key)를 몇 개로 할 것인가
• 성능 향상을 위해 테이블을 추가해야 할 것인가 혹은 통합해야 할 것인가
• 통계 작업을 위해 합계(Summary) 테이블 같은 임시성 테이블을 몇 개로 할 것이며, 유일키를 무 엇으로 할 것인가
• 테이블의 칼럼을 다른 테이블에 중복할 것인가, 중복한다면 어떤 애플리케이션이 관련되어 있는 가, 인덱스의 설정, 스냅샷(Snapshot) 또는 뷰(View) 등의 객체가 필요한가
• 분산 환경에서 테이블을 중복할 것인가, 중앙에 필요한 테이블을 따로 가져갈 것인가
• 데이터가 분산 환경에서 이동 시 문제를 어떻게 해결할 것인가

물리 데이터 모델링 단계에서는 이러한 해결 과제가 산적해 있으며, 이를 종합적으로 해결할 때 전체적인 성능 향상을 기대할 수 있다. 위의 개념은 매우 중요하며 논리 데이터 모델과 물리 데이터 모델의 구분이 반드시 필요하다. 왜냐하면 물리적인 디자인은 시스템의 변경에 따라 필수적으로 변경이 되는 요소지만 논리 데이터 모델은 업무 영역이 바뀌지 않는 이상 변경이 거의 없는 특성이 있기 때문이다. 따라서 하나의 그림으로 모델을 관리하게 되어 변경이 일어날 때마다 유지 보수를 하다 보면 현재의 시스템과 상관없는 것으로 전락하게 되고, 결국은 막대한 비용을 들여 만들었던 개체-관계 다이어그램이 존재 가치를 상실하게 될 수도 있다.

엔터티(Entity)

엔터티는 업무 활동상 지속적인 관심을 가지고 있어야 하는 대상으로서, 그 대상들 간에 동질성을 지닌 것으로 볼 수 있는 개체 집합이나 그들이 행하는 행위의 집합으로 정의할 수 있다. 동질성은 집합을 어떻게 정의하느냐에 따라 달라질 수 있는데, 집합에 들어갈 개체들의 동일한 성질을 어디까지로 한정할 것인지를 결정하는 것으로 동질성 유무를 판단할 수 있다. 예를 들면, ‘고객’이라는 집합을 ‘우리 상품을 구매한 사람이나 법인’으로 정의했다면 아직 구매를 한 적이 없는 잠재 고객이나 구매 상담자, 또 법인번호가 없는 단체나 개인 사업자 등은 이들과 동질성을 갖지 못한다. 그러나 이들이 현재 어떠한 방법으로든 관리가 되고 있거나 앞으로 관심을 갖고자 하는 범주에 해당한다면 집합의 정의를 더 확장해야만 이들을 고객 집합 내에 끌어들일 수 있다. 집합에 대한 정의 문제는 엔터티의 구성 속성과 관계 정의에도 영향을 미치고, 이것은 결과적으로 데이터 모델 전체의 구성에 영향을 미치게 되므로 엔터티, 즉 집합에 대한 명확한 정의는 데이터 모델링에서 가장 핵심적인 사안이라 할 수 있다. 그러므로 엔터티를 정의할 때는 어떤 대상이 그 엔터티에 속하는지 여부를 명확하게 구분할 수 있도록 정의해야 한다.

엄밀한 의미에서 엔터티는 동질성을 갖는 개별 개체나 행위를 지칭하며, 달리 엔터티 인스턴스(Entity Instance) 라고도 한다. 그리고 이들의 집합을 엔터티 타입(Entity Type)이라고 부른다. 동질성을 갖는다는 의미는 어떤 한 개체(엔터티 인스턴스)를 설명하거나 묘사할 수 있는 특성들(예컨대, 학번, 이름, 학과 등과 같은 항목들)에 대해 다른 여러 개체들이 동일한 특성들로 설명 또는 묘사될 수 있음을 말하며, 이와 같은 개체들의 집합을 엔터티 타입이라고 한다. 예를 들면, 어떤 특정한 학번, 이름, 학과로 특징지어질 수 있는‘홍길동’학생은 엔터티 인스턴스이고, 학번, 이름, 학과 등과 같은 공통적인 특성 항목들을 공유하는 학생들의 집합인 ‘학생’은 엔터티 타입이 된다. 엔터티와 엔터티 타입은 각각‘실체’와‘실체형’으로 번역되어 사용되기도 하나, 일반적으로 엔터티와 엔터티 타입으로 사용하기로 하며, 통상적으로 많은 책들과 실무상에서 엔터티와 엔터티 타입은 엄격하게 구분하지 않고 엔터티로 줄여서 사용하고 있기 때문에, 본 과목에서는 개체나 행위의 집합을 엔터티로 통칭할 것이다.

엔터티는 그 집합에 속하는 개체들의 특성을 설명할 수 있는 속성(Attribute)을 갖는데, 예를 들어 ‘학생’이라는 개체 집합은 학번, 이름, 이수학점, 등록일자, 생일, 주소, 전화번호, 전공 등의 속성으로 특징지어질 수 있다. 이러한 속성 가운데에는 개체 집합 전체가 공유할 수 있는 공통 속성도 있고, 개체 집합 중 일부에만 해당하는 개별 속성도 있을 수 있다.

개체-관계 다이어그램을 표기하는 방법은 여러 가지가 있는데, 그것들에 대해서는 뒤에서 설명하기로 하고, 여기서는 그 중 한가지만 리차드 바커(Richard Barker)가 제안한 바커 표기법(Barker Notation)과 정보공학표기법(IE Notation)에 따른 표현을 예로 설명한다. 엔터티를 개체-관계 다이어그램으로 나타낼 때는 [그림 4-1-4]와 같은 모양으로 나타내고 이름을 부여할 수 있다. [그림4-1-4]에서 좌측은 바커 표기법을, 우측은 정보공학표기법(이후 IE 표기법이라 지칭)을 적용한 엔터티 모습의 예이다.

속성(Attribute)

속성은 엔터티에 저장되는 개체 집합의 특성을 설명하는 항목이라고 할 수 있다. 엔터티를 명확하고 구체적으로 정의했다 하더라도 이것만으로는 개체 집합의 특성을 설명하기에는 부족함이 있다. 예를 들면, ‘직원’엔터티의 개체인 ‘김철수’와 ‘홍길동’은 독립적인 사람 개체임에는 분명하지만 이들의 특성을 설명할 수 있는 보다 구체적인 항목(속성)이 없으면 이 집합을 명쾌하게 객관화할 수 없다. ‘직원’집합의 특성을 설명하기 위해 직원번호, 직원명, 주민등록번호, 연락전화번호, 거주지, 주소 등과 같은 속성을 정의했다면 이제 이러한 속성 구성을 통해 어떻게 ‘홍길동’이라는 개체를 특징짓고 변별할 것인지를 분명하게 이해할 수 있고, 집합의 의미 또한 좀 더 명확해진다고 할 수 있다. [그림 4-1-5]와 [그림 4-1-6]에서 엔터티의 속성을 표현하는 서로 다른 방법을 보여 주고 있다. [그림 4-1-5]는 엔터티에 연결되는 속성을 타원으로 보여 주고 있다. 이 스타일은 데이터 모델링 소프트웨어 제품이 출현하기 이전에 원래의 개체-관계 모델에서 사용되었다. [그림 4-1-6]은 현재의 데이터 모델링 소프트웨어 제품에서 보편적으로 사용되고 있는 바커 표기법과 IE 표기법의 스타일을 보여 주고 있다.

[그림 4-1-5]의 개체-관계 다이어그램에서 속성은 개체 집합을 나타내는 직사각형에 실선으로 연결된 타원형으로 표현되며, 각 타원형은 고유의 속성 이름을 갖는다. 또한 각 속성은 가질 수 있는 값의 범위가 있는데, 이를 그 속성의 도메인(Domain)이라 한다. 예를 들면 학생이라는 엔터티가 있을때 학점이라는 속성의 도메인은 0.0에서 4.0 사이의 실수 값이며, 주소라는 속성은 길이가 20자리 이내의 문자열로 정의할 수 있다. 여기서 물론 각 속성은 도메인 이외의 값을 갖지 못한다.

일반적으로 서로 다른 개체 집합에 정의된 속성은 같은 도메인을 공유할 수 있다. 예를 들면, 학생 개체 집합에서 주소 속성에 해당하는 도메인과 교수 개체 집합에서의 주소 속성 도메인은 같은 값들의 범위를 가질 수 있다. 개체 집합 내에서 각각의 개체를 식별할 수 있도록 하나 또는 그 이상의 속성들로 이루어진 속성 집합을 식별자(Unique Identifier)라고 하는데, 이 속성들이 개체 집합 내의 각 개체를 유일하게 지정한다. 예를 들면 학번, 성명, 주소, 생년월일, 학과 등의 속성들로 이루어진 학생 엔터티에서 학번 속성은 하나의 식별자가 될 수 있다.

[그림 4-1-7]은 자동차 개체 집합의 속성 구성을 나타낸 것이며, ‘ID_NUM’이라는 속성에 밑줄을 친 것은 식별자를 의미한다. [그림 4-1-6]과 같은 표현에서는 ‘#’표시가 붙은 속성이 식별자이다. 속성은 단순형 혹은 복합형으로 분류할 수 있다. 예를 들면, 주소 속성은 시, 구, 동, 번지 등과 같은 여러 세부 속성들로 구성될 수 있는데, 이를 복합 속성(Composite Attribute)이라 한다. 또한 나이, 성별 등의 속성은 더 이상 다른 속성들로 구성될 수 없는 단순한 속성이므로 단순 속성(Simple Attribute)이라 한다. 속성은 관리 목적이나 상세화 정도에 따라서 단일 값(Single Value) 또는 다중 값(Multi Value)을 가질 수 있다. 주민등록번호와 같은 속성은 반드시 하나의 값만 존재하므로 이 속성은 단일치 속성(Single-Valued Attribute)이라 하고, 어떤 사람 전화번호와 같이 여러 개의 값을 가질 수 있다. 자동차의 색상 속성도 차 지붕, 차체, 외부의 색이 다를 수 있다. 이런 속성을 다중치 속성(Multi-Valued Attribute)이라 한다.

[그림 4-1-7]과 같은 표현에서 다중치 속성은 두 개의 실선으로 표시한다. 개체-관계 모델에서는 복합 속성, 다중치 속성을 정의할 수 있지만, 직접 구현은 불가능할 수도 있다. 이를 위해서는 M:M 관계나 다수의 속성 또는 1:M 관계의 추가 엔터티를 사용하여 수정해 주어야 한다. 만약 다중치 속성이 존재하면 설계자는 아래의 방법 중 하나를 선택하여 해결할 수 있다.

1) 엔터티 내에서 다중치 속성을 여러 개의 새로운 속성으로 나눈다. [그림 4-1-7]에서의‘COLOR’ 속성에 대해 [그림 4-1-8]과 같은 새로운 속성을 만들어 [그림 4-1-7]에서‘CAR’개체형의 속성들로 부착시킨다.

2) 다중치 속성을 구성하는 속성들로 구성된 새로운 엔터티를 만든다. 이때 새로운 엔터티는 원래 엔터티와 M:1 관계를 맺게 한다. [그림 4-1-8]의‘COLOR’속성을 떼어내어 새로운 엔터티로 만들면 새로운 엔터티‘COLOR’는‘CAR’개체형과 M:1 관계가 될 것이다. 속성 중에는 유도 속성 (Derived Attribute)으로 분류될 수 있는 것도 있는데, 이 속성은 다른 속성의 값으로부터 어떤 계산을 통해 새로운 값을 얻게 되므로 집합의 본질이나 특성을 규명하기 위한 속성을 고려할 때 제외할 수도 있다. 예를 들면, 어떤 사람의 나이 속성은 현재 날짜로부터 생년월일 속성의 값을 뺌으로써 나이의 값을 유도할 수 있다. [그림 4-1-9]에서와 같은 표현에서 유도 속성은 점선으로 표시된다.

식별자

엔터티의 각 개체들은 인스턴스라고 하는데, 인스턴스는 그들을 지칭하거나 식별해 주는 속성인 식별자(Unique Identifier)를 가지고 있다. 예를 들어, 직원 인스턴스는 직원번호, 주민번호, 직원명으로 식별될 수 있다. 이들 중 직원명은 실세계에서는 직원 각각을 식별하는 데 이용될 수 있으나 데이터 측면에서는 동명이인의 문제 때문에 식별성이 미약한 편이다. 봉급이나 입사일 같은 속성으로는 각각의 인스턴스를 유일하게 식별할 수 없다. 이와 마찬가지로 고객은 고객번호나 고객이름으로 식별될 수 있고, SALES-ORDER은 OrderNumber(주문번호)에 의해서 구별될 수 있다.

식별자는 하나 또는 그 이상의 속성으로 구성된다. 특히 두 개나 그 이상의 속성으로 이루어진 식별자를 복합 식별자(Composite Identifier)라 부른다. 그 예로는 (Area Code, Local Number), (Project Name, Task Name), (First Name, Last Name, Date Of Hire) 등이 있다. 식별자와 키는 구별하여 사용되어야 하며, 이 둘은 서로 일치할 수도 있고 그렇지 않을 수도 있다. 즉 식별자는 논리적인 관점에서 사용되고 키(Key)는 물리적인 관점에서 사용된다. 따라서 엔터티는 식별자를 가지며, 테이블은 키를 가진다고 할 수 있다. 이러한 이유로서 식별자가 엔터티에 대해 하는 역할은 키가 테이블에 대해 하는 역할과 동일하다.

엔터티는 데이터 모델에서 3단계의 상세 수준으로 표현된다. 때로는 엔터티와 그것이 가지는 속성 모두가 표시되기도 한다. 이 경우 [그림 4-1-10]에 나와 있는 것과 같이 식별자 속성을 표현하기 위해 바커 표기법에서는 #이 식별자 속성 앞에 그려지고, IE 표기법에서는 엔터티 박스 내부의 상단에 식별자 속성을 표시한다. 데이터 모델에서는 모든 속성을 자세히 표현하면 개체-관계 다이어그램을 다루기가 힘들어진다. 이 경우에는 [그림 4-1-11]에서처럼 식별자만 보이거나 [그림 4-1-12]에서처럼 엔터티 박스 안에 엔터티 이름만 간결하게 보일 수도 있다.

데이터 모델링의 초기 단계에서부터 모델을 지나치게 상세히 표현하면 개체-관계 다이어그램을 이해하고 다루기가 힘들어질 수도 있기 때문에 [그림 4-1-11]에서처럼 간단하게 식별자만 보이거나 [그림 4-1-12]에서처럼 직사각형 안에 개체 이름만 간결하게 보임으로써 많은 모델들 중에서 사용자가 필요한 것들을 손쉽게 식별하게 하기도 한다. [그림 4-1-11]과 [그림 4-1-12]에서 위는 바커 표기법을 사용한 엔터티의 약식 표현이며, 아래는 IE 표기법을 사용한 엔터티의 약식 표현이다. 세가지 기법 모두가 실제로 사용되며, [그림 4-1-12]의 더 간결한 형식은 상위 수준의 개요와 전반적인 개체-관계를 보여주는 데 사용된다.

관계(Relationship)

관계는 엔터티와 엔터티 간 연관성을 표현하는 것으로, 엔터티의 정의에 따라 영향을 받기도 하고, 속성 정의 및 관계 정의에 따라서도 다양하게 변할 수 있다. 엔터티 간에 논리적으로 존재할 수 있는 수많은 관계 중에서 정말로 의미가 있고 관리할 가치가 있는 관계를 식별해 낸다는 것이 쉬운 일은 아니다. 최초의 개체-관계 다이어그램에서 관계는 속성을 가질 수 있었으나 현재는 그렇지 않다. 관계의 표현에는 이항 관계(Binary Relationship), 삼항 관계(Ternary Relationship), n항 관계가 존재할 수 있는데, 실제 삼항 관계 이상은 잘 사용되지 않는다. [그림 4-1-13] 참조 매핑 카디날리티(Mapping Cadinality)는 개체-관계 다이어그램에서 개체와 연결될 때 나타나는 대응(Mapping)되는 수로 대응수라고도 한다. 대응수는 최대 대응수(Maximum Cadinality)와 최소 대응수(Minimum Cadinality)로 구분된다. 매핑 카디날리티가 포함된 개체-관계 다이어그램에 대하여 예제를 통해 설명하고자 한다. [그림 4-1-13] 참조

다음과 같은 조건하에서 교수 개체와 학생 개체 간에 성립하는 지도 관계의 매핑 카디날리티를 결 정하고, 개체-관계 다이어그램을 작성하면 [그림 4-1-13]과 같은 이항 관계 구조의 다이어그램을 완성할 수 있다.

■ 조건 1 : 교수는 꼭 학생에 대한 지도를 해야 한다.
<min-card(교수, 지도)="1</p"></min-card(교수,>

■ 조건 2 : 교수는 여러 명의 학생을 지도할 수 있다.
Max-Card(교수, 지도) = n

■ 조건 3 : 학생은 꼭 교수에게 지도를 받아야 한다.
Min-bCard(교수, 지도) = 1

■ 조건 4 : 학생은 여러 명의 교수에게 지도를 받을 수 없다.
Max-Card(교수, 지도) = 1

카디날리티(Cardinality)

개체-관계 다이어그램은 데이터베이스가 지켜야 할 제약 조건들을 명시할 수 있다. 중요한 제약 조건 중의 하나로 연결(Connectivity)이라는 것이 있는데, 이는 한 개체가 관계를 통하여 다른 개체 와 관련된 개체들의 수를 나타낸다. 관계의 연결은 1:1, 1:M, M:M으로 분류된다. 개체-관계 다이어 그램에서는 관계의 연결을 1, M을 사용하여 표현하며 [그림 4-1-14]의 예와 같다. 표기법에 따라서 는 M:M을 M:N으로 표현하기도 하지만 여기서는 M:M으로 나타내기로 한다.

• 일대일(One To One, 1:1) : X에 속하는 한 개체는 Y에 속하는 한 개체에만 연결되며, Y에 속하는 한 개체도 X 에 속하는 한 개체에만 연결된다.
• 일대다(One To Many, 1:M) : X에 속하는 한 개체는 Y에 속하는 한 개체에만 연결되며, Y에 속하는 한 개체는 X에 속하는 여러 개체와 연결된다
• 다대다(Many To Many, M:M) : X에 속하는 한 개체는 Y에 속하는 여러 개체와 연결될 수 있으며, Y에 속하는 한 개체도 X에 속하는 여러 개체와 연결될 수 있다.

또한 카디날리티(Cardinality)란 관계에 참여하는 하나의 개체에 대해 다른 엔터티에서 몇 개의 개체가 참여하는지를 나타낸다. 예를 들면, 한 명의 학생이 1개 이상 6개 이하의 과목에 등록할 수 있다면 카디날리티는 (1, 6)이다. 한 명의 교수가 최대 3개의 과목을 가르칠 수 있다면 카디날리티는 (0, 3)이다. 카디날리티는 (Min, Max)의 값 한 쌍으로 표현하는데, 여기서 Min은 관계에 참여하는 개체의 최소 개수, Max는 관계에 참여하는 최대 개수를 각각 의미한다. 여기서 Max의 값이 M으로 표시되면 최대 개수에 제한이 없음을 의미한다. [그림 4-1-15]에서 PROFESSOR-COURSE의 관계를 살펴보면 다음과 같이 해석할 수 있다.

1) PROFESSOR-COURSE는 1:M 관계이다.

2) PROFESSOR의 카디날리티는 (0, 3) 이다. 즉 각 교수는 3개 이하의 과목을 가르칠 수 있다.

3) COURSE의 카디날리티는 (1, 1)이다. 즉 각 과목을 가르치는 교수는 반드시 1명이어야 한다.

존재 종속

만약 한 엔터티의 존재가 다른 엔터티(들)의 존재에 영향을 받는다면 이를 존재 종속(Existence-Dependent)이라 한다. 예를 들어, 어느 보험회사가 J. H. Callifante라는 사원과 그의 부양 가족들에게 보험 혜택을 준다고 할 때 EMPLOYEE, DEPENDENT라는 엔터티들을 정의한다고 하자. J. H.Callifante에게 Jill, Annelise, Jorge라는 3명의 부양 가족이 있다면 부양 가족 3명은 J. H.Callifante 없이는 보험 혜택을 받을 수 없다. 다시 말해 부양 가족 3명의 정보가 DEPENDENT라는 테이블에 존재하지만 EMPLOYEE와 연관지어 있을 때만 존재하게 된다. 이러한 것을 존재 종속이라 한다. 만약 J. H. Callifante가 직장을 그만 두어 테이블에서 없어지게 되면 부양 가족 3명도 함께 없어지게 된다. 여기서 DEPENDENT의 식별자는 EMPLOYEE의 키인 E_NUM과 DEP_NUM으로 구성된다. 두 개의 테이블들을 연결시켜 보면 J. H. Callifante는 3명의 부양 가족이 있고, W.K. Smithson은 부양 가족이 없음을 알 수 있다.

서브타입

확장된 개체-관계 다이어그램은 서브타입의 개념을 도입했다. 서브타입은 정확한 의미로는 서브 타입 엔터티이며 그것의 전체집합인 슈퍼타입(Supertype)의 부분집합이다. 예를 들어 학생들은 학 부학생이나 대학원생으로 분류될 수 있다. 이 경우 학생이 슈퍼타입이고 학부학생과 대학원생은 서브타입이다.

[그림 4-1-17]은 바커 표기법에 따른 서브타입 표현으로, 슈퍼타입인 사원은 서브타입인 내근사원, 설계사, 대리점을 가지고 있다. 슈퍼타입은 세 서브타입에 공통적인 모든 속성을 포함하고 있고, 서브타입은 각 서브타입에 적절한 속성만을 포함하고 있다. [그림 4-1-17]에서 속성 ‘사원구분’은 내근사원, 설계사, 대리점인지를 가리킨다. 어떤 서브타입이 적합한지를 결정해 주는 속성을 구분자(Discriminator)라고 부른다. IE 표기법을 사용하는 툴을 사용하면 [그림 4-1-18]과 같이 구분자는 서브타입 부호 바로 옆에 나타난다.

모든 슈퍼타입이 구분자를 가지고 있는 것은 아니다. 만일 구분자가 없다면 적합한 서브타입을 생성하기 위해 응용 코드가 작성되어야 한다. 서브타입은 배타적(Exclusive) 또는 포괄적(Inclusive)일 수 있다. 만약 배타적이라면 슈퍼타입은 많아야 1개의 서브타입과 관련될 수 있다. 만약 포괄적이라면 슈퍼타입은 1개 또는 그 이상의 서브타입과 관련될 수 있다. [그림 4-1-19]는 IE 표기법에 따라 MANAGER와 DB_ADMIN을 서브타입으로 가진 사원 슈퍼타입의 형태를 표현한 사례이다. 돔 안의 X는 서브타입이 배타적인 것을 의미한다. 따라서 사원은 MANAGER나 DB_ADMIN 중 하나가 될 수는 있으나 둘 다 될 수는 없다. 이에 대한 구분은 서브타입을 의미하는 돔 옆에 서브타입 구분자를 표시하여 이 서브타입 구분자 속성을 통해 사원이 어느 서브타입에 속하는지 알 수 있음을 표현하고 있다. [그림 4-1-20]은 이러한 동일한 서브타입을 포괄적으로 보여주고 있다. 여기서 사원 슈퍼타입은 MANAGER, DB_ADMIN, 또는 양쪽 모두 될 수도 있는 포괄적 서브타입의 형태로 표현되어 있으며, X가 없는 돔 형태를 사용하여 두 개 이상의 서브타입과 관련된 포괄적 서브타입을 표현한다. 여기서 돔 옆에 서브타입 구분자를 나타내지 않음은 특정한 서브타입 구분자 속성을 가지고 있지 않음을 의미한다. 이와 같이 배타적 서브타입이나 포괄적 서브타입을 표현할 때 서브타입 구분자를 지정하지 않고 서브타입을 표현하는 것은 가능하나, 서브타입 구분자를 사용하지 않게 되면 인스턴스가 어느 유형에 해당하는지 알기 위해 주변 속성들을 확인해 보아야 하기 때문에 불가피한 경우가 아니면 효율성 측면에서 바람직하지 않다.

객체지향 모델링(Object-Oriented Modeling)

과거, 소프트웨어 생산성 향상은 상당히 힘든 일로 여겨졌다. 구조적 기법, 방법론, 4세대 언어, 관계형 DBMS, CASE 도구는 시스템 개발상의 문제점을 없애고 비용을 절감하고 소프트웨어 개발의 품질을 향상시키기 위해 시도되었다. 그러나 대부분의 시도는 실패로 끝났다. 최근의 접근 방식 중의 하나가 재사용 코드(Reusable Code)의 개념에 초점을 둔 것이다. 이 개념은 한번 소프트웨어 루틴 (Routine)을 저장해 놓고 그것을 모든 프로그래머들과 공유하는 것을 말하는 것이다. 많은 노력 끝에 방법론과 CASE와 같은 많은 접근 방식들의 결합(Combination)은 재사용 코드에 대한 실제적인 성 과로 생산성의 이익을 가져왔다. 많은 개발자들은 이 새로운 접근 방식이 향후 시스템 개발에 있어 지 배적인 대세가 될 수 있다고 확신하고 있다. 만약 이것이 성공한다면 객체지향 접근 방식은 애플리케이션이 어떻게 개발되어야 하는지를 과감하게 변화시킬 수 있을 것이다. 객체지향 개발은 전체 시스 템 개발 영역을 다루고 있다. 그것의 종류는 아래와 같다.

• 객체지향 방법론
• 객체지향 분석
• 객체지향 설계
• 객체지향 모델링
• 객체지향 프로그래밍
• 객체지향 DBMS

객체지향 개발이 시작된다면 그것은 시스템 개발 생명 주기의 많은 부분(논리적 데이터 모델링을 포함해서)에 영향을 미칠 것이다. 객체지향 모델링의 간단한 개요를 제시하고 그것이 어떻게 논리적 데이터 모델링의 스키마에 적합하게 되는지를 살펴보자.

객체지향 개념

객체지향 모델링은 객체지향 개발의 기본이다. 여기에서 객체지향에 대한 특성과 개념을 발견할 수 있을 것이다. 우선 객체지향의 용어를 검토해 보자. 조직이나 시스템은 객체(Object)라는 것에 관 련되어 있고 객체에 대한 정보를 저장한다. 고객, 직원, 교실, 책, 그리고 전표 등이 객체의 예이다. 객체는 대개 객체를 기술하는 데이터와 그 기술 데이터를 운영하는 메소드(Method)로 구성된다. 속 성 유형과 메소드를 공유하는 객체가 그룹화되어서 객체 클래스(또는 클래스)로 된다. 객체 인스턴스 는 객체 클래스의 어커런스이다. 예를 들어, 직원이 객체 클래스이면‘홍길동’은 클래스 직원의 객체 인스턴스이다.

객체는 속성과 메소드로 구성된다. 속성은 객체클래스의 성질이다. 이름, 주문번호, Color, 그리 고 책제목 등은 속성의 예이다. 속성값이 바로 객체 인스턴스의 성질인 것이다. 메소드는 하나 이상 의 속성을 접근, 조작, 수정, 삭제, 생성하는 프로세스이다. 예를 들어‘신규조직을 추가하라’또는 ‘주문서를 작성하라’등이 그 예이다.

객체는 연관(Association) 또는 상속(Inheritance)을 통해서 다른 객체들에 연결된다. 연관은 객 체 간의 자연적 관계이다. 비??다. 예를 들어, 고객은 제품을 산다. 그래서 고객 객체와 제품 객체 간의 자연적 관계인‘산다’가 있다. 연관은 카디날리티 와 모달러티(선택적 그리고 의무적)를 가질 수 있고 연관은 하나, 둘, 셋 이상 객체들 간에 존재할 수 있다.(즉 일항, 이항 그리고 다항)

반적인 객체(상위클래스)를 가지고 제일 아래 (Hierarchy) 조직을 생각해 보면 하위 클래스는 상위 클래스로부터 속성과 메소드를 상속한다. 예를 들어 도매 고객 객체와 소매 고객 객체는 상위 클래스‘고객’의 하위 클래스이다. 이 하위 클래스는 고객 클래스로부터 모든 속성과 메소드를 상속한다. 게다가 하위 클래스는 하위 클래스 고유의 속성 과 메소드를 가질 수 있으며 다른 객체들에게 상위클래스로 작는 것은 그 객체 외부에서 일어나는 것과는 관계가 없다는 것과 같은 구체적 경계 (Boundary)를 가지고 있다. 이것을 일명 캡슐화(Encapsulation)라고 한다. 예를 들어 고객 객체는 ‘신규 고객을 추가하라’라는 메소드를 가지고 있다. 고객 객체는 그 메소드가 호출될(Invoke) 때 무 엇을 해야 하는지를 정확히 알고 있다. 그러나 제품 객체에 적용될 때에 그 메소드는 의미가 없다.

고객 객체의 속성과 메소드는 다른 객체들로부터 감추어져 있다. 본질적으로 그 객체는 적절한 메 시지가 전달될 때 작업을 수행하는 ‘블랙박스’이다. 그 작업이 무엇이고 그 작업이 어떻게 수행되는 지는 다른 객체에게 알려지지 않는다. 객체는 메시지를 주고 받음으로써 다른 객체와 통신한다. 예를 들어 구매 객체는 고객 객체에게 고객의 신용 상태를 변화시키라는 메시지를 보낼 수 있다. 캡슐화 때문에 구매 객체는 고객 객체가 신용 상태를 어떻게 변화시키는지 알 필요가 없다. 즉, 메시지‘고 객 신용 상태를 변화시켜라’를 받은 결과로써 고객 객체가 사용하거나 수정하려는 메소드와 속성은 구매 객체에게 전달된다. 이러한 정보는 객체 모형에 표시될 수 있다. [그림 4-1-21]과 같이 객체 모형에서 객체는 굵은 선으로 된 상자(Bold-lined Box)로 표시된다. 연관과 상속의 연결은 두꺼운 선으로 나타난다. [그림 4-1-22] 참조

속성이 적거나 별도 문서에 있다면 속성은 [그림 4-1-23]과 같이 객체 상자 안에 기입될 수도 있다. 객체 안의 속성이 속성 자신의 구조를 가질 수 있다면 그 객체는 자기 자신의 논리적 데이터 모델을 가질 수 있다. [그림 4-1-24] 참조

대부분의 객체 메소드는 메소드를 기술하는 서술(Narrative)에 의해서 표현될 수 있다. 그러나 메소드가 복잡하다면, 데이터 흐름 다이어그램(DFD, Data Flow Diagram)과 같은 다양한 프로세스 모델링 기법 중의 하나가 사용될 수 있다. [그림 4-1-25] 참조

메시지는 메시지 이동의 방향을 나타내는 화살표와 점선에 의해 객체 모형에 표현된다. [그림 4-1-26] 참조

객체 모형

객체 모형을 생성시키기 위해서 아래와 같은 방법을 취한다.

1) 주제에 연관된 기본(Basic) 객체를 식별한다. 그 결과는 엔터티 목록과 같은 것이다.

2) 객체 간의 연관(Association)을 식별한다.

3) 많이 알려져 있는 객체 모델링의 규약을 이용해서 객체의 다이어그램을 그린다.

4) 객체 간의 메시지는 다이어그램에 추가될 수 있다.

?

객체 모형이 완료되었을 때, 각 객체 내부에 대해서 표시하면 된다. 즉, 객체의 속성과 메소드가 문서화될 필요가 있다.

객체 모형 데이터

객체 내의 데이터를 문서화하는 것은 상대적으로 간단하다. 그 이유는 객체 내에서 발견된 속성들 은 그 객체의 성질이거나 메시지 안에 전달된 다른 객체의 성질이기 때문이다. 예를 들어 [그림 5- 1-28]에서 메시지 부분으로서의 트랜잭션 객체는 트랜잭션 번호를 주식 중개인 객체에 전달한다. 두 객체의 메시지가 트랜잭션 번호를 사용한다고 할지라도 트랜잭션 번호는 트랙잭션의 성질이지 주식 중개인의 성질은 아니다. 트랜잭션 번호는 트랜잭션 객체 안에 정의되어 있다. 그래서 주식 중개인 객체 안에서 재정의될 필요는 없다. 오직 데이터만이 한번 문서화할 필요가 있다. 그래서 다른 객체 들에 속하는 데이터는 소유 객체 안에만 문서화 된다.

대부분의 경우에서 한 객체 안의 데이터는 구조를 가지지 않는다. 구조상 데이터가 개체-관계 다 이어그램에 있다면, 다양한 엔터티 내에 있을 수 있다는 것을 뜻한다. 즉 데이터 구조가 없는 객체는 모든 객체의 속성들이 개체-관계 다이어그램에서 하나의 엔터티 내에 있다는 것을 의미한다. 데이터 구조가 없을 때 객체의 데이터를 문서화하는 것은 객체의 정의와 도메인을 구체화시키는 것으로 제 한된다. 그러나 객체의 데이터가 구조를 가진다면 그 구조는 개체-관계 다이어그램의 단편도 (Fragment Diagram) 안에 모형화되어야 한다.

예를 들어 계좌 객체의 데이터가 정적인(Static) 계좌 정보뿐만 아니라 다양한 활동 항목(Activity Items)을 포함하고 있다면 분석가는 개체-관계 다이어그램 단편도에 계좌와 계좌 활동 간의 일대다 관계를 표현할 것이다. [그림 5-1-28] 참조

객체 모형의 메소드

객체 메소드가 복잡하지 않다면 메소드는 간단한 설명부(Narrative) 또는 구조화된 기법으로 가장 잘 문서화된다. 복잡한 메소드는 좀 더 정교한 문서화 접근 방식이 필요하다. 이벤트 지향적인 프로세스는 상태 전이 모델링(State Transition Modeling)과 같은 동적(Dynamic) 프로세스 모델링 기법이 필요하다. 반면에 정적인 프로세스는 데이터 흐름 다이어그램이나 기능 분해(Functional Decomposition)와 같은 기법을 사용한다. 계좌 객체의 계좌 갱신 메소드는 데이터 흐름 도표에 의해서 문서화된다. [그림 4-1-29] 참조

다이어그램에서 어떻게 트랜잭션 객체가 외부 엔터티로 표현되었는지, 또한 계좌 갱신 메시지가 계좌 객체에 대한 데이터 흐름이라는 점을 유의해야 한다.

다이어그램에서 어떻게 트랜잭션 객체가 외부 엔터티로 표현되었는지, 또한 계좌 갱신 메시지가 계좌한다.

불명료한 객체 접근 방식

객체 접근 방식에는 두 가지 주의 사항이 있다. 첫번째는 객체지향 개발의 가장 단순화된 표현이다. 이것은 객체지향 개발을 분명하게 이해하는데 필요한 많은 객체지향 특징을 무시하는 것이다. 불행히도 그러한 특징을 탐색하는 것은 설명하기가 매우 어렵다. 두번째는 객체지향 모델링의 미성숙이다. 객체가 어떻게 표현되고 기호가 어떻게 사용되어야 하는가 등의 정의는 아직까지 초기단계이 다. 현재 접근 방식은 크게 변화하고 있고 많은 개발자들이 표준안을 원한다고 할지라도 이러한 상황은 당분간 계속될 것이다.

객체지향 모델링과 논리 데이터 모델링간의 관계

객체지향 모델링과 논리 데이터 모델링은 공통점이 많다. 객체지향 모델링 개념은 논리 데이터 모델 링의 개념과 매우 유사하다. 그러나 많은 유사점에도 불구하고 차이점 또한 존재한다. 객체지향 모델링 에서만 유일한 것은 데이터와 프로세스를 같은 엔터티로 결합시킨 것이다.

[표 4-1-2] 객체지향 모델링과 논리 데이터 모델링 간의 비교

객체지향 모델링	논리 데이터 모델링	차이점
객체	엔터티	객체는 프로세스를 포함한다.
속성	속성	-
연결 (Link)	관계 (Relationships)	유사하다. - 연관은 동일하다. - 상속은 데이터 모델링이 메소드를 포함하지 않는다는 것만 제외한다면 서브타입/슈퍼타입과 동일하다.
캡슐화	-	대응하는 논리적 데이터 모델링의 개념은 없다.
객체 클래스	엔터티 유형	없음
객체 인스턴스	엔터티 인스턴스	없음
메시지	-	메시지는 프로세스와 연관되어 있기 때문에 대응하는 개념은 없다.

논리적 기초가 잘 갖춰진 데이터 모델러는 일반 프로세스 모델러보다 객체지향 모델링 개념을 더 쉽게 소화한다. 많은 객체지향 접근 방식은 논리적 데이터 모델링 접근 방식과 유사하다. 그래서 객체지향 모델링을 논리적 데이터 모델링의 연장으로 간주하기도 한다. 다른 주요 유사성은 두 가지 접근 방식이 다음의 어려움을 공유한다는 것이다. 많은 분석가는 데이터가 프로세스에 종속하지 않는 방식으로 데이터와 프로세스의 개념을 결합한다. 이것은 객체지향 모델링에 기반한 애플리케이션을 개발하는 사람들이 논리적 데이터 모델링의 개념도 잘 이해하고 있기 때문이다. 또한 좋은 접근 방식들은 서로 결합하기 때문이다.

객체지향 모델링 장점

객체지향 모델링의 장점은 재사용 코드와 같은 개념이 실제로 가능한 환경을 제공한다는 것이다. 이것은 또 다른 문제를 해결해 준다. 데이터나 프로세스 중 어느 것도 조직의 모든 규칙을 표현할 수는 없다. 일부 규칙은 프로세스 모형에서 표현될 수 있고 일부는 데이터 모형에서 표현된다. 그러나 객체지향 모델링은 모든 비즈니스 규칙이 표현될 수 있는 유일한 환경을 제공한다. 객체지향 모델링은 또한 프로세스와 데이터 모델링을 함께 운영한다. 데이터와 프로세스가 객체의 성질인 반면 데이터와 프로세스 각각은 그들의 풍부함(Richness)을 달성하는 다른 접근 방식을 필요로 한다는 사실이 위의 사항들을 확신하게 한다.