Re: oodb <-> rdb

>>>>> On 27 Oct 92 19:18:03 GMT, Dulan.Weerasinha_at_brunel.ac.uk (Dulan >>>>> Weerasinha) said:  

> Given an object, what needs to be considered/done for an object to be
> translated to a relation (or a set of relations)? Similarly, given a
> relation (or a set of relations), what do you need to consider when
> re-creating the corresponding object? What issues need to be considered
> during the translation process? How, if at all possible, is object
> behaviour captured in the rel. model? What rules do you have to follow or
> what heuristics do you have to apply?

Hmmm, where to begin this...

1. A relational database system is one implementation of an object oriented database system. In other words, you can think of an RDBMS as an OODBMS where objects such as Database, Table, Tuple, Attribute, Projection, Join, etc. have been implemented and no user-defined objects are allowed. Therefore, try not to expect more out of the database system than these objects allow.
2. One area to address in translating objects to relations is the question of "object identification". In a relational model, tables can have primary keys that come from different domains. In an object model, the ID of all objects *should* be from one domain (it makes changing the hierarchical model easier). In C++ in-memory object models, this domain is usually a memory address. The first issue you'll want to address is, therefore, what does the object PersistentID look like and what are its capabilities?
3. Object models talk about relationships like "is-a", "contains", "is-like-a", and so on. These relationships are certainly modellable in an RDBMS through foreign keys. Try to keep the relational model and the object model in synch with respect to these issues (ie. if the object is a derivative of a base class, then the database should show this via a parent-child relationship). It will make issues like changing inheritance hierarchies much easier to deal with.
4. Because of #3, instantiating a full object (a child with its base classes) may entail many database queries (or one large join) as you instantiate each part of the object. This is a tradeoff between flexibility of the model and performance. Ultimately, though, with this model, you will probably find that the objects your applications use will be very targetted toward the information they need from the database (ie. they will select only what they need).
5. Depending on the object oriented environment you use, you probably cannot store object behaviours in the database. For the most part, your applications will be dealing with the database through some sort of object layer in your application, so no one will really know that the behaviour is not stored in the database. An issue, though, will be users of the RDBMS who are not using your object interface (can they mess up your objects?).
6. Constraints/triggers should be used to try to get as much of the business rules about your data into the database. This will certainly protect you against those database users who are not using your object interface and from errant objects. An issue, though, is what is the definition of NULL in the object world (you need NULL in order to save objects with constraints that haven't been fully satisfied yet)?

This ought to be enough to get you going... ;-)

--
====================================================================
David Masterson					Consilium, Inc.
(415) 691-6311					640 Clyde Ct.
davidm_at_consilium.com				Mtn. View, CA  94043
====================================================================
"The crux... is that the vast majority of the mass of the universe seems to be
 missing."
-- William J. Broad