A Fact Model

Let's illustrate this by starting with a small pre-existing example model. It concerns employees and projects. An employee is identified by an employee number, and has a first name. A project is identified by a project number and requires a project title. The cardinalities may be used in the generation of the implementation; columns could become nullable or require a value.

We want to add data about which employees are working on which project. In logical modeling this would either require adding a foreign key to table Employee, or adding a foreign key to table Project, or even creating a new table Employee_Project with two foreign keys, depending on how many employees can work on how many projects. No wonder this is an issue at the level of a logical model. In contrast, in Fact Oriented Modeling we simply add another fact type and specify uniqueness constraints, from which the correct foreign keys follow automatically when a logical schema is derived. We illustrate this by adding a fact type that verbalizes the relationship between Project and Employee. Once we have added this fact type, we can use a wizard in CaseTalk to easily find the correct uniqueness constraints.

The diagram below shows how the added fact type (Project Employee) is visualized. Additionally the diagram displays the added constraint to specify projects requires at least one Project Employee (and the employee may have a project employee). These are added to demonstrate cardinality variations in the generation of our foreign keys.