1 Functional Dependencies. 2 Motivation v E/R  Relational translation problems : –Often discover more “detailed” constraints after translation (upcoming.

Slides:



Advertisements
Similar presentations
primary key constraint foreign key constraint
Advertisements

Schema Refinement and Normal Forms
Chapter 3 Notes. 3.1 Functional Dependencies A functional dependency is a statement that – two tuples of a relation that agree on some particular set.
Database Management Systems, 3ed, R. Ramakrishnan and J. Gehrke1 Schema Refinement and Normal Forms Chapter 19.
CS Schema Refinement and Normal Forms Chapter 19.
Normalization DB Tuning CS186 Final Review Session.
Normalization DB Tuning CS186 Final Review Session.
Schema Refinement and Normal Forms
H.Lu/HKUST L02: Logical Database Design  Introduction  Functional Dependencies  Normal Forms  Normalization by decomposition.
Cs3431 Normalization. cs3431 Why Normalization? To remove potential redundancy in design Redundancy causes several anomalies: insert, delete and update.
Schema Refinement and Normal Forms. The Evils of Redundancy v Redundancy is at the root of several problems associated with relational schemas: – redundant.
1 Functional Dependency and Normalization Informal design guidelines for relation schemas. Functional dependencies. Normal forms. Normalization.
1 Schema Refinement and Normal Forms Chapter 19 Raghu Ramakrishnan and J. Gehrke (second text book) In Course Pick-up box tomorrow.
Databases 6: Normalization
1 Schema Refinement and Normal Forms Yanlei Diao UMass Amherst April 10, 2007 Slides Courtesy of R. Ramakrishnan and J. Gehrke.
Functional Dependencies CS 186, Spring 2006, Lecture 21 R&G Chapter 19 Science is the knowledge of consequences, and dependence of one fact upon another.
1 Database Theory and Methodology. 2 The Good and the Bad So far we have not developed any measure of “goodness” to measure the quality of the design,
Database Management Systems, R. Ramakrishnan and J. Gehrke 1 Schema Refinement and Normal Forms Chapter 19 Instructor: Mirsad Hadzikadic.
Schema Refinement and Normal Forms Jianlin Feng School of Software SUN YAT-SEN UNIVERSITY courtesy of Joe Hellerstein for some slides.
Normal Forms1. 2 The Problems of Redundancy Redundancy is at the root of several problems associated with relational schemas: Wastes storage Causes problems.
CSCD34 - Data Management Systems - A. Vaisman1 Schema Refinement and Normal Forms.
Schema Refinement and Normal Forms Chapter 19 1 Database Management Systems 3ed, R.Ramakrishnan & J.Gehrke.
1 Schema Refinement, Normalization, and Tuning. 2 Design Steps v The design steps: 1.Real-World 2. ER model 3. Relational Schema 4. Better relational.
LECTURE 5: Schema Refinement and Normal Forms SOME OF THESE SLIDES ARE BASED ON YOUR TEXT BOOK.
Logical Database Design (1 of 3) John Ortiz Lecture 6Logical Database Design (1)2 Introduction  The logical design is a process of refining DB schema.
R EVIEW. 22 Exam Su 3:30PM - 6:30PM 2010/12/12 Room C9000.
1 Lecture 6: Schema refinement: Functional dependencies
Functional Dependencies and Normalization R&G Chapter 19 Lecture 26 Science is the knowledge of consequences, and dependence of one fact upon another.
Functional Dependencies. FarkasCSCE 5202 Reading and Exercises Database Systems- The Complete Book: Chapter 3.1, 3.2, 3.3., 3.4 Following lecture slides.
Christoph F. Eick: Functional Dependencies, BCNF, and Normalization 1 Functional Dependencies, BCNF and Normalization.
Functional Dependencies And Normalization R&G Chapter 19.
Database Systems/COMP4910/Spring02/Melikyan1 Schema Refinement and Normal Forms.
1 IT 244 Database Management System Topic 7 The Relational Data Model Functional Dependencies Ref : -A First Course in Database System (Jeffrey D Ullman,
CSC 411/511: DBMS Design Dr. Nan Wang 1 Schema Refinement and Normal Forms Chapter 19.
1 Schema Refinement and Normal Forms Week 6. 2 The Evils of Redundancy  Redundancy is at the root of several problems associated with relational schemas:
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide
© D. Wong Ch. 3 (continued)  Database design problems  Functional Dependency  Keys of relations  Decompositions based on Functional Dependency.
Database Management Systems, R. Ramakrishnan and J. Gehrke1 Schema Refinement and Normal Forms Chapter 15.
Functional Dependencies R&G Chapter 19 Science is the knowledge of consequences, and dependence of one fact upon another. Thomas Hobbes ( )
Database Management Systems, 3ed, R. Ramakrishnan and J. Gehrke1 Schema Refinement and Normal Forms Chapter 19.
Schema Refinement and Normalization Nobody realizes that some people expend tremendous energy merely to be normal. Albert Camus.
CS 405G: Introduction to Database Systems Instructor: Jinze Liu Fall 2009.
ICS 421 Spring 2010 Relational Model & Normal Forms Asst. Prof. Lipyeow Lim Information & Computer Science Department University of Hawaii at Manoa 1/19/20101Lipyeow.
1 Schema Refinement and Normal Forms Chapter The Evils of Redundancy  Redundancy is at the root of several problems associated with relational.
CS542 1 Schema Refinement Chapter 19 (part 1) Functional Dependencies.
Database Management Systems, 3ed, R. Ramakrishnan and J. Gehrke1 Schema Refinement and Normal Forms Chapter 19.
© D. Wong Functional Dependencies (FD)  Given: relation schema R(A1, …, An), and X and Y be subsets of (A1, … An). FD : X  Y means X functionally.
Chapter 8 Relational Database Design. 2 Relational Database Design: Goals n Reduce data redundancy (undesirable replication of data values) n Minimize.
1 Schema Refinement and Normal Forms Chapter The Evils of Redundancy  Redundancy causes several problems associated with relational schemas: 
Normalization and FUNctional Dependencies. Redundancy: root of several problems with relational schemas: –redundant storage, insert/delete/update anomalies.
CSC 411/511: DBMS Design Dr. Nan Wang 1 Schema Refinement and Normal Forms Chapter 19.
1 CS122A: Introduction to Data Management Lecture #12: Relational DB Design Theory (1) Instructor: Chen Li.
LECTURE 5: Schema Refinement and Normal Forms 1. Redundency Problem Redundent Storage Update Anomaly If one copy updated, an inconsistancy may occur Insertion.
CSC 411/511: DBMS Design Dr. Nan Wang 1 Schema Refinement and Normal Forms Chapter 19.
Schema Refinement & Normal Forms.
Functional Dependencies and Schema Refinement
Introduction to Database Systems Functional Dependencies
UNIT - 3 DATABASE DESIGN Functional Dependencies
Functional Dependencies, BCNF and Normalization
Functional Dependencies, BCNF and Normalization
Schema Refinement & Normalization Theory
Functional Dependencies
Schema Refinement and Normal Forms
Functional Dependencies
Schema Refinement and Normalization
Normalization cs3431.
Chapter 19 (part 1) Functional Dependencies
Schema Refinement and Normal Forms
Schema Refinement and Normalization
Schema Refinement and Normal Forms
Presentation transcript:

1 Functional Dependencies

2 Motivation v E/R  Relational translation problems : –Often discover more “detailed” constraints after translation (upcoming example) –Some relationships not easily captured in E/R diagrams: for a particular star and movie, there is exactly one studio: –Sometimes attributes were misplaced in an E/R diagram (Section ) StarFilm Contracts Studio

3 The Evils of Redundancy v Redundancy is at the root of these problems: – redundant storage, insert/delete/update anomalies v Integrity constraints, in particular functional dependencies, can be used to identify schemas with such problems and to suggest refinements. v Main refinement technique: decomposition (replacing ABCD with, say, AB and BCD, or ACD and ABD). v Decomposition should be used judiciously: –Is there a reason to decompose a relation? –What problems (if any) does the decomposition cause?

4 Functional Dependencies (FDs) v A functional dependency X Y holds over relation R if, for every allowable instance r of R: – (t1 r, t2 r, t1.X = t2.X) implies t1.Y = t2.Y –i.e., given two tuples in r, if the X values agree, then the Y values must also agree. (X and Y are sets of attributes.) v An FD is a statement about all allowable relations. –Identified by DBA based on semantics of application. –Given some allowable instance r1 of R, we can check if it violates some FD f, but we cannot tell if f holds over R! v K is a candidate key for R means that K R v K R means that K is a superkey

5 Example: Constraints on Entity Set v Consider the relation schema for Hourly_Emps: –Hourly_Emps ( ssn, name, lot, rating, hrly_wages, hrs_worked ) v Notation : We will denote this relation schema by listing the attributes: SNLRWH –This is really the set of attributes {S,N,L,R,W,H}. –Sometimes, we will refer to all attributes of a relation by using the relation name (e.g., Hourly_Emps for SNLRWH). v Some FDs on Hourly_Emps: – ssn is a candidate key: S SNLRWH – rating determines hrly_wages : R W

6 Example (Contd.) v Problems due to R W : – Update anomaly : Can we change W in just the 1st tuple of SNLRWH? – Insertion anomaly : What if we want to record the fact that rating = 6 implies wages = 10? – Deletion anomaly : If we delete all employees with rating 5, we lose the information about the wage for rating 5! Hourly_Emps2 Wages

7 Reasoning About FDs v Given some FDs, we can usually infer additional FDs: – S R, R W implies S W v An FD f is implied by a set of FDs F if f holds whenever all FDs in F hold. – = closure of F is the set of all FDs that are implied by F. v Armstrong’s Axioms (X, Y, Z are sets of attributes): – Reflexivity : If Y X, then X Y – Augmentation : If X Y, then XZ YZ for any Z – Transitivity : If X Y and Y Z, then X Z v These are sound and complete inference rules for FDs!

8 Reasoning About FDs (Contd.) v Couple of additional rules (that follow from AA): – Union : If X Y and X Z, then X YZ – Decomposition : If X YZ, then X Y and X Z v Example: Contracts( cid,sid,jid,did,pid,qty,value ), and: –C is the key: C CSJDPQV –Project purchases each part using single contract: JP C –Dept purchases at most one part from a supplier: SD P v JP C, C CSJDPQV imply JP CSJDPQV v SD P implies SDJ JP v SDJ JP, JP CSJDPQV imply SDJ CSJDPQV

9 Reasoning About FDs (Contd.) v Computing the closure of a set of FDs can be expensive. (Size of closure is exponential in # attrs!) v Often, we just want to check if a given FD X Y is in the closure of a set of FDs F. An efficient check: –Compute attribute closure of X (denoted ) wrt F: u Set of all attributes A such that X A is in u There is a linear time algorithm to compute this. –Check if Y is in v Does F = {A B, B C, C D E } imply A E? –i.e, is A E in the closure ? Equivalently, is E in ?

10 Summary v E/R  Relational translation can lead to relational schemas with redundancy (wasted space, anomalies) v Functional dependencies : –Describe connections among attributes –Allow us to precisely describe the redundancy –Allow us to eliminate it algorithmically by decomposing the relation with the redundancy (more next time…) v We can use given FDs to derive others (closure of a set of dependencies) v We can determine candidate keys (attribute closure)