The Mathematical Foundation of OODBs (XDb)

The Mathematical Foundation of OODBs (XDb)

Post by Jame » Tue, 11 Jun 2002 08:20:16



If a RDB can be defined as follows:
------------------------------------
A RDB represents data as values in relations. A relation is
approximately equivalent to the mathematical concept of relation. A
relation has a header consisting of a set of N named, typed attributes
and a body consisting of a set of N-dimensional tuples where each
tuple dimension value corresponds to the appropriate named, typed
attribute.

One can represent a relation as a table of values where each row
corresponds to a tuple, each column corresponds to a named attribute
and each cell contains some value stored in the relation.

For example

Relation: Person
  Id Name Age
  -- ---- ---
   1 John 32
   2 Mary 22

Then an OODB can be "ROUGHLY" defined as follows:
---------------------------------------------
An OODB represents data as values in single-column relations. A
single-column relation is approximately equivalent to the mathematical
concept of relation. A single-column relation has a header consisting
of ONE named, VARIANT type attribute and a body consisting of a set of
tuples where each tuple's value corresponds to the named, variant type
attribute.

One can represent a single-column relation as a single column of
values where each row corresponds to a tuple, the column corresponds
to the named attribute
and each cell contains some value stored in the relation.

For example, data viewed in XDb's Class/Instance Hierarchy
(www.xdb1.com/Basics/ObjHierarchy.asp) appears as below:

Relation: Person
  1
  2

Relation: Name
  John
  Mary

Relation: Age
  32
  22

The same data viewed in XDb's Parent/Child Hierarchy appears as shown
below:

Person[id=1]
  .Name=John
  .Age=32

Person[id=2]
  .Name=Mary
  .Age=22

An OODB can be defined more precisely as follows:
------------------------------------------------
OODB represents data as instances of classes.
Each instance can store a value of variant type.
Class and instances are approximately equivalent to the mathematical
concept of single-column relation.

But unlike RDB where each tuple in the relation is typically a simple
value,
in OODB each instance is actually an object which allows it to have
its own instances.

For example:

  Person
    John
    Mary
    Doctor
      Jim
      Jerry
  Age
    22
    32

Or more generically, where [] indicates objects class:

Root
  Obj1 [Root]
    Inst11 [Obj1]
    Inst12 [Obj1]
  Obj2 [Root]
    Inst21 [Obj2]
    Inst22 [Obj2]
  Obj3 [Root]
    Inst31 [Obj3]
    Inst32 [Obj3]

********************************************************************
Summary:
Pure OODB and RDB are fundamentally based
on the same mathematical concept of relations.
In RDB, it is relation/values.
In OODB, the equivalent is class/instances.

In RDBs, the relation (box) and values (marbles) are of different
type.
The box and the marbles it holds are of different type.
It isn't practical for a marble to act as box, although it is not
impossible.

In OODBs, the class (obj) and its instances (obj) are of the same
type.
Both are objects.
This orthogonality allows an instance to have its own instances and so
on.

Orthogonality makes it is possible to create algorithms that are more
generic and more resilient to schema-evolutions.

Put simply:
1. Pure OODBs are based on the same mathematical foundation as RDBs.
2. Pure OODBs are more orthogonal then RDBs.

For further details see www.xdb1.com
********************************************************************

 
 
 

The Mathematical Foundation of OODBs (XDb)

Post by Bob Badou » Tue, 11 Jun 2002 09:25:57


Well, your definition is close, but slightly misstated:


Quote:> If a RDB can be defined as follows:
> ------------------------------------
> A RDB represents data as values in relations. A relation is
> approximately equivalent to the mathematical concept of relation. A
> relation has a header consisting of a set of N named, typed attributes
> and a body consisting of a set of N-dimensional tuples where each
> tuple dimension value corresponds to the appropriate named, typed
> attribute.

> One can represent a relation as a table of values where each row
> corresponds to a tuple, each column corresponds to a named attribute
> and each cell contains some value stored in the relation.

> Then an OODB can be "ROUGHLY" defined as follows:
> ---------------------------------------------
> An OODB represents data as values in single-column relations.

Directly transliterated that should read:

"An OODB represents data as values in one-dimensional relations."

You will recall that a single dimension is linear and is often called a
domain or range. One should properly adjust the above to:

An OODB represents data as values of domains.

Quote:> A
> single-column relation is approximately equivalent to the mathematical
> concept of relation.

Should read: "A domain is approximately equivalent to the mathematical
concept of domain."

Quote:> A single-column relation has a header consisting
> of ONE named, VARIANT type attribute and a body consisting of a set of
> tuples where each tuple's value corresponds to the named, variant type
> attribute.

There are no columns in relations -- only attributes. One can represent an
attribute on a two-dimensional medium as a column. It's an important
distinction, which one should strive to keep clear.

"A one-dimensional relation would have a header consisting of a single
named, typed attribute and a body consisting of a set of singles where the
value in each single corresponds to the named, typed attribute."

One would ordinarily call such a linear set an "extent".

It's important to note that the relational operators are not closed over
one-dimensional relations, and this has dire implications.

Quote:> One can represent a single-column relation as a single column of
> values where each row corresponds to a tuple, the column corresponds
> to the named attribute
> and each cell contains some value stored in the relation.

One can represent a domain or an extent as a single column of values where
each row corresponds to a single value of the domain.

Quote:> For example, data viewed in XDb's Class/Instance Hierarchy

Let's not be bothered with such time-consuming nonsense.

Quote:> An OODB can be defined more precisely as follows:
> ------------------------------------------------
> OODB represents data as instances of classes.

Your terms are not very well defined.

What exactly is an instance? Instantiation is a well-known concept in logic,
but it's not at all clear that you mean the same thing.

What exactly is a class? The literature has some controversy over whether
class corresponds to type.

For instance, see Chris Date's recent article at
http://www.pgro.uk7.net/c_substit.htm (One can navigate to this as an
Article under the title "What Does Substitutability Really Mean? Part 1" in
the Content section of http://www.dbdebunk.com/ -- in case the site moves to
a new provider.)

Quote:> Each instance can store a value of variant type.

Isn't this the same as a weakly typed variable?

Quote:> Class and instances are approximately equivalent to the mathematical
> concept of single-column relation.

I disagree. I suspect your usage of class is approximately equivalent to
type, and I suspect your usage of instance is approximately equivalent to
variable.

Of course, the literature is sufficiently confused over these terms that
nothing is really clear.

Quote:> But unlike RDB where each tuple in the relation is typically a simple
> value,

I think you need to reconsider the above statement. A tuple is a set of
values and is not a simple value at all.

Quote:> 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. That might work well in your application programming
environment, but it sucks for data management.

Contrast this with Date's and 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.

Quote:> ********************************************************************
> Summary:
> Pure OODB and RDB are fundamentally based
> on the same mathematical concept of relations.

OODB and RDB are fundamentally based on the same mathematical concept of
domains; however, OODB lacks the very important concept of relation. The
OODB model is the equivalent of nouns without sentences.

Quote:> In RDB, it is relation/values.

In an RDBMS, all data are logically accessed as strongly typed values in
relations as described above. This empowers the DBMS with the might of
modern mathematics -- set algebra or equivalently first order predicate
logic to be exact.

Quote:> In OODB, the equivalent is class/instances.

Your particular brand of OODB exposes all data as weakly typed, named
variables as described above. It has no equivalent of either set algebra or
predicate logic, and it exposes physical structure in the logical interface.

Any other brand of OODB will do things differently.

Quote:> 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?

All this and no generic operators too!

===========================
To finally restate things:

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 suggest we drop terms like "class" and "domain" to focus on "type".

 
 
 

The Mathematical Foundation of OODBs (XDb)

Post by Jame » Sat, 15 Jun 2002 10:52:02


Please ignore this thread. See revision in thread titled
"OOPs!  Object is the foundation of a Relation"
 
 
 

The Mathematical Foundation of OODBs (XDb)

Post by Jame » Sat, 15 Jun 2002 11:44:17


I agree, my description was not complete.

I have revised my definitions in the thread titled
"OOPs!  Object is the foundation of a Relation"

Quote:> What exactly is an instance?
> What exactly is a class?

See new thread.

Quote:> For instance, see Chris Date's recent article at
> http://www.pgro.uk7.net/c_substit.htm (One can navigate to this as an
> Article under the title "What Does Substitutability Really Mean? Part 1" in
> the Content section of http://www.dbdebunk.com/ -- in case the site moves to
> a new provider.)

Thanks.

Quote:> > Each instance can store a value of variant type.
> Isn't this the same as a weakly typed variable?

Yes, required to achieve object orthogonality.
A domain can contain elements that must be represented by variou data
types.

Quote:> > Class and instances are approximately equivalent to the mathematical
> > concept of single-column relation.

> I disagree. I suspect your usage of class is approximately equivalent to
> type, and I suspect your usage of instance is approximately equivalent to
> variable.

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

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?

www.xdb1.com/Data.asp & www.xdb1.com/DataTypes.com

Quote:> > But unlike RDB where each tuple in the relation is typically a simple
> > value,

> I think you need to reconsider the above statement. A tuple is a set of
> values and is not a simple value at all.

My understanding of a tuple was weak.
Is it a set of elements from several domains arranged vertically
side-by-side?
Is a record a tuple?
If so, my earlier comment was way off.

Quote:> > 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?

Quote:> That might work well in your application programming
> environment, but it sucks for data management.

You mean like schema evolution (changing classes)?
If so, how could it be so easy in XDb?
www.xdb1.com/HowTo/ChangeCls.asp

Quote:> Contrast this with Date's and 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.
At the logical level, no physical representations.
See new thread.

Quote:> > ********************************************************************
> > Summary:
> > Pure OODB and RDB are fundamentally based
> > on the same mathematical concept of relations.

> OODB and RDB are fundamentally based on the same mathematical concept of
> domains; however, OODB lacks the very important concept of relation. The
> OODB model is the equivalent of nouns without sentences.
> > In RDB, it is relation/values.

> In an RDBMS, all data are logically accessed as strongly typed values in
> relations as described above. This empowers the DBMS with the might of
> modern mathematics -- set algebra or equivalently first order predicate
> logic to be exact.

My understanding of relation was not complete.

Quote:> > In OODB, the equivalent is class/instances.

> Your particular brand of OODB exposes all data as weakly typed, named
> variables as described above. It has no equivalent of either set algebra or
> predicate logic, and it exposes physical structure in the logical interface.

At the physical level, an object must be able to store variable data
types to remain orthogonal. Without orthogonality you end up with
today's typical rdbs.

Quote:> > 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 equivalent to an element in either domain or range.

Quote:> All this and no generic operators too!

Could you explain/give example of generic operators.
Do you mean obj.Instantiate & obj.Classify() ?

Quote:> 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.

Quote:

> I suggest we drop terms like "class" and "domain" to focus on "type".

Could you define type at the logical level?
What part does it play in defining a relation?
 
 
 

The Mathematical Foundation of OODBs (XDb)

Post by Bob Badou » Sat, 15 Jun 2002 15:06:37



Quote:> > I disagree. I suspect your usage of class is approximately equivalent to
> > type, and I suspect your usage of instance is approximately equivalent
to
> > variable.
> 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.

... doesn't convey much meaning. It's kind of like saying everything is a
symbol and then we can replace the above sentences with:

Symbol symbol symbol symbol.
Symbol symbol symbol symbol.
Symbol symbol symbol symbol symbol symbol symbol symbol.

Quote:> 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.

Quote:> > > But unlike RDB where each tuple in the relation is typically a simple
> > > value,

> > I think you need to reconsider the above statement. A tuple is a set of
> > values and is not a simple value at all.

> My understanding of a tuple was weak.
> Is it a set of elements from several domains arranged vertically
> side-by-side?
> Is a record a tuple?

A tuple is logical with unordered attributes and a record is physical with
ordered attributes. However, they are otherwise similar.

Quote:> If so, my earlier comment was way off.

Okay.

Quote:> > > 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.

Quote:> > Contrast this with Date's and 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?

Quote:> > > 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.

Quote:> 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.

Quote:> > 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...

Quote:> Do you mean obj.Instantiate & obj.Classify() ?

Nope. Those are non-generic operations defined on a specific type -- in this
case the universal supertype.

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.

Quote:> > 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.

Quote:> > 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.

Quote:> 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.

 
 
 

The Mathematical Foundation of OODBs (XDb)

Post by Jame » Sun, 16 Jun 2002 14:20:57


Quote:> > 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.

Quote:> > 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.

Quote:> > > 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.

- Show quoted text -

Quote:> > > > 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.

Quote:> > 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"}

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

Quote:> > 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.

- Show quoted text -

Quote:> 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.

- Show quoted text -

Quote:> > > 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.)

 
 
 

The Mathematical Foundation of OODBs (XDb)

Post by Bob Badou » Sun, 16 Jun 2002 14:33:22



Quote:> > > 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.

If object A points at object B and object B points at object A, does that
mean that each is a class of the other?

Quote:> A object is just an object and does not imply a relation with another.

What defines the operations for a type?

Quote:> > > > 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.

Then it gives up physical independence.

Quote:> 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.

Big deal, you've re-invented the network model dbms. If you want to use the
accepted terminology, I guess you would need to dig up CODASYL -- if anyone
even remembers what that is.

Quote:> > > > 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.

You mean it doesn't have such high-level logic operations it only has record
at a time navigation.

Quote:> > > 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.

Because every object is a subtype of a common class that defines them.

What generic operation do you have that in any way resembles 'cartesian
product' ? ie. That operates on two "objects" of any type returing an
"object" of a third derived type. (Here I use "derive" in its broadest
sense, and it does not imply inheritance.)

Quote:> > 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.

Yes, you will. Please, do so.

Quote:> XDb does not restrict the data type of an object by it's class.

This only means that your variables are untyped or weakly typed.
 
 
 

The Mathematical Foundation of OODBs (XDb)

Post by Jame » Sun, 16 Jun 2002 21:34:24


I have come to the conclusion that my model is NOT the OO or
Relational Model. And that my attempt to describe it as such requires
hi-jacking the OO/Relational concepts and vocabulary which has
resulted in a lot of confusion for everyone. Therefore I will rename
my model and vocabulary and present it separately from OO or
Relational.
 
 
 

The Mathematical Foundation of OODBs (XDb)

Post by Jame » Tue, 18 Jun 2002 02:54:00


What is so obvious to others, hasn't been for me. Thanks for your help.
 
 
 

1. The Foundation of OO (XDb)

The object is the fundamental atomic thing.
An object can represents anything: a number, a word, a person, a car,
a sound, a picture, a movie, a smell, a feeling, an idea, etc.
An object can have instances.
An instance is an object that has a class.
A class is an object that has instances.

An object inherits the non-overridden properties
and methods of its ancestor classes.
An object can override/add properties and methods.

(www.xdb1.com)

2. hash

3. mathematical functions

4. import lotus ?

5. mathematical operator problem

6. Questions about back-ends for Visual Foxpro

7. mathematical operator problem (^)

8. Immigration hastens downward wage equalization of EEO

9. Mathematical Functions

10. SQL Using Mathematical Functions

11. Mathematical Permutation with asp!!

12. how a query looks in descibed in a mathematical way

13. Mathematical function (MIN,MAX etc...)