Database

[Database] Entity-Relationship Data Model

dh_0e 2025. 6. 2. 17:37

Entity-Relationship Data Model

  • ER 데이터 모델은 DB를 개체와 관계로 모델링함 (+속성 Attribute)
  • ER 데이터 모델의 모델링 원소는 개체와 관계이며, 두 개 모두가 특성으로 속성만 가짐

출저: https://victorydntmd.tistory.com/126

 

Entity / Entity Set (Entity Type)

  • 개체란 구별이 가능한 객체를 의미하며, 데이터베이스에 저장/관리하고자 하는 어떤 객체도 개체가 될 수 있음
  • 위 예시에서 학번, 이름, 학년 3개의 정보가 모두 같은 학생이 오직 한 명이면 이를 Entity(개체)라 함
  • 이 개체들의 집합을 Entity Set(Entity Type)이라 하며 위 예시에선 Student, Course가 이에 해당
  • ER 다이어그램에서 네모로 표현함

새로운 예시

 

Relationship, Relationship Set (Relationship Type)

  • Entity set 내의 개체는 다른 set과 relationship이 있을 수 있음
  • 첫 번째 예시에서 student set과 course set이 takes라는 relationship set으로 연결되어 있음
  • 관계성은 수학적으로 표현하면 각 개체 집합에 속하는 개체의 나열로 표현 가능
  • 관계성 중에서 같은 속성을 가지는 관계성을 relationship set(relationship type)이라 함
  • ER 다이어그램에서 마름모로 표현

Relationship Set Example

  • 관계성 집합 또한 개체 집합과 마찬가지로 속성을 가질 수 있음
  • 위 예시에서 takes 관계성 집합은 학기 및 연도를 속성으로 가지고 있음

 

Degree of a Relationship Set

  • 관계성 집합 차수는 관련되는 개체의 개수를 의미함
  • 위 예시는 이진(Binary) 관계성
  • 3진/4진/5진 또한 이론적으로 가능하지만 2진이 가장 흔함  

 

Attributes

  • 속성은 개체 또는 관계성이 가지는 특성으로 서술적인 사항
  • 단순 속성(simple attribute)과 복합 속성(composite attribute)으로 구분할 수 있음

 

Composite Attribute

  • 복합 속성은 속성을 여러 가지 가지는 것을 의미

  • name은 이름, 중간 이름, 성으로 구성된 복합 속성
  • 복합 속성 address는 거리, 도시, 도, 우편 번호로 구성되며, 거리는 다시 거리번호, 거리명, 아파트번호로 구성이 되는 복합 속성

 

Cardinality Constraints

  • 관계를 맺는 두 Entity Type에 대해, 한 개체가 얼마나 많은 다른 개체와 관련될 수 있는지를 나타내는 제약 조건 
  • 카디날리티 제약은 이진 관계성 집합에서 유용하며 다음과 같이 4가지가 있음
    • One to One
    • One to many
    • Many to One
    • Many to many

 

 

Keys

  • Super key -  특정한 튜플(행)을 유일하게 식별하는 하나 또는 여러 개의 속성들의 집합
  • Candidate key - 특정한 튜플(행)을 유일하게 식별하는 최소한의 속성 집합으로 후보 키 중에서 집합의 개체 수가 최솟값인집합들을 말함
  • Primary key - 후보 키 중 하나를 기본 키로 선택하여 각 데이터를 고유하게 식별하는 용도로 사용 

출처: https://www.geeksforgeeks.org/types-of-keys-in-relational-model-candidate-super-primary-alternate-and-foreign/

 

Keys for Relationship Sets

  • 관계성 집합의 슈퍼 키는 참여하는 개체 집합의 주 키(primary key) 조합으로 구성
  • ex) takes 관계성 집합에 student의 주 키가 studentID, course의 주 키가 courseID라고 했을 때 (studentID, courseID)는 takes 관계에 대한 슈퍼 키가 됨
  • 이 조합이 슈퍼 키가 된다는 것은 학생 하나와 과목 하나 사이에 오직 하나의 관계만 존재한다는 뜻
  • >> 같은 학생이 같은 과목과 여러 번 관계를 맺는 것은 허용되지 않음 (중복 관계 금지)  
  • 슈퍼 키에서 후보 키 및 주 키를 선정할 때에는 카디날리티 제약(1:1, 1:N, N:M) 및 참여 제약(전체 참여인지 부분 참여인지)을 고려해야 함
    • ex) 1:N 제약 관계에서 N쪽 개체의 외래 키가 deptID처럼 유일하지 않고 학생들이 공유하는 속성이라면 후보 키 불가
    • ex) 없는 학생이 있을 수 있는 부분 참여 속성인 email보다 모든 학생이 가지고 있으며 중복이 불가한 sID가 주 키에 적합

ER Diagrams

  • ER 모델의 결과물로 사각형은 entity set(개체 집합)을, 마름모는 relationship set(관계성 집합)을 표현
  • 밑줄은 primary key 속성을 의미하며 속성은 사각형 안에 나열함

Entity Example

  • 복합 속성을 가진 Employee 개체 예시
  • name은 firstName, middleNameInitial, lastName을 가진 복합 속성
  • address는 street, city, state, zipCode를 가진 복합 속성이며 street 또한 복합 속성
  • phoneNumber는 하나 이상의 값을 가진 다수값 속성
  • age는 dateOfBirth 속성으로부터 값을 가져와 유도되는 속성

속성을 가진 관계성 집합 takes

  • 위 예시와 같이 takes라는 관계성 집합이 date라는 속성을 가지게 되면 외래키를 포함한 별도의 테이블로 표현됨
Takes(sID FOREIGN KEY REFERENCES Student(sID),
      cID FOREIGN KEY REFERENCES Course(cID),
      date,
      PRIMARY KEY (sID, cID))

 

 

Cardinality Constraints (카디날리티 제약)

  • 카디날리티 제약에서 화살표는 일(One)을 의미하며, 화살표가 없는 선은 다(Many)를 의미함
  • 예를 들어 다음과 같은 ERD에서 관계성 집합 advise는 N:1 제약을 가짐

  • N은 다수를 의미하지만 0도 포함
  • 여러 명의 교수가 한 학생을 관리한다는 의미

 

Particicpation Constraints (참여 제약)

Total participation (전체 참여)

  • 이중선으로 표현됨
  • 모든 개체가 적어도 한 관계성 집합에 참여해야 함

Partial participation (부분 참여)

  • 단일선으로 표현됨
  • 개체가 아무 관계성 집합에 참여하지 않을 수도 있음

Constraint Example

  • student:course는 M:N 구조를 띄며 student 개체는 Partial participation으로 takes에 참여하지 않는 학생이 존재할 수 있음
  • course는 Total participation으로 모든 과목이 takes relationship에 참여해야 하며 즉 학생이 수강하지 않는 과목이 없어야 함

 

Cardinality Constraints on Ternary Relationship (3진 관계성 집합 카디날리티 제약)

  • 3진 관계성 집합에서 카디날리티 제약은 표기가 가능하지만 1에 대응이 되는 개체 집합을 최대 하나만 허용함
    • 모호성과 일관성 문제를 피하기 위함임
    • 두 개의 개체 집합이 1에 대응되면, 나머지 하나의 개체가 두 개의 개체 쌍에 대해 1:N 관계를 갖는 2진 관계와 똑같은 의미가 되어버리기 때문
  •  위 예시는 professor가 1에 대응되며 한 교수가 여러 프로젝트와 여러 학생들을 관리한다는 의미

 

Roles (롤)

  • 동일 개체 집합이 두 번 이상 관계성 집합에 참여를 하는 경우에 참여에 대한 의미를 구분하기 위하여 Role(롤) 표시를 함

Role Example

  • 상기 다이어그램에서 과목 개체 집합은 prerequisiteOf 관계성 집합에 2번 참여함
  • prerequisite >> course 방향으로 생각해서, "prerequisite는 course의 선수 과목이다" 
  • 과목 참여는 1에 대응되며 선수 과목 참여는 N에 대응이 되므로, 한 과목에 선수 과목이 다수가 있음을 의미함
  • recursive(재귀)를 표현하는 것과 동일한 의미
  • 또한 모든 참여가 부분 참여이므로 모든 과목에 선수 과목이 있지는 않으며, 모든 과목이 선수 과목으로 참여하지도 않음 
-- 강의 테이블
Course(
    CourseID   PRIMARY KEY,
    title      VARCHAR,
    level      INT,
    credits    INT
)

-- 선수과목 관계 테이블
Prerequisite(
    CourseID        INT,  -- 본 과목
    PrerequisiteID  INT,  -- 선수 과목
    PRIMARY KEY(CourseID, PrerequisiteID),
    FOREIGN KEY(CourseID) REFERENCES Course(CourseID),
    FOREIGN KEY(PrerequisiteID) REFERENCES Course(CourseID)
)

Role Example2

  • 상기 다이어그램에선 people 개체가 spouse 관계성에 1:1 제약으로 부분참여를 하고 있음
  • people 개체 중에는 배우자가 없는 사람도 있으며, 배우자가 있어도 한 명이라는 관계를 보여줌
-- 사람 테이블 (기본 엔터티)
people(
    ID        PRIMARY KEY,
    name      VARCHAR,
    address   VARCHAR,
    age       INT
)

-- 배우자 관계 테이블 (자기참조 관계)
spouse(
    husband   INT,  -- people.ID 참조
    wife      INT,  -- people.ID 참조
    PRIMARY KEY(husband, wife),
    FOREIGN KEY(husband) REFERENCES people(ID),
    FOREIGN KEY(wife) REFERENCES people(ID)
)

 

Weak Entity Sets (약한 개체 집합)

  • primary key가 없는 개체 집합을 약한 개체 집합이라 함
  • 이는 강한 개체(identifying entity)에 의존적이며 강한 개체 존재 없이는 존재할 수 없음
  • 이들 간에 존재하는 관계성은 identifying relationship(구분하는 관계성)이라 하며 약한 개체는 반드시 전체 참여이며 N:1의 관계를 띔
  • 강한 개체는 single 네모로, 약한 개체는 double 네모로 표현
  • 약한 개체 집합 내에서는 부분 키(partial key)가 존재할 수 있음
  • 약한 개체 집합의 primary key = 강한 개체의 primary key + 약한 개체의 partial key

Example of Weak Entity Set

  • 약한 개체 section의 primary key는 강한 개체 course의 주 키인 cID와 section의 partial key인 sID, year, semester가 됨
  • 1:N 구조를 띄며 section은 course에 의존적이기 때문에 course와 연관이 없는 section 개체는 존재할 수 없음
  • course는 부분 참여이므로 section이 없는 course가 존재할 수 있으며, section은 전체 참여로 모든 section은 하나의 course를 가짐
  • 이때, 약한 개체와 강한 개체의 관계성을 표현하는 마름모는 double 마름모로 표현함

 

ER Diagram for a University

  • course는 재귀로 N:M으로 된 선이수 과목이란 관계를 가지고 있으며 부분 참여이기 때문에 선이수 과목을 안 가질 수 있음
  • coruse는 Course_dept라는 관계로 department와 N:1 관계를 가지며 부분 참여이므로 아무 건물에 속하지 않을 수 있음
  • instructor와 학생은 1:N 관계며 부분 참여로 아직 instructor가 배정되지 않은 학생, 학생이 없는 instructor가 있을 수 있음
  • section은 course와 1:N으로 전체 참여이기 때문에 course가 없는 section은 없음
    마찬가지로 teaches로 isntructor와도 N:M으로 모두 배정이 되어있으며 classroom도 1:N으로 배정되어 있음
    결론적으로 section은 course, instructor, classroom, time_slot을 모두 가져야 하며 instructor는 여러 명을 가질 수 있음
    student와는 N:M의 관계이며, 부분 참여이기 때문에 학생이 수업을 갖지 않을 수도 수업이 학생이 없을 수도 있음

 

관계형 스키마로 변환

  • 설계자가 사용자 요구 사항을 반영하는 ER Diagram을 작성하면 이를 관계형 스키마로 변환함
  • Entity Set(개체 집합)과 Relationship Set(관계성 집합)은 각각 한 개의 테이블로 속성과 함께 변환됨
  • 기본적으로 개체 속성은 테이블 속성으로 변환되나, 개체 속성 타입에 따라 변환이 상이할 수 있음

Strong / Weak Entity Sets

  • 강한 개체는 관계로 변환이 되어 테이블로 변환
  • 약한 개체도 관계로 변환이 되지만 약한 개체를 구분하는 관계성은 변환이 되지 않음
    테이블에서 이미 강한 개체의 주 키를 이미 포함하기 때문에 구분하는 관계성을 변환하면 중복 발생

offered 테이블은 변환 X

M:N Relationship Set

  • 다대다 관계성은 반드시 독립적인 테이블로 변환되며, 속성은 관여하는 개체 집합의 주 키를 포함

  • own 테이블이 관여하는 각 테이블의 주 키를 포함하여 독립적인 테이블로 변환됨

 

N:1 / 1:1 Relationship Set

  • 다대일이 관계성이 전체 포함 조건을 가진다면 독립적인 테이블로 변환도 가능하고, N측 개체로 병합되어 테이블로 변환도 가능함
  • 일대일은 양쪽 모두 N측이 될 수 있어 N측 역할을 한쪽으로 병합하여 테이블로 변환이 가능함

N:1 Relationship Set Example

  • 첫 번째 스키마는 own이 독립적인 테이블로 변환이 되며 N측 주 키인 vehicleID를 주 키로 가져옴
  • 두 번째 스키마는 registrationDate, pID를 N측 개체인 car 테이블로 밀어서 병합시킴

1:1 Relationship Set Example

  • 첫 번째 스키마는 own이 독립적인 테이블로 변환이 되며 각 테이블의 주 키만 속성으로 가져옴
  • 두 번째 스키마는 car로 own의 속성과 pID를 밀어서 병합시킴
  • 세 번째 스키마는 people로 own의 속성과 vehicleID를 밀어서 병합시킴

 

Composite Attributes (복합 속성)

  • 복합 속성의 속성들이 변환이 되며 다수값을 가지는 phoneNumber는 포함되지 않고 독립 테이블로 변환됨
    이 때 phoneNumber 테이블은 관련 개체의 주 키 속성인 ID를 포함함

ER Design Decisions (설계 이슈)

Entity Set vs Attributes

  • 휴대전화를 독립 개체로 모델링하는 것(우측 ERD) 휴대전화 정보를 사람 개체의 속성으로 모델링하는 것(좌측 ERD)
  • 정답은 없지만 각각 장단점이 존재함 / 휴대전화의 개수가 여러 개이거나 정보가 많은 경우 우측 ERD가 적절

Entity vs Relationship

  • 보통 명사(noun)는 개체로 표현이 되며 동사(action)는 관계성으로 표현
  • 상단 ERD는 register를 동사로 보고 관계성으로 표현 / 하단 ERD는 registration이라는 명사로 보고 개체로 표현

 

Redundant Attribute (중복 속성)

  • professor 테이블의 deptName과 department 테이블의 dName이 중복되므로 deptName은 제거되어야 함

 

Binary vs Non-binary Relationship

  • 다진 관계성이 다수 개체 간의 관계를 명확히 표현함
    • ex) 교수 - 학생 - 프로젝트 관계는 각각의 2진 관계로는 완전하게 표현할 수 없음
  • 다진 관계성은 다수 개의 이진 관계성으로 변환이 가능하지만 간혹 가다 일부 정보가 유실되는 경향이 있음

Binary vs Ternary Relationship Set

  • 좌측 ERD는 재귀적(recursive) 관계성을 사용한 삼진 관계성 / 우측 ERD는 두 개의 이진 관계성
  • 좌측 ERD의 parenthood 관계성은 아버지/어머니/자식에 대한 정보가 정확히 기록되어야 함
  • 우측 ERD의 fatherhood 관계성과 motherhood 관계성은 서로 독립적인 관계성이므로 아버지 정보만도 기록이 가능
    >> 아버지/어머니/자식정보를 반드시 함께 기록하려면 삼진 관계성 / 부분 정보만이라도 표현하려면 이진 관계성

Converting Non-Binary Relationship

  • 일반적으로 다진 관계형은 다수개의 이진 관계성으로 변환이 가능함
  • 새로운 객체 집합을 생성한 후, 다진 관계성 집합에 속하는 관계성에 대응하는 개체 및 관계성을 생성

  • E 개체, A, B, C와의 관계성을 생성하여 3개의 이진 관계성으로 변환
  • Translating all constraints may not be possible
  • 번역된 스키마에 R의 어떤 인스턴스와도 일치할 수 없는 인스턴스가 있을 수 있음

Specialization / Generalization

  • ER 데이터 모델은 객체지향 모델의 일반화(Generalization)/특수화(Specialization)/상속 기능을 지원

Top-down design process (하향식 설계 과정)

  • 하나의 개체 집합에서 다른 개체들과 구별되는 하위 그룹을 지정함
  • 하위 그룹들은 속성을 가지거나, 상위 개체 집합에는 해당되지 않는 관계에 참여하는 하위 수준의 개체 집합이 됨
  • 특수화가 가능함
    • ex) 사람 >> 학생, 교수 

Bottom-up design process (상향식 설계 과정)

  • 비슷한 특징을 가진 여러 개체 집합을 결합하여 상위 수준의 개체 집합을 생성
  • 일반화가 가능함
    • ex) 학생, 교수 >> 사람

Attribute Inheritance (속성 상속) 

  • 하위 수준의 개체 집합은 자신과 연결된 상위 수준 개체 집합의 모든 속성과 관계 참여를 상속받음

Specialization/Generalization Example

  • 화살표가 하나로 통일되는 상속은 disjoint specialization을 의미하며, 상위 개체가 둘 중 하나의 개체만 속할 수 있음을 의미
  • 화살표가 따로 있는 상속은 overlapping specialization을 의미하며, 상위 개체가 두 개체 모두를 속할 수 있음을 의미 

 

Completeness Constraint (완전성 제약)

Total (전체 특수화)

  • 상위 개체에 속한 모든 개체는 반드시 하위 개체 중 하나에 포함되어야 함
  • 선 2개(이중 실선)로 나타냄
  • ex) person > 반드시 male, female 같은 하위 집합 중 하나에 속해야 함

Partial (부분 특수화)

  • 상위 개체에 속한 일부 개체는 어떠한 하위 개체에도 속하지 않아도 됨
  • 선 1개(단일 실선)로 나타냄 
  • default 값임
  • ex) person은 student, employee 같은 하위 집합 중 아무것도 속하지 않을 수 있음

스키마 변환 방법

방법 1

  • 하위 개체는 하위 개체에만 속하는 속성과 상위 개체의 주 키만을 가지게끔 스키마 변환
  • 특수화가 partial 제약을 가져 상위 개체가 반드시 하위 개체에 속할 필요가 없음
  • 하위 관계에 대한 모든 속성을 검색하기 위해서는 하위 관계와 상위 관계를 Join해야 하므로 시간이 소요됨

방법 2

  • 하위 개체는 상속받은 모든 속성과 해당 개체에만 적용되는 속성을 가지게끔 스키마 변환
  • 특수화가 total 제약을 가지면 상위 개체는 반드시 하위 개체에 속하게 되므로, 상위 개체만을 위한 테이블 생성이 필요하지 않을 수 있음
  • 상위 개체에 대한 데이터 제약 사항을 설정하지 못하며 공간을 많이 차지함