1 / 40

Chapter 10

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.

kevlyn
Download Presentation

Chapter 10

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Design MethodologyReview • A structured approach that uses procedures, techniques, tools, and documentation aids to support and facilitate the process of design.

  3. Database Design Review Hardware independent Software independent Conceptual DB design Hardware independent Software dependent Logical DB design Hardware dependent Software dependent Physical DB design

  4. 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.

  5. 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.

  6. 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

  7. 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

  8. 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.

  9. 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.

  10. 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.

  11. 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);

  12. 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.

  13. STAFF BrnNo StaffNo LName NoPro FName SL21 John White B005 0 SG37 Ann Beech B003 2 SG14 David Ford B003 1 Mary B007 SA9 1 Howe SG5 Susan Brand B003 0 SL41 Julie Lee B005 1

  14. 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))

  15. 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.

  16. 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.

  17. 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).

  18. 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.

  19. 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.

  20. Transaction’s Pathways for Global View StaffNo (b) SUPERVISOR STAFF register (0,*) (a) (0,100) (e) (d) manage OwnerNo PropertyNo VDate Comment (0,1) (1:1) (c,g) (1,*) (1,1) PROPERTY BOwn views CLIENT OWNER ClientNo (0,*) (0,*) (0,*) (h,i) (0,*) (1:1) associate hold d state (m) (l) PRIVATE OWNER BUSINESS OWNER (1:1) (1:1) (j) LEASE PREFERENCE LeaseNo (1:1) (k)

  21. Transaction Usage Map Avg = 20 Max= 40 (C) STAFF 2000 BRANCH 100 has Avg = 50 Max= 100 (E) (F) Avg = 1000 Max= 3000 (D) PROPERTY 100000 offer manage

  22. Transaction Analysis Form

  23. 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

  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. Index Example STAFF (brnNo) B005 B003 SG14 John White 18000 B003 SG37 Ann Beech 12000 B003 SL21 B003 David B005 Ford 30000 B007 Mary 9000 SL41 B007 Howe Data File Index File Of any file organization ordered

  26. Primary Index Example Anchor record Data file index page 1 2 3 S5 1 S14 2 S37 3 S5 Record S9 Record S14 Record S21 Record S37 Record S41 Record

  27. Cluster Index Example Data file index page 1 2 3 S5 1 S14 2 S21 3 S5 Record S5 Record S14 Record S14 Record S14 Record S21 Record

  28. Indexes STAFF (salary, brnNo) BrnNo Salary StaffNo LName FName (salary) 9000, B007 B005 9000 SG14 John White 18000 12000,B003 B003 SG37 Ann Beech 12000 12000 18000,B005 SL21 B003 David 18000 Ford 30000 30000,B003 B007 Mary 9000 SL41 30000 Howe

  29. Index Categories Data file index page 1 2 3 S5 1 S9 1 S14 2 S21 2 S37 3 S41 3 S5 Record S9 Record S14 Record S21 Record S37 Record S41 Record Dense index Data file index page 1 2 3 S5 1 S14 2 S37 3 S5 Record S9 Record S14 Record S21 Record S37 Record S41 Record Sparse index

  30. Multilevel Index Data file Level 1 Index Level 2 Index page 1 2 3 4 S5 S14 S5 Record S9 Record S14 Record S21 Record S37 Record S41 Record S56 Record S87 Record S5 S37 S37 S56

  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.

  33. 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).

  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.

  35. Additional Indexes Table Index Staff FName, LName SupervisorStaffNo Position Client StaffNo FName, LName PropertyForRent OwnerNo StaffNo ClientNo RentFinish City Rent Viewing ClientNo

  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).

  37. 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.

  38. 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.

  39. 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.

  40. Step 9Monitor 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.

More Related