Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]
Date: Fri, 17 Jun 2005 14:45:15 +0200
Message-ID: <42b2c5de$1_at_news.fhg.de>
Jon Heggland schrieb:
> In article <yZKdnTcZTZ6hOi_fRVn-jA_at_comcast.com>, boston103_at_hotmail.com
> says...
>
>>>Not at all. It knows constraints (of which foreign keys are an important >>>special case), it knows domains. It can suggest "join paths", but if >>>multiple paths are possible, some path (or combination of paths) must be >>>selected! This can be done in multiple ways; *how* is not an issue of >>>data model. >> >>That's approximately what I wrote to AS awhile ago. He appears to be >>claiming that RM 'explicit joins' are the 'instructions' one has to specify >>in order to retrieve data and that the 'instructions', a.k.a 'explicit >>joins', are eliminated in his model.
>
>
> I understand him as saying that some "join paths" should be considered
> special, and others forbidden, thus simplifying the formulation of some
> queries (by not requiring the joins to be stated), but disallowing
> others altogether. In other words, the functionality that views provide,
> but with additional limitations.
>
> A more generous reading might be that the other queries are not
> disallowed, but that their joins must be stated explicitly.
We can disable or enable other (arbitrary) queries - it does not matter, it does not influence the model itself. For example, all normal query possibilities could be allowed for compatibility. Or we could disable them to avoid "data hacking".
An important thing is that the data model and database has a very concrete interpretation of the table structure it becomes the most important part of the model. We can call them join paths or foreign keys but for the model it is important that a table (called concept in COM) has a number of supertables and a number of subtables. And then this structure is supposed to serve all other needs (hopefully).
-- http://conceptoriented.comReceived on Fri Jun 17 2005 - 14:45:15 CEST