Traveling back in time is easy and can answer important questions. Take the next step with Scott on this journey through the castle.

Glad you could join me for episode two of this series. When I last talked to you, I had just learned what house the Sorting Hat had chosen for me. In an unexpected turn of events, I am bound for the house of Slytherin. Unlike some before me, I don’t resist the decision, bowing to the wisdom of the enchanted hat. Perhaps I’m comforted by the knowledge that my path will be influenced by future decisions that I can control.

My housemates welcome me with open arms and wary looks. After some time has passed, I have settled into a routine of training and competition. I am intrigued by the possibilities that lie before me. Much like my life here in the castle, DB2 for i on IBM i 7.3 provides similar opportunities for new adventures.

Figure 1 shows one of the most valuable additions to 7.3. DB2 for i has its own version of a “Time-Turner.” For those who have failed to read, listen to, or watch the many books, tapes, and movies that mention this device, you can read more about it here: HP Time-Turner

A Time-Turner is controlled by its user. When the hour glass is turned, the user is transported temporarily one hour back in time. If you need to travel further back in time, simply do the math and rotate until you reach your desired point in time.

Figure 1: Turn back the clock with DB2 for i’s Time-Turner.

Why bother moving back in time with DB2 for i? Because by doing so, you can easily answer important time-based questions.

Temporal Tables and DB2 for i

As you read about or evaluate IBM i 7.3, we expect many of you will discover use cases for system-period temporal tables. Figure 2 shows some simple examples of the realm of possibility when you can time travel with SQL on IBM i.

This may sound gruesome, but time travel in DB2 for i becomes possible when the database tracks the birth and death of rows. What constitutes the death of a row? Rest assured, there is no “Killing Curse” to use in the data center. Instead, when a row is updated or deleted, the previous version of the row has officially died and been laid to rest in something called a “history table.” More on that topic will be covered in the next episode of this series.

Figure 2: Here are some examples of time-based temporal (and SQL query) questions.

As seen in the figure, there are different coding styles that can be used to assign the period-specification of the query. Three styles of explicit time specification can be used:

1. FOR SYSTEM_TIME AS OF value
   AS OF returns rows that were born before the AS OF value and did not die before the AS OF value. The value can be a literal value or an expression that includes time arithmetic.
   If the table includes a primary key, you will see at most one row returned for any specific primary key value.
2. FOR SYSTEM_TIME FROM value1 TO value2
   FROM TO returns rows that were born before value2 and are active rows or died after value1. Again, either value can be a literal value or an expression that includes time arithmetic.
   If the table includes a primary key, you can see zero to many rows returned for any specific primary key value.
3. FOR SYSTEM_TIME BETWEEN value1 AND value2
   BETWEEN AND returns rows that were born before or equal to value2 and are active rows or died after value1. Once again, either value can be a literal value or an expression that includes time arithmetic.
   If the table includes a primary key, you can see zero to many rows returned for any specific primary key value.

The figure also shows that a new CURRENT TEMPORAL SYSTEM_TIME special register can be used to avoid coding literal values in your SQL. When set to a non-NULL value, any system-time eligible applications will implicitly be treated as though they were encoded with:

FOR SYSTEM_TIME AS OF CURRENT TEMPORAL SYSTEM_TIME

It does not take a Transfiguration spell to get from Figure 3 to Figure 4; all you need to do is to decide to use system-period temporal table support.

Figure 3 depicts life before temporal table support. History is captured via user-maintained techniques. Triggers populate one or more external tracking tables, and applications were constructed to reconstruct the data to produce time-oriented analysis.

Figure 3: Do-it-yourself historical maintenance is a hassle.

Figure 4 shows the greatly improved solution that awaits you on IBM i 7.3. Historical triggers are revised or completely retired. Better yet, the SQL Query Engine (SQE) can be leveraged to implement time-based or time-ranged queries. As with other data-centric enhancements in the database, you can achieve real value for small effort by having the database do more for you. If you’ve never seen the term DBE, it stands for Database Engineer. The DBE is similar to a Hagrid and certainly dissimilar to “he who must not be named.”

.

Figure 4: The DB2 for i data-centric temporal table is so much easier!

Till Next Time…

This episode merely scratched the surface of how you can use system-period temporal tables with DB2 for i. Come back to read the next episode to discover how you transform your table to be temporal and other fun facts.

As for the wizarding world, it’s time to work on your Patronus Charm because there are dementors in the midst. Stay awake and alert!