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

From: Dawn M. Wolthuis <dwolt_at_tincat-group.comREMOVE>
Date: Sun, 20 Feb 2005 12:52:09 -0600
Message-ID: <cvam8s$q1p$1_at_news.netins.net>


"Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message news:pP%Rd.16249$UG1.1279164_at_phobos.telenet-ops.be...
> Dawn M. Wolthuis wrote:
>>
>> I will attempt to explain how I think we can introduce these more complex
>> data structures into the mix without making queries more procedural, but
>> violating other (non-essential, in my opinion) aspects of relational
>> theory.
>>
>> Let's say we admit sets, bags, lists, and trees, but our declarative
>> query language works only against single logical functions (relations
>> with primary keys). Every such function is just one single (logical)
>> relation, where every "column name" a user can use in the query is
>> defined (somewhat like a View). The definition of each function includes
>> a base relation name and each defined column includes "code" for the
>> function that maps this column name to some derivation from columns in
>> this or other base relations. [...]
>
> 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? But given that I arrived at this from experience of looking at systems based on different data models and "feeling" the difference in, let's say agility, rather than studying all models and picking one, there is something very satisfying about finding out that what I think is the best model IS a model that has mathematical backing. 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.

> Note by the way that although this is an old model it has actually seen
> some renewed interest recently. E.g.:
>
> http://www.csd.abdn.ac.uk/~gjlk/mediator/report.html

Great!

>> Did I successfully demonstrate how to introduce more complex data
>> structures into the mix without introducing procedural code or fail to do
>> that? --dawn
>
> 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.

> Avoiding procedural code is a part of that, but not the full story.
> 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? 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. Thanks. --dawn

>
> However, if you remove the lists from your data model and replace them
> with sets then you have something wich is essentially equivalent with the
> relational model restricted to binary relations. As useful and interesting
> as that might be, I would not call that "extending the relational model
> with more complex data structures".
>
> -- Jan Hidders
Received on Sun Feb 20 2005 - 19:52:09 CET

Original text of this message