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

Slides:



Advertisements
Similar presentations
1 Senn, Information Technology, 3 rd Edition © 2004 Pearson Prentice Hall James A. Senns Information Technology, 3 rd Edition Chapter 7 Enterprise Databases.
Advertisements

Copyright: ©2005 by Elsevier Inc. All rights reserved. 1 Author: Graeme C. Simsion and Graham C. Witt Chapter 3 The Entity-Relationship Approach.
1 Copyright © 2010, Elsevier Inc. All rights Reserved Fig 2.1 Chapter 2.
By D. Fisher Geometric Transformations. Reflection, Rotation, or Translation 1.
ASYCUDA Overview … a summary of the objectives of ASYCUDA implementation projects and features of the software for the Customs computer system.
Relational Database and Data Modeling
Business Transaction Management Software for Application Coordination 1 Business Processes and Coordination.
Jeopardy Q 1 Q 6 Q 11 Q 16 Q 21 Q 2 Q 7 Q 12 Q 17 Q 22 Q 3 Q 8 Q 13
Jeopardy Q 1 Q 6 Q 11 Q 16 Q 21 Q 2 Q 7 Q 12 Q 17 Q 22 Q 3 Q 8 Q 13
Title Subtitle.
DIVIDING INTEGERS 1. IF THE SIGNS ARE THE SAME THE ANSWER IS POSITIVE 2. IF THE SIGNS ARE DIFFERENT THE ANSWER IS NEGATIVE.
Addition Facts
Fact-finding Techniques Transparencies
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide
Database Performance Tuning and Query Optimization
the Entity-Relationship (ER) Model
Lecture plan Outline of DB design process Entity-relationship model
Introduction to Databases
Chapter 5 Test Review Sections 5-1 through 5-4.
GG Consulting, LLC I-SUITE. Source: TEA SHARS Frequently asked questions 2.
Addition 1’s to 20.
25 seconds left…...
Week 1.
We will resume in: 25 Minutes.
Relational Algebra and Relational Calculus
Chapter 15 A Table with a View: Database Queries.
1 PART 1 ILLUSTRATION OF DOCUMENTS  Brief introduction to the documents contained in the envelope  Detailed clarification of the documents content.
Topic Denormalisation S McKeever Advanced Databases 1.
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.
Physical Database Monitoring and Tuning the Operational System.
Database Systems: A Practical Approach to Design, Implementation and Management International Computer Science S. Carolyn Begg, Thomas Connolly Lecture.
PARTITIONING “ A de-normalization practice in which relations are split instead of merger ”
Chapter 17 Methodology – Physical Database Design for Relational Databases Transparencies © Pearson Education Limited 1995, 2005.
Chapters 17 & 18 Physical Database Design Methodology.
Practical Database Design and Tuning. Outline  Practical Database Design and Tuning Physical Database Design in Relational Databases An Overview of Database.
CSC271 Database Systems Lecture # 30.
1 © Prentice Hall, 2002 Physical Database Design Dr. Bijoy Bordoloi.
Methodology - Conceptual Database Design Transparencies
Software School of Hunan University Database Systems Design Part III Section 5 Design Methodology.
1 Chapter 15 Methodology Conceptual Databases Design Transparencies Last Updated: April 2011 By M. Arief
© Pearson Education Limited, Chapter 16 Physical Database Design – Step 7 (Monitor and Tune the Operational System) Transparencies.
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.
Chapter 6 1 © Prentice Hall, 2002 The Physical Design Stage of SDLC (figures 2.4, 2.5 revisited) Project Identification and Selection Project Initiation.
1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.
DATABASE MGMT SYSTEM (BCS 1423) Chapter 5: Methodology – Conceptual Database Design.
© Pearson Education Limited, Chapter 15 Physical Database Design – Step 7 (Consider Introduction of Controlled Redundancy) Transparencies.
Chapter 16 Practical Database Design and Tuning Copyright © 2004 Pearson Education, Inc.
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.
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.
Physical Database Design Purpose- translate the logical description of data into the technical specifications for storing and retrieving data Goal - create.
Lec 7 Practical Database Design and Tuning Copyright © 2004 Pearson Education, Inc.
Switch off your Mobiles Phones or Change Profile to Silent Mode.
Practical Database Design and Tuning
Methodology Conceptual Databases Design
Methodology Conceptual Database Design
Methodology – Physical Database Design for Relational Databases
Methodology – Monitoring and Tuning the Operational System
Physical Database Design for Relational Databases Step 3 – Step 8
CHAPTER 5: PHYSICAL DATABASE DESIGN AND PERFORMANCE
Practical Database Design and Tuning
Methodology – Monitoring and Tuning the Operational System
Methodology Conceptual Databases Design
Presentation transcript:

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

2 Chapter 18 - Objectives u Meaning of denormalization. u When to denormalize to improve performance. u Importance of monitoring and tuning the operational system. u How to measure efficiency. u How system resources affect performance. © Pearson Education Limited 1995, 2005

3 Step 7 Consider the Introduction of Controlled Redundancy To determine whether introducing redundancy in a controlled manner by relaxing normalization rules will improve the performance of the system. © Pearson Education Limited 1995, 2005

4 Step 7 Consider the Introduction of Controlled Redundancy u Result of normalization is a design that is structurally consistent with minimal redundancy. u However, sometimes a normalized database does not provide maximum processing efficiency. u May be necessary to accept loss of some benefits of a fully normalized design in favor of performance. © Pearson Education Limited 1995, 2005

5 Step 7 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. © Pearson Education Limited 1995, 2005

6 Step 7 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. © Pearson Education Limited 1995, 2005

7 Step 7 Consider the Introduction of Controlled Redundancy u Consider denormalization in following situations, specifically to speed up frequent or critical transactions: –Step 7.1 Combining 1:1 relationships –Step 7.2 Duplicating non-key attributes in 1:* relationships to reduce joins –Step 7.3 Duplicating foreign key attributes in 1:* relationships to reduce joins © Pearson Education Limited 1995, 2005

8 Step 7 Consider the Introduction of Controlled Redundancy –Step 7.4 Duplicating attributes in *:* relationships to reduce joins –Step 7.5 Introducing repeating groups –Step 7.6 Creating extract tables –Step 7.7 Partitioning relations. © Pearson Education Limited 1995, 2005

9 Sample Relation Diagram © Pearson Education Limited 1995, 2005

10 Sample Relations © Pearson Education Limited 1995, 2005

11 Step 7.1 Combining 1:1 relationships © Pearson Education Limited 1995, 2005

12 Step 7.2 Duplicating non-key attributes in 1:* relationships to reduce joins © Pearson Education Limited 1995, 2005

13 Step 7.2 Duplicating non-key attributes in 1:* relationships: Lookup Table © Pearson Education Limited 1995, 2005

14 Step 7.2 Duplicating non-key attributes in 1:* relationships: Lookup Table © Pearson Education Limited 1995, 2005

15 Step 7.3 Duplicating FK attributes in 1:* relationship to reduce joins © Pearson Education Limited 1995, 2005

16 Step 7.4 Duplicating attributes in *:* relationships to reduce joins © Pearson Education Limited 1995, 2005

17 Step 7.5 Introducing repeating groups © Pearson Education Limited 1995, 2005

18 Step 7.6 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 relations required by reports, and allow users to access extract table directly instead of base relations. © Pearson Education Limited 1995, 2005

19 Step 7.7 Partitioning relations u Rather than combining relations together, alternative approach is to decompose them into a number of smaller and more mannageable partitions. u Two main types of partitioning: horizontal and vertical. © Pearson Education Limited 1995, 2005

20 Step 7.7 Partitioning relations © Pearson Education Limited 1995, 2005

21 Advantages and disadvantages of denormalization © Pearson Education Limited 1995, 2005

22 Step 8 Monitor & Tune Operational System To monitor operational system and improve performance of system to correct inappropriate design decisions or reflect changing requirements. © Pearson Education Limited 1995, 2005

23 Step 8 Monitor & Tune Operational System u Number of factors 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. u No one factor is always correct. Have to trade each off against another to achieve reasonable balance. u Need to understand how the various hardware components interact and affect database performance. © Pearson Education Limited 1995, 2005

24 Step 8 Monitor & Tune Operational System DreamHome wish to hold pictures of properties, and comments that describe main features of property. © Pearson Education Limited 1995, 2005