The Entity-Relationship Model

Databases Model the Real World
The EntityRelationship
Model
Data Model allows us to translate real

world things into structures computers
can store
Many models: Relational, E-R, O-O,
Network, Hierarchical, etc.
Relational
Rows & Columns
Keys & Foreign Keys to link Relations
R &G - Chapter 2
A relationship, I think, is like a

shark, you know? It has to
constantly move forward or it
dies. And I think what we got
on our hands is a dead shark.
Enrolled
sid
53666
53666
53650
53666
Woody Allen (from Annie Hall, 1979)
Steps in Database Design

Requirements Analysis
user needs; what must database
do?
Conceptual Design
high level descr (often done w/ER
model)
Logical Design
translate ER into DBMS data model
Schema Refinement
consistency, normalization
Physical Design - indexes, disk layout
Security Design - who accesses what,
and how
ER Model Basics
cid
nam
essn
lot
Employees
Carnatic101
Reggae203
Topology112
History105
Students
grade
sid
name
C
B
A
B
login
age
gpa
5366 Jones jones@cs

18
6
5368 Smith smith@eecs 18
8
5365 Smith smith@mat 19
0
h
Conceptual Design
3.2
3.8
What are the entities and relationships

in the enterprise?
What information about these entities
and relationships should we store in the
database?
What are the integrity constraints or
business rules that hold?
A database `schema in the ER Model
can be represented pictorially (ER
diagrams).
Can map an ER diagram into a
relational schema.
ER Model Basics
(Contd.)
since
name
ssn
dname
did
lot
budget
Works_In
Entity: Real-world object, distinguishable

from other objects. An entity is described
using a set of attributes.
Entity Set: A collection of similar entities.
E.g., all employees.
All entities in an entity set have the
same set of attributes.
(Until we
consider hierarchies, anyway!)
Each entity set has a key
(underlined).
Each attribute has a domain.
3.4
Employees
Departments
Relationship: Association among two or more

entities. E.g., Attishoo works in Pharmacy
department.
relationships can have their own attributes.
Relationship Set: Collection of similar
relationships.
An n-ary relationship set R relates n entity sets
E1 ... En ; each relationship in R involves entities e1
E1, ..., en En
name
name
ER Model Basics
(Cont.)
ssn
Key
Constraints
lot
since
ss n
lot
Employees
dname
did
Manages
budget
Departments
Employees
rsupe
visor
since
dname
budget
did
Departments
s
ubord inate
Works_In
Same entity set can participate in

different relationship sets, or in
different roles in the same set.
lot
did
budget
since
Manages
Many-toMany
1-to Many
1-to-1
Departments
A weak entity can be identified uniquely

only by considering the primary key of
another ( owner) entity.
Owner entity set and weak entity set must
participate in a one-to-many relationship
set (one owner, many weak entities).
Weak entity set must have total
participation in this identifying
relationship set.
ssn
Em ployees
Works_In
since
Weak Entities
Participation Constraints
Does every employee work in a department?
If so, this is a participation constraint
the participation of Employees in Works_In is said
to be
total (vs. partial)
What if every department has an employee
working in it?
name
dname
Basically means
at least one
ssn
An employee
can work in
many
departments; a
dept can have
Inmany
contrast, each
dept
has at most
employees.
one manager,
according to the
key constraint on
Manages.
name
lot
cost
pname
age
Works_In
Means: exactly
one
since
Policy
Employees
Dependents
Weak entities have only a partial key (dashed

underline)
Binary vs. Ternary Relationships (Contd.)
Binary vs. Ternary

Relationships
If each policy is
owned by just
1 employee:
Key
constraint on
Policies
would mean
policy can
only cover 1
dependent!
Think through
all the
constraints in
the 2nd
diagram!
name
ssn Employees
lot
pname
Bad
design
ssn
name
age
Covers
Dependents
Previous example illustrated a case when two

binary relationships were better than one
ternary relationship.
Policies
policyid
cost
pname
lot
age
Dependents
Employees
Purchaser
Better
design
Beneficiary
Policies
policyid
cost
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.
Summary so far
Binary vs. Ternary Relationships
(Contd.)
qty
Parts
Contract
Departments
Suppliers
Parts
VS
.
Departments
needs
can-supply
Suppliers
deals-with
Entities and Entity Set (boxes)

Relationships and Relationship sets (diamonds)
binary
n-ary
Key constraints (1-1,1-M, M-M, arrows on 1 side)
Participation constraints (bold for Total)
Weak entities - require strong entity for key
Next, a couple more advanced concepts
S can-supply P, D needs P, and D dealswith S does not imply that D has agreed to
buy P from S.
How do we record qty?
Aggregati
on
ssn
Conceptual Design Using the ER Model
lot
Employees
Used to model
a relationship
involving a
relationship
set.
name
Monitors
until
since
started_on
pid
pbudget
did
dname
budget
Sponsors
Departments
Projects
Allows us to treat
a relationship
Aggregation vs. ternary
participation
set as an entityrelationship?
in
(other)
set for
Monitors is a distinct relationship,
relationships
purposes of with a descriptive attribute.
.
Also, can say that each sponsorship
is
monitored by at most one employee.
Entity vs. Attribute

Should address be an attribute of
Employees or an entity (related to
Employees)?
Depends upon how we want to use
address information, and the
semantics of the data:
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, address must be modeled as
an entity (since attribute values are
atomic).
ER modeling can get tricky!

Design choices:
Should a concept be modeled as an entity or an
attribute?
Should a concept be modeled as an entity or a
relationship?
Identifying relationships: Binary or ternary?
Aggregation?
Note constraints of the ER Model:
A lot of data semantics can (and should) be captured.
But some constraints cannot be captured in ER
diagrams.
Well refine things in our logical (relational) design
Entity vs. Attribute

(Cont.)
from
name
ssn
Works_In2 does
not allow an
employee to work
in atwo
department
for
or more
periods.
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.
to
lot
Works_In2
Employees
ssn
dname
did
budget
Departments
name
lot
Employees
did
Works_In3
dname
budget
Departments
to
from
Dur tion
a
Now you try it
Entity vs.
Relationship
OKseparate
as long as a
manager gets
discretionary
a
budget
dept.
What if managers
dbudget covers
all managed
depts?
(can repeat value,
but
such
redundancy
is
problematic)
since
name
ssn
dbudget
lot
Employees
dname
budget
did
Departments
Manages2
name
ssn
lot
dname
did
Employees
budget
Departments
is_manager
apptnum
managed_by
Try this at home - Courses database:

Courses, Students, Teachers
Courses have ids, titles, credits,
Courses have multiple sections that have
time/rm and exactly one teacher
Must track students course schedules and
transcripts including grades, semester taken,
etc.
Must track which classes a professor has taught
Database should work over multiple semesters
since
Mgr_Appts
dbudget
These things get pretty hairy!
A Cadastral E-R Diagram
Many E-R diagrams cover entire walls!

A modest example:
cadastral: showing or recording property boundaries, subdivision
lines, buildings, and related details
Source: US Dept. Interior Bureau of Land Management,
Federal Geographic Data Committee Cadastral Subcommittee
http://www.fairview-industries.com/standardmodule/cad-erd.htm
Converting ER to Relational
Logical DB Design: ER to
Relational
ssn
Entity sets to
tables.
But many simple concepts in ER are
subtle to specify in relations
ssn
lot
name
lot
123-22-3666 Attishoo
48
231-31-5368 Smiley
22
131-24-3650 Smethurst 35
Employees
CREATE TABLE Employees

(ssn CHAR(11),
name CHAR(20),
lot INTEGER,
PRIMARY KEY
(ssn))
Relationship Sets to Tables

CREATE TABLE Works_In(
In
translatingset
a many-to-many
CHAR(1),
relationship
to a
did ssn
INTEGER,
relation,
attributes of the relation must since
include
PRIMARY KEY (ssn, did),
:
DATE,
1) Keys for each participating FOREIGN KEY (ssn)
entity set (as foreign
REFERENCES Employees,
keys). This set of attributesFOREIGN KEY (did)
forms a superkey for
REFERENCES Departments)
the relation.
ssn
did since
2) All descriptive
attributes.
123-22-3666 51 1/1/91
123-22-3666
231-31-5368
56
51
3/3/93
2/2/92
Translating ER with Key

Constraints
n
lot
Employees
name
ss
since
Manages
did
bu
Depar
tments
dname
dget
Since each department has a unique

manager, we could instead combine
Manages and Departments.
ssn CHAR(11),
since DATE,
Vs.
PRIMARY KEY (did),
FOREIGN KEY (ssn)
REFERENCES Employees,
FOREIGN KEY (did)
REFERENCES Departments)
did INTEGER,
budget REAL,
ssn CHAR(11),
since DATE,
PRIMARY KEY (did),
FOREIGN KEY (ssn)
REFERENCES
Employees)
Review: Key
Constraints
most one
Each dept has at
manager,
according to
the key
constraint on
Manage
s.
since
name
dname
ssn
lot
did
budget
Employees
Manages
Departments
Translation to
relational
model?
1-to-1
1-to Many
Many-to-1
Many-to-Many
Review: Participation Constraints

Does every department have a manager?
If so, this is a participation constraint: the

participation of Departments in Manages is said to be
total (vs. partial).
Every did value in Departments table must
appear in a row of the Manages table (with a
non-null
namessn value!)
dname
Manages
Em ployees
Departments
Works_In
since
Participation Constraints in SQL

We can capture participation constraints involving one
entity set in a binary relationship, but little else
(without resorting to CHECK constraints which well
learn later).
CREATE TABLE
Dept_Mgr( did INTEGER,
dname CHAR(20),
budget REAL,
ssn CHAR(11)
NOT NULL,
since DATE,
PRIMARY KEY (did),
FOREIGN KEY (ssn)
REFERENCES
Employees,
ON DELETE NO ACTION)
Review: Weak Entities

A weak entity can be identifed uniquely only by
considering the primary key of another (owner)
entity.
Owner entity set and weak entity set must
participate in a one-to-many relationship set (1
owner, many weak entities).
Weak entity set must have total participation in
this
cost
identifying
relationship
set.
pname
lot
age
ssn
name
Policy
Employees
Dependents
Translating Weak Entity Sets
Weak entity set and identifying relationship

set are translated into a single table.
When the owner entity is deleted, all owned
weak entities must also be deleted.
CREATE TABLE Dep_Policy

( pname CHAR(20),
age INTEGER,
cost REAL,
ssn CHAR(11) NOT NULL,
PRIMARY KEY (pname, ssn),
FOREIGN KEY (ssn) REFERENCES Employees,
ON DELETE CASCADE)
Summary of ER (Cont.)
Several kinds of integrity constraints:
key constraints
participation constraints
Some foreign key constraints are also
implicit in the definition of a relationship
set.
Many other constraints (notably,
functional dependencies) cannot be
expressed.
Constraints play an important role in
determining the best database design for
an enterprise.
Summary of Conceptual Design

Conceptual design follows requirements analysis,
Yields a high-level description of data to be
stored
ER model popular for conceptual design
Constructs are expressive, close to the way
people think about their applications.
Note: There are many variations on ER model
Both graphically and conceptually
Basic constructs: entities, relationships, and

attributes (of entities and relationships).
Some additional constructs: weak entities, ISA
hierarchies
(see text if youre curious), and aggregation.
Summary of ER (Cont.)
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:
Entity vs. attribute, entity vs. relationship, binary
or n- ary relationship, whether or not to use ISA
hierarchies, aggregation.
Ensuring good database design: resulting
relational schema should be analyzed and
refned further.
Functional
Dependency
information
and
normalization techniques are especially useful.

The Entity-Relationship Model

Uploaded by

Copyright:

Available Formats

The Entity-Relationship Model

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The Entity-Relationship Model

Uploaded by

Copyright:

Available Formats

Databases Model the Real World

Data Model allows us to translate real

A relationship, I think, is like a

Woody Allen (from Annie Hall, 1979)

Steps in Database Design

5366 Jones jones@cs

What are the entities and relationships

Entity: Real-world object, distinguishable

Relationship: Association among two or more

Same entity set can participate in

A weak entity can be identified uniquely

Weak entities have only a partial key (dashed

Binary vs. Ternary Relationships (Contd.)

Binary vs. Ternary

Previous example illustrated a case when two

An example in the other direction: a ternary

Entities and Entity Set (boxes)

Conceptual Design Using the ER Model

Entity vs. Attribute

ER modeling can get tricky!

Entity vs. Attribute

Now you try it

Try this at home - Courses database:

These things get pretty hairy!

A Cadastral E-R Diagram

Many E-R diagrams cover entire walls!

CREATE TABLE Employees

Relationship Sets to Tables

Translating ER with Key

Since each department has a unique

Review: Participation Constraints

If so, this is a participation constraint: the

Participation Constraints in SQL

Review: Weak Entities

Translating Weak Entity Sets

Weak entity set and identifying relationship

CREATE TABLE Dep_Policy

Summary of Conceptual Design

Basic constructs: entities, relationships, and

You might also like