Decay On Net

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.

Posted by DK on Sunday, November 19, 2006 at 1:13 PM