1. Binary Fact Type creation

 The following are examples of Binary Fact Type creation statements written in FEKL:

2. N-Ary Fact Type creation

The following are examples of n-Ary Fact Type creation statements written in FEKL:

NB The ‘IS WHERE’ statement above defines the name of the Fact Type, ‘Stocked Item’ and two Fact Type Readings for the ternary Fact Type, ‘Part is in Bin in Warehouse’ and ‘Warehouse houses Part in Bin’.

The ONE clause in FEKL is used to create a Fact Type with a Mandatory Role Constraint and Internal Uniqueness Constraint.

E.g. The following FEKL statement with a ONE clause creates the Object-Role Model below:

FEKL: 


Object-Role Model:

NB At this stage the Person Entity Type has no Reference Mode and so is in error and coloured red, and similarly the Name Value Type has no Data Type, and so is in error and is red.

The AT MOST ONE clause in FEKL is used to create a Fact Type an Internal Uniqueness Constraint but without a Mandatory Role Constraint.
Optionally, if the second Object Type is a Value Type, the Data Type of the Value Type can be defined.

E.g. The following FEKL statement with a AT MOST ONE clause creates the Object-Role Model below:

FEKL: 


Object-Role Model:

NB At this stage the Person Entity Type has no Reference Mode and so is in error and coloured red, and similarly the Name Value Type has no Data Type, and so is in error and is red.

Optionally Defining the Data Type of a Value Type

FEKL:


Object-Role Model:

NB At this stage the Person Entity Type has no Reference Mode and so is in error and coloured red, however the Name Value Type is not in error becausee we have defined the Data Type for the Value Type, and so is not red, but blue.

The AT LEAST ONE clause in FEKL is used to create a Fact Type with a Mandatory Role Constraint and an Internal Uniqueness Constraint on the far Role of the Fact Type.

E.g. The following FEKL statement with a ONE clause creates the Object-Role Model below:

FEKL: 


Object-Role Model:

NB If a Many-to-Many Relationship is required, rather than a 1-to-Many Relationship, the Internal Uniqueness Constraint on the Fact Type can be changed.
E.g. If you need the relationship to be reciprocal and where a Management Role can also have many Managers.

NB At this stage the Manager Entity Type has no Reference Mode and so is in error and coloured red, and similarly the Management Role Value Type has no Data Type, and so is in error and is red.