Re: An object-oriented network DBMS from relational DBMS point of view
Date: Sat, 10 Mar 2007 04:02:24 GMT
Message-ID: <2ma4v2dcakqr4nmh6vfgcs7b0p3m0faahu_at_4ax.com>
On 9 Mar 2007 03:44:37 -0800, "Dmitry Shuklin" <shuklin_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.
If you follow the normalization rules for 3NF, you constrain the object structures and instances, how about that? And if you don't, then you give up the ability to run SQL efficiently, or at all, against the database.
>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.
Vtbl sucks, do something dynamic like python.
>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.
Factoring into 3NF is an alternative to specialization, you have the pattern of a base table ANIMAL with specialization annexes in tables like REPTILE and MAMMAL, an entity always has an ANIMAL base record and either one or the other table records, linked by a foreign key. Well, OK, then specialization can be supported and INTEPRETED as a set of tables under this pattern.
>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.
And is considered a kluge.
>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.
Only at the cost of constraining the ODBMS.
>Network OODBMS
(skipped)
>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.
That's not news, that an unconstrained description has constrained grammers as a subset, that type 0 grammar has type 1,2,3 grammars as "special cases", but the general case does not have some of the properties of its simplified, special cases. See: fallacy of composition. Just because this baseball is red, does not mean that the set of all baseballs is red. If you want a red baseball, you have to stay within the constrained subset. To generalize from a red baseball to a set of red-or-blue baseballs, is not much of a leap.
...
>I will be very appreciated for your feedback. Thank You for reading.
>
>WBR, Dmitry Shuklin, PhD, Ukraine
J. Received on Sat Mar 10 2007 - 05:02:24 CET