Institute of Southern Punjab, Multan

Transcription

1 Institute of Southern Punjab, Multan Mr. Muhammad Nouman Farooq BSC-H (Computer Science) MS (Telecomm. and Networks) Honors: Magna Cumm Laude Honors Degree Gold Medalist! Blog Url: noumanfarooqatisp.wordpress.com

2 Advance Database Systems Physical Database Design & Performance Lecture# 7

3 Lecture 7: Physical Database Design & Performance Introduction of Physical Database Design Process Designing Fields Choosing Data Types Controlling Data Integrity Denormalizing and Partitioning Data Designing Physical Database Files File Organizations Clustering Files Indexes Optimizing Queries 3

4 Introduction of Physical Database Design & Performance In previous lectures; We have learned how to describe and model organizational data during the conceptual data modeling and logical database design phases of the database development process. We learned how to use EER notation, the relational data model, and normalization to develop constructs of organizational data that capture the meaning of data; however, these notations do not explain how data will be processed or stored. The purpose of physical database design is to translate the logical description of data into the technical specifications for storing and retrieving data. The goal is to create a design for storing data that will provide high performance and ensure database integrity, security, and recoverability. Physical database design does not include implementing files and databases (i.e., creating them and loading data) 4

5 Introduction of Physical Database Design Process 5

6 Introduction of Physical Database Design Process The primary goal of physical database design is data processing efficiency. It is very important for database developer to design the physical database to minimize the time required by users to interact with the information system. Designing physical files and databases requires certain information that should have been collected and produced during prior database development phases. The information needed for physical file and database design includes these requirements: Normalizing Relations to eliminate anomalies Definitions of each attribute, along with physical specifications such as maximum possible length Descriptions of where and when data are used: entered, retrieved, deleted, and updated Requirements for response time and data security, backup, recovery and integrity Descriptions of the simulator (database management systems) used for implementing the database 6

7 Continued.. Physical database design requires several critical decisions that will affect the integrity and performance of the application system. These key decisions include the following: Choosing the storage format (called data type) for each attribute from the logical data model. The format and associated parameters are chosen to minimize storage space and to maximize data integrity. Selecting structures (called indexes and database architectures) for storing and connecting files to make retrieving related data more efficient. Preparing strategies for handling queries against the database that will optimize performance and take advantage of the file organizations and indexes that you have specified. 7

8 Designing Fields 8

9 Designing Fields The basic decisions you must make in specifying each field concern the type of data (or storage type) used to represent values of this field, data integrity controls built into the database. 9

10 Choosing Data Types 10

11 Choosing Data Types A data type is a detailed coding scheme recognized by system software, such as a DBMS, for representing organizational data. Selecting a data type involves four objectives that will have different levels of importance for different applications: 1. Minimizing Storage Space 2. Represent all possible Values 3. Improve Data Integrity (only Legal Values allowed as per Field) 4. Support all Data Manipulations 11

12 12

13 13

14 CODING TECHNIQUES Some attributes have set of values so large that, given data volumes, considerable storage space will be consumed. A field with a limited number of possible values can be translated into a CODE that requires less space. Consider the example of the ProductFinish field illustrated in Figure 5-2 on next slide. Products at Pine Valley Furniture come in only a limited number of woods: Birch, Maple, and Oak. By creating a code or translation table, each ProductFinish field value can be replaced by a code, a cross-reference to the lookup table, similar to a foreign key. This will decrease the amount of space for the ProductFinish field and hence for the PRODUCT file. There will be additional space for the PRODUCT FINISH lookup table, and when the ProductFinish field value is needed, an EXTRA ACCESS (called a JOIN) to this lookup table will be required. 14

15 15

16 Controlling Data Integrity 16

17 Controlling Data Integrity For many DBMS, data integrity controls (controls on the possible value a field can assume) can be built into the physical structure of the fields and controls enforced by the DBMS on those fields. The data type enforces one form of data integrity control because it may limit the type of data (numeric or character) and the length of a field value. Some other typical integrity controls that a DBMS may support are the following: 1. Default Value: A default value is the value a field will assume unless a user enters an explicit value for an instance of that field. Assigning a default value to a field can reduce data entry time because entry of a value can be skipped and it can also help to reduce data entry errors for the most common value. It can be achieved by implementing an Auto-Increment check on field having data type Integer. 17

18 Continued.. 2. Range Control: A range control limits the set of allowable values a field may assume. Range controls must be used with caution because the limits of the range may change over time. A combination of range controls and coding led to the Year 2000 problem faced by many Organizations, in which a field for year is represented by only the numbers 00 to

19 Continued.. 3. Null Value Control: A null value was also defined in previous lectures as an empty value. Each Primary Key must have an Integrity control that prohibits a null value. Any other required field may also have a Null Value control placed on it if that is the policy of the organization. For example, a university may prohibit adding a course to its database unless that course has a Title as well as a value of the Primary Key field CourseID. 19

20 Continued.. 4. Referential Integrity: The term Referential Integrity" was also defined in previous lectures. Referential Integrity on a field is a form of range control in which the value of that field must exist as the value in some field in another Row of the same or (most commonly) different table. 20

21 Denormalizing and Partitioning Data 21

22 22

23 23

24 24

25 25

26 26

27 27

28 28

29 29

30 30

31 31

32 32

33 33

34 34

35 35

36 36

37 37

38 38

39 39

40 Designing Physical Database Files 40

41 41

42 File Organizations 42

43 43

44 44

45 45

46 46

47 47

48 48

49 49

50 50

51 51

52 52

53 53

54 54

55 Clustering Files 55

56 56

57 57

58 58

59 59

60 Indexes 60

61 61

62 62

63 63

64 64

65 65

66 Optimizing Queries 66

67 67

68 68

69 69

70 70

71 71

72 72

73 73

74 74

75 75

76 Recommended Readings Chapter 6 from: - Modern Database Management by Jeffrey A. Hoffer, Marry B. Presscott & Fred R. McFadden; 8 th Edition (Page No ) Chapter 5 from: - Modern Database Management by Jeffrey A. Hoffer, V. Ramesh & H. Toppi; 10 th Edition (Page No ) 76

77 Lecture 7 Summary of Lecture Introduction of Physical Database Design Process Designing Filed Choosing Data Types Controlling Data Integrity Denormalizing and Partitioning Data Designing Physical Database Files File Organizations Clustering Files Indexes Optimizing Queries 77

78 END OF LECTURE 7 78