chapter 11 structuring system requirements: - · web viewstructuring system requirements: ......

Chapter 10Structuring System Requirements:

Conceptual Data Modeling

Chapter Overview

Chapter 10 presents a detailed description of the techniques used to structure the data requirements for an information system application. This chapter emphasizes entity-relationship (E-R) diagramming, the most common notation used by practicing systems and data analysts. Chapter 10 explains how 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 also introduces the modeling of business rules for entity integrity, referential integrity, domains, and triggering operations using both E-R diagrams and textual constraint statements. 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.

Classroom Ideas

1. This chapter was to be read following Chapters 8 and 9 on process and logic modeling, respectively. However, many instructors prefer to emphasize data modeling by requiring their

120

Modern Systems Analysis and Design, 3rd edition Instructor’s Manual

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 8 and 9.

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 10-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. Problem and Exercise 12 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 the students 10 minutes to prepare for the interview and 15-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 10-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

121

Chapter 10 Structuring System Requirements: Conceptual Data Modeling

“entity” is often used either way, with the meaning intended to come from the context in which it is used.

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 10-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 10-8). 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 might a student 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 3, 7, 8, 9, 10, 15, and 21. 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).

122


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 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.

7. Conceptual data model 3. Binary relationship11. Entity-relationship data model (E-R model) 23. Ternary relationship12. Entity-relationship diagram (E-R diagram) 6. Cardinality14. Entity type 1. Associative entity13. Entity instance (instance) 4. Business rules2. Attribute 21. Subtype5. Candidate key 22. Supertype

15. Identifier 24. Total specialization rule16. Multivalued attribute 18. Partial specialization rule20. Repeating group 9. Disjoint rule19. Relationship 17. Overlap rule8. Degree 10. Domain

26. Unary relationship (recursive relationship) 25. Triggering operation (trigger)

Answers to Review Questions

1. 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 rather than processes are the most complex aspects of many information systems, and hence must be modeled with clarity; (3) data characteristics and natural structures (as opposed to processing requirements) 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 important for automatic program generation.

2. 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

123


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.

3. 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.

4. Although many 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.

5. A many-to-many relationship must be modeled as an associative entity when there are attributes associated with the relationship.

6. 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.

7. 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.

8. 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.

9. 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 relationship. A customer placing an order with a salesperson is an example of a ternary relationship.

124


10. 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.

11. 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.

12. Minimum cardinality refers to the minimum number of instances of entity B that can 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.

13. 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.

14. E-R diagrams are produced: (1) to cover just the data needed in the project’s application; (2) for the application system being replaced; (3) to document the entire database from which the new application’s data is extracted; and (4) for the whole database from which data for the application being replaced is drawn.

A subtype is a subgrouping of the entities in an entity type that is meaningful to the organization and that shares common attributes or relationships distinct from other subgroupings. A supertype is a generic entity type that has a relationship with one or more subtypes. The total specialization rule specifies that each entity instance of the supertype 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. 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.

Answers to Problems and Exercises

1. 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 since quantity attributes are indicated. Unique attribute names are used even though the exercise text involves homonyms. The following E-R diagram depicts this situation.

125


2. 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 gerund 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).

3. Many CASE tools have facilities to help people create and edit E-R diagrams. Users use the mouse to 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, 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

126

Ticker Code

Current Price

Date No of Shares

BROKER TRANSACTION STOCK

CUSTOMER

Order No T_Price

Product NoComponent No

C_Description

Unit of Measure

Cost

P_DescriptionC_Quantity

G_Quantity

PRODUCT COMPRISEDOF

COMPONENT

GOES INTO

3


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 nonredundantly and consistently modeled.

4. This exercise defines two entities--Training Program and Training Module--with a one-to-many relationship (Composed of) between them, and a unary optional (since 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.

5. 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 covers 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 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.

6. Since 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. Since a part number is unique, is a single-attribute, and will not be null, these features make it a good candidate.

7. The identifier is a combination of Employee_ID and Course_Name. 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_Name, and Date. Students will also specify other identifiers for this situation.

8. An employee can work on one-to-many projects; the Includes relationship is a binary relationship. 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. The SKILL attribute can be modeled as an attributive or weak entity. It is not possible for the Includes relationship to have attributes since it is a one-to-many relationship. Only one-to-one and many-to-many relationships are allowed to have attributes. 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 since 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. Following is one possible set of relationship cardinalities for Figure 10-22.

127


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 (we make some components), and a vendor supplies one to many components.

10. Each of the four statements yields a new entity and relationship with an existing entity in Figure 10-22.

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).

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.

11. 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.

128


12. 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 10-1 so that they practice exploring all the dimensions of data modeling.

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

an attribute is and is necessary information for later physical file and database design steps.)

Question: Are there any restrictions on when an order is promised? 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.)

129


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 needs 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.)

13. This is a fairly complex situation. For this exercise, we take the statement literally that a reservation is a ternary relationship (a gerund if it has associated data) between the three listed entities. We assume that a flight means a flight on a particular day, hence flight has a composite primary key. Thus, a seat on a flight may have a passenger. A passenger must have some seat on one or many flights. A passenger will have exactly one seat on a given flight.

14. Three examples of ternary relationships are provided below.

television programming: the ternary relationship among a TV 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.

15. A vessel holds potentially many consignments, and a consignment is on at most one vessel, which probably means that holds tracks 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

130


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, we do not know from just Transports and Goes on which vessel a consignment is currently on (there are no attributes from which to infer this). Thus, it would appear that we need all three relationships.

16. A suggested answer is provided below.

17. Suggested answers are provided below.

131

PRODUCT

CUSTOMER

ORDER

Places

Includes

Name

Customer_No

Street_Address City

State

Zip

Order_No

Order_Date

Promise_Date

Quantity

Product_No

Description

Unit_Price

PROPERTY

Offer_Date, Offer_Price Offer_Name

Property_No


132

OFFER

Property_No

PROPERTY

Offer_No

Offer_Date

Offer_Price

OFFER

Property_No

PROPERTY

Offer_No

Offer_Date

Offer_Price

POTENTIAL_ BUYER

Buyer_No

Phone_No Address

Name

OFFER

Property_No

PROPERTY

Offer_No

Offer_Date

Offer_Price

Offer_Name


18. Suggested answers are provided below.

19. 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.

Domain Definition:

Name: BalanceMeaning: Balance of the Customer’s

AccountData Type: NumericFormat: 2 Decimal PlacesUniqueness: NonuniqueNull support: Non-null

Triggering Operation:

User Rule: Initial ACCOUNT Balance is equal to or greater than $100.00

Event: InsertEntity name: ACCOUNTCondition: Initial Deposit < required

starting ACCOUNT BalanceAction: Reject the insert transaction

20. The text and figure for Problems and Exercises 9 and 10 do not tell us much about the processes and logic underlying the data and relationships. We do know that there are data stores on the DFDs for the associated business situation; these data stores contain the same attributes as identified on the E-R diagram. The E-R diagram identifies several of the business rules that apply. For example, we know that each sales representative is assigned to a small, unique set of customers, that some customers are “members,” which entitles them to special benefits, and so on. These are all statements that are collected during requirements determination and listed as business rules. There are processing steps where, for example, customers are assigned benefits, but the process description for the associated processing steps would not show the rules that govern the assignment of benefits to customers. A decision table

133

PERSON

Is_Married_to

Date_Married

PERSON

Married Date_Married


might outline these rules; the result of which is the determination of which benefits a member receives.

While the E-R diagrams tell us about the data, relationships among data, and the relevant business rules, the process models (DFDs) and the logic models (Structured English, decision tables, and decision trees) from previous chapters tell us more about the business process and the flow of data. Obviously, we need 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 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.

21. This is one of the more complex exercises since there are many entities, relationships, and complicated business rules. We assume 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. We assume that a purchase request is for exactly one product or service. We also assume that a purchase request is tracked before bids start to come in. Finally, we assume 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 we show below) if generalization-modeling techniques are used. Without supertype and subtype relationships, we are forced to use a TYPE attribute on the PURCHASE REQUEST entity; we would have to write detailed business rules that indicate that large 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.

134

CUSTOMER

PURCHASE_ REQUEST

VENDOR REQUEST_FOR_BID

CASE_WORKER

Submits

Assigned_ to

PURCHASING_ DEPT_MGR

Approved_by

Approves

Bids_on

Creates Purchased

_from


Guidelines for Using the Field Exercises

1. Students are likely to come up with a number of E-R diagrams for a variety of work settings. If they focus their answer on a situation that mirrors 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.

2. The E-R diagramming technique is fairly 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 OO data model is richer than the E-R model, and your students will certainly find many similarities.

3. 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 SDLC. 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.

4. If the 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 relatively complexity of the systems they help to develop and maintain.

5. 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 that 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

135


relationships), advanced features can be simulated and useful, approximate data models (albeit imprecise for generating code) can be created.

6. There are several different standards for E-R diagramming. The Peter Chen method uses diamonds for the relationships, while 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.

7. This question’s answer is similar to that for Field Exercise 6 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.

Guidelines for Using the Broadway Entertainment Company Cases

Guidelines and answers for using the Broadway Entertainment Company cases are available on this textbook’s companion Web site. Please visit www.prenhall.com/hoffer to access this information.

136

chapter 11 structuring system requirements: - · web viewstructuring system requirements: ......

Documents