Scribd
Upload
22 views

Anomalies in DBMS

Uploaded by

moazmizan666
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
22 views

Anomalies in DBMS

Uploaded by

moazmizan666
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

Anomalies in a Database Management System (DBMS)

Typically arise in poorly designed or unnormalized tables, leading to various problems related to
data consistency, redundancy, and integrity. Below are situations where insertion, deletion, and
update anomalies occur, along with solutions for each using examples.

1. Insertion Anomaly

Situation:

An insertion anomaly occurs when certain data cannot be inserted into the database without the
presence of other unnecessary data. This usually happens in tables where multiple pieces of
unrelated data are stored together.

Example:

Consider the table Employee_Project, which stores both employee and project details:

Employee_ID Employee_Name Project_ID Project_Name Project_Manager


101 John P001 App Dev Manager X
102 Alice P002 Web Dev Manager Y

If you want to insert a new project P003 (AI Development) that no employee is currently
working on, you cannot insert this project because the table requires employee information. The
table structure forces the presence of employee data, which is irrelevant in this case.

Solution:

To eliminate this insertion anomaly, normalize the table by separating project details and
employee details into two tables:

1. Project Table:

Project_ID Project_Name Project_Manager


P001 App Dev Manager X
P002 Web Dev Manager Y
P003 AI Development Manager Z

FCSDI 1
2. Employee_Project Table:

Employee_ID Employee_Name Project_ID


101 John P001
102 Alice P002

This way, the project can be added to the Project table without needing any employee
information.

2. Deletion Anomaly

Situation:

A deletion anomaly occurs when the deletion of a piece of data leads to the unintentional loss of
other important data.

Example:

Consider the following table Employee_Department, which stores both employee and
department information:

Employee_ID Employee_Name Dept_ID Dept_Name Dept_Manager


201 Sarah D001 HR Manager A
202 Bob D001 HR Manager A
203 Mike D002 Finance Manager B

Now, if both Sarah and Bob leave the company and we delete their records, we also lose all
information about the HR department, including its manager (Manager A). This happens because
the department and employee data are stored together, leading to the unintentional loss of
department data.

Solution:

To prevent deletion anomalies, normalize the data by separating employee and department
information into two tables:

1. Department Table:

Dept_ID Dept_Name Dept_Manager


D001 HR Manager A
D002 Finance Manager B

2. Employee_Department Table:

FCSDI 2
Employee_ID Employee_Name Dept_ID
201 Sarah D001
202 Bob D001
203 Mike D002

Now, when Sarah


and Bob leave, you only remove their records from the
Employee_Department table, leaving the HR department data intact in the Department table.

3. Update Anomaly

Situation:

An update anomaly occurs when multiple instances of the same data are stored redundantly,
requiring updates in multiple places. If one place is not updated, inconsistencies occur.

Example:

Consider the Employee_Project table again, where employee information and project details
are stored together:

Employee_ID Employee_Name Project_ID Project_Name Project_Location


301 Alex P101 Web App New York
302 Jane P101 Web App New York
303 Steve P102 Mobile App Chicago

If the project location for P101 changes from "New York" to "Boston", we need to update this in
all rows where P101 appears. If we miss updating one row, we will have inconsistent data.

For example, if only Alex’s row is updated:

Employee_ID Employee_Name Project_ID Project_Name Project_Location


301 Alex P101 Web App Boston
302 Jane P101 Web App New York
303 Steve P102 Mobile App Chicago

This creates an inconsistency.

Solution:

To avoid update anomalies, separate the project information into its own table:

1. Project Table:

FCSDI 3
Project_ID Project_Name Project_Location
P101 Web App Boston
P102 Mobile App Chicago

2. Employee_Project Table:

Employee_ID Employee_Name Project_ID


301 Alex P101
302 Jane P101
303 Steve P102

Now, if the project location changes, it needs to be updated only once in the Project table,
avoiding inconsistencies.

Summary of Anomalies and Solutions:

 Insertion Anomaly:

 Situation: Unable to insert new data unless other unrelated data is present.
 Solution: Normalize the database to separate unrelated data into different tables.

 Deletion Anomaly:

 Situation: Deleting one piece of data unintentionally deletes other important data.
 Solution: Split data into different tables based on their logical relationships.

 Update Anomaly:

 Situation: Redundant data requires updates in multiple places, risking


inconsistencies.
 Solution: Eliminate redundant data by creating separate tables for distinct entities.

By using normalization techniques, especially up to 3rd normal form (3NF), we can avoid
these anomalies and maintain a well-structured, consistent, and efficient database.

FCSDI 4

You might also like