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

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 in Figure 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 in Figure 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 client type copay row-crt epis- beg P861 Feb10 Feb10 Feb10 Feb10 Apr10 Apr11 Apr11 Apr10 Apr11 Apr11 Apr11 Apr10 Oct10 Oct11 Oct11 Jul11 Jul11 Jul11 Aug11 Aug11 Jul11 9999 9999 9999 9999 Mar11 Mar10 Jan11 Jan12 Jan12 Jan12 Jan10 C882 HMO $15 $15 $20 $20 $20 $20 HMO HMO HMO PPO PPO C882 C882 C882 C882 C882 Jan11 Jan10 Jan10 Jan10 P861 P861 P861 P861 P861 Figure 10.10 Updating a Policy: Withdrawing the Versions in the Target Range. 224 Chapter 10 TEMPORAL TRANSACTIONS ON SINGLE TABLES 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> oid eff-beg eff-end asr-beg asr-end client type copay row-crt epis- beg P861 Feb10 Feb10 Feb10 Apr10 Apr10 Oct10 Oct11 Oct11 Jan12 Jan12 Apr11 Apr11 Apr11 Apr10 Apr11 Apr11 Apr10 Jul11 Jul11 Jul11 Jul11 Aug11 Aug11 9999 9999 9999 9999 9999 Mar11 Mar10 Feb10 Jul10 Jan11 Jan10 Jan12 Jan10 Jan10 Jan11 Jan10 Jan10 C882 HMO HMO HMO HMO HMO PPO PPO $15 $15 $20 $20 $20 $20 $20 C882 C882 C882 C882 C882 C882 Jan12 Jan12 P861 P861 P861 P861 P861 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 oid eff-beg eff-end asr-beg asr-end copay row-crt type client epis- beg P861 Feb10 Feb10 Feb109999 9999 9999 9999 9999 9999 9999 Feb10 Apr10 Apr10 Oct10 Oct11 Oct10 Oct11 Apr11 Apr11 Apr11 Apr10 Apr11 Apr11 Apr11 Aug11 Aug11 Apr10 Apr11 Jul11 Jul10 Jul11 Jul11 Jul11 Jul11 Mar11 9999 Mar11 Mar10 Jul10 Jan11 Jan10 Jan12 Jan12 Jan10 C882 C882 C882 C882 C882 C882 C882 C882 C882 C882 HMO $15 $15 $20 $20 $20 $20 $20 $40 $40 $40 HMO PPO PPO PPO HMO HMO HMO HMO HMO Jan10 Jan11 Jan11 Jan10 Jan10 Jan10 Jan12 Jan12 Jan12 Jan12 Jan12 Jan12 Jan12 Jan12 Jan12Jan11 P861 P861 P861 P861 P861 P861 P861 P861 P861 Figure 10.12 Updating a Policy: Superceding the Affected Versions. Chapter 10 TEMPORAL TRANSACTIONS ON SINGLE TABLES 225 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 cla use 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 proprietar y 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 incl udes 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. 226 Chapter 10 TEMPORAL TRANSACTIONS ON SINGLE TABLES 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 tempo ral delete’s target range may include part of an epi- sode or version, an entire episode or version, multiple episodes 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 in Figure 10.12. We have also reset the version numbers so they correspond to the row numbers in Figure 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 B Episode C Jan 2014 Jan 2013 Jan 2012 Jan 2011 Jan 2010 7 9 41016 8 Figure 10.14 Deleting an Episode: Before the Transaction. Temporal Delete Physical Transaction(s) 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. Chapter 10 TEMPORAL TRANSACTIONS ON SINGLE TABLES 227 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 t he transaction will not be confused by this fact pro vided sh e reme mbers that a dele te transaction simply stops asserting the presence of an object anywhere in the effective timespan indicated on the transa ction. Both timespans shown her e contain exactly the same occupied clock ticks. Withdrawing these versions is the first of the three physical transaction steps shown in Figure 10.15. As f or 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 i n Figure 10.14.Itisnow 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 # oid eff-beg eff-end asr-beg asr-end client type copay row-crtepis- beg P861 Feb10 Apr10 Aug11 Aug11 Oct10 Oct11 Oct11 Oct10 Apr10 Apr10 Apr11 Apr11 Apr11 Apr11 Apr11 Apr11 Jul11 Jul11 Jul10 Jul11 Jul11 9999 9999 9999 9999 Jul10 Jan11 Jan12 Jan12 Jan12 Jan12 Jan12 Jan12 Jan12 Jan12 Jan12 Jan11 Jan10 Jan10 Jan10 Jan11 Jan10 C882 C882 C882 C882 C882 C882 C882 C882 C882 C882 HMO HMO HMO HMO HMO HMO HMO $15 Feb10 Apr10 Apr11 Jul11$15 $20 $20 $20 $20 $20 $40 $40 $40 PPO PPO PPO Jan10 Jan12 Jan12Jan11 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. 228 Chapter 10 TEMPORAL TRANSACTIONS ON SINGLE TABLES 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 in Figure 10.13. The first physical transaction step withdraws versions 9 and 10. The result is shown in Figure 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- sod e, 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 in Figure 10.17. Episode C has been {erased}, completely withdrawn into past asse rtion time. E pisode 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 # oid eff-beg eff-end asr-beg asr-end client type copay row-crtepis- beg P861 Feb10 Apr10 Aug11 Aug11 Oct10 Oct11 Oct11 Oct10 Apr10 Apr10 Apr11 Apr11 Apr11 Apr11 Apr11 Apr11 Jul11 Jul11 Jul10 Jul11 Jul11 9999 9999 Jul10 Jan11 Jan12 Jan12 Jan12 Jan12 Jan12 Jan12 Jan12 Jan12 Jan12 Jan11 Jan10 Jan10 Jan10 Jan11 Jan10 C882 C882 C882 C882 C882 C882 C882 C882 C882 C882 HMO HMO HMO HMO HMO HMO HMO $15 Feb10 Apr10 Apr11 Jul11$15 $20 $20 $20 $20 $20 $40 $40 $40 PPO PPO PPO Jan10 Jan12 Jan12Jan11 Jan10 Feb10 Feb10 Mar11 Mar12 Mar12 Mar12 May12 May12 Mar12 Mar10 Mar11 P861 P861 P861 P861 P861 P861 P861 P861 P861 1 2 3 4 5 6 7 8 <9> <10> Figure 10.16 Shortening an Episode Forwards: After Step 1. Chapter 10 TEMPORAL TRANSACTIONS ON SINGLE TABLES 229 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} bec ause 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 asse rted 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 client type copay row-crt Feb10 Feb10 Feb10 Feb10 Apr10 Apr11 Apr11 Apr11 Apr11 Apr11 Apr10 Apr10 Apr11 Apr11 Apr10 Jul11 Jul11 Jul11 Jul11 Jul11 Aug11 Aug11 Jul11 Oct10 Oct10 Oct11 Oct11 Jul10 Jul10 Jul11 Jan11 Jan12 Jan12 Jan12 Jan12 Jan12 Jan12 Jan12 Jan12 Jan12 Jan12 Jan11 Jan12 Jan10 Jan10 Jan10 Jan11 Jan10 Jan10 C882 C882 C882 C882 C882 C882 C882 C882 C882 C882 C882 C882 HMO $15 $15 $20 $20 $15 $20 $20 $20 $40 $40 $40 $40 HMO HMO HMO HMO HMO HMO HMO PPO PPO PPO PPO Jan11 May11 May12 May12 May12 May12 May12 May12 May12 May11 May11 Mar11 Mar12 Mar11 Mar12 Mar12 Mar12 Mar10 9999 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. 230 Chapter 10 TEMPORAL TRANSACTIONS ON SINGLE TABLES 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 in Figure 10.15 and 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 Februa ry 2012. Note that this is one month before the {shorten forwar ds} transaction, described in the previous section, is processed. That’s why we’re going b ack to Figure 10.15, rather than to Figur e 10.16. The follo wi ng transaction is submitted t o 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 in Figure 10.18. Having {erased} the entire episode, the next step is to replace those parts of those versions which lie outsid e 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 in Figure 10.19. Chapter 10 TEMPORAL TRANSACTIONS ON SINGLE TABLES 231 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 episo de has been {shortened forwa rds} 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 oid eff-beg eff-end asr-beg asr-end epis- beg client type copay row-crt Feb10 Feb10 Feb12 Feb12 Feb10 Feb12 Feb10 Feb12 Feb12 Apr10 Apr11 Apr11 Apr11 Apr11 Apr11 Apr10 Apr10 Apr11 Apr11 Apr11 Apr11 Apr10 Jul11 Jul10 Jul11 Jul11 Jul11 Aug11 Aug11 Jul11 Oct10 Oct10 Oct11 Oct11 Jul10 Jul10 Dec12 Jan11 Jan12 Jan12 Jan12 Jan12 Jan12 Jan12 Jan12 Jun10 Jan11 Jan12 Jan10 Jan10 Jan10 Jan11 Jan10 Jan10 C882 C882 C882 C882 C882 C882 C882 C882 C882 C882 C882 C882 C882 HMO $15 $15 $20 $20 $15 $20 $20 $20 $40 $40 $40 $20 $40 HMO HMO HMO HMO HMO PPO PPO PPO PPO PPO PPO PPO Jan11 Jun10 May11 Mar12 Mar12 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 oid eff-beg eff-end asr-beg asr-end epis- beg client type copay row-crt Feb10 Feb10 Feb12 Feb12 Feb10 Feb10 Apr10 Apr11 Apr11 Apr11Apr11 Apr11 Apr10 Apr10 Apr11 Apr11 Apr10 Jul11 Jul10 Jul11 Jul11 Jul11 Aug11 Aug11 Jul11 Oct10 Oct10 Oct11 Oct11 Jul10 Jun10 Jul10 Jan11 Jan12 Jan12 Jan12 Jan12 Jan12 Jan12 Jan12 Jan11 Jan12 Jan10 Jan10 Jan10 Jan11 Jan10 Jan10 C882 C882 C882 C882 C882 C882 C882 C882 C882 C882 C882 $15 $20 $20 $15 $20 $20 $20 $40 $40 $40 $20 HMO HMO HMO HMO HMO HMO HMO PPO PPO PPO PPO Jan11 Mar12 Mar12Jun10 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. 232 Chapter 10 TEMPORAL TRANSACTIONS ON SINGLE TABLES 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 ou rselves 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 effe ctive 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 assumi ng that they exist in shared assertion time. When one of those time periods is on a tran saction, 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 Chapter 10 TEMPORAL TRANSACTIONS ON SINGLE TABLES 233 [...]... included in that timespan, those being the ones at the begin and/or end of the timespan This delete transaction carries out a {split} transformation on the episode in question [During–1] If a temporal delete transaction’s effective time begins before that of an episode, and ends after that episode ends, then the transaction will {erase} the one or more episodes wholly included within its timespan In. .. withdrawn version that is not within its timespan 235 236 Chapter 10 TEMPORAL TRANSACTIONS ON SINGLE TABLES [Finishes] If a temporal delete transaction’s effective time ends on the same clock tick as that of an episode, but begins after that episode begins, it will withdraw all versions wholly or partially included within its timespan If one version is partially within the timespan, the temporal delete... partially included within its timespan Those other versions will exist within one or more earlier episodes On any of those episodes wholly included within the transaction’s timespan, there will be an {erase} transformation on them, as well The earliest episode within the transaction’s timespan may be wholly or partially included within that timespan If it is wholly contained, there will be an {erase}... transactions and the temporal referential integrity constraint to which they must conform Conventional referential integrity (RI), at the level of types rather than instances, is a relationship between two relational Managing Time in Relational Databases Doi: 10.1016/B978-0-12-375041-9.00011-X Copyright # 2010 Elsevier Inc All rights of reproduction in any form reserved 241 242 Chapter 11 TEMPORAL TRANSACTIONS... effective time begins on the same clock tick as that of an episode, but ends after the episode ends, the transaction will {erase} the episode; and, in addition, it will withdraw all other versions, for the same object, that are wholly or partially included within its timespan Those other versions will exist within one or more later episodes On any of those episodes wholly included within the transaction’s timespan,... transaction’s timespan does not fall on a version effective time boundary, then the temporal delete will replace the part of that withdrawn version that is not within its timespan [During] If a temporal delete transaction’s effective time begins after that of an episode, and ends before that episode ends, then the transaction will withdraw all versions wholly or partially included within its timespan At... a temporal delete transaction’s effective time begins on the same clock tick as that of an episode, but ends earlier than the episode ends, it will withdraw all versions wholly or partially included within its timespan If one version is partially within the timespan, the temporal delete will replace the part of that withdrawn version not within its timespan In either case, the result is a {shorten backwards}... wholly included within the transaction’s timespan, there may be one or two episodes only partially included within the transaction’s timespan If there is an earlier but partially included episode, the delete transaction will do a {shorten backwards} transformation on it If there is a later but partially included episode, the delete transaction will result in a {shorten forwards} transformation In either... each grouping reflecting the semantic perspective of each chapter There will usually be several 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 the two taxonomies referenced in this chapter are included in this list In general,... lists since they are long enough without them 12/31/9999 clock tick Now() until further notice Allen relationships Chapter 10 TEMPORAL TRANSACTIONS ON SINGLE TABLES adjacent include contiguous asserted version table Asserted Versioning Framework (AVF) assertion begin date assertion end date assertion time business data effective begin date effective end date effective time episode episode begin date . partially included with in its timespan. At most two versions can be par- tially included in that timespan, those being the ones at the begin and/or end of the timespan two relational Managing Time in Relational Databases. Doi: 10.1016/B978-0-12-375041-9.00011-X Copyright # 2010 Elsevier Inc. All rights of reproduction in