Applying the Fact-Based Modeling Protocol: The

DEF phone directory example

Consider following example of communication (a page of the DEF company
phone book):

First Last
Personnel ID Name Name Position Workphone Home Phone

0012 Jim Jones Manager 3678 043-7869463

0013 Dave Leary Manager 3678 043-7869551
0014 Jim Jones Clerk 7896 043-7869551

The DEF company keeps track of all the work phone and home phone numbers
of its employees. Furthermore, the DEF company records the current position of
each employee. The DEF company uses the employee id for identifying an
employee, although most employees use the combination of first and last name,
while that combination is not necessarily unique .

Step 0: Produce examples (will come later, in this case

example is already provided)

Step 1a: Verbalise from examples of representations of

facts
In this step we will transform documents containing information in different
formats into natural language sentences (the universal format).

The employee 0012 has the position of a manager ............................................(1)

The employee 0012 has the phone extension 3678 at work and has the
phone extension 043-7869463 at home...............................................................(2)
The employee 0012 has first name Jim………….................................................(3)
The employee 0012 has last name Jones………….............................................(4)
The employee 0013 has the position of a manager.............................................(5)
The employee 0013 has the phone extension 3678 at work and has the phone
extension 043-786955 at home............................................................................(6)
The employee 0013 has first name Dave…………..............................................(7)
The employee 0013 has last name Leary………….............................................(8)
The employee 0014 has the position of a clerk...................................................(9)
The employee 0014 has the phone extension 7896 at work and has the phone
extension 043-786955 at home..........................................................................(10)
The employee 0013 has first name Jim…………...............................................(11)
The employee 0013 has last name Jones…………...........................................(12)

1
Step 1b: Split into elementary facts
We prefer to work with elementary or ‘stand-alone’ facts. Hence, we will split
up sentences 2, 6 and 10 into 2 ‘stand-alone’sentences that each contain exactly
one fact. Later we will discuss a heuristic to formally check whether such an
splitting process leads to elementary facts.

The employee 0012 has the position of a manager ............................................(1)

The employee 0012 has the phone extension 3678 at work.............................(2a)
The employee 0012 has the phone extension 043-7869463 at home…………..(2b)
The employee 0012 has first name Jim………….................................................(3)
The employee 0012 has last name Jones………….............................................(4)
The employee 0013 has the position of a manager.............................................(5)
The employee 0013 has the phone extension 3678 at work.............................(6a)
The employee 0013 has the phone extension 043-786955 at home..................(6b)
The employee 0013 has first name Dave…………..............................................(7)
The employee 0013 has last name Leary………….............................................(8)
The employee 0014 has the position of a clerk...................................................(9)
The employee 0014 has the phone extension 7896 at work...........................(10a)
The employee 0014 has the phone extension 043-786955 at home…………..(10b)
The employee 0013 has first name Jim…………...............................................(11)
The employee 0013 has last name Jones…………...........................................(12)

Step 2: Denote variable and constant parts in the fact

We now can initially classify the sentence groups in variable and fixed parts.

|The employee| 0012 | has the position of a | manager|.

|The employee| 0013 | has the position of a | manager|.
|The employee| 0014 | has the position of a | clerk |.
fixed variable fixed variable

General classification structure of this group:

fixed 1|variable 1|fixed 2 | variable 2

Step 3: Qualification of variables in the fact

Qualification is the specification of additional terms in parts of a sentence group.
To do this in a precise way we will first introduce additional information or
knowledge modeling constructs that we will use in the remainder of this
methodology. In this step of the methodology analysis we have to classify the
fixed parts of the sentences as either entity types, name classes or verbs.

An entity is a real or imaginary object within a specific subject area. Examples:

The student 126734, the student 123546, the employee piet, the employee jake.
An entity type can now be defined as a referring to a set of entities , e.g. the

2
entity type of the entities student 126734 and student 123546 is student. The
entity type of the entities employee piet and employee jake is employee.

A name class is a set of names that can be used for identifying instances of a
given entity type (entities).

Examples of name classes :

The name class of 10 digit codes (e.g. 0437885367, 0456356378) that can be
used to identify the dutch phone extensions.

The name class of SOFI-numbers (e.g. 8675845940, 576895047) that can be

used to identify dutch taxpayers.

The name class of student ID’s (e.g. 997564, 995678) that can be used to
identify the UM students

The name class of integers (1, 2, 3,…) that can be used to identify an amount.

We will now apply the qualifying procedure on our example . Once again, for
each variable part in the sentence type we ask:

What entity type does the individual name refer to ?

Analyst: What type of entity is referred to by '0012'

Domain expert: The entity type 'employee'

By (names from) what name class are entities of the entity type identified?

Analyst: How are specific entities of the entity type 'employee'

identified within the union of all ‘employees’?
Domain expert: By names from the name class 'employee id'

For the second variable part in the example sentence group we ask the same
questions:

What entity type does the individual name refer to ?

Analyst: What type of entity is referred to by 'manager'

Domain expert: The entity type 'position'

By (names from) what name class are entities of the entity type identified?

Analyst: How are specific entities of the entity type 'position'

identified within the union of all ‘positions’?
Domain expert: By names from the name class position name'

In case the name class and/or entity type is part of any of the fixed parts of the
sentence types, we relabel these parts as name class and/or entity type

3
respectively until we have processed all variable parts in a sentence group. In
some initial verbalizations all entity types and name classs will be contained in
the fixed parts of the sentence groups. E.g. in the following sentence: The car
with licenseplate number 23-JK-56 is owned by the person with person id
234577, all entity types (car, person) and name classs (licenseplate number,
person id) are contained in the initial verbalization. In case the entity type and/or
name class designators are not contained in the initial verbalization they will be
added (this is the process of qualification). The remaining parts of the fixed parts
are by definition labeled as verb, sometimes omitting semantic irrelevant fill-up
words. Applying this procedure on our example sentence groups yields:

Group 1:

The employee with ......entity type

employee id ......name class
0012 0013 0014 .......individual name
has ........verb
the position with .......entity type
position name ........name class
Manager Manager Clerk ........individual name

Group 2:

The employee with1 ......entity type

employee id ......name class
0012 0013 0014 .......individual name
has ........verb
the phone extension .......entity type
with number ........name class
3678 3678 7896 ........individual name
at work .......verb

Group 3:

The employee with ......entity type

employee id ......name class
0012 0013 0014 .......individual name
has ........verb
the phone extension .......entity type
with number ........name class
043-7869463 043-7869551 043-7869551..individual name
at home ..........verb

1Note that with should be considered as a fill-up word in this context.

4
Group 42:

The employee with ......entity type

employee id ......name class
0012 0013 0014 .......individual name
has ........verb
first name ........name class
Jim Dave Jim ........individual name

Group 5:

The employee with .........entity type

employee id .........name class
0012 0013 0014 ........individual name
has .........verb
last name .........name class
Jones Leary Jones .........individual name

The sentence format that contains all entity type and name classes explicitly will
be called a deep structure sentence.

Step 4: Identification of concepts mentioned in the facts

Now we can inventorize all the relevant concepts in the deep structure sentences
that represent the facts in our example: Employee, Employee ID, Phone
extension at home, Phone extension at work, Number, Position, Position name ,
First name and Last name

Step 5: Generalization towards fact type forms (fact

communication patterns) and fact types

Let's take a look again at the following classified and qualified sentences from
the example group 1:

The employee with ......entity type

employee id ......name class
0012 0013 0014 .......individual name
has ........verb
the position with .......entity type
position name ........name class
Manager Manager Clerk ........individual name

2 For sentence groups 4 and 5 we only give a name class for the 2nd variable part in the
fact type form because it basically refers to an alternative name for the entity type for the
first variable part (i.e. Employee)

5
In figure 1 we will show the transformation template for the creation of diagrams
starting from those fully classified and qualified expressions (deep structure
sentences).

Figure 1: Diagrammization mapping procedure

In figure 1 an exact mapping from the elements in the deep structure sentence is
given to the elements in the information diagram. Note that the individual names
from the variable parts of the sentence groups can be considered as being
elements of the fact type population. The fixed parts can be considered as being
elements of the fact type form.

In the former section we exactly described the process of deriving an

information diagram from a (collection) fully classified and qualified fact
type(s). However, to derive a diagram like figure 2 we have to:

1) Assign a unique role code to each role (within a fact type).

2) Assign a unique fact type code to each fact type.

In figure 2 a template is given for the integration of 'stand-alone ' fact types
into an integrated diagram.

6
 Figure 2: Fact type integration template
In figure 3 the fact types and fact type forms (and the example fact population)
of the classified and qualified sentences for example 3 are given including the
relevant entity types and name classes or name types.

First name
FT4
R7 R8

<R7> has <R8> Last name

Ft5
R9 R10

<R9> has <R10>

Figure 3: Fact types and Fact type forms DEF example

7
Step 6: Adding Uniqueness rules (NIAM/ORM CSDP
step 4)

In step 6 of the fact-base modeling methodology we will derive uniqueness

integrity rules. These rules will prohibit the existence of some instance
populations. Uniqueness integrity rules reflect some of the domain rules in a
semantic-conceptual model. Let’s assume that following explicit documented
domain rules hold in our example UoD.

Domain rule 3.1: Each employee has a company phone extension

Domain rule 3.2: Each employee has a position.
Domain rule 3.3: Each employee has at most one position (at a time).
Domain rule 3.4: Each employee has at most one home phone extension listed
in the phone book.
Domain rule 3.5: A work phone extension always consists of 4 digits.
Domain rule 3.6: A home phone extension always consists of 10 digits.
Domain rule 3.7: DEF currently knows manager, clerk and secretary
positions.
Domain rule 3.8: Each employee has at most one first name.
Domain rule 3.9: Each employee has at most one last name.

By applying the FBM modeling protocol, we will furthermore, be able to make

business rules explicit (rule mining) by involving the domain expert in the
analysis process. In this step 4 we will derive the uniqueness integrity. We will
derive the uniqueness integrity rules for an information model by investigating
one fact type at a time. We thereby can use the following "law":

The N-1 law for uniqueness integrity rules

For each elementary (or atomic) fact type having N roles, exactly one of the
following rules applies:

1) There is a uniqueness integrity that covers N roles.

2) There is at least one and at most N uniqueness integrity rules that
cover exactly N-1 roles.

The uniqueness integrity rule detection protocol

We will denote a uniqueness integrity rule graphically as an arrow covering one

or more roles (according to the rules in the N-1 law). The modeling protocol for
the uniqueness integrity rules that are defined on a given fact type is as follows.
Consider one allowed sentence from the fact type population e.g.

Employee 0012 has the position of a manager

8
For the derivation of uniqueness integrity rules it is easy to refer to a sentence by
listing the individual names in the roles as follows:

0012 manager3

We will now create a second sentence in which the value of the first role is
changed:

0013 manager

The analyst will now ask the domain expert whether these two sentences are
allowed in combination.

Analyst: Dear domain expert; are following sentences allowed in

combination ?

Employee 0012 has the position of a manager

Employee 0013 has the position of a manager

Domain expert: Such a combination is allowed

The analyst can now conclude that this combination does not lead to a
uniqueness integrity rule.

We will now create a third sentence in which the value for the second role is
changed.

Employee 0012 has the position of a clerk

Analyst: Dear domain expert are following sentences allowed in

combination ?

Employee 0012 has the position of a manager

Employee 0012 has the position of a clerk

Domain expert: Such a combination is not allowed, because an employee can at

most have one position at a time (as is explicitly documented by
domain rule 3.4).

The analyst can now conclude that this combination leads to a uniqueness
integrity graphically defined on role r1. This uniqueness integrity rule (uc 1) is
the fact-based equivalent of domain rule 3.3 . In figure 4 we have shown fact
type FT1 with uniqueness integrity rule uc1.

3 It should be noted that the deep structure sentences can be easily recreated by filling in
the individual names into the fact type formulation (see figure 15).

9
 Figure 4: Fact type FT1 with uniqueness integrity rule

We can now generalize the procedure for deriving uniqueness integrity rules for
any fact type having an arity N. For each role in the fact type we have to create a
sentence instance in which the individual name occurence for that role is
changed. Each non-allowed combination of such a sentence with the first
sentence will lead to a uniqueness integrity rule on the other N-1 roles.

Let’s now analyze fact type FT2. Consider one allowed sentence from the fact
type population e.g.

The employee 0012 has the phone extension 3678 at work.

For the derivation of uniqueness integrity rules it is easy to refer to a sentence by

listing the individual names in the roles as follows:

0012 3678

We will now create a second sentence in which the value of the first role is
changed:

0013 3678

The analyst will now ask the domain expert whether these two sentences are
allowed in combination.

Analyst: Dear domain expert: are following sentences allowed in

combination ?

Employee 0012 has the phone extension 3678 at work

Employee 0013 has the phone extension 3678 at work

Domain expert: Such a combination is allowed

10
The analyst can now conclude that this combination does not lead to a
uniqueness integrity rule. We will now create a third sentence in which the value
for the second role is changed.

Employee 0012 has the phone extension 8768 at work

Analyst: Dear domain expert are following sentences allowed in

combination ?
Employee 0012 has the phone extension 3678 at work
Employee 0012 has the phone extension 8768 at work

Domain expert: Such a combination is not allowed, because an employee can at

most have one work phone extension at a time.

Now we have discovered a new domain rule:

Domain rule 3.10: Each employee has at most one company phone extension

We now have illustrated how the fact based uniqueness integrity rule protocol
can be used for ‘rule mining’, i.e. finding domain rules in a domain that are not
yet made explicit but that become visible when the domain experts are
confronted with combinations of fact instances that are not allowed to exist in
combination. The newly found domain rule 3.10 is mapped onto uniqueness
integrity rule uc2 in figure 5. Note that uniqueness integrity rule uc3 corresponds
with domain rule 3.4.

uc4 First name

FT4
R7 R8
<R7> has <R8>
uc5 Ft5 Last name
R9 R10

<R9> has <R10>

Figure 5 :Fact-based semantic conceptual model DEF example including all

uniqueness integrity rules.

11
Applying the Fact-Based Modeling Protocol: The DEF phone
directory example (part 2)
Let’s assume that following explicit documented domain rules hold in our example UoD

Domain rule 3.1: Each employee has a company phone extension

Domain rule 3.2: Each employee has a position.
Domain rule 3.3: Each employee has at most one position (at a time).
Domain rule 3.4: Each employee has at most one home phone extension listed in the phone book.
Domain rule 3.5: A work phone extension always consists of 4 digits.
Domain rule 3.6: A home phone extension always consists of 10 digits.
Domain rule 3.7: DEF currently knows senior manager, manager, clerk and secretary positions.
Domain rule 3.8: Each employee has at most one first name.
Domain rule 3.9: Each employee has at most one last name.
Domain rule 3.10: Each employee has exactly one company phone extension
Domain rule 3.11: At any moment in time a maximum of 15 people might be employed on a given
position

Let’s extend our DEF Universe of Discourse with the following example:

Positions that are entitled to a company car

Senior manager
Manager

Applying the Fact-Based modeling protocol on this example leads to the following verbalizations:

The position senior manager is entitled to a company car........................................(16)

The position manager is entitled to a company car...................................................(17)

We now can initially classify this sentence group (6) in variable and fixed parts.

|The position | senior manager | is entitled to a company car|.

|The position | senior manager | is entitled to a company car|.
fixed variable fixed

General classification structure of this sentence group:

fixed 1|variable1|fixed 2 |

Group 6:

the position with .......................................entity type

position name .....................................name class
Senior Manager Manager ........................individual name
is entitled to a company car ……………………………………..verb

We now notice that the extension of the UoD with this new example will lead to the addition of a unary
fact type (ft 6) to the conceptual schema for this UoD.

1
Step 7: Add other integrity rules:
7.1 Mandatory rule

In step 6 of the fact-based modeling methodology we derived the uniqueness rules for our knowledge
model. Another group of integrity rules is called mandatory (or non-empty) rule.

A mandatory rule is a rule defined on an entity type. The mandatory rule is defined on one role.
Each instance of an entity from the entity type must play the role on which the mandatory rule
is defined.

We will now derive the mandatory rule of the DEF phone book example. In this introductory skills
training we will only apply the definition of the mandatory rule on the specified business rules. In
Bollen (2011a, 2011b) the methodological support or protocol for the ‘mining’ of these mandatory rules
is provided. Domain rule 3.1 can be directly mapped as a mandatory role constraint mc2 defined on
role r3. Furthermore, domain rule 3.3 can be mapped onto a mandatory rule mc1 defined on role r1
(see figure 1).

mc3 mc4 uc4

mc2 First name
FT4
R7 R8
mc1
<R7> has <R8>
uc5 Ft5 Last name
R9 R10

<R9> has <R10>

uc6 Ft6
R11
<R11> is entitled to
a company car

Figure 1: FB conceptual model of DEF phone book example including mandatory rules.

2
7.2 Set comparison rules

Set comparison rules are defined on roles or role combinations that in which the same (combination)
of entity types play a role. Furthermore,set comparison rules are only relevant in cases where an entity
type performs more than one role in the conceptual schema. The first type of set comparison constraint
will be the subset rule.

7.2.1 Subset rule

We will now give the definition of a subset rule.

A subset rule is defined on two (ordered combinations of) roles having the same (ordered
combinations of) entity type(s). The subset rule enforces a subset relation between these role
(combination) populations.

In our DEF example we note that only for some of the positions a company car is entitled. This points
at the existence of a subset (set-comparison) rule sc1 in which the instance population of role R11 at all
times must be subset of the instance population of role R2 (note that both roles are played by the entity
type Position (see figure 2)).

7.2.2 Equality rule

We will now give the definition of a subset rule.

An equality rule is defined on two (ordered combinations of) roles having the same (ordered
combinations of) entity types. The equality rule enforces the set equality of these role
(combination) populations.

Let’s look once again at domain rules 3.8 and 3.9:

Domain rule 3.8: Each employee has at most one first name.
Domain rule 3.9: Each employee has at most one last name.

Suppose that an additional domain requirement is that if a first name is known for an employee there a
last name also must be known and the other way round (domain rule 3.12)

Domain rule 3.12: An employee has a first name and a last name OR no name at all.

We can model this requirement now as an equality rule ec1 between roles R7 and R9 (see figure 2)

7.2.3. Exclusion rule

We will now give the definition of the exclusion constraint.

An exclusion constraint is defined on two (ordered combinations of) roles having the same
(ordered combinations of) entity types. The exclusion rule enforces the disjunction of these role
(combination) populations.

If we refer once again to the business rules 3.5 and 3.7 from the DEF phone book example we can
conclude that the populations of roles R4 and R6 will always exclude one another (see figure 2).

3
 uc4 First name
FT4
R7 R8
mc2
ec1 <R7> has <R8>
0012 Jim
= 0013 Dave
0014 Jim
mc1 uc5 Ft5 Last name
R9 R10
<R9> has <R10>
0012 Jones
0013 Leary
0014 Jones
0012 Manager
0013 Manager
uc6 Ft6
0014 Clerk sc1
0015 Secretary
0016 Senior manager R11
<R11> is entitled to
a company car
Manager
Senior manager

ex1
0012 3678 0012 043-7869463
0013 3678 0013 043-7869551
0014 7896 0014 043-7869551
0015 1237 0015 050-2758439
0016 9434

Figure 2: DEF example including mandatory-, and set-comparison rules

7.2.4 Methodology for deriving set-comparison rules in a knowledge modeler-domain user

dialogue

FT1
FT1 FT1

xxxx
xxxx
a1 A
xxxx a1
a1 A A (ac ode)
(ac ode) (ac ode)

FT2
FT2 FT2

yyy
yyy yyy a1
a1
a2

(a) extension 1 (b) extension 2 (c) extension 3

Figure 3: Graphical fact-based presentation of extensions 1, 2 and 3 from set-comparison

algorithm.

4
We can now summarize the algorithm as a decision-table in which a given combination of allowed
existence or non-allowed existence of each of the example extensions as confirmed by the domain user
in an analyst-user dialogue leads to the detection of (at most) one set-comparison constraint (see table
2). We note that for the other 4 possible outcomes of the algorithm no set-comparison constraints will
be derived.

Table 2: Decision logic from the set-comparison rule derivation algorithm .

1 2 3 4
EXT1 Allowed Not Allowed Not Allowed Allowed
EXT2 Allowed Allowed Allowed Not Allowed
EXT3 Not Allowed Allowed Not Allowed Not Allowed
Set- Subset1 Subset2 equality exclusion
comparison (FT2 ≤ FT1) (FT1≤ FT2)
rule type

7.3 Value rule

A value rule defined on an entity type, constrains the possible occurences of such an entity type
to the values defined in the value rule.

Let’s review the domain rules again. The first domain rule that can lead to a value rule in the fact-
based conceptual schema is domain rule 3.5:

Domain rule 3.5: A work phone extension always consists of 4 digits.

We can model this as a value rule vc1 defined on role R4.

Next we run into domain rule 3.6:

Domain rule 3.6: A home phone extension always consists of 10 digits.

We can model this as a value rule vc2 defined on role R6

Now we consider domain rule 3.7.

Domain rule 3.7: DEF currently knows senior manager, manager, clerk and secretary positions.

Contrary to value constraints vc1 and vc2, domain rule 3.7 must be mapped onto a value rule that is
defined on an entity type, rather than on a specific role. So domain rule is now mapped as value rule
vc3 defined on the entity type Position (see figure 4).

5
7.4 Occurrence frequency rule

In this section we will introduce the occurence frequency rule (sometimes called cardinality rule).

Definition 7.4:

An occurence frequency rule defined on an individual role, constrains the number of times that a
specific value (or name) may occur in the role population.

This rule limits the total number of times that a specific value (or name) of an entity type or a name
type in a given role is allowed , it can be fixed, a minimum, a maximum or a range . Note that the
special case where the occurrence frequency or cardinality is 1 results an uniqueness rule defined on
that role.
When we inspect the domain rules for our DEF domain we run into domain rule 3.11:

Domain rule 3.11: At any moment in time a maximum of 15 people might be employed on a given
position

This domain rule can be mapped onto occurrence frequency rule of1 defined on role R2.

uc4 First name

FT4

mc3 mc4 R7 R8
mc2
ec1 <R7> has <R8>
0012 Jim
= 0013 Dave
vc3:[clerk, manager, secretary, 0014 Jim
mc1 senior manager] uc5 Ft5 Last name
of1:[1..15]
R9 R10
<R9> has <R10>
0012 Jones
0013 Leary
0014 Jones
0012 Manager
0013 Manager
uc6 Ft6
0014 Clerk sc1
0015 Secretary
0016 Senior manager R11
<R11> is entitled to
a company car
Manager
Senior manager

vc1:[0000, ...,9999] vc2: [0000000000, ...,

9999999999]

ex1
0012 3678 0012 043-7869463
0013 3678 0013 043-7869551
0014 7896 0014 043-7869551
0015 1237 0015 050-2758439
0016 9434

Figure 4:FB conceptual model of DEF example including value and occurrence frequency
rules.

6
7.5 General rule

Consider the conceptual schema in figure 4 in which fact types and integrity rules on the domain of
tax collecting are given.

Figure 5: conceptual schema including general rules

Further consider the following rule that governs this domain:

If a taxpayer has a work status of unemployed, the gross year income can never be more than
20.000,- guilders

In figure 5 we have added this domain rule as a general rule, by connecting the general rule code to the
roles that are involved in this rule and have phrased this rule in natural language sentences. A more
formal way of representing this general rule in a declarative way is:

FT1.R1(where FT1.R2=a)= ‘unemployed’  FT4.R8(where FT4.R7=a) =< ’20 000’

7
Step 8: Define concepts

Now we will give concept definitions of all the concepts identified as the result of step 4 of the
CogNIAM modeling procedure in our example: Employee, Employee ID, Phone extension at home,
Phone extension at work, Number, Position, Position name , First name and Last name plus the
concepts that are identified on the extension of our example UoD: entitled to, Company car.

Concept Definition
Employee a person that works for the DEF company
Employee ID a name class, instances of which can be used to identify an <Employee> among the collection
of <employees> that have ever been, are or will be working for the DEF company
Phone extension at home
a landline telephone that is located at the house of an <employee>
Phone extension at work
a landline telephone that is connected to the DEF company telephone network
Number a name class, instances of which can be used to identify a <phone extension at home> among the
union of <phone extensions at home> OR to identify a <phone extension at work> among the
union of <phone extensions at work>
Position The type of job that is performed by an <employee> in the DEF company
Position name a name class, instances of which can be used to identify a <position> among the collection of
<positions> at DEF company.
First name a name class
Last name a name class
Entitled to privilege of an <employee> based on <position>
Company car a specific privilege for an <employee>in specified <position>s

8
Nesting, Objectified association, Nominalization

Figure 6: conceptual schema inventory

In figure 6 we have given a fact type in which a ‘flat’ relationship between the entity types Year, Item
and Amount is verbalized as the following fact type form:

The inventory cost in the Ulster production site in year <r4> for item <r5> is the amount <r6>

Let’s assume that in this UoD a concept exists called planningitem which is expressed as the following
fact type form:

The planningitem referred to by year <R4> anno domino and item with itemcode <R5>.

In that case it is possible to phrase the original fact type form as foloows:

The inventory cost in the Ulster production site for planningitem <R7> will be the amount of <R8>
dollar/unit/year .

In figure 7 we have shown the diagrammization of this nominalization or objectification. We can

consider a nominalization as a special kind of entity type.

9
 Figure 7: Diagrammization of nominalized fact type (forms)

In essence a nominalization is a compound naming convention. Instead of having a specific name class
that identifies entities of a given entity type, we have a compound name (a.d and itemcode) that
identifies an instance of the nominalized concept (planningitem). We should remark, however, that
nominalizations or objectifications (or nesting as it is sometimes called) should only be applied when
the nested or nominalized concept exists in the domain. Splitting of objectfications only for the sake of
splitting of should not take place. In the example in figure 7 this nominalization is rooted in a domain
concept planningitem.

10
 A Primer on Derivation Rules in Fact-Based Modeling

Peter Bollen
Department of Organization & Strategy
SBE
Maastricht University

Let’s consider following example of communication (see figure 1).

HARDY'S RESTAURANT

0089 12-04-2016

beer $ 2,--
cheeseburger $ 2,50
-------
total $ 4,50

Figure 1: sales receipt

The input document is an order receipt for Hardy's Restaurant. We will further assume that we have a
human processor: the accountant of Hardy's Restaurant. Every month this human processor creates a
document of the type monthly sales sheet (see figure 2).

HARDY'S-RESTAURANT SALES SHEET

MONTH: April 2016

Day Turnover Day Turnover Day Turnover

1 $ 345,-- 11 $ 221,50 21 $110,34
2 $ 678,-- 12 $567,12 22 $ 56,--
3 $ 456,-- 13 $445.-- 23 $123,45
4 $ 339,56 14 $899,-- 24 $113,--
5 $ 899,67 15 $ 78,-- 25 $ 34,50
6 $ 786,55 16 $234,90 26 $450,--
7 $ 567,45 17 $ 55,-- 27 $ 65,--
8 $ 347,-- 18 $600,-- 28 $500,--
9 $ 234,-- 19 $ 450,-- 29 $ 50,--
10 $ 455,-- 20 $ 475,-- 30 $ 250,--

Figure 2: monthly sales sheet

documents of the order receipt types are transformed into documents of the monthly sales sheet type.
We will illustrate the content of the instructional document in figure 3.

Take all order receipts for a given month.

Add up the order total on a day to day base
Starting on day 1 of the month and ending
on the last day of the month (day 28, 29,
30 or 31).

Figure 3: instructional document

In figure 4 the conceptual model for this example is shown.

Figure 4: Knowledge model hardy's restaurant example

Derivation rules

The first derivation rule is the derivation rule in which the order total is derived from the amounts on
the individual order lines. In the terminology of the information grammar we can say that for a given
Receipt (R4) the total sales amount (R4) is equal to the sum (R3) over all order lines (R2) for the given
receipt (R1). We will use the following shorthand notation for this derivation rule DR1:

DR1: FT2.<R5>[where FT2.<R4>='x']:=SUM(FT1.<R3>[where FT1.<r1>= 'x']).

The second derivation rule is the derivation rule in which the order total is derived from the amounts
on the individual order lines. In the terminology of the information grammar we can say that for a given
Day (R10) the total sales amount (R11) is equal to the sum (R5) over all receipts (R4). We will use the
following shorthand notation for this derivation rule DR2:

DR2: FT4.<R11>[where FT4.<R10>='x'] := SUM(FT2.<R5>[where FT2.<R4>= 'x'])

 uc9
Ft9
R18 R19
<R18> has as net order cost <R19>
Money amount
in euros
uc8 (decimal number)
gc2 gc2 Ft8 * dr1
R16 R17
uc10
<R16> has as transportation fee <R17>
Ft10
R19 R20
uc7
<R20> has as shipment destination <r19> Ft7 * dr 2
R14 R15
City <R14> has as a total shipment value <R15>
(city name)
Transaction Organization
tc1 gc2 gc2 uc1 (transaction code) (organization ID)
mc7 uc2
Ft1 mc5 Ft2
mc1 mc6 mc4
R1 R2 R3 R4
gc1, gc2 mc8 mc3
<R2> has as shipment origin<r1> <R3> has as supplier <R4>
gc1, gc2 mc9 mc2
Distance factor x ec3
uc9 (natural number) uc3
Ft4 Ft3
R7 R8 R9 R5 R6
The distance factor between <R5> has as customer <R6>
<R7> and <R8> is <R9>
Package Size
uc5 (package size code)
Ft5
vc1:[A,B]
R10 R11
The shipment in <R10> has as <R11>
Transportation priority
(transporation priority code)
uc6
Ft6
R12 R13
The shipment in <R12> has as <13>
vc2:[regular, overnight]
Gc1: a combination of 2 cities can only appear once in roles r7 and r8 regardless of order

Tc1 can be replaced by Gc2:

Gc2: For every tranasction the city in role R19 and the city in role R1 must be contained as an
instance of R7 and r8 or r8 and r7.

Dr1: ft8.r17:= X (where Ft8.r17=’a’)

IF[ ft5.r11 = A (where ft5.r10=’a’) AND f6.r13= overnight (where ft6.r10=’a’)]

THEN X:=Ft4.R9 (where ft4.R7/R9=Ft1.R1/Ft10.R19)*16
ELSE IF[ ft5.r11 = A (where ft5.r10=’a’) AND f6.r13= regular (where ft6.r10=’a’)]
THEN X:=Ft4.R9 (where ft4.R7/R9=Ft1.R1/Ft10.R19)*8
ELSE IF[ ft5.r11 = B (where ft5.r10=’a’) AND f6.r13= overnight (where ft6.r10=’a’)]
THEN X:=Ft4.R9 (where ft4.R7/R9=Ft1.R1/Ft10.R19)*30
ELSE X:=Ft4.R9 (where ft4.R7/R9=Ft1.R1/Ft10.R19)*15

Dr2: Ft7.R15 (where Ft7.R14=’b’):= Ft8.r17 (where ft9.r18=’b’)

+Ft9.r19 (where ft9.r18=’b’)

List of concept definitions

Transaction A business agreement between a supplier <organization> and customer

<organization>
Transaction code A name class instances of which can identify a specific <transaction>
among the set of all <transactions>
City Point of origin or destination of a package that is sent as a result of a
<transaction>
City name A name class instances of which can identify a specific <city>
among the set of all <cities>
Money Amount in euros A quantity that refers to money.
Decimal number A name class instances of which can identify a specific <money amount
in euros> among the set of all <money amounts in euros>
Organization A member of a consortium
Organization ID A name class instances of which can identify a specific <organization>
among the set of all <organizations> within a <consortium>

Package size An indicator of the volume of package.

Package size code A name class instances of which can identify a specific <package size>
among the set of all <package sizes>

Transportation priority An indicator of the speed in which a package in a given <transaction.

should be delivered
Transportation priority code A name class instances of which can identify a specific
<transportation priority> among the set of all <transportation priorities>

Distance factor An indicator of the relative distance between two <cities>

Natural number A name class instances of which can identify a specific <distance
factor> among the set of all <distance factors>