Re: Object/Relational Mapping is the Vietnam of Computer Sci

On 3/31/07, Austin Ziegler <[e-mail]> wrote:
> On 3/31/07, Rick DeNatale <[e-mail]> wrote:
> > On 3/31/07, Clifford Heath <[e-mail]> wrote:
> >> Yes. Relations are the right way to store data, objects are the right
> >> way to manipulate them, but facts are the right way to conceive of
> >> them, and hence to query them. Both ER and OO schemata are
> >> absorptions of fact-based schemata to suit the physical
> >> characteristics of disk storage and RAM storage/allocation
> >> respectively. IOW they're both derived, to some extent contrived, for
> >> different purposes. Neither can ever be the "one true way".
> > And there's a fundamental tension between the driving ideas of a
> > database and object oriented programming.
>
> I don't think that there's a fundamental tension, but that's just me.
>
> > Databases come from a philosophy of separating data and it's
> > representation from the programs which operate on it. In the case of
> > relational databases, that representation is encapsulated behind an
> > interface defined by SQl.
>
> This is not correct. Fabian Pascal would have a field day with this
> statement. Databases come from a formalization of the need to store
> data.

I think you misinterpret my point.

>  Hierarchical databases (and, to a degree, object databases) store
> the data in the same way that the programs which manipulate the data
> represent the data.

I don't believe that this is, in general, true. but let me get back to that.

> Relational databases come from the realisation that more than one
> program needs to work with a given set of data, you don't want to store
> more than one copy of any given datum, and there should be a formal way
> of modelling such things. Thus, you have the Relational Model of Data --
> which, as I have mentioned several times, is a model that represents
> tuples, attributes, and relations that can be queried using relational
> algebra.

I'll refer you to  Chris Dates 1975 book "An Introduction to Database
Systems." Which was the bible on database systems to folks of my
generation. Actually I'm looking at the third edition from 1981.  The
book covers the relational (using System R as the example),
hierarchical (using IMS/DB), and network (EBTG) approaches.

In the introduction, Date gives the driving reason for databases as
allowing enterprises to put their operational data under centralized
control. He gives a lengthy list of advantages from this reduction in
redundancy, reduction in inconsistency, data can be shared, standards
(various levels of enterprise standards, industry, national and
international), easier data interchange/migration, ability to apply
security restrictions, integrity maintenance, and the ability to
balance conflicting requirements.

These requirements lead to what Date calls an important goal of
database systems, 'data independence.'  This is the separation between
the database managment system and the applications which I was talking
about.  Data indepence allows applications to have different views of
the data, and to allow a DBA to change the storage structure and/or
access strategy without affecting applications.

The abstract model for this presented by Date is that the architecture
of the system has three levels, in internal storage level, an external
level (which comprises the individual views of the different
applications), and a conceptual level which provides a 'level of
indirection' between the two.  This conceptual level is what provides
the encapsulation/information hiding I alluded to.  The use of SQL as
the realization of the conceptual level for the relational approach
was just an example.

Maybe I'm just an old fuddy duddy, but this is what I learned as the
defining quality of a database system when I first encountered the
idea in the 1970s.

Object oriented databases back off just a bit from data independence
because they turn the conceptual level into a framework to be fleshed
out by the clients rather than sticking with a standard, and that's
the tension I'm talking about.

Now getting back to your statement:

>  Hierarchical databases (and, to a degree, object databases) store
> the data in the same way that the programs which manipulate the data
> represent the data.

This depends on the programs.  Some programs are written to look at
data hierarchically, or as a network.  Others aren't.  In fact the
vast majority of applications written when database systems were
introduced tended to work on sequential (usually sorted) data.  Back
then the ideas introduced by systems like IMS and CODASYL DBTG were
actually rather foreign and might be one reason why the relational
approach was widely adopted, the conceptual model looked more like an
extension and formalization of what application developers were
accustomed to back in those days.

It might be hard to see this, but for someone who lived through some
of the revolutions in information technology since the early 1970s,
it's evident.  I spent a good part of my career evangelizing
enterprise programmers about object-oriented technologies, so I know
how foreign what we take for granted these days was for the older
folks.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/