4. ER to Relational Database Design

Regular Entity Mapping

• Map each Regular Entity to a Relation with all simple attributes

• Unpack composite attribute

  💡

  즉 다시 말해서 name를 따로 column으로 만드는 것이 아니라 나머지만 취급하면 된다는 것이다.

• A primary key can also be a composite key

  ex : country code, car number

💡

아직 multivalued attribute를 어떻게 다룰 지에 대해서는 논의하지 않음

Mapping of one-one Relation

3 possible ways

1. Foreign key : Better to choose an entity with total participation

   → 위 예시의 경우에는 department쪽이 foreign key를 가지는 것이 유리하다는 것이다. 왜냐하면 mandatory이기 때문이다.

2. Merge relation: This may be appropriate if both participations are total. Might lose the context for a logical entity.

   → But in this case, the employee entity partially participated so it is not appropriate for the above example.

3. Build a cross reference table: However, FK option is efficient

Mapping of one-many Relation

2 possible ways

1. Foreign key : Choose an entity having one-sided of the relationship

2. Build a cross reference table: Rarely used

만약 Department에서 employee 정보를 저장하려고 하면 여러 값을 저장해야한다는 문제가 발생한다.

→ relational model은 single value만 허용하므로 이러한 방식으로 처리할 수 없다.

💡

즉 하나에만 대응되는 쪽의 entity에 column을 추가하는 방식으로 이를 처리한다고 생각해주면 된다. (추가는 foreign key를 해주면 된다. 즉 상대방의 primary key를 foreign key로 취급하는 것이다.)

Mapping of many-many Relation

양 방향에서 문제가 발생한다. 왜냐하면 relational model의 경우에는 single value만을 허용하기 때문이다.

→ 그래서 이 경우에는 mapping table 만 가능하다.

SSN	N
1	{p1, p2}
2	p2
3	p1

N	SSN
p1	1
p2	{1, 2}

이 경우에는 employee와 project가 합해져야 unique가 된다.

→ 즉 combinational key인 것이다. 그래서 위 사진에서 works_on table에 underline이 2개 존재하는 것이다.

💡

즉 many to many case만 따로 table을 형성하는 것이다.

💡

즉, TABLE은 relation이다. relationship은 항상 table이 되는 것이 아니라 many to many인 경우에만 relationship이 table로 표현되는 것이다.

Mapping of Multivalued Attribute

Create a new table. This table will have:

1. attribute itself

2. PK of the original table as a FK in the new table

💡

Composite PK of the new table : (PK of original + the Attribute itself)

Weak Entity Mapping

Create a new table having all the attributes. Add a FK attribute of the PK of the owner entity to this new table.

💡

Composite PK of the new table : (PK of original + Partial key of the week entity)

N-ary Relationship

→ 흔한 경우는 아니지만 가능하기는 하다.

Recursive Relationship Mapping

In this case, the supervision relationship is not a many-to-many relationship. Therefore, we can convert it to the relational model by adding one column.

Procedures to ER to DBMS Table

EER to Relational Database Design

In this example, specialization is based on the attribute “Job Type”

Specialization

어느 것이 정답일지에 대한 것은 data의 특성에 따라 다르다.

예를 들어 disjoint한 경우에는 redundant한 data를 추가로 저장해야한다는 단점이 있다.

→ 만약 table을 다르게 저장한 경우에는 query를 날리는 과정에서 서로 다른 table를 joint해야하는데 이게 overhead가 크다.

Generalization

Disjoint participation

💡

However, it only works for total participation

Overlapping participation

MFlag와 PFlag를 일종의 boolean flag 처럼 쓰는 것이다.

→ 이러한 flag가 없으면 나머지 field가 NULL인 경우 어떤 것에 속하는지 판단할 수 없게 된다.

💡

물론 이러한 접근 방법은 겹치는 것이 많을수록 좋은 접근 방법이다.