From: Rick DeNatale Date: 2007-04-05T06:37:36+09:00 Subject: Re: Object/Relational Mapping is the Vietnam of Computer Sci On 3/31/07, Austin Ziegler wrote: > On 3/31/07, Rick DeNatale wrote: > > On 3/31/07, Clifford Heath 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/