Re: RA with MV attributes

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 ?

>

>


> > 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

>

>

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

>

>


>     r3''(Names)


>         bill

>         john, fred

>
>

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 Received on Thu Jan 18 2007 - 01:44:47 CET