A look at object-oriented network DBMS from the point of view of relational database DBMS vs RDBMS

Naive ORDBMS

Consider building an abstract object-oriented DBMS, taking the relational DBMS as a starting point. Let rows in tables be instances of classes described by table headers. All rows of the table will be instances of this class. In this case, the table column will correspond to the field of a certain class, the value of the row field in the table will correspond to the value of the field of the class instance. This first iteration of developing an OOSUBD already allows working with RDBs in terms of classes, instances, values ​​of instance fields. Up to a full-fledged OO system, there are not enough methods, overriding virtual methods, inheritance and encapsulation. Nevertheless, it is obvious that no advantages of RDBMS in this interpretation of the ORDBMS are lost.

Object-relational DBMS

Moving on. Let us define methods that implicitly take as a parameter a row of one particular table. Such methods can be considered as methods of a class-table operating with data of class instances (rows of tables). We add a hidden field to each table in which we will store the identifier of the table of such functions (vtbl). Now, by analogy with OOP, it is possible to enter a single inheritance. So a table that inherits a table inherits the columns of this table, or the same thing inherits the fields of a class. Additionally, the class interface defined in the base table is inherited. The presence of the identifier of the table of virtual methods allows you to implement virtual methods in such a database. Calling a method for a row will consist in determining the table of virtual functions by the identifier of such a table and then in searching and invoking the implementation of the method by its name in the table of virtual methods. The base table will contain all instances of classes inherited from this table. The presence of vtbl will allow you to call the implementation of overridden methods defined in the derived tables on the rows included in the base table. So, in the developed abstract DBMS there is support for the concept of inheritance and polymorphism. It is also clear that the addition of this feature has retained all the existing capabilities of the RDBMS.

Encapsulation is implemented in the developed DBMS by using VIEWs. VIEWs allow you to protect some table fields from direct access, while providing access to the class interface due to the vtbl identifier in each row.

Note that such an implementation of OO ideas in an RDBMS environment is not new - Postgree SQL can be cited as an example of an already existing implementation.

We continue. Each row of the table is physically located in the repository at some unique address. Even if it is not yet implemented in the RDBMS used as a prototype, it is technically possible to ensure that this address is immutable for the entire lifetime of the string corresponding to this address. An analogue of such an address can serve as bookmarks used in modern RDBMS for addressing strings. The presence of a unique and timeless logical address of a string allows us to implement the concept of pointers to strings and enter the type of pointer to a string object. In conjunction with the previously developed concepts of inheritance, polymorphism and encapsulation, this makes the developed abstract OOSUBD a full-featured OO programming system.

It should be noted that the idea of ​​pointers to lines is also not new and has long been implemented in such a well-known RDBMS as Oracle.

Considered extensions of the RDBMS left the existing possibilities unaffected. As before, the developed abstract ORDBMS includes RDBMS as a special case.

Network OOSUBD

We continue to develop. In the developed ORDBMS, the tables are collections of bookmarks pointing to some rows. The same instance of a row can be in several tables at once. One instance in the table, the class instance of which is the given row and one instance of this row in all the base class tables. The interface supported by the string (columns + methods) corresponds to the class of which this string is an instance. It is important that this interface is not equivalent to the interfaces of the base tables. It is broader than the base table interfaces; however, this interface is compatible with the interface of the tables to which this row belongs. So smoothly we come to the concept of interface, abstract classes and multiple inheritance of interfaces that have been used in OOP for a long time.

This is a very important step, since now the possibility of a certain row belonging to a certain table is determined by the interface compatibility of this row with the interface defined for a certain table. This allows you to take the next step — to treat tables not as physical storage for rows, but as collections of instances of some classes whose interfaces are compatible with the interfaces defined for these collections. Note the potential independence of the interface defined for the table and the interface defined for the row. Despite the fact that the developed system, in some particular case, can function in the same way as the RDBMS with which the development was started, the tables in the developed DBMS are no longer relations in the classical sense. The rows of such collection tables are no longer a subset of the Cartesian product of the definition of an interface in the region of possible values ​​of the interface. Yes, the collections in the developed system, if desired, can be interpreted as a subset of the Cartesian product of defining the interface to the area of ​​possible interface values. This makes the RDBMS a special case developed. But, given the polymorphism of instance copies that provide access to their internal structures through public interfaces in such a DBMS, it becomes possible to share some interfaces (columns and / or methods) by several tables-collections. Such tables can no longer be considered classical relations, since when changing fields of rows through a single table, the fields of the same rows in all other tables containing modified rows will also be changed.

Consider the interface in more detail. A string interface consists of definitions of method signatures that are applicable to a given string, as well as definitions of column fields inherited by this string. Previously, by allowing the possibility of table inheritance, the possibility was created of simultaneously including the same column-fields in different tables, which ensured polymorphism of rows. As a consequence, a separate line that inherits a set of interfaces has values ​​for the columns described in all inherited interfaces. However, only that subset of values ​​can be accessed through a certain table, which is the intersection of the set of all columns inherited by a given row and the set of all columns defined as an interface for a given collection table. What then is the string? A string is a subset of the Cartesian product of all possible columns for all possible values ​​of these columns. Here an interesting and unexpected result is obtained, despite the fact that the developed abstract ORDBMS includes RDBMS as a special case, however, not a table but a row of a table is a relation .

Results

Let's sum up. During the development process, no RDBMS features were removed from the developed abstract database management system. In the process of developing new features just added. Developed ORDBMS includes RDBMS as a special case. Instance lines inherit a significant number of columns, publishing only a few through table interfaces. Both rows and columns can simultaneously be included in several different tables. Tables are collections of instances of objects and are no longer classic relations. We can say that class-row instances are nodes, the fields of these instances are node attributes. Including fields of the reference type store pointers to other nodes. The nodes themselves can have millions of attributes, publishing only a few through the collections interface. Attributes can have both scalar values ​​and links to other nodes, thereby forming a network. Inheritance, polymorphism and encapsulation within VIEWs are provided.

So, as a result of this development, an abstract object-oriented network database management system was obtained, which includes all the capabilities of a relational DBMS as a special case.

The ability to effectively implement such an object-oriented network database management system requires further research.