A hierarchical role structure exists which consists of 4 roles O1, O2, O3,and O4. Employee X is assigned to roles O1, O4, and O3. The assignment of software to roles is depicted in the following.
Figure 30: Role structure as in the example above
Three processes run between two DBQueue Processor runs, each with its own GenProcID:
-
P1: Software application A1 is assigned to the role O1
-
P2: Software application A2 is assigned to the role O1
-
P3: Software application A3 is assigned to the role O2
The following operations are in the DBQueue (DialogDBQueue table) and in the process information:
Operation | Object | GenProcID |
---|---|---|
OrgHasApp |
O1 |
P1 |
OrgHasApp |
O1 |
P2 |
OrgHasApp |
O2 |
P3 |
The operation OrgHasApp cannot be subdivided with respect to O1 because the union of software applications is being calculated for O1. At this point, no more information is available as to which GenProcID has been entered by the assignment for which software application.
In order to achieve uniqueness for the combination of operation and object, a new GenProcID P4 is introduced and the two O1 operations are compacted into this GenProcID. P1 and P2 are noted in the DialogProcessSubstitute table as possible predecessors of P4 (but not clearly in the individual actions).
Operation | Object | GenProcID |
---|---|---|
OrgHasApp |
O1 |
P4 |
OrgHasApp |
O2 |
P3 |
The following constellations can occur depending on whether the operation OrgHasApp is processed as a single step or in bulk:
- Case 1) O1 is calculated and then O2.
- Case 2) O2 is calculated and then O1.
- Case 3) O1 and O2 are calculated together simultaneously in a bulk operation.
After these operations have been run and assuming that they all cause changes to the total sets affected, the following situation arises:
Case 1) O1 is calculated and then O2.
Operation | Object | GenProcID |
---|---|---|
OrgHasApp |
O2 |
P3 |
OrgHasApp |
O4 |
P4 |
OrgHasApp |
O2 |
P4 |
OrgHasApp |
O3 |
P4 |
PersonHasApp |
X |
P4 |
Before the next DBQueue Processor run, the GenProcID’s must be compressed again, because the OrgHasApp operation did not produce a unique result for the object O2. P5 is introduced with possible predecessors P4 and P3.
Operation | Object | GenProcID |
---|---|---|
OrgHasApp |
O2 |
P5 |
OrgHasApp |
O4 |
P4 |
OrgHasApp |
O3 |
P4 |
PersonHasApp |
X |
P4 |
Now the calculation is done for O2:
Operation | Object | GenProcID |
---|---|---|
OrgHasApp |
O3 |
P5 |
PersonHasApp |
X |
P5 |
OrgHasApp |
O4 |
P4 |
OrgHasApp |
O3 |
P4 |
PersonHasApp |
X |
P4 |
Because O3 is not unique, P6 is introduced with possible predecessors P4 and P5.
Operation | Object | GenProcID |
---|---|---|
OrgHasApp |
O3 |
P6 |
PersonHasApp |
X |
P5 |
OrgHasApp |
O4 |
P4 |
PersonHasApp |
X |
P4 |
After O3 and O4 have been calculated, the following situation exists:
Operation | Object | GenProcID |
---|---|---|
PersonHasApp |
X |
P6 |
PersonHasApp |
X |
P5 |
PersonHasApp |
X |
P4 |
There is no uniqueness for object X such that P7 is introduced with possible predecessors P4, P5 and P6.
Case 2) O2 is calculated and then O1.
Operation | Object | GenProcID |
---|---|---|
OrgHasApp |
O1 |
P4 |
OrgHasApp |
O2 |
P3 |
After running, the following entries are in the DBQueue:
Operation | Object | GenProcID |
---|---|---|
OrgHasApp |
O1 |
P4 |
OrgHasApp |
O3 |
P3 |
The following situation is the result after the next step:
Operation | Object | GenProcID |
---|---|---|
OrgHasApp |
O3 |
P3 |
OrgHasApp |
O4 |
P4 |
OrgHasApp |
O2 |
P4 |
OrgHasApp |
O3 |
P4 |
PersonHasApp |
X |
P4 |
To achieve uniqueness for O3 a process P5 with possible predecessors P3 and P4 is created:
Operation | Object | GenProcID |
---|---|---|
OrgHasApp |
O3 |
P5 |
OrgHasApp |
O4 |
P4 |
OrgHasApp |
O2 |
P4 |
PersonHasApp |
X |
P4 |
After the calculations, the following situation exists:
Operation | Object | GenProcID |
---|---|---|
PersonHasApp |
X |
P5 |
PersonHasApp |
X |
P4 |
There is no uniqueness for object X such that P6 is introduced with possible predecessors P4 and P5.
Case 3) O1 and O2 are calculated together simultaneously in a bulk operation.
Operation | Object | GenProcID |
---|---|---|
OrgHasApp |
O1 |
P4 |
OrgHasApp |
O2 |
P3 |
After the first step in the calculation the following entries are in the DBQueue:
Operation | Object | GenProcID |
---|---|---|
OrgHasApp |
O4 |
P4 |
OrgHasApp |
O2 |
P4 |
OrgHasApp |
O3 |
P4 |
OrgHasApp |
O3 |
P3 |
PersonHasApp |
X |
P4 |
Uniqueness is achieved for O3 by introducing P5 with possible predecessors P3 and P4:
Operation | Object | GenProcID |
---|---|---|
OrgHasApp |
O4 |
P4 |
OrgHasApp |
O2 |
P4 |
OrgHasApp |
O3 |
P5 |
PersonHasApp |
X |
P4 |
After the next step in the calculation, the following content is found
Operation | Object | GenProcID |
---|---|---|
OrgHasApp |
O3 |
P4 |
PersonHasApp |
X |
P4 |
PersonHasApp |
X |
P5 |
After O3 has been calculated in the next run and has not created a new PersonHasApp entry, only X exists with P4 and P5 because X already exists with P4.
Operation | Object | GenProcID |
---|---|---|
PersonHasApp |
X |
P4 |
PersonHasApp |
X |
P5 |
There is no uniqueness for object X such that P6 is introduced with possible predecessors P4 and P5.