1. Heading 1. Normalisation LEARNING OBJECTIVES. Study Guide. On completion of this session you will be able to:

Transcription

1 1. Heading 1 Normalisation Study Guide 6 LEARNING OBJECTIVES On completion of this session you will be able to: Understand the purpose of normalisation Understand the problems associated with redundant data Identify various types of update anomalies such as insertion, deletion, and modification anomalies Recognise the appropriateness or quality of the design of relations Identify various types of functional dependencies between attributes Understand how functional dependencies can be used to group attributes into relations that are in a known normal form Identify the most commonly used normal forms, namely 1NF, 2NF and 3NF Perform normalisation Understand various ways to refine 3NF relations to achieve better database design Produce an ER diagram from the derived set of 3NF relations

2 FIT1004 Database Reading Prescribed readings Rob P. & Coronel C. Database Systems: Design, Implementation & Management, Sixth Edition 2004, Thomson Course Technology. Chapter 5 Rob P. & Coronel C. Database Systems: Design, Implementation & Management, Seventh Edition 2007, Thomson Course Technology. Chapter 5 Further references Website: Rob & Coronel textbook Where we are Introduction to Database Systems The Relational Model Database Lifecycle Conceptual Design Logical Design Physical Design Normalisation Implementation SQL (DML) SQL (DDL & DCL) Transaction Management Database Administration Data Warehousing, Data Mining, ECommerce 57

3 Study Guide 6: Normalisation 1. Heading 1 1. Introduction Entity Relationship (ER) modelling is the Top-down approach to database design. In this study guide, we will look at the Bottom-Up approach to database design, called normalisation. Bottom-Up approach usually begins with user views expressed via reports, forms, data entry screens, etc., normalises the organization of the data in these views to a series of relations where the attributes in each of these relations do not cause inadequate data redundancy. These relations are used to produce a logical model expressed as a set of relations. This set of relations is then used to create the database schema file. Clearly the set of relations produced via Bottom-Up approach and the data structure diagram produced from Top- Down approach represent (or at least should represent) the SAME thing. Although in theory, we can use normalisation to derive a good logical design for a relational database, in practise, due to the complexity and the sheer quantity of the different data in an organisation, the Top-Down approach is likely to be a more effective and efficient way to develop the logical design. Instead of using normalisation as a database design technique, it is used as verification mechanism to check if the attributes in each entity derived from the ER modelling process are ideally placed. In this unit, we will focus on how normalisation is used as a verification mechanism rather than a database design technique. Read R & C 6 th Edn, p.184 Section 5.1 R & C 7 th Edn, p.148 Section

4 FIT1004 Database 2. Purposes of Normalisation Normalisation is a process for evaluating and correcting table structures to minimise data redundancies, thereby helping to eliminate data anomalies. i To better appreciate the purposes of normalisation, you will need to understand what are inadequate data redundancies and how they can to data anomalies. Read R & C 6 th Edn, p Section R & C 7 th Edn, p Section 5.2 Do R & C 6 th Edn, p Review Questions 1, 8 R & C 7 th Edn, p.175 Review Questions 1, 8 3. The Normalisation Process Now, we will focus on the normalisation process. To minimise data redundancies, normalisation uses a systematic process of converting a table (can also be entity or relation) from an unnormalised form (UNF) to the first normal form (1NF), subsequently from the 1NF to second normal form (2NF), and finally, from the 2NF to the third form (3NF). Theoretically, the normalisation process does stop the conversion of a table at 3NF, but may be a higher level of normal form. However, since a table at 3NF would usually meet the requirements of most applications, this unit will not go beyond the 3NF. So what is achieved by converting a table from one normal to the next normal form? In each conversion, the normalisation process is trying to evaluate the presence of a specific undesirable characteristic and eliminate i R&C 59

5 Study Guide 6: Normalisation it from the table. The following are the undesirable characteristics which the conversions from UNF to 3NF are trying to eliminate: UNF to 1NF: eliminates repeating groups 1NF to 2NF: eliminates partial dependencies 2NF to 3NF: eliminates transitive dependencies The following are the detailed discussions on how to identify each of these undesirable characteristics and the method to eliminate them from the table. Conversion to First Normal Form Read R&C 6 th Edn, p Section R & C 7 th Edn, p Section Do R&C 6 th Edn, p Review Questions 2, 6(a) R&C 6 th Edn, p Problems 1, 5, 6, 8 R&C 7 th Edn, p.175 Review Questions 2, 6(a) R&C 7 th Edn, p Problems 1, 5, 6, 8 Conversion to Second Normal Form Read R&C 6 th Edn, p Section R&C 7 th Edn, p Section

6 FIT1004 Database Do R&C 6 th Edn, p Review Questions 3, 7 R&C 6 th Edn, p Problems 2, 9 R&C 7 th Edn, p.175 Review Questions 3, 7 R&C 7 th Edn, p Problems 2, 9 Conversion to Third Normal Form Read R&C 6 th Edn, p Section R&C 7 th Edn, p Section Do R&C 6 th Edn, p Review Questions 4, 9 R&C 6 th Edn, p Problems 3, 9 R&C 7 th Edn, p.175 Review Questions 4, 9 R&C 7 th Edn, p Problems 3, 9 Improving the design Read R&C 6 th Edn, p Section R&C 7 th Edn, p Section 5.4 Do R&C 6 th Edn, p Problems 11, 12, 15, 16 R&C 7 th Edn, p Problems 11, 12, 15, 16 61

7 Study Guide 6: Normalisation 4. Illustrating the normalisation process using relations Instead of showing the normalisation process using a series of dependency diagram, we can also use a series of relations to illustrate the conversion from one form to the next form. This section illustrates this way of presenting the normalisation process using the following scenario. Scenario You have an entity called Order which is one of the entities you have derived from the ER modelling process. This entity represents the document shown in Figure 1. To validate if this entity is in the third normal form, you have decided to use normalisation. CUSTOMER ORDER ORDER#: DATE: 11/4/199X CUSTOMER#: 1273 CUSTOMER NAME: DUDE FASHIONED FURNITURE CUSTOMER ADDRESS: 123 EXCELLENT ST. CITY-STATE-POSTCODE: WAYNESVILLE, VIC PRODUCT# DESCRIPTION QUANTITY ORDERED UNIT PRICE M128 B381 R210 BOOKCASE CABINET TABLE Figure 1: Customer Order Normalisation Process The first step is to illustrate entity Order in UNF and we can do that by listing all the attributes of the entity in the relation format, as follows: UNF ORDER (order#, customer#, customer_name, customer_address, customer_zip, order_date product#, product_description, quantity_ordered, unit_price)

8 FIT1004 Database Conversion from UNF to 1NF: To convert the relation from UNF to 1NF, we would need to eliminate repeating groups by identifying a proper primary key which can uniquely identify any attribute any attribute value. In this case, a proper primary key we can use is one which comprises of order# and product#. With such a primary key, we can now identify the attribute values for each line of products that appear in a particular order. With the new primary key, it seems that this relation represents the order line (i.e. grey portion of Figure 1) better, rather than the order itself. Due to this reason, we have decided to rename the relation from ORDER to ORDER_LINE. 1NF ORDER_LINE (order#, customer#, customer_name, customer_address, customer_zip, order_date product#, product_description, quantity_ordered, unit_price) Conversion from 1NF to 2NF: Converting the relation from 1NF to 2NF involves eliminating the partial dependencies you have identified in the previous step. In this example, we can see that there are some non-key attributes which are only dependent on order#, while some others are only dependent on product#. Thus eliminating the partial dependencies would create new relations from the relation above, as shown as follows: 2NF ORDER_LINE (order#, product#, quantity_ordered) ORDER (order#, customer#, customer_name, customer_address, customer_zip, order_date ) PRODUCT (product#, product_description, unit_price) Conversion from 2NF to 3NF: Finally, we check for dependencies between non-key attributes and remove these transitive dependencies as a new relation. The following shows the relations in 3NF: 63

9 Study Guide 6: Normalisation 3NF ORDER_LINE (order#, product#, quantity_ordered) ORDER (order#, customer#, order_date ) CUSTOMER (customer#, customer_name, customer_address, customer_zip) PRODUCT (product#, product_description, unit_price) Do Based on what you have just learnt in Section 4, normalise another entity, called INVOICE, you have derived from the ER modelling process. This entity represents the document shown in Figure 2. CUSTOMER NO: 1273 INVOICE NO: NAME: DUDE FASHIONED FURNITURE DATE: 11/5/199X ADDRESS: 123 EXCELLENT ST. ORDER NO: CITY-STATE-POSTCODE: WAYNESVILLE, VIC PRODUCT DESCRIPTION QTY QTY QTY UNIT TOTAL NO. ORD. SHIP. BACK. PRICE PRICE B381 CABINET M128 BOOKCASE R210 TABLE TOTAL AMOUNT % DISCOUNT AMOUNT DUE Figure 2: Customer Invoice 64

10 FIT1004 Database 5. Normalisation as a verification mechanism Read R&C 6 th Edn, p Section 5.2 R&C 7 th Edn, p Section 5.7 Do In Study Guide 4, Section 4, we have illustrated the ER modelling process with Fly-By-Night Travels case study. Using normalisation, verify if the entities in the ER diagram you have derived at Step 6 are well designed (i.e. if they are at 3NF). 6. Summary Developing a good logical model is an essential step towards implementing a database which can efficiently and effectively meet the requirements of the business. In this study guide, you have learnt how to perform normalisation which can be used to systematically verify if the entities derived from ER modelling are well-designed. If not, normalisation can be used to further improve your ER design. Read R&C 6 th Edn, p Summary R&C 7 th Edn, p Summary 65