Consider a relation R with attributes ABCDEF GH and functional dependencies S:

Similar documents
Consider a relation R with attributes ABCDEF GH and functional dependencies S:

Normal Forms Lossless Join.

DESIGN THEORY FOR RELATIONAL DATABASES. csc343, Introduction to Databases Renée J. Miller and Fatemeh Nargesian and Sina Meraji Winter 2018

Design theory for relational databases

Design Theory for Relational Databases

Chapter 3 Design Theory for Relational Databases

Chapter 11, Relational Database Design Algorithms and Further Dependencies

Lossless Joins, Third Normal Form

Normal Forms (ii) ICS 321 Fall Asst. Prof. Lipyeow Lim Information & Computer Science Department University of Hawaii at Manoa

CSC 261/461 Database Systems Lecture 13. Spring 2018

Relational Database Design

1. Binary Decomposition Approach: Considering R: Keys ={BEFG, CEFG, EFGH} F = {CD A, EC H, GHB AB, C D, EG A, H B, BE CD, EC B}

Functional Dependency and Algorithmic Decomposition

UVA UVA UVA UVA. Database Design. Relational Database Design. Functional Dependency. Loss of Information

Information Systems for Engineers. Exercise 8. ETH Zurich, Fall Semester Hand-out Due

Functional Dependencies. Getting a good DB design Lisa Ball November 2012

CS54100: Database Systems

Normaliza)on and Func)onal Dependencies

Design Theory for Relational Databases

SCHEMA NORMALIZATION. CS 564- Fall 2015

Homework 2 (by Prashasthi Prabhakar) Due: Wednesday Sep 20, 11:59pm

DECOMPOSITION & SCHEMA NORMALIZATION

CSC 261/461 Database Systems Lecture 11

Comp 5311 Database Management Systems. 5. Functional Dependencies Exercises

CS 186, Fall 2002, Lecture 6 R&G Chapter 15

FUNCTIONAL DEPENDENCY THEORY. CS121: Relational Databases Fall 2017 Lecture 19

Lectures 6. Lecture 6: Design Theory

Normal Forms. Dr Paolo Guagliardo. University of Edinburgh. Fall 2016

Relational Database Design Theory Part II. Announcements (October 12) Review. CPS 116 Introduction to Database Systems

Functional Dependencies and Normalization

Databases Lecture 8. Timothy G. Griffin. Computer Laboratory University of Cambridge, UK. Databases, Lent 2009

Information Systems (Informationssysteme)

Review: Keys. What is a Functional Dependency? Why use Functional Dependencies? Functional Dependency Properties

Homework 2 (by Prashasthi Prabhakar) Solutions Due: Wednesday Sep 20, 11:59pm

Schema Refinement & Normalization Theory

INF1383 -Bancos de Dados

CSC 261/461 Database Systems Lecture 10 (part 2) Spring 2018

Functional Dependencies. Applied Databases. Not all designs are equally good! An example of the bad design

Relational Design Theory II. Detecting Anomalies. Normal Forms. Normalization

Schema Refinement and Normal Forms. The Evils of Redundancy. Schema Refinement. Yanlei Diao UMass Amherst April 10, 2007

CSC 261/461 Database Systems Lecture 8. Spring 2017 MW 3:25 pm 4:40 pm January 18 May 3 Dewey 1101

Relational-Database Design

10/12/10. Outline. Schema Refinements = Normal Forms. First Normal Form (1NF) Data Anomalies. Relational Schema Design

Databases 2012 Normalization

CSC 261/461 Database Systems Lecture 12. Spring 2018

Design Theory. Design Theory I. 1. Normal forms & functional dependencies. Today s Lecture. 1. Normal forms & functional dependencies

Relational Design Theory

Schema Refinement and Normal Forms. Case Study: The Internet Shop. Redundant Storage! Yanlei Diao UMass Amherst November 1 & 6, 2007

Relational Database Design

Functional Dependency Theory II. Winter Lecture 21

Functional Dependencies & Normalization. Dr. Bassam Hammo

Introduction. Normalization. Example. Redundancy. What problems are caused by redundancy? What are functional dependencies?

Database Design and Implementation

Schema Refinement and Normalization

Exam 1 Solutions Spring 2016

Problem about anomalies

zone# Garbage_Truck ships_to Garbage_Structure structid max_age

Relational Design: Characteristics of Well-designed DB

Normalization. October 5, Chapter 19. CS445 Pacific University 1 10/05/17

CS122A: Introduction to Data Management. Lecture #13: Relational DB Design Theory (II) Instructor: Chen Li

CSE 544 Principles of Database Management Systems

CSIT5300: Advanced Database Systems

Design Theory for Relational Databases. Spring 2011 Instructor: Hassan Khosravi

Schema Refinement and Normal Forms

Schema Refinement and Normal Forms

Background: Functional Dependencies. æ We are always talking about a relation R, with a æxed schema èset of attributesè and a

Schema Refinement & Normalization Theory: Functional Dependencies INFS-614 INFS614, GMU 1

Schema Refinement. Feb 4, 2010

Schema Refinement and Normal Forms. The Evils of Redundancy. Functional Dependencies (FDs) [R&G] Chapter 19

The Evils of Redundancy. Schema Refinement and Normal Forms. Functional Dependencies (FDs) Example: Constraints on Entity Set. Example (Contd.

Constraints: Functional Dependencies

The Evils of Redundancy. Schema Refinement and Normal Forms. Example: Constraints on Entity Set. Functional Dependencies (FDs) Example (Contd.

The Evils of Redundancy. Schema Refinement and Normal Forms. Example: Constraints on Entity Set. Functional Dependencies (FDs) Refining an ER Diagram

Schema Refinement and Normal Forms. The Evils of Redundancy. Functional Dependencies (FDs) CIS 330, Spring 2004 Lecture 11 March 2, 2004

The Evils of Redundancy. Schema Refinement and Normalization. Functional Dependencies (FDs) Example: Constraints on Entity Set. Refining an ER Diagram

Introduction to Data Management CSE 344

CSE 344 AUGUST 6 TH LOSS AND VIEWS

Functional Dependencies

Chapter 3 Design Theory for Relational Databases

Introduction to Management CSE 344

HKBU: Tutorial 4

12/3/2010 REVIEW ALGEBRA. Exam Su 3:30PM - 6:30PM 2010/12/12 Room C9000

Designing Information Devices and Systems I Spring 2018 Lecture Notes Note 3

CSE 344 MAY 16 TH NORMALIZATION

CMPT 354: Database System I. Lecture 9. Design Theory

Database Design: Normal Forms as Quality Criteria. Functional Dependencies Normal Forms Design and Normal forms

Introduction to Data Management. Lecture #7 (Relational DB Design Theory II)

CSE 344 AUGUST 3 RD NORMALIZATION

CSE 132B Database Systems Applications

CS322: Database Systems Normalization

Relational Design Theory I. Functional Dependencies: why? Redundancy and Anomalies I. Functional Dependencies

11/6/11. Relational Schema Design. Relational Schema Design. Relational Schema Design. Relational Schema Design (or Logical Design)

Schema Refinement and Normal Forms. Why schema refinement?

Constraints: Functional Dependencies

Chapter 7: Relational Database Design

Schema Refinement and Normal Forms

Relational Database Design

Chapter 7: Relational Database Design. Chapter 7: Relational Database Design

Normal Forms 1. ICS 321 Fall Asst. Prof. Lipyeow Lim Information & Computer Science Department University of Hawaii at Manoa

Practice and Applications of Data Management CMPSCI 345. Lecture 16: Schema Design and Normalization

Transcription:

University of Toronto CSC343 Sample 3NF Problem Questions Consider a relation R with attributes ABCDEF GH and functional dependencies S: S = {A CD, ACF G, AD BEF, BCG D, CF AH, CH G, D B, H DEG} 1. Compute a minimal basis for S. In your final answer, put the FDs into alphabetical order. 2. Using the minimal basis from part (b), employ the 3NF synthesis algorithm to obtain a lossless and dependency-preserving decomposition of relation R into a collection of relations that are in 3NF. 3. Does your schema allow redundancy? Explain all your answers and show your rough work. 1

Solutions Although one can often skip ahead to some of the conclusions or combine steps, these solutions are very systematic, so that you can see the full pattern. Important note: This solution does elimination of redundant FDs before the simplification of LHSs. This is a legitimate approach, and is how it is described in the text, but it requires iterating over these two steps until no more changes are possible. We have learned to do the steps in the opposite order, and in that case we don t need to iterate. 1. Compute a minimal basis for S. In your final answer, put the FDs into alphabetical order. To find a minimal basis, we ll first eliminate redundant FDs. The order in which we do this will affect with results we get, but we will always get a minimal basis. We ll simplify to singleton right-hand sides before doing so, since it may be possible to eliminate some but not all of FDs that we get from one of our original FDs. We ll also number the resulting FDs for easy reference, and call this set S1: 3 ACF G 4 AD B 5 AD E 10 CH G Now we ll look for redundant FDs to eliminate. Each row in the table below indicates which of the 14 FDs we still have on hand as we consider removing the next one. Of course, as we do the closure test to see whether we can remove X Y, we can t use X Y itself, so an FD is never included in its own row. 2

Exclude these from S1 FD when computing closure Closure Decision 1 1 There s no way to get C without this FD keep 2 2 A+ = AC keep 3 3 ACF + = ACF DBEHG discard 4 3, 4 AD+ = ADCEF B... discard 5 3, 4, 5 AD+ = ADCF GBE... discard 6 3, 4, 5, 6 There s no way to get F without this FD keep 7 3, 4, 5, 7 BCG+ = BCG keep 8 3, 4, 5, 8 There s no way to get A without this FD keep 9 3, 4, 5, 9 There s no way to get H without this FD keep 10 3, 4, 5, 10 CH+ = CHDEG... discard 11 3, 4, 5, 10, 11 There s no way to get B without this FD keep 12 3, 4, 5, 10, 12 H+ = HEG keep 13 3, 4, 5, 10, 13 There s no way to get E without this FD keep 14 3, 4, 5, 10, 14 There s no way to get G without this FD keep Let s call the remaining FDs S2: Now let s try reducing the LHS of any FDs with multiple attributes on the LHS. For these closures, we will close over the full set S2, including even the FD being considered for simplification; remember that we are not considering removing the FD, just strengthening it. A + = ACDF... so we can reduce the LHS to A. B + = B so we can t reduce the LHS to B. C + = C so we can t reduce the LHS to C. G + = G so we can t reduce the LHS to G. BC + = BC so we can t reduce the LHS to BC. BG + = BG so we can t reduce the LHS to BG. CG + = CG so we can t reduce the LHS to CG. So this FD remains as it is. C + = C so we can t reduce the LHS to C. F + = F so we can t reduce the LHS to F. So this FD remains as it is. We saw above that C + = C and F + = F, so this FD remains as it is. Let s call the set of FDs that we have after reducing left-hand sides S3: 3

6 A F Although we ve looked at every FD for elimination and have tried simplifying every LHS with multiple attributes, we must look again in case any of the changes we made allow further simplification. Exclude these from S3 FD when computing closure Closure Decision 1 1 There s no way to get C without this FD keep 2 2 A+ = ACF HD... discard!!! 6 6 There s no way to get F without this FD keep 7 2, 7 BCG+ = BCG keep 8 2, 8 There s no way to get A without this FD keep 9 2, 9 There s no way to get H without this FD keep 11 2, 11 There s no way to get B without this FD keep 12 2, 12 H+ = HEG keep 13 2, 13 There s no way to get E without this FD keep 14 2, 14 There s no way to get G without this FD keep How is it possible that we can discard FD 2 now, when we tried and failed to discard it earlier? Because we have FD 6 (A F ) now instead of FD 6 (AD F ). This allows a closure to get to F from A alone, without D. No further simplifications are possible. So the following set S4 is a minimal basis: 6 A F 2. Using the minimal basis from the previous step, employ the 3NF synthesis algorithm to obtain a lossless and dependency-preserving decomposition of relation R into a collection of relations that are in 3NF. Following the 3NF synthesis algorithm, we would get one relation for each FD. However, we can merge the right-hand sides before doing so. This will yield a smaller set of relations and they will still form a lossless and dependency-preserving decomposition of relation R into a collection of relations that are in 3NF. 4

Let s call the revised FDs S5: A CF BCG D CF AH D B H DEG The set of relations that would result would have these attributes: R1(A, C, F ), R2(B, C, D, G), R3(A, C, F, H), R4(B, D), R5(D, E, G, H) Since the attributes BD occur within R2, we don t need to keep the relation R4. Similarly, since the attributes ACF occur in R3, we don t need to keep the relation R1. A is a key of R, so there is no need to add another relation that includes a key. So the final set of relations is: 3. Does your schema allow redundancy? R2(B, C, D, G), R3(A, C, F, H), R5(D, E, G, H) Because we formed each relation from an FD, the LHS of those FDs are indeed superkeys for their relations. However, there may be other FDs that violate BCNF and therefore allow redundancy. The only way to find out is to project the FDs onto each relation. We can quite quickly find a relation that violates BCNF without doing all the full projections: Clearly D B will project onto the relation R2. And D + = DB, so D is not a superkey of this relation. So yes, these schema allows redundancy. 5