1

04 Entity-Relational Model [1]

CRI2E4 Basis Data
 2

Learning Outcomes
Students can explain and understand ER, ER Notation (CLO1)
and make a simple ERD using the right ER Notation, according to
the case study (CLO2)
 Outline
3

Basic Concepts
Complex Attributes
Mapping Cardinalities
Primary Keys
Weak Entity Sets
Entity Relationship Design Issues
Extended ER Features (additional)
Alternative Notation for Modelling Data (additional)
 4

Basic Concepts
 ER Model
5

• The ER data mode was developed to facilitate database design by allowing

specification of an enterprise schema that represents the overall logical structure of
a database.

• The ER data model employs three basic concepts:

• entity sets,
• relationship sets,
• attributes.

• The ER model also has an associated diagrammatic representation, the ER diagram,

which can express the overall logical structure of a database graphically.
 Entity Sets
6

• An entity is an object that exists and is distinguishable from other objects.

• Example: specific person, company, event, plant
• An entity set is a set of entities of the same type that share the same properties.
• Example: set of all persons, companies, trees, holidays
• An entity is represented by a set of attributes; i.e., descriptive properties possessed
by all members of an entity set.
• Example:
instructor = (ID, name, salary )
course= (course_id, title, credits)
• A subset of the attributes form a primary key of the entity set; i.e., uniquely
identifying each member of the set.
 Representing Entity sets in ER Diagram
7

▪ Entity sets can be represented graphically as follows:

• Rectangles represent entity sets.
• Attributes listed inside entity rectangle
• Underline indicates primary key attributes
 Relationship Sets
8

• A relationship is an association among several entities

• Example: we define the relationship set advisor to denote the associations between
students and the instructors who act as their advisors.
• Pictorially, we draw a line between related entities.

• Diamonds represent relationship sets.

 Relationship Sets (cont.)
9

• An attribute can also be associated with a relationship set.

• For instance, the advisor relationship set between entity sets instructor and student may
have the attribute date which tracks when the student started being associated with the
advisor

76766 Crick 98988 Tanaka

45565 Katz 3 May 2008 12345 Shankar
10 June 2007
10101 Srinivasan 00128 Zhang
12 June 2006

98345 Kim 6 June 2009 76543 Brown

76543 Singh 30 June 2007
76653 Aoi
31 May 2007
22222 Einstein 23121 Chavez
4 May 2006

instructor 44553 Peltier

student
 Degree of a Relationship Sets
10

• Binary relationship
• involve two entity sets (or degree two).
• most relationship sets in a database system are binary.
• Relationships between more than two entity sets are rare. Most relationships are
binary. There are occasions when it is more convenient to represent relationships as
non-binary.
• Example: students work on research projects under the guidance of an instructor.
• relationship proj_guide is a ternary relationship between instructor, student, and
project
 Roles
11

• Entity sets of a relationship need not be distinct

• Each occurrence of an entity set plays a “role” in the relationship
• The labels “course_id” and “prereq_id” are called roles.
 12

Complex Attributes
 Complex Attributes
13

• Attribute types:
• Simple and composite attributes.
• Composite attributes allow us to divided
attributes into subparts (other
attributes).
• Single-valued and multivalued attributes
• Example: multivalued attribute:
phone_numbers
• Derived attributes
• Can be computed from other attributes
• Example: age, given date_of_birth
• Domain – the set of permitted values for each
attribute
 14

Mapping Cardinalities
 Mapping Cardinality Constraints
15

• Express the number of entities to which another entity can be associated via
a relationship set.
• Most useful in describing binary relationship sets.
• For a binary relationship set the mapping cardinality must be one of the
following types:

One to one One to many Many to one Many to many

 16
Representing Cardinality Constraints in ER Diagram
• We express cardinality constraints by drawing either a directed line (→), signifying “one,” or an undirected
line (—), signifying “many,” between the relationship set and the entity set.

• One-to-one relationship between an instructor • Many-to-one relationship between an instructor

and a student: and a student:

• One-to-many relationship between an instructor • Many-to-many relationship between an instructor

and a student and a student
 Total and Partial Participation
17

▪ Total participation (indicated by double line): every entity in the entity set participates
in at least one relationship in the relationship set

• participation of student in advisor relation is total

▪ every student must have an associated instructor
▪ Partial participation: some entities may not participate in any relationship in the
relationship set
• Example: participation of instructor in advisor is partial
 18
Notation for Expressing More Complex Constraints
▪ A line may have an associated minimum and maximum cardinality, shown in the form
l..h, where l is the minimum and h the maximum cardinality
• A minimum value of 1 indicates total participation.
• A maximum value of 1 indicates that the entity participates in at most one
relationship
• A maximum value of * indicates no limit.
▪ Example

• Instructor can advise 0 or more students. A student must have 1 advisor; cannot
have multiple advisors
 19

Primary Keys
Primary Key
20

Primary Key for Entity Sets

Primary Key for Relationship

Sets

Weak Entity Sets

 Primary Key for Entity Sets
21

• By definition, individual entities are distinct.

• From database perspective, the differences among them must be expressed in
terms of their attributes.

• The values of the attribute values of an entity must be such that they can uniquely
identify the entity.
• No two entities in an entity set are allowed to have exactly the same value for all
attributes.

• A key for an entity is a set of attributes that suffice to distinguish entities from each
other
 Primary Key for Relationship Sets
22

• To distinguish among the various relationships of a relationship set we use the

individual primary keys of the entities in the relationship set.
• Let R be a relationship set involving entity sets E1, E2, .. En
• The primary key for R is consists of the union of the primary keys of entity sets
E1, E2, ..En
• If the relationship set R has attributes a1, a2, .., am associated with it, then the
primary key of R also includes the attributes a1, a2, .., am

• Example: relationship set “advisor”.

• The primary key consists of instructor.ID and student.ID

• The choice of the primary key for a relationship set depends on the mapping
cardinality of the relationship set.
 Choice of Primary key for Binary Relationship
23

• Many-to-Many relationships.
The preceding union of the primary keys is a minimal superkey and is chosen as the
primary key.
• One-to-Many relationships .
The primary key of the “Many” side is a minimal superkey and is used as the primary
key.
• Many-to-one relationships.
The primary key of the “Many” side is a minimal superkey and is used as the primary
key.
• One-to-one relationships.
The primary key of either one of the participating entity sets forms a minimal
superkey, and either one can be chosen as the primary key.
 24

Weak Entity Sets

 Weak Entity Sets
25

• An entity that does not have a specific identifier. A weak entity must participate in an
identifying relationship type with an owner or identifying entity type.
• The primary key of a weak entity set is formed by the primary key of the strong entity
set on which the weak entity set is existence dependent, plus the weak entity set’s
discriminator.
• The discriminator (or partial key) of a weak entity type is the set of attributes that
distinguishes among all the entities of a weak entity type.
• An entity set that is not a weak entity set is termed a strong entity set.
• Every weak entity must be associated with an identifying entity; that is, the weak entity
set is said to be existence dependent on the identifying entity set.
• The identifying entity set is said to own the weak entity set that it identifies.
• The relationship associating the weak entity set with the identifying entity set is called
the identifying relationship.
 Expressing Weak Entity Sets
26

• In E-R diagrams, a weak entity set is depicted via a double rectangle.

• We underline the discriminator of a weak entity set with a dashed line.
• The relationship set connecting the weak entity set to the identifying strong
entity set is depicted by a double diamond.
• Primary key for section – (course_id, sec_id, semester, year)
 27

Entity Relationship
Design Issues
 Common Mistakes in E-R Diagrams
28

1. The use of the primary key of an entity set as an attribute of another entity
set, instead of using a relationship.

2. People sometimes make is to designate the primarykey attributes of the

related entity sets as attributes of the relationship set.
For example, ID (the primary-key attributes of student) and ID (the primary key of
instructor) should not appear as attributes of the relationship advisor. This should not be
done since the primary-key attributes are already implicit in the relationship set.
 Common Mistakes in E-R Diagrams (cont.)
29

3. To use a relationship with a single-valued attribute in a situation that

requires a multivalued attribute.
 Use of Entity Sets vs. Attributes
30

▪ Use of entity sets vs. attributes

▪ Use of phone as an entity allows extra information about phone numbers

(plus multiple phone numbers)
 Use of Entity Sets vs. Relationship Sets
31

▪ Use of entity sets vs. relationship sets

Possible guideline is to designate a relationship set to describe an action that occurs
between entities

• Placement of relationship attributes

For example, attribute date as attribute of advisor or as attribute of student
 32

Extended ER Features
(additional)
 Extended ER Features
33

• Although the basic E-R concepts can model most database features, some
aspects of a database may be more aptly expressed by certain extensions to
the basic E-R model.
• In this section, we discuss the extended E-R features of :
• specialization,
• generalization,
• higher- and lower-level entity sets,
• attribute inheritance, and
• aggregation.
 Specialization
34

• Top-down design process; we designate sub-groupings within an entity set

that are distinctive from other entities in the set.
• These sub-groupings become lower-level entity sets that have attributes or
participate in relationships that do not apply to the higher-level entity set.
• Depicted by a triangle component labeled ISA (e.g., instructor “is a” person).
• Attribute inheritance – a lower-level entity set inherits all the attributes and
relationship participation of the higher-level entity set to which it is linked.
 Specialization Examples
35

• Overlapping – employee and student

• Disjoint – instructor and secretary
• Total and partial
 Generalization
36

• A bottom-up design process – combine a number of entity sets that share

the same features into a higher-level entity set.
• Specialization and generalization are simple inversions of each other; they
are represented in an E-R diagram in the same way.
• The terms specialization and generalization are used interchangeably.
 Completeness Constraint
37

• Completeness constraint -- specifies whether or not an entity in the higher-level entity

set must belong to at least one of the lower-level entity sets within a generalization.
• total: an entity must belong to one of the lower-level entity sets
• partial: an entity need not belong to one of the lower-level entity sets
• Partial generalization is the default.
• We can specify total generalization in an ER diagram by adding the keyword total in the
diagram and drawing a dashed line from the keyword to the corresponding hollow
arrow-head to which it applies (for a total generalization), or to the set of hollow arrow-
heads to which it applies (for an overlapping generalization).
• The student generalization is total: All student entities must be either graduate or
undergraduate. Because the higher-level entity set arrived at through generalization is
generally composed of only those entities in the lower-level entity sets, the
completeness constraint for a generalized higher-level entity set is usually total
 Aggregation
38

▪ Consider the
ternary relationship
proj_guide, which we
saw earlier
▪ Suppose we want to
record evaluations
of a student by a
guide on a project
 Aggregation (cont.)
39

▪ Eliminate this redundancy via

aggregation without
introducing redundancy, the
following diagram represents:
• A student is guided by a
particular instructor on a
particular project
• A student, instructor,
project combination may
have an associated
evaluation
 40

Alternative Notation for

Modelling Data
(additional)
Symbols Used in E-R Notation
41
Alternative ER Notations
42
ER vs. UML Class Diagram
43
ER vs. UML Class Diagram (cont.)
44

ER Diagram Notation Equivalent in UML

 45

References

[1] Silberschatz, Korth, and Sudarshan. Database System Concepts – 7th

Edition. McGraw-Hill. 2019.
[2] Slides adapted from Database System Concepts Slide.
Source: https://db-book.com/slides-dir/index.html
Questions
46