On the flight back from the AMWeek I realized that if you cannot get any information from the source about when changes occur (and no delta files), then bi-temporality will not solve the ABA problem. The only solution is to go back to the source and try to get information about when changes occur. If that is possible, then using only valid time will suffice.
You will then in an anchor database, while waiting for (late arriving) asynchronous information, have something like:
<#2, ‘Green’, 2001, #23>
<#2, ‘Green’, 2004, #56>
Here you rely on the source having told you that the second row is a change, even if your current information says otherwise. The metadata for #23 tells you that this information was loaded in 2002, the metadata for #56 tells you that this information was loaded in 2004.
At some point in time (after 2004) you will hopefully get the missing piece of information and the rows become:
<#2, ‘Green’, 2001, #23>
<#2, ‘Blue’, 2003, #98>
<#2, ‘Green’, 2004, #56>
The metadata for #98 tells you that this information was loaded in 2005. Using ‘changing time’ I can reconstruct the order of the changes, where changing time must come from the source. Using ‘recording time’ I can reconstruct the order in which the database was given the information, which is in a different order.
