Overview of Database Design

™ Conceptual design: (ER Model is used at this stage.)

ƒ What are the entities and relationships in the
The Entity-Relationship Model enterprise?
ƒ What information about these entities and
relationships should we store in the database?
Chapter 2 ƒ 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.

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 1 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 2

name
name
ER Model Basics ssn lot
ER Model Basics (Contd.) ssn lot

Employees Employees
since
name dname
™ Entity: Real-world object distinguishable ssn lot did budget
super- subor-
visor
from other objects. An entity is described dinate

(in DB) using a set of attributes. Employees Works_In Departments

Reports_To

™ Entity Set: A collection of similar entities.

E.g., all employees. ™ Relationship: Association among two or more entities.
ƒ All entities in an entity set have the same set of
E.g., Attishoo works in Pharmacy department.
attributes. (Until we consider ISA hierarchies, ™ Relationship Set: Collection of similar relationships.
anyway!) ƒ An n-ary relationship set R relates n entity sets E1 ... En;
ƒ Each entity set has a key. each relationship in R involves entities e1 E1, ..., en En
ƒ Each attribute has a domain. • Same entity set could participate in different
relationship sets, or in different “roles” in same set.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 3 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 4

Key Constraints name

since
dname Participation Constraints
ssn lot did budget

™ Does every department have a manager?

™ Consider Works_In: ƒ If so, this is a participation constraint: the participation of
Employees Manages Departments
An employee can Departments in Manages is said to be total (vs. partial).
work in many • Every did value in Departments table must appear in a row of
departments; a dept the Manages table (with a non-null ssn value!)
can have many since
employees. name dname
ssn lot did budget
™ In contrast, each
dept has at most Employees Manages Departments
one manager,
according to the Works_In
1-to-1 1-to Many Many-to-1
key constraint on Many-to-Many

Manages.
since
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 5 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 6
 name
ssn lot

Weak Entities ISA (`is a’) Hierarchies Employees

™ A weak entity can be identified uniquely only by considering vAs in C++, or other PLs, hourly_wages hours_worked
ISA
the primary key of another (owner) entity. attributes are inherited. contractid
ƒ Owner entity set and weak entity set must participate in a one-to-
vIf we declare A ISA B, every A
many relationship set (one owner, many weak entities). Hourly_Emps Contract_Emps
entity is also considered to be a B
ƒ Weak entity set must have total participation in this identifying
relationship set. entity.
™ Overlap constraints: Can Joe be an Hourly_Emps as well as
a Contract_Emps entity? (Allowed/disallowed)
name ™ Covering constraints: Does every Employees entity also have
ssn lot
cost pname age to be an Hourly_Emps or a Contract_Emps entity? (Yes/no)
™ Reasons for using ISA:

Policy Dependents
ƒ To add descriptive attributes specific to a subclass.
Employees
ƒ To identify entitities that participate in a relationship.

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 7 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 8

name
ssn lot

Aggregation Employees
Conceptual Design Using the ER Model
™ Used when we have ™ Design choices:
to model a Monitors until
ƒ Should a concept be modeled as an entity or an
relationship
attribute?
involving (entitity
sets and) a started_on since
dname
ƒ Should a concept be modeled as an entity or a
relationship set. pid pbudget did budget relationship?
ƒ Aggregation allows us ƒ Identifying relationships: Binary or ternary?
Projects Sponsors Departments
to treat a relationship Aggregation?
set as an entity set
for purposes of * Aggregation vs. ternary relationship: ™ Constraints in the ER Model:
participation in v Monitors is a distinct relationship, ƒ A lot of data semantics can (and should) be captured.
(other) relationships.
with a descriptive attribute. ƒ But some constraints cannot be captured in ER
v Also, can say that each sponsorship diagrams.
is monitored by at most one employee.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 9 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 10

Entity vs. Attribute Entity vs. Attribute (Contd.)

from to
name dname
™ Should address be an attribute of Employees or an ™ Works_In4 does not ssn lot did budget
allow an employee to
entity (connected to Employees by a relationship)? work in a department Employees Works_In4 Departments
for two or more periods.
™ 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 ™ Similar to the problem of
must be an entity (since attributes cannot be set- wanting to record several
addresses for an employee: name dname
valued). We want to record several ssn lot did budget

• If the structure (city, street, etc.) is important, e.g., we values of the descriptive
Works_In4 Departments
attributes for each instance of Employees
want to retrieve employees in a given city, address this relationship.
must be modeled as an entity (since attribute values Accomplished by
Duration
from to
are atomic). introducing new entity set,
Duration.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 11 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 12
 Entity vs. Relationship Binary vs. Ternary Relationships
name
™ First ER diagram OK if ssn lot pname age
since dbudget
a manager gets a name dname ™ If each policy is Employees Covers Dependents
separate discretionary ssn lot did budget owned by just 1
budget for each dept. employee, and Bad design Policies
Employees Manages2 Departments
™ What if a manager gets each dependent
policyid
a discretionary name is tied to the
cost

budget that covers ssn lot covering policy, name pname age
ssn lot
all managed depts? since dname first diagram is
ƒ Redundancy: dbudget Employees did budget Dependents
Employees
stored for each dept inaccurate.
managed by manager. Manages2 Departments ™ What are the Purchaser
ISA Beneficiary
ƒ Misleading: Suggests additional
dbudget associated with
department-mgr This fixes the constraints in the
Managers dbudget Better design Policies
combination. problem! 2nd diagram?
policyid cost
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 13 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 14

Binary vs. Ternary Relationships (Contd.) Summary of Conceptual Design

™ Previous example illustrated a case when two ™ Conceptual design follows requirements analysis,
binary relationships were better than one ternary ƒ Yields a high-level description of data to be stored
relationship. ™ ER model popular for conceptual design
™ An example in the other direction: a ternary ƒ Constructs are expressive, close to the way people think
relation Contracts relates entity sets Parts, about their applications.
Departments and Suppliers, and has descriptive ™ Basic constructs: entities, relationships, and attributes
attribute qty. No combination of binary
(of entities and relationships).
relationships is an adequate substitute:
ƒ S “can-supply” P, D “needs” P, and D “deals-with” S ™ Some additional constructs: weak entities, ISA
does not imply that D has agreed to buy P from S. hierarchies, and aggregation.
ƒ How do we record qty? ™ Note: There are many variations on ER model.

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 15 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 16

Summary of ER (Contd.) Summary of ER (Contd.)

™ Several kinds of integrity constraints can be expressed ™ ER design is subjective. There are often many ways
in the ER model: key constraints, participation to model a given scenario! Analyzing alternatives
can be tricky, especially for a large enterprise.
constraints, and overlap/covering constraints for ISA
Common choices include:
hierarchies. Some foreign key constraints are also
ƒ Entity vs. attribute, entity vs. relationship, binary or n-
implicit in the definition of a relationship set. ary relationship, whether or not to use ISA hierarchies,
ƒ Some constraints (notably, functional dependencies) cannot be and whether or not to use aggregation.
expressed in the ER model. ™ Ensuring good database design: resulting
ƒ Constraints play an important role in determining the best relational schema should be analyzed and refined
database design for an enterprise. further. FD information and normalization
techniques are especially useful.

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 17 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 18