SADM 5/ed – CASE STUDY 4 – Milestone 3: Data Modeling
Page 3-1
MILESTONE 3 – DATA MODELING
 Synopsis
he requirements analysis phase answers the question, “What does the user
need and want from a new system?” The requirements analysis phase is
critical to the success of any new information system. In this milestone, you
need to identify what information systems requirements need to be defined
from the system users’ perspectives, and draw graphical, logical, models to document
the data requirements for a new and improved system.
T
Data modeling is a technique for organizing and documenting a system’s data. Data
modeling is sometimes called database modeling because a data model is usually
implemented as a database. Data are viewed as a resource to be shared by as many
processes as possible. As a result, data must be organized in a way that is flexible
and adaptable to unanticipated business requirements – and that is the purpose of
data modeling.
In this milestone you will first discover those entities in the system that are or might
be described by data. With each entity you identify, you will define it in respect to
the business. Then, you will construct a Context Data Model that graphically depicts
each of the entities and the relationships they have with each other. Next, you will
refine the context data model to include primary and foreign keys. The resulting
model is called a Key-Based Data Model. Finally, you refine the key-based data
model to include any hierarchies and attributes, and this model is referred to as the
Fully Attributed Data Model.
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 5ed
by J. L. Whitten, L. D. Bentley, & K. C. Dittman
Copyright Irwin/McGraw-Hill 2001
SADM 5/ed – CASE STUDY 4 – Milestone 3: Data Modeling
Page 3-2
 Objectives
After completing this milestone, you should be able to:
 Understand and perform the techniques for entity discovery.
 Define each entity with respect to the business, and complete an entity/definition
matrix.
 Perform the necessary data modeling techniques to organize, and document the
data requirements for the proposed system.
 Construct the Context, Key-Based, and Fully-Attributed data models.
 Prerequisites
Before starting this milestone the following topics should be covered:
1. Data modeling – Chapter 7
2. Milestone 2 Solution
 Assignment
Now that you have studied the current system and analyzed some of its problems and
opportunities, plus gained approval to proceed, you can now start to identify the
business data requirements and graphically model them. In this assignment you will
use your results of the previous Milestone and transcripts of an interview with Julius
Marx, IT Director of Huxley College. The results of this activity will identify the
business data requirements for the proposed system.
Exhibit 3.1 is a copy of the transcript of the interview. Refer to the transcript, sample
forms, and results from Milestones 1 and 2 for the information necessary to complete
the activities.
 Activities
1. Complete an Entity/Definition Matrix. Analyze each of the forms referenced by
the user interview, plus any comments made by Julius Marx. Make assumptions
where necessary.
2. Prepare a Context Data Model.
3. Prepare a Key-Based Data Model.
4. Prepare a Fully-Attributed Data Model including any generalization hierarchies.
Add the data attributes for each entity.
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 5ed
by J. L. Whitten, L. D. Bentley, & K. C. Dittman
Copyright Irwin/McGraw-Hill 2001
SADM 5/ed – CASE STUDY 4 – Milestone 3: Data Modeling
Page 3-3
Deliverable format and software to be used are according to your instructor’s
specifications. Deliverables should be neatly packaged in a binder, separated with a
tab divider labeled “Milestone 3.”
References:
Milestone 2 Solution
Provided by your instructor
Transcripts of Interview with Julius Marx and Accompanying Sample
Forms and Report
Exhibits 3.1-3.5
Templates
See online learning center web site for the textbook.
Deliverables:
Entity Definition Matrix:
Due: __/__/__
Time:_______
Context Data Model:
Due: __/__/__
Time:_______
Key-Based Data Model:
Due: __/__/__
Time:_______
Fully-Attributed Data Model:
Due: __/__/__
Time:_______
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 5ed
by J. L. Whitten, L. D. Bentley, & K. C. Dittman
Copyright Irwin/McGraw-Hill 2001
SADM 5/ed – CASE STUDY 4 – Milestone 3: Data Modeling
Page 3-4
ADVANCED OPTION
For the advanced option, assume that the proposed system must also handle the
entry of Purchase Orders. Your instructor will specify additional system
requirements for the Purchase Order part of the system. Modify your initial Entity
Definition Matrix and Fully-Attributed Data Model to be able to handle this
system requirement.
Entity Definition Matrix:
Due: __/__/__
Time:_______
Fully-Attributed Data Model:
Due: __/__/__
Time:_______
Milestone’s Point Value:
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 5ed
by J. L. Whitten, L. D. Bentley, & K. C. Dittman
_______
Copyright Irwin/McGraw-Hill 2001
SADM 5/ed – CASE STUDY 4 – Milestone 3: Data Modeling
Page: 3-5
The following is a copy of the transcript of an interview between Mr. Julius Marx, IT
Director, and Frank Baravelli, the systems analyst assigned to the project. The goal
of this interview was to obtain sample forms used for processing employee
information and to ask questions about them to discover data entities of the system.
Exhibit 3.1
Scene: Frank Baravelli, systems
analyst, is meeting with Julius
Marx, IT Director for Huxley
College, at Mr. Marx’s office.
Mr. Baravelli scheduled the
interview to obtain instructions
and sample forms for designing
the data structure for the IT
Tracker system.
Julius: Good Morning Frank! Well, are
you ready to begin the design for
IT Tracker?
Frank: Yes, sir. Although suddenly it
seems like a big job.
Julius: It is a big job. But I’ll be glad to
help you all I can.
Frank: Thanks. I thought I should start
with designing the data.
Julius: You requested some samples of
the forms we use now. Here are
copies of the main three forms
that I think will be relevant to
you.
Frank: Great! That will be a big help.
Julius: The first form is the PC
Configuration Sheet [Exhibit
3.2]. This is just a spreadsheet
that we currently use to keep
track of equipment in each PC.
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 5ed
by J. L. Whitten, L. D. Bentley, & K. C. Dittman
Frank: OK. Are these columns all the
pieces of information that need
to be tracked for each PC?
Julius: Well, I don’t think this whole
format works very well. I can
remember several years ago
when we had to add a column
for CD ROM drive when those
started getting popular. Today, I
think we need a column for
mouse as we are getting all kinds
of specialty mice and other
pointing devices on the market.
We may need a column for web
cam, also. But the point I want to
get at is that we don’t want to be
restructuring the data every time
there’s a technology shift. I want
you to design it with more
flexibility.
Frank: I see. We ought to move away
from having these specific
components as fields.
Julius: Right. Also, we have a problem
with this format in that it doesn’t
allow for multiple hard drives or
multiple CD ROMs. That
happens pretty often.
Frank: Any other problems with this
form?
Copyright Irwin/McGraw-Hill 2001
SADM 5/ed – CASE STUDY 4 – Milestone 3: Data Modeling
Julius: A couple things. Let’s say I
replace the hard drive. I know
what the machine now has. But I
don’t know what it had before,
how long that component was in
service, a history of
replacements for the PC.
Frank: So you want a maintenance
history of each PC.
Julius: From a component standpoint, I
just need to see a list of all
components that have ever been
in the PC, when those
components were added, and
when they were removed.
Frank: So those dates need to be tracked
for each installed component.
What else needs to be tracked
for each installed component?
Julius: For things such as RAM, I
probably need to track a
quantity, too. For other items, I
should track the Serial Number
of the component.
Frank: OK. Given the changes you
want, I think we ought to define
the word component.
Julius: Good question. You have to
think about how we first buy and
later upgrade the equipment.
Sometimes we buy a complete
system with CPU, monitor,
mouse, keyboard – the works in
one package. In those cases there
isn’t anything to enter into some
of the columns.
Page: 3-6
Frank: So a complete system might be a
single component?
Julius: Right. But then later we will
upgrade a hard drive, add RAM,
replace a bad CD drive, etc. A
replacement NIC can be a
component. A PC we build from
individual parts would have lots
of components.
Frank: So, if everything is a component,
is there any information that
pertains to the PC in general?
Julius: Yes. First of all, this PC
Configuration Sheet doesn’t
show it, but we need to track
whether we are talking about a
PC or a printer or some other
kind of technology equipment.
Second, each piece of equipment
is given a name. The names are
printed on labels and affixed to
the machines as identifiers.
Third, everything has an “In
Service Date.” Finally, I want to
track the department that
equipment is assigned to.
Frank: This sheet tracks the user, not
the department.
Julius: Tracking the user doesn’t work.
We don’t get informed of
personnel turnover. So we go
into an office months later and
can’t find the people we have on
file. But we handle moving the
PCs ourselves, so we know
when they change departments.
Frank: Are machines ever renamed?
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 5ed
by J. L. Whitten, L. D. Bentley, & K. C. Dittman
Copyright Irwin/McGraw-Hill 2001
SADM 5/ed – CASE STUDY 4 – Milestone 3: Data Modeling
Julius: Yes. Some secretary will name
her PC Lemondrop or
something, and then it will go to
some manly guy who wants it
renamed Corvette or Terminator.
Frank: How long do the names get?
Julius: I think the longest we have is 15
letters. It’s not a perfect ID. You
may want to add a numeric ID.
But I want to keep the names.
Users would rather call in with a
problem on Rambo than a
problem on 153934.
Frank: Speaking of that, let’s talk about
handling service requests. That’s
what this Service Request does,
correct? [Exhibit 3.3]
Julius: Yes. This actually works pretty
well. But I’d like to see it more
automated. I would like a system
where the user could submit the
request electronically. Then I
could look at requests that have
come in, and assign a Tech. I’d
like the Techs to be able to add
their work info (the bottom part
of the form) either in the field or
when they get back. Then we’d
have a record of everything done
on that problem and a history.
Frank: OK. That seems pretty
straightforward. But what about
this Purchase Order? [Exhibit
3.4] We’re not keeping POs in
our system, correct?
Julius: Our mainframe accounting
system will handle all the entry
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 5ed
by J. L. Whitten, L. D. Bentley, & K. C. Dittman
Page: 3-7
and edit of purchases. But for
warranty purposes, we need to
be able to tie each component
we install to a specific PO.
Frank: Will we be linking to that data
on the mainframe or pulling
down a copy of the data?
Julius: E. H. Calvert, the VP of Finance,
doesn’t want us making any live
connections to the mainframe.
It’s pretty old and doesn’t need
to be taxed anymore. But we can
write some SQL to pull out the
data we need at the end of each
business day, and store it in our
own tables. Then we can query
that information all we want.
Frank: I assume that means I am limited
to the fields available in the
mainframe PO system.
Julius: To a large extent that is true. But
with SQL we can combine fields,
separate fields, and generally
reformat the data about any way
we want.
Frank: So what should tie to what?
Julius: That’s what you’ll have to think
through. But let me tell you what
I want to accomplish. Each
installed component on a PC
should tie back to an individual
line on a PO. That way I can
look up the order related to each
installed component.
Frank: So if you have a PC with a set of
Bose speakers that go bad, you
Copyright Irwin/McGraw-Hill 2001
SADM 5/ed – CASE STUDY 4 – Milestone 3: Data Modeling
should be able to trace those
speakers back to that second line
on PO 2001-10 and figure out
when they were purchased and
who from.
Julius: Right. That would allow me to
check out the warranty situation.
That should also allow me to run
a list of PO items that have never
been installed anywhere.
Frank: How would that help you?
Julius: The uninstalled items would
either be in inventory or indicate
a problem in the data. Either
way, I want to know about it.
When a Tech finds a bad NIC, he
or she ought to be able to see if
we have any in inventory.
Frank: Wow. I can really see how this
system could be helpful.
Page: 3-8
me look at trends. There is no
end to the management we can
get out of this system – provided
you design the data correctly. It
all comes down to data design.
Frank: Now I feel more nervous than
ever.
Julius: Don’t be. You aren’t in this
alone. We have a steering
committee and users who will
look over your design. We’ll get
it right. Do you have any other
questions for now?
Frank: I don’t believe so. Thanks for
your time, Mr. Marx. You have
been a big help.
Julius: Thank you. Call me if you need
anything else. Goodbye.
Frank: Goodbye.
Julius: Yes, we can use it to help the
Techs, help the users, and help
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 5ed
by J. L. Whitten, L. D. Bentley, & K. C. Dittman
Copyright Irwin/McGraw-Hill 2001
SADM 5/ed – CASE STUDY 4 – Milestone 3: Data Modeling
Page: 3-9
Exhibit 3.2
PC Configuration Sheet
Machine name
Processor
Mertz
Pentium III 700
RAM
128 RTL 8139A
NIC
Hard Drive
Maxtor 10Gb
CD Rom Drive
Asus 50X
User
Child
Pentium III 700
16Mb AtiRage
Maxtor 60gb.
2/Asus 50X
AJM
Rambo
Pentium III 700
128 RTL 8139A
32Mb. Savage 4
Maxtor 10Gb
Asus 50X
Isiah A.
Gilligan
Pentium III 700
128 AEF 360 TX Fast PCI
32Mb Diamond Viper
Maxtor 60gb.
Asus 50X
JB Richland
Moll
Pentium III 700
128 AEF - 360 TX Fast PCI
8 Mb Rage Pro AGP
Maxtor 30 Gb
Creative 52X
Laura
Poe
Pentium III 700
96 Realtek RTL 8029 PCI
8Mb Rage IIC AGP
IBM 13 Gb.
Creative 52X
Mark
Bradbury
Pentium III 700
128 RTL 8139A
8 Mb Rage Pro AGP
Maxtor 10Gb
Asus 50X
Vanessa
Marlow
Pentium III 700
128 Soho Fast Ethernet
32 Mb 3dfx Voodoo 4
Maxtor 20 Gb
Asus 50X
DeSoto
Pentium II 233
64 3 Com Fast Etherlink XL
1 Mb SiSV
Western Dig. 4Gb
Mitsumi 32X
Princeton
Pentium II 350
64 AEF 360 TX Fast PCI
8Mb Rage IIC AGP
Seagate 6Gb
Creative infra 60
Frag
Pentium II 350
64 AEF - 360 TX Family PCI Fast
4 Mb Rage IIC AGP
Maxtor 9Gb
Acer 40X
Jennifer
Hoser
Pentium II 350
64 3 Com Fast Etherlink XL
Creative 52X
Lisa
Rose
Pentium II 350
64 3 Com Fast Etherlink XL
4 Mb Rage IIC PCI
Maxtor 6 Gb
Creative 24X
Norma
Troi
Pentium II 350
64 Realtek RTL 8029 PCI
Matrox Millennium 4Mb
Seagate 6Gb
Creative infra 60
Rebecca
Nimitz
Pentium II 400
64 3 Com Fast Etherlink XL
8Mb Rage IIC AGP
Maxtor 9Gb
Creative 48X
Mary
Beetle
Pentium II 450
128 AEF 360 TX Fast PCI
8Mb Rage IIC AGP
IBM 13 Gb.
Creative 48X
Beth C.
Reverb
Pentium II 450
128 AEF 360 TX Fast PCI
32Mb Rage Pro
IBM 20 Gb
Creative 52X
Lab
Reliant
Pentium II 450
64 3 Com Fast Etherlink XL
8Mb Rage Pro AGP
IBM 13 Gb.
Creative 52X
Lab
Tiger
Pentium II 450
64 AEF - 360 TX Fast PCI
32Mb. Viper 770
IBM 10Gb.
Creative 52X
Lab
Goober
Pentium II 450
64 AEF - 360 TX Fast PCI
32Mb. Creative Blaster
Maxtor 4Gb.
Creative 48X
Lab
Lamer
Pentium II 450
128 3 Com Fast Etherlink XL PCI
8Mb Rage IIC AGP
Seagate 13Gb.
Asus 50X
Lab
Bug
Pentium II 450
128 3 Com Fast Etherlink XL
16Mb AtiRage
IBM 14Gb.
Creative 52X
Lab
OkieDokie
Pentium II 450
64 Realtek RTL 8029 PCI
8Mb Rage IIC
Maxtor 9Gb
Creative 52X
CIS
Enola
Pentium II 450
128 3 Com Fast Etherlink XL PCI
4 Mb Rage IIC AGP
IBM 9Gb.
Creative 52X
CIS
Wplfman
Pentium II 450
128 3 Com Fast Etherlink XL PCI
16Mb AtiRage
Horsefeathers
Pentium II 450
Encroachment
Pentium II 500
128 AEF 360 TX Fast PCI
16Mb AtiRage
Coyote
Pentium II 550
128 AEF 360 TX Fast PCI
Swordfish
Pentium II 550
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 5ed
by J. L. Whitten, L. D. Bentley, & K. C. Dittman
96 3 Com Fast Etherlink XL
Video Card
32 Mb Savage 4
64 AEF - 360 TX Fast PCI
64 AEF - 360 TX Fast PCI
Rich
CIS
16Mb AtiRage
Creative 52X
Sonya
Western Dig. 20Gb
Asus 50X
Byron
4 Mb Rage IIC PCI
IBM 10Gb.
Creative 52X
Stephanee
4 Mb Rage IIC AGP
Maxtor 10Gb
Creative 52X
Teri
Copyright Irwin/McGraw-Hill 2001
SADM 5/ed – CASE STUDY 4 – Milestone 3: Data Modeling
Page: 3-10
Exhibit 3.3
Service Request
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 5ed
by J. L. Whitten, L. D. Bentley, & K. C. Dittman
Copyright Irwin/McGraw-Hill 2001
SADM 5/ed – CASE STUDY 4 – Milestone 3: Data Modeling
Page: 3-11
Exhibit 3.4
Purchase Order
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 5ed
by J. L. Whitten, L. D. Bentley, & K. C. Dittman
Copyright Irwin/McGraw-Hill 2001