Re: RA with MV attributes

From: David <davidbl_at_iinet.net.au>
Date: 17 Jan 2007 17:49:33 -0800
Message-ID: <1169084973.538291.236640@a75g2000cwd.googlegroups.com>

dawn wrote:
> David wrote:
> > Bob Badour wrote:
> > > Jon Heggland wrote:
> > >
> > > > David wrote:
> > > >
> > > >>Example
> > > >>
> > > >>r1(Names,Cars)
> > > >> bill, car1,car2,car4
> > > >> john,fred car3
> > > >>
> > > >>r2(Cars,Colours)
> > > >> car1,car3,car4 red
> > > >> car2 green
> > > >>
> > > >>r1 |X| r2 (Names,Cars,Colours)
> > > >> bill car1,car4 red
> > > >> bill car2 green
> > > >> john,fred car3 red
> > > >> john,fred green
> > > >>
> > > >>[...]
> > > >>For example the
> > > >>last tuple of r1 |X| r2 above doesn't imply that John and Fred
> > > >>don't own any cars.
> > > >
> > > >
> > > > So what exactly does that last tuple mean?
> > >
> > > And what would happen if we replaced (car1,car3,car4)<->(red) with
> > > (car1,car3,car4)<->(red,blue) in r2 ?
> >
> > Not that an integrity constraint should prevent that, unless we want to
> > model multi-coloured cars.
> >
> > > Suppose as well that r2(Cars,Colours) has the following tuple:
> > > yellow
> > >
> > > Would r1 |X| r2 (Names, Cars, Colours) have these tuples?
> > >
> > > bill yellow
> > > john, fred yellow
> > >
> > > Or would it have this tuples?
> > >
> > > bill,john,fred yellow
> >
> > I agree these tuples are more that a little suspicious - perhaps enough
> > to reject the MV approach. Nevertheless it is mathematically
> > consistent to simply regard these tuples as vacuous because there are
> > no cars in the tuple to which yellow applies. In that sense I imagine
> > an implementation of the RA would be free to remove redundant
> > information as required.
> >
> > The non-uniqeness of representation is troublesome but not necessarily
> > fatal.

>

> Exactly! Yes, there are tradeoffs.

>

> > I have this idea of a mapping from the set of tuples to an
> > underlying set of respectable 6NF propositions.

>

> Most MV providers map to 1NF for SQL purposes. The issues are a)
> NULL-handling and interpretation and b) getting the ordering attributes
> into the mix for multi-values where the ordering is significant. But
> if the data were not in BCNF or 3NF minus 1NF, for example, as defined
> to MV then they do not magically get into 3NF in the mapping. I'm not
> recalling what 5NF and 6NF are right now, but if your MV data were in
> 6NF minus 1NF to start, then it should be easy to map to 6NF.

>


> > > What meaning would we ascribe to restricting r2 to the colour yellow and

> > > projecting on colour? Similarly, what meaning would we ascribe to

> > > restricting the join to the colour yellow and then projecting on Names?

> >
> > Very perceptive questions. The second case is most interesting

>

> r2 would be considered poor modeling (we really should name some of
> these "normal forms" for MV). It would be OK for a virtual relation,
> but not for a base relation. The higher level (relation) should be the
> strong entity, while the property for that entity would be modeled as
> an attribute. So Car(carId, carName, colors) would be acceptable, but
> r2 as it looks above would not be.

>


> > Start with

> >

> >     r3 = r1 |X| r2 (Names,Cars,Colours)

> >         bill              car1,car4     red

> >         bill              car2          green

> >         bill                            yellow

> >         john,fred         car3          red

> >         john,fred                       green

> >         john, fred                      yellow

>

> This is unlike any relation I have seen in any MV system because, again
> , it stems from bad data modeling (although I have surely seen bad data
> model, just not this bad). Think of it this way - if someone were to
> hand you a form and it would make sense to you to fill it out with the
> information on a single record above, then such a record might make
> sense. The above r3 makes no sense to me.

>


> > Now select yellow

> >

> >     r3'(Names,Cars,Colours)

> >         bill                            yellow

> >         john, fred                      yellow

> >

> > Then project on Names

> >

> >     r3''(Names)

> >         bill

> >         john, fred

> >

> >
> > This is clearly not useful. The problem lies with the selection step.

>

> I think it would be found in the data model itself. Model "strong
> entities" as relations, with properties (such as color) in property
> lists.

>


> > If our intention is to find people that really own yellow cars then we

> > must remove the tuples with no cars.

> >
> > The MV approach is on shaky ground!

>

> There is a different, but unfortunately unwritten as best I can tell,
> set of "rules for modeling data" in MV compared to 1NF. I have
> collected information related to this, but the summary would be to
> determine whether something is a "thing" within the context of your
> system, or is merely a piece of demographic data or a property of some
> other thing. The Things in your system have one row/record per, while
> the properties or entities that can be perceived as properties within
> the context of the system, are attributes. I don't know if that
> helped, but just in case it does... -dawn

I purposely wanted to investigate the set theoretic nature of MV attributes without getting bogged down in rules for modeling data (or even the presence of primary keys). Received on Wed Jan 17 2007 - 19:49:33 CST