Database
Management
Systems
Course No. 306008001 & 306008011
Instructor: Chih-Yuan Chou
2023/02/21 & 2023/02/23
Lecture 2 (ER Model & EER Model)
Moodle
For Tuesday Class (306008001):
https://moodle.nccu.edu.tw/course/view.php?id=30637
For Thursday Class (306008011):
https://moodle.nccu.edu.tw/course/view.php?id=30638
Some Terms We May Use (again and again)
Informal Terms
Table
Column
or Field
Row or Record
Data range in field
Definition of table
Formal Terms in Relational Model
Relation
Attribute
Tuple
Domain
Schema of relation
The Entity-Relationship Model
Introduction to the ER model Conceptual Data Modeling
SDLC Revisited Data Modeling is an Analysis Activity
Project Identification
and Selection
Purpose thorough analysis
Deliverable functional system specifications
Project
Project Initiation
Initiation
and
and Planning
Planning
Analysis
Analysis
Logical Design
Physical Design
Database activity
conceptual data modeling
Implementation
Maintenance
Are statements that define or constrain some
aspect of the business
Are derived from policies, procedures, events,
functions
Business
Rules
Assert business structure
/
Control/influence business behavior
Are expressed in terms familiar to end users
Are automated through DBMS software
DBMS
A Good Business Rule Is:
Declarative what, not how
Precise clear, agreed-upon meaning
Atomic one statement
Consistent internally and externally
Expressible structured, natural language
Distinct non-redundant
Business-oriented understood by
businesspeople
Related to business, not
technical, characteristics
A Good Data
Name is:
Meaningful and self-documenting
Unique
Readable
Composed of words from an
approved list
Repeatable
Written in standard syntax
⼀
Data Definitions
Explanation of a term or fact
Term word or phrase with specific meaning
Fact association between two or more terms
Guidelines for good data definition
A concise description of essential data meaning
Gathered in conjunction with systems requirements
Accompanied by diagrams
Achieved by consensus and iteratively refined
Sample E-R Diagram
Entities:
Entity instance person, place, object, event,
concept (often corresponds to a row in a
table)
Entity Type collection of entities (often
corresponds to a table)
E-R Model
Constructs
Relationships:
Relationship instance link between entities
(corresponds to primary key foreign key
equivalencies in related tables)
Relationship type category of relationship;
link between entity types
Attributes:
Properties or characteristics of an entity or
relationship type (often corresponds to a
field in a table)
Gordon Everest
Source: University of Minnesota
Basic E-R
Notation
In our textbook
Basic E-R
Notation
In our reference book (Chen)
Pin-Shan Chen
Inventor of E-R Model
Source:
Comparison of
ER and other
diagrams
E-R (Chen)
representation
E-
E-R (Rain 85) representation
E-R (INDF1X) representation
For the
notation
common way to learn for the beginners,
in many practical software.
representation during this semester.
(different from our textbook!)
Entity
Entities
a person, a place, an object, an event,
or a concept in the user environment
about which the organization wishes
to maintain data
Entity type
a collection of entities that share
common properties or characteristics
Entity instance
a single occurrence of an entity type
Entity Type and Entity Instances
FIGURE 2-3 Entity type EMPLOYEE with two instances
Entity type: EMPLOYEE
Attributes
Attribute Data Type
Example Instance
Example Instance
Employee Number CHAR (10)
64217836
53410197
Name
CHAR (25)
Michelle Brady
David Johnson
Address
CHAR (30)
100 Pacific Avenue
450 Redwood Drive
City
CHAR (20)
San Francisco
Redwood City
State
CHAR (2)
CA
CA
Zip Code
CHAR (9)
98173
97142
Date Hired
DATE
03-21-1992
08-16-1994
Birth Date
DATE
06-19-1968
09-04-1975
Should Be:
An object that will have many instances
in the database
An object that will be composed of
multiple attributes
An object that we are trying to model
Should Not Be:
A user of the database system
An output of the database system (e.g., a
report)
Inappropriate entities
System output
System user
Appropriate entities
Guidelines for Naming Entities
Singular noun
Specific to organization
Concise, or abbreviation
For event entities, the result not the process
Name consistent for all diagrams
8
Guidelines for Defining Entities
Describe unique characteristics of each instance
Explicit about what is and is not the entity
When an instance is created or destroyed
Changes to other entity types ( when )
History that should be kept
Attributes
Attribute property or characteristic of an entity or relationship
type
Classifications of attributes:
Required versus Optional
Simple versus Composite
Single-Valued versus Multivalued
Stored versus Derived
Identifier
Entities & Attributes
Required v s. Optional Attributes
ersu
Entity type: STUDENT
Attributes
Attribute Data Type
Required or Optional
Example Instance
Example Instance
Student ID
CHAR (10)
Required
28-618411
26-844576
Student Name
CHAR (40)
Required
Michael Grant
Melissa Kraft
Home Address
CHAR (30)
Required
314 Baker St.
1422 Heft Ave
Home City
CHAR (20)
Required
Centerville
Miami
Home State
CHAR (2)
Required
OH
FL
Home Zip Code
CHAR (9)
Required
45459
33321
Major
CHAR (3)
Optional
MIS
Blank
Required must have a value for every entity (or relationship) instance with which it is associated
Optional may not have a value for every entity (or relationship) instance with which it is associated
A Composite Attribute
Composite attribute An attribute that has
meaningful component parts (sub-attributes)
Street
Address
City
Employee Address
Chen
Multivalued
Attributes
May take on more than one value for a given
entity (or relationship) instance
An employee can have more than one skill
Chen
State
Derived Attributes
Values can be calculated from related attribute
values (not physically stored in the database)
Years employed calculated from date employed
and current date
Chen
Derived & Multivalued Attribute
□
⼀
L
)
Multivalued:
Derived
an employee can have
more than one skill
from date employed and current date
⻄這樣畫
*
!
An attribute that
is both
multivalued and
composite
This is an example of timestamping
Identifiers (Keys)
Identifier (Key) an attribute (or combination of attributes) that
uniquely identifies individual instances of an entity type
Simple versus Composite Identifier
Candidate Identifier an attribute that could be an identifier; it
satisfies the requirements for being an identifier
Simple and Composite Identifier Attributes
a) Simple identifier attribute
Student ID
b) Composite identifier attribute
Flight
Number
Date
Flight ID
Simple Key Attribute
The key is underlined
Composite Key Attribute
The key is composed
of two subparts
Criteria for Identifiers
Choose Identifiers that
Will not change in value
Will not be null
Avoid intelligent identifiers (e.g., containing locations or
people that might change)
(
Substitute new, simple keys for long, composite keys
)
Naming
Attributes
Name should be a singular noun or
noun phrase
Name should be unique
Name should follow a standard
format
Similar attributes of different
entity types should use the same
qualifiers and classes
Defining
Attributes
State what the attribute is and
possibly why it is important
Make it clear what is and is not
(1 of 2)
Include aliases in documentation
Defining
Attributes
(2 of 2)
State source of values
State whether attribute value can
change once set
Specify whether required or
optional
State min and max number of
occurrences allowed
Indicate relationships with other
attributes
Relationship Types versus. Relationship Instances
The relationship type is modeled as lines between
entity types. The relationship instance is between
specific entity instances
Relationships can have attributes
Modeling
Relationships
These describe features pertaining to the association
between the entities in the relationship
v Two entities can have more than one type of
relationship between them (multiple
relationships)
Associative Entity combination of relationship
and entity
Basic Relationship
Figure 2-10 Relationship Type and Instances
a) Relational type
(Completes)
b) Relationship
instances
Degree of Relationships
Degree of a relationship is the number of entity types that participate in it
Unary Relationship
Binary Relationship
Ternary Relationship
Unary entities of the same entity type related to each other
Degrees of
Relationships
Binary entities of one type related to entities of another
Ternary entities of three different types involved in the same
relationship
Chen
Cardinality (
)
of Relationships
One-to-One
Each entity in the relationship will have exactly one related entity
One-to-Many
An entity on one side of the relationship can have many related entities, but
an entity on the other side will have a maximum of one related entity
Many-to-Many
Entities on both sides of the relationship can have many related entities on
the other side
Cardinality
Examples of Relationships of Different Degrees (1 of 3)
a) Unary relationships
1
Is
Married
To
PERSON
EMPLOYEE
Manages
M
Examples of Relationships of Different Degrees (2 of 3)
b) Binary relationships
N
M
Registers
For
STUDENT
(1,6)
COURSE
(0,35)
Examples of Relationships of Different Degrees (3 of 3)
c) Ternary relationships
PART
N
VENDOR
M
Supplies
Shipping
Mode
Q
WAREHOUSE
Unit Cost
PART
N
VENDOR
M
Supplies
Shipping
Mode
时
Q
Unit Cost
Ternary relationships should be converted to composite entities.
Cardinality Constraints
Cardinality Constraints the number of instances of one
entity that can or must be associated with each instance of
another entity
Minimum Cardinality
If zero, then optional
If one or more, then mandatory
Maximum Cardinality
The maximum number
WAREHOUSE
Examples of Cardinality Constraints (1 of 3)
a) Mandatory cardinalities
A patient must have recorded at least
one history, and can have many
M
1
A patient history is
recorded for one and
only one patient
Has
Recorded
PATIENT
PATIENT
HISTORY
Chen
(1,1)
(1,M)
Examples of Cardinality Constraints (2 of 3)
b) One mandatory, one optional cardinality
A project must be assigned to at least one
employee, and may be assigned to many
M
EMPLOYEE
(0,N)
An employee can be assigned to any number of
projects, or may not be assigned to any at all
Is
Assigned
To
N
PROJECT
(1,M)
Chen
Examples of Cardinality Constraints (3 of 3)
c) Optional cardinalities
A person is married to at
most one other person, or
may not be married at all
(0,1)
Is
Married
To
PERSON
Chen
(0,1)
Example of Multiple Relationships (1 of 2)
a) Employees and departments
(0,M)
Supervis
es
EMPLOYEE
(0,1)
(0,M)
(1,1)
manag
es
works
(1,N)
Entities can be related to one another in more than one way
DEPARTMENT
(1,1)
Figure 2-21 Example of Multiple Relationships (2 of 2)
b) Professors and courses (fixed lower limit constraint)
At least two
professors must be
qualified to teach
each course. Each
professor must be
qualified to teach at
least one course.
N
M
Is
Qualified
PROFESSOR
(1,N)
COURSE
(1,2)
Chen
Special Entities (1/3)
Strong entity
Weak entity (
Identifying relationship
)
Weak entity
What is weak entity?
1. Cannot exist without entity with which it has a
relationship. (existence dependence)
2. Has primary key that is partially or totally derived from the
parent entity in the relationship.
Example data for weak entity
Weak entity
Strong entity
Identifying relationship
Weak entity
Special Entities (2/3)
Composite entity (
) (associative entity
)
A bridge entity used in ERD to resolve M:N relationship between two or more
entities.
1
N
M
1
PACKAG
E_PC
PACKAGE
(1,M)
PC
(1,1)
(1,1)
(1,N)
Composite entity
combination of those
primary keys will theprimary
keyof
tr o
be
enrollsin
entiey
"
Example data for composite entity
Special Entities (3/3)
Super-type entity
Contains shared attributes.
Sub-type entity
Contains unique attributes.
G: non-overlapping subtypes.
Gs: overlapping subtypes.
JOIN PILOT (sub-type) & EMPLOYEE (super-type) will get the full data
of PILOT
Super-type & sub-type
We will NOT use this notation in this page.
Example data for super-type & sub-type
EMPLOYEE (super-type)
PILOT (sub-type)
The Enhanced Entity-Relationship Model
Introduction to the EER model Conceptual Data Modeling
Supertypes and Subtypes
Enhanced E-R (EER) model extends original E-R model with new
modeling constructs
Subtype: A subgrouping of the entities in an entity type that has
attributes distinct from those in other subgroupings
Supertype: A generic entity type that has a relationship with one
or more subtypes
Attribute Inheritance:
Subtype entities inherit values of all attributes and relationships of the
supertype
An instance of a subtype is also an instance of the supertype
Figure 3-1 Basic Notation for Supertype/Subtype Notation (1 of 2)
8
a) EER notation
SUPERTYPE
SUBTYPE 1
SUBTYPE 2
Figure 3-1 Basic Notation for Supertype/Subtype Notation (2 of 2)
b) Microsoft Visio Notation
Figure 3-2 Employee Supertype with Three Subtypes
All employee subtypes will have employee number, name, address, and date hired
Each employee subtype will also have its own attributes
EMPLOYEE
G
HOURLY
EMPLOYEE
G
SALARIED
EMPLOYEE
Employee supertype with three subtypes
All employee subtypes
will have emp nbr, name,
address, and date-hired
Each employee subtype
will also have its own
attributes
COUSULTANT
Relationships and Subtypes
Relationships at the supertype level indicate that all subtypes will
participate in the relationship
The instances of a subtype may participate in a relationship unique to
that subtype. In this situation, the relationship is shown at the
subtype level
Figure 3-3 Supertype/Subtype Relationships in a Hospital
Patient
ID
Admit
Date
Patient
Name
Physician
ID
M
Is
Cared
For
PATIENT
(1,1)
1
RESPONSIBLE
PHYSICIAN
(0,M)
G
1
OUTPATIENT
Checkback
Date
RESIDENT
PATIENT
Date
Discharged
(1,1)
1
Is
Assigned
BED
(0,1)
Bed ID
Supertype/subtype relationships in a hospital
Both outpatients and
resident patients are
cared for by a
responsible physician
Only resident patients are
assigned to a bed
79
Generalization and Specialization
Generalization: The process of defining a more general
entity type from a set of more specialized entity types.
BOTTOM-UP
Specialization: The process of defining one or more subtypes
of the supertype and forming supertype/subtype
relationships. TOP-DOWN
Figure 3-4 Example of Generalization (1 of 2)
a) Three entity types: CAR, TRUCK, and MOTORCYCLE
All these types of vehicles have common attributes
Figure 3-4 Example of Generalization (2 of 2)
b) Generalization to VEHICLE supertype
We put the shared attributes in a supertype. Note: no subtype for motorcycle,
since it has no unique attributes
All these types of vehicles
have common attributes
So we put the shared attributes in a
supertype
Generalization
Figure 3-5 Example of Specialization (1 of 2)
a) Entity type PART
Note: Routing Number only applies if part is manufactured in house.
Supplier only applies if part is purchased from a supplier.
Figure 3-5 Example of Specialization (1 of 2)
a) Entity type PART
Note: Routing Number only applies if part is manufactured in house.
Supplier only applies if part is purchased from a supplier. Applies only to purchased parts
Supplier
ID
Part No
Description
Location
Qty On
Hand
Routing
Number
Unit
Price
Supplier
Only applies
to
manufactured
parts
PART
Figure 3-5 Example of Specialization (2 of 2)
b) Specialization to MANUFACTURED PART and PURCHASED PART
Multivalued composite attribute replaced by associative entity relationship to another entity
Part No
Description
Location
Qty On
Hand
PART
Supplier
ID
SUPPLIER
1
(0,M)
o
(1,1) M
MANUFACTURED
PART
Routing
Number
PURCHASED 1 M
PART
(1,M) (1,1)
Part No
Supplier
ID
SUPPLIES
Unit
Price
Specialization
Constraints in Supertype/Subtype Relationships
Completeness Constraints: Whether an instance of a
supertype must also be a member of at least one subtype
Total Specialization Rule: Yes (double line)
Partial Specialization Rule: No (single line)
Figure 3-6 Examples of Completeness Constraints (1 of 2)
a) Total
specialization rule
Patient
ID
Admit
Date
Patient
Name
Physician
ID
M
Is
Cared
For
PATIENT
(1,1)
1
RESPONSIBLE
PHYSICIAN
(0,M)
A patient must be either
an outpatient or a
resident patient
d
1
RESIDENT
PATIENT
OUTPATIENT
(1,1)
1
Is
Assigned
BED
(0,1)
Date
Discharged
Checkback
Date
Bed ID
Figure 3-6 Examples of Completeness Constraints (2 of 2)
b) Partial specialization rule
Make
Price
Engine
Displacement
Vehicle ID
A vehicle could be a car,
a truck, or neither
Vehicle
Name
VEHICLE
CAR
No Of
Passengers
Model
TRUCK
Capacity
Cab Type
Constraints in Supertype/Subtype Relationships (1 of 2)
Disjointness Constraints: Whether an instance of a
supertype may simultaneously be a member of two (or
more) subtypes
Disjoint Rule: An instance of the supertype can be only ONE of the
subtypes
Overlap Rule: An instance of the supertype could be more than
one of the subtypes
Figure 3-7 Examples of Disjointness Constraints (1 of 2)
Figure 3-7 Examples of Disjointness Constraints (1 of 2)
Patient
Name
Patient ID
Admit Date
PATIENT
Physician ID
M
Is_Cared_
For
(1,1)
a) Disjoint rule <Chen>
1
(0,M)
A patient can either be outpatient
or resident, but not both
d
1
1
RESIDENT
PATIENT
OUTPATIENT
RESPONSIBLE
PHYSICIAN
BED
Is_Assigned
(0,1)
(1,1)
Date
Discharged
Checkback
Date
Bed ID
Figure 3-7 Examples of Disjointness Constraints (1 of 2)
Patient
Name
Patient ID
Admit Date
PATIENT
Physician ID
M
Is Cared
For
(1,1)
a) Disjoint rule <Chen>
(alternative notation)
1
(0,M)
RESPONSIBLE
PHYSICIAN
G
1
OUTPATIENT
RESIDENT
PATIENT
Date
Discharged
BED
Is Assigned
(1,1)
Checkback
Date
1
(0,1)
Bed ID
Figure 3-7 Examples of Disjointness Constraints (2 of 2)
Figure 3-7 Examples of Disjointness Constraints (2 of 2)
b) Overlap rule <Chen>
Part No
Description
Qty On
Hand
Location
Supplier ID
SUPPLIER
PART
1
(0,M)
o
A part may be both purchased
and manufactured
(1,1)
1
MANUFACTURED PART
PURCHASED PART
Part No
M
SUPPLIES
(1,M)
Routing
Number
M
(1,1)
Supplier ID
Unit Price
Figure 3-7 Examples of Disjointness Constraints (2 of 2)
b) Overlap rule <Chen> (alternative notation)
Part No
Description
Qty On
Hand
Location
Supplier ID
SUPPLIER
PART
1
(0,M)
Gs
(1,1)
1
MANUFACTURED PART
PURCHASED PART
Part No
M
SUPPLIES
(1,M)
Routing
Number
M
(1,1)
Supplier ID
Unit Price
Constraints in Supertype/Subtype Relationships (2 of 2)
Subtype Discriminator: An attribute of the supertype whose
values determine the target subtype(s)
Disjoint a simple attribute with alternative values to indicate the
possible subtypes
Overlapping a composite attribute whose subparts pertain to
different subtypes. Each subpart contains a Boolean value to
indicate whether or not the instance belongs to the associated
subtype
Figure 3-8 Introducing a Subtype Discriminator (Disjoint Rule)
Figure 3-8 Introducing a Subtype Discriminator (Disjoint Rule)
Employee
Number
Employee
Name
Address
Date Hired
Employee
Type
EMPLOYEE
Employee Type
A simple attribute with
different possible values
indicating the subtype
d
HOURLY
EMPLOYEE
Hourly Rate
Annual
Salary
SALARIED
EMPLOYEE
Stock Option
CONSULTANT
Contract
Number
Billing Rate
Figure 3-8 Introducing a Subtype Discriminator (Disjoint Rule)
Employee
Number
Employee
Name
Address
Date Hired
Employee
Type
EMPLOYEE
G
HOURLY
EMPLOYEE
Hourly Rate
Annual
Salary
G
SALARIED
EMPLOYEE
Stock Option
COUSULTANT
Contract
Number
Figure 3-9 Subtype Discriminator (Overlap Rule)
Billing Rate
Figure 3-9 Subtype Discriminator (Overlap Rule)
Description
Part_No
Qty_On_
Hand
Purchased?
Manufactur
ed?
Location
Supplier ID
Part Type
PART
A composite attribute
with sub-attributes
Part Type
1
PURCHASED PART
M
M
SUPPLIES
(1,M)
Routing
Number
1
(0,M)
to determine whether it
is of each subtype
(1,1)
o
MANUFACTURED PART
SUPPLIER
Part No
(1,1)
Supplier ID
Unit Price
Figure 3-9 Subtype Discriminator (Overlap Rule)
Description
Part No
Part Type
Location
Qty On
Hand
Supplier ID
SUPPLIER
PART
1
(0,M)
Gs
(1,1)
1
MANUFACTURED PART
PURCHASED PART
Part No
M
SUPPLIES
(1,M)
Routing
Number
M
(1,1)
Supplier ID
Unit Price
Figure 3-10 Example of Supertype/Subtype Hierarchy
Figure 3-10 Example of Supertype/Subtype Hierarchy
SSN
Name
Address
Date Of
Birth
Gender
PERSON
Date
Hired
Major Dept
o
Salary
STUDENT
EMPLOYEE
ALUMNUS
d
d
Degree
FACULTY
Rank
STAFF
Position
Year
Date
Designation
GRADUATE STUDENT
Test Score
UNDERGRADUATE
STUDENT
Class Standing
Union Types (Categories)
All of the superclass/subclass relationships we have seen thus far
have a single superclass
A shared subclass is a subclass in:
more than one distinct superclass/subclass relationships
each relationships has a single superclass
shared subclass leads to multiple inheritance
In some cases, we need to model a single superclass/subclass
relationship with more than one superclass
Superclasses can represent different entity types
Such a subclass is called a category or UNION TYPE
Union Types (Categories)
Example: In a database for vehicle registration, a vehicle owner can
be a PERSON, a BANK (holding a lien on a vehicle) or a COMPANY.
A category (UNION type) called OWNER is created to represent a subset of
the union of the three superclasses COMPANY, BANK, and PERSON
A category member must exist in at least one (typically just one) of its
superclasses attyibute inheritance
it
depends on which
Difference from shared subclass, which is a:
supertype
belongsto
subset of the intersection of its superclasses
shared subclass member must exist in all of its superclasses
attributes
and inherit all
supertypes
'
Two categories
(UNION types):
OWNER,
REGISTERED_VEHICLE
Alternative
Diagrammatic
Notations - UML
ER/EER diagrams are a specific notation for
displaying the concepts of the model
diagrammatically
DB design tools use many alternative notations
for the same or similar concepts
One popular alternative notation uses UML
class diagrams
Alternative
Diagrammatic
Notations - ERD
Entity Clusters
v
EER diagrams are difficult to read when there are too many
entities and relationships.
Solution: Group entities and relationships into entity clusters.
Entity cluster: Set of one or more entity types and associated
relationships grouped into a single abstract entity type
Figure 3-13
Entity
Clustering for
Pine Valley
Furniture
Company
(1 of 2)
Figure 3-13
Entity
Clustering for
Pine Valley
Furniture
Company (2 of 2)
a) Possible entity
clusters (using
Microsoft Visio)
Related groups of
entities could
become clusters
b) EER diagram for
entity clusters
(using Microsoft
Visio)
it?
Figure 3-14 Entity Clustering for Pine Valley Furniture Company
Detail for a single cluster
TA Discussion Sessions
Susan Su
Sandy Lee
Bo-Yi Li
John Jiang
MS Candidate
MS Student
PhD Candidate
MS Student
110356007@nccu.edu.tw
110356017@nccu.edu.tw
107356508@nccu.edu.tw
111356034@nccu.edu.tw
Kaiser Zheng
Yi-Ting Chang
MS Student
Andy Lee
MS Student
MS Student
110356035@nccu.edu.tw
110356014@nccu.edu.tw
Time:
For Tuesday Class:
Tuesdays 7 pm - 9 pm
For Thursday Class:
Thursdays 7 pm - 9 pm
TA Class Location:
Yi Xian Bldg.
050502 (5th floor)
111356042@nccu.edu.tw
Group Discussion Location:
ITI Lab at College of
Commerce Bldg. 260526 (Time to be
announced during semester)
Physical-learning students are
required to attend the TA classes &
group discussions.
Wen Jing Chen
MS Student
111356010@nccu.edu.tw
Richard Lin
MS Student
111753205@nccu.edu.tw
Participation may be counted.
Assignments, practices, and tips
provided in the TA classes may be
highly beneficial to the final project
(which counts for 45 points).
Bonus points may be offered.
Starting from Feb 21 / 23
Your homework
Start to make teams (
5+ 1
people in a group).
Attend the TA discussion sessions (starting from Feb 21/23).
Submit the list of team members to our TA team.
If you wish our TA to help you make teams, send your
information to our TA team.
Start your brainstorming and make plans.
HW1: Requirement Analysis will be due on Mar 14, 2023.
See you next week!
See you next week!