1 5 Chapter 5 Database Design 1: Some Normalization Examples Spring 2006.

Slides:



Advertisements
Similar presentations
Database Design: Normalization J.G. Zheng June 29 th 2005 DB Chapter 4.
Advertisements

Normalisation.
PMIT-6102 Advanced Database Systems By- Jesmin Akhter Assistant Professor, IIT, Jahangirnagar University.
BTM 382 Database Management Chapter 6: Normalization of Database Tables Chitu Okoli Associate Professor in Business Technology Management John Molson School.
Chapter 5 Normalization of Database Tables
Accounting 6500 Relational Databases: Accounting Applications Introduction to Normalization.
Information Resources Management March 13, Agenda n Administrivia n Normalization n Homework #7 n Mid-Term #2.
Database Design Conceptual –identify important entities and relationships –determine attribute domains and candidate keys –draw the E-R diagram Logical.
CS263:Revision on Normalisation
Relation StudentAdvisor ( St_id, St_fname, St_lname, St_major, Semester, Adv_fname, Adv_lname, Adv_ , Adv_dept, Adv_id) Primary Key: St_id, Semester.
Relational Data Analysis II. Plan Introduction Structured Methods –Data Flow Modelling –Data Modelling –Relational Data Analysis Feasibility Maintenance.
Chapter 5 Normalization of Database Tables
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 5 Normalization of Database Tables.
Terms - data,information, file record, table, row, column, transaction, concurrency Concepts - data integrity, data redundancy, Type of databases – single-user,
NORMALIZATION N. HARIKA (CSC).
Logical Relational Database Design. Logical Relational Design Purpose of logical data design is to represent application data in the form of related 2-dimensional.
Chapter 5 Normalization of Database Tables
Chapter 4: Logical Database Design and the Relational Model (Part II)
Chapter 1 Overview of Database Concepts Oracle 10g: SQL
1 Chapter 1 Overview of Database Concepts. 2 Chapter Objectives Identify the purpose of a database management system (DBMS) Distinguish a field from a.
Lecture 2 An Overview of Relational Database IST 318 – DB Admin.
Avoiding Database Anomalies
Normalization. Rigorous technique used to break down data represented in a user view into a set of 2- dimensional tables where “all attributes in the.
Normalization A technique that organizes data attributes (or fields) such that they are grouped to form stable, flexible and adaptive entities.
Module Title? DBMS Normalization. Module Title? DBMS Normalization  Normalization is the process of removing redundant data from tables in order to improve.
Normalisation Mia’s Sandwich Shop The Process Explained.
Concepts of Relational Databases. Fundamental Concepts Relational data model – A data model representing data in the form of tables Relations – A 2-dimensional.
BIS Database Systems School of Management, Business Information Systems, Assumption University A.Thanop Somprasong Chapter # 5 Normalization of Database.
Copyright Ó Oracle Corporation, All rights reserved. Normalization Use the student note section below for further explanation of the slide content.Use.
Logical Database Design Relational Model. Logical Database Design Logical database design: process of transforming conceptual data model into a logical.
SALINI SUDESH. Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that avoid unnecessary duplication of.
Chapter 7 1 Database Principles Data Normalization Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that.
Lecture9:Functional Dependencies and Normalization for Relational Databases Prepared by L. Nouf Almujally Ref. Chapter Lecture9 1.
IMS 4212: Normalization 1 Dr. Lawrence West, Management Dept., University of Central Florida Normalization—Topics Functional Dependency.
Normalization Well structured relations and anomalies Normalization First normal form (1NF) Functional dependence Partial functional dependency Second.
1 5 Normalization. 2 5 Database Design Give some body of data to be represented in a database, how do we decide on a suitable logical structure for that.
Chapter 1Introduction to Oracle9i: SQL1 Chapter 1 Overview of Database Concepts.
ITN Table Normalization1 ITN 170 MySQL Database Programming Lecture 3 :Database Analysis and Design (III) Normalization.
Database Design – Lecture 8
Component 4/Unit 6d Topic IV: Design a simple relational database using data modeling and normalization Description and Information Gathering Data Model.
Database Design – Lecture 9 Normalization Continued.
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 MIS335 Database Systems. Why Normalization? Optimizing database structure Removing duplications Accelerating the instructions Data integrity!
PMIT-6102 Advanced Database Systems By- Jesmin Akhter Assistant Professor, IIT, Jahangirnagar University.
Normalization Example. Database Systems, 8 th Edition 2 Database Tables and Normalization Normalization –Process for evaluating and correcting table structures.
PMIT-6102 Advanced Database Systems
Logical (Information Level) Design of Relational Databases.
BSA206 Database Management Systems Lecture 2: Introduction to Oracle / Overview of Database Concepts.
© 2009 Pearson Education, Inc. Publishing as Prentice Hall 1 Chapter 5 (Part c): Logical Database Design and the Relational Model Modern Database Management.
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 7 Normalization Hour1,2 Presented & Modified by Mahmoud Rafeek Alfarra.
Normalisation 1NF to 3NF Ashima Wadhwa. In This Lecture Normalisation to 3NF Data redundancy Functional dependencies Normal forms First, Second, and Third.
Chapter 8: Object-Relational Modeling Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey A. Hoffer.
Lecture 4: Logical Database Design and the Relational Model 1.
IMS 4212: Normalization 1 Dr. Lawrence West, Management Dept., University of Central Florida Normalization—Topics Functional Dependency.
IT-501 Database Management Systems By- Jesmin Akhter Assistant Professor, IIT, Jahangirnagar University.
Logical Database Design and Relational Data Model Muhammad Nasir
Chapter 4 © 2013 Pearson Education, Inc. Publishing as Prentice Hall Chapter 4: Logical Database Design and the Relational Model Modern Database Management.
SLIDE 1IS 257 – Fall 2006 Normalization Normalization theory is based on the observation that relations with certain properties are more effective.
Relational Data Model, Review Relation Tuple Attribute Domains Candidate key, primary key Key attribute, non-key attribute.
Lecture # 17 Chapter # 10 Normalization Database Systems.
Copyright © 2016 Pearson Education, Inc. Modern Database Management 12 th Edition Jeff Hoffer, Ramesh Venkataraman, Heikki Topi CHAPTER 4: PART C LOGICAL.
Normalisation Worked example for an Order Remember : The data should depend upon the key, the whole key and nothing but the key.
Normal Forms 1NF – A table that qualifies as a relation is in 1NF. (Back)(Back) 2NF – A relation is in 2NF if all of its nonkey attributes are dependent.
Normalizing Database Designs. 2 Objectives In this chapter, students will learn: –What normalization is and what role it plays in the database design.
SEEM3430: Information Systems Analysis and Design
Some Normalization Examples
CHAPTER 4: LOGICAL DATABASE DESIGN AND THE RELATIONAL MODEL
Chapter 8 – Part2 Database Design.
Chapter 8 – Part2 Database Design.
Some Normalization Examples
Presentation transcript:

1 5 Chapter 5 Database Design 1: Some Normalization Examples Spring 2006

2 5 Dependencies: Definitions u Multivalued Attributes (or repeating groups): non- key attributes or groups of non-key attributes the values of which are not uniquely identified by (directly or indirectly) (not functionally dependent on) the value of the Primary Key (or its part).

3 5 Dependencies: Definitions u Partial Dependency – when an non-key attribute is determined by a part, but not the whole, of a COMPOSITE primary key. Partial Dependency

4 5 Dependencies: Definitions u Transitive Dependency – when a non- key attribute determines another non-key attribute. Transitive Dependency

5 5 Normal Forms: Review u Unnormalized – There are multivalued attributes or repeating groups u 1 NF – No multivalued attributes or repeating groups. u 2 NF – 1 NF plus no partial dependencies u 3 NF – 2 NF plus no transitive dependencies

6 5 Example 1: Determine NF u ISBN  Title u ISBN  Publisher u Publisher  Address All attributes are directly or indirectly determined by the primary key; therefore, the relation is at least in 1 NF

7 5 Example 1: Determine NF u ISBN  Title u ISBN  Publisher u Publisher  Address The relation is at least in 1NF. There is no COMPOSITE primary key, therefore there can’t be partial dependencies. Therefore, the relation is at least in 2NF

8 5 Example 1: Determine NF u ISBN  Title u ISBN  Publisher u Publisher  Address Publisher is a non-key attribute, and it determines Address, another non-key attribute. Therefore, there is a transitive dependency, which means that the relation is NOT in 3 NF.

9 5 Example 1: Determine NF u ISBN  Title u ISBN  Publisher u Publisher  Address We know that the relation is at least in 2NF, and it is not in 3 NF. Therefore, we conclude that the relation is in 2NF.

10 5 Example 1: Determine NF u ISBN  Title u ISBN  Publisher u Publisher  Address In your solution you will write the following justification: 1)No M/V attributes, therefore at least 1NF 2)No partial dependencies, therefore at least 2NF 3)There is a transitive dependency (Publisher  Address), therefore, not 3NF Conclusion: The relation is in 2NF

11 5 u Product_ID  Description Example 2: Determine NF All attributes are directly or indirectly determined by the primary key; therefore, the relation is at least in 1 NF

12 5 u Product_ID  Description Example 2: Determine NF The relation is at least in 1NF. There is a COMPOSITE Primary Key (PK) (Order_No, Product_ID), therefore there can be partial dependencies. Product_ID, which is a part of PK, determines Description; hence, there is a partial dependency. Therefore, the relation is not 2NF. No sense to check for transitive dependencies!

13 5 u Product_ID  Description Example 2: Determine NF We know that the relation is at least in 1NF, and it is not in 2 NF. Therefore, we conclude that the relation is in 1 NF.

14 5 u Product_ID  Description Example 2: Determine NF In your solution you will write the following justification: 1) No M/V attributes, therefore at least 1NF 2) There is a partial dependency (Product_ID  Description), therefore not in 2NF Conclusion: The relation is in 1NF

15 5 Example 3: Determine NF u Part_ID  Description u Part_ID  Price u Part_ID, Comp_ID  No Comp_ID and No are not determined by the primary key; therefore, the relation is NOT in 1 NF. No sense in looking at partial or transitive dependencies.

16 5 Example 3: Determine NF u Part_ID  Description u Part_ID  Price u Part_ID, Comp_ID  No In your solution you will write the following justification: 1)There are M/V attributes; therefore, not 1NF Conclusion: The relation is not normalized.

17 5 Bringing a Relation to 1NF

18 5 Bringing a Relation to 1NF u Option 1: Make a determinant of the repeating group (or the multivalued attribute) a part of the primary key. Composite Primary Key

19 5 Bringing a Relation to 1NF u Option 2: Remove the entire repeating group from the relation. Create another relation which would contain all the attributes of the repeating group, plus the primary key from the first relation. In this new relation, the primary key from the original relation and the determinant of the repeating group will comprise a primary key.

20 5 Bringing a Relation to 1NF

21 5 Bringing a Relation to 2NF Composite Primary Key

22 5 Bringing a Relation to 2NF Composite Primary Key u Goal: Remove Partial Dependencies Partial Dependencies

23 5 Bringing a Relation to 2NF u Remove attributes that are dependent from the part but not the whole of the primary key from the original relation. For each partial dependency, create a new relation, with the corresponding part of the primary key from the original as the primary key.

24 5 Bringing a Relation to 2NF

25 5 Bringing a Relation to 3NF u Goal: Get rid of transitive dependencies. Transitive Dependency

26 5 Bringing a Relation to 3NF u Remove the attributes, which are dependent on a non-key attribute, from the original relation. For each transitive dependency, create a new relation with the non-key attribute which is a determinant in the transitive dependency as a primary key, and the dependent non-key attribute as a dependent.

27 5 Bringing a Relation to 3NF