The EntityRelationship Model

Overview of
Database Design
v Requirements Analysis:
Understand what data will be
stored in the database, and the
operations it will be subject to.
v Conceptual Design: (ER

Model is used at this stage.)

v What

are the entities and

relationships in the
enterprise?

v What

information about these

entities and relationships
should we store in the
database?

v What

are the integrity

constraints or business rules
that hold?

vA

database `schema in the ER

Model can be represented
pictorially (ER diagrams).

v Can

map an ER diagram into a

relational schema.

v Logical Design: Convert the

conceptual database design into
the data model underlying the
DBMS chosen for the application.

Overview of
Database Design
(cont.)

v Schema Refinement:
(Normalization) Check
relational schema for
redundancies and anomalies.
v Physical Database Design
and Tuning: Consider typical
workloads and further refinement
of the database design (v.g. build
indices).
v Application and Security
Design: Consider aspects of the
application beyond data.
Methodologies like UML often
used for addressing the complete
software development cycle.

ER Model Basics

v Entity: Real-world object

distinguishable from other

objects. An entity is
described using a set of

attributes.
v Entity Set: A collection of

entities of the same kind.

E.g., all employees.
v All

entities in an entity set

have the same set of
attributes.

v Each

entity set has a key(a set

of attributes uniquely
identifying an entity).

v Each

attribute has a domain.

ER Model Basics
(Contd.)

v Relationship: Association among two or

more entities. E.g., Peter works in
Pharmacy department.

v Relationship Set: Collection of similar

relationships.
v An n-ary relationship set R relates n
entity sets E1 ... En; each
relationship in R involves entities e1
E1, ..., en En
v Same entity set could participate in
different relationship sets, or in
different roles in same set.
v Relationship sets can also have
descriptive attributes (e.g., the since
attribute of Works_In). A relationship
is uniquely identified by participating
entities without reference to
descriptive attributes.

Key Constraints
(a.k.a. Cardinality)

v Consider Works_In (in previous

slide): An employee can work in
many departments; a dept can
have many employees.
v In contrast, each dept has at
most one manager, according to
the key constraint on Manages.

Key Constraints
(ternary
relationships)
Participation
Constraints
v Does every department have a
manager?
v If so, this is a participation
constraint: the participation of
Departments in Manages is said to
be total (vs. partial).

Every Department MUST have at

least an employee
Every employee MUST work at
least in one department
There may exist employees
managing no department

Weak Entities
v A weak entity can be identified
uniquely only by considering the
primary key of another (owner)
entity.
v Owner entity set and weak entity set
must participate in a one-to-many
relationship set (one owner, many
weak entities).
v Weak entity sets must have total
participation in this identifying
relationship set.
v transac# is a discriminator within
a group of transactions in an ATM.

ISA (`is a)
Hierarchies
v Overlap constraints: Can Joe be an
Hourly_Emps as well as a
Contract_Emps entity? if so, specify =>
Hourly_Emps OVERLAPS
Contract_Emps.

v Covering constraints: Does every

Employees entity also have to be an
Hourly_Emps or a Contract_Emps
entity?. If so, write Hourly_Emps AND
Contract_Emps COVER Employees.

Aggregation
v Used when we have to model a
relationship involving (entity sets
and) a relationship set.

v Aggregation allows us to treat a

relationship set as an entity set for
purposes of participation in (other)
relationships.
v Employees are assigned to monitor
SPONSORSHIPS.

Conceptual Design
Using the ER Model
v Design choices:
v Should

a concept be modeled
as an entity or an attribute?

v Should

a concept be modeled
as an entity or a relationship?

v Identifying

relationships:
Binary or ternary?
Aggregation?

v Constraints in the ER Model:

vA

lot of data semantics can

(and should) be captured.

v But

some constraints cannot

be captured in ER diagrams.

Entity vs. Attribute

v Should address be an

attribute of Employees or an
entity (connected to
Employees by a
relationship)?
v Depends upon the use we

want to make of address

information, and the
semantics of the data:
v

If we have several
addresses per employee,
address must be an entity
(since attributes cannot be
set-valued).

If the structure (city, street,

etc.) is important, e.g., we
want to retrieve employees
in a given city, address
must be modeled as an
entity (since attribute
values are atomic).

Entity vs. Attribute

(Contd.)
v Works_In4 does not

allow an
employee to work in a department
for two or more periods (a relationship
is identified by participating entities).

v Similar to the problem of wanting to

record several addresses for an
employee: We want to record several
values of the descriptive attributes for
each instance of this relationship.
Accomplished by introducing new entity
set, Duration.

Entity vs.
Relationship
v First ER diagram OK if a manager
gets a separate discretionary
budget for each dept.
v What if a manager gets a
discretionary budget that
covers
all managed depts?
v Redundancy: dbudget stored for
each dept managed by manager.
v Misleading: Suggests dbudget
associated with department-mgr
combination.

Binary vs. Ternary

Relationships
v Suppose:

v A policy cannot be owned by more

than one employee.
v Every policy must be owned by
some employee.
v Dependent is a weak entity set,
identified by policiId.

Binary vs. Ternary

Relationships (Contd.)
v Previous example illustrated

a case when two binary

relationships were better
than one ternary
relationship.

v An example in the other

direction: a ternary relation

Contracts relates entity sets
Parts, Departments and
Suppliers, and has
descriptive attribute qty. No
combination of binary
relationships is an adequate
substitute:
v Although

S can-supply P, D
needs P, and D dealswith S, all these do not imply
that D has agreed to buy P
from S (because D could buy P
from another supplier).

Summary of
Conceptual Design

v Conceptual design follows

requirements analysis,
v Yields

a high-level description
of data to be stored

v ER model popular for

conceptual design
v Constructs

are expressive,
close to the way people think
about their applications.

v Basic constructs: entities,

relationships, and attributes

(of entities and
relationships).
v Some additional constructs:

weak entities, ISA

hierarchies, and
aggregation.

v Note: There are many

variations on ER model.

Summary of ER
(Contd.)
v Several kinds of integrity

constraints can be
expressed in the ER model:
key constraints,
participation constraints,
and overlap/covering
constraints for ISA
hierarchies. Some foreign
key constraints are also
implicit in the definition of a
relationship set.

v Some

constraints (notably,
functional dependencies)
cannot be expressed in the ER
model.

v Constraints

play an important
role in determining the best
database design for an
enterprise.

Summary of ER
(Contd.)
v ER design is subjective.

There are often many ways

to model a given scenario!
Analyzing alternatives can
be tricky, especially for a
large enterprise. Common
choices include:

v Entity

vs. attribute, entity vs.

relationship, binary or n-ary
relationship, whether or not to
use ISA hierarchies, and
whether or not to use
aggregation.

v Ensuring good database

design: resulting relational

schema should be analyzed
and refined further. FD
information and
normalization techniques
are especially useful.