Professional Documents
Culture Documents
ER Model
ER Model
Chapter 2
1
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
Motivating Example: Design DB for
B&N Hiring Dudes DB Co.
Requirements:
Topic: Books focusing on horse racing
Customers to browse catalog over the internet
Order books over the internet
Order contains: ISBN number, and quantity.
Shipment of whole order in one shot. If not all books in
stock, then additional copies made.
For each book, catalog contains: ISBN, title, author, purchase
price, sales price, and year book was published.
Records for customers are maintained: names and
addresses.
New customers have to open an account first, and get CID.
Payment by credit card
HOW???
2
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
Outline
Database Design and ER Diagram
Entities, Attributes, & Entity set
Relationships and relationship Set
Additional Features of the ER Model
Conceptual design with the ER Model
Conceptual Design for Large Enterprises
Case Study: Internet Shop
3
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
Database Design Approach
1. Requirement Collection
2. Requirement Analysis
3. Conceptual Design (Ch. 2)
4. Logical Design (Ch. 3)
5. Physical Implementation (Ch. 8)
6. Tuning & possibly repeating above steps
(Ch. 4, 5, 19)
4
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
Requirements Analysis
5
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
Conceptual Design
In this step, develop a high level description of
the data to be stored in DB and their constraints.
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?
Represent the database `schema’ in the ER Model
pictorially (ER diagrams).
Then, map the ER diagram into a relational
schema. 6
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
Remaining steps in the design
Logical Design
Translate ER Diagram to Relations (Ch. 3)
Physical Implementation
E.g. Choosing Indexing (Ch. 8)
Tuning & possibly repeating above steps
E.g. Normalization (Ch. 19)
…Other considerations, e.g. applications
(Ch.6-7), security, …
7
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
Outline
Database Design and ER Diagram
Entities, Attributes, & Entity set
Relationships and relationship Set
Additional Features of the ER Model
Conceptual design with the ER Model
Conceptual Design for Large Enterprises
Case Study: Internet Shop
8
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
Entity-Relationship Data Model
(ER)
entity: a real-world object such as a student.
attributes: to describe a particular entity (e.g. name, SS#,
height).
domain: Each attribute comes from a specified domain (e.g.,
name may be a 20 character string; SS# is a nine-digit integer)
entity set: a collection of similar entities (i.e., those which are
distinguished using the same set of attributes. E.g. Football
Players
key: a minimal set of attributes for an entity set. May be a
single attribute (such as SS#) or multiple attributes as a key
("Bob from Accounting"). We will generally designate one such
key as the primary key.
Relationships between entities: Association between entities
9
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
ER Diagram - Entities
name
ssn lot
Employees
10
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
Outline
Database Design and ER Diagram
Entities, Attributes, & Entity set
Relationships and relationship Set
Additional Features of the ER Model
Conceptual design with the ER Model
Conceptual Design for Large Enterprises
Case Study: Internet Shop
11
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
name
since Employees
name dname
super- subor-
ssn lot did budget visor dinate
Reports_To
Employees Works_In Departments
13
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
Types of relationships since
name dname
ssn lot did budget
Consider Works_In:
Employees Works_in Departments
An employee can
work in many
departments; a dept
can have many
employees.
15
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
Key Constraint
since
name dname
ssn lot did budget
name
cost pname age
ssn lot
started_on since
dname
pid pbudget did budget
entity.
Reasons for using ISA:
To add descriptive attributes specific to a subclass.
To identify (specific sub-class) entitities that participate
in a relationship.
20
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
name
ssn lot
Other good
Aggregation Employees
examples:
OGC vs RPD,
prog mgrs vs
Used when we have people mgrs
to model a Monitors until
relationship set
involved in another
relationship set. started_on since
dname
Aggregation allows us pid pbudget did budget
to treat a relationship
set as an entity set Projects Sponsors Departments
for purposes of
participation in * Aggregation vs. ternary relationship:
(other) relationships.
• Monitors is a distinct relationship,
Represented by
dashed box. with a descriptive attribute.
• Also, can say that each sponsorship
is monitored by at most one employee.
21
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
Outline
Database Design and ER Diagram
Entities, Attributes, & Entity set
Relationships and relationship Set
Additional Features of the ER Model
Conceptual design with the ER Model
Case Study: Internet Shop
22
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
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.
23
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
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 (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).
24
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
Entity vs. Attribute (Contd.)
Works_In4 does not from to
name dname
allow an employee to ssn lot did budget
work in a department
for two or more periods. Employees Works_In4 Departments
this relationship.
Accomplished by from Duration to
introducing new entity set,
Duration.
25
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
Entity vs. Relationship (1/2)
since dbudget
name dname
ssn lot did budget
26
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
Entity vs. Relationship (2/2)
Fixing the problem:
Create a new entity and assign “dbudget” to the entity rather than the
realtionship.
Eliminates the redundancy
Clear association of “dbudget” to all
name
ssn lot
since dname
Employees did budget
Manages2 Departments
ISA
Managers dbudget
29
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
name
ssn lot
Aggregation vs Employees
started_on since
dname
pid pbudget did budget
31
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
Case Study: B&N Hiring Dudes DB Co.
Requirements:
Books focusing on horse racing
Customers to browse catalog over the internet
Order books over the internet
Order contains: ISBN number, and quantity.
Shipment of whole order in one shot. If not all books in
stock, then additional copies made.
For each book, catalog contains: ISBN, title, author, purchase
price, sales price, and year book was published.
Records for customers are maintained: names and
addresses.
New customers have to open an account first, and get CID.
Payment by credit card
32
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
Case Study (cont-d): Conceptual
Schema
Order_date Ship_Date
qty
Author cardnum
Qty_in_stock
price
title
cname
isbn Yr_publish cid address
How to handle?:
1. Same books in same day (qty), 2. diff books in same day (isbn)
3. Same books on different days problem (order = cid/isbn).
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
33
Congratulations!!!!
34
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
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.
35
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
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
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, 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.
36
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke