Re: OO versus RDB

From: <>
Date: 28 Jun 2006 12:30:14 -0700
Message-ID: <>

> [SalariedEmployee]
> * employeeNo
> + salary
> ...
> where 'salary' is semantically defined as base salary. Now suppose it
> becomes necessary to keep track of burdened salary. For whatever
> reasons the DBA decides to deliberately denormalize and use a separate
> attribute that depends on 'salary' and other attributes of
> [SalariedEmployee]. (With appropriate stored procedures to synchronize
> the value with changes to those attributes.) The DBA then proceeds to
> "clean up" the schema:
> [SalariedEmployee]
> * employeeNo
> + baseSalary
> + burdenedSalary
> ...
> The semantics of 'baseSalary' is exactly the same as the original
> 'salary' so an application needing the base salary still uses exactly
> the same value. But it can't get it without rewriting the query to use
> the new field name. However, the application solution doesn't care
> about what the schema name is or even where it comes from. IOW, the
> application solution is completely unaffected by the schema change --
> provided one encapsulates RDB access in a subsystem and changes the
> query there.

If the semantics of the old column "salary" are the same as the new column "baseSalary", why on earth would you need to change the name? If the name is not changed, no existing SQL statements would break. Only the applications that needs the new "burdenedSalary", would need to be rewritten.

In what way was the schema denormalized? What did the stored procedure do?

> This sort of situation is actually rather common at the enterprise
> level.

Changing names of columns but keeping the sematics is extremly rare, just because it breaks the interface to the applications.

> That's because different applications use the same data for
> different reasons.

But no single application can force the database schema to break. The applications might use the data for different reasons, but the data is still the same.

> When requirements changes trigger changes to the
> schema, those requirements typically only affect some of the reasons the
> applications use the data. So only a fraction of the applications that
> use the data are affected by the change and have to be modified for the
> requirements changes.

In your example, only the applications that need the new column would need to change. All other remains unchanged.

Fredrik Bertilsson Received on Wed Jun 28 2006 - 21:30:14 CEST

Original text of this message