Update anomaly

Sometimes, I feel so helpless at work. Didn’t we all learnt database normalization back in school? Why is it that we can’t apply the things we learn in school in our daily work?

I’m not refering to normalizing our actual database. That part is already cooked rice. The actual database design is already a flaw. Back in school, I can never really visualize the real impact of having duplicated data in 2 database. That was, until I start working in my current company. Nothing can be don’t to save it already. The initial fountation is already a flaw. Too late to do anything now.

Anyway, I’m not refering to the database design. I’m refering to other part that we are currently doing.

Again and again, we see requester asking us to put the value of the component onto the description. For example, the value of component ABC is 250. Instead of naming the component ‘ABC’, they wanted us to name it ‘ABC – 250’. Unless you have more than 1 component ‘ABC’ with different values, I do not see the need for you to name it ‘ABC – 250’.

This is where update anomaly comes about.

A non-normalized database may store data representing a particular referent in multiple locations. An update to such data in some but not all of those locations results in an update anomaly, yielding inconsistent data. A normalized database prevents such an anomaly by storing such data (i.e. data other than primary keys) in only one location.

Imagine 1 fine day, someone decided to change the value 250 to 200. Instead of just changing the value, they also need to change the description of the component. Isn’t that a bit redundant? It is not that user can’t see the value of the component. They can click on the component and see the value. Perhaps they just need some double assurance. When they see the value is 250 and the description is also 250, they feel safer.

But this extra step is giving us lots of trouble.

As a System Analyst, our duty is to advice the users the best approch to get things done from the IS perspective. Some approch may not be the same as what the user has been doing, then it is the SA’s job to get the user to change. I still remember 1 thing we learnt in Software Development Life Cycle is that users are always resistant to changes. Why are we allowing users to make the whole system look so complicated? There are times where system need to change abit for the users. But there are also times where users have to change abit for the system. It cannot be always system change for the users. Users cannot see the implications of doing some things the old way. We need to let them know and advice them to change some of the methods that they are using. And not give in to their “Last time the old system can do this, why now change new system we must change?”

If the old system is good, then the new system wouldn’t be taking over the old system’s job now.


  1. So are there really flaws with the database design or its just that they may have one “ABC” component now but they might have a few “ABC” family type components coming up in the future?

    Many ways to name two items in the description field:

    1) ABC – 250
    2) ABC – 200


    1) ABC – Type I
    2) ABC – Type II

  2. I would prefer to put the unique identifier behind the word ‘ABC’. After all, the unique identifier is going to stay with the component forever. No chance of it changing.

    Putting the value of the component in the descriptions is just NOT the way to go.

  3. Sounds like they are stuck with the database design as you’ve said earlier.

    If there is going to be potential for multiple variation of the ‘ABC’ item. They could introduce new sub-fields.

    Check out this blog by Vadivel. He post a lot on SQL and database:


  4. Yeah…some users are like that…good advice often falls on deaf ears
    Did they say why they need to put the value in the description? If it’s just for visual inspection purposes then maybe you can suggest building a view with a field that concats the description and the value on top of the table?


Leave a Reply

Your email address will not be published. Required fields are marked *