永続性の概要

最終公開日 : Sep 16, 2026
この章は、履歴テーブルとレプリケートされたテーブルの概要です。
注意:
マップモード という用語は、そのまま保存されているため、データベース内のコンテンツに直接アクセスできるテーブルを指します。
Related information

管理対象マスターデータのプライマリ永続性

EBX® リポジトリでモデル化および管理されるデータは、一般的なテーブル (すべてのデータセットとデータモデルに共通) を使用して、主にリレーショナルデータベースに保持されます。

履歴化

マスターデータテーブルは、複製されているかどうかに関係なく、データへの変更を追跡するために履歴をアクティブ化できます。
履歴自体はマップモードです。つまり、基になるデータベースで直接参照できます。
以下も参照してください。:

レプリケーション

レプリケーションでは、リポジトリ内のデータのコピーをリレーショナルデータベース内のレプリカテーブルに作成することにより、マスターデータのテーブルへの直接 SQL アクセスが可能になります。履歴がアクティブ化されているかどうかに関係なく、任意のテーブルでレプリケーションを有効にできます。
レプリカテーブルは、主な目的が EBX® の外部の直接クエリにマスターデータにアクセスできるようにすることであるため、マップモードで永続化されます。
以下も参照してください。:

マップモード

マップモードの概要

マップモードとは、EBX® の外部でデータに直接アクセスできる形式で、テーブルが基になるリレーショナルデータベースに永続化される場合を指します。履歴テーブルとレプリカテーブルはすべて、マップモードのテーブルの例です。
マップモードのすべてのケースでは、必要な DDL ステートメントをバックグラウンドで自動的に実行することにより、必要に応じてデータベーススキーマ (データベーステーブル、インデックスなど) を自動的に変更します。このような手順は常にデータモデルのコンパイル時にトリガーされ、データモデルのコンパイルレポートは結果として生じるエラーを通知します。
マップモードに関するもう 1 つの一般的な考慮事項は、ほとんどの場合、データモデルエンティティが削除されても、対応するデータベースオブジェクトはすぐには削除されないということです。代わりに、無効としてマークされているため、後でオブジェクトを再度有効にする可能性があります。オブジェクトとそれに関連するデータおよびリソースをデータベースから確実に削除するには、パージのマークを付ける必要があります。削除は、次のグローバルパージ中に行われます。
以下も参照してください。:

構造上の制約

マップモードが設定されている場合、一部の EBX® データモデル制約は、基になる RDBMS スキーマに「構造制約」を生成します。これは、次の制約ファセットに関係します。
  • string エレメントのファセット xs:maxLength および xs:length
  • xs:decimal エレメントのファセット xs:totalDigits および xs:fractionDigits
    データベースは、EBX® ほど寛容な検証モードをサポートしていません。したがって、上記の制約は ブロッキング制約 になります。ブロッキング制約とは、更新が準拠していない場合に更新が拒否されることを意味します。トランザクションがブロッキング制約に準拠していない場合、トランザクションはキャンセルされ、ConstraintViolationException がスローされます。
以下も参照してください。:

マップモードによるデータモデルの制限

基になるデータベースに直接保存するという性質上、マップモードで保存されるすべてのテーブルにはいくつかの制限が適用されます。
  • 長さ無制限の文字列:外部キーを除く、xs:string 型、その派生型、および xs:anyURI のすべての文字列フィールドは、'maxLength' または 'length' ファセットを定義する必要があります。外部キーフィールドは、そのターゲットテーブルの最終主キーフィールドで構成されるため、このファセット要件は、外部キーフィールド自体ではなく、最終主キーフィールドのそれぞれに適用されます。さらに、VARCHARNVARCHAR2 などの文字型の最大長に関する、基になるデータベースの制限が適用されます。
  • type="osd:password" 型のフィールドは無視されます。
  • ターミナル複合型はサポートされていますが、レコードレベルでグローバルに null に設定することはできません。
より一般的には、マップモードのテーブルは、基になる RDBMS の制限に従います。たとえば、テーブル内の列の最大数が適用されます (Oracle の場合は 1000、PostgreSQL の場合は 1600)。履歴テーブルには、スキーマで宣言されたフィールドの 2 倍の数のフィールド (機能フィールド 1 つと、操作コード用に生成されたフィールド 1 つ) が含まれていることに注意してください。
既存のデータモデルに応じて、データモデルの進化は、基になる RDBMS によって制約される場合もあります。
以下も参照してください。: