Normalization NORMALIZATION. Primary keys (contd.) Primary keys



Similar documents
RELATIONAL DATABASE DESIGN Good Database Design Principles

RELATIONAL DATABASE DESIGN. Basic Concepts

Normalization of Database

C# Cname Ccity.. P1# Date1 Qnt1 P2# Date2 P9# Date9 1 Codd London Martin Paris Deen London

DATABASE NORMALIZATION

Part 6. Normalization

MCQs~Databases~Relational Model and Normalization

Normalization. CIS 3730 Designing and Managing Data. J.G. Zheng Fall 2010

Database Normalization. Mohua Sarkar, Ph.D Software Engineer California Pacific Medical Center

Functional Dependency and Normalization for Relational Databases

CS 377 Database Systems. Database Design Theory and Normalization. Li Xiong Department of Mathematics and Computer Science Emory University

DATABASE SYSTEMS. Chapter 7 Normalisation

If it's in the 2nd NF and there are no non-key fields that depend on attributes in the table other than the Primary Key.

Chapter 6. Database Tables & Normalization. The Need for Normalization. Database Tables & Normalization

Normalization. Reduces the liklihood of anomolies

Normalisation to 3NF. Database Systems Lecture 11 Natasha Alechina

Fundamentals of Database System

Module 5: Normalization of database tables

Chapter 15 Basics of Functional Dependencies and Normalization for Relational Databases

DATABASE DESIGN: NORMALIZATION NOTE & EXERCISES (Up to 3NF)

Chapter 5: Logical Database Design and the Relational Model Part 2: Normalization. Introduction to Normalization. Normal Forms.

Lecture 2 Normalization

RELATIONAL DATABASE DESIGN

Normalization. Functional Dependence. Normalization. Normalization. GIS Applications. Spring 2011

Introduction to normalization. Introduction to normalization

Topic 5.1: Database Tables and Normalization

LOGICAL DATABASE DESIGN

Normalisation 6 TABLE OF CONTENTS LEARNING OUTCOMES

Schema Refinement, Functional Dependencies, Normalization

Normalization in Database Design

Databases -Normalization III. (N Spadaccini 2010 and W Liu 2012) Databases - Normalization III 1 / 31

Introduction to Computing. Lectured by: Dr. Pham Tran Vu

Database Concepts II. Top down V Bottom up database design. database design (Cont) 3/22/2010. Chapter 4

Database Systems Concepts, Languages and Architectures

Chapter 9: Normalization

14 Databases. Source: Foundations of Computer Science Cengage Learning. Objectives After studying this chapter, the student should be able to:

Normalization. Normalization. Normalization. Data Redundancy

COSC344 Database Theory and Applications. Lecture 9 Normalisation. COSC344 Lecture 9 1

DBMS. Normalization. Module Title?

Functional Dependencies and Finding a Minimal Cover

BCA. Database Management System

Week 11: Normal Forms. Logical Database Design. Normal Forms and Normalization. Examples of Redundancy

CS143 Notes: Normalization Theory

Physical Database Design and Tuning

Database Management System

A. TRUE-FALSE: GROUP 2 PRACTICE EXAMPLES FOR THE REVIEW QUIZ:

Bridge from Entity Relationship modeling to creating SQL databases, tables, & relations

Unit 3.1. Normalisation 1 - V Normalisation 1. Dr Gordon Russell, Napier University

1. Physical Database Design in Relational Databases (1)

Database Design and Normalization

Databases Model the Real World. The Entity- Relationship Model. Conceptual Design. Steps in Database Design. ER Model Basics. ER Model Basics (Contd.

7.1 The Information system

Normalization. CIS 331: Introduction to Database Systems

2. Basic Relational Data Model

Normalisation 1. Chapter 4.1 V4.0. Napier University

Database Design and the Reality of Normalisation

Announcements. SQL is hot! Facebook. Goal. Database Design Process. IT420: Database Management and Organization. Normalization (Chapter 3)

- Eliminating redundant data - Ensuring data dependencies makes sense. ie:- data is stored logically

Designing Databases. Introduction

Chapter 2: Entity-Relationship Model. Entity Sets. " Example: specific person, company, event, plant

Relational Database Design

6.830 Lecture PS1 Due Next Time (Tuesday!) Lab 1 Out today start early! Relational Model Continued, and Schema Design and Normalization

DATABASE DESIGN: Normalization Exercises & Answers

Database Fundamentals: 1

Limitations of E-R Designs. Relational Normalization Theory. Redundancy and Other Problems. Redundancy. Anomalies. Example

KNOWLEDGE FACTORING USING NORMALIZATION THEORY

COMP 378 Database Systems Notes for Chapter 7 of Database System Concepts Database Design and the Entity-Relationship Model

Alabama Commission of Higher Education P. O. Box Montgomery, AL. Alabama

Introduction Decomposition Simple Synthesis Bernstein Synthesis and Beyond. 6. Normalization. Stéphane Bressan. January 28, 2015

Theory of Relational Database Design and Normalization

Introduction to Databases, Fall 2005 IT University of Copenhagen. Lecture 5: Normalization II; Database design case studies. September 26, 2005

Determination of the normalization level of database schemas through equivalence classes of attributes

Database Design. Marta Jakubowska-Sobczak IT/ADC based on slides prepared by Paula Figueiredo, IT/DB

Tutorial on Relational Database Design

Chapter 10. Functional Dependencies and Normalization for Relational Databases

Database Management Systems. Redundancy and Other Problems. Redundancy

State Insurance Information

DATABASE DESIGN. - Developing database and information systems is performed using a development lifecycle, which consists of a series of steps.

Chapter 5: FUNCTIONAL DEPENDENCIES AND NORMALIZATION FOR RELATIONAL DATABASES

Normalization. Purpose of normalization Data redundancy Update anomalies Functional dependency Process of normalization

STATE LIQUOR AUTHORITIES

MODULE 8 LOGICAL DATABASE DESIGN. Contents. 2. LEARNING UNIT 1 Entity-relationship(E-R) modelling of data elements of an application.

Normal forms and normalization

How To Write A Diagram

AZ State Board of Physical Therapy, 1400 W Washington, Suite 230, Phoenix, AZ 85007, Phone: Fax:

State Vocational Rehabilitation (VR) Agencies

Files. Files. Files. Files. Files. File Organisation. What s it all about? What s in a file?

Normalisation and Data Storage Devices

This chapter deals with the database approach to

The process of database development. Logical model: relational DBMS. Relation

State-by-State Listing of Departments of Insurance Updated August 2005

Chapter 7: Relational Database Design

Chapter 8. Database Design II: Relational Normalization Theory

Chapter 10. Functional Dependencies and Normalization for Relational Databases. Copyright 2007 Ramez Elmasri and Shamkant B.

SAMPLE FINAL EXAMINATION SPRING SESSION 2015

Grade 8 Mathematics Data Analysis, Probability, and Discrete Mathematics: Lesson 3

COMPLETE CAPITAL ONE CUP STANDINGS As of June 29, 2015

Transcription:

Normalization NORMALIZATION R L A Ellis Primary keys and foreign keys Functional dependencies Anomalies and their causes First, second, and third normal forms Examples: sitter database Hardware store database Video store database Primary keys A primary key is an attribute, or a collection of attributes, whose value(s) uniquely identify each row in a relation. A primary key must be minimal (that is, must not contain unnecessary attributes). Student Activity Fee 50 Swimming 50 We assume that a student is allowed to participate in at most one activity. The primary key in the above table is Student. Primary keys (contd.) What if we allow the students to participate in more than one activity? Student Activity Fee 00 Golf 65 75 Swimming 50 200 Golf 65 In this table, the two attributes {Student,Activity} constitute the primary key. A multi-attribute primary key is called a composite key.

Foreign keys A foreign key is an attribute, or a collection of attributes, in a relation, whose values match the values of a primary key in some relation. the STATE and CITY relations on the next slide. Primary key in STATE relation: StateAbbrev Primary key in CITY relation: {StateAbbrev,City} Foreign key in CITY relation: StateAbbrev STATE relation Foreign keys (contd.) State Abbrev State Union StateBird State Population CT Connecticut 5 American robin 3,287,6 MI Michigan 26 robin 9,295,297 SD South Dakota 40 pheasant 696,004 TN Tennessee 6 mocking bird 4,877,85 TX Texas 28 mocking bird 6,986,50 CITY relation: State Abbrev City City Population CT Hartford 39,739 CT Madison 4,03 CT Portland 8,48 MI Lansing 27,32 SD Madison 6,257 SD Pierre 2,906 TN Nashville 488,374 TX Austin 465,622 TX Portland 2,224 STATE = {StateAbbrev, State, Union, StateBird, StatePopulation} CITY = {StateAbbrev, City, CityPopulation} Functional dependencies Functional dependencies (contd.) A functional dependency is a relationship among attributes. Attribute B is functionally dependent on attribute A if, given a value of attribute A, the value of attribute B is uniquely defined. Attribute A is the determinant of attribute B if attribute B is functionally dependent on attribute A. In the STATE relation above, StateAbbrev is a determinant of all other attributes. A dependency diagram is a pictorial representation of all functional dependencies in a database. An attribute is represented by a rectangle. An arrow is drawn from the rectangle for attribute A to the rectangle for attribute B whenever attribute A is the determinant of attribute B. In the STATE relation, the attribute State is also a determinant of other attributes. In the CITY relation above, the attributes StateAbbrev and City together are a determinant of the attribute CityPopulation. 2

Functional dependencies (contd.) Students sports activity I consists of the relation ACTIVITY = {Student, Activity, Fee} Student Activity Fee Students sports activity II consists of the relation ACTIVITY = {Student, Activity, Fee} Partial Dependencies A partial dependency is a functional dependency in which the determinant is a part of the primary key. ACTIVITY = {Student, Activity, Fee} The dependency between the attributes Activity and Fee is a partial dependency. Student Activity Fee Student Activity Fee Transitive Dependency A transitive dependency is a functional dependency in which none of the attributes involves attributes of a primary key. ACTIVITY = {Student, Activity, Fee} The dependency between the attributes Activity and Fee is a transitive dependency. Student Activity Fee Anomalies Anomalies are problems caused by bad database design. Problems mean here: undesirable irregularities of relations (tables). Three types of anomalies: Insertion anomaly Deletion anomaly Update anomaly ACTIVITY = {Student, Activity, Fee} 3

Insertion anomaly Deletion Anomaly Student Activity Fee 00 Golf 65 75 Swimming 50 200 Golf 65 An insertion anomaly occurs when a row cannot be added to a relation, because not all data is available. We want to store the fact that scuba-diving costs $75, but cannot enter this fact into the table until a student takes up scuba-diving. Student Activity Fee 00 Golf 65 75 Swimming 50 200 Golf 65 A deletion anomaly occurs when data is deleted from a relation, and unintentionally other critical data are lost. By deleting the activity skiing for student 00, the fact that skiing costs $200 is lost. Update Anomaly Student Activity Fee 00 Golf 65 75 Swimming 50 200 Golf 65 An update anomaly occurs when the DBMS must make multiple changes to reflect a single attribute change. If the cost of swimming changes, then all entries where Activity=swimming must be changed. Redundant data Partial dependencies Causes of anomalies Student Activity Fee 00 Golf 65 75 Swimming 50 200 Golf 65 Student Activity Fee 4

Causes of anomalies (contd.) Transitive dependencies Removing anomalies Break a table into two tables to remove anomalies. Student Activity Fee 50 Swimming 50 Student Activity Fee Student Activity Activity Fee Student Activity Fee Observe that the above relations do not show any of the anomalies. We have not lost any information by breaking the table. Good database design principles Good database design principles (contd.) No redundancy: A field is stored in only one table, unless it happens to be a foreign key. Replication of foreign keys is permissible, because they allow two tables to be joined together. No partial dependencies: The dependency diagram of any relation in the database should contain no partial dependencies. Normalization: The process of eliminating partial and transitive dependencies. As we normalize relations, larger tables are split into smaller tables with a common foreign key field. There are six normal forms. No transitive dependencies: The dependency diagram of any relation in the database should contain no transitive dependencies. 5

Good database design principles (contd.) First Normal Form First Normal Form (NF) Second Normal Form (2NF) Third Normal Form (3NF) Boyce Codd Normal Form (BCNF) Fourth Normal Form (4NF) Fifth Normal Form (5NF) A relation is said to be in the first normal form (NF) if it does not contain any repeating section. CLIENT relation with repeating sections. Vet Vet Type 273 Barbara Hennesey 27 Vet 2 3 Sam Hoober Tom Bird Dog Hamster 459 Vernon Noordsy 3 Care 2 Charlie Cat 8005 Sandra Amidon 27 Vet 2 Beefer Kirby Dog Cat 82 Helen Wandzell 24 srus 3 Kirby Dog First Normal Form (contd.) The CLIENT relation without repeating sections Vet Vet Type 273 Barbara Hennessey 27 Vet Sam Bird 273 2 Barbara Hennessey 27 Vet Hoober Dog 273 3 Barbara Hennessey 27 Vet Tom Hamster 459 2 Vernon Noordsy 3 Care Charlie Cat 8005 Sandra Amidon 27 Vet Beefer Dog 8005 2 Sandra Amidon 27 Vet Kirby Cat 82 3 Helen Wandzell 24 srus Kirby Dog Second Normal Form A NF relation is said to be in the second normal form (2NF) if it does not contain any partial dependencies. Partial dependencies are eliminated by new relations. Partial dependencies in the relation CLIENT = {,,, Vet, Vet,, Type} partial Vet Vet Type transitive 6

Second Normal Form (contd.) To convert to second normal form, create new relations so that each attribute is functionally dependent upon the entire primary key. There are now no partial dependencies. The field is replicated, but it is a foreign key. The relation still has some anomalies. Vet transitive Type Vet Third normal form A 2NF relation is said to be in third normal form (3NF) if it does not contain any transitive dependencies. Transitive dependencies are eliminated by new relations. [In the third normal form, each determinant is a primary key] Conversion of CLIENT relation to 3NF. CLIENTS = {,, Vet} PETS = {,,, Type} VETS = {Vet, Vet} Third normal form (contd.) Third normal form (contd.) Vet Note that the tables can be joined to yield a table in the first normal form. The and Vet fields are replicated, but they are both foreign keys. Type Vet Vet CLIENT database in the third normal form. Vet 273 Barbara Hennessey 27 459 Vernon Noordsy 3 8005 Sandra Amidon 27 82 Helen Wandzell 24 Vet Vet 27 Vet 3 Care 24 srus Type 273 Sam Bird 273 2 Hoober Dog 273 3 Tom Hamster 459 2 Charlie Cat 8005 Beefer Dog 8005 2 Kirby Cat 82 3 Kirby Dog 7

Hardware Store Database The ORDERS relation Hardware Store Database (contd.) The ORDERS relation in the first normal form: Cust Cust Descr Quantity Numb Code Date Price 000 527 /22/94 Williams Hammer Screwdriver $8.99 $4.45 2 0002 502 /22/94 Johnson Clipper Screwdriver Crowbar Saw $8.22 $44.45 $.07 $4.99 3 0003 48 /22/94 Lorenzo Hammer $8.99 0004 6002 /22/94 Kopiusko Saw Screwdriver $4.99 $4.45 2 0005 502 /23/94 Johnson Cordless drill $34.95 Cust Cust Descr Quantity Numb Code Date Price 000 527 /22/94 Williams Hammer $8.99 2 000 527 /22/94 Williams Screwdriver $4.45 0002 502 /22/94 Johnson Clipper $8.22 0002 502 /22/94 Johnson Screwdriver $44.45 3 0002 502 /22/94 Johnson Crowbar $.07 0002 502 /22/94 Johnson Saw $4.99 0003 48 /22/94 Lorenzo Hammer $8.99 0004 6002 /22/94 Kopiusko Saw $4.99 0004 6002 /22/94 Kopiusko Screwdriver $4.45 2 0005 502 /23/94 Johnson Cordless drill $34.95 Hardware Store Database (cont.) Dependency diagram of the ORDERS relation in NF Hardware Store Database (contd.) Conversion of ORDERS relation to 3NF partial Numb Descr Quant Descr Price Numb Descr Cust Code Date Cust Price Quantity transitive partial Dependency diagram of the ORDERS relation in 2NF Quantity Numb Descr Descr Price Cust Cust Cust Numb Code Date Code Table relationships for the hardware store database Numb Cust Code Date Cust transitive 8

Video Store Database The CUSTOMER relation Customer Phone Last First Address City State Zip Code 502-666-7777 Johnson Martha 25 Main St. Alvaton KY 4222 2 502-888-6464 Smith Jack 873 Elm St. Bowling KY 420 Green 3 502-777-7575 Washington Elroy 95 Easy St. Smith s KY 427 Grove 4 502-333-9494 Adams Samuel 746 Brown Dr. Alvation KY 4222 5 502-474-4746 Steinmetz Susan 5 Speedway Dr.Portland TN 3748......... The RENTAL-FORM relation Trans Rent Customer Video Copy# Title Rent Date 4/8/95 3 2 200:SpaceOdyssey $.50 4/8/95 3 6 3 Clockway Orange $.50 2 4/8/95 7 8 Hpscotch $.50 2 4/8/95 7 2 Apocalypse Now $2.00 2 4/8/95 7 6 Clockwork Orange $.50 3 4/8/95 8 9 Luggage of the Gods $2.50....... Video Store Database (contd.) A customer can rent multiple videos as part of the same transaction however, the Video fields will be different for each video. Multiple copies of the same video are allowed the copy# field stores the number of the copy. Video rental charge depends on the title and not on the day. Video Store Database (contd.) Dependency diagram for the video store database. Video Store Database (contd.) Dependency diagram for the video store database in 3NF Customer Phone Address City State ZipCode Customer Phone Address City State ZipCode Trans Rent Date Customer Video Title Rent Trans Rent Date Customer Video Copy# Title Rent Trans Video Copy# Table relationships for the video store database 9

Boyce Codd Normal Form A relation is said to be in Boyce Codd Normal Form (BCNF) if each determinant is a primary key (or at least a candidate key). Guidelines for Database Design Create an Enhanced E-R diagram: Identify the entities involved in the database. Identify the attributes relevant for each entity and determine an identifier. Define relationships between entities. Ensure that all the required database processing can be done using the defined relations. Transform the E-R diagram to a relational schema. Normalize the relations by splitting them into smaller ones. Check for redundancy merge redundant relations. 0