ISM641-week3assignment.docx

Running head: NORMALIZATION PROCESS 1

NORMALIZATION 6

Normalization Process

Chioma Nnama

ISM 641: Database Design and Management

Asif Choudhery

September 29, 2019

Normalization Process

Purpose of Normalization Process

Normalization forms an integral component and process of the database design process. Nonetheless, the task of separating the normalization procedure from the ER modeling processes to ensure that the two strategies are utilized concurrently. In the above case, the purpose of normalizing the Student Grade entity is to ensure that there is focus on characteristics of specific entities and to represents the micro views of entities within the entity relationship diagram (Watt & Eng, 2018). As such, normalization can be defined as the procedure of seeking to understand the levels of redundancy that is found in a specific table. There are various purposes for which normalization is undertaken in all the normal forms (First Normal Form, Second Normal Form, Third Normal Form, as well as the Boyce-Codd Normal Form). In the first normal form, the process of normalization of relation begins with eliminating the repeating group and forming two new relations. Usually, the primary key of the new relation is a combination of the primary key of the original relations relation as well as an attribute of the newly developed relation from distinct identification.

In the second normal form, the relation should first be in 1NF. This relation should be automatically in 2NF when the primary key is comprised of a single attribute. In the event that the relation has a composite primary key. Then each non-key attribute should be wholly dependent on the entire primary key and not merely subset of the primary key. In light of the above, there should be no partial dependency or augmentation. For instance, in 2NF, the student table is already in 2NF since it has a single-column primary key. When assessing the Student Course table, there is need to recognize that not all the attributes are wholly reliant on the primary key. This is especially the case when dealing with all course information. Therefore, the only attribute that is fully dependent is grade. In the third normal form, the relation should be in second normal form. In addition, all the transitive dependencies should be eliminated. As such, non-key attributes may not be functionally reliant on another key attribute. In this process, it is important to remove all dependent attributes in transitive relationships from each of the tables that contain transitive relationships. This process begins by developing new tables that have removed dependencies. The new tables should be examined and modified to ensure that each of the table possesses a determinant and that no table is comprised of inappropriate dependencies.

How the Anomalies Were Rectified

There are various steps that were taken to eliminate all the anomalies that were detected in each normal form. For instance, in order to rectify the anomalies in 2NF, there were various factors that were taken into consideration. For instance, when adding a new department, a course was required (Watt & Eng, 2018). In the same vein, the process of updating course information could result in inconsistencies in the department information. Moreover, deleting a course may also result in the deletion of department information. Therefore, in order to be in the third normal form, there is need to eliminate all transitive dependencies. In that phase, there should be no anomalies that should be found in third normal form (Watt & Eng, 2018). As such, the first phase is to eliminate repeating groups as indicated below:

Student (StudentNo, StudentName, Grade)

StudentCourse (StudentNo, CourseNo, CourseName, DepartmentID, DepartmentName, Grade)

In case the table possesses more than a single candidate key, the likelihood of anomalies may emerge, although the relations are in 3NF. Boyce-Codd normal form is essentially a special form of 3NF if the relations in BCNF in situations in which each determinant is a candidate key.

References

Watt, A., & Eng, N. (2018). Database design. New York: OpenText.