Dr. Suleiman H. Mustafa
Slide 2- 1
UNIT 02
Conceptual Data Modeling
Using
The Entity-Relationship (ER) Modeling
Language
Reviewed and Edited by Prof. Suleiman H. Mustafa
Dr. Suleiman H. Mustafa
Slide 2- 2
Unit Outline

ER Model Concepts and notation








Entities and Attributes
Entity Types, Value Sets, and Key Attributes
Relationships and Relationship Types
Weak Entity Types
Roles and Attributes in Relationship Types
Example Database Application (COMPANY)
 ER Diagram for COMPANY Schema
Alternative ER Notations for Constraints
Subentities and superentities: concepts and
modeling notation.
Dr. Suleiman H. Mustafa
Slide 2- 3
Conceptual Database Design

This unit of the course focuses on the
conceptual database design phase.


Which results in a conceptual database schema
using the ER modeling language.
Diagrams are popular in industry to document
conceptual database designs. Most popular:


The Entity Relationship (ER) modeling language,
including the Enhanced Entity Relationship (EER)
version.
The Object-Oriented Unified Modeling Language
(UML) which is used in object-oriented databases.
Dr. Suleiman H. Mustafa
Slide 2- 4
UNIT 02
Implementation
Dr. Suleiman H. Mustafa
Slide 2- 5
ER Modeling Concepts
Dr. Suleiman H. Mustafa
Slide 2- 6
ER Main Concepts

The ER modeling language has three basic
concepts:

Entities

Attributes

Relationships
Dr. Suleiman H. Mustafa
Slide 2- 7
Entities

The Entity is a basic concept for the ER model.
Entities are things or objects in the business
domain (or real world) that are represented in the
database.


For example: EMPLOYEE, DEPARTMENT, PROJECT,
STUDENT, and COURSE are entities.
An entity has a group of instances. For example:
Ahmed, Leila, and Faris are instances of STUDENT.

In ER diagrams, an entity name is displayed in a
rectangular box.

Two types of entities (See next slide)
Dr. Suleiman H. Mustafa
Slide 2- 8
Types of Entities and Notation in ER
Entity
Types
Regular Entity
Weak Entity
Weak entity (which depends in its existence on another
entity which is called strong entity)
Dr. Suleiman H. Mustafa
Slide 2- 9
Entity Set of Instances

Each entity has a collection of instances stored
in the database



Called the entity set of instances or sometimes
called entity collection
The next slide shows three CAR entity instances in
the entity set for CAR.
The set of instances of a given entity is the current
state of that entity at a given point in time.
Dr. Suleiman H. Mustafa
Slide 2- 10
Entity Set of Instances
E
E1
Dr. Suleiman H. Mustafa
E2
…… En
Slide 2- 11
Attributes

Attributes are properties used to describe an
entity.

For example the EMPLOYEE entity may have the
following attributes Name, SSN, Address, Sex,
BirthDate
Attribute
Types
Simple
Attribute
Composite
Attribute
Derived
Attribute
Dr. Suleiman H. Mustafa
Multivalued
Attribute
Slide 2- 12
NOTATION for ER diagrams
Dr. Suleiman H. Mustafa
Slide 2- 13
Types of Attributes

Simple Attribute



Each entity instance has a single atomic value for the
given attribute.
For example, SSN or Sex.
Composite Attribute


The attribute may be composed of several components.
For example:



Address (Apt#, House#, Street, City, State, ZipCode,
Country), or
Name (FirstName, MiddleName, LastName).
Composition may form a hierarchy (see next slide).
Dr. Suleiman H. Mustafa
Slide 2- 14
Types of Attributes

Derived Attribute



An entity may have an attribute whose values are
computed from the values of another attribute.
For example: Number of employees in a department
may be derived by counting the employees.
Multi-valued Attribute


An entity may have multiple values for a specific
attribute.
For example, Color of a CAR or Degrees of a
EMPLOYEE.


Denoted as {Color} or {Degrees}.
{silver, Black}, {B.Sc., M.Sc.}
Dr. Suleiman H. Mustafa
Slide 2- 15
Composite and Multivalued Attributes


A composite attribute may be nested arbitrarily to
any number of levels.
 For example, see Figure 3.4
The same can apply to multivalued attributes,
although this is rare.

For instance,


Degrees of an EMPLOYEE may be a composite
multi-valued attribute denoted by {Degrees
(College, Year, DegreeName, Field)}
Example
{Degrees (YU, 2001, B.Sc., Computer Science),
(JUST, 2010, M.Sc., Computer Science)}
Dr. Suleiman H. Mustafa
Slide 2- 16
Example of a composite attribute

Composition may form a hierarchy where some
components are themselves composite.
Dr. Suleiman H. Mustafa
Slide 2- 17
Values of Attributes

A specific individual instance of an entity will have
a value for each of its attributes.


For example a specific EMPLOYEE instance may
have
 Name='John Smith',
 SSN='123456789',
 Address ='731, Fondren, Houston, TX',
 Sex='M',
 BirthDate='09-JAN-55‘
Each attribute has a value set (or data type)
associated with it.

e.g. integer, string, date, enumerated values type, …
Dr. Suleiman H. Mustafa
Slide 2- 18
Key Attributes

Each individual instance of an entity must have a
unique key.


The key attribute is selected from the set of
attributes associated with an entity,


Two types of keys: simple key and composite key
(next slide)
given it is unique.
Examples:


ID of STUDENT
SSN of EMPLOYEE
Dr. Suleiman H. Mustafa
Slide 2- 19
Entity Key
Key Types
Simple Key
(one attribute)
Simple
Attribute
Composite Key
(two or more
attributes)
Composite
Attribute
Dr. Suleiman H. Mustafa
Slide 2- 20
Key Attributes


A key attribute may be composite attribute.
 VehicleTagNumber is a key of the CAR entity
with components (Number, State).
An entity may have more than one key
(Candidate Keys).
 The CAR entity type may have two keys:



VehicleIdentificationNumber (popularly called VIN)
VehicleTagNumber (Number, State), aka license
plate number.
Each key is underlined
Dr. Suleiman H. Mustafa
Slide 2- 21
Full Notation of ER Diagrams


In ER diagrams, an entity name is displayed in
a rectangular box
Names of attributes are displayed in ovals






Each attribute is connected to its entity
Components of a composite attribute are connected
to the oval representing the composite attribute
Each key attribute is underlined
Multivalued attributes are displayed in double ovals
Relationships are displayed using a diamondshaped box.
See the full ER notation on the next slide
Dr. Suleiman H. Mustafa
Slide 2- 22
Full NOTATION for ER diagrams
Constraints
(Explained later)
Dr. Suleiman H. Mustafa
Slide 2- 23
Homework
Given the following CAR entity and its attributes as represented in ER,
give a example of …
A. Simple attribute
B. Composite attribute
C. Multivalued attribute
D. Key attribute
E. Derived attribute
Dr. Suleiman H. Mustafa
Slide 2- 24
Example:
Company Database
Initial Design (Entities and
Attributes)
Dr. Suleiman H. Mustafa
Slide 2- 25
Example COMPANY Database

We need to create a database schema design
based on the following (simplified) requirements
of the COMPANY Database:


The company is organized into DEPARTMENTs.
Each department has a name, number and an
employee who manages the department. We keep
track of the start date of the department manager.
A department may have several locations.
Each department controls a number of
PROJECTs. Each project has a unique name,
unique number and is located at a single location.
Dr. Suleiman H. Mustafa
Slide 2- 26
Example COMPANY Database
(Continued)


The database will store each EMPLOYEE’s social
security number, address, salary, sex, and birthdate.
 Each employee works for one department but may
work on several projects.
 The DB will keep track of the number of hours per
week that an employee currently works on each
project.
 It is required to keep track of the direct supervisor of
each employee.
Each employee may have a number of DEPENDENTs.
 For each dependent, the DB keeps a record of name,
sex, birthdate, and relationship to the employee.
Dr. Suleiman H. Mustafa
Slide 2- 27
Initial Conceptual Design of Entity Types
for the COMPANY Database Schema

Based on the requirements, we can identify four
initial entity types in the COMPANY database:






DEPARTMENT
PROJECT
EMPLOYEE
DEPENDENT
Their initial conceptual design is shown on the
following slide
The initial attributes shown are derived from the
requirements description
Dr. Suleiman H. Mustafa
Slide 2- 28
Initial Design of Entity Types:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT
Dr. Suleiman H. Mustafa
Slide 2- 29
Relationships between Entities
Dr. Suleiman H. Mustafa
Slide 2- 30
Relationships and Relationship Types (1)

A relationship relates two or more distinct entities with
a specific meaning.



For example, EMPLOYEE John Smith works on the
ProductX PROJECT, or
EMPLOYEE Franklin Wong manages the Research
DEPARTMENT.
The degree of a relationship is the number of
participating entities.

Both MANAGES and WORKS_ON are binary
relationships.
Dr. Suleiman H. Mustafa
Slide 2- 31
Relationship type vs. relationship set (2)

In ER diagrams, we represent relationships as follows:
 Diamond-shaped box is used to display a relationship.
 Connected to the participating entities via straight
lines

Note that the relationship is not shown with an arrow.
The name should typically be readable from left to right
and top to bottom.
Dr. Suleiman H. Mustafa
Slide 2- 32
NOTATION of Relationships in ER
Diagrams
Two Types of
Relationships
Identifying relationships exist when the primary key of the parent entity is
included in the primary key of the child entity.
On the other hand, a non-identifying relationship exists when the primary
key of the parent entity is included in the child entity but not as part of the
child entity's primary key.
Dr. Suleiman H. Mustafa
Slide 2- 33
Refining the Initial Design of the Company
Database by Adding Relationships



Some aspects in the requirements will be represented as
relationships.
By examining the requirements, six binary relationships
(degree 2) are identified and listed below.
Identified Relationships






WORKS_FOR (between EMPLOYEE, DEPARTMENT)
MANAGES (also between EMPLOYEE, DEPARTMENT)
CONTROLS (between DEPARTMENT, PROJECT)
WORKS_ON (between EMPLOYEE, PROJECT)
SUPERVISION (between EMPLOYEE (as subordinate),
EMPLOYEE (as supervisor))
DEPENDENTS_OF (between EMPLOYEE, DEPENDENT)
Dr. Suleiman H. Mustafa
Slide 2- 34
ER DIAGRAM – Relationship Types are:
WORKS_FOR, MANAGES, WORKS_ON, CONTROLS, SUPERVISION, DEPENDENTS_OF
Dr. Suleiman H. Mustafa
Slide 2- 35
Discussion on Relationship Types

In the refined design, some attributes from the initial
entities are refined into relationships:





Manager of DEPARTMENT  MANAGES
Works_on of EMPLOYEE  WORKS_ON
Department of EMPLOYEE  WORKS_FOR
etc
More than one relationship type can exist between
the same participating entities.


MANAGES and WORKS_FOR are distinct relationship
types between EMPLOYEE and DEPARTMENT
Different meanings and different relationship instances.
Dr. Suleiman H. Mustafa
Slide 2- 36
Constraints on Relationships
Dr. Suleiman H. Mustafa
Slide 2- 37
Two Types of Constraints on Relationships
Participation
Constraints on
Relationships
Cardinality Ratio
Constraint(Maximum)
One-toOne-toOne (1:1) Many (1:n)
Existence Dependency
Constraint(Minimum)
Many-toMany(N:M)
Partial
(0)
Dr. Suleiman H. Mustafa
Total
(1)
Slide 2- 38
Constraints on Relationships

Cardinality Ratio Constraint:
specifies maximum participation of an entity
 One-to-one (1:1)
 One-to-many (1:N) or Many-to-one (N:1)
 Many-to-many (M:N)
 Shown by placing appropriate numbers on the
relationship edges.
Dr. Suleiman H. Mustafa
Slide 2- 39
Constraints on Relationships

Existence Dependency Constraint:
specifies minimum participation of an entity
 zero (optional/partial participation, not existencedependent)
 one or more (mandatory/total participation, existencedependent)
 Total shown by double line, partial by single line.
Dr. Suleiman H. Mustafa
Slide 2- 40
Constraints on Relationships (Example):
WORKS_FOR, MANAGES, WORKS_ON, CONTROLS, SUPERVISION, DEPENDENTS_OF
Partial (optional) Participation
Total (Mandatory) Participation
Dr. Suleiman H. Mustafa
Slide 2- 41
Relationship Instances of One-to-One
Relationship (1:1): MANAGES Relationship
EMPLOYEE
MANAGES
DEPARTMENT
E1
R1
D1
R2
D2
R3
D3
E2
E3
E4
E5
E6
Dr. Suleiman H. Mustafa
Slide 2- 42
Relationship instances of the WORKS_FOR (1:N)
relationship between EMPLOYEE and DEPARTMENT
Dr. Suleiman H. Mustafa
Slide 2- 43
Relationship instances of the (N:M) WORKS_ON
relationship between EMPLOYEE and PROJECT
Dr. Suleiman H. Mustafa
Slide 2- 44
Alternative ER Notations for
Constraints
Dr. Suleiman H. Mustafa
Slide 2- 45
Alternative (min, max) notation for
relationship structural constraints



Specified on each participation of an entity E in a
relationship R
 It specifies that each instance e in E participates in
at least min and at most max relationship
instances in R
 Derived from the knowledge of the business
domain constraints
Must have (0  min max ) and ( max 1 )
Default (no constraint): min=0, max=n (signifying no
limit)
Dr. Suleiman H. Mustafa
Slide 2- 46
Alternative (min, max) notation for
relationship structural constraints:

Examples:

A department has exactly one manager and an
employee can manage at most one
department (Next slide).



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 (Next slide).


Specify (1,1) for participation of EMPLOYEE in
WORKS_FOR
Specify (0,n) for participation of DEPARTMENT
in WORKS_FOR
Dr. Suleiman H. Mustafa
Slide 2- 47
The (min,max) notation for
relationship constraints
Read the min,max numbers next to the entity
and looking away from the entity
Dr. Suleiman H. Mustafa
Slide 2- 48
COMPANY ER Schema Diagram using (min,
max) notation
Dr. Suleiman H. Mustafa
Slide 2- 49
Recursive Relationships
Dr. Suleiman H. Mustafa
Slide 2- 50
Recursive Relationship Type


A recursive relationship is a self-referencing
relationship between the same participating entity with
two distinct roles
 Both participations are of the same entity but in
different roles.
For example, SUPERVISION relationships between
EMPLOYEE.



One employee in supervisor (or boss) role
One employee in supervisee (or subordinate) role
Each relationship instance relates two distinct
EMPLOYEE instances.
Dr. Suleiman H. Mustafa
Slide 2- 51
Recursive Relationship Type is: SUPERVISION
(participation role names are shown)
we display role names to
distinguish participations.
Dr. Suleiman H. Mustafa
Slide 2- 52
A Recursive Relationship: Supervision`
Dr. Suleiman H. Mustafa
Slide 2- 53
Weak Entities,
Relationship Attributes and
N-ary Relationships
Dr. Suleiman H. Mustafa
Slide 2- 54
Weak Entities

A weak Entity is



A weak entity must participate in an identifying
relationship with an owner or identifying entity
Entities are identified by the combination of:



An entity that does not have a key attribute and that
its identification is dependent on another entity.
A partial key of the weak entity type
The particular entity they are related to in the
identifying relationship.
Example (next slide)
Dr. Suleiman H. Mustafa
Slide 2- 55
Weak Entities and Identifying Relationships
Identifying (owner)
entity
Identifying relationship
Weak entity
Identifier
Dr. Suleiman H. Mustafa
Slide 2- 56
Weak Entity and Identifying Relationship
Notation
Identifying relationships exist when the primary key of the parent entity is
included in the primary key of the child entity.
On the other hand, a non-identifying relationship exists when the primary
key of the parent entity is included in the child entity but not as part of the
child entity's primary key.
Dr. Suleiman H. Mustafa
Slide 2- 57
Relationship Attributes

A relationship between two entities 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 on the N-side of the relationship
Dr. Suleiman H. Mustafa
Slide 2- 58
Relationship Attributes
Dr. Suleiman H. Mustafa
Slide 2- 59
Relationships of a Higher Degree

Relationship Degree:



Relationships of degree 2 are called binary
Relationships of degree 3 are called ternary and
Relationships of degree n are called n-ary
Relationship
Degrees
Binary
(2 entities)
Ternary
(3 entities)
N-ary
( ≥ 3 entities)
Dr. Suleiman H. Mustafa
Slide 2- 60
Relationships of Higher Degree


In general, an n-ary relationship is not equivalent
to n binary relationships.
Example:



3 binary relationships can represent different
information than a single ternary relationship.
See Figure 3.17a and b on next slide.
Three ways of representing a ternary relationship
using ER diagrams.
Dr. Suleiman H. Mustafa
Slide 2- 61
Example of a ternary relationship
Dr. Suleiman H. Mustafa
Slide 2- 62
Specialization & Generalization
in Extended ER Diagrams
Dr. Suleiman H. Mustafa
Slide 2- 63
Subgrouping of Entities

An entity may have additional meaningful
subgroupings of its members or instances.


See next slide
This process of forming subgroupings of the
members of an entity based upon some
distinguishing characteristics in the superentity is
called “specialization”.

Example: EMPLOYEE may be further grouped based on
the EMPLOYEE’s Job into:


SECRETARY, ENGINEER, TECHNICIAN, …
See Figure 4.4 (next slide)
Dr. Suleiman H. Mustafa
Slide 2- 64
Entity Subgrouping
Instructors in the IT College
B
A
C
D
E
G
H
F
J
I
Dept.
E
F
H
D
I
J
CS
C
A
IS
Dr. Suleiman H. Mustafa
IT
Slide 2- 65
Representing Specialization in ER
Diagrams
Distinguishing Characteristic
IS-A Relationships
Super-Entity
Specialization
Sub-entity
Dr. Suleiman H. Mustafa
Slide 2- 66
Subentities and EER Notation


Etended ER diagrams (EER) extend the basic ER
diagrams notation (as seen in the previous slide)
to represent these additional subgroupings, called
subentities (or subclasses).
Example: Company Database (See the next slide)
Dr. Suleiman H. Mustafa
Slide 2- 67
Distinguishing Characteristic
Relationship
Disjoint
Local Attribute
Dr. Suleiman H. Mustafa
Slide 2- 68
EMPLOYEE Example


Each of these subgroupings is a subset of EMPLOYEE
entity.
 Each is called a subentity of EMPLOYEE
 EMPLOYEE is the superentity or superclass
for each of these subentities.
These are called superentity-subentity relationships:




EMPLOYEE/SECRETARY
EMPLOYEE/TECHNICIAN
EMPLOYEE/MANAGER
These are also called IS-A relationships

SECRETARY IS-A EMPLOYEE, TECHNICIAN IS-A EMPLOYEE,
….
Dr. Suleiman H. Mustafa
Slide 2- 69
Representing Instances of a Super-Entity
and Subenty Relationships
Superentity-subentity relationships
Dr. Suleiman H. Mustafa
Slide 2- 70
Subentity Instances (Members)

A data member or instance of a subentity
represents the same real-world instance as
some member of the superentity:
1. An instance or member cannot exist in the
database merely by being a member of a
subentity; it must also be a member of the
superentity
2. The subentity member is the same as a
superentity member but serving a distinct
specific role
3. It is not necessary that every entity instance in
a superclass be a member of some subclass
Dr. Suleiman H. Mustafa
Slide 2- 71
Subentity Instances (Members)
4. A member of the super-entity can be optionally included
as a member of any number of its subentities.
 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
Dr. Suleiman H. Mustafa
Slide 2- 72
Multiple Specialization


A super-entity may have several specializations
of the same super-entity
Example: EMPLOYEE may be further grouped
into:

SECRETARY, ENGINEER, TECHNICIAN, …


MANAGER


EMPLOYEEs who are managers (the role they play)
SALARIED_EMPLOYEE, HOURLY_EMPLOYEE


Based on the EMPLOYEE’s Job
Based on the EMPLOYEE’s method of pay
Next slide
Dr. Suleiman H. Mustafa
Slide 2- 73
Multiple Specialization Example
Job Type
Method of Pay
Role
Dr. Suleiman H. Mustafa
Slide 2- 74
Multiple Specialization Example

Three types of specializations

First Specialization:


Second Specialization:


{SECRETARY, ENGINEER, TECHNICIAN} is a
specialization of EMPLOYEE based upon job type.
MANAGER is a specialization of EMPLOYEE based on
the role the employee plays
Third Specialization:

SALARIED is a specialization of EMPLOYEE based on
the method of pay
Dr. Suleiman H. Mustafa
Slide 2- 75
Types of Specialization Determination
1.
2.
3.
Attribute-defined: shows the name of the
attribute next to the line drawn from the
superclass toward the subclasses (e.g., Job
Type)
Predicate-defined ( or condition-defined) :
based on some predicate. E.g., based on value
of an attribute, say, Age (e.g., Age ≥ 60).
User-defined: membership is defined by the
user on an instance by instance basis
Dr. Suleiman H. Mustafa
Slide 2- 76
Attribute-Defined Specialization
Dr. Suleiman H. Mustafa
Slide 2- 77
Predicate-Defined Specialization
Salary
Dr. Suleiman H. Mustafa
Slide 2- 78
Generalization (Bottomup Refinement)

Generalization is the reverse of the specialization process
(which is bottomup refinement)
 Several entities with common features are
generalized into a superentity;


Original classes become its subclasses
Example: CAR, TRUCK generalized into VEHICLE;



both CAR, TRUCK become subentities of the superentity
VEHICLE.
We can view {CAR, TRUCK} as a specialization of
VEHICLE
Alternatively, we can view VEHICLE as a generalization of
CAR and TRUCK
Dr. Suleiman H. Mustafa
Slide 2- 79
Generalization Example
Dr. Suleiman H. Mustafa
Slide 2- 80
Inheritance,
Local Attributes, and Local
Relationships
Dr. Suleiman H. Mustafa
Slide 2- 81
Inheritance of Attributes and Relationships

An entity instance that is member of a subentity
inherits
1)
2)

All attributes of the instance as a member
of the superentity
All relationships of the instance as a member
of the superentity
Example (next two slide):


In the following slide, SECRETARY (as well as
TECHNICIAN and ENGINEER) inherit the
attributes Name, SSN, …, from EMPLOYEE
Every SECRETARY entity instance will have
values for the inherited attributes
Dr. Suleiman H. Mustafa
Slide 2- 82
Inheritance
Dr. Suleiman H. Mustafa
Slide 2- 83
Dr. Suleiman H. Mustafa
Slide 2- 84
Local Attributes and Local Relationships

Example: Another specialization of EMPLOYEE based on
method of pay is {SALARIED_EMPLOYEE,
HOURLY_EMPLOYEE}.


Example (next slide)
Attributes of a subentity are called specific or local
attributes.


For example, the attribute TypingSpeed of SECRETARY
The subentity can also participate in specific local
relationships.

For example, a relationship BELONGS_TO of
HOURLY_EMPLOYEE
Dr. Suleiman H. Mustafa
Slide 2- 85
Local Attributes and Relationships
Dr. Suleiman H. Mustafa
Slide 2- 86
Single vs. Multiple Inheritance



A subentity may itself have further subentities
specified on it forming a hierarchy.
A subentity with more than one superentity is
called a shared subentity (multiple inheritance as
opposed to single inheritance).
Example (Next slide).
Dr. Suleiman H. Mustafa
Slide 2- 87
Shared Subentity “Engineering_Manager”
Dr. Suleiman H. Mustafa
Slide 2- 88
Participation Constraints in
Specialization Relationships
Dr. Suleiman H. Mustafa
Slide 2- 89
Specialization Participation Constraints

Two basic constraints can apply to a superentitysubentity relationships:
Specialization
Participation Constraints
Disjointness
Constraint
Disjoint
Completeness
Constraint
Overlapping
Total
Dr. Suleiman H. Mustafa
Partial
Slide 2- 90
Disjoint vs. Overlapping Coverage Constraints

Disjointness Constraint:

Specifies that the subentities of the specialization
must be disjoint:



an instance can be a member of at most one of
the subentities of the specialization
Specified by d in EER diagram
Overlapping Constraint:

If not disjoint, specialization is overlapping:


that is the same instance may be a member of
more than one subentity of the specialization
Specified by o in EER diagram
Dr. Suleiman H. Mustafa
Slide 2- 91
Complete vs. Partial Coverage Constraints

Completeness (Exhaustiveness) Constraint:


Total specifies that every instance in the superentity must be a member of some subentity.
 Shown in ER diagrams by a double line
Partial allows an instance not to belong to any of
the subentities.
 Shown in ER diagrams by a single line
Dr. Suleiman H. Mustafa
Slide 2- 92
Participation Constraints
 Hence, we have four types of superentity-subentity
relationship constraints:
TOTAL
1
DISJOINT
PARTIAL
2
3
4
OVERLAPPING
Dr. Suleiman H. Mustafa
Slide 2- 93
Partial-Disjoint Example
Dr. Suleiman H. Mustafa
Slide 2- 94
Partial-Overlapping Example
Dr. Suleiman H. Mustafa
Slide 2- 95
Total-Disjoint Example
Dr. Suleiman H. Mustafa
Slide 2- 96
Total-Overlapping Example
Dr. Suleiman H. Mustafa
Slide 2- 97
Homework:
A UNIVERSITY Database



To keep track of the enrollments in classes and
student grades, another database is to be
designed.
It keeps track of the COLLEGEs,
DEPARTMENTs within each college, the
COURSEs offered by departments, and
SECTIONs of courses, INSTRUCTORs who
teach the sections etc.
These entities and the relationships among these
entities are shown on the next slide.
Dr. Suleiman H. Mustafa
Slide 2- 98
Conceptual Schema of the UNIVERSITY
Database
Dr. Suleiman H. Mustafa
Slide 2- 99
Summary







ER Model Concepts: Entities, attributes,
relationships
Constraints in the ER model
Using ER in step-by-step mode conceptual
schema design for the COMPANY database
ER Diagrams - Notation
Subentities and superentities representation
Alternative Notation Example
Binary Relationship types and those of higher
degree.
Dr. Suleiman H. Mustafa
Slide 2-