この章の内容は次のとおりです。
モデルは、一連のデータストアの記述です。それは、データ・サーバーに格納されている表データ構造のグループに対応しています。モデルは、トポロジに定義されている論理スキーマに基づいています。特定のコンテキストで、論理スキーマは物理スキーマにマップされます。物理スキーマのデータ・スキーマには、物理的なデータ構造(データストアとして表現される、表、ファイル、JMSメッセージ、XMLファイルの要素)が含まれています。
モデルとそれらのコンポーネントすべては、リレーショナル・パラダイム(表、属性、キーなど)に基づいています。Data Integratorのモデルには、データ構造の記述であるメタデータのみが含まれています。これらのモデルには、実際のデータのコピーは含まれていません。
注意:
頻繁に使用されるテクノロジには、リバース・メソッドとモデル作成メソッドが含まれています。詳細は、Oracle Data Integrator接続およびナレッジ・モジュール・ガイドを参照してください。
モデルは、モデル・フォルダに編成でき、モデルのデータストアはサブモデルに編成できます。モデル・フォルダとサブモデルの作成方法および編成方法については、フォルダを使用したモデルの編成を参照してください。
データストアはデータ構造を表現します。データストアは、表、フラット・ファイル、メッセージ・キューまたはOracle Data Integratorでアクセスできる他のデータ構造のいずれかです。
データストアでは、データが表構造で記述されており、データストアは複数の属性で構成されます。
データストアはリレーショナル・パラダイムに基づいているため、次の要素をデータストアに関連付けることもできます。
キー
キーは、リレーショナル・パラダイムで特定の役割がある属性セットです。主キーおよび代替キーは各レコードを一意に識別します。一意でない索引を使用すると最適化されたレコードにアクセスできます。
参照
参照は2つのデータストアの間の機能リンクで、リレーショナル・モデルの外部キーに対応しています。たとえば、INVOICEデータストアは顧客番号を介してCUSTOMERデータストアを参照します。
条件とフィルタ
条件とフィルタは、データストアに関連付けられているWHEREタイプのSQL式で、データストア内のデータを検証またはフィルタするために使用されます。
モデルには、キー、参照、条件などの制約が含まれていますが、属性に対するnull以外のフラグも含まれています。Oracle Data Integratorには、データ・モデルの品質を保証するためのデータ整合性フレームワークが用意されています。
このフレームワークを使用すると、次の操作を実行できます。
静的チェック: データ・モデルに含まれているデータの整合性を検証します。この操作は、データ・サーバーには制約が物理的に存在しないが、Data Integratorにのみ定義されている場合に、モデル内のデータの品質を評価するために実行します。
フロー・チェック : データ・フローを特定のデータストアに統合する前に、その整合性を検証します。データ・フローは、Oracle Data Integratorで定義されている、データ・フローのターゲットであるデータストアの制約と照合してチェックされます。
新規モデルは、データストアなしで作成されます。リバースエンジニアリングは、データ構造を保持するデータ・サーバーからメタデータを取得してOracle Data Integratorのモデルに移入するプロセスです。リバースエンジニアリングには2つのタイプがあります。
標準リバースエンジニアリング: 標準のJDBCドライバ機能を使用してメタデータを取得します。標準リバースエンジニアリングを使用する場合、一意キーはリバースエンジニアリングされません。
カスタマイズしたリバースエンジニアリング : 特定のテクノロジに固有のメソッドを使用し、テクノロジ固有のリバース・ナレッジ・モジュール(RKM)を使用して、メタデータを取得します。一般に、標準リバース・エンジニアリング・メソッドよりも多くの情報を取得できるため、テクノロジ固有のRKMが存在する場合は、このメソッドが推奨されます。利用できるRKMのリストについては、Oracle Data Integrator接続およびナレッジ・モジュール・ガイドを参照してください。
フラット・ファイル・データストアの場合は、リバースエンジニアリングに対する他のメソッドがあります。詳細は、ファイル・データストアのリバースエンジニアリングに記載されています。
Oracle Data Integratorでは、データストアのショートカットを含むモデルをリバースエンジニアリングできます。詳細は、ショートカットの使用を参照してください。
ジャーナル化とも呼ばれるチェンジ・データ・キャプチャ(CDC)を使用すると、データに加えられた変更を捕捉できます。CDCは、Oracle Data Integratorで変更のないデータの転送を回避するために使用します。この機能は、データ同期化やレプリケーションなどで使用できます。
ジャーナル化は、特定のタイプのテクノロジに基づいたモデル、サブモデルまたはデータストアに適用できます。
チェンジ・データ・キャプチャの設定の詳細は、ジャーナル化の使用を参照してください。
ODIモデルの主要なコンポーネントについてはすでに説明しましたが、ここではモデルの作成方法とリバースエンジニアリング方法の概要について説明します。
モデルは、物理スキーマに保持されているデータ構造に対応する一連のデータストアです。
ヒント:
新規のモデルと新規のトポロジ・オブジェクトを同時に作成するには、モデルおよびトポロジ・オブジェクトの作成で説明されている手順を使用します。
モデルを作成するには:
モデルは作成されましたが、データストアはまだ格納されていません。
モデルにデータストアを自動的に移入するには、そのモデルに対してリバースエンジニアリングを実行する必要があります。
標準リバースエンジニアリング
標準リバースエンジニアリングでは、データ・サーバーの接続に使用するJDBCドライバの機能を使用して、モデルのメタデータを取得します。
標準リバースエンジニアリングを実行するには:
モデルの「リバース・エンジニアリング」タブで、次の操作を実行します。
「標準」を選択します。
リバースエンジニアリングで使用するコンテキストを選択します。
リバースエンジニアリングするオブジェクトのタイプを選択します。リバースエンジニアリング・プロセスで考慮されるのは、選択したタイプのオブジェクトのみです。
「マスク」フィールドに、リバースエンジニアリングする表のマスクを入力します。マスクによって、リバースするオブジェクトが選択されます。このマスクでは、SQLのLIKE構文を使用します。パーセント(%
)記号は、ゼロ個以上の文字を意味し、アンダースコア(_
)記号は1つの文字を意味します。
オプションで、表の別名で削除する文字を指定できます。これらは、別名を導出するために削除する文字です。データストアがすでに存在している場合は、ここで指定した文字が表の別名から削除されないことに注意してください。データストアの更新は表の別名に適用されません。
「選択的リバース・エンジニアリング」タブで、「選択的リバース・エンジニアリング」、「新規データストア」、「既存のデータストア」および「リバース・エンジニアリングするオブジェクト」を選択します。
リバースエンジニアリング対象のデータストアのリストが表示されます。リバースエンジニアリングするデータストアは選択した状態のままにします。
「ファイル」メイン・メニューから「保存」を選択します。
モデルのツールバー・メニューで、「リバースエンジニアリング」をクリックします。
Oracle Data Integratorによって、選択したデータストアに対するリバースエンジニアリング・プロセスが起動されます。進行状況バーには、リバースエンジニアリング・プロセスの進行状況が表示されます。
リバースエンジニアリングされたデータストアが、「モデル」パネルの該当モデル・ノードの下に表示されます。
カスタマイズしたリバースエンジニアリング
カスタマイズしたリバースエンジニアリングでは、リバースエンジニアリング・ナレッジ・モジュール(RKM)を使用して、特定タイプのテクノロジのメタデータを取得し、対応するデータストア定義をデータ・モデルに作成します。
たとえば、OracleテクノロジのRKM Oracleでは、データベース・ディクショナリ表にアクセスして、モデルに作成する表、属性、キーなどの定義を取得します。
注意:
RKMはグローバルRKMとしてまたはプロジェクトにインポートされて使用可能になっている必要があります。KMインポートの詳細は、統合プロジェクトの作成,を参照してください。
RKMを使用してカスタマイズしたリバースエンジニアリングを実行するには:
リバースエンジニアリング・タスクは、オペレータ・ナビゲータで確認できます。リバースエンジニアリング・プロセスが正確に完了すると、リバースエンジニアリングされたデータストアが、「モデル」パネルの該当モデル・ノードの下に表示されます。
モデルにデータストアを作成するための推奨方法はリバースエンジニアリングですが、空のモデルにデータストアを手動で定義することもできます。これは、フラット・ファイル・データストアを作成する際の推奨方法です。
データストアを作成するには:
データストアが作成されました。これがファイル・データストアである場合は、データストアに属性を作成するために、「ファイル・データストアのリバースエンジニアリング」を参照してください。すべてのデータストアの属性を手動で編集することもできます。詳細は、「データストア属性の追加および削除」を参照してください。
Oracle Data Integratorには、フラット・ファイルをリバースエンジニアリングするための特定の方法があります。次に、フラット・ファイルをリバースするための方法を説明します。
固定ファイルは、固定属性の境界とそのパラメータを定義できるウィザードを使用してリバースエンジニアリングできます。
デリミタ付きファイルは、(ファイルを分析して属性を検出し、ファイル・ヘッダーから属性名を読み取る)組込みJDBCを使用して、リバースエンジニアリングできます。
属性をデータストアに追加するには:
データストアの「属性」タブで、ツールバー・メニューの「属性の追加」をクリックします。
空の行が表示されます。新しい属性に関する情報を入力します。少なくとも「名前」、「データ型」および「長さ」の各フィールドに値を入力する必要があります。
データストアに追加する属性ごとにステップ1とステップ2を繰り返します。
「ファイル」メイン・メニューから「保存」を選択します。
属性をデータストアから削除するには:
Oracle Data Integratorでは、キー、参照、条件、必須属性などのデータ・モデルに対する制約が管理されます。これらの制約に基づいてデータ・モデルの品質を保証するためのデータ整合性フレームワークが含まれています。
フィルタは制約ではありませんが、条件と同じように定義します。フィルタは、データストアに対してデータ品質ルールを実施する際には使用しませんが、ソースとして使用されているデータストアを自動的にフィルタ処理する際に使用します。
データストアのキーを作成するには:
2つのデータストア間の参照を作成するには:
データストアの条件を作成するには:
データストアに必須属性を定義するには:
データストアにフィルタを追加するには:
データストアのデータを表示するには:
デザイナ・ナビゲータで、モデルからデータストアを選択します。
右クリックして「データの表示」を選択します。
編集不可のグリッド内にデータが表示されます。
データストアのデータを編集するには:
データ・エディタの編集可能なグリッド内にデータが表示されます。「リフレッシュ」ボタンを使用すると、データストアのデータを戻す問合せを編集して再度実行できます。この方法を使用すると、データをフィルタ処理したり、データストアに対して任意の問合せを実行することができます。
データストアのデータを編集できるのは、使用する接続とデータ・サーバーのユーザー権限で許可され、かつデータストア構造によってデータストアの各行(PKなど)が識別可能である場合です。
注意:
表示されるデータは、現在の作業コンテキストで、モデルの論理スキーマに対応する物理スキーマに格納されているデータです。
Oracle Data Integratorでは、パーティション表のデータをマッピングのソースまたはターゲットとして使用して処理する場合、データベース定義のパーティションを使用できます。これらのパーティションは、表に対応するデータストアに、リバースエンジニアリング・プロセスを使用して、または手動で作成されます。たとえば、Oracleテクノロジでは、パーティションはRKM Oracleを使用してリバースエンジニアリングされます。
サポートされるパーティション化メソッドは、データストアのテクノロジによって異なります。たとえば、Oracleテクノロジでは、レンジ、ハッシュ、リストのパーティション化メソッドがサポートされています。
データストアで定義されたパーティションは、そのデータストアをマッピングのソースまたはターゲットとして使用するときに選択できます。詳細は、マッピングの作成および使用を参照してください。
共通フォーマット・デザイナを使用する場合は、「DDLの生成」操作の実行時にパーティションを作成することもできます。
データ品質管理は、情報システムのアプリケーションでデータ全体の一貫性を保証するために重要です。
アプリケーション・データは、情報システムによって課せられる制約および宣言的ルールに対して有効でない場合があります。たとえば、顧客が指定されていない注文や製品が指定されていない注文明細などが検出される可能性があります。さらに、そのような不正なデータが統合フローを介して伝播される場合があります。
Oracle Data Integratorには、これらの制約違反を検出してリサイクルまたはレポート目的で格納するための作業環境が用意されています。
主なタイプとして、静的制御とフロー制御があります。この2つのタイプの相違について説明します。
静的制御
静的制御は、アプリケーション・データの整合性を検証するために使用するルールが存在することを意味します。これらのルール(制約とも呼ばれます)の一部は、データ・サーバーに(主キー、参照制約などを使用して)すでに実装されている可能性があります。
Oracle Data Integratorでは、追加の制約を定義することでデータの検証を調整できます。追加の制約をサーバーに直接実装する必要はありません。この手順は、既存(静的)データのチェックを直接実行できるため、静的制御と呼ばれます。アクティブなデータベース制約(「制御」タブで「データベースで定義済」と「アクティブ」が選択された)は、すでにデータベースによって制御されているため、Oracle Data Integratorからの追加の制御は不要です。
フロー制御
変換プロセスおよび統合プロセスに対応する情報システムでは、通常、独自の宣言的ルールが実装されています。フロー制御機能は、データを対応する情報システムにロードする前に、それらの制約に基づいてアプリケーションの着信データを検証するために使用します。フロー制御の設定の詳細は、「マッピングの作成および使用」に記載されています。
Oracle Data Integratorでの制約の作成時に、その制約に違反する行数を取得できます。同期制御と呼ばれるこのアクションは、特定の制約エディタの「制御」タブで「チェック」ボタンをクリックして実行します。
同期制御の結果は永続的ではありません。このタイプの制御は、制約定義の有効性をすばやく評価するために使用します。
モデル、サブモデルまたはデータストアに対して静的チェックを実行するには:
チェック・タスクは、オペレータ・ナビゲータで確認できます。制御プロセスが正確に完了すると、チェック済のデータストアごとにエラーのあるレコードを確認できます。