Re: An object-oriented network DBMS from relational DBMS point of view

Some disarrayed comments to...

On 9 Mar 2007 03:44:37 -0800, Dmitry Shuklin wrote:

> Naive ORDBMS

[...]
This is rather aggregation of ADTs, not yet full-blown OO.

> Object - relational DBMS
>
> Lets move further. By analogy with OOP it is possible to implement
> single inheritance. The table, which has inherited base table, also
> inherits columns of that base table or, what is equivalently, inherits
> class fields. Base table should contain all class instances (= rows)
> from all derived tables, which were inherited from this base table.

That's extension, a case of generalization. Specialization is no less interesting, though.

[...]
(= ADT's of rows. Classes of.)

> Let's go on. Each row of the table is physically located in the
> storage at some unique address. Even if it was not yet implemented in
> the RDBMS used as prototype, it is technically possible to provide
> invariability of this address during all row lifetime. The analogue of
> this address can be bookmarks, used in the modern RDBMS for rows
> addressing. The availability of unique and invariant row logical
> address allows us to implement the concept of pointers to the rows.

What for? Identity is not always required.

If you already introduced ADTs you can make referential ADTs as well. No need to introduce then as first-class objects, or limit to only rows.

That RDBMS have various kludges to achieve this, is just because their type systems have stayed frozen on the state-of-art of mid-70's...

> Network OODBMS
>
> Let continue the building. The table of ORDBMS is a bookmarks
> collection which refers to some rows. So many tables can contain
> reference to one row and the same instance of row can be contained by
> several tables. The row instance will be contained by the table, which
> corresponds to the row class. And the same row instance will be
> contained by the all base tables (= classes). Interface, which was
> implemented by the row (= columns + methods), corresponds to the class
> from which this instance was inherited. It is significant that this
> interface is not equivalent to interfaces of base tables. It is wider
> than base table's interfaces. However, this interface is compatible
> with interfaces of tables, which are containing this row. That is how
> we are getting to the concepts of interface, abstract classes and
> multiple inheritance of interfaces.

Yes, ADT /= the ADT of the class of.

[...]
(= a typed system is, well, typed)

> Lets examine data interfaces more elaborately. Interface implemented
> by the row consists of the definition of signatures of methods, which
> are applicable to this row, and also of the definition of fields (=
> columns) which were inherited by this row from base tables.

Forget first about tables. Tables are just unordered sets of rows. You can have different sorts of collections. Unordered set is just one case of.

When you want to derive, do it from a type (row). The type of the table is another thing. You can get it from some abstract collection type constrained by the class of rows (=the type of the element). The iterator (index) is another parameter.

Nothing in a type system should prevent you to derive from any type. Tables and rows are distinct types. Derivation from a row and from a table are two sufficiently different things.

> Tables are collections of instances and are not
> classical relations.

Table is an instance of a type which has relations as methods.

> So relational DBMS is
> just a special case of network DBMS.

That is quite obvious. Similarly, relational systems is a case of general case type systems. This alone is not yet an immediate advantage. The weakness of DBMS is its total inability to deal with constrained cases. Generalized cases are more rare, though also important. One difficult issue is how the type system you introduce would handle specialization. How constrains put on the types (like row) propagate across the system and the validity of corresponding methods is checked. This is a big issue independent on DBMS, which is only an application area of.

> The Object-oriented network knowledge base Cerebrum (OONKB) has the
> following features:
>
> It saves the current state of the graph of objects or the neural
> network in the OONKB between user sessions, including the current
> topology of objects so that it does not require the creation of
> objects again at the next run.
>
> It restricts the amount of memory used by the graph of objects or the
> neural network with larger quantities of class instances. The most
> frequently used objects are left in the RAM, the others are moved to
> the physical storage area and are loaded into the RAM upon demand. It
> unloads the rarely used objects when other objects are loaded to the
> RAM. The memory amount restriction allows not using the paging file so
> that it significantly increases the modeling performance of networks
> with larger quantities of class instances.
>
> The primary goal of this research is to create a virtual machine
> supporting free topology object-oriented network with up 2 billons of
> object instances within one physical storage area. This possibility is
> provided with implementation of the network object-oriented knowledge
> database. So that only a few class instances are in the RAM and the
> most objects are frozen in the file system.

Yes sure.

(I too stored fuzzy decision trees (actually graphs, DT is a legacy term) in RDBMS, which was quite nasty, I must admit. But it is not the issue with a persistency layer. The real problem is training in-situ. Though my system could train trees on training sets both resident in a persistent storage, that would twist the neck of any DBMS.)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de