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

From: Jan Hidders <>
Date: Wed, 06 Jul 2005 06:50:09 GMT
Message-ID: <BaLye.138283$>

VC wrote:
> "Jan Hidders" <> wrote in message
> news:EtCye.138094$

>>VC wrote:
>>>"Jan Hidders" <> wrote in message 
>>>>VC wrote:
>>>>>OK,  we want specifically an algebra (RA) primarily for two practical 
>>>>>(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:

> 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.

> And further:
> "That is rather than returning relations [...] we must be able to express
> queries that return
> existing objects. Views [...] are the most evident reason for this
> requirement, called adequacy.
> To our knowledge, none of the OOQL proposals found so far deals
> satisfactorily with this requirement"
> 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.

>>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.

>>>>>>>Well, apparently,  I am not as smart as most of your students are. 
>>>>>>>Please provide a definition of "conceptual object type".
>>>>>>A unary predicate.
>>>>>If so,  what would it mean to say that object O is of conceptual type T 
>>>>>given that T is a unary predicate ?
>>>>T(O) holds.
>>>What does it mean ? What's the "T(O)" domain of interpratation  ?
>>All the objects in the universe of discourse that is supposed to be 
>>described by the data model. This set is defined by the modeler, just like 
>>the exact meaning of the predicate in question.

> 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.

>>>>>>>Cannot  we just use the notion of data type (aka domain) instead ?
>>>>>>We can, with the additional restriction that the elements of the 
>>>>>>domains must have some kind of lexical representation.
>>>>>Please define "lexical representation".
>>>>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 


> 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.

  • Jan Hidders
Received on Wed Jul 06 2005 - 08:50:09 CEST

Original text of this message