Normalization Ioan Despi 2 The basic objective of logical modeling: to develop a “good” description of the data, its relationships and its constraints.

Slides:



Advertisements
Similar presentations
Functional Dependencies and Normalization for Relational Databases
Advertisements

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.
Announcements Read 5.1 – 5.5 for today Read 5.6 – 5.7 for Wednesday Project Step 3, due Monday 10/18 Homework, due Friday 10/15 – by Research paper,
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.
Functional Dependencies and Normalization for Relational Databases.
The Relational Model System Development Life Cycle Normalisation
Chapter 8 Normal Forms Based on Functional Dependencies Deborah Costa Oct 18, 2007.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide
1 Database Design Theory Which tables to have in a database Normalization.
1 CMSC424, Spring 2005 CMSC424: Database Design Lecture 9.
Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Slide
Normalization I.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide
1 Functional Dependency and Normalization Informal design guidelines for relation schemas. Functional dependencies. Normal forms. Normalization.
Databases 6: Normalization
Chapter 14 Advanced Normalization Transparencies © Pearson Education Limited 1995, 2005.
Introduction to Schema Refinement
Chapter 8: Relational Database Design First Normal Form First Normal Form Functional Dependencies Functional Dependencies Decomposition Decomposition Boyce-Codd.
©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.
FUNCTIONAL DEPENDENCIES
IS 230Lecture 8Slide 1 Normalization Lecture 9. IS 230Lecture 8Slide 2 Lecture 8: Normalization 1. Normalization 2. Data redundancy and anomalies 3. Spurious.
NormalizationNormalization Chapter 4. Purpose of Normalization Normalization  A technique for producing a set of relations with desirable properties,
Announcements Read 5.8 – 5.13 for Monday Project Step 3, due Monday 10/18 Homework 4, due Friday 10/15 – by (or turn in Monday in class)
Lecture 6 Normalization: Advanced forms. Objectives How inference rules can identify a set of all functional dependencies for a relation. How Inference.
Objectives of Normalization Develop a good description of the data, its relationships and constraints Produce a stable set of relations that Is a faithful.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide
M Taimoor Khan Course Objectives 1) Basic Concepts 2) Tools 3) Database architecture and design 4) Flow of data (DFDs)
Instructor: Churee Techawut Functional Dependencies and Normalization for Relational Databases Chapter 4 CS (204)321 Database System I.
CS143 Review: Normalization Theory Q: Is it a good table design? We can start with an ER diagram or with a large relation that contain a sample of the.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall, Modified by Dr. Mathis 3-1 David M. Kroenke’s Chapter Three: The Relational.
Normal Forms through BCNF CPSC 356 Database Ellen Walker Hiram College (Includes figures from Database Systems by Connolly & Begg, © Addison Wesley 2002)
Functional Dependencies and Normalization for Relational Databases.
Normalization Well structured relations and anomalies Normalization First normal form (1NF) Functional dependence Partial functional dependency Second.
Chapter Functional Dependencies and Normalization for Relational Databases.
11/07/2003Akbar Mokhtarani (LBNL)1 Normalization of Relational Tables Akbar Mokhtarani LBNL (HENPC group) November 7, 2003.
1 Functional Dependencies and Normalization Chapter 15.
ABSTRACT OF FIRST LECTURE then … the second lesson.
Dr. Mohamed Osman Hegaz1 Logical data base design (2) Normalization.
9/23/2012ISC329 Isabelle Bichindaritz1 Normalization.
Normalization.
Chapter 5.1 and 5.2 Brian Cobarrubia Database Management Systems II January 31, 2008.
Databases Illuminated Chapter 6 Normalization. Objectives of Normalization Develop a good description of the data, its relationships and constraints Produce.
Databases Illuminated
Ch 7: Normalization-Part 1
11/10/2009GAK1 Normalization. 11/10/2009GAK2 Learning Objectives Definition of normalization and its purpose in database design Types of normal forms.
CS411 Database Systems Kazuhiro Minami 04: Relational Schema Design.
Chapter 8 Relational Database Design. 2 Relational Database Design: Goals n Reduce data redundancy (undesirable replication of data values) n Minimize.
1 CS 430 Database Theory Winter 2005 Lecture 8: Functional Dependencies Second, Third, and Boyce-Codd Normal Forms.
NormalisationNormalisation Normalization is the technique of organizing data elements into records. Normalization is the technique of organizing data elements.
ITD1312 Database Principles Chapter 4C: Normalization.
Chapter 14 Functional Dependencies and Normalization Informal Design Guidelines for Relational Databases –Semantics of the Relation Attributes –Redundant.
CSC 411/511: DBMS Design Dr. Nan Wang 1 Schema Refinement and Normal Forms Chapter 19.
Chapter 8 Relational Database Design Topic 1: Normalization Chuan Li 1 © Pearson Education Limited 1995, 2005.
10/3/2017.
Normalization Database Management Systems, 3rd ed., Ramakrishnan and Gehrke, Chapter 19.
Functional Dependency and Normalization
Advanced Normalization
Announcements Read 5.1 – 5.5 for today Read 5.6 – 5.7 for Wednesday
Chapter 15 Basics of Functional Dependencies and Normalization for Relational Databases.
Relational Database Design by Dr. S. Sridhar, Ph. D
Advanced Normalization
Database Management systems Subject Code: 10CS54 Prepared By:
Database Normalization
Schema Refinement What and why
Normalization.
Database Management System
Chapter 7a: Overview of Database Design -- Normalization
Presentation transcript:

Normalization Ioan Despi

2 The basic objective of logical modeling: to develop a “good” description of the data, its relationships and its constraints For the relational model: we must identify a suitable set of relations Normalization = a logical design process that produces a stable set of relations, free of anomalies and with reduced redundancy

3 Anomaly = an inconsistent, incomplete, or contradictory state of the database UpdateInsertionDelete anomalies Research: E. Codd: identified the causes of anomalies and defined the first 3 NF Boyce, Fagin, Date, Zaniolo

4 A relation is in a specific NF if it satisfies the set of requirements or constraints for that form. All the NF are nested, in that each satisfies the constraints of the previous one but is a “better” form because each eliminates flaws found in the previous one All relations 1NF 2NF 3NF BCNF 4NF 5NF

5 Our design objective: to put the schema in the highest NF that is practical and appropiate for the application Normalization = putting a relation into a higher NF using functional dependencies multivalued dependencies join dependencies

6 Functional Dependency A, B, C : attributes or sets of attributes of a relation R B is functionally dependent on A if each value of A in R has associated with it exactly one value of B in R A ---> B “A functionally determines B”, “A determines B” R.A ---> R.B to be more specific The (set of)attribute(s) on the left side of the arrow is called determinant When two rows have the same A value, they must also have the same B value For a given B value, there may be several different A values

7 STUDENT(Sid, Sname, Major, Credits, Status, SSN) Sid ---> Sname Sid --> Same, Major, Credits, Status, SSN SSN--> Same, Major, Credits, Status, Sid

8 Inference rules (Armstrong’s axioms): used to find all the FDs logically implied by a set of FD they are sound and complete Let A, B, C and D be subsets of attributes of a relation R, A  R, B  R, C  R, D  R. AC means A  C, subset of both attributes, A and C. F1. Reflexivity If B is a subset of A, B  A, then A -->B. Obs. A ---> A always holds. We call this kind of dependency trivial functional dependency

9 F3. Transitivity If a --> B and B --> C, then A --> C F2. Augmentation If A --> B, then AC --> BC The following rules can be derived from the previous three: F4. Additivity (Union) If A --> B and A --> C, then A --> BC F5. Projectivity (Decomposition) If A --> BC, then A --> B and A --> C F6. Pseudotransitivity If A --> B and CB --> D, then AC --> D

10 First normal form (1NF) A relation is in 1NF if and only if every attribute is single - valued for each tuple. Each attribute in each row, or each “cell” of the table contains only one value No repeating fields or groups are allowed The domains of the attributes are atomic (they consist of single units that cannot be broken down further).

11

12

13 Full Functional Dependency

14 Class (Course#, Sid, Sname, Facid, Sched, Room, Grade) FD: {Course#, Sid} --> Sname, Facid, Sched, Room, Grade Course# --> Facid, Sched, Room Sid ---> Sname {Course#, Sid} --> Grade Definition. Attribute B is fully functional dependent on an attribute A if B is functionally dependent on A but not functionally dependent on any proper subset of A.

15 Second Normal Form (2 NF) A relation is in 2NF iff it is in 1NF and all the nonkeys attributes are fully functional dependent on the key. CLASS2 (Course#, Sid, Grade)

16 STUD (Sid, Sname) COURSE(Course#, Facid, Sched, Room)

17 Transitive dependency: STUD (Sid, Sname, Major, Credits, Status) Sid --> Credits Credits --> Status Sid --> Status Definition. A relation is in 3NF if it is in 2NF and no nonkey attribute is transitively dependent on that key.

18 STUD (Sid, Sname, Major, Credits, Status)

19 STUD2 (Sid,Sname, Major, Credits) STATS (Credits, Status)

20 Definition. A relation is in BCNF if and only if every determinant is a candidate key. FACULTY (Facname, Dept, Office, Rank, Datehired) Example with overlapping keys: Office  Dept Facname, Dept  Office, Rank. Datehired Facname, Office  Dept, Rank, Datehired Candidate keys: Facname, Dept Facname, Office BCNF relations: FAC1 (Dept, Office) FAC2 (Facname, Office, Rank, Datehired)

21 Comprehensive example of functional dependencies: table WORK

22 1. Each project has a unique name, but names of employees and managers are not unique 2. Each project has one manager, whose name is stored in Prjmgr 3. Many employees may be assigned to work on each project, and an employee may be assigned to more than one project. Hours tells the number of hours per week that a particular employee is assigned to work on a particular project 4. Budget stores the amount budgeted for a project, and Startdate gives the starting date for a project 5. Salary gives the annual salary of an employee 6. Empmgr gives the name of the employee’s manager, eho is not the same as the project manager 7. Empdept gives the employee’s department. Department names are unique. The employee’s manager is the manager of the employee’s department. 8. Rating gives the employee’s rating for a particular project. The project manager assigns the rating at the end of the employee’s work on that project. Prjname --> Prjmgr, Bufget, Startdate Empid --> Empname, Slary, Empmgr, Empdept Prjname, Empid --> Hours, Rating

23 Since we assumed that people’s names were not unique, Empmgr does not functionally determine Empdept However, since department names are unique and each department has only one manager, we add Empdept --> Empmgr Because people’s names are not unique, Prjmgr does not determine Prjname. Remember that FD does not mean “causes” or “figures out”, so ther eare no FD between Prjmgr [NOT -->] {Budget, Rating} Since we see that every attribute is Fd on the combination {Prjname, Empid}, we will choose that combination as our primary key 1NF: with our composite key, each cell would be single-valued, so WORK is in 1NF 2NF: We found partial (nonfull) dependencies: Prjname --> Prjmgr, Budget, Startdate Empid --> Empname, Salary, Empmgr, Empdept We transform the relation into an equivalent set of 2NF relations by projection, resulting in: PROJ (Prjname, Prjmgr, Budget, Startdate) EMP (Empid, Empname, Salary, Empmgr, Empdept) WORK1 (Prjname, Empid, Hours, Rating)

24 3NF: Using the set of the above projections, we test each relation for 3NF. PROJ is 3NF because no nonkey attribute functionally determines another nonkey attribute. In EMP we have a transitive dependency, Empdept --> Empmgr. Therefore, we need to rewrite EMP as: EMP1 (Empid, Empname, Salary, Empdept) DEPT (Empdept, Empmgr) In WORK1, there is no FD between Hours and Rating, so the relation is already in 3NF BCNF: Our new set of relations is also BCNF, since in each relation the only determinant is the primary key: PROJ (Prjname, Prjmgr, Budget, Startdate) WORK1 (Prjname, Empid, Hours, Rating) EMP1 (Empid, Empname, Salary, Empdept) DEPT (Empdept, Empmgr)

25 We already know that our original relation could not have been BCNF, since it was not even in 2NF. To verufy the fact that WORK was not BCNF, all we need to do was find a determinant that was not a candidate key. Any one of Empid, Empdept or Projname is sufficient to show that the original WORK relation was not BCNF

26 Multivalued Dependencies FACULTY (Facid, Dept, Committee) Here we will assume that a faculty member can belong to more than one department. For example, a professor can be hired jointly by the CSC and Math departments. A faculty member can belong to several college-wide committees, each identified by the committee name. There is no relationship between department and committees.

27

28 Definition. Let R be a relation having attributes or sets of attributes A, B and C. There is a multivalued dependency of attribute B on attribute A if and only if the set of B values associated with a given A value is independent of the C values. A  B “ A multidetermines B” In R (A, B, C), if A  B, then A  C as well.

29

30 Definition. A relation is in 4NF if and only if it is in BCNF and there are no nontrivial multivalued dependencies. The FACULTY relation from slide 27 is not in 4NF because of the non trivial multivalued dependencies: Facid  Dept Facid  Committee When a relation is BCNF but not 4NF, we can transform it into an equivalent set of 4NF relations by projection. We form two separate relations, placing in each the attribute that multideteermines the others, along with one of the multidetermined attributes or sets of attributes.

31 FAC1 (Facid, Dept) FAC2 (Facid, Committee)

32 Definition. A decomposition of a relation R is a set of relations {R 1, R 2, …, R n } such that each R i is a subset of R and the union of all the R i is R. Note that the R i need not be disjoint. Definition. A decomposition {R 1, R 2, …, R n } of a relation R is called losless decomposition for R if the natural join of R 1, R 2, …, R n produces exactly the relation R. Not every decomposition is losless. It is possible to produce a decomposition that is lossy, one that loses information.

33

34 A join which produces more tuples than in the original table

35 Definition. A relation is in 5NF if no remaining nonless projections are possible, except the trivial one in which the key appears in each projection An alternative formulationof 5NF: with the notion of join dependency:A join dependency means that a relation can be reconstructed by taking the join of its projections. Thus, if R (A, B, C) is decomposed into R 1 (A, C) and R 2 (B, C), a join dependency exists if we can get back R by taking the join of R 1 and R 2, R = R 1 JOIN R 2 As we have seen from our MARKS example, not all projections have this property.

36 Definition. A relation is in domain-key normal form (DKNF) if every constraint is a logical consequence of domain constraints or key constraints. Fagin have proved that a relation in this form cannot have update, insertion or deletion anomalies. Therefore, this form represents the ultimate NF with respect to these defects. Domain = the set of allowable values for an attribute Key = a unique identifier for each entity (we called it superkey) Constraint = a logical predicate which we can verify by examining instances of the relation Although FD, MD and JD are constraints, there are other types, called “general constraints”, as well ( intrarelation dependencies).