Chapter 5

Physical Database
Design
1
Physical Database Design

Physical database design is the process of
translating the logical structure of a
database, as defined in the conceptual and
logical design phases, into a physical
structure that can be implemented on a
specific database management system
(DBMS).

This involves specifying how the data will be
stored, accessed, and managed on physical
storage devices.

2
Cont...
 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.

3
 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 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.
4
 Cont…
Example:

Consider a logical database design for a
library system that includes entities like
Books, Authors, and Members.

The physical database design would
involve decisions such as:
-Choosing appropriate data types (e.g.,
VARCHAR for book titles, INT for
member IDs).
-Partitioning the Books table based on
genres to improve query performance.

5
 Cont…

In general, physical database design
transforms the abstract concepts of a
logical model into a practical
implementation, focusing on
performance, efficiency, and data
integrity in a specific database
environment.

6
 Steps in physical database
design
1. Translate logical data model for target DBMS
 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

 When designing a database for an enterprise, several key

concepts must be considered to ensure that the database
meets the business requirements and operates efficiently
within the chosen Database Management System (DBMS).
Below are explanations for each component:
1.1. Design base relation
1.2. Design representation of derived data
1.3. Design enterprise constraint

7
 1.1 Design Base Relation
 Base relations are the fundamental tables in a database that
store actual data. Each base relation corresponds to an entity
or a relationship defined in the data model.

 Steps to Design Base Relations:

 Identify Entities: Determine the main entities in the
enterprise (e.g., Customers, Orders, Products).
 Define Attributes: List the attributes for each entity that

need to be stored (e.g., CustomerName, OrderDate,

ProductPrice).
 Establish Keys: Choose primary keys for each base relation

to uniquely identify records (e.g., CustomerID, OrderID).

 Determine Relationships: Identify how entities relate to

each other (e.g., a Customer can place multiple Orders).

8
 1.2 Design Representation
of Derived Data

Derived data is information that can be calculated
or derived from other data within the database
rather than being stored directly. This can include
aggregations, calculations, or transformations.


Identify Derived Data Needs: Determine
what derived data will be useful for the
enterprise (e.g., total sales, average order
value).


Decide on Calculation Methods: Identify
how the derived data will be calculated
(e.g., sum, average, count).
9
 1.3 Design Enterprise
Constraints

Enterprise constraints are rules that dictate how
data can be entered, modified, and maintained in
the database. These constraints are essential for
ensuring data integrity, consistency, and
compliance with business rules.


Check Constraints: Validate data entry
based on specific conditions (e.g.,
OrderDate must be in the past).


Not Null Constraints: Ensure that certain
fields cannot be left empty (e.g.,
CustomerName must not be null).
10
 Cont…
2. Design physical representation

involves translating the logical design into a
concrete implementation that can be
efficiently executed on a specific database
management system (DBMS).

This process ensures that the database can
handle transactions effectively and utilize
storage resources optimally.

Below are the key components of this
design phase:
11
 Cont…
2.1 Analyze transactions

Analyzing transactions involves
understanding the operations that will be
performed on the database, including their
frequency, complexity, and business
significance.

This includes
-Identify Key Transactions
-Understand Transaction Characteristics
-Assess Transaction Frequency
12
 Cont…
2.2 Choose file organization

File organization refers to how data is
physically stored on disk. The choice of file
organization can significantly impact
performance, especially for read and write
operations.

13
 Cont…
2.3 Choose indexes

Indexes are data structures that improve the
speed of data retrieval operations on a
database table. Choosing the right indexes
is crucial for optimizing query performance.

14
 Cont…
2.4 Estimate disk space and system
requirement
◦To estimate the amount of disk space that
will be required by the database
◦Estimating disk space and system
requirements involves calculating the
amount of storage needed for the
database, including data, indexes, and
overhead.
◦This estimation helps in planning for
hardware resources and capacity.

15
 Cont…
3. Design user view
 Designing user views involves creating specific
representations of the database tailored to the needs of
different user groups.
 User views present a subset of the data, often filtered or
structured in a way that simplifies access for end-users,
ensuring that they can interact with the data relevant to their
roles without being overwhelmed by the entire database
schema.
 Identify User Roles: Determine who will be using the
database and their specific requirements (e.g., sales
representatives, managers, analysts).

 Define View Requirements: For each user role, identify

what data they need to see, including necessary attributes
and any calculations or derived data.

16
 Cont…
4. Design security mechanisms
 Designing security mechanisms involves establishing

protocols and rules to protect the database from

unauthorized access, ensuring that sensitive data is
safeguarded and that only authorized users can perform
certain actions.
 Key Components of Security Mechanisms:
 User Authentication: Implement methods to verify user
identities (e.g., username/password, multi-factor
authentication).
 Authorization: Define roles and permissions associated

with each user, detailing what data they can access and
what operations they can perform.
 Encryption: Utilize encryption techniques for sensitive data

storage and transmission to protect against data breaches.

17
 Cont…
5. Consider controlled redundancy

 Controlled redundancy refers to the deliberate introduction

of duplicate data into the database schema to enhance
performance without compromising data integrity.
 This approach may involve relaxing normalization rules in
certain areas where performance benefits outweigh the risks
of redundancy.
6. Monitor and tune the operational system

 Monitoring and tuning the operational system involves

continuously assessing the database performance and
making adjustments as needed to ensure optimal operation.
This includes analyzing query performance, system resource
usage, and user interactions.

18
End!

19