履歴

最終公開日 : Sep 16, 2026
Related information

概要

履歴は、テーブル上のすべてのデータ変更 (レコードの作成、更新、削除) を追跡できる機能です。
これは、非推奨の XML 監査証跡 を改良したものです。
以下も参照してください。:

履歴の構成

テーブルの履歴化を有効にするには、データモデル内のテーブルに履歴プロファイルを設定する必要があります。このセクションでは、履歴プロファイルと、それがテーブルに関連付けられる方法について説明します。

リポジトリの履歴の構成

履歴プロファイルは、履歴化がいつ作成されるかを指定します。履歴プロファイルを編集するには、 > を選択します。
履歴プロファイルは名前で識別され、次の情報を定義します。
  • 国際化されたラベル。
  • 履歴が有効化されているデータスペース (ブランチ) のリスト。直接の子および/またはすべての子孫も対象とするかどうかを指定できます。
リポジトリのインストール時に、いくつかのプロファイルがすでに作成されています。これらのプロファイルは削除も変更もできません。
プロファイル ID 説明
ebx-referenceBranch このプロファイルは参照データスペースでのみアクティブ化されます。
ebx-allBranches このプロファイルはすべてのデータスペースでアクティブ化されます。
ebx-instanceHeaders このプロファイルはデータセットヘッダーを履歴化します。ただし、内部データモデルではデータセットノードのみが定義されるため、このプロファイルは将来のバージョンでのみ設定されます。

データモデルでの履歴の構成

テーブル履歴の有効化

履歴は、データモデルアシスタントを使用するか、基になるデータモデルを編集することによって、テーブル上でアクティブ化できます。
データモデルを編集して履歴を有効にするには、historyProfile エレメントを使用してテーブルに履歴プロファイルを宣言する必要があります。
<osd:table>
    <primaryKeys>/key</primaryKeys>
    <historyProfile>historyProfileForProducts</historyProfile>
</osd:table>
データモデルアシスタントを使用すると、リポジトリで定義されている履歴化プロファイルを表示できます。
履歴化は各テーブルごとに個別に有効にする必要があります。詳細については、モデル設計 ドキュメントを参照してください。

特定のフィールドまたはグループの履歴の無効化

履歴化されたテーブルの場合、デフォルトの動作では、サポートされているすべてのエレメントが履歴化されます (履歴モードの影響と制限 を参照)。
データモデルアシスタントを使用するか、基になるデータモデルを編集することにより、特定のフィールドまたはグループの履歴を無効にすることができます。
データモデルを編集してフィールドまたはグループの履歴を無効にするには、属性 disable="true" を持つエレメント osd:history を使用します。
<xs:element name="longDescription" type="xs:string">
    <xs:annotation>
        <xs:appinfo>
            <osd:history disable="true" />
        </xs:appinfo>
    </xs:annotation>
</xs:element>
データモデルアシスタントを使用してフィールドまたはグループの履歴を無効にするには、エレメントの Advanced プロパティ の History プロパティを使用します。
このプロパティがグループで定義されている場合、履歴はそのすべての子孫に対して再帰的に無効になります。グループが履歴を無効にすると、子孫の履歴を具体的に再度有効にすることはできません。
注意:
フィールドまたはグループを含むテーブルが履歴に記録されていない場合、このプロパティは効果がありません。
主キーフィールドの履歴を無効にすることはできません。

整合性

データモデルのコンパイル時に問題が検出された場合、警告メッセージまたはエラーメッセージがこのデータモデルに関連付けられた検証レポートに追加されます。さらに、エラーが検出されると、関連する各インスタンス (データセット) にアクセスできなくなります。最も一般的なエラーケースは次のとおりです。
  • テーブルは、リポジトリで定義されていないプロファイルを参照しています。
  • データモデルで参照されている履歴プロファイルは、現在のリポジトリ内の未定義または閉じたデータスペースに言及しています。
注意:
予期されたプロファイルがないリポジトリにデータモデルを展開するには、管理者がそれらを追加する必要があります。

履歴ビューと権限

テーブル履歴ビュー

データモデルのテーブルで履歴がアクティブ化されると、ユーザーインターフェイスのさまざまな場所 (レコード、レコードの選択、テーブル、データセット) から履歴ビューにアクセスできます。
次のセクションでは、アクセス許可がどのように解決されるかについて説明します。
詳細については、テーブル履歴ビュー セクションを参照してください。Java からテーブル履歴ビューにアクセスするには、メソッド AdaptationTable.getHistory を呼び出す必要があります。

テーブル履歴の権限

データ権限はデータ履歴にも適用されます。履歴権限は、データ権限と アクセス権の間で最も制限された権限として自動的に解決されます。
これは、ユーザー定義のアクセス許可ルールとプログラムによるアクセス許可ルールにも当てはまります。
プログラムルールを定義する際、機能的なデータセットコンテキストと履歴ビューコンテキストを区別する必要がある場合があります。これは、期待される権限が同じでない、または履歴構造に存在しないフィールドがあるためです。これには、データセットフィールド、計算値、および履歴が無効になっているフィールド があります。次に、メソッド Adaptation.isHistory および AdaptationTable.getHistory をプログラムルールで使用して、履歴動作に関する特定の実装を行うことができます。
注意:
現在、テーブルにスクリプト化されたレコードのアクセス許可ルールが指定されている場合、制限があります。セキュリティ上の理由から、テーブル履歴へのアクセスはすべてのユーザーに対して完全に無効になっています。履歴へのアクセスは、将来のバージョンで許可される予定です。

トランザクション履歴ビュー

トランザクション履歴ビューを使用すると、テーブル、データセット、またはデータモデルに関係なく、実行されたトランザクションにユーザーインターフェイスから直接アクセスできます。
テーブルを表示するには、 領域に移動し、ナビゲーションペインの下矢印メニューを使用して を選択します。トランザクション履歴には、履歴化されたデータスペースを選択し、ワークスペースの メニューを使用して、データスペース領域からアクセスすることもできます。
詳細については、トランザクション履歴ビュー を参照してください。

サイドバーの履歴サービス

サイドバーからレコードの履歴ビューにアクセスします。このビューには、次のリストが表示されます。
  • トランザクション
  • 変更されたフィールド値
  • レコードを変更したユーザー
  • タイムスタンプ
トランザクションを日付と時刻で並べ替えたり、フィールドでフィルタリングしたりできます。履歴表示は、多値リストタイプを含む、単純型と複合型の両方のデータタイプをサポートしています。

履歴への SQL アクセス

このセクションでは、SQL を使用して履歴データに直接アクセスする方法について説明します。

アクセス制限

データベーステーブルには、読み取り専用モードでのみアクセスする必要があります。データベースアクセスとユーザー権限のルール のセクションで指定されているように、TIBCO EBX® で使用されるデータベースユーザーを除いて、書き込みアクセスを禁止するのはデータベース管理者の責任です。

リレーショナルスキーマの概要

データベース内の履歴テーブルの説明は次のとおりです。
データベーススキーマには次のものが含まれます (次のセクションのダイアグラムも参照してください)。
共通および汎用テーブル
メインテーブルは HV_TX です。このテーブルの各レコードはトランザクションを表します。少なくとも 1 つの履歴テーブルを含むトランザクションのみが記録されます。
これらの共通テーブルにはすべて「HV」というプレフィックスが付いています。
特定の生成されたテーブル
履歴テーブルごとに、特定の履歴テーブルが生成されます。このテーブルには、テーブルのデータ変更の履歴が含まれています。
EBX® ユーザーインターフェイスでは、データベース内のこのテーブルの名前は、テーブルのドキュメントペイン (詳細モード) をクリックして取得できます。すべての特定の履歴テーブルには、「HG」というプレフィックスが付いています。

生成された履歴テーブルの例

次の例では、product というテーブルを履歴にしています。このテーブルが EBX® データモデルの 3 つのフィールドを宣言していると仮定します。
Product
  • productId: int
  • price: int
  • beginDate: Date
    次のダイアグラムは、結果のリレーショナルスキーマを示しています。
    scaphas
    このテーブルで履歴をアクティブ化すると、上記の履歴スキーマ構造に示されている HG\_product テーブルが生成されます。さまざまなフィールドの説明は次のとおりです。
  • tx_id: トランザクション ID。
  • instance: インスタンス ID。
  • op: 操作タイプ - C (作成)、U (更新)、または D (削除)。
  • productId: productId フィールド値。
  • OproductId: productId の操作フィールド。次のセクションを参照してください。
  • price: price フィールド値。
  • Oprice: price の操作フィールド。次のセクションを参照してください。
  • beginDate: date フィールド値。
  • ObeginDate: beginDate の操作フィールド。次のセクションを参照してください。

操作の組み合わせ

同じトランザクションで複数の操作が組み合わされた場合、操作フィールドは次のように解決されます。
  • C + U -> C
    D + U -> D
    D + C -> U
    C + D - > {} (履歴にエントリなし)

操作フィールドの値

機能フィールドごとに、文字 O が前に付いたフィールド名で構成される追加の操作フィールドが定義されます。このフィールドは、機能フィールドが変更されているかどうかを指定します。次のいずれかの値に設定されます。
  • null: 機能フィールドの値が変更されていない場合 (およびその値が INHERIT ではない場合)。
  • M: 機能フィールドの値が変更されている場合 (継承ではない)。
  • D: レコードが削除された場合。
    継承 が有効になっている場合、操作フィールドには次の 3 つの追加値を含めることができます。
  • T: 機能フィールドの値が変更されておらず、その値が INHERIT の場合。
  • I: 機能フィールドの値が INHERIT に設定されている場合。
  • O: レコードが OCCULTING モードに設定されている場合。

履歴モードの影響と制限

履歴機能には、いくつかの影響と既知の制限があります。これらは、このセクションに一覧表示されます。履歴化モードを使用する場合は、これらの制限を注意深く読み、質問があれば Cloud Software Group, Inc. のサポートに連絡することを強くお勧めします。

検証

一部の EBX® データモデル制約は、テーブル履歴がアクティブ化されるとブロッキング制約になります。詳細については、構造上の制約 のセクションを参照してください。

履歴テーブルのデータモデルの制限

履歴テーブルを含むデータモデルには、いくつかの制限が適用されます。
  • マップモードによるデータモデルの制限
  • 別の集約リストの下の集約リストと、ターミナルグループの下の集約リストの 2 種類の集約リストには制限があります。このような集約リストを含むデータモデルを使用できますが、これらのリストは無視されます (履歴は作成されません)。
  • 計算された値は無視されます。
  • リンクされたフィールドは無視されます。
  • 履歴テーブルのユーザー定義属性により、データモデルのコンパイルエラーが発生します。
    データモデルの進化は、関係するテーブルにすでに含まれているデータに応じて、基盤となる RDBMS によって制約される場合もあります。
以下も参照してください。:

履歴モードのその他の制限

  • 既存のデータを含むテーブルが履歴に対してアクティブ化されている場合、データのコピーは実行されません。
  • データセットに対するグローバル操作は、履歴テーブルを宣言している場合でも、履歴化されません (インスタンスの作成と削除)。
  • 非履歴フィールドを参照するデフォルトのラベルは、履歴テーブルではサポートされていません。
    結果として、計算フィールドを参照するデフォルトのラベルは、履歴テーブルではサポートされていません。
    回避策は、UILabelRenderer インターフェイスを実装し、ラベル計算を履歴に適合させることです。
  • D3: 履歴はプライマリノードの配信データスペースで有効にできますが、レプリカノードの配信データスペースでは履歴機能は常に無効になります。
  • 履歴に記録されたユーザー：特定の操作によっては、最後の操作を実行したユーザーと、対応する履歴レコードに記録されたユーザーが異なる場合があります。
    これは、これらの操作が実際には前の状態でのデータステータスのレポートであるという事実によるものです。
    • アーカイブのインポート：データスペースにアーカイブをインポートする場合、子データスペースで最後に実行された操作の時間とユーザーが保持されますが、履歴に記録されるユーザーはインポートを実行するユーザーです。
    • プログラムによるマージ：データスペースでプログラムによるマージを実行すると、子データスペースで最後に実行された操作の時間とユーザーが保持されますが、履歴に記録されるユーザーはマージを実行するユーザーです。
    • D3: 分散データ配信機能の場合、ブロードキャストが実行されると、プライマリノードからのデータがレプリカノードに報告され、子データスペースで実行された最後の操作の時間とユーザーが保持されますが、履歴に記録されるユーザーは「ebx-systemUser」となり、ブロードキャスト時のレプリカノードでのレポートの実行は、このユーザーによって行われます。