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

On Mar 9, 12:44 pm, "Dmitry Shuklin" <shuk..._at_bk.ru> wrote:
> Shuklin D.E.
>
> An object-oriented network DBMS from relational DBMS point of view
>
> Naive ORDBMS
>
> Lets examine the implementation of an abstract object-oriented DBMS.
> Lets take the relational DBMS as starting point. Rows in OODB tables
> will be an object instances. All table's rows will be instances of a
> class, which are corresponding to the table. Classes will be defined
> by table headings. In this case table column will conform to the field
> of the class. The value of the row field will conform to the value of
> the instance field. This first iteration of the ODBMS development
> allows us to work with DBMS in terms of classes, instances and values
> of instance fields. This OO system is still missing methods, virtual
> methods overriding, inheritance and encapsulation. Neverless, it is
> obvious, that no RDBMS values at that ORDBMS interpretation were lost.
>
> 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.
> Some methods can be associated to the row (= instance). An interface
> of the class, which was determined in the basic table, is inherited by
> derived tables. Each row method should implicitly receive one row as
> hidden parameter (= this). These row methods can be regarded as class
> (= table) methods. These methods will be executed on data stored in
> the row of table (= class instance or this). Identifiers of all
> virtual methods of single class can be stored in some table known as
> vtbl. Lets add hidden field (= column) with identifier of vtbl to each
> data table. The vtbl identifier stored in hidden field in each row
> allows to implementing overriding of virtual methods. The call of
> virtual method of some row will be implemented as searching of the
> virtual methods table by the vtbl identifier stored in this row and
> then searching and calling the implementation of the method by its
> name in the virtual methods table. The availability of vtbl allows to
> invocate overridden methods, defined in the derived tables by rows
> contained in the base table. So, in the developed abstract DBMS
> support of inheritance and polymorphism concepts are presented. Also
> it is obvious that the addition of such capacity uphold all present
> RDBMS capacities.
>
> The encapsulation is implemented in the developed DBMS by VIEWs using.
> VIEW allows protect some table fields from direct access, providing
> the access to fields interface. Due to the availability of vtbl
> identifier in each row the VIEW also provides access to methods
> interface.
>
> As is easy to see, such implementation of OOP concepts in the RDBMS is
> not new. PostgreeSQL is an example of already existing implementation.
>
> 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.
> Previously it was developed concepts of inheritance, polymorphism and
> encapsulation. They are converting developed abstract ODDBMS to
> valuable OO programming system.
>
> Note, that the concept of references to the rows is also not new and
> was embodied long ago in such famous RDBMS, as Oracle.
>
> Neverless, it is obvious, that no RDBMS values at that ORDBMS
> interpretation were lost too. As before, developed abstract ORDBMS
> includes RDBMS as special case.
>
> 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.
>
> This is very important step, because now the possibility of the
> belonging of some row to some table is determined by compatibility of
> this row interface with interface fixed for some table. This gives a
> possibility to make next step - to consider tables to be not just
> physical storage for rows, but a collection of instances of some
> classes, which interfaces were compatible with interfaces determined
> for this collections. Lets draw your attention to potential
> independence of the interface, determined for the table from the
> interface, fixed for the row. Notwithstanding the fact that developed
> system in some special case can operate just as RDBMS, tables in the
> developed DBMS are not relations in classical meaning. Rows of these
> tables (= collections) are not a subset of Cartesian product of
> interface declaration to possible domain of the interface. Yes,
> collections at the developed system can be interpreted as a subset of
> Cartesian product of interface declaration to possible domain of the
> interface. This makes RDBMS to be special case of developed one. But,
> the polymorphism of instances (= rows), which provides the access to
> their internal structures through public interfaces caused in this
> DBMS interfaces sharing (= columns and/or methods) to many tables (=
> collections). These tables can't be considered as relations because
> the changes of row fields provided through one table caused changes in
> all other tables.
>
> 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. The
> possibility of the table inheritance causes the possibility of
> simultaneous ownership of the same columns (= fields) by different
> tables. As result, row (= object) instance has values for columns,
> which were described in all inherited interfaces. However, only that
> subset of values can be available through some table, which is an
> intersection of variety of all columns, which were inherited by row
> and the variety of all columns, fixed as the interface for the
> collection (= table). What is the row in this case? The row is the
> subset of Cartesian product of all possible columns by all possible
> values of these columns. Here interesting and unexpected result is
> obtained. Though the developed abstract ORDBMS included RDBMS as
> special case, the row is a relation instead of table.
>
> Resume
>
> During development no RDBMS capacities from the developed abstract
> DBMS were removed, but new capacities was only added to it. Developed
> ORDBMS includes RDBMS as special case. Rows are instances inheriting
> many columns, published only some columns through tables interface.
> Both rows and columns can be simultaneously placed into several
> different tables. Tables are collections of instances and are not
> classical relations. We could say that instances of classes (= rows)
> are nodes, fields of these instances are attributes of nodes. Fields
> of reference type holds pointers to other nodes. Nodes themselves can
> have millions of attributes, publishing only some attributes through
> interfaces of collections. Attributes can have both scalar values and
> references to other nodes, thus forming the net. So relational DBMS is
> just a special case of network DBMS.
>
> The possibility of effective implementation of this OODBMS is required
> for further research.
>
> Prototype of such network object oriented DBMS can be downloaded from
> herehttp://www.codeplex.com/Cerebrum.
>
> 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.
>
> I will be very appreciated for your feedback. Thank You for reading.
>
> WBR, Dmitry Shuklin, PhD, Ukraine

<<So relational DBMS is just a special case of network DBMS. >> A show stopper. Received on Fri Mar 09 2007 - 14:09:25 CET