Database Systems: A Practical Approach to Design, Implementation and Management International Computer Science S. Carolyn Begg, Thomas Connolly Lecture.

Slides:



Advertisements
Similar presentations
Chapter 18 Methodology – Monitoring and Tuning the Operational System Transparencies © Pearson Education Limited 1995, 2005.
Advertisements

Logical Database Design
Topic Denormalisation S McKeever Advanced Databases 1.
Chapter 6 Methodology Logical Database Design for the Relational Model Transparencies © Pearson Education Limited 1995, 2005.
Normalization of Database Tables
Database Systems: A Practical Approach to Design, Implementation and Management International Computer Science S. Carolyn Begg, Thomas Connolly Lecture.
Chapter Physical Database Design Methodology Software & Hardware Mapping Logical Design to DBMS Physical Implementation Security Implementation Monitoring.
Chapter 6 Methodology Conceptual Databases Design Transparencies © Pearson Education Limited 1995, 2005.
Lecture Eleven Entity-Relationship Modelling
Physical Database Monitoring and Tuning the Operational System.
1 Methodology : Conceptual Databases Design © Pearson Education Limited 1995, 2005.
Methodology Logical Database Design for the Relational Model
Lecture Fourteen Methodology - Conceptual Database Design
1 Database Systems: A Practical Approach to Design, Implementation and Management International Computer Science S. Carolyn Begg, Thomas Connolly Lecture.
Chapter 5 Normalization of Database Tables
Database Systems Design, Implementation, and Management Coronel | Morris 11e ©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or.
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 5 Normalization of Database Tables.
Database Systems: A Practical Approach to Design, Implementation and Management International Computer Science S. Carolyn Begg, Thomas Connolly Lecture.
Methodology Conceptual Database Design
LOGICAL DATABASE DESIGN
CSC271 Database Systems Lecture # 21. Summary: Previous Lecture  Phases of database SDLC  Prototyping (optional)  Implementation  Data conversion.
Relational Model & Relational Algebra. 2 Relational Model u Terminology of relational model. u How tables are used to represent data. u Connection between.
Chapters 17 & 18 Physical Database Design Methodology.
CSC271 Database Systems Lecture # 30.
Chapter 16 Methodology - Conceptual Database Design.
Methodology - Conceptual Database Design Transparencies
Software School of Hunan University Database Systems Design Part III Section 5 Design Methodology.
Methodology Conceptual Databases Design
9/14/2012ISC329 Isabelle Bichindaritz1 Database System Life Cycle.
1 Chapter 15 Methodology Conceptual Databases Design Transparencies Last Updated: April 2011 By M. Arief
Physical Database Design Chapter 6. Physical Design and implementation 1.Translate global logical data model for target DBMS  1.1Design base relations.
Chapter 16 Methodology – Physical Database Design for Relational Databases.
Database Systems: Design, Implementation, and Management Tenth Edition
10/3/2012ISC329 Isabelle Bichindaritz1 Logical Design.
Methodology - Conceptual Database Design. 2 Design Methodology u Structured approach that uses procedures, techniques, tools, and documentation aids to.
Chapter 9 Methodology - Logical Database Design Chapter 16 in Textbook.
1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.
Methodology: Conceptual Databases Design
DATABASE MGMT SYSTEM (BCS 1423) Chapter 5: Methodology – Conceptual Database Design.
Team Dosen UMN Database Design Connolly Book Chapter
Lecture2: Database Environment Prepared by L. Nouf Almujally & Aisha AlArfaj 1 Ref. Chapter2 College of Computer and Information Sciences - Information.
© Pearson Education Limited, Chapter 15 Physical Database Design – Step 7 (Consider Introduction of Controlled Redundancy) Transparencies.
10/10/2012ISC239 Isabelle Bichindaritz1 Physical Database Design.
Physical Database Design Transparencies. ©Pearson Education 2009 Chapter 11 - Objectives Purpose of physical database design. How to map the logical database.
Chapter 8 Methodology - Conceptual Database Design Chapter 15 in Textbook.
Methodology - Conceptual Database Design
Part4 Methodology of Database Design Chapter 07- Overview of Conceptual Database Design Lu Wei College of Software and Microelectronics Northwestern Polytechnical.
Methodology – Physical Database Design for Relational Databases.
Switch off your Mobiles Phones or Change Profile to Silent Mode.
Methodology – Monitoring and Tuning the Operational System.
Sekolah Tinggi Ilmu Statistik (STIS). Main Topics Denormalizing and introducing controlled redundancy  Meaning of denormalization.  When to denormalize.
Lection №4 Development of the Relational Databases.
Modelling Methodologies Chapter 16, 17, 18. Modeling Methodologies2 Database Design Physical DB design Logical DB design Conceptual DB design Hardware.
CSC271 Database Systems Lecture # 7. Summary: Previous Lecture  Relational keys  Integrity constraints  Views.
B. Information Technology (Hons.) CMPB245: Database Design Physical Design.
Switch off your Mobiles Phones or Change Profile to Silent Mode.
Logical Design 12/10/2009GAK1. Learning Objectives How to remove features from a local conceptual model that are not compatible with the relational model.
Normalization. Overview Earliest  formalized database design technique and at one time was the starting point for logical database design. Today  is.
Methodology - Logical Database Design. 2 Step 2 Build and Validate Local Logical Data Model To build a local logical data model from a local conceptual.
5 1 Chapter 5 Normalization of Database Tables Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel.
Methodology Conceptual Databases Design
Methodology Logical Database Design for the Relational Model
Methodology Conceptual Database Design
Methodology – Monitoring and Tuning the Operational System
Physical Database Design for Relational Databases Step 3 – Step 8
Conceptual Database Design
Chapter 14 Normalization.
Methodology – Monitoring and Tuning the Operational System
Methodology Conceptual Databases Design
Presentation transcript:

Database Systems: A Practical Approach to Design, Implementation and Management International Computer Science S. Carolyn Begg, Thomas Connolly Lecture Seventeen Methodology – Monitoring and Tuning the Operational System Based on Chapter Seventeen of this book:

2 Lecture 17 - Objectives u Meaning of denormalization. u When to denormalize to improve performance. u Importance of monitoring and tuning the operational system.

3 Overview of Physical Database Design Methodology u Step 8 Consider the introduction of controlled redundancy u Step 9 Monitor and tune the operational system

4 Step 8 Consider the Introduction of Controlled Redundancy To determine whether introducing redundancy in a controlled manner by relaxing the normalization rules will improve the performance of the system.

5 Step 8 Consider the Introduction of Controlled Redundancy u Result of normalization is a logical database design that is structurally consistent and has minimal redundancy. u However, sometimes a normalized database design does not provide maximum processing efficiency. u It may be necessary to accept the loss of some of the benefits of a fully normalized design in favor of performance.

6 Step 8 Consider the Introduction of Controlled Redundancy u Also consider that denormalization: –makes implementation more complex; –often sacrifices flexibility; –may speed up retrievals but it slows down updates.

7 Step 8 Consider the Introduction of Controlled Redundancy u Denormalization refers to a refinement to relational schema such that the degree of normalization for a modified relation is less than the degree of at least one of the original relations. u Also use term more loosely to refer to situations where two relations are combined into one new relation, which is still normalized but contains more nulls than original relations.

8 Step 8 Consider the Introduction of Controlled Redundancy u Consider denormalization in following situations, specifically to speed up frequent or critical transactions: –Step 8.1 Combining 1:1 relationships –Step 8.2 Duplicating nonkey attributes in 1:* relationships to reduce joins –Step 8.3 Duplicating foreign key attributes in 1:* relationships to reduce joins

9 Step 8 Consider the Introduction of Controlled Redundancy –Step 8.5 Introducing repeating groups –Step 8.6 Merging lookup tables with base relations –Step 8.7 Creating extract tables.

10 Sample global relation diagram

11 Sample relations

12 Step 8.1 Combining 1:1 relationships

13 Step 8.2 Duplicating nonkey attributes in 1:* relationships to reduce joins u List all property details, including owner’s last name, for properties at branch B003 –SELECT p.*, o.lName FROM PropertyForRent p, PrivateOwner o WHERE p.ownerNo = o.ownerNo AND branchNo = ‘B003’

14 Step 8.2 Duplicating nonkey attributes in 1:* relationships to reduce joins

15 Step 8.2 Duplicating nonkey attributes in 1:* relationships to reduce joins u List all property details, including owner’s last name, for properties at branch B003 u Use expanded PropertyForRent relation –SELECT * FROM PropertyForRent WHERE branchNo = ‘B003’

16 Step 8.3 Duplicating foreign key attributes in 1:* relationship to reduce joins u List the last name of all private owners whose property is handled by branch B003 –SELECT o.lName FROM PropertyForRent p, PrivateOwner o WHERE p.ownerNo = o.ownerNo AND branchNo = ‘B003’

17 Step 8.3 Duplicating foreign key attributes in 1:* relationship to reduce joins

18 Step 8.3 Duplicating foreign key attributes in 1:* relationship to reduce joins u List the last name of all private owners whose property is handled by branch B003 u Use expanded PrivateOwner relation –SELECT lName FROM PrivateOwner WHERE branchNo = ‘B003’

19 Step 8.4 Duplicating attributes in *:* relationships to reduce joins

20 Step 8.5 Introducing repeating groups

21 Step 8.6 Merging lookup tables with base relations

22 Step 8.7 Creating extract tables u Reports can access derived data and perform multi-relation joins on same set of base relations. However, data the report is based on may be relatively static or may not have to be current. u Possible to create a single, highly denormalized extract table based on the relations required by the reports, and allow the users to access extract table directly instead of the base relations.

23 Step 9 Monitor and Tune the Operational System To monitor operational system and improve performance of system to correct inappropriate design decisions or reflect changing requirements. DreamHome wish to hold pictures of properties, and comments that describe main features of property.