Chapter 12

Physical Database Design ² Step 3

(Translate Logical Design)
Transparencies

|
 
     
 
 Chapter 12 - Objectives
0 Purpose of physical database design.
0 How to map the logical database
design to a physical database design.
0 How to design base tables for target
DBMS.
0 How to design representation of
derived data.
0 How to design business rules for
target DBMS. |
 
     
 
 Logical Ä Physical Database Design
0 Logical db design independent of
implementation details, such as
functionality of target DBMS.
0 Logical db design concerned with the Œ
,
physical database design is concerned with
the Œ.
0 Sources of information for physical design
includes logical data model and data
dictionary.
|
 
     
 
Physical Database Design
Process of producing a description of
implementation of the database on
secondary storage.
It describes base tables, file organizations,
and indexes used to achieve efficient
access to the data, and any associated
integrity constraints and security
restrictions.
|
 
     
 
 Overview of Physical Database
Design Methodology

0 Step 3 Translate logical database design for

target DBMS
0 Step 4 Choose file organizations and indexes
0 Step 5 Design user views
0 Step 6 Design security mechanisms
0 Step 7 Consider introduction of controlled
redundancy
0 Step 8 Monitor and tune operational system
|
 
     
 
 Step 3 Translate logical database
design for target DBMS

To produce a basic working relational

database from the logical data model.
0 Consists of the following steps:
0 Step 3.1 Design base tables

0 Step 3.2 Design representation of

derived data
0 Step 3.3 Design remaining business rules

|
 
     
 
 Step 3 Translate logical database
design for target DBMS

0 ·eed to know functionality of target DBMS

such as how to create base tables and
whether DBMS supports the definition of:
0 PKs, FKs, and AKs;
0 required data ² i.e. whether system supports
·OT · LL;
0 domains;
0 relational integrity rules;
0 business rules.
|
 
     
 
 Step 3.1 Design base tables

To decide how to represent base

tables identified in logical model in
target DBMS.
0 ·eed to collate and assimilate the
information about tables produced during
logical database design (from data
dictionary and tables defined in DBDL).

|
 
     
 
 Step 3.1 Design base tables
0 For each table, need to define:
0 name of the table;
0 list of simple columns in brackets;

0 PK and, where appropriate, AKs and FKs.

0 referential integrity constraints for any FKs

identified.
0 For each column, need to define:
0 its domain, consisting of a data type, length,
and any constraints on the domain;
0 an optional default value for the column;

0 whether the column can hold nulls.

|
 
     
 
DBDL for the Branch table

|
 
     
 
 Step 3.2 Design representation of
derived data

To design the representation of

derived data in the database.
0 Produce list of all derived columns from
logical data model and data dictionary.
0 Derived column can be stored in database
or calculated every time it is needed.

|
 
     
 
 Step 3.2 Design representation of
derived data
0 Option selected is based on:
0 additional cost to store the derived data and
keep it consistent with data from which it is
derived;
0 cost to calculate it each time it·s required.

0 Less expensive option is chosen subject to

performance constraints.

|
 
     
 
MentalAgreement and Member with
derived column noOfMentals

|
 
     
 
 Step 3.3 Design remaining
business rules

To design the remaining business rules

for the target DBMS.
0 Some DBMS provide more facilities than
others for defining business rules. Example:

CO·STMAI·T member_not_renting_too_many
CHECK (·OT EXISTS (SELECT member·o
FMOM MentalAgreement
GMO P BY member·o
HAVI·G
|
 CO ·T(*) > 10))