Explain insertion, update, and deletion anomalies in a table that repeats the same fact across many rows, and give a concrete example of each.

## The root cause All three anomalies have a single origin: a fact is stored in more than one row. When a fact has exactly one home, changing it is one write and it cannot disagree with itself. When it has n homes, correctness depends on the application touching all n, every time, atomically, forever. That is a guarantee no schema can make and no code reliably keeps. Running example: employee(emp_id, emp_name, dept_id, dept_name, dept_location). The functional dependency dept_id determines dept_name and dept_location is a fact about departments that has been parked inside the employee table. ## Insertion anomaly You cannot record a fact until an unrelated fact exists. A new department created in January with its first hire in March cannot be represented at all: the only row type available is an employee row. The workarounds are all bad. A dummy employee row pollutes every count and report of employees. NULLs in emp_id break the primary key. Storing the department elsewhere, in a spreadsheet or a config file, moves the problem outside the database where nothing enforces it. The general shape: two independent facts are forced into one row, so the less frequent one cannot exist alone. ## Update anomaly Changing one fact requires many writes. Relocating a department with 400 employees is a 400-row UPDATE. Three things go wrong. First, cost and contention: the write touches far more rows than the change conceptually implies, taking locks and generating write-ahead log volume proportional to headcount rather than to the change. Second, partial application. If any path in the codebase updates dept_location for one employee, for instance an admin screen that edits a single employee record, the table immediately holds two locations for one department. Nothing rejects this, because a per-row column has no constraint tying rows together. Third, unresolvable ambiguity afterwards. Once 250 rows say Building A and 150 say Building B, the data itself cannot tell you which is correct. You need an external source of truth to repair it. Note that wrapping the update in a transaction fixes only atomicity of that one statement. It does not stop a different code path writing one row, and it does not reduce the cost. ## Deletion anomaly Removing one fact removes another. Delete the last employee in the Research department and the fact that Research sits in Building C is gone, although the department still exists. The information was only ever a passenger on employee rows. This is the insertion anomaly running backwards, and it is the more dangerous of the two because the loss is silent. Nobody gets an error; the data is simply no longer there. ## The fix Give the fact one home: department(dept_id PRIMARY KEY, dept_name, dept_location) and employee(emp_id PRIMARY KEY, emp_name, dept_id REFERENCES department). Now a department exists independently of any employee, relocation is one UPDATE of one row, deleting the last employee leaves the department intact, and the location cannot disagree with itself because there is only one copy. This is exactly what normalizing to Third Normal Form accomplishes here; the anomalies are the symptom, the normal form is the rule that prevents them. ## What an interviewer is listening for Name all three anomalies, give a concrete instance of each rather than a definition, and then collapse them to the single cause, duplicated facts. Candidates who list the three without connecting them to redundancy usually cannot recognise the problem in an unfamiliar schema.