데이터베이스 이론 – 모델링 #.2

개체-관계(E-R, Entity-Relationship) 모델이란?

데이터 모델은 데이터베이스 설계에 대한 계획 또는 청사진입니다. 건축에 비유해보면 시공을 하기전에 설계를 하는 것인데, 시공이 어느정도 된 시점에서 변경사항을 반영하는 것은 비용도 많이 들고, 시간적인 손해도 많이 발생합니다. 데이터베이스도 마찬가지로 구축이 완료된 후에 데이터가 쌓이기 시작한 상황에서 관계를 변경하는 것은 데이터를 새로운 구조로 옮겨야 함을 나타내며, SQL문 역시 변경해야 합니다.

RDBMS가 지속적으로 사용된 만큼 데이터 모델을 만들어 주는 많은 도구와 기법들이 정의되어 왔습니다. 하지만 근래에는 개체-관계 모델이 세계적으로 표준 모델로 떠올랐습니다.

개체-관계(E-R, Entity-Relationship) 모델은 1976년 Peter Chen에 의해 최초로 발표되었으며, Chen이 정립한 모델의 기본적인 구성요소에 서브타입이 추가되어 확장된 E-R(extended E-R) 모델이 만들어졌으며, 현재 E-R 모델이라고 흔히 말하는 기법이 바로 이 확장된 E-R 모델을 말하는 것이라고 보면 됩니다.

 

개체(Entity)

개체란 사용자가 추적하고자 하는 어떤 사물입니다. 쉽게 설명하면 테이블과 테이블이 포함하는 컬럼을 엔티티라고 할 수 있으며, 테이블에 포함되어 있는 데이터들의 집합을 개체 클라스라고 정의할 수 있습니다. 또, 테이블의 컬럼이 가진 속성에 맞는 각각의 값들을 개체의 인스턴스하고 표현합니다. 즉, 모든 개체 인스턴스의 집합을 개체 클래스로 그룹지을수 있습니다. 그리고 개체가 갖는 속성(attribute)은 컬럼을 생성할 떄 정의하는 것들이라고 보시면 되고, 같은 컬럼의 데이터들은 모두 같은 속성을 가집니다. 실제 데이터에서 어떤 값을 저장하는가? 그리고 저장된 데이터를 어떤 형식으로 저장하는가? 이런것들을 나타냅니다.

• 개체 클래스 = Table 명
• 개체 인스턴스 = 열이 갖는 데이터
• 개체 속성 = 컬럼이 갖는 속성
• 개체 식별자 = key

아무래도 모델링 이론을 공부할 때는 학술적 용어와 실제 사용하는 용어가 달라서 많이들 어려워 하는 부분이 있는데, 그냥 실무용어로 쉽게 생각하면 좋을것 같습니다.

개체와 테이블의 차이는 무엇일까?
개체와 테이블의 본질적인 차이는 외래키(FK)를 사용하지 않고 개체 간의 관계를 표현할 수 있다는 것입니다.

 

관계(Relationship)

개체는 다른 개체와 관계로 표현될 수 있습니다. E-R 모델은 관계 클래스와 관계 인스턴스를 모두 포함하고 있습니다. 관계 클래스는 개체 클래스관의 연관이고 관계 인스턴스는 개체 인스턴스들 간의 연관을 나타냅니다. 이렇게 설명하면 말은 어려운데 A라는 특정 테이블의 특정 컬럼B가 다른 C라는 테이블의 특정 컬럼D와 관계가 맺어져 있어 매칭이 되는 컬럼간의 데이터가 동일하거나 관계가 있는 상태 라고 보시면 쉽습니다.

관계 클래스는 2개 또는 그 이상의 개채 클래스를 포함할 수 있습니다. 관계에 참여하고 있는 개채 클래스의 수는 관계의 차수(dgree)입니다. 2개의 개체 클래스를 포함하면 차수는 2로 이항관계(Binary Relationship)라고 하며, 차수가 3인 관계를 삼항 관계(ternary relationship)이라고 합니다. 데이터 모델을 관계형 설계로 변환시킬 때, 모든 차수의 관계는 이항 관계의 결합으로 처리됩니다. 그리고 비이항(nonbinary) 관계에서는 추가적인 작업이 필요합니다. 대부분의 모델링 툴에서는 모든 관계를 이항 관계로 표현해야 합니다.

 

카디널리티(Cardinality)

E-R 모델에서 관계는 그 카디널리티에 의해 분류됩니다. 최대 카디널리티는 관계 인스턴스에 참여할 수 있는 개체 인스턴스의 최대 개수이며, 최소 카디널리티는 관계 인스턴스에 반드시 참여해야 하는 개체 인스턴스의 최소 개수입니다.

E-R 모델에서는 최대 카디널리티는 기본적으로 세가지입니다.

• 일 대 일(1:1)
• 일 대 다(1:N)
• 다 대 다(N:M).

1:1 관계는 하나의 개체 인스턴스가 다른 개체의 하나의 인스턴스와 관계되는 것입니다. A 테이블의 하나의 데이터(행이 갖는 모든 속성)이 B 테이블의 하나의 데이터와 관계가 맺어지는 것이 1:1 관계입니다.

1:N 관계는 하나의 개체 인스턴스가 다른 개체의 다수의 인스턴스와 관계되는 것입니다. A 테이블의 하나의 데이터(행이 갖는 모든 속성)가 B 테이블이 갖는 여러가지 값들과 관계를 형성합니다. 예를 들면 DEPARTMENT 테이블의 부서 데이터가 EMPLOYEE 테이블의 Mary라는 데이터와 관계를 맺을수 있지만 다른 직원들과도 관계를 맺을수 있습니다. 하지만 EMPLOYEE의 직원들은 하나의 부서만 가질수 있습니다. 즉 DEPARTMANT 테이블은 EMPLOYEE 테이블의 여러 데이터에 관계를 가지지만 EMPLOYEE 테이블은 DEPARTMANT 테이블의 데이터에 대해 하나만 배정받을수 있는 관계가 1:N 관계를 쉽게 보여준다고 보시면 됩니다. 1:N 관계에서는 부모(Parent)와 자식(child)이라는 용어가 나오는데 이때 1인 쪽이 부모, N쪽이 자식이 된다고 보면됩니다.

N:M의 관계는 EMPLOYEE 테이블의 직원이 특정 스킬을 가지고 있음을 나타내는 SKILL 테이블과 관계가 있을때, 특정 스킬을 한명의 직원만 아닌 다수의 직원이 가질 수 있고, 한명이 여러개의 스킬을 가질수도 있습니다. 이런 N:M의 관계에서 N과 M이 같을 필요는 없으며, 관계를 N:M으로 기록하는 것은 카디널리티가 서로 다를지 모른다는 가능성을 강조하기 위함입니다.

E-R 모델에서 최소 카디널리티는 관계에 반드시 참여해야하는 개체 인스턴스들의 개수를 말합니다. 최소 카디널리티는 네가지입니다.

• 필수적 대 필수적(M-M) 관계
• 선택적 대 선택적(O-O) 관계
• 선택적 대 필수적(O-M) 관계
• 필수적 대 선택적(M-O) 관계

DEPARTMANT와 EMPLOYEE는 서로 반드시 있어야하는 필수적 대 필수적(M-M) 관계 입니다. 회사의 직원은 적어도 하나의 부서를 가지고 있어야 하니까요. EMPLOYEE와 SKILL 관계는 물론 직원에 대한 데이터는 반드시 있어야 하지만, 아무런 스킬이 없는 직원도 있다면? 필수적 대 선택적(M-O)관계가 됩니다. 이런식으로 반드시 필요한 데이터와 선택을 할 수 있는 데이터를 나타내는 것이 최소 카디널리티 입니다.

이 것을 다이어그램을 통해 표기하는 방법이 여러가지가 있고, 그중에 대표적인 까마귀발 표기법(Crow’s foot notation)은 다음과 같습니다. 무료로 사용할 수 있는 ERD 툴중 하나인 MySQL workbench에서 사용하는 방법이기도 합니다. 까마귀발 표기법은 최대 카디널리티와 최소 카디널리티 모두 표현할 수 있습니다.

 

그리고 이 것을 이용해 모델링을 하게 되면 아래와 같은 예시를 볼수 있습니다. MySQL workbench에서 제공하는 샘플입니다.

 

강한 개체와 약한 개체

E-R 모델에서는 강한 개체와 약한 개체가 분류됩니다.

• 강한 개체(Strong Entity): 다른 개체의 존재 여부와 상관없이 독립적으로 존재할 수 있는 개체, 직사각형으로 표기
• 약한 개체(Weak Entity): 존재 여부가 다른 개체에 달려있는 개체, 독립적으로 존재할 수 없는 개체, 모서리를 라운드로 표기

 

ID-종속 개체

E-R 모델은 ID-종속 개체(ID-dependent entity)라고 불리는 특별한 타입의 개체를 포함합니다. ID-종속 개체는 그 자신의 식별자가 다른 개체의 식별자를 포함하는 개체입니다.ID-종속 개체들은 모두 약한 개체에 속합니다. 그렇다고 약한 개체가 ID-종속 개체는 아닙니다.

 

서브타입 개체

확장된 E-R 모델을 서브타입의 개념을 도입하였는데, 하나의 개체를 2개 이상의 분류로 나눌때 사용하게 됩니다. 아래 그림처럼 예를들면 Person은 슈퍼타입이되고 Person을 Customer, Employee, Supplier 이렇게 3개의 서브타입으로 나눌수 있습니다. 또, Employee를 Engineer와 Writer 2개의 서브타입으로 나누었는데 Employee 슈퍼타입이자 서브타입이 되는 것이죠.

 

오늘은 E-R 모델에 대해 알아 보았습니다. 다음 포스팅에서는 E-R 모델의 패턴을 알아보겠습니다.

모델링은 자꾸 해봐야하는데 실무에서는 솔직히 모델링 프로젝트만 뛰는 DA가 아니고서야 접할 기회가 많지 않은것 같습니다. 아무쪼록 많은 연습과 노력이 필요한 부분인 것 같습니다.