Download Document

The Entity-Relationship
Model
Overview of Database Design

Conceptual Design -- A first model of the real world
(using ER modeling)
 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)
 An ER schema should be understandable by noncomputer scientists.
 We can map an ER diagram into a relational schema
421B: Database Systems - ER Model
2
ER Model Basics


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 (similarity to a “class” in OO)
 All entities in an entity set have the same attributes (until we
consider ISA hierarchies later…). An attribute describes a
property of the entity set.
 Each entity set has a key:

Minimum set of attributes whose values uniquely identify an entity
in the set
 Each attribute has a domain:
 Integer, 20-character string
eid
name
lot
Employees
Entity set = rectangle, Attribute = oval
421B: Database Systems - ER Model
3
ER Model Basics (Contd.)


Relationship: Association among two or more entities.
E.g. Miller works in Pharmacy department.
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
•
Same entity set could participate in different relationship sets, or
in different roles in the same set.
eid
Employees
name
salary
Works_in
since
did
dname
Departments
eid
did
4
5
2
1
1998
1999
5
...
2
1999
...
...
since
budget
421B: Database Systems - ER Model
4
ER Model (contd.)
3-ary relationship
Employees with different
roles in a relationship
name
eid
salary
name
eid
salary
Employees
address
since Works_in
Location
capacity
Employees
supervisor
subordinate
Reports_To
Departments
budget
did
dname
421B: Database Systems - ER Model
Role indicator:
supervisor/subordinate
5
Multiplicity: Many-to-many

Works_In:
 An employee can work in several departments;
department has several employees
 Many-many relationship between departments and
employees
Many to many
eid
name salary
Employees
Works_In
Departments
did
421B: Database Systems - ER Model
dname
budget
6
Multiplicity: one-to-many,many-to-one

Manages:
 One employee can manage several departments; each department
is managed by only one employee;
 One-to-many relationship between employee and department
 Many-to-one relationship between department and employee;
 The condition “each department is managed by only one employee”
is called a key constraint on Manages and depicted with arrow
from Departments to Manages
One to many
since
eid
name
Employees
salary
Manages
Departments
did
421B: Database Systems - ER Model
dname
budget
7
Multiplicity: one-to-one

Manages-2:
 Each employee can only manage one department;
each department is managed by only one employee;
 One-to-one relationship between Employees and
Departments
 Key constraints in both directions
One to one
since
eid
name
Employees
salary
Manages
Departments
did
421B: Database Systems - ER Model
dname
budget
8
Participation Constraints

Manages-3:
 Each department must have a manager: the
participation constraint requires that the
participation of Departments in Manages is total (vs.
partial) (depicted with a thick line)
since
eid
name
salary
Employees
Manages
Departments
did
421B: Database Systems - ER Model
dname
budget
9
Weak Entities

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 supporting one-to-many relationship
set (one owner, many weak entities).
 Weak entity set must have total participation in this
identifying set.
cost
eid
name
Employees
421B: Database Systems - ER Model
pname dateofbirth
salary
Policy
Dependants
10
ISA (“is a”) Hierarchies: Subclasses


Subclass = special case =
fewer entities = more
properties
“A ISA B”, then every A
entity is also a B entity
eid
name
Employees
hours_worked
hourly_wages
 Key only in B.

Reasons for using Subclasses:

Where do the entities reside:
Hourly_Emps
Contract_id
ISA
Contract_Emps
 Additional descriptive attributes specific for a subclass salary?
 Identification of a subclass that participates in a relationship
 E/R-viewpoint: An entity has a component in each entity set to
which it logically belongs. Its properties are the union of these
entity sets.
 Contrast OO-viewpoint: An object belongs to exactly one class.
The subclass inherits the attributes of its superclass.
421B: Database Systems - ER Model
11
ISA Hierarchies (Contd.)
Overlap Constraint: Can an entity be in more than one
subclass? (allowed/disallowed)
 Covering Constraint: Must every entity of the
superclass be in one of the subclasses? (yes/no)
 Developing Class Hierarchies

 Specialization: Identifying subsets of an entity set (the
superclass) that share some distinguishing characteristic.
Represents top-down design: superclass is first, then
subclasses are defined and specific attributes and
relationships are set.
 Generalization: Several entity sets are generalized into a
common entity set. Represents bottom-up design: common
characteristics of a collection of entity sets are identified, a
superclass entity set is built with these characteristics as
attributes.

Theoretically multiple inheritance possible, in practice
not used
421B: Database Systems - ER Model
12
Aggregation


Aggregation allows us to treat a
relationship set R as an entity set so
that R can participate in (other
relationships).
Aggregation vs. ternary relationship:
eid
 Monitors is a distinct relationship with a
descriptive attribute
 Can provide additional multiplicity constraints
name salary
Employees
Monitors until
Started_on
pid
pbudget
Projects
421B: Database Systems - ER Model
since
Sponsors
did dname budget
Departments
13
Conceptual Design with ER

Design Principles:
 Keep it simple
 Avoid redundancies
 Capture as many constraints as possible

Design Choices
 Entity or attribute?
 Attributes and relationships
 Identifying relationships: Binary or ternary?
Aggregation?
421B: Database Systems - ER Model
14
Design Principles

Avoid redundancies and keep it simple
pid
sname
name
Avoid
Redundancy
Parts
sname
address
Suppliers
pid
offer
name
Parts
saddress
sname
Suppliers
pid
offer
421B: Database Systems - ER Model
Parts
name
Keep it
simple
pid
name
sname
Parts
15
Relationships and Attributes
since
name
eid
mbudget
salary
Employees
Manages
Departments
did
eid
name
dname
budget
salary
Employees
mbudget
ISA
Managers
since
Manages
Departments
did
421B: Database Systems - ER Model
dname
budget
16
Entity vs. Attribute
Should address be an attribute of Employees or an
entity (connected to Employees by a relationship)?
 Depends on the use and the semantics of the
information

 If we have several addresses for each employee, address
must be an entity (since attributes cannot be set-valued).
 If address represents a lodging or place of business and
hence is a real object that is independent of the people
who live or work there, then it should be an entity
 Note, it we want to capture the structure of address
(because we want to retrieve all employees in a given
city), we must use several separate attributes (street,
zip, city, etc.). This can happen within the Employees
entity or as an extra entity.
421B: Database Systems - ER Model
17
Entity vs. Relationship
sid
name
Suppliers
quantity
Order
did
Department
sid
name
date
Suppliers
name
Parts
dname
quantity oid
Department
name
pid
Parts
Order
did
421B: Database Systems - ER Model
pid
dname
18
Binary vs. Ternary Relationships

Situation I:
 employee can own several policies
 each policy can be owned by several
employees
 each dependent can be covered by
several policies
 a policy can cover several dependents

Employees
policy
 a policy can cover several
dependents
covers
pid
Situation II:
 employee can own several policies
 each policy has only one owner
 each dependent is identified by its
pname
name salary
eid
Policies
eid
name
Dependents
cost
pname dob
salary
Employees
dob
Dependents
beneficiary
purchaser
421B: Database Systems - ER Model
pid
Policies
cost
19
Summary

Conceptual design follows requirement analysis
 Yields a high-level description of data to be stored

ER model popular for conceptual design
 Constructs are expressive, close to way people think
about their applications
Basic constructs: entities, relationships, and
attributes (of entities and relationships)
 Some additional constructs: weak entities, ISA
hierarchies, and aggregation
 Note: there are many variations on ER model
 Alternative: UML

421B: Database Systems - ER Model
20
Summary (contd.)

Several kinds of integrity constraints can be
expresses in the ER model: key constraints,
participation constraints, overlap/covering constraints
for ISA hierarchy. Some foreign key constraints are
also implicit in the definition of the relationship set

Some constraints (notably, functional dependencies)
cannot be expressed in the ER model

Constraints play an important role in determining the
best database design for an enterprise
421B: Database Systems - ER Model
21
Summary (contd.)

Conceptual 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, and whether or not to use aggregation

Ensuring good database design: resulting
relational schema should be analyzed and
refined further. FD information and
normalization techniques are especially useful
421B: Database Systems - ER Model
22
421B: Database Systems - ER Model
23
Binary vs. Ternary vs.
Aggregation

Situation :
 Stars play in movies and movies are produced by studios
 Several constraints possible:
 Each movie is only produced by one studio
 A star has only a single contract for a movie (even if several studios involved)
 A contract for a movie is always between a star and a single studio (even if
several studios involved)

Solution I:
 Ternary relation
 Each arrow would lead to a nonsense restriction
 Consequence:
 Each movie can be produced by several studios
 But only possible if at least one star has contract with this studio for this movie
Stars
421B: Database Systems - ER Model
Studios
Movies
24
Binary vs. Ternary vs.
Aggregation
Solution II:
 Two binary relations
Stars
 movie produced by one studio possible
 A star plays now exactly once for a
movie (with one contract)
play
 But if several studios produce a movie
we cannot express with which studio
the contract is done
 Solution III:
 Aggregation
Movies
 movie produced by one studio possible
 Star can have one or more contracts
for a movie; each with a different
studio

Studios
produce
Movies
produce
Studios
play
stars
421B: Database Systems - ER Model
25
Attributes of Relationships

Given a relationship set R between entity sets
E1 and E2 and its own attributes r1,…rr. If for
a given instance (e1,e2) of the relationship
there exist several values for the attributes
r1,…rr, we have to add a new entity to the
relationship
ssn
ssn
Employees
from
name
from
Employees
Duration
Works_in3
lot
lot
Works_in2
to
to
did
dname
Departments
budget
421B: Database Systems - ER Model
name
did
Departments
dname
budget
26
Binary vs. Ternary Relationships
(contd.)

Ternary:
 Order lists the last
order of company X of
part Y at supplier Z
sid
Suppliers
Binary
 Supplier offer Parts
 Companies own Parts
 Company deals with
Supplier
Order
did
IS NOT THE SAME AS

quantity
name
Department
sid
name
Suppliers
did
cid
421B: Database Systems - ER Model
offer
Parts
dname
needs
pid
Parts
name
deal
with
pid
Parts
name
name
Departments
pid
name
name
Departments
name
sid
Suppliers
27