entity relationship modelwidit.knu.ac.kr/~kiyang/teaching/db/s17/lectures/6.db-er...degrees of data...
Post on 12-May-2018
216 Views
Preview:
TRANSCRIPT
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 module
Facilitates development & revalidates the conceptual model
PhysicalLowest level of abstraction• determine of physical storage devices and access methods
software 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
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 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 1945-03-22 070-1234-5678 010-1234-5678
070-1234-5678 010-1234-5678
SimpleSimple Simple
Composite
Database 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)
Database Systems: Design, Implementation, & Management: Rob & Coronel
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 Systems: Design, Implementation, & Management: Rob & Coronel
Database Design 9
Relationship Strengths 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 table
e.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
CRS_ID CRS_Name Credit
DB Database Design 3
IT Internet Technology 3
WP Web Programming 3
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 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
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
CRS_ID CRS_Name Credit
DB Database Design 3
IT Internet Technology 3
WP Web Programming 3
Class_ID CRS_ID Room
DBs15 DB 421
ITs15 IT 403
DBs16 DB 421
CRS_ID CRS_Name Credit
DB Database Design 3
IT Internet Technology 3
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 belong 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
ERM: Relationship Strength vs. Participation
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
Relationship: Weak Entities
Database System 17
Database Systems: Design, Implementation, & Management: Rob & Coronel
Strong vs. Weak entities
Strong Entity = existence-independent entity in a strong relationship
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 18
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 19
M:N to 1:M Conversion
Database System 20
STU_ID STU_NAME CLS_ID
1234 John Doe 10012
1234 John Doe 10014
2341 Jane Doe 10013
2341 Jane Doe 10014
2341 Jane Doe 10023
CLS_ID CRS_NAME CLS_SECT STU_ID
10012 L546 1 1234
10013 L546 2 2341
10014 L548 1 1234
10014 L548 1 2341
10023 L571 1 2341
STU_ID STU_NAME
1234 John Doe
2341 Jane Doe
CLS_ID CRS_NAME CLS_SEC
10012 L546 1
10013 L546 2
10014 L548 1
10023 L571 1
CLS_ID STU_ID ENR_GRD
10012 1234 B
10013 2341 A
10014 1234 C
10014 2341 A
10023 2341 A
1. Move the foreign key columns to create a bridge table & add attributes if needed.
2. Collapse the duplicate records in remaining tables.
STUDENT CLASS
STUDENT
CLASS
ENROLL
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 jtkiri@trek.org 010-1111-1111
2345 Spock spock@logic.vulcan 010-2222-2222
3456 Sulu sulu@star.ac.jp 070-1212-3456
0007 Pike cpike@trek.org 011-0001-0007
EMP_ID Pilot_License FlightHR
1234 enpr-sc213g 1923
0007 enpr-cg123k 355
Shared attributes
Unique attributes
Database Design 21
Subtypes: Overlapping vs. Non-overlapping
Database System 22
Non-overlapping (Disjoint)
Overlapping
Database Systems: Design, Implementation, & Management: Rob & Coronel
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
Database Systems: Design, Implementation, & Management: Rob & Coronel
- 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
Database Systems: Design, Implementation, & Management: Rob & Coronel
ERD Example: ERD segment 2 & 3
Each department offers several courses
Each course may have several sections (classes)
Database System 27
Database Systems: Design, Implementation, & Management: Rob & Coronel
ERD Example: ERD segment 4 & 5
Each department has many professors
One of the professors chairs the department
Each professor may teach up to 4 classes
Database System 28
Database Systems: Design, Implementation, & Management: Rob & Coronel
ERD Example: ERD segment 6 & 7
A student may enroll in several classes
Each department has many students
Each student belong to only one department
Database System 29
Database Systems: Design, Implementation, & Management: Rob & Coronel
ERD Example: ERD segment 8 & 9
Each student has an advisor
Class is held in class rooms
Database System 30
Database Systems: Design, Implementation, & Management: Rob & Coronel
ERD Example: ERD components
Database System 31
Database Systems: Design, Implementation, & Management: Rob & Coronel
ERD Example: Merging ERD segments
Database System 32
ERD Example: Completed ERD
Database System 33
Database Systems: Design, Implementation, & Management: Rob & Coronel
Exercises
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.
1. Construct a data model of a typical university.
→ To keep track of class & advising information by department (double-major allowed)
Database Design: University Database
Database Design 36
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.
1. Construct a data model of a typical university.
→ To keep track of class & advising information by department (double-major allowed)
Database Design: University Database
M
has
SCHOOL
DEPARTMENT
PROFESSORis
STUDENThas
COURSEEMPLOYEE
has
CLASS
1
1
M
1 1 1 1M M
M1
ENROLL
1
M
M
1
major2
1 M
Database Design 37
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.
2. Convert the data model of a university to a relational schema.
Database Design: University Database
Database Design 38
Sample DB
3. 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.
Database Design: University Database
Database Design 39
Sample DB
M
has
SCHOOL
DEPARTMENT
PROFESSORis
STUDENThas
COURSEEMPLOYEE
has
CLASS
1
1
M
1 1 1 1M M
M1
ENROLL
1
M
M
1
major2
1 M
ADVISING
M
M
1
1
Business Rules
A professor can meet many times with an advisee. A student can meet many times with a professor
3. 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.
Database Design: University Database
Database Design 40
Sample DB
M
has
SCHOOL
DEPARTMENT
PROFESSORis
STUDENThas
COURSEEMPLOYEE
has
CLASS
1
1
M1 1 1 1M M
M1
ENROLL
1
M
M
1
major2
1 M
advises ADVISING
M
M
1
1
1
M
offers1
M
top related