DBMS: ER Diagram ~ 관계 모델 변환

INTRO 🙌

저번 시간에는 관계 모델에 대하여 알아보았다.

이번 시간에는 생성한 ER Diagram을 Relation Model/Design으로 변환하는 방법에 대해 알아보자.

---

ER Diagram ~ Rel. Design 변환 ✔

일반

1. Entity set E

    CREATE TABLE Employees
        (ssn CHAR(11),
        name CHAR(20),
        lot INTEGER,
        PRIMARY KEY (ssn))

• 규칙: Relation with attributes of E

2. Relationship R

    CREATE TABLE Works_In(
            ssn CHAR(1),
            did INTEGER,
            since DATE,
            PRIMARY KEY(ssn, did),
            FOREIGN KEY(ssn) REFERENCES Employees,
            FOREIGN KEY(did) REFERENCES Departments
    )

• 규칙:
  • 1. Relation with attributes being keys of related entity sets (외래 키로 표현)
  • 1. All descriptive attributes of R

개체의 기본키 값들이 Relation에서 해당 개체 이름에 포함된다 (i.e., Product-name).

관계에 붙어있는 속성은 그대로 표현되는 모습이다 (i.e., Start-year).

또 다른 예시를 살펴보자.

가령, Likes‘라는 관계는 Drinkers ~ Beers를 연결하기 때문에, ‘Likes(drinker, beer)’로 ER Digram에서 해당 관계에 대한 관계 모델을 정의하는 모습이다.

특수

1. Many-one Relations

[Relation Makes]

Makes는 일대다 관계, 즉 Many(Products) ~ One(Company)로 구성되어 있다.

이 경우, Many(Product)에 종속된 속성들과 One(Company)의 기본키 값을 가지고 관계 모델을 설계한다.

💣 Risk with Many-Many Relationships

다대다 관계(Drinkers(=name) ~ Beers)에서, Likes 관계 연결 시 addr 속성에서 Redundancy가 발생하는 모습

2. Two Relations

Drinkers(name, addr) + Favorite(drinker, beer) ☞ Drinker1(name, addr, favoriteBeer)

서로 다른 두 관계 Drinkers, Favorite가 하나의 관계 Drinker1로 합쳐지는 모습이다.

3. Weak entity sets

[Relation Team]

규칙

• 약한 개체 Team의 모든 속성을 포함시켜야 한다.
  • complete key 속성들을 반드시 모두 포함시킨다.
  • 약한 관계(이중 다이아몬드)는 불필요하며, 관계를 생성하지 않는다.
• 상기 ER Diagram에서, 관계 Affiliation을 위한 별도의 관계 모델은 필요없다.
  • 약한 개체와의 연결은 무시
  • 상기 관계 모델은 Team 개체 관계 모형이다.

Complete Key: 한 개체 스스로에 종속된 속성, 연결된 다른 개체에 종속된 속성, 키가 없는 속성 등 모든 종류의 속성들을 일컫는다.

4. is-a relationships(= subclasses)

Option 1: the OO Approach

Object-oriented

• Each entity belongs to exactly one class; create a relation for each class, with all its attributes.

상기 ER Diagram로부터 4개의 서로 다른 테이블이 만들어질 수 있다: Product, EducationalProduct, SoftwareProduct, 그리고 EducationalSoftwareProduct.

각 테이블마다 연결된 속성들로 관계 모델을 설계해보자.

    Product(name, price, category, manufacturer)

    EducationalProduct(name, price, category, manufacturer, ageGroup, topic)

    SoftwareProduct(name, price, category, manufacturer, platforms, requiredMemory)

    EducationalSoftwareProduct(name, price, category, manufacturer,ageGroup, topic, platforms, requiredMemory)

All names are distinct

여기서 주목할 점은 테이블마다 존재하는 name 속성은 서로 다른 고유한 객체들이다.

이름이 우연히 같을 수는 있지만, 그들은 엄연히 다른 개체들이다.

O-O approach good for queries like “find the color of ales made by Pete’s.”

• Just look in Ales relation

Option 2: the E/R Approach

E/R style

• Create one relation for each subclass, with only the key attribute(s) and attributes attached to that E.S.; entity represented in all relations to whose subclass/E.S. it belongs.

is-a hierarchy 구조를 가지는 ER Diagram을 관계 모델로 변환할 때, 부모 개체가 포함하는 속성을 자식 개체가 중복해서 담을 필요는 없다.

    Product(name, price, category, manufacturer)

    EducationalProduct(name, ageGroup, topic)

    SoftwareProduct(name, platforms, requiredMemory)

상기 관계 모델에서, 테이블 EducationalSoftwareProduct은 존재하지 않는 모습인데, 이는 해당 테이블에 종속된 속성들이 이미 다른 테이블에 전부 존재하기 때문이다.

만약 해당 테이블만이 가지는 고유한 추가 속성이 없다면, EducationalSoftwareProduct 관계 모델은 더이상 필요없을 것이다.

가령, 하기처럼 educational-method라는 추가 속성이 존재한다면, 해당 테이블 역시 관계 모델에 추가한다.

    EducationalSoftwareProduct(name, educational-method)

E/R approach good for queries like “find all beers (including ales) made by Pete’s.”

• Just look in Beers relation.

Option 3: The Null Value Approach

Use nulls

• Create one relation; entities have null in attributes that don’t belong to them.

하기 관계 모델에서 몇몇 속성은 NULL 값을 가질 수 있다.

    Product(name,  price,  manufacturer, age-group, topic, platforms, required-memory, educational-method)

Using nulls saves space unless there are lots of attributes that are usually null.

---

Summary ✨

Basic cases

• entity to table, relation to table
• selecting attributes based on keys

Special cases

• many-one relation can be merged
• merging many-many is dangerous
• translating weak entity sets
• translating isa hierarchy
  • 3 choices, with trade-offs

다음 시간에는 SQL(Structured Query Language)에 대해 알아보자.

---

Reference

Database Management Systems by Raghu Ramakrishnan and Johannes Gehrke