Normalization Lecture 7 May Aldoayan

13.1:The purpose of normalization. Normalization: A technique for producing a set of relations with desirable properties, given the data requirements of an enterprise. How normalization can be used when designing a relational database. The potential problems associated with redundant data in base relations. The concept of functional dependency, which describes the relationship between attributes. May Aldoayan

13.1:The purpose of normalization. How to identify functional dependencies for a given relation. How functional dependencies identify the primary key for a relation. How to undertake the process of normalization. How normalization uses functional dependencies to group attributes into relations that are in a known normal form. May Aldoayan

13.1:The purpose of normalization. The characteristics of functional dependencies used in normalization. How to identify the most commonly used normal forms, namely First Normal Form (1NF), Second Normal Form (2NF), and Third Normal Form (3NF). The problems associated with relations that break the rules of 1NF, 2NF, or 3NF. How to represent attributes shown on a form as 3NF relations using normalization. May Aldoayan

Data Redundancy and Update Anomalies Major aim of relational database design is to group attributes into relations to minimize data redundancy. Problems associated with data redundancy are illustrated by comparing the Staff and Branch relations shown in figure 13.1 with the StaffBranch relation shown in Figure 13.2. May Aldoayan

Figure 13.1: Staff and Branch relations Figure 13.1: Staff Branch relation May Aldoayan

Data Redundancy and Update Anomalies Staff (staffNo, sName, psition,slaray,branchNo) Branch(branchNo, bAddress) StaffBranch(staffNo, sName, psition,slaray,branchNo, bAddress) Note that the primary key for each relation underline. In the StaffBranch relation has redundant data; the details of a branch are repeated for every member of staff. In contrast, the branch information appears only once for each branch in the Branch relation and only the branch number (branchNo) is repeated in the Staff relation, to represent where each member of staff is located. May Aldoayan

Data Redundancy and Update Anomalies Relations that contain redundant information may potentially suffer from update anomalies. Types of update anomalies include Insertion Deletion Modification Ex: To insert a new staff tuple into staffbranch, we must include either the attribute values correctly for the branch that the employee works for, or NULLs to insert a new branch that has no employees as yet in the staffbranch relation. The only way to do this is to place NULL values in the attributes for staff. This violates the entity integrity forstaffbranchbecause Staffnum is its primary key May Aldoayan

Lossless-join and Dependency Preservation Properties Two important properties of decomposition. Lossless-join property enables us to find any instance of the original relation from corresponding instances in the smaller relations. Dependency preservation property enables us to enforce a constraint on the original relation by enforcing some constraint on each of the smaller relations. May Aldoayan

Functional Dependencies Important concept associated with normalization. Functional dependency describes relationship between attributes. For example, if A and B are attributes of relation R, B is functionally dependent on A (denoted A  B), if each value of A in R is associated with exactly one value of B in R. May Aldoayan

Functional Dependencies Property of the meaning or semantics of the attributes in a relation. Diagrammatic representation. The determinant of a functional dependency refers to the attribute or group of attributes on the left-hand side of the arrow. Determinate Dependent May Aldoayan

Figure 13.1: Staff and Branch relations May Aldoayan

Example 13.1:identifying a functional dependency Consider the attribute staffNo and position of the Staff relation in figure13.1. For a specific staffNo, for example SL21, we can determine the position of that member of staff as Manager. In other words, the position attribute is functionally dependent on staffNo, as shown in Figure 13.4(a). However, Figure 13.4(b) illustrates that the opposite is not true, as staffNo is not functionally dependent on position. A member of staff holds one position, however, there may be several members of staff with the same position. The relationship between staffNo and position is one-to-one (1:1) for each staff number there is only one position. On the other hand, the relationship between position and staffNo is one-to-many (1:*): there are several staff numbers associated with a given position. In this example, staffNo is the determinant of this functional dependency. For the purposes of normalization we are interested in identifying functional dependencies between attributes of a relation that have a one-to-one relationship. May Aldoayan

Figure 13.4: (a) position is functionally dependent on StaffNo (StaffNo  position); (b) staffNo is not functionally dependent on position (position  staffNo) May Aldoayan

Example 13.2: Identifying a functional dependency that holds for all time. Consider the values shown in staffNo and sName attributes of the staff relation in figure 13.1. we see that for a specific staffNo, for example SL21, we can determine the name of that member of staff as John White. Furthermore, it appears that for a specific sName, for example, John White, we can determine the staff number for that member of staff as SL21. Can we therefore conclude that the staffNo attribute is functionally dependent on the sName attribute and/or that the sName attribute is functionally dependent on the staffNo? If the values shown in the staff relation of Figure 13.1 represent the set of all possible values for staffNo and sName attributes then the following functional dependencies hold: May Aldoayan

Example 13.2: Identifying a functional dependency that holds for all time. StaffNo  sName sName  StaffNo However, the only functional dependency that remains true for all possible values for the staffNo and sName attributes of the Staff relation is: staffNo → sName May Aldoayan

Example 13.3: Trivial functional dependencies Example of trivial dependencies for the staff relation include: StaffNo, sName  sName StaffNo, sName  StaffNo Although these functional dependncies are true for the staffNo and sName attributes of the StaffNo relation, they do not provide any additional information about possible integrity constraints on the values held by these attributes. As the name implies, trivial dependencies are not very interesting in practical terms, we are normally more interested in nontrivial dependencies because they represent integrity constraints for the relation. May Aldoayan

The main characteristics of functional dependencies that we use in normalization: Have a one-to-one relationship between attributes on the left- and right-hand side of a dependency Hold for all time Are nontrivial. We demonstrate the process of identifying a set of useful functional dependencies for a given relation in the following example May Aldoayan

Figure 13.1: Staff Branch relation May Aldoayan

Example 13.4: identfying a set of functional dependencies for the StaffBranch Identify the functional dependencies for the StaffBranch relation as: staffNo → sName, position, salary, branchNo, bAddress branchNo → bAddress bAddress → branchNo branchNo, position → salary bAddress, position → salary We identify five functional dependencies in the StaffBranch relation with: StaffNo, BranchNo, bAddress, (branchNo, position), and (address, city, position) as Determinants For each functional dependency, we ensure that all the attributes on the right-hand side are functionally dependent on the determinat on the left-hand side. May Aldoayan

Identifying the PK for a relation using Functional dependencies The main purpose of identifying a set of functional dependency for relation, to specify the set of integrity constraints that must hold on a relation The determinant attribute(s) are candidate of the relation 1:1 relationship between determinant & dependent No subset of determinant attribute(s) is a determinant. (nontrivial) If (A, B)  C, then NOT A  B, and NOT B  A May Aldoayan

Identifying the PK for a relation using Functional dependencies All attributes that are not part of the CK should be functionally dependent on the key. CK  all attributes of R Hold for all time PK is the candidate attribute(s) with the minimal set of functional dependency May Aldoayan

13.3.3 Inference Rules for Functional Dependencies Closure: the set of functional dependencies that are implied by a given set of functional dependencies X. Armstrong’s aximos (inference rules): the set of inference rules specifies how functional dependencies can be inferred from given one Inference rules: Reflexivity If B  A, then A  B Augmentation If A  B, then A,C  B,C Transitivity If A  B and B  C, then A  C Self-Determination A  A Decomposition If A  B,C, then A  B and A  C Union If A  B and A  C, then A  B,C Composition If A  B and C  D, then A,C  B,D May Aldoayan

Minimal Sets of Functional Dependencies Complete set of functional dependencies for a relation can very large We need to reduce the set to a manageable size, by applying the inference rules repeatedly until they stop producing new FDs Assume S1 & S2 are set of dependencies S1  S2, then S2 is a cover for S1 or S1 is covered by S2 if S2 is a cover for S1 & S1 is a cover for S2 S1 equivalent to S2 May Aldoayan

Minimal Sets of Functional Dependencies A set of functional dependencies X is minimal if it satisfies the following: Every dependency in X has a single attribute for its right-hand side Can’t replace any dependency A  B in X with C B , where C  A, & still have a set of dependencies equivalent to X Can’t remove any dependency from X and still have a set of dependencies that is equivalent to X May Aldoayan

Example 13.6: Identifying the minimal set of functional dependencies of the StaffBranch relation Produce the following functional dependencies: staffNo  sName staffNo  position staffNo  salary staffNo  branchNo staffNo  bAddress branchNo bAddress bAddress branchNo branchNo, p0sition salary bAddress, p0sition salary These functional dependencies satisfy the three conditions for producing a minimal set of functional dependencies for the StaffBranch relation May Aldoayan

The Process of Normalization As normalization proceeds, the relations become progressively more restricted (stronger) in format and also less vulnerable to update anomalies. May Aldoayan

The Process of Normalization Normalization is a bottom-up approach to database design that begins by examining the relationships between attributes. It is performed as a serious of tests on a relation to determine whether it satisfies or violates the requirements of a given normal form. Purpose: Guarantees no redundancy due to FDs Guarantees no update anomalies Normal Forms: First Normal Form (1NF) Boyce-Codd Normal Form (BCNF) Second Normal Form (2NF) Fourth Normal Form (4NF) Third Normal Form (3NF) Fifth Normal Form (5NF) May Aldoayan

First Normal Form (1NF) First Normal Form (1NF) Unnormalized Form (UNF) A table that contains one or more repeating groups. To create an unnormalized table Transform the data from the information source (e.g. form) into table format with columns and rows. First Normal Form (1NF) A relation in which the intersection of each row and column contains one and only one value. May Aldoayan

First Normal Form (1NF) UNF to 1NF: to transfer the unnormalize table to first nomal form we identify and remove repeating groups within a table. There are two common approaches to removing repeating groups from unnormalized tables : In the first approach, we Remove the repeating group by Entering appropriate data into the empty columns of rows containing the repeating data (‘flattening’ the table). In the second approach, we Remove the repeating group by Placing the repeating data along with a copy of the original key attribute(s) into a separate relation. May Aldoayan

ClientRental Figure13.7: ClientRental unormalized table OName ownerNo rentFinish rentStart pAddress PoertyNo cName clientNo Tina Murphy Tony Shaw CO40 CO39 350 450 31-jul-01 1-sep-02 1-jul-00 1-sep-01 6 Lawernce St, Glassgow 5 Novar Dr, Glasgow PG4 PG16 John Kay CR76 CO93 375 10-June-00 1-Dec-01 10-Aug-03 1-sep-99 10-Oct-00 1-Nov-02 2 Manor Rd, Glasgow PG36 Aline Stewart CR56 Figure13.7: ClientRental unormalized table May Aldoayan

UNF to 1NF We identify the key attribute for the clientRental unnormalized table as clientNo. Next, we identify the repeating group in the unnormalized table as the property rented details, which repeats for each client. The structure of the repeating group is: Repeating Group = (propertyNo, pAddress, rentStart, rentFinish, rent, ownerNo, oName) There are multiple values at the intersection of certain rows and column. There are two values for ropertyNo (PG4 and PG16) for the client Name John Kay. To transfor an unnormalized table into 1NF: We ensure that there is a single value at the intersection of each row and column. May Aldoayan

UNF  1NF Approach 1 Expand the key so that there will be a separate tuple in the original relation for each repeated attribute(s). Primary key becomes the combination of primary key and redundant value OName ownerNo rent rentFinish rentStart pAddress PoertyNo cName clientNo Tina Murphy CO40 350 31-jul-01 1-jul-00 6 Lawernce St, Glassgow PG4 John Kay CR76 Tony Shaw CO39 450 1-sep-02 1-sep-01 5 Novar Dr, Glasgow PG16 10-June-00 1-sep-99 Aline Stewart CR56 375 1-Dec-01 10-Oct-00 2 Manor Rd, Glasgow PG36 CO93 10-Aug-03 1-Nov-02 1NF relation May Aldoayan

UNF  1NF Approach 1 ClientRental(ClientNo, PropertyNo, cName,pAddress, rentStart, rentFinish, rent, ownerNo, oName) Disadvantage: introduce redundancy in the relation May Aldoayan

UNF  1NF Approach 2 The second approaches: we remove the repeating group (property rented details) by placing the repeating data along with a copy of the original key attribute (clientNo) in a separate relation. We identify a primary key for the new relation. The format of the resulting 1NF relation are as followers : Client( ClientNo, cName) propertyRenatOwner( clientNo, propertyNo, pAddress, rentStart, rentFinish, rent, ownerNo, oName ) May Aldoayan

Client PropertyRentalOwner cName ClientNo John Kay CR76 Aline Stweart CR56 Client OName ownerNo rent rentFinish rentStart pAddress PoertyNo clientNo Tina Murphy CO40 350 31-jul-01 1-jul-00 6 Lawernce St, Glassgow PG4 CR76 Tony Shaw CO39 450 1-sep-02 1-sep-01 5 Novar Dr, Glasgow PG16 10-June-00 1-sep-99 CR56 375 1-Dec-01 10-Oct-00 2 Manor Rd, Glasgow PG36 CO93 10-Aug-03 1-Nov-02 PropertyRentalOwner May Aldoayan

Second Normal Form (2NF) Second Normal Form (2NF):Based on the concept of full functional dependency. If A and B are attributes of a relation B is fully functionally dependent on A if B is functionally dependent on A, but not on any proper set of A B is partial functional dependent on A if some attributes can be removed from A & the dependency still holds StaffNo, Sname  BranchNo Partial dependency ClientNo, PropertyNo  RentDate Full dependency May Aldoayan

Second Normal Form (2NF) Second normal form (2NF): A 1NF relation in which every attribute is fully nontrivial functionally dependent on the PK.non-prime attributes fully dependent on PK. Applies to relations with composite primary keys & partial dependencies May Aldoayan

1NF  2NF Identify the primary key for the 1NF relation. Identify the functional dependencies in the relation. If partial dependencies exist on the primary key remove them by placing then in a new relation along with a copy of their determinant. May Aldoayan

Example OName ownerNo rent rentFinish rentStart pAddress cName propertyNo clientNo Fd1 (primary key) Fd2 (partial dependency) Fd3 (partial dependency) Fd4 (Transitive dependency) Fd5 (Candidate Key) Fd6 (Candidate Key) Fd1 clientNo, propertyNo  rentStart, rentFinish (primary Key) Fd2 clientNo  cName (partial dependency) Fd3 propertyNo pAddress,rent, ownerNo, oName (partial dependency) Fd4 ownerNo  oName (Transitive dependency) Fd5 clientNo, rentStart  propertyNo, pAddress, rentFinish, rent, ownerNo, oName (candidate dependency) Fd6 propertyNo, rentstart  clientNo, cName, rentfinish (candidate dependency) May Aldoayan

1NF  2NF 3. Remove partial dependencies by placing the functionally dependent attributes in a new relation along with a copy of their determinants RentFinish Rentstart PropertyNo ClientNo 31-Aug-01 1-jul-00 PG4 CR76 1-sep-02 1 – Sep-01 PG16 10-jun-00 1-Sep-99 CR56 1-DEC-01 10-OCT-00 PG36 10-AUG-03 1-Nov-02 RENTAL CLIENT cName clientNo John Kay CR76 Aline Stewart CR56 2NF Relation PROPERTY_OWNER 2NF Relation Oname ownerNo Rent pAddress PoertyNo Tina Murphy CO40 350 6 Lawernce St, Glassgow PG4 Tony Shaw CO93 450 5 Novar Dr, Glasgow PG16 375 2 Manor Rd, Glasgow PG36 2NF Relation May Aldoayan

Transitive Dependency A, B, C are attributes of a relation, such that If A  B and B  C, then C is transitively dependent on A via B Provided A is NOT functionally dependent on B or C (nontrivial FD) Example StaffNo  BranchNo , BranchNo  Address StaffNo  Address May Aldoayan

Third Normal Form (3NF) Third normal form (3NF): A 2NF relation in which NO non-prime attribute is transitively dependent on the PK Based on the concept of transitive dependency. Transitive Dependency is a condition where A, B and C are attributes of a relation such that if A  B and B  C, then C is transitively dependent on A through B. (Provided that A is not functionally dependent on B or C). May Aldoayan

CLIENT RENTAL 2NF Relation 2NF Relation PROPERTY_OWNER 2NF Relation cName clientNo RentFinish Rentstart PropertyNo ClientNo 2NF Relation 2NF Relation PROPERTY_OWNER Oname ownerNo Rent pAddress PoertyNo 2NF Relation May Aldoayan

Third Normal Form (3NF) 2NF to 3NF: A relation that is in 1NF and 2NF and in which no non-primary-key attribute is transitively dependent on the primary key. 2NF to 3NF: Identify the primary key in the 2NF relation. Identify functional dependencies in the relation. If transitive dependencies exist on the primary key remove them by placing them in a new relation along with a copy of their dominant. May Aldoayan

2NF  3NF Owner 3NF relation PROPERTY_FOR_RENT ownerNo rent pAddress oName OwnerNo Tiny Murphy CO40 Tony Shaw CO93 3NF relation PROPERTY_FOR_RENT ownerNo rent pAddress PropertyNo CO40 350 6 Lawernce St, Glassgow PG4 CO93 450 5 Novar Dr, Glasgow PG16 375 2 Manor Rd, Glasgow PG36 3NF relation May Aldoayan

The Decompositions of the ClientRental 1NF relation into 3NF relation 1NF ClientRental 2NF 3NF PROPERTY_OWNER CLIENT RENTAL OWNER PROPERTY_FOR_RENT Client ( ClientNo, cName ) Rental ( ClientNo, ProepertyNo, rentStart, rentFinish) PropertyForRent ( PropertyNo, pAddress, rent, ownerNo) Owner ( OwnerNo , oName ) May Aldoayan

General Definition of 2NF & 3NF Second normal form (2NF) A relation that is in first normal form and every non-primary-key attribute is fully functionally dependent on any candidate key. Third normal form (3NF) A relation that is in first and second normal form and in which no non-primary-key attribute is transitively dependent on any candidate key. May Aldoayan

Boyce-Codd Normal Form (BCNF) Based on functional dependencies that take into account all candidate keys in a relation, however BCNF also has additional constraints compared with the general definition of 3NF. Boyce-Codd normal form (3NF): A 3NF relation in which every determinant in a nontrivial FD is a CK Difference between 3NF & BCNF: A  B 3NF allows this dependency in a relation if B is a primary-key attribute and A is not a candidate key. BCNF insists that for this dependency to remain in a relation, A must be a candidate key. May Aldoayan

Boyce-Codd Normal Form (BCNF) Every relation in BCNF is also in 3NF. However, a relation in 3NF is not necessarily in BCNF. Violation of BCNF is quite rare. The potential to violate BCNF may occur in a relation that: contains two (or more) composite candidate keys; the candidate keys overlap, that is have at least one attribute in common. May Aldoayan

3NF  BCNF Examine FDs for a relation 2. If determinant is NOT a CK, decompose relation into 2 relations CLIENT_INTERVIEW ClientNo Int_Date Int_Time StaffNo RoomNo Fd1 ClientNo, Int_Date  Int_Time, StaffNo, RoomNo (primary Key) Fd2 StaffNo, Int_Date, Int_Time  ClientNo (Candidate Key) Fd3 RoomNo, Int_Date, Int_Time  StaffNo, ClientNo (Candidate Key) Fd4 StaffNo, Int_Date  RoomNo May Aldoayan

3NF  BCNF 3. Remove non-CK dependencies by placing the functionally dependent attributes in a new relation STAFF_ROOM INTERVIEW RoomNo Int_Date ClientNo StaffNo Int_time Int_date ClientNo BCNF Relation BCNF Relation May Aldoayan

Review of Normalization (UNF to BCNF) May Aldoayan

Review of Normalization (UNF to BCNF) Fd1 propertyNo, iDate  iTime, comments, staffNo, sName, carReg (primary Key) Fd2 propertyNo  pAddress (Partial dependency) Fd3 staffNo  sName (Transitive dependency) Fd4 staffNo, iDate  carReg Fd5 carReg, iDate, iTime  propertyNo, pAddress, comments, staffNo, sName (CK) Fd6 staffNo, iDate, iTime  propertyN, pAddress, comments (CK) May Aldoayan

Review of Normalization (UNF to BCNF) May Aldoayan

Review of Normalization (UNF to BCNF) 1NF  2NF PROPERTY_INSPECTION Pno iDate iTime comments StaffNo sName CarReg 2NF PROPERTY Pno pAddress 2NF Pno, iDate iTime, comments, StaffNo, Sname, CarReg StaffNo Sname Transitive Dependency iDate, StaffNo CarReg iDate, iTime, CarReg Pno, comments, StaffNo, Sname iDate, iTime, StaffNo Pno, comments May Aldoayan

Review of Normalization (UNF to BCNF) 1NF  2NF PROPERTY_INSPECTION Pno iDate iTime comments StaffNo CarReg 3NF STAFF StaffNo sName 3NF PROPERTY(Pno, pAddres) STAFF(StaffNo, sName) PROPERTY_INSPECT(Pno, iDate, iTime, comments, staffNo, CarReg) May Aldoayan

Review of Normalization (UNF to BCNF) 3NF  BCNF PROPERTY_INSPECTION Pno iDate comments StaffNo CarReg iTime 3NF Pno, iDate iTime, comments, staffNo, CarReg) StaffNo, iDate carReg CarReg, iDate, iTime pno, comments, staffNo StaffNo, iDate, iTime pno, comments STAFF_CAR(StaffNo, iDate, CarReg) BCNF PROPERTY_INSPECT(pno, iDate, iTime, comments, StaffNo) BCNF May Aldoayan

Fourth Normal Form (4NF) Multi-Valued Dependency (MVD) Although BCNF removes anomalies due to functional dependencies, another type of dependency called a multi-valued dependency (MVD) can also cause data redundancy. Possible existence of multi-valued dependencies in a relation is due to 1NF and can result in data redundancy. May Aldoayan

Multi-Valued Dependency (MVD) Represents a dependency between attributes A, B, C in a relation, such that for each value of A, there is a set of values for B and a set of values of values for C. However, the set of values for B & C are independent of each others. Denoted by: A B, A C Example BranchNo SName, BranchNo OName BRANCH_STAFF_OWNER BranchNo SName OName B003 Ann David Carol Tina May Aldoayan

Trivial MVD : A B trivial MVD if: B  A OR A  B = R May Aldoayan

Fourth Normal Form (4NF) Fourth Normal Form (4NF) : a relation that is in Boyce- Codd Normal Form and contains no nontrivial multi- valued dependencies May Aldoayan

Fourth Normal Form (4NF) Start with a BCNF relation Examine FDs for a relation If nontrivial MVD exists, remove the MVD by placing the attributes in a new relation along with a copy of their determinant 4NF May Aldoayan

Fifth Normal Form (5NF) Lossless-Join Dependency A relation decompose into two relations must have the lossless-join property, which ensures that no spurious tuples are generated when relations are reunited through a natural join operation. However, there are requirements to decompose a relation into more than two relations. Although rare, these cases are managed by join dependency and fifth normal form (5NF). May Aldoayan

Fifth Normal Form (5NF) Fifth Normal Form (5NF): a relation that has no join dependency. 5NF – Example May Aldoayan

Fifth Normal Form (5NF) May Aldoayan