Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]

In article <42b185ff$1_at_news.fhg.de>, savinov_at_host.com says...
> For example, consider the use of joins. We have several types of them
> including manual joining by means of WHERE. Then in each individual
> query you need to specify all the details of joins. Again, that is
> needed because our database unable to derive necessary information. And
> it is unable to do it because it does not know the semantics of data -

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.

What makes your model "more semantic"? How does your model specify which path(s) to use? In your model, how does the EO, ED, EP, DM, OD database look, and how is the "find the offices of employees managed by Sally" handled?

> it simply can retrieve the specified data according to processing
> instructions given in the query. And the semantics is absent because
> there is no acceptable data model. So in very simplified form you can
> consider a goal getting rid of joins. Each model then will include as a
> necessary part all relationship and the user needs only specify *what*
> he want to retrieve but not *how* he has to produce the result set.
>
> As I mentioned somewhere, a motivating example from UR model might be
> very appropriate for COM as well: we need to compute queries like
>
> SELECT Emploees.name FROM Emploees WHERE Managers.name='Jones' AND
> Products.type'cars'
>
> In terms of MS WinFS it would sound like "I want to get all employees
> with Jones as a manager and related to product with type 'cars'". Note
> that we use 3 tables here (2 for constraints which are propagated and 1
> as a target).

Thank you. Now I think I have discovered still more about where our disagreement lies. I dislike the query above. It is vague, ambiguous and like a box of chocolates---you never know what you're gonna get, because you don't specify what kind of relationships between employees, managers and products you are asking about. Someone might have added the information that a certain manager's mother-in-law likes a certain kind of product, and that influences your result whether you think that relevant or not.

In the RM, queries are theorem proofs. Very exact, but you have to be specific when you ask them. So if you want information retrieval-style queries---simple formulation, possibly ranked results, but you have to manually check their validity---your approach has merit, and you feel the RM is cumbersome. Fair enough. I think it is possible, and very useful, to use the RM for this purpose also, cf. my recent posts about the UR. You disagree, and I don't think any of us will convince the other in this manner.

-- 
Jon