Transcript Methodology – Physical Database Design

Chapter 10
Methodology Physical Database Design
Chapter 18, Appendix F in Textbook
Design Methodology
Review
A structured approach that uses procedures, techniques, tools,
and documentation aids to support and facilitate the process of
design.
Conceptual DB Design
2
Database Design Review
Hardware independent
Software independent
Conceptual
DB design
Hardware independent
Software dependent
Logical
DB design
Hardware dependent
Software dependent
Physical
DB design
Physical DB Design
3
Design Methodology Overview
Review
Step 1 Build local conceptual data model for each user view.
Step 2 Build and validate local logical data model for each view.
Step 3 Build and validate global logical data model.
Step 4 Translate global logical data model for target DBMS.
Step 5 Design physical representation.
Step 6 Design user views.
Step 7 Design security mechanisms.
Step 8 Consider the introduction of controlled redundancy.
Step 9 Monitor and tune the operational system.
Physical DB Design
4
Comparison of Logical and
Physical Database Design
Logical database design is concerned with the what,
Physical database design is concerned with the how.
Process of producing a description of the implementation of the database on
secondary storage; it describes the base relations, file organizations, and
indexes used to achieve efficient access to the data, and any associated integrity
constraints and security measures.
Physical DB Design
5
Overview of Physical Database
Design Methodology
Step 4 Translate global logical data model for target DBMS
Step 4.1 Design base relations
Step 4.2 Design representation of derived data
Step 4.3 Design enterprise constraints
Step 5 Design physical representation
Step 5.1 Analyze transactions
Step 5.2 Choose file organizations
Step 5.3 Choose indexes
Step 5.4 Estimate disk space requirements
Physical DB Design
6
Overview of Physical Database
Design Methodology
Step 6 Design user views
Step 7 Design security mechanisms
Step 8 Consider the introduction of controlled redundancy
Step 9 Monitor and tune the operational system
Physical DB Design
7
Step 4 Translate Global Logical
Data Model for Target DBMS
Objective: To produce a relational database schema that can be implemented in
the target DBMS from the global logical data model.
Need to know functionality of target DBMS such as how to create base relations
and whether the system supports the definition of:
– PKs, FKs, and AKs;
– required data (NOT NULL);
– domains;
– relational integrity constraints;
– enterprise constraints.
Physical DB Design
8
Step 4.1 Design Base Relations
Objective: To decide how to represent base relations identified in global logical
model in target DBMS.
For each relation, need to define:
– the name of the relation;
– a list of simple attributes in brackets;
– the PK and, where appropriate, AKs and FKs.
– a list of any derived attributes and how they should be computed;
– referential integrity constraints for any FKs identified.
Physical DB Design
9
Step 4.1 Design Base Relations
For each attribute, need to define:
– its domain, consisting of a data type, length, and any constraints on the
domain;
– an optional default value for the attribute;
– whether the attribute can hold nulls.
Physical DB Design
10
PropertyForRent Relation
Domain PropertyNumber: variable length character string, length 5
Domain street:
variable length character string, length 25
Domain city:
variable length character string, length 15
:
PROPERTYFORRENT(
propertyNo
PropertyNumber NOT NULL,
Street
street
NOT NULL,
City
city
NOY NULL,
:
PRIMARY KEY(propertyNo),
FOREIGN KEY (staffNo) REFERENCES staff(staffNO)
ON UPDATE CASCADE ON DELETE SET NULL,
FOREIGN KEY (ownerNo) REFERENCES POwner(ownerNO)
ON UPDATE CASCADE ON DELETE SET NULL);
Physical DB Design
11
Step 4.2 Design Representation of
Derived Data
Objective: To decide how to represent any derived data present in the global
logical data model in the target DBMS.
Derived attribute can be stored in database or calculated every time it is needed.
Option selected is based on:
– additional cost to store the derived data and keep it consistent with
operational data from which it is derived;
– cost to calculate it each time it is required.
Physical DB Design
12
STAFF
StaffNo
Physical DB Design
FName
LName
BrnNo
NoPro
SL21
John
White
B005
0
SG37
Ann
Beech
B003
2
SG14
David
Ford
B003
1
SA9
Mary
Howe
B007
1
SG5
Susan
Brand
B003
0
SL41
Julie
Lee
B005
1
13
Step 4.3 Design Enterprise
Constraints
Objective: To design the enterprise constraints for the target DBMS.
Some DBMS provide more facilities than others for defining enterprise
constraints.
Example:
CONSTRAINT StaffNotHandlingTooMuch
CHECK (NOT EXISTS (SELECT staffNo
FROM PropertyForRent
GROUP BY staffNo
HAVING COUNT(*) > 100))
Physical DB Design
14
Step 5 Design Physical
Representation
Objective: To determine optimal file organizations to store the base relations and
the indexes that are required to achieve acceptable performance; that is, the way
in which relations and tuples will be held on secondary storage.
Physical DB Design
15
Step 5 Design Physical
Representation
Number of factors that may be used to measure efficiency:
- Transaction throughput: number of transactions processed in given time
interval.
- Response time: elapsed time for completion of a single transaction.
- Disk storage: amount of disk space required to store database files.
However, no one factor is always correct. Typically, have to trade one factor off
against another to achieve a reasonable balance.
Physical DB Design
16
Step 5.1 Analyze Transactions
Objective: To understand the functionality of the transactions that will run on the
database and to analyze the important transactions.
Attempt to identify performance criteria, such as:
– transactions that run frequently and will have a significant impact on
performance;
– transactions that are critical to the business;
– times during the day/week when there will be a high demand made on the
database (called the peak load).
Physical DB Design
17
Step 5.1 Analyze Transactions
Use this information to identify the parts of the database that may cause
performance problems.
To select appropriate file organizations and indexes, also need to know high-level
functionality of the transactions, such as:
• attributes that are updated in an update transaction;
• criteria used to restrict tuples that are retrieved in a query.
Often not possible to analyze all expected transactions, so investigate most
‘important’ ones.
Physical DB Design
18
Step 5.1 Analyze Transactions
To focus on areas that may be problematic:
(1) Map all transaction paths to relations.
(2) Determine which relations are most frequently accessed by transactions.
(3) Analyze the data usage of selected transactions that involve these relations.
Physical DB Design
19
Transaction’s Pathways for Global View
StaffNo
(b)
SUPERVISOR
STAFF
(a)
register
(0,*)
(0,100)
(e)
(d)
manage
OwnerNo
PropertyNo
(0,1)
(c,g)
(1,*)
OWNER
VDate
(1:1)
(1,1)
PROPERTY
BOwn
(0,*)
(0,*)
d
(l)
PRIVATE
OWNER
Comment
(h,i)
associate
BUSINESS
OWNER
LEASE
(k)
(j)
(1:1)
(0,*)
ClientNo
CLIENT
(0,*)
hold
(1:1)
LeaseNo
views
(1:1)
state
(m)
(1:1)
PREFERENCE
Transaction Usage Map
Avg = 20
Max= 40
STAFF
2000
Avg = 50
Max= 100
(E)
Physical DB Design
manage
has
(C)
BRANCH
100
(F)
Avg = 1000
Max= 3000
PROPERTY
100000
offer
(D)
21
Transaction Analysis Form
22
Step 5.2 Choose File Organizations
Objective: To determine an efficient file organization for each base relation.
File organizations include:
• Heap (unordered)
• Ordered
• Hash
• Indexed Sequential Access Method (ISAM)
• B+-Tree
Physical DB Design
23
Indexes
A data structure that allows the DBMS to locate particular records in a file more
quickly and thereby speed response to user queries.
Types of Indexes:
• Primary Index: the data file is sequentially ordered by an ordering key field,
and the indexing field is built on the ordering key field (unique).
• Clustering Index: the data file is sequentially ordered on a non-key field (not
distinct), and the indexing field is built on this non-key field (clustering
attribute).
• Secondary Index: an index that is defined on a non-ordering field of the data
file (distinct or not).
A file can have at most 1 primary index or clustering index, and several secondary
indexes.
24
Index Example
STAFF
(brnNo)
SG14
John
White
18000
B005
B003
SG37
Ann
Beech
12000
B003
B003
SL21
David
Ford
30000
B003
B005
SL41
Mary
Howe
9000
B007
B007
Physical DB Design
Data File
Index File
Of any file organization
ordered
25
Primary Index Example
Anchor record
index
S5
S14
S37
Physical DB Design
1
2
3
Data file
S5 Record
S9 Record
S14 Record
S21 Record
S37 Record
S41 Record
page
1
2
3
26
Cluster Index Example
Data file
index
S5
S14
S21
1
2
3
S5 Record
S5 Record
S14 Record
S14 Record
S14 Record
S21 Record
page
1
2
3
Physical DB Design
27
Indexes
STAFF
(salary, brnNo)
StaffNo
FName
LName
Salary
9000, B007
12000,B003
18000,B005
30000,B003
Physical DB Design
BrnNo
(salary)
SG14
John
White
18000
B005
9000
SG37
Ann
Beech
12000
B003
12000
SL21
David
Ford
30000
B003
18000
SL41
Mary
Howe
9000
B007
30000
28
Index Categories
Data file
index
Dense index
S5
S9
S14
S21
S37
S41
1
1
2
2
3
3
index
Sparse index
Physical DB Design
S5
S14
S37
1
2
3
S5 Record
S9 Record
S14 Record
S21 Record
S37 Record
S41 Record
Data file
S5 Record
S9 Record
S14 Record
S21 Record
S37 Record
S41 Record
page
1
2
3
page
1
2
3
29
Multilevel Index
Level 2 Index
S5
S37
Level 1 Index
S5
S14
S37
S56
Physical DB Design
Data file
page
1
S5 Record
S9 Record
S14 Record
S21 Record
S37 Record
S41 Record
S56 Record
S87 Record
2
3
4
30
Step 5.3 Choose Indexes
Objective: To determine whether adding indexes will improve the performance of
the system.
Two approaches:
•
Keep tuples unordered and create many secondary indexes.
•
Order tuples in the relation by specifying a primary or clustering index.
Choose the attribute for ordering the tuples as:
– attribute that is used most often for join operations.
– attribute that is used most often to access the tuples in a relation in order of
that attribute.
Example:
CREATE UNIQUE INDEX PropertyNoInd ON PropertyForRent(PNo);
CREATE INDEX StaffNoInd ON PropertyForRent(StaffNo) CLUSTER;
31
Choose Secondary Indexes
• Overhead involved in maintenance and use of secondary indexes that has to be
balanced against performance improvement gained when retrieving data. This
includes:
– adding an index record to every secondary index whenever tuple is
inserted;
– updating a secondary index when corresponding tuple is updated;
– increase in disk space needed to store the secondary index.
Physical DB Design
32
Guidelines for Choosing Indexes
(1) Do not index small relations.
(2) Index PK of a relation if it is not a key of the file organization.
(3) Add secondary index to a FK if it is frequently accessed.
(4) Add secondary index to any attribute that is heavily used as a secondary key.
(5) Add secondary index on attributes that are involved in: selection or join
criteria; ORDER BY; GROUP BY; and other operations involving sorting
(such as UNION or DISTINCT).
Physical DB Design
33
Guidelines for Choosing Indexes
(6) Add secondary index on attributes involved in built-in functions.
SELECT branchNo, AVG(salary)
FROM Staff
GROUP BY branchNo;
(7) Add secondary index on attributes that could result in an index-only plan.
(8) Avoid indexing an attribute or relation that is frequently updated.
(9) Avoid indexing an attribute if the query will retrieve a significant proportion of
the tuples in the relation.
(10) Avoid indexing attributes that consist of long character strings.
Physical DB Design
34
Additional Indexes
Physical DB Design
Table
Index
Staff
FName, LName
SupervisorStaffNo
Position
Client
StaffNo
FName, LName
PropertyForRent
OwnerNo
StaffNo
ClientNo
RentFinish
City
Rent
Viewing
ClientNo
35
Step 5.4 Estimate Disk Space
Requirements
Objective: To estimate the amount of disk space that will be required by the
database.
Estimating the disk usage is highly dependent on the target DBMS and hardware
used to support the database.
The estimate is based on:
– Size of each tuple.
– Maximum number of tuples in each relation (i.e. Consider how the relation
will grow to estimate the Max potential size).
Physical DB Design
36
Step 6 Design User Views
Objective: To design the user views that were identified during the Requirements
Collection and Analysis stage of the relational database application lifecycle.
User view play a major role in enforcing security, especially in multi-user DBMS.
The major advantages of user view:
• Data independence.
• Reduce complexity.
• Customization.
Physical DB Design
37
Step 7 Design Security Measures
Objective: To design the security measures for the database as specified by the
users during the development life cycle.
Relational DBMS provide two type of security:
•System Security: covers access and use of the database at the system
level, such as user name and password.
•Data Security: covers access and use of database objects, such as a
relation or view, and the action that users can have on that objects.
Physical DB Design
38
Step 8 Consider the introduction of
controlled redundancy
Objective: To determine whether introducing redundancy in a controlled manner
by relaxing the normalization rules will improve the performance of the system.
This step should be undertaken only if necessary, because of the inherited
problems involved in introducing redundancy while still maintaining consistency.
Physical DB Design
39
Step 9 Monitor and tune the
operational system
Objective: To monitor the operational system and improve the performance of
the system to correct inappropriate design decisions or reflect changing
requirements.
Its an ongoing process of monitoring the operational system.
Physical DB Design
40