DATABASE DESIGN: Normalization Exercises & Answers



Similar documents
DATABASE NORMALIZATION

DBMS. Normalization. Module Title?

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

Normalization in Database Design

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

Chapter 15 Basics of Functional Dependencies and Normalization for Relational Databases

Normalisation to 3NF. Database Systems Lecture 11 Natasha Alechina

Normalization. Normalization. Normalization. Data Redundancy

Fundamentals of Database System

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

DATABASE SYSTEMS. Chapter 7 Normalisation

Functional Dependency and Normalization for Relational Databases

Lecture 2 Normalization

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

Database Management System

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.

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

Normalization of Database

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

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

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

Introduction to normalization. Introduction to normalization

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


Normalisation 1. Chapter 4.1 V4.0. Napier University

Theory of Relational Database Design and Normalization

Chapter 9: Normalization

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

Chapter 10. Functional Dependencies and Normalization for Relational Databases

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

C HAPTER 4 INTRODUCTION. Relational Databases FILE VS. DATABASES FILE VS. DATABASES

Topic 5.1: Database Tables and Normalization

Database Design and Normalization

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

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

Normalization. CIS 331: Introduction to Database Systems

RELATIONAL DATABASE DESIGN

Normalization in OODB Design

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

MCQs~Databases~Relational Model and Normalization

Benefits of Normalisation in a Data Base - Part 1

Normal forms and normalization

CSCI-GA Database Systems Lecture 7: Schema Refinement and Normalization

Normalization. Normalization. First goal: to eliminate redundant data. for example, don t storing the same data in more than one table

Higher National Unit specification: general information. Relational Database Management Systems

Normalisation 6 TABLE OF CONTENTS LEARNING OUTCOMES

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

Schema Refinement, Functional Dependencies, Normalization

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

Notes. Information Systems. Higher Still. Higher. HSN31010 Database Systems First Normal Form. Contents

Relational Database Design Theory

Functional Dependencies and Finding a Minimal Cover

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

Theory of Relational Database Design and Normalization

Jordan University of Science & Technology Computer Science Department CS 728: Advanced Database Systems Midterm Exam First 2009/2010

Chapter 10 Functional Dependencies and Normalization for Relational Databases

Part 6. Normalization

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

BCA. Database Management System

An Algorithmic Approach to Database Normalization

Chapter 5: FUNCTIONAL DEPENDENCIES AND NORMALIZATION FOR RELATIONAL DATABASES

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

The class slides, your notes, and the sample problem that we worked in class may be helpful for reference.

RELATIONAL DATABASE DESIGN. Basic Concepts

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

Optimum Database Design: Using Normal Forms and Ensuring Data Integrity. by Patrick Crever, Relational Database Programmer, Synergex

Relational Data Analysis I

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

LOGICAL DATABASE DESIGN

DATABASE MANAGEMENT SYSTEMS

Module 5: Normalization of database tables

Database Design and Normal Forms

CS143 Notes: Normalization Theory

Access Tutorial 2 Building a Database and Defining Table Relationships

Teaching Database Modeling and Design: Areas of Confusion and Helpful Hints

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

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

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

Figure Sample 3GL COBOL Program

Database Design Basics

Database Design and Normalization

Tutorial on Relational Database Design

Normalization. Reduces the liklihood of anomolies

normalisation Goals: Suppose we have a db scheme: is it good? define precise notions of the qualities of a relational database scheme

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

SQL, PL/SQL FALL Semester 2013

How To Find Out What A Key Is In A Database Engine

Functional Dependencies and Normalization

Normalization for Relational DBs

1) After login WinTonenet Securities Trading System, a window named WinTonenet Securities Trading will be shown.

Lecture Notes on Database Normalization

Developing Entity Relationship Diagrams (ERDs)

IT2305 Database Systems I (Compulsory)

Normalization NORMALIZATION. Primary keys (contd.) Primary keys

SQL DATA DEFINITION: KEY CONSTRAINTS. CS121: Introduction to Relational Database Systems Fall 2015 Lecture 7

z Introduction to Relational Databases for Clinical Research Michael A. Kohn, MD, MPP copyright 2007Michael A.

Database Design and the Reality of Normalisation

Transcription:

DATABASE DESIGN: Normalization Exercises & Answers (a) The table shown in Figure 1 is susceptible to update anomalies. Provide examples of insertion, deletion, and modification anomalies. Answers: This table is not well structured, un-normalized containing redundant data. By using a bottom-up approach we analyzing the given table for anomalies. First observation, we see multiple values in an appointment column and this of course violate the 1NF. By assuming the staffno and patientno as candidate keys, there are many anomalies exist. Insertion anomalies: To insert a new patient particular that makes an appointment with the designated Doctor, we need to enter the correct detail for the staff. For example, to insert the details of new patient in patientno, patientname and an appointment, we must enter the correct details of the doctor (staffno, dentistname) so that the patient details are consistent with values for the designated Doctor for example, S1011. To enter new patient data that doesn t have Doctor to be assigned we can t insert NULL values for the primary key. Deletion anomalies: If we want to delete a patient named Ian MacKay for example, two records need to be deleted as in row 3 and 4. This anomaly also obvious when we want to delete the dentistname, multiple records needs to be deleted to maintain the data integrity. When we delete a Dentist record, for example Tony Smith, the details about his patients also lost from the database.

Modification anomalies: With redundant data, when we want to change the value of one columns of a particular Dentist, for example the dentistname, we must update all the Dentist records that assigned to the particular patient otherwise the database will become inconsistent. We also need to modify the appointment schedules because different Dentist has different schedules. (b) Describe and illustrate the process of normalizing the table shown in Figure 1 to 3NF. State any assumptions you make about the data shown in this table. Assumptions made include that a patient is registered at only one surgery and he/she may have more than one appointment on a given day. All the schedules have been fixed for the whole days and week. In the 1NF we remove all the repeating groups (appointment), assigning new column (apptdate and appttime) and assigned primary keys (candidate keys). Then we figure out the functional dependencies (FDs). By using dependency diagram we represent the table as shown below. (NF stand for Normal Form) Note: How to find the FDs is subjective!!! However, the rule is, it must reflect the real word situation. FD1 staffno apptdate appttime dentistname patientno patientname surgeryno FD2 FD3 FD4 FD5 FD1 is already in 2NF. In this case, we can see that FD2 (just depend on staffno) and FD4 (just depend on staffno and apptdate) violate the 2NF. These two NFs are partially dependent on the candidate keys not the whole keys. FD2 can stand on its own by depending on the staffno and meanwhile FD4 also can stand on its own by depending on the staffno. The FD3 violates the 3NF showing the transitive dependency where surgeryno and patientname depend on patientno while patientno depend on the staffno that is the non-key is depending on another non-key.

The 2NF, it is already in 1NF and there is no partial dependency. So we need to remove the FD2 and FD4 by splitting into new tables and at the same time creating foreign keys. The new tables that are in 2NF are shown below. staffno apptdate appttime patientno patientname staffno apptdate surgeryno staffno dentistname Finally in 3NF we must remove the transitive dependency. In this case we remove the FD3 by splitting into a new table. The transitive dependency left is the patientname that depend on the patientno, so we split this into new table while creating a foreign key. staffno apptdate appttime patientno staffno apptdate surgeryno staffno dentistname patientno patientname Let re-arrange and giving names to the tables.

staffno dentistname Dentist(staffNo, dentistname) staffno apptdate surgeryno Surgery(staffNo, apptdate, surgeryno) patientno patientname Patient(patientNo, patientname) staffno apptdate appttime patientno Appointment(staffNo, apptdate, appttime, patientno)

An agency called InstantCover supplies part-time/temporary staff to hotels throughout Scotland. The table shown in Figure 2 lists the time spent by agency staff working at two hotels. The National Insurance Number (NIN) is unique for employee. (1) The table shown in Figure 2 is susceptible to update anomalies. Provide examples of insertion, deletion, and modification anomalies. Answers: It is obvious that the NIN and contractno can be candidate keys. There are data redundancies in term of repeating groups. Insertion anomalies: To insert the details of new hotel we must know the NIN of the staff because this is primary key and we cannot assign NULL value for primary key. For example if we want to insert the details of new hotel, we must also insert the NIN and contractno. To recruit a new staff we need to know the details of hotel. For example if we want to recruit and assign new staff at H4 we need to enter the correct details of H4 so that the hotel details are consistent with values for hotel H4. Deletion anomalies: If we delete a record from the table that represent the staff name for example, John Smith, the details about the contract also will be lost from the database and will affect other record as seen in the second row of the contractno (C1024). Oppositely, when we delete a contractno, other staff details will also be lost. For example if we delete C1025, both Sarah White and John Smith details will be lost. Modification anomalies: If we change the value of the contractno, several records need to changed, for example row 1 and 2, also row 3 and 4 if we edit either contractno. If we edit the staff details, for example updating John Smith, several records need to be updated. This also applies to the hotelno column.

(2) Describe and illustrate the process of normalizing the table shown in Figure 2 to 3NF. State any assumptions you make about the data shown in this table. In the 1NF we remove all the repeating groups if any and assigned primary keys (candidate keys). Then we figure out the functional dependencies (FDs). By using dependency diagram we represent the table as shown below. (NF stand for Normal Form) FD1 FD4 NIN contractno hours ename hotelno hotellocation FD2 FD3 Obviously FD2 and FD3 violate the 2NF (partial dependency) and FD4 violate 3NF (transitive dependency). In the 2NF we remove the partial dependency of the FD2 and FD3 by splitting it into new tables as shown below. NIN contractno hours NIN ename contractno hotelno hotellocation

In 3NF we remove the transitive dependency of the FD4 by splitting it into new table as shown below. NIN contractno hours NIN ename contractno hotelno hotelno hotellocation Finally, let re-arrange the table and assign names. NIN ename Staff(NIN, ename) hotelno hotellocation Hotel(hotelNo, hotellocation) contractno hotelno Contract(contractNo, hotelno)

NIN contractno hours WorkHours(NIN, contractno, hours)