Re: The Theoretical Foundations of the Relational Model

From: Clifford Heath <cjh_nospam_at_managesoft.com>
Date: Fri, 28 Jun 2002 13:03:28 +1000
Message-ID: <3D1BD200.77D91422_at_managesoft.com>


Bernard Peek wrote:
> Good point. OO and RM are maps, neither should be mistaken for the
> territory.

Actually they aren't even maps, but approaches to constructing maps.

To pursue the analogy, relational insists you shouldn't mark an object on the map until you know its exact lat/long, whereas OO allows you to mark it approximately. The drawback with OO that you might forget to go back and mark its exact position later so you get left with woolly, incomplete and inaccurate data. The drawback with the stricter approach is that things get incorrectly marked at an exact location, so you think the map is more accurate than it is. Sometimes one approach is better, sometimes the other. Generally I favour allowing woolly data as long as it's visibly untrustworthy, i.e. marked to indicate what degree of reliance may be placed on it.

> That shows my main objection to the OO model in its current form. Having
> defined a class called Cat it becomes necessary to redefine some members
> as Feline Cats and Canine Cats or possibly not cats at all.

Evolution occurs in all models. There are three main classes of evolutionary step:

* Adding new attributes/entities/relationships
* Migrating an attribute to become a new entity
* Refining classifications

The latter two are the difficult ones. An example where both may occur at once is in a genealogy system where "date of birth", "date of marriage" and "date of death" attributes migrate out into a new LifeEvent entity with three subclasses.

> Another good point. The RM assumes that there is a set of attributes
> which always map 1:1 with the objects they are describing. OO looks as
> if it should be able to deal with an error in identifying that set.

Both can deal with the error, given appropriate discipline. Which is better depends on which kind of discipline your project team is more likely to lack :-). I.e. it's a human decision not just a technical one.

> In
> practise it seems that substituting class membership for the primary-key
> negates that advantage. Excising classes from the OO model looks to me
> to be the way to go.

Relation models and class hierarchies can both be quite inflexible. I really think that ORM offers the least inflexible method for capturing conceptual designs and evolving them over time. What needs to be studied is the methods for mapping such fact-based models to physical schemata, in the light of the need to evolve a physical schema to reflect conceptual evolution. This evolutionary aspect is the most important point of view to take of any conceptual->physical mapping strategy.

--
Clifford Heath
Received on Fri Jun 28 2002 - 05:03:28 CEST

Original text of this message