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

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

Author: Graeme C. Simsion and Graham C. Witt

Chapter 10

Logical Database Design


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


Process and Deliverables in Data Modeling Revisited

DesignPhysical

Data Model

DesignLogical

Data Model

BuildConceptualData Model

DevelopInformation

Requirements

Data Modeler

Database Designer

BusinessSpecialist

ReviewInformation

Requirements

BusinessSpecialist

ReviewConceptualData Model

ReviewLogical

Data Model

ReviewPhysical

Data Model

Data Modeler

Database Designer

Business Requirements

Information Requirements

DBMS & Platform

Specification

Performance Requirements

Conceptual Data Model

Logical Data Model

Physical Data Model


Data Modelling and Development Methods

• Iterative / agile approaches will encourage much change

• Waterfall style approaches have less volatility but still encourages iteration and revision


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)


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.


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


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.


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.


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


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


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.


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


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)


Generic Human Resources Model

Employee EventOrganization

Unit

JobPosition

Skill

Employee

Contractor

Human Resource

berequired by

require

be occupied by

occupy

be possessed by

possess

be involved in

involve

include

bepart

of

manage

reportto

Miscellaneous Event

AppraisalEvent

PromotionEvent

Transfer Event

LeaveEvent

Human Resource Event

HireEvent

TerminationEvent

be involved in

involve


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?”


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 Policyan agreement of a different kind, but nevertheless one involving clients and the organization. So let’s see about it…


Policy vs. Rental Agreement

PolicyType

OrganizationUnit

Policy

Non-Employee

Employee

. . .

Assignment

Claim

BillingTransaction

PolicyAlteration

Person

Policy Event

PersonRole inPolicy

beclassified by classify

affect be affected

bybe for

involve

play

be played by

be issued by

issue

be partof

include

RentalAgreement

Type

OrganizationUnit

RentalAgreement

Renter

. . .

RentalPayment

RentalAgreementAlteration

Person

Rental AgreementEvent

PersonRole inRental

Agreement


affect be affected

bybe for

involve

play

be played by

be managed by

manage

be partof

include

Employee

Other Occupier


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.

• …


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.


Inclusion of Rental Arrears

Agreement Rental Agreement

RentalAgreement

Type

OrganizationUnit

RentalArrears

Agreement

Person Rolein Rental

Agreement


affect be affected by

be for

involve

play

be played by

be managed by

manage

be partof

include

BasicRental

Agreement

supplement

besupplemented

by

Person

Renter

. . .

RentalPayment

RentalAgreementAlteration

Rental AgreementEvent

Employee

Other Occupier


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


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 285-288)


Product No.: 450TE VolumeDiscount

2-4 5%

Type: Air Conditioning Unit – Industrial 5-10 10%

Unit Price: $420 Over 10 12%

Sales Tax: 3% (except VT/ND: 2%) ServiceCharges

09 Install $35

Delivery Charge: $10 01 Yearly Service $40

Remote Delivery: $15 05 Safety Check $10

Insurance: 5%

ProductProductSalesTax

VolumeDiscount

DeliveryCharge

ServiceCharge

be subject to

apply to

apply be to subject to

apply to

be subject to

apply to

be subject to


Product

ProductSalesTax

VolumeDiscount

DeliveryCharge

ServiceCharge

InsuranceCharge

Additional Chargeor Discount

be subject to

apply toProduct

ProductSalesTax

VolumeDiscount

DeliveryCharge

ServiceCharge

InsuranceCharge

Additional Chargeor Discount

be subject to

apply toBase PriceVariation

PhysicalProduct

ProductSalesTax

VolumeDiscount

DeliveryCharge

InsuranceCharge

be subject to

apply to

Base PriceVariation

ServiceProduct

Product

apply to

haveassociated


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!


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.


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. 1 Author: Graeme C. Simsion and Graham C. Witt Chapter 10 Logical Database Design.

Documents

logical data model

physical data model

data model development

data modelers

similar data

data modeling revisited

logical data structures

data modelling