Thanks for the sugegstion to generate a sample database from the sample data in an ORM model. This has been on our list of to-dos for quite some time. In addition, we plan to let you enter counterexamples, and use that to automatically generate tests to check whether the relevant constraints are mapped correctly to the ...
Good questions, Ralf.
Support for counterexamples, including automatic generation of test cases, is something that we've planned for years, but unfortunately we still haven't got around to implementing it. Hopefully we will do that in that not too distant future.
Although you can't display fact tables on the diagram page like in ...
Though rarely encountered, I think it's OK for a value type that is a subtype of another value type to have a "more restrictive data type", in the sense used in the following example, but not an incompatible data type.
Consider ISO2CountryCode as a subtype of ISOCountryCode, where the former permits only ...
I just spotted a typo in my previous post. Please replace
the character string 'u"
the character string "us"
Here's a simple, concrete example that will hopefully clarify the distinction between value types and data types in ORM, at least from my perspective.
Suppose we declare two value types CountryCode and Pronoun to store instances of pronouns and country codes respectively, and assign each of these a ...
The constraints you need are called join-subset constraints. These are discussed in Section 10.1 of "The Big Brown Book".
I've tried to attach a diagram for the "Employee works in Building" example, but it doesn't appear in my Post window. If you can see the diagram, then notice that ...
That's a neat trick, and it will work so long as (a) the CPI Authority itself is immutable, and (b) you know the CPI Authority. If either of those assumptions doesn't hold, then you are going to need a cardinality constraint.
I'd prefer to add support for cardinality constraints in the relevant ORM tool, as I think ...
Hi Clifford, that alternative won't work for the example posed because the
value may change over time. The cardinality constraint does the job because it
simply restricts the cardinality for the population (which may vary over time),
not the type. Of course, you could use a value constraint if you were willing to
change the constraint ...
Here are suggested verbalizations for the object cardinality constraint examples on p. 289, Fig. 22:
(a) The number of instances in the
population of JuryMember is 12.
(b) The number of instances in the
population of Senator is less than or equal to 100.
Here is a suggested, ...
ORM includes an Object Cardinality Constraint for this purpose (in this case, use # <= 1), as discussed on p. 289 of the "Big Brown Book".
Unfortunately, we have not yet added support for this kind of constraint to NORMA. Until we do add this support, I suggest you add the constraint in a model note, and code the constraint ...