[CS][데이터베이스설계와질의] Chapter02. The Entity Relationaship model

 

---

 

 

 

Overview of Database Design

•  Conceptual Design
  • ER model이 여기서 사용됨
  • entity 와 realtionship이 어떻게 되는지
  • 우리가 DB에 저장해야 할 entity 와 relationship 의 정보가 어떻게 되는지
  • integrity constraints 혹은 business rules가 무엇인지
  • ER model의 DB인 schema는 그림으로 표현되어야 한다
  • ER diagram을 relational schema에 매핑할 수 있다

 

 

 

ER Model Basics

• Entity
  • 객체
  • 실세계 object
  • attribute의 집합을 이용해 entity 서술
• Entity set
  • 비슷한 entity의 집합
  • Entity set의 모든 entity는 동일한 attributes 집합을 가진다
  • Entity set이 완전히 분리될 필요 없다
    • Ex.John은 장난감 부서 직원의 모임과 기계 부서 직원의 모임데 모두 포함될 수 있다, 이 경우 두 부서 직원 모임을 모두 포함하는 employess라는 entity set을 정의할 수 있다
  • 각 entity set에는 entity identifier(key)가 있다 → entity끼리 구분하기 위해
• Attribute
  • entity가 가지고 있는 것
  • entity가 attribute로 묘사된다
  • entity에 관한 정보를 얼마나 상세하게 표현할 것인가 하는 정도를 반영
  • 구조가 다르면 설계도에 나타내야 한다
  • 각 attribute에는 domain이 있다
    • domain은 결국 type, 분량 등
• Type
  • Atomic vs Composite
    • sub component가 없음 vs sub component가 있음
  • Single-valued vs Multi-valued
    • 값이 1개 vs 값이 여러개
  • Stored vs Derived
    • 반드시 저장 vs 저장 할지말지(점선)
  • Relational model은 오직 atomic과 single-valued만 허용
• Relationship
  • 2개 이상의 entity들의 관련성

 

• Relationship set
  • 유사한 relationship들의 집합
  • attribute를 가질 수 있음
  • n차 relationship은 
  • 같은 entity set은 서로 다른 relationship set에 참여하거나 같은 relationship set의 다른 role에 참여할 수 있음

Works_In이 relationship set

 

 

 

Mapping Constraints (Cardinality Ratio)

• Entity가 몇 대 몇인지
• 관계를 맺는 두 entity에 대해, 한 entity가 얼마나 많은 다른 entity와 관련될 수 있는지를 나타내는 제약조건

 

 

 

Participation Constraints

• total vs partial
  • total : 굵은 줄이나 두 줄로 표현, 모든 부서에 매니저가 있어야 한다, Departments의 테이블의 모든 did 값이 Manage 테이블의 행에 나타나야 한다(ssn)
  • partial : 일반적인 줄로 표현, Manages에서 각 직원이 모두 하나의 부서를 관리하지 않음

 

 

 

Weak Entites

• Entity의 한 종류
• 다른 (owner) entity의 primary key를 고려해야 한다
  • owner : 어딘가에 달려 있는, 소속되어 있는
• weak entity의 key = key of owner entity + partial key
  • 둘 다 봐야 구별 가능 
  • 자기 자신은 key가 없어 구별 X
• owner entity : weak entity = 1 : N
  • weak entity가 다른 곳에 달려 있어야 한다
  • dependent가 많은 employees를 가지는 것이 불가능하다
• weak entity set은 identifying relationship set에서 total 참여를 가져야 한다
• owner entity를 삭제하면 weak entity도 삭제된다 = existence dependency

 

 

 

Conceptual Design Using the ER model

• Design Choices
  • 설계는 주관적이다 (subjective)
• Constraints in the ER model
  • 몇몇 constraints는 ER diagram에서 확인되지 않을 수 있다
  • 많은 데이터 의미를 열심히 찾아내야 한다
• Entity vs Attribute
  • 어떻게 쓰일지, 어떤 부분이 중요한지에 따라 객체로 할지 속성으로 할지 다르다

 

 

 

ISA ("is a") Hierarchies

• "A is a B" 라고 선언한다면 A의 모든 Entity는 B의 Entity로 간주
• A는 B의 subclass
• B는 A의 superclass
• class Hierarchy 이야기
  • Generalization: Bottom up, 공통 사항을 이야기, 여러 entity set 사이에서 공통되는 attribute를 찾고 그 공통된 attribute만으로 구성된 entity set을 생성, subclass 정의 후 superclass 정의
  • Specialization : Top down, unique한 사항을 이야기, superclass의 모든 attribute를 상속하고 추가, superclass 정의 후 subclass 정의
• 사용 이유
  • 클래스 간간의 관계 표현을 위해
  • 특히 overlap 되는 것에 관해서
  • subclass에 고유한 attributes 추가
  • relationship에 속한 entity를 구별하기 위해
• Constraints
  • Overlap constraints
    • 두 subclass가 같은 entity를 포함하는 것이 허락되는가
    • Ex. 어떤 사람이 Hourly_empo이면서 Contract_empo 일 수 있는가? → X
    • Allow → o를 쓰고 원 그리기
    • Disallow → d를 쓰고 원 그리기
  • Covering constraints
    • 모든 subclass의 entity들이 superclass의 모든 entity를 포함하는가 결정
    • Ex. employees entity들은 subclass 중 1개에 반드시 속해야 하는가? → X
    • Yes → 굵거나 2개의 선 쓰기
    • No → 얇거나 1개의 선 쓰기

 

 

 

Aggregation

• 어떤 relationship set가 다른 relationship set에 참여하는 것을 나타낼 때 사용

 

 

 

Summary of Conceptual Design

• Conceptual Design은 requirements analysis를 따른다
• ER model은 conceptual design으로 유명하다
• ER model에는 여러 가지 변형이 있다
• Basic constructs
  • entities, relationships, attributes
• Some additional constructs
  
  • weak entities, ISA hierarchies, aggregation

 

 

 

Summary of ER

• ER model은 integrity constraints를 표현
  • mapping cardinality constraints, participation constraints, overlap/covering constraints for ISA hierarchies
• relationship set 정의에 foreign key constraints가 포함
• 일부 constraints은 ER model에 표현 불가능
• contraints는 적합한 DB를 디자인하는 데에 중요
• ER 설계는 주관적 (아래 중 적절한 것을 골라 설계)
  • Entity vs. attribute, entity vs. relationship, binary or n-ary relationship, whether or not to use ISA hierarchies, and whether or not to use aggregation
• 좋은 DB 설계를 위해서 결과적인 relational schema를 더 분석하고 정교화 해야 함

 

---