physical database design transparencies. ©pearson education 2009 chapter 11 - objectives purpose of...
TRANSCRIPT
Physical Database DesignTransparencies
©Pearson Education 2009
Chapter 11 - ObjectivesPurpose of physical database design.How to map the logical database design to a
physical database design.How to design base tables for target DBMS.How to design representation of derived
data.How to design integrity constraints for the
target DBMS.How to analyze the users’ transactions to
identify characteristics that may impact on performance.
2
©Pearson Education 2009
Chapter 11 - ObjectivesThat a database represents an essential
corporate resources that must be made secure.
The meaning of denormalization.About the importance of monitoring and
tuning the operational system.How to measure efficiency.
3
©Pearson Education 2009
Logical vs Physical Database Design Logical db design independent of
implementation details, such as functionality of target DBMS.
Logical db design concerned with the what, physical database design is concerned with the how.
Sources of information for physical design includes logical data model and data dictionary.
4
©Pearson Education 2009
Physical Database DesignProcess 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.
5
©Pearson Education 2009
Overview of Physical Database Design Methodology
Step 3 Translate logical database design for target DBMS
Step 4 Choose file organizations and indexes
Step 5 Design user viewsStep 6 Design security mechanismsStep 7 Consider introduction of controlled
redundancyStep 8 Monitor and tune operational system
6
©Pearson Education 2009
Step 3 Translate logical database design for target DBMS
To produce a basic working relational database from the logical data model.
Consists of the following steps:Step 3.1 Design base tablesStep 3.2 Design representation of
derived data Step 3.3 Design remaining integrity
constraints
7
©Pearson Education 2009
Step 3 Translate logical database design for target DBMS
Need to know functionality of target DBMS such as how to create base tables and whether DBMS supports the definition of:PKs, FKs, and AKs;required data – i.e. whether system
supports NOT NULL;domains;relational integrity rules;other integrity constraints.
8
©Pearson Education 2009
Step 3.1 Design base tables
To decide how to represent base tables identified in logical model in target DBMS.
Need to collate and assimilate the information about tables produced during logical database design (from data dictionary and tables defined in DBDL).
9
©Pearson Education 2009
Step 3.1 Design base tablesFor each table, need to define:
name of the table;list of simple columns in brackets;PK and, where appropriate, AKs and FKs.referential integrity constraints for any FKs
identified.For each column, need to define:
its domain, consisting of a data type, length, and any constraints on the domain;
optional default value for the column;whether column can hold nulls;whether column is derived.
10
©Pearson Education 2009
DBDL for the Branch table
11
©Pearson Education 2009
Step 3.2 Design representation of derived data
To design the representation of derived data in the database.
Produce list of all derived columns from logical data model and data dictionary.
Derived column can be stored in database or calculated every time it is needed.
12
©Pearson Education 2009
Step 3.2 Design representation of derived dataOption selected is based on:
additional cost to store the derived data and keep it consistent with data from which it is derived;
cost to calculate it each time it’s required.
Less expensive option is chosen subject to performance constraints.
13
©Pearson Education 2009
Step 3.3 Design remaining integrity constraintsTo design the remaining integrity constraints for the target DBMS.
Some DBMS provide more facilities than others for defining integrity constraints. Example:
CONSTRAINT member_not_renting_too_manyCHECK (NOT EXISTS (SELECT memberNo
FROM RentalDelivery r. DVDRental dWHERE r.deliveryNo=d.deliveryNo AND
dateReturn IS NULL GROUP BY memberNoHAVING COUNT(*) > 5))
14
©Pearson Education 2009 15
Step 4 Choose file organizations/indexes
Determine optimal file organizations to store the base tables, and the indexes required to achieve acceptable performance.
Consists of the following steps:Step 4.1 Analyze transactionsStep 4.2 Choose file organizations Step 4.3 Choose indexes
©Pearson Education 2009 16
Step 4.1 Analyze transactions To analyze the functionality of the transactions that will run on the database to identify those that may impact performance.
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).
©Pearson Education 2009 17
Step 4.1 Analyze transactionsUse 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:columns that are updated in an update
transaction; criteria used to restrict records that are
retrieved in a query.One way to do this is to use the transaction
pathway diagram created in Step 1.8.
©Pearson Education 2009 18
Step 4.1 Analyze transactionsTo focus on areas that may be
problematic:
(1) Map all transaction paths to tables.
(2) Determine which tables are most frequently accessed by transactions.
(3) Analyze the data usage of selected transactions that involve these tables.
©Pearson Education 2009 19
Transaction pathway diagram (expected daily occurrences added)
©Pearson Education 2009 20
Step 4.1 Analyze transactionsFor each transaction determine:
(a) Tables and columns accessed and type of access.
(b) Columns used in any search conditions.
(c) For query, columns involved in joins.(d) Expected frequency of transaction.(e) Performance goals of transaction.
©Pearson Education 2009 21
Step 4.2 Choose file organizations To determine an efficient file organization for each base table.
File organizations include Heap, Hash, Indexed Sequential Access Method (ISAM), B+-Tree, and Clusters.
Some DBMSs (particularly PC-based DBMS) have fixed file organization that you cannot alter.
©Pearson Education 2009 22
Step 4.3 Choose indexes Determine whether adding indexes will improve the performance of the system.
One approach is to keep records unordered and create as many secondary indexes as necessary.
Have to balance overhead in maintenance and use of secondary indexes against performance improvement gained when retrieving data.
This includes: adding an index record to every secondary index whenever
record is inserted; updating a secondary index when corresponding record is
updated; increase in disk space needed to store the secondary index; possible performance degradation during query optimization
to consider all secondary indexes.
©Pearson Education 2009 23
Step 4.3 Choose indexes – Guidelines for choosing ‘wish-list’
(1) Do not index small tables. (2) Index PK of a table if it is not a key of the file
organization. (3) Add secondary index to any column that is
heavily used as a secondary key. (4) Add secondary index to a FK if it is frequently
accessed.(5) Add secondary index on columns that are
involved in: selection or join criteria; ORDER BY; GROUP BY; and other operations involving sorting (such as UNION or DISTINCT).
©Pearson Education 2009 24
Step 4.3 Choose indexes – Guidelines for choosing ‘wish-list’
(6) Add secondary index on columns involved in built-in functions.
(7) Add secondary index on columns that could result in an index-only plan.
(8) Avoid indexing an column or table that is frequently updated.
(9) Avoid indexing an column if the query will retrieve a significant proportion of the records in the table.
(10) Avoid indexing columns that consist of long character strings.
©Pearson Education 2009 25
Step 5 Design User Views Design user views identified during Requirements Collection and Analysis stage of the database system development lifecycle.
Normally views created using SQL or a QBE-like facility. For example:
CREATE VIEW Staff1ViewAS SELECT staffNo, name, position,
eMailFROM StaffWHERE dCenterNo = ‘D001’;
©Pearson Education 2009 26
Step 6 Design Security Measures Design security measures for the database as specified by the users.
RDBMSs generally provide two types of database security:system security: access and use of database
at system level (such as username/password);
data security: access and use of database objects (such as tables and views).
©Pearson Education 2009 27
Step 6 Design Security Measures - SQLEach database user assigned an
authorization identifier by DBA (usually has an associated password).
Each object created has an owner.Privileges are the actions that a user is
permitted to carry out on a given base table or view (such as SELECT, UPDATE).
GRANT statement allows owner to give privileges to other users.
REVOKE statement takes privileges away.
©Pearson Education 2009 28
Step 7 Consider Introduction of Controlled Redundancy
Determine whether introducing redundancy in a controlled manner by relaxing the normalization rules will improve system performance.
Normalization results in a logical database design that is structurally consistent and has minimal redundancy.
However, sometimes a normalized database design does not provide maximum processing efficiency.
May be necessary to accept loss of some of the benefits of a fully normalized design in favor of performance.
©Pearson Education 2009 29
Denormalization Refinement to relational schema such that
the degree of normalization for a modified table is less than the degree of at least one of the original tables.
Also use term more loosely to refer to situations where two tables are combined into one new table, which is still normalized but contains more nulls than original tables.
©Pearson Education 2009 30
Step 7 Consider Introduction of Controlled Redundancy
Also consider that denormalization:makes implementation more complex;often sacrifices flexibility;may speed up retrievals but it slows down
updates.
©Pearson Education 2009 31
Step 8 Monitor and tune the operational system
To monitor operational system and improve performance of system to correct inappropriate design decisions or reflect changing requirements.
©Pearson Education 2009 32
Step 8 Monitor and tune the operational system
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.
No one factor is always correct. Typically, have to trade one factor off against another to achieve a reasonable balance.
©Pearson Education 2009 33
Step 8 Monitor and tune the operational system
Must be aware how 4 main hardware components interact and affect performance:main memoryCPUdisk I/Onetwork.
Note that an improvement in one resource may effect an improvement in other resources.
©Pearson Education 2009 34
Step 8 Monitor and tune the operational system
Main memory:Significantly faster than secondary storage.More main memory, faster applications will
run.Should always have between 5%-10% main
memory available.Need to understand how target DBMS uses
main memory.
©Pearson Education 2009 35
Step 8 Monitor and tune the operational system
CPU:Controls tasks of other system resources and
executes user processes.Most costly resource, so needs to be correctly
utilized.Want to prevent CPU contention (processes
waiting for CPU).Need to understand typical 24-hour workload
and ensure sufficient resources available for both normal and peak workload.
©Pearson Education 2009 36
Step 8 Monitor and tune the operational system
Disk I/O:With any large DBMS, significant amount of
disk I/O.Need to carefully design how data is
organized on disk.
©Pearson Education 2009 37
Step 8 Monitor and tune the operational system
StayHome wish to hold plus brief story line for DVDs.