Re: The (incomplete) Mathematical Foundation of OODBs (XDb)

> > Class is an object.
> > Instance is an object.
> > A object can store data of a type.
>
> Object is an object.
> Object is an object.
> An object can store data of a type.

The 3 new sentences are not equivalent.
A Class is an object but implies a relation with another object. A object is just an object and does not imply a relation with another.

> > It could be that an object could have a type which may not necessary
> > be the same as data type. What is your definition of type?
>
> A set of values with common semantically equivalent operations and those
> operations.
>
> > > > in OODB each instance is actually an object which allows it to have
> > > > its own instances.
> > >
> > > You just lost data independence by exposing physical structure in the
> > > logical interface.
> >
> > Instances(objects) are not independent of their class(object).
> > Which physical structure was exposed?
>
> References.

Each of my objects has an auto-generated ID, similar to a Key in rdbs. XDb can access any object this way, equivalent to accessing each cell in a table uniquely, instead of just by row.

> > > Contrast this with Date's & Darwen's proposals in _The Third Manifesto
> > > where the logical interface exposes only operators and no physical
> > > representation. This, of course, allows for any possible physical
> > > representation gaining us the physical independence we so desperately
> > > need for effective data management.
> >
> > Same with my object model.
>
> You allow any representation of an object and do not rely on pointers?

Each XDb object can do either mode: key or reference.

> > > > In OODBs, the class (obj) and its instances (obj) are of the same
> > > > type.
> > >
> > > Here is a perfect example of the confused thinking in the OODB world.
> It's
> > > not clear at all what a class really is. Is it a type? Is it an object?
> An
> > > object was defined as an instance of a class above, but now instances
> are
> > > the same as classes. An object is an instance of an instance? A class is
> an
> > > object? Doesn't that make an object an instance of an instance of an
> > > instance? And so on ad infinitum?
> >
> > I stated it very poorly.
> > I meant class is an object.
> > and an instance is also an object.
>
> An object is an instance and an instance is an object. We are back to ad
> infinitum.

Yes, and my model could be thought of as "ad infinitum" in some respects.
Ie, Any person can have any number of children who in turn could have any number of children, etc.

> > An object is equivalent to an element in either domain or range.
>
> By this you must mean an object value, because the elements in a domain do
> not change.

In XDb, an object is equivalent to an element in either domain or range.
The object's data (ie "MyFav", 5, "Hello", "1/1/2002") corresponds to the value.

Ie.
Range = {"MyFav"}
Domain = {5, 3.14, "Hello", "1/1/2002"}

> > > All this and no generic operators too!
> > Could you explain/give example of generic operators.
>
> Join, restriction, projection, cartesian product, rename, extend, summarize,
> union, intersection, difference...

XDb doesn't have such low-level operators. They are rather high level.

Addr_getA, AddToDescInsts, AliasDef_get, Child_getByPath, ChildFirst, ChildLast, ChildsDesc_walk, CInstFirst, CInstLast, Cls, CutPaste, CSibNext, CSibPrev, CopyPaste, Data_getAsNumber, Data_getAsStr, Data_setAsStr, Data_getAsStrForTree, DataTypeId_get, Db_set, Del_alsoFromParsInsts, Delete, Fldr_get, Id_get, Inst_add, Inst_findByData, Inst_getByPath, InstPkg_add, InstsDesc_walk, IsAlias, IsAncestCls, IsAncestClsOrEq, IsAncestPar, IsAncestParOrEq, IsDataTypeNumerical, IsDataTypeSummable, IsDescChild, IsDescChildOrEq, IsDescInst, IsDescInstOrEq, IsEntity, IsFolder, IsIncRef, IsProp, IsPropStatic, IsPropVirtual, IsRef, IsSysObj, LevelsToACls_get, LevelsToAPar_get, ObjTypeId_get, Parent, Prop_childFirst_get, Prop_childFirst_set, Prop_get, PropInAncestCls, PropInAncestPar, PropType_toggle, Qty_get, Qty_set, QtyX_get, SibNext, SibPrev, XmlFile_create

> > Do you mean obj.Instantiate & obj.Classify() ?
>
> Nope. Those are non-generic operations defined on a specific type
> -- in this case the universal supertype.

In XDb, obj.Instantiate & obj.Classify() work on any object. It can makes instances of an object
including the one that store numeric 5, if needed.

> Consider three relations: order, order_item, customer. Assume they have
> appropriate attributes and mean what we would think they mean.
>
> Each of the three relations has a different type. The generic operation
> 'restrict' is defined on all three of those types (and any other relation
> type), and the result is the same type as the original relation.
>
> The generic operation 'join' is defined on each pair of relation types. The
> join between order and order_item will result in a fourth relation type. The
> join between order and customer will result in a fifth relation type. The
> join between order_item and customer will result in a sixth relation type. A
> pair of nested join operations on all three will result in a seventh
> relation type.
>
> The join operation is defined on any pair of relation types and always
> results in a relation type. Likewise for the other generic operations.
>
> Because these operations operate on relations resulting in relations, they
> exhibit the important property of closure meaning that we can nest them.
> i.e. The result of one can become the operand of another.

I'll have to do a little reading here.

> > > An RDBMS equates type with domain.
> > > Each scalar value in the RDBMS is a value
> > > of some domain.
> > > Appropriately enough, a domain is approximately equivalent
> > > to the mathematical concept of domain as pertains to relations.
> >
> > I am confused, I thought a relation always has a domain.
> > A domain is used to define a relation.
>
> As near as I can tell, an N-ary relation involves up to N+2 declared types
> (ignoring inheritance and most specific types). Each attribute of the
> relation has a type. The tuples have a type and the relation itself has a
> type.
>
>
> > > I suggest we drop terms like "class" and "domain" to focus on "type".
> >
> > Could you define type at the logical level?
>
> Yes. It is a set of values and their associated operations.
>
>
> > What part does it play in defining a relation?
>
> Type defines the data types of the attributes. The DBMS has a type generator
> that will create tuple and relation types from the attribute types.
>
> As you can see, it plays a very important part.

XDb does not restrict the data type of an object by it's class. This allow the following:
Class = "MyFavThings"
Instances = 5, "Hello", 3.45, "1/1/2002", BLOB.

(Would like to use the BLOB to store object's function in the future.) Received on Sat Jun 15 2002 - 07:20:57 CEST