Re: What is Aggregation? Re: grouping in tuple relational calculus

From: Jan Hidders <jan.hidders_at_REMOVETHIS.pandora.be>
Date: Sun, 20 Feb 2005 23:48:36 GMT
Message-ID: <ol9Sd.16967$pe2.1324068@phobos.telenet-ops.be>

Dawn M. Wolthuis wrote:
> "Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message
> news:pP%Rd.16249$UG1.1279164_at_phobos.telenet-ops.be...

>> 
>> Er, Dawn, you have just been nominated for the "best description of
>> the Functional Data Model, FDM, that doesn't mention that name"
>> award.  ;-)

>
> Dang! So, if I had just read more (and FDM's are on my list of
> someday reading -- I browsed a paper once and it was more complicated
> than I wanted to read), I would not have had to derive this myself,
> eh?

Yep. But this way you gave some more credence to the claim that it is a fairly intuitive and natural data model. :-)

> [...] It seems that those who have learned relational theory in
> colleges often think theirs is the only one where the mathematics has
> been worked out.

Yes. That is indeed regrettable. But there is a grain of truth in that in the sense that already at birth the relational model was already surrounded by a cloud of knowledge that it inherited from already existing research areas such as first order logic, finite model theory and computational complexity. Since then this cloud has only become bigger. On the other hand, this should also not be overstated. There are for exampole also close links between FDM and first order logic, and even between the XML data model and first order logic.

>> Being declarative is not just about avoiding procedural code, it is
>> about making it easy for the optimizer to come up with alternative
>> equivalent implementations.

>
> Yup, agreed, but the challenge I saw in the e-mail was to minimize
> procedural code, which I didn't think was so problematic.

No argument there.

>> Because finding alternative implementations is much harder for list
>> operations than for set operations the model should persuade the
>> modeller to use sets rather than lists whenever possible. This is a
>> crucial feature of the relational mode.

>
> But it seems to me that then data modelers will model lists by
> putting ordering attributes in their relations instead and that
> definitely doesn't help with the optimization of list handling, does
> it?

For query optimization it definitely does. Especially for complex queries on large sets of data.

> By "optimizing", I'm still sticking to the logical side of this, not
> physical implementations, so I'm referring to optimal agility,
> productivity, etc. With ordering attributes rather than the DBMS
> handling ordered lists, joe average programmer (I'll switch from
> average housewife to average programmer here) has to perform inserts,
> ripple deletes and such, rather than permitting the database
> management system to handle.

We're back with the pizza toppings, are we? :-) It has already been argued before that often there will be one ore more natural attributes that define the ordering. I can only add to this that in my (admittedly very limited experience) this is usually the case. But even if it is not and you have to add an artifical seq# column, I don't see why Joe programmer cannot get his head around the fact that for a single insert into a list he has to do the following two updates:

UPDATE OrderItemToppings
SET ToppingSeq# = ToppingSeq# + 1
WHERE OrderID = :thisOrder: AND ItemNr = :thisItem:

   AND ToppingSeq# >= :insertPlace: ;

INSERT
INTO OrderItemTopping ( OrderID, ItemNr, ToppingSeq#, Topping) VALUES ( :thisOrder:, :thisItem:, :insertPlace:, :topping:) ;

• Jan Hidders

Received on Sun Feb 20 2005 - 17:48:36 CST