IBM i 7.3からサポートされている「テンポラル・テーブル（Temporal Table）」をご存じだろうか。発表では、テーブルの履歴をDB2上でサポートすると説明されているが、その利用意図や目的についてはあまり明確ではない。
そこで本稿では、「テンポラル・テーブル」の狙いと利用方法について解説してみよう。
企業情報とデータベース
昨今、企業情報には次の2種類のデータが用いられている。1つは業務データ、もう1つはBI（Businesses Intelligence）やDWH（Data Warehouse）のデータである。
業務データでは、企業のトランザクション処理で発生するデータを記録・更新・削除する。一方、BIやDWHでは企業内のパフォーマンスや顧客動向、商品の販売動向など個々のトランザクションデータではなく、大量のトランザクションデータを検索し、サマリーすることで、データの傾向を把握し、経営判断などに役立てる。
今までIBM iなどのホストコンピュータでは業務データの処理が大半であり、データ記録の正確性や一貫性に重点が置かれていた。そこには企業の意思決定（Decision Making）に必要なデータのヒストリーや組織の変遷といった情報が含まれることはまれだった。
では、企業の意思決定に必要な情報とは何であろうか。1つは業務データの時系列の変遷や組織、顧客など複数の切り口を組み合わせ、さらにそこに「集約した次元」という切り口をもたせたものである。いわゆる、「ディメンショナル・モデリング（Dimensional Modeling）」といった考え方である。
これまでのIBM iでは、ディメンショナル・モデリングに対応するデータ処理機能の実装は、別途にBI／DHW専用のソフトウェアをIBM i上、もしくは他のプラットフォーム上に配置し、業務データを配信・集計・加工することで多次元データを生成し、データを分析・評価してきた。
こういう形態になった背景としては、多次元データモデルの実装が標準のSQL DBMSでは労力を要することに加え、通常のSQLモデルでは多次元データの生成やデータの照会にコストがかかり、満足できるパフォーマンスを得られなかった点が挙げられる。
バッチ処理の遅延などが業務データ処理に影響しないようにとの配慮の結果、BI／DHWデータは即時性を欠くことが多かった。しかし今日における企業活動では、データ量やそのデータを用いた意思決定は日々加速し、即時性が求められている。そこでBI／DWHデータを業務データに統合し、情報の即時性を高めようというアプローチが1つの解決策と考えられている。
以上が、今日の企業情報処理に求められるBI／DWHの背景である。次に、ディメンショナル・モデリングに関して少し掘り下げて解説しよう。
ディメンショナル・モデリング
ディメンショナル・モデリングを語るうえで参考となる書籍が、『The Data Warehouse Toolkit Third Edition』（Ralph Kimball、Margy Ross著、Wiley刊）である。英語版のみであるが、多次元データのアーキテクチャに始まり、業務別に対応したディメンショナル・モデリングのパターン解説やETLまでカバーしたBI／DHWを検討する際に貴重な参考書となる。
Ralph Kimball氏が提唱したディメンショナル・モデリングに関して記述されており、企業システムの現場で実装が試みられている。以下に、本書を参照しながら解説を進めていくが、本稿は本自体の解説が目的ではないので、IBM iのテンポラル・テーブルに関わるトピックスに絞ることにする。
ディメンショナル・モデリングにおけるREBMSの実装
『The Data Warehouse Toolkit』（以下、参考図書と呼ぶ）のChapter 1、Page 8にスタースキーマとOLAPキューブという項目がある。ここでは、ディメンショナル・モデリングについてRDBMSでの2つの実装アーキテクチャが解説されている。
1つはスタースキーマである。通常のSQLのようなRDBMS環境へ実装され、そのモデル構造が「星形」なので、そう呼ばれている。もう1つは、多次元データベース環境に実装されるOLAP（OnLine Analytical Processing） である（図表1）。
通常、BI／DHWの世界ではOLAPキューブの利用がよく見られる。その理由としては大量データを事前にロード／サマリーし、分析に必要な多次元データをあらかじめ作成することで、ユーザーが満足するパフォーマンスの確保が容易である点が挙げられる。その半面、対象となるデータが増大するのに比例して、事前処理の負荷も増加することに注意すべきである。
では、スタースキーマはどうであろうか。ディメンショナル・モデリングでは論理的に共通のデザインモデルであるとされているが、物理的な実装は異なる。OLAPキューブの実装は、実世界では有効であり、利用が推奨される。ただしOLAPを含めて多次元データを扱う際には、スタースキーマに基づいたRDBMSのデータベースデザインを基本にすることが肝心である。
OLAPキューブの観点から見た場合、ロード元であるRDBMSレベルのディメンショナル・モデリングのデータ構造はOLAP処理の効率化に寄与し、データ構造の簡略化も図れるので有効な考え方である。
以下に、このスタースキーマを前提としたKimball Database Modelingについて解説を進めていく。
Slowly Changing Dimension
ここでは、Kimball Database Modelingで中核的なデータモデルのコンセプトである「Slowly Changing Dimension」（SCD）について解説する。
SCDはきわめて標準的な考え方であり、ある次元（切り口）のデータの変遷を追跡できるデータモデルの考え方である。代表例として、ある次元データを時系列に追跡できる仕組みがある。テンポラル・テーブルの機能は、このコンセプトを実装するのに有効である。
実装例を解説する前に、SCDの実装パターンがKimballによって提唱されているので、短く紹介しよう。図表2は、SCDのデータ操作パターンごとにType分類し、想定業務を定義したものである。参考図書には、これらのSCD Typeを組み合わせて小売、在庫、販売管理、会計、通信、運輸、教育、ヘルスケア、電子商取引などの企業業務で活用できるディメンショナル・モデリングを解説しているので、詳細はそちらを参照いただきたい。
SCDのさまざまなTypeの中で、基本的に参照されるのが「Type 2 Add New Row」である。これを実装するためにテーブルに最低限必要なカラム情報としては、以下の3つがある。
（1） 行単位で、有効期限を日付やタイムスタンプで表したカラム
（2） 行単位で、期限超過を日付やタイムスタンプで表したカラム
（3） 現在行を指し示すインジゲータカラム
ある次元データを時系列に記録・参照・更新するための基本的な考え方であり、ユーザーも容易にイメージし、理解できるモデリングである。
それでは以下に、IBM i 7.3から利用可能となったテンポラル・テーブル機能を利用したSCD Type 2 Dimensional Modelingについて解説していこう。
IBM iのテンポラル・テーブルを利用した
SCD Type 2 Dimensional Modelingの実装
ここでは具体的な実装例を挙げて、SCD Type 2がIBM i上で実装できることを説明する。まずシステム期間テンポラル表として、以下の例を挙げる。
● システム期間テンポラル表
テーブル：TMPLTEST01.DEPARTMENT
履歴表：TMPLTEST01.DEPARTMENT_HISTORY
今回はデータの保守とデータの扱いやすさを考慮し、カレントテーブルと履歴テーブルを分割した後に、テンポラル・テーブル機能で1つの表として扱えるようにした。実際のDDL実装は、図表3のようになる。
最後にあるALTER TABLEコマンドで、履歴テーブルをバージョニングとして追加している。これにより、データが更新されるごとにヒストリーテーブルに追加行と現在行が更新されることになる。この検証で利用したデータは、図表4である。
それではデータを実際に操作し、テンポラル・テーブルの動きを見てみよう。
1.最初の照会
SELECT * FROM TMPLTEST 01.DEPARTMENT ORDER BY DEPTNO;
これを発行し、初期データを確認すると、図表5のようになる。
2. レコードの更新
UPDATE TMPLTEST01.DEPARTMENT SET DEPTNAME=’生産技術本部’ WHERE DEPTN=’A00010′;
COMMIT;
この操作で、DEPTNOがA00010のデータを更新する。次に、更新後のデータがどのように見えるかを確認してみよう。
3.更新後の照会 （時刻設定は現在）
SELECT * FROM TMPLTEST01.DEPARTMENT ORDER BY DEPTNO;
通常のSQLでの更新と同じく、2.で更新したデータが表示されている。参照の際に時刻としてはシステムタイムスタンプがデフォルトして用いられ、通常のデータ処理として参照が可能である（図表6）。
次の操作で、テンポラル・テーブルの機能の真価が確認できる。
4. 更新後の照会 （時刻設定は更新タイミングの前に設定）
SELECT * FROM DEPARTMENT FOR SYSTEM_TIME AS OF ‘2016-07-05-19.20.00’ ORDER BY DEPTNO;
システム時間に更新前のタイムスタンプを指定することで、更新前データが表示される。
このようにデータの時系列の管理・照会が、同一テーブルのアクセスで容易に実現される。アプリケーション開発・保守の観点からも、SCD Type 2 Dimensional Modelingを容易に追加実装できる。
ここで参考までに、V7.3以前のDB2 for i で、SCD Type 2 Dimensional Modelingを実装する場合の具体例を挙げてみよう。必要な機能は、Flexible ViewsとInstead OF Triggerの2つである。
Flexible Viewは、2015年度からDB group PTFとして追加されてきた機能であり、詳細はhttp://ibm.co/2aY56vRを参照してほしい。
簡単に説明すると、これは従来のSQL Viewについて、SQL Global変数を確認して動的にViewデータを参照する機能である。もちろんViewなので、基本的に追加・更新・削除などはできない。そのためInstead Of Triggerを利用し、Viewの参照元テーブルの変更を実装することになる（図表7）。
Flexible Viewで類似の機能を実装
具体的な実装例を説明しよう。下記のように設定した場合、DDLは図表8のようになる。
ビュー：TEMPLTEST02.DEPARTMENT_VIEW
テーブル：TEMPLTEST02.DEPARTMENT
続いて、Instead Of Trigger定義は挿入・更新・削除ごとに作成する必要があり、図表9、10、11のようになる。データは、図表12を用いた。
以上が定義である。テンポラル・テーブルの定義に比べて、はるかに複雑になっていることがわかるだろう。では、実際に操作例を見ていこう。
1. 最初の照会
SET TMPLTEST02.PERFORM_TIMESTAMP=CURRENT TIMESTAMP;
SELECT * FROM TMPLTEST02.DEPARTMENT_VIEW ORDER BY DEPTNO;（図表13）
2. レコードの更新
UPDATE TMPLTEST02.DEPARTMENT_VIEW SET DEPTNAME=’生産技術本部’ WHERE DEPTNO=’A00010′;
COMMIT;
Instead Of Triggerによって、DEPARTMENTテーブルのDEPTNOがA00010のデータのレコード終了タイムスタンプを更新。更新後、レコードが新規に挿入される。
3. 更新後の照会 （時刻設定は現在）
SET TMPLTEST02.PERFORM_TIMESTAMP =CURRENT TIMESTAMP;
SELECT * FROM TMPLTEST02.DEPARTMENT_VIEW
ORDER BY DEPTNO;
2.で更新したデータが表示される（図表14）。
4. 更新後の照会（時刻設定は更新タイミングの前に設定）
SET TMPLTEST02.PERFORM_TIMESTAMP=’2016-07- 05-19.25.00′;
SELECT * FROM TMPLTEST02.DEPARTMENT_VIEW ORDER BY DEPTNO;
更新前のデータが表示される（図表15）。
見てわかるように、同じ操作結果が得られる。しかしSQL実行の際に事前にSQL Global 変数のセットが必要であり、テンポラル・テーブルと比較するとわかりやすさや簡便性に劣るのが実感できる。
以上、テンポラル・テーブル機能がBI／DWHで基本となるSCD Type 2 Dimensional Modelingに適用できることが理解いただけたと思う。このことは、IBM iのDBで従来から利用されている業務データ処理に加えて、BI／DWHでも活用できるディメンショナル・モデリングを従来のDB2 for i環境へ容易に統合・活用する道が広がったことを示すものであろう。
著者｜箕手 幸広 氏
日本アイ・ビー・エム システムズエンジニアリング株式会社
テクノロジー・ソリューション
インテグレーションサービス
［i Magazine 2016 Winter（2016年11月）掲載］
