Past-event records don't make our demonstration easier; they avoid the challenge altogether. applies. But why do you look troubled? Ah, you want to know how on earth we came up with two more boxes despite having no idea what we're going to do with them. Weil, I'm reluctant to admit it, but I haven't the foggiest notion either. I threw them in because that's what the future- event pattern told us to do and, as I men- tioned, it is an old and trusted friend. Now that we have them, what say we press on and figure out their use? Consider the resupply report. "Based on its stock guantity being too low," the goal said. Evidently, we need a field, gty-that's-too-low, in part-item. The daily resupply report will list all items whose on-hand-stock-gty is less than its gty-that's-too-low. But a moment's thought reveals that once listed, an item will continue to be listed every day until resupply arrives and on-hand-stock-gty gets back up to where it should be. Surely, that can't be what was wanted. After it's printed, the report will undoubtedly go to someone in purchasing who buys parts to resupply the stockroom. Assume she immediately orders everything on the first day's report. How will she feel about being harassed every day about those same items until they arrive? When that happens, we know it will be futile to plead that ""We met the goals," for the time-hal- lowed reply is, "What we really wanted was... "—and that path leads to madness. Should we then suppress an item's appearance on the resupply report if it is already on order? Well, not exactly. If on- hand-stock-gty is 13, and gty-that's-too- low is 350, and she ordered 12, she deserves harassing. She should have ordered at least 337. The solution is to report only those items where on-hand-stock-gty plus the sum of all the already-ordered-gtys is less than gty-that's-too-low. This leads us to seek a place to put the guantity and expected arrival date of every outstanding purchase order. In other words, we need a record for each expected part-in event. The future-event pattern happens to have provided just that. As a second example, consider our. supply of framis bearings. This vital component's on-hand-stock-gty is 20. Its gty-that's-too-low is 15. And its sum of al- User inforrnaton Now there's a data design methodolo- 9y for structured analysis that takes advantage of the best of the data-oriented sys- tems design technigues. Logical Data Design for Structured x" , Analysis, a new five-day seminar from Ken Orr 8 Associates, Inc., will teach you how to logically develop a fully normalized data base without the frustrations of classic normalization. "The Missing Link" System Processing Model OO logical J Logical —%, Data Model Dala —ee Working from your system data flows, you will use steps from Ken Orr's Data Structured Systems Development (DSSD") methodology to build a logical data model that can easily be translated to any physical DBMS environment. DSSOD logical data design makes explicit the implicit link between structured analysis and detailed design. Logical Data Design for Structured Analysis — The Missing Link. Jan. 13-17 Atlanta Aug. 25-29 Chicago Mar. 24-28 Portland Nov. 10-14 Kansas City May 5-9 Washington Call toll-tree for more information: 800[255.2459 1725 Gage Bilvd., Topeka, Ks. 66604 Ken Orr 8% Associates, Inc. CIRCLE 65 ON READER CARD 4118 DATAMATION ready-ordered-gty is 10. Since 20 plus 10 is 3 not less than 15, we don't want the thing to show up on report. If it does appear we'll'4 soon have more framis bearings (whatever " they are) than we need. 3 But investigation reveals that Main- x tenance plans to tear down the paraxylene dehydration tower's regeneration loop and'' replace 50 framis bearings as routine pre- ventive maintenance. Conseguently, they' need 50 framis bearings next month, and if we fail to include the item in the report, -$ they might not be ordered in time. CASE IS Don't think this is an un- ; NOTAN usual case to be handled EXCEPTION as an exception. Major : preventive maintenance ' is costly in labor, materials, and (especially) "$ downtime. If we fail to use this information 3 in selecting items for resupply, our system 3 will consistently fail to keep in stock the: very parts that are most needed. Listenl : Did you hear those voices? They sounded :; like, "We met the goals," followed by "What we really wanted was...." Taking preventive maintenance int account, an item should go on report if on hand-stock-gty plus already-ordered-gt minus planned-maint-gty is less than gty- Si that's-too-low. In other words, we need a si record for expected part-out events. We : happen to have one handy. E: Call the two scenarios "resupply '. suppression based on ordered guantity" : and 'resupply triggered by planned use." -ši There's something thought provoking about them. Notice three things: they rep- zi resent significant reguirements, they would not have been noticed, and intuitive solu- tions would have led to blind alleys. They represent significant reguirements because failure to handle either would have made MESPIS unacceptable, generating emergen cy change reguests within days after instal lation. They would not have been noticed because the craft of design centers around asking what output the user wants. Yet nei ther case affects output format or content in the slightest. Intuitive solutions would ši have led to cul-de-sacs because, in both cases, the solutions would have buckled un- $ der postinstallation pressures. Suppressing every item once it's been listed leads to insufficient reorder, and treating routine preventive maintenance as an exception ig- ; nores the heaviest spare parts use ofall. sij Yet the future-event pattern provid- if ed the solution to both, even before the? problems became visible. oi Frank Sweet is corporate manager of data administration for the Charter Co., Jacksonville, Fla.