Account no |
Address |
Startpoint |
DHkey |
Generation |
endpoint |
3 |
DUMMY |
02/03/2010 |
eccbc87e4b5ce2fe28308fd9f2a7baf3 |
0 |
14668 |
3 |
10 Upping Street |
01/03/2010 |
eccbc87e4b5ce2fe28308fd9f2a7baf3 |
14669 |
|
In the above derived object we can see that the Dummy record created by an orphaned event or fact instance was created with a start point of 02/03/2010 – this would be due to the event instance having a timestamp of 02/03/2010 or this being the point in time that the orphaned event was first encountered. This is entirely dependent on the data requirements and data source.
Subsequently the reference for account 3 was received with a start point of 01/03/2010.
As the Dummy always has a generation of 0 we can see that the correct reference – although arriving late overrides the dummy for the time period due to the genuine reference having a generation derived from the epoch of its start point.
This is a viable option whenever the reference source has a specific and identifiable start point.
It may be the case that the source of the reference data does not have a start point that can be identified and under these circumstances the load point in time is used as a start point. That is to say the reference instance is valid from the point in time corresponding to its first appearance.
So let us say that the valid reference for account 3 arrived on the 03/03/2010 and we do not have the luxury of a sourced start point – thus we use the load point as a start point.
Account no |
Address |
Startpoint |
DHkey |
Generation |
endpoint |
3 |
DUMMY |
02/03/2010 |
eccbc87e4b5ce2fe28308fd9f2a7baf3 |
0 |
14670 |
3 |
10 Upping Street |
03/03/2010 |
eccbc87e4b5ce2fe28308fd9f2a7baf3 |
14671 |
|
Clearly this derived view is not desirable as the event that resulted in the creation of the dummy instance will not now realign with the genuine late arriving reference.
In a case like this we would revert to protocol of the first genuine reference having a generation of 1.
We then have a derived object as follows
Account no |
Address |
Startpoint |
DHkey |
Generation |
endpoint |
3 |
DUMMY |
02/03/2010 |
eccbc87e4b5ce2fe28308fd9f2a7baf3 |
0 |
0 |
3 |
10 Upping Street |
03/03/2010 |
eccbc87e4b5ce2fe28308fd9f2a7baf3 |
1 |
|
So in this case all event instances with a matching key would relate to the generation 1 instance for account 3 – being that the generation of the event would be far greater than one (unless the event point in time tended towards January 1 1970) .
Any subsequent instance encountered for account 3 would naturally have their epoch derived generation and would thus provide a genuine endpoint going forward.
Account no |
Address |
Startpoint |
DHkey |
Generation |
endpoint |
3 |
DUMMY |
02/03/2010 |
eccbc87e4b5ce2fe28308fd9f2a7baf3 |
0 |
0 |
3 |
10 Upping Street |
03/03/2010 |
eccbc87e4b5ce2fe28308fd9f2a7baf3 |
1 |
15154 |
3 |
124 Conch Street |
01/07/2011 |
eccbc87e4b5ce2fe28308fd9f2a7baf3 |
15155 |
|