Modeler:Tutorial/Integrity Checks

Every fact type must have an intra UC

For each fact type, there must be at least one uniqueness constraint that concerns one or more roles of this fact type only.

The N rule must be valid for every nominalized fact type

Every nominalized fact type with n roles only has exactly one uniqueness constraint over all n roles.

The N-1 rule must be valid for every fact type

If a fact type with n roles has at least one uniqueness constraint on less than n-1 roles, then the fact type is splittable. The n-1 rule-test simply consists of the check that there are no UCs that are too small.

The subtype rule must be valid for every subtype

• There can be no single role totality constraint on the role of a unary fact type.
• Each derivable subtype must have a derivation rule, in which only roles can occur (apart from the role of the subtype itself) from fact types that
  • either are played by one or more of its supertypes
  • or are found in one or more of its supertypes
• In a fact type that is a subtype, all roles have a single role uniqueness constraint. For nominalized subtypes, all object type expressions concern exactly one role.

All object type expressions must be used

Object type expressions are to be used as part of another and finally in an Fact type expression. If no substitution is found for an object type expression, it is found to be invalid.

Non-lexical object types without totality constraints must have a fact type expression

If no totality constraint at all applies to any of the roles played by a certain nominalized fact type, then that fact type must have an existence postulating fact type expression.

Fact types may not contain object types

Fact types with n roles, and n > 2, with a single UC covering N-1 roles, these roles under the UC may be candidate for nominalization.

Binary fact types must have grouping preference

Binary fact types where both roles are under a single uc, or both roles under their own uc, this fact type cannot be automatically grouped during transformation. Therefor to be optimized, at least one role needs a grouping preference.

All generated expressions require validated semantics

In later version of CaseTalk more model (re)factoring functions exist. This may lead to default generated expressions, which are not manually entered by an analyst. To guarantee model quality, these need to be manually verified.

Label types must be used

Label types can only exist if played by at least one role. Label types found in the model without any role played by this label type, the label type should be removed.

Populations must comply with uniqueness constraints

The example population should adhere to the uniqueness constraints applied to the corresponding roles.

Populations must comply with totality constraints

If a tc mandates tuple existence, the population should comply to that. More tuples are required to satisfy this rule.

Population must comply with subset constraints

Subset constraints mandate existence of a population in another fact type. Therefor this rule checks if that is the case within the model and the example population.

Population must comply with datatype

Population values are set to be of a specific data type as specified in the corresponding label type. The values are parsed by CaseTalk to validate they meet the datatype requirements.

Value constraints must comply with datatype

The population contains values and value constraints limits the range of these values. Therefor the limits specified must comply to these datatype themselves.

Expression requires soft semantics

---

Back: Subtype and Generalisation