Functional Dependencies and Normalization

Slides:



Advertisements
Similar presentations
Schema Refinement: Normal Forms
Advertisements

Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 16 Relational Database Design Algorithms and Further Dependencies.
Normalization 1 Instructor: Mohamed Eltabakh Part II.
Announcements Read 6.1 – 6.3 for Wednesday Project Step 3, due now Homework 5, due Friday 10/22 Project Step 4, due Monday Research paper –List of sources.
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.
Murali Mani Normalization. Murali Mani What and Why Normalization? To remove potential redundancy in design Redundancy causes several anomalies: insert,
Chapter 7: Relational Database Design. ©Silberschatz, Korth and Sudarshan7.2Database System Concepts Chapter 7: Relational Database Design First Normal.
Normalization DB Tuning CS186 Final Review Session.
Chapter 7: Relational Database Design. ©Silberschatz, Korth and Sudarshan7.2Database System Concepts Chapter 7: Relational Database Design First Normal.
Nov 11, 2003Murali Mani Normalization B term 2004: lecture 7, 8, 9.
1 Normalization Chapter What it’s all about Given a relation, R, and a set of functional dependencies, F, on R. Assume that R is not in a desirable.
1 CMSC424, Spring 2005 CMSC424: Database Design Lecture 9.
Cs3431 Normalization. cs3431 Why Normalization? To remove potential redundancy in design Redundancy causes several anomalies: insert, delete and update.
Schema Refinement and Normalization Nobody realizes that some people expend tremendous energy merely to be normal. Albert Camus.
Cs3431 Normalization Part II. cs3431 Attribute Closure : Example Consider R (A, B, C, D, E) with FDs A  B, B  C, CD  E Does A  E hold ? (Is A  E.
©Silberschatz, Korth and Sudarshan7.1Database System Concepts Chapter 7: Relational Database Design First Normal Form Pitfalls in Relational Database Design.
Chapter 10 Functional Dependencies and Normalization for Relational Databases.
CS 405G: Introduction to Database Systems 16. Functional Dependency.
Relational Database Design by Relational Database Design by Dr.S.Sridhar, Ph.D.(JNUD), RACI(Paris, NICE), RMR(USA), RZFM(Germany) DIRECTOR ARUNAI ENGINEERING.
Computing & Information Sciences Kansas State University Tuesday, 27 Feb 2007CIS 560: Database System Concepts Lecture 18 of 42 Tuesday, 27 February 2007.
Functional Dependencies and Normalization 1 Instructor: Mohamed Eltabakh
Revisit FDs & BCNF Normalization 1 Instructor: Mohamed Eltabakh
Final Exam Revision Instructor: Mohamed Eltabakh 1.
Functional Dependencies. FarkasCSCE 5202 Reading and Exercises Database Systems- The Complete Book: Chapter 3.1, 3.2, 3.3., 3.4 Following lecture slides.
Chapter 7: Relational Database Design. ©Silberschatz, Korth and Sudarshan7.2Database System Concepts Chapter 7: Relational Database Design First Normal.
1 CSE 480: Database Systems Lecture 18: Normal Forms and Normalization.
Chapter 7 Functional Dependencies Copyright © 2004 Pearson Education, Inc.
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.
Functional Dependencies CIS 4301 Lecture Notes Lecture 8 - 2/7/2006.
CS542 1 Schema Refinement Chapter 19 (part 1) Functional Dependencies.
© 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.
Computing & Information Sciences Kansas State University Friday, 03 Oct 2007CIS 560: Database System Concepts Lecture 16 of 42 Wednesday, 03 October 2007.
Normalization and FUNctional Dependencies. Redundancy: root of several problems with relational schemas: –redundant storage, insert/delete/update anomalies.
Normal Forms Zachary G. Ives University of Pennsylvania CIS 550 – Database & Information Systems June 18, 2016 Some slide content courtesy of Susan Davidson.
Functional Dependencies and Normalization 1 Instructor: Mohamed Eltabakh Part 2.
Normalization Database Management Systems, 3rd ed., Ramakrishnan and Gehrke, Chapter 19.
Functional Dependency and Normalization
Advanced Normalization
CS422 Principles of Database Systems Normalization
Schema Refinement and Normal Forms
Module 5: Overview of Database Design -- Normalization
Normalization First Normal Form (1NF) Boyce-Codd Normal Form (BCNF)
CS422 Principles of Database Systems Normalization
Relational Database Design by Dr. S. Sridhar, Ph. D
Relational Database Design
Chapter 8: Relational Database Design
Advanced Normalization
Functional Dependencies and Normalization
Database Management systems Subject Code: 10CS54 Prepared By:
Module 5: Overview of Normalization
Schema Refinement What and why
Normalization Murali Mani.
Functional Dependencies and Normalization
How to test Whether Subschemes in BCNF??
Normalization Part II cs3431.
Functional Dependencies and Normalization
Functional Dependencies
Normalization cs3431.
CS 405G: Introduction to Database Systems
Instructor: Mohamed Eltabakh
Chapter 19 (part 1) Functional Dependencies
Schema Refinement and Normalization
Relational Database Design
Instructor: Mohamed Eltabakh
Chapter 7a: Overview of Database Design -- Normalization
Functional Dependencies and Normalization
Functional Dependencies and Normalization
Presentation transcript:

Functional Dependencies and Normalization Part 2 Instructor: Mohamed Eltabakh meltabakh@cs.wpi.edu

Properties of FDs Consider A, B, C, Z are sets of attributes Reflexive (trivial): A  B is trivial if B  A

Properties of FDs (Cont’d) Consider A, B, C, Z are sets of attributes Transitive: if A  B, and B  C, then A  C Augmentation: if A  B, then AZ  BZ Union: if A  B, A  C, then A  BC Decomposition: if A  BC, then A  B, A  C Use these properties to derive more FDs

Use the FD properties to derive more FDs Example Use the FD properties to derive more FDs Given R( A, B, C, D, E) F = {A  BC, DE  C, B  D} Is A a key for R or not? Does A determine all other attributes? A  A B C D Is BE a key for R? BE  B E D C Is ABE a candidate or super key for R? ABE  A B E D C AE  A E B C D NO NO >> ABE is a super key >> AE is a candidate key

What to Cover Functional Dependencies (FDs) Closure of Functional Dependencies Lossy & Lossless Decomposition Normalization

Closure of a Set of Functional Dependencies Given a set F set of functional dependencies, there are other FDs that can be inferred based on F For example: If A → B and B → C, then we can infer that A → C Closure set F  F+ The set of all FDs that can be inferred from F We denote the closure of F by F+ F+ is a superset of F Computing the closure F+ of a set of FDs can be expensive

Inferring FDs Suppose we have: Question: a relation R (A, B, C, D) and functional dependencies A  B, C  D, A  C Question: What is a key for R? We can infer A  ABC, and since C  D, then A  ABCD Hence A is a key in R Is it is the only key ???

Attribute Closure Attribute Closure of A Given a set of FDs, compute all attributes X that A determines A  X Attribute closure is easy to compute Just recursively apply the transitive property A can be a single attribute or set of attributes 21

Algorithm for Computing Attribute Closures Computing the closure of set of attributes {A1, A2, …, An}: Let X = {A1, A2, …, An} If there exists a FD: B1, B2, …, Bm  C, such that every Bi  X, then X = X  C Repeat step 2 until no more attributes can be added. X is the closure of the {A1, A2, …, An} attributes X = {A1, A2, …, An} +

Example 1: Inferring FDs Assume relation R (A, B, C) Given FDs : A  B, B  C, C  A What are the possible keys for R ? Compute the closure of each attribute X, i.e., X+ X+ contains all attributes, then X is a key For example: {A}+ = {A, B, C} {B}+ = {A, B, C} {C}+ = {A, B, C} So keys for R are <A>, <B>, <C>

Example 2: Attribute Closure Given R( A, B, C, D, E) F = {A  BC, DE  C, B  D} What is the attribute closure {AB}+ ? {AB}+ = {A B} {AB}+ = {A B C} {AB}+ = {A B C D} What is the attribute closure {BE}+ ? {BE}+ = {B E} {BE}+ = {B E D} {BE}+ = {B E D C} Set of attributes α is a key if α+ contains all attributes

Example 3: Inferring FDs Assume relation R (A, B, C, D, E) Given F = {A  B, B  C, C D  E } Does A  E? The above question is the same as Is E in the attribute closure of A (A+)? Is A  E in the function closure F+ ? A  E does not hold A D  ABCDE does hold A D is a key for R 21

Summary of FDs They capture the dependencies between attributes How to infer more FDs using properties such as transitivity, augmentation, and union Functional closure F+ Attribute closure A+ Relationship between FDs and keys

What to Cover Functional Dependencies (FDs) Closure of Functional Dependencies Lossy & Lossless Decomposition Normalization

Decomposing Relations StudentProf Greg Dave sName p2 p1 pNumber MM s2 s1 pName sNumber FDs: pNumber  pName Lossless Greg Dave sName p2 p1 pNumber s2 s1 sNumber Student MM pName Professor Lossy Greg Dave sName MM pName S2 S1 sNumber Student p2 p1 pNumber Professor

Lossless vs. Lossy Decomposition Assume R is divided into R1 and R2 Lossless Decomposition R1 natural join R2 should create exactly R Lossy Decomposition R1 natural join R2 adds more records (or deletes records) from R

Lossless Decomposition StudentProf Greg Dave sName p2 p1 pNumber MM s2 s1 pName sNumber FDs: pNumber  pName Lossless Greg Dave sName p2 p1 pNumber s2 s1 sNumber Student MM pName Professor Student & Professor are lossless decomposition of StudentProf (Student ⋈ Professor = StudentProf)

Lossy Decomposition StudentProf Greg Dave sName p2 p1 pNumber MM s2 s1 pName sNumber FDs: pNumber  pName Lossy Greg Dave sName MM pName S2 S1 sNumber Student p2 p1 pNumber Professor Student & Professor are lossy decomposition of StudentProf (Student ⋈ Professor != StudentProf)

Goal: Ensure Lossless Decomposition How to ensure lossless decomposition? Answer: The common columns must be candidate key in one of the two relations

Back to our example StudentProf Greg Dave sName p2 p1 pNumber MM s2 s1 pName sNumber pNumber is candidate key FDs: pNumber  pName Lossless Greg Dave sName p2 p1 pNumber s2 s1 sNumber Student MM pName Professor pName is not candidate key Lossy Greg Dave sName MM pName S2 S1 sNumber Student p2 p1 pNumber Professor

What to Cover Functional Dependencies (FDs) Closure of Functional Dependencies Lossy & Lossless Decomposition Normalization

Normalization

Normalization Set of rules to avoid “bad” schema design Decide whether a particular relation R is in “good” form If not, decompose R to be in a “good” form Several levels of normalization First Normal Form (1NF) BCNF Third Normal Form (3NF) Fourth Normal Form (4NF) If a relation is in a certain normal form, then it is known that certain kinds of problems are avoided or minimized

We assume all relations are in 1NF First Normal Form (1NF) Attribute domain is atomic if its elements are considered to be indivisible units (primitive attributes) Examples of non-atomic domains are multi-valued and composite attributes A relational schema R is in first normal form (1NF) if the domains of all attributes of R are atomic We assume all relations are in 1NF

First Normal Form (1NF): Example Since all attributes are primitive  It is in 1NF