Data Modeling

using Entity Relationship Diagramming (ERD)

ERD
Planning Use Cases. DFDs. Analysis ERDs. Working toward an actual information system.

Design

Implementation

Users

Use Cases
DFDs

ERDs

Information System

ERD
Planning Use Cases. DFDs. Analysis ERDs. Working toward an actual information system. Physical DFDs and ERDs go here.

Design

Implementation

Items in an ERD
Entity
* Attribute (identifier) Attribute

Relationship

Items in an ERD
Entity
* Attribute (identifier) Attribute

Relationship

Each occurrence of an Entity is 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>.

1:1
Dept. Manager contains Dept.

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)

1:M
Dept. Manager manages Dept. Employee

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)

M:M
Dept. Projects works on Dept. Employee

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

1
Dept. Manager contains Dept.

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

0
Dept. Manager manages Dept. Employee

The Modality 0 symbol

Both
Dept. Projects works on Dept. Employee

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 Dont 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 ERDs 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

Course Offering Changes 1 Course Offering List Maintain department course offerings Course Offering Updates Course enrollment request Available courses

Available course request

2 Available courses

Course Offerings

Maintain student enrollments

Course enrollment
Student schedule

Students

D2 Dept Staff

Course Offerings Course information

Student schedule Enrollments Fee Payment History

D3

Student Enrollment Report Request Student Enrollment Report

3
Course Enrollment Reports Enrollment information D1 Fees

Registration ERD
Course Offering Dept. # * Course # Course name Hours Credit Max. size Number enrolled
includes

Enrollment

* Student ID Dept # Course # Hours credit

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 AREIs 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 AREIs 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

Sales Contract D2 Maintain house seller information Sales Contracts

1 Sales Contract

House information

Sellers

House information

House information D1 Multiple Listing Services File D3 Offered Houses

House information

2 House information request Buyer information form Generate requested report

House information

Buyers

Buyer information D4 Buyers

House information

AREI ERD
Sales Contract offers * Seller name Address Phone Listing date Listing term * Seller name Address Style Size Price Offered House shown * Name Address Phone Preferred style Preferred size Price limit Buyer