Re: atomic

On Nov 2, 6:28 am, paul c <toledobythe..._at_ooyah.ac> wrote:
> I'm wondering are there applications where RVA values that are "empty"
> make sense or are such values just a curious by-product of RVA's? If
> the latter, should they be suppressed or somehow prevented?

In January I started a thread called "RA with MV attributes", in which I provided a formal definition of a join operator. It basically takes set intersections on the joined attributes. Here is the example I used to show it in action, where we are joining on cars...

r1(Names,Cars)
    bill,            car1,car2,car4
    john,fred        car3

   bill              car1,car4     red
   bill              car2          green
   john,fred         car3          red
   john,fred                       green

In that thread I suggested that we could interpret this in FOPL by defining a mapping back to conventional predicates with single valued attributes, based on taking cross products of the multi-valued attributes. Furthermore under that interpretation the above result comes back to an inner join!

Note therefore that the last tuple actually maps to zero predicates.

So r1 |X| r2 is *interpreted* as

   Name Car Colour

   bill              car1          red
   bill              car4          red
   bill              car2          green
   john              car3          red
   fred              car3          red

The MV approach suffers from a troubling non-uniqeness of representation. I don't know if this is really a problem or not.

BTW, in that thread Bob pointed out that a naive definition of projection gives the wrong answers. Clearly a correct definition of projection would be straightforward given the reinterpretation in single valued attributes.

I'm not sure whether the idea has any merit. It possibly could if one is faced with a problem domain with lots of missing information, and many, many 6NF predicates that would become painful to work with. In certain problem domains the space reduction could be significant. There are potential benefits for both the user and the DBMS implementation Received on Sat Nov 03 2007 - 13:01:56 CET