‫الجامعة السعودية االلكترونية‬

‫الجامعة السعودية االلكترونية‬

‫‪26/12/2021‬‬
College of Computing and Informatics
Data Science Pre-Master Program
IT244
Introduction to Database
IT244
Introduction to Database
Week 5
Entity–Relationship Model-2
Contents
1. ER Diagrams, Naming Conventions, and Design Issues
2. Example of Other Notation: UML Class Diagrams
3. Relationship Types of Degree Higher than Two
4. Another Example: A UNIVERSITY Database
5. Subclasses, Superclasses, and Inheritance
6. Specialization and Generalization
Weekly Learning Outcomes

1. Create an Entity-Relationship model.

Required Reading
1. Chapter 3: ER Diagrams, Naming Conventions, and Design Issues
2. Chapter 3: Example of Other Notation: UML Class Diagrams
3. Chapter 3: Relationship Types of Degree Higher than Two
4. Chapter 3: Another Example: A UNIVERSITY Database
5. Chapter 4: Subclasses, Superclasses, and Inheritance
6. Chapter 4: Specialization and Generalization
(Fundamentals of Database Systems, Global Edition, 7th Edition (2017) by Ramez
Elmasri & Shamkant Navathe)

Recommended Reading
Entity–Relationship Model-2:
https://courses.cs.vt.edu/cs4604/Spring21/pdfs/3-ermodel2.pdf

This Presentation is mainly dependent on the textbook: Fundamentals of Database Systems, Global Edition, 7th Edition (2017) by Ramez Elmasri & Shamkant Navathe
• ER Diagrams, Naming Conventions, and Design
Issues
Constraints on Relationships (1)

• Constraints on Relationship Types

– Two main types of constraints on binary relationships
– Cardinality Ratio (specifies maximum participation)
• One-to-one (1:1)
• One-to-many (1:N) or Many-to-one (N:1)
• Many-to-many (M:N)
– Existence Dependency Constraint (specifies minimum
participation) (also called participation constraint)
• zero (optional participation, not existence-dependent)
• one or more (mandatory participation, existence-dependent)
Constraints on Relationships (2)

• Cardinality ration specified by labeling 1, M, or N to

relationship lines in ER diagrams.
• See Figure 7.2, repeated in next slide
• Total participation specified by double line, partial
participation by single line.
• These constraints are derived from the real-world meaning
and characteristics of each relationship type
• In some ER diagrammatic notation, it is common to specify
cardinality ration and participation constraint jointly using
(min, max) notation
– Called (min, max) constraints or multiplicities
Displaying a Recursive Relationship Type
in ER Diagrams
• In a recursive relationship type.
– Both participations are same entity type in different roles.
– For example, SUPERVISION relationships between
EMPLOYEE (in role of supervisor or boss) and (another)
EMPLOYEE (in role of subordinate or worker).
• In ER diagram, need to display role names to
distinguish participations (see Figure 7.2).
• Role names can also be optionally displayed for other
relationship types
Attributes of Relationship Types

• A relationship type can have attributes:

– For example, HoursPerWeek of WORKS_ON
– Its value for each relationship instance describes the
number of hours per week that an EMPLOYEE works on a
PROJECT.
• A value of HoursPerWeek depends on a particular (employee,
project) combination
– Most relationship attributes are used with M:N
relationships
• In 1:N relationships, they can be transferred to the entity type on
the N-side of the relationship
Alternative (min, max) notation (1)
• Alternative way to specify relationship constraints; pecified on each
participation of an entity type E in a relationship type R
• Specifies that each entity e in E participates in at least min and at most
max relationship instances in R
• Default (no constraint): min=0, max=n (signifying no limits)
• Must have minmax, min0, max 1
• Derived from the knowledge of mini-world constraints
• Examples:
– A department has exactly one manager and an employee can manage
at most one department.
• Specify (0,1) for participation of EMPLOYEE in MANAGES
• Specify (1,1) for participation of DEPARTMENT in MANAGES
– An employee can work for exactly one department but a department
can have any number of employees.
• Specify (1,1) for participation of EMPLOYEE in WORKS_FOR
• Specify (0,n) for participation of DEPARTMENT in WORKS_FOR
Alternative (min, max) notation (2)

• Figure 7.15 (next slide) shows the complete COMPANY ER

schema diagram with the (min, max) notation

• Also shows all the (optional) role names

• Important: In some popular diagrammatic notations, the

placement of (min, max) are reversed (placed on the other
side of the binary relationship) – for example, in UML class
diagrams (see later in this chapter)
Summary of ER Diagrams (1)
Summary of ER Diagrams (2)
• Example of Other Notation: UML Class Diagrams
Alternative diagrammatic notation
• ER diagrams (as described here) is one popular
method for displaying database schemas
• Many other diagrammatic notations exist in the
literature and in various database design and
modeling tools
• Appendix A illustrates some of the alternative
notations that have been used
• UML class diagrams is representative of an alternative
way of displaying ER concepts that is used in several
automated design tools
UML Class Diagrams (1)
• UML (Universal Modeling Language) is a popular
language/methodology for object-oriented software design
• Part of software design is specifying classes using class
diagrams – this is somewhat similar to ER design
• Classes (similar to entity types) as displayed as large rounded
boxes with three sections:
– Top section includes entity type (class) name
– Second section includes attributes
– Third section includes class operations (operations are not in
basic ER model)
• Relationships (called associations) represented as lines
connecting the classes
– Other UML terminology also differs from ER terminology
• UML has many other types of diagrams for software design
(see Chapter 10)
UML Class Diagrams (2)
• Next slide (Figure 7.16) shows example of UML class diagrams
for the COMPANY database schema
• Multiplicities (similar to (min, max) constraints) placed on
opposite end when compared to our previous notation:
– Displayed as min..max
– * represents no maximum limit on participation (like N)
• Two kinds of relationships
– Association: Relationship between two independent objects;
displayed as lines
– Aggregation: Relationship between object and its parts;
displayed as lines with small diamond at object end
• Weak entity can be represented using concept of qualified
association/aggregation (discriminator similar to partial key)
• Relationship names are optional; relationship instances called
links; relationship attributes called link attributes
• Relationship Types of Degree Higher than Two
Relationships of Higher Degree
• Recall that degree of a relationship type is the number of
participating entities in each instance
• Relationship types of degree 2 are called binary, degree 3
are ternary, and degree n are n-ary
• Example: A relationship instance in SUPPLY (Figure 7.10 , next
slide) relates three entities (s, p, j) where s is a SUPPLIER, p a
PART, j a PROJECT such that s currently supplies part p to
project j (with Quantity items per month)
• In general, an n-ary relationship (where n > 2) is not
equivalent to n binary relationships
• Constraints are harder to specify for higher-degree
relationships (n > 2) than for binary relationships
Discussion of n-ary relationships (1)
• In general, 3 binary relationships can represent different
information than a single ternary relationship (see Figure
7.17a and b on next slide)
• If needed, the binary and n-ary relationships can all be
included in the schema design
• In some cases, a ternary relationship can be represented as a
weak entity type if the data model allows multiple identifying
relationships (and hence multiple owner entity types) (see
Figure 7.17c)
Discussion of n-ary relationships (2)
• If a particular binary relationship can be derived from
a higher-degree relationship at all times, then it is
redundant
• For example, TAUGHT_DURING binary relationship in
Figure 7.18 (see next slide) can be derived from the
ternary relationship OFFERS (based on the meaning
of the relationships)
• It all depends on the meaning of the relationships in
the real world
Displaying constraints on higher-degree
relationships

• The (min, max) constraints can be displayed on the edges –

however, they do not fully describe the constraints
• Displaying a 1, M, or N indicates additional constraints
– An M or N indicates no constraint
– A 1 indicates that an entity can participate in at most one
relationship instance that has a particular combination of the
other participating entities
• In general, both (min, max) and 1, M, or N are needed to
describe fully the constraints
 Why Extended Entity-Relationship (EER)
Model?

• The basic ER model described so far does not support

specialization and generalization abstractions
• Next chapter illustrates how the ER model can be
extended with
– Type-subtype and set-subset relationships
– Specialization/Generalization Hierarchies
– Notation to display them in EER diagrams
• Another Example: A UNIVERSITY Database
Additional Examples (1)
Additional Examples (2)
Additional Examples (3)
Additional Examples (4)
Additional Examples (5)
Additional Examples (6)
• The Enhanced Entity-Relationship (EER) Model
• Subclasses, Superclasses, and Inheritance
 Subclasses and Superclasses (1)

• An entity type may have additional meaningful subtypes (or

specializations) of its entities
– Example: EMPLOYEE may be further specialized into:
• SECRETARY, ENGINEER, TECHNICIAN, …
– Based on the EMPLOYEE’s Job
• MANAGER
– EMPLOYEEs who are managers
• SALARIED_EMPLOYEE, HOURLY_EMPLOYEE
– Based on the EMPLOYEE’s method of pay
Subclasses and Superclasses (2)

• EER diagrams extend ER diagrams to represent these

additional subgroupings, called subclasses or subtypes (see
Figure 8.1, next slide)
• Important Note: As with ER diagrams, there are many different
diagrammatic notations for each concept
• We show some alternatives in Appendix A
• UML class diagrams notation for subclasses is presented later
in this chapter
Subclasses and Superclasses (3)

• Each of these subgroupings (ENGINEER, TECHNICIAN,

MANAGER, SALARIED_EMPLOYEE, etc.) will hold a subset of
EMPLOYEE entities
• Each is called a subclass of EMPLOYEE
• EMPLOYEE is called the superclass
• The relationships are called superclass/subclass relationships:
– EMPLOYEE/SECRETARY
– EMPLOYEE/TECHNICIAN
– EMPLOYEE/MANAGER
– …
Subclasses and Superclasses (4)
• These are also called IS-A relationships
– Based on Knowledge Representation terminology in Artificial
Intelligence field
– SECRETARY IS-A EMPLOYEE, TECHNICIAN IS-A EMPLOYEE, ….
• Note: An entity that is member of a subclass represents the
same real-world entity as some member of the superclass:
– The subclass member is the same entity in a distinct specific role
– Entity cannot exist in database merely by being a member of a
subclass; it must also be a member of the superclass
– A member of the superclass can be optionally included as a
member of any number (zero or more) of its subclasses
Subclasses and Superclasses (5)
• Examples:
– A salaried employee who is also an engineer belongs to the two
subclasses:
• ENGINEER, and
• SALARIED_EMPLOYEE
– A salaried employee who is also an engineering manager belongs
to the three subclasses:
• MANAGER,
• ENGINEER, and
• SALARIED_EMPLOYEE
• It is not necessary that every entity in a superclass be a
member of some subclass
Attribute Inheritance in Superclass/
Subclass Relationships
• An entity that is member of a subclass inherits
– All attributes of the entity as a member of the
superclass
– All relationships of the entity as a member of the
superclass
• Example (Figure 8.1):
– SECRETARY (as well as TECHNICIAN, MANAGER,
ENGINEER, etc.) inherit the attributes Name, SSN, …,
from EMPLOYEE
– Every SECRETARY entity will have values for the
inherited attributes
• Specialization and Generalization
 Specialization (1)

• Is the process of defining a set of subclasses of a

superclass – the set must be based upon some
distinguishing characteristics of the entities in the
superclass
– Example: {SECRETARY, ENGINEER, TECHNICIAN} is a
specialization of EMPLOYEE based upon job type.
• May have several specializations of the same superclass
• {SALARIED_EMPLOYEE, HOURLY_EMPLOYEE} is another
specialization of EMPLOYEE based on method of pay
Specialization (2)
• Specialization can be diagrammatically represented in EER diagrams
as (see Figure 8.1, repeated in next slide))
– The subclasses are connected to a circle that represents the
specialization (using lines with the subset symbol)
– The circle is also connected to the superclass
– Attributes of a subclass are called specific or local attributes.
• For example, the attribute TypingSpeed of SECRETARY
– The subclass can also participate in specific relationship types.
• For example, a relationship BELONGS_TO of HOURLY_EMPLOYEE
(see Figure 8.1)
 Generalization
• Generalization is the reverse of the specialization process
• Several classes with common features are generalized into a
superclass;
– original classes become its subclasses
• Example (Figure 8.3, next slide): CAR, TRUCK generalized into
VEHICLE;
– Both CAR, TRUCK become subclasses of the superclass VEHICLE
because they have several common attributes.
– VEHICLE includes the common attributes
– Can view {CAR, TRUCK} as a specialization of VEHICLE
– Alternatively, we can view VEHICLE as a generalization of CAR
and TRUCK
Generalization vs. Specialization (1)
• Diagrammatic notations sometimes distinguish
generalization and specialization
– Arrow pointing to the generalized superclass
represents a generalization
– Arrows pointing to the specialized subclasses
represent a specialization
– We do not use this notation because it is often unclear
or subjective as to which process was used to reach
the final design
Generalization vs. Specialization (2)

• Data Modeling with Specialization and Generalization

– A superclass or subclass represents a type of entity, as
well as the collection (or set or grouping) of entities of
that type
– Subclasses and superclasses are displayed in rectangles
in EER diagrams (like entity types)
– We can call all entity types classes, whether they are
entity types, superclasses, or subclasses (object-
oriented terminology)
Main Reference
1. Chapter 3: ER Diagrams, Naming Conventions, and Design Issues
2. Chapter 3: Example of Other Notation: UML Class Diagrams
3. Chapter 3: Relationship Types of Degree Higher than Two
4. Chapter 3: Another Example: A UNIVERSITY Database
5. Chapter 4: Subclasses, Superclasses, and Inheritance
6. Chapter 4: Specialization and Generalization
(Fundamentals of Database Systems, Global Edition, 7th Edition (2017) by Ramez
Elmasri & Shamkant Navathe)

Additional References
https://courses.cs.vt.edu/cs4604/Spring21/pdfs/3-ermodel2.pdf
http://eds.a.ebscohost.com.sdl.idm.oclc.org/eds/pdfviewer/pdfviewer?vid=4&sid=dc163
5b3-88ab-4a84-814c-5908ea9c232c%40sdc-v-sessmgr01

This Presentation is mainly dependent on the textbook: Fundamentals of Database Systems, Global Edition, 7th Edition (2017) by Ramez Elmasri & Shamkant Navathe
Thank You