Re: Possible bridges between OO programming proponents and relational model

Cimode wrote:

> I noticed a recurring commercial argumentation about creating
> *behavior* into components (named classes). This caracteristics is
> often presented as being a differentiation of relational model where no
>
> such thing really exists (and in fact is not necessary). In a word, In
>
> OO approach (for whatever it may rely on), one of the main limitation
> of relational model would be not to allow its elementary components to
> emulate elementary predefined processes (transformations for instance).

You don't have to worry all that much about what the relational model allows or doesn't allow. As anybody here can tell you, there are no pure relational databases in the Real World.

What we have is quasi-relational table-based systems that in fact can handle processes very well.

The problem is in how you think about the process, especially transformations. All transformations and processes can be mapped into simple precise definitions of what values should be written to what columns of what tables. In other words, processes resolve to database specifications. If you can specify it, you can code it.

When trying to specify processes in terms of tables, the relational concepts of unique key and foreign key come in very handy for specifying how data should be moved from place to place as it is transformed. Adding basic formulas finishes it off.

So sure, the RM can't do it, but who cares? Table-centric systems can.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)