We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byBlake Wilson
Modified over 3 years ago
Chapter 10 Logical Database DesignAuthor: Graeme C. Simsion and Graham C. Witt Copyright: ©2005 by Elsevier Inc. All rights reserved.
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 Copyright: ©2005 by Elsevier Inc. All rights reserved.
Process and Deliverables in Data Modeling RevisitedCopyright: ©2005 by Elsevier Inc. All rights reserved.
Data Modelling and Development MethodsIterative / agile approaches will encourage much change Waterfall style approaches have less volatility but still encourages iteration and revision Copyright: ©2005 by Elsevier Inc. All rights reserved.
Conceptual, Logical and Physical Modelsuse 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) Copyright: ©2005 by Elsevier Inc. All rights reserved.
Copyright: ©2005 by Elsevier Inc. All rights reserved.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. Copyright: ©2005 by Elsevier Inc. All rights reserved.
From Conceptual to Logical ModelAim: 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 Copyright: ©2005 by Elsevier Inc. All rights reserved.
From logical to physical modelAim: 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. Copyright: ©2005 by Elsevier Inc. All rights reserved.
Roles and ResponsibilitiesHow 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. Copyright: ©2005 by Elsevier Inc. All rights reserved.
Conceptual Data Modelingconceptual 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 Copyright: ©2005 by Elsevier Inc. All rights reserved.
Copyright: ©2005 by Elsevier Inc. All rights reserved.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 Copyright: ©2005 by Elsevier Inc. All rights reserved.
Copyright: ©2005 by Elsevier Inc. All rights reserved.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. Copyright: ©2005 by Elsevier Inc. All rights reserved.
Patterns and Generic ModelsExperienced 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 Copyright: ©2005 by Elsevier Inc. All rights reserved.
Copyright: ©2005 by Elsevier Inc. All rights reserved.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) Copyright: ©2005 by Elsevier Inc. All rights reserved.
Generic Human Resources ModelCopyright: ©2005 by Elsevier Inc. All rights reserved.
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 they’re 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?” Copyright: ©2005 by Elsevier Inc. All rights reserved.
Adapting Generic Models from Other ApplicationsSuppose 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 Policyan agreement of a different kind, but nevertheless one involving clients and the organization. So let’s see about it… Copyright: ©2005 by Elsevier Inc. All rights reserved.
Policy vs. Rental AgreementCopyright: ©2005 by Elsevier Inc. All rights reserved.
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 don’t 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, it’s 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. … Copyright: ©2005 by Elsevier Inc. All rights reserved.
Copyright: ©2005 by Elsevier Inc. All rights reserved.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 samesending 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. Copyright: ©2005 by Elsevier Inc. All rights reserved.
Inclusion of Rental Arrears AgreementCopyright: ©2005 by Elsevier Inc. All rights reserved.
When There Is Not a Generic ModelSometimes 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.” Copyright: ©2005 by Elsevier Inc. All rights reserved.
Copyright: ©2005 by Elsevier Inc. All rights reserved.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 ) Copyright: ©2005 by Elsevier Inc. All rights reserved.
Copyright: ©2005 by Elsevier Inc. All rights reserved.Product No.: 450TE Volume Discount 2-4 5% Type: Air Conditioning Unit – Industrial 5-10 10% Unit Price: $420 Over 10 12% Sales Tax: 3% (except VT/ND: 2%) Service Charges 09 Install $35 Delivery Charge: $10 01 Yearly Service $40 Remote Delivery: $15 05 Safety Check Insurance: Copyright: ©2005 by Elsevier Inc. All rights reserved.
Copyright: ©2005 by Elsevier Inc. All rights reserved.
Copyright: ©2005 by Elsevier Inc. All rights reserved.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! Copyright: ©2005 by Elsevier Inc. All rights reserved.
When the Problem is Too ComplexInitially 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. Copyright: ©2005 by Elsevier Inc. All rights reserved.
To the final transformationsWe 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) Copyright: ©2005 by Elsevier Inc. All rights reserved.
Business Intelligence and Analytics: Systems for Decision Support (10 th Edition) Conceptual Model Development Business Intelligence and Analytics: Systems.
Author: Graeme C. Simsion and Graham C. Witt Chapter 8 Organizing the Data Modeling Task.
Author: Graeme C. Simsion and Graham C. Witt Chapter 4 Subtypes & Supertypes.
Author: Graeme C. Simsion and Graham C. Witt Chapter 6 Primary Keys and Identity.
Copyright: ©2005 by Elsevier Inc. All rights reserved. 1 Author: Graeme C. Simsion and Graham C. Witt Chapter 3 The Entity-Relationship Approach.
Author: Graeme C. Simsion and Graham C. Witt Chapter 7 Extensions and Alternatives.
Author: Graeme C. Simsion and Graham C. Witt Chapter 11 Logical Database Design.
Week 2 The Object-Oriented Approach to Requirements
McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 12 View Design and Integration.
Author: Graeme C. Simsion and Graham C. Witt Chapter 9 Understanding the Business Requirements.
SYSTEM ANALYSIS AND DESIGN
Conceptual / semantic modelling
Database Design Using the REA Data Model
Requirements Engineering Process
1 Copyright © 2010, Elsevier Inc. All rights Reserved Fig 2.1 Chapter 2.
Lecture 6: Software Design (Part I)
the Entity-Relationship (ER) Model
Module N° 7 – Introduction to SMS
Chapter 2 Entity-Relationship Data Modeling: Tools and Techniques
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 28 Slide 1 Process Improvement 1.
Fundamentals of Information Systems, Second Edition
Chapter 1 The Study of Body Function Image PowerPoint
Copyright © 2011, Elsevier Inc. All rights reserved. Chapter 5 Author: Julia Richards and R. Scott Hawley.
Project Cycle Management and Statistics
Fact-finding Techniques Transparencies
Basic Principles of GMP
Database Design: ER Modelling (Continued)
Copyright © 2011, Elsevier Inc. All rights reserved. Chapter 6 Author: Julia Richards and R. Scott Hawley.
Entity Relationship (E-R) Modeling
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 25 Slide 1 Chapter 25 Process Improvement.
Modern Systems Analyst and as a Project Manager
Lecture plan Outline of DB design process Entity-relationship model
Chapter 7 System Models.
Fundamentals of Information Systems, Second Edition 1 Systems Development.
Author: Julia Richards and R. Scott Hawley
Chapter 6 Flowcharting.
1 of 19 Organization and Management New Structures and Alliances IMARK Investing in Information for Development Organization and Management New Structures.
SDLC and Related Methodologies
1 Dr. Ashraf El-Farghly SECC. 2 Level 3 focus on the organization - Best practices are gathered across the organization. - Processes are tailored depending.
EMS Checklist (ISO model)
Software change management
Chapter 5 Transfer of Training
Chapter 4 Project Management.
Data Flow Diagrams Supplementary material to support Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design Using UML, (4th Edition),
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 27 Slide 1 Quality Management.
1 According to PETROSAFE safety policy, the company is keen that: Introduction All Egyptian Petroleum companies and foreign companies working in A.R.E.
Designing Organizational Structure: Specialization and Coordination
© 2017 SlidePlayer.com Inc. All rights reserved.