Topic Denormalisation S McKeever Advanced Databases 1.

Slides:



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

BUSINESS DRIVEN TECHNOLOGY Plug-In T4 Designing Database Applications.
Topic Database Normalisation S McKeever Advanced Databases 1.
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.
IS 4420 Database Fundamentals Chapter 6: Physical Database Design and Performance Leon Chen.
Physical Database Monitoring and Tuning the Operational System.
Lecture Fourteen Methodology - Conceptual Database Design
Database Design Concepts Info 1408 Lecture 2 An Introduction to Data Storage.
Database Systems: A Practical Approach to Design, Implementation and Management International Computer Science S. Carolyn Begg, Thomas Connolly Lecture.
Methodology Conceptual Database Design
Modeling & Designing the Database
Information systems and databases Database information systems Read the textbook: Chapter 2: Information systems and databases FOR MORE INFO...
APPENDIX C DESIGNING DATABASES
Chapter 14 & 15 Conceptual & Logical Database Design Methodology
Chapter 6 Physical Database Design. Introduction The purpose of physical database design is to translate the logical description of data into the technical.
Week 6 Lecture Normalization
Chapters 17 & 18 Physical Database Design Methodology.
CSC271 Database Systems Lecture # 30.
1 © Prentice Hall, 2002 Physical Database Design Dr. Bijoy Bordoloi.
Course Introduction Introduction to Databases Instructor: Joe Bockhorst University of Wisconsin - Milwaukee.
ITEC224 Database Programming
Chapter 16 Methodology - Conceptual Database Design.
1 Introduction to Database Systems. 2 Database and Database System / A database is a shared collection of logically related data designed to meet the.
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.
CSCI 3140 Module 2 – Conceptual Database Design Theodore Chiasson Dalhousie University.
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.
Databases and Database Management Systems
CORE 2: Information systems and Databases NORMALISING 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.
Copyright 2008 McGraw-Hill Ryerson 1 TECHNOLOGY PLUG-IN T5 DESIGNING DATABASE APPLICATIONS.
Methodology - Conceptual Database Design. 2 Design Methodology u Structured approach that uses procedures, techniques, tools, and documentation aids to.
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
© Pearson Education Limited, Chapter 15 Physical Database Design – Step 7 (Consider Introduction of Controlled Redundancy) Transparencies.
Conceptual Database Design
Physical Database Design Transparencies. ©Pearson Education 2009 Chapter 11 - Objectives Purpose of physical database design. How to map the logical database.
Methodology - Conceptual Database Design
Database Management COP4540, SCS, FIU Physical Database Design (ch. 16 & ch. 3)
Part4 Methodology of Database Design Chapter 07- Overview of Conceptual Database Design Lu Wei College of Software and Microelectronics Northwestern Polytechnical.
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.
B. Information Technology (Hons.) CMPB245: Database Design Physical Design.
Switch off your Mobiles Phones or Change Profile to Silent Mode.
1 Information Retrieval and Use De-normalisation and Distributed database systems Geoff Leese September 2008, revised October 2009.
Understanding Data Storage
Methodology Conceptual Databases Design
Physical Database Design
Physical Changes That Don’t Change the Logical Design
Methodology Conceptual Database Design
© The McGraw-Hill Companies, All Rights Reserved APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES.
Physical Database Design and Performance
Methodology – Monitoring and Tuning the Operational System
Physical Database Design for Relational Databases Step 3 – Step 8
Databases A brief introduction….
CHAPTER 5: PHYSICAL DATABASE DESIGN AND PERFORMANCE
Teaching slides Chapter 8.
The Physical Design Stage of SDLC (figures 2.4, 2.5 revisited)
Methodology – Monitoring and Tuning the Operational System
Methodology Conceptual Databases Design
Chapter 17 Designing Databases
Presentation transcript:

Topic Denormalisation S McKeever Advanced Databases 1

The result of normalisation is a logical database design that is structurally consistent and has minimal redundancy. So it’s all perfect. Is it?

S McKeeverAdvanced Databases 3 Does it ever make sense to deliberately relax normalisation rules and deliberately introduce redundancy into the system. Question?

S McKeever 4 The answer is yes, but only when it is estimated that the system may not be able to meet its performance requirements. Answer

S McKeever 5 A fully normalised system does not necessarily provide maximum processing efficiency. In this situation introducing redundancy in a controlled manner by relaxing the normalisation rules will improve the performance of the system. Denormalisation

S McKeever 6 When we talk about denormalisation we are not just talking about forms. For example, we may decide to have some portion of the logical data model in 2NF and the rest in 3NF. In general we are loosely using the term to refer to situations where we combine relations and the new relation is still normalised but may contain nulls but there are other techniques Denormalisation

S McKeever 7 Often in normalisation, you split a table into two tables (like our various examples) Then when you need data from both tables, you need to access two tables instead of one. In some situations we may decide to leave the relations in 2NF – because it’s faster. Denormalisation

S McKeever 8 Normalisation is still very important for database design. In addition the following factors have to be considered: Denormalisation makes implementation more complex. Denormalisation often sacrifices flexibility Denormalisation may speed up retrievals but it slows down updates. Denormalisation

Denormalisation techniques S McKeeverAdvanced Databases 9 Denormalisation uses various techniques but techniques used will depend upon on usage of the database) Consider the use of these techniques for frequent or critical transactions:

S McKeeverAdvanced Databases 10 Consider the introduction of controlled redundancy (denormalisation) Some techniques  1 Combining 1:1 relationships  2 Duplicating non-key attributes in 1:* relationships to reduce joins  3 Duplicating attributes in *:* relationships to reduce joins  4 Introducing repeating groups  5 Partitioning relations into smaller chunks.

Sample Relation Diagram S McKeeverAdvanced Databases 11

Sample Relations S McKeeverAdvanced Databases 12

1 Combining 1:1 relationships S McKeeverAdvanced Databases 13 Queries on the interview details for a client are very frequent in this database. Two separate tables. So combining the two tables will be faster (it’s faster to query one table than to join two)

2 Duplicating non-key attributes in 1:* relationships: Lookup Table S McKeeverAdvanced Databases 14 This table shows all properties available for rent. Have to go to lookup table to “translate” type

2 Duplicating non-key attributes in 1:* relationships: Lookup Table duplicated S McKeeverAdvanced Databases 15

3 Duplicating attributes in *:* relationships to reduce joins S McKeeverAdvanced Databases 16 When you’re using an intermediate or bridging table, can perhaps add duplicate attributes to the bridging table to speed up queries e.g. Furniture store: Orders table linked to order items, Which is linked to products How do I show all orders for products of type chair? Add product type to order_items table for speed.

4 Introducing repeating groups S McKeeverAdvanced Databases 17 But only where there is a limited number of groups e.g. max of three telephone numbers

5 Partitioning relations S McKeeverAdvanced Databases 18  Rather than combining relations together, alternative approach is to decompose them into a number of smaller and more manageable partitions  Two main types of partitioning: horizontal and vertical.  Very important technique for performance tuning Don’t give me such a big table to search… divide it up to help me How do I decide what to chop the table into?

5 Partitioning relations S McKeeverAdvanced Databases 19 Handy if there’s a natural split e.g. Customers in Dublin in one table, other customers on a 2 nd table Vertical Maybe some columns aren’t used much

S McKeeverAdvanced Databases 20 Supposing.. Mobile phone company has a customer service system. All service calls logged. Transaction description: When a phone call is received, the customer service clerk usually searches the database for a customer call for a specific day. Search for a customer’s calls for a specific day. There are 1M customers. Each makes on average 2 calls per day 2X365M records added per year It could take days to query calls for a specific customer Use partitioning? 5 Partitioning relations

S McKeeverAdvanced Databases 21 Using Partitioning Partition the customer_calls table into separate partitions per customer? Per day? – this one is easier because you don’t have to keep “old” partitions up to date Search space will go from M+ records to 2M.. 5 Partitioning relations

S McKeeverAdvanced Databases Smaller and more manageable pieces of data ( Partitions ) 2. Reduced recovery time 3. Failure impact is less 4. import / export can be done at the " Partition Level". 5. Faster access of data 6. Partitions work independent of the other partitions. 7. Very easy to use 5 Partitioning relations

S McKeever 23 We’ve looked at techniques and concepts ERDs entities, relationships, cardinalities Normalisation Denormalisation Database Design

S McKeever 24 ConceptualLogicalPhysical Database design phases Normalisation done in this step Denormalisation In this step DBMS must be known DBMS not necessarily known

S McKeever 25 Design methodology defines 3 phases Conceptual The process of constructing a model of the data used in an enterprise independent of all physical considerations Logical The process of constructing a model of the data used in an enterprise based on a specific data model, but independent of a particular DMBS and other physical considerations Physical The process of producing a description of the implementation of the database on secondary storage; it describes the base relations, file organisations and indexes used to achieve efficient access to the data, and any associated integrity constraints and security measures. What? How?

S McKeever 26 Summary  Sometimes after normalising, need to revisit design in order to improve performance  Denormalisation investigated for frequent or critical transactions  Various techniques