Modeler: 15/RepositoryRules

Model Well-formedness checks

To make sure the model is well formed, CaseTalk can validate it for you. The checks range from structural rules, to soft semantics and example populations, to multi-model management aspects. Each finding is reported at one of three severity levels:

• Error — must be solved before model transformations or generation can start.
• Warning — points at a likely mistake that deserves attention.
• Hint — suggests where the model may be improved.

The rules below are grouped by what they are about, the same way the Verify pane groups them, and each one states the level it is reported at. Category and level are independent, with one exception: a rule about the population is never an error. The sample population is your evidence, not the model; when it clashes with a constraint, either the tuple or the constraint is wrong and only you can say which, so such findings are reported as warnings or hints and never block a transformation. Some rules have been present since the very first version of CaseTalk; others were added over the years to catch mistakes made by beginners and experienced modelers alike, or are defined in SQL.

It is advised to run these checks regularly to keep the model in order.

Structure

What the model is made of: fact types, roles, subtypes, keys, and the names they go by.

Every fact type must have an intra UC

Error

UC Rules

Each fact type must have at least one uniqueness constraint (UC) that concerns one or more roles of that fact type only.

• The diagram UC Rules shows that neither the fact type nor the object type contains any UC.
• The severity of this rule is demoted to a warning when the transformation settings are set to "Assume wide UC".

Role path names must match their role sequence

Error

Derivation rules refer to roles through named role paths. The name of a role path reflects the sequence of roles it traverses. When the underlying model changes, a role path name may no longer match its actual role sequence; this is reported as an error.

Roles must have distinct semantic meanings

Error

A fact type can contain more than one role. When multiple roles in a fact type are played by the same object type or label type, the modeler should either place a role-fix or insert an extra object type to make them distinguishable. Model transformations will fail if this is not handled first — it prevents ending up with a table containing multiple columns with the same name.

• The diagram Semantic Roles shows how roles 20 and 21 are both played by Person and bear no distinction. Either an object type needs to be inserted into the model, or a role should be named using a so-called role-fix.

Additionally, the fixed role name must not already exist as a separate object/fact type name or alias, as that would violate the unique names in the model.

Roles must refer to the correct Meta Level

Error

When modeling across meta-levels (for instance with concepts, templates, and containers), each role must respect the meta-level of its fact type: an FCO-IM role must play a type at the same meta-level as its fact type, a containment role may only contain types at an equal or lower meta-level, and other roles may not reference a lower meta-level than their fact type.

A concept identified by one label type should be an object type

Hint

An object type identified by a single label type is one type with one identifying role, covered by a uniqueness constraint. Modeled instead as a concept with a separate binary fact type stating what identifies it, the model holds two types where it needs one, and the concept ends up identified by nothing: no value constraint accepts it, and it reads as an object type inside a fact type.

Reported is a concept that owns no roles of its own and plays exactly one role, in a binary fact type whose other role is played by a label type. The fix turns that concept into an object type in place — every fact type already referring to it keeps doing so — gives it the identifying role and its own object type expression, places the uniqueness constraint, and removes the fact type that stood in for all of it.

The check is deliberately narrow, because the same structure is what an ordinary binary fact type looks like: only the modeler knows that Country is identified by Country Code was meant as identification while Employee earns Salary was not. Hence a hint, and a fix offered one finding at a time rather than in bulk. As soon as the concept plays a second role something else can identify it, and the rule stops reporting it.

The fix is withheld when the fact type carries sample population, because those values are not carried over to the identifying role.

The related rule Unique label types must be nominalized reaches the same conclusion from the label side, but excludes a concept partner precisely so that this situation is reported once, by the rule that can act on it.

All roles of a composite fact type must be mandatory

Warning

Fact types can be marked as composite, indicating a deliberately non-elementary fact type. Composite fact types are exempt from the n-1 rule, but in return every role must be mandatory. This rule reports (as a warning) composite fact types that still contain optional roles.

Binary fact types must have grouping preference

Warning

In a binary fact type where both roles are under a single UC, or each role is under its own UC, the fact type cannot be grouped automatically during transformation. To optimize the result, at least one role needs a grouping preference.

• The diagram Role Without Grouping shows a fact type with two roles (14, 15) forming a one-to-one relationship between Student and Apprenticeship. This can be implemented as a single column in a table — but which table should CaseTalk choose without a user preference?

Derivable subtypes must have a type declaration

Warning

Subtypes can be flagged as derivable. To properly derive them, the supertype usually has a binary fact type specifying which subtype each instance actually is. The rule checks for a binary fact type attached to the supertype that is populated with the subtype names.

• The diagram Derivable subtype shows Person and two derivable subtypes. The fact type Person Subtype contains the subtype indicator. This rule checks whether the subtype names exist in the population.

Fact types may not contain object types

Warning

In a fact type with more than two roles and a single UC covering n-1 roles, the roles under the UC may be a candidate for nominalization.

Fact types may not contain redundant role combinations

Warning

Different fact types may contain sets of roles with a similar construction. Such role sets, and the object types playing them, may be modeled redundantly. This can be resolved by combining the role sets into an object type. The rule evaluates UCs spanning more than a single role and looks for an equivalent set of played-by roles elsewhere.

• The diagram Role redundancy shows a potential redundancy between roles 17+18 and 11+12.

Fact types must be named

Warning

Newer versions of CaseTalk allow users to enter fact types without naming them right away. To meaningfully generate artifacts, however, they should be named at some stage. This rule checks for nameless fact types.

Label types must be used

Warning

A label type should be played by at least one role. Label types without any role playing them should be removed from the model.

The N rule must be valid for every nominalized fact type

Warning

Every nominalized fact type with n roles must have exactly one uniqueness constraint covering all n roles. Generalizations are an exception, which is why this rule is reported as a warning rather than an error.

• In the diagram UC Rules the object type City should have all of its roles under a single UC.

Note: in newer versions of CaseTalk this rule is more nuanced: the uniqueness constraints are checked against the role sets of each object type expression, rather than against the object type as a whole. This allows both regular object types and generalizations to be correct, as long as each UC matches a corresponding object type expression.

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

Warning

Every fact type must have one or more uniqueness constraints over n-1 roles: a UC should cover all roles, or all roles minus one. If a fact type with n roles has a uniqueness constraint on fewer than n-1 roles, the fact type is splittable. The n-1 test simply checks that no UC is too small.

• In the diagram UC Rules the fact type contains 2 roles, so a UC should exist over at least 1 role.

Note: similar to the N rule, CaseTalk applies this rule per fact type expression rather than on the fact type as a whole. This allows generalizations that require different verbiage under the same fact type, while still guaranteeing a correct model.

The subtype rule must be valid for every subtype

Warning

Every object type that is marked as a subtype must have exactly one role, covered by a single UC. That role must be played by an object type and cannot carry a totality constraint (TC). If the object type played by the role is not flagged as a supertype, this rule reports that as well. For nominalized subtypes, all object type expressions concern exactly one role.

• The figure Proper Subtype shows Student as a valid subtype construction under the supertype Person.

Unique label types must be nominalized

Warning

Roles played by a label type that are also under a narrow UC should really be modeled as object types. The violations are reported as nominalizable label types.

A fact type whose other role is played by a concept is excluded here. Building a new object type out of the label would be the wrong move in that case, because the concept already carries the name and every reference to it; it is reported instead by A concept identified by one label type should be an object type, which promotes the concept and hands it the label role as its identifier.

Subtype declaration needs to be consistent

Hint

Once an object type is marked as a subtype and checked into the Teams Server, this rule watches that it does not fall back to a regular object type.

Constraints

The constraints themselves — whether they are present, unique and complete.

Primary key must occur only once

Error

UCs may be marked as preferred, allowing CaseTalk to render them as primary keys in database artifacts. For a single database table, only one UC can be marked as preferred at a time.

Totality constraint must cover all subtypes

Warning

When a supertype exists and a TC is placed on one or more of its subtypes, this rule checks whether all subtypes are under that TC. If any of them is marked, then they should all be marked.

• The diagram Derivable subtype shows a TC between Teacher and Student, which means that every Person must be either a Teacher or a Student.

Uniqueness Constraints must be unique

Warning

A uniqueness constraint may carry a name to identify the group of involved roles. This name must be unique among the object/fact type names. It is considered a warning since it may not cause failures in the artifacts, where the UC name is used to name primary or alternate keys.

A fact type that can ring should say how it rings

Hint

A fact type that relates a population to itself — a recursive type, or a binary whose two roles are played by the same object type (or types meeting in a subtype hierarchy) — rings in some way: it is a hierarchy, a mutual pair, a ranking. Leaving that open is a decision nobody took yet, and this rule lists those fact types.

Answer it in the OFType editor with a ring constraint, choosing a named pattern (Hierarchy, Direct hierarchy, Ancestry, Peer, Grouping, Ranking, Tournament) or a single ring type. If the fact type genuinely rings in no particular way, pick No ring rule — that is an answer, and it clears the warning, while an empty choice keeps it open. See Ring Constraints.

Data Types

Data type definitions, and the values that have to fit them.

Data type must be known

Error

Label types specify a data type, which must either be one of the types embedded in CaseTalk or defined in one of the artifact lists of available types. If CaseTalk does not know the type, go to Tools\Data Types and drag and drop it into the appropriate data type tree.

Default values must comply with datatype

Error

Roles may carry a default value. This value must also match the data type of the label type.

Value constraints must comply with datatype

Error

Value constraints limit the range of the population values. The limits specified must themselves comply with the data type.

Data type cannot be default

Warning

Until a data type is specified, or derived by CaseTalk itself, the type is set to default. This should not be the case when the model is to be forward engineered.

Label types must contain a datatype definition

Warning

Label types require a data type definition. CaseTalk can derive it from the population using a wizard. Label types without a data type trigger this warning.

Population

The example tuples, weighed against what the model says about them. No rule in this group is ever an error: a tuple that clashes with a constraint means one of the two is wrong, and only you know which.

A strict equality constraint must apply on each subtype tupel

Warning

The population under a subtype must correspond to the population of the supertype. Strictly speaking the strict equality constraint itself is not yet fully supported in CaseTalk; this rule checks the populations instead.

---

Facts must have at least one sample population

Warning

Fact types only exist by expressions and examples. Without any tuples, the expression cannot be validated; therefore at least one sample must exist.

Population must comply with datatype

Warning

Population values must be of the data type specified in the corresponding label type. CaseTalk parses the values to validate that they meet the data type requirements.

Population must comply with subset constraints

Warning

Subset constraints mandate the existence of a population in another fact type. This rule checks whether that is the case for the model and its example population.

Population must not contradict a ring constraint

Warning

A ring constraint states how a fact type relates a population to itself, and the example population has to be able to be true beside it. This rule reads the ring constraint back against the tuples and lists what cannot hold with it:

• Irreflexive — a tuple relates something to itself.
• Purely reflexive — a tuple relates two different things.
• Asymmetric and Antisymmetric — two things are related both ways round. Relating something to itself is allowed under antisymmetry, but not under asymmetry.
• Acyclic — the tuples lead from something back to itself.
• Intransitive — two things are related directly as well as through a third.
• Strongly intransitive — the same, by a detour of any length.

A named pattern is read as everything it stands for, so Ancestry is checked for cycles and for both directions alike.

Only population you have confirmed is weighed: counter examples are entered to be wrong, and tuples nobody has ruled on yet are left alone.

Either the population or the constraint is mistaken and only you can say which, so this rule makes no corrections. See Ring Constraints.

Populations could complete model

Warning

To render a knowledge graph, some populations require additional population under a different object/fact type. This rule checks for missing instances that would allow a more complete knowledge graph to be rendered.

Populations must be confirmed

Warning

Population tuples can be in one of three states: unconfirmed, confirmed, or counter example. In a valid model none should remain unconfirmed.

Populations must comply with totality constraints

Warning

If a TC mandates the existence of tuples, the population should comply with it. More tuples are required to satisfy this rule.

Populations must comply with uniqueness constraints

Warning

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

The actual population of every fact type must be verbalizable

Warning

Object type expressions alone are not always sufficient to verbalize a population. Sometimes an additional fact type expression or totality constraint is required to guarantee that the population really exists.

When the transformation settings assume wide totality constraints, this rule is reported as a hint instead.

The population should match the value constraints

Warning

This rule checks that the population values lie within the value constraints specified on the label types.

Population should say no more and no less than a ring constraint does

Hint

Where the warning above lists population that cannot be true beside the ring constraint, this rule lists population that is perfectly true and says the wrong amount. Nothing here stops a model transformation.

• Symmetric — both directions have been entered. Declaring symmetry is precisely what makes the second tuple a repetition: it states once more what the constraint already says of every tuple.
• Transitive — a relates to b and b relates to c, but the population does not say that a relates to c. It follows from the constraint, so it is not missing; a reader of the population alone will not see it.
• Locally reflexive — something takes part without relating to itself, which the constraint says it does.

See Ring Constraints.

Expressions

How the model reads: verbalizations, substitutions, and the locale they are written in.

Expressions must contain at least one role

Error

Every fact type or object type expression must contain at least one role. Deleting roles from an expression may leave a text-only sentence behind, which can no longer express facts. This is reported as an error, since such expressions block model transformations. Use the Fix option to open the expression editor, where roles can be inserted into the expression again, or the expression can be deleted altogether.

Substitutions must exist

Error

This rule checks for potential integrity issues in expressions and their substitutions to other object type expressions.

Depending on the issue found, this is reported as an error or a warning.

Substitutions must reference a role within their expression

Error

Each substitution in an expression must refer to a role that is actually part of that expression. When roles are removed from an expression, a substitution may be left behind without a matching role. Such leftover substitutions can produce incorrect verbalizations and block model transformations, and are therefore reported as an error. Use the Fix option to open the expression editor and re-insert the missing role, which reconnects the substitution. If the expression itself no longer exists, the fix offers to remove the leftover substitution instead.

All generated expressions require validated semantics

Warning

Recent versions of CaseTalk offer more model (re)factoring functions. These may generate default expressions that were not manually entered by an analyst. To guarantee model quality, such expressions need to be verified manually.

All object type expressions must be used

Warning

Object type expressions are generally created while qualifying fact expressions. This rule states that every object type expression should be verbalized as part of another object type or fact type expression.

Expressions and substitutions must use one Locale

Hint

The model file can be set to a locale (country and language), and expressions can be set similarly. It is however a clear violation when an object type expression has a different locale than the fact type expression it is substituted in. This rule checks for such violations.

Expressions must be current

Hint

Repeatedly merging newer versions of a model may leave older, previously merged expressions behind. If such expressions are not used in any substitution, they are marked as expired. Object type expressions that are not substituted anywhere else are reported as unused and expired.

Expressions must be meaningful

Hint

This rule checks for duplicate expressions under the same object/fact type.

Expressions should not be redundant

Hint

Merging can introduce expressions with similar soft semantics. This rule checks for those occurrences.

Facts require proper verbalizations

Hint

When an example population is absent and the soft semantics have been refactored but not reconfirmed, this warning notifies the user of a state that needs attention.

Documentation

What a reader of the model is told: annotations, URIs, metadata and vocabulary.

Vocabulary names must be unique

Error

All object/fact type names must be unique. This also holds when translations enter the model: every object/fact type name in a given locale must be unique within that locale, across all translated names.

This rule is reported as an error when the model has a specific locale set; otherwise it is reported as a warning.

Elements must comply with mandatory custom metadata

Warning

Custom attribute definitions may mark some attributes as mandatory. This rule checks for elements in the information model that lack such custom attributes while the active definitions require them. Note: only the selected custom attribute definition set is checked.

The alias of an object/fact type must be unique

Warning

Object/fact type names must be unique, and each type may additionally have an alias. This rule warns when an alias corresponds to the name of another object/fact type.

Used namespace must be up to date

Warning

A namespace imported into the active model has a newer version on the Teams Server, and therefore the object/fact types from this namespace may need to be updated.

Catalog mappings must be linked

Hint

Catalog mappings bind physical columns from an external catalog to the model through role paths. This rule hints at mapping paths that do not, or no longer, exist in the model.

Concepts must be qualified

Hint

Concepts may be added to the information model without expressions, population, or even roles. This is a convenient way to start collecting terms and qualify them later. Concepts that are not yet qualified are listed by this rule. They do not stop model transformations; they are simply ignored and removed from the result.

Every object/fact type should have an annotation

Hint

Well-documented models carry an annotation (a description) on each object/fact type. This rule hints at types that have no annotation yet.

Types must be depicted

Hint

CaseTalk keeps track of which object/fact/label types appear in diagrams. Types that are not shown in any diagram are reported by this rule. The solution is to add them to at least one diagram.

URIs require fresh and valid content

Hint

Custom attributes and annotations may contain links to external documentation or content (URIs). CaseTalk can check these external sources for validity and content changes.

Namespaces

Models merged in from elsewhere, and keeping up with the versions they came from.

External expressions must be supported

Warning

Fact expressions can be merged from another model file (a namespace) into the current one. Such expressions are flagged as originating from a different namespace. CaseTalk allows architects to specify which namespaces may be used and which may not. This rule simply checks for expressions that are not yet marked as coming from a valid merged namespace.

External namespace must cover one version

Warning

Elaborate editions of CaseTalk allow various namespaces, in various versions, to be merged into other models. However, expressions from two distinct versions of the same namespace must never be merged together.

External substitutions must be supported

Warning

Object type expressions can likewise be merged from another model file (a namespace). This rule simply checks for object type expressions that are used in fact expressions but not yet marked as coming from a valid merged namespace.

Facts may not be merged from multiple namespaces

Warning

Facts contain expressions. These expressions should originate from the same namespace, or be added in the current information grammar; they should not originate from multiple sources. This is reported as a warning, not an error.

Namespace support may not be recursive

Warning

Namespaces let users track the re-use of information across models. Granting and revoking the allowed use of a namespace may introduce a self-reference: namespace A uses B, which uses A. This is not allowed and needs to be addressed.

Transformation

What stands between the model and a transformation.

A FTE is required when an artificial key is created for an object/fact type

Error

When an object/fact type is set up to generate an artificial key, it must have at least one fact type expression. Without one, there is no fact context in which the artificial key can be generated.

Cannot lexicalize recursion

Warning

An object type plays a role that refers back to itself. The current version of CaseTalk cannot lexicalize such a model, which prevents a database schema from being derived.

Generalized Object Types needs a key

Warning

A generalized object type may be modeled with only optional roles, which would prevent the generated artifacts from containing a primary key. The fix can be as simple as setting the flag to generate an artificial key in those cases.

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

Warning

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

• The diagram OT with TC shows no fact type expressions, but a TC over roles 4 and 10 guarantees that the city population exists in a fact.

When the transformation settings assume wide totality constraints, this rule is reported as a hint instead.

Recursive identification warning

Warning

An object/fact type identifies itself recursively through one of its lexicalization paths. Unlike direct recursion this may still be lexicalizable, but it deserves attention.

Reducing object types deletes fact type expressions

Warning

When the transformation settings enable reduction, object types marked for reduction will lose their fact type expressions during the transformation. This rule warns up front which fact type expressions would be deleted.

Custom SQL

Users can build their own additional set of rules using SQL.

A SQL rule states in its leading comment which group it belongs to, for example -- category: population. Recognised words are structure, constraints, data types, population, expressions, documentation, namespaces and transformation. A rule that says nothing is listed under Custom Rules.

There may be more validation rules active in your environment, added through customization. See also: Customization through own rules in SQL

---

---

Other versions: v8 | v9 | v10 | v11 | v12 | v13 | v14 | v15