0% found this document useful (0 votes)
138 views

Physical Database Design

The document discusses the steps in physical database design which includes translating the logical data model for the target DBMS, designing the physical representation through analyzing transactions, choosing file organizations and indexes, estimating storage needs. It also covers designing user views, security, redundancy, and monitoring the operational system. The goal is to describe how the database will be implemented and organized on secondary storage for efficient data access.

Uploaded by

Smachew Gedefaw
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
138 views

Physical Database Design

The document discusses the steps in physical database design which includes translating the logical data model for the target DBMS, designing the physical representation through analyzing transactions, choosing file organizations and indexes, estimating storage needs. It also covers designing user views, security, redundancy, and monitoring the operational system. The goal is to describe how the database will be implemented and organized on secondary storage for efficient data access.

Uploaded by

Smachew Gedefaw
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 13

Chapter 5

Physical Database Design

1
Introduction
 The Logical database design is concerned with the
what;
 ƒThe Physical database design is concerned with
the how.
 ƒPhysical database design is the process of
producing a description of the implementation of
the database on secondary storage.
 It describes the base relations, file
organization, and indexes used to achieve
effective access to the data along with any
associated integrity constraints and security
measures.
2
Cont…
 Physical design describes the base relation, file
organization, and indexes used to achieve efficient
access to the data, and any associated integrity
constraints and security measures.
 ƒ
Sources of information for the physical design
process include global logical data model and
documentation that describes model.
 ƒ
Describes the storage structures and access
methods used to achieve efficient access to the data
 ƒKnowledge of the DBMS that is selected to host
the database systems, with all its functionalities, is
required since functionalities of current DBMS vary
widely.

3
Steps in physical database design
1.Translate logical data model for target DBMS
 ƒTo determine the file organizations and access
methods that will be used to store the base
relations; i.e. the way in which relations and tuples
will be held on secondary storage
 To decide how to represent the base relations we
have identified in the global logical data model
in the target DBMS.
 ƒDesign enterprise constraints for target DBMS
1.1. Design base relation
1.2. Design representation of derived data
1.3. Design enterprise constraint
4
Cont…
2. Design physical representation
2.1 Analyze transactions
◦ To understand the functionality of the transactions
that will run on the database and to analyze the
important transactions
2.2 Choose file organization
◦ To determine an efficient file organization for each
base relation
2.3 Choose indexes
2.4 Estimate disk space and system
requirement
◦ To estimate the amount of disk space that will be
required by the database
5
Cont…
3. Design user view
 To design the user views that were identified in the
conceptual database design methodology
4. Design security mechanisms
5. Consider controlled redundancy
 To determine whether introducing redundancy in a
controlled manner by relaxing the normalization
rules will improve the performance of the system.
6. Monitor and tune the operational system
Design access rules
 To design the access rules to the base relations and
user views

6
1. Translate logical data model for
target DBMS
 This phase is the translation of the global
logical data model to produce a relational
database schema in the target DBMS.
 This includes creating the data dictionary
based on the logical model and information
gathered.
 After the creation of the data dictionary, the
next activity is to understand the
functionality of the target DBMS so that all
necessary requirements are fulfilled for the
database intended to be developed.
7
Cont…
Knowledge of the DBMS includes:
 how to create base relations
 whether the system supports:
◦ definition of Primary key
◦ definition of Foreign key
◦ definition of Alternate key
◦ definition of Domains
◦ Referential integrity constraints
◦ definition of enterprise level constraints
8
1.1Design base relation
 Designing base relation involves
identification of all necessary
requirements about a relation starting from
the name up to the referential integrity
constraints.
 The implementation of the physical model is
dependent on the target DBMS since some
has more facilities than the other in defining
database definitions.
 The base relation design along with every
justifiable reason should be fully documented.

9
1.2. Design representation of derived data
 While analyzing the requirement of users, we may
encounter that there are some attributes holding
data that will be derived from existing or other
attributes.
 A decision on how to represent such data should
be devised
 Most of the time derived attributes are not
expressed in the logical model but will be included
in the data dictionary.
 Whether to store stored attributes in a base
relation or calculate them when required is a
decision to be made by the designer considering
the performance impact.
 The representation of derived attributes should be
fully documented.
10
1.3. Design enterprise constraint
 Data in the database is not only subjected
to constraints on the database and the data
model used but also with some enterprise
dependent constraints.
 This constraint definition is also
dependent on the DBMS selected and
enterprise level requirements.
 All the enterprise level constraints and the
definition method in the target DBMS
should be fully documented.
11
2. Design physical representation
 This phase is the level for determining the
optimal file organizations to store the
base relations and indexes that are
required to achieve acceptable
performance, that is, the way in which
relations and tuples will be held on the
secondary storage.

12
Cont…
2.1. Analyze transactions
2.2. Choose file organization
2.3. Choose indexes
2.4. Estimate disk space and system requirement
3. Design user view
4. Design security mechanisms
5. Consider controlled redundancy
6. Monitor and tune the operational system

13

You might also like