[Database] 3. Entity-Relationship Model

데이터베이스 디자인과 그 이행 단계:

Entity: 존재하고 다른 객체와 구분할 수 있는 객체

Attribute: 객체의 성질(특성)

Relationship: 여러 엔티티 간의 관련성

DB 디자인에 High-level 개념 데이터 모델 사용

1.     필요 조건 분석 및 모으기:

-       DB 설계자와 application programmers는 예상 DB 사용자들을 인터뷰하여 그들의 데이터와 요구 Operations를 이해하고 문서화한다. 이 사용자 요구사항들은 가능한 한 자세하고 완전하게 정의되어야 한다.

-       Requirements specification techniques: 사용자 요구, 용어집, 클래스 다이어그램, 데이터 흐름도, use case diagram 등을 분석한다.

2.     개념적 데이터베이스 디자인:

-       개념적 스키마 디자인: 1단계에서의 결과를 토대로 필요한 데이터를 조사하고 ER 다이어그램 같은 개념적인 DB 스키마를 만들어낸다.

-       트랜잭션과 Application 디자인: 정리된 DB application을 조사하고 input과 output을 구분하고 DB applications나 트랜잭션의 기능에 대한 High-level specification을 만든다.

3.     DBMS 선택: 기술적, 경제적, 정책적인 요소들을 고려한다.

4.     논리적 데이터베이스 디자인: 2단계의 개념 스키마를 선택한 DBMS의 데이터 모델에 적용한다. 많은 자동화된 CASE 디자인 도구들은 개념 스키마 디자인을 통해서 DDL을 생성해낼 수 있다. ANSI/SPARC three-level DBMS 아키텍쳐에서는 이 단계의 결과가 특정 application을 위한 개념적 스키마와 외부 스키마이다.

5.     물리적 데이터베이스 디자인: 내부 저장소 구조, 파일 조직, 인덱스들, 접근 경로(Access paths), 그리고 DB 파일을 위한 물리적 설계 매개변수(Physical design parameters)들을 지정한다. 반응 시간, 공간 활용, 트랜잭션 처리량은 실제 데이터베이스 디자인 옵션을 선택하는데 사용되는 기준(Creteria)이다. 이 단계에서 three-level DBMS 아키텍쳐의 용어에서 내부 스키마를 설계한다.

6.     데이터베이스 시스템 구현 및 튜닝: 이 단계는 보통 DBA가 맡고 DB 설계자와 함께 수행한다. DDL을 작성하고 이전 시스템으로부터 데이터를 이전하며, 선택된 DBMS의 DDL/SDL들이 DB 스키마와 DB 파일들을 만들기 위해 컴파일되면, DB는 이제 데이터를 로드 할 수 있다. DML을 포함한 DB 프로그램들은 application programers가 구현한다. DB의 튜닝은 성능적 문제가 발견되면 계속되며, 그 동안 요구 사항이 지속적으로 변한다.

샘플 DB Application

ER 다이어그램 표기법: 사각형은 어떤 종류의 추상화된 객체인 엔티티를 나타낸다. 다이아몬드는 여러 엔티티 간의 연관 관계를 나타낸다. 엔티티 또는 관계에 직선으로 연결된 타원은 속성(Attribute)를 나타낸다. 밑줄은 Primary key attributes임을 가리킨다.

이런 ER 다이어그램은 어떤 직원이 프로젝트들에 참여하고 있고 관리하는 지에 대한 회사의 정보를 보여준다.

필요 데이터: COMPANY 데이터베이스는 회사의 직원, 부서, 그리고 프로젝트를 가지고 있다.

엔티티와 속성

엔티티: 독립적으로 존재하는 실제 세상의 물건. 물리적 혹은 개념적으로 존재하는 객체.

속성(Attributes): 엔티티를 설명하기 위한 부분적인 속성. 단순/합성 속성, 단일 값/다중 값 속성, 저장된/파생된 속성(다른 속성으로 컴퓨팅 될 수 있는 속성), 복잡한 속성(합성 속성과 다중 값 속성은 임의로 중첩될 수 있다.).

Entity Types, Sets, Keys, Value sets

Entity type: 스키마 또는 동일한 구조를 공유하는 엔티티 집합을 위한 의도. DB에 있는 각 entity type은 이름과 속성으로 설명되어 있다. Entity type은 ER 다이어그램에서 엔티티 타입의 이름이 적힌 사각형 상자로 표현된다.

Entity set: Entity type의 확장. 어떤 한 시점에서 일부 entity type의 모든 엔티티의 모음이다. Entity set은 주로 entity type의 이름과 같은 이름을 사용하여 참조된다.

Key attribute: 엔티티 타입에서 각각을 구분할 수 있는 값을 가지는 속성을 말한다. 복합 키(Composite key)는 여러 간단한 구성 요소 속성을 가지는 키이다. ER 도식화 표현법에서, key attribute는 타원 안쪽의 이름에 밑줄이 쳐져 있다.

어떤 엔티티 타입은 하나 이상의 key attribute를 가지기도 한다. 또한, key를 가지지 않기도 하는데, 이럴 경우를 weak entity type이라고 한다.

Relationship Types, Sets, and Instances

Relation: 한 엔티티 타입의 한 속성이 다른 엔티티 타입을 참고할 때, 관계(Relationship)이라고 한다. 속성이 아닌 관계로 참조를 표시하며, 일반적으로 요구 사하에 두 개 이상의 엔티티 간의 논리적 연결을 제공하는 개념이 포함된 경우에 사용한다.

Relationship type R among n entity types: 엔티티 타입들로부터 엔티티 간의 연관성 집합을 정의한다. ER 다이어그램에서, relation types은 다이아몬드 모양으로 표현된다.

Relationship set R is a set of relationship instances r: 각 r은 각각의 엔티티들과 연관시킨다. R에 있는 엔티티 e는 entity set E의 멤버이다.

Relationship Degree, Role Names and Recursive Relationship

Degree of a relationship type: 관여하고 있는 entity type의 개수. Binary, ternary 등이 있다. SUPPLY라는 relationship set은 relationship 인스턴스들의 집합이다.

Relationships as attributes: 가끔은 속성의 관점에서 생각하면 이진 관계 유형(binary relationship type)이 생각하기 편리할 수 있다. 하지만, 이진 관계 유형을 속성으로 생각하면, 우리는 언제나 2가지 선택지만 주어지게 된다. 예를 들어, WORKS_FOR relationship type은 오직 ‘Employee entity type의 Department attribute’ 혹은 ‘Department entity type의 Employee attribute’로만 표현할 수 있게 된다.

Role names: Relation type에 관여하고 있는 각 entity type은 관계에서 부분적인 역할을 맡는다. 역할 이름은 관여하고 있는 엔티티가 각 관계 인스턴스에서 역할을 의미하고, 이 relationship이 의미하는 것을 설명하는 것을 돕는다. Role names는 모든 관여하는 entity types가 뚜렷한 relation types에겐 필요하지 않다. 각 관여하는 entity type의 이름은 role name으로 사용 될 수 있기 때문이다.

Recursive relationships: 같은 엔티티 타입이 한 번 이상 하나의 relation type에 다른 역할로 관여할 때이다. 이럴 때는 role name을 명시해야만 한다.

Constraints on Binary Relationship Types

Relationship types는 주로 상응하는 relationship set에 관여가 가능하도록, 가능한 엔티티 조합을 제한하는 특정한 제약들을 가진다.

이진 관계를 위한 Cardinality ratio: 엔티티가 관여할 수 있는 relationship instance의 최대 개수를 지정한다. 이진 관계에서 가능한 Cardinality ratio들로는 1:1, 1:N, M:N이 있다.

참여 제약 조건 및 존재 종속성: Relationship type을 통해 하나의 엔티티가 존재하는 것을 다른 엔티티와 관련되도록 지정한다. Total participation(두 줄)과 partial participation(한 줄)로 나뉜다. Total participation은 존재 종속성이라고 불리기도 한다.

Attributes of Relationship Types

Relationship types 또한, 엔티티와 비슷하게 속성을 가질 수 있다. 1:1 혹은 1:N relationship types의 속성은 하나의 entity type에 마이그레이션 할 수 있다. 1:1 relationship type에서는 아무 entity type에 마이그레이션이 가능하다. 1:N relationship type에서는 N에 해당하는 엔티티에게만 마이그레이션이 가능하다. 하지만 M:N relationship type의 특성은 relationship의 특성으로 정의되어야만 한다.

Weak Entity Types

Primary key가 존재하지 않는 entity type이다. 다른 엔티티가 존재하는 것에 엔티티의 존재가 의존한다.

Weak entity type의 존재는 identifying entity type(혹은 owner entity type)의 존재에 의존한다. Weak entity type은 구분하기 위해서 identifying entity type과 총체적으로(existence dependency) 그리고 1:N relation type으로 연관되어야만 한다. Weak entity type과 이를 구분하는 relationship은 두 줄로 된 박스와 다이아몬드 모양으로 구분할 수 있다.

Weak entity type의 discriminator(혹은 partial key)는 weak entity type의 모든 엔티티를 구분해주는 속성의 집합이다. Discriminator는 점선으로 밑줄을 그어 표시한다. Weak entity type의 primary key는 identifying entity type의 primary key와 weak entity type의 discriminator의 합으로 생성된다.

Weak entity types는 가끔 복합(조합, 다중 값) 특성으로 표현될 수 있다. 어떤 표현을 사용할 것인지에 대한 선택은 DB 설계자한테 있다. 사용할 수 있는 한 표준은 만약 어떤 것이 많은 속성을 가지고 있다면 weak entity type 표현을 선택하도록 하고 있다. 만약 weak entity가 독립적으로 그것의 identifying relationship type보다 relationship type에 관여한다면, 그것은 복합 속성으로 모델링 되어서는 안된다.

ER 설계를 위한 디자인 선택

어떤 부분적인 개념을 entity type으로, 속성으로, 혹은 relationship type으로 할 것인지 결정하는 것은 어려운 일이다. 일반적으로, 스키마 설계 과정은 가장 알맞은 설계에 도달할 때까지 반복적인 Refinement process로 간주 되어야한다.

자주 사용되는 Refinement process는 다음을 포함한다:

-       개념은 속성으로써 가장 먼저 모델링 되어야한다. 만약 속성이 다른 entity type에 참고되면 relationship으로 재정의한다.

-       여러 entity types에 존재하는 속성들은 독립적인 entity type으로 만들 수 있다.

데이터베이스 설계 과정:

-       요구 사항을 모아서 설명을 붙인다.

-       Entity type을 구분해낸다. (명사)

1.     모은 요구사항으로 만든 설명에서 명사를 분리한다.

2.     잘못 정의되거나 너무 광범위한 개념을 제외한다.

3.     생략된 entity type이 있는지 확인한다.

-       Relationship types를 구분한다. (동사)

-       Relationship type을 1:1인지, 1:N인지, 아니면 M:N인지 결정한다.

-       ER 스키마 다이어그램을 그린다.

-       Entity types와 Relation types에 필요한 속성들을 구분한다. (명사 혹은 형용사)

-       Entity types의 primary key를 구분한다.

-       ER 스키마 다이어그램이 요구 사항을 충족시키는지 확인한다.

-       DBMS에서 사용되는 적절한 데이터 모델에 ER 스키마 다이어그램을 매핑한다.

ER 다이어그램의 대체 표기법

한 ER 대체 표기법은 Relationship type R에 대한 entity type E의 관계를 한 쌍의 정수 (Min, Max)를 연관시킨다. 숫자들은 entity set E의 각 e에 대해서, e는 적어도 min에서 최대 max개의 relationship instances에게 영향을 미쳐야 한다. Min=0이면 partial participation이고, min>0이면 total participation이다.

UML Class Diagrams

UML(Unified Modeling Language) 방법은 소프트웨어 설계에 광범위하게 사용되고 있으며, 다양한 소프트웨어 설계 목적을 위한 다양한 유형의 다이어그램을 가지고 있다. Class diagram, Object diagram, Deployment diagram 등이 있는 구조적인 다이어그램과 Use Case diagram, Sequence diagram, Activity diagram 등이 있는 행동적인 다이어그램이 있다.

Class Diagram: 다른 엔티티들이 서로에게 어떻게 연관되어 있는지 보여준다. 다른 말로, 시스템의 정적인 구조를 보여준다. 시스템 내의 클래스, 속성, operations와 각 클래스 간의 relationship(association, aggregation 등)을 포함한다. 클래스는 3개의 부분으로 나뉘어 사각형으로 묘사된다. 가장 위쪽 부분은 클래스의 이름을, 중간 부분은 클래스의 특성을, 아래 부분은 클래스의 Operations를 포함한다. 집합(Aggregation)은 모든 객체와 그 구성하는 부분 간의 관계를 보여주는 것을 의미한다.

Relationship Types of Degree Higher than Two

Degree of a relationship type: 관련 있는 entity types의 개수. Binary, ternary 등이 있다. 일반적으로, n-ary relationship은 n binary relationships와 같지 않다.

일부 DB 설계 도구들은 오직 binary relationships만 지원한다. 이럴 경우, ternary relationship은 partial key와 three identifying relationship가 없이 weak entity type으로 표현되어야 한다.

Artificial 혹은 surrogate key를 도입하는 것으로, ternary relationship을 regular entity type인 것처럼 표현할 수 있다. 아래 예시의 경우, key attribute인 Supply_id는 regular entity type으로 변환하는 것으로 supply entity type으로 사용될 수 있다.