7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
1/27
CONCEPTUAL DESIGN
USING THE
ENTITY-RELATIONSHIP MODEL
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
2/27
Objectives
After completing this chapter, you will be able to:
Explain the process of designing a database
List the components of an E-R model
Draw E-R diagrams
Design E-R Diagrams with key constraints
Define Aggregation
Describe Conceptual Design using the ER Model
Describe constraints beyond the E-R Model
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
3/27
Overview of Database Design
The database design process comprises the following
steps:
Requirement Analysis :
The database designers interview prospective database users to understand and
document their data requirements. The result of this step is concisely written set of
users requirements. This concept of user defined operations will be applied to the
database and they include both retrievals and updates in soft ware design
Conceptual Design (ER Model is used here)
It is a concise description of the data requirements of the users and includes detailed
descriptions of the entity types, relationships and constraints. They are expressed using
the concepts provided by the high level data model
Logical Design: Identification of data model mapping is done here - RDBMS / DBMS /
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
4/27
E-R Modeling
Conceptual Schema Design Relational Calculus
Formal Language for Relational D/B.
Relational Calculus
Predicate Calculus Domain Calculus
SQL / Tuple Based Query By Examples
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
5/27
Requirements Collection& Analysis
Data Requirements
Functional Requirements Conceptual Design
Logical Design
Physical Design
User Defined Operations
Data Flow Diagrams
Sequence Diagrams, Scenarios
Entity Types, Constraints , Relationships
No Implementation Details.
Ensures Requirements
Meets the DesignData Model Mapping Type of Database is identified
Internal Storage Structures / Access Path / File Organizations
Design Phases
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
6/27
Basic Terms
Entity - is anything that exists and is distinguishable.
Entity Set - a group of similar entities.
Attribute - properties that describe an entity.
Relationship - an association between entities
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
7/27
Basic Notations
ENTITY TYPE ( REGULAR )
WEAK ENTITY TYPE
RELATIONSHIP TYPE
WEAK RELATIONSHIP TYPE
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
8/27
Entity
CREATE TABLE Employees
(ssn CHAR (11),name CHAR (20),
lot INTEGER,
PRIMARY KEY (ssn))
Employee
ssn name lotSSN NAME LOT
123- 22- 3666 Attishoo 48
231- 31- 5368 Smiley 22131- 24- 3650 Smethurst 35
Enti ty Set
Attributes
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
9/27
Types of Relationships
One-to-one: One student is issued only one card (and vice-
versa).
One-to-many (or many-to-one): One student can enroll for
only one course, but one course can be offered to many
students.
Many-to-many: One student can take many tests, and one
test can be taken by many students.
An instance of a relationship set is a set of relationships.
Intuitively, an instance can be thought of as a snapshot of
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
10/27
Types continued...
One-to-one
Many-to-many
One-to-many
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
11/27
Department
did
dname
budgetsince
Works_inEmployee
ssnname
lot
Reports_To
supervisor Sub-ordinate
E-R Model
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
12/27
CREATE TABLE Works_ In(
ssn CHAR (11),
did INTEGER,since DATE,
PRIMARY KEY (ssn, did),
FOREIGN KEY (ssn)
REFERENCES Employees,
FOREIGN KEY (did)REFERENCES Departments)
SSN DID SINCE
123-22-3666 51 1/1/91
123-22-3666 56 3/3/93
231-31-5368 51 2/2/92
Works_ In
E-R Model continued...
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
13/27
Manages
Department
did
dname
budgetsince
Employee
ssn
name
lot
Consider Manages: Each dept has at most one manager, according to the key
constraint on Manages relationship (In contrast, Works_In relationship shows
that an employee can work in many departments and a dept can have many
employees). The arrow from Department to Manages indicates that each
Department entity appears in at most one Manages relationship in any
allowable instance of Manages. Thus given a Department entity, we can
uniquely determine the Manages relationship in which it appears.
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
14/27
Department
did
dnamesince
Works_inEmployee
ssnname
lotbudget
Location
capacityaddress
Key Constraints for
Ternary Relationships
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
15/27
Department
did dname budget
since
ManagesEmployee
ssn
namelot
Works_in
since
A participation constraint between an entity set S and a relationship set
restricts instances of the relationship set by requiring that each entity of S
participate in at least one relationship. Every did value in Department table
must appear in a row of the Manages table (with a non- null ssn value!).
Similarly, every ssn value in Employee table must appear in a row of the
Works_intable.
Hence a weak entity will not have its own key It can be identified
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
16/27
policy Dependent
pname
age
cost
Employee
ssn
name
lot
Hence, a weak entity will not have it s own key. It can be identifieduniquely only by considering the primary key of its owner entity.
Weak entity set must have total participation in this identifying
relationship set.
To indicate that Dependent is a weak entity and policy is its identifying
relationship, we draw both with dark lines.
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
17/27
Employee
ssn name lot
Hourly_Emp
Hrs_worked
Hrly_wages
Contract_Emp
contractidIsA
Reasons for using ISA :
To add descriptive attributes specific to a subclass;
To identify entities that participate in a relationship.
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
18/27
Employee
ssn name lot
monitors
project
pid pbudget Started on
department
did dname budget
sponsors
until
. .monitors this Sponsorship (and not Project or Department). This is
aggregation.
d b h k l h
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
19/27
Works_ In does not allow an employee to work in a
department for two or more periods (why?)
Works_inDepartment
did
dnamebudget
from
Employee
ssn
name
lot to
.descriptive attributes for each instance of Works_in relationship. We can
address this problem by introducing an entity set called Duration, with
attributes from and to.
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
20/27
Works_in Department
did
dnamebudget
from
Employee
ssn
name
lot
toDuration
Entity vs. Attribute continued...
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
21/27
Redundancy of dbudget, which is stored for each dept managed by the
manager.
-- Misleading: suggests dbudget tied to managed dept.
manages Department
did
dname
budget
since
Employee
ssn
name
lot
Dbudget
appointment (such as the discretionary budget) are not repeated for each
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
22/27
managesDepartment
diddname
budget
since
Employee
ssn name lot
DBudget
Mgr_apptAppt num
appointment (such as the discretionary budget) are not repeated for each
department that is included in the appointment now, although there is still
one Manages relationship instance per such Department.
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
23/27
Dependent
pname
age
cost
Employee
ssn
name
lot
covers
Policy
policyid
Suppose we have the following constraint:
Each policy is owned by just 1 employee. =>
Key constraint on Policy would mean policy can only cover 1
dependent!
The key constraints allow us to combine Purchaser with Policy and
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
24/27
Dependent
pnameage
cost
Employee
ssn name lot
Beneficiary
Policypolicyid
Better Design
purchaser
The key constraints allow us to combine Purchaser with Policy and
Beneficiary with Dependent.
Participation constraints lead to NOT NULL constraints.
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
25/27
Binary vs. Ternary Relationships
Some constraints cannot be captured in ER diagrams:
=> Functional dependencies :
For example, a department cant order twodistinct parts from the same supplier.
=> Inclusion dependencies :
For example, at least one person must report toeach manager.
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
26/27
DEPARTMENT
DEPT_EMP
EMPLOYEE
EMP_DEP
DEPENDENT
PROJ_
WORK
PROJ_MGR
PROJECT
SUPPLIER
SUPP_PART_PROJ
PART
PART_STRUCTURE
SUPP_PART
M
M
M
M
M
M
M
M
M M
M
M
1
1 1
E-R Diagram
7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model
27/27
Summary
You now should be able to:
Explain the process of designing a database
List the components of an E-R model
Draw E-R diagrams
Design E-R Diagrams with key constraints
Define Aggregation
Describe Conceptual Design using the ER Model
Describe constraints beyond the E-R Model