Tài liệu Managing time in relational databases- P12 pdf

If the user happens to know the effective end date for an episode of an object she is creating, she can specify this date on the temporal insert, as long as it is at least one clock tick

Another aspect of the semantics of a temporal insert is the interpretation of its target span If the transaction does not sup-ply an effective end date, that date defaults to 12/31/9999 The result is that an open episode will be created However, in the scenario shown in Figure 9.6, an open episode cannot be cre-ated, and the AVF will reject the attempt to create one For if

we tried to create an open episode with an effective begin date prior to version 7, that new episode would collide with one of the three episodes shown, and thus violate the temporal entity integrity (TEI) constraint And if we tried to create an open epi-sode, or in fact any epiepi-sode, with an effective begin date on or after May 2013, it would collide with Episode C, whose effective end date is 12/31/9999

It follows that there can be at most one open episode for an object, within any period of assertion time No episode, open

or closed, can be created later than an open episode because if

it were created, it would occupy effective time already occupied

by that open episode And an open episode cannot be created earlier than any other episode, open or closed, for the same reason

What of a temporal insert that specifies a non-12/31/9999 effective end date? Here the situation is more straightforward Such transactions satisfy TEI just in case none of the clock ticks specified in the transaction’s target span are already occupied by that object And we should remember that because of our closed-open convention, TEI will still be satisfied if an episode already exists whose begin date has the same value as the end date of the transaction’s target span, or one whose end date has the same value as the begin date of the transaction’s target span, or if both such episodes are present

The Temporal Insert Transaction: Mechanics

The scope of a conventional insert is a single row in the target table If the transaction is successful, the result is a new row added to the table The scope of a temporal insert is a designated period of effective time, within current assertion time So, in Figure 9.6, that scope cannot include any of the clock ticks already occupied by any of the three episodes shown there, but can include any other clock ticks We should note that this means that the scope of the insert cannot be any clock tick from May 2013 forward Since Episode C is open, it extends to 12/31/ 9999; consequently any other episode for the same object any-where in the effective period starting with May 2013 would [intersect] that episode

So a temporal insert of P861, given the state of the target table

shown in Figure 9.6, can have an effective begin date which is

any clock tick not occupied by any of the three episodes What,

then, of the effective end date? With a basic scenario temporal

insert, both the effective begin and end dates are left to take on

their default values which are, respectively, the date current

when the transaction is applied, and 12/31/9999 But just as

the effective begin date can be overridden on a transaction, so

too can the effective end date

What this means is that when a new episode is created, it

does not need to be created as an open episode If the user

happens to know the effective end date for an episode of an

object she is creating, she can specify this date on the temporal

insert, as long as it is at least one clock tick later than the

effec-tive begin date, and does not [intersect] a time period already

occupied by another episode of the same object

In the scenario shown inFigure 9.6, in fact, a temporal insert

would have to specify an effective end date The reason is that no

matter what the effective begin date is, an effective end date of

12/31/9999 would [intersect] one of the episodes already in the

table

For example, a temporal insert could place a new episode

between the second two episodes, but given that our clock ticks

only once a month, it would be a tight fit In fact, there are only

three possibilities They are:

(i) P861[Feb 2013 – Mar 2013]

(ii) P861[Feb 2013 – Apr 2013]

(iii) P861[Mar 2013 – Apr 2013]

There are four ways in which Episode B could be {lengthened

forwards}, the last listed of which would {merge} it with Episode

C They are:

(i) P861[Jan 2013 – Feb 2013]

(ii) P861[Jan 2013 – Mar 2013]

(iii) P861[Jan 2013 – Apr 2013]

(iv) P861[Jan 2013 – May 2013]

And there are also four ways in which Episode C could be

{lengthened backwards}, the first listed of which would {merge}

it with Episode B They are:

(i) P861[Jan 2013 – May 2013]

(ii) P861[Feb 2013 – May 2013]

(iii) P861[Mar 2013 – May 2013]

(iv) P861[Apr 2013 – May 2013]

As we said earlier, no temporal insert would be valid that

spe-cified an effective time period of May 2013 or later However, any

temporal insert would be valid that specified an effective time

Chapter 9 AN INTRODUCTION TO TEMPORAL TRANSACTIONS 205

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

(ii) No oid, no business key, business key is not reliable In

this case, the AVF rejects the update, for the same reason

as for case (i)

(iii) No oid, business key present, business key is reliable In

this case, the AVF looks for a match on the business key

If it finds one, it assigns the oid of the matching row to

the transaction Otherwise, it rejects the transaction The

reason is that reliable business keys are unique identifiers

of objects, and that, because all temporal insert

trans-actions to tables with reliable business keys must have a

business key on the transaction, all existing rows for the

same object will contain that reliable business key This

means that a temporal update with a non-matching

reli-able business key is just like a conventional update which

cannot match a primary key It is a mistaken update

(iv) No oid, business key present, business key is not reliable

In this case, the AVF rejects the update The reason is that if

the business key isn’t reliable, it doesn’t matter if it’s there or

not, and so the AVF proceeds as though the business key

were not there Note that if we did attempt a match on

the business key, and were successful, we might or might

not have the right oid to assign to the transaction We can’t

be sure because the AVF can’t guarantee that an unreliable

business key value is not being used by two or more oids

If we use a match on a business key that may be associated

with several different objects, then unless we have an oid

supplied by the transaction itself, we have no way of

know-ing which oid is the correct target of the transaction

(v) Oid present, no business key, business key is reliable In

this case, the AVF looks for a match on the oid If it finds

one, it accepts the transaction Otherwise, it rejects it

The reason is obvious Note that, unlike inserts, updates

to tables with reliable business keys are not required to

have the business key on the transaction

(vi) Oid present, no business key, business key is not reliable

In this case, the AVF looks for a match on the oid If it finds

one, it accepts the transaction Otherwise, it rejects it

(vii) Oid present, business key present, business key is

reli-able In this case, the AVF looks for a match on the

busi-ness key If it finds a match, and the oid of the matching

row matches the oid on the transaction, the AVF accepts

the transaction If it finds a match, but the oid of the

matching row does not match the oid on the transaction,

the AVF rejects the transaction If it does not find a match,

and the oid on the transaction does not match any oid

Chapter 9 AN INTRODUCTION TO TEMPORAL TRANSACTIONS 207

already in use, the AVF rejects the transaction And if it does not find a match, but the oid on the transaction does match an oid already in use, the AVF rejects the transac-tion The reason behind all this logic is that when both

an oid and a reliable business key are present, any conflict makes the transaction invalid; and when a temporal update has an oid and business key that do agree, but that

do not match anything on the target table, the temporal update fails the match, and is rejected

(viii) Oid present, business key present, business key is not reli-able In this case, the AVF attempts to match on the oid If it does, it accepts the transaction, and otherwise rejects it Note that if the business key is a new one, then when the transaction is applied, it assigns a new business key to an object, in clock ticks already occupied by that object

The Temporal Update Transaction: Semantics

In a conventional table, if an object is represented and the user wishes to modify the row doing the representing, she issues an update transaction which overwrites the data to be changed with the data that changes it The update transaction expresses not only her intentions, but also her beliefs and assumptions It expresses her intention to update a representation of an object, but it also expresses her belief that such a representation already exists If she is mistaken in her belief, her transaction is rejected, which is precisely what she would expect and want to happen

In an asserted version table, the question is not whether or not the object is already represented, but rather whether or not the object is already represented, in current assertion time, within the effective-time target span indicated on the transaction If the user submits a temporal update transaction, she also expresses both intention and belief Her intention is to modify a currently asserted representation of an object in every clock tick within the target effective timespan Her belief is that such a representa-tion already exists in at least one clock tick within that target span

If she is mistaken in her belief, her transaction is rejected, which

is precisely what she would expect and want to happen

The Temporal Update Transaction: Mechanics

Here are some examples that will illustrate how this interpre-tation of the target timespans on temporal update transactions works Consider a temporal update with a [Nov 2011 – 12/31/ 9999] target timespan This update affects all versions in

Episodes B and C shown inFigure 9.6 A temporal update with

an [Apr 2012 – Oct 2013] scope affects entire versions, but partial

episodes It will update versions 5–7, i.e the last two versions of

Episode B and the first version of Episode C

For our final example, let’s consider an update that affects

partial versions Suppose that the temporal update specifies a

target span of [Jan 2012 – May 2012] January 2012 is the third

clock tick within version 3, and is not the last clock tick within

that version So the AVF must split version 3 into two versions,

the first covering [Nov 2011 – Jan 2012] and the second covering

[Jan 2012 – Mar 2012] Call these two versions 3a and 3b,

respec-tively In just the same way, the AVF must split version 5 into

versions 5a and 5b Version 5a’s effective target span is [Apr

2012 – May 2012], and 5b’s is [May 2012 – Aug 2012]

Versions 3, 4 and 5 are then withdrawn into past assertion

time Versions 3a and 5b replace the unaffected parts of versions

3 and 5, in current assertion time Finally, the update is applied

to 3b, 4 and 5a, which now supercede the versions that previously

occupied that effective target span in current assertion time

Notice that the semantics we have given to temporal updates

which span episodes is that they do not “fill in the gaps” between

episodes Filling in the gaps is left to temporal inserts, whose job

is to place the representation of an object into one or more clock

ticks that did not previously contain one By the same token,

temporal updates cannot be used for any {lengthen}

transforma-tion Since any such expansion puts the representation of an

object into one or more previously unoccupied clock ticks,

tem-poral inserts are used for all of them

The Temporal Delete Transaction

The format of a temporal delete transaction is as follows:

DELETE FROM {tablename} [,,, ] eff_beg_dt, eff_end_dt,

asr_beg_dt

The validity checks work exactly as they do for temporal

update transactions The reason is that a temporal update is

equivalent to a temporal delete followed by a temporal insert

So for purposes of validity checking, exactly the same logic

applies to both

Other than supplying the business key when the object

iden-tifier is not known, there is no business data to specify on a

tem-poral delete The target timespan picks out the effective-time

range which is to be left empty of any representation of the

object, in current assertion time, after the transaction has

Chapter 9 AN INTRODUCTION TO TEMPORAL TRANSACTIONS 209

completed The delete withdraws any such representations into past assertion time, leaving those corresponding effective time clock ticks unoccupied by the object in current assertion time

The Temporal Delete Transaction: Semantics

In a conventional table, if an object is represented and the user wishes to delete it, she issues a delete transaction which deletes the one row representing the object And once again, this kind of transaction expresses not only her intentions, but also her beliefs It expresses her intention to delete a row representing an object, but it also expresses her belief that such

a row is currently there to delete If she is mistaken in her belief, her transaction is rejected, which is precisely what she would expect and want to happen

In an asserted version table, the question is not whether or not the object is already represented, but rather whether or not the object is represented, in current assertion time, within the target effective time span If the user submits a temporal delete transaction, she also expresses both intention and belief Her intention is to remove the representation of an object from the indicated timespan Her belief is that such a representation already exists in one or more of the clock ticks within that target span If she is mistaken in her belief, her transaction is rejected, which is precisely what she would expect and want to happen

The Temporal Delete Transaction: Mechanics

The scope of a conventional delete is a single row in the target table If the transaction is successful, the result is that the designated row is deleted from the table The scope of a tempo-ral delete is any set of one or more contiguous effective time clock ticks at least one of which contains a representation of the object So, inFigure 9.6, it must include at least one of the clock ticks occupied by Episodes A, B or C

In Chapter 7, we looked at a basic temporal delete transac-tion, submitted in December 2010, that specified a target timespan of [Now() – 12/31/9999], and we saw what the AVF did in response to that transaction It found that an episode did exist whose effective time period [intersected] that target span It split that episode into two parts The part from the episode’s begin date to (the then-current value of) Now() lay out-side the target timespan, while the part from Now() to the end of the episode was found to lie entirely within the target timespan This split occurred within the latest version of that episode So the AVF split that version, withdrew it, and replaced the effective

time earlier, unaffected part Since the target timespan extended

to 12/31/9999, no later part of the episode lay outside that target

span, so nothing else was replaced The transaction terminated a

current episode as of Now() But in doing so, it went through

exactly the same steps that all temporal deletes go through

Glossary References

Glossary entries whose definitions form strong

inter-dependencies are grouped together in the following list The

same glossary entries may be grouped together in different ways

at the end of different chapters, each grouping reflecting the

semantic perspective of each chapter There will usually be

sev-eral other, and often many other, glossary entries that are not

included in the list, and we recommend that the Glossary be

consulted whenever an unfamiliar term is encountered

We note, in particular, that none of the nodes in our

taxon-omy of temporal extent transformations are included in this list

In general, we leave taxonomy nodes out of these lists, but

rec-ommend that the reader look them up in the Glossary

12/31/9999

Now()

asserted version table

Asserted Versioning Framework (AVF)

assertion

assertion begin date

assertion end date

assertion time

shared assertion time

statement

transaction time

version

bi-temporal

uni-temporal

business data

business key

reliable business key

unreliable business key

clock tick

Chapter 9 AN INTRODUCTION TO TEMPORAL TRANSACTIONS 211

closed-closed closed-open open-closed open-open closed episode episode episode begin date open episode conventional table conventional transaction deferred assertion deferred transaction effective begin date effective end date effective time incommensurable intersect

occupied represented managed object object

object identifier oid

replace supercede terminate withdraw row creation date target episode target span temporal transaction temporal dimension temporal entity integrity (TEI) temporal referential integrity (TRI) temporal extent

temporal extent state transformation the alternative temporal model the standard temporal model

TEMPORAL TRANSACTIONS

ON SINGLE TABLES

The Temporal Insert Transaction 214

Creating an Episode 216

Lengthening an Episode Backwards 217

Lengthening an Episode Forwards 219

Merging Episodes 220

The Temporal Update Transaction 222

Restricted and Unrestricted Temporal Transactions 226

The Temporal Delete Transaction 226

Deleting One or More Episodes 227

Shortening an Episode Forwards 228

Shortening an Episode Backwards 230

Splitting an Episode 231

Completeness Checks 233

An Allen Relationship Completeness Check 233

A Temporal Extent Transformation Completeness Check 237

Glossary References 238

In the previous chapter, we looked at the “specs” of the three

types of temporal transactions In this chapter, we’ll take those

transactions out for a spin and see exactly how the AVF responds

to each one Its response has two parts After performing the edit

and validity checks described in the previous chapter, the AVF

looks to see if applying a transaction would violate temporal

entity integrity (TEI) or temporal referential integrity (TRI) If it

would violate either one, the transaction is rejected

Otherwise, the temporal transaction is translated into one or

more physical transactions which are then submitted to the

DBMS If the DBMS finds that applying any of those physical

transactions would violate an entity integrity or a referential

integrity constraint, it will reject that transaction In response,

the AVF will stop processing the temporal transaction, undo

Managing Time in Relational Databases Doi: 10.1016/B978-0-12-375041-9.00010-8

Copyright # 2010 Elsevier Inc All rights of reproduction in any form reserved. 213