Objects in DB

About object-relational mappers:

Let there is an Object. When stored in a DB it acquires ID (primary
key in DB terminology).

Object+ID should be a derived object? (adding new field DB to Object)

Any comments and ideas?

On Sat, 11 Oct 2008 09:57:30 -0700 (PDT), Victor Porton wrote:

> About object-relational mappers:
>
> Let there is an Object. When stored in a DB it acquires ID (primary
> key in DB terminology).

> Object+ID should be a derived object? (adding new field DB to Object)

There are two objects, the original object of some type T and the key of
some type ID. Resulting DB table is a mapping ID -> T or equivalently a set
of pairs (ID, T). These pairs have a third type.

In DB terms the pair is not derived from T, because for DBMS row does not
automatically inherit operations of the column T. Row is merely a container
type. In OO containment and inheritance are separate concepts, so I don't
see obvious reasons why the pair must inherit to T.

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

On Oct 12, 2:49*pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sat, 11 Oct 2008 09:57:30 -0700 (PDT), Victor Porton wrote:
> > About object-relational mappers:
>
> > Let there is an Object. When stored in a DB it acquires ID (primary
> > key in DB terminology).
> > Object+ID should be a derived object? (adding new field DB to Object)
>
> There are two objects, the original object of some type T and the key of
> some type ID. Resulting DB table is a mapping ID -> T or equivalently a set
> of pairs (ID, T). These pairs have a third type.
>
> In DB terms the pair is not derived from T, because for DBMS row does not
> automatically inherit operations of the column T. Row is merely a container
> type. In OO containment and inheritance are separate concepts, so I don't
> see obvious reasons why the pair must inherit to T.

Your comments are probably wise. But how we would implement real
objects. Do you suggest that for pairs (ID, T) we should not introduce
a new class (or template/generic) and threat it just as a pair of
separate objects?

On Sun, 12 Oct 2008 06:51:28 -0700 (PDT), Victor Porton wrote:

> On Oct 12, 2:49*pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Sat, 11 Oct 2008 09:57:30 -0700 (PDT), Victor Porton wrote:
>>> About object-relational mappers:
>>
>>> Let there is an Object. When stored in a DB it acquires ID (primary
>>> key in DB terminology).
>>> Object+ID should be a derived object? (adding new field DB to Object)
>>
>> There are two objects, the original object of some type T and the key of
>> some type ID. Resulting DB table is a mapping ID -> T or equivalently a set
>> of pairs (ID, T). These pairs have a third type.
>>
>> In DB terms the pair is not derived from T, because for DBMS row does not
>> automatically inherit operations of the column T. Row is merely a container
>> type. In OO containment and inheritance are separate concepts, so I don't
>> see obvious reasons why the pair must inherit to T.
>
> Your comments are probably wise. But how we would implement real
> objects. Do you suggest that for pairs (ID, T) we should not introduce
> a new class (or template/generic) and threat it just as a pair of
> separate objects?

I would create a class for each type, this includes one for the pair type.
But this is rather a property of the programming language. I would not call
a fully OOPL any language that does not have classes for almost all types.
So when there is no class of int, it is not 100% OO. I.e. Ada, C++, Java do
not qualify. (There could be exceptions for the procedural types and types
of classes themselves, but that is another story.)

But I guess you meant in first place a type. I also suppose that "separate"
does not address reference semantics. The pair may contain reference
objects that would change nothing in the picture.

When you consider as "separate" logically related objects which do not
constitute a new object (the pair, and thus the type of such pairs). Then I
am against that. I believe that in OO spirit a relation like this should
always be represented by an object, and thus be described by the type of. A
class of such types follows, not necessarily contained in the class of T.

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

On Oct 12, 4:41*pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> But this is rather a property of the programming language. I would not call
> a fully OOPL any language that does not have classes for almost all types..
> So when there is no class of int, it is not 100% OO. I.e. Ada, C++, Java do
> not qualify. (There could be exceptions for the procedural types and types
> of classes themselves, but that is another story.)

I do not agree about Ada.

Ada 95 private types (rough equivalent of C++ classes) are
indistinguishable from basic types (such as Integer) in their external
semantics.

It is easy to introduce our own private type which would behave almost
the same as the built-in Integer type.

Also built-in types in Ada 95 are not tagged and cannot serve a base
for type extension (inheritance) but the same applies to simple (non-
tagged) private types.

Well, there is a little difference that we cannot define new
attributes for private types.

Victor Porton wrote:

> About object-relational mappers:

> Let there is an Object. When stored in a DB it acquires ID (primary
> key in DB terminology).

> Object+ID should be a derived object? (adding new field DB to Object)

> Any comments and ideas?

1. This concept has been around in OOP since day 1.

Object+ID is known as a *reference* .
Object references can be compared with each other (equality) .
The equality op hides the implementation details of identity (such as RDBMS
key ids, memory location etc) .


2. Object+ID should be *substitutable* for Object.

How you implement this depends on your prog lang env (type checking/
substitutability regimes, C++ "smart pointers" etc) .


Regards,
Steven Perryman

Responding to Porton...

> Let there is an Object. When stored in a DB it acquires ID (primary
> key in DB terminology).
>
> Object+ID should be a derived object? (adding new field DB to Object)

Tuples in an RDB table and objects in an application are quite different
things. The most obvious difference is behavior; only the knowledge
attributes of an object are persisted in an RDB. Another difference is
that RDB tuples *require* explicit data fields for identity while
objects in an application do not.

However, an OO Class Model shares the same relational model as the RDB
(the more general one from set theory, not Codd's relational data
model). The Class Model is even normalized in much the same was as an
RDB schema. So there exists an unambiguous *mapping* between the OO
Class Model and the RDB Data Model because both are rigorously defined
with respect to a common problem domain.

To facilitate that mapping when objects need to be persisted it is often
*convenient* to provide an attribute in the application object that is
the RDB tuple identity. But there is no notion of either the tuple or
the object being derived from one another directly. [Outside of
CRUD/USER environments, classes and RDB tables typically do not map 1:1
to each other. In fact, even knowledge attributes of objects sometimes
do not map 1:1 to tuple fields.]

Note that for persistence all you need to do is transfer data from the
object attributes to the corresponding RDB tuple fields. Essentially
that is just message encoding. So one does not see a "DB object" in an
OO application. (One does see things like DAO objects in the RAD
infrastructures for CRUD/USER processing, but that's no OO development.)
Instead, when it is time to persist the object, some method extracts the
object's attributes and constructs a SQL query string and a dataset
(message data packet) that is then sent to the DBMS.



--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

On Sun, 12 Oct 2008 09:12:25 -0700 (PDT), Victor Porton wrote:

> On Oct 12, 4:41*pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> But this is rather a property of the programming language. I would not call
>> a fully OOPL any language that does not have classes for almost all types.
>> So when there is no class of int, it is not 100% OO. I.e. Ada, C++, Java do
>> not qualify. (There could be exceptions for the procedural types and types
>> of classes themselves, but that is another story.)
>
> I do not agree about Ada.
>
> Ada 95 private types (rough equivalent of C++ classes) are
> indistinguishable from basic types (such as Integer) in their external
> semantics.
>
> It is easy to introduce our own private type which would behave almost
> the same as the built-in Integer type.

Right. With noticeable exceptions of integer type attributes and ability to
pass it where a formal integer type expected (range <> etc). This is
because there is no common class.

> Also built-in types in Ada 95 are not tagged and cannot serve a base
> for type extension (inheritance) but the same applies to simple (non-
> tagged) private types.

Yes, and this is the problem. Private and built-in types should have had
classes like tagged types do. Of course, with the difference that the type
tag would not be a part of the value. So Boolean'Size would remain 1
(differently to Boolean'Class'Size, which would be 64 or so).

> Well, there is a little difference that we cannot define new
> attributes for private types.

They are ADTs, but not 100% OO. You can derive from Integer in Ada, but not
all options are on the table.

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