The basic versioning (generational) strategy works extremely well in all respects for object relationships considered as Type 1.
High performance builds without lookups.
High performance resolution of object relationships during target audience queries.
High fidelity replication of keys.
Complete referential integrity.
Simple exception reporting.
Simple dimensional object maintenance.
Retention of history
However this is not all true for object relationships considered to be of Type 2 or of a temporal nature.
An extension of the model could be considered.
Use of the epoch as a generation has some advantages with regard to temporal dimension objects and very late arriving referential data that would split an existing generation rather than simply being the latest.
Taking the dimensional object
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 |
2 |
7 Block Lane |
01/01/2000 |
c81e728d9d4c2f636f067f89cc14862c |
1 |
3 |
DUMMY |
02/03/2010 |
eccbc87e4b5ce2fe28308fd9f2a7baf3 |
0 |
3 |
10 Upping Street |
01/03/2010 |
eccbc87e4b5ce2fe28308fd9f2a7baf3 |
1 |
Using epoch as generation
Account no |
Address |
Startpoint |
DHkey |
Generation |
1 |
1 Acacia Avenue |
01/01/2000 |
c4ca4238a0b923820dcc509a6f75849b |
946684800 |
1 |
101 High Street |
02/02/2010 |
c4ca4238a0b923820dcc509a6f75849b |
1265068800 |
1 |
52 Festive Road |
30/04/2011 |
c4ca4238a0b923820dcc509a6f75849b |
1301785200 |
2 |
7 Block Lane |
01/01/2000 |
c81e728d9d4c2f636f067f89cc14862c |
946684800 |
3 |
DUMMY |
02/03/2010 |
eccbc87e4b5ce2fe28308fd9f2a7baf3 |
0 |
3 |
10 Upping Street |
01/03/2010 |
eccbc87e4b5ce2fe28308fd9f2a7baf3 |
1267401600 |
Note that Dummies are still identifiable by generation 0
Lets say we receive a reference to account 1 changing address on 01/11/2010 for some reason we failed to receive this reference at the time so have to handle it retrospectively.
Account no |
Address |
Startpoint |
DHkey |
Generation |
1 |
1 Acacia Avenue |
01/01/2000 |
c4ca4238a0b923820dcc509a6f75849b |
946684800 |
1 |
101 High Street |
02/02/2010 |
c4ca4238a0b923820dcc509a6f75849b |
1265068800 |
1 |
52 Festive Road |
30/04/2011 |
c4ca4238a0b923820dcc509a6f75849b |
1301785200 |
1 |
62 West Wallaby Street |
01/11/2010 |
c4ca4238a0b923820dcc509a6f75849b |
1288569600 |
The epoch as a generation has the advantage of the reference instance being inserted in the correct generation order of change.
An additional consideration of this strategy is that the epoch granularity can be reduced dependent on the temporal granularity of the dimensional object so for instance if the granularity is day (date) then simply dividing the epoch by 86400
e.g. 1288569600 becomes 14914