Databases Reference
In-Depth Information
indicated object, or to extend an existing episode into effective
time clock ticks that it does not yet occupy. And analogously to
entity integrity in non-temporal tables, the user is tacitly agree-
ing that if an episode of the same object already exists in the tar-
get table and if its effective and assertion time periods have any
clock ticks in common with the time periods targeted by the
transaction, the transaction should be rejected. The user is
telling the Asserted Versioning Framework “I believe that this
table does not contain any row or rows for this object that
already represent the object in even a single clock tick that is
specified on the transaction. So if I'm wrong, I don't want the
transaction to proceed. I want you to kick out the transaction,
and notify me.”
Next, let's consider update and delete transactions. By a simi-
lar process of reasoning, we can see that in submitting either
type of transaction, the user is telling the Asserted Versioning
Framework “I believe that the table does contain one or more
rows for this object with one or more clock ticks that [
intersect
]
the clock ticks specified on this transaction. So if I'm wrong, I
don't want the transaction to proceed. I want you to kick out
the transaction, and notify me.”
One Clock Tick: Convention or Constraint?
Given two rows representing the same object, there are three
temporal relationships between them that are distinguishable by
means of a single clock tick. First, if there is even a single clock
tick between the end of one and the start of the next, then they
are non-contiguous. In Allen relationship terms, one is [before]
the other. Next, if there is even a single clock tick that is
contained in both their time periods, then they [intersect].
Finally, if neither is the case, then they are contiguous. In Allen
relationship terms, they [meet].
Two versions of the same object that are non-contiguous may
exist in the same target table at the same time. But if they do,
they necessarily belong to different episodes. And if one of those
versions is the only version of that object already in the target
table and the other is a transaction, that transaction cannot be
an update. If it were an update transaction, it would be equiva-
lent to attempting a conventional update when there was no
row for that object already in the target table. By the same token,
if one of those versions is in the target table and the other is a
transaction, that transaction cannot be a deletion.
Two versions of the same object that [
intersect
], in both effec-
tive and assertion time, cannot exist in the same target table at
