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	Reflexive, Symmetric, Transitive, etc.	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	Every object must be related to itself	Each Person is related to that same Person
Locally Reflexive	Any participating object must also relate to itself	Each Person that is related to some Person also is related to 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	Stricter form of intransitivity	Same verbalization as intransitive

Acyclicity

Type	Meaning	Example Verbalization
Acyclic	No chain of relationships can form a cycle	If Person1 is parent of Person2 then it is not the case that Person2 is parent of Person1

Common Ring Constraint Combinations

Some ring constraint types are commonly used together:

• Irreflexive + Asymmetric — typical for hierarchies (is parent of)
• Irreflexive + Asymmetric + Intransitive — strict parent relationship
• Irreflexive + Asymmetric + Acyclic — DAG (directed acyclic graph) relationships
• Symmetric + Irreflexive — mutual relationships (is sibling of)

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. Select the desired constraint type
4. The constraint is saved with the fact type

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.