Has anyone found occation to use the deontic modality for a constraint? Seems that all factypes require alethic IU constraints, and deontic is only allowed in external constraints. I guess this implies that they are only appropriate when you are adding some quasi-constraint condition to indicated an '...in most cases...' type of implication.
I'm curious as to when and how people have choosen to use this modality, and did they achieve the results they were aiming for. Did the introduction of the implied ambiguity create problems? Were these constraints used in the generation of a RM compliant DB? BRN..
I haven't used deontic modality in ORM, but I have used it elsewhere (like in my data layer generator). Basically it's saying to the tool "Don't enforce this constraint because it may occasionally or temporarily get violated - I'll enforce this one myself!". In other words, don't generate SQL that enforces it, leave enforcement to the business logic layer.
As an example, my generator produces a method TableNameGetByField1Field2 for an index on TableName that's unique over (Field1, Field2). If the index is not unique over those two fields, it generates TableNameGetAllByField1Field2, which returns a collection instead. But sometimes, due to subclassing, the index might include a nullable field, and because SQL Server treats NULL as a single distinct value, a unique index would prevent more than one occurrence of NULL in this field, other fields being equal. Now I actually want to get individual records only when they contain non-NULL values; the nullable ones are handled as sets. So instead I declare to the generator that the index is unique *logically*; it contains values that are technically duplicate, but when used to fetch a record given two non-null values, only one record will ever result; so the method should be called "...GetBy...", not "...GetAllBy...".
However, and as a side note, if the promotors of ORM and authors of NORMA ever want the tool and technique to become mainstream, they'll have to lose the academic language and simply provide a mode control that says "Always true, please enforce" versus "Should mostly be true, I'll enforce it, make it easy for me to do it". I'd never even heard the words deontic and alethic before playing with NORMA, had to look them up, and I've been doing data modelling for 30 years :-). This sort of language simply says to folk "this stuff is above and beyond your mental powers, just don't bother playing in the domain of we lesser gods" - which is completely unnecessary. Sorry to ruffle academic feathers, but it's true.
Thanks for the reply. I was curious about how a deontic constraint was implemented. Apparently, it's not - unless you implement it in some manor outside of the scope of what the tool will generate. That's Ok, as long as clearly denoted as such. Maybe there should be a method of marking these constraints on the diagram (color from red to green?), as the modeler wishs to indicate which ones have external procedures in place to implement the rule. ORM modeles aren't just for generation, they are also documentation, and a way of noting what has actually been implemeted would be helpful.
As for the academic lexicon, if it's necessary to preserve semantics being expressed, then let it stay; if it's just to show off, then loose it. Actually, as long as they are using words (even if they're new to me), it's easier to follow than the symbols used in predicate calculus (especially as they don't always use the same set of symbols).
I'll keep your example in mind. Thanks. BRN..
Actually, I do think that a deontic constraint should be implemented. An alethic constraint is verbalized in terms of "must"; e.g. a race horse must have exactly one trainer. If you break an alethic constraint an error should be issued and the operations should be denied. A deontic constraint is verbalized in terms of "should"; e.g. a race horse should have exactly one trainer. If you break a deontic constraint, no error but a warning should be issued, while the operation should be allowed. Hope this helps
> Actually, I do think that a deontic constraint should be implemented
Yes, I agree - but it cannnot be enforced mandatorily.
There's no standard "warning" system in SQL or semantics
defining what should happen when a warning occurs, which
is why I said: "Should mostly be true, I'll enforce it,
make it easy for me to do it".
The implication is that the infrastructure cannot know
when it's valid to enforce, so the user must arrange
for enforcement at whatever time is appropriate. If
it's easier to enforce using a stored procedure, then
the generator should produce the SP but leave it to the
user to call it... hence "make it easy for me to enforce".
Your comments about distinct coloring are a good idea.
Whether a warning or fatal error is the effect you want, when a constraint is violated, depends on the target of the modeling. As I am most concerned with modeling RM compliant relational database schemas, I don't want anything to get by that would break compliance and open the DB to data integrity errors. As ORM can be used for other types of modeling, I can see where there would be places for allowing vioaltion through with a warning. A bit like a detour sign - if there's work being done, and the road is rough, you might still want to try to get through; but if the bridge is out, better make sure that no one is allowed past. BRN..
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.