[데이터베이스 03] Entity Relationship Model

 하나의 프로그램을 설계할 때는 어플리케이션 디자인 및 데이터베이스 디자인이 필요하다. 이때 수행되는 데이터베이스 디자인은 엄밀하게 따지면 분석(analysis) 및 디자인(design) 작업을 포함하지만, 보통 뭉뚱그려 같이 표현한다.

데이터의 출처	Mini World
데이터의 분석	요구사항 수집 및 분석
요구사항	기능적 요구사항(Functional, Application)	데이터 요구사항(Data, Database)
	기능 분석(Functional Analysis)	개념적 설계(Conceptual Design)
요구사항 구현 모델	High-Level Transaction Specification	Conceptual Schema
DBMS independent		논리적 설계(Logical Design) + Mapping
DBMS dependent
결과물	어플리케이션에 대한 디자인	Logical Schema(DBMS specific)
		Physical Design
	트랜잭션 구현	Internal Schema
최종 결과물	어플리케이션 프로그램

Entity Relationship Model

ER 모델에서는 Entity, Attribute, Relationship 이 세가지 요소가 주가 된다.

 

• Entity
  : 데이터베이스에서 표현되는 실제 세계(mini-world)의 특정 물건 또는 대상.
  • SCHEMA 수준의 Entity Type 및 데이터 수준의 Entity Set 모두를 지칭한다.
  • ex) STUDENT, LECTURE, EMPLOYEE ...
• Attribute
  : entity를 묘사/설명하기 위해 사용되는 프로퍼티. 특정한 엔티티는 특정한 속성을 가지며, 하나의 attribute는 가질 수 있는 값의 제약 ( 데이터 타입, value set ... ) 이 존재한다.
  • ex) EMPLOYEE - phone_number, address, salary ...
  • Type of attributes
    
    • Simple 
      : 더 이상 구분될 수 없는 (atomic) 속성. 
      • ex) 성별, 나이 등
    • Composite
      : 여러 컴포넌트들이 모여 구성되는 속성. ( , ) 을 이용하여 나타낸다.
      • attr ( com1,com2,com3 ) 꼴로 나타낸다.
      • ex) NAME ( FIRST_NAME, MIDDLE_NAME, LAST_NAME )
    • Multi-valued
      : 하나의 엔티티가 여러개를 가질 수 있는 속성. 즉, 한가지 속성에 대해 특정 엔티티가 여러개의 값을 가질 수 있는 경우를 의미한다. { } 을 이용하여 나타낸다.
      • { attr } 꼴로 나타낸다.
      • ex) 연필에 여러가지 색깔 ( 빨강, 노랑, 초록 등 ) 이 사용됨 -> { COLOR_PENCIL } 
    • 보통 Composite 및 Multi-valued attribute 들은 중첩되어(nested) 나타나는 경우가 많다.
    • ex ) 한 사람은 여러 번호를 가질 수 있다. 하나의 전화번호는 국제 코드와 실제 번호로 나뉜다고 하자. 이 경우 다음과 같이 나타낼 수 있다  : { PHONE_NUMBER ( GLOBAL_CODE, INNER_NUMBER ) }
      한 사람 -> 여러개의 값 : { } 을 통해 Multi-valued 를 표현한다.
      2개 컴포넌트로 나뉘는 전화번호 : ( ) 을 통해 Composite 타입으로 나타낸다.

 

• Entity Type
  : 엔티티를 집합적으로 나타내는 방법으로, SCHEMA · 정의 · attribute · 데이터 타입 등을 정의해둔 것이다. 카탈로그/딕셔너리에 저장되며, 엔티티의 그룹 또는 타입을 나타낸다.
  
  • ex ) PERSON 은 각각의 사람을 나타낼 수도 있지만, "사람" 이라는 집합 명사로 사용될 수도 있다. 이 경우의 사람은 Entity Type 으로 해석할 수 있다.
• Identifier (Key Attribute)
  : 각 엔티티가 반드시 가져야 하는 유니크한 속성. 보통 Identifier은 특정 엔티티에 대한 식별자로 사용된다. 
  • ex ) 한국에서는 모든 사람에게 주민등록번호가 부여되며, 해당 번호는 각각의 사람에 대해 고유하다. 이러한 값은 Key Attribute 가 될 수 있다.
  • Key라는 표현은 보통 Relational Model이 정해진 이후에 사용되는 것이 맞지만, 현재는 Identifier 이라는 표현과 자주 혼용하는 경향이 있다.
  • 각 Key는 Composite 일 수도 있다.
    • ex) 전화번호를 Key Attribute로 취급할때, PHONE_NUMBER ( GLOBAL_CODE, INNER_NUMBER ) 이다.
  • Key 자체가 여러개일 수도 있다.
    • ex) 사람은 주민등록번호로 식별할 수도 있지만, 전화번호로 식별할 수도 있다.
  • Primary Key
    : Key 들중 특히 식별자로 사용되는 속성. 반드시 각 엔티티 당 하나의 값을 가져야 하며 (Null이면 안되며), primary key는 하나 이상의 속성에 부여될 수 없다.
• Entity Set
  : 엔티티(인스턴스적 성격) 들의 컬렉션으로, 데이터베이스 상에 저장된 실제 · "현재" 데이터들의 집합을 의미한다. state/collection 이라는 표현을 사용하기도 하며, Entity Type의 조건을 만족하는 데이터들이다.
  • ex ) CAR 엔티티 타입 - car1, car2, car3 -> CAR 타입에 대한 엔티티 셋
  • 이때 CAR이라는 표현은 엔티티 타입을 설명할 수도 있고, 엔티티 셋을 설명할 수도 있다. 엔티티 타입 및 엔티티 셋을 지칭할 때 동일한 name 을 이용하므로, 문맥에 따라 적당히 구분해야 한다. 물론, 경우에 따라 두가지의 이름을 달리 정할 수도 있다.
• Domains( Value Sets )
  : 특정 속성(attribute)이 가질 수 있는 값의 집합으로, 속성으로 부여할 수 있는 값들에 제약을 가할 수 있다. 대부분 프로그래밍 언어에서의 "타입"과 유사한 역할을 수행한다.
  • ex ) 이름은 15자까지 허용됩니다 -> 이름이라는 속성에 "15글자 이내" 라는 조건이 존재. 
          날짜는 MM-DD-YYYY 형태로 나타나며, 각 글자는 숫자로 나타난다.
  • A : E -> P(V)
    where A : Attribute
             E : Entity Type
             V : Value set
             P : V에 대한 power set. 즉, V로 만들 수 있는 모든 조합.
    A(e) = Attribute A 의 entity e가 가지는 값을 의미.

ER diagram에서 사용하는 표현법들

 위 정보들을 이용하면 특정 엔티티 및 엔티티에 대한 속성을 나타낼 수 있다. 그러나 mini-world 상의 대부분의 대상들은 서로 관계를 맺는다. 따라서 엔티티간의 관계를 표현하기 위해서는 이를 위한 수단이 필요하다. ER 모델에서는 엔티티 사이의 관계를 Relationship을 통해 나타낸다.

• Relationship
  : 둘 이상의 엔티티 사이에서 발생하는 관계. 이때 두 엔티티의 타입이 반드시 같을 필요는 없다.
  • ex ) 직원 은 회사에서 일한다(WORK_FOR).
  • 엔티티와 유사하게, 스키마 수준에서 Entity Type 사이의 관계를 나타내기 위한 Relationship Type 과 각 엔티티(인스턴스) 들 사이에서 발생하는 관계의 집합을 의미하는 Relationship Set 으로 구분된다.
  • Relationship Type
    : Relationship에 대한 스키마 레벨의 묘사. 관계의 이름 + 참여하는 엔티티 타입으로 식별되며, 관계에서 발생하는 제약조건 (Constraints) 에 의해 식별되기도 한다. 일반적으로 좌->우, 상-> 하 순으로 해석된다. 
    • ex1 ) 직원 은 회사에서 일한다(WORK_FOR) 에서 WORK_FOR은 엔티티 타입 "직원" 과 "회사" 사이의 관계를 정의하기 위한 Relationship Type으로 사용되었다.
  • Relationship Set
    : 데이터베이스 상에서 현재 표현되어 있는 Relationship Instance 에 대한 집합(current state) 으로, 개별적인 엔티티 사이에서 발생하는 관계를 묶어둔 것이다.
    • ex2 ) 직원 홍길동 은 회사 A 에서 일한다(WORK_FOR). 에서 WORK_FOR은 "홍길동" 이라는 인스턴스와 회사 A 라는 인스턴스 사이의 관계를 설명한다. 이런 관계의 집합이 Relationship Set 이다.

 

Constraints on Relationship

관계에 참여할 때 나타나는 제약조건을 의미한다.

• Cardinality Ratio
  : 관계에 참여할 수 있는 엔티티의 최대 비율을 나타낸다.
  • one-to-one
    : 일대일 관계만 가질 수 있다.
    • 학생은 하나의 학번을 가진다. & 학번은 하나의 학생에 대응된다.
  • many-to-one(N-1) / one-to-many(1:N)
    : 1대 n 관계를 가질 수 있다.
    • N : 1 ) 직원 은 각각 하나의 부서에서 일한다. & 하나의 부서는 여러 직원을 거느린다.
    • 1 : N ) 고객은 여러 오더를 주문한다. & 하나의 주문은 하나의 고객에게 속한다.
  • many-to-many(M:N)
    : 상호간에 다수의 관계를 가질 수 있다.
    • 학생 은 여러 수업을 듣는다. & 수업은 여러 학생들이 포함된다.

 

• Existence Dependency Constraint
  : 엔티티가 관계에 참여하는 것이 필수적인지, 아니면 선택적인지 여부를 설명할 때 사용되는 제약조건으로, 엔티티가 관계에 있어야 하는지 여부를 식별한다.
  • zero (optional participation)
    : 모든 엔티티가 관계에 참여할 필요는 없다.
  • one or more (mandatory participation)
    : 모든 원소가 관계에 참여한다
  • https://www.ibm.com/docs/en/informix-servers/14.10?topic=relationships-existence-dependency
  • Participation Constraint와 표현이 다른 유사 개념이다.

•  Participation Constraints
  : 하나의 엔티티가 relationship type을 통해 다른 엔티티에 의존하여 존재하는지 여부를 설정할 때 사용되는 제약조건이다. 관계에 참여하는 최소 엔티티 숫자를 지정할 수 있으며, 이를 minimum participation constraint 라고 한다.
  • Total Participation(existence dependency)
    : 엔티티 내 모든 원소가 relationship을 통해 다른 엔티티와의 관계에 참여한다. 
  • Partial Participation 
    : 엔티티 내의 일부 원소가 관계에 참여한다.

Recursive Relationship type

 동일한 엔티티 타입 사이에서 distinct role 을 가지고 발생하는 relationship type으로, 자기 자신을 가리킨다고 해서 self-referencing relationship type 이라고도 한다. 관계가 하나의 엔티티 타입에 대해 발생하므로, 관계에 참여하는 대상이 "어떤" Role로 참여하는지에 대해 명시해야 한다.

Weak Entity Type

 자기 자신을 식별할 수 있는 Key Attribute 를 가지지 않아 다른 엔티티 타입에 의존하는 엔티티 타입.

 Weak Entity Type에 속한 엔티티들은 다른 엔티티 타입이 가지고 있는 attribute 값에 의해 식별되며 (partial key + 다른 엔티티 타입 필요) , 항상 total participation constraint (existence dependency) 을 가진다.

• Owner/identifying entity type
  : weak entity type 을 식별하는데 사용되는 엔티티 타입
• Identifying relationship
  : weak entity type이 owner entity type과 가지는, 자신을 식별하기 위한 관계
• Partial Key
  : owner entity 에 대해 weak entity을 고유하게 식별하는데 사용되는 attribute의 집합

고객이 물품을 주문(ORDER) 하면 주문에 포함된 리스트(ORDERITEM) 이 존재하는데, 해당 리스트들은 각각의 제품(PRODUCT) 을 포함할 것이다. 보통 인터넷 쇼핑몰을 사용하면, 각 주문은 고유한 주문 번호(Key)를 가지고 있다. 따라서 ORDER 자체는 고객과 Weak Relationship을 가지지 않는다. 반면 각 주문에 대응되는 제품 리스트(ORDERITEM) 은 보통 각각 고유한 식별자(Key) 를 가지지 않는다. 대신 해당 리스트들은 "8063 번 주문에 포함된 제품들" 과 같이 ORDER 에 종속되어 표현된다. 실제로도 특정 ORDER을 가리키는 Order_Id Partial Key를 가지고 있다.

 보통 ORM에서는 각 엔티티 사이의 관계를 지정하는데, 이 사이에서 자동적으로 Weak Entity Type을 자동으로 생성 및 삽입하여 편리하게 사용할 수 있도록 도와준다. TypeORM 등 다양한 ORM에서 이러한 동작을 보인다.

min-max notation

 통상적인 Entity Relationship 모델에서 모델 사이의 관계는 cardinality ratio ( 최대 참여 비율 ) 및 participation constraints ( 최소 참여 숫자 ) 을 이용하여 나타냈다. 이런 방식은 엔티티 사이의 관계를 나타내기 좋기는 하나, 충분하지 않을 수 있다.

 예를 들어 직원과 부서 사이의 관계를 생각해보자. 여러명의 직원은 하나의 부서에서 일할 수 있고, 한명의 직원이 동시에 여러 부서에 속할 수는 없다면, 다음과 같이 모델을 표현할 수 있다.

 이때 하나의 부서에 최소 3명의 직원이 필요하다는 제약조건이 추가로 주어졌다고 하자. 해당 조건을 어떻게 지금까지의 제약조건으로 표현할 수 있을까? 결론만 말하면 표현할 수 없다. cardinality ratio 로는 최대 "비율" 만 나타낼 수 있고, participation constraint 로는 참여 "여부" 만 알 수 있기 때문이다. 따라서 정확한 수치를 요구하는 관계는 현재까지의 표현방법으로 나타낼 수 없다.

 이러한 상황에 대해 ER-Model 은 다른 표기법을 가지고 있다. min-max notation 은 관계에 참여하는 인스턴스의 수를 명확하게 표기하는데 사용되는 기법으로, 참여 비율을 나타내는 대신 구체적인 최소/최대 참여 수치를 명시한다.

두 표기법은 해석 방법에서도 큰 차이가 존재한다.

---

Cardinality + participation 방식

 기존 방식은 관계를 묘사할 때 참여 비율을 나타낸다. 이때 비율이라는 것은 기본적으로 비교하는 대상이 반드시 필요한데, ER-Model에서는 이러한 대상들이 관계에 참여하고 있는 엔티티가 된다. 따라서 관계에서의 참여 비율을 표현하기 위해서는 반드시 2개의 엔티티가 필요하며, 두 엔티티는 관계를 중심으로 집단(Entity Type)에 대해 해석된다. 

여러명의 직원은 하나의 부서에서 일한다.

 직원 및 부서의 관계를 나타내기 위해서는 직원, 부서 라는 엔티티, 여럿, 하나 라는 비율 및 일한다 라는 관계가 필요하다. 이때 여럿 이라는 표현 자체는 개개의 직원 입장(Entity) 의 입장이라기 보다는, 직원이라는 집단(Entity Type) 을 설명하는 것이다. 

min-max notation 방식

 min-max notation 방식은 특정 엔티티 하나(Entity. 개개의 엔티티를 의미)가 상대 엔티티와 최소 m개 이상, 최대 n개 이하의 관계를 가진다는 의미를 나타내기 위해 사용된다. 각각의 엔티티 입장에서 관계를 해석하므로, 관계에 참여하는 특정 엔티티와 다른 엔티티 사이를 묘사할 때마다 min-max 표현을 사용하게 된다.

 위의 경우를 떠올려보자. 일한다는 관계를 중심으로 보면, 여러명의 직원은 하나의 부서에서 일하는 것이 된다. 이때 두 엔티티 사이의 관계를 엔티티를 중심으로, 즉 각각의 직원과 각각의 부서 입장에서 생각해보자.

• 한명의 직원은 하나의 부서에서 일한다.
• 하나의 부서에는 여러명의 직원들이 포함된다.

 위 표현에 따르면, 여러명의 직원 이라는 표현은 부서측 관계에서 나타나고, 하나의 부서라는 표현은 직원측에서 나타나게 되었다. 즉 관계 입장에서는 N : 1 으로 나타났던 것이, 각각의 엔티티 인스턴스 입장에서 보면 반대 자리에 위치하게 되는 것이다. 이처럼 cardinality에서의 비율은 min-max notation에서 반대 위치에서 나타난다.

 특징적인 부분은 역시 (3, n) 으로 표현된 부분이다. cardinality 표현법에서는 비율만 나타낼 수 있으므로, 실제 수치는 결정할 수 없었다. 그러나 min-max 표기법에서는 관계에 참여하는 상대 엔티티의 실제 최소값 및 최대값을 명시적으로 나타낼 수 있어 관계에 제약조건을 더 확실하게 명시할 수 있다.