Chapter 13 Normalization Review Questions

13.1

Describe the purpose of normalizing data. When we design a database for a relational system, the main objective in developing a logical data model is to create an accurate representation of the data, its relationships and constraints. To achieve this objective, we must identify a suitable set of relations. A technique that we can use to help identify such relations is called normali ation. !ormali ation is a technique for producing a set of relations with desirable properties, given the data requirements of an enterprise. !ormali ation supports database designers by presenting a series of tests, which can be applied to individual relations so that a relational schema can be normali ed to a specific form to prevent the possible occurrence of update anomalies. "ee also "ections 13.1 and 13.#.

13.$

Describe the types of update anomalies that may occur on a relation that has redundant data. A major aim of relational database design is to group attributes into relations so as to minimi e information redundancy and thereby reduce the file storage space required by the base relations. Another serious difficulty using relations that have redundant information is the problem of update anomalies. These can be classified as insertion, deletion, or modification anomalies. "ee "ection 13.$

13.3

Describe the concept of functional dependency. %unctional dependency describes the relationship between attributes in a relation. %or e&ample, if A and ' are attributes of relation (, ' is functionally dependent on A )denoted A '*, if each value of A in ( is associated with e&actly one value of ' in (.
%unctional dependency is a property of the meaning or semantics of the attributes in a relation. The semantics indicate how the attributes relate to one another and specify the functional dependencies between attributes. When a functional dependency is present, the dependency is specified as a constraint between the attributes.

"ee also "ection 13.3. 13.# How is the concept of functional dependency associated with the process of normalization?

!ormali ation is a formal technique for analy ing relations based on their primary +ey )or candidate +eys in the case of ',!%* and functional dependencies. !ormali ation is often performed as a series of tests on a relation to determine whether it satisfies or violates the requirements of a given normal form. Three normal forms were initially proposed, which are called first )1!%*, second )$!%* and third )3!%* normal form. "ubsequently, a stronger definition of third normal form was introduced and is referred to as 'oyce-,odd normal form )',!%*. All of these normal forms are based on the functional dependencies among the attributes of a relation. 13.# What are the main characteristics of functional dependencies that are used when normalizing a relation? The main characteristics of functional dependencies that we use in normali ation )see "ection 13.3.1*. have a one-to-one relationship between attribute)s* on the left and righthand side of a dependency/ hold for all time/ are nontrivial.

13.0 Describe how a database designer typically identifies the set of functional dependencies associated with a relation. !ormally, the database designer starts by specifying functional dependencies that are semantically obvious/ however, there are usually numerous other functional dependencies. 1n fact, the tas+ of specifying all possible functional dependencies for 2real3 database projects is more often than not, impractical. To begin to identify the set of functional dependencies % for a relation, typically first identify the dependencies that are determined from the semantics of the attributes of the relation. Then, apply Armstrong3s a&ioms )(ules 1 to 3* to infer additional functional dependencies that are also true for that relation. A systematic way to determine these additional functional dependencies is to first determine each set of attributes A that appears on the left-hand side of some functional dependencies and then to determine the set of all attributes that are dependent on A. Thus, for each set of attributes A we can determine the set A4 of attributes that are functionally determined by A based on %/ )A4 is called the closure of A under F*. 13.5 Describe Armstrongs axioms. Armstrongs axioms specify how new functional dependencies can be inferred from given ones. 6et A, ', and , be subsets of the attributes of the relation (. Armstrong3s a&ioms are as follows. 1. Reflexivit ! $. Augmentation ! 3. "ransitivit ! 1f ' is a subset of A, then A B 1f A B, then A,C ,C 1f A B and B C, then A C

7atabase "ystems. 1nstructor3s 8uide - 9art 111

13.:

Describe the characteristics of a table in unnormalized form ( !"# and describe how such a table is con$erted to a first normal form (%!"# relation. A table in unnormali ed form contains one or more repeating groups. To convert to first normal form )1!%* either remove the repeating group to a new relation along with a copy of the original +ey attribute)s*, or remove the repeating group by entering appropriate data in the empty columns of rows containing the repeating data )see "ection 13.0*.

13.;

What is the minimal normal form that a relation must satisfy? &ro$ide a definition for this normal form. <inimal normal form is 1!%. a relation in which the intersection of each row and column contains one and only one value )see "ection 13.0*.

13.=

Describe the two approaches to con$erting a first normal form (%!"# relation to second normal form ('!"# relation(s#. The normali ation of 1!% relations to $!% involves the removal of partial dependencies. 1f a partial dependency e&ists, we remove the functionally dependent attributes from the relation by placing them in a new relation along with a copy of their determinant )see "ection 13.5.$*.

13.1> Describe the concept of full functional dependency and describe how this concept relates to '!". &ro$ide an example to illustrate your answer. Full functional dependenc 1ndicates that if A and ' are attributes of a relation, ' is fully functionally dependent on A if ' is functionally dependent on A, but not on any proper subset of A. "econd !ormal %orm )$!%* is a relation that is in first normal form and every non-primary-+ey attribute is fully functionally dependent on the primary +ey. 13.11 Describe the concept of transiti$e dependency and describe how this concept relates to (!". &ro$ide an example to illustrate your answer. "ransitive dependenc A condition where A, ', and , are attributes of a relation such that if A ' and ' ,, then , is transitively dependent on A via ' )provided that A is not functionally dependent on ' or ,* Third !ormal %orm )3!%* is a relation that is in first and second normal form in which no non-primary-+ey attribute is transitively dependent on the primary +ey. 13.1$ Discuss how the definitions of '!" and (!" based on primary )eys differ from the general definitions of '!" and (!". &ro$ide an example to illustrate your answer. The above definitions for second )$!%* and third normal form )3!%* disallow partial or transitive dependencies on the primary )ey of relations to avoid update anomalies. ?owever, these definitions do not ta+e into account other

candidate +eys of a relation, if any e&ist. The more general definitions for $!% and 3!% ta+e account of the candidate +eys of a relation. !ote that this requirement does not alter the definition for 1!% as this normal form is independent of +eys and functional dependencies. %or the general definitions, we define that a primary-+ey attribute is part of any candidate +ey and that partial, full, and transitive dependencies are with respect to all candidate +eys of a relation. #econd normal form $%NF& A relation that is in first normal form and every non-primary-+ey attribute is fully functionally dependent on any candidate )ey. "hird normal form $3NF& A relation that is in first and second normal form and in which no non-primary-+ey attribute is transitively dependent on any candidate )ey. When using the general definitions of $!% and 3!% we must be aware of partial and transitive dependencies on all candidate +eys and not just the primary +ey. This can ma+e the process of normali ation more comple&, however the general definitions place additional constraints on the relations and may identify hidden redundancy in relations that could be missed. 13.13 Discuss the purpose of *oyce+,odd !ormal "orm (*,!"# and describe how *,!" differs from (!". &ro$ide an example to illustrate your answer.
',!% is based on functional dependencies that ta+e into account all candidate +eys in a relation, however ',!% also has additional constraints compared with the general definition of 3!% given above.

'o ce(Codd normal form $'CNF& only if every determinant is a candidate +ey.

A relation is in ',!% if and

To test whether a relation is in ',!%, we identify all the determinants and ma+e sure that they are candidate +eys. "ee "ections 13.= and 13.1>. 13.1# Describe the concept of multi+$alued dependency and describe how this concept relates to -!". &ro$ide an example to illustrate your answer. )ulti*valued +ependenc $),+& (epresents a dependency between attributes )for e&ample, A, ', and ,* in a relation, such that for each value of A there is a set of values for ' and a set of values for ,. ?owever, the set of values for ' and , are independent of each other. A multi-valued dependency can be defined as being trivial or nontrivial. A <@7 A ' in relation ( is defined as being trivial if )a* ' is a subset of A or )b* A ' A (. A <@7 is defined as being nontrivial if neither )a* nor )b* are satisfied. A trivial <@7 does not specify a constraint on a relation, while a nontrivial <@7 does specify a constraint.
#

7atabase "ystems. 1nstructor3s 8uide - 9art 111

Fourth Normal Form $-NF& A relation that is in 'oyce-,odd !ormal %orm and contains no nontrivial multi-valued dependencies.
%ourth normal form )#!%* is a stronger normal form than ',!% as it prevents relations from containing nontrivial <@7s, and hence data redundancy. The normali ation of ',!% relations to #!% involves the removal of the <@7 from the relation by placing the attribute)s* in a new relation along with a copy of the determinant)s*.

"ee "ection 13.11. 13.10 Describe the concept of .oin dependency and describe how this concept relates to /!". &ro$ide an example to illustrate your answer. .ossless*/oin dependenc A property of decomposition, which ensures that no spurious tuples are generated when relations are reunited through a natural join operation. 1n splitting relations by projection, we are very e&plicit about the method of decomposition. 1n particular, we are careful to use projections that can be reversed by joining the resulting relations, so that the original relation is reconstructed. "uch a decomposition is called a lossless*/oin )also called a nonloss or nonadditi$e* decomposition, because it preserves all the data in the original relation and does not result in the creation of additional spurious tuples. ?owever, there are cases were we require to perform a lossless-join decompose of a relation into more than two relations. These cases are the focus of the lossless-join dependency and fifth normal form )0!%*. Fifth Normal Form $0NF& A relation that has no join dependency.

%ifth normal form )0!%* )also called project-join normal form )9B!%** specifies that a 0!% relation has no join dependency. "ee "ection 13.1$.

1xercises

13.15 0xamine the &atient 1edication "orm for the Wellmeadows Hospital case study shown in "igure %(.'/.

%igure 13.$0 The Well1eadows Hospital 9atient <edication %orm. (a# 2dentify the functional dependencies represented by the data shown in the form in "igure %(.'/. 9atient !o %ull !ame Ward !o Ward !ame 7rug !o !ame, 7escription, 7osage, <ethod of Admin 9atient !o, 7rug !o, "tart 7ate Cnits per 7ay, %inish date The functional dependencies for 'ed !o are unclear. 1f 'ed !o was a unique number for the entire hospital, then could say that 'ed !o Ward !o. ?owever, from further e&amination of the requirements specification, we can observe that 'ed !o is to do with the allocation of patients on the waiting list to beds. (b# Describe and illustrate the process of normalizing the data shown in "igure %(.'/ to first (%!"#3 second ('!"#3 third ((!"#3 and *,!". First Normal Form Patient No, Drug No, Start Date, Full Name, Ward No, Ward Name, Bed No, Name, Description, Dosage, Method of Admin, Units per Day, Finish Date #econd Normal Form Patient No, Drug No, Start Date, Ward No, Ward Name, Bed No, Units per Day, Finish Date Drug No, Name, Description, Dosage, Method of Admin Patient No, Full Name

7atabase "ystems. 1nstructor3s 8uide - 9art 111

"hird Normal Form2'CNF Patient No, Drug No, Start Date, Ward No, Bed No, Units per Day, Finish Date Drug No, Name, Description, Dosage, Method of Admin Patient No, Full Name Ward No, Ward Name (c# 2dentify the primary3 alternate3 and foreign )eys in your *,!" relations. Patient No F!", Drug No F!", Start Date, Ward No F!", Bed No, Units per Day, Finish Date Drug No, Name, Description, Dosage, Method of Admin Patient No, Full Name Ward No, Ward Name 9rimary +eys underlined. 13.1: 4he table shown in "igure %(.'5 lists dentist6patient appointment data. A patient is gi$en an appointment at a specific time and date with a dentist located at a particular surgery. 7n each day of patient appointments3 a dentist is allocated to a specific surgery for that day.

%igure 13.$5 6ists dentistDpatient appointment data. )a* 4he table shown in "igure %(.'5 is susceptible to update anomalies. &ro$ide examples of insertion3 deletion3 and update anomalies. The student should provide e&amples of insertion, deletion and update anomalies using the data shown in the table. An e&ample of a deletion anomaly is if we delete the details of the dentist called 2?elen 9earson3, we also loose the appointment details of the patient called 21an <acEay3. )b* Describe and illustrate the process of normalizing the table shown in "igure %(.'5 to *,!". 8tate any assumptions you ma)e about the data shown in this table.

The student should state any assumptions made about the data shown in the table. %or e&ample, we may assume that a patient is registered at only one surgery. Also, a patient may have more than one appointment on a given day.
1NF
staffNo

P!
aDate a#ime dentistName patNo patName surgeryNo

fd$ fd% fd)

fd&

fd'

fd% and fd& (iolates %NF

2NF

staff! o
staffNo aDate

aDate

a#ime

patNo

patName

surgeryNo

staffNo

dentistName

Fd)* (iolates )NF

3NF / BCNF
F! P!
staffNo aDate a#ime

F!
patNo fd$ fd'

P!
staffNo dentistName fd%

F! P!
staffNo aDate surgeryNo fd&

P!
patNo patName Fd)*

7atabase "ystems. 1nstructor3s 8uide - 9art 111

13.1; An agency called 2nstant ,o$er supplies part+time6temporary staff to hotels within 8cotland. 4he table shown in "igure %(.'9 lists the time spent by agency staff wor)ing at $arious hotels. 4he !ational 2nsurance !umber (!2!# is uni:ue for e$ery member of staff.

%igure 13.$: 1nstant ,over3s contracts )a* 4he table shown in "igure %(.'9 is susceptible to update anomalies. &ro$ide examples of insertion3 deletion3 and update anomalies. The student should provide e&amples of insertion, deletion and update anomalies using the data shown in the table. An e&ample of an update anomaly is if we wish to change the name of the employee called 2"mith B3, we may only change the entry in the first row and not the last with the result that the database becomes inconsistent. )b* Describe and illustrate the process of normalizing the table shown in "igure %(.'9 to *,!". 8tate any assumptions you ma)e about the data shown in this table. The student should state any assumptions made about the data shown in the table. %or e&ample, we may assume that a hotel may be associated with one or more contracts.

1NF

P!
N+N contractNo hours eName hNo h,oc

fd$

fd% fd)

fd&

fd% and fd) (iolates %NF

2NF
N+N contractNo hours contractNo hNo h,oc

N+N

eName

fd& (iolates )NF

3NF / BCNF

F! P!
N+N

F! P!
hours contractNo

F!
hNo

contractNo

fd$

fd)

P!
N+N eName

P!
hNo h,oc

fd%

fd&

1>

7atabase "ystems. 1nstructor3s 8uide - 9art 111

13.1= 4he table shown in "igure %(.'; lists members of staff (staffName# wor)ing in a gi$en ward (wardName# and patients (patientName# allocated to a gi$en ward. 4here is no relationship between members of staff and patients in each ward. 2n this example assume that staff name (staffName# uni:uely identifies each member of staff and that the patient name (patientName# uni:uely identifies each patient.

%igure 13.$; The WardStaffPatient relation. (a# Describe why the relation shown in "igure %(.'; is in *,!" and not in -!".
-ardName staffName -ardName patientName

(elation is in ',!% but there is a nontrivial multi-valued dependency in the relation, so relation is not in #!%. (b# 4he relation shown in "igure %(.'; is susceptible to update anomalies. &ro$ide examples of insertion3 deletion3 and update anomalies. 1f we wanted to insert a new patient name, would have to add two records, one for each member of staff. 1f we wanted to update the name of patient ,laire Bohnson, we would have to update two records. 1f we wanted to delete the record corresponding to patient ,laire Bohnson, we would have to delete two records. (c# Describe and illustrate the process of normalizing the relation shown in "igure %(.'; to -!". To remove the <@7, we create two new relations. WardStaff -ardName, staffName" WardPatient -ardName, patientName" 13.$> 4he relation shown in "igure %(.'< describes hospitals (hospitalName# that re:uire certain items (itemDescription#3 which are supplied by suppliers (supplierNo# to the hospitals (hospitalName#. "urthermore3 whene$er a hospital (h# re:uires a certain item (i# and a supplier (s# supplies that item (i# and the supplier (s# already supplies at least one item to that hospital (h#3 then the supplier (s# will also be supplying the re:uired item (i# to the hospital (h#.

11

2n this example3 assume that a description of an item (itemDescription# uni:uely identifies each type of item.

%igure 13.$= The .ospital+temSupplier relation. (a# Describe why the relation shown in "igure %(.'< is not in /!". This relation has a join dependency B7)hospitalName, itemDescription, supplierNo* among the three projections. (1)hospitalName, itemDescription*, ($)hospitalName, supplierNo*, and (3)itemDescription, supplierNo* of .ospital+temSupplier. (b# Describe and illustrate the process of normalizing the relation shown in "igure %(.'< to /!". To remove the join dependency, we create the following 0!% relations. .ospital+tem)hospitalName, itemDescription* .ospitalSupplier)hospitalName, supplierNo* +temSupplier)itemDescription, supplierNo*.

1$