Re: General semantics

On 22 mei, 03:13, Clifford Heath <n..._at_spam.please.net> wrote:
> Erwin wrote:
>
> 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.)

In general, there are multiple forms in which all database constraints can be expressed (type constraints are obviously a different matter) :

<relationalexpression1> SUBSETOF <relationalexpression2> ISEMPTY(<relationalexpression>)
<relationalexpression1> EQUALTO <relationalexpression2> COUNT(<relationalexpression>) EQUALTO <somenumber> ... and presumably there are still more, but of at least these I'm sure.

They can be converted into one another using the following equivalences :

R1 SUBSETOF R2 <===> ISEMPTY (R1 MINUS R2) <===> (R1 MINUS R2) EQUALTO empty relation
ISEMPTY(R) <===> R SUBSETOF empty relation <===> R EQUALTO empty relation
R1 EQUALTO R2 <===> R1 SUBSETOF R2 AND R2 SUBSETOF R1 <===> ISEMPTY(R1 SYMDIFF R2) (with SYMDIFF denoting the symmetric difference)

> 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.

Every database constraint can be expressed as a "subset" expression. Does that then make every database constraint a subset constraint ? If that is so, then what useful purpose does it serve to invoke the name "subset constraint", if in the aftermath, it doesn't give any distinction anyway ?

Inventing such names is, imo, creating complexity for the sake of it.

> 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.

All database constraints can be formulated in natural language in the form "there cannot be any x(,y,z) such that ..."

With the x,y,z replaced with the names of your business things (customer, address, contract, employee, ...) and the ellipsis replaced with the predicate that corresponds to the relational expression that expresses the constraint formally.

And I don't mean this to suggest in any way that the "natural language" version must be a consequence, derivative, ... of the "formal algebra expression". Of course things go exactly the other way round. Start off with prose specs (informal by necessity because natural language is always somewhat imprecise and ambioguous by necessity) and drawings of rectangles connected by straight lines (informal by necessity because there are not enough graphical / visualization techniques to render anything we might possibly want to express), and when the limits of the expressive power of your prose and drawings are reached, then start using a language that has full expressive power and yet is fully formal. D, for example.

> 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 non-
> experts. That's what the field of fact-oriented modeling is on about.

Then you agree with me that ORM is at the conceptual modeling level ? Then you must also agree that this has nothing to do with RM per se, and you must also agree that you contradicted yourself when you said "This stuff is pure relational"). ORM is an exercise in informality, whereas 'pure relational' is an exercise in formality. Received on Sat May 22 2010 - 12:09:10 CEST