chapter 10

40
Chapter 10 Methodology - Methodology - Physical Database Design Physical Database Design Chapter 18, Appendix F in Textbook

Upload: kevlyn

Post on 06-Jan-2016

24 views

Category:

Documents


0 download

DESCRIPTION

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. Database Design Review. - PowerPoint PPT Presentation

TRANSCRIPT

Chapter 10

Methodology - Methodology -

Physical Database DesignPhysical Database Design

Chapter 18, Appendix F in Textbook

2

Design MethodologyDesign Methodology ReviewReview

A structured approach that uses procedures, techniques, tools,

and documentation aids to support and facilitate the process of

design.

Conceptual DB Design

3

Database Design Database Design ReviewReview

Physical DB design

LogicalDB design

ConceptualDB design

Hardware dependentSoftware dependent

Hardware independentSoftware dependent

Hardware independentSoftware independent

Physical DB Design

4

Design Methodology Overview Design Methodology Overview ReviewReview

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

5

Comparison of Logical and Comparison of Logical and Physical Database DesignPhysical 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

6

Overview of Physical Database Overview of Physical Database Design MethodologyDesign 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

7

Overview of Physical Database Overview of Physical Database Design MethodologyDesign 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

8

Step 4Step 4 Translate Global Logical Translate Global Logical Data Model for Target DBMSData 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

9

Step 4.1 Design Base RelationsStep 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

10

Step 4.1 Design Base RelationsStep 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

11

PropertyForRent RelationPropertyForRent 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

12

Step 4.2 Design Representation of Step 4.2 Design Representation of Derived DataDerived 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

13

SL21

SG37

SG14

SA9

SG5

StaffNo

John

Ann

David

Mary

Susan

FName

White

Beech

Ford

Howe

Brand

LName NoPro

0

2

1

1

0

SL41 Julie Lee 1

STAFF

BrnNo

B005

B005

B003

B003

B003

B007

Physical DB Design

14

Step 4.3 Design Enterprise Step 4.3 Design Enterprise ConstraintsConstraints

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

15

Step 5Step 5 Design Physical Design Physical RepresentationRepresentation

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

16

Step 5Step 5 Design Physical Design Physical RepresentationRepresentation

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

17

Step 5.1 Analyze TransactionsStep 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

18

Step 5.1 Analyze TransactionsStep 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

19

Step 5.1 Analyze TransactionsStep 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

Transaction’s Pathways for Global ViewTransaction’s Pathways for Global View

BUSINESSOWNER

STAFF

PROPERTY

PRIVATEOWNER

LEASE

CLIENT

PREFERENCE

holdassociate

manage

state

register

BOwn

(1:1)

(1:1)

(1:1)

(1:1)

(1:1)

(0,*) (0,*)

(0,*)

(1,1)(1,*)

(0,1)

(0,100)

views (0,*)(0,*)

OwnerNo

LeaseNo

StaffNo

PropertyNo

ClientNo

CommentVDate

OWNER

d

SUPERVISOR(a)

(e)(d)

(h,i)

(j)

(l)

(c,g)

(m)

(k)

(b)

21

Transaction Usage MapTransaction Usage Map

manage offer

has

Avg = 20Max= 40 (C)

Avg = 1000Max= 3000

(D)

Avg = 50Max= 100

(E)

(F)

PROPERTY100000

BRANCH100

STAFF2000

Physical DB Design

22

Transaction Analysis FormTransaction Analysis Form

23

Step 5.2 Choose File OrganizationsStep 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

24

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.

25

SG14

SG37

SL21

SL41

John

Ann

David

Mary

White

Beech

Ford

Howe

STAFF

18000

12000

30000

9000

Index Example

B005

B003

B003

B007

B003

B003

B005

B007

(brnNo)

Of any file organization ordered

Index FileData File

Physical DB Design

26

Primary Index Example

S5 1

S14 2

S37 3

page 1

2 3

S5 RecordS9 RecordS14 RecordS21 RecordS37 RecordS41 Record

index Data fileAnchor record

Physical DB Design

27

Cluster Index Example

S5 1

S14 2

S21 3

page 1

2

3

S5 RecordS5 Record

S14 RecordS14 RecordS14 RecordS21 Record

index Data file

Physical DB Design

28

SG14

SG37

SL21

SL41

StaffNo

John

Ann

David

Mary

FName

White

Beech

Ford

Howe

LName

STAFF

Salary

18000

12000

30000

9000

Indexes

BrnNo

B005

B003

B003

B007

9000, B007

12000,B003

18000,B005

30000,B003

9000

12000

18000

30000

(salary, brnNo)(salary)

Physical DB Design

29

Index Categories

S5 1S9 1S14 2 S21 2S37 3S41 3

page 1

2 3

S5 RecordS9 RecordS14 RecordS21 RecordS37 RecordS41 Record

index Data file

S5 1

S14 2

S37 3

page 1

2 3

S5 RecordS9 RecordS14 RecordS21 RecordS37 RecordS41 Record

index Data file

Dense index

Sparse index

Physical DB Design

30

Multilevel Index

S5S14

page 1

2 3

4

S5 RecordS9 RecordS14 RecordS21 RecordS37 RecordS41 RecordS56 RecordS87 Record

Level 1 Index Data file

S5

S37

S37

S56

Level 2 Index

Physical DB Design

31

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;

32

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

33

(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

Guidelines for Choosing Indexes

34

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

35

Additional IndexesTable IndexStaff FName, LName

SupervisorStaffNoPosition

Client StaffNoFName, LName

PropertyForRent OwnerNoStaffNoClientNoRentFinishCityRent

Viewing ClientNo

Physical DB Design

36

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

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.

37Physical DB Design

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.

38Physical DB Design

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.

39Physical DB Design

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.

40Physical DB Design