Constraints

This page provides a complete reference of all constraint types supported by CaseTalk for conceptual modeling.

Overview

Constraints in CaseTalk enforce business rules on your conceptual model. They restrict which populations (instances) are valid by specifying conditions that must hold. CaseTalk supports the full set of constraints from ORM (Object-Role Modeling) and FCO-IM methodology.

Category	Constraint Types	Purpose
Identification	Uniqueness (primary)	Defines how instances are uniquely identified
Multiplicity	Uniqueness, Mandatory, Frequency	Controls how many times values can or must occur
Set Comparison	Subset, Equality, Exclusion	Relates populations of different fact types
Value Restriction	Value Constraint	Limits allowed values for a role or type
Taxonomy	Subtype	Defines type hierarchies and partitions
Ring	Irreflexive, Symmetric, Acyclic, etc. (and named combinations)	Restricts recursive binary relationships
Derivation	Derivation Rule	Defines computed/derived fact types

Identification Constraints

An identification constraint is a primary uniqueness constraint that defines the reference scheme for an entity type. It specifies which roles (or combination of roles) uniquely identify instances.

Example: Person is identified by PersonID

Every entity type should have at least one identification constraint. When a uniqueness constraint is marked as primary, it serves as the preferred identification scheme for that type.

See also: Uniqueness Constraints

Uniqueness Constraints (UC)

A uniqueness constraint restricts how many times a particular combination of values can appear in a population.

Single-role UC: Each Person has at most one BirthDate

Multi-role UC: The combination of Country and City is unique

Uniqueness constraints come in several forms:

Form	Description	Example
Primary UC	Identification constraint (reference scheme)	Person is identified by PersonID
Secondary UC	Additional uniqueness beyond identification	Each Person has at most one BirthDate
Spanning UC	Uniqueness over multiple roles	The combination of FirstName and LastName is unique
External UC	Uniqueness across fact types	Each Person has at most one Address in each Country

Diagram notation: A bar or arrow spanning the constrained roles.

Mandatory Role Constraints (MRC)

A mandatory role constraint (also called a total constraint) requires that every instance of an object type participates in at least one instance of a fact type.

Example: Each Person has at least one LastName

Mandatory constraints support several modes:

Mode	Meaning	Example
Mandatory (OR)	Must participate in at least one of the constrained roles	Each Person has at least one PhoneNumber
Exclusive (XOR)	Must participate in exactly one of the constrained roles	Each Vehicle is either a Car or a Truck (but not both)
Mandatory and Exclusive	Must participate, and in only one	Combines both restrictions
Absent	Explicitly non-mandatory (documentation only)	Role participation is optional

Combined with UC: When a role has both a uniqueness and a mandatory constraint, CaseTalk can verbalize this as exactly one (e.g., Each Person has exactly one BirthDate).

Diagram notation: A solid dot on the constrained role(s). Exclusive constraints use a circled X connecting roles.

Subset Constraints (SC)

A subset constraint requires that the population of one role combination is always a subset of another role combination.

Example: The set of Persons who manage a Department is a subset of the Persons who work in a Department

Subset constraints connect roles from different (or the same) fact types and enforce that if a tuple exists in the from side, a corresponding tuple must exist in the to side.

Diagram notation: An arrow from the subset roles to the superset roles.

See also: Equality Constraints

Equality Constraints

An equality constraint is formed when two subset constraints exist in opposite directions between the same role pairs, making them bidirectional subsets.

Example: Person manages Department if and only if Person is head of Department

CaseTalk automatically detects paired subset constraints and reports them as a single equality rule in the SBVR export.

Diagram notation: A double-headed arrow (or two opposing subset arrows).

Value Constraints (VC)

A value constraint restricts the allowed values for a role or value type.

Type	Description	Example
Enumerated	A fixed list of allowed values	Gender must be M or F
Range	A numeric or date range	Age must be between 0 and 150
Key-Value	Named value pairs	Status: A=Active, I=Inactive
State	State transition definitions	Order status transitions: New, Approved, Shipped

Diagram notation: A set of values shown near the constrained role, enclosed in braces.

Frequency Constraints (CC)

A frequency constraint (also called a cardinality constraint) specifies how many times a value may or must occur in a role. It generalizes the uniqueness constraint to allow counts other than "at most one."

Example: Each Team must have between 3 and 10 Players

Example: Each Person may occur at most 5 times as member of a Committee

Internally, CaseTalk represents frequency constraints as uniqueness constraints with Min and Max values.

Pattern	Min	Max	Verbalization
At most N	0	N	may occur at most N times
At least N	N	0	must occur at least N times
Exactly N	N	N	must occur exactly N times
Range	N	M	must occur between N and M times

Diagram notation: A frequency annotation (e.g., greater than or equal to 3) near the constrained role.

Subtype Constraints

Subtype constraints define type hierarchies where one type is a specialization of another.

Example: Employee is a subtype of Person

CaseTalk supports several subtype patterns:

Pattern	Description	Example
Simple subtype	One type specializes another	Student is a subtype of Person
Exclusive subtypes	Subtypes do not overlap	Male and Female are exclusive subtypes of Person
Exhaustive subtypes	Subtypes cover the entire supertype	Every Person is either Male or Female
Exclusive and Exhaustive	Complete, non-overlapping partition	Person is partitioned into Male and Female

Diagram notation: An arrow from subtype to supertype. Exclusive/exhaustive shown with a circled X or dot on the subtype connection.

See also: The SBVR export includes subtype rules and the Business Glossary can show categorization schemes.

Ring Constraints

Ring constraints apply to binary fact types where both roles are played by the same object type (or subtypes of a common ancestor). They restrict how objects relate to themselves through a recursive predicate.

Example: Person is parent of Person can have an irreflexive ring constraint (no one can be their own parent).

Reflexivity Family

Type	Meaning	Example Verbalization
Irreflexive	No object can be related to itself	No Person is parent of that same Person
Purely Reflexive	The fact can relate an object to nothing but itself: if A relates to B, then A is B	If Person1 is parent of Person2 then Person1 is the same Person as Person2
Locally Reflexive	Any participating object must also relate to itself	Each Person that is related to some Person also is related to itself

Note that ORM has no "reflexive" that requires every object to relate to itself. Purely reflexive is the opposite statement: nothing but itself.

Symmetry Family

Type	Meaning	Example Verbalization
Symmetric	If A relates to B, then B relates to A	If Person1 is sibling of Person2 then Person2 is sibling of Person1
Asymmetric	If A relates to B, then B does not relate to A	If Person1 is parent of Person2 then it is not the case that Person2 is parent of Person1
Antisymmetric	If A relates to B and B relates to A, then A equals B	If Person1 is related to Person2 and vice versa, then they are the same Person

Transitivity Family

Type	Meaning	Example Verbalization
Transitive	If A to B and B to C then A to C	If Person1 is ancestor of Person2 and Person2 is ancestor of Person3 then Person1 is ancestor of Person3
Intransitive	If A to B and B to C then NOT A to C	If Person1 is parent of Person2 and Person2 is parent of Person3 then it is not the case that Person1 is parent of Person3
Strongly Intransitive	Not just the two-step shortcut: no chain of any length may reach what the fact already reaches directly	If Person1 is parent of Person2 then it is not the case that Person1 reaches Person2 through a chain of two or more parent steps

Acyclicity

Type	Meaning	Example Verbalization
Acyclic	No chain of relationships can form a cycle, of any length	No Person is parent of that same Person, directly or through any chain of parent

What Follows From What

Ring constraint types are not independent. Picking one already says several of the others, so combining them adds nothing:

• Asymmetric ⇒ Irreflexive
• Acyclic ⇒ Asymmetric ⇒ Irreflexive
• Intransitive ⇒ Irreflexive
• Strongly Intransitive ⇒ Intransitive and Acyclic
• Transitive + Irreflexive ⇒ Acyclic (they are the same rule as Acyclic + Transitive)

This is why "Irreflexive + Asymmetric" is simply Asymmetric, and "Irreflexive + Asymmetric + Acyclic" is simply Acyclic. CaseTalk stores the minimal spelling and drops what is already implied.

Combinations Worth Naming

Individual ring types are hard to remember; the combinations are what modellers actually mean. CaseTalk offers these as ready-made choices in the Ring Constraint dropdown:

Pattern	Ring types	What it says	Typical fact types
Hierarchy	Acyclic	Nothing can end up above itself	reports to, is part of, supersedes
Direct hierarchy	Acyclic + Intransitive	One step at a time, and never back to the start	is direct manager of, is immediate part of
Ancestry	Acyclic + Transitive	Carries through the whole chain, and never returns	is ancestor of, precedes
Peer	Symmetric + Irreflexive	Always both ways, never with itself	is married to, is sibling of, borders on
Grouping	Symmetric + Transitive + Locally Reflexive	Everyone in the group, itself included	is in the same team as, is a synonym of
Ranking	Antisymmetric + Transitive + Locally Reflexive	Carries through, and ties only with itself	is at least as senior as, is contained in
Tournament	Asymmetric + Intransitive	One way only, and beating the beater proves nothing	beats, outranks
Only with itself	Purely Reflexive	The fact can relate a thing to nothing but itself	rare

Purely Reflexive and Strongly Intransitive are the two types that never appear in a combination: the first contradicts everything it could be paired with, the second already implies its partners.

Combinations That Can Never Hold

Some combinations look reasonable but leave a fact type that can never be populated:

Combination	Why nothing can satisfy it
Symmetric + Asymmetric	One says always both ways, the other says never both ways
Symmetric + Transitive + Irreflexive	Symmetry and transitivity together force a thing to relate to itself, which irreflexivity forbids. This is the sibling trap: is sibling of cannot be all three
Symmetric + Acyclic	Every symmetric pair is a two-step cycle
Irreflexive + Locally/Purely Reflexive	One forbids relating to itself, the other requires it
Transitive + Intransitive	One completes a chain, the other forbids the very same completion

CaseTalk refuses these combinations rather than storing a rule that empties the fact type.

How to Apply a Ring Constraint

1. Open a binary fact type in the OFType editor
2. If both roles play the same type (or related subtypes), the Ring Constraint dropdown appears automatically
3. Pick a named pattern (Hierarchy, Peer, ...) or, indented underneath, a single ring type
4. The choice is saved with the fact type, and the model check reports fact types where the question is still open

No ring rule is a separate answer from leaving the choice empty. Empty means nobody decided yet, which the model check reports as an open question; No ring rule records that the fact type was considered and rings in no particular way.

Derivation Rules

A derivation rule defines a fact type whose population is computed from other fact types rather than directly asserted.

Example: Person is grandparent of Person is derived from Person is parent of Person (two steps).

Derivable fact types are marked in CaseTalk and their OTE (Object Type Expression) defines the derivation logic.