Data Modelingusing Entity Relationship Diagramming (ERD)

ERD

Planning

Analysis

Design

Implementation

Use Cases.DFDs.

ERDs.“Working toward anactual informationsystem”.

UsersUse

Cases

DFDs

ERDs

Information System

ERD

Planning

Analysis

Design

Implementation

Use Cases.DFDs.

ERDs.“Working toward anactual informationsystem”.

Physical DFDs and ERDsgo here.

Items in an ERD

RelationshipEntity

* Attribute (identifier)Attribute

Items in an ERD

RelationshipEntity

* Attribute (identifier)Attribute

Each occurrence of an Entityis an “instance”.

Cardinality Cardinality refers to the number of times

instances in one entity can be related to instances in another entity One instance in an entity refers to one and only one

instance in the related entity (1:1)

Cardinality I find it helpful to use this sentence:

A single <instance> <relationship> in at most <either 1 or many> <entity>.

Dept. Manager Dept.

1:1

contains

Cardinality symbols

Cardinality Cardinality refers to the number of times

instances in one entity can be related to instances in another entity One instance in an entity refers to one and only one

instance in the related entity (1:1) One instance in an entity refers to one or more

instances in the related entity (1:M)

Dept. Manager Dept. Employee

1:M

manages

The “Many” Cardinality symbol

Cardinality Cardinality refers to the number of times

instances in one entity can be related to instances in another entity One instance in an entity refers to one and only one

instance in the related entity (1:1) One instance in an entity refers to one or more

instances in the related entity (1:M) One or more instances in an entity refer to one or more

instances in the related entity (M:M)

Dept. Projects Dept. Employee

M:M

works on

Modality Modality refers to the minimum number of

times that an instance in one entity can be related to an instance in another entity One means that an instance in the related entity must

exist for an instance in another entity to be valid

Modality I find it helpful to use this sentence:

A single <instance> <relationship> in at least <either 0 or 1> <entity>.

Dept. Manager Dept.

1

contains

Modality “1” symbols

Modality Modality refers to the minimum number of

times that an instance in one entity can be related to an instance in another entity One means that an instance in the related entity must

exist for an instance in another entity to be valid Zero means that no instance in the related entity is

necessary for an instance in another entity to be valid

Dept. Manager Dept. Employee

0

manages

The Modality “0” symbol

Dept. Projects Dept. Employee

Both

works on

Steps in Building ERDs Identify the entities Add appropriate attributes for each entity Draw the relationships that connect

associated entities

ERD Building Tips Data stores of the DFD should correspond

to entities Only include entities with more than one

instance of information Don’t include entities associated with

implementation of the system, not the system itself

Balancing ERDs with DFDs All analysis activities are interrelated Process models contain two data components

Data flows and data stores The DFD data components need to balance the ERD’s data

stores (entities) and data elements (attributes) Many CASE tools provide features to check for imbalance Check that all data stores and elements correspond between

models Do not follow thoughtlessly -- check that the models make

sense!

Recall: on-line university registration (from Use Case & DFD examples)

The system should enable the staff of each academic department to examine the course offered by their department, add and remove course, and change the information about them (e.g., the maximum number of students). It should permit students to examine currently available courses, add and drop courses to and from their schedules, and examine the course for which they are enrolled. Department staff should be able to print a variety of reports about the courses and the students enrolled in them. They system should ensure that no student takes too many course and that students who have any unpaid fees are not permitted to register. (Assume that a fees data store is maintained by the university's financial office that the registration system accesses but does not change.)

Level 0 DFD: Registration

DeptStaff

1

Maintaindepartmentcourseofferings

2

Maintainstudentenrollments

3

CourseEnrollmentReports

Course OfferingChanges

CourseOfferings

Availablecourses

D1 Fees

D2 Course Offerings

D3 EnrollmentsCourseinformation

Student EnrollmentReport Request

StudentEnrollmentReport

Enrollmentinformation

StudentsCourseOfferingUpdates

Course OfferingList

Fee PaymentHistory

Availablecourse request

Available courses

Availablecourses

Course enrollment

Student schedule

Studentschedule

Courseenrollmentrequest

CourseOffering

Dept. #* Course #Course nameHours CreditMax. sizeNumber enrolled

Enrollment

* Student IDDept #Course #Hours credit

includes

Registration ERD

Recall: real estate (from Use Case & DFD examples)

A Real Estate Inc. (AREI) sells houses. People who want to sell their houses sign a contract with AREI and provide information on their house. This information is kept in a database by AREI and a subset of this information is sent to the citywide multiple-listing service used by all real estate agents. AREI works with two types of potential buyers. Some buyers have an interest in one specific house. In this case, AREI prints information from its database, which the real estate agent uses to help show the house to the buyer (a process beyond the scope of the system to be modeled). Other buyers seek AREI’s advice in finding a house that meets their needs. In this case, the buyer completes a buyer information form that is entered into a buyer database, and AREI real estate agents use its information to search AREI’s database and the multiple-listing service for houses that meet their needs. The results of these searches are printed and used to help the real estate agent show houses to the buyer.

Level 0 DFD: AREI

Sellers

Maintainhousesellerinformation

D2 Sales Contracts

Houseinformation

Generaterequestedreport

1

2

Sales Contract

D3 Offered Houses

House information

Buyer information form

D1Multiple ListingServices File

House information

SalesContract

House information

House information

House information

Buyers

House information request

D4 Buyers

Buyerinformation

SalesContract

* Seller nameAddressPhoneListing dateListing term

OfferedHouse

* Seller nameAddressStyleSizePrice

Buyer

* NameAddressPhonePreferred stylePreferred sizePrice limit

offers shown

AREI ERD