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

From: VC <boston103_at_hotmail.com>
Date: Wed, 6 Jul 2005 19:19:43 -0400
Message-ID: <tuSdncNOyMaR-lHfRVn-vA_at_comcast.com>


"Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message news:MkWye.138787$ys.7375973_at_phobos.telenet-ops.be... [...]
>>>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.
>>
>> I did not ask you about an intro, did I ?
>
> Conversations with you have a tendency of evolving into that. :-)
>

Only when one uses creatures of darkness like LOT, NOLOT, conceptual object type and semantic whatever, do I ask for an introduction ;)

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

I am quite familiar with G.G.'s work in the area of relation query optimization (who is not ?) but I do not find his OO optimization techniques very interesting, in paticular because of this statement:

"
The basic assumption is that high-level query and request languages are and will continue to be based on sets, other bulk types, predicates, and operators. Therefore, operators consuming and producing sets or sequences of items are the fundamental  building blocks of next-generation query and request  processing systems. In other words, we assume that some algebra of sets is the basis of query processing, and our research tries to support any algebra of collections, including  heterogeneous collections and many-sorted algebras.  Fortunately, algebras and algebraic equivalence rules are a very suitable basis for database query optimization.  Moreover, sets (permitting definition and exploitation  of subsets) and operators with data passed (or pipelined)  between them are also the foundations of parallel algorithms  for database query processing.
" ( The Volcano optimizer generator ).

Also, he does not have much to say about views and such, not surprisingly since his interest is mainly query optimization, not a query language per se.
So what's the XML algebra du jour we could chat about (since OODB algebra research appears to be dead or at least dormant) ;) ?

>>>>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.
>>
>> But that's exactly what you are doing: not discerning subtypes.
>
> Oh, but I am. Every object type I introduce in my schema is yet another
> subtype I discern. Subtypes all over the place.

Well, it was not obvious since you used only one predicate, T(O), and by extension one set/data type.

>
>>>>>>>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.
>> OK, I am not sure what "lexical representation" gives you in addition
>> to the old boring data type notion, e.g. varchar(32). As I said
>> before, what's the use of the finiteness property, in practical,
>> terms if it does not do even what varchar(32) already does ?
>
> 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.
>

OK, I'll stay with varchar for now since l.r. benefits are rather nebulous.

Thanks.

> -- Jan Hidders
Received on Thu Jul 07 2005 - 01:19:43 CEST

Original text of this message