Note: a glossary of technical terms used in these articles can be found on the Web sites of the authors. The URLs are MindfulData.com and InbaseInc.com. Last time, we said that we had completed the split transformation. But we were wrong. There is one more thing that needs to be done. So this time, we really will complete that transformation. At the same time, we can also learn something from this mistake: why it has been worthwhile to develop a taxonomy of all possible state transformations of asserted version tables and how to work through each of those transformations. For it may seem, to some of our readers, that our discussions have become repetitious. After all, from the user's point of view, asserted version tables are maintained much the same way that conventional tables are by means of insert, update and delete transactions. For example, if the user intends her changes to take effect immediately and has no reason to hold those changes in reserve by means of deferred assertion begin dates, then her original asserted versioning transactions are completely equivalent to conventional transactions. On the other hand, if she wants her changes to take effect at some time other than immediately, all she has to do is to append a date or two to her transactions. Why, then, do we need to work through eight different scenarios in which this is what happens, every time? Of course these original transactions, as we have seen, are not the transactions that are submitted to the database management system. Instead, asserted versioning code translates them into one, or usually several, physical transactions. They are the transactions that are submitted to the DBMS. But the pattern of translation for each of these three types of original transaction is also clear. An original insert always results in one physical insert being applied to the database. Original updates and deletes always involve withdrawing a assertion and replacing it with other assertions. So why, again, do we need to work through eight different scenarios in which this is what happens, every time? Figure 1 shows the state of the database, which we said last time represented the completion of a split transaction. But this is an invalid database state. The thoughtful reader might want to look at Figure 1 now and try to find what is invalid about it. (We will provide the answer later on in this column, but first we need the background for that answer.)
One Episode or Two?
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access