Margaret S. W% 425 Beldon Ave Iowa City, Iowa 52246 Phone: (319) 335-0846 ABSTRACT



Similar documents
Normalization in OODB Design

Chapter 15 Basics of Functional Dependencies and Normalization for Relational Databases

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

Database Design and Normalization

COMPUTING PRACTICES ASlMPLE GUIDE TO FIVE NORMAL FORMS IN RELATIONAL DATABASE THEORY

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

Fundamentals of Database System

DATABASE SYSTEMS. Chapter 7 Normalisation

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

Database Management System

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

Functional Dependency and Normalization for Relational Databases

Theory of Relational Database Design and Normalization

Database Design and Normal Forms

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

Database Design and the Reality of Normalisation

DATABASE NORMALIZATION

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

MCQs~Databases~Relational Model and Normalization

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

Relational Database Design: FD s & BCNF

CS143 Notes: Normalization Theory

Design of Relational Database Schemas

Theory of Relational Database Design and Normalization

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

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

Lecture 2 Normalization

Chapter 5: FUNCTIONAL DEPENDENCIES AND NORMALIZATION FOR RELATIONAL DATABASES

Advanced Relational Database Design

Introduction to normalization. Introduction to normalization

Functional Dependencies and Finding a Minimal Cover

Normalisation 6 TABLE OF CONTENTS LEARNING OUTCOMES

Chapter 10. Functional Dependencies and Normalization for Relational Databases

Normalization of Database

An Algorithmic Approach to Database Normalization

Chapter 7: Relational Database Design

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

Chapter 10 Functional Dependencies and Normalization for Relational Databases

Introduction to Database Systems. Normalization

Relational Database Design Theory

Topic 5.1: Database Tables and Normalization

RELATIONAL DATABASE DESIGN

IT2304: Database Systems 1 (DBS 1)

Normalisation to 3NF. Database Systems Lecture 11 Natasha Alechina

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

Schema Refinement, Functional Dependencies, Normalization

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

Chapter 7: Relational Database Design

IT2305 Database Systems I (Compulsory)

Normal forms and normalization

Normalization in Database Design

Carnegie Mellon Univ. Dept. of Computer Science Database Applications. Overview - detailed. Goal. Faloutsos CMU SCS

Boyce-Codd Normal Form

How To Write A Diagram

Schema Design and Normal Forms Sid Name Level Rating Wage Hours

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

Why Is This Important? Schema Refinement and Normal Forms. The Evils of Redundancy. Functional Dependencies (FDs) Example (Contd.)

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

Module 5: Normalization of database tables

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

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

Relational Database Design

Database Management Systems. Redundancy and Other Problems. Redundancy

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

Normalization of database model. Pazmany Peter Catholic University 2005 Zoltan Fodroczi

Database Constraints and Design

Schema Refinement and Normalization

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

Database Systems Concepts, Languages and Architectures

Xml Normalization and Reducing RedUndies

Functional Dependencies and Normalization

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

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

Functional Dependencies

REPRESENTING MULTIVALUED ATTRIBUTES IN DATABASE DESIGN

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

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

KNOWLEDGE FACTORING USING NORMALIZATION THEORY

Analysis and Design Complex and Large Data Base using MySQL Workbench

Normalization. Normalization. Normalization. Data Redundancy

Chapter 9: Normalization

Review of Business Information Systems First Quarter 2011 Volume 15, Number 1

Part 6. Normalization

Fundamental Concepts of Relational Theory Technical Brief

A Simple Guide to Five Normal Forms in Relational Database Theory

SQL Server. 1. What is RDBMS?

Chapter 5 More SQL: Complex Queries, Triggers, Views, and Schema Modification

DATABASE MANAGEMENT SYSTEMS. Question Bank:

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

BCA. Database Management System

City University of Hong Kong. Information on a Course offered by Department of Computer Science with effect from Semester A in 2014 / 2015


1.264 Lecture 10. Data normalization

Design of Normalized Relation: An Ameliorated Tool

Chapter 13. Chapter Outline. Disk Storage, Basic File Structures, and Hashing

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.

56:231 Computer Integrated Manufacturing What is CIM? (Fall 2002)

Chapter 8. Database Design II: Relational Normalization Theory

DBMS. Normalization. Module Title?

Transcription:

The Practical Need for Fourth Normal Form Margaret S. W% 425 Beldon Ave Iowa City, Iowa 52246 Phone: (319) 335-0846 ABSTRACT Many practitioners and academicians believe that data violating fourth normal form is rarely encountered. We report upon a study of forty organizational database$ nine of them contained data violating fourth normal form. Consequently, the need to understand and use fourth normal form is more important than previously believed. INTRODUCTION A paramount issue in the design of any database is what data fields should be grouped together into records. In the relational model, the data fields are grouped into logical structures called relations. The determination of which data fields are placed together in a relation is based upon the concept of normal forms; the process is known as normalization. The set of data fields comprising the database is progressively organized into relations in first through fdth normal form (5NF) according to constraints placed upon the relations in each normal form. At any step in the normalization process, we may find that the relations no longer require further reorganization, in that case, we say that final normal form has been achieved. Frequently, a set of data may be in final normal form when it has been normalized only to third normal form (3NF). Because the definition of 3NF does not treat certain instances of data adequately, an additional normal form called Boyce-Codd normal form (BCNF) was created to replace 3NF. In theory, BCNF is placed after 3NF in the normalization process. There is an addkional normal form called Domain Key normal form which is not applied to normalize data but serves to verify that a relation has been normalized to its final form by showing Permission to copy without fee all or part of this material is grantad provided that tha copies are not made or distributed for direct commercial advantage, the ACM copyright notica and the title of the publication and its date appear, and notica is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. e 1992 ACM 0-89791-468-6192100021001 9..,$1.50 that the relation has no modification anomalies. There is some evidence that academicians view fourth normal form (4NF) as unimportant and thus may neglect the topic in database management courses in M [S. Stamper and Price in [10] state that fourth and fifth normal forms are so rarely encountered in business applications as to be almost obscure; hence, they are not described in thk book. Mittra [8] states that Although BCNF and 4NF may be less rare than 5NF, they are still highly theoretical in nature. Other database texts [1,6,9] either ignore or do not fully explain 4NF. The view of practitioners regarding 4NF is represented by Edwards in [3] where he states that 4NF is merely an academic issue. Thus, the practical use of normalization theory apparently stops with 3NF or BCNF for some academicians and practitioners. Because the normal forms were defined in order to prevent data inconsistencies and update anomalies, the termination of the normalization process with the database violating 4NF will result in recc~rd designs that are ineffective in meeting these objectives. The purpose of this paper is to present the results of an empirical study which investigated the practical need for 4NF by the examination of real world databases. In the next section, we state the normalization procedures for 4NF and discuss the advantages of 4NF. The second section details the research methodology of this study. In the third section, we present the results of the empirical research. Additional insights into the organization of data gained during this investigation are presented in the fourth section. Finally, a summary of these results is given in the last section. 19

NORMALIZATION OF DATA To normalize a set of data items, we may proceed from frost normal form (lnf) to second normal form (2NF) to third normal form (3NF) to Boyce-Codd normal form (BCNF) to fourth normal form (4NF). In practice, we can proceed directly from lnf to BCNF. The use of BCNF rather than 3NF is preferred because normalization to BCNF is easily understood by students and can be quickly implemented, in addition, a relation in BCNF is dso in 3NF. To normalize a record type to lnf, any repeating fields or groups of fields are repeated for each record. The only attribute values permitted by lnf are single atomic values. A relation schema R is in Boyce-Codd normal form if whenever a functional dependericy X -> A holds in R, then there do not exist two tuples tl and t in R such that tl[x] = t2[x]. X is called a superkey o3 R. To define fourth normal form, the concept of multivalued dedendencv (MVD) is required. An MVD X ->-> Y holds for R(X,Y,Z) if and only if whenever (FY,Z) ad LY,z ) are tuples of R, then so are (Ly,z) and (XJ,Z ). An MVD X ->-> Y is said to be. trivial ify is a subset of X or XUY = R. follows: The deffition of 4NF is then given by Fagin [51 as A relation schema R* is in 4NF if, w~enever a nontrivial MVD X ->-> Y holds for R, then so does the functional. dependency X -> A for every column name of R. If X ->-> Y, we also say that Y is a mukivalued fact about X. It is possible for Y to be called a multivalued fact about X and yet the relationship between X and Y is not a mukivalued dependency. When a multivalued fact is not independent, i.e., a mukivalued dependency does not exist, redundancy of data values is necessary. To obtain 4NF, the relation R is decomposed into two or more relations which meets the constraints given by the deftition of 4NF. For the purpose of normrdizing real world data, we may restate the deftition of 4NF as follows: A relation R is in fourth normal form if R is in BCNF and does not contain any nontrivial multivalued dependencies. We note that this simpler statement does not conform fidly to the original deftition given by Fagin [4]. However, the theoretical differences do not affect the normalization of real world databases. Table 1 The nine databases with data violating 4NF Functional Total * Record Orszanization Area Fields Z!I&S Financial Firm Sales Management System 307 24 Physician Database Data on Individual Physician 68 6 Publishing Firm Job Scheduling 63 9 ColIege of Nursing Student Skills Database 55 8 Apartment Complex Maintenance Tracking 47 17 Division of Sponsored Grants Database 42 7 Research Animal Laboratory Inventory of Animals 33 5 Athletic Tutoring Program Assignment of Tutors 18 7 Automotive Parts Retailer Inventory 16 4 20

RESEARCH METHODS The databases from forty organizations were studied for this project. Each organization was a small firm, a division of a large fum, or a division of a major university. The database for each organization was limited to the data required for the functional area of the organization with the exception of one business firm which was studied in its entirety. Eighteen organizations were functional units within a large university, twenty were private firms, and the remaining two were government organizations. The study included the entire database for a reprographics firm, the manufacturing database for a Fortune 500 firm, and the sales management system for a major financial firm. These three large databases were examined for data that violated 4NF. The remainder of the organizations were studied by student teams for undergraduate classes in the Systems Analysis and Design course. Each team was required to present the data as a set of record types in 3NF. These reports were then carefully reviewed and revised by the author as necessary to obtain record types in 4NF. Additional contact with the organizations was made to resolve any ambiguities in the data and the relationships between the data. RESULTS OF THE STUDY This study has determined that data violating 4NF occurred at least once in nine organizational databases constituting over twenty percent of the databases in this study. Twenty of the 350 record types comprising the forty databases resulted from normalization of BCNF relations to 4NF. These record types represent six percent of the normalized record types in this study. Because of this incidence, 4NF is not so rare. Table 1 provides information regarding the data found in the organizational databases which contained data violating 4NF. The number of data fields for each organizational database has been tabulated. The number of normalized record types for each organization is also given. The tabulation of the number of data fields found at each organization yields a general picture of the magnitude of these databases. Both large and small databases were included in the study. The database represented by the 307 data fields required for the sales management system of a major financial firm was found to violate 4NF. The other eight databases contain an average of over 40 data fields. AVOIDANCE OF FOURTH NORMAL FORM It is sometimes possible to avoid the use of fourth normal form by representing the data differently. As an example of this approach, let us consider the database of the Financial Organization. This database in BCNF contains the following relation violating fourth normal form: Codes (ACCOUNT ID, HOME PENDING CODE, FIELD PENDING CODE) To obtain 4NF, thk relation is decomposed to form two relations: Home-Codes (ACCOUNT ID, HOME PENDI~U CODE) Pending-Reqts (ACCOUNT ID, FIELD PENDI~U REQUIREMENT) It is possible to represent the attributes of HOME PENDING CODE and FIELD PENDING REQUIREMENT so that the data does not violate 4NF. The value of these fields is given by a numeric value that indicates a particular item of information has not been received by the organization. For example, if the value of 01 is present for HOME PENDING CODE for a particular value of ACCOUNT ID, we know that the document identified as 01 has not been received. To represent this information without violating fourth normal form, we will require that all values for HOME PENDING CODE be given and an additional field called HOME-PENDING-CODE-Y-N be included. This latter field will contain either a Y or N value to indiciite whether a particular document identified by its corresponding value in the HOME PENDING COI)E field has been received or not. Similarly, we add the field P-REQTS-Y-N to contain a Y or N value corresponding to a particular value of FIELD PENDING REQUIREMENT. We then have two relations as shown below Home-Code-YN (ACCOUNT ID, HOME PENDING CODE, HOME-PENDING- CODE-Y-N) Pending-Reqts-YN (ACCOUNT ID, FIELD PENDING REQUIREMENT, P-REQTS- Y-N) These two relations do not violate fourth normal form and require no further normalization. Another representation for this data is possible by the use of buckets. In actuality, the HOME PENDING CODE field has only 19 possible codes while the FIELD PENDING REQUIREMENT field has only five possible codes. 21

Table 2 The Violations of Fourth Normal Form In this research study, nine databases were found to contain data violating fourth normal form. The relevant data for these nine organizations is shown below in relations normalized to 4NF. 1. Financial Organization - Sales Management System Home-ties (ACCOUNT ID, HOME PENDING CODE) Pending-Reqts (ACCOUNT ID, FIELD PENDING REQ UIREMEMP) 2. Physician Identification System Is-Member (PHYSICIAN ID, GROUP ID) Works-At (PHYSICIAN ID, LOCATION ID) 3. Publishing Firm - Scheduling System Associated-Job (JOB NUMBER ASSOCIATED JOB NUMBER) Colors (JOB NUMBERj COLOR REQUIRED) 4. College of Nursing - Student Skills Database Has-Prerequisite (SKILL CODE, PREREQUIWI E SKILL CODE) Course (COURSE, SKILL CODE) 5. Family Housing Office - Maintenance Tracking System Adjoining-Apt (AIT CODE, ADJOINfNG APT CODE) Maintenance (APT CODE, MAINTENANCE CODE, MAINTENANCE DATE) Spraying (APT CODE, SPRAY DATE, AREA SPRAYED) 6. Division of Sponsored Research - Grants Database Grant-Area (GRANT CODE, DISCIPLINE) Grant-Keyword (GRANT CODE, KEYWORD) Faculty-Interests (UNfVERSITY ID, KEYWORD) 7. Animal Laboratory - Inventory of Animals Account-Investigators (ACCOUNT NUMBER INVESTIGATOR NUMBER) Account-Animals (ACCOUNT NUMBER ANIMAL ID) 8. Athletic Tutoring System - Tutor Assignment Note: The Athletic Tutoring Service did not wish to classify individual courses by subject area(s) but did wish to track both courses and subject areas for which a student was deemed qualified to sewe as a tutor. Tutor-Subjects (TUT OR ID, SUBJECI_ AREA) Tutor-Courses (TUT OR ID, COURSE ld) 9. Automotive Parts Retailer - Inventory Vehicle-Engine-Part (W3 HICLE, MODEL. YEAR ENGINE TYPE, ENGINE FEATURE, ENGINE-PART-NUMBER) Vehicle-Feature (VEHICLE, MODEL, YEAR FEATURE, ~ Note: The field FEATURE consists of several subfields. 22

Consequently, we may choose to store thk same information in one relation as shown below All-Codes (ACCOUNT ID, HOME-PENDING- CODE-1,... HOME-PENDING-CODE-19, FIELD-PENDING-REQUIREMENT-1,... FIELD-PENDING-REQUIREMENT-5) Although the relation All-Codes is technically in 4NF, the use of the bucket violates the principles of the relational model. The organization may choose the bucket representation because these data fields have been in use for several years and it is unlikely that change would occur. The bucket representation presents potential problems due to its inflexibility. We note that the proper choice for data representation is dependent on the individual installation s preference for data representation, the requirements for flexibility, the need to minimize storage space, and the trade-off of data structure for ease of programming. 5. Fagin, Ronald. Multivalued Dependencies and a New Normal Form for Relational Databases+ ACM Transactions on Database Svstems, ~, 3, (Sept. 1977), 262-278. 6. Fife, Dennis, W. Terry Hardgrave, and Donald R. Deuth. Database Concepts. Cincinnati Southwestern Publishing Co., 1986. 7. Kent, W. A Simple Guide to Five Normal Forms in Relational Data base Theory, Communications of the ACM, 26, 2, (Feb. 1983), 120-125. 8. Mittra, Sitansu S. PrincirJes of Relational Database Svstems. Englewood Cliffs, N. Y.: Prentice-Hall, Inc., 1991. 9. Pratt, Philip J. Microcomputer Data Base Mana~ement Usimz dbase III Plus. Boston, MA Boyd & Fraser Publishing Co., 1988. 10. Stamper, David and Wilson Price. Database Desire and Mana~ement: An A~plied Ap~roach. New York McGraw-Hill, Inc., 1990. CONCLUSION The study of forty real world databases showed that 4NF occurs more often than we previously believed. Data violating 5NF did not occur in any of the databases which may indicate that 5NF is only an academic issue, Because data violating 4NF was found to occur in over twenty percent of the organizations in the study, it is advisable that practitioners understand and apply the constraints for 4NF. It is also imperative that the rules for 4NF be emphasized in the teaching of normalization theory. ACKNOWLEDGEMENT The author wishes to thank Jeff Hoffer for su~esting this research project. REFERENCES 1. Courtney, James F. and David B. Paradice. Database Svstems for Management. St. Louis: Times Mh-ror/Mosby College Publishing Co., 1988. 2. Date, C. J. An Introduction to Data Base m. 5th ed. Reading, MA: Addison-Wesley Publishing Co., 1990. 3. Edwards, Joe B. High Performance Without Compromise} Datamation, ~, 13, (July 1, 1990), 53-58. 4. Elmasri, Ramez and Shamkant B. Navathe. Fundamentals of Database Svstems. Redwood City, CA: Benjamin/Cummings Publishing Co. 1989. 23