この章は、履歴テーブルとレプリケートされたテーブルの概要です。
マップモードという用語は、そのまま保存されているため、データベース内のコンテンツに直接アクセスできるテーブルを指します。
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」ファセットを定義する必要があります。外部キーフィールドは、ターゲットテーブルの最終主キーフィールドで構成されているため、このファセット要件は、外部キーフィールド自体ではなく、これらの最終主キーフィールドのそれぞれに適用されます。さらに、VARCHARやNVARCHAR2など、文字タイプの最大長に関する基礎となるデータベースの制限が適用されます。
タイプtype="osd:password"のフィールドは無視されます。
ターミナルコンプレックスタイプがサポートされています。ただし、レコードレベルでグローバルにnullに設定することはできません。
より一般的には、マップモードのテーブルは、基盤となるRDBMSの制限の対象となります。たとえば、テーブルの最大列数が適用されます（Oracleの場合は1000、PostgreSQLの場合は1600）。履歴テーブルには、スキーマで宣言されているフィールドの2倍のフィールドが含まれていることに注意してください（1つの機能フィールドと、オペコード用に生成された1つのフィールド）。
データモデルの進化は、既存のデータモデルによっては、基盤となるRDBMSによって制約される場合もあります。