Re: domain questionnaire

JRStern wrote:
>
> Twenty years ago (and today?) Date and Codd wanted a database to be a
> transparent representation of things in the world, that was half the
> reason they each advocated rows to be identified by value, rather
> than by some "non-relational" arbitrary identifier, rowID, etc.
> Their "domains" were generally real-world domains.
>
> It is not clear today if that was a good idea or not. It seemed to
> make the database more tractable mathematically, perhaps. But, the
> streets are now teeming with "certified" database architects who use
> an identity field or GUID as their primary key at all times, I am not
> aware of good support for enumerable domains in major databases
> (there are constraints and hand-coded triggers and referential
> integrity, but those are not necessarily the same things), and the
> world/representation issue remains unresolved.

I think this touches a deep philosophical problem with the relational model. Date and Codd assume that you look at the relational data model as a data model, a way to describe an ontology, a way to describe a universe of discourse, a way of modelling a part of reality. (I hope the reader understands at least one of these formulations. :-)) But is that really how it is used? It is my impression that in practice you will see two approaches. The classical approach is to directly model your data as tables and call this your data model. In this case you are using the relational model as your data model and the arguments made by Codd and Date apply directly. The other approach is that you use a fancier data model such as the Ent.-Rel. Model, UML class diagrams, ORM or whatever, and then "implement" this in the form of relations. In this case the relational model is used as an "implementation model" (if that is the proper word) and then the arguments by Codd and Date do not seem to apply directly.

Or do they? :-)

-- 
  Jan Hidders