Re: The Foundation of OO (XDb)

"James" <jraustin1_at_hotmail.com> wrote in message news:a6e74506.0206150636.109aed5b_at_posting.google.com...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
news:<Q_zO8.358$Dw1.51783809_at_radon.golden.net>...
> > "James" <jraustin1_at_hotmail.com> wrote in message
> > news:a6e74506.0206142035.662b10e9_at_posting.google.com...
> > > Considering the amount of existing confusion + my redefintions,
> > > your suggestions to use new vocabulary seem more appealing....
> > > What word can I use instead of an object?
> >
> > Would "record" describe what your product uses?
>
> What would be the most appropriate name for the intersection of a
> Variable X-Dimensional Relation? Would it still be called a point?

(Stay with me folks! This one starts a little dry but gets really interesting toward the end.)

If one thinks of a relation as describing a set of points in a space (locus), one would think of a tuple as describing a point.

If one thinks of a relation as describing a theorem, one would think of a tuple as describing a proposition.

If a given tuple exists within the relation, the point is on the locus, or alternatively the proposition is true. If the given tuple does not exist within the relation, the point is not on the locus, or alternatively the proposition is false. (This is known as the "closed world assumption".)

Consider the following bill of materials relation (I have shown the tuples as ordered tuples to establish the correspondence between header and body):

BOM =

{ ( Product, Ingredient, Qty, UoM ) |
     ( Cake, Flour, 3, Cup ),
     ( Cake, Egg, 2, Each ),
     ( Cake, Sugar, 1, Cup ),
     ( Cake, Cocoa, 0.5, Cup ),
     ( Shelf, Bracket, 2, Each ),
     ( Shelf, Plank, 1, Each ),
     ( Shelf, Screw, 4, Each )

One might describe its predicate as "A Product is made with Qty UoM of Ingredient".

The proposition "A Cake is made with 4 Cups of Flour" is false, while the proposition "A Cake is made with 3 Cups of Flour" is true. Alternatively, the point ( Cake, Flour, 4, Cup ) is not on the locus of the relation, while the point ( Cake, Flour, 3, Cup ) is on the locus.

If we don't care about the quantity and units of measure, we can project the relation onto { Product, Ingredient }:

BOM{ Product, Ingredient } =

{ ( Product, Ingredient ) |
     ( Cake, Flour ),
     ( Cake, Egg ),
     ( Cake, Sugar ),
     ( Cake, Cocoa ),
     ( Shelf, Bracket ),
     ( Shelf, Plank ),
     ( Shelf, Screw )

We can see from this relation making a cake uses flour and making a shelf uses screws, but making a cake uses no screws and making a shelf uses no flour.

One might describe this relation's predicate as: "Making a Product uses some measure of Ingredient."

If one thinks of the original BOM relation as describing a set of points in 4 dimensions, one could informally think of the projected relation as the shadow it would cast on the ( Product, Ingredient ) plane.

Keep in mind that the above example is intentionally simple. We might have another relation that gives instructions for making these products in the form of a training video:

INSTR =
{ ( Product, Video ) |

     ( Cake, ... ),
     ( Shelf, ... )

I have used ellipsis above because (as one might imagine) representing a Video as text involves some difficulty. I think anyone would agree that Video is a complex type whose values are complex object values.

(I hope you have followed along thus far. The next step is a real jaw dropper.)

Logically, a Video has a sequence of frames (pictures) and a stream of sound waves and everything necessary to synchronize them. Physically, though, we have many ways to represent Video. QuickTime, AVI and MPEG jump to mind.

QuickTime, AVI and MPEG are not subtypes of Video; they are different representations or encodings of the same type. Logically, they perform the same function perhaps with different performance and size characteristics.

Date's and Darwen's model of type allows the dbms to deliver all possible representations of Video at the logical level regardless of the actual representation stored on the physical medium.

Someone in the creative department querying the dbms might watch a Video in its QuickTime representation on their Mac. Someone it the engineering department querying the same dbms might watch the same Video in its MPEG representation on their unix workstation. Someone else might watch it as an AVI in Excel.

Consider the following view:

RECIPE = ( BOM join INSTR ) group { Ingredient, Qty, UoM } as Ingredients = { ( Product, Video, Ingredients = { ( Incredient, Qty, UoM ) } ) |

    ( Cake, ..., {

        ( Flour, 3, Cup ), ( Egg, 2, Each ), ( Sugar, 1, Cup ), ( Cocoa, 0.5, Cup )

    } )
    ( Shelf, ..., {

        ( Bracket, 2, Each ), ( Plank, 1, Each ), ( Screw, 4, Each )     } )
}

Just imagine how a user might interact with a view like that in Excel or on WebTV.

Doesn't it just make you drool? It makes me drool! Wouldn't you like to work with a product like that? I know I do!

If you want to make a product that supports complex objects in a dbms, don't give me no steeenking OID. We don't neeeed no steeenking OID. We need an RDBMS! Received on Sat Jun 15 2002 - 19:52:33 CEST