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

vc wrote:
>
> Jan Hidders wrote:
>

>>VC wrote:
>>
>>>"Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message
>>>news:EtCye.138094$Px7.7310395_at_phobos.telenet-ops.be...
>>>
>>>
>>>>VC wrote:
>>>>
>>>>
>>>>>"Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message
>>>>>news:64hye.137293$VX3.7329860_at_phobos.telenet-ops.be...
>>>>>
>>>>>
>>>>>>VC wrote:
>>>>>>
>>>>>>
>>>>>>>OK,  we want specifically an algebra (RA) primarily for two practical
>>>>>>>reasons.
>>>>>>>
>>>>>>>(A) It's trivial to compose relational algebra operators (create nested
>>>>>>>queries) thanks to the closure property. One can create arbitrarily
>>>>>>>complex queries by using several simple and easily understood relational
>>>>>>>operators (join, projection, etc).  I imagine similar freedom is not
>>>>>>>available to the user even with modern network/graph query languages
>>>>>>>(whatever those might be).
>>>>>>
>>>>>>Well, it is available, most of those languages are orthogonal.
>>>>>
>>>>>For example  ? One non-relational language example would suffice.
>>>>
>>>>XQuery and OQL spring to mind. Here is a nice overview:
>>>>
>>>>http://citeseer.ist.psu.edu/heuer91principle.html
>>>
>>>The article you referenced says:
>>>
>>>"As a very important feature of OOQLs we introduced the notion of
>>>object-preserving
>>>operator semantics"
>>>
>>>My note: apparently to make up for the lack of closure.
>>
>>It has nothing to do with lack of closure, it has to do with
>>completeness and expressive power. You can have closure but still not be
>>able to express certain operations.

Just because I refer to it doesn't mean I agree with everything it says.

> Instead
> of talking about completness and expressive power, the article sez:

It's not either / or. It mentions both closedness and adequacy and the latter is about expressive power.

> "The relational model is closed[...] each operation yields a relation.
> This is important for a lot of database features such as composite
> queries, query optimization, and views[...]"

This remark is made in the section where they discuss the desired properties for an algebra. Of course if you use an algebra for these purposes, closure is important. I have never claimed otherwise. What I claimed was that the algebraic approach is not a necessity. The authors of the article think otherwise, but I disagree with them there. More recent research on for example the nested relational calculus has given some evidence for my view.

> and further they claim that "simply extending an object-oriented
> database model by relations makes the query language closed if we
> generate relations as query results." However, they say, closure over
> relations is not adequate for a OO q.l. So they introduce the notion of
> "adequacy" and say that "adequacy complements closure" and among other
> things, "[they] have to introduce object-preserving operations" (see my
> previous comment on object-preserving ops).

Indeed. And as I already said, this adequacy has very little to do with closure. It is about being able to express all the operations that should be expressible.

>>>And elsewhere in the same article:
>>>
>>>"If we have only object generating operations [...] we cannot use the
>>>constructs like views,  updates of  views,
>>>and the equivalence of queries for optimization purposes"
>>>
>>>That's essentially the issues with non-relational query languages I
>>>mentioned in my earlier message.
>>
>>Yes, but as you can see, these problems have been addressed and not only
>>by them. 

True, I certainly agree that the problem is not solved yet. But the algebra they propose is closed and adequate (in the sense that they use this word) and from that way that they do it you can see that even if this was not a good algebra and the operators would have to changed they could probably still get these properties. There have also been other proposals, for example, for investigating theoretically the notion of adequacy that more or less worked in the same way. I believe that the main reason that we don't have *the* object-oriented algebra at the moment is mainly that OODBs never really caught on and then XML came along, so most talented researchers moved there.

>>>>They also mention a few algebras, by the way.
>>>
>>>They do, don't they, but do not provide any example.
>>
>>The paper gives the references, you can look them up in the literature
>>yourself. I don't think this is the place nor do I have the time to give
>>you an introductory course on query optimization in object-oriented
>>databases. 

Conversations with you have a tendency of evolving into that. :-)

> I asked about an example of
> an object-oriented/network/whatever algebra.

And I gave you a pointer so you could find a few yourself. If you need more, Google for "Goetz Graefe" and "query optimization object oriented databases". If you are as smart as you think you are, you will find the examples you are looking for.

>>>If the set/universe of discourse consists of all the objects defined by the
>>>modeller,  then there is no point in talking about the type since there is
>>>only one data type -- the whole universe of discourse.
>>
>>Are you a buddhist, by any chance? :-) Just because all objects belong
>>to a single type doesn't mean we cannot or should not discern subtypes.

Oh, but I am. Every object type I introduce in my schema is yet another subtype I discern. Subtypes all over the place.

>>>>>>A finite string over some finite alphabet.
>>>>>
>>>>>Why do we care about a finite string over some finite alphabet
>>>>>representing a value ?
>>>>
>>>>It ensures that we can show it to the user and the user can enter it via a
>>>>keyboard.
>>>
>>>What's that got to do with a logical model ?
>>
>>The purpose of a logical model is to describe information that can at
>>least in principle be stored and communicated. So objects that cannot be
>>communicated should not be in there.

You're right, the difference with varchar(32) is not that big, although the notion of lexical representation is less restrictive. This restriction is only a first requirement, the absolute minimum. If you as a modeler think that more is necessary then you are of course free to add that. Finally, the model language could in theory provide you with a powerful mechanism to define which set of strings is exactly allowed and thus add a bit more semantics. But that's about it, I think.

• Jan Hidders