Fact concept is an abstract model that defines the fundamentals of knowledge in a specific context. Facts describe what business people know about their business. A Fact has certain characteristics: structure, relationships and constraints. The Fact Concept visually describes these characteristics. When Fact Concept is modeled, it defines:
- The context of a business domain
- Bases of business glossary (terms) and associated expressions
- Constraints about Facts, structurally and semantically
- Relationships of the Facts within a business context
Relationships enable navigation between Facts. This navigability allows the traversing of facts from one to another.
- Fact: A fact is a logical grouping of data and/or information that represents a concept. For example, a Person has a Name and Family can be modeled as a Fact named Person which two members of Name and Family which each can have string values.
- Option: A list of valid pre-defined values for a member of a Fact.
The table below illustrates all of the elements in a Fact Concept model:
In Fact Concept, a Fact is illustrated by a rectangle. The Fact must have a name and some Members. Each Member of a Fact is listed inside the rectangle. Constraints are denoted by a yellow lock behind the Member's name. A Relationship is illustrated with a solid line, starting with a diamond and connecting two Facts (i.e., rectangles).
Each Fact's member can define constraints. These are the value constraints a member of a Fact may have to ensure the Fact is sensible. For example:
- Should a Fact always have a specific member name (i.e., an Order must always have an Order Number to be considered a valid order)?
- Can the value of the member be anything or should the member value have a specific type (e.g., string, int, decimal, etc.)?
- Can the value become null or empty (e.g., A Person (fact) has a Surname for which the Surname cannot be null or empty in the real world)?
These are just examples of what the constraints of a Fact's member is capable of doing.
Constraints can individually validate values of a member (e.g., Age of a Person), or these can validate the value in comparison with some other member's value (e.g., On a Flight (Fact), the Departure cannot be prior to the Arrival time).
In the Fact Concept, there are some standard constraints which do not require any expression to be written in order to enforce these constraints:
- Field is Required: Ensures a member existence for the Fact
- Not Null or Empty: Ensures the value of the member cannot be null or empty
- RegEx Pattern: Ensures the value of a member follows a specific pattern (e.g., email address)
- Type of Value: Ensures the value of a member is in a specific type (i.e., string, int, decimal, etc.). When the Type is 'Other', it propagates the check on the referenced Fact automatically.
- Minimum: Ensures the value of a member has a minimum (e.g., Age cannot be less than zero), or the Name of a person cannot have less than one character in length.
- Maximum: Similar to Minimum, but checks the upper boundary of the value.
Also you can use a Custom constraint and validate the value against any expression that is required.
Modeling the Fact Concept simplifies a couple of scenarios:
- Validating data (value and structure), based on defined constraints and relations of facts
- Writing expressions across different models (i.e., Decision Table, Flow, etc.), as well as a Glossary of Terms
- Defining input/testing data in a context