DATABASE MANAGEMENT SYSTEMS

Part 2 : E-R Diagrams

 A database can be modeled as:
◦ a collection of entities,
◦ relationship among entities.

 An entity is an object that exists and is distinguishable

from other objects.
◦ Example: specific person, company, event, plant

 Entities have attributes

◦ Example: people have names and addresses

 An entity set is a set of entities of the same type that

share the same properties.
◦ Example: set of all persons, companies, trees,
holidays
 Entity sets to tables:

CREATE TABLE Employees

name (ssn CHAR(11),
ssn lot name CHAR(20),
lot INTEGER,
PRIMARY KEY (ssn))

Employees
 CREATE TABLE Works_In(
 In translating a relationship set to
a relation, attributes of the ssn CHAR(11),
relation must include: did INTEGER,
◦ Keys for each participating
since DATE,
entity set (as foreign keys).
PRIMARY KEY (ssn, did),
 This set of attributes
forms a superkey for the FOREIGN KEY (ssn)
relation. REFERENCES Employees,
◦ All descriptive attributes. FOREIGN KEY (did)
REFERENCES Departments)
 Each dept has at most
one manager, according
to the key constraint since
on Manages. 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
 Map relationship to a
table: CREATE TABLE Manages(
◦ Note that did is the key ssn CHAR(11),
now! did INTEGER,
◦ Separate tables for since DATE,
Employees and PRIMARY KEY (did),
Departments. FOREIGN KEY (ssn) REFERENCES Employees,
FOREIGN KEY (did) REFERENCES Departments)
 Since each department
has a unique manager,
we could instead CREATE TABLE Dept_Mgr(
combine Manages and did INTEGER,
Departments. dname CHAR(20),
budget REAL,
ssn CHAR(11),
since DATE,
PRIMARY KEY (did),
FOREIGN KEY (ssn) REFERENCES Employees)
 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 ssn value!)

since
name dname
ssn lot did budget

Employees Manages Departments

Works_In

since
 We can capture participation constraints involving one entity set in a binary
relationship, but little else (without resorting to CHECK constraints).

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)
 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.

name
cost pname age
ssn lot

Employees Policy Dependents

 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)
 name
 As in C++, or other ssn lot
PLs, attributes are
inherited. Employees

 If we declare A ISA B,
hourly_wages hours_worked
every A entity is also ISA
considered to be a B contractid

entity. Contract_Emps
Hourly_Emps

 Overlap constraints: Can Joe be an Hourly_Emps as well as a

Contract_Emps entity? (Allowed/disallowed)
 Covering constraints: Does every Employees entity also have to
be an Hourly_Emps or a Contract_Emps entity? (Yes/no)
 General approach:
◦ 3 relations: Employees, Hourly_Emps and Contract_Emps.
 Hourly_Emps: Every employee is recorded in Employees.
For hourly emps, extra info recorded in Hourly_Emps
(hourly_wages, hours_worked, ssn); must delete
Hourly_Emps tuple if referenced Employees tuple is
deleted).
 Queries involving all employees easy, those involving just
Hourly_Emps require a join to get some attributes.

 Alternative: Just Hourly_Emps and Contract_Emps.

◦ Hourly_Emps: ssn, name, lot, hourly_wages,
hours_worked.
◦ Each employee must be in one of these two subclasses.
 name
ssn lot pname age
 What are the
additional Employees Covers
constraints in the Dependents
2nd diagram? Bad design Policies

policyid cost

name pname age

ssn lot
Dependents
Employees

Purchaser
Beneficiary

Better design
Policies

policyid cost
 CREATE TABLE Policies (
 The key
constraints allow policyid INTEGER,
us to combine cost REAL,
Purchaser with ssn CHAR(11) NOT NULL,
Policies and PRIMARY KEY (policyid).
Beneficiary with FOREIGN KEY (ssn) REFERENCES Employees,
Dependents. ON DELETE CASCADE)
 Participation
constraints lead CREATE TABLE Dependents (
to NOT NULL pname CHAR(20),
constraints. age INTEGER,
 What if Policies is policyid INTEGER,
a weak entity PRIMARY KEY (pname, policyid).
set?
FOREIGN KEY (policyid) REFERENCES Policies,
ON DELETE CASCADE)
customer_id customer_ customer_ customer_ loan_ amount
name street city number
 An entity is represented by a set of attributes, that is
descriptive properties possessed by all members of an
entityExample:
set.
customer = (customer_id, customer_name,
customer_street, customer_city )
loan = (loan_number, amount )

 Domain – the set of permitted values for each attribute

 Attribute types:
◦ Simple and composite attributes.
◦ Single-valued and multi-valued attributes
 Example: multivalued attribute: phone_numbers
◦ Derived attributes
 Can be computed from other attributes
 Example: age, given date_of_birth
 Express the number of entities to which another
entity can be associated via a relationship set.

 Most useful in describing binary relationship sets.

 For a binary relationship set the mapping

cardinality must be one of the following types:
◦ One to one
◦ One to many
◦ Many to one
◦ Many to many
 One to one One to many
Note: Some elements in A and B may not be mapped to any
elements in the other set
 Many to one Many to many
Note: Some elements in A and B may not be mapped to any
elements in the other set
 name
ssn lot

Employees

 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

ssn lot
since
name dname
ssn lot did budget Employees

super- subord
Employees Works_In Departments visor inate
Reports_To

 Relationship: Association among two or more entities. E.g.,

Attishoo 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 same set.
 A relationship is an association among several
entities
Example:
Hayes depositor A-102
customer entity relationship set account entity

 A relationship set is a mathematical relation among

n  2 entities, each taken from entity sets
{(e1, e2, … en) | e1  E1, e2  E2, …, en  En}

where (e1, e2, …, en) is a relationship

◦ Example:
(Hayes, A-102)  depositor
 An attribute can also be property of a relationship set.
 For instance, the depositor relationship set between
entity sets customer and account may have the attribute
access-date
 Refers to number of entity sets that
participate in a relationship set.

 Relationship sets that involve two entity

sets are binary (or degree two). Generally,
most relationship sets in a database system
are binary.

 Relationship sets may involve more than

two entity sets.
 Example:
Suppose employees of a bank may have jobs
(responsibilities) at multiple branches, with
different jobs at different branches.
Then there is a ternary relationship set between
entity sets employee, job, and branch

 Relationships between more than two entity sets

are rare. Most relationships are binary. (More on
this later.)
 Additional features of the ER model
since
name dname
ssn lot did budget
 Consider Works_In:
An employee can
Employees Manages Departments
work in many
departments; a dept
can have many
employees.

 In contrast, each dept

has at most one
manager, according
to the key
constraint on
Manages.
1-to-1 1-to Many Many-to-1 Many-to-Many
 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 Departments entity must appear in an
instance of the Manages relationship.

since
name dname
ssn lot did budget

Employees Manages Departments

Works_In

since
 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.

name
cost pname age
ssn lot

Employees Policy Dependents

 An entity set that does not have a primary key is referred to
as a weak entity set.

 The existence of a weak entity set depends on the existence of

a identifying entity set
◦ it must relate to the identifying entity set via a total, one-
to-many relationship set from the identifying to the weak
entity set
◦ Identifying relationship depicted using a double diamond

 The discriminator (or partial key) of a weak entity set is the

set of attributes that distinguishes among all the entities of a
weak entity set.

 The primary key of a weak entity set is formed by the primary

key of the strong entity set on which the weak entity set is
existence dependent, plus the weak entity set’s discriminator.
 We depict a weak entity set by double rectangles.
 We underline the discriminator of a weak entity set with a
dashed line.
 payment_number – discriminator of the payment entity set
 Primary key for payment – (loan_number, payment_number)
 Note: the primary key of the strong entity set is
not explicitly stored with the weak entity set, since
it is implicit in the identifying relationship.

 If loan_number were explicitly stored, payment

could be made a strong entity, but then the
relationship between payment and loan would be
duplicated by an implicit relationship defined by
the attribute loan_number common to payment
and loan
 In a university, a course is a strong entity and a
course_offering can be modeled as a weak entity

 The discriminator of course_offering would be

semester (including year) and section_number (if
there is more than one section)

 If we model course_offering as a strong entity we

would model course_number as an attribute.
Then the relationship with course would be
implicit in the course_number attribute
 name
ssn
 As in C++, or other PLs, lot

attributes are inherited.

Employees
 If we declare A ISA B,
every A entity is also hourly_wages hours_worked
considered to be a B ISA
contractid
entity.
Contract_Emps
Hourly_Emps

 Overlap constraints: Can Joe be an Hourly_Emps as well as a

Contract_Emps entity? (Allowed/disallowed)
 Covering constraints: Does every Employees entity also have to
be an Hourly_Emps or a Contract_Emps entity? (Yes/no)
 Reasons for using ISA:
◦ To add descriptive attributes specific to a subclass.
◦ To identify entitities that participate in a relationship.
 Used when we have name
ssn lot
to model a
relationship
involving (entitity Employees
sets and) a
relationship set.
Monitors until
◦ Aggregation
allows us to treat
a relationship set started_on since
dname
as an entity set pid pbudget did
for purposes of budget
participation in Sponsors
Projects Departments
(other)
relationships.
Consider the ternary relationship works_on, which we
saw earlier
 Suppose we want to record managers for tasks
performed by an employee at a branch
 Relationship sets works_on and manages represent
overlapping information
◦ Every manages relationship corresponds to a works_on
relationship
◦ However, some works_on relationships may not
correspond to any manages relationships
 So we can’t discard the works_on relationship

 Eliminate this redundancy via aggregation

◦ Treat relationship as an abstract entity
◦ Allows relationships between relationships
◦ Abstraction of relationship into new entity
 Eliminate this redundancy via aggregation
◦ Treat relationship as an abstract entity
◦ Allows relationships between relationships
◦ Abstraction of relationship into new entity

 Without introducing redundancy, the following diagram

represents:
◦ An employee works on a particular job at a particular
branch
◦ An employee, branch, job combination may have an
associated manager
 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.
 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 (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).
 Works_In4 does not
allow an employee to
work in a department from to
for two or more name dname
periods. ssn lot did budget
 Similar to the Departments
problem of wanting Employees Works_In4
to record several
addresses for an
employee: We want
to record several
values of the
descriptive attributes name dname
for each instance of ssn lot did budget
this relationship.
Accomplished by Employees Works_In4 Departments
introducing new
entity set, Duration.
from Duration to
 First ER diagram OK if a
manager gets a separate since dbudget
name dname
discretionary budget for ssn lot did budget
each dept.
 What if a manager gets a Employees Manages2 Departments
discretionary budget
that covers all
managed depts? name
ssn lot
◦ Redundancy: dbudget
stored for each dept since dname
Employees did
managed by manager. budget
◦ Misleading: Suggests
Manages2 Departments
dbudget associated ISA
with department-mgr
combination.
Managers dbudget
This fixes the
problem!
 If each policy is name
owned by just 1 ssn lot pname age
employee, and Employees Dependents
Covers
each dependent
is tied to the Bad design Policies
covering policy,
first diagram is policyid cost
inaccurate. name pname age
ssn lot
Dependents
 What are the Employees
additional
constraints in Purchaser
Beneficiary
the 2nd
diagram? Better design Policies

policyid cost
 Previous example illustrated a case when two binary
relationships were better than one ternary
relationship.

 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:
◦ S “can-supply” P, D “needs” P, and D “deals-
with” S does not imply that D has agreed to buy P
from S.
◦ How do we record qty?