Process Modeling
CHAPTER 8 STRUCTURING SYSTEM DATA REQUIREME NTS 307
IHI:Mt! PETRIE ELECTRONICS Chapter 8: Structuring System Data Requirements
Jim Watanabe, manager of the "No Customer Escapes" project, and assistant director of IT for Petrie Electron- ics, was sitting in the company cafeteria. He had just fin- ished his house salad and was about to go back to his office when Stephanie Welch sat down at his table. Jim had met Stephanie once, back when he started work at Petrie. He remembered she worked for the database administrator.
"Hi, Jim, remember m 'e?" she asked. "Sure, Stephanie, how are you? How are things in data-
base land?" "Can't complain. Sanjay asked me to talk to you about
the database needs for your new customer loyalty sys- tern ." Stephanie's phone binged. She pulled it out of her oversize bag and looked at it. She started to text as she continued to talk to Jim . "How far along are you on your database requirements?"
That's kinda rude, Jim thought. Oh well. "We are still in the early stages. I can send you a very preliminary E-R diagram we have (PE Figure 8-1), along with a description of the major entities."
"OK, that will help . I suspect that you won't have too many new entities to add to what's already in the system," Stephanie responded, still looking at her phone and still texting. She briefly looked up at Jim and smiled slightly before going back to texting. "Just send the E-R to me, and rlliet you know if I have any questions." She stood up, still looking at her phone. "Gotta go," she said, and she walked away.
OK, Jim thought, I need to remember to send Stephanie the preliminary E-R we have . I should probably send her the entity descriptions too (PE Table B-1), just in case. Jim stood up, cairied his tray over to the recycling area of the cafeteria, and went back to his office.
When Jim got back to his office, Sanjay was waiting for him.
"I've got more information on those alternatives we talked about earlier," Sanjay said. "I had one of my em- ployees gather some data on how the alternatives might satisfy our needs." (See the descriptions of the alterna- tives at the end of Chapter 6.) Sanjay handed Jim a short report. "The matrix shows the requirements and con- straints for each alternative and makes it relatively easy to compare them ." (See PE Figure 8-2.)
"The matrix favors the XRA CRM system," Jim said, af- ter looking over the report. "It looks like their proposal meets our requirements the best, but the Nova group's proposal does the best job with the constraints."
"Yes, but just barely, " Sanjay said. "There is only a five point difference between XRA and Nova, so they are pretty comparable when it comes to constraints. But I think the XRA system has a pretty clear advantage in meeting our requirements."
"XRA seems to be pretty highiy rated in your matrix in terms of all of the requirements. You have them ranked better than the other two proposals for implementation, scalability, and vendor support," Jim said. "The '5' you gave them for prove n performance is one of the few '5's' you have in your whole matrix."
"That's because they are one of the best companies in the industry to work with," Sanjay responded, "Their rep- utation is stellar."
r------- I Coupon
i
I Service I
, l
,-
I Promotion ~ Customer .I'i
~ Transaction
PE FIGURE 8-1 !nitiol E·R for Pe trie's customer loyalty program
308 PART III ANALYSIS
PE TABLE 8-1
En61y
Coupon
Customer
Product
Promotion
Service
Transaction
Entity Descriptions jar the Preliminary E-R Diagram lor Petrie's Customer Loyalty System
Description
A coupon is a special promotion created specifically for an individua l customer. A coupon is for a set dollar amount, for example, $10 . The customer may use it like cosh or like a dollars-off promotion when purchasing products or services . Coupons con only be created for an individual customer based on the poin ts in his or her customer loyalty account. For each dollar value of a coupon, a certa in number of pOints must be redeemed . Coupons must be accounted for when created and when redeemed .
A customer is someone who buys produc ts and/or services from Petrie Electronics . Customers include both online customers and those who shop in Petrie's brick<Jnd·mortar stores.
An item made available for sale to a Petrie's customer. For example, a product is a 40" Sony LCD HD television, Products can be purchased online or in brick<Jnd·mortar stores .
A promotion is a special incentive provided to a customer to entice the custome r into buying a specific product or service . For example, a promotion intended to sell BluRay d isks may involve 2·for· l coupons . Promotions are targeted to all customers, or to subsets of customers, not just to individual customers .
A job performed by one of Petrie 's associates for a customer. For example, upgrading the memory in a computer by installing new memory cards is a service that Petrie provides for a fee . Services may only be ordered and performed in brick-ond·mo rtar stores, not o nline .
A record that a particular product or service was sold to a specified customer on a particular date, A transaction may involve more than one product or service , and it may involve more than o ne of a particular kind o f product or service . For example, one transaction may involve blank DVDs and pre-recorded DVDs, and the pre-recorded DVDs may all be of the same movie , For members of the loyalty program , each tran saction is worth a number of points, depending on the dollar value of the transaction.
Criteria AltA: SBSt AltB XRA Alte Nova Weight Rating Score Rating Score Rating Score
Requirements
Effective customer incentives 15 5 75 4 60 4 60 Easy for customers to use 10 3 30 4 40 5 50 Proven performance 10 4 40 5 50 3 30 Easy to implement 5 3 15 4 20 3 15 Scalable 10 3 30 4 40 3 30 Vendor support 10 3 30 4 40 3 30
60 220 250 c215
Constraints
C ost to buy 15 3 45 4 60 5 75 Cost to operate 10 3 30 4 40 4 40 Time to implement 5 3 15 3 15 3 15 Staff to implement 10 3 30 4 40 3 30
40 120 155 160
TOTAL 100 340 - 375 PE FIGURE 8-2
Evaluation matrix for customer loyalty proposals
"This looks really promising," Jim said. "Let's see if real- ity matches what we have h ere. It's time to put together the formal request for proposal. I'll get that work started today. I hope that all three of these companies decide to bid."
and decided whether you agree with the team's conclu· sion that the only 6 entity types needed are listed in th~ case and in PE Figure 8-1. If you disagree, define addi· tional entity types, explain why they are necessary, and modify PE Figure 8-1 accordingly.
Case Questions
L Review the data-flow diagrams you developed for ques- tions in the Petrie Electronics case at the end of Chap- ter 7 (or diagrams given to you by your instructor). Study the data flows and data stored on these diagrams
2. Again, r evie w the DFDs you develope d for the Petrie Electronics case (or those given to you by your in· structor). Use these DFDs to identify the attributes of each of the six entities listed in this case plus anY ad- ditional entities identified in your answer to Question 1. Write an unambiguous definition for each attributR
CHAPTER 8 STRUCTURING SYSTEM DATA REQUIREMENTS 309
Then, redraw PE Figure 8-1 by placing the six (and ad- ditional) entities in this case on the diagram along with their associated attributes.
3. Using your answer to Question 2, designate which at- tribute or attributes form the identifier for each entity type. Explain why you chose each identifier.
4. Using your answer to Question 3, draw the relationships between entity types needed by the system. Remem- ber, a relationship is needed only if the system wants data about associated entity instances. Give a mean- ingful name to each relationship. Specify cardinalities for each relationship and explain how you decided on each minimum and maximum cardinality on each end of each relationship. State any assumptions you made if the Petrie Electronics cases you have read so far and the answers to questions in these cases do not provide the evidence to justify the c ardinalities you choose. Redraw your final E-R diagram in Microsoft Visio.
5. Now that you have developed in your answer to Ques- tion 4 a complete E-R diagram for the Petrie Electronics
database, what are the consequences of not having an employee entity type in this di agram? Assuming only the attributes you show on the E-R diagram, would any attribute be moved from the entity it is currently asso- ciated with to an employee entity type if it were in the diagram? Why or why not?
6. Write project dictionary entries (using standards given to you by your instructor) for all the entities, attributes, and relationships shown in the E-R diagram in your an- swer to Question 4. How detailed are these entries at this point? What other details still must be filled in? Are any of the entities on the E-R diagram in your answer to Question 4 weak entities? Why? In particular, is the SERVICE entity type a weak entity? If so, why? If not, why not?
7. What date-related attributes did you identify in each of the entity types in your answer to Question 4? Why are each of these needed? Can you make some general ob- servations about why date attributes must be kept in a database based on your analysis of this database?