Re: MV Keys

From: vc <boston103_at_hotmail.com>
Date: 3 Mar 2006 06:39:21 -0800
Message-ID: <1141396761.201643.73400_at_v46g2000cwv.googlegroups.com>


Jon Heggland wrote:
> In article <1141320627.995968.219210_at_i40g2000cwc.googlegroups.com>,
> jog_at_cs.nott.ac.uk says...
> > Jon Heggland wrote:
> > > If you instead say that a "cell" can and must contain exactly one value,
> > > *but* that value may very well be a list, or a set, or a relation---then
> > > there are no problems (in theory).
> >
> > Neither of these. I was referring to a case where specifiying an
> > attribute-name may map to more than one "cell" as you refer to it. i.e.
> > not a one-one functional mapping but a generalised one-many mapping.
>
> I don't really understand. You mean several columns/attributes with the
> same name?
>
> > > Join is crucial, and depends on equality between "cells". But with
> > > multiple values, how do you define equality?
> >
> > Well this has to be specified to the system as with all equality
> > matches. Is 15.0 equal to 15? Is "HELLO" equal to "Hello"? How is a
> > date greater or less than another? These subjective equality decisions
> > are already being made in numerous domains without significant issue..
> >
> > In a sense this is no different in nature to something such as a C++
> > sort template where one has to specify a comparison function. Here,
> > when a type is created one can define how comparisons are made, and I
> > don't see a problem there.
>
> As long as the type of a bunch of values is well-defined, there is
> indeed no problem---indeed, that makes the two alternatives I outlined
> equivalent. However, if any attribute is a set (or list), you probably
> want (for convenience) to treat it as a single value of its constituent
> type when it contains only one value, I.e. "Jon" = { "Jon" }. A language
> that does this may exhibit undesirable behaviour in other places; I
> believe SQL has trouble with table literals because of this.

I am not sure what all the fuss with types is about. The issue has been settled in various functional PLs by treating types as [formal] structures (sets with associated operations). So when it makes sense, you can treat a bunch of values as an element of some type in which case you'll get 1NF for free, or when it does not make sense for whatever reason, you need to normalize.

> --
> Jon
Received on Fri Mar 03 2006 - 15:39:21 CET

Original text of this message