Data Modeling using Entity Relationship Diagramming (ERD)

ERD Planning Use Cases. DFDs. ERDs. “Working toward an Analysis actual information system”. Analysis Design Implementation

Use Cases Users DFDs ERDs Information System

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

Items in an ERD Entity Relationship * Attribute (identifier) Attribute

Items in an ERD Entity Relationship Each occurrence of an Entity * Attribute (identifier) Attribute 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 Dept. 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)

1:M Dept. Manager Dept. Employee 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)

M:M Dept. Projects Dept. Employee 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>.

1 Dept. Manager Dept. 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 manages The Modality “0” symbol

Both Dept. Projects Dept. Employee 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 Course Offering Changes 1 Maintain department course offerings Available course request Available courses Available courses Course Offering List 2 Maintain student enrollments Students Available courses Course enrollment Course Offering Updates Course Offerings Student schedule Course enrollment request D2 Course Offerings Dept Staff Student schedule Course information D3 Enrollments Fee Payment History Student Enrollment Report Request 3 Course Enrollment Reports D1 Fees Enrollment information Student Enrollment Report

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

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 Maintain house seller information D2 Sales Contracts House Generate requested report 1 2 Sales Contract D3 Offered Houses House information Buyer information form D1 Multiple Listing Services File Sales Contract Buyers House information request D4 Buyer

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