Chapter 4 notes DBMS.pdf
- 1. Database Management System Chapter 4: Data Normalization Anomalies in Relational Database Design Anomaly means inconsistency in the pattern from the normal form. In Database Management System (DBMS), anomaly means the inconsistency occurred in the relational table during the operations performed on the relational table. There can be various reasons for anomalies to occur in the database. For example, if there is a lot of redundant data present in our database then DBMS anomalies can occur. If a table is constructed in a very poor manner then there is a chance of database anomaly. Due to database anomalies, the integrity of the database suffers. The other reason for the database anomalies is that all the data is stored in a single table. So, to remove the anomalies of the database, normalization is the process which is done where the splitting of the table and joining of the table (different types of join) occurs. Worker_id Worker_name Worker_dept Worker_address 65 Ramesh ECT001 Jaipur 65 Ramesh ECT002 Jaipur 73 Amit ECT002 Delhi 76 Vikas ECT501 Pune 76 Vikas ECT502 Pune 79 Rajesh ECT669 Mumbai In the above table, we have four columns which describe the details about the workers like their name, address, department and their id. The above table is not normalized, and there is definitely a chance of anomalies present in the table.
- 2. Database Management System There are 3 different types of anomalies. 1. Update Anomaly 2. Delete Anomaly 3. Insert Anomaly Update Anomaly When we update some rows in the table, and if it leads to the inconsistency of the table then this anomaly occurs. This type of anomaly is known as an updation anomaly. In the above table, if we want to update the address of Ramesh then we will have to update all the rows where Ramesh is present. If during the update we miss any single row, then there will be two addresses of Ramesh, which will lead to inconsistent and wrong databases. Insertion Anomaly If there is a new row inserted in the table and it creates the inconsistency in the table then it is called the insertion anomaly. For example, if in the above table, we create a new row of a worker, and if it is not allocated to any department then we cannot insert it in the table so, it will create an insertion anomaly. Deletion Anomaly If we delete some rows from the table and if any other information or data which is required is also deleted from the database, this is called the deletion anomaly in the database. For example, in the above table, if we want to delete the department number ECT669 then the details of Rajesh will also be deleted since Rajesh's details are dependent on the row of ECT669. So, there will be deletion anomalies in the table. To remove this type of anomalies, we will normalize the table or split the table or join the tables. There can be various normalized forms of a table like 1NF, 2NF, 3NF, BCNF etc. we will apply the different normalization schemes according to the current form of the table. Stu_id Stu_name Stu_branch Stu_club 2018nk01 Shivani Computer science literature 2018nk01 Shivani Computer science dancing 2018nk02 Ayush Electronics Videography
- 3. Database Management System 2018nk03 Mansi Electrical dancing 2018nk03 Mansi Electrical singing 2018nk04 Gopal Mechanical Photography Updation / Update Anomaly In the above table, if Shivani changes her branch from Computer Science to Electronics, then we will have to update all the rows. If we miss any row, then Shivani will have more than one branch, which will create the update anomaly in the table. Insertion Anomaly If we add a new row for student Ankit who is not a part of any club, we cannot insert the row into the table as we cannot insert null in the column of stu_club. This is called insertion anomaly. Deletion Anomaly If we remove the photography club from the college, then we will have to delete its row from the table. But it will also delete the table of Gopal and his details. So, this is called deletion anomaly and it will make the database inconsistent. Decomposition in database design o When a relation in the relational model is not in appropriate normal form then the decomposition of a relation is required. o In a database, it breaks the table into multiple tables. o If the relation has no proper decomposition, then it may lead to problems like loss of information. o Decomposition is used to eliminate some of the problems of bad design like anomalies, inconsistencies, and redundancy. Types of Decomposition
- 4. Database Management System Lossless Decomposition o If the information is not lost from the relation that is decomposed, then the decomposition will be lossless. o The lossless decomposition guarantees that the join of relations will result in the same relation as it was decomposed. o The relation is said to be lossless decomposition if natural joins of all the decomposition give the original relation. Example: EMPLOYEE_DEPARTMENT table: EMP_ID EMP_NAME EMP_AGE EMP_CITY DEPT_ID DEPT_NAME 22 Denim 28 Mumbai 827 Sales 33 Alina 25 Delhi 438 Marketing 46 Stephan 30 Bangalore 869 Finance 52 Katherine 36 Mumbai 575 Production 60 Jack 40 Noida 678 Testing The above relation is decomposed into two relations EMPLOYEE and DEPARTMENT Employee table: EMP_ID EMP_NAME EMP_AGE EMP_CITY 22 Denim 28 Mumbai 33 Alina 25 Delhi 46 Stephan 30 Bangalore 52 Katherine 36 Mumbai 60 Jack 40 Noida
- 5. Database Management System DEPARTMENT table DEPT_ID EMP_ID DEPT_NAME 827 22 Sales 438 33 Marketing 869 46 Finance 575 52 Production 678 60 Testing Now, when these two relations are joined on the common column "EMP_ID", then the resultant relation will look like: Employee ⋈ Department EMP_ID EMP_NAME EMP_AGE EMP_CITY DEPT_ID DEPT_NAME 22 Denim 28 Mumbai 827 Sales 33 Alina 25 Delhi 438 Marketing 46 Stephan 30 Bangalore 869 Finance 52 Katherine 36 Mumbai 575 Production 60 Jack 40 Noida 678 Testing Hence, the decomposition is Lossless join decomposition. Dependency Preserving o It is an important constraint of the database. o In the dependency preservation, at least one decomposed table must satisfy every dependency. o If a relation R is decomposed into relation R1 and R2, then the dependencies of R either must be a part of R1 or R2 or must be derivable from the combination of functional dependencies of R1 and R2. o For example, suppose there is a relation R (A, B, C, D) with functional dependency set (A->BC). The relational R is decomposed into R1(ABC) and R2(AD) which is dependency preserving because FD A->BC is a part of relation R1(ABC).
- 6. Database Management System Functional Dependency The functional dependency is a relationship that exists between two attributes. It typically exists between the primary key and non-key attribute within a table. X Y The left side of FD is known as a determinant, the right side of the production is known as a dependent. For example: Assume we have an employee table with attributes: Emp_Id, Emp_Name, Emp_Address. Here Emp_Id attribute can uniquely identify the Emp_Name attribute of employee table because if we know the Emp_Id, we can tell that employee name associated with it. Functional dependency can be written as: Emp_Id → Emp_Name We can say that Emp_Name is functionally dependent on Emp_Id. Types of Functional Dependency Trivial Functional Dependency o A → B has trivial functional dependency if B is a subset of A. o The following dependencies are also trivial like: A → A, B → B Example: Consider a table with two columns Employee_Id and Employee_Name. {Employee_id, Employee_Name} → Employee_Id is a trivial functional depend ency as Employee_Id is a subset of {Employee_Id, Employee_Name}.
- 7. Database Management System Also, Employee_Id → Employee_Id and Employee_Name → Employee_Name are trivial dependencies too. Non-trivial functional dependency o A → B has a non-trivial functional dependency if B is not a subset of A. o When A intersection B is NULL, then A → B is called as complete non- trivial. Example: ID → Name, Name → DOB