Bases de datos relacionales y diseño Orientado a Objetos

Como periódicamente sucede, el dos de noviembre comenzó otro debate sobre el mapeo de datos (persistencia) entre RDB y OO en Google Groups. Como siempre, a medida que se desarrollan, aumenta su interés
El planteo inicial es muy simple:

I am wanting to create an application that is for time management and I
want most of the data to be on my webservers database, but in creating
my OO 'client' I really want to create a good design.
(...) how do people go about designing and storing the data once it has been
retrieved from the database? Do you keep it as records, or when you get
the data, do you create collections of objects which represent the data
which you have obtained from your database?

Frans Bouma, defensor de Object Role Modeling (ORM):

It's IMHO always a good idea to start with a design for your abstract
datamodel. This is a level above E/R, so it can have inheritance etc.
For the technique, please check http://www.orm.net (Object Role
Modelling, formely known as NIAM)
This gives you a good idea which entities are identifyable within your system, their attributes and their relations with other entities. Once you've modelled this out, you can go in several directions: you can pick this model and turn it into a domain model (thus a class model) and simply get an o/r mapper of your liking and store the entities into a physical datamodel matching your domain model.
You can also pick it up and create a physical data model in a database with it and use it as well for your entity classes, which are then consumed by your application logic.

Lahman propone:

(...) when you know what object attributes need to be persisted, define a suitable Data Model for the database. The RDB Data Model and the solution's Class Model will typically be different for non-CRUD/USER applications because they need to be optimized differently.
Finally, provide a subsystem for the application that maps between the two views. The interface to the DB Access subsystem is defined by the time management solution's need to obtain and store data to initialize and save objects. The DB Access subsystem then maps those requests into SQL queries or whatever that are appropriate for the Data Model.
Typically, on the solution side one will have factory objects to instantiate the solution's objects. Those factory objects will request the appropriate data from the DB Access to do the instantiation and initialization. Conversely, when it is time to save attributes from the solution objects, some object extracts the relevant attribute values sends them off to the DB Access subsystem to be stored.

Lahman desarrolla más su planteo acotando una respuesta de Andy:

>>Solving a time management problem is a quite different subject matter
>>than persisting the relevant data. Solve the time management problem in
>>you application first. Then, when you know what object attributes need
>>to be persisted, define a suitable Data Model for the database. The RDB
>>Data Model and the solution's Class Model will typically be different
>>for non-CRUD/USER applications because they need to be optimized
>>differently.

> I agree with the solution, but I really think one is talking about a
> Persistant Storage Engine (PSE) rather than perhaps an OO database. A
> PSE can often be implemented using an object schema or RDB model.

That's fine. In fact, it is one of the advantages of the approach I proposed. It really doesn't matter to the time management problem solution whether the data is persisted in an RDB, an OODB, flat files, or clay tablets. The persistence mechanisms are fully encapsulated in the DB Access subsystem. So one could regard the DB Access subsystem I proposed as being a PSE from the perspective of the problem solution.
Among other things, that allows one to change one's mind about how the data is stored without having to touch the problem solution in any way. All one needs to do is replace the DB Access subsystem underneath the same subsystem interface.
Another advantage is reuse. Once one starts to abstract a DB Access subsystem for, say, the RDB paradigm, one quickly realizes that the abstractions are things like Schema, Table, Tuple, Query, etc. that are quite generic. So one can reuse the DB Access subsystem across applications with relatively little extra effort. (All one needs is an identity mapping between the problem solution and the RDB artifacts, which is easily described in configuration data for a particular application.) In fact, RAD IDEs are based upon exactly that sort of problem-independent reuse.
People tend to discount swapping paradigms as an advantage because RDBs have dominated for 2+ decades. However, I've personally watched the paradigm for persistence changing from paper tape/punched cards to flat sequential disk to ISAM to CODASYL to RDBs to OODBs (in at least some niches). Each shift required major surgery for huge amounts of legacy code because the persistence mechanisms were not encapsulated. And each paradigm shift was regarded as the last possible -- until some new technology appeared. So I wouldn't bet against another paradigm shift in the future just because RDBs have been around awhile.
I would also argue that modern RDB or OODB engines are not as portable as the vendors would have us believe. Each vendor has their own SQL extensions or whatever. And they each have their own unique quirks that need to be addressed in the way the data is accessed for optimal performance. So even when one just changes vendors within the RDB paradigm or the OODB paradigm, one may have to do some tweaking and that should be isolated from the problem solution code.

La discusión suele extenderse...Si la relación entre bases de datos relacionales y diseño orientado a objetos le afecta, es de interés agendarse el link.