このために私達は計画します：
- 標準Oracleモジュールに含まれるチェックのタイプと、それらをアクティブにするために必要な設定について話します。
- パフォーマンス機能、標準モジュールを拡張する可能性、開発中の機能の普遍性を確保するために使用される代替APIの使用に触れます。
- 特定の例を使用して、Oracle Data Integrator Toolsが提供する可能性と、トポロジを使用してDEV-> PROD設定を転送するオプションを検討してください。
- CKMモジュールによって検出されたエラーを処理するオペレーターの職場を評価します。
序論として、ODIのすべてのモジュールが誇らしげに知識モジュールと呼ばれていることは注目に値します。これは明らかに、次の事実を反映しています。
- 特定の動作はモジュールに事前に接続されています。
- モジュールの名前（チェック、ロード、統合など）は、モジュールによって解決されるタスクのクラスに対応します。
- 1つのクラス内で、特定のタイプの問題を解決するために特定のモジュールを選択または開発できます。
CKMモジュールは、いわゆるテンプレートタイプのモジュール、つまり （オプションのインストールによるモジュール自体の動作への影響に加えて）「ボディ」の変更またはこのクラスの独自モジュールのゼロからの作成が含まれます。
この記事では、ODI CKMで提供されるモジュールに実装されている標準チェックから話を始めます。 それらの設定方法と、それらを使用して実装できる機能を検討しましょう。
すぐにモジュールが2つのモード（STATIC_CONTROLおよびFLOW_CONTROL）で使用できることに注目する価値があります：ソース/エンドデータの制御、またはターゲットテーブルに配置する前に統合マッピングの結果として取得されたデータの正確性をそれぞれ確認します。
したがって、「標準」には、5種類の「自分で話す」チェックが含まれます。
- 主キー（PK）-主キーの一意性
- 代替キー（AK）-キーの一意性
- Join（FK）-関連レコードの可用性を制御します
- 状態チェック（CK）-コンプライアンス
- 必須（NN）-必須フィールド
検証データは、ODIのデータモデル記述のレベルで設定されますが、モジュールの動作モードに応じてさまざまな場所で有効化/無効化できます。
最初の4つのタイプのチェックは、特定のデータストアのConstarintsレベルで設定され（DS-エンティティの説明-テーブル、ファイルなど-ODIメタデータリポジトリ内）、指定された制限ごとに個別のレコードを使用します。
図では、2つのデータストア（DIM_COUNTRYとREF_CALENDAR）に対して定義された一連のチェックが表示されています。 DSの1つで作成する場合、FK条件で接続された他のDSで両方の外部キーチェックが表示されることに注意してください。
検証の最後のタイプである必須は、DSフィールドレベルで設定されます。
さまざまなタイプのチェックに設定されている一般的なパラメータとプライベートパラメータを見てみましょう。
1.考慮されるデータ制御（静的/フロー）を使用できるモードは、CKM動作モード-STATIC_CONTROL / FLOW_CONTROLにそれぞれ対応します。 下の図では赤です。
緑色のブロックのフラグ（PK / AK / CKチェックのみ）は、そのような可能性が暗示される場合、最終システムでのこの制限の物理的な存在とアクティビティの必要性をそれぞれ示します。 Type = Database参照パラメーターの意味とFKタイプを制限するActivate on Databaseフラグは同じ意味を持ちます。
または、CKを制限するデータベース条件の値。
実際、制限の物理的な存在と活動に関与するパラメーターは、最終システムの望ましい/既存の状態を反映することのみを目的としており、それらのインストール/削除は最終システムに直接影響しません。 これらのパラメーターは、最終システムのメタデータに基づいてデータモデルを構築するときに配置されます（リバースエンジニアリング）。 または、対応する制約の定義がターゲットシステムのオブジェクト生成スクリプトに追加されます。これは、データモデルの記述に基づいて自動的に作成され、明示的な作成要求があります。
2. PK / AKの制限条件に関与する属性は、キーに含まれるフィールドを指定します。
FKの場合-参照フィールド（左）および親テーブルの対応するキーフィールド（右）：
FK制約タイプがComplex User Referenceとして指定されている場合、テーブルリンク条件はExpressionフィールドで指定されます
CKの場合、チェックされる条件が設定されます（非常に複雑になる場合があります）。
ここで、FKとCKの両方の式で、ワイルドカードAPIからの関数の使用が許可されていることを述べる価値があります（次の記事でそれらについて）。 ただし、CK（条件タイプ= Oracle Data Integrator条件）の場合、そのような条件は組み込みのチェック（緑のdaw）に合格しますが、FKには合格しません。
3.カスタマイズされた設定。
A. PKおよびAKの場合。
主キーまたは代替キー制約タイプは、検証の適切なタイプを示します。 Not Unique Indexオプションは、生産性を向上させるために追加のインデックスを作成する必要があることを示すためにのみ使用されます。
B. FKの場合
制限を決定する際、データモデルと親テーブル（より正確にはDS）は、使用可能なものから選択されます-下の図では赤で示しています。
単純なバージョン（Type = User Reference / Database Reference）では、接続条件によって外部キー制約が設定されます。「advanced」バージョン（Type = Complex User Reference）では、上記で既に説明したように、より複雑な条件が許可されます（図では、オプションが緑色で強調表示されています）。
C. CKおよびNNの場合、利用可能なオプションは他のアイテムを解析するときにすでにカバーされていました
そのため、データモデルには制限が明記されています。次は何でしょうか。 これでSTATIC_CONTROLチェックに関与するはずです。 FLOW_CONTROLには、制限のACTIVATIONの追加の制御レベルがあります。これは、マッピングを作成するときに、モデルで使用可能な設定に従って設定されますが、再定義できます。 彼を知りましょう。
これを行うには、特定の統合マッピングを表示するときに選択される[論理]タブを検討します。
結果のDSを選択して、そのプロパティに移動する必要があります。 ここでは、示されている赤いブロック内の既存のチェックを有効化/無効化できます。
しかし、微妙な違いがいくつかあります。
NNタイプチェックは、データモデルで必須フラグとフローフラグが設定されているかどうかに関係なく、有効化/無効化できます。 つまり これらの設定はモデルから完全に独立しており、完全に再定義されます。 したがって、モデルレベルで行われた変更は既存のマッピングに影響せず、新しいマッピングを作成する場合にのみ考慮されます。
PK / AK / FK / CKのようなチェックは有効化/無効化できますが、モデルでフローフラグがクリアされている場合、マッピングレベルで制限を有効化しても役に立ちません-このチェックは、マッピングレベルで指定された値に関係なく、FLOW_CONTROLモードでは実行されません。 逆も同様です-検証はマッピングレベルで無効にできます。
ODI Studio 12c（バージョン12.1.3.0.0）の動作の機能があります。 モデルレベルでPK / AK / FK / CK制限のフローフラグを変更すると、この事実は既存のマッピングに自動的に表示されません（対応する制限の反対側のConstarintsウィンドウに単語が表示されない/表示されなくなります）。 これは、インターフェイスでフラグ値が再選択された場合にのみ発生します。 そのため、以前のニュアンスを考慮してモジュールの動作の誤解を避けるために、モデルの制限を無効にする場合、それに関連付けられているすべてのマッピングを手動で更新する必要があります。
そして、議論したトピックを完了するためにこの記事で最後に言う必要があるのは、チェックでCKMを使用する方法です。 STATIC_CONTROLモードの場合、データモデル設定でモジュールを指定する必要があります。
これにより、たとえば、特定のDSで適切なコンテキストメニュー項目を選択するか、DSを表示しているときに[定義]タブの[データストア静的制御]ボタンをクリックすることで、使用可能なDSのデータの「純度」を分析できます。
マッピングレベルでSTATIC_CONTROL / FLOW_CONTROLモードをアクティブにするには、マッピングに接続されたIKMモジュールのコードで対応するディレクティブCKM_STATIC / CKM_FLOWを指定する必要があります。
また、マッピングの[物理]タブで、CKMモジュール自体を指定し、IKM（緑色で強調表示）を接続するときに、FLOW_CONTROLオプションがアクティブになっていることを確認します。
この記事は、Jet Infosystems Applied Financial Systems DepartmentのアーキテクトであるAlexey Polevによって作成されました。