Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]
Date: 4 Jul 2005 02:55:58 -0700
I have some obeservations on ORM (my exp. lies in the cloggie-ORM called FCO-IM (Jan , are you using CaseTalk as well?))
ORM's distinction between LOT/NOLOT *is* abritrary, as are ORM's primitive types. Since ORM does not distinguis between business NOLOTS and abstract/mathematcial NOLOTS(i.e a customer is a NOLOT, but a complex number is one also) ORM loses out on the TTM in my opinion(where a customer should never be a type). (I suspect ORM needs a mechanism to promote/demote a NOLOT to a type and vice versa so ORM can hanlde type creation, but that is another matter).
As far as I can see ORM currently lacks candidate keys as a fundamental concept(at least in practice candiate keys are not supported). You can "simulate" them but it doesn't look pretty.
As far as I understand the TTM and ORM from the subtyping point of view, ORM allows subtyping by extension and constraint, TTM only allows by constraint. In this ORM combines the OO subtyping and the TTM subtyping in one, which shows again that ORM does not distinguish between types and (business) NOLOTS.
As long as ORM has not distinction between business NOLOTS and type NOLOTS, together with subtyping/typing, (I do not know if ORM can be extended that way) I consider ORM inferior to TTM with regard to typing.
ORM's contstraint handling is somewhat *erratic*. Different dialects have different notations/annotations, and sometimes lack even some basic constraints. Constraints handling also changed over time as well. It has become somewhat of a pasttime of mine to spot the constraint differences between e.g FORML, ORM(Halpin) and FCO-IM. I'm really looking forward to this fall, when Halpin will introduce ORM2;)
ORM/NIAM *is* flexible, so many shortcomings could be fixed. It's just that all this extensions and modifications make the ORM (definition) actually a *running* target. In this respect the ORM/NIAM dialects use a flexible strategy of extend and embrace to come to a good data model. the RDM caters more of a define, investigate and prove methodology. In the end you can define a data model in both. Currently i cannot do without the RDM even if I model using ORM.
BTW opaque keys are nothing special, been using them for years. I would rather just have *JOIN transparency* instead, though;)
DM Unseen Received on Mon Jul 04 2005 - 11:55:58 CEST