Re: OO versus RDB

I wish I weren't taking this post seriously.

H. S. Lahman wrote:
> Responding to Frebe73...
> > 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?
>
> To capture the correct semantics of the attribute. In a context where
> one must distinguish between different flavors of salary, the original
> name was poorly chosen and the DBA fixed that.

So you have a poor design. You can still create a view adding the old column name as a derived attribute. For those apps that care only about base salary (nee salary), there's no change. I have no clue how O-O would help in this situation.

> The attribute name is
> supposed to reflect the attribute semantics. Not changing it just leads
> to opportunities for new applications to screw up later.

Agreed, so you fix it. A view helps make the migration gradual, if you need it.

> However, that isn't the point. There are lots of ways to modify schemas
> without affecting individual attribute semantics. For example, I can
> easily construct an example where the attribute is simply moved to
> another table (e.g., to a new [EmployeeSalaryInfo] table, which is a
> child of [Employee]). The application query would still be broken.

In a real DBMS, there's no difference between a view and a table. What's the problem?

> As stated, the burdenedSalary attribute's value is dependent on other
> non-key attributes of Employee. That violates 3NF, which requires that
> non-key attributes be dependent only on the tuple key.

Then it's a calculation to be done in a view. It's not an attribute in a base relvar / table.

> The stored procedure ensures that burdenedSalary is updated whenever any
> of the attributes it depends upon is modified. That is necessary for
> dependent attributes to ensure data integrity outside the scope of the
> update transaction.

There's no integrity concern if you don't store the derived value.

> > Changing names of columns but keeping the sematics is extremly rare,
> > just because it breaks the interface to the applications.
>
> So do all changes to enterprise schemas, which is why /any/ change to
> such a schema is a big deal. The DBA already had to change the schema
> to provide burdenedSalary and chose that opportunity to clean up the
> semantics.

And that's a fine thing to do, but applications will be affected. I don't see O-O helping at all with this.

> > In your example, only the applications that need the new column would
> > need to change. All other remains unchanged.
>
> No, in my example any application that accesses 'salary' must have the
> query construction code modified even though they don't access the new
> attribute.

You're still talking about 2 distinct changes - whether the DBA added them at the same time is irrelevant. And a view still helps.

If you're "correcting" semantics, then any application using the old "semantics" is broken, by definition. If the old apps were doing "select ... from emp..." then you name the base relation "new_emp" or whatever you like, then create a view called "emp" with the proper definition.

If the old apps are getting derived values from the existing table, the "semantics" are broken in that respect too.  

• erk