Entity-Relationship Model


Entity Sets

Relationship Sets

Mapping Constraints

Keys

E-R Diagram

Extended E-R Features

Design of an E-R Database Schema

Reduction of an E-R Schema to Tables
 Entity-Relationship Model

• Most popular conceptual model for database

design
• Basis for many other models
• Describes the data in a system and how that
data is related
• Describes data as entities, attributes and
relationships

2
 Database requirements
• We must convert the written database
requirements into an E-R diagram
• Need to determine the entities, attributes and
relationships.
– nouns = entities
– adjectives = attributes
– verbs = relationships

3
 The Pieces
• Objects
– Entity (including weak entities)
– Attribute
– Relationship
• “Structural” Constraints
– Cardinality
– Participation

4
 Entities
• Entity – basic object of the E-R model
– Represents a “thing” with an independent
existence
– Can exist physically or conceptually
• a professor, a student, a course
• Entity type – used to define a set of entities
with the same properties.

5
 Entity and Entity Types

Name
Number Topic
Entity Type
Course

Number: 3753
Name: Database Management
Entity Systems
Topic: Introduction to DBMSs
6
 Attributes
• Each entity has a set of associated properties that
describes the entity. These properties are known as
attributes.
• Attributes can be:
– Simple or Composite
– Single or Multi-valued
– Stored or Derived
– NULL

7
 Attributes (cont’d)

Simple Professor Start Date

First
Professor Name
Composite
Last
8
 Attributes (cont’d)

Single Professor Employee ID#

Multi-Valued Professor Email

9
 Attributes (cont’d)

Stored Professor Start Date

Derived Professor Years Teaching

10
 Attributes(cont..)

Complex Attributes:
- collection of composite and multivalued
attributes.
- Eg. Address ,phone no.

11
 Attributes (cont’d)
• NULL attributes have no value
– not 0 (zero)
– not a blank string
• Attributes can be “nullable” where a null value
is allowed, or “not nullable” where they must
have a value.

12
 Primary Keys

Professor Employee ID

• Employee ID is the primary key

• Primary keys must be unique for the entity
in question

13
 Relationships
• defines a set of associations between various
entities
• can have attributes to define them
• are limited by:
– Participation
– Cardinality Ratio

14
 Relationships (cont’d)

Employee works-for Dept

15
 Participation
• Defines if the existence of an entity depends on it
being related to another entity with a relationship
type.
• What is the minimum number of relationship in
which entity can participate.
– Total
- Partial
Emp Works-for Dept

16
 Contd..
• Types of participation constraints:

1. Total participation (Mandatory):

– Every entity must be related to an instance
in the relationship..
– It is represented in the ER by a double line
connecting the participating entity type to
the relationship.
– It is also called the existence dependency.
– The “Works-For” relationship illustrates
how Employee is total participated in the
relationship.

17
 Contd..

2. Partial participation (Optional):

– Part (some) of the entities are related to
some instances in the relationship.
– It is represented in the ER by a single line
connecting the entity to the relationship.
– Employee is partially participated in
“Manages”.

18
 Concepts and Notations (cont)
Relationship
• A relationship R among n entity types E1,E2, ..
En defines a set of associations (relationship
set) among entities from these types.
• A relationship has its type and set (instances).
• Each instance in R is an association of entities,
where the association includes exactly one
entity from each participating entity type.
• The reference from entity to another should be
represented in the ER model as a relationship
not as attributes.

19
Constraints on Relationship Types
• Cardinality Ratio: it specifies the number of
relationship instances that an entity can
participate in.
• What is the maximum no. of relationship in
which an entity can participate.

– There is three types:

• 1:1 (one-to-one) relationship.
• 1:N (one-to-many) relationship.
• M:N (many-to-many) relationship.
20
Constraints on Relationship Types
• 1:1 (one-to-one) relationship:
• RA: Every dept should have a manager and only one
employee can manages only one dept. and employee can
manage only one dept. MANGES
EMPLOYEE r1
e1 • 
DEPARTMENT
e2 • r2
e3 • 
• d1
e4 • r3 • d2
e5 • • d3

. .
r4 .
.
. 
.
r5
21
Constraints on Relationship Types
1:N (one-to-many):
RA: Every employee works for exactly one dept. and a dept.
WORKS_FOR
can have many employee.
EMPLOYEE r1
e1 • 
DEPARTMENT
e2 • r2
e3 • 
• d1
e4 • r3 • d2
e5 • • d3

. .
r4 .
.
. 
.
r5
22
Constraints on Relationship Types
• M:N (many-to-many): Every emp supposed to
work at least one project and employee can work on many
project. Similarly project can have many employees.
WORKS_ON

EMPLOYEE r1
e1 • 
PROJECT
e2 • r2
e3 • 
• p1
e4 • r3 • p2
e5 • • p3

. .
r4 .
.
. 
.
r5
23
Attributes of Relationship Types
• Relationship types can also have
attributes (e.g. “Works-On” may have
attributes as hours, start_date, ..etc).

24
 Weak Entity Sets

An entity set that does not have a primary key
is referred to as a weak entity set.

An entity set that has a primary key is
referred to as a strong entity set.

E.g. Entiy set payment has 3 attributes:
- payment_number,payment_date,
payment_amount, payment for
different loans may share the same
payment number.
 Weak Entity Sets...

- The existence of a weak entity set depends on the

existence of a identifying entity set

- it must relate to the identifying entity set via a

total, one-to-many relationship set from the
identifying to the weak entity set
 Weak Entity Sets (Cont.)

- Identifying relationship depicted using a double

diamond
- The discriminator (or partial key) of a weak entity
set is the set of attributes that distinguishes
among all the entities of a weak entity set.
- 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.
 Weak Entity Sets (Cont.)

We depict a weak entity set by double rectangles.

We underline the discriminator of a weak entity set with a
dashed line.

payment-number – discriminator of the payment entity set

Primary key for payment – (loan-number, payment-number)
 Weak Entity Sets (Cont.)


Note: the primary key of the strong entity set is not
explicitly stored with the weak entity set, since it is
implicit in the identifying relationship.

If loan-number were explicitly stored, payment could
be made a strong entity, but then the relationship
between payment and loan would be duplicated by
an implicit relationship defined by the attribute loan-
number common to payment and loan
 More Weak Entity Set Examples


In a university, a course is a strong entity and a course-offering
can be modeled as a weak entity

The discriminator of course-offering would be semester
(including year) and section-number (if there is more than one
section)

If we model course-offering as a strong entity we would model
course-number as an attribute.
Then the relationship with course would be implicit in the
course-number attribute
 Roles

Entity sets of a relationship need not be distinct

The labels “manager” and “worker” are called roles; they specify
how employee entities interact via the works-for relationship set.

Roles are indicated in E-R diagrams by labeling the lines that
connect diamonds to rectangles.

Role labels are optional, and are used to clarify semantics of the
relationship
Roles...
Symbols Used in E-R Notation
Summary of Symbols (Cont.)
Alternative E-R Notations
 Keys

Keys in a Relation: A key allows us to identify a

set of attributes that suffice to distingwish entities
from each other.
- For eg. Student
Roll.No Name DOB Course Ph.No Email Address
1 Nita 3-1-1968 B.Tech 9832465231 [email protected] Mumbai
om

2 Amit 4-8- B.Tech 9833163523 [email protected] Mumbai

1989 om

3 Rita 5-3- B.Tech 9831162522 [email protected] Santacruz

1999 om
 Keys...

Key Attributes set(KAS):

- Key attribute is minimal number of attributes used
to differentiate all tuples of the relation.
- For eg. KA1 = Roll.No
KA2 = Ph.No
KA3= Email
 Keys...

Types of Keys:
1. Super Key: set of one or more
attributes that allows identifying
an entity uniquely.
- For eg. {Roll No,Name}
- It may contain extra attributes.
 Contd...
2. A candidate key:
- It is a minimal set of super key which can
uniquely identify an entity
- For eg. Roll No, Ph.No,Email
- Every candidate key is a super key but
every superkey is not a candidate key
- For eg. {Roll No , name}----> S.K
 Contd..

3. Primary key : An attribute ,which is

uniquely identifies each record within a
table.
- For eg. Roll.No
4. Foreign key: An attribute whose value
match the primary key in the releated table.
- For eg. Emp Dept

E_id D_id D_id Dname E_id

E-R Diagram with a Ternary Relationship
 Cardinality Constraints on Ternary
Relationship

We allow at most one arrow out of a
ternary (or greater degree) relationship to
indicate a cardinality constraint

E.g. an arrow from works-on to job
indicates each employee works on at most
one job at any branch.

If there is more than one arrow, there are
two ways of defining the meaning.
 contd...
- E.g a ternary relationship R between A, B and C
with arrows to B and C could mean
1. each A entity is associated with a unique entity
from B and C or
2. each pair of entities from (A, B) is associated
with a unique C entity, and each pair (A, C)
is associated with a unique B
- Each alternative has been used in different
formalisms
- To avoid confusion we outlaw more than one
arrow
 Extended E-R Features
Specialization

Top-down design process; we designate
subgroupings within an entity set that are
distinctive from other entities in the set.

These subgroupings become lower-level
entity sets that have attributes or
participate in relationships that do not
apply to the higher-level entity set.
 Specialization..

- Depicted by a triangle component labeled

ISA (E.g. customer “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 Example
 Generalization

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.
 Specialization and Generalization (Contd.)

Can have multiple specializations of an entity
set based on different features.

E.g. permanent-employee vs. temporary-
employee, in addition to officer vs. secretary
vs. teller

Each particular employee would be

a member of one of permanent-employee or
temporary-employee,
 Specialization and Generalization (Contd.)

- and also a member of one of officer,

secretary, or teller
- The ISA relationship also referred to as
superclass - subclass relationship
 Design Constraints on a
Specialization/Generalization

Constraint on which entities can be
members of a given lower-level entity set.

condition-defined
 E.g. all customers over 65 years are
members of senior-citizen entity set; senior-
citizen ISA person.

user-defined

Constraint on whether or not entities may
belong to more than one lower-level entity
set within a single generalization.
 Design Constraints on a
Specialization/Generalization

Disjoint
- an entity can belong to only one lower-level
entity set
Noted in E-R diagram by writing disjoint next to
the ISA triangle
- Overlapping
- an entity can belong to more than one lower-
level entity set
 Design Constraints on a
Specialization/Generalization (Contd.)

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
 Aggregation
 Consider the ternary relationship works-on, which we saw earlier

 Suppose we want to record managers for tasks performed by an

employee at a branch
 Aggregation (Cont.)

Relationship sets works-on and manages
represent overlapping information

Every manages relationship corresponds to a
works-on relationship

However, some works-on relationships may not
correspond to any manages relationships
 So we can’t discard the works-on relationship

Eliminate this redundancy via aggregation

Treat relationship as an abstract entity

Allows relationships between relationships
 Aggregation (Cont.)

- Abstraction of relationship into new entity

- Without introducing redundancy, the following

diagram represents:
- An employee works on a particular job at a
particular branch
- An employee, branch, job combination may have
an associated manager
E-R Diagram With Aggregation
 E-R Design Decisions

The use of an attribute or entity set to
represent an object.

Whether a real-world concept is best
expressed by an entity set or a
relationship set.

The use of a ternary relationship versus
a pair of binary relationships.

The use of a strong or weak entity set.
 E-R Design Decisions...

- The use of specialization/generalization –

- contributes to modularity in the design.
- The use of aggregation – can treat the
aggregate entity set as a single unit without
concern for the details of its internal
structure.
E-R Diagram for a Banking Enterprise
Reduction of an E-R Schema to Tables


Primary keys allow entity sets and
relationship sets to be expressed
uniformly as tables which represent
the contents of the database.

A database which conforms to an
E-R diagram can be represented by
a collection of tables.
 Reduction of an E-R Schema to Tables...

- For each entity set and relationship set there is a

unique table which is assigned the name of the
corresponding entity set or relationship set.
- Each table has a number of columns (generally
corresponding to attributes), which have unique
names.
- Converting an E-R diagram to a table format is the
basis for deriving a relational database design
from an E-R diagram.
Representing Entity Sets as Tables

A strong entity set reduces to a table
with the same attributes.
 Composite and Multivalued Attributes

Composite attributes are flattened out by
creating a separate attribute for each
component attribute

E.g. given entity set customer with composite
attribute name with component attributes first-
name and last-name the table corresponding
to the entity set has two attributes
name.first-name and name.last-
name

A multivalued attribute M of an entity E is
represented by a separate table EM
Composite and Multivalued Attributes...

- Table EM has attributes corresponding to

the primary key of E and an attribute
corresponding to multivalued attribute M
- E.g. Multivalued attribute dependent-
names of employee is represented by a
table employee-dependent-
names( employee-id, dname)
Composite and Multivalued Attributes...

- Each value of the multivalued attribute

maps to a separate row of the table EM
E.g., an employee entity with primary key
John and dependents Johnson and
Johndotir maps to two rows:
(John, Johnson) and (John, Johndotir)
Representing Weak Entity Sets
 A weak entity set becomes a table that includes a column for the
primary key of the identifying strong entity set
 Representing Relationship Sets as
Tables

A many-to-many relationship set is represented as a table with
columns for the primary keys of the two participating entity sets,
and any descriptive attributes of the relationship set.

E.g.: table for relationship set borrower
 Redundancy of Tables
 Many-to-one and one-to-many relationship sets that are total
on the many-side can be represented by adding an extra
attribute to the many side, containing the primary key of the
one side
 E.g.: Instead of creating a table for relationship account-
branch, add an attribute branch to the entity set account
 Redundancy of Tables (Cont.)

For one-to-one relationship sets, either
side can be chosen to act as the “many”
side

That is, extra attribute can be added to
either of the tables corresponding to the
two entity sets

If participation is partial on the many
side, replacing a table by an extra
attribute in the relation corresponding to
the “many” side could result in null
values
 Redundancy of Tables (Cont.)..

The table corresponding to a relationship set

linking a weak entity set to its identifying
strong entity set is redundant.
E.g. The payment table already contains the
information that would appear in the loan-
payment table (i.e., the columns loan-number and
payment-number).
 Representing Specialization as Tables

Method 1:

Form a table for the higher level entity

Form a table for each lower level entity set, include
primary key of higher level entity set and local
attributes

table table attributes

person name, street, city
customer name, credit-rating
employee name, salary

Drawback: getting information about, e.g.,
employee requires accessing two tables
 Representing Specialization as Tables
(Cont.)

Method 2:

Form a table for each entity set with all local and inherited
attributes
table table attributes
person name, street, city
customer name, street, city, credit-rating
employee name, street, city, salary


If specialization is total, table for generalized entity (person) not
required to store information
 Can be defined as a “view” relation containing union of
specialization tables
 But explicit table may still be needed for foreign key
constraints

Drawback: street and city may be stored redundantly for persons
who are both customers and employees
 Relations Corresponding to
Aggregation

 Torepresent aggregation, create a table

containing
 primary key of the aggregated relationship,
 the primary key of the associated entity set
 Any descriptive attributes
 Relations Corresponding to
Aggregation (Cont.)

 E.g. to represent aggregation manages between relationship

works-on and entity set manager, create a table
manages(employee-id, branch-name, title, manager-name)
 Table works-on is redundant provided we are willing to store
null values for attribute manager-name in table manages
Relations Corresponding to Aggregation
(Cont.)
 Academic Teaching Database

Design an E-R schema for a database to store info about professors, courses
and course sections indicating the following:
• The name and employee ID number of each professor
• The salary and email address(es) for each professor
• How long each professor has been at the university
• The course sections each professor teaches
• The name, number and topic for each course offered
• The section and room number for each course section
• Each course section must have only one professor
• Each course can have multiple sections

76
 Visual View of the Database

Employee ID Start Date Years Teaching Section ID Room

1 N
Professor teaches Section
Email

Salary First
Name Part of

Last
1

Number Course

77
Topic Name
 Binary Vs. Non-Binary Relationships

Some relationships that appear to be non-
binary may be better represented using
binary relationships

E.g. A ternary relationship parents, relating a
child to his/her father and mother, is best
replaced by two binary relationships, father
and mother
 Using two binary relationships allows partial
information (e.g. only mother being know)

But there are some relationships that are
naturally non-binary
 E.g. works-on
End of Chapter 2
E-R Diagram for Exercise 2.10
E-R Diagram for Exercise 2.15
E-R Diagram for Exercise 2.22
E-R Diagram for Exercise 2.15
 Existence Dependencies

If the existence of entity x depends on the existence of
entity y, then x is said to be existence dependent on y.
y is a dominant entity (in example below, loan)
x is a subordinate entity (in example below, payment)
 Contd..

loan loan-payment payment

If a loan entity is deleted, then all its associated payment entities

must be deleted also.