[데이터베이스] CH6. Database Design Using the E-R Model

0. INTRO

1. Design Phases

1. Initial phase : 데이터베이스 사용자가 필요로 하는 데이터를 파악하기
2. Second phase : conceptual design
   • data model을 선택해서 개념을 적용한다.
   • requirements를 데이터베이스의 conceptual schema로 변환한다. (ex. ER Model)
   • 개발이 완료된 conceptual schema는 기업의 기능 요구 사항을 나타낸다.
3. Final Phase : 추상적인 data model을 기반으로 구현하기
   • Logical Design : 데이터베이스의 스키마를 결정한다. (conceptual schema(er diagram)을 logical schema(relational schema)에 대응시킨다)
   • Physical Design : 데이터베이스의 물리적 구조를 결정한다.

2. Design Alternatives

데이터베이스 schema 디자인을 할 때엔 다음과 같은 두가지 사항을 꼭 피하도록 만들자

• Incompleteness : 불완전성. 설계가 잘못되면 기업의 특정 부분을 모델링하기 어렵거나 불가능할 수 있다!
• Redundancy : 중복성. 정보의 중복은 지양하자. 중복으로 인해 여러 copy본의 데이터의 불일치가 일어날 수 있다.

물론, 이 bad designs을 피한다고 끝은 아님. 우리가 선택해야 할 좋은 디자인이 매우매우 많음

3. Design Approaches

• entity relationship model
  : entity및 relation의 집합으로 enterprise를 모델링한다.
  • entity : enterprise에서 다른 objects랑 구분되는 'thing' 또는 'object'
  • relationship : entity간의 연관성
    _entity-relationship diagram_으로 도식화되어 표현됨.
    _Normalization Theory_로 어떤 디자인이 나쁜지 공식화하고 테스트 함.

1. Outline of ER(Entity- Relationship) Model

• ER data model은 데이터베이스의 설계를 용이하게 하기 위해 개발 되었다.
  데이터베이스의 논리적 구조를 나타내는 enterprise schema의 specification을 허용함
• ER data model = entity sets, relationship sets, attributes로 구성됨
• ER model은 ER diagram이라는 다이어그램 표현과도 연관되어 있다. 이것은 데이터베이스의 전체 논리적 구조를 graphically하게 표현할 수 있다.

1. Entity sets

• entity는 다른 objects와 구분되는 하나의 object.
• entity sets은 같은 type이나 properties를 가진 엔티티들의 집합!
• 하나의 엔티티는 attribute의 집합으로 표현할 수 있다.
  ex. instructor = (ID, name, salary)
• attribute의 부분집합은 entity set의 primary key를 구성할 수 있다.

Representing Entity sets in ER Diagram

1. entity set은 직사각형으로 나타낸다
2. attributes는 직사각형 안에 나열해서 작성한다.
3. primary key인 attribute 에는 밑줄을 긋는다.

   

2. Relationship sets

• relationship은 entity들의 association!!
• 하나의 relationship set는 n>=2인 entity간의 수학적 relation이다.

ex ) (45522, 32321) ∈ advisor

• 그림으로 그리면 related entity끼리 선을 그어줄 수 있다.

  

Representing Relationship sets via ER Diagrams

Diamond = relationship sets

+) relationship set와 attribute를 연결할 수도 있음.
예를 들어, instructor과 student 사이에 advisor라는 relationship이 있다고 했을 때,
이들이 연결되기 시작한 시점을 attribute로 가질 수 있다.

Roles

• 같은 entity 안에서의 relationship을 말함 (꼭 서로 다른 엔티티일 필요 X)

  

Degree of a Relationship set

1. Binary relationship
   • 두 개의 entity를 가지고 있음
   • 대부분의 디비 시스템의 relationship set는 binary임
   2. Non-binary relationship sets
      물론 세 개 이상의 entity set을 갖는 경우도 드물지만 있다.
      ex) student는 instructor 아래에서 project를 진행한다. (삼원관계)

      

3. Complex Attributes

Attribute types

• simple and composite attributes
  ex) 주소 : composite attributes (시, 동, 상세주소 ..)
• singled-valued and multivalued attributes
  ex) 폰 번호 : multivalued attribute
• derived attributes : 다른 attribute로 부터 얻어지는 것
  ex) 생일 --> 날짜

  

Domain : 각 attribute가 가질 수 있는 값의 집합

4. Mapping Cardinality Constarints

참고 ) ER Diagram 에서는 one = 화살표, many = 직선 으로 표시한다.

One to one

One to many

instructor에는 여러명의 학생(0~n명)이 있고
student에는 최대 한명의 교수자가 연결된다.

Many to one

반대로 instructor당 학생 한 명,
학생 한 명당 instructor 여러 명

Many to many

헷갈리면 그림을 그려놓고 생각하자. many 쪽이 여러개 !!!
선으로 보면 one 하나에서 many쪽으로 선이 여러개로 감.

5. Total and Partial Participation

Total participation (두 줄) : 모든 entity가 반대편 다른 entity와 무조건 하나씩은 연결되어야 함.

모든 학생은 무조건 최소 한 명의 instructor과 연결되어야 함.

Partial participation : 연결될 수도 있고 아닐 수도 있음

교수님은 student를 배정받지 않아도 됨

좀 더 복잡한 constraints

-> 연결할 relation의 최대/최소 개수를 지정해서 쓸 수 있다.

0.. * : partial
1..1 : 최대 연결이 1인 total

6. Primary key

1. Entity sets

Key of an entity : 엔티티를 서로 구별할 수 있는 attribute의 집합
super key -> candidate key -> primary key

entity set의 두 entity는 모든 attribute에 대해 동일한 값을 가질 수 없다. 식별 가능해야 한다.

2. Relationship sets

• relationship set의 여러 relation을 구분하기 위해서 relation set에 있는 entity들의 primary key를 사용한다.
• mapping cardinality에 따라 primary key 선택이 달라진다.

1. Many-to-Many : 양 쪽의 primary key를 둘 다 사용한다.
2. One-to-Many : Many 쪽에 있는 primary key를 사용한다.
3. Many-to-One : Many 쪽에 있는 primary key를 사용한다.
4. One-to-One : 둘 중 하나 고르면 된다.

Cardinality Constraints on Ternary Relationship

• cardinality constraints는 binary 뿐만 아니라 3 이상의 ternary relationship에서도 쓸 수 있다.
  이 때 화살표는 하나!
  ex) proj_guid에서 강사로의 화살표는 각 학생이 프로젝트에 대해 최대 한 명의 가이드를 가지고 있음을 나타냄
• 화살표가 만약 두 개 이상인 경우 두 가지 방법으로 의미를 정할 수 있다. 
  1. 각 A entity는 고유한 B와 C entity와 연관되어 있다.
  2. (A, B)의 각 entity 쌍은 고유한 C entity와 연결되고, (A,C)는 고유한 B entity와 연결된다.
  --> 이런 혼란을 막기 위해 화살표는 하나만!!!! (one은 하나만!!)
• ->C
• ex) A->B

3. Weak entity sets

• section entity와 course entity가 있고, 이 둘을 잇는 sec_course relation을 생각해보자.
  이미 section에는 course_id가 있기 때문에 sec_course를 만들 경우, 정보가 중복되게 된다.
  그렇다고 해서 sec_course를 없애고 section과 course간의 관계가 attribute에만 명시되게 만드는 것은 바람직하지 않다.
• 대안책은 course_id attribute를 section entity에 추가하지 않고 나머지 특성만 추가해 명시하는 것이다.
  근데 이대로 놔두면 특정 entity를 식별할 수가 없다. attribute가 부족하니까!
• 이 해결책이 바로 weak entity set임
  sec_course를 section entity를 식별하기 위해 필요한 course_id를 제공하는 특수 관계로 만드는 것임.
• weak entity set은 어떤 entity에 종속된 entity를 말함.
  weak entity와 primary key를 associating하는 대신, weak entity를 식별 가능하게 해주는 discriminator라고 불리는 추가 attributes와 identifying entity를 사용할 것임. (weak entity 안에서의 primary key = discriminator 라고 보면 될 듯)

Strong entity set : weak entity set 이 아닌 모든 entity set

• 모든 weak entity는 식별 가능한 다른 entity set과 연관되어 있어야 한다. 즉,
  existence dependent on the identifying entity set 이다.
• Identifying entity set은 weak entity set을 own 한다고 표현한다.
• 그리고 이런 weak entity set과 identifying entity를 연결하는 relation을 Identifying relationship 이라고 한다.

Expressing Weak entity sets

• ER Diagram에서 weak entity set은 double 직사각형으로 표현됨 (두 줄의 직사각형..)
• discriminator아래엔 점선을 그어줌
• weak entity set과 strong entity set을 이어주는 relation은 double diamond로 표시함

  

2. Reduction to Relation Schemas ( ER Diagram -> Schemas Diagrams )

1. Representing Entity sets

1. Strong entity set : same.. 그대로 만드셈
   Weak entity set : 원래 그 attribute들에 자신이 속한 entity의 primary key 를 가져와서 table을 만듦
2. Composite attributes : 가장 하위의 attribution을 모아서 사용한다. ex. name -> first_name, last_name
   derived attributes : 그냥 없애버림.
3. multivalued attributes : 새 테이블을 만든다.
   entity E의 multivalued attribute M 이 있을 경우, E의 Primary key와 M의 attribute를 가지고 새 테이블을 만든다.
   ex) inst_phone = (ID, phone_number)

2. Representing Relationship Sets

1. Many-to-many relationship set의 경우, 두 entity sets의 primary keys로 table을 구성한다.
2. One-to-many relationship set는 many 쪽에서 primary key만 있으면 된다.
3. One-to-one은 둘 중 아무거나 선택해도 상관 없다.

Redundancy of Schema

Many 쪽이 total인 Many to one이나 one to many relationship sets의 경우, one side의 primary key를 many side에 추가해주는 것 만으로도 둘의 관계를 나타낼 수 있다. 즉, 새 테이블 안만들고 attribute만 추가해주면 됨. primary key도 굳이 안바꿔도 됨.

One-to-one 관계에서는 둘 중 하나의 primary key를 다른 한 쪽에 추가해 주면 됨.
만약 many side에서 total이 아닌 partial일 경우에 이 many side 쪽에서 attribute를 추가할 경우 null 값이 채워질 수도 있음

• weak entity set과 strong entity set을 연결하는 relationship에 해당하는 schema는 redundant하다!

3. Extended ER Features

1. Specialization

Top-down design process : entity 내에서 sub-groupings을 지정하는 것..?

• sub grouping은 상위 레벨 entity에는 적용되지 않는 attributes나 participate를 가진 lower-level entity sets이 왼다.
• ISA라는 이름의 triangle component로 표현된다.
• attribute inheritance : lower level entity들은 high level entity의 모든 attribute와 relationship participation을 상속 받는다.

ISA 관계에는

Overlapping : 두 개의 속성이 동시에 가능 (겸하기 가능)

Disjoint : 무조건 둘 중 하나. 동시 불가.

Representing Specialization via Schemas

Method 1

• higher level entity 를 schema로 구성한다.
• lower level entity를 schema 구성한다. 이 때 higher-level의 primary key를 포함한다.
• 따라서 하위에서 상위 정보를 가져오려면 join 해야한다.
• 그렇기 때문에 단계가 깊어질 수록 비효율적이다.

  

Method 2

• 하위 레벨에 상위 레벨 정보까지 그냥 싹 다 저장한다.
• 정보의 중복이 일어나지면 join 할 필요는 없어진다.

  

2. Generalization

A bottom-up design process : 하위 entity set을 이용해 공통 분모를 찾아서 상위 entity를 구성한다.
구성된 결과는 specialization과 같다.

Completeness constraint

high-level entity set이 무조건 lower-level entity set에 속해야 하는지를 지정한다.

• total : 무조건 lower-level entity sets 중 하나엔 속해야 함
• partial : 안 속해도 됨. 그 lower leve entity 외의 다른 것이 있을 수 있음partial generalization이 기본이다.

• 화살표에 'total'이라고 적음으로서 ER Diagram 상에 표시할 수 있다.
• generalization은 하위 entity set의 공통점으로 만들어진거라 거의 대부분은 total이다.

4. Design Issues

1. Common Mistakes in ER Diagram

• incorrect use of attribute (redundancy)
• erroneous use of relationship attributes (multivalue)

Entities vs attributes

1. entity set 사용 : entity 쪼개기. (한 entity가 여러 entity를 가질 수 있음)
2. attribute 추가 : single value

Entities vs Relationship sets

• relation으로 명시적으로 이을지, 아니면 바로 이을지 결정
• entity 간에 일어나는 action은 relationship으로 지정하라는게 일단 권장됨.

Binary vs Non-binary relationships

• non binary relationship은 여러 구분된 binary relationship sets로 만들 수 있긴 한데, n-ary relationship이 각 entity들이 하나의 relation에 참여한다는 것을 잘 보여줌
• 어떤 relationship은 non-binary보다 binary 쓰는 것이 좋을 수 있음

ex. parent라는 ternary relationship : child, father, mother
이건 두개의 binary relation으로 쪼갬 . child - father / child - mother

근데 뭐 다 되는 건 아님

Convertubg Non-binary Relationship to Binary form

• 일반적으로 non binary 관계는 binary 관계를 이용해 나타낼 수 있다.
• A,B,C 사이의 Relation R을 entity set E로 바꾸고, relation을 A-E, B-E, C-E로 쪼갠다.
• E에 identifying attribute를 추가하고, R의 attribute를 E에 추가한다.

  

ER Design Decisions

1. 어떤 object를 나타내기 위해 attribute를 추가할 것인지, entity set으로 나타낼 것인지
2. 실제 세계의 개념을 entity set또는 relationship set 중 무엇이 가장 잘 표현할 수 있는지
3. ternary relationship 을 쓸 것인지 binary relationship을 쓸 것인지
4. strong 또는 weak entity set의 사용
5. specialization 또는 generalization의 사용