DWHにおける時間性（Temporality）第1部：定義と課題

過去数年間、筆者はSCD Type 2（緩やかに変化するディメンション・タイプ2）を用いたレポーティングの要件に幾度となく直面してきました。しかし、データウェアハウスには通常3つ以上の時間軸（タイムライン）が存在するため、ビジネス要件が真に求めているものが何であるかを何度も明確化する必要がありました。本連載では筆者の思考を整理し、こうした議論を行うための明確なガイドラインを提示します。

本記事は以下の構成でお届けします：

• 異なる時間軸（タイムライン）の定義
• 第2部：DWH出力の時間軸を削減し、使いやすいレポートを作成する
• 第3部：どのようなユースケースで複数時間軸の出力が必要となるのか
• 時間平面全体を出力する技術的ソリューション、タイムスライス（Time Slice）、SCD Type 2、そしてas-is、as-was、as-ofの相互関係

時間軸（タイムライン）とは何か？タイムスライスとは？SCD Type 2とは？as-is / as-was / as-of との関係性

単純な世界では、「今、ここ」という現在しか存在しません。時間の経過に伴う推移を記録したい場合、私たちは時間軸（タイムライン）を必要とします。

任意の場所でタイムラインを切断（スライス）すれば、特定の「時点（Point in time）」へと変換できます。

しかし、タイムライン上の過去のデータを修正・訂正する場合、その変更が発生した時刻を別の独立したタイムライン上に記録できます。

これら2本のタイムラインを直交（90度）させると、「時間の平面（Time Surface）」が生まれます。

いずれかの軸に平行な直線でこの時間平面を切断すれば、いつでも再び1本のタイムラインへと縮約できます。

このように、時間平面を1本のタイムラインへ、そしてそれをさらに単一の時点へと還元することができます。

このような断面（カット）を「as-of ビュー（〜時点のビュー）」と呼びます。これには特別な断面が2つあります。1つは現在有効な時点（必ずしもタイムラインの終端とは限らない）で切断する「as-is（現状ビュー）」です。もう1つは、過去の特定のイベント発生時における情報状態を表す「as-was（当時の認識ビュー）」です。つまり、as-is、as-was、as-of のいずれの断面であっても、平面から直線へ、直線から点へと単純化する論理構造は同一です。

この単純化した例では、第1の時間軸として「ビジネス上の有効期間（業務有効期間）」、第2の時間軸として「その情報が業務ITシステムに記録された時刻」を選択でき、これで2次元の時間平面が成立します。

しかしデータウェアハウスでは、さらに第3の時間軸が加わります。「データウェアハウスがその新規または変更情報をいつ認識・受領したか」です。この第3のタイムラインを既存の時間平面に対して垂直に交差させると、3次元の「時間の立方体（Time Cube）」が完成します。筆者がこれらを「時間次元（Time Dimensions）」と呼ぶのはこのためです。4次元以上を直感的にイメージすることは困難であるため、ここではこれら3つの主要な時間軸に絞って説明を進めます。

用語の混乱を避けるため、筆者はこれら3つの軸を次元番号で呼ぶアプローチを好みます：

• 1d（第1次元）：業務上の有効期間（Valid Time）。 業務上の現実において、その事象がいつ有効であったか。Snodgrassの言葉を借りれば「変化する現実の歴史を捉える時間」。
• 2d（第2次元）：ソースシステムへの登録時刻（Inscription Time / System Time / Logged Time）。 ソースITシステムにおいてデータが真であると主張（アサーション）された時間。
• 3d（第3次元）：DWHへのロード時刻（Load Time / Acquisition Time）。 データウェアハウスがその情報を取得・永続化した時間。

タイムスライス（Time Slice）

タイムスライスとは、特定かつ識別可能なオブジェクトの属性が変化しない、タイムライン上の連続した期間区間です。タイムスライスは明示的な開始日と終了日で記述される場合もあれば、新しいエントリが始まった瞬間に前のエントリが暗黙的に終了したとみなされる場合もあります。後者の場合、終了していないタイムスライスは永遠に（あるいはDBの最大日付値まで）有効とみなされます。

実際の業務有効期間（1d）では、契約解約期間のように業務オブジェクトが無効となる休眠期間が存在し得るため、明示的な開始時刻と終了時刻を保持することが一般的です。

一方、2d（登録日時）や3d（ロード日時）のタイムラインでは、新規エントリの発生時刻が前のエントリの終了時刻を暗黙的に意味するため、終了時刻を明示的に永続化する必要はありません。

時間軸の呼称

Christian Kaul氏が様々な呼称を整理していますが、業界全体で統一された合意は未だありません。最低限の共通認識として、第1の時間軸は「Valid Time（有効時間）」と呼ぶべきでしょう（DWHのLoad Timeを誤ってVALID_FROM / VALID_TOと呼ぶ習慣もありますが、混乱のもとです）。

筆者の推奨呼称は以下の通りです：

• 1d: Valid Time（有効時間）
• 2d: Inscription Time（登録時刻）
• 3d: Load Time（ロード日時）

重要なのは名称の議論ではなく、全員が各軸の意味を理解し、データが発生・記録される順序に基づいた 1d / 2d / 3d という明確なショートカットを共有することです。

SCD Type 2 とは何か？

SCD Type 2（Slowly Changing Dimensions Type 2）とは、異なる時点で受信した情報から新しい時間軸を文書化・履歴化するための手法です。

通常、この用語はデータウェアハウスにおける「3d（ロード日時）のタイムライン」を生成する処理の同義語として使われています。DWHへのロード時刻が新しいタイムスライスの開始となり、同一キーに対する次回ロード時刻が前エントリの有効期間を暗黙的に終了させます。

この手法の大きな利点は、ソースシステムで生じたすべての変更を捕捉し、任意の時点において「当時何が真実とみなされていたか」を完全に再現して出力できる点にあります。

しかし問題は、多くのDWH実装やデータモデラーが、「自分たちがここで表現しているのはどの時間軸なのか？」「この時間軸はレポーティング要件を満たすために本当に適切なのか？」「ビジネス評価において本当にこの履歴が必要なのか？」「記録された変更は単なるデータ誤りの訂正なのか、それとも現実世界での状態変化なのか？」という本質的な問いを立てていないことです。

ビジネス要件の精査を怠ると、すべてのレポートであらゆるディメンションをSCD Type 2形式で無差別に肥大化出力する、無分別な実装に陥ります。この理解不足こそが、3dのロード日時にVALID_FROM / VALID_TOという紛らわしい名称をつけてしまう悪習の根本原因でもあります（Data Vaultの世界においてダン・リンステッド氏が「Load Time」という明確な用語を定着させたことは幸いでした）。

本連載の続きでは、特定のケースにおいてこれが単に無駄であるだけでなく、誤った分析結果を導く危険性について解説します。同時に、Data VaultおよびDWH全般において時間を正しく扱うための代替ソリューションを提案します。

• 第2部：複雑さの排除
• 第3部：時間軸の出力要件