entity relationship model - knukiyang/teaching/db/s20/... · 2020. 5. 1. · relationship degree. ....

Entity Relationship Model:

E-R Modeling

Basic Modeling Concepts

Model“Description or analogy used to visualize

something that cannot be directly observed” -Webster’s Dictionary -

Data ModelsRelatively simple representation of complex real-world data structures

→Facilitate communication→Enhance understanding

Database System 2

Degrees of Data Abstraction Conceptual

Global view of data• identify and describe main data items (e.g. E-R diagram)Hardware and software independent

InternalRepresentation of database as seen by DBMS• adapt conceptual model to specific DBMS (e.g. Access tables)Software dependent

ExternalUsers’ views of data environment• group requirements & constraints subsets into functional modules • e.g. student registration module, class scheduling moduleFacilitates development & revalidates the conceptual model

PhysicalLowest level of abstraction• determine of physical storage devices and access methodssoftware and hardware dependent

Database System 3

Data Abstraction Models

Database System 4

Database Systems: Design, Implementation, & Management: Rob & Coronel

Main Components of the ER Model Entities 개체

• Thing about which to collect data→ e.g., STUDENT, TEACHER

Attributes 속성• Characteristics of entities

→ Attribute Domain ⇒ set of possible values

Relationships 관계• Association between entities

Entity Relationship Diagram (ERD) ER model forms the basis of an ER diagram ERD represents the conceptual view 개념뷰 of the database

Main Components of the ER Model Entities 개체

• Thing about which to collect data→ e.g., STUDENT, TEACHER

Attributes 속성

• Characteristics of entities→ Attribute Domain ⇒ set of possible values

Relationships 관계

• Association between entities

Entity Relationship Diagram (ERD) ER model forms the basis of an ER diagram ERD represents the conceptual view 개념뷰 of the database

Entity Relationship Model

STUDENT TEACHER

ID

GPA

Major Name

email

Office

Database Design 5

E-R Model: Attribute Types

Simple attribute 단순 속성 Composite attribute 복합 속성→ cannot be subdivided → can be subdivided into multiple attributes

→ Replace with multiple simple attributesAge Gender Marital Status Name

⇒First Name Middle Name Last Name

34 Male Single James T. Kirk James Tiberius Kirk

Single-valued attribute 일가 속성 Multi-valued attribute 다중값 속성→ can have only one value → can have many values

→ Avoid if possibleRace Gender Birthdate Phone

⇒Home Phone Cell Phone Work Phone

Vulcan Male 1945-03-22 070-1234-5678 010-1234-5678

070-1234-5678 010-1234-5678

SimpleSimple Simple

CompositeDatabase Design 6

Name First Name

Middle Name

Last Name

Avoid Multi-valued attributes (MVA)1. Replace with multiple single-valued attributes (SVA).

• Car_Color Car_TopColor, Car_TrimColor, Car_BodyColor, Car_InteriorColor• could be problematic

2. Create a new entity composed of original multi-valued attribute’s components• Car_Color CAR_COLOR (Car_Vin, Col_Section, Col_Color)


E-R Model: Multi-valued Attributes 다중값속성

Database Design 7

E-R Model: Multi-valued Attributes

MVA → multiple SVA

MVA → Entity

ID Name HomePhone CellPhone WorkPhone

1234 James Kirk 070-1234-5678 010-1234-5678 053-1234-5678

2345 Spock 010-2345-6789

3456 Khan 010-3456-7890

CellPhone2 CellPhone3

010-4567-7890 010-5678-7890

ID Name

1234 James Kirk

2345 Spock

3456 Khan

ID PhoneType PhoneNumber

1234 home 070-1234-5678

1234 cell 010-1234-5678

1234 work 053-1234-5678

2345 cell 010-2345-6789

3456 cell 010-3456-7890

3456 cell2 010-4567-7890

3456 cell3 010-5678-7890

3456 cell4 010-6789-7890

Database Design 8

E-R Model: Relationships

Relationship 관계 Association between entities→ Connectivity & Cardinality are established by business rules

Connectivity 관계유형Type/Classification of Relationships

→ 1:1, 1:M, M:N

Cardinality 관계차수

(min, max) = minimum/maximum number of occurrences of the related entity


Database Design 9

Relationship Strength Existence Dependence

⇒ Entity’s existence depends on the existence of related entities.• Existence-independent entities can exist apart from related entities.

Weak Entities• Existence dependent entities• Cannot exist without the related entity

e.g. EMPLOYEE claims DEPENDENT→ DEPENDENT is existence-dependent on EMPLOYEE

Strong Entities• Can exist apart from all of the related entity

→ Table with a primary key that does not contain the primary key of related tablee.g. EMPLOYEE has SPOUSE→ EMPLOYEE is existence-independent of SPOUSE

Database System 10

Identifying (Strong) RelationshipPK of related entity contains PK component of parent entity관련된 개체의 PK가 모개체의 PK요소를 포함함

Non-identifying (Weak) Relationship PK of related entity does not contain PK component of parent entity

관련된 개체의 PK가 모개체의 PK요소를 포함하지 않음

ERM: Relationship Strength

CRS_ID CRS_Name Credit

DB Database Design 3

IT Internet Technology 3

WP Web Programming 3

CRS_ID Section Room

DB s15 421

IT s15 403

DB s16 421

IT s16 403

Database Design 11





Class_ID CRS_ID Room

DB-s15 DB 421

IT-s15 IT 403

DB-s16 DB 421

IT-s16 IT 403

Relationship strength is determined by table design (PK),but it can be driven by Business rules A student can decide his/her major after 2 years

A student must decide his/her major in the beginning

ERM: Relationship Strength

Dpt_ID CRS_Name

LIS Library & Information Science

CS Computer Science

HIST History

Stud_ID Dpt_ID Name

12345 LIS Kirk

23456 LIS Spock

34567 CS Sulu

45678 Kahn

Dpt_ID CRS_Name

LIS Library & Information Science

CS Computer Science

HIST History

Dpt_ID Snum Name

LIS 15001 Kirk

LIS 15002 Spock

CS 15001 Sulu

LIS 16001 Kahn

Database Design 12

Optional Participation 선택관계(Child) Entity is not required to participate in a relationship→Minimum cardinality of the optional entity is 0

CLASS is optional to Course- i.e., Course does not have to generate a class

ERM: Relationship Participation





CRS_ID Section Room

DB s15 421

IT s15 403

DB s16 421

COURSE CLASS

Database Design 13

Mandatory Participation 필수관계 Entities must participate in a relationship

→Minimum cardinality of the mandatory entity is 1

CLASS is mandatory to Course- i.e., Course has to generate a class

ERM: Relationship Participation





Class_ID CRS_ID Room

DBs15 DB 421

ITs15 IT 403

DBs16 DB 421




COURSE CLASS

Database Design 14

Participation & Strength do not determine each other Relationship strength is determined by the composition of the related table’s PK Relationship participation is based on business rules

EMPLOYEE and DEPENDENT Strong & Optional relationship

An employee has many dependent.→ An employee may not have any dependent→ DEPENDENT is optional to EMPLOYEE

A dependent belongs to one employee.→A dependent must belong to an employee→PK of DEPENDENT must contain PK of EMPLOYEE⇒ Strong relationship

ERM: Relationship Strength vs. Participation

EMPLOYEE DEPENDENThas1 M

(1,1)(0,M)

Dpd_ID Emp_ID Name

123s1 123 Kirk

234s1 234 Spock

345s2 Sulu

123s2 123 Kahn

Dseq Emp_ID Name

s1 123 Kirk

s1 234 Spock

s2 123 Kahn

s2 Sulu

DEPENDENT(weak)

DEPENDENT(strong)

Database Design 15

Participation & Strength do not determine each other Relationship strength is determined by the composition of the related table’s PK Relationship participation is based on business rules

PHD_STUD and CLASS Weak & Mandatory relationship

A doctoral student can teach many classes.→ A doctoral student must teach a class→ CLASS is mandatory to PHD_STUD

A class is taught by one doctoral student.→A class can be taught by a professor→PK of CLASS does not contain PK of PHD_STUD⇒Weak relationship


PHD_STUD CLASSteaches1 M

(1,1)(1,M)

Class_ID CRS_ID st_ID pf_ID Room

DBs15a DB g123 403

DBs15b DB kiyang 403

ITs15a IT kiyang 421

ITs16a IT g123 403

CRS_ID Section st_ID pf_ID Room

DB s15 g123 403

DB s15 kiyang 403

IT s15 kiyang 421

IT S15 g123 403

CLASS(weak)

CLASS(strong)

Database Design 16


PHD_STUD CLASSteaches1 M

(1,1)(1,M)

Class_ID CRS_ID st_ID pf_ID Room

DBs15a DB g123 403



ITs16a IT g123 403

PHD-CLASS (weak & mandatory)

Database Design 17

PROF teaches1

M(0,1)

(0,M)

(0,1)

Class_ID CRS_ID tch_ID Room

DBs15a DB g123 403



ITs16a IT g123 403

PROF-CLASS (weak & optional)

PHD_STUD and CLASS Weak, Mandatory CLASS & Optional PHD_STUD relationship

PROF and CLASS Weak & Optional relationship

A professor can teach many classes.→ A professor does not have to teach a class.⇒ CLASS is optional to PROF

A class is taught by one professor.→ A class may be taught by a doctoral student.⇒ PROF is optional to CLASS→ PK of CLASS does not contain PK of PROF⇒ Weak relationship

Relationship: Weak Entities

Database System 18


Strong vs. Weak entities Strong Entity = existence-independent entity Weak Entity

existence-dependent entity in a strong relationship inherits all or part of its primary key from parent entity entity w/ clipped corners in CF model, double-walled in Chen model

ERM: Relationship Degree Relationship Degree indicates

the number of associated entities.

Unary RelationshipRelationship exists between occurrences of same entity sete.g., Recursive relationship

Binary RelationshipTwo entities associatedMost common• higher-order relationships are often

decomposed into binary relationships

TernaryThree entities associatede.g., DOCTOR, PATIENT, DRUG

CRS_ID CRSname Prereq

DB1 Database Design

DB2 Web Database DB1

DB3 Database Projects DB2

PRS_ID Dr_ID Pat_ID Drug_ID expireDate

160101-121 Frnknstein55 4567 hrn21pr 16/06/25

100415-001 Strangelove21 4567 thc16ts 20/04/15

160101-122 DrWho6 1234 trs10by 16/12/31

Database Design 19

ERM: Composite Entities

Composite Entity (i.e., Bridge Entity)

Transforms a M:N relationship into two 1:M relationships

Contains primary keys of the “bridged” entities• May also contain additional attributes that play no role in connective

process

Typically has strong relationships with the “bridged” entities

STUDENT CLASSenrolls inM N

(0,M) (10,M)

A student doesn’t have to enroll in a class A class has to have minimum 10 students

STUDENT CLASS1 M

(0,M) (10,M)

ENROLLM 1

(1,1)(1,1)

Class_ID Stud_ID Grade

DB-s15 1234 A

IT-s15 1234 A

DB-s16 2345 B

IT-s16 3456 C

Database Design 20

ERM: Entity Supertype & Subtype

Problem⇒ Unshared characteristics of certain entity subtypes (e.g. EMPLOYEE & PILOT)

Solution• Supertype (parent) & lower-level Subtype (child) entities

→ Subtypes inherit the attributes and relationships of the supertype→ 1:1 relationship

EMPLOYEE(Supertype)

PILOT(Subtype)

is

1

1

EMP_ID Name email Phone

1234 Kirk [email protected] 010-1111-1111

2345 Spock [email protected] 010-2222-2222

3456 Sulu [email protected] 070-1212-3456

0007 Pike [email protected] 011-0001-0007

EMP_ID Pilot_License FlightHR

1234 enpr-sc213g 1923

0007 enpr-cg123k 355

Shared attributes

Unique attributes

Database Design 21

mailto:[email protected]

Subtypes: Overlapping vs. Non-overlapping

Database System 22

Non-overlapping (Disjoint)

Overlapping


Developing ERD Iterative Process

1. Create detailed narrative of organization’s description of operations

2. Identify business rules based on description of operations

3. Identify main entities and relationships from business rules

4. Develop initial ERD

5. Identify attributes and primary keys that adequately describe entities

6. Revise and review ERD

Database System 23

ERD Example: Narrative Narrative of operational environment

Tiny College is divided into several schoolsEach school is composed of several departments

Each school is administered by a deanEach dean is a member of administrators groupA dean is also a professor and may teach classesAdministrators and professors are employees

Each department offers several coursesEach course may have several sections (classes)

Each department has many professors and studentsOne of the professors chairs the departmentEach professor may teach up to 4 classes

A student may enroll in several classesEach student has an advisor in his/her departmentEach student belong to only one department

Database System 24

ERD Example: Supertype/Subtype

Professors and administrators have unique characteristics not present in other employeesEMPLOYEE supertype, PROFESSOR & ADMINISTRATOR (overlapping) subtypes

Professors and administrators have same set of characteristicscollapse PROFESSOR and ADMINISTRATOR entities

Database System 25


- Each school is administered by a dean- Each dean is a member of administrators group- A dean is also a professor and may teach classes- Administrators and professors are employees

ERD Example: ERD segment 1

Professors are employeesA professor may be a deanEach school is administered by a deanEach school is composed of several departments

Database System 26


ERD Example: ERD segment 2 & 3

Each department offers several coursesEach course may have several sections (classes)

Database System 27



Each department has many professorsOne of the professors chairs the departmentEach professor may teach up to 4 classes

Database System 28



A student may enroll in several classesEach department has many studentsEach student belong to only one department

Database System 29



Each student has an advisorClass is held in class rooms

Database System 30


ERD Example: ERD components

Database System 31


ERD Example: Merging ERD segments

Database System 32

ERD Example: Completed ERD

Database System 33Database Systems: Design, Implementation, & Management: Rob & Coronel

entity relationship model - knukiyang/teaching/db/s20/... · 2020. 5. 1. · relationship degree. ....

Documents