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

To do this, the AVF creates a version whose effective time period extends from version 8’s effective begin date up to the effective begin date of the transaction, July 2010.. To superced

Trang 1

We begin by withdrawing the affected versions The transac-tion specifies the timespan [Jul 2010 – Jul 2011] Part of version

8, and all of versions 5 and 3, [fill 1] this timespan So the first step is to withdraw these three versions Since no assertion begin date was explicitly specified on the transaction, that date defaults to Now(), January 2012 The result is shown in Figure 10.10 Using a convention described previously, we enclose in angle brackets the row numbers of all rows which are part of this atomic, isolated unit of work and, because these rows are now withdrawn, we show them shaded

Only part of row 2 (version 8) [intersects] the range of the transaction Since row 2 has been withdrawn into past assertion time, the next thing we must do is to replace, in current assertion time, that part of the version that the transaction is not concerned with To do this, the AVF creates a version whose effective time period extends from version 8’s effective begin date up to the effective begin date of the transaction, July 2010 The result is row 7, shown inFigure 10.11

The rest of version 8 does [fill 1] the range of the transaction,

as do all of versions 5 and 3 The versions which take the place of these two versions are not replacements, because they do not contain identical business data Instead, they are versions which supercede the original versions with the new business data To supercede these versions, the AVF first creates a version whose effective time period extends from the transaction’s effective begin date up to the effective end date of version 8 The result

is row 8, shown inFigure 10.12

Jan12 UPDATE Policy [P861, , , $40] Jul 2010, Jul 2011

Jan 2014

Jan 2013

Jan 2012

Jan 2011

Jan 2010 Row

# 1

<2>

<3>

<5>

4 6

oid eff-beg eff-end asr-beg asr-end epis- client type copay row-crt

beg P861 Feb10

Feb10

Apr10

Apr10 Apr11

Apr11 Apr11

Apr10 Oct10

Jul11 9999

9999 9999 9999

Mar11

Mar10

Jan12 Jan12 Jan10 C882 HMO $15

$15

$20

HMO HMO HMO PPO

PPO

C882 C882 C882 C882 C882

Jan11 Jan10

Jan10

P861 P861 P861 P861 P861 Figure 10.10 Updating a Policy: Withdrawing the Versions in the Target Range

Trang 2

The last step for the AVF is to insert rows 9 and 10 Row 9

supercedes row 3 (version 3 in Figure 10.4), and row 10

supercedes row 5 (version 5) The temporal update transaction

is now complete The atomic unit of work is over, and the DBMS

can release its locks on the rows involved in this transaction

These rows are no longer isolated, but are now part of the

database

Jan12 UPDATE Policy [P861, , , $40] Jul 2010, Jul 2011

Jan 2014

Jan 2013

Jan 2012

Jan 2011

Jan

2010

Row

#

1

4

6

<2>

<3>

<5>

<7>

beg

Apr10

Apr10 Oct10

Apr10 Apr11

Apr11

Apr10

Jul11

9999

9999 9999 Mar11

Mar10

Feb10 Jul10

Jan11 Jan10

Jan12

Jan10 Jan10

Jan11 Jan10 Jan10

C882 HMO HMO

HMO HMO

HMO

PPO

$15

$20

C882 C882 C882 C882 C882 C882

Jan12

P861

Figure 10.11 Updating a Policy: Replacing the Unaffected Part of Version 2

Jan 2014

Jan 2013

Jan 2012

Jan12 Update Policy [P861, , , $40] Jul 2010, Jul 2011

Jan 2011

Jan

2010

Row

#

1

<2>

<3>

<5>

<7>

<8>

<9>

<10>

4

6

beg

9999

9999 9999 9999 9999 9999 Feb10

Apr10

Apr10 Oct10

Oct11

Oct10 Oct11

Apr11 Apr11 Apr11

Apr10 Apr11

Apr11

Apr10

Apr11

Jul11

Jul10

Jul11

Jul11 Mar11

9999 Mar11 Mar10

Jul10

Jan11 Jan10

Jan12

Jan10 C882 C882 C882 C882 C882 C882 C882 C882 C882 C882

HMO $15

$15

$20

$40

HMO PPO

PPO

HMO HMO

HMO

Jan10

Jan11

Jan11 Jan10 Jan10 Jan10

Jan12

Jan12 Jan12 Jan11

P861

Figure 10.12 Updating a Policy: Superceding the Affected Versions

Trang 3

Restricted and Unrestricted Temporal Transactions

The temporal update transactions discussed in this book are restricted temporal updates By that we mean that these trans-actions designate a specific object, a span of effective time, and

a value for one or more columns of business data, and then change all representations of that object, in all clock ticks within that timespan, to those new values But limited to only restricted update transactions, Asserted Versioning could not, for example, change the copay amounts on all policies within a target timespan provided that the original amounts are less than a cer-tain value Instead, the AVF could only change all copay amounts within that timespan, for a single object, to that new value Obviously, a series of carefully designed restricted temporal updates could produce any desired result, and do so across any set of objects But just as obviously, it would be a tedious process And because of the careful analysis required, it would also be an error-prone process

As we go to press, these limitations on temporal update trans-actions have been removed Release 1 of our Asserted Versioning Framework now supports unrestricted temporal update trans-actions, ones which will update multiple objects within a target timespan, and will do so based on WHERE clause qualifying criteria The AVF also now supports unrestricted temporal deletes as well

In addition, instead of requiring the user to write trans-actions in a proprietary format required by an Application Programming Interface (API) we were developing, the AVF now accepts temporal insert, update and delete transactions written as native SQL This is done by means of Instead of Triggers, as described in the section Ongoing Research and Development, in Chapter 16

Our new support for unrestricted temporal transactions, written as native SQL statements, can be found on our website AssertedVersioning.com

The Temporal Delete Transaction

A temporal delete transaction specifies an object and a target range for the transaction (Figure 10.13) It includes the object identifier, if it is known to the user If an oid is not provided on the transaction, the AVF attempts to find one according to the rules described in the previous chapter Finally, the transaction either accepts the default values for its temporal parameters, or overrides one or more of them with explicit values

Trang 4

A temporal delete is the inverse of a temporal insert A

tem-poral insert always increases the total number of clock ticks

occupied by an object A temporal delete always decreases the

total number of those clock ticks

As long as even a single clock tick in the transaction’s target

timespan [intersects] the effective time period of some version

of the same object, the delete is valid because it means that there

is data in one or more clock ticks for the delete to move into past

assertion time

A temporal delete’s target range may include part of an

epi-sode or version, an entire epiepi-sode or version, multiple epiepi-sodes

or versions, or any combination thereof But a temporal delete

never creates a new episode or version in clock ticks that were

previously unoccupied, just as a temporal insert never removes

one from clock ticks that were previously occupied

Deleting One or More Episodes

We will begin with the set of three episodes shown in

Figure 10.14 These are the current episodes A, B and C after being

updated as shown inFigure 10.12 We have also reset the version

numbers so they correspond to the row numbers inFigure 10.12

To completely remove an episode from current assertion

time, we do not need to provide the exact begin and end dates

of the episode, but simply need to include its effective time

Episode A Episode C Episode B

Jan 2014

Jan 2013

Jan 2012

Jan 2011

Jan

2010

1

Figure 10.14 Deleting an Episode: Before the Transaction

Remove an object

from a designated

timespan.

Withdraw the affected versions.

Assert the replacements which delimit the deletion.

Reset affected versions.

Figure 10.13 The Temporal Delete Transaction: Temporal to Physical Mapping

Trang 5

period in the transaction’s target timespan If that target timespan includes that of the episode, the result is to remove the entire episode, i.e to {erase} that episode from current assertion time

It is now March 2012, and either of the following two trans-actions is submitted to the AVF:

DELETE FROM Policy [P861] Jan 2010, Nov 2010 or

DELETE FROM Policy [P861] Jan 2010, Dec 2010 These two temporal delete transactions have the same result They both {erase} Episode A, the episode consisting of versions 6, 1,

7 and 8 The author of the transaction will not be confused by this fact provided she remembers that a delete transaction simply stops asserting the presence of an object anywhere in the effective timespan indicated on the transaction Both timespans shown here contain exactly the same occupied clock ticks

Withdrawing these versions is the first of the three physical transaction steps shown inFigure 10.15 As for the other two steps, neither of them is needed to complete this temporal transaction The reason is that since an entire episode is being {erased}, and the object is represented nowhere else in the target timespan, no other episodes are affected We can think of the empty clock tick

or clock ticks that exist on both ends of an episode as insulating other episodes from whatever happens to just that one episode

Shortening an Episode Forwards

We still currently assert episodes C and B inFigure 10.14 It is now May 2012, and the following transaction is submitted to the AVF: DELETE FROM Policy [P861] Jan 2011, May 2011

This transaction will {erase} Episode C, and {shorten Episode

B forwards} by one month

Row

#

beg P861 Feb10

Apr10

Oct10

Apr10

Apr11

Apr11 Apr11 Apr11

Apr11

Jul11 Jul11

Jul10

Jul11

Jul11 9999

9999 9999

9999

Jul10

Jan11

Jan12 Jan12

Jan12 Jan11

Jan10 Jan10 Jan10

Jan11

Jan10 C882 C882 C882 C882 C882 C882 C882 C882 C882 C882

HMO HMO

HMO

$15 Feb10 Apr10 Apr11 Jul11

$15

$20

$40

$40 PPO PPO

PPO Jan10

Jan12 Jan12 Jan11

Jan10 Feb10

Feb10

Mar11

Mar12 Mar12 Mar12

Mar12 Mar10

Mar11

P861 P861 P861 P861 P861 P861 P861 P861 P861

<1>

2 3 4 5

<6>

<7>

<8>

9 10

Figure 10.15 Deleting an Episode

Trang 6

Because the delete transaction {shortens Episode B forwards},

it alters the episode begin date Specifically, it changes that begin

date from April 2011 to May 2011 This transaction will require

all three of the physical transaction steps shown inFigure 10.13

The first physical transaction step withdraws versions 9 and

10 The result is shown inFigure 10.16 These versions have been

withdrawn, as all versions are, by overwriting their assertion end

dates The overwrites which withdraw rows into past assertion

time do not lose information, however, as overwrites of business

data do This is because we always know what the assertion end

date was before the row was withdrawn In all cases, it was

12/31/9999 This is guaranteed because (i) all versions are

cre-ated with an assertion end date of 12/31/9999, and (ii) the AVF

will never alter an assertion end date that is not 12/31/9999

In comparing the transaction’s time period to that of the

epi-sode, we see that it completely includes version 10 but only

[overlaps] version 9 So, having withdrawn version 9, we must

now replace it with a version identical to it except that its

effec-tive time period begins on May 2011 But because version 9 is

the first version of Episode B, it changes the episode begin date

of the episode from April 2011 to May 2011 This, in turn, affects

version 4, which is the second version in that episode

Conse-quently, we must withdraw version 4, and replace it with a

ver-sion that is identical to it except for having the new episode

begin date The result of all this work is shown inFigure 10.17

Episode C has been {erased}, completely withdrawn into past

assertion time Episode B has been {shortened forwards} by one

month

The first delete transaction we considered covered an entire

episode, {removing} that episode by withdrawing all its versions

into past assertion time This delete transaction, however, left part

Row

#

beg P861 Feb10

Apr10

Oct10

Apr10

Apr11

Apr11 Apr11 Apr11

Apr11

Jul11 Jul11

Jul10

Jul11

9999 9999

Jul10

Jan11

Jan12 Jan12

Jan12 Jan11

Jan10 Jan10 Jan10

Jan11

Jan10 C882 C882 C882 C882 C882 C882 C882 C882 C882 C882

HMO HMO

HMO

$15 Feb10 Apr10 Apr11 Jul11

$15

$20

$40

$40 PPO PPO

PPO Jan10

Jan12 Jan12 Jan11

Jan10 Feb10

Feb10

Mar11

Mar12 Mar12 Mar12 May12 May12

Mar12 Mar10

Mar11

P861

1

2

3

4

5

6

7

8

<9>

<10>

Figure 10.16 Shortening an Episode Forwards: After Step 1

Trang 7

of a target episode in current assertion time It withdrew part but not all of that episode, bringing about the temporal extent trans-formation in which an episode is {shortened forwards}

In this way, a temporal delete is different from a non-temporal delete Non-temporal deletes remove the one and only row representing an object from the database Temporal deletes remove some but not necessarily all of the possibly multiple rows representing an object, and may also remove part but not neces-sarily all of any one (or two) of those rows And, of course, tempo-ral deletes do not physically remove any data from the database They just withdraw assertions and end the effective time of vers-ions, so that at any point in time, what used to be the case can

be recreated exactly as it was then

Shortening an Episode Backwards

A temporal delete can also {shorten an episode backwards} in time This happens when the transaction’s target range [overlaps] later clock ticks in the episode (and perhaps additional clock ticks

as well) while one or more earlier clock ticks are not [overlapped] {Shortening an episode backwards} is easier than {shortening

it forwards} because it doesn’t alter the episode’s begin date Since the episode’s begin date remains the same, the only vers-ions in the episode that are affected by the transaction are those which [overlap] the transaction’s target range If we’re really for-tunate, the target range will line up on version boundaries An example would be a temporal delete whose target range is [Jul 2011 – 12/31/9999] against the episode still asserted in Figure 10.17 In this case, the timespan on this transaction [equals] the effective time of version 12

Row

# 1

oid eff-beg eff-end asr-beg asr-end

epis-beg

Feb10

Apr10

Apr11

Apr10

Apr10 Jul11

Jul11

Jul11 Oct10

Oct10

Jul10

Jul11

Jan11

Jan12 Jan12

Jan12

Jan12 Jan12 Jan12

Jan12

Jan12 Jan11 Jan12

Jan10

Jan10 C882 C882 C882 C882 C882 C882 C882 C882 C882 C882 C882 C882 HMO $15

$15

$20

$15

$20

$40

HMO HMO HMO HMO HMO HMO

HMO PPO PPO PPO PPO

Jan11

May12 May12

May12 May11

May11 Mar11

Mar12

Mar11

Mar12 Mar12 Mar12

Mar10

9999

9999 9999 Jan10

P861 P861 P861 P861 P861 P861 P861 P861 P861 P861 P861 P861

2 3 4 5 6 7 8

<9>

<10>

<11>

<12>

Figure 10.17 Shortening an Episode Forwards: After Step 2

Trang 8

When a temporal delete’s timespan lines up on a version

boundary within a target episode, then all that has to be done

is to withdraw the affected versions Doing so, in this case, leaves

an episode whose effective time extends from May 2011 to July

2011 So the effective end date, July 2011, of this previous

ver-sion, row 11, would designate the end of the episode

Splitting an Episode

{Splitting} an episode is a little more interesting than either

{shortening an episode backwards} or {shortening an episode

for-wards} The reason is that, from the point of view of the earlier of

the two resulting episodes, {splitting} is {shortening an episode

backwards}, while from the point of view of the later of the two

resulting episodes, it is {shortening an episode forwards} From

the point of view of the “internals” of AVF processing, of course,

it is simply another case of removing the representation of an

object from a series of clock ticks, the case in which those clock

ticks are contained within the clock ticks of a single episode

Let’s begin with the life history of policy P861 as represented

in the table inFigure 10.15and as graphically illustrated in

Fig-ure 10.14 In that table, versions (row numbers) 9 and 4

consti-tute a currently asserted episode, one which extends from April

2011 to 12/31/9999

It is now February 2012 Note that this is one month before the

{shorten forwards} transaction, described in the previous section,

is processed That’s why we’re going back toFigure 10.15, rather than

toFigure 10.16 The following transaction is submitted to the AVF:

DELETE FROM Policy [P861] May 2011, Dec 2012

Policy P861 exists, in current assertion time, in every clock

tick from May 2011 to December 2012 As we can see from

ver-sion 9, it also exists for exactly one clock tick prior to that

timespan And as we can see from version 4, it exists past

December 2012, into the indefinite future

The first physical transaction step in this deletion is to

with-draw versions 9 and 4 since each of them has at least one clock

tick included in the timespan specified by the temporal delete

The result is shown inFigure 10.18

Having {erased} the entire episode, the next step is to replace

those parts of those versions which lie outside the scope of the

transaction For version 9, [Apr 2011 – May 2011] is the single

clock tick that must be replaced For version 4, [Dec 2012 –

12/31/9999] is the effective timespan that must be replaced

The result is shown inFigure 10.19

Trang 9

The second physical transaction step in carrying out a tem-poral delete is to assert the replacement versions which delimit the time period of the deletion This is done with versions 12 and 13 Version 12 replaces the one clock tick from version 9 that was not included in the range of the delete Version 13 replaces the clock ticks from December 2012 to 12/31/9999 from version

4 that were not included in the range of the delete

The third physical transaction step resets any versions that need their episode begin dates reset That is version 13 Version

4, which it replaces, belongs to an episode which began on July

2011 That episode has been {shortened forwards} by the trans-action so that it now begins on December 2012, the effective begin date of what is now its only version

Row

# 1

epis-beg

Feb10 Feb10

Feb12

Feb10

Feb12 Feb10

Feb12 Feb12

Apr10

Apr11

Apr10

Apr11

Apr10 Jul11

Jul10

Jul11

Jul11 Oct10

Oct10

Jul10

Dec12

Jan11

Jan12

Jun10 Jan11 Jan12

Jan10

Jan10 C882 C882 C882 C882 C882 C882 C882 C882 C882 C882 C882 C882 C882 HMO $15

$15

$20

$15

$20

$40

$20

$40

HMO HMO HMO HMO

HMO PPO PPO

PPO PPO PPO PPO PPO

Jan11 Jun10

May11

Feb12 Dec12

Mar11

Mar12

Mar11

Mar12 Mar12

Mar10

9999

9999 9999

9999 9999 9999 9999 9999 9999

9999 Jan10

P861 P861 P861 P861 P861 P861 P861 P861 P861 P861 P861 P861 P861

2 3

<4>

5 6 7 8

<9>

10 11

<12>

<13>

Figure 10.19 Splitting an Episode: After Steps 2 and 3

Row

# 1

epis-beg

Feb10 Feb10

Feb12

Feb10

Apr10

Apr11

Apr10

Apr10 Jul11

Jul10

Jul11

Jul11 Oct10

Oct10

Jul10

Jun10

Jul10

Jan11

Jan12 Jan12 Jan12

Jan12

Jan12 Jan11 Jan12

Jan10

Jan10 C882

C882 C882 C882 C882 C882 C882 C882 C882 C882 C882

$15

$20

$15

$20

$40

$20

HMO HMO HMO HMO HMO HMO

HMO PPO PPO PPO PPO

Jan11

Mar11

Mar12

Mar11

Mar12 Mar12

Mar10

9999

9999 9999 9999 9999 9999 9999

Jan10

P861 P861 P861 P861 P861 P861 P861 P861 P861 P861 P861

2 3

<4>

5 6 7 8

<9>

10 11

Figure 10.18 Splitting an Episode: After Step 1

Trang 10

Completeness Checks

We have now used all three temporal transactions, in a variety

of situations There are several ways to categorize the situations

which temporal transactions might encounter, but we

con-cluded, a couple of chapters ago, that we could not provide an

example for all of them Nonetheless, we would like some

assur-ance that any semantically valid request to transform one or

more asserted version tables from one state to another state

can be made with temporal transactions and can be carried

out with the physical transactions that the AVF maps them into

We know of two ways to do this One is with the Allen

relationships The other is with our taxonomy of temporal extent

state transformations The relationship of these two ways of

demonstrating completeness is this While we will use the Allen

relationships to compare temporal transactions to their target

episodes, we will use the temporal extent state transformations

to compare before and after states of a target database

An Allen Relationship Completeness Check

First of all, it is well established that the Allen relationships are a

mutually exclusive and jointly exhaustive set of all the possible

relationships between two time periods along a common timeline

that are based on the temporal precedence and succession of

one to the other (Figure 10.20) We ourselves derived precisely those

Allen relationships as the leaf nodes in a taxonomy of our own

invention Since taxonomies are tools for demonstrating mutual

exclusion and joint coverage of an original root node, this is further

proof, if any were needed, of the validity of the Allen relationships

In the case of temporal transactions, one of those two Allen

relationship time periods is the effective time period specified

on the transaction The other time period is the effective time

period of each episode and version to which those transactions

may apply

We should also remind ourselves that when we compare any

two time periods in effective time, we are assuming that they

exist in shared assertion time When one of those time periods

is on a transaction, that assertion time cannot begin in the past,

and usually begins Now(); and the assertion time specified on

the transaction always extends to 12/31/9999

[Before], [before–1] When a temporal transaction’s effective

time is non-contiguous with that of any episodes of the same

object already in the target table, a temporal insert will {create}

a new episode of the object In Allen relationship terms, this

Tiêu đề	Temporal transactions on single tables
Thể loại	Chapter

Định dạng
Số trang	20
Dung lượng	604,12 KB