Database Design using ER

Diagrams

Modified from “Database Management Systems 3ed, R. Ramakrishnan and J.

Gehrke”
 Overview of Database Design
• Conceptual design: (ER Model is used at this
stage.)
– 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
• Entity: Real-world object distinguishable from other objects. An
entity is described (in DB) 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 ISA hierarchies, anyway!)
• Each entity set has a key.

• Each attribute has a domain.

name

aadhar
Employees cabin
 Complex Attributes
• Attribute types:
– Simple and composite attributes.
– Single-valued and multivalued attributes
• Example: multivalued attribute: phone_numbers
– Derived attributes
• Can be computed from other attributes
• Example: age, given date_of_birth
• Domain – the set of permitted values for each attribute
Composite Attributes
 Redundant Attributes
• Suppose we have entity sets:
– instructor, with attributes: ID, name, dept_name,
salary
– department, with attributes: dept_name, building,
budget
• We model the fact that each instructor has an
associated department using a relationship set
inst_dept
• The attribute dept_name appears in both entity sets.
Since it is the primary key for the entity set
department, it replicates information present in the
relationship and is therefore redundant in the entity set
instructor and needs to be removed.
• BUT: when converting back to tables, in some cases
the attribute gets reintroduced, as we will see later.
 Relationship Sets
• Relationship: Association among two or more entities.
E.g., John works in Physics 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
attributes. (Until we consider ISA hierarchies, anyway!)

name
aadhar cabin dname
did budget

Works
Employees Departments
in

since
 Relationships (contd.)
• Ternary Relationship-example
since
name
aadhar cabin dname
did budget

Works
Employees Departments
in2

Locations

address capacity
 Roles in a relationship set
• The same entity set could participate in different
relationship sets, or in different “roles” in same set

name
aadhar cabin

Employees

Supervisor Subordinate
Reports
to
Key Constraints (contd.)
 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 aadhar value!)

name since
aadhar cabin dname
did budget

Employees Manages Departments

Works in

since
 Weak Entities
• A weak entity can be identified uniquely only by considering the
primary key of another (owner) entity.
– Each weak entity is existence dependent on the identifying entity set.

– 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.

name cost
aadhar cabin pname age

Employees Policy Dependents

Extended ER Features
•
ISA (`is a’) Hierarchies
As in C++, or other PLs, attributes are inherited.

• If we declare A ISA B, every A entity is also considered to be a B entity.

• Overlap constraints: Can Joe be an Hourly_Emps as well as a Contract_Emps entity? (Hourly_Emps

overlaps Contract_Emps)

• Covering constraints: Does every Employees entity also have to be an Hourly_Emps or a

Contract_Emps entity? (Hourly_Emps AND Contract_Emps cover Employees)

• Reasons for using ISA:

– To add descriptive attributes specific to a subclass.
– To identify entitities that participate in a relationship.

name
aadhar cabin

Employees

Hourly_ Hours_Wor
OfferID
Wage ked ISA

Hourly_Emps Perma_Emps
 Aggregation
• Used when we have to model a relationship involving (entitity sets and) a relationship set.

• Aggregation allows us to treat a relationship set as an entity set for purposes of participation in (other)
relationships.
• Example: Each department that sponsors a project might assign employees to oversee the sponsorship.
– Why not have a ternary relationship? (Ans: sponsors may have different attributes from oversees, for example, dates)

name
aadhar cabin

Employees

overs
ees

pid start_date did dname budget

pbudget

Projects Spons
Departments
ors
 Aggregation (example
• Consider a DB with information about employees who work
on a particular special project and use a number of machines
doing that work
name
number location

Machinery

uses

aadhar name pid pname

cabin

Employees Works Sp_Project

hours
Reduction to Relation Schemas
 Representing Entity Sets
• A strong entity set reduces to a schema with the same
attributes
Employees(aadhar, name, cabin)

• A weak entity set becomes a table that includes a column

for the primary key of the identifying strong entity set
section ( aadhar, pname, age )

name cost
aadhar cabin pname age

Employees Policy Dependents

 Representation of Entity Sets with Composite Attributes

• Composite attributes are flattened out by creating a

separate attribute for each component attribute

– Example: given an entity set Employees with composite

attribute name with component attributes first_name
and last_name the schema corresponding to the entity
set has two attributes name_first_name and
name_last_name
• Prefix omitted if there is no ambiguity (name_first_name could
be first_name)

• Ignoring multivalued attributes, the extended

Employees schema is Employees(aadhar,
first_name, middle_initial, last_name,
cabin)
 Representation of Entity Sets with Multivalued Attributes

• A multivalued attribute M of an entity E is represented

by a separate schema EM

• Schema EM has attributes corresponding to the

primary key of E and an attribute corresponding to
multivalued attribute M

• Example: Multivalued attribute phone_number of

Employees is represented by a schema:
emp_phone= ( aadhar, phone_number)

• Each value of the multivalued attribute maps to a

separate tuple of the relation on schema EM
– For example, an employee entity with primary key 11111
and phone numbers 456-7890 and 123-4567 maps to
two tuples:
(11111, 456-7890) and (11111, 123-4567)
 Representing Relationship Sets
• A relationship must be uniquely identified by the participating entities.

• Relationship set keys: Let R involve entity sets E1..En and let pk(Ei) denote
the primary key of Ei.

• If R has attributes a1,a2,…am, R is described by pk(E1)Ս pk(E2) Ս…. Ս

pk(En) Ս a1 Ս a2… Սan

• Super Key of R is pk(E1) Ս…. Ս pk(En)

eid name did name

• Manages is
described by
{eid,did,since} man
Manager age Department
• Superkey is {eid,did} s

since
 Representing Relationship Sets (contd.)
• Case1: one manager can manage many departments
eid did since
101 A123 2010
101 B123 2010
201 C123 2010

• Case2: one department has several managers

eid did since
101 A123 2010
201 B123 2010
301 B123 2010

• Case3: one manager can manage many departments and one department has
several managers eid did since
101 A123 2010
101 B123 2010
201 B123 2010

• Case4: one manager can manage only one department and each department has
one manager
eid did since
101 A123 2010
201 B123 2010
301 C123 2010
 Representing Relationship Sets
(contd.)
• Primary key is -
• {did} if one manager can manage many departments;{eid} if one
department has several managers
• {eid,did} if if one manager can manage many departments and if one
department has several managers
• {eid } or {did} if one manager can manage only one department

• In general, the primary key of R is –

– pk of “many” in a many-to-one or one-to-many relationship
– union of pks of both entity sets in a many-to-many relationship and
– either entity set’s pk in a one-to-one relationship
 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?
• Constraints in the ER Model:
– A lot of data semantics can (and should) be captured.
– But some constraints cannot be captured in ER
diagrams.
 Entity vs Attribute
• Should address be an attribute of Employees or an
entity (connected to Employees by a relationship)?

• Depends upon the use we want to make of address

information, and the semantics of the data:

– If we have several addresses per employee, address

must be an entity (if attributes cannot be setvalued in the version of ER
model. In any case, the relations that we get would be the same).

– 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.)
• Worksinfor does not allow an employee to work in a
department for two 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.

name
aadhar cabin dname
did budget

Worksinf
Employees Departments
or

from to
 Entity vs Attribute (contd.)
• Accomplished by introducing new entity
set, Duration.

name
aadhar cabin dname
did budget

Worksinf
Employees Departments
or

Duration

from to
 Entity vs Relationship
• This ER diagram OK if a manager gets a separate discretionary budget for each dept.

• What if a manager gets a discretionary budget that covers all managed depts?
– Redundancy: dbudget stored for each dept managed by manager.
– Misleading: Suggests dbudget associated with department-mgr combination.

• Solution??????

name
aadhar cabin dname
did budget

Manages
Employees Departments
2

since dbudget
• Add a new specialized entity set Managers under Employees. Have the attribute
dbudget for Managers and relationship “Manages3” from Managers to Departments
 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, ISA
hierarchies, and aggregation.
• Note: There are many variations on ER model.
 Summary of ER (Contd.)

• 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.

• 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.
 Summary of ER (Contd.)

• 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 nary
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.