履歴

概要

履歴は、テーブル上のすべてのデータ変更 (レコードの作成、更新、および削除) を追跡できる機能です。

これは、非推奨の 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

次のダイアグラムは、結果のリレーショナルスキーマを示しています。

このテーブルで履歴をアクティブ化すると、上記の履歴スキーマ構造に示されている 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」となり、ブロードキャスト時のレプリカノードでのレポートの実行は、このユーザーによって行われます。