Re: RA with MV attributes

Interesting post. Some comments inline.

On Jan 16, 12:40 am, "David" <davi..._at_iinet.net.au> wrote:
>
> Definition: A relation r consists of a relation-type A(r) together
> with a set of tuples T(r), where each tuple is a map from each
> attribute a inA(r) to a subset of D(a).

I realize it's becoming fashionable, but I still dislike the idea that a relation "consists of" its type and its value, both. It's type is its type and its value is its value; it doesn't make sense to me otherwise. If we consider the relation as being a combination of two things, we ought to be able to consider those two things separately. In which case we can ask the question, what is the type of a relation's value? Presumably that is also its type, and so we have infinite regress.

Or consider how it sounds for a value of a non-parameterized type: "An integer consists of a numeric-type int together with an int." ???

Yet another reason to dislike it is that it combines in a single construct both a static construct and a dynamic one. It is entirely reasonable to consider a system where types exist at compile time and do not exist at runtime, and values exist at runtime and do not exist at compile time. So how could we combine them?

Anyway, this is a diversion from your main point.

> T(r) =
> { t |
> there exists t1 in T(r1) &
> there exists t2 in T(r2) &
> for each a in A(r1) \ A(r2), t(a) = t1(a) &
> for each a in A(r2) \ A(r1), t(a) = t2(a) &
> for each a in (A(r1) intersect A(r2)), t(a) = (t1(a) intersect
> t2(a))
> }

Wow. Crazy.

> This is actually an outer join.

It's actually a sort of full outer join, yes?

I'm not sure why you'd want to *replace* regular natural join with this operator, assuming we consider it useful. It seems more like an add-on.

  An inner join requires removal of
> tuples with empty intersections on the common attributes.
>
> Some advantages of MV attributes
>
> 1. Avoids redundancy. This could be significant – say when there
> are a large number of people that co-own a large number of cars.

I don't see how this avoids redundancy.

> 2. It deals rather elegantly with missing information.

I don't get this point either.

> and some significant disadvantages
>
> 1. Each tuple only represents a *lower bound* on the known
> relationships. Therefore it is important to avoid making assumptions
> about what is not true when looking at a given tuple. For example the
> last tuple of r1 |X| r2 above doesn’t imply that John and Fred
> don’t own any cars.
>
> 2. The simple relationship back to propositions and FOPL is lost.
> Perhaps the meaning of a relation could be understood in terms of
> underlying 6NF predicates.
>
> 3. There is a non-uniqueness of representation because tuples can
> group values in different ways yet achieve the same set-theoretic
> result.

2 seems like a deal-breaker, doesn't it? Unless we can use something other than FOPL to assign meaning to terms.

> In the end I’m not sure whether MV attributes are a good idea or not.

Well, I'm not entirely sure whether your analysis was of MV or of this operator you came up with. I still see modest benefit to nested relations,
for example. And they seem to work fine without any additional operators
besides the usual ones, although I haven't analyzed this all that much.

Marshall Received on Tue Jan 16 2007 - 12:10:38 CET