Question

AdventureWorks tables have Insert/Update/Delete anomalies. Isn’t that considered bad design?

Let’s take for example following table.

Sales.SalesReason(SalesReasonID, Name, ReasonType, ModifiedDate)  

where ReasonType is of type nvarchar(50)

Shouldn’t we have another table for ReasonType so the model would look like this:

SalesReason(SalesReasonID, Name, ReasonTypeId, ModifiedDate)  
ReasonType(ReasonTypeId, Name)

This way when doing update of name of ReasonType the change should be done only on one record (prevent update anomaly). Also, it will prevent delete/insert anomalies by keeping available types in db disregarding of whether there are actual data related to them.

Can I have your thoughts on this matter?

Answer 1

Removing ReasonType to another table wouldn’t improve anything. Presumably you would still have one ReasonTypeId per ReasonType so you still have the same potential number of updates to do. I guess you are assuming that you would need to update ReasonTypeId less frequently than ReasonType. Without knowing more about the business requirements that’s just a possibility but it doesn’t have anything to do with solving the type of “update anomaly” that database design theory is usually concerned with.

Consider the table from a normalization theory point of view. If the dependencies are:

{SalesReasonID}->{Name}
{SalesReasonID}->{ReasonType}
{SalesReasonID}->{ModifiedDate}

and if SalesReasonID is the only key then the table is already in Fifth Normal Form. So it doesn’t require any further decomposition.

The Relational Database Dictionary has this to say about the term “update anomaly”:

A somewhat old fashioned term, never very precisely defined, for the
kind of thing that can go wrong in a less than fully normalized
database

Carlo Zaniolo says:

no clear-cut description of anomalies can be given without knowing the
operations envisioned by the user

(ACM Transactions on Database Systems, Vol. 6, No. 1, March 1981)