SADM 6/ed – Case Study 1 CRS – Milestone 4: Solution
Page: 4-1
MILESTONE 4 – DATA MODELING
 Activity 1 – Entity/Definition Matrix
he entities in the following matrix were identified by analyzing the forms provided in Milestone
4. This list and the following diagrams are based on the author’s assumptions. In some cases
liberties have been taken to add items that may aid in clarification or simplification. If you, the
instructor, choose to do your own solution, it may be different, depending on your interpretation
of the forms provided. In most activities explanations for why things were done as they were have been
provided to aid in your understanding of the solution.
T
The following tables contain the attributes identified from each form and the interview.
PC Configuration Sheet:
Machine Name
Client
Component
Date Installed
Date Removed
Quantity
User
Time and Billing Spreadsheet:
Date
Client
Begin Time
End Time
Work Type
Description
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 6ed
by J. L. Whitten, L. D. Bentley, & K.C. Dittman
Copyright Irwin/McGraw-Hill 2004
SADM 6/ed – Case Study 1 CRS – Milestone 4: Solution
Page: 4-2
Billing Statement:
Invoice Num
Invoice Date
Client Contact
Client Name
Client Address
Description
Hours
Rate
Misc Amount
Students should be able to identify at least the major entities listed below. Whether or not they identify
the optional entities will depend on how they interpret the user requirements and on their experience
level with database normalization. The following completed matrix is one possible solution.
Entity/Definition Matrix
ENTITY
Client
Equipment
EquipmentComponent
SeviceRequest
WorkRecord
WorkType
Technician
OtherCharge
EquipType
ComponentType
BUSINESS DEFINITION
Major Entities
A billable business entity for whom work is done.
A computer, printer, or other piece of technology equipment that is in use.
A component (anything from a stick of RAM to an entire turn-key system) that
is or has been installed in Equipment.
A request for service on Equipment.
Work done to resolve a SeviceRequest.
A classification of WorkRecord, including the billing rate.
Anyone who performs a WorkRecord.
A charge to be billed a Client other than time-related WorkRecords.
Optional Entities
A classification of Equipment.
A classification of EquipmentComponent.
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 6ed
by J. L. Whitten, L. D. Bentley, & K.C. Dittman
Copyright Irwin/McGraw-Hill 2004
SADM 5/ed – Case Study 1 CRS – Milestone 4: Solution
Page: 4-3
 Activity 2 – Context Data Model
his model should be constructed based on the entities identified in Activity 1. All of the
cardinalities of the major entities can be determined from the interview or the forms. The
student may need to make assumptions on the cardinalities of the optional entities or other
entities the student may include.
T
The following diagram is based on the following assumptions and/or business rules:
 A piece of Equipment is made up of one or more EquipmentComponents that either have
in the past or are now installed.
 Each piece of Equipment is a particular EquipmentType.
 Each piece of Equipment is owned by a particular Client.
 Each EquipmentComponent is a particular ComponentType.
 A piece of Equipment may have zero or more ServiceRequests submitted for it.
ServiceRequests may be submitted that do not deal with equipment.
 Each ServiceRequest will be worked on with zero or more WorkRecords (initially zero but
eventually at least one). Since WorkRecord tracks time and billing not related to
ServiceRequests, WorkRecords can relate to zero or one ServiceRequests.
 Each WorkRecord will be of a specific WorkType.
 Each WorkRecord will be done by a specific Technician.
 Each WorkRecord will be done for a specific Client. A Client can be charged zero or more
WorkRecords.
 OtherCharges will also be billed to a specific Client. A Client can be charged zero or more
OtherCharges.
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 6ed
by J. L. Whitten, L. D. Bentley, & K.C. Dittman
Copyright Irwin/McGraw-Hill 2004
SADM 5/ed – Case Study 1 CRS – Milestone 4: Solution
Page: 4-4
Technician
WorkType
Works
Is a
WorkRecord
Is Charged
OtherCharge
Is Performed On
Is Charged
Requested by
ServiceRequest
has
Equipment
Client
Owns
EquipType
Is a
EquipmentComponent
Contains
Is a
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 6ed
by J. L. Whitten, L. D. Bentley, & K.C. Dittman
ComponentType
Copyright Irwin/McGraw-Hill 2004
SADM 5/ed – Case Study 1 CRS – Milestone 4: Solution
Page: 4-5
 Activity 3 – Key-Based Data Model
his model is constructed by adding the primary keys to the model in Activity 2. The primary
keys are based on how the user uniquely identifies each entity. Make sure students specify
primary keys that uniquely identify the entities as well as use proper names for the keys.
The following diagram illustrates one possible solution.
T





The Equipment entity has EquipNum as the primary key. In the present system, the
computer name acts as a primary identifier. This could be the primary key. However, Jeff
Summers states that the computer name is sometimes changed. Though primary keys can be
changed in most systems, it is not best practice. An EquipNum is a number that could be
generated by the system and stays unchanged forever. As a number it would also consume
less disk space as a foreign key in related tables and would provide for faster joins.
The EquipmentComponent entity has ComponentNum as the primary key. This would also
be a system-generated number.
None of the forms hint at a ClientID. But a long text field such as the client name would
make a poor primary key for Client, consuming extra storage space, slowing down database
operations, and probably requiring extra typing. A numeric ClientID serves better.
While a combination of ClientID and RequestDate might work as primary key for
ServiceRequest, a better solution is ReqNum, which would be a system-generated number.
Similarly, WorkNum is a system-generated key value for the WorkRecord entity and
ChargeNum is a system-generated key value for OtherCharge.
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 6ed
by J. L. Whitten, L. D. Bentley, & K.C. Dittman
Copyright Irwin/McGraw-Hill 2004
SADM 5/ed – Case Study 1 CRS – Milestone 4: Solution
Page: 4-6
Technician
WorkType
Works
TechID
WorkType
Is a
WorkRecord
Is Charged
WorkNum
Is Performed On
OtherCharge
ChargeNum
Is Charged
Requested by
ServiceRequest
ReqNum
has
Equipment
Client
Owns
EquipNum
ClientID
EquipType
Is a
EquipmentComponent
EquipType
Contains
ComponentNum
Is a
ComponentType
ComponentID
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 6ed
by J. L. Whitten, L. D. Bentley, & K.C. Dittman
Copyright Irwin/McGraw-Hill 2004
SADM 5/ed – Case Study 1 CRS – Milestone 4: Solution
Page: 4-7
 Activity 4 – Fully Attributed Data Model
his model should be constructed by adding non-key attributes to the entities in Activity 3.
Since students’ models are not necessarily normalized, attributes could be placed in various
entities. But make sure each non-key attribute exists in only one entity. Students may also
include other attributes based on their interpretations of the users’ needs.
T
The diagram below includes foreign keys, assuming implementation in a relational database.
Subject to interpretation, this diagram is in third normal form, which is the bulk of the assignment
for Milestone 5. If you will be doing Milestone 5 as a separate assignment, you may want to
withhold this solution. An attractive alternative is to have students analyze and critique each other’s
Fully Attributed Data Models in small groups before proceeding to normalization. Another
alternative is to start with this data model for Milestone 5 but add additional requirements, such as
the Milestone 4 Advanced Option and require that students revise the data model accordingly.
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 6ed
by J. L. Whitten, L. D. Bentley, & K.C. Dittman
Copyright Irwin/McGraw-Hill 2004
SADM 5/ed – Case Study 1 CRS – Milestone 4: Solution
Page: 4-8
Technician
WorkType
PK
WorkRecord
WorkType
Is a
Rate
AccountCode
PK
WorkNum
FK4
FK2
FK1
ReqNum
TechID
ClientID
WorkDate
TimeBegin
TimeEnd
WorkType
Description
Is Performed On
FK3
ReqNum
FK1
FK2
ReportDate
ResolutionDate
ProblemDescription
ReportedBy
EquipNum
ClientID
TechID
TechName
Is Charged
OtherCharge
PK
ChargeNum
FK1
ChargeAmount
ChargeDate
Description
ClientID
ServiceRequest
PK
PK
Works
Is Charged
Requested by
Client
has
Equipment
PK
PK
EquipNum
Owns
FK2
FK1
EquipType
EquipName
InserviceDate
ClientID
Is a
ComponentNum
FK1
FK2
EquipNum
ComponentID
Quantity
SerialNum
DateInstalled
DateRemoved
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 6ed
by J. L. Whitten, L. D. Bentley, & K.C. Dittman
ClientName
ContactName
Address
City
State
Zip
Phone
Email
Discount
EquipType
EquipmentComponent
PK
ClientID
PK
EquipType
Contains
ComponentType
Is a
PK
ComponentID
Copyright Irwin/McGraw-Hill 2004
SADM 5/ed – Case Study 1 CRS – Milestone 4: Solution
Page: 4-9
 Advanced Option – Revised Attributed Data Model
There are multiple ways to handle tracking and payment of invoices. In most cases an Invoice entity
should be added that relates to both WorkRecord and OtherCharge as child entities. If you assume
that a client might make multiple payments on a single invoice, you would also need a Payment
entity.
Instructor Notes:
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 6ed
by J. L. Whitten, L. D. Bentley, & K.C. Dittman
Copyright Irwin/McGraw-Hill 2004