DB-2장 : ER (Entity-Relationship) Model (Peter Chen ERD)

ER 모델, ERD 혹은 ER 다이그램으로 들어보신 분도 많을 거 같은데요.

ER모델링, ERD 를 그리는 것은 본격적으로 데이터베이스와 SQL 에 들어가기 전에 개념적으로 데이터베이스를 모델링하는 중요한 부분입니다.

반말 존댓말 왔다갔다 하는데, 양해부탁드려요 ㅎ.ㅎ

오늘 설명할 개념과 단어들은 다음과 같습니다

디비 설계를 할 때는 개념적 설계를 한 후에 논리적 설계를 진행합니다. 논리적 설계는 DBMS를 고르고, ER 모델을 Database 스키마로 바꾸는 활동인데요 그렇다면 개념적 설계는 무엇일까요?

용어 정리

• Entity : 실제 세상에서 다른 객체와 구별되는 객체.
  • Entity 의 단어 의미는 '실재', '실체' 와 같은 의미를 가지고있는데요, DB에서, 하나하 구별되는 요소 즉 객체. 라는 의미로 사용됩니다.
• attributes : 엔티티의 속성.
• Entity Set : 비슷한 엔티티의 집합.
  • 특정 엔티티 세트 내에 있는 모든 엔티티는 같은 세트의 attribute를 가지고있다.
  • entity set 는 key를 가진다.
    • 키는 한 엔티티 세트를 다른 엔티티 세트로부터 구별해주는 값이다.
    • 키는 attribute의 최소한의 세트다. 꼭 필요한 attribute만 포함해야한다.
      • candidate key, 즉 후보키는 하나 이상 있을 수 있다.
      • primary key : 후보키 중 대표적인 키.
  • 각 attribute는 domain 을 가진다.
    • domain은 특정 attribute(속성)에 들어갈 수 있는 값의 유형, 범위, 길이 등을 정한 규칙이다.
    • ex) up to 20 characters, 1부터 10까지의 정수 등
• Relationship(관계) : 두개 혹은 그 이상의 entities 의 연결이다.
  • Relationship은 관계. 말 그대로 관계다. 합쳐서 말하면 '객체와 관계를 추상화 해 표현한 구조.' 라는 것
• Relationship Set : 비슷한 relationships 의 집합.
  • 관계는 엔터티들 간의 한 건의 연결이고, 관계 집합은 그 연결들의 전체 모음입니다. ER 모델은 두 개 이상의 엔터티를 연결하는 n-ary 관계를 표현할 수 있으며, 같은 엔터티 집합이 여러 관계에 참여하거나 한 관계 안에서 서로 다른 역할을 맡을 수 있다.

Peter Chen ERD에서 알아야하는것

• 네모 : Entities
• 마름모 : Relations
• 타원 : attributes
• 타원 속 밑줄 : primary key
  • pdf 에서는 attribute의 굵은 선 표기로도 하는 듯
• 점선 밑줄 : Partial Key(부분 키)
  • Weak Entity가 가진 속성으로, partial key 하나만으로는 유일하지 않지만 Owner entity의 key와 합쳐지면 유일하게 되는 속성
• 화살표 연결 선 : Key-constrints (키 제약)
• 굵은 연결 선 : Participation Constraints (참여 제약)
• 굵은 마름모: Identifying Relationship (식별 관계)
  • 약한 엔터티(Weak Entity)의 존재를 “정의하는” 관계를 뜻함
• 세모 : ISA hierarchies
  • 하위 엔터티(Subclass)는 상위 엔터티(Superclass)의 모든 속성과 관계를 상속받는다.
• 아주 큰 그룹형 점선 네모 : Aggregation

Key-constrints (키 제약)

• Key-constrints (키 제약)
  • "관계에서 엔터티가 몇 개 연결될 수 있는가”에 대한 제약.
  • pdf 에서 보이는 걸 그대로 설명해보자면, Works_in 관계랑 대조적으로, Manages는, department 에 대해 최대 1명의 manager만 허용하므로, departments 에서 manages 쪽으로 화살표가 나가는 것으로 그것을 표현한다.
    • 근데 내가 이해가 안가는건, departments에서 manages라는 관계쪽으로 화살표를 뻗게 그리는 것이, departments에게 최대 하나의 employee 만 배정하는 것에 대해 직관적으로 어떤 연관관계가 있고, 내가 이 화살표를 보고 대체 그걸 어떻게 알아채고, 또 그 의미를 외워야하냐는 것이다. 왜 이런 표기법을 상상해냈지? 무슨의미로? 의도가뭐지?
      • 이렇게 외우자. 화살표가 뻗어나오는 그 엔티티는, manages 라는 관계안에서 한번만 등장한다. 그러니까 그걸 화살표로 표시하는거다.
      • departments 엔티티에서 manages 관계쪽으로 화살표가 나가는 것의 의미  
        • Department는 Manages 관계 안에서 한 번만 등장할 수 있다.
        • 즉, 1-to many 일때, many 측에서 화살표가 나가는거다.
        • 1-to-1 일 때는 양쪽에서 다 나오고.
        • 완전 이해했다.
        • 내가 이해한 key constraint 는, erd에서, 엔티티 쪽에서 관계 쪽으로 나가는 화살표로 표현하며, 1대 다 관계에서 '다' 측의 엔티티에서 나오는거다. 그리고 그것은 무슨 의미냐면 그 화살표가 나온쪽 엔티티는 그 관계에서 1번만 등장한다는거다. 즉 하나의 상대 엔티티랑만 관계를 맺는다.
          • 근데 Peter Chen 전통식 (정석)에서는 위의 경우 '관계' 에서 '1'쪽 엔티티로 가는 화살표로 저 상황을 표현한다네..음.
          • 교재는 Ramakrishnan & Gehrke) 표기 방식?

Participation Constraints (참여 제약)

• Participation Constraints (참여 제약)
  • 모든 department가 manager을 가져야하는가?
    • 그것이 맞다면, 이건 participation constraint의 일종이다. 그리고 departments 는, manages 관계에 대한 '전체참여'이다. ('부분참여'와는 반대개념임)
    • 관계와 굵은선이 그어진 엔터티의 모든 인스턴스가 반드시 관계에 참여해야 함. 혼자두면 안된다는거야. 이건 쉽죠.

Role indicator & self-relationship

• 같은 엔티티 세트 내에서 다른 역할을 가진다면,
  • self-relationship (자기참조 관계)이면, 연결 선에 Role 을 붙여주어야한다.

Weak entity

Weak entity

• 자기 자신의 속성만으로는 유일하게 구분되지 않고, 다른 엔터티(Owner entity)의 도움을 받아야 식별 가능한 엔티티입니다.

ISA hierarchies

• 말그대로 'is a' 이다. A 'is a' B 라면, A는 곧 B라고 간주할 수 있는것이며, A는 B의 모든 특성(attributes)을 동일하게 가지고 있다.
• 서브클래스에만 해당되는 attribute를 표시해주기 위해서 사용한다.
• 관계에 참여하는 엔티티를 구별하기 위해서도 사용한다.

Aggregation(집합)

• entity set를 포함한 relationship set 와의 관계를 나타내야할 때 사용한다.
• 집합은, 관계세트를, 다른 관계세트의 참여요소로서의 엔티티세트처럼 다룰 수 있게 해준다.

ER 모델을 사용한 개념적 디자인에서 고민할 거리들

• entity vs attribute
• entity vs relationship
• binary? ternary? Aggregation? or other
• binary vs ternary
  • 만약 세 엔터티가 동시에 관계를 맺지만, 그 중 하나가 나머지 둘 사이의 연결고리 역할이라면, ternary보다 binary 관계 두 개로 나누는 게 낫다.
  • 하지만 세 엔터티가 동시에 참여해야 하나의 의미 있는 사건(예: 계약, 구매)이 된다면 ternary 관계가 필수다.
• ternary vs Aggregation