[DB] E-R 모델

임승섭·2023년 4월 8일
0

Database system

목록 보기
2/22
post-custom-banner

ER data model은 database의 전반적인 logical structure를 표현하는 enterprise schema의 구체화(?)를 허용하여 database 디자인을 더 쉽게 한다.

ER diagram은 database의 전반적인 logical structure를 graphically하게 표현한다.


Basic concepts

Entity Sets

  • entity는 다른 객체들과 구별 가능한 하나의 객체이다.
    : specific person, company, event, plant
  • entity set은 동일한 type(같은 특성을 공유)을 갖는 entity들의 집합이다.
    : set of all persons, companies, trees, holidays
  • entity는 속성들의 집합으로 표현된다
    : instructor = (ID, name, salary)
    course = (course_id, title, credits)
  • 속성들의 부분집합은 entity set의 primary key를 형성한다.
    집합의 멤버들을 unique하게 식별할 수 있다.

Relationship sets

  • relationship은 몇몇 entity들 사이의 관계를 의미한다
    : Peltier[44553](in student entity)와 Einstein[22222](in instructor entity)의 관계는 advisor이다.
  • relationship set은 둘 이상의 entity들 사이의 수학적인 관계를 의미한다.
    : (44553, 22222) ∈ advisor
  • relationship set에는 속성이 관련될 수도 있다.
    예를 들어, instructor와 student 사이의 관계인 advisor에는, 지도를 언제 시작했는지 나타내는 date 속성이 있을 수 있다.
    이를 diagram에서는 relationship set에 점선으로 이어붙여서 표현한다.

Roles

  • relationship으로 엮인 entity sets은 꼭 다를 필요가 없다.
    예를 들어, 선수관계를 나타내는 'prereq' relationship은 동일한 entity set인 'course' 두 개를 엮는다.
  • 그래서 entity set (2개지만 하나인) 은 role을 수행한다.
  • 'course_id'와 'prereq_id'로 role의 label을 줄 수 있다.

Degree of a relationship set

  • 대부분의 relationship은 binary이다. (degree two)
  • 2개 이상의 entity set들 사이의 relationship도 있을 수 있다.
  • relationship 'proj_guide'는 instructor, student, project 총 3개의 entity set에 대해 ternary relationship을 갖는다.
  • 일단은 뭐 그럴 수 있다, 하고 넘어간다.

Attributes

  1. Simple or composite
    • simple : 세부 속성이 없다.
    • compoisite : 세부 속성이 있다.
      : name -> (first_name, middle_initial, last_name)
  2. Single-valued of multivalued
    • single-valued : atomic하다.
    • multivalued : 하나의 속성이 여러 값을 가질 수 있다.
      : {phone_number} - 한 사람의 번호가 여러 개일 수 있다.
  3. Derived
    • 다른 속성으로부터 compute된다.
      : 'age'는 'date_of_birth'로부터 계산 가능하다.

Domain : 각 속성에서 허용되는 값들의 집합


Mapping

Mapping Cardinality

binary relationship set의 경우, 4가지의 mapping cardinality가 존재한다

  • One to One
  • One to many
  • Many to One
  • Many to many

cf). 관계가 있는 entity에 대해 적용되는 것이다. 아예 관계가 없는 entity도 있을 수 있다.

Total and Partial Participation

  • Total participation
    • entity set에서 모든 entity는 적어도 하나의 relationship이 있다.
      즉, 모든 entity들이 반드시 참여해야 한다
    • diagram 상에서 선 두개로 표현한다
  • Partial participation
    • some entities는 아무 relationship에도 참여하지 않아도 된다.
  • Example
    : intructor - advisor = student 라고 하면,
    모든 student는 최소한 한 명의 지도교수가 있어야 한다.
    어떤 instructor는 지도학생이 아무도 없어도 된다.

More Complex Constraints

  • diagram의 선 위에 l...h 로 표현할 수 있다.
    l은 minimum, h는 maximum cardinality를 의미한다.
    h에 *로 표시하면, no limit을 의미한다.

  • l = 1이라면, 모든 entity가 적어도 하나의 관계가 있어야 하므로 total participation과 같은 의미로 볼 수 있다.

  • h = 1이라면, 모든 entity는 최대 1개의 관계만 가질 수 있다

Cardinality on Ternary Relationship

  • ternary relationship에서는 최대 한개의 arrow(one 의미)를 사용할 수 있다.

Primary Key

For entity sets

entity set : student (ID, name, dept_name, tot_cred)
entity : (10123, Tom, Physics, 123), (20212, James, Music, 140), ...

  • By def, 각각의 entity들은 모두 distinct하다.
  • database의 관점에서, 그 차이점들은 속성 측면에서 표현되어야 한다
  • entity의 속성이 가지는 value들은 반드시 그 entity를 unique하게 식별할 수 있도록 구성되어야 한다. 예를 들어, 2개의 entity가 모든 속성에 대해 정확히 같은 값을 가질 수는 없다. 즉, 여러 entity는 같은 primary key를 가질 수 없다.
  • 하나의 entity의 primary key는 다른 entity들 사이에서 그 entity를 구분해낼 수 있는 속성의 집합이다.

For relationship sets

relationship set : advisor (instructor - student)
relationship : ( (101, Einstein, Physics, 20000) - (23432, Tom, Music, 141) ), ...

  • 여러 relationship들 사이에서 특정 relationship을 구분하기 위해서는 relationship set으로 엮여있는 entity들의 각각 primary key를 사용해야 한다.

  • Let R := a relationship set involving entity sets E1, E2, ..., En
    (n개의 entity를 엮고 있는 relationship)

  • The set of attributes of R은 각각의 entity sets(E1, E2, ..., En)들의 primary key의 union으로 구성되어 있다. 그리고 이게 R에서의 indiviual relationship을 찾아낼 수 있게 한다.

  • 만약 relationship set R이 이미 속성이 있다면 (이전에 예시로 들었던 date) the set of attributes of R은 그 속성들 또한 포함한다.

  • relationship set의 primary key를 선택하는 방법은 그 relationship set의 mapping cardinality에 따라 달라진다.

    • 엮여있는 모든 entity의 primary key들의 union은 R의 superkey가 된다.

    (1). Many-to-Many

    • union of the primary key가 곧바로 minimul superkey가 된다.
      and is chosen as the primary key.

    • ex).
      (a1, b1)
      (a1, b2)
      (a2, b2)
      (a2, b3)
      (a3, b1)
      (a3, b3)

      이런 식으로 relationship이 있으면, 양 쪽의 정보를 모두 알고 있어야 각 relationship들을 labeling할 수 있다.

    (2). One-to-Many / Many-to-One

    • primary key of the "Many" side가 minimul superkey가 된다.
      and is used as the primary key.

    • ex). (one-to-many) * many-one이랑 one-many랑 헷갈리지 말자
      (a1, b1)
      (a1, b2)
      (a2, b3)
      (a2, b4)
      (a3, b5)

      이 relationship들을 labeling하기 위해서는 many side(b)의 정보가 필요하다

    (3). One-to-One

    • primary key of either one of the participating entity sets가 minumul superkey가 된다. 아무 entity나 선택하면 된다
      and can be chosen as the primary key

    • ex).
      (a1, b1)
      (a2, b2)
      (a3, b3)

      한 쪽 없애고 나머지 한 쪽으로도 모든 relationship을 labeling할 수 있다.

For Weak entity sets

  • section entity

    section
    course_id
    sec_id
    semester
    year
    building
    room_number
    time_slot_id
  • course entity

    course
    course_id
    title
    dept_name
    credits
  • section entities는 course_id, semester, year, sec_id에 의해 unique하게 식별된다.
    section entities는 course entities에 related 되어 있다.

  • section entitiy set과 course entity set 사이에 relationship set 'sec_course'를 만든다고 하자.

  • 그렇다면, 우리가 만들어야 할 sec_course의 정보들(attribute)은 이미 section entity에 다 있기 때문에 정보의 중복(redundant)가 발생한다.

  • 이를 해결하기 위한 방법은, relationship set 'sec_course'를 없애는 것이다.
    하지만 그렇게 되면 section과 course의 relationship이 하나의 속성으로 내포되어버리게 된다. 좋은 방법은 아니다.

  • 해결하기 위한 다른 방법은, course_id라는 특성을 section entity에 저장하지 않는 것이다. 즉, section entity에는 남은 sec_id, year, semester만 저장한다.
    하지만 그렇게 되면, 특정한 section entity를 식별하기 위한 정보(attribute)가 부족해지는 상황이 생긴다.

  • 이 문제를 해결하기 위해, 우리는 'sec_course' relationship을 추가적인 정보를 제공하는 특별한 relationship으로 다룬다.
    이 상황에서는 coures_id를 제공하여, section entity를 unique하게 식별할 수 있도록 한다.

  • weak entity set이란 그 존재가 다른 entity에 의존적인 entity set을 의미한다. 의존하는 entity는 identifying entity라고 부른다.

  • weak entity의 primary key를 관련시키는 대신에, 우리는 identifying entity를 이용한다. 또한 weak entity를 식별하기 위한 나머지 속성들은 discriminator라고 부른다.

  • weak entity가 아닌 entity set은 strong entity set이라고 부른다.

  • 한 번 언급했듯이, 모든 weak entity는 반드시 identifying entity와 associated되어있어야 한다. 즉, the weak entity set is existence dependent on the identifying entity set.

  • identifying entity set은 weak entity set을 own 했다고 부른다.

  • weak entity set과 identifying entity set을 엮어주는 relationship을 identifying relationship 이라고 부른다.

  • 그림 상에서 weak entity set은 두 줄 사각형으로 그어주고, discriminator들은 점선 밑줄로 표시한다.
    주의해야 하는 건, 그림 상에서는 section 안에 sec_id, semester, year밖에 없지만, section의 primary key는 여전히 (course_id, sec_id, semester, year)이다.


Redundant Attributes

  • student

    student
    ID
    name
    tot_cred
    dept_name
  • department

    department
    dept_name
    building
    budget
  • relationship : 'stud_dept'

  • 우리는 각 student가 department와 stud_dept을 통해 엮여 있다는 사실을 model해야 한다.

  • 이 때, student 안에 있는 dept_name 속성은 현재 relationship에 있는 정보를 복제하게 되고, 결국 중복되게 된다...(?)
    따라서, 제거되어야 한다.

  • 이걸 다시 table로 변환할 때, 때때로 속성들이 다시 들어오는 경우가 있다. 나중에 배울거다.

post-custom-banner

0개의 댓글