Nontemporarl・Unitemporal・Bitemporalの特徴と設計

データモデルには、時間軸（履歴や有効期間など）をどのように管理するかによって、いくつかのパターンが存在する。

1. Nontemporal（ノンテンポラル）
2. Unitemporal（ユニテンポラル）
3. Bitemporal（バイテンポラル）

それぞれは「時間情報をどの程度細かく、どのような意味で管理するか」という点で異なる。

これらのデータモデルの特徴や設計例、メリット・デメリットについて解説する。

1. Nontemporal（ノンテンポラル）データモデル

特徴

• いわゆる「現在のみを管理する」データモデルで、時間軸を全く扱わないか、扱っても参照用の日時程度に留まるケース。
• データベース上のレコードは常に最新版の状態のみを保持し、過去や未来の履歴や有効期間は格納しない。

設計例

• 一般的なOLTPシステムのテーブル構造や、履歴管理を要しない運用系システムなど。
• テーブル定義例：

  CREATE TABLE product (
      product_id    INT PRIMARY KEY,
      product_name  VARCHAR(100),
      price         INT,
      update_date   DATETIME DEFAULT CURRENT_TIMESTAMP,
      -- update_dateはあくまでいつ更新されたかを表す程度で、有効期間の管理等は行わない
      ...
  );
  

メリット

• テーブル構造がシンプルで、開発・運用コストが低い。
• クエリが単純で、パフォーマンスも高い（履歴を考慮しなくて良い）。

デメリット

• 過去や未来の状態を追跡できない。履歴の分析が必要な場合に対応できない。
• 更新のたびに情報が上書きされるため、監査や法令対応で「いつ」「どのように」変更があったかを正確に追跡できない。

2. Unitemporal（ユニテンポラル）データモデル

特徴

• 「単一の時間軸」を管理するデータモデル。一般的には「システム時間(レコードがデータベースに存在していた期間)」または「ビジネス上の有効期間(業務上の開始日・終了日など)」のいずれかを管理する。
• 履歴トラッキングを行うために、日付・時刻列やバージョン管理の仕組みを設ける。

パターン例

1. システム時間（トランザクションタイム）を管理

   • データベースに「このレコードがいつINSERTされ、いつDELETEされたか（あるいは無効化されたか）」を管理する。
   • 主に監査目的や、DB上の履歴を遡って参照する場合に有用。

2. ビジネス時間（有効期間）を管理

   • 「このレコードがビジネス上いつからいつまで有効か」を表す。
   • 価格や契約期間、組織改編の有効期間など、業務ロジック上の“有効日付”が重要となるケースで使う。

設計例（ビジネス時間管理の場合）

• 「契約」のユニテンポラルモデル例

  CREATE TABLE contract (
      contract_id         INT PRIMARY KEY,
      contract_name       VARCHAR(100),
      valid_from          DATE,   -- この契約が開始する日
      valid_to            DATE,   -- この契約が終了する日（業務上の有効期限）
      updated_at          DATETIME DEFAULT CURRENT_TIMESTAMP,
      ...
  );
  

• 過去の契約内容や今後の有効期間を参照・管理できるよう、INSERT/UPDATEの運用ルールやアプリケーションロジックが必要。

メリット

• Nontemporalよりも柔軟に履歴を追跡可能。指定した時間におけるビジネス上の状態を再現しやすい。
• バージョン管理や監査ログを兼ねる場合は、システム時間を保持するモデルがよく使われる。

デメリット

• テーブルの管理がNontemporalより複雑になる。INSERT/UPDATE時に期間の整合性を保つためのロジックが必要。
• バージョンが増えるとデータ量が肥大化し、クエリの複雑度とパフォーマンス負荷が増加する。

3. Bitemporal（バイテンポラル）データモデル

特徴

• システム時間（レコードがDBで有効な期間）とビジネス時間（業務上有効な期間）の両方を管理する。
• 例えば、以下の2つの時間軸を管理する。
  1. 有効期間(ビジネス時間): 業務的に「このレコードがいつからいつまで有効か」を示す期間
  2. トランザクション期間(システム時間): データベース上で「いつからいつまでこのレコードが存在したか」を示す期間
• 「過去のある時点では業務的にこういう状態だが、DB上ではいつ登録されいつ修正されたか」「将来のデータを誤って事後修正したい」「過去分の有効期間を事後訂正したい」など、ややこしい変更管理にも対応できる。

設計例

以下は一例です。実際にはDB製品や要件に応じて型や制約は様々ですが、概念としては同様になります。

CREATE TABLE contract_bitemporal (
    contract_id          INT,
    contract_name        VARCHAR(100),
    business_from        DATE,   -- ビジネス上の有効開始日
    business_to          DATE,   -- ビジネス上の有効終了日
    system_from          TIMESTAMP, -- DB上でこのレコードが有効になった時刻
    system_to            TIMESTAMP, -- DB上でこのレコードが無効化(または論理削除)された時刻
    ...
    PRIMARY KEY (contract_id, business_from, system_from)
    -- PK設計の方法は要件次第
);

• business_from, business_to 業務上の契約有効期間。例えば、2025年1月1日から2025年12月31日まで有効、といった形で設定する。
• system_from, system_to レコードがDBにINSERTされた日時をsystem_fromに入れ、当該レコードがUPDATEされて新しいバージョンがINSERTされる際には古いレコードのsystem_toをセットする、といった扱いにする。
• バイテンポラルでは、「いつ（業務上の視点）」「いつ（データベース上の視点）」の両面から履歴を問い合わせできるようになる。

メリット

• 最も柔軟で完全な履歴管理が可能。過去のビジネス有効期間の状態を、さらに「いつの時点のDB視点で見たか」を再現できる。
• 監査要件や法的要件で「後から過去データを修正し、再度正しい履歴を持たせたい」など高度な変更履歴管理が求められる場合に有効。

デメリット

• 設計・運用が最も複雑。データのInsert/Update/Deleteすべてに複雑な制御・ルールが必要となる。
• データ量やバージョン数が急増しやすく、パフォーマンスやストレージ管理の工夫が不可欠。
• システム時間とビジネス時間を混同しないようなアプリケーションロジック・クエリの作り込みが要求される。

まとめと選定のポイント

1. Nontemporal
   • 「現在の状態のみを管理できればよい」「履歴を遡る必要がない」シナリオに最適。
   • 設計や実装、パフォーマンス、運用は最も簡単。
2. Unitemporal
   • 過去や未来の履歴をある程度管理したい場合に有効。
   • システム時間かビジネス時間、いずれかの軸がクリティカルな場合に選択。
3. Bitemporal
   • システム時間とビジネス時間の両方を正確に管理し、柔軟に過去状態を再現・訂正したい場合に使用。
   • 最も高機能だが、設計・実装・運用が難しく、データ量も増えやすい。

選定基準としての考え方

• 監査・法令遵守が厳しい業務、または事後訂正が頻繁に発生する業務ではバイテンポラルが求められやすい。
• 実装コストやパフォーマンスとトレードオフで、システム負荷・要件の複雑度を見極める。
• 将来的な拡張を見越してUnitemporalやBitemporalにしておきたい場合も多いが、その分初期コストや運用が重くなるので、要件の優先度とのバランスが重要。

補足

• RDBMSの中には、標準でシステム時間の履歴を管理できる（いわゆる「テンポラルテーブル」機能）製品がある（例: SQL Server の System-Versioned Temporal Table、Oracle の Flashback など）。
• バイテンポラルをネイティブにサポートしているかはDB製品により様々だが、標準機能がない場合でもテーブル設計と運用ロジックで実現が可能である。（ただし、複雑度が高くなる）