This article originally appeared on the BeyeNETWORK.
How volatile is your database? How often does it change? Now these are two innocent sounding questions. But the answer to these questions leads to some very deep issues in the world of databases and database design.
How often does your database change? And, does this mean how often do the contents of your database change or how often are updates done? When it comes to the change of the contents of data, one thinks of data such as a bank balance. A bank balance changes every time an activity hits the account. A check is written. A deposit is made. An ATM activity occurs. Every time one of these activities occurs, the bank balance changes. This is data at its most volatile.
Or, consider a person’s name and address. It is said that the average American moves principal residences every 4.5 years. The contents of this data element do not change nearly as rapidly as the contents of a bank balance.
So one way to look at change inside a database is to look at how quickly the contents of a data element change. But there is another way to look at change – and that way is referred to as semantic change.
Suppose you have built a database for your sales organization. Today, the sales organization wants to organize sales territories by state. Tomorrow, the sales organization wants to organize by area code. And the day after that, the sales organization wants to organize sales territory by the alphabetic ordering of the names of companies. Each day, the database designer is asked to organize the data a different way.
This type of change is referred to as semantic change. And there is traditionally a lot of data that undergoes semantic changes. Organization charts, sales territories, data organized around the legislation of a company – these, and many more, are common data candidates for semantic change.
So why should an architect care about the different kinds of change? The different kinds of change are important because traditional database management systems are geared to handle the change of content of data, not semantic change. Ask a traditional database management system to allow an element of data to be updated, and you normally have no problem. But ask a traditional database management system to have its structure altered – a data element added, an existing data element changed, an existing data element deleted – and you have a problem. Semantic change can be accommodated, but usually not gracefully at all.
One question arises – are data warehouses an exception? The reason why this question arises is that data inside a data warehouse is not updated. Instead, when the values in a field of data change, a new record is written with the date the change has gone into effect. So, in a way, data inside a data warehouse is immune from the changing of data content. But adding a new row of data is a very easy thing to do. So accommodating change inside a data warehouse is natural and normal.
But adding a new element of data or a new data relationship inside a data warehouse is another story altogether. New elements of data must be treated carefully. Going backward in time and trying to construct a new data element may not be feasible. And new data elements may cause entire blocks of data to have to be reorganized.
When one refers to a database being able to handle change, great care must be taken in specifying exactly what kind of change is being considered.