Re: General semantics

Erwin wrote:
> If that refers to my complaint about all those distinct "types" of
> constraint : a D can do with exactly two : type constraints and
> database constraints. So which language do you prefer : a D where you
> need to master only one single language construct to declare just any
> database constraint, or an ORM where you need to master dozens of them
> to do just the same ?

In fact, I made a similar point to Terry Halpin and Sjir Nijssen at last years ORM Workshop. All constraints can be written as a query and a requirement that the query return either one or no tuples. (Maybe even simpler, but I haven't explored that.)

Certainly all the ORM constraints can be. Terry's thesis involved, in part, proving a mapping between these constraints and KL. KL is first order logic, and we know that everything expressible in FOL can also be expressed in RM and vice versa.

However, that doesn't mean it's not worthwhile to name the common types of constraint expression, and to use standard forms of verbalisation. So for example when a domain expert says "A can only have X if it also has Y", that is easily seen as a subset constraint. As such, whatever wording the domain expert used can be re-worded into the standard form for ORM constraint verbalisations. That re-statement is both formal, and comprehensible to the domain expert, who can instantly tell whether it's what s/he mean, which helps discover and avoid errors.

All the various ORM constraints exist because they translate well to common expressions and ideas in natural language. That is *not* true of all possible RM constraint expressions.

The point here is that while RM is the most precise and succinct way to represent a model, in order to develop correct models, it's easier to use tools that lend themselves to better communication with nonexperts.  That's what the field of fact-oriented modeling is on about.

Clifford Heath. Received on Sat May 22 2010 - 03:13:29 CEST