DATABASE SYSTEMS

Chapter 12
ENTITY-RELATIONSHIP MODELING
Chapter Objectives
• How to use Entity–Relationship (ER) modeling in database design.
• The basic concepts associated with the ER model: entities,
relationships, and attributes.
• A diagrammatic technique for displaying an ER model using the
Unified Modeling Language
(UML).
• How to identify and resolve problems with ER models called
connection traps.
ER diagram of Branch user views of DreamHome
Concepts of the ER Model
•Entity types (Rectangles)
•Relationship types (Links)
•Attributes (Names inside rectangles)
Entity Type
“A group of objects with the same properties, which are identified by
the enterprise as having an independent existence.”

Entity occurrence:
A uniquely identifiable object of an entity type
ER diagram of Staff and Branch entity types
Relationship Types
Relationship type:
◦ Meaningful associations among entity types.
◦ i.e., Link between classes
◦ Name occurs as label on the link
◦ Arrow indicates direction of relationship type
Relationship occurrence:
◦ Uniquely identifiable association, which includes one occurrence
from each participating entity type.
◦ i.e., Link between instances
ER diagram of Branch Has Staff
relationship type
Relationship Types
Degree of a Relationship
◦ Number of participating entities in relationship.

Relationship of degree :
◦ A relationship of degree two is called binary
◦ A relationship of degree three is ternary
◦ A relationship of degree four is quaternary.
Binary relationship called POwns
Ternary relationship called Registers
(add diamond instead of label)
Quaternary relationship called Arranges
(add diamond instead of label)
Relationship Types
Recursive Relationship:
◦ Relationship type where same entity type participates more than
once in different roles.

Relationships may be given role names to indicate purpose that each

participating entity type plays in a relationship.
◦ End up with 2 labels on arrow (one per role)
Recursive relationship called Supervises with role
names
Entities associated through two distinct
relationships with role names
Attributes
Attribute
◦ Property of an entity or a relationship type.
◦ Line below relationship type name, separating name from attributes
Attribute Domain
◦ Set of allowable values for one or more attributes.
Simple Attribute
◦ Attribute composed of a single component with an independent existence. E.g. salary
Composite Attribute
◦ Attribute composed of multiple components, each with an independent existence.
E.g. address
◦ Indent components under attribute name
Attributes
Single-valued Attribute
◦ Attribute that holds a single value for each occurrence of an entity type. E.g. Branch no.
◦ Add name under relationship type name
Multi-valued Attribute
◦ Attribute that holds multiple values for each occurrence of an entity type. E.g. tel no. of
Branch B003 can be two or more.
◦ Add number n or range [n..m] after attribute name
Derived Attribute
◦ Attribute that represents a value that is derivable from value of a related attribute, or set of
attributes, not necessarily in the same entity type.
◦ Add ‘/’ before attribute name
◦ E.g. for birthdate ---- /age
Keys
Candidate Key (add {CK} or {AK} for alternate key after attribute name)
◦ Minimal set of attributes that uniquely identifies each occurrence of an entity
type.

Primary Key (add {PK} after attribute)

◦ Candidate key selected to uniquely identify each occurrence of an entity type.

Composite Key (unknowable; put {PK} after both attributes)

◦ A candidate key that consists of two or more attributes.
ER diagram of Staff and Branch entities and their attributes
Attributes on Relationships
•Attributes can also be assigned to relationships.
•Attributes associated with a relationship type can be represented using the
same symbol as an entity type.
•To distinguish between a relationship with an attribute and an entity, the
rectangle representing the attribute(s) is associated with the relationship using a
dashed line.
 Relationship called Advertises with attributes
(Note: No name on the box for relationship attributes)
Structural Constraints
•Main type of constraint on relationships is called multiplicity.
•Multiplicity - number (or range) of possible occurrences of an entity type that
may relate to a single occurrence of an associated entity type through a
particular relationship.
•The most common degree for relationships is binary.
Binary relationships are generally referred to as being:
◦ one-to-one (1:1)
◦ one-to-many (1:*)
◦ many-to-many (*:*)
Multiplicity of Staff Manages Branch (1:1) relationship
Multiplicity of Staff Oversees PropertyForRent (0:*)
relationship type
Multiplicity of Newspaper Advertises PropertyForRent (*:*)
relationship
Structural Constraints
•Multiplicity for Complex Relationships
o Number (or range) of possible occurrences of an entity type in an n-ary
relationship when other (n-1) values are fixed.
o Multiplicity is made up of two types of restrictions on relationships:
cardinality and participation.
The multiplicity of the ternary Registers relationship.
Structural Constraints
Cardinality
◦ Describes maximum number of possible relationship occurrences
for an entity participating in a given relationship type.
Participation
◦ Determines whether all or only some entity occurrences
participate in a relationship.
Multiplicity described as cardinality and participation constraints for
the Staff Manages Branch (1:1) relationship.
Summary of multiplicity constraints
ER Modeling Process
• Get requirements from user
• Create ER diagram (Conceptual modeling)
◦ Nouns -> entities or attributes
◦ Verbs -> relationships
• Map from ER diagram to SQL tables (Logical modeling)
◦ Entities -> tables
◦ Attributes -> tables or attributes
◦ Relationship attributes -> tables or attributes
Example
Draw the ER Diagram for the following online registration system:
◦ The university offers courses uniquely identified by department
and course number.
◦ There may be multiple sections of a given course in a particular
semester, including no offerings at all.
◦ Sections are taught by professors in rooms (identified by building
number and room number).
◦ Rooms have specific capacities, but sections may have lower
capacity (unused seats).
◦ Students enroll in sections.
Example – Identify nouns
Draw the ER Diagram for the following online registration system:
◦ The university offers courses uniquely identified by department
and course number.
◦ There may be multiple sections of a given course in a particular
semester, including no offerings at all.
◦ Sections are taught by professors in rooms (identified by building
and room number).
◦ Rooms have specific capacities, but sections may have lower
capacity (unused seats).
◦ Students enroll in sections.
Example1 – Select entities (in red) (Rest are
attributes or discarded)
Draw the ER Diagram for the following online registration
system:
◦ The university offers courses uniquely identified by department and
course number.
◦ There may be multiple sections of a given course in a particular
semester, including no offerings at all.
◦ Sections are taught by professors in rooms (identified by building and
room number).
◦ Rooms have specific capacities, but sections may have lower capacity
(unused seats).
◦ Students enroll in sections.
ER Model
Course: dept. name, course number, title, credit hours,
description, …
Section: sectionId, semester, professor name, Student:
studentId, name, major, …
EnrolledIn: relationship between Student-Section
Offered: relationship between Section-Course
◦ Relationship attributes: building name, room number, room
capacity
Add Multiplicity
Student – Section
◦* : *
Course – Section
◦1 : *
Map to Tables
Course: dept. name, course number, title, credit hours,
description, …
Section: sectionId, semester, professor name,
Student: studentId, name, major, …
Enrollment: studentID, sectionID
Room: building name, room number, room capacity
◦ - or add these attributes to section
Complete Logical Model
Add
◦ Primary keys
◦ Foreign keys
◦ Constraints
◦ Domains
◦ etc