chapter3 - conceptual design using the entity-relation model

7/28/2019 Chapter3 - Conceptual Design Using the Entity-relation Model

1/27

CONCEPTUAL DESIGN

USING THE

ENTITY-RELATIONSHIP 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


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 /


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


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


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/27

Basic Notations

ENTITY TYPE ( REGULAR )

WEAK ENTITY TYPE

RELATIONSHIP TYPE

WEAK RELATIONSHIP TYPE


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


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


10/27

Types continued...

One-to-one

Many-to-many

One-to-many


11/27

Department

did

dname

budgetsince

Works_inEmployee

ssnname

lot

Reports_To

supervisor Sub-ordinate

E-R 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...


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.


14/27

Department

did

dnamesince

Works_inEmployee

ssnname

lotbudget

Location

capacityaddress

Key Constraints for

Ternary Relationships


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


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.


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.


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


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.


20/27

Works_in Department

did

dnamebudget

from

Employee

ssn

name

lot

toDuration

Entity vs. Attribute continued...


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


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.


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


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.


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.


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


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

chapter3 - conceptual design using the entity-relation model

Documents