Solution Manual for Modern Systems Analysis and Design, 9th Edition, Joseph Valacich Joey F.

Solution Manual for Modern Systems Analysis and

Design, 9th Edition, Joseph Valacich Joey F. George

To download the complete and accurate content document, go to:

https://testbankbell.com/download/solution-manual-for-modern-systems-analysis-and-
design-9th-edition-joseph-valacich-joey-f-george/

Visit TestBankBell.com to get complete for all chapters

Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

Chapter 8
Structuring System Data Requirements

Chapter Overview
Chapter 8 presents a detailed description of the techniques used to structure the data
requirements for an information system application. Entity-relationship (E-R) diagramming,
the most common notation used by practicing systems and data analysts, is emphasized. E-R
diagramming is used, along with process and logic modeling techniques, to develop a
thorough, unambiguous description of system requirements. In addition to the standard
constructs of the E-R model (entities, attributes, and relationships), data-oriented questions
that should be raised during requirements determination are described. This chapter discusses
the modeling of business rules for entity integrity, referential integrity, domains, and
triggering operations using both E-R diagrams and textual constraint statements and
introduces the student to object modeling using class diagrams. The chapter concludes with
an example of conceptual modeling for an Internet-based electronic commerce application.

Instructional Objectives
Specific student learning objectives are included at the beginning of the chapter. From an
instructor’s point of view, the objectives of this chapter are to:

1. Emphasize the importance of understanding organizational data and convince your students that
unless they can represent the data requirements of an application unambiguously in logical terms,
they cannot implement a system that will effectively serve the needs of management.
2. Present the E-R model as a conceptual data model that captures the structure and much (although
not all) of the semantics of data in several front-end stages of the systems development process.
3. Show students how data, process, and logic models represent data requirements, and that
conceptual data models (such as an E-R diagram) provide a more thorough, stable representation
of data than do other types of system structures.
4. Show students, via a Hoosier Burger example, how to match data requirements from data, process,
and logic system models. This example emphasizes the differences between data stores and data
entities yet shows how to reconcile process and data models to ensure each covers all data
requirements (while each represents different semantics about data).
5. Discuss data modeling for Internet-based electronic commerce applications.

1
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

Classroom Ideas

1. This chapter was to be read following Chapters 6 and 7 on process and logic modeling,
respectively. However, many instructors prefer to emphasize data modeling by requiring their
students to first study data modeling then study other modeling techniques. If you choose this
approach, ask your students to skip the “An Example of Conceptual Data Modeling at Hoosier
Burger” and “Internet Development: Conceptual Data Modeling” sections. These sections are
tightly linked to the preceding chapters. You can then have students read these sections after
reading Chapters 6 and 7.
2. This chapter covers topics addressed in most database management courses. Depending on your
curriculum, this chapter may review previously covered material or may be covered (in more
depth) in a subsequent course. Conceptual data modeling is not strictly a database topic and is
essential for thorough systems analysis, thus it is an activity that should not be assigned to only
specialists (database analysts). Although you are strongly encouraged to cover this chapter in your
systems analysis and design course, you should coordinate how you address this topic with those
who teach database courses. This chapter is carefully written for the systems analysis and design
student. First, data modeling is presented as a step of the larger systems development process.
Second, questions to ask users and investigate via other requirements determination techniques
are introduced, again placing data modeling within the whole systems development effort. Finally,
the wording is less technical, and the breadth and depth of coverage has been reduced to make the
material more accessible to those who do not have an extensive database background. This chapter
is an excellent refresher for those who have already studied E-R modeling and will provide a solid
introduction to E-R modeling for those students who will study this topic later in a database course.
3. This is a very detailed chapter, and there are many concepts as well as notations to cover. You
should devote at least two lecture periods to this chapter, and if possible, schedule a third session
that is devoted entirely to working sample exercises with students.
4. It is important to review with students how central a role data modeling and data design play in
systems development. You should discuss Figure 8-2 with your students and show examples of
the types of data models, designs, and code developed in each phase of the systems development
process. Discuss who in the organization is most involved in each of these phases and how end
users may best participate in the process.
5. It is important that students learn what questions to ask during requirements determination.
Learning what questions to ask comes from the experience of developing structured statements
and models, like E-R models, of requirements. Problems and Exercises 57 is a good in-class
exercise. This exercise emphasizes what information should be collected during requirements
determination. Ask your students to work in pairs. One student should play the manager of Pine
Valley Furniture’s order entry department and the other student should play a systems analyst.
Give students 10 minutes to prepare for the interview and 15 to 20 minutes to conduct the
interview. Each team should develop an E-R diagram based on the interview answers. Ask the
teams to present their results and discuss in class why the data models differ among the teams.
This exercise emphasizes the importance of careful interviewing and the need to be impertinent
by seeking out detailed business rules at every point in the interview.
6. Introduce the notation that is used in the chapter for E-R diagrams (Figure 8-5). Provide an
example (and then have students provide examples) for each of the constructs shown in the figure.
7. Contrast the terms “entity type” and “entity instance.” Discuss other examples, such as STUDENT
(with each student in the classroom as an instance). Warn students that the term “entity” is often
2
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

used either way, with the meaning intended to come from the context in which it is used. Have
students come up with and discuss other possible examples. These can be from the book or
examples found elsewhere.
8. Discuss the representation of multivalued attributes and repeating groups in E-R diagrams and
provide several examples. If students are familiar with programming languages that support arrays
and other data structures of repeating data, use this understanding to emphasize the need to
separate conceptual from physical data modeling.
9. Discuss relationships and their different degrees (Figure 8-6). Have your students develop
additional examples (students are quite creative with this type of exercise when paired up in
class!).
10. Introduce the concept and notation of cardinalities in relationships (Figure 8-10). Start with a basic
example in Figure 8-10, and again, have your students develop additional examples.
11. As a general suggestion, you should show (develop step-by-step) many examples of small (two to
three entities) and larger (eight to ten entities) E-R diagrams in class. Develop these from your
own personal experience. Three approaches work well and mixing these is best. One approach is
to give students descriptions of an organization and have them identify entities, attributes, and
relationships (with degrees and cardinalities). You can do this as a group exercise, asking for
volunteers or calling on students in class. The second approach is to show E-R diagrams and ask
factual and interpretive questions about the business depicted in the diagram (such as, how many
faculty advisors a student might have, or would all universities have only one department
associated with each course and why). Yet a third approach is to pair students and have one student
in the pair develop an E-R diagram for an exercise you give them, and then have the other student
in the pair read the diagram to see if it agrees with the description. Once each pair of students
develops a diagram both are satisfied with, have several teams present their diagrams to the class
and discuss differences. You can also have students bring in copies of computer system forms and
reports and develop E-R models for each. Several of the Problems and Exercises can be used for
in-class practice problems, especially Problems and Exercises 48, 52, 53, 54, 55, 60, and 66. If
you have part-time students, or students with prior work experience, several of the Field Exercises
also make excellent class discussions.
12. Unary and ternary relationships can be especially difficult for some students. Present several
examples of each (for unary, for example, a hierarchical organization structure or the relationships
between geographical areas or governmental territories; for ternary, for example, a faculty member
advising students about majors, or a customer buying products through different sales channels).
13. If you have the time, an exciting way for students to better appreciate conceptual data modeling is
to listen to a guest speaker who has developed an enterprise data model for a local organization.
Students are usually amazed by how many entities and relationships exist in any reasonably sized
organization (several dozen entities and relationships are common, and models with a hundred
entities exist). Such a guest can usually discuss: the difficulties in developing this data model;
misunderstandings people had or controversies that existed before the data model was developed;
how the data model is being used to guide the development of many new or redesigned systems;
and the administrative effort necessary to maintain such a data model (as well as many other
topics).
14. Students who study process modeling before data modeling often have difficulties with this
chapter. For instance, students may try to include entities for the sources and sinks from the process
model. You must emphasize that data entities must be described by attributes, and each instance
must have a primary key. Further, there are usually multiple instances. For example, in a data

3
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

model for a retail store, a student might include the store or the store’s manager as a data entity.
Such concepts do not satisfy the definition of a data entity.
15. Have students identify the entities and relationships associated with an Internet-based electronic
commerce application, such as the ordering process for an electronic clothing store. Next, have
your students prepare an E-R diagram for this application.

Answers to Key Terms

Suggested answers are provided below. These answers are presented top-down, left to right.

8.8. Conceptual data model

8.14. Entity-relationship data model (E-R model)
8.15. Entity-relationship diagram (E-R diagram)
8.16. Entity type
8.13. Entity instance
8.2. Attribute
8.5. Candidate key
8.17. Identifier
8.18. Multivalued attribute
8.23. Repeating group
8.22. Relationship
8.9. Degree
8.30. Unary relationship
8.3. Binary relationship
8.27. Ternary relationship
8.6. Cardinality
8.1. Associative entity
8.25. Subtype
8.26. Supertype
8.28. Total specialization rule
8.21. Partial specialization rule
8.11. Disjoint rule
8.20. Overlap rule
8.4. Business rules
8.12. Domain
8.29. Triggering operation (trigger)
8.24. Required attribute
8.19. Optional attribute
8.7. Composite attribute
8.10. Derived attribute

Answers to Review Questions

8.31. Some systems developers believe that a data model is one of the most important parts of the
statement of information system requirements for four reasons: (1) completely representing
data requirements is crucial for the design of databases, programs, computer screens, and
printed reports—critical elements of any information system; (2) data, not processes, are the
most complex aspects of many modern information systems and requires a central role in

4
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

structuring system requirements; 3) the characteristics about data are reasonably permanent,
so designing information systems based on data yields more stable systems with longer lives
(and less maintenance); and (4) structural information about data is essential for automatic
program generation.

8.32. Data modeling performed during information systems planning tends to be less detailed than
in the phases of the development of a system. Further, a data model prepared during planning
covers many systems, but usually shows only entities and relationships, not attributes, and an
entity in a planning data model may represent several entities and relationships in other data
models. The purpose of data modeling during project initiation and planning is to show the
scope of the proposed system in terms of data requirements. Entities, attributes, and
relationships represented are only those needed for the application under study. Data modeling
during the analysis phase adds details and validates the earlier project data model, since
systems analysts have now thoroughly studied specific information requirements. Thus, the
resulting data model is usually more extensive, including more entities, attributes, or
relationships, than earlier data models.

8.33. Data stores, data flows, and even processes all provide information for data modeling. A data
store often represents one or more data entities and their associated attributes. All data in data
flows must either be stored in some entity, be computed from data in entities, or in rare
circumstances pass through the system. The description of a process sheds light on business
rules that must be represented in the data model.

8.34. Although some CASE tools do not support representing ternary relationships but rather force
the analysts to represent the ternary relationship as three binary relationships, this enforced
representation is not semantically correct. A ternary relationship represents the simultaneous
association of three entities (such as a selling relationship links a customer with a product and
salesperson), not three binary relationships (between a sale entity/associative entity and
customer, sale and product, and sale and salesperson). When representing a ternary
relationship as three binary relationships, you make the minimum cardinality 1 for each of the
three entities in their relationships with the associative entity (such as, for each sale there is
exactly one customer and exactly one salesperson and at least one product), but the maximum
cardinality can be 1, many, or a specific value.

8.35. A many-to-many relationship must be modeled as an associative entity when there are
attributes associated with the relationship or when the relationship itself has relationships to
other entities.

8.36. A triggering operation business rule governs the validity of data for insertion, update, and
deletion operations on an entity. A triggering operation controls the integrity of data when
data maintenance events occur. The rule states what condition must be true when the data
maintenance event occurs, and what action is to be taken under this condition.

8.37. One-to-one and many-to-many relationships (associative entities) may have attributes. For
example, a one-to-one unary relationship between employees, married to, may have a Date
Married attribute, and a many-to-many binary relationship between students and courses,
Takes, may have a Grade attribute.

5
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

8.38. An important linkage is that each describes, in different ways, the data requirements of an
information system; these different descriptions must be consistent. For example, rules in a
decision table may correspond to business rules in a data model; attributes in data flows must
be stored in or generated from attributes of data entities; different states on a state-transition
diagram correspond to different values for an attribute, which may then define a domain
business rule for that attribute.

8.39. The degree of a relationship indicates the number of entity types participating in a relationship.
The three most common relationships are unary, binary, and ternary. An employee working
for a department is an example of a binary relationship. A part composed of other parts is an
example of a unary (also known as a recursive) relationship. A customer placing an order with
a salesperson is an example of a ternary relationship.

8.40. An example of a ternary relationship might be that of a car service. A particular driver and car
might be assigned to a particular client. Another possible ternary relationship is that of an
airline pilot, which is assigned to a particular airplane going to a particular place. A third
example might be a baseball manager assigned to a team that is playing games in a season.

8.41. The primary deliverable for the conceptual modeling part of analysis is an E-R diagram,
showing the major categories of data and the business relationships between them. A full set
of entries about data objects to be stored in the project repository is also produced.

8.42. Minimum cardinality refers to the minimum number of instances of entity B that must be
associated with entity A. If the minimum cardinality of B is one, then entity B is a mandatory
participant in the relationship. However, if the minimum cardinality for entity B is zero, then
entity B is an optional participant in the relationship.

8.43. An identifier that meets the criteria set forth in the chapter is an ideal choice. The criteria
include: (1) choosing an attribute that will not change its value over the life of each entity
type, (2) choosing an attribute that for each instance of the entity will have valid values and
will not be null, (3) avoiding intelligent key usage, and (4) substituting surrogate keys for large
composite keys.

8.44. Conceptual data modeling is different when you start with a prepackaged software rather than
a clean sheet for several reasons. First, prepackaged software has defined business processes
that are hard to adjust or change. Second, prepackaged software dictates the capabilities of the
data that is captured and stored in a given system. Taken together, prepackaged software has
predefined models that limit the ability of the data model to be expanded.

8.45.
a. Subtype; supertype:
A subtype is a subgrouping of the entities in an entity type that is meaningful to
the organization and that share common attributes or relationships distinct from
other subgroupings. A supertype is a generic entity type that has a relationship
with one or more subtypes.

b. Total specialization rule; partial specialization rule:

The total specialization rule specifies that each entity instance of the supertype
6
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

must be a member of some subtype in the relationship. In contrast, the partial

specialization rule specifies that an entity instance of the supertype is allowed not
to belong to any subtype.

c. Disjoint rule; overlap rule:

The disjoint rule specifies that if an entity instance of the supertype is a member
of one subtype, it cannot simultaneously be a member of any other subtype. The
overlap rule specifies that an entity instance can simultaneously be a member of
two (or more) subtypes.

d. Attribute; operation:
Attributes refer to an object’s data, operation refers to a function or a service that
is provided by all the instances of a class.

Answers to Problems and Exercises

8.46. This is a version of a bill-of-materials structure in which components are different entities
from products, but raw materials are considered components. This exercise also indicates a
minimum cardinality of 3 for the number of components composing a product, but no such
restriction is placed on components as part of other components. Associative entities are used
for the many-to-many relationships because quantity attributes are indicated. Unique attribute
names are used even though the exercise text involves homonyms. The following E-R diagram
depicts this situation.

8.47. One interpretation of this exercise is not as complicated as the situation involving products at
Pine Valley Furniture. In its simplest terms, there are two prices implied in this exercise: the
price at the time of a transaction and the current price. This simply means two different price
attributes, one associated with the transaction and one associated with the stock entity. The
following E-R diagram depicts this situation (only a few attributes have been added to clarify
this example).

7
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

8.48. Many CASE tools have facilities to help people create and edit E-R diagrams. Users select
drawing tools, such as for drawing entity symbols, from a tool palette and draw symbols with
a click and drag of the mouse. Some tools also let users link the elements of the E-R diagram
directly with elements of a data repository and other parts of the CASE tool. Such a tool might
also have a library of “generic” diagrams and relationships for common business processes
(e.g., order entry, manufacturing company, and personnel management). Users could then
choose the diagrams for a corresponding process and quickly and easily edit them so that they
fit the situation. A data modeling CASE tool might translate verbal descriptions of business
rules into semantically rich data models. Such a feature allows more direct translation from
requirements determination to requirements structuring. Also, an E-R tool should seamlessly
integrate with other requirements structuring tools, so that all dimensions (data structure, data
movement, processing logic, and timing of events) of the same object are non-redundantly
and consistently modeled. Visio has many built in templates that would work.

8.49. This exercise defines two entities, Training Program and Training Module, with a one-to-
many relationship (Composed of) between them, and a unary optional (because some modules
do not have a prerequisite, and some modules are not a prerequisite to other modules) many-
to-many relationship (Is Prerequisite for) on the Training Module entity. This is represented
in the E-R below:

8.50. This exercise defines two entities, ADVISOR and STUDENT, and two relationships, Is
Assigned Advisor and Registers, between ADVISOR and STUDENT. An advisor is assigned
zero-to-many students, and a student is assigned to exactly one advisor; an advisor registers
zero-to-many students, and a student is registered by exactly one advisor. An important rule
in this exercise is that the data model cover only “the current term,” so no historical records
need to be kept. As an alternative, it is also possible to create a data model with the above two
8
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

entities and a ROLE associative entity in between, where ROLE has an attribute of ROLE
PLAYED (which could take on values of ‘Advises,’ ‘Advises and Registers,’ and ‘Registers’).
Then, we would create a relationship between the entities through the associative entity such
that an advisor is associated with zero to many students, and a student is associated with one
or two advisors. The problem with this alternative is clarifying on only the data model what
combination of ROLE PLAYED values are permitted for a given student. This is represented
in the E-R below:

8.51. As Part_Number and Drawing_Number most likely have unique values for each entity
instance, these attributes are candidate keys. Part_Number is a logical choice for the identifier.
As a part number is unique, is a single-attribute, and will not be null, these features make it a
good candidate.

8.52. a. The identifier is a combination of Employee_ID and Course_ID.

b. If an employee is permitted to take the course multiple times, then the identifier is no longer
unique. Therefore, another identifier must be specified. The new identifier is a combination
of Employee_ID, Course_ID, and Date. Students may also specify other identifiers for this
situation.

8.53. a. An employee can work on one-to-many projects.

b. The Includes relationship is a binary relationship.
c. No associative entities are directly shown by the associative entity or gerund symbol. The
only many-to-many relationship, Works On, has no attributes, so it does not need to be shown
as an associative entity.
d. The SKILL attribute can be modeled as an attributive or weak entity.
e. It is not possible for the Includes relationship to have attributes because it is a one-to-many
relationship. Only one-to-one and many-to-many relationships are allowed to have attributes.
f. TASK could be modeled as a gerund since it falls at the intersection of mandatory binary
relationships between PROJECT, TOOL, and CITY, depending on the meaning of task. As
currently modeled, TASK is something done on a project with a tool at a city, so it is not an
independent concept. TASK can be modeled as an entity because it has its own primary key
independent of the keys of PROJECT, CITY, and TOOL. Some semantic information would
be lost if TASK were modeled as a gerund (e.g., the minimum cardinalities related to task on
the Includes, Done at, and Used on relationships).

9
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

g. HOURLY PAY RATE would be an ideal entity that would be between EMPLOYEE and
PROJECT. The relationships between EMPLOYEE to HOURLY PAY RATE is many to one.
The relationship between PROJECT to HOURLY PAY RATE is a many to many relationship.
The HOURLY PAY RATE would have Employee_ID and Project_ID are the primary key for
the attitude.

8.54. Following is one possible set of relationship cardinalities for Figure 8-24.

Places: A customer places zero to many orders, and an order is for exactly one
customer.
Generates: An order generates zero to one backorder, and a backorder is for exactly one
order.
Includes: An order includes one to many products, and a product is included on zero to
many orders.
Comprised of: A product is comprised of one to many components, and a component goes
into making one to many products.
Supplied by: A component is supplied by zero-to-many vendors (the manufacturer makes
some components), and a vendor supplies one to many components.

8.55. Each of the four statements yields a new entity and relationship with an existing entity in
Figure 8-24.

▪ The assignment of customers to sales representatives adds a SALES REP

entity and an Assigned to relationship, such that a sales representative is
assigned one-to-many customers, and a customer is assigned zero (the
statement does not say all customers are assigned a sales representative) or
one sales representatives (a sales representative gets a unique set of
customers).

▪ The statement in this exercise that causes the most difficulty is the one about
customers becoming “members” with unique benefits. The debatable term is
“unique.” Unique means that only members, not other customers, receive
benefits. Using this assumption, the following representation is reasonable:
Create a BENEFIT entity and a many-to-many Receives relationship between
BENEFIT and CUSTOMER, such that a customer receives zero (not all
customers are members) to many benefits (each benefit is recorded as a
separate instance of the BENEFIT entity), and a benefit is received by zero
(on a transient basis, nobody may hold a given benefit) to many customers
(this also allows different members to receive different benefits). Again, this
statement points out how much more precise an E-R model is than a
requirements, narrative statement.

▪ The creation of manufacturing teams adds a TEAM entity (the exercise does
not say we need to know what employees are on a team) and a Produces
relationship such that a team produces one-to-many products, and a product
is produced by exactly one team (teams get unique sets of products, and some
team has to produce each product).

10
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

▪ The assignment of purchasing agents to vendors is analogous to the first

situation described, so we create an AGENT entity and a relationship, such
that an agent is responsible for one-to-many vendors, and a vendor is under
the responsibility of zero or one agent.

8.56. Student answers will vary depending on the document they find. Generally, each type of
document involves three or four entities or gerunds, with a gerund representing the many-to-
many relationship between two of the other entities. Also, each document has master entity or
header data and detail or line item data. Since normalization is not done until logical data
modeling, students may combine some entities.

8.57. This is, of course, a very open-ended question. An actual interview dialogue is quite long and
varies depending on the particular order entry function. The following is an excerpt from a
representative interview script. This excerpt illustrates the types of initial and probing
questions that arise as an analyst attempts to understand the data required to support order
entry. Bold terms indicate data modeling requirements. Suggest to your students that they
create a script that includes questions from all eight of the areas covered in Table 8-1 so that
they practice exploring all the dimensions of data modeling. An example script follows:
Question: What basic operations are performed in order entry?
Answer: Order entry concerns the creation and maintenance of data about customer orders.
Question: What do you know about a customer order?
Answer: We know the order date, order number, customer P.O. number, promised delivery
date for the order, customer name, ship-to address, bill-to address, customer number,
customer phone number, product number, order quantity, color ordered (if
applicable), and item description. (So, there are customer, customer order,
product, and order line item entities.)
Question: Does a customer have the same ship-to and bill-to address for every order she places?
Answer: No, the ship-to address can vary by order, but the bill-to address is always the same
for each of our customers. Some customers have many stores to which we ship
furniture. If we have a customer, like Fred’s Furniture, which has different purchasing
offices where invoices are sent for different regions of the country, we consider each
office a separate customer for billing purposes. (Thus, ship-to address is a
characteristic of the customer order, whereas bill-to address is a characteristic
of the customer.)
Question: What distinguishes one customer from another customer?
Answer: We assign each customer a unique customer number.
Question: Must a customer have a customer number before you start to keep track of them?
Answer: Yes, but often we do not know some of the other data about a customer, like the bill-
to address. (So, nulls are not permitted for customer number, but other customer
and order data can be null.)
Question: What is the format of a customer number?
Answer: A customer number is six digits long. (This is useful information to clarify what is an
attribute. This is also necessary information for later physical file and database design
steps.)
Question: Are there any restrictions on when an order is promised?

11
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

Answer: Yes, the promised delivery date is no sooner than one day after the order date and
cannot be more than three months after the order date. (So, there are integrity rules
on the promised delivery date.)
Question: How long do you retain data about customer orders?
Answer: We retain order data for seven years after the order is paid. (So, it is likely that many
customers will have many associated orders.)
Question: Do you keep information about customers that have never ordered from you or who
have not ordered for more than seven years?
Answer: Yes, we do receive data about prospective customers, and we want to keep track of
potential, previous, and current customers. (So, the minimum cardinality is 0.)
Question: Are customers grouped or categorized in any way?
Answer: Yes, we group customers by regions of the country or by foreign country (which we
consider separate regions), and we have a sales manager responsible for each region.
Question: Can a sales manager be responsible for more than one region and must a region have
only one manager?
Answer: Yes. (So, there is a one-to-many relationship between sales manager and region, and
then a one-to-many relationship from region to customer.)
Question: Can a sales manager be responsible for a customer order outside her region?
Answer: Yes, either because she initiates that order or because she changes regions after the
order is placed.
Question: Do you want to keep track of these out-of-region orders for sales managers?
Answer: Yes, since sales managers are paid partially based upon commissions. We need to
distinguish and track both the sales manager of the region in which the customer
resides as well as the sales manager who initiated the sale. (So, there need to be
relationships from customer order to customer to region to sales manager as well
as a relationship directly from customer order to sales manager.)

12
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

8.58.

8.59. Three examples of ternary relationships are provided below.

▪ television programming: the ternary relationship among a T V show, a

date/time slot, and a channel

▪ shipping: the ternary relationship among a product, a carrier, and a ship-to

location

▪ class scheduling at a multi-campus university: the ternary relationship among

a course, an instructor, and a campus
A difficult issue with a ternary relationship is determining the cardinalities along each edge of
the relationship. Be sure students can argue the logic of the cardinalities they choose.

8.60. A vessel holds potentially many consignments, and a consignment is on at most one vessel,
which probably means that the holds relationship keeps track of the consignments currently
held on a vessel (and the vessel, if any, which currently holds a consignment). A vessel goes
on potentially many voyages, but a voyage involves only one vessel. The Transports
relationship says that a consignment is transported on zero to many voyages (which may
involve the same or different vessels), and a voyage transports zero to many consignments.
Given that a consignment might be on many voyages, and even though each voyage involves
exactly one vessel, it is not known from just Transports and Goes on which vessel a
consignment is currently on (there are no attributes from which to infer this). Thus, all three
relationships are needed.

13
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

8.62. A suggested answer is provided below.

8.63. Suggested answers are provided below.

a.

b.

c.

14
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

d.

8.63. Suggested answers are provided below.

a.
15
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

b.

16
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

c. Yes this is possible; if the relationship married is changed to an associative entity as in the
figure below.

8.64. A suggested answer is provided below. Ask students if limits should be placed on the range
of this attribute. Why or why not? For the triggering operation, an assumption is made that
when an account is first opened the initial balance cannot be less than $100.00.

a. Domain Definition: b. Triggering Operation:

Name: Balance User Rule: Initial ACCOUNT Balance is

Meaning: Balance of the Customer’s equal to or greater than $100.00
Account Event: Insert
Data Type: Numeric Entity name: ACCOUNT
Format: 2 Decimal Places Condition: Initial Deposit < required
Uniqueness: Nonunique starting ACCOUNT Balance
Null support: Non-null Action: Reject the insert transaction

8.65. While the E-R diagrams tell us about the data, relationships among data, and the relevant
business rules, decision trees focus on the logic in the models. Obviously, it is necessary to
know about the data, the relationships, the business rules, and the business processes in order
to develop a good system. Thus, the various modeling techniques are complementary. If either
data or logic modeling techniques (decision trees) are done poorly (or not done at all) the
resulting system suffers. For example, if data modeling is left out, the business process is well
understood but the implementation of the databases is likely flawed. The system probably
provides information to the right person at the right time, but the information will be useless.
Conversely, if logic-modeling techniques are done poorly, the databases might be
implemented well, but they will not do anyone much good.

8.66. This is one of the more complex exercises because there are many entities, relationships, and
complicated business rules. It is assumed that a caseworker may not have been assigned a
purchase request, and that some vendors, who only bid on the large purchase requests, are not
approved to supply commonly purchased products and services. Further, it is assumed that a
purchase request is for exactly one product or service, and that a purchase request is tracked
before bids start to come in. Finally, it is assumed that to be recognized as a customer, the
customer must have submitted at least one purchase request. The E-R diagram can be more
explicit (than shown below) if generalization-modeling techniques are used. Without
supertype and subtype relationships, a TYPE attribute on the PURCHASE REQUEST entity
would have to be used; detailed business rules would have to be written that indicate that large

17
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

purchase requests require bids, whereas small requests do not. It also appears from the scenario
that only small purchase requests are associated with products and services, which necessitate
a business rule to elaborate on the E-R diagram. A suggested answer follows.

Guidelines for Using the Field Exercises

8.67. Students are likely to come up with several E-R diagrams for a variety of work settings. If
they focus their answers on a situation that mirrors the one discussed in the book (e.g., order
entry), or if several students focus on the same situation in different organizations, it is useful
for them to compare their answers. This comparison highlights the different business rules
used across organizations for these same activities and the robustness and applicability of the
E-R diagramming technique. Alternatively, your students can build from their own
educational experiences and the education examples provided in this chapter and draw an E-
R diagram for a situation at their school.

8.68. The E-R diagramming technique is robust and applicable across a variety of situations. There
should be little or no difference in using the technique for service- versus product-oriented
organizations. Similarly, there should be little or no differences in using the technique for
public, private, or governmental organizations. Your students may find that governmental
organizations are a bit more rule-bound than nongovernmental organizations, and so there
may be more and stricter rules that apply to data. The only other major differences are the
various ways that data happen to be stored and used in these organizations. This is not likely
based on the “type” of organization, but on the choices made for managing data and business
processes. More detailed and dedicated students may find that the E-R model needs more
semantic richness or some extended constructs. Business rules provide one useful extension.
As an alternative, you might suggest that students read about the object-oriented database
model; some people believe that the O O data model is richer than the E-R model, and your
students will certainly find many similarities.

18
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

8.69. Students are likely to discover that conceptual data modeling is handled in a variety of ways.
Some larger organizations, with relatively large systems staff, offer formal training in
conceptual data modeling, and they use formal conceptual data modeling as a fixed part of the
analysis phase. This activity might be performed by systems personnel with the explicit title
of “modeler,” “data modeler or analyst,” or “conceptual data modeler.” In other organizations,
conceptual data modeling is done less formally, probably by an “analyst” who performs this
and many other functions throughout the S DL C. In other organizations, particularly those
where the systems are relatively small and simple, there may be no true conceptual data
modeling; that is, systems are implemented without a thoughtful design of a conceptual
database for the organization.

8.70. If students find analysts who have experience with conceptual data modeling, then these
analysts will likely provide several examples for all three relationships. The analysts’
experiences with each type of relationship will vary depending on their amount and level of
experience with modeling and the relative complexity of the systems they help to develop and
maintain.

8.71. Students are likely to find that where E-R diagrams are being used the systems personnel are
using CASE tools to create and edit them. Many of these CASE tools have been discussed
throughout this book. CASE tools with E-R diagramming features are very effective for the
creation and manipulation of good E-R diagrams and the linking of E-R diagram elements to
other information within the CASE tool and system. For those people who are drawing E-R
diagrams by hand, perhaps they do not know of or have not yet found the proper automated
tool. Even with the limitations of CASE tools to draw advanced E-R features (such as ternary
relationships), advanced features can be simulated and useful, approximate data models (albeit
imprecise for generating code) can be created.

8.72. There are several different standards for E-R diagramming. The Peter Chen method uses
diamonds for the relationships, whereas the James Martin version uses no symbols for
relationships but instead calls for the relationship to be written near each entity box in the
relationship. Different ways to represent minimum and maximum cardinality exist. In
addition, some CASE tools use their own slightly modified, nonstandard notation. So,
whatever the student is able to get from a systems analyst will probably differ from what is in
the book, if only slightly. The best way to find and analyze the differences is to do a point-by-
point comparison.

8.73. This question’s answer is similar to that for Field Exercise 72 in that the details of the diagram
depend on the E-R diagramming method being used. The bill-of-materials E-R diagram will
be more specific as it pertains to a specific assembly or subassembly.

19
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

Appendix: Object-Oriented Analysis and Design

Object Modeling – Class Diagrams
The purpose of this appendix is to introduce students to object-oriented analysis and design (OOAD).
OOAD’s increasing popularity is brought about in part because of its ability to represent complex
relationships, as well as data and data processing, with a consistent notation. Students are introduced
to several techniques and notations that systems analysts use to perform object-oriented analysis and
design, specifically, class diagrams. The standard object-oriented language, UML, is used to present
these techniques and notations.

The appendix begins with a comparison of the object-oriented development life cycle and the
traditional development life cycle. The object-oriented development life cycle consists of three
primary phases: analysis, design, and implementation. An object representation will develop as it
moves through each of these phases. After a brief introduction to U ML, students are shown how to
prepare the diagrams mentioned above. This appendix concludes with a discussion of these various
diagramming techniques and their use in analysis and design.

Instructional Objectives
Specific student learning objectives are included at the beginning of the appendix. From an
instructor’s point of view, the objectives of this appendix are to:

1. Discuss the similarities and differences between the object-oriented development life cycle
and the more traditional systems development life cycle.
2. Show the similarities and differences between object-oriented analysis and design and more
traditional, structured systems analysis and design notations and methods.
3. Reinforce the terminology utilized in this appendix.
4. Discuss when each of the modeling techniques is utilized in the object-oriented development
life cycle.
5. Show students how to construct class diagrams.
6. Show students how to take a data flow model as Figure 8-35 and form an E-R Diagram such
as Figure 3-37.

Classroom Ideas
1. An object-oriented (O O) specification can become very extensive since all aspects are
integrated into one model, so you will need to use simple examples. After briefly reviewing
OOAD terminology and notation, it is recommended that you teach from examples for the rest
of the class. The situations described in the Problems and Exercises are suitable to work in
class. Experience has shown that the greatest discussion centers on what methods should exist
and where they should be located (that is, with what object).

2. It is essential that students have a sound understanding of the core concepts of O OAD: object,
class, encapsulation, inheritance, and to some extent polymorphism. Be sure students can
distinguish an object from a data entity instance and a class from an entity type. Emphasize
the ramifications of encapsulation for systems development, which deal primarily with
decoupling system components.

20
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

3. Compare and contrast the OOAD phases with the traditional SDLC phases. Stress to students
that in the beginning the model is abstract, showing more detail as it moves through the OOA
D phases. The text uses a good analogy; OOAD resembles more of an onion than a waterfall.

4. If you have access to practicing systems analysts, invite these analysts to your class to discuss
their usage of OOAD.

5. Stress the benefits of O O A D, especially the increased consistency among the models
developed during object-oriented analysis and design.

6. For some students this is their first exposure to object-oriented analysis and design. One way
to approach the presentation of this material is to make heavy use of the figures and
illustrations utilized in this appendix. Use these figures and illustrations to reinforce the
terminology and diagramming rules presented in the text.

7. Review Question 1 is a good tool for comparing and contrasting the terminology presented in
this appendix.

8. Using two or three case studies (depending upon the size of your class), have students break
up into small teams. A pair of teams will handle modeling one case study. One team will use
E-R modeling concepts and the other OO modeling. Ask each team pair to present their results
and how the two models are similar and different for the case that was represented.

Answers to Key Terms

Suggested answers are provided below. These answers are presented top-down, left to right

8.84. Composition
8.76. Aggregation
8.93. Polymorphism
8.88. Method
8.75. Abstract operation
8.82. Class-scope attribute
8.85. Concrete class
8.74. Abstract class
8.79. Associative class
8.89. Multiplicity
8.78. Association role
8.77. Association
8.83. Class-scope operation
8.96. Update operation
8.94. Query operation
8.86. Constructor operation
8.87. Encapsulation
8.92. Operation
8.81. Class diagram
8.91. Object class
8.80. Behavior
8.95. State
8.90. Object

21
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

Answers to Review Questions

8.97. An example of aggregation

8.98. a. Object class; object:

Object class refers to the logical grouping of objects that have the same
attributes whereas an object refers to an entity that has a well-defined role in
the application domain.

b. Abstract class; concrete class:

Abstract class has no direct instance, but whose descendents may have direct
instances whereas concrete class is a class that can have direct instances.

Answers to Problems and Exercises

8.99. a. Employee Billing Class Diagram

b. University Course Class Diagram

22
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

c. Lab Class Diagram

d. Course Class Diagram

e. Hospital Class Diagram

23
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

8.100.

8.101.

8.102.

24
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

The E RD is able to directly represent M:N relationships, whereas the object diagram is not. Also,
some data flows, such as receives inventory, appears to be in the Object diagram. You will note
that an associative entity for Recipe is used.

25
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

Petrie Electronic Case Solutions

8.103. The six entity types in 102 above are the only ones needed to represent the reward
tracking system. However, depending on what data about Customers and Managers
are required, entities for these objects may also be required. If they were, this would
be a more normalized E R D as you can see plainly the duplication of data in this
drawing.

8.104.
The Promotion Entity has the attributes:
• Promotion I D—a number generated by the system to uniquely identify a
promotion.
• Promotion Description—the text that described the type of promotion.
• Promotion Time Stamp—the date and the time that the promotion was entered
into the system by the customer.
• Coupon_ ID – coupon being used in the promotion.

The Coupon entity has the attributes:

• Coupon ID—a number generated by the system to uniquely identify a coupon.
• Promotion I D—a number generated by the system to uniquely identify a
promotion.
• Coupon Description—the text that describes the coupon.
• Coupon Discount—the amount of discount.
• Customer ID—the ID number of the customer.
• Product_ ID—the ID number of the product that is being discounted.
• Coupon Time Stamp—the date and the time that the coupon is created.

The Customer entity has the attributes:

• Customer I D—a number generated by the system to uniquely identify a
customer.
• Customer Name-text field for the name of the customers.
• Customer Address—the address of the customer.
• Customer Email—the email address of the customer.
• Customer Time Stamp—the date the customer record is created.

The Product entity has the attributes:

• Product ID—a number generated by the system to uniquely identify a product.
• Product Description—the text to describe the product.
• Product Price—the price of the product.

The Service entity has the attributes:

• Customer I D—the customer I D number of the customer who owned the
product.
• Product_ID – The product being serviced.
• Produc_Descr—the text to describe the product.

26
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

• Service Name—the name of the service.

• Service Time Stamp—the date that a customer got service the product.

The Transaction entity has the attributes:

• Transaction ID—a number generated by the system to uniquely identify a sale
or service of a product.
• Customer ID—the customer ID number of the customer who purchased the
product.
• Transaction Name—the name of the transaction.
• Transaction Time Stamp—the date and the time that the product was
purchased or serviced by the customer.
• Product ID—a number generated by the system to uniquely identify a product.
• Product Description—the text to describe the product.
• Product Price—the price of the product.
• Coupon_ID – Coupons Used.

27
Copyright © 2020 Pearson Education, Inc.
Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

8.105. Each identifier has been noted in 104 above.

8.106. The E-R Diagram in 104 above has included cardinality for each relationship.

8.107. The consequence of not including the employee entity types on this diagram is that
names (and possibly other attributes) appear as an attribute on several of the other
entities. It is recommended that employee entity is created and related to service and
product. With the employee ID attitude added to each of these entities as well. This
will allow tracking of who sold the product and who serviced the product. This would
eliminate the duplication of data.

8.108. Answers to this question will vary due to specific instructor directions. Typical

28
Copyright © 2020 Pearson Education, Inc.
Solution Manual for Modern Systems Analysis and Design, 9th Edition, Joseph Valacich Joey F.

Chapter 8 Modern Systems Analysis and Design 9th edition Instructor’s Manual

dictionary contents for entity, attribute, and relationship objects are listed below.

Entity: Short name, name, plural, volume (initial, maximum, average, growth rate),
data warehouse type, list of attributes, description

Attributes: Primary U ID, optional, percentage used (initial, average), domain, type,
maximum length, average length, decimal places, units, derivation, on condition, null
value, default, sequence in sort, sort order

Relationships: From entity name, from relationship name, from optionality and
degree, to entity name, to relationship name, to optionality and degree, description

8.109. The Transaction, Service, Product, and Coupon entities all have date/time-related
entities. The date/time attributes are needed because the same customer could buy,
service and the coupon needs an expiration date. Also, to archive old, obsolete data,
or to see temporal trends, dates are needed.

29
Copyright © 2020 Pearson Education, Inc.

Visit TestBankBell.com to get complete for all chapters