Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]
Date: Mon, 04 Jul 2005 20:35:14 GMT
> "Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message
>>VC wrote: >> >>>"Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message >>>news:xxBxe.135773$vq.7300203_at_phobos.telenet-ops.be... >>> >>> >>>>VC wrote: >>>> >>>> >>>>>"Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message >>>>>news:eHrxe.135259$JD6.7251058_at_phobos.telenet-ops.be... >>>>> >>>>> >>>>> >>>>>>vc wrote: >>>>>> >>>> >>>>Anyway, why do you want specifically an algebra? You don't need one for >>>>asking queries, not for defining views and you don't need one for query >>>>optimization, so why bother? >>> >>>Please clarify whether tour are talking about the RM views and queries or >>>about something else. >> >>All of them, really. FDM-like models, OODB data models, and also the RM.
> 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
Well, it is available, most of those languages are orthogonal.
> (B) The same freedom to re-arrange RA operators is extremely useful for
> query optimization (contrary to your opinion). Internally, the query
> processor decomposes the original query into a set of RA operators and then
> tries to rewrite the query so that its execution were most effective in
> terms of resorces (CPU, IO, etc). In other words, the query processor
> creates an efficient execution plan. I believe this kind of flexibility is
> not possible with alternative data models ue to lack of closure.
Your belief is wrong. Every rearrangement can also be expressed in a calculus.
> I do not know what a network view might be, but, since a relational view is
> just a stored query, the same argument as with (A) applies.
Exactly, you all you need is query language. Whether that is a calculus or an algebra is irrelevant.
>>>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 ?
>>>>>OK. Firstly, why do we care about 'value representation' at all ? >>>> >>>>Because otherwise we couldn't indicate in an ORM schema that the name of >>>>a department is represented as a string. >>> >>>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.
- Jan Hidders