ER Model

<Conceptual design phase>

 - Design conceptual schema

 - includes detailed descriptions of the entity types, relationship types, and constraints.

Conceptual design을 위한 DM

 - Entity-Relationship(ER) model : 인기 많은 하이레벨의 개념 데이터 모델

 - ER diagrams : ER모델과 연결된 다이어그램으로 나타낸 명시

 - Unified Modeling Language(UML) : 객체지향 디자인을 위한 표준 명시

<ER diagram>

<Entity>

 - 네모로 표시.

 - 같은 특성을 갖을 수 있는 entities들의 집합

 - 독립적인 존재로 현실세계에 존재하는 Thing

 - [[Weak entity type]] : 그들 자신만으로는 키 특성을 갖고 있지 않다. 관련되어있는 특정 entity(owner entity type)에 의해 식별된다.

 - weak entity는 항상 total participation constraint를 갖는다.

 - Identifying relationship : weak entity를 자신의 onwer와 연결해주는 것

   

<Attribute>

 - Entity를 규정짓는 특정한 특성

 - Types of attributes : 

1. Composite vs simple(atomic) : 하나의 특성이 다른 세부 특성을 갖는지 아닌지 위의 그림의 빨간 그리기 부분.
2. Single-valued vs multivalued : entity의 특성이 하나의 값을 갖는지 여러개의 값을 갖을 수 있는지. ( 이중 동그라미 )
3. Stored vs derived : 파생이 되어진 특성인지 아닌지 ( 점선의 동그라미 )
4. Key attribute : entity를 구분지을 수 있는 특성. ( 동그라미 안에 밑줄 )
   key attribute의 조건 : 
   - Uniqueness 
   - 최소성 
   - 불변성
   Key 의 종류  : 
   - Super key(유일성의 보장)
   - Candidate key (유일성 + 최소성 ) : 후보 키
   - Primary key(주 키) : DB 디자니어가 하나를 선택한다. 주로 검색에 많이 이용되는 것 -> 응용도가 높은 것 -> 짧을수록 연속속도가 빠르다.
   - alternate key(대체 키)
5. Null values
6. Complex attributes

<Relationship>

 - Entity들 끼리의 연관관계

 - 관계를 명시 함.

 - 참조특성은 relationship type으로 변형 되어야 한다.

 - Degree : 연결된 entity의 개수(나가는 선의 개수), Binary , ternary(3), n-ary ...

 - role name : 아래의 그림에서 선에 새겨진 숫자. 관계 인스턴스가 수행하는 역할을 나타냄 . (1) 상사 (2) 부하직원

 - Recursive relationship : 동일한 entity type이 서로다른 역할의 관계유형이 두번이상 참여 , 반드시 role name 을 명시 해야한다.

< Relationship 특성과 degree >

• Mapping Cardinality ratio for a binary relationship : entity에 참여할 수 있는 관계 인스턴스의 최대개수를 구체화 함.
  
  

  
  
  

  1:1 , 1:N , M:N 이 존재함.
  1:1 의 경우 : 1명의 직원은 관리해야한다 1개의 부서를. 1개의 부서는 관리자가있어야한다 1명의 직원으로.
  1:N 의 경우 : N명의 직원은 WORKS_FOR한다 1개의 부서에.1개의 부서는 N명의 직원을 갖는다.(여려명의 직원은 1개의 부서에서만 일해야한다)
  M:N은 M개의 엔티티가 N개의 엔티티를 관계해야한다.
  
  Attribute of relationship type (관계타입에 특성이 붙어있는 경우) :
   - 1:1 : 특성이 어느 entity type으로 가든지 상관없다. 효율성을 보고 판단.
   - 1:N : 특성은 오직 N-side로만 움직일 수 있다.
   - M:N : 특성은 움직일 수 없다.
  
  
  

• Participation constraint : entity의 존재가 다른 entity와 관련되어져 있는것에 의존하는지 안하는지를 명시화 한다 
  
  Total, partial 이 존재함.
  Total : 관계선이 두줄임 . 직원들은 반드시 전부 WORKS_FOR 해야한다 . 그것은 모두 부서에 관계되어야 한다
  partial : 관계선이 한줄임. 직원들은 manage를 할수도 있고 안할수도 있다. manages는 반드시 부서에 있어야 한다.

**정리** : 

 N명의 직원은 반드시 WORKS_FOR해야하고 1개의 부서에 반드시 들어가야 한다.

 1개의 부서는 반드시 WORKS_FOR해야하고 N명의 직원을 갖을 수 있다.

 1개의 직원은 매니저를 할수도 있고 안할수도 있지만 매니저는 반드시 한명 부서에 있어야 한다.

<적절한 ER model의 이름붙이기> --> 권장사항!

의미를 전달할 수 있는 이름을 붙여야 한다.

보통 명사는 entity , 동사는 relationship 타입이다. 그리고 관계타입은 주고 왼쪽->오른쪽, 위->아래 방향으로 관계를 설명해준다 

<Binary relationship type만을 지원하는 경우에 표현 방법>

<Enhanced Entity-Relationship (EER ) model >

더욱 정확하고 복잡한 요구사항의 DB를 표현할 수 있다. ER 에 있는 것은 모두 포함하고 있다.

 - Subclass and superclass

 - Specialization and generalization

 - Category or union type

 - Attribute and relationship inheritance

※Type inheritance 

 - subtype or subclass of an entity type

 - 의미있는 entity들의 서브 그룹

 - 서브타입은 그들의 부모타입의 모든 특성과 관계를 상속받는다.

사원의 관계를 3종류로 표현함.

<Specialization>

 - entity type의 서브클래스들의 집합을 정의하는 과정.

 - 수퍼클래스에서 entity들의 구별되는 특징들의 기초를 정의하는 것

 - 서브클래스는 구체적인 특성, 구체적인 관계타입을 정의할 수 있다.

<Generalization>

 - Specialization의 반대 과정

 - 주어진 entity type들로 부터 일반화된 entity type을 정의하는 과정

 - 하나의 단일 슈퍼클래스로 일반화 한다.

a --> b : Generalization

b --> a : Specialization

specializations과 서브클래스들은 정확한 conceptual model을 만들기 위해 사용될 수 있다.

만약 서브클래스가 너무 적은 특성갖거나 관계타입이 없으면 부모에 합쳐질 수 있다.

Entity subclass를 결정할 때 : super class 특성의 값에 의해 자동 분해.

ⓓ : disjointness constraint 서로 겹칠 수 없다. Car 이면서 truck 일 수 없다.

ⓞ : overlap 서로 겹칠 수 있다.

Completeness (or totalness) constraint

 : total or partial

우의 두 조건은 서로 독립적이다. 2X2 개의 경우의 수.

<Union type --> Multiple inheritance>

부모를 두개 이상 갖는 서브클래스 : ⓤ