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

"Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message news:ol9Sd.16967$pe2.1324068_at_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. :-)

Yup -- I've got intuition written all over me :-)

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

I've just started to look into one of the other topics on my list -- I'd like to understand what the concern is about non-1NF structures leading to 2nd order predicate logic for queries. I do understand that if it did require such then we get into Godel's theorem territory. I just don't know what exactly drives us there to know why folks bring that up. I'm thinking I should read about monadic second order logic (which is provable). Do you have any idea if monadic 2nd order logic is relevant to the FDM, XML data model, PICK model, or other non-RDM data models? The fact that PICK (and XML too, sort of) works with all types extending the String type (in some sense) might be relevant as well, but I haven't studied any logic in connection with databases and query languages as yet beyond a couple of googles, and it has been many years since I studied logic at all, so it might take me more brain power than I want/have to use.

>>> 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? :-)

Yup -- gotta problem with that? Everyone's mom repeats themselves, right? ;-)

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

Of course s/he can -- just as they can do all of the validation of values. referential integrety, and other tasks. But when I look at what I want a data model to do for me and what I'd prefer it not do for me (as a software developer), I end up with different characteristics I desire in a data model than what is commonly provided, it seems.

>
> 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:) ;

One thing that might help it make more sense that I care about this is that I'm working both ends against the middle -- the data model as "told to" the dbms and the data model as told to the UI. I don't want the developer coding that SQL code at all. But that's another story.

Cheers! --dawn

> -- Jan Hidders
Received on Tue Feb 22 2005 - 04:53:19 CET