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

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
here
http://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

On Mar 9, 12:44 pm, "Dmitry Shuklin" <shuk...{}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.

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

A show stopper. A perfect example on how to write a lot a say very
little.

On 9 Mar 2007 03:44:37 -0800, "Dmitry Shuklin" <shuklin{}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.

But if those pointers do not follow normalization rules, you lose the
underlying RDBMS. Is anything lost by using keys?

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

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

"Dmitry Shuklin" <shuklin{}bk.ru> wrote in message
news:1173440677.467627.35460{}q40g2000cwq.googlegr oups.com...

[snip]

> Note, that the concept of references to the rows is also not new and
> was embodied long ago in such famous RDBMS, as Oracle.

[snip]

It's not only not new, but also not relational. Oracle's claims to be
relational. Many database builders, myself included, have designed
relational databases, and implemented using Oracle. However, some of the
features offered by Oracle are not relational. This is one of them.

Anyone relying on using a reference to a row as implicitly referencing the
data contained in the row is suing the graph model of data, and not the
relational model of data. It seems to me that the rest of this topic
overlooks this simple point.

On Mar 10, 6:15 am, "Walt" <wami...{}verizon.net> wrote:
> "Dmitry Shuklin" <shuk...{}bk.ru> wrote in message
>
> news:1173440677.467627.35460{}q40g2000cwq.googlegr oups.com...
>
> [snip]
>
> > Note, that the concept of references to the rows is also not new and
> > was embodied long ago in such famous RDBMS, as Oracle.
>
> [snip]
>
> It's not only not new, but also not relational.

It's not only not relational, but also not necessary.

Every relation, by definition, has a set of attributes
whose values are unique, and which can therefore
be used in relational expressions to uniquely identify
a row. That's all you'd get out of a pointer. Further,
by requiring the unnecessary pointer, you constrain
implementations unnecessarily.


> Anyone relying on using a reference to a row as implicitly referencing the
> data contained in the row is suing the graph model of data, and not the
> relational model of data.

Hmmm. Various of us have pondered many different ways to
help educate the programming public about the value of the
relational model, but I don't think anyone has ever proposed
involving the courts before. But as an American I love the idea!
Let us sue other data models for false advertising.


Marshall

PS. Sorry.

"Marshall" <marshall.spight{}> wrote in message
news:1173540150.918109.138900{}p10g2000cwp.googleg roups.com...
> On Mar 10, 6:15 am, "Walt" <wami...{}verizon.net> wrote:
> > "Dmitry Shuklin" <shuk...{}bk.ru> wrote in message
> >
> > news:1173440677.467627.35460{}q40g2000cwq.googlegr oups.com...
> >
> > [snip]
> >
> > > Note, that the concept of references to the rows is also not new and
> > > was embodied long ago in such famous RDBMS, as Oracle.
> >
> > [snip]
> >
> > It's not only not new, but also not relational.
>
> It's not only not relational, but also not necessary.
>
> Every relation, by definition, has a set of attributes
> whose values are unique, and which can therefore
> be used in relational expressions to uniquely identify
> a row. That's all you'd get out of a pointer. Further,
> by requiring the unnecessary pointer, you constrain
> implementations unnecessarily.
>
>
> > Anyone relying on using a reference to a row as implicitly referencing
the
> > data contained in the row is suing the graph model of data, and not the
> > relational model of data.
>
> Hmmm. Various of us have pondered many different ways to
> help educate the programming public about the value of the
> relational model, but I don't think anyone has ever proposed
> involving the courts before. But as an American I love the idea!
> Let us sue other data models for false advertising.
>
>
> Marshall
>
> PS. Sorry.
>

My bad. Typo. "suing" should be "using".

On Mar 10, 7:54 am, "Walt" <wami...{}verizon.net> wrote:
> "Marshall" <marshall.spi...{}> wrote in message
>
> news:1173540150.918109.138900{}p10g2000cwp.googleg roups.com...
>
>
>
> > On Mar 10, 6:15 am, "Walt" <wami...{}verizon.net> wrote:
> > > "Dmitry Shuklin" <shuk...{}bk.ru> wrote in message
>
> > >news:1173440677.467627.35460{}q40g2000cwq.googleg roups.com...
>
> > > [snip]
>
> > > > Note, that the concept of references to the rows is also not new and
> > > > was embodied long ago in such famous RDBMS, as Oracle.
>
> > > [snip]
>
> > > It's not only not new, but also not relational.
>
> > It's not only not relational, but also not necessary.
>
> > Every relation, by definition, has a set of attributes
> > whose values are unique, and which can therefore
> > be used in relational expressions to uniquely identify
> > a row. That's all you'd get out of a pointer. Further,
> > by requiring the unnecessary pointer, you constrain
> > implementations unnecessarily.
>
> > > Anyone relying on using a reference to a row as implicitly referencing
> the
> > > data contained in the row is suing the graph model of data, and not the
> > > relational model of data.
>
> > Hmmm. Various of us have pondered many different ways to
> > help educate the programming public about the value of the
> > relational model, but I don't think anyone has ever proposed
> > involving the courts before. But as an American I love the idea!
> > Let us sue other data models for false advertising.
>
> > Marshall
>
> > PS. Sorry.
>
> My bad. Typo. "suing" should be "using".

Walt,

You should know something about me: if there is a cheap
laugh to be had, I'm there with bells on. It was clear
it was a typo, however I found the idea quite appealing!
So I ran with it. The only thing that gave me hesitation
was that it might appear to be at your expense, so
I put in an explicit "sorry."


Marshall

> "Dmitry Shuklin" <shuk...{}bk.ru> wrote in message
> Note, that the concept of references to the rows is also not new and
> was embodied long ago in such famous RDBMS, as Oracle.

I worry that this is yet another system that focuses on technology
instead of the information part of IT, and which doesn't understand
what data is (data = given fact = proposition).

Considering two bits of data:
- Aristotle is a human
- A human is mortal

Now that seems fine to me. Two different bits of data, with different
structures (and hence different predication). A join also gives me
"Aristotle is mortal". All is good, and I certainly don't need any
"human object" inheritance - my foreign key indicates that connection
for me.

So you want to add 'row references' so that the real world
propositions to be recorded has become.
- Row A says Aristotle is a Row Z
- Row Z says a Human is a mortal.

This would add nothing to the data, it has a superfluous extra
addressing mechanism that has to be navigated along, and propositions
are no longer directly match those recorded in the real world or how
we communicate. This is not good.

I also find the overall conclusion to be back to front. Objects are
very constrained subsets of general relationships, not the other way
around. Regards, J.