CostAnalysis: 1 Cost Analysis Rule-of-Thumb Guidelines As a guide, consider denormalizing if: –redundancy is minimal and update anomalies are not expected.

Slides:



Advertisements
Similar presentations
©Silberschatz, Korth and Sudarshan12.1Database System Concepts Chapter 12: Indexing and Hashing Basic Concepts Ordered Indices B+-Tree Index Files B-Tree.
Advertisements

Chapter Secondary Storage Rough Speed Differentials –nanoseconds: retrieve data in main memory –microseconds: retrieve from disk cache or under a.
NestedRelations: 1 Nested Relations Flat schemas often have replicated data values in their relations. Nested schemas allow us to collapse some of these.
Chapter Design Objectives Obtain the theoretically “best” design (normalize) –Remove redundancy and update anomalies –Remove nulls –Minimize the.
XNF: 1 XML and NNF A Standard Form for XML Documents (XNF) Properties –As few hierarchical trees as possible –No redundant data values in any tree Method.
De-normalize if… Performance is unsatisfactory Table has a low update rate –(sacrifice flexibility) Table has a high query rate –(speed up retrieval)
Chapter Abstraction Concrete: directly executable/storable Abstract: not directly executable/storable –automatic translation (as good as executable/storable)
PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design Copyright 2000 © John Wiley & Sons, Inc. All rights reserved. Slide 1 Key.
Chapter Physical Database Design Methodology Software & Hardware Mapping Logical Design to DBMS Physical Implementation Security Implementation Monitoring.
1 File Organizations and Indexing Module 4, Lecture 2 “How index-learning turns no student pale Yet holds the eel of science by the tail.” -- Alexander.
FDImplication: 1 Functional Dependencies (FDs) Let r(R) be a relation and let t  r, then the restriction of t to X  R, written t[X], is the projection.
Database Implementation Issues CPSC 315 – Programming Studio Spring 2008 Project 1, Lecture 5 Slides adapted from those used by Jennifer Welch.
SQL Components DML DDL DAL. Overview u Getting the records onto the disk - mapping u Managing disk space u SQL Modes u Ceating database.
FileOrg: 1 Secondary Storage Rough Speed Differentials –nanoseconds: retrieve data in main memory –microseconds: retrieve from under a read head –milliseconds:
Mappings & Normal Form Guarantees. Can Mappings of Diagrams Yield Normalized Schemas? “Yes”—but only if canonical. Most (?) diagrams are canonical. Mappings.
OSM—Normalize Then Map. ER Model Instance Type  RackRate Room Date  Guest Rate Discount Date  Discount Rate = (1 – Discount/100)  RackRate includes.
Chapter Nested Schemes Flat schemes often have replicated data values. Nested schemes allow us to collapse some of these replicated data values.
Databases and Processing Modes. Fundamental Data Storage Concepts and Definitions What is an entity? An entity is something about which information is.
Chapter Specification Detailed and precise proposal for a system Provides the technical basis for a contract Typically increases understanding and.
XNF-1 XML and NNF A Standard Form for XML Documents (XNF) Properties –As few hierarchical trees as possible –No redundant data values in any tree Method.
CostEst: 1 Cost Estimation Based on: –operations –file and record sizes –file structures –block layout on disk –caching scheme (in our simplified world,
View Processing & Update. View Processing create view PresSuite as select * from Room where NrBeds = 2 select * from PresSuite p natural join Reservation.
Create, Insert, Delete, Update. Create Create database Create table Create index – Primary – Secondary.
QueryRewriting: 1 Query Rewriting (for Query “Optimization”) Main Strategy: Make intermediate results small by applying selection and projection early.
Chapter 4 Relational Databases Copyright © 2012 Pearson Education, Inc. publishing as Prentice Hall 4-1.
Chapter Implementation Faithful translation of a design into a target environment Design should be free of target-environment dependencies Should.
Design Algorithm Essentials 1.Combine functional edges with the same tail object set(s) into a scheme. (The tail object set(s) and any others in a 1-1.
Why Normalization? To Reduce Redundancy to 1.avoid modification, insertion, deletion anomolies 2.save space Goal: One Fact in One Place.
Chapter 4 Relational Databases Copyright © 2012 Pearson Education 4-1.
Database Normalization CP3410 Daryle Niedermayer, I.S.P., PMP.
Databases. Objectives Define what a database is. Understand the difference between a flat and relational database Design and create a relational database.
Database Management Systems, R. Ramakrishnan and J. Gehrke1 File Organizations and Indexing Chapter 8.
Chapters 17 & 18 Physical Database Design Methodology.
CSC271 Database Systems Lecture # 30.
IT The Relational DBMS Section 06. Relational Database Theory Physical Database Design.
1 © Prentice Hall, 2002 Physical Database Design Dr. Bijoy Bordoloi.
PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design, 2 nd Edition Copyright 2003 © John Wiley & Sons, Inc. All rights reserved.
FILE VS. DATABASES Let’s examine some basic principles about how data are stored in computer systems. – An entity is anything about which the organization.
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.
PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design Copyright 2000 © John Wiley & Sons, Inc. All rights reserved. Slide 1 Systems.
Lecture 5: Functional dependencies and normalization Jose M. Peña
M Taimoor Khan Course Objectives 1) Basic Concepts 2) Tools 3) Database architecture and design 4) Flow of data (DFDs)
Copyright © Curt Hill Query Evaluation Translating a query into action.
Object Persistence (Data Base) Design Chapter 13.
More about Databases. Data Entry through Forms Table View (Data sheet view) is useful for data entry of new records But sometimes customization would.
1 CS 430 Database Theory Winter 2005 Lecture 16: Inside a DBMS.
© Pearson Education Limited, Chapter 13 Physical Database Design – Step 4 (Choose File Organizations and Indexes) Transparencies.
Functional Dependencies and Normalization Jose M. Peña
Storage and Indexing1 Overview of Storage and Indexing.
Copyright 2007, Paradigm Publishing Inc. ACCESS 2007 Chapter 2 BACKNEXTEND 2-1 LINKS TO OBJECTIVES Creating Related Tables Creating Related Tables Determining.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Overview of Storage and Indexing Chapter 8.
File and Database Design Class 22. File and database design: 1. Choosing the storage format for each attribute from the logical data model. 2. Grouping.
University of Sunderland COM 220 Lecture Ten Slide 1 Database Performance.
Physical Database Design Purpose- translate the logical description of data into the technical specifications for storing and retrieving data Goal - create.
RelAlg: 1 Relational Algebra An Algebra is a pair: (set of values, set of operations) Note that an algebra is the same idea as an ADT Relational Algebra:
CS4432: Database Systems II More on Index Structures 1.
Extended ER Mappings & Models. General Principle #1 Graphical representations dictate cardinality relationships among attributes. When graphical representations.
SQL: 1 SQL Correspondence with Relational Algebra select A from r where B = 1 Assume r(AB) and s(BC). select B from r except select B from s select A as.
1 CS 430 Database Theory Winter 2005 Lecture 7: Designing a Database Logical Level.
NORMALIZATION Handout - 4 DBMS. What is Normalization? The process of grouping data elements into tables in a way that simplifies retrieval, reduces data.
CS 405G: Introduction to Database Systems Instructor: Jinze Liu Fall 2007.
Database Management Systems, R. Ramakrishnan and J. Gehrke1 File Organizations and Indexing Chapter 8 Jianping Fan Dept of Computer Science UNC-Charlotte.
Database Normalization. What is Normalization Normalization allows us to organize data so that it: Normalization allows us to organize data so that it:
1 CS122A: Introduction to Data Management Lecture #15: Physical DB Design Instructor: Chen Li.
April 20022/CS/3X1 Database Design Design method John Wordsworth Department of Computer Science The University of Reading Room.
Indexes By Adrienne Watt.
Database Normalization
Databases A brief introduction….
Presentation transcript:

CostAnalysis: 1 Cost Analysis Rule-of-Thumb Guidelines As a guide, consider denormalizing if: –redundancy is minimal and update anomalies are not expected (e.g., StreetNr City State  Zip) –replicated objects are large (e.g., images in View) –join frequencies are very high when compared to updates (e.g., approximate cost in Canadian dollars) Using actual application characteristics, estimate space and time requirements for various possibilities and compare costs.

CostAnalysis: 2 Cost Estimation (Space) Case 1: Room(RoomNr, RoomName, NrBeds, Cost) Guest(GuestNr, GuestName, StreetNr, City) Reservation(GuestNr, RoomNr, ArrivalDate, NrDays) vs. Case 2: Room(RoomNr, RoomName, NrBeds, Cost) Reservation(GuestNr, GuestName, StreetNr, City, RoomNr, ArrivalDate, NrDays) vs. Case 3: Guest(GuestNr, GuestName, StreetNr, City) Reservation(GuestNr, RoomNr, ArrivalDate, NrDays, RoomName, NrBeds, Cost) vs. Case 4: Reservation(GuestNr, GuestName, StreetNr, City, RoomNr, ArrivalDate, NrDays, RoomName, NrBeds, Cost) Assume: 5 rooms, 100 reservations, and 80 guests. 5  4 =  4 =  4 =  4 =  7 =  4 =  7 =  10 = 1000

CostAnalysis: 3 Cost Estimation (Time) Case 1: Room(RoomNr, RoomName, NrBeds, Cost) Guest(GuestNr, GuestName, StreetNr, City) Reservation(GuestNr, RoomNr, ArrivalDate, NrDays) vs. Case 2: Room(RoomNr, RoomName, NrBeds, Cost) Reservation(GuestNr, GuestName, StreetNr, City, RoomNr, ArrivalDate, NrDays) Most important queries/updates: 1. (40%) What rooms are available? 2. (30%) Make a reservation. 3. (10%) Change a reservation. 4. (10%) Cancel a reservation. 5. (the rest) Miscellaneous. Assume indexed on primary keys. 1. Case 1 & 2: Using the Reservation table, retrieve reservations that could overlap the requested date and determine room availability. (Case 1 insignificantly better  the only difference is that Case 1 transfers fewer values in its records.) …

CostAnalysis: 4 Semantic Change? Case 1: Room(RoomNr, RoomName, NrBeds, Cost) Guest(GuestNr, GuestName, StreetNr, City) Reservation(GuestNr, RoomNr, ArrivalDate, NrDays) vs. Case 2: Room(RoomNr, RoomName, NrBeds, Cost) Reservation(GuestNr, GuestName, StreetNr, City, RoomNr, ArrivalDate, NrDays) Most important queries/updates: (30%) Make a reservation.... Assume indexed on primary keys. 2. Case 1: Insert tuple in Reservation (1 read & 1 write) and insert tuple in Guest, if necessary, (1 read and (usually) 1 write). Case 2: Insert tuple in Reservation (1 read & 1 write); check duplicate guest information (read file, or add secondary index). (Developer) Do we really need to check duplicate guest information? (Proprietor) Hmmm, maybe not; it doesn’t matter if it is different. (Developer) Does a guest always need the same guest number? (Proprietor) Not really; there are no guest numbers in our manual system. (Developer) Aha! Great, this really lets us save  watch this.

CostAnalysis: 5 Unique GuestNr in Reservation Observe that we have a new set of keys: { {GuestNr}, {RoomNr, ArrivalDate} } And thus a new generated database scheme: Reservation(GuestNr, GuestName, City, Street, RoomNr, ArrivalDate, NrDays) Room(RoomNr, RoomName, NrBeds, Cost)