Re: Database-valued attributes?

From: Costin Cozianu <c_cozianu_at_hotmail.com>
Date: Tue, 11 Nov 2003 10:21:08 -0800
Message-ID: <bor9cg$1glml3$1@ID-152540.news.uni-berlin.de>

Marshall Spight wrote:
> "Costin Cozianu" <c_cozianu_at_hotmail.com> wrote in message news:boqt6f$1g3h55$1_at_ID-152540.news.uni-berlin.de...
>

>>I wouldn't call that an attribute. Because if you have a database call
>>attribute a database is a collection of relations. Now you are no more
>>in first order logic.

>
>
> I want to make sure I understand you: you are saying that if I have
> a relation that contains tuples that are pointers to outside databases
> (or relations as well, presumably) then I have left the realm of
> first order logic. Yes? But that if I have a relation with an attribute
> type relation, or tuple of (relation, relation) then I'm still "safely"
> first order.
>

Actually for the relational model to work, it has to be weaker than FOL.

But the point is that if you have say for the tree example a tuple with 2 relations inside (the nodes set and the edge set), the structure of the information is fixed, it is always known at compile time.

However if you had a database than the structure of the information (metadata) inside of it can vary dynamically ( add, drop relations, add drop columns, etc) therefore the operators you offer to the user will probably have to query about the structure dynamically. This is what I wanted to avoid, because if you compose a complex domain by means of type composition with TUPLE, RELATION, ARRAY, etc, those operators still maintain a fix structure as to what's inside.

Just my 2c.

>
>

>>However to your question, the answer is simple, once you have the
>>following type constructors:
>>
>>TUPLE
>>RELATION
>>ARRAY
>>LIST

>
>
> What's the difference between array and list?
>

An array has a lower bound and a high bound of index values, and you can address the elements using a[i].

A list offers you only the guarantee that you can iterate over the elements sequentially.

>
>

>>So yes, you could represent that "tree" as a tuple with two elements,
>>the base set and the adjacency list but then you've just accomplished
>>very little.

>
>
> Fair enough.
>
>
>

>>Better try this one:
>>
>>type 'a tree = Empty | Node of 'a * 'a tree list

>
>
> Mwa ha ha ha! But if I were asking about *that*, it would be
> on comp.lang.functional. And I probably won't be doing
> that until I finish reading "Haskell: the Craft of Functional
> Programming."
>

Well, just because the good folks from comp.database.theory think that tuple and relation are the only needed type constructors, that doesn't make it so. Actually the above definition implies pointers (oh, what a horror :) although they are carefully hidden under the syntax.
>
> Marshall
>
>

Best,
Costin Received on Tue Nov 11 2003 - 12:21:08 CST