1. Entity Relationship Model
Database Design
Entity Relationship Model

2. Entity Relationship Model
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
STUDENT
TEACHER ID
Major
Name
Office
GPA
Database Design

3. E-R Model: Attribute Types
Simple attribute 단순 속성
Composite attribute 복합 속성
→ cannot be subdivided
→ can be subdivided into multiple attributes
→ Replace with multiple simple attributes
Age
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 possible
Race
Gender
Birthdate
Phone 
Home Phone
Cell Phone
Work Phone
Vulcan
Male
Name
First Name
Simple
Simple
Simple
Middle Name
Composite
Last Name
Database Design

4. E-R Model: Multi-valued Attributes 다중값 속성
Avoid Multi-valued attributes (MVA)
Replace with multiple single-valued attributes (SVA).
Car_Color  Car_TopColor, Car_TrimColor, Car_BodyColor, Car_InteriorColor
could be problematic
Create a new entity composed of original multi-valued attribute’s components
Car_Color  CAR_COLOR (Car_Vin, Col_Section, Col_Color)
Database Systems: Design, Implementation, & Management: Rob & Coronel
Database Design

5. E-R Model: Multi-valued Attributes
MVA → multiple SVA ID
Name
HomePhone
CellPhone
WorkPhone
1234
James Kirk
2345
Spock
3456
Khan
CellPhone2
CellPhone3
MVA → Entity ID
Name
1234
James Kirk
2345
Spock
3456
Khan ID
PhoneType
PhoneNumber
1234
home
cell
work
2345
3456
cell2
cell3
3456
cell4
Database Design

6. E-R Model: Relationships
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 Systems: Design, Implementation, & Management: Rob & Coronel
Database Design

7. ERM: Relationship Strength
Weak (non-identifying) Relationship
PK of related entity does not contain PK component of parent entity
관련된 개체의 PK가 모개체의 PK요소를 포함하지 않음
Strong (identifying) Relationship
PK of related entity contains PK component of parent entity
관련된 개체의 PK가 모개체의 PK요소를 포함함
CRS_ID
CRS_Name
Credit DB
Database Design 3 IT
Internet Technology WP
Web Programming
Class_ID
CRS_ID
Room
DB-s15 DB
421
IT-s15 IT
403
DB-s16
IT-s16
CRS_ID
CRS_Name
Credit DB
Database Design 3 IT
Internet Technology WP
Web Programming
CRS_ID
Section
Room DB
s15
421 IT
403
s16
Database Design

8. ERM: Relationship Strength
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
Dpt_ID
CRS_Name
LIS
Library & Information Science CS
Computer Science
HIST
History
Stud_ID
Dpt_ID
Name
12345
LIS
Kirk
23456
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
15002
Spock CS
Sulu
16001
Kahn
Database Design

9. ERM: Relationship Participation
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
COURSE
CLASS
CRS_ID
CRS_Name
Credit DB
Database Design 3 IT
Internet Technology WP
Web Programming
CRS_ID
Section
Room DB
s15
421 IT
403
s16
Database Design

10. ERM: Relationship Participation
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
COURSE
CLASS
CRS_ID
CRS_Name
Credit DB
Database Design 3 IT
Internet Technology WP
Web Programming
CRS_ID
CRS_Name
Credit DB
Database Design 3 IT
Internet Technology
Class_ID
CRS_ID
Room
DBs15 DB
421
ITs15 IT
403
DBs16
Database Design

11. ERM: Relationship Strength vs. Participation
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 belong to one employee.
A dependent must belong to an employee
PK of DEPENDENT must contain PK of EMPLOYEE
Strong relationship
DEPENDENT
(weak)
Dpd_ID
Emp_ID
Name
123s1
123
Kirk
234s1
234
Spock
345s2
Sulu
123s2
Kahn
DEPENDENT
(strong)
Dseq
Emp_ID
Name s1
123
Kirk
234
Spock s2
Kahn
Sulu 1 M
EMPLOYEE
has
DEPENDENT
(0,M)
(1,1)
Database Design

12. ERM: Relationship Strength vs. Participation
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
CLASS
(weak)
Class_ID
CRS_ID
st_ID
pf_ID
Room
DBs15a DB
g123
403
DBs15b
kiyang
ITs15a IT
421
ITs16a
CLASS
(strong)
CRS_ID
Section
st_ID
pf_ID
Room DB
s15
g123
403
kiyang IT
421
S15 1 M
PHD_STUD
teaches
CLASS
(1,M)
(1,1)
Database Design

13. ERM: Relationship Degree
Relationship Degree indicates the number of associated entities.
Unary Relationship
Relationship exists between occurrences of same entity set
e.g., Recursive relationship
Binary Relationship
Two entities associated
Most common
higher-order relationships are often decomposed into binary relationships
Ternary
Three entities associated
e.g., DOCTOR, PATIENT, DRUG
CRS_ID
CRSname
Prereq
DB1
Database Design
DB2
Web Database
DB3
Database Projects
Unary
- a course is a prerequisite for another course (M:N)
Ternary
- CONTRIBUTOR donate money to research FUND (M:N)
- RECIPIENT researchers are funded $ from FUND (M:N)
PRS_ID
Dr_ID
Pat_ID
Drug_ID
expireDate
Frnknstein55
4567
hrn21pr
16/06/25
Strangelove21
thc16ts
20/04/15
DrWho6
1234
trs10by
16/12/31
Database Design

14. 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 M N
STUDENT
enrolls in
CLASS
A student doesn’t have to enroll in a class
A class has to have minimum 10 students
(0,M)
(10,M)
Class_ID
Stud_ID
Grade
DB-s15
1234 A
IT-s15
DB-s16
2345 B
IT-s16
3456 C 1 M M 1
STUDENT
ENROLL
CLASS
(0,M)
(1,1)
(1,1)
(10,M)
Database Design

15. 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
Shared attributes
EMP_ID
Name
Phone
1234
Kirk
2345
Spock
3456
Sulu
0007
Pike
EMPLOYEE
(Supertype) 1 is 1
Unique attributes
PILOT
(Subtype)
EMP_ID
Pilot_License
FlightHR
1234
enpr-sc213g
1923
0007
enpr-cg123k
355
Database Design

16. Subtypes: Overlapping vs. Non-overlapping
Non-overlapping (Disjoint)
Overlapping
Database Systems: Design, Implementation, & Management: Rob & Coronel
Database Design

17. Exercises

18. Database Design: University Database
Construct a data model of a typical university.
To keep track of class & advising information by department (double-major allowed)
Database Objectives
Generate a course listing by semester (e.g., professor, department, class time & place)
For each professor, generate the classes taught & student grades for each class.
For each student, generate the complete listing of advising sessions (e.g, date, time, advisor)
For each school, generate a list of all employees by department.
For each department, generate a listing of all double-major students.
Database Objectives
Generate a course listing by semester (e.g., professor, department, class time & place)
For each professor, generate the classes taught & student grades for each class.
For each student, generate the complete listing of advising sessions (e.g, date, time, advisor)
For each school, generate a list of all employees by department.
For each department, generate a listing of all double-major students.
Business Rules
A school can have many departments. Each department belongs to one school.
A department has many employees. An employee works in one departments.
An employee can be a professor or a staff.
A course generates many classes. Each class belongs to a course.
A professor teaches many classes. A class is taught by one professor.
A student can take many classes. A class has many students.
A student belongs to one department. A department has many students.
A student can double-major in a department. A department can have many double-major students.
Database Design

19. Database Design: University Database
Construct a data model of a typical university.
To keep track of class & advising information by department (double-major allowed)
Business Rules
A school can have many departments. Each department belongs to one school.
A department has many employees. An employee works in one departments.
An employee can be a professor or a staff.
A course generates many classes. Each class belongs to a course.
A professor teaches many classes. A class is taught by one professor.
A student can take many classes. A class has many students.
A student belongs to one department. A department has many students.
A student can double-major in a department. A department can have many double-major students.
Business Rules
A school can have many departments. Each department belongs to one school.
A department has many employees. An employee works in one departments.
An employee can be a professor or a staff.
A course generates many classes. Each class belongs to a course.
A professor teaches many classes. A class is taught by one professor
A student can take many classes. A class has many students.
A student belongs to one department. A department has many students.
A student can double-major in a department. A department can have many double-major students. M 1 M
DEPARTMENT
has
STUDENT 1 1 M 1
major2 M
has
ENROLL
has M 1 M 1
SCHOOL
EMPLOYEE 1 1 1 M M 1 is
PROFESSOR
CLASS
COURSE
Database Design

20. Database Design: University Database
Convert the data model of a university to a relational schema.
Sample DB
Database Design

21. Database Design: University Database
One of the database objective is to generate a list of students advised for a given year & dates of advising sessions for each students for each professor. Modify the ERD to support this DB objective.
Business Rules
A professor can meet many times with an advisee. A student can meet many times with a professor
Sample DB M 1 M
DEPARTMENT
has
STUDENT 1 M 1 1 1
major2 M M
has
has
ENROLL
ADVISING M M 1 M 1 1 1 1 1 M M 1
SCHOOL
EMPLOYEE is
PROFESSOR
CLASS
COURSE
Database Design

22. Database Design: University Database
Data model below corrects the following problems with the previous data model.
The departmental advisor information is missing -- A student may consult with a professor who is not his/her departmental advisor
A professor can advise many students. A student is advised by one professor.
The department designation for courses is missing -- A professor may teach courses outside of his/her department.
A department offers many courses. A course is offered by one department.
Sample DB 1
offers M 1 M
DEPARTMENT
has
STUDENT 1 M 1 1 1
major2 M M M
has
has
ENROLL
advises
ADVISING M M 1 M 1 M 1 1 1 1 1 M M 1
SCHOOL
EMPLOYEE is
PROFESSOR
CLASS
COURSE
Database Design