Re: Database-valued attributes?

From: Costin Cozianu <c_cozianu_at_hotmail.com>
Date: Tue, 11 Nov 2003 06:53:06 -0800
Message-ID: <boqt6f$1g3h55$1_at_ID-152540.news.uni-berlin.de>


Marshall Spight wrote:
> There's been the occasional incidental discussion of relation-valued
> attributes on the list lately. This has got me thinking: what about
> database-valued attributes? That is to say, what about an attribute
> that consists of a set of relation values?
>
> The reason I ask is because I have been thinking about expressing
> trees as values. The canonical logical representation of a tree from
> "Practical Issues in Database Management" is a pair of relations:
> one for nodes, one for edges.
>
> If one wanted to have an attribute that belonged to the tree domain,
> one would need to support an attribute with such a pair of relation
> values.
>
> Does this raise any problems? I don't see any immediate issues, but
> it's not an idea I've ever heard mentioned anywhere else.
>
> Comments welcome, including alternative ideas.
>
>
> Marshall
>
>
>

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.

However to your question, the answer is simple, once you have the following type constructors:

TUPLE
RELATION

ARRAY
LIST You'll obviously be able to have a TUPLE who's fields are relations, and ARRAY whose fields are relations, and so on so forth, merely by composing types together.

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.

Better try this one:

type 'a tree = Empty | Node of 'a * 'a tree list Received on Tue Nov 11 2003 - 15:53:06 CET

Original text of this message