Databases Reference
In-Depth Information
period that ended on February 2010 or earlier because that insert
would not result in a time period that [
intersected
] any time
period for P861 already in the target table.
Sometimes we have no open episode of an object, but we
may want to
wake up
the latest closed episode and change it
to an open episode. It is only the latest episode of an object that
can be transformed into an open episode, of course, because if it
were not the latest, it would then collide with the next later epi-
sode and thus violate the TEI constraint.
So if a temporal insert specifies a 12/31/9999 end date, and
no effective begin date is provided, the target span is [Now() -
12/31/9999]. An insert with this target timespan will wake up
an existing episode of an object only if (i) there is a closed epi-
sode of the object already in the target table, and its effective
end date is Now() (a situation which is very unlikely to occur
when timestamps rather than dates are used to specify temporal
parameters); and (ii) there are no representations of the object
which begin in future effective time. So we cannot wake up a
closed episode unless we supply an effective begin date on an
insert transaction which matches the effective end date of an
existing episode, and there are no other episodes of that object
in later effective time.
Waking up a closed episode is a special case of the {lengthen
episode forwards} transformation. But in every case, what the
user must do to lengthen an episode forwards is to specify a
target span whose effective begin date matches the effective
end date of the last version of a closed episode, and whose
effective end date does not [intersect] that of the next later epi-
sode of that object, if there is one. In this latter case, the
episode is {lengthened forwards} because an unknown end
date (represented by 12/31/9999) is replaced by a known end
date.
The Temporal Update Transaction
The format of a temporal update transaction is as follows:
UPDATE {tablename} [,,, ] eff_beg_dt, eff_end_dt, asr_beg_dt
The validity checks work like this:
(i) No
oid
, no business key, business key is reliable. In this
case, the AVF rejects the update. The reason is that an
update must attempt to find a match, and must be
rejected if it cannot make that attempt. Lacking both an
oid
and a reliable business key, the transaction cannot be
matched to what is already in the target table.
