The
main issue is with respect to late arriving temporal reference data
that has a retrospective impact on objects of Type 2.
For instance take the dimensional object address presented in a temporal view
|
Account no |
Address |
Startpoint |
DHkey |
Generation |
endpoint |
|
1 |
1 Acacia Avenue |
01/01/2000 |
c4ca4238a0b923820dcc509a6f75849b |
1 |
01/02/2010 |
|
2 |
7 Block Lane |
01/01/2000 |
c81e728d9d4c2f636f067f89cc14862c |
1 |
|
|
1 |
101 High Street |
02/02/2010 |
c4ca4238a0b923820dcc509a6f75849b |
2 |
|
|
3 |
No Fixed Abode |
02/03/2010 |
eccbc87e4b5ce2fe28308fd9f2a7baf3 |
1 |
02/04/2011 |
|
3 |
12 Acme Road |
03/04/2011 |
eccbc87e4b5ce2fe28308fd9f2a7baf3 |
2 |
|
According to the data received so far account 1 changed address on 02/02/2010
So a typical fact object may resolve to the following dataset for account 1
|
AccDHKey |
AccDHGen |
Tax point |
|
invoice |
Value |
|
c4ca4238a0b923820dcc509a6f75849b |
1 |
01/01/2010 |
|
1 |
100 |
|
c4ca4238a0b923820dcc509a6f75849b |
1 |
01/02/2010 |
|
2 |
20 |
|
c4ca4238a0b923820dcc509a6f75849b |
2 |
01/03/2011 |
|
3 |
30 |
|
c4ca4238a0b923820dcc509a6f75849b |
2 |
01/04/2011 |
|
4 |
50 |
|
c4ca4238a0b923820dcc509a6f75849b |
2 |
01/05/2011 |
|
5 |
70 |
|
c4ca4238a0b923820dcc509a6f75849b |
2 |
01/06/2011 |
|
6 |
30 |
But let us say that on the 02/06/2011 we receive late arriving referential data that suggests that account 1 changed address again on the 30/04/2011.
This would be a problem as the address object would now be
|
Account no |
Address |
Startpoint |
DHkey |
Generation |
|
1 |
1 Acacia Avenue |
01/01/2000 |
c4ca4238a0b923820dcc509a6f75849b |
1 |
|
1 |
101 High Street |
02/02/2010 |
c4ca4238a0b923820dcc509a6f75849b |
2 |
|
1 |
52 Festive Road |
30/04/2011 |
c4ca4238a0b923820dcc509a6f75849b |
3 |
The temporal view of this object would therefore be
|
Account no |
Address |
Startpoint |
DHkey |
Generation |
endpoint |
|
1 |
1 Acacia Avenue |
01/01/2000 |
c4ca4238a0b923820dcc509a6f75849b |
1 |
01/02/2010 |
|
1 |
101 High Street |
02/02/2010 |
c4ca4238a0b923820dcc509a6f75849b |
2 |
29/04/2011 |
|
1 |
52 Festive Road |
30/04/2011 |
c4ca4238a0b923820dcc509a6f75849b |
3 |
|
This
would have no impact if presented as a Type 1.
However if presented as a Type 2 the references would be incorrect
|
AccDHKey |
AccDHGen |
Tax point |
|
invoice |
Value |
|
c4ca4238a0b923820dcc509a6f75849b |
1 |
01/01/2010 |
|
1 |
100 |
|
c4ca4238a0b923820dcc509a6f75849b |
1 |
01/02/2010 |
|
2 |
20 |
|
c4ca4238a0b923820dcc509a6f75849b |
2 |
01/03/2011 |
|
3 |
30 |
|
c4ca4238a0b923820dcc509a6f75849b |
2 |
01/04/2011 |
|
4 |
50 |
|
c4ca4238a0b923820dcc509a6f75849b |
2 |
01/05/2011 |
|
5 |
70 |
|
c4ca4238a0b923820dcc509a6f75849b |
2 |
01/06/2011 |
|
6 |
30 |
Invoices
5 and 6 will be related to the ‘wrong’ address or rather the most
up to date address at process time.
Really the only practical solution to this is to identify the fact objects that are related to this dimensional object
Identify the keys that have been effected and reprocess those fact instances – or update the generation on the fact object for said instances.