CAS CS 460/660

Data Base Design

Entity/Relationship Model
 Describing Data: Data
Models
• Data model : collection of concepts for
describing data.

• Schema: description of a particular collection

of data, using a given data model.

• Relational model of data

– Main concept: relation (table), rows and columns
– Every relation has a schema
• describes the columns
• column names and domains
 Levels of Abstraction
• Views describe how users see
the data.

View 1 View 2 View 3

• Conceptual schema defines

Conceptual Schema
logical structure

Physical Schema
• Physical schema describes the
files and indexes used.
DB
 Example: University
Database
• Conceptual schema:
– Students(sid text, name text,
login text, age integer,
gpa float)
– Courses(cid text, cname text,
credits integer)
– Enrolled(sid text, cid text,
grade text)
• Physical schema:
– Relations stored as unordered files.
– Index on first column of Students.

• External Schema (View):

– Course_info(cid text,
enrollment integer)
 Data Independence
• Insulate apps from structure of data

• Logical data independence:

– Protection from changes in logical
structure
• Physical data independence:
– Protection from changes in physical
structure

• Q: Why particularly
Because important
databases and for
DBMS?their associated
 Data Models

• Connect concepts to
bits!
• Many models exist
• We will ground
ourselves in the Student (sid: string, name: string, login:
Relational model string, age: integer, gpa:real)
– clean and common
– generalization of
key/value
• Entity-Relationship 101011
model also handy for 1101
design
– Translates down to
 Entity-Relationship Model
• Relational model is a great formalism
– and a clean system framework
• But a bit detailed for design time
– a bit fussy for brainstorming
– hard to communicate to customers

• Entity-Relationship model is a popular

“shim” over relational model
– graphical, slightly higher level
 Steps in Traditional Database Design

• Requirements Analysis
– user needs; what must database do?
• Conceptual Design
– high level description (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
 Conceptual Design
• What are the entities and relationships?
• What info about E’s & R’s should be in DB?
• What integrity constraints (business rules) hold?
• ER diagram is the “schema”
• Can map an ER diagram into a relational schema.
 name
ER Model Basics ssn lot

Employees

• Entity:
– A real-world object described by a set of
attribute values.

• Entity Set: A collection of similar entities.

– E.g., all employees.

– All entities in an entity set have the same
attributes.
– Each entity set has a key (underlined)
– Each attribute has a domain
 ER Model Basics (Contd.)
since
name dname
ssn lot did budget

Employees Works_In 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 ...
 ER Model Basics
(Cont.) name

ssn lot

Employees
since
dname
super- subor-
did budget visor dinate
Reports_To
Departments Works_In

• Same entity set can participate in

different relationship sets, or in
different “roles” in the same
relationship set.
 name since dname
ssn lot did budget
Key Constraints
Employees Manages Departments

An employee
can work in Works_In
many since
departments; a
dept can have
many
Inemployees.
contrast, each
dept has at most
one manager,
according to the Many-to- 1-to-1
1-to- Many-
key constraint on Many Many to-1
Manages.
 Participation Constraints
• Does every employee work in a department?
• If so: a participation constraint
– participation of Employees in Works_In is total (vs. partial)
– What if every department has an employee working in it?
• Basically means “at least one”

since
name dname
ssn lot did budget

Employees Manages Departments

Works_In
or

since
Alternative: Crow’s Foot
Notation
 Summary so far

• Entities and Entity Set (boxes)

• Relationships and Relationship sets
(diamonds)
• Key constraints (arrows)
• Participation constraints (bold for Total)

These are enough to get started, but we’ll need

more…
 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
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

Weak entities have only a “partial key” (dashed underline)

 Binary vs. Ternary Relationships
name
ssn lot pname age

Employees Covers Dependents

If each policy is
owned by just 1
employee:
Policies
Key constraint
on Policies policyid cost
would mean name pname age
policy can only ssn lot
cover 1 Dependents
Employees
dependent!

• Think through Purchaser

Beneficiary
all the constraints
in the 2nd Better design Policies
diagram!
policyid cost
 Binary vs. Ternary Relationships
(Contd.)

• Previous example:
– 2 binary relationships better than 1 ternary
relationship.

• An example in the other direction:

– ternary relationship set Contracts relates entity sets
Parts, Departments and Suppliers
– relationship set has descriptive attribute qty.
– no combo of binary relationships is a substitute!
• See next slide…
 Binary vs. Ternary Relationships
(Contd.)
qty

Parts Contract Departments

VS.
Suppliers

Parts needs Departments

can-supply
Suppliers deals-with

– 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?
 name
ssn lot

Aggregation Employees

Monitors until

started_on since
dname
pid pbudget did budget

Projects Sponsors Departments

Allows relationships with relationship sets.

 E/R Data Model
Extensions to the Model: Aggregation
 E/R: No relationships between relationships
 E.g.: Associate loan officers with Borrows relationship set

Customers Borrows Loans

?
Loan_Officer

Employees

 Associate Loan Officer with Loan?

 What if we want a loan officer for every (customer, loan) pair?
 E/R Data Model
Extensions to the Model: Aggregation
 E/R: No relationships between relationships
 E.g.: Associate loan officers with Borrows relationship set

Customers Borrows Loans

Loan_Officer

Employees

 Associate Loan Officer with Borrows?

 Must First Aggregate
 E/R Data Model
Extensions to the Model: Specialization and Generalization

 An Example:
 Customers can have checking and savings accts
 Checking ~ Savings (many of the same attributes)

 Old Way:

Customers Has1 Savings Accts

acct_no balance interest

Has2 Checking Accts

acct_no balance overdraft

 E/R Data Model
Extensions to the Model: Specialization and Generalization

 An Example:
 Customers can have checking and savings accts
 Checking ~ Savings (many of the same attributes)

 New Way:
acct_no balance

Customers Has Accounts superclass

ISA

Savings Accts Checking Accts

interest overdraft

subclasses
 Conceptual Design Using the ER
Model

• ER modeling can get tricky!

• Design choices:
– Entity or attribute?
– Entity or relationship?
– Relationships: Binary or ternary? Aggregation?
• ER Model goals and limitations:
– Lots of semantics can (and should) be captured.
– Some constraints cannot be captured in ER.
• We’ll refine things in our logical (relational) design
 Entity vs. Attribute
• “Address”:
– attribute of Employees?
– Entity of its own?
• It depends! Semantics and usage.
– Several addresses per employee?
• must be an entity
• atomic attribute types (no set-valued attributes!)
– Care about structure? (city, street, etc.)
• must be an entity!
• atomic attribute types (no tuple-valued attributes!)
 Entity vs. Attribute (Cont.)
from to
name dname
ssn lot did budget
• Works_In2:
employee cannot Departments
Employees Works_In2
work in a department
for >1 period.

• Like multiple
addresses per
employee! name dname
ssn lot did budget

Employees Works_In3 Departments

from Duration to
 Converting ER to
Relational
• Fairly analogous structure
• But many simple concepts in ER are
subtle to specify in relations

since
name dname
ssn lot did budget

Employees Works_In Departments

Logical DB Design: ER to Relational
• Entity sets to tables. ssn name lot
123-22-3666 Attishoo 48
name
ssn lot 231-31-5368 Smiley 22
131-24-3650 Smethurst 35
Employees

CREATE TABLE Employees

(ssn VARCHAR(11),
name CHAR(20),
lot INTEGER,
PRIMARY KEY (ssn));
 Relationship Sets to
Tables
CREATE TABLE Works_In(
• In translating a many- ssn VARCHAR(11),
to-many relationship did INTEGER,
since DATE,
set to a relation, PRIMARY KEY (ssn, did),
attributes of the FOREIGN KEY (ssn)
REFERENCES Employees(ssn),
relation must include: FOREIGN KEY (did)
1) Keys for each REFERENCES Departments(did));
participating entity set
(as foreign keys). This
set of attributes forms ssn did since
a key for the relation.
2) All descriptive
123-22-3666 51 1/1/91
attributes. 123-22-3666 56 3/3/93
231-31-5368 51 2/2/92
 Example of Foreign Keys
CREATE TABLE Students
CREATE TABLE Enrolled (sid CHAR(20),
(sid CHAR(20), name CHAR(20),
cid CHAR(20), login CHAR(10),
grade CHAR(2), age INTEGER,
PRIMARY KEY (sid, cid), gpa FLOAT);
FOREIGN KEY (sid)
REFERENCES Students(sid));
Enrolled
cid grade sid Students
Carnatic101 C 53666
Reggae203 B 53666
Topology112 A 53650
History105 B 53666
 Review: Key Constraints
• Each dept has at
since
most one name dname
manager,
ssn lot did budget
according to the
key constraint on
Employees Manages Departments
Manages.

Translation to
relational model?

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

 Translating ER with Key Constraints

since
name dname
ssn lot did budget

Employees Manages Departments

• Since each department has a unique manager,

we could instead combine Manages and Departments.
CREATE TABLE Employees CREATE TABLE Departments
(ssn CHAR(11), (did INTEGER,
name CHAR(20), dname CHAR(20),
lot INTEGER, budget REAL,
PRIMARY KEY (ssn)); PRIMARY KEY (did));

CREATE TABLE Manages(

ssn CHAR(11),
did INTEGER,
since DATE,
PRIMARY KEY (did),
FOREIGN KEY (ssn) REFERENCES
Employees(ssn),
FOREIGN KEY (did) REFERENCES
Departments(did));
CREATE TABLE Employees
OR
(ssn CHAR(11),
name CHAR(20),
lot INTEGER,
PRIMARY KEY (ssn));

CREATE TABLE Dept_Mgr(

did INTEGER,
dname CHAR(20),
budget REAL,
ssn CHAR(11),
since DATE,
PRIMARY KEY (did),
FOREIGN KEY (ssn)
REFERENCES Employees)
 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 ssn value!)
since
name dname
ssn lot did budget

Employees Manages 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).

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(ssn)
ON DELETE NO ACTION)
 Review: 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 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

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
weakTABLE
CREATE entities must also( be deleted.
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 Conceptual Design
• Conceptual design follows requirements analysis,
– Yields a high-level description of data to be stored
– You may want to postpone it for read-only “schema on use”
• 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, and aggregation.
 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 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
refined further.
– Functional Dependency information and normalization
techniques are especially useful.