DWHにおける時間性（Temporality）第3部：時間軸の出力要件

多くの場合、レポート層で複数の時間軸（タイムライン）をそのまま出力する必要はありませんが、時間軸の出力が不可欠となる重要な業務要件も確かに存在します。

代表的な例は以下の通りです：

• 顧客の変遷履歴の表示（1d：業務有効時間）
• 事後修正されたデータを可視化し、不正検知や正当な訂正を把握する（2d：登録時刻）
• 異なる時点における認識状態を柔軟に比較し、相対的な変化を検証する（3d：ロード日時）

※「1d（業務有効性）」「2d（登録時刻）」「3d（ロード日時）」の概念をまだご覧になっていない方は、本連載の第1部：定義と課題を先にお読みいただくことをお勧めします。

1dタイムラインの出力：顧客履歴の表示

集計レポートから個別ケースへとドリルダウンする際、個々の顧客の変遷（いつどの地域に住み、いつどの契約プランに変更したか）を詳細に把握したい場合があります。例えば、既存顧客がDSL回線を解約し、後に光ファイバー回線を契約したようなケースです。背景を理解するためにサンプルを抽出し、分析結果をもとに新たなビジネスルールを策定して、後から全体集計へと還元します。

これは1d（業務有効期間）の履歴です。

本連載の第2部で解説したように、ビジネスキーに有効開始日（Valid From）を連結してテンポラル・インスタンス・ハブを作成すれば、ハブの粒度と出力すべきデータの粒度が完全に一致するため、出力時の複雑な加工は不要です。

唯一考慮すべき点は、ソース側で有効開始日（Valid From）が前後にずれた場合、キーの一部が変更されるため、DWH側では「1行の削除」と「1行の新規追加」として認識されることです。

そのため、無効となった古いタイムスライスを特定・除外する仕組みが必要になります。

これには「トラッキングサテライト（Tracking Satellite）」を用い、ソースシステム側にキーがまだ存在しているかどうかを追跡します。これはフルロード時（全件キー比較）に威力を発揮します。ソースから明示的な削除通知が届かない場合、差分ではなく全件のキーと有効日を比較することで暗黙の削除を確実に検知します。

レポート出力時には、トラッキングサテライトを結合し、ソースに存在しない古いレコードを除外するか、削除フラグとして提示します。

Datavault Builderではトラッキングサテライトの生成や仮想フィールドの読み出しは完全自動化されています。このアプローチの最大の美点は、代理キー（サロゲートキー）を一切生成する必要がない点です。ビジネスキー＋Valid From（またはそのハッシュ値）によって一意性が担保され、ルックアップや多段JOINなしでそのままレポート出力できます。

2dタイムラインの出力：不正検知と事後訂正

数年前、ある顧客企業で営業コミッション（歩合給）の算出における不正調査を依頼されたことがありました。その会社では、毎月1日時点での月間成約数に基づいてコミッションを算定していました。商品の在庫状況によっては納品や請求が2〜3週間遅れることがありました。

悪質な一部の営業担当者は、月末の最終日に架空の大型契約を大量に入力し、コミッション確定直後の翌月2日にそれらの契約を一斉に解約（事後キャンセル）していたのです。

単一の受注データだけを見れば、「同日中に入力されてキャンセルされた」通常の商談破談に見えます。しかし、月末時点の認識と2日後の認識を比較すると、不正のパターンが明白に浮き彫りになりました。もっとも、正当なクーリングオフなど合法的理由によるキャンセルもあるため、単純に契約を無効化するだけでは解決しません。

解決策の検討：

ソースシステムが変更の都度「登録時刻（2d: Inscription Time）」を記録していれば、履歴を正確に復元できます。

ソース側で登録日時は保持しているものの変更履歴自体は残らない場合、DWH側での3d（ロード日時）の蓄積を用いて2d履歴を再現します（DWHへのロード頻度が高ければ高いほど、2dの近似精度は向上します）。

単に3d履歴を持つサテライトデータをSCD Type 2としてそのままレポートへ流し込んでも、集計者は何をどう解釈すべきか分かりません。

私たちが必要としているのは、「不変の時間軸上における契約の締結イベントと解約イベント」です。契約ステータスの推移からビジネスイベントを導出します：

解約イベントにマイナス値を設定するルール（ルール1）を適用しても、悪質な担当者が解約直前に担当営業者コードを同僚に変更してペナルティを回避しようとするケースがあります。

そこで、「直前の成約イベント時の営業担当者を引き継ぐ」ルール（ルール2）を導入して不正を遮断します：

さらに、非線形な歩合率に対応するため、補正が適用される対象月期間を明示的に導出します（ルール3）：

お分かりいただけるように、単にサテライトのデータを「SCD Type 2形式で吐き出す」だけでは何の解決にもなりません。異なる時間軸上のイベントをビジネスルールに基づいて正しく解釈して初めて、有益なビジネスインテリジェンスが生まれます。

したがって、第2部で提示した基本方針がここでも完全に有効です：

基本方針：2d（登録日時）はサテライトの通常属性として格納しておき、分析が必要になった段階で3d履歴を解釈してイベント化する

3dタイムラインの出力：認識状態の再現と比較

3dタイムライン（DWHロード日時）の出力が求められる典型的な理由は、「過去レポートの完全な再現性」です。これはSarbanes-Oxley法、バーゼル規制（Basel I/II/III）など、法規制への対応において極めてクリティカルな要件です。

ただし、現代のクラウドデータウェアハウスでは、データベースのネイティブ機能で解決できるケースが増えています。例えばSnowflakeの「Time Travel（タイムトラベル）」機能を使えば、SELECT ... AT(TIMESTAMP => ...) を実行するだけで、追加のモデリングなしに過去特定時点の認識状態を即座にクエリできます。また、CLONE AT を使えば特定時点のスナップショットデータベースを追加ストレージコストなしで瞬時に作成できます。

認識状態の比較（Compare Knowledge Levels）

では、「毎日の認識状態を自在に呼び出し、2つ以上の時点の認識差分を比較分析したい」という要件がある場合はどうでしょうか？

ビジネスユーザーが過去の認識推移を厳密に比較することを真に求めている場合、3dタイムラインに対して明示的なSCD Type 2出力を構築する必要があります。この具体的な技術実装については、本連載の第4部で解説します。

まとめ

データウェアハウスの現場において、「とりあえずすべてのディメンションをSCD Type 2で出力する」という設計が横行しています。しかし、ビジネスユーザーの真の目的を分析しないまま機械的にSCD Type 2を出力すると、レポートクエリが不必要に肥大化し、セルフサービスBIの活用を著しく阻害します。

時間軸の性質（1d/2d/3d）とビジネスの目的を正しく見極め、適切なモデリング手法と抽象化レイヤーを選択することが成功への不可欠な鍵となります。