© Pearson Education Limited, 20041 Chapter 15 Physical Database Design – Step 7 (Consider Introduction of Controlled Redundancy) Transparencies.

Slides:



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

DENORMALIZATION CSCI 6442 © Copyright 2015, David C. Roberts, all rights reserved.
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.
IS 4420 Database Fundamentals Chapter 6: Physical Database Design and Performance Leon Chen.
Data Management Design
The Relational Database Model:
Physical Database Monitoring and Tuning the Operational System.
© 2005 by Prentice Hall 1 Chapter 6: Physical Database Design and Performance Modern Database Management 7 th Edition Jeffrey A. Hoffer, Mary B. Prescott,
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.
Distributed Databases
© Pearson Education Limited, Chapter 12 Physical Database Design – Step 3 (Translate Logical Design) Transparencies.
Team Dosen UMN Physical DB Design Connolly Book Chapter 18.
Chapter 6 Physical Database Design. Introduction The purpose of physical database design is to translate the logical description of data into the technical.
Chapters 17 & 18 Physical Database Design Methodology.
CSC271 Database Systems Lecture # 30.
1 © Prentice Hall, 2002 Physical Database Design Dr. Bijoy Bordoloi.
Database Design – Lecture 16
Lecture 9 Methodology – Physical Database Design for Relational Databases.
Concepts and Terminology Introduction to Database.
TM 7-1 Copyright © 1999 Addison Wesley Longman, Inc. Physical Database Design.
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.
Massively Distributed Database Systems - Distributed DBS Spring 2014 Ki-Joune Li Pusan National University.
DATABASE MGMT SYSTEM (BCS 1423) Chapter 5: Methodology – Conceptual Database Design.
Chapter 16 Practical Database Design and Tuning Copyright © 2004 Pearson Education, Inc.
© Pearson Education Limited, Chapter 13 Physical Database Design – Step 4 (Choose File Organizations and Indexes) 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.
IMS 4212: Database Implementation 1 Dr. Lawrence West, Management Dept., University of Central Florida Physical Database Implementation—Topics.
Views Lesson 7.
Distributed Database. Introduction A major motivation behind the development of database systems is the desire to integrate the operational data of an.
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.
In this session, you will learn to: Describe data redundancy Describe the first, second, and third normal forms Describe the Boyce-Codd Normal Form Appreciate.
University of Sunderland COM 220 Lecture Ten Slide 1 Database Performance.
Sekolah Tinggi Ilmu Statistik (STIS). Main Topics Denormalizing and introducing controlled redundancy  Meaning of denormalization.  When to denormalize.
Topic Distributed DBMS Database Management Systems Fall 2012 Presented by: Osama Ben Omran.
Physical Database Design Purpose- translate the logical description of data into the technical specifications for storing and retrieving data Goal - create.
Switch off your Mobiles Phones or Change Profile to Silent Mode.
1 Chapter 22 Distributed DBMS Concepts and Design CS 157B Edward Chen.
Distributed Database Design Bayu Adhi Tama, MTI Fasilkom-Unsri Adapted from Connolly, et al., Database Systems 4 th Edition, Pearson Education Limited,
1 Information Retrieval and Use De-normalisation and Distributed database systems Geoff Leese September 2008, revised October 2009.
1 Chapter 22 Distributed DBMSs - Concepts and Design Simplified Transparencies © Pearson Education Limited 1995, 2005.
1 Agenda TMA02 M876 Block 4. 2 Model of database development data requirements conceptual data model logical schema schema and database establishing requirements.
Converting ER/EER to logical schema; physical design issues 1.
Practical Database Design and Tuning
Indexing Structures for Files and Physical Database Design
Physical Changes That Don’t Change the Logical Design
Physical Database Design
Database Management System
Physical Database Design and Performance
ITD1312 Database Principles Chapter 5: Physical 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 19: Distributed Databases
CHAPTER 5: PHYSICAL DATABASE DESIGN AND PERFORMANCE
國立臺北科技大學 課程:資料庫系統 fall Chapter 18
Physical Database Design
Introduction to Databases Transparencies
Practical Database Design and Tuning
The Physical Design Stage of SDLC (figures 2.4, 2.5 revisited)
Methodology – Monitoring and Tuning the Operational System
Presentation transcript:

© Pearson Education Limited, Chapter 15 Physical Database Design – Step 7 (Consider Introduction of Controlled Redundancy) Transparencies

© Pearson Education Limited, Chapter 15 - Objectives Understanding meaning of denormalization. When to denormalize to improve performance. Importance of monitoring and tuning the operational system.

© Pearson Education Limited, Denormalization Refinement to relational schema such that the degree of normalization for a modified table is less than the degree of at least one of the original tables. Also use term more loosely to refer to situations where two tables are combined into one new table, which is still normalized but contains more nulls than original tables.

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

© Pearson Education Limited, Step 7 Consider the Introduction of Controlled Redundancy Normalization results in a logical database design that is structurally consistent and has minimal redundancy. However, sometimes a normalized database design does not provide maximum processing efficiency. May be necessary to accept loss of some of the benefits of a fully normalized design in favor of performance.

© Pearson Education Limited, Step 7 Consider the Introduction of Controlled Redundancy Also consider that denormalization: makes implementation more complex; often sacrifices flexibility; may speed up retrievals but it slows down updates.

© Pearson Education Limited, Step 7 Consider the Introduction of Controlled Redundancy Consider denormalization in following situations, specifically to speed up frequent or critical transactions: Step 7.1 Combining 1:1 relationships Step 7.2 Duplicating nonkey columns in 1:* relationships to reduce joins Step 7.3 Duplicating FK columns in 1:* relationships to reduce joins Step 7.4 Duplicating columns in *:* relationships to reduce joins

© Pearson Education Limited, Step 7 Consider the Introduction of Controlled Redundancy Step 7.5 Introducing repeating groups Step 7.6 Creating extract tables Step 7.7 Partitioning tables.

© Pearson Education Limited, Step 7.1 Combining 1:1 relationships

© Pearson Education Limited, Step 7.2 Duplicating nonkey columns in 1:* relationships to reduce joins

© Pearson Education Limited, Step 7.3 Duplicating FK columns in 1:* relationship to reduce joins

© Pearson Education Limited, Step 7.4 Duplicating columns in *:* relationships to reduce joins

© Pearson Education Limited, Step 7.5 Introducing repeating groups

© Pearson Education Limited, Step 7.6 Creating extract tables Reports can access derived data and perform multi-table joins on same set of base tables. However, data report based on may be relatively static or may not have to be current. Can create a single, highly denormalized extract table based on tables required by reports, and allow users to access extract table directly instead of base tables.

© Pearson Education Limited, Step 7.7 Partitioning tables Rather than combining tables, could decompose a table into a smaller number of partitions. Horizontal partition: distribute records across a number of (smaller) tables. Vertical partition: distribute columns across a number of (smaller) tables. PK duplicated to allow reconstruction. Partitions useful for applications that store and analyze large amounts of data.

© Pearson Education Limited, Step 7.7 Partitioning tables

© Pearson Education Limited, Step 7.7 Partitioning tables Advantages: Improved load balancing Improved performance Increased availability Improved recovery Security. Disadvantages: Complexity Reduced performance Duplication.