Lecture 3

The ER and EER Model

The Entity-Relationship Model
 Main Phases of Database Design
• Requirements document and analysis: a
specification of user requirements
• Conceptual design: ER Model is used at this
stage, which is then translated to a relational
schema
• Schema refinement: (Normalization) Check
relational schema for redundancies and related
anomalies
• Physical database design and tuning:
Consider typical workloads and further refine the
database design
 ER Diagrams -- The Basics
• Entity: an object that exists and is distinguishable from
other objects, e.g. Student, Course, Route, Climber
• Entity set: a set of entities of the same type that share the
same properties or attributes.
– Drawn as rectangles: Courses
• Attribute: descriptive properties possessed by each
member of an entity set, e.g. Name, Age, Height.
– Drawn as ovals: Name
• Relationship: an association among several entities, e.g.
a student enrolls in a course, a climber climbs a route, etc.
• Relationship set: a set of relationships with the same
type
– Drawn as diamonds: Enrolls
 Drawing Entity Sets
• The term “entity” and “entity set” are often
confused. Boxes represent sets of entities
• To draw an entity set we connect it with its
attributes and indicate the key by
underlining it:

Routes

RId RName Grade Rating Height

 Drawing Relationships
• Relationship sets are represented by
diamonds
• They connect the entity sets they relate,
and may additionally have attributes

Climbers Climbs Routes

Duration Date
 The Whole Diagram

CId CName RId

RName
Climbers Climbs Routes Grade

Skill Age Duration Date Rating Height

 Types of Attributes
• Composite: Divided into smaller subparts
which represent more basic attributes with
independent meanings

• Atomic: Not divisible

• Single-valued: A single value for a particular
entity (e.g., age of person)
• Multi-valued: Attribute with a set of values for
the same entity (e.g., degrees); A person may
have 2 or more degrees
 Types of Attributes
• Stored: DOB
• Derived: Value of an attribute can be derived
from other attributes (e.g., age from DOB)

• Null Values: When a value is not applicable for

an attribute of a particular entity (e.g., apt#) or a
value exists but is missing (e.g., weight of a
person) or it is not known whether the attribute
value exists (e.g., phone#)
 Key Attribute
• An attribute of an entity set for which each
entity must have a unique value
– SSN of EMPLOYEE
– StudentID of STUDENT
• A key attribute may be composite
– VehicleTagNumber is a key of the CAR entity
set with components (Number, State)
 Types of Keys
• Superkey: combination of one or more attributes
that allow us to identify an entity in an entity set
– Name attribute of EMPLOYEE is not a superkey
• Candidate key: a minimal superkey that
uniquely identifies an entity
– Suppose combination of Name and Address is
sufficient to distinguish among members of the
EMPLOYEE entity set
– SSN and {Name, Address} are candidate keys
• Primary key: candidate key chosen by DBA to
identify entities of an entity set (e.g., SSN)
 Degree of Relationship
• Degree of relationship: # of participating
entity sets in a relationship
• Binary: Degree two (e.g., Employee works for
Department)
• Ternary: Degree three

• N-ary
 Cardinality Ratio
• Expresses the # of entities to which
another entity can be associated via a
relationship set
– 1:1—Employee manages department
– 1:N—Mother having children
– N:1—Children having mothers
– M:N—Students enrolled courses
 Binary Relationships
• 1:1: An entity in A is associated with at most one
entity in B and an entity in B is associated with at
most one entity in A
• 1:N: An entity in A is associated with any
number of entities in B. An entity in B, however,
can be associated with at most one entity in A
• M:N: An entity in A is associated with any
number of entities in B and an entity in B is
associated with any number of entities in A
 Binary Relationships
• Relationships involving two entity sets
(binary relationships) can be classified as
1-to-1, 1-to-Many (Many-to-1) or Many-to-
Many

1-to-1 1-to Many-to-1 Many-to-Many

Many
 Modeling Many-to-1
Relationships
• A many-to-1 relationship is modeled by placing
an arrow in the many ® one direction or N:1
• An employee can work for exactly one
department but a department can have any
number of employees

since
name dname
ssn addr did budget

Employees Work_for Departments

 Modeling Many-to-1
Relationships
• Explicit Notation:
since
name dname
ssn addr did budget

Employees Work_for
N 1 Departments
 Participation
• Specifies whether the existence of an
entity depends on its being related to
another entity via the relationship set
• Two types
– Total
– Partial
 Total Participation
• Every employee must work for a
department, then every employee in
Employee entities must be related to a
department entity via Works_For
relationship (represented by double line)

name dname
ssn did

Employees Works_for Departments

N 1
 Partial Participation
• Some employee entities are related to a
department entity via Manages but not
necessarily all
name dname
ssn did

Employees Manages Departments

1 1
• Structural constraints: cardinality ratio and
participation
 Role
• Role: Function that an entity plays in a
relationship is called its role
• Implicit role: All the participating entity
sets in a relationship set are distinct
– Works_For relationship set: Employee plays
the role of employee or worker and
Department plays the role of department or
employer
name dname
ssn did

Employees Works_for Departments

N 1
 Recursive Relationships
• Explicit role: all the participating entity sets in a
relationship are not distinct
1 Supervisor

Supervision Employee

N Supervisee

• Recursive relationship: Same entity set participates

more than once in a relationship in different roles
– Supervision relationship relates an employee to a supervisor,
where both employee and supervisor entities are the members
of the same Employee entity set
 Weak Entities
• Weak entity set does not have enough attributes to form
a primary key
• 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 (1 owner, many weak entities)
- Weak entity set must have total participation in this identifying
relationship set

cost name age

ssn name

Employees Policy Dependents

1 N
 Aggregation
• Used when we have to model a relationship
between a collection of entities and relationships
• Allows us to treat a relationship set as an entity
set for purposes of participation in (other)
relationships
• Why aggregation?
– Need to express relationship among relationships
• Why not ternary relationship?
– Several distinct relationships
– Each with its own attributes
Aggregation Example
name
ssn lot

Employees

Monitors until

started_on since
dname
pid pbudget did budget

Projects Sponsors Departments

M N
 Conceptual Design Using the ER
Model
• 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?
 Entity vs. Attribute
• Works_In2 does not allow an employee to work
in a department for two or more periods
from to
name dname
ssn lot did budget

Employees Works_In2 Departments

N 1
• We want to record several periods for each
employee
name dname
ssn lot did budget

Employees Works_In3 Departments

from Duration to
 Entity vs. Relationship
• First ER diagram OK if a
since dbudget
manager gets a separate name dname
discretionary budget for ssn lot did
each dept
• What if a manager gets a Employees Manages2 Departments
1 N
discretionary budget that
covers all managed
depts?
name dname
– Redundancy of
ssn lot did
dbudget, which is
stored for each dept Employees Manages3 Departments
managed by the
manager
– Misleading: suggests since
dbudget tied to apptnum Mgr_Appts
managed dept dbudget
 Binary vs. Ternary Relationships

• Ternary relationship represents more

information than do 3 binary relationships
• In general, an n-ary relationship is not
equivalent to n binary relationships
 Binary vs. Ternary Relationships
• A ternary relation Supply relates entity sets Part,
Project and Supplier, and has descriptive
attribute Quantity. No combination of binary
relationships is an adequate substitute
Binary vs. Ternary Relationships
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
• Basic constructs: entities, relationships, and
attributes (of entities and relationships)
• Some additional constructs: weak entities, and
aggregation
• Note: There are many variations on ER model
 Summary of ER
• 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, 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
 Summary of ER (Contd.)
Symbol Meaning
Entity

Weak Entity

Relationship

Identifying Relationship

Attribute

Key Attribute
 Summary of ER (Contd.)
Symbol Meaning

Multi-valued

Composite Attribute

Derived Attribute
 Summary of ER (Contd.)
Symbol Meaning

E1 R E2 Total Participation of E2 in R

1 N
E1 R E2 Cardinality Ratio 1:N for E1:E2 in R
 DNumber
Name
Salary Addr
1
1 No-Emp
Supervision Employee N department
Works For
1
N 1 Name 1
SSN location
M
Controls
manages
N
Dependents
Works-on Project
N Location
N Hours Number
Name
Name Dependent

Sex Bdate Relationship

Recap of E-R Model
 Conceptual Design
• 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 constraints that hold?
• Represent this information pictorially in ER
diagram, then map ER diagram into a
relational schema
 Entities and Attributes
• Entity: real world “object”
• Entity set: set of “similar” entities/objects
• Attributes: properties typically used as
column names, similar to fields of a struct
 Relationships
• Relationship set: set of “similar”
relationships
• Connect two or more entity sets
• Represented by diamonds
 Structural Constraints
• Cardinality ratio (of a binary relationship):
1:1, 1:N, or M:N
– Shown by placing appropriate number on the
link
• Participation constraint
– Total (called existence dependency)
• Shown by double lining the link
– Partial
 Design Issues
• Setting: client has (possibly vague) ideas
of what they want. You must design a
database that represent these thoughts
and only these thoughts
• Avoid redundancy
– Redundancy=saying the same thing more than once
– Wastes space and encourages inconsistency
 Example
• Good

N 1

• Bad
 Intuitive Rules for Entity Sets vs.
Attributes
• Make an entity set only if it either:
1. Is more than a name of something; i.e., it
has nonkey attributes or relationships with
a number of different entity sets, or
2. Is the “many” in a many-one relationship
 Example

N 1

• Manfs deserves to be an E.S. because we

record addr, a nonkey attribute
• Beers deserves to be an E.S. because it is
the “many” end
Don’t Overuse Weak Entity Sets
• There is a tendency to feel that no entity
set has its entities uniquely determined
without following some relationships
• However, in practice, we almost always
create unique ID’s to compensate: social-
security numbers, VIN’s, etc
The Enhanced Entity-
Relationship Model
 EER
• EER=ER + subclass/superclass
(specialization/generalization)
• Specialization: Defines a set of subclasses
of an entity set—superclass
• Generalization: Result of computing the
union of two or more entity sets to produce a
higher-level entity set
 EER Example 1
• Employee (superclass) entity set can be
grouped into secretary, engineer,
technician,…(subclass)
BirthDate Addr JobType

Employee Name
SSN

Typing Speed EngType

Tgrade

Secretary Technician Engineer

 EER Example 2
• Vehicle (superclass) entity set can be
categorized into car, truck, … (subclass)
VehicleId Price
LicensePlateNo

Vehicle

NoOfPassengers d NoOfAxles

Tonnage
MaxSpeed Car Truck
 Inheritance
• An entity cannot merely exist by being a
member of a subclass but no superclass;
however, it is not necessary that every entity
in a superclass be a member of some
subclass
• An entity of subclass inherits
– all attributes of superclass
– all relationships in which superclass participates
– plus its own specific attributes and relationships
 Specialization
• Why specialization
– Define a set of subclasses of an entity set
– Associate additional specific attributes with each
subclass
– Establish additional specific relationship sets
between each subclass and other entity sets
• Types of specialization
– Predicate-defined: Entities will become members of
a subclass by satisfying explicit condition or
predicate
• Can automatically handled by the system
– User defined
Generalization
 Constraints of Specialization and
Generalization
• Disjointness
– Disjoint: An entity can be a member of at most one of the
subclasses
– Overlap: When sub-classes are not disjoint
• Completeness
– Total: Every entity in super class must be a member of some
subclass
– Partial: An entity might not belong to any subclass
• 4 Possible constraints on specialization
– Disjoint, total
– Disjoint, partial
– Overlapping, total
– Overlapping, partial
 Hierarchies and Lattices
• Tree-structured (hierarchy): All subclasses have
only one parent
• Graph-structured (lattice): A subclass may have
multiple superclasses
– Engineering_Manager inherits attributes and
relationships from multiple superclasses
Employee

d
d
Secretary Engineer
Technician Hourly Employee
Manager
Salaried Employee
Engineering_Manager
 Multiple Inheritance
• Potential ambiguity: If same attributes can be
inherited from more than one superclass
• Bank employee: Instead of defining attribute
salary for superclass employee, we define
attribute pay for each of full-time, part-time,
teller, and secretary as follows:
– Full-time: pay (0-100k)
– Part-time: pay (0-30/hr)
– Teller: pay (0-30k)
– Secretary: pay (0-35k)
 Bank Employee Example

Employee
Secretary

Pay

FullTime PartTime
Teller

Pay
Pay
Pay

FullTime-Secretary
 Solutions
• Keep all and use alias: fulltime.pay and
secretary.pay
• Choose one based on implementation
• Force user to choose
• Error report
 No Ambiguity
• If salary attribute is retained in only one
superclass Employee – all subclasses share
the same definition of salary
• An attribute originating in the same
superclass is inherited more than once via
different paths
– Attribute should be included only once in
subclasses
 EER
Name Address
SSN Person Birth-date
o Major-Dept
Salary Student
Degrees Alumnus
Employee
d
d Year Major
Degree
Faculty Under-Grad-
Student- Graduate- Student
Staff Assistant
Rank Student
d Class
Project Degree-Prog

Research-Assistant Teaching-Assistant Course

 Exercise
Suppose it is necessary to
keep track of
• different types of
ACCOUNTS(
SAVINGS_ACCTS,
CHECKING_ACCTS,…)
• different types of
LOANS(CAR_LOANS,
HOME_LOANS,…)
• each account’s
TRSACTIONS(deposits,
withdrawals, checks,…)
• each loan’s PAYMENTS
• include the amount, date,
time,… for PAYMENTS and
TRANSACTIONS
Modify the BANK schema
on the right side