Lecture 2 ER Model

MLLO 20180228
What is a Model?
❖ A model is an abstract representation of (a part of)
➢ Physical world
➢ Domain with a lot of details
➢ Complicated set of things
❖ Different models have
➢ Different degrees of abstraction
➢ Different degrees of expressive power (model power)
Database Some data
and need for
Application Design application

Process Data Model Type/ Requirements collection

DBMS independent and analysis
● Model type independent phase
○ Requirements collection
and analysis Functional requirements Data requirements
■ Data requirements
■ Functional Functional analysis Conceptual Design
requirements High level transaction
○ Conceptual design Conceptual schema
specification
■ Conceptual schema
Data Model Type specific, Logical design
○ Functional analysis
■ High-level
DBMS independent (Data model mapping)
transaction Logical schema
specification Application program
● Model type specific phase design Physical design
● DBMS specific phase DBMS
specific
Transaction
Internal schema
implementation
Application program Database
The Entity-Relationship Model
❖ Proposed by Peter Chen in 1976
❖ An very abstract model that can be on top of other data models
Modeling
Data ER Model

Modeling
Relational model OO model Networked model

Relational database OO database Networked database

❖ Why we need this extra layer of model?

➢ It helps us see things more clearly
➢ Especially the relationship among entities
Why Study ER Model?
● Allow designers to think accurately and clearly at the high level, without
worrying about or become prejudiced by
○ Specific data model to use
○ Implementation details
● Relationships become a first-order concept. Designers can consider and
design for relationships clearly.
● Most importantly, help us to think clearly in terms of sets and relationships
between sets, thus design our system correctly (and hopefully also more
efficiently.)
The ER Model
❖ Entity-Relationship Model
➢ Entities, Attributes, Relationships
❖ Entities
➢ Objects distinguishable from other objects
➢ Can be described using a set of attributes
❖ Attributes
➢ Describe an entity
➢ Has a name, has an atomic domain for its value: string, integer
❖ Relationship
➢ Association between entities
❖ Entity-Relationship Diagram
➢ Graphical representation
ER Diagram of Entities and Attributes

Student University

Name Age Name Location

Attribute values
● Attributes value
○ Each value is drawn from a Value set or Domain of attribute
■ Domain: the set of all possible values for an attribute
○ Single-valued vs Multi-valued
■ E.g. ID vs favorite books
○ Simple value vs Composite value
■ E.g. Address expressed as text string, is single-valued
■ E.g. Address modeled as Street No. X Street name X City Name, is composite-valued
○ Storaged value vs Derived value/derived attribute
■ E.g. Age can be derived from birthday
○ Null value
■ An attribute can have a null value: no value exist or “not applicable”
■ E.g. Occupation for children
Multivalued attributes
● An attribute whose value consists
of multiple atomic values Student

● E.g. Hobbies = {reading, movies,

sports}
Name Age Hobbies
● In ERD, represented as a
double-oval
Composite-Value Attribute
Address
● Whether an attribute takes
simple value or composite
value as its value is a design Street
issue, not a nature of the address City State Zip
attribute
● E.g. Address on the right can
be designed as a Number Street
Apartment
number
○ Composite value attribute with
street address, city, state, etc. as
components
○ Simple value attribute with a text
string describing the whole
address
● What is best for your
application?
Null value
● Three types of NULL value
○ Not applicable
○ Known to be exist, but value not known
○ Do not known whether it exists
● Assume we can a student database, if the following value of attributes is
NULL, what type of NULL is it?
○ The “GPA” of a student who just enters the school is NULL
○ The height of student is NULL
Think!
○ The home phone of a student is NULL
● Why bother with the difference?
○ It may affect how we handle the missing value
Complex Attributes
● Multivalued attribute and composite attribute can be nested
○ Notation:
■ Multivalued attribute: {value1, value2, …}
■ Composite attribute: (component1, component2, …)
● E.g.
○ A person is allowed to have multiple residence, each residence has one address and multiple
phones:
■ {AddressPhone ( {Phone( Area_code, phone_number)}, address( Street_address(
Number, Street, appartment_number), City, Zipcode))}
Entity, Entity Type, Entity Set
● Entity type: a group of entities with the same attributes and name
● Entity instance: a instance of the entity type
● Entity set: a set of of entity instances at any point of time
● In the literature, not all papers/books use the terms rigorously
● E.g.
○ Employee: is an entity type
○ “John”: is an entity (of the entity type Employee)
○ {“John”, “Mary”, “Peter”} is an entity set
補充：Intension and Extension
● Sometimes we see terms “Intension” and “Extension” is literature concerning
data modeling or conceptual model
● Originally a terminology used in Logic, Linguistics, Mathematics, and Philosophy in
general
● 簡言之 (非正式):
○ Intension: 一群物體背後的共同定義．觀念界的存在．如；"人"這個概念
○ Extension: 符合某一定義的個體的集合; 某一個觀念的外顯．現象界的存在．如: 現在
教室裡所有的人的集合
● Note: Intension != Intention
● Entity type is an Intension
● Entity and Entity set are Extension
Key Attributes of an Entity Type (Important!)
● For an entity type, there may exist one
Student
or more attributes, such that which Different students
may have same
entity in the entity type takes a unique names
value in each of these attributes. Such Name Age
an attribute is called a key attribute of
the entity type Designed as:
● Also called a uniqueness constraint
● In practice, for an entity type to be
useful, it usually needs to have at least Student
one key attribute
● Represented with an underline in ER
ID Name Age
diagram
Attribute: Mathematical Definitions
● Assume A is an attribute of entype type of E, with value set (domain) V. A is
defined as a function from E to the power set V, denoted P(V). That is:

A: E → P(V)

○ Note: the power set of a set S is the set of all subsets of S, including empty set.
○ E.g. S={a, b}, P(S) = { {}, {a}, {b}, {a, b}}
● For single-valued attributes, A(E) maps only to singleton sets in P(V)
● For multivalued attributes, A(E) maps to all of P(V) . That is, there is no
restriction in the mapping
Relationship
● Intuitively:
○ Relationship in daily experience
● ER model:
○ An attribute of one entity type refers to another entity type
○ In ER model, such reference should be relationship rather than attribute
● ER model design
○ Relationship are usually initially captured in the form of attributes.
○ As the design is refined, these attributes gets converted into relationships between entity types
Designing Relationship in ER Modeling
Student Department

ID Name Age Dept ID Name

Student enroll Department

ID Name Age ID Name

Relationship Types, Sets and Instances
● Relationship type: a group of associations between entities
● Relationship instance: a instance of the relationship type
● Relationship set: a set of of relationship instances at any point of time
● In the literature, not all papers/books use the terms rigorously
● E.g.
○ A student and the department he/she registers from a relationship type
○ “John” register in dept of EE, is a relationship instance
○ { (“John”, EE), (“Mary”, Physics), (“Peter”, Literature) } is a relationship set
●
Relationship:Mathematical Definitions
● Assume E1, E2, ... , En are entity types , and e1, e2, … en are instances of these n entity
types, respectively.
○ A relationship set is a function RS is a mapping from the Cartesian product of E1, E2, … En to the truth value.
○ The corresponding relationship type RT is the set of possible F.
○ A relationship instance is an element of the Cartesian product of E1, E2, … En, for which RS maps it to “T”.
● That is,
RS: E1 X E2 X ... X En → {T, F}
RT: {All possible RS}
ri: such that RS(ri) = T
● Alternatively (text book)
RS: a subset of E1 X E2 X ... X En
RT: power set of RS
ri: an element of an RS
Relationship vs Relation
❖ Relationship:
➢ A daily concept
➢ A logical concept
❖ Relation
➢ A mathematical construct with rigorous definition
❖ We can use Relation to model Relationship mathematically
❖ Relation == Relationship set
Relations
❖ Mathematical definition:
➢ Let A, B be two sets, a relation R between A and B is a subset of A x B (Cartesian product of
A and B)
➢ The relation R usually has a name
❖ E.g.
➢ A = {Tom, Many, John}, B={Dog, Cat, Bird, FIsh}
➢ R = {(Tom, dog), (Tom, cat), (Mary, bird), (John, cat)}

A Dog B
Tom
Cat
Mary
Bird
John
Fish
Degree of Relationships Binary relationship,
degree=2
● The degree of a relationship Student enroll Department
type is the number of
participating entity types
● Relationship can be of any
ID Name Age ID Name
degree in theory
● Relationship of degree 2: binary.
Most common. ID Name
● Relationship of degree 3: ternary Ternary relationship
● In theory there is no limit to the Degree=3 Part
number of degree
Supplier supply Project
● In practice, binary or ternary are
most frequently used
ID Cname ceo ID Name
Role Name
● For each entity type participating in
Student enroll Department
a relationship type, a role name
signifies the role it plays in each
relationship instance.
ID Name Age ID Name
● Role names are not technically
necessary in relationship types
where all the participating entity Role name: Role name:
types are distinct. student department
○ Each participating entity type
name can be used as the role
name.
● Role names are indispensable in
recursive relationships.
 super-
Recursive Relationship vise
Superviser Supervisee

● Recursive relationship: A Employee

relationship where two or more
participating entities are of the ID Name Age

same entity type

● Role name are necessary to
understand recursive relationship Employee Supervise

● Recursive relationship is important Superviser

Tom
in real-life DB applications
Supervisee S1
● E.g. Mary Superviser
○ Employee = {Tom, Mary, John}, S2
Relationship: supervise = {(Tom, Mary), John Supervisee
(Mary, John)}
Constraints on Relationship Types
● Relationship types usually have certain constraints that limit the possible combinations of entities
that may participate in the corresponding relationship set.
● Note: Constraints are determined by the real world situation which the relationships try to model.
● E.g.: Company A may have a rule that each employee must work for exactly one department;
company B may not have such restriction.
→ There is a constraint on the relationship between employee and department in the database of
company A
● Two important kinds of constraints:
○ Cardinality ratio
○ Participation
Cardinality Ratio
● Three types
○ 1:1
○ 1:N / N:1
○ N:M
● It’s best to understand through examples
Cardinality Ratio 1:N
N 1
● Assume entity type EMPLOYEE
works
DEPT
for
EMPLOYEE, DEPT, and
Relationship type:
WORKS_FOR ID Name Age ID Name

○ Each EMPLOYEE instance

works for exactly one EMPLOYEE WORKS_FOR DEPT
department.
e1 w1
○ Each DEPT instance can have
e2 w2 d1
many employees w3
e3
○ We say, in relationship type e4 w4 d2
WORK_FOR, DEPT and e5 w5
EMPLOYEE are of cardinality e6 w6 d3
1:N e7 w7
Cardinality Ratio 1:1
1 1
● Assume entity type EMPLOYEE MANAGES DEPT
EMPLOYEE, DEPT, and
Relationship type: MANAGES
○ Each EMPLOYEE instance may ID Name Age ID Name
manage exactly one department.
○ Each DEPT instance can have
EMPLOYEE MANAGES DEPT
exactly one employee who
manage it e1 w1
○ We say, in relationship type e2 w2 d1
e3 w3
MANAGES, DEPT and
e4 w4 d2
EMPLOYEE are of cardinality 1:1 w5
e5
e6 w6 d3
e7 w7
Cardinality Ratio M:N
M N
● Assume entity type EMPLOYEE DEPT
WORKS_ON
EMPLOYEE, PROJ, and
Relationship type:
WORKS_ON ID Name Age ID Name

○ Each EMPLOYEE instance can

work on many projects EMPLOYEE WORKS_ON PROJ
○ Each PROJ instance can have
e1 w1
many employees working on it
e2 w2 p1
○ We say, in relationship type w3
e3
WORK_ON, EMPLOYEE and e4 w4 p2
PROJ are of cardinality M:N e5 w5
e6 w6 p3
e7 w7
Participation Constraints
● Participation constraint specifies the minimum number of relationship
instances that each entity instance participates in, and is sometimes
called the minimum cardinality constraint.
● There are two types of participation constraints
○ Total participation
○ Partial participation
Total Participation Constraint
● En entity type is under total N works 1
EMPLOYEE DEPT
for
participation constraint in a
relationship type, if each entity
instance must participate at
ID Name Age ID Name
least once in that relationship.
● E.g.: if a company requires
that each employee work for EMPLOYEE WORKS_FOR DEPT
one department, and no e1 w1
employee is allowed not to e2 w2 d1
e3 w3
work for any department
e4 w4 d2
● Not total participation is called w5
e5
partial participation e6 w6 d3
e7 w7
Total Participation and Existence Dependency
● Total participation is also called existence dependency
● Because if an entity type E1 must have total participation in relationship to an
entity type E2, it can be considered that the existence of E1 in the database
depends on E2.
● E.g. in the previous example, the existence of EMPLOYEE depends on DEPT

● Structural Constraints
○ We refer to Cardinality Ratio and Participation Constraints together as Structural Constraints
Review and Think

We talk about Structural Constraint

→ Structure of what?

We are talking about Relationship

We examine the participation behaviors of the members (entity

instances) of sets (entity types) to define the structure of
Relationships
Relationship and Attributes
● Relationship with Attribute & Relationship as Attribute
● Relationship with Attribute
○ Relationship can have attributes itself
○ 1:1 relationship, 1:N relationship: attributes can move to entity
■ 1:1: move to either entity
■ 1:N: move to the N-side entity
■ Where to put the attribute is a design issue
○ For M:N relationship
■ The attribute cannot be moved to the entities, it must be associated with the relationship
 Example: “Start_date” attribute
Start Start
date date

N Work 1 N Work 1
EMPLOYEE DEPT EMPLOYEE DEPT
for for

Nam Nam Nam Nam

ID e
Age ID e ID e
Age ID e

EMPLOYEE WORKS_FOR DEPT EMPLOYEE WORKS_FOR DEPT

e1 w1 e1 w1
e2 w2 d1 e2 w2 d1
e3 w3 e3 w3
e4 w4 d2 e4 w4 d2
e5 w5 e5 w5
e6 w6 d3 e6 w6 d3
e7 w7 e7 w7
Example: “Start_date” Attribute
M N
EMPLOYEE WORKS_ON PROJ

Start
date

ID Name Age ID Name

EMPLOYEE WORKS_ON PROJ

e1 w1
e2 w2 p1
e3 w3
e4 w4 p2
e5 w5
e6 w6 p3
e7 w7
 Relationship as Attribute We can also think of and implement
relationship as attribute
● If we do not plan to access the other
Start entity independently in the application
date

N Work 1 Working
EMPLOYEE DEPT EMPLOYEE
for DEPT
Start
date
Nam Nam Nam
ID e
Age ID e ID e
Age

EMPLOYEE WORKS_FOR DEPT

e1 w1
e2 w2 d1 Hobbies DEPT
w3 OR EMPLOYEES
e3
e4 w4 d2
e5 w5
e6 w6 d3 Nam
ID e
e7 w7
Weak Entity Type
● Weak entity type: entity types that do not have key attributes of their own
● Regular entity types do have a key attribute, and are called strong entity types.
○ All examples we see so far are strong entity types
● How to identify weak entity type instances?
○ Identified by: one relationship + one attribute
■ Identified by a relationship to another entity type in combination with one of weak entity’s
attribute value
■ We call this other entity type the identifying entity type or owner entity type,
■ We call the relationship type that relates a weak entity type to its owner the identifying
relationship of the weak entity type.
■ Owner entity type is sometimes also called dominating, or parent entity type
■ The weak entity type is sometimes also called subordinate, or child entity type
Weak Entity Type (2): Example
Partial
key

Subject score comment

Math 99 It’s very interesting

ID name
Physics 80 Quite hard
99633 John
Math 90 Quite useful
99634 Mary
History 70 It’s boring
99635 Peter
History 95 A lot of fun

Identifying entity type Identifying Cooking 88 I had fun

relationship
Weak entity type
Weak Entity Type (3)
● More about weak entity type:
○ A weak entity type always has a total participation constraint(existence dependency) with
respect to its identifying relationship because a weak entity cannot be identified without an
owner entity.
○ However, not every existence dependency results in a weak entity type.
● Partial key: the attribute which uniquely identifies the weak entity instances with respective to a
specific owner entity instance

Identifying relationship Weak entity type

Enhanced Entity-Relationship Model
● Origin
○ ER model is sufficient for most traditional applications
○ New applications in manufacturing (CAD/CAM), telecommunications, complex software
systems, and Geographic Information Systems (GIS), etc. require more modeling power
○ ER enhanced with semantic data modeling concepts → Enhanced ER Model
■ Semantic data modeling is also used in AI and software engineering
● EER model
● EER diagram
EER Key Concepts
● Superclass / Supertype vs Subclass / Subtype
● Specialization vs generalization
● Predicate-defined subclasses (or Condition defined subclasses)
○ Defining predicate
○ Attribute defined specialization
■ Defining attribute of specialization
○ vs User-defined subclasses
● Constraints on specialization
○ Disjointness constraint: Disjoint vs overlapping
○ Completeness constraint: Total vs partial
● Union type / category
EER example (1)
ID name

Specialization Employee Superclass/supertype

Generalization d

U
U

U
Secretary Technician Engineer Subclass/subtype

Typing Tgrade Eng_

speed type
● A secretary is also an employee. It’s
the same person
● A secretary inherits all the attribute of
Specific attributes
Employee, but has its own specific
attribute “typing_speed”.
EER example (1A)
Job
ID name
type
Specialization Employee
Job type
Defining predicate
d

U
U

U
Secretary Technician Engineer Subclass/subtype

Typing Tgrade Eng_

speed type
If there is a “job type” attribute in Employee
entity type to identify the kind of job an
Employee instance takes, the subclasses
Specific attributes “Secretary”, “Technician”, “Engineer” will
be predicate defined subclasses.
Otherwise they are called user-defined.
EER example (2)
ID name

Employee

d U

U
U

U ● Some relationship are only

Secretary Technician Engineer Manager participated by specific subclass
● In this example, only Manager
Eng_ managers Project
Typing Tgrade
type ● This illustrates the importance of
speed
man- subtypes
ages

Project
EER example (3)
Total specialization
ID name
Disjoint specialization Disjoint specialization
Employee

d U d Hourly
U

U
U
U

U pay
Secretary Technician Engineer Manager Salary_ Hourly_
Employee Employee

Typing Tgrade Eng_

type Salary
speed
man- Be-
ages long

Project Trade union

Partial specialization