1. Chapter 10 Logical Database Design
Author: Graeme C. Simsion and Graham C. Witt
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
Copyright: ©2005 by Elsevier Inc. All rights reserved.

3. Process and Deliverables in Data Modeling Revisited
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
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)
Copyright: ©2005 by Elsevier Inc. All rights reserved.

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

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
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.
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.
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
Copyright: ©2005 by Elsevier Inc. All rights reserved.

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

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

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
Copyright: ©2005 by Elsevier Inc. All rights reserved.

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

15. Generic Human Resources Model
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 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.

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 let’s see about it…
Copyright: ©2005 by Elsevier Inc. All rights reserved.

18. Policy vs. Rental Agreement
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 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.

20. 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 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.
Copyright: ©2005 by Elsevier Inc. All rights reserved.

21. Inclusion of Rental Arrears Agreement
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.”
Copyright: ©2005 by Elsevier Inc. All rights reserved.

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

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

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

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

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.
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)
Copyright: ©2005 by Elsevier Inc. All rights reserved.