Re: General semantics
Date: Sat, 22 May 2010 21:31:56 +1000
> 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.
Well, I think we'll have to agree to differ here. My experience is that when you restate a domain expert's constraint in one of the standard forms, they're happy to have been understood and be able to confirm what they meant in a formal way. Comprehension and confirmation becomes a two-way street, and I've seen that with no other modelling process.
>> 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.
No, I disagree. An ORM model can be incomplete (invalid) and yet have captured much of the conceptual content of a business problem. At the point at which the tools identify that none of ORMs metaconstraints are violated, it is a formal model; just as formal as a RM, and in fact directly expressible as RM, i.e., there's a one- -one correspondence for every expression (this is what Terry's thesis established, indirectly through the mapping to KL). I therefore claim that ORM is RM expressed in another language.
Now why is that useful? Because it enables the process of developing a complete model. When a business person says "Person works for Company", I can write *nothing* in RM, because I haven't yet decided what keys will be used for Person or Company, so I have no domains to form a tuple. Yet now that the fact type has been expressed, I can enter it into an ORM tool, which will accept it, but not give assent to the model as being valid until I define a identification schemes (key) for both.
I also don't know whether the model being developed will allow a Person to work for more than one Company. The model is still invalid; I need to define a uniqueness constraint over the fact type. This will indicate one of three things in this case; whether the combination (Person, Company), or the Person, or the Company, is unique with respect to the set of all possible "Person works for Company" facts. Until that uniqueness constraint has been defined, the model is still invalid
So ORM allows models to be developed incrementally, and to be formally and automatically checked for completeness (meaning RM correctness) before being used.
How would you go about this process of model development using D?
Clifford Heath. Received on Sat May 22 2010 - 06:31:56 CDT