Re: Object support in the relational model??

"George Weer" <none_at_none.com> wrote in message news:actl56$sdo72$1_at_ID-116287.news.dfncis.de...
> Are you saying that to use the properties of objects that is polymorhism,
> inheritance, adt's methods etc
> mean that any referential integrity is jepardised? (im thinking mainly of
> inheritance) but through inheritance with adts for example defining a
> person as a class and a child as a person doesnt integrity become easier
to
> manage? sure there would be some grey water relating a child to a car
> becuase a child would interit all of those properties of a person but
thats
> the beauty of OO.

There's nothing wrong with inheritance per se, except that the details of inheritance models vary widely among different languages. Date and Darwen, in "Foundation for Future Database Systems: The Third Manifesto", devise a rigorous data model of inheritance that is compatible with relational theory, but unfortunately it does not map directly to any language that I'm familiar with (although it has some similarities).

The most basic mistake made by most OODB approaches is to treat relations as classes and rows as objects. You lose a lot if this is your only view of the database -- namely all of the ad-hoc querying capability that is the primary strength of the relational model. My experience convinces me that this is a huge loss that tends to produce performance problems, and a less flexible view of the database. Views based on application-defined queries let you focus on just the data that you need -- and those views should be updatable, because performance counts for database updates, too.

But as soon as you can update the database by bypassing OO classes that you've wrapped around relations, then you can no longer rely on encapsulating critical database constraints in those objects. It is crucial to data sanity and maintainability that there be no way to bypass database constraint logic.

Note that I am *not* rejecting the use of objects to represent data in the database. I'm primarily a C++ programmer. As I see it, it's perfectly valid to design classes to represent entities stored in the database. You could for instance have constructors that takes a reference to your database and a key, which then load the data into the object. You can then code whatever conveniences you like into the interface and implementation of your classes. But these classes should not *replace* any part of the logical database schema (where the concept of 'schema' database constraints).

> im sorry i just cant see the problem.

You might not see it unless you understand the theoretical relational model pretty well and compare it to whatever object model you're partial to. It also helps to study the history of relational database theory, to see why it came about and what problems it solves -- and what problems OODBMS's re-introduce. I'm not an expert on the subject myself, but I'm thoroughly convinced of the basic merits of Date & Darwen's position.

> i take it this is the third manifesto:
>
>
http://216.239.51.100/search?q=cache:WGirvC26ETYC:www.acm.org/sigmod/record/
> issues/9503/manifesto.ps&hl=en&ie=UTF8

Yes, that's it, in its terse form. The book is large and explains in detail the reasoning behind it. It also describes a simple language called Tutorial D, for illustrative purposes. (This language is also used in Date's tutorial book, "An Introduction to Database Systems", mentioned earlier by Jan.)

>
> "Carl Rosenberger" <carl_at_db4o.com> wrote in message
> news:acthbt$3q4$06$1_at_news.t-online.com...
> > Dan Muller wrote:
> > > But usual OODB practice is to treat
> > > relations as classes, which really obscures the entire relational
model
> and
> > > hides its most useful features from application programmers. Coupled
> with
> > > the practice of moving database constraint logic out of the database
> system
> > > and into the objects, this approach can be a disaster. (That's another
> > > unintended invitation to a flamefest, btw. :> )
> >
> > Indeed. :-)
> >
> > I could answer:
> > "Moving object business logic from objects to the database
> > usually ends up in a disaster."
> > (please ignore)
> >
> > A more useful answer:
> > Maybe we are still missing the right approach in our
> > object-oriented programming languages, as we know them
> > today. Indeed it is very difficult to come up with a
> > design, that lasts to be reused with multiple different
> > applications.

I think most mainstream languages could benefit from good, built-in syntax supporting the relational model directly. Math is ubiquitous, and supported by built-in syntax -- and database programming is also ubiquitous, so why shouldn't it get the same treatment?

Of course, the ability to easily store objects of user-defined classes, with inheritance, as field values in commercial DBMS's would go a long way to satisfying the needs of many OO programmers. (Some DBMS's have taken steps in this direction, I think, but unfortunately not the ones that I have to use.)

> > Maybe inheritance is the wrong approach and we need a
> > more loosely coupled system of dynamic delegates.
> > (Tables and relations? :-) )

I'm not exactly sure what you mean by "dynamic delegates", but it sounds interesting. :-)

I find Date & Darwen's model of inheritance pretty fascinating, and well defined. There *are* some loose ends in it that I'm investigating as time allows.

In general, though, after years of being an OOP advocate and practitioner, I'm quite dismayed by how it OO designs get applied to *everything*. It's just one useful programming paradigm among many. That's one reason I still like C++, warts and all.

To really bend your brain a bit around some other programming paradigms, take a long look at the programming language Oz (http://www.mozart-oz.org). Received on Mon May 27 2002 - 18:49:02 CEST