Normalization of Database Lecture - ANS Yong Choi School of Business CSUB.

Slides:



Advertisements
Similar presentations
Normalization of Database
Advertisements

Chapter 5 Normalization of Database Tables
5 5 Normalization of Database Tables Database Systems: Design, Implementation, and Management 4th Edition Peter Rob & Carlos Coronel.
Chapter 5 Normalization of Database Tables
Chapter 5 Normalization of Database Tables
Normalization Dr. Mario Guimaraes. Data Normalization Primarily a tool to validate and improve a logical design so that it satisfies certain constraints.
Normalisation The theory of Relational Database Design.
4 TH NORMAL FORM & Lossless Decomposition By: Karen McVay CS 157B.
Chapter 5 Normalization of Database Tables
Jump to first page Normalization Jump to first page Topics n Why normalization is needed n What causes anomalies n What the 4 normal forms are n How.
Chapter 8 Normal Forms Based on Functional Dependencies Deborah Costa Oct 18, 2007.
Information Resources Management March 13, Agenda n Administrivia n Normalization n Homework #7 n Mid-Term #2.
Need for Normalization
Database Design Conceptual –identify important entities and relationships –determine attribute domains and candidate keys –draw the E-R diagram Logical.
Normalization Practice Yong Choi BPA CSUB. 1NF Customer_IDNameAddressCompany Name 104Mr. Ray Suchecki 123 Pond Hill Road, Detroit, MI, CSUB 624Mr.
1 5 Concepts of Database Management, 4 th Edition, Pratt & Adamski Chapter 5 Database Design: Normalization.
Normalization of Database Tables
4 Normal Form Nathanael Chow CS 157A Fall 2006 Dr. Lee.
Normalization of Database Tables
Normalization of Database Tables
Chapter 5 Normalization of Database Tables
Database Systems Design, Implementation, and Management Coronel | Morris 11e ©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or.
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 5 Normalization of Database Tables.
1 5 Concepts of Database Management, 4 th Edition, Pratt & Adamski Chapter 5 Database Design 1: Normalization.
NORMALIZATION N. HARIKA (CSC).
Introduction to Schema Refinement
Normalization of relational database Data redundance Second Normal Form Third Normal Form Forth Normal Form.
Lecture 12 Inst: Haya Sammaneh
Normalization. 2 Objectives u Purpose of normalization. u Problems associated with redundant data. u Identification of various types of update anomalies.
NormalizationNormalization Chapter 4. Purpose of Normalization Normalization  A technique for producing a set of relations with desirable properties,
Database Systems: Design, Implementation, and Management Tenth Edition
Concepts of Database Management, Fifth Edition
Database Management COP4540, SCS, FIU Relation Normalization (Chapter 14)
5 1 Chapter 5 Normalization of Database Tables Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel.
The Relational Model and Normalization R. Nakatsu.
Normalization. Learners Support Publications 2 Objectives u The purpose of normalization. u The problems associated with redundant data.
Lecture 6 Normalization: Advanced forms. Objectives How inference rules can identify a set of all functional dependencies for a relation. How Inference.
BIS Database Systems School of Management, Business Information Systems, Assumption University A.Thanop Somprasong Chapter # 5 Normalization of Database.
Logical Database Design Relational Model. Logical Database Design Logical database design: process of transforming conceptual data model into a logical.
Chapter 7 1 Database Principles Data Normalization Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that.
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.
Normalization Well structured relations and anomalies Normalization First normal form (1NF) Functional dependence Partial functional dependency Second.
Database Design – Lecture 8
Normalization of Database Tables
Data Analysis Improving Database Design. Normalization The process of transforming a data model into a flexible, stable structure. Reduces anomalies Anomaly.
Normalization. 2 u Main objective in developing a logical data model for relational database systems is to create an accurate representation of the data,
Normalization Example. Database Systems, 8 th Edition 2 Database Tables and Normalization Normalization –Process for evaluating and correcting table structures.
Brian Thoms.  Databases normalization The systematic way of ensuring that a database structure is suitable for general-purpose querying and free of certain.
Logical Database Design and the Relational Model.
NormalisationNormalisation Normalization is the technique of organizing data elements into records. Normalization is the technique of organizing data elements.
Week 4 Lecture Part 1 of 3 Normalization of Database Tables Samuel ConnSamuel Conn, Asst. Professor.
Database Architecture Normalization. Purpose of Normalization A technique for producing a set of relations with desirable properties, given the data requirements.
Decomposition and Normalization Fan Qi
5 1 Chapter 5 Normalization of Database Tables Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel.
SLIDE 1IS 257 – Fall 2006 Normalization Normalization theory is based on the observation that relations with certain properties are more effective.
Copyright © 2016 Pearson Education, Inc. Modern Database Management 12 th Edition Jeff Hoffer, Ramesh Venkataraman, Heikki Topi CHAPTER 4: PART C LOGICAL.
Database Normalization. What is Normalization Normalization allows us to organize data so that it: Normalization allows us to organize data so that it:
1 CS490 Database Management Systems. 2 CS490 Database Normalization.
4TH NORMAL FORM By: Karen McVay.
Chapter 5: Logical Database Design and the Relational Model
Functional Dependencies
A SIMPLE GUIDE TO FIVE NORMAL FORMS (See the next slide for required reading) Prof. Ghandeharizadeh 2018/11/14.
Chapter 6 Normalization of Database Tables
Normalization Practice
Normalization Practice ANS
CS 3630 Database Design and Implementation
Normalization Normalization theory is based on the observation that relations with certain properties are more effective in inserting, updating and deleting.
4 Normal Form.
Normalization of DB relations examples Fall 2015
Normalization Practice
Presentation transcript:

Normalization of Database Lecture - ANS Yong Choi School of Business CSUB

2 1NF Example Unnormalized Table PK

3 1NF Example (con’t.) Conversion to 1NF PK

4 Another 1NF Example Cust_IDNameStreetPhone 104Mr. Ray Suchecki 123 Pond Hill Road, Detroit, MI, (313) Cust_IDSalesRep_NameRep_OfficeOrder_1Order_2Order_3 1022Jones PK

5 2NF Example PK Each arrow shows partial dependency

6 2NF Example

7 Example of 3NF PK: Cust_ID

8 Relation with transitive dependency PK

9 Transitive dependency All attributes are functionally dependent on Cust_ID. –Cust_ID -> Name –Cust_ID -> Salesperson –Cust_ID -> Region However, there is a transitive dependency. –Region is functionally dependent on Salesperson. –Salesperson -> Region

10 Problems with Transitive dependency A new sales person (Yong) assigned to the North region cannot be entered until a customer has been assigned to that salesperson (since a value for Cust_ID must be provided to insert a row in the relation). If customer number 6837 is deleted from the table, we lose the information that salesperson Hernandez is assigned top the Easy region. If sales person Smith is reassigned to the East region, several rows must be changed to reflect that fact.

11 Decomposing the SALES relation

12 Relations in 3NF Now, there are no transitive dependencies… Both relations are in 3 rd NF CustID  Name CustID  Salesperson Salesperson  Region

13 Dependency Diagram

14 Boyce-Codd Normal Form (BCNF) Special case of 3NF. A relation is in BCNF if it’s in 3NF and there is no hidden dependencies. Below is in 3NF but not in BCNF

15 BCNF Stu_IDAdvisorMajorGPA 123NasaPhysics ElvisMusic KingLiterature JacksonMusic NasaPhysics3.5 Student

16 BCNF Stu_IDAdvisorMajorGPA Don’t confuse with Transitive Dependency! Advisor is functionally dependent on Major.

17 BCNF In Physics the advisor Nasa is replaced by Einstein. This change must be made in two ( or more) rows in the table. If we want to insert a row with the information that Choi advises in MIS. This cannot be done until at least one student majoring in MIS is assigned Choi as an advisor. If student number 789 withdraw from school, we lose the information that Jackson advises in Music.

18 Conversion to BCNF Stu_IDAdvisorGPA 123Nasa Elvis King Jackson Nasa3.5 AdvisorMajor NasaPhysics ElvisMusic KingLiterature JacksonMusic Student Advisor

19 Decomposition into BCNF

20 3NF and BCNF In practice, most relation schemas that are in 3NF are also in BCNF. Only if a hidden dependency X -> A exists in a relation. In general, it is best to have relation schemas in BCNF. If that is not possible, 3NF will do. However, 2NF and 1NF are not considered good relation schema designs.

21 4NF A relation is in 4NF if it is already in 3NF and does not contain two multi-valued dependencies that are independent.- it’s a different meaning than not having multi- valued attributes for 1NF. e.g., Smith can cook and type. Smith speaks French, German, and Greek

22 4NF E_NameSkillLanguage Smithcooknull Smithtypenull SmithnullFrench SmithnullGerman SmithnullChinese E-Name ->-> Skill E-Name ->-> Language PK

23 4NF The values for Skill and the values for Language are independent. E_NameSkillE_NameLanguage SmithCookSmithFrench SmithTypeSmithGerman SmithChinese PK

24 Faculty (A) relation FacultyNumStudentNumCommitteeCode ADV HSG PER HSG CUR Faculty (A) – normalized table

25 Faculty (A) relation Each FacultyNum has a well-defined set of StudentNums. Each FacultyNum has a well-defined set of CommitteeCodeses. The STUDENTNUM and the COMMITTEECODE are independent of each other.

26 Faculty (B) relation Faculty (B)

27 Faculty (B) relation Has a composite PK –FacultyNum, StudentNum, and CommitteeCode Since there are no determinants other than the PKs, the relation is in BCNF. Yet it does contain much redundant data that can easily lead to update anomalies because of multi-valued dependencies.

28 Problems with Faculty (B) relation Changing the CommitteeCode for faculty member requires more than one change. Suppose that a new faculty member 555 but does not yet serve on any committee. When a facultyNum 555 begins advising student 44332, there is a problem because the CommitteeCode is a part of PK. If faculty member 444 no longer advises student and delete appropriate record from the relation, we lose the information that faculty member serves on the Housing committee (HSG).

29 Conversion to 4NF