Chapter 6.
Data Modeling
© Copyright 2011 John Wiley & Sons, Inc. 6-1
Chapter 6 Outline
The Entity Relationship Diagram
(ERD).
- Elements of ERD
- The Data Dictionary and Metadata
Creating an Entity Relationship
Diagram.
Validating an ERD.
© Copyright 2011 John Wiley & Sons, Inc. 6-2
INTRODUCTION
In this chapter, we discuss how the data are
organized and presented.
A data model is a formal way of representing the
data that are used and created by a business system.
During analysis (this Chapter), analysts draw a
Logical data model which shows the logical
organization of data without indicating how it is
stored, created, or manipulated.
© Copyright 2011 John Wiley & Sons, Inc. 6-3
THE ENTITY-RELATIONSHIP DIAGRAM
(ERD)
An entity-relationship diagram (ERD) is a
picture showing the information that is
created, stored, and used by a business
system.
Entities lists similar kinds of information
Lines drawn between entities represent
relationships among the data.
Special symbols communicate high-level
business rules.
© Copyright 2011 John Wiley & Sons, Inc. 6-4
Reading an Entity Relationship
Diagram
© Copyright 2011 John Wiley & Sons, Inc. 6-5
Elements of an Entity Relationship
Diagram
© Copyright 2011 John Wiley & Sons, Inc. 6-6
Entity
The entity is the basic building block for
a data model. It is a person, place,
event, or thing about which data is
collected.
Entities represent something for which
there exist multiple instances, or
occurrences.
- E.g., John Smith could be an instance of the
customer entity.
© Copyright 2011 John Wiley & Sons, Inc. 6-7
(cont’d)
© Copyright 2011 John Wiley & Sons, Inc. 6-8
Attributes
An attribute is some type of information that
is captured about an entity.
Attributes are nouns that are listed with an
entity.
One or more attributes can serve as the entity
identifier - the attribute(s) that can uniquely
identify one instance of an entity.
Concatenated identifier - several attributes
are combined to uniquely identify an instance.
© Copyright 2011 John Wiley & Sons, Inc. 6-9
(cont’d)
Choices for Identifiers
© Copyright 2011 John Wiley & Sons, Inc. 6-10
Relationships
Relationships are associations
between entities.
Every relationship has a parent
entity and a child entity.
Relationships should be labeled with
active verbs.
© Copyright 2011 John Wiley & Sons, Inc. 6-11
Cardinality
A relationship has cardinality which is the ratio of
parent instances to child instances.
The 1:1 relationship means that one instance of the
parent entity is associated with one instance of the
child entity.
The 1:N relationship means that a single instance of a
parent entity is associated with many instances of a
child entity.
The M:N relationship means that many instances of a
parent entity can relate to many instances of a child
entity.
© Copyright 2011 John Wiley & Sons, Inc. 6-12
(cont’d)
Example of M:N Relationship
© Copyright 2011 John Wiley & Sons, Inc. 6-13
Modality
A relationship has modality of null or not null,
which refers to whether or not an instance of a
child entity can exist without a related instance in
the parent entity.
Null means that an instance of a child entity can
exist without a related instance in the parent
entity.
Not Null means that an instance of a child entity
can’t exist without a related instance in the
parent entity.
© Copyright 2011 John Wiley & Sons, Inc. 6-14
(cont’d)
Cardinality and modality together gives us four possible combinations:
© Copyright 2011 John Wiley & Sons, Inc. 6-15
© Copyright 2011 John Wiley & Sons, Inc. 6-16
Data dictionary
A data dictionary is a collection of descriptions of the
data objects or items in a data model for the benefit of
programmers and others who need to refer to them.
Identify each object and its relationship to other
objects. This process is called data modeling.
– given a descriptive name
– its relationship is described
– possible predefined values are listed,
– a brief textual description is provided.
This collection can be organized for reference into a
book called a data dictionary.
© Copyright 2011 John Wiley & Sons, Inc. 6-17
Types of Metadata Captured by the Data Dictionary
© Copyright 2011 John Wiley & Sons, Inc. 6-18
CREATING AN ENTITY RELATIONSHIP
DIAGRAM (ERD)
Drawing the ERD is an iterative
process of trial and revision.
The basic steps in building an ERD:
1. Identify the entities;
2. add the appropriate attributes to each entity;
3. draw relationships among entities.
© Copyright 2011 John Wiley & Sons, Inc. 6-19
Step 1: Identify the Entities
The entities should represent the major
categories of information that you need
to store in your system.
If you begin the data model using a use
case, look at the major inputs and
outputs of the use case.
If the process models are available, look
at the data stores, external entities, and
data flows.
© Copyright 2011 John Wiley & Sons, Inc. 6-20
Step 2: Add Attributes and Assign
Identifiers
The information that describes each entity
becomes its attributes.
– Check in the CASE repository of the process model for
details on data flows and data stores.
– Check the data requirements of the requirements
definition.
– Use requirements elicitation techniques (e.g., interview
and document analysis).
One or more of the attributes will become the
entity’s identifier.
© Copyright 2011 John Wiley & Sons, Inc. 6-21
Step3: Identify Relationships
The last step in creating ERDs is to
determine how the entities are
related to each other.
Lines are drawn between the entities
that have relationships.
Each relationship is labeled, and
cardinality and modality are
assigned.
© Copyright 2011 John Wiley & Sons, Inc. 6-22
Advanced Syntax
Three special types of entities:
Independent Entity
– Can exist without the help of another entity.
– The identifiers is created from the entity’s
own attributes.
– Attributes from other entities are not
needed to uniquely identify instances of
these entities.
© Copyright 2011 John Wiley & Sons, Inc. 6-23
(cont’d)
Dependent Entity
– There are situations when a child entity does
require attributes from the parent entity to
uniquely identify an instance.
– In these cases, the child entity is called a
dependent entity, and its identifier consists of
at least one attributes from the parent entity.
© Copyright 2011 John Wiley & Sons, Inc. 6-24
(cont’d)
Intersection Entity
– It exists in order to capture some
information about the relationship
between two other entities.
– Typically, intersection entities are added
to a data model to store information
about two entities sharing an M : N
relationship.
© Copyright 2011 John Wiley & Sons, Inc. 6-25
(cont’d)
There are three steps involved in adding an
intersection entity:
Step 1. Remove the M:N relationship line and
insert a new entity (intersection entity) in
between the two existing ones.
Step 2. Add two 1:N relationships to the
model.
Step 3. Name the intersection entity.
© Copyright 2011 John Wiley & Sons, Inc. 6-26
(cont’d)
Resolving an M:N Relationship
© Copyright 2011 John Wiley & Sons, Inc. 6-27
VALIDATING AN ERD
General design guidelines.
Normalization.
Check the ERD against the process
models to make sure that both
model balance each other.
© Copyright 2011 John Wiley & Sons, Inc. 6-28
Design Guidelines
© Copyright 2011 John Wiley & Sons, Inc. 6-29
Normalization
Normalization is a technique that
can help analysts validate the data
models.
It is a process whereby a series of
rules are applied to a logical data
model to determine how well
formed it is.
© Copyright 2011 John Wiley & Sons, Inc. 6-30
(cont’d)
Normalization Steps
© Copyright 2011 John Wiley & Sons, Inc. 6-31
Sample ER diagram of University
Management System
© Copyright 2011 John Wiley & Sons, Inc. 6-32
Example
In a university, a Student enrolls in
Courses. A student must be assigned
to at least one or more Courses. Each
course is taught by a single Professor.
To maintain instruction quality, a
Professor can deliver only one course
© Copyright 2011 John Wiley & Sons, Inc. 6-33
Step 1) Entity Identification
We have three entities
– Student
– Course
– Professor
© Copyright 2011 John Wiley & Sons, Inc. 6-34
Step 2) Add Attributes and Assign
Identifiers
© Copyright 2011 John Wiley & Sons, Inc. 6-35
Step 3) Identifying relationship
For them problem statement we know
that,
– A student can be assigned multiple courses
– A Professor can deliver only one course
© Copyright 2011 John Wiley & Sons, Inc. 6-36
© Copyright 2011 John Wiley & Sons, Inc. 6-37
Assignment
© Copyright 2011 John Wiley & Sons, Inc. 6-38
SUMMARY
Basic Entity Relationship Diagram Syntax
- Entity describes people, places, or things.
- Attribute is some type of information about the entity.
- Relationship conveys the associations between entities.
Creating an ERD
- Identify the entities.
- Add the attributes to each entity.
- Draw relationships among entities.
Validating an ERD
- Normalization
© Copyright 2011 John Wiley & Sons, Inc. 6-39
Data Flow Diagram
© Copyright 2011 John Wiley & Sons, Inc. 6-40
Models: Logical and Physical
Model – a pictorial representation of reality.
Just as a picture is worth a thousand words, most
models are pictorial representations of reality.
Logical model – a Physical model – a technical
nontechnical pictorial pictorial representation that
representation that depicts depicts what a system is or does
what a system is or does. and how the system is
Synonyms or essential implemented. Synonyms are
model, conceptual model, implementation model and
and business model. technical model.
9-41
What is a Data Flow Diagram?
A data flow diagram (DFD) is a graphical
representation of the movement of data between
external entities, processes and data stores within a
system.
Simply put, DFD’s show how data moves through an
information system.
9-42
External Agents
External agent – an outside person, unit, system, or
organization that interacts with a system. Also
called an external entity.
– External agents define the “boundary” or
scope of a system being modeled.
– As scope changes, external agents can
become processes, and vice versa.
Gane and Sarson shape DeMarco/Yourdon shape
9-43
Data Stores
Data store – stored data intended for later use.
Synonyms are file and database.
– Frequently implemented as a file or database.
– A data store is “data at rest” compared to a data flow
that is “data in motion.”
– Almost always one of the following:
• Persons, Places, Objects etc
Gane and Sarson shape
– Data stores depicted on a DFD store
all instances of data entities
(depicted on an ERD)
DeMarco/Yourdon shape
9-44
Process
Process – work performed by a system in
response to incoming data flows or
conditions. A synonym is transform.
– All information systems include
processes - usually many of them
– Processes respond to business Gane and Sarson shape
events and conditions and transform
data into useful information
– Modeling processes helps us to understand the
interactions with the system's environment, other systems,
and other processes.
– Named with a strong action verb followed by object clause
9-45 describing what the work is performed on/for .
Data Flows & Control Flows
Data flow – data that is input to or output
from a process.
– A data flow is data in motion Data flow name
– A data flow may also be used to represent the
creation, reading, deletion, or updating of
data in a file or database (called a data store).
Composite data flow – a data flow that
consists of other data flows.
Control flow – a condition or nondata
Control flow name
event that triggers a process.
– Used sparingly on DFDs.
9-46
© Copyright 2011 John Wiley & Sons, Inc. 6-47
Simple Data Flow Diagram
9-48
Common Process Errors on DFDs
9-49
Data Flow Packet Concept
Data that should travel together should be shown as
a single data flow, no matter how many physical
documents might be included.
9-50
Data Flows to and from Data Stores
9-51
Rules for Data Flows
A data flow should
never go
unnamed.
In logical
modeling, data
flow names should
describe the data
flow without
describing the
implementation
All data flows must
begin and/or end
at a process.
9-52
Diverging and Converging
Data Flows
Diverging data flow – a data flow that splits into
multiple data flows.
– Indicates data that starts out naturally as one flow, but is
routed to different destinations.
– Also useful to indicate multiple copies of the same output
going to different destinations.
Converging data flow – the merger of multiple data
flows into a single packet.
– Indicates data from multiple sources that can (must) come
together as a single packet for subsequent processing.
9-53
Diverging and Converging
Data Flows
9-54
Process Decomposition
Decomposition – the act of breaking a system into
sub-components. Each level of abstraction reveals
more or less detail.
9-55
Decomposition Diagrams
Decomposition diagram
– a tool used to depict
the decomposition of a
system. Also called
hierarchy chart.
9-56
Level 0 Diagram
Shows all the processes that
comprise the overall system
Shows how information moves from
and to each process
Adds data stores
9-57
Level 1 Diagrams
Shows all the processes that comprise a
single process on the level 0 diagram
Shows how information moves from and
to each of these processes
Shows in more detail the content of
higher level process
Level 1 diagrams may not be needed for
all level 0 processes
9-58
Level 2 Diagrams
Shows all processes that comprise a single
process on the level 1 diagram
Shows how information moves from and to
each of these processes
Level 2 diagrams may not be needed for all
level 1 processes
Correctly numbering each process helps the
user understand where the process fits into
the overall system
9-59
Modern Structured Analysis
(More Commonly Practiced)
1. Draw context DFD to establish initial project scope.
2. Draw functional decomposition diagram to partition the
system into subsystems.
3. Create event-response or use-case list for the system to
define events for which the system must have a response.
4. Draw an event DFD (or event handler) for each event.
5. Merge event DFDs into a system diagram (or, for larger
systems, subsystem diagrams).
6. Draw detailed, primitive DFDs for the more complex event
handlers.
7. Document data flows and processes in data dictionary.
9-60
Structured Analysis Diagram
Progression (1 of 3)
9-61
Structured Analysis Diagram
Progression (2 of 3)
9-62
Structured Analysis Diagram
Progression (3 of 3)
9-63
Context Data Flow Diagram
Context data flow diagram - a process model used
to document the scope for a system. Also called the
environmental model.
1. Think of the system as a "black box."
2. Ask users what business transactions the system must
respond to. These are inputs, and the sources are
external agents.
3. Ask users what responses must be produced by the
system. These are outputs, and the destinations are
external agents.
4. Identify any external data stores, if any.
5. Draw a context diagram.
9-64
Balancing
Balancing - a concept that requires that
data flow diagrams at different levels of
detail reflect consistency and
completeness
– Quality assurance technique
– Requires that if you explode a process to another DFD
to reveal more detail, you must include the same dta
flows and data stores
9-65
System DFD
9-66
System DFD (concluded)
9-67
Exercise: Order food
Draw a Data Flow Diagram (DFD) for “Food Ordering System”
considering the following scenarios:
Customer place an Order. The Order Food process receives the Order,
forwards it to the Kitchen, store it in the Order data store, and store the
updated Inventory details in the Inventory data store. The process also
delivers a Bill to the Customer. Manager can receive Reports through the
Generate Reports process, which takes Inventory details and Orders as
input from the Inventory and Order data store respectively. Manager can
also initiate the Order Inventory process by providing Inventory order. The
process forwards the Inventory order to the Supplier and stores the
updated Inventory details in the Inventory data store.
9-68
© Copyright 2011 John Wiley & Sons, Inc. 6-69
Payroll management system
© Copyright 2011 John Wiley & Sons, Inc. 6-70
Patient Information system
© Copyright 2011 John Wiley & Sons, Inc. 6-71
© Copyright 2011 John Wiley & Sons, Inc. 6-72
Manage Robot
© Copyright 2011 John Wiley & Sons, Inc. 6-73
Manage Robot decomposed
© Copyright 2011 John Wiley & Sons, Inc. 6-74
Here passenger input current location and destination address to set up destination
and estimate fare process and the process send estimate fare to the passenger. The
same process gather map information from Google map and rate from taxi rate data
base.
Class work
i. Draw level 1 DFD where set up destination and estimate fare process is
decomposed into two sub process as get distance and calculate fare. Data of
distance will sent from get distance to calculate fare.
ii. Draw Level 2 DFD for get distance sub process. Decompose get distance in
two sub process as get route and calculate distance. Data of route will sent
from get route to calculate distance.
i. Draw level 1 DFD where set up destination and estimate fare process is decomposed
into two sub process as get distance and calculate fare. Data of distance will sent from
get distance to calculate fare.
Draw Level 2 DFD for get distance sub process. Decompose get distance in two
sub process as get route and calculate distance. Data of route will sent from get
route to calculate distance.
