Re: General semantics

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

My problem is the "one of the + plural" part. I don't want to have to learn an artificial multitude of "standard forms" if I know that one single form can suffice.

Besides, I have seen no objective criteria to decide, e.g., when (and when not) a certain constraint is a subset constraint. So at this stage, I must conclude that choices wrt classification of constraints are quite arbitrary. Not a good feature for a technique that claims to be "more formal" ...

> 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

Your example here is the equivalent of the "every relvar must have a (explicitly declared) key" controversy.

On a side-note, this demonstrates that/how completeness/validity is in the eye of the beholder : Darwen has long insisted very strongly on mandating explicitly declared keys. He's come round from that position, now allowing relvar declarations with no key specified, implying KEY {ALL}. End of side note.

But your example made me wonder about something more important : nullology.

What about defining the key of relvars that are required to be singleton ? In D : KEY {}. In ORM ? No bars above any attribute(/"role") ?
What about defining relvars of degree zero intended to record information such as "The shop is open" and "The alarm is set" ? In D : VAR RELATION {} THE_SHOP_IS_OPEN. In ORM ? No roles ?

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

In exactly the same way as you do with ORM : by allowing it to be incomplete and invalid.

Note that a logical database design is nothing more than a set of relvar declarations (thanks to the information principle), plus a set of constraint declarations.

I could have relvar specifications that omit the type name from each attribute. To be filled in later.
I could have relvar specifications that specify attribute types where the type "doesn't exist". To be added later. I could have constraint expressions that are syntactically invalid. To be corrected later.
I could have constraints that are defined only by a comment in natural language, and that do not even have the actual expression specced out. To be added later.
This way, you can build a design incrementally, but it won't be valid until it satisfies all the constraints that your D engine imposes on its D.

Only at the point where the design is valid, can it actually be "exported" to the actual engines. But since I started off using D from the first step onward, I saved myself a translation battle. And I saved myself having to learn an additional language for the specification.

In SIRA_PRISE, I have catalog constraints that (e.g.) prohibit attributes to be declared as part of a key if that attribute is not part of the relvar. If I remove all those constraints from the catalog, then I have precisely the database that I need to support incremental database design work. Anyone can enter anything, but only at the point where it satisfies all constraints from the "real" catalog, can the design be ported to the "real" machinery. Received on Sat May 22 2010 - 15:33:34 CEST