Presentation is loading. Please wait.

Presentation is loading. Please wait.

Copyright: ©2005 by Elsevier Inc. All rights reserved. 1 Author: Graeme C. Simsion and Graham C. Witt Chapter 10 Logical Database Design.

Similar presentations


Presentation on theme: "Copyright: ©2005 by Elsevier Inc. All rights reserved. 1 Author: Graeme C. Simsion and Graham C. Witt Chapter 10 Logical Database Design."— Presentation transcript:

1 Copyright: ©2005 by Elsevier Inc. All rights reserved. 1 Author: Graeme C. Simsion and Graham C. Witt Chapter 10 Logical Database Design

2 Copyright: ©2005 by Elsevier Inc. All rights reserved. 2 On to data modeling itself… This lecture –The process (uncovered further) –Starting (with conceptual modeling) –Patterns and Generic Models –When there is no pattern top down vs. bottom up modeling –Overwhelming complexity

3 Copyright: ©2005 by Elsevier Inc. All rights reserved. 3 Process and Deliverables in Data Modeling Revisited

4 Copyright: ©2005 by Elsevier Inc. All rights reserved. 4 Data Modelling and Development Methods Iterative / agile approaches will encourage much change Waterfall style approaches have less volatility but still encourages iteration and revision

5 Copyright: ©2005 by Elsevier Inc. All rights reserved. 5 Conceptual, Logical and Physical Models use a three-stage approach delivering, in turn, a conceptual, logical and physical model. This means we can: –more easily trace the reasons for a design decision. –defer some details of the design until they are needed, giving us time to gather information and explore possibilities. –use representation methods and techniques appropriate to the different participants in each stage. –establish reference points if the implementation environment changes (especially performance influences)

6 Copyright: ©2005 by Elsevier Inc. All rights reserved. 6 Conceptual modeling Aim: designing a set of data structures that will meet business requirements determined from an earlier requirements stage Product: Conceputal Model Participants: business specialists, data modelers. Tasks: to discuss and review proposed data concepts and structures without becoming embroiled in the technicalities of DBMS-specific constructs or performance issues. Tools: diagrams and plain language assertions, supported by diagrams, for presenting and discussing the conceptual model.

7 Copyright: ©2005 by Elsevier Inc. All rights reserved. 7 From Conceptual to Logical Model Aim: to properly map the conceptual model to the logical data structures supported by a particular DBMS. Product: Logical Data Model. If the DBMS is relational, the logical model will be documented in terms of tables and columns Participants: Data Modelers, Database Designer (for reviewing the model) Tools: Depends on DBMS

8 Copyright: ©2005 by Elsevier Inc. All rights reserved. 8 From logical to physical model Aim: to cater for performance. Product: Physical Data Model (actually implemented database) including views Participants: Database Designer, Data Modeler (to review), [ with business stakeholders, process modelers, and programmers, according to the scope of changes recommended ] Tasks: to work creatively with the database designer to propose and evaluate changes to the logical model to be incorporated in the physical model, Tools: DBMS catalogue and sometimes a diagram showing the foreign key linkages between tables.

9 Copyright: ©2005 by Elsevier Inc. All rights reserved. 9 Roles and Responsibilities How many and what sort of people should participate in the development of a data model? Two extremes: –a specialist data modeler, working largely alone and gathering information from documentation and one-on-one interviews, and –joint applications development (JAD) style of session, which brings business people, data modelers, and other systems staff together in facilitated workshops. key objectives: (a) we want to produce the best possible models at each stage, and (b) we need to have them accepted by all stakeholders.

10 Copyright: ©2005 by Elsevier Inc. All rights reserved. 10 Conceptual Data Modeling conceptual data modeling involves three main stages: –Identification of requirements (last lecture) –Design of solutions –Evaluation of the solutions. Designing conceptual models is the most difficult stage to learn in data model development

11 Copyright: ©2005 by Elsevier Inc. All rights reserved. 11 How is it done? Data modeling practitioners, like most designers, seldom work from first principles, but adapt solutions that have been used successfully in the past. We look in some detail at two patterns that occur in most models: –hierarchies –one-to-one relationships. Evaluation is through reviews with users and business specialists

12 Copyright: ©2005 by Elsevier Inc. All rights reserved. 12 Starting the Modeling To design a data model from first principles, we classify instances of things of interest to the business into entity classes. Begin by grouping together things that the business handles in a similar manner (and about which it will, therefore, need to keep similar data). –This might seem a straightforward task. On the contrary, similarity can be a very subjective concept: –An insurance company may have assigned responsibility for handling accident and life insurance policies to separate divisions, which have then established different procedures and terminology for handling them. It may take a considerable investigation to determine the underlying degree of similarity.

13 Copyright: ©2005 by Elsevier Inc. All rights reserved. 13 Patterns and Generic Models Experienced data modelers rarely develop their designs from first principles and instead use: –A library of proven structures and structural components, some of them formally documented, –Models remembered from experience or observation. Formal texts ignore this critical and very popular part of data modeling in practice Many industry specific and general libraries are now available

14 Copyright: ©2005 by Elsevier Inc. All rights reserved. 14 Using a Generic Model try to find a generic model that broadly meets the users requirements, then tailor it to suit the particular application, For example, we may need to develop a data model to support human resource management: –Suppose we have seen successful human resources models in the past, and have we (explicitly or just mentally) generalized these to produce a generic model, shown in part in Figure 10.2 (next slide)

15 Copyright: ©2005 by Elsevier Inc. All rights reserved. 15 Generic Human Resources Model

16 Copyright: ©2005 by Elsevier Inc. All rights reserved. 16 Now to narrow down the model! The generic model suggests some questions Does your organization have a formally-defined hierarchy of job positions? –Yes, but theyre outside the scope of this project. We can remove this part of the model. Do you need to keep information about leave taken by employees? –Yes, and one of our problems is to keep track of leave taken without approval, such as strikes. –We will retain Leave Event, possibly subtyped, and add Leave Approval. Perhaps Leave Application with a status of approved or not approved would be better, or should this be an attribute of Leave Event ? Some more focused questions will help with this. Could Leave be approved but not taken? –Certainly. Can one application cover multiple periods of leave? – Not currently. Could our new system support this?

17 Copyright: ©2005 by Elsevier Inc. All rights reserved. 17 Adapting Generic Models from Other Applications Suppose we are developing a model to support the management of public housing. We have not worked in this field before, but we pick up on the central importance of the rental agreement. We recall an insurance model in which the central entity class was Policy an agreement of a different kind, but nevertheless one involving clients and the organization. So lets see about it…

18 Copyright: ©2005 by Elsevier Inc. All rights reserved. 18 Policy vs. Rental Agreement

19 Copyright: ©2005 by Elsevier Inc. All rights reserved. 19 Proceed as before (with a specialist) Who are the parties to a rental agreement? Only persons? Or families or organizations? –Only individuals (tenants) can be parties to a rental agreement, but other occupiers of the house are noted on the agreement. We dont need to keep track of family relationships. Are individual employees involved in rental agreements? In what role? –Yes, each agreement has to be authorized by one of our staff. How do we handle changes to rental agreements? Do we need to keep a history of changes? –Yes, its particularly important that we keep a history of any changes to rent. Sometimes we establish a separate agreement for payment of arrears. What do we do here? Can we treat a rental arrears agreement as a subtype of Agreement ? We can certainly try the idea. …

20 Copyright: ©2005 by Elsevier Inc. All rights reserved. 20 Rental Arrears How do rental arrears agreements differ from ordinary rental agreements? –They always relate back to a basic rental agreement. Otherwise, administration is much the same sending the bill and collecting the scheduled repayments. Can we have more than one rental arrears agreement for a given basic rental agreement? –No, although we may modify the original rental arrears agreement later. The answer provides some support for treating rental arrears agreements similarly to basic rental agreements. Now we can look for further similarities to test the value of our subtyping and refine the model. Do we have different types of rental arrears agreements? Are people directly involved in rental arrears agreements, or are they always the same as those involved in the basic rental agreement? … And so on. Figure 10.5 (next slide) shows an enhanced model including the Rental Arrears Agreement concept.

21 Copyright: ©2005 by Elsevier Inc. All rights reserved. 21 Inclusion of Rental Arrears Agreement

22 Copyright: ©2005 by Elsevier Inc. All rights reserved. 22 When There Is Not a Generic Model Sometimes one cannot find a suitable generic model as a starting point. A good opportunity to develop new generic models. There are essentially two approaches: –bottom up and top down.

23 Copyright: ©2005 by Elsevier Inc. All rights reserved. 23 Bottom-Up Modeling develop a very literal model, based on existing data structures and terminology, use subtyping and supertyping to move towards other options. Work through the example from the text for a air conditioning retailer (pages )

24 Copyright: ©2005 by Elsevier Inc. All rights reserved. 24 Product No.:450TEVolume Discount 2-45% Type:Air Conditioning Unit – Industrial5-1010% Unit Price:$420Over 1012% Sales Tax:3% (except VT/ND: 2%)Service Charges 09Install$35 Delivery Charge:$1001Yearly Service$40 Remote Delivery:$1505Safety Check$10 Insurance:5%

25 Copyright: ©2005 by Elsevier Inc. All rights reserved. 25

26 Copyright: ©2005 by Elsevier Inc. All rights reserved. 26 Top-Down Modeling is an extreme version of the generic model approach use a model that is generic enough to cover at least the main entity classes in any business or organization. The most extreme is starting from the single entity class Thing, and looking for subtypes. We can usually be a little more specific than this!

27 Copyright: ©2005 by Elsevier Inc. All rights reserved. 27 When the Problem is Too Complex Initially narrow your view. Select a specific typical area and model it in isolation. Generalize this to produce a generic model, which you use to investigate other areas. Focus on similarities and differences and on modifying and fleshing out our base model. Which bit to select? We are looking for business activities that are representative of those in other areas. –Many organizations are structured around products, customer types, or geographic locations. –Each organization unit has developed its own procedures and terminology. Thus, by selecting an organizational unit, then generalizing out these factors, is usually a good start.

28 Copyright: ©2005 by Elsevier Inc. All rights reserved. 28 To the final transformations We have examined the process of gathering requirements and of constructing the conceptual model Now it is time to transform that conceptual model into a usable database (thus completing the process / stages we have seen)


Download ppt "Copyright: ©2005 by Elsevier Inc. All rights reserved. 1 Author: Graeme C. Simsion and Graham C. Witt Chapter 10 Logical Database Design."

Similar presentations


Ads by Google