データウェアハウス向けのOracle Data Integratorベ …...データウェアハウス向けのOracle Data Integratorベスト・プラクティス 7 図1：従来のETLとE-LTアプローチの比較

Oracleホワイト・ペーパー

2010年8月

データウェアハウス向けの

Oracle Data Integratorベスト・プラクティス

データウェアハウス向けのOracle Data Integratorベスト・プラクティス

2

はじめに .............................................................................................................................. 4

目的 ................................................................................................................................ 4

対象読者 ........................................................................................................................ 4

追加情報 ........................................................................................................................ 4

Oracle Data Integratorの概要 ............................................................................................. 5

目的 ................................................................................................................................ 5

ビジネス・ルール主導型のアプローチ ......................................................................... 5

従来のETLとE-LTアプローチの比較 ............................................................................. 6

Oracle Data Integratorインタフェースの理解 ............................................................... 7

ビジネス課題の事例 ...................................................................................................... 8

手動コーディングを使用した実装 ............................................................................... 10

従来のETLツールを使用した実装 ............................................................................... 12

Oracle Data IntegratorのE-LTとビジネス・ルール主導型アプローチを使用した実装 14

E-LTとビジネス・ルール主導型アプローチの組合せがもたらす利点 ........................ 17

データウェアハウス・プロジェクトでのOracle Data Integratorの活用 .......................... 19

Oracle Data Integratorとデータウェアハウス・プロジェクト .................................... 19

チームの編成 ............................................................................................................... 19

ソース・アプリケーションのリバース・エンジニアリング、監査、プロファイリング ..................................................................................................................................... 21

データウェアハウスのスキーマの設計と実装 ............................................................ 23

ビジネス・ルールの指定と設計 .................................................................................. 24

データ品質フレームワークの構築 ............................................................................... 27

追加コンポーネントの開発 ......................................................................................... 28

開発のパッケージとリリース ...................................................................................... 29

開発のバージョニング ................................................................................................. 29

シナリオのスケジューリングと運用 ........................................................................... 29

データウェアハウスのデータ品質の監視 .................................................................... 30

ビジネス・ユーザーへのメタデータの公開 ................................................................ 30

次期リリースの計画 .................................................................................................... 31

Oracle Data Integratorを使用したオラクルのベスト・プラクティス .............................. 32

Oracle Data Integratorリポジトリのアーキテクチャ .................................................. 32

Oracleスキーマのリバース・エンジニアリング ......................................................... 32

Oracleのロード戦略..................................................................................................... 32

チェンジ・データ・キャプチャの使用 ....................................................................... 34


3

Oracleの統合戦略 ........................................................................................................ 35

データ品質戦略の定義 ................................................................................................. 36

Oracle環境でのエージェントの設定 ........................................................................... 37

アーキテクチャの事例 ...................................................................................................... 38

リポジトリのセットアップ ......................................................................................... 38

Oracle Data Integratorバージョン管理機能の使用 ...................................................... 41

本番への移行 ............................................................................................................... 44

エージェントの設定 .................................................................................................... 46

リポジトリのバックアップ ......................................................................................... 48

付録 ................................................................................................................................... 49

付録I Oracle Data Integratorを使用したTeradataのベスト・プラクティス ..................... 49

Oracle Data Integratorリポジトリのアーキテクチャ .................................................. 49

Teradataスキーマのリバース・エンジニアリング ...................................................... 49

Teradataのロード戦略 ................................................................................................. 50

Teradataの統合戦略 ..................................................................................................... 51

Teradata環境でのエージェントの設定 ........................................................................ 52

付録II：追加情報 ............................................................................................................... 53

このドキュメントで使用された頭字語 ....................................................................... 53


4

はじめに

目的

このドキュメントでは、データウェアハウス・ソリューションに対してOracle Data Integratorを実装

する際のベスト・プラクティスについて説明します。本書の目的は、エンタープライズ・データウェ

アハウス・プロジェクトやアクティブ・データウェアハウス・プロジェクトでのデータ統合を成功

に導く環境をセットアップすることにあります。

このドキュメントの内容はOracle Data Integrator 11gに適用されます。

対象読者

このドキュメントの対象読者は、エンタープライズ・データウェアハウスまたはアクティブ・デー

タウェアハウスのプロジェクトで、抽出、ロード、変換ツールとしてOracle Data Integratorの使用を

予定しているデータ統合プロフェッショナル・サービス担当者、システム・インテグレーター、お

よびITチームです。

追加情報

詳しい情報については、次のリソースを参照してください。

オラクルのWebサイト：http://www.oracle.com

Oracle Data Integrator 11gのオンライン・ドキュメント：

http://download.oracle.com/docs/cd/E14571_01/odi.htm

Javaリファレンス：http://www.oracle.com/technetwork/java/index.html

Jythonリファレンス：http://www.jython.org


5

Oracle Data Integratorの概要

目的

この章の目的は次のとおりです。

ビジネス・ルール主導型アーキテクチャの主要概念の説明

E-LTの主要概念の説明

Oracle Data Integratorインタフェースの理解

ビジネス課題の事例を通じた、次の各種開発アプローチについての理解と評価

○ 手動コーディング

○ 従来のETL

○ Oracle Data Integratorのビジネス・ルール主導型アプローチとE-LTの組合せ

ビジネス・ルール主導型のアプローチ

ビジネス・ルールの概要

ビジネス・ルールは、マッピング、フィルタ、結合、制約を規定するものです。多くの場合、デー

タを変換する目的でメタデータに適用され、通常はビジネス・ユーザーによって自然言語で記述さ

れます。典型的なデータ統合プロジェクト（データウェアハウス・プロジェクトなど）では、仕様

決定フェーズ中にこれらのルールが定義され、ビジネス・アナリストとプロジェクト・マネージャー

によってドキュメントに記述されます。

ビジネス・ルールでは通常、"どのように"実行するかではなく、"何を"実行するかが定義されます。

参照先のメタデータが明らかであり、メタデータ・リポジトリに定義されている場合、通常、ルー

ルはSQL式を使用して実装されます。

次の表に、ビジネス・ルールの例を示します。

ビジネス・ルール種類 SQL式

2010年5月に販売されたすべての商品数×

商品単価

マッピング SUM(

CASE WHEN SALES.YEARMONTH=201005 THEN

SALES.AMOUNT * PRODUCT.ITEM_PRICE

ELSE

0

END

)

ハードウェア・カテゴリに属し、'CPU'で始

まる製品

フィルタ Upper(PRODUCT.PRODUCT_NAME) like ‘CPU%’

And PRODUCT.CATEGORY = ‘HARDWARE’

顧客とその注文および明細結合 CUSTOMER.CUSTOMER_ID = ORDER.ORDER_ID

And ORDER.ORDER_ID = ORDER_LINE.ORDER_ID


6

ビジネス・ルール種類 SQL式

重複した顧客名の拒否一意キー制約 CONSTRAINT CUST_NAME_PK PRIMARY

KEY (CUSTOMER_NAME)

存在しない顧客へのリンクを持つ注文の

拒否

参照制約 CONSTRAINT CUSTOMER_FK

FOREIGN KEY (CUSTOMER_ID)

REFERENCES CUSTOMER(CUSTOMER_ID)

マッピング

マッピングはSQL式として実装されるビジネス・ルールであり、ソース列（フィールド）からター

ゲット列へマッピングするための変換ルールです。このルールはリレーショナル・データベース・

サーバーによって実行時に適用されます。実行サーバーは、ソース・サーバー（可能な場合）か中

間層サーバー、またはターゲット・サーバーのいずれかになります。

結合

結合処理では、表やファイルなどの複数のデータセットに含まれるレコードが関連付けられます。

結合は複数のソースを関連付けるために使用されます。結合はSQL式として実装され、2つ以上のデー

タセットに含まれる列（フィールド）を関連付けます。

結合は、使用するソース・データセットの物理的ロケーションとは無関係に定義できます。たとえ

ば、JMSキューをリレーショナル表に結合することができます。

結合を実行するテクノロジーによって、内部結合、右側外部結合、左側外部結合、完全外部結合と

して表現されます。

フィルタ

フィルタはソース・データセットの列に適用される式です。このフィルタに一致するレコードのみ

がデータ・フローによって処理されます。

制約

制約はデータセットのデータに適用されるルールを定義したオブジェクトです。制約によって、特

定のデータセットに含まれるデータの妥当性とモデル内データの整合性が確保されます。ターゲッ

トに対する制約は、ターゲット内で統合が実行される前にデータの妥当性をチェックするために使

用されます。

従来のETLとE-LTアプローチの比較

従来のETLツールを使用した処理では、初めに各種ソースからデータが抽出され、中間層の専用ETL

エンジン上でデータが変換され、ターゲットのデータウェアハウスまたは統合サーバー上に変換

データがロードされます。つまり、図1に示すとおり、"ETL"という用語は処理の名前と実行順序を

表しています。


7

図1：従来のETLとE-LTアプローチの比較

ETLアーキテクチャによって提起された問題に対応するため、新たなアーキテクチャが登場しました。

このアーキテクチャには、手動コーディング・アプローチと自動コード生成アプローチのもっとも

良い面が数多く取り込まれています。"E-LT"という名前で知られるこの新アプローチでは、データ

変換を実行する場所と方法が変更されており、既存の開発者スキルやRDBMSエンジン、およびサー

バー・ハードウェアが可能な限り最大限に活用されます。

要するに、E-LTではデータ変換ステップをターゲットRDBMSに移動することで、処理の順序が次の

とおりに変更されています。ソース表からデータを抽出し、宛先サーバーに表をロードした後で、

ネイティブのSQL処理を使用してターゲットのRDBMSエンジン上でデータを変換します。注目すべ

きは、図1に示すとおりE-LTアーキテクチャでは中間層のエンジンやサーバーが必要ない点です。

Oracle Data Integratorインタフェースの理解

インタフェースは、Oracle Data Integratorリポジトリに格納されたOracle Data Integratorオブジェクト

であり、マッピング、結合、フィルタ、制約として実装されているビジネス・ルールに基づいて、1

つ以上のソース・データ・ストアから取得したデータを変換し、1つのターゲット・データ・ストア

にロードします。

データ・ストアには次の種類があります。

リレーショナル・データベースに格納された表

ASCIIまたはEBCDICのファイル（デリミタ付きまたは固定長）

XMLファイルのノード

メッセージ指向に含まれるJMSトピックまたはキュー

LDAPディレクトリのノード

レコード配列の形式でデータを返すAPI

図2に、FACT_SALESターゲット表にデータをロードするOracle Data Integratorインタフェースのスク

リーンショットを示します。ソース・データはCORRECTIONSファイルとORDERS表およびLINES

表に対する異種問合せとして定義されています。


8

マッピング、結合、フィルタ、制約はこのウィンドウ内で定義されます。

図2：Oracle Data Integratorインタフェースの例

Oracle Data Integratorインタフェースは可能な限り、ターゲットのRDBMSサーバーに変換処理を任せ

るE-LT処理を生成します。

ビジネス課題の事例

図3は、Microsoft SQL ServerデータベースおよびファイルからターゲットのOracle表に対して、デー

タの抽出、変換、ロードを実行する際のビジネス課題の例を示したものです。

データは2つのMicrosoft SQL Server表（結合されたORDERSとLINES）から取得され、CORRECTIONS

ファイルのデータと組み合わせられます。ターゲットとなるOracleのSALES表では、ID列の一意性や

SALES_REP表への参照の有効性などの制約を満たしている必要があります。

データは図3に示したマッピングに従って、変換および集計されます。


9

図3：ビジネス課題の例

これらのビジネス・ルールは、通常、自然言語からSQL式へ簡単に変換できます。この例では、図に

示したルールが次のように変換されます。

種類ルール SQL式または制約

フィルタ完了マークの付いたORDERSのみ ORDERS.STATUS = ‘CLOSED’

結合 LINESの行には、ORDERSに含まれるORDER_IDと

一致するORDER_IDが存在

RDERS.ORDER_ID = LINES.ORDER_ID

マッピングターゲットの SALESは注文明細の AMOUNTを

SalesRepごとに合計し、修正を適用したものである

SUM(LINES.AMOUNT + CORRECTIONS.VALUE)

マッピング SalesRep=ORDERSのSalesRepID ORDERS.SALES_REP_ID

制約 IDはNULLであってはならないデータ・モデル内でIDを"not null"に設定する

制約 IDは一意でなければならない一連の列をIDとして、データ・モデルに主キーを追加する

制約 SalesRepIDはターゲットのSalesRep表に存在しな

ければならない

SALES.SALES_REP =

SALES_REP.SALES_REP_ID

という参照（外部キー）をデータ・モデルに追加


10

手動コーディングを使用した実装

手動コーディングを使用してデータ・フローなどを実装する場合、複数のステップで、複数の言語、

および複数のスクリプト・ツールまたはユーティリティを使用する可能性が高くなります。

図4に、抽出、変換、ロードのプロセスを実行するために必要なステップの違いを簡単に示します。

図4：プロセス処理の順序

このようなプロセスを実装する技術的なソリューションは、もちろん複数存在します。そのうちの1

つ（Oracleデータウェアハウスを変換エンジンとして使用しているため、おそらくはもっとも効率的

な方法）について、次の表で詳しく説明します。

ステップ説明コード例

1 データベース・ビューを使用して、ソースとなる

Microsoft SQL Server上でORDERSとLINESの結合と

フィルタを実行

BCPユーティリティを使用して、ビューの内容をフ

ラット・ファイルに抽出

SQL*Loaderユーティリティを使用して、BCPの一時

ファイルをOracle表TEMP_1にロード

Create view C$_SALES

As select ... from ORDERS, LINES

where ORDERS.STATUS = ‘CLOSED’

and ORDERS.ORDER_ID = LINES.ORDER_ID

bcp C$_SALES out c$_sales_extract.bcp –c -S...-U...-P...–

t¥b

sqlldr control=TEMP_1.ctl log=logfile.log userid=.../..

2 SQL*Loaderユーティリティを使用して、ASCIIファイ

ルCORRECTIONSをOracle表TEMP_2にロード

sqlldr control=TEMP_2.ctl log=logfile.log userid=.../...

3 SQLを使用して、2つの一時表TEMP_1とTEMP_2に対

して結合、変換、集計を実行し、その結果を3番目の表

（TEMP_SALES）にロード

insert into TEMP_SALES (...)

select

SUM(TEMP_1.AMOUNT+TEMP_2.VALUE),

TEMP1.SALES_REP_ID,

...

from

TEMP_1, TEMP_2

where TEMP_1.LINEID = TEMP_2.CORR_ID)

...


11

ステップ説明コード例

4 SQLを使用して一意制約をチェックし、Errors表に

エラーを挿入

SQLを使用して参照制約をチェックし、Errors表にエ

ラーを挿入

insert into Errors(...)

select ... from TEMP_SALES

where ID in (select ID

from TEMP_SALES

group by ID

having count(*) > 1)

insert into Errors(...)

select ... from TEMP_SALES

where SALES_REP not in

(select SALES_REP_ID from SALES_REP)

5 EMP_SALESへの問合せを使用したSQLロジックを通

じて、ターゲットのSALES表に挿入または更新を実行

update SALES set ...

from ...

where ID in

(select ID

from TEMP_SALES

where IND_UPDATE=’U’)

insert into SALES (...)

select ...

from TEMP_SALES

where IND_UPDATE=’I’

...

このアプローチの利点は次のとおりです。

高いパフォーマンス：

○ 純粋な集合指向SQLの使用により、行単位の処理を回避

○ Oracleデータベースを変換エンジンとして使用することで、RDBMSの能力を活用

○ 外部表などの配置済みユーティリティを使用

柔軟なコード：

○ 組込み変換関数などの最新のOracle機能を活用


12

ただし、エンタープライズ・データウェアハウス・プロジェクトが拡大し、関与する開発者が増え

るにしたがって、このアプローチにはいくつかの困難な課題が持ち上がります。持ち上がる課題は

次のとおりです。

低い生産性

○ さまざまな環境で複数の言語を使用して、ロード・プロセスごとに一連のスクリ

プトやプログラムを開発する必要がある

○ ビジネス・ルール（"データがどうなったか" - SUM（AMOUNT + VALUE））が技

術的なロジック（"どのようにしてデータを移動/ロードするか" - SQL*Loader、外

部表、挿入など）と混同される

○ 環境変数やオブジェクトの可変修飾名が定義されていない場合、本番移行が困難

になることが多い

データ品質管理の高い実装コスト

○ 事前定義された制約に基づくデータ・クレンジングまたはデータ品質管理が、実

装コストのせいで通常は実施されない

○ 一元化フレームワーク（エラー表のデフォルト構造やエラーの再利用など）がな

く、プロジェクトごとにデータ品質が独自に定義されている

困難な保守

○ プロジェクト・マネージャーがフレームワークをセットアップしている場合でも、

スクリプトごとに"焼き直し"が行われ、理解の難しい固有ルーチンが含まれる可能

性がある

○ 中央リポジトリがなく、複数のマシンやフォルダに開発環境が散在している

○ メタデータが管理されておらず、相互参照の仕組みがないため、影響分析が不可

能である

柔軟性のないプロジェクト

○ データ・モデルやビジネス・ルールの変更にかかるコストに束縛されて、ITチー

ムが変更を拒否するため、ビジネス・ユーザー間に不満が広がる

従来のETLツールを使用した実装

従来のETLツールでは、専用エンジン内ですべての変換が実行されます。このため通常は、データを

変換する前にステージングを行うための追加のハードウェアが必要になります。これらのツールで

はRDBMSの能力はあまり利用されていません。

図5に、標準的なETLアーキテクチャを示します。


13

図5：ETLを使用した実装

すべての変換ステップで、固有のコネクタかトランスフォーマが必要になります。

ETLツールには次のような利点があることが知られています。

一元化された開発と管理

○ 1つにまとめられたグラフィカル・ユーザー・インタフェース

○ 一元化リポジトリ

簡素化された保守

○ 影響分析（一部のツール）

また、このETLアプローチには次の短所があります。

不十分なパフォーマンス

○ エンジンでデータを処理する必要があるため、行単位で処理されることが多くな

ります。

○ ターゲット・データベースのデータが参照されると（表の参照など）、データベー

スからエンジンにデータが抽出され、さらにもう一度ターゲット・データベース

に送り返される必要があります。

○ ほとんどのマッピングや結合、および集計やフィルタで、強力なRDBMSエンジン

が活用されていません。

低い生産性

○ ロード・プロセスごとに一連のステップを開発し、ビジネス・ルール（"データが

どうなったか" - SUM（AMOUNT + VALUE））と技術的なロジック（"どのように

してデータをロードするか" - コネクタ1、コネクタ2など）を結びつける必要があ

ります。

○ 環境変数や問合せ内での可変修飾名が定義されていないと、多くの場合、本番移

行が困難になります。

○ 一部のETLアプローチでは、特定のタスクを実行したり、効果的なRDBMSの変

換関数を利用したりするために、依然として多大な手動コーディングを必要と

します。


14

高いコスト

○ ETLツールには追加のハードウェアが必要です。

○ ETLツールには固有のスキルが必要です。

Oracle Data IntegratorのE-LTとビジネス・ルール主導型アプローチを使用した実装

Oracle Data Integratorを使用したビジネス課題の実装は、非常に簡単で分かりやすい作業です。ビジ

ネス・ルールをインタフェースに変換するだけで、実装が完了します。すべてのビジネス・ルール

はインタフェース・ウィンドウのDiagramパネルからアクセスできます。

インタフェース内でのビジネス・ルールの指定

図6に、ビジネス課題がOracle Data Integratorインタフェースに変換される様子を簡単に示します。

ORDERS、LINES、CORRECTIONSのデータ・ストアをドラッグして、インタフェースの

"Source"パネルにドロップします。

ターゲットのSALESデータ・ストアを"Target Datastore"パネルにドロップします。

"Source"パネルの列をドラッグ・アンド・ドロップすると、結合とフィルタが定義されます。

ターゲット列を選択してドラッグ・アンド・ドロップするか、または高度な式エディタを使

用することで、マッピングが定義されます。

制約はインタフェースの"Control"タブ内で定義されます。制約によって、フロー・データの

チェック方法と拒否された場合のErrors表への格納方法が定義されます。

図6：Oracle Data Integratorを使用した実装


15

ビジネス・ルールからプロセスへの変換

インタフェース内に定義されたビジネス・ルールを分割して、ソース・データからターゲット表に

対する結合、フィルタ、マッピング、制約を実行するプロセスを作成する必要があります。図7に解

決すべき問題を示します。

図7：どのようにして、ビジネス・ルールからプロセスへ変換するか

Oracle Data Integratorはデフォルトでステージング領域としてRDBMSを使用し、ソース・データを一

時表にロードして、必要なマッピング、ステージング・フィルタ、結合、制約をすべて適用します。

ステージング領域はRDBMS内の独立した領域であり（ユーザー/データベース）、Oracle Data Integrator

はここに一時オブジェクトを作成して一部のルール（マッピング、結合、最終的なフィルタ、集計

など）を適用します。このような方法で処理を実行する場合、最初に抽出と一時表へのロードが実

行されてから、ターゲットRDBMS内で変換が実行されるため、Oracle Data IntegratorはE-LTアーキテ

クチャを利用していることになります。

特定のケースとして、ソース・ボリュームが小さい（50万レコード未満）場合、Oracle Data Integrator

のインメモリ・リレーショナル・データベースであるOracle Data Integratorメモリ・エンジン内のメ

モリに、このステージング領域を配置できます。この場合、Oracle Data Integratorは従来のETLツール

のような動きをします。

図8に、最終的にSALES表へロードするためにOracle Data Integratorによって自動的に生成されるプロ

セスを示します。図7に定義されているビジネス・ルールは、ナレッジ・モジュール（KM）によっ

てコードに変換されます。さらにこのコードが、複数のステップを生成します。これらのステップ

のうちの一部で、ソースからのデータ抽出とステージング領域へのロードが実行されます（ロード・

ナレッジ・モジュール - LKM）。その他のステップでは、ステージング領域にあるデータが変換さ

れ、ターゲット表に統合されます（統合ナレッジ・モジュール - IKM）。データ品質を維持するた

め、チェック・ナレッジ・モジュール（CKM）によってステージング・データにユーザー定義制約

が適用され、誤りのあるレコードはErrors表に分離されます。


16

図8：Oracle Data Integratorナレッジ・モジュールの動作

Oracle Data Integratorのナレッジ・モジュールには、インフラストラクチャ内の各種サーバーによっ

て実行される実際のコードが含まれています。ナレッジ・モジュールに含まれるコードの一部は汎

用コードです。このコードから呼び出されるOracle Data Integratorの代替APIが実行時にビジネス・

ルールに関連付けられ、最終的に実行されるコードが生成されます。図9に、この仕組みを示します。

設計時にインタフェース内でルールが定義され、ナレッジ・モジュールが選択されます。

実行時にコードが生成され、リポジトリ内のメタデータに基づいて、ナレッジ・モジュールに含ま

れるすべてのAPIコール（<%と%>で囲まれた部分）は、対応するオブジェクト名と式で置換されま

す。

たとえば、<%=odiRef.getTable(“TARG_NAME”)%>に対するコールは、コンテキスト情報やトポ

ロジ設定などに従って、適切な修飾子を持ったインタフェースのターゲット表の名前を返します。

一般に、SQL INSERT文はナレッジ・モジュール内で次のようにコーディングされます。

INSERT INTO <%=odiRef.getTable(“TARG_NAME”)%> ...

言うまでもなく、このコード・テンプレートはターゲット表によって異なるSQL文を生成します（ター

ゲットがSALES表である場合は"INSERT INTO MyDB1.SALES..."、ターゲットがPRODUCT表で

ある場合は"INSERT INTO DWH_DB.PRODUCT"など）。これはまた、異なる環境間でOracle Data

Integratorプロセスを移行する際（開発からQAへのプロセス移行など）にも便利です。コードを変更

しなくても、指定された環境に基づいてOracle Data Integratorが自動的に正しいスキーマ情報で置換

を行います。


17

図9：ナレッジ・モジュールによるネイティブ・コードの生成

いったん生成されたコードはOracle Data Integratorエージェントに送信されます。Oracle Data Integratorエー

ジェントはこのコードを適切なデータベース・エンジンおよびオペレーティング・システムにリダイレクト

するか、または必要になったときに実行します（メモリ・エンジン変換、javaまたはjythonコードなど）。

ほとんどの場合、エージェントは指揮者の役割を果たすだけで、実際にデータを処理することはあ

りません。

E-LTとビジネス・ルール主導型アプローチの組合せがもたらす利点

その他のアーキテクチャ（手動コーディングと従来のETL）と比較すると、Oracle Data Integratorでは

両方のアーキテクチャの長所が生かされています。

生産性と保守

○ ビジネス・ルール主導型アプローチでは、開発者が"どのように"実行するかを気に

することなく"何を"実行するかに集中できるため、生産性が向上します。開発者が

ビジネス・ルールに対するSQL式を定義すると、Oracle Data Integratorナレッジ・モ

ジュールによってルールの実現に必要な一連のSQL処理全体が生成されます。

○ 運用ロジック（"新規レコードをロードする前にすべてのターゲット表のバック

アップ・コピーを作成する"など）を変更する必要が生じたら、適切なナレッジ・

モジュールにこれを適用するだけで、すでに開発された数百ものインタフェース

への反映が自動的に実行されます。従来のETLアプローチでこのような変更を実施

するには、すべてのジョブを1つずつ開き、手動で新規ステップを追加する必要が

あったため、間違いや不整合の生じる可能性が高くなっていました。


18

○ RDBMSの最新機能を利用することで、柔軟性が確保され、習熟も容易になります。

○ ソースとターゲットに対するすべてのメタデータを含む一元化リポジトリと、1つ

に統一された包括的なグラフィカル・インタフェースを使用することで、いつで

もオブジェクト間の相互参照を確認できるため、保守作業は大幅に効率化されま

す。また開発者とビジネス・ユーザーは、1つのエントリ・ポイントから影響分析

とデータ系統（"何がどこで使用されているか"、"どのソースからどのターゲット

が生成されているか"など）を調べることができます。

○ Oracle Data Integratorリポジトリにはインフラストラクチャのトポロジが詳細に定

義されており、異なる実行コンテキスト（開発、テスト、QA、本番など）間での

オブジェクト移動も簡単に実行できます。この強力なバージョン管理リポジトリ

を使用すると、複数のチームが同じプロジェクトに対して異なるリリース・ステー

ジで作業を実施でき、成果物の整合性も保証されます。

○ データ品質を確保する一元化フレームワークを使用することで、開発者は技術的

なステップの定義ではなく、データ品質ルールの明確化により多くの時間を割く

ことができます。これにより、一貫性のある標準化されたデータウェアハウスを

構築できるようになります。

高パフォーマンス

○ E-LTアーキテクチャは既存のデータベース・エンジンが提供するあらゆる機能や

能力を活用します。Oracle Data Integratorが生成する純粋な集合指向SQLは各

RDBMS向けに最適化されており、パラレル処理などの高度な機能を活用できます。

○ Oracle Data Integratorナレッジ・モジュールからネイティブのデータベース・ユー

ティリティを起動できます。

○ ターゲット・データベースのデータが参照される際（表の参照など）、このデー

タをデータベースからエンジンへと抽出する必要はありません。データはそのま

まの状態で、データベース・エンジンによって処理されます。

低いコスト：

○ Oracle Data Integratorは専用サーバーを必要としません。ロードと変換はRDBMSに

よって実行されます。

つまり、ビジネス・ルール手動型のE-LTアーキテクチャを利用したOracle Data Integratorは、手動コー

ディングと従来型ETLのそれぞれの長所を生かした最善のソリューションであると言えます。


19

データウェアハウス・プロジェクトでのOracle Data Integratorの活用

Oracle Data Integratorとデータウェアハウス・プロジェクト

データウェアハウスの一番の目的は、正確なインジケータを集約して提供することで、ビジネス・

ユーザーの日常業務に関する意思決定を支援することにあります。一般的なプロジェクトは複数の

ステップとマイルストーンで構成されています。次にその一部を示します。

ビジネス・ニーズの定義（キー・インジケータ）

キー・インジケータに関係するソース・データの特定と、ソース情報からキー・インジケー

タへと変換するビジネス・ルールの明確化

ターゲット・ウェアハウスにキー・インジケータを保管するためのデータ構造のモデル化

ビジネス・ルールの実装によるインジケータの生成

データ品質ルールの設定による全般的なデータ精度の測定

キー・インジケータに関するレポートの開発

非定型の問合せツールや事前定義されたレポートを介した、ビジネス・ユーザーへのキー・

インジケータとメタデータの公開

ビジネス・ユーザーの満足度の評価とキー・インジケータの追加または変更

Oracle Data Integratorを使用すると、ソース・データの調査やメタデータの系統からロードやデータ

品質の監査まで、ほとんどの手順を網羅できます。Oracle Data Integratorはそのリポジトリを通じて

仕様決定や開発の作業を一元化するとともに、プロジェクトの成功を委ねられる優れたアーキテク

チャを提供します。

チームの編成

Oracle Data Integratorでは一元化リポジトリが使用されるため、さまざまなタイプのユーザーがこの

リポジトリにアクセスする必要があります。次のリストでは、Oracle Data Integratorをチーム・メン

バーがどのように使用するのかを説明します。

プロファイル説明使用されるOracle Data

Integratorモジュール

ビジネス・ユーザービジネス・ユーザーはレポートや非定型問合せを介して、最終的に計算された

キー・インジケータへアクセスします。場合によっては、インジケータの定義

やその計算方法、また更新された時期を理解しておく必要があります。また、

インジケータの精度に関するデータ品質の問題について把握しておく必要があ

ります。

Oracle Data Integrator

コンソール

ビジネス・アナリストビジネス・アナリストはキー・インジケータを定義します。ソース・アプリケー

ションについて理解し、ソース・データから意味のあるターゲット・インジケー

タへ変換するためのビジネス・ルールを規定します。また運用セマンティック

から統一されたデータウェアハウス・セマンティックへの変換データを保守す

る役割を果たします。

Designer Navigator

（アクセス制限付き）


コンソール


20

プロファイル説明使用されるOracle Data

Integratorモジュール

開発者開発者はビジネス・アナリストによって規定された仕様に従って、ビジネス・

ルールを実装する責任を負います。開発者は実行可能なシナリオを本番チーム

に提供することで、その作業をリリースします。開発者はインフラストラクチャ

に関する技術的スキルとソース・アプリケーションのビジネス知識の両方を備

えている必要があります。

Topology Navigator

（読取り専用アクセス）

Designer Navigator：

モデルへのアクセス制限

付き

プロジェクトへのフル・

アクセス

Operator Navigator


コンソール

メタデータ管理者メタデータ管理者はソース・アプリケーションとターゲット・アプリケーショ

ンのリバース・エンジニアリングを担当し、Oracle Data Integratorリポジトリに

含まれるメタデータの全般的な整合性を保証します。またソースとターゲット

の構造に関する詳しい知識を持ち、キー・インジケータのデータ・モデリング

に参加しています。ビジネス・アナリストと協力して、コメントや説明だけで

なく、整合性規則（制約など）も追加することで、メタデータの質を向上しま

す。メタデータ管理者はバージョン管理の責任を負います。

Topology Navigator

（フル・アクセス）

Designer Navigator


Operator Navigator



コンソール

データベース管理者データベース管理者はOracle Data Integratorをサポートするデータベース・イン

フラストラクチャの技術的な定義を担当します。またOracle Data Integratorから

データにアクセスするためのデータベース・プロファイルを作成します。ステー

ジング領域を格納するために独立したスキーマとデータベースを作成します。

トポロジ内に環境を定義することで、環境へのアクセスを可能にします。

Topology Navigator


Designer Navigator


Operator Navigator



コンソール

システム管理者システム管理者はプロジェクトの技術的なリソースとインフラストラクチャの

保守を担当し、次のような作業を実行します。

Scheduler Agentのインストールと監視リポジトリのバックアップとリストア

Oracle Data Integratorコンソールのインストールと監視

環境のセットアップ（開発、テスト、保守など）

Agent

Topology Navigator

（アクセス制限付き）

Oracle Data Integratorコン

ソール

セキュリティ管理者セキュリティ管理者はOracle Data Integratorリポジトリにセキュリティ・ポリ

シーを定義する役割を担っており、Oracle Data Integratorユーザーを作成し、モ

デルやプロジェクト、およびコンテキストに対する権限を付与します。

Security Navigator


Designer Navigator

（読取りアクセス）

Topology Navigator

（読取りアクセス）


コンソール

オペレーターオペレーターはリリースおよびテストされたシナリオを本番環境にインポート

する担当者であり、これらのシナリオの実行をスケジューリングします。また

実行ログを監視し、必要に応じて失敗したセッションを再開します。

Operator Navigator


コンソール

Oracle Enterprise Manager

のOracle Data Integrator用

プラグイン


21

Oracle Data Integratorマスター・リポジトリには、ユーザーに割り当てることができるデフォルト・

プロファイルが組み込まれています。次の表に、これらの組込みプロファイルの使用例を示します。

プロファイル Oracle Data Integratorの組込みプロファイル

ビジネス・ユーザー CONNECT、NG REPOSITORY EXPLORER

ビジネス・アナリスト CONNECT、NG REPOSITORY EXPLORER、NG DESIGNER

開発者 CONNECT、DESIGNER

メタデータ管理者 CONNECT、METDATA ADMIN、VERSION ADMIN

データベース管理者 CONNECT、DESIGNER、METADATA ADMIN、TOPOLOGY ADMIN

システム管理者 CONNECT、OPERATOR

セキュリティ管理者 CONNECT、SECURITY ADMIN

オペレーター CONNECT、OPERATOR

ソース・アプリケーションのリバース・エンジニアリング、監査、プロファイリング

プロジェクトの出発点としてふさわしいのは、ソース・アプリケーションのコンテンツと構造を理

解する作業です。ソース・アプリケーションに関する紙ベースのドキュメントを使用するよりも、

Oracle Data Integratorを使用してソース・アプリケーションに接続し、アプリケーションのメタデー

タを取得する方法を推奨します。この作業が完了したら、通常はOracle Data Integratorリポジトリに

データ品質のビジネス・ルールを定義すると良いでしょう。これによりソースのデータ整合性が

チェックされ、データ・モデルに対する理解を検証することもできます。次の質問に対する回答を

用意して、このフェーズを始める必要があります。

インジケータを計算する際に考慮にいれるべきソースは何種類あるか

インジケータの計算に必要なデータがソース・システム内に含まれているか

ターゲット・ウェアハウスの精度を確保するには、どのようなデータ品質の課題を解決する

必要があるか

インジケータから参照されるマスター・データ（ディメンション）はどのようなソース・シ

ステムで提供されるか

処理するデータ量はどのくらいになるか

その他

ときには、ソース・アプリケーションに直接アクセスできず、アプリケーションから抽出したASCII

ファイルまたはバイナリ・ファイルのみが提供される場合があります。このような場合は、データ

ウェアハウス・モデルを実装する前にソース・ファイルの処理から開始することを推奨します。ソー

ス・ファイルは、本番ソース・システムが提供する"実際のビジョン"を表しているためです。通常、

これらのファイルのメタデータをリポジトリに定義します。また初めにサンプル・ファイルをター

ゲットの一時表にロードして、その構造とコンテンツを確認します。


22

これらの作業はすべて、次のとおりにOracle Data Integratorを使用して実装できます。

Topology Navigatorを使用して、ソース・アプリケーションまたはファイルに接続する

Topology Navigatorで論理アーキテクチャを定義する

Designer Navigatorで論理スキーマごとに1つのモデルを作成する

可能な場合はモデルのリバース・エンジニアリングを実行する。または、データ・ストアを

手動で記述する

○ 標準のJDBCリバース・エンジニアリングを使用して、データベースのメタデータ

を取得する

○ 標準のJDBCリバース・エンジニアリングを使用できない（または正しくない）場

合、カスタマイズされたリバース・エンジニアリング手法（リバース・ナレッジ・

モジュール）を使用する

○ 可能な場合、ASCIIファイルまたはバイナリ・ファイルに対して、COBOLコピー

ブックによるインポートを使用する

○ デリミタ付きのASCIIファイルに対して、デリミタ付きファイルのリバース・エン

ジニアリングを実行する

次の情報が含まれていない場合、これらを追加してメタデータを充実させる

○ データ・ストアと列の説明およびタイトル

○ 一意キーの情報（主キー、代替キー）

○ データ・ストア間での参照整合性の前提（外部キー）

○ チェック制約（列の値の範囲チェックなど）

ソース・データがファイルに格納されている場合、データ品質レベルの評価を効果的に実行

するため、簡単なインタフェースを開発してこれらのファイルをターゲット・データベース

の一時領域にロードする

ソース・データ内の重要エンティティを探し、次の機能を使用してコンテンツをプロファイ

リングする

○ データ・ストア上のデータを表示する

○ データ・ストア内の列に対する値の分散を確認する

○ レコード数を数える

○ Designer Navigatorで、非定型のSQL問合せを実行する

データ品質制御を実行することで、モデル内に定義した制約を検証する

○ データ・ストアとモデルに対して、"静的"なデータ品質制御を実行する（スケジュー

ル実行またはインタラクティブな実行）

○ エラー表にアクセスし、内容を理解する

○ 将来的なデータの不一致を処理する代替手段を提示する

○ ターゲット・ウェアハウスに対して、"許容できる"データ品質レベルを定義する

もちろん、これらのアクション項目はビジネス・アナリストとともに実行する必要があります。通

常はこのフェーズと並行して、ターゲット・データウェアハウスのデータ・モデル設計を行います。


23

データ品質の監査エラーやデータ・プロファイリングは現状への理解を深めるために役立ち、結果

的に優れたターゲット・ウェアハウスのモデリングにつながります。

データウェアハウスのスキーマの設計と実装

この項だけで1冊の本が書けますが、ここでの目的はデータウェアハウス・モデリングに対するガイ

ドラインではなく、Oracle Data Integrator開発の結果を左右する全般的なヒントとアドバイスを提供

することにあります。

加工する前の業務データは常にオペレーショナル・データ・ストア（ODS）に保存しておくことを

推奨します。ODSのデータ・モデルは通常、OLTPソース・アプリケーションのデータ・モデルと非

常に良く似ています。ODSではあらゆるソース・データが受け入れられるべきであり、データ品質

ルールはほとんど実装する必要はありません。これによって、業務システムに含まれるすべての当

日データを表すデータ・ストアを持つことができます。

データウェアハウスのスキーマを設計する場合、次のような一般的なヒントが役に立ちます。

可能な場合、データベースのデータ・ディクショナリ内に列の説明を付加します（"COMMENT

ON TABLE"文や"COMMENT ON COLUMN"文などを使用）。こうすることで、Oracle Data

Integratorはこれらのコメントを取得し、メタデータ・リポジトリに格納できます。

Oracle Data Integratorが必要な一時表やデータ品質のエラー表を作成できるように、ステージ

ング領域向けのストレージ領域を設計します。

ターゲット表の主キーには、ソース・システムの主キーではなく、できるだけカウンタやID

列を使用します。これによりデータ・モデルが柔軟になり、将来的な拡張も簡単になります。

Oracle Data Integratorモデル内に参照整合性（RI）とリバース・エンジニアリングの外部キー

を設計します。パフォーマンスの問題が発生する可能性があるため、これらの外部キーはター

ゲット・データベースに実装しないでください。Oracle Data Integratorの自動的なデータ品質

チェックを通じて、これらのRIルールに従ったデータの整合性が保証されます。

標準化したオブジェクトのネーミング規則を使用します。たとえば、サブジェクト領域を表

す3文字の接頭辞を表名に付加します。一時オブジェクトの作成時にOracle Data Integratorが表

名に接頭辞を付ける場合があるため（たとえば、E$_CustomerはCustomer表のエラー表になり

ます）、非常に長い名前は回避します。

第3正規形（3NF）モデリングとディメンション・モデリング（"スノー・フレーク"または"

スター・スキーマ"）のいずれを使用するかによってOracle Data Integratorに影響が及ぶことは

ありませんが、将来的なビジネス・ルール開発とビジネス・ユーザー・レポートの設計方法

に影響が及びます。

ODSとDWの設計が完了したら、Designerで適切なモデルを作成し、リバース・エンジニアリングを

実行する必要があります。

Oracle Data Integratorでは、Common Format Designerと呼ばれるモデリング機能が提供されています。

この機能を利用すると、表の列と制約をドラッグ・アンド・ドロップするだけで、ソース・システ

ムの既存構造からODSとDWの構造を設計できます。


24

生成されたデータ記述言語（DDL）には、ターゲット・データベースに固有の機能が自動的に含ま

れています。また元のソース列が追跡され、ターゲット・ロード用のインタフェースが自動的に生

成されるため、大幅に時間を節約できます。Common Format Designerを使用する際のベスト・プラク

ティスは、このドキュメントの対象外です。

ビジネス・ルールの指定と設計

このステップは通常、ターゲット・スキーマの設計とほとんど同じ時期に開始します。ビジネス・

ニーズを理解することが、プロジェクト全体を成功に導くための一番の要因になることは明らかで

す。これはウェアハウスに対して選択されたキー・インジケータだけでなく、ソース・データから

ターゲット・データへの変換に使用されるルールにも影響を与えます。ビジネス・ルールの仕様が

正確であればあるほどOracle Data Integratorでのルール設計は簡単になります。成功を収めたいくつ

かのプロジェクトでは、Oracle Data Integrator Designerを使用してビジネス・ルールを指定することで、

Wordドキュメントと最終的に開発されたルール間での不一致が回避されています。

次の表に、ビジネス・ルールを設計する前にODSまたはDWの各ターゲット表に指定する必要のある

項目をまとめます。

ターゲット・データ・ストア：できるだけ修飾接頭辞（データベース名やスキーマ名など）を付けて、ター

ゲット・データ・ストアの名前を指定します。

変換の説明：変換の目的を短く説明します。

統合戦略：ターゲットに対するデータの書込み方法を定義します。例：

ソースから取得した新規データでコンテンツを置換します。

受信データをターゲットに追加します。

更新キーに従って既存レコードを更新し、新規レコードは挿入します（ここ

にキーを指定）。

緩やかに変化するディメンション戦略を使用します。代理キー、緩やかに変

化する属性、更新可能な属性、開始日と終了日の列などを指定します。

独自戦略を使用します（Basel IIの遵守やSOXの履歴監査証跡など）。

ここで指定したすべての戦略はOracle Data Integratorの統合ナレッジ・モ

ジュールに対応します。

更新頻度：このデータ・ストアをロードする頻度を指定します（毎晩、毎月、2時間ごと

など）。

依存性：ロード・プロセスにおけるすべての依存性を記述します（事前にロードする

必要のあるデータ・ストア、事前に実行する必要のある特定ジョブなど）。

ソース・データ・ストア：ターゲット表のロードに関係するソース・データ・ストアのリストを提供し

ます。このリストにはすべての参照表も含まれます。各ソース・データ・ス

トアに対して次の情報を記述します。

Oracle Data Integratorソース・モデル Designerに表示されるソース・モデル名を指定します。

データ・ストア名データ・ストアの名前を指定します。


25

目的/説明メインのソース・セットであるか、参照ソースであるかを指定します。チェ

ンジ・データ・キャプチャが使用されている場合はその旨を記述します。

フィールドのマッピングと変換：ターゲット・フィールド（列）ごとに、ソース・フィールドに対して適用す

べき変換を指定します。これらの変換はできる限り式や計算式で記述します。

ターゲット列ターゲット列の名前を指定します。

マッピングの説明マッピングの目的を記述します。

マッピング式ソース列名を使用した式を記述します。擬似コードを使用するようにします。

リンクまたは結合の条件対になっているソース・データ・ストアに対して、レコードを照合する条件

を指定します。これは多くの場合、SQL結合と呼ばれます。

データ・ストア1 1番目のデータ・ストア名

データ・ストア2 2番目のデータ・ストア名

リンク式 2つのデータ・ストアを関連付けるために使用される式を擬似コードで指定し

ます。

説明このリンクの説明として、左側、右側、完全のいずれの外部結合であるかを

指定します。

フィルタ：ソース・データに適用されるフィルタのリストを記述します。フィルタは自

然言語で記述し、可能な場合は擬似コードを使用します。

フィルタの説明フィルタに対する説明を記述します。

フィルタの説明フィルタを実装するために使用される式を擬似コードで指定します。

データ品質要件：必要な場合のエラーの再利用を含む、すべてのデータ品質要件のリストを記

述します。この要件は可能な限り制約として記述します。

制約名検証に使用する制約の名前または短い説明を記述します。

説明データ品質チェックの目的を指定します。

制約式データ制御に必要な式を擬似コードで指定します。

このようなフォームの使用法を説明するため、"Oracle Data Integratorの概要"の章で定義されたビジネ

ス課題の事例を次の表に示します。

ターゲット・データ・ストア： Oracle Warehouse.SALES

変換の説明： Microsoft SQL Serverの本番ソース・システムから取得した注文と注文明細を集計する

統合戦略：当日の新規レコードを追加する

更新頻度：毎晩

依存性：参照整合性を維持するため、この表の前に次の表をロードする必要がある

PRODUCT

SALES_REP


26

ソース・データ・ストア：

Oracle Data Integratorソース・モデルデータ・ストア目的/説明

Microsoft SQL Serverソース ORDERS 本番システムの注文データ

Microsoft SQL Serverソース

ユーザー・データ・ファイル

LINES

CORRECTIONS

注文明細データ。おもな集計ソース

特定の注文明細に対して手動で修正が行わ

れた場合に、販売額に追加すべき値を含む

ファイル

フィールドのマッピングと変換：

ターゲット列マッピングの説明マッピング式

ID Order Id ORDERS.ORDER_ID

PRODUCT_PK 注文明細に表示される製品ID LINES.PRODUCT_ID

SALES_REP 注文に表示される製品営業担当者ID ORDERS.SALES_REP_ID

SALE 販売された金額。この金額に対する修正が

"CORRECTIONS"ファイルに含まれる場

合、その値を追加する。金額を加算して合

計金額を出す必要がある。

SUM ( LINES.AMOUNT +

(CORRECTIONS.VALUE when it exists) )

QUANTITY 販売された製品の総数 SUM ( LINES.QUANTITY )

リンクまたは結合の条件

データ・ストア1 データ・ストア2 リンク式説明

ORDERS LINES 注文IDを使用して注文と注文明細

を関連付ける。すべての注文明細

は既存の注文に関連付けられる必

要がある。

ORDERS.ORDER_ID =

LINES.ORDER_ID

LINES CORRECTIONS 明細品目IDに対する修正値が存在

する場合（左側結合）、修正ファ

イルから修正値を検索する。

LINES.LINE_ITEM_ID =

CORRECTIONS.CORR_ID

フィルタ：

フィルタの説明フィルタ式

当日の注文 ORDER.ORDER_DATE between yesterday and now

検証された注文 ORDER.STATUS = Closed

データ品質要件：

制約説明制約式

SALES_REPへの参照すべてのSALES_REP IDが必ず参照表SALES_REPに存在する SALES_REP references SALES_REP(ID)

PRODUCTへの参照すべてのPRODUCT_PKが必ず参照表PRODUCTに存在する PRODUCT_PK references PRODUCT(ID)

IDがNULLでない ID列は必須。 Check ID not null

数量が1以上

販売の一意性

販売数は常に正数でなければならない

1人の営業担当者が同じ注文で同一製品を2回販売することは

できない

QUANTITY > 0

(PRODUCT_PK, SALES_REP) is unique


27

次のステップでは、Designer Navigatorを使用してこれらのビジネス・ルールを設計します。仕様から

設計への変換は分かりやすい作業です。ターゲット表のロードに対する1つの仕様が、1つのインタ

フェースに変換されます。仕様がDesigner Navigatorで直接作成されている場合、このプロセスはさら

に迅速に実行できます。

一般的なインタフェースの実装ステップは、次のとおりです

ターゲット・データ・ストアをドラッグ・アンド・ドロップします。

ソース・データ・ストアをドラッグ・アンド・ドロップします。

すべてのターゲット・フィールドに対して、擬似変換コードをSQL式に変換します。可能な

場合は式を実行する場所（ソース、ステージング領域、ターゲット）を決定します。

すべての結合に対して、インタフェースのソース・パネル内で結合を定義します。仕様に応

じて、内部結合、左側結合、右側結合、自然結合、完全外部結合のいずれかを定義します。

可能な場合は、ネットワーク・トラフィックを最小化するため、結合をソース上で実行する

ようにします。

すべてのフィルタに対して、擬似コードをSQL式に変換します。ソース・データベースでSQL

フィルタを実行できる場合、ネットワーク・トラフィックを最小化するために"ソース上で実

行"するよう設定します。

インタフェースのフロー・ダイアグラムで、仕様に合ったロード戦略（LKM）を定義し、統

合戦略（IKM）を指定します。適切なナレッジ・モジュール・オプションを選択し、必要に

応じてデータ品質制御をアクティブ化します。

インタフェースの制御タブで、制御するための制約を選択します。ターゲット・データ・スト

アで制約が定義されていない場合、Designer NavigatorのModelsビューでこれらを定義します。

すべてのインタフェースを設計し終わったら、シミュレーション・モードで生成コードを確認し、

コードを実行してテストを行います。Operator Navigatorを使用すると、インタフェースの実行を簡単

に追跡し、処理されたレコード数やその他多数の便利なインジケータ（生成コード、経過時間、挿

入、更新、削除された件数など）を取得できます。インタフェースが完了したら、Designerから結果

のデータとエラーを直接選択して、ビジネス・ルールの正確さを検証できます。

Oracle Data Integratorコンテキストのおかげで、インタフェースの実行は"開発"環境で行われるため、

本番データに影響は及びません。

データ品質フレームワークの構築

ビジネス・ルールに基づくアプローチを採用したOracle Data Integratorは、間違いなく、データの不

整合追跡を目的としたデータ品質フレームワークの構築に最適なツールです。チェック・ナレッジ・

モジュールを使用すると、制御のビジネス・ルールを定義するだけで不整合データが自動的にエラー

表に分離されます。しかしながら、データ品質における問題はエラー・データの分離だけではあり

ません。重複キーや必須フィールド、また欠落参照やより複雑な制約がOracle Data Integratorによっ

て自動的に検出されたとしても、データの不一致を修正し、適切な意思決定を行うプロセスにビジ

ネス・ユーザーを巻き込む必要があります。データ品質戦略を決定する前に、次の質問に対する回

答を用意する必要があります。


28

どのようなデータ品質レベルがデータウェアハウスに必要とされているか

ソース・データのビジネス・オーナーは誰か

エラー判定されたレコードをどのように処理するか

エラーの再利用戦略を定義する必要があるか

データのビジネス・オーナーを巻き込んで、エラー判定されたレコードについて報告する必

要があるか

ビジネス・ユーザーはどのような方法で誤ったソース・データを修正するか

エラー表に含まれる誤ったレコードをビジネス・ユーザーが修正するためのGUIが提供され

ているか

データ品質の問題と推奨されるベスト・プラクティスについて、詳しくはドキュメント『Oracle Data

Integratorを使用した包括的なデータ品質』を参照してください。

追加コンポーネントの開発

データウェアハウスへの標準的なロード作業のすべてが、Oracle Data Integratorインタフェースを使

用して実行できる訳ではありません。通常、次のようなタスクを実行する追加のコンポーネントや

ジョブが開発されます。

電子メールの受信と送信

ファイル・システム内でのファイルのコピー、移動、連結、名前の変更

ファイルの圧縮と解凍

Webサービスの実行

特定のオペレーティング・システム向けシェル・スクリプトの作成と実行

Javaプログラムの作成と実行

その他

これらのコンポーネントはDesigner Navigatorを使用して、パッケージに含まれるプロシージャや変数、

ユーザー関数、またはステップとして開発し、テストすることができます。Oracle Data Integratorのプ

ロシージャは、これらのコンポーネント開発に幅広い可能性を提供します。次にその例を示します。

任意のデータベース向けの非定型SQL文

オペレーティング・システム・コール

Oracle Data Integratorに組み込まれたツールとAPI（メール送信、メール受信、ファイル待機など）

Jakarta Bean Scripting Frameworkでサポートされているスクリプト言語で記述されたコード

（Java、Java Script、Python、Perl、NetRexx、Groovyなどを含む）

言うまでもなく、Oracle Data Integratorインタフェースとナレッジ・モジュールによる強力なメカニズムを

使用することなく、シェル・スクリプトやSQLスクリプトの手動コーディングを使用して、プロシージャ

として変換プロセスの開発を開始するリスクがあります。このリスクを回避するには、技術的なプロセ

スではなくできる限りビジネス・ルールとして変換処理を指定するようにします。Oracle Data Integrator

のプロシージャは常に、プロセス全体で実行する必要のある技術的なステップとして見なすべきであり、

データに適用する詳細なビジネス・ロジックを含むべきではありません。標準的なデータウェアハウス・

プロジェクトでは、プロシージャの形で開発されるのは全体の10%未満にすぎません。


29

開発のパッケージとリリース

インタフェース、プロシージャ、変数の開発およびテストが完了したら、これらをパッケージ内の

ステップとして並べる必要があります。すべてのステップで、エラー発生時の対応を考えておく必

要があります。デフォルトでは、Oracle Data Integratorエージェントは処理に失敗したステップでそ

のパッケージの実行を停止し、オープン・トランザクションがあれば、接続されたすべてのデータ

ベースに対してこれをロールバックします。エラーはOracle Data Integratorログに記載されるとは言

え、ベスト・プラクティスとして、何らかのステップが失敗したときに起動される"on-error"プロシー

ジャを常に記述しておくことを推奨します。このプロシージャでは、たとえば電子メールをオペレー

ターに送信してパッケージ処理の失敗について警告し、セッションIDを通知することができます。

次のステップ属性には特に注意する必要があります。

処理失敗時の次のステップ

処理失敗時の試行回数

試行間の時間間隔

パッケージ内に繰返しの多いループ（50回を超える反復）を実装しないようにしてください。ほと

んどの場合、インタフェースのソースとして表を追加するだけでループの使用を回避できます。

パッケージのテストに成功したら、これをシナリオとしてリリースします。シナリオは、インタ

フェースやプロシージャ、またはパッケージなどのソース・オブジェクトをコンパイルしたもので

あると考えてください。このシナリオはテスト環境にインポートされ、本番向けに検証されます。

開発のバージョニング

本番へ移行する前に、シナリオのリリースに関係するすべてのオブジェクトの安定したバージョン

を記録しておく必要があります。オブジェクトのバージョンを作成すると、問題が発生した場合に、

以前にリリースした項目を復元して追加の保守を実行できます。

Oracle Data Integrator 10g以降では、オブジェクトのバージョンはマスター・リポジトリに格納され、オブ

ジェクト間の依存性はソリューションと呼ばれるオブジェクト内に保持されています。リリースに関連

するすべてのオブジェクトの一貫性を保ってバージョニングするため、ソリューション・オブジェクト

を作成し、このソリューションにプロジェクトを追加することを推奨します。Designerによってオブジェ

クト間のすべての依存性が計算され、使用されるプロジェクト、モデル、シナリオ、グローバル・オブ

ジェクトの新規バージョンが自動的に作成されます。また、Designer NavigatorのRestoreメニューを選択す

るだけで、以前のバージョンからこれらのオブジェクトを必要に応じて復元できます。

バージョン管理のベスト・プラクティスについて、詳しくは"Oracle Data Integratorバージョン管理機

能の使用"の項を参照してください。

シナリオのスケジューリングと運用

シナリオのスケジューリングと運用は通常、テスト環境と本番環境で別々の作業リポジトリを使用し

て実行されます。Operator Navigatorは、これらのタスクを実行するためのグラフィカル・インタフェー

スを提供します。すべてのシナリオはオペレーティング・システムのコマンドから起動できるため、

Oracle Data Integratorエージェントや外部スケジューラを使用してスケジューリングできます。

シナリオが本番で実行されると、エージェントによって実行ログがOracle Data Integrator作業リポジ

トリ内に生成されます。これらのログはOperator Navigatorを介して、またはOracle Data Integratorコン

ソールかOracle Enterprise ManagerのOracle Data Integrator向けプラグインを使用したWebブラウザを

介して監視できます。


30

運用チームは、Operator NavigatorやOracle Data Integratorコンソール、またはOracle Enterprise Manager

の使用法を学ぶ必要があります。運用チームはログを監視し、失敗したジョブを再開し、非定型タ

スクを送信して実行する必要があります。

データウェアハウスのデータ品質の監視

ビジネス・ユーザーは、データウェアハウスが提供するキー・インジケータの正確さを信頼して意

思決定を行います。もしこれらのインジケータが誤っている場合、その決定は無意味なものになり

ます。

選択したデータ品質戦略によっては、ビジネス・ユーザーがデータの不一致を監視する作業に積極

的に関与する場合があります。ビジネス・ユーザーは、インジケータの計算と誤ったデータの修正

作業をより洗練するため、ITチームを支援します。通常、これによってビジネス・ルールが修正さ

れます。ルールの更新は開発環境で実施され、プロジェクトで定義された通常のリリース・サイク

ルに従います。

標準的なプロジェクトでは、Oracle Data Integratorのエラー表から生成されたレポートを介してデー

タ品質エラーがビジネス・ユーザーに報告されます。これらのレポートは、内部で使用されている

ワークフロー・アプリケーションや電子メール・システムを通じて、データ・オーナーに送信され

ます。

ビジネス・ユーザーへのメタデータの公開

ビジネス・ユーザーは通常、メタデータに基づいた次のようなデータ品質インジケータにアクセス

する必要があります。

最後に表が更新されたのはいつか

何件のレコードが表に対して追加、削除、または更新されたか

どのようなルールを使用して、特定のインジケータが計算されているか

データはどこから取得されるか、またどのように変換されるか

データはどこに格納されるか、またどのように変換されるか

その他

ビジネス・ユーザーがOracle Data Integratorコンソールへアクセスできるようにすると、これらすべ

ての質問に対する回答が得られます。アクセス権を付与するには、Security Navigatorでユーザーに

ユーザーIDを割り当てます。Webベースのインタフェースを使用すると、すべてのデータ・モデル

とモデル間の相互作用を確認できます。確認できる内容には次が含まれます。


31

フロー・マップ

データ系統：データがたどった経路とアプリケーション間での変換を理解するために役立ち

ます

処理されたレコード数（挿入、更新、削除、エラーの数）に関する正確な統計情報を含む実

行ログ

次期リリースの計画

企業のビジネス・ニーズが変わるにつれて、データウェアハウスは発展していきます。その結果、

データ・モデルが頻繁に更新されます。このような絶え間ない変化は、新規コンポーネントの開発

や既存コンポーネントの保守に影響を与えます。しかしながら、常にサイクルを主導すべきなのは

ビジネス要件であると理解することが重要です。これに対してどのような計画を立てるかについて、

次に一般的なステップを示して簡単に説明します。

1. ビジネス・ルールの仕様を定義するか、または修正します。

2. 現在の作業リポジトリで修正を始める前に、以前のリリースのオブジェクトが正しくバー

ジョニングされており、空の新規作業リポジトリに安全にリストアできることを確認します。

3. Topology Navigatorで新しいソースまたはターゲットを定義します。

4. 新規モデルと既存モデルをリバース・エンジニアリングします。Oracle Data Integratorの相互

参照を使用して、ソース・フィールドやターゲットの変更が構造に与える影響を評価します。

表から削除されたフィールドがなおも一部の変換で使用されている場合があるため、特別な

注意を払ってください。

5. 新規インタフェースを開発し、既存インタフェースを更新します。追加コンポーネントを作

成または更新します。すべての項目を開発環境で個別にテストします。

6. 既存のパッケージを更新するか、または新規パッケージを作成します。基盤となるスキーマ

が変更されている可能性もあるため、前回のリリースから変更していないものを含め、すべ

てのパッケージをテストします。

7. 次のリリース向けに新規シナリオを再生成します。

8. シナリオをそれぞれのテスト環境に対してリリースします。テスト・プロセスから報告され

たバグがあれば、これを修正します。テスト・プロセスにビジネス・ユーザーを参加させま

す。

9. 新規ソリューションを作成し、すべてのプロジェクトとモデルをバージョニングします。ど

のオブジェクトをバージョニングするべきかを見つけるには、各オブジェクトに表示される

変更インジケータを利用します。

10. 受入れテストに成功したら、新規シナリオを本番に対してリリースします。


32

Oracle Data Integratorを使用したオラクルのベスト・プラクティス

Oracle Data Integratorリポジトリのアーキテクチャ

ソース・アプリケーションやターゲット・アプリケーションとは別のOLTPデータベースに、Oracle

Data Integratorのマスター・リポジトリと作業リポジトリをインストールすることを推奨します。

Oracleスキーマのリバース・エンジニアリング

Oracle JDBCドライバには、ほとんどのメタデータAPIが実装されています。したがって、Oracle Data

Integratorでは標準JDBCのリバース・エンジニアリングを使用できます。この方法を使用すると、次

のメタデータを取得できます。

表、ビューなど（表コメントを含む）

列（データ型、データ長、スケール、コメントを含む）

主キー

外部キー

チェック制約

RKM Oracleを使用したカスタムのリバース・エンジニアリングが必要になる場合があります。たと

えば、Oracle Data Integrator 11gではデータベース・パーティションがネイティブ・サポートされてい

ますが、これはRKM Oracleを使用しない限りリバース・エンジニアリングすることができません。

RKM 説明

RKM Oracle Oracle向けのリバース・エンジニアリング・モジュール

このRKMはOracleデータ・ディクショナリとして知られるOracleシステムを使用して、表とその関連

アーチファクト（列、キー、パーティションなど）のメタデータ定義を抽出します。

Oracleのロード戦略

Oracleデータウェアハウスへのロードを実行する際の目標は、常にもっとも効率的な方法でデータベー

スにデータをロードすることです。Oracle Data IntegratorはOracle向けに最適化されたいくつかのロー

ド・ナレッジ・モジュールを提供しており、この目標の達成を支援します。それぞれのユースケース

に適したナレッジ・モジュールを選択すると、データ統合プロセスの効率が大幅に向上します。


33

次の表に、Oracle向けに最適化されたロード・ナレッジ・モジュールのリストを記載します。

LKM 説明

LKM File to Oracle (EXTERNAL TABLE) 外部表のSQLコマンドを使用して、ファイルからOracleステージング領域にデータをロー

ドします。

LKM File to Oracle (SQLLDR) SQL*Loaderコマンドライン・ユーティリティを使用して、ファイルからOracleステージ

ング領域にデータをロードします。Oracle Data Integratorエージェントのホスト・マシン

にOracleクライアントがインストールされている必要があります。

LKM SQL to Oracle エージェントを使用して、任意のSQL RDBMSからOracleステージング領域にデータを

ロードします。

LKM MSSQL to Oracle (BCP SQLLDR) BCPおよびSQL*Loaderユーティリティを使用して、Microsoft SQL Serverデータベースか

らOracleステージング領域にデータをロードします。Oracle Data Integratorエージェント

のホスト・マシンにユーティリティがインストールされている必要があります。

LKM Oracle to Oracle (DBLINK) データベース・リンクを使用して、Oracleソース・データベースからOracleステージング

領域データベースにデータをロードします。

LKM Oracle to Oracle (datapump) datapump形式の外部表を使用して、Oracleソース・データベースからOracleステージン

グ領域データベースにデータをロードします。

その他に数種のナレッジ・モジュールが提供されており、SAP ERPやSAP BW、またはOracle Business

Intelligenceからデータを抽出してOracleデータベースにレコードをロードするために使用できます。

フラット・ファイル向けローダーの使用

インタフェースのソースにフラット・ファイルが含まれるケースでは、Oracle Data Integratorエージェ

ントを使用してフラット・ファイルのデータをロードする標準の"LKM File to SQL"モジュールを使

用するよりも、ステージング領域のテクノロジーに対してもっとも効率の優れたロード・ユーティ

リティを利用する方が良い場合があります。

エージェントはターゲットへの書込みにJDBCを使用するため、外部表のSQLコマンドやSQL*Loader

を使用したOracleデータベースへのロードと比較すると、重大なパフォーマンスの問題につながる可

能性があります。

大容量ファイルをロードする場合、Oracle Data Integratorエージェントを使用するのではなく、"LKM

File to Oracle (EXTERNAL TABLE)"を使用してファイルをOracleデータベースに転送することを推奨

します。

リモート・サーバーに対するアンロードとロードの使用

ソースの結果セットがリモートのデータベース・サーバーに配置されている場合、エージェントを

使用してデータを転送する代わりに、データをファイルにアンロードしてからステージング領域に

ロードする方法があります。

"LKM MSSQL to Oracle (BCP SQLLDR)"はこの方法に従うナレッジ・モジュールの例であり、BCPユー

ティリティを使用してMicrosoft SQL Serverデータベースからファイルにデータをバルク・アンロー

ドし、SQL*Loaderを使用してOracleステージング領域にデータを再ロードします。このロード・ナレッ

ジ・モジュールは、Microsoft SQL Serverから抽出したデータをOracleデータベースにロードするため

に最適なアプローチを提供します。


34

SAP ERPやBWのLKMなど、いくつかのナレッジ・モジュールで同様のアプローチが使用されています。

OracleデータベースからOracleデータベースへのロード

Oracleシステム間でデータを移動する必要のあるユースケースがあります。Oracle Data Integratorはこ

れを実現するため、いくつかの方法を提供しています。

このようなシナリオでデータをロードするための最善の方法の1つは、Oracle Data Pumpを使用する方

法です。Oracle Data Integratorが提供する"LKM Oracle to Oracle (datapump)"モジュールは、Oracle Data

Pumpを利用して、効率的なデータのエクスポートとロードを実行します。この際、ソース・データ

ベースとターゲット・データベースの両方にOracle Data Pumpを使用して外部表が作成されます。

また、Oracle Data Integratorが提供する"LKM Oracle to Oracle (DBLINK)"を使用すると、ソースとター

ゲットのOracleデータベース間にデータベース・リンクが作成され、データがロードされます。

チェンジ・データ・キャプチャの使用

チェンジ・データ・キャプチャ（CDC）アプローチを適用すると、Oracle Data Integratorプロセスの

パフォーマンスを大幅に向上できます。

たとえば、データウェアハウスのロードを毎晩実行している場合、抽出する必要があるのは、過去

24時間以内に変更されたデータのみです。ソース・データセット全体をロードするとOracle Data

Integratorジョブの効率が大幅に低下します。

CDCを使用すると、各種ソース・システムからの抽出が段階的に実行されます。これによって、ソー

ス・システムからターゲット・データベースに送信されるデータ量だけでなく、Oracle Data Integrator

によって変換されるデータ量も削減されます。CDCプロセスの作成は困難な作業ですが、Oracle Data

Integratorはナレッジ・モジュールの提供を通じてこれを簡素化します。このナレッジ・モジュール

では、データベースのネイティブCDC機能を含む多くのCDCメカニズムが利用されています。

Oracleデータベースのチェンジ・データ・キャプチャ

Oracleデータベースで実施された変更を検出するために、Oracle Data Integratorはいくつかのオプショ

ンを提供しています。

Oracle GoldenGateを使用したCDC

Oracle Streamsを使用したCDC

データベース・トリガーを使用したCDC

Oracleジャーナル化ナレッジ・モジュール（JKM）を利用すると、Oracle Data IntegratorのCDCフレー

ムワークに必要な基盤インフラストラクチャが自動的に作成されるため、エンドユーザーはこれを

心配する必要はありません。たとえばOracle JKMには、必要に応じてOracle GoldenGateやOracle

Streamsのインフラストラクチャを構成する機能が含まれています。


35

次の表に、Oracle Data Integratorで提供されるOracle向けJKMのリストを記載します。

JKM 説明

JKM Oracle to Oracle Consistent (OGG) CDC向けにOracle GoldenGateを使用した場合、Oracle Data

IntegratorのCDCフレームワーク・インフラストラクチャを作成し、

管理します。

JKM Oracle 10g Consistent (Streams) Oracle Streamsを使用して、一貫したジャーナル化を行うためのジャー

ナル化インフラストラクチャをOracle 10gの表に作成します。

JKM Oracle 11g Consistent (Streams) Oracle Streamsを使用して、一貫したジャーナル化を行うためのジャー

ナル化インフラストラクチャをOracle 11gの表に作成します。

JKM Oracle Consistent トリガーを使用して、一貫したジャーナル化を行うためのジャーナ

ル化インフラストラクチャをOracle表に作成します。

JKM Oracle Consistent (Update Date) ソース表の最終更新日付列に基づくトリガーを使用して、一貫した

ジャーナル化を行うためのジャーナル化インフラストラクチャを

Oracle表に作成します。

JKM Oracle Simple トリガーを使用して、単純なジャーナル化を行うためのジャーナル

化インフラストラクチャをOracle表に作成します。

また、タイムスタンプや日付、または順序番号など、Oracle Data Integratorで提供されているその他

のメカニズムを利用して変更を検出することもできます。

Oracle Data Integratorではこの他にも多数のJKMが提供されています。JKMの一覧については、Oracle

Data Integratorドキュメントを参照してください。

Oracleの統合戦略

Oracleデータベース向けに最適化された統合ナレッジ・モジュールには、Oracleデータウェアハウス

にデータ挿入する際のベスト・プラクティスが数多く実装されています。

- 可能な限り、/*+ APPEND */ヒントを使用して、ダイレクト・パス・ロードを適用します。

- IKMのOPTIMIZER_HINTオプションを使用すると、特定のデータベース処理に対する並列度

を指定するPARALLELなどの追加のオプティマイザ・ヒントを指定できます。

- 最高のパフォーマンスを実現するため、Oracle Data Integratorステージング領域の表はデフォ

ルトでNOLOGGINGを使用して作成されます。

- "IKM Oracle Incremental Update (MERGE)"を使用すると、MERGE SQL文を利用できます。

MERGEはINSERTとUPDATEを1つに組み合わせて最適化されたSQLコマンドです。

- Oracle Data Integratorは表の統計情報を収集して、Oracleデータベースのコストベース・オプ

ティマイザ（CBO）が長期にわたって最適な実行計画を選択できるようにします。

- 結合やフィルタの実行を高速化するため、索引が作成されます。エンドユーザーは、ビット

マップ索引の作成を含む複数のオプションから自由に選択できます。ビットマップ索引はス

ター・スキーマ内の大きなファクト表と小さなディメンション表間の結合を大幅に効率化し

ます。


36

次の表に、Oracleデータベースで使用できるIKMのリストを記載します。

IKM 説明

IKM SQL Control Append ISO-92に準拠したデータベースのターゲット表に含まれるデータをTRUNCATE/INSERT

（追加）モードで統合します。データ品質はチェックされ、無効なデータはエラー判定され

て"E$"エラー表に格納され、再利用されます。

IKM Oracle Incremental Update Oracleデータベースに対するセット・ベースの増分更新

IKM Oracle Slowly Changing Dimension Oracleデータベース向けの緩やかに変化するディメンション・タイプ2

IKM Oracle Incremental Update (MERGE) MERGE文を使用して、増分更新モードでOracleターゲット表のデータを統合します。

IKM Oracle Multi Table Insert 複数表の挿入文（MTI）を使用し、1つのソースから1つ以上のOracleターゲット表に対して、

追加モードでデータを統合します。

IKM Oracle AW Incremental Update 増分更新モードでOracleターゲット表のデータを統合し、アナリティック・ワークスペース

内のキューブを更新できます。

また、必要に応じて独自のベスト・プラクティスに対して、Oracle Data Integratorナレッジ・モジュー

ルを拡張することもできます。ナレッジ・モジュールのすぐれた再利用性のおかげで、ベスト・プ

ラクティスの適用と利用をすべての開発者に簡単に徹底できます。

データ品質戦略の定義

クリーンでないデータをデータウェアハウスにロードすると、ETLプロセスのパフォーマンス全体に

大きな影響を与える可能性があります。データ統合プロセスに適切なデータ品質フレームワークが

組み込まれていない場合、主キーまたは外部キーの違反、ビジネス・ルールの不履行、予期しない

NULL値などによって時間やリソースが浪費される場合があります。

Oracle Data Integratorでは、データベースへのデータ・ロード中に発生するデータ品質エラーを処理

するフレームワークが標準で提供されています。ビジネス・ルールや制約はメタデータ・レベルで

定義され、これらの検証ルールはターゲット表に統合される前のデータに対してチェックされます。

制約は必要に応じて有効化または無効化できます。検出されたエラーはOracle Data Integratorが管理

するエラー表に送信され、Designer NavigatorやOracle Data Integratorコンソールを介して確認されます。

"CKM Oracle"は特定のOracle表に定義されたデータ整合性制約をチェックする場合に推奨されてい

るチェック・ナレッジ・モジュールです。


37

Oracle環境でのエージェントの設定

エージェントをインストールする場所

一般的なデータウェアハウス実装では、本番で1つ以上のエージェントが使用されます。Oracle環境

では通常、データウェアハウスへのデータ・ロードに使用されたホスト・マシン上にエージェント

がインストールされます。エージェントはソース・データベースまたはファイルに対する接続を必

要とし、適切なロード・ユーティリティを起動します。Oracle Data Integrator 11g以降では、Oracle Data

IntegratorエージェントをOracle WebLogic Serverにインストールして、クラスタ配置を利用した高可

用性を実現できます。


38

アーキテクチャの事例

リポジトリのセットアップ

Oracle Data Integratorリポジトリの一般的なアーキテクチャ

データウェアハウス・プロジェクトにおける標準的な環境では、通常、次のリポジトリが作成され

ます。

すべてのトポロジ情報とセキュリティ情報を含む、1つのマスター・リポジトリ。すべての作

業リポジトリはこのマスター・リポジトリ内に登録されます。この1つのマスター・リポジト

リに、設計者がコミットしたすべてのオブジェクト・バージョンが格納されます。

すべてのOracle Data Integrator設計者によって共有される"開発"作業リポジトリ。このリポジ

トリには開発中であるすべてのプロジェクトとモデルが含まれます。

ITテスト・チームによって共有される"テスト"作業リポジトリ。このリポジトリには、将来的

なリリースに向けてテストを進行中のすべてのプロジェクトとモデルが含まれます。

ITテスト・チームとビジネス・アナリストによって共有される"ユーザー受入れテスト"作業

リポジトリ。このリポジトリには、まもなくリリースされるすべてのプロジェクトとモデル

が含まれます。ビジネス・アナリストはこのリポジトリに対してOracle Data Integratorコンソー

ルを使用して、本番にリリースする前にシナリオと変換を検証します。

本番チーム、オペレーター、そしてビジネス・アナリストによって共有される"本番"作業リ

ポジトリ。このリポジトリには、すべてのプロジェクトとモデルが読取り専用モードで格納

されており、メタデータ系統とリリースされたすべてのシナリオを確認できます。

保守チームと開発チームによって共有される"ホット・フィックス"作業リポジトリ。この作

業リポジトリは通常、空の状態にあります。本番で重大なエラーが発生すると、保守チーム

は該当するプロジェクトとモデルをこのリポジトリにリストアし、開発チームの協力を得て

修正を実行します。問題が解決されると、シナリオは本番リポジトリに対して直接リリース

され、マスター・リポジトリ内では新規のモデルとプロジェクトがバージョニングされます。


39

次の図に、この推奨アーキテクチャを示します。

図10：Oracle Data Integratorリポジトリとチーム組織

マスター・リポジトリとすべての作業リポジトリは通常、同じOLTPデータベース・インスタンス上

の別々のスキーマまたはカタログ内に作成されます。

開発者はプロジェクトに対する作業を終了し、リリースを決定すると、プロジェクトとモデルに対

してバージョンを作成し、マスター・リポジトリに保管します。このバージョンは、後でITテスト・

チームによってテスト・リポジトリ内にリストアされます。技術テストが完了したら、テスト・チー

ムはビジネス・アナリスト用に"ユーザー受入れテスト"リポジトリを初期化します。作業していたも

のと同じバージョンをリストアし、ビジネス・ユーザーによるテストを実施します。このバージョ

ンの機能が受け入れられたら、本番チームによって本番リポジトリへのリストアが実行されます。

本番で重大なバグが発見された場合、通常、開発者はすでに次のリリースに対する作業を開始して

います。したがって、開発を停止して修正用に以前のバージョンをリストアすることはできません。

このため、保守チームが本番で使用されているバージョンのリストアを担当し、"ホット・フィック

ス"と呼ばれる独立した空の作業リポジトリにリストアしてから、適切な修正を適用します。この作

業が終了したら、保守チームは修正したプロジェクトやモデル、またシナリオをマスター・リポジ

トリにリリースします。これにより、本番チームはパッチとしてこれらを本番リポジトリにリスト

アすることができます。

本番向けの独立マスター・リポジトリの作成

特殊なセキュリティ要件があるケースでは、開発環境と本番環境で同じマスター・リポジトリを共

有しない方が良い場合があります。この場合の解決策として、次に示すとおりマスター・リポジト

リを複製し、本番環境をその他の環境から分離します。


40

図11：複数のマスター・リポジトリ

本番環境に新しいマスター・リポジトリを作成する場合、Topology Navigatorからマスター・リポジ

トリをエクスポートし、次にマスター・リポジトリ・インポート・ウィザードを使用する方法を推

奨します。マスター・リポジトリ・インポート・ウィザードはOracle Data Integrator Studioで提供され

ています。新規マスター・リポジトリを作成する際、開発マスター・リポジトリで使用されていたID

とは異なる新しいIDを割り当てる必要があります。

作成が終わったら、次のタスクを実行して本番環境をセットアップします。

本番コンテキストを作成します。

トポロジの物理アーキテクチャに含まれるすべての本番データ・サーバーと物理スキーマを

作成します。

設計者によって本番コンテキスト内に定義されている論理スキーマに対して、本番の物理ス

キーマからの関連付けを作成します。

既存のコンテキストや論理スキーマを変更したり、削除したりしないでください。

本番のユーザーとビジネス・アナリストのみがリポジトリにアクセスできるように、セキュ

リティを更新します。

本番作業リポジトリを作成し、その他の作業リポジトリ（開発、ホット・フィックス、テス

ト、ユーザー受入れテスト）で使用されていないIDを割り当てます。作業リポジトリIDが与

える影響の理解の項を参照してください。

開発マスター・リポジトリが更新されるたびに、手動で本番マスター・リポジトリ内にこの

変更を複製します。


41

開発マスター・リポジトリからXMLファイルへ、本番準備の整ったプロジェクト、モデル、

シナリオをエクスポートします。この作業を実行するには、"バージョン・ブラウザ"を使用

します。または、ソリューションを使用している場合、ソリューションを圧縮ファイルにエ

クスポートします。

Designerを使用して本番作業リポジトリに接続し、XMLファイルまたはソリューションの圧

縮ファイルをインポートします。

作業リポジトリIDが与える影響の理解

マスター・リポジトリまたは作業リポジトリを作成する際、Oracle Data Integratorではリポジトリに3

桁のIDを割り当てる必要があります。このIDを選択する際、次のルールに従う必要があります。

企業内に作成したすべてのマスター・リポジトリが一意なIDを持つこと

異なるマスター・リポジトリに属する場合を含めて、企業内に作成したすべての作業リポジ

トリが一意なIDを持つこと

Oracle Data Integratorリポジトリに含まれるすべてのオブジェクトには、<自動割当て番号>に3桁のリ

ポジトリIDを連結するというルールに従って一意なIDが割り当てられます。

例を挙げると、インタフェースの内部IDが1256023である場合、023というIDを持つ作業リポジトリ

で最初に作成されたことが自動的に判明します。

このルールのおもな目的は、複数の作業リポジトリ間で、ID競合のリスクなしにオブジェクトを"シ

ノニム・モード"でエクスポートおよびインポートできるようにすることです。

2つの作業リポジトリが同じIDを持つ場合、これらのリポジトリに含まれる異なる2つのオブジェク

トが同じIDを持つ危険性があります。つまり、最初のリポジトリから2番目のリポジトリに1番目の

オブジェクトをインポートすると、2番目のオブジェクトが上書きされる可能性があります。これを

回避するには、言うまでもなく2つの作業リポジトリに異なるIDを割り当てる必要があります。

Oracle Data Integratorバージョン管理機能の使用

バージョン管理の仕組み

Oracle Data Integratorにおけるバージョン管理の目的は、次に示すとおり複数の作業リポジトリにわ

たって、さまざまなバージョンのオブジェクトに対する作業を実行できるようにすることにあります。


42

図12：Oracle Data Integratorを使用したバージョン管理

注：ユーザー受入れテスト・リポジトリはこの図に含まれていません。これは、このリポジトリの

新規バージョンを生成する仕組みはテスト・リポジトリの場合と類似しているためです。

開発者はすでに、開発バージョン1.0、2.0、および2.1をマスター・リポジトリにリリースしています。

新しいバージョンがリリースされるたびに、ソリューションが使用されています。詳しくは、ソ

リューションを使用した構成管理の項を参照してください。開発者は次のリリースに対して作業を

進めており、ソリューション・バージョン2.2をまもなくリリースする予定です。一方、ITテスト・

チームは作業リポジトリでバージョン2.1のテストを実行しています。また本番チームは依然として

バージョン2.0に取り組んでおり、このバージョンには重大なバグが発見されています。したがって、

保守チームはホット・フィックス作業リポジトリにバージョン2.0をリストアして、パッチ・リリー

スv2.05に対する作業を実行中です。このパッチ・リリースがマスター・リポジトリにコミットされ

次第、本番チームはこれを本番リポジトリにリストアします。開発者は、保守チームがバージョン

2.0.5に対して実行した変更を反映するために、バージョン2.1と2.2を手動で更新する必要があります。

注：作業リポジトリに格納できるオブジェクト・バージョンは1つだけです。

オブジェクト・バージョンの作成とリストア

オブジェクト・バージョンを作成する場合、オブジェクトを右クリックして、「Version」→「Create

Version」の順に選択するだけで完了です。


43

オブジェクト・バージョンが作成されると、オブジェクトの"Version"タブの"Version Browser"に表示

されます。またOracle Data Integratorによってこのオブジェクトに関連するすべての"I"フラグと"U"

フラグが更新され、マスター・リポジトリに含まれたバージョンと同期が取れていることが分かり

ます。マスターにコミットした後で作業リポジトリ内のオブジェクトを変更すると、オブジェクト

のアイコンが変化して小さい"U"マークが表示され、ステータスが"Updated"に変わったことが示され

ます。この機能を使用すると、現在のバージョンとマスター・リポジトリに最後にコミットされた

バージョンとの間での相違点がすべて明らかになるため、非常に便利です。

オブジェクト・バージョンを作成すると、オブジェクトはメモリ内のXMLにエクスポートされ、バ

イナリ・ラージ・オブジェクトとして圧縮された状態でマスター・リポジトリに格納されます。こ

のため、オブジェクト・バージョンの作成を検討するのは、確実にリリースするつもりでコミット

しようとしている場合に限る必要があります。

オブジェクトを以前のバージョンに戻すには、オブジェクトを右クリックして、「Version」→

「Restore」の順に選択します。次に、バージョン・リストからリストアするバージョンを選択します。

このとき、次の点に注意する必要があります。

現在のオブジェクトに対する最新バージョンを作成した後に実行したすべての変更が失われ

ます。

リストアしようとしているオブジェクトは、作業リポジトリからすでに削除されているオブ

ジェクトを参照している可能性があります。よくある事態は、モデル内に存在しない列を参

照しているインタフェースをリストアしようとするケースです。このような場合、リストア

されたオブジェクトには赤い感嘆符が表示され、"無効"であることが示されるため、オブジェ

クトを編集してすべての欠落参照を修正する必要があります。

ソリューションを使用した構成管理

設計期間中に、おそらくバックアップ用のオブジェクト・バージョンが作成されるでしょう。例を

挙げると、モデルやフォルダ、インタフェースや変数、またナレッジ・モジュールなどのバージョ

ンが作成されます。これらのオブジェクトのほとんどは互いに依存関係にあるため、連携して動作

するよう設計されます。たとえば、インタフェース・バージョン2.1.0には、モデル3.1.2に含まれる

表とバージョン1.2および4.5のナレッジ・モジュールが必要になります。依存性リストの保守は、非

常に退屈で時間のかかる作業になります。したがって、テスト・チーム向けの開発をリリースする

場合、1つのオブジェクトでこれらの依存性を管理できるようにすることが望ましいと言えます。

Oracle Data Integratorソリューション・オブジェクトは、プロジェクトと参照先のすべてのモデル、

グローバル・オブジェクト、そしてシナリオの間に存在する依存性を管理するよう設計されていま

す。開発をリリースする直前に新しいソリューションを作成し、このソリューションにプロジェク

トをドラッグ・アンド・ドロップするだけで、Oracle Data Integratorによってプロジェクトの新規バー

ジョンが作成され（必要な場合）、このプロジェクトから参照されているすべてのモデル、シナリ

オ、その他のプロジェクトやグローバル・オブジェクトの新規バージョンも作成されます。したがっ

て、複数のオブジェクトをリリースしなくても、このソリューションをリリースするだけで良いこ

とになります。

注：

パフォーマンス上の理由から、バージョン作成メカニズムを効率化するため、プロジェクトのサイ

ズを小さく抑えるようにしてください。開発内容を複数の小規模プロジェクトに分割し、含まれる

オブジェクトを300未満に抑えることを推奨します。


44

ソリューションを構築するためにプロジェクトの依存性を計算する際、Oracle Data Integratorはその

プロジェクトによって参照されるすべてのモデルのバージョンを作成します。次にそれぞれのモデ

ルを調べて、どのナレッジ・モジュール（RKM、JKM、CKM）が参照されているかを確認します。

最後に、これらのナレッジ・モジュールが属するすべてのプロジェクトの新規バージョンを作成し

ます。したがって、モデルが参照しているナレッジ・モジュールが3つの異なるプロジェクトに属し

ている場合、ソリューションはこれら3つのプロジェクトも参照します。このようなケースを避ける

ためのベスト・プラクティスは、"メタデータ・ナレッジ・モジュール"と呼ばれるプロジェクトを作

成し、このプロジェクトにモデルから参照されているすべてのRKM、CKM、JKMを含めることです。

そうすることで、ソリューションが作成されるときはいつでも、3つや4つも異なるプロジェクトを

追加する代わりにこのプロジェクトが依存性として追加されます。

本番への移行

シナリオのリリース

Oracle Data Integratorバージョン管理機能の使用の項では、本番環境にリリースする際のオブジェク

ト・バージョンの管理方法について簡単に説明しました。しかし、該当するプロジェクトやモデル

なしで、シナリオのみを本番作業リポジトリに配置したい場合があります。このような場合、"開発"

作業リポジトリではなく"実行"作業リポジトリを作成します。シナリオがマスター・リポジトリに対

してリリースされるか、またはシンプルなXMLファイルとしてリリースされる際、これらを作業リ

ポジトリにリストアするか、もしくはOperator Navigatorを使用して"シノニム"モードまたは"重複"

モードでインポートします。

シナリオの実行

手動によるシナリオの実行

Operator Navigatorを使用すると、手動でシナリオを実行できます。シナリオに変数を設定する必要が

ある場合、シナリオで使用されているすべての変数を編集して、デフォルト値を更新する必要があ

ります。シナリオを実行するには、実行用のコンテキストに加えて、実行を担当する論理エージェ

ントを指定する必要があります。

もう1つのシナリオ実行方法は、Oracle Data Integratorコンソールを使用してWebブラウザからシナリ

オを開始する方法です。この方法は、ビジネス・ユーザーやアナリストからオンデマンドで実行さ

れるシナリオを検討している場合に便利な方法です。また変数を必要とするシナリオに対しては、

変数値を入力するよう求めるプロンプトがユーザーに適宜表示されます。

オペレーティング・システム・コマンドを使用したシナリオの実行

"startscen"シェル・スクリプトを使用すると、オペレーティング・システム・コマンドからシナリオ

を開始できます。この方法は、外部のスケジューラを使用してジョブをスケジューリングする場合

に使用されます。このオペレーティング・システム・コマンドについて、詳しくはOracle Data Integrator

ドキュメントを参照してください。

オペレーティング・システムからシナリオを開始する際、実行エージェントは必要ありません。

"startscen"コマンドには独自のエージェントが組み込まれており、このエージェントによってシナリ

オが実行され、セッション終了時に停止されます。


45

セッションに対するセッション・キーワードの割当て

Operator Navigatorログには多数のセッションが含まれるため、ときとして閲覧が困難であると感じる

場合があります。この制限を克服するため、Oracle Data Integratorではセッションにキーワードを割

り当てられるようになっています。このセッションはOperator Navigator内に作成された適切なセッ

ション・フォルダに自動的に格納されます。

次の図では、キーワード"PDIM"に対して"Product Dimensions"というフォルダが作成されています。

LOAD_FAMILY_HIERARCHY シナリオと LOAD_PRODUCTS シナリオが開始されると、

"-KEWORDS"パラメータに"-KEYWORDS=PDIM"が設定されます。その結果、Operator Navigatorを使

用して実行済みセッションにアクセスすると、これらが自動的に"Product Dimensions"フォルダに表

示されます。

図13：セッション・フォルダとキーワード

この機能を使用すると、複数のビジネス領域にセッションを分散することができます。

本番でのOperator Navigatorの使用

Oracle Data Integrator StudioのOperator Navigatorは、本番環境でもっとも使用されるモジュールです。

このモジュールを使用すると、オペレーターは次のタスクを実行できます。

本番作業リポジトリへのシナリオのインポート

手動によるシナリオの実行と、シナリオ変数に対するデフォルト値の割当て

処理された行数や実行経過時間を含む高度な統計情報を使用した、実行ログの追跡

実行されているセッションの強制終了

処理に失敗したセッションの再開と、タスク・ステータスの更新による再開ポイントの定義

変更


46

事前定義したキーワードとセッションを格納するセッション・フォルダの作成

スケジューリング情報に対するアクセスと定義

本番でのOracle Data Integratorコンソールの使用

本番でOracle Data Integratorコンソールを使用する目的は、次の2つがあります。

ビジネス・ユーザーやアナリスト、またオペレーターがメタデータ系統、メタデータ検索、

シナリオ実行、ログ監視にアクセスできるようにすること。この場合、本番作業リポジトリ

を"開発"リポジトリとして使用し、リリースされたすべてのプロジェクト、モデル、シナリ

オをこのリポジトリにリストアする必要があります。

オペレーターがシナリオやログのみにアクセスできるようにすること。この場合、本番作業

リポジトリは"実行"作業リポジトリとなり、リリースされたシナリオのみを含むことになり

ます。

エージェントの設定


一般的なデータウェアハウス実装では、本番で1つ以上のOracle Data Integratorエージェントを使用す

る必要があります。データウェアハウス環境では通常、データウェアハウスへのデータ・ロードに

使用されるホスト・マシン上にOracle Data Integratorエージェントがインストールされます。エージェ

ントはソース・データベースまたはファイルに対する接続を必要とし、適切なロード・ユーティリ

ティを起動します。

Oracle Data Integrator 11gで導入されたJava EEエージェントはJava EEアプリケーション・サーバーに

配置されており、その機能を利用できます。このようなエージェントは、エージェントの配置と管

理の一元化を求める要件があるか、または高可用性に対するニーズがある場合に推奨されます。

エージェントのホスト・マシンとデータウェアハウス間のネットワーク帯域幅は、ユーティリティ

によってウェアハウス・データベースにロードされるデータ量に対して十分な大きさを備えている

必要があります。また一方で、エージェントからその他のソース・サーバーにアクセスする必要が

生じる場合もあるため、これらのソース・サーバーとのネットワーク帯域幅に細心の注意を払う必

要があります。

ナレッジ・モジュールによってオペレーティング・システム固有のコマンドが生成される場合、エー

ジェントがインストールされているマシンのオペレーティング・システムとこれらのコマンドが一

致している必要があります。

通常の環境では、次の設定を行います。

開発チーム向けの1つの物理エージェント。本番エージェントと同じオペレーティング・シス

テムへの配置が望ましい

テスト・チーム、保守チーム、ユーザー受入れチームに共有される1つの物理エージェント。

本番エージェントと同じオペレーティング・システムの使用が望ましい


47

本番向けの1つの物理エージェント

ロードバランシングの使用

並行して開始された多数のセッションを処理する必要がある場合は特に、1つしかないエージェント

がボトルネックとなるケースがあります。たとえば、300のストアからソース・データを取得すると

します。1つのエージェントを使用してこれを並行処理しようとする場合、300のスレッド（セッショ

ンごとに1つ）を開く必要が生じ、過剰なオーバーヘッドにつながる可能性があります。これを回避

する方法は、複数エージェントにまたがるロードバランシング機能をセットアップすることです。

Oracle Data Integratorでロードバランシングをセットアップするには、Topology Navigatorで次の手順

を実行します。

ワークロードの分散を担当するエージェントを定義します。これ以降、このエージェントを"

マスター・エージェント"と呼びます。マスター・エージェントが維持できる同時セッション

は2つのみです。すべてのシナリオは、– AGENTパラメータを使用してこの単一エージェン

トによって実行されます。

実際のシナリオ実行を担当する子エージェントをいくつか定義します。各エージェントの最

大セッション数を2から20の間の値に設定します。

Topology Navigatorでマスター・エージェントを開き、"Load Balancing"タブですべての子エー

ジェントを選択します。

次の図に、このアーキテクチャのセットアップ方法の一例を示します。

図14：ロードバランシングの例

この例では2つの異なるマシン上に4つのエージェントがインストールされており、それぞれのエー

ジェントが最大3つのセッションを並行して受け入れます。またマスター・エージェントは別のマシ

ン上にインストールされています。


48

マスター・エージェントは複数のシナリオを並行して開始するよう求める14のリクエストを受信し、

これら14のリクエストを使用可能なエージェントに分散します。各エージェントが3つのシナリオを

並行して開始し、最初の2つのエージェントは残りのセッションを後で実行するようキューイングし

ます。いずれかのエージェントが使用可能になると、キューイングされていたセッションが取得さ

れて実行が開始されます。

マスター・エージェントは最初に、現在実行されているセッション数とエージェントに許可された

最大セッション数の比率に応じて、エージェントごとのワークロードを計算します。次に各エージェ

ントに1つずつ受信セッションを分散し、ワークロードの割合を再計算します。あるエージェント向

けにキューイングされたセッションを別のエージェントが取り出すこともできるため、全体的なシ

ステムのバランスが取れます。

この柔軟なアーキテクチャを利用すると、システムの最大スケーラビリティに達するまで、必要な

数のエージェントを追加できます。複数のシナリオを並行して開始する予定がある場合、手際よく

これを実現する方法の詳細についてはOracle Data Integratorバージョン管理機能の使用の項を参照し

てください。

注：必要なエージェント数とサポートされる最大セッション数は、環境設定によって異なります。

本番移行前に、入念なテストを実施してください。すべてのエージェントが同じデータベース表に

アクセスするため、このアーキテクチャにおける一番のボトルネックはOracle Data Integratorリポジ

トリをホストするRDBMSになります。このようなアーキテクチャのセットアップを計画している場

合、Oracle Data Integratorリポジトリ専用のデータベース・サーバーを配置することを推奨します。

そうすることで、ロックやパフォーマンスの問題が発生した場合にも、より柔軟にこのサーバーを

チューニングできます。

リポジトリのバックアップ

Oracle Data Integratorでは、作業の損失を回避するため、マスター・リポジトリと作業リポジトリを

毎日バックアップすることを推奨します。

リポジトリをバックアップするには、標準のデータベース・バックアップ手順を使用して、マスター・

リポジトリまたは作業リポジトリをインストールしたすべてのスキーマをバックアップします。

スキーマやカタログのバックアップ方法については、データベース固有のドキュメントを参照して

ください。


49

付録

付録I Oracle Data Integratorを使用したTeradataのベスト・プラクティス

Oracle Data Integratorリポジトリのアーキテクチャ

ソース・アプリケーションやターゲット・アプリケーションとは別のOLTPデータベースに、マス

ター・リポジトリと作業リポジトリをインストールすることを推奨します。Teradataデータベースは

Oracle Data Integratorリポジトリのホスト・データベースとして推奨されていません。

Teradataスキーマのリバース・エンジニアリング

TeradataのJDBCドライバには、ほとんどのメタデータAPIが実装されています。したがって、Oracle

Data Integratorでは標準JDBCのリバース・エンジニアリングを使用できます。この方法を使用すると、

次のメタデータを取得できます。

表やビュー（表コメントを含む）

列（データ型、データ長、スケール、コメントを含む）

主キー制約文を使用してデータベースに定義された主キー

しかし、ほぼ確実に次の制限事項に直面するでしょう。

JDBCドライバに外部キー・メタデータが実装されていない。この場合、Oracle Data Integrator

に外部キーが取得されません。

一意の1次索引（UPI）と一意でない1次索引（NUPI）がインポートされない。UPIをOracle Data

Integratorの主キーとしてインポートするには、これをデータベース・レベルで主キー制約と

して定義する必要があります。

その他の索引がインポートされない。

チェック制約がインポートされない。

Oracle Data Integratorで提供されているTeradata向けのリバース・ナレッジ・モジュールを使用すると、

これらの制限事項の一部を回避できます。このRKMはDBCカタログ表（DBC.Tables、DBC.Columns

など）に基づいています。独自の要件を満たすように、このナレッジ・モジュールを拡張すること

もできます。

RKM 説明

RKM Teradata DBCシステム・ビューを使用して、Teradataデータベースからメタデータを取得します。

このRKMはUNICODE列に対応しています。


50

Teradataのロード戦略

次の表に、Teradata向けに最適化されたロード・ナレッジ・モジュールを記載します。

LKM 説明

LKM SQL to SQL エージェントを使用して、任意のSQL RDBMSから任意のSQL

RDBMSステージング領域にデータをロードします。

LKM File to Teradata (TTU) Teradataバルク・ユーティリティを使用して、ファイルから

Teradataステージング領域データベースにデータをロードします。

Oracle Data Integratorエージェントのホスト・マシンにユーティリ

ティがインストールされている必要があります。

LKM SQL to Teradata (TTU) ネイティブのTeradataバルク・ユーティリティを使用して、SQLに

準拠したソース・データベースからTeradataステージング領域デー

タベースにデータをロードします。Oracle Data Integratorエージェ

ントのUNIXホスト・マシンにユーティリティがインストールされ

ている必要があります。

フラット・ファイル向けローダーの使用

インタフェースのソースにフラット・ファイルが含まれるケースでは、標準の"LKM File to SQL"モ

ジュールを使用するよりも、ステージング領域のテクノロジーに対してもっとも効率の優れたロー

ド・ユーティリティを利用する方が良い場合があります。

Oracle Data Integratorエージェントはバイナリ・ファイルに対応しており、バイナリ・ビッグ・エンディ

アンやリトル・エンディアン、EBCDIC、EBCDICゾーン10進数、パック10進数などのネイティブのバ

イナリ・データ型をサポートしています。ただし、Oracle Data Integratorエージェントを使用して大容

量のバイナリ・ファイルをTeradataステージング領域にロードすることは推奨されていません。

エージェントはターゲットへの書込みにJDBCを使用するため、ネイティブのTeradata Tools and

Utilities（TTU）を使用したロードと比較すると、重大なパフォーマンスの問題につながる可能性が

あります。TTUにはFastLoad、MulitLoad、TPump、Teradata Parallel Transporter、またはFastExportが

含まれます。Teradata表へのバイナリ・ファイルのロード方法について、詳しくはTTUドキュメント

を参照してください。"LKM File to Teradata (TTU)"を使用すると、適切なTTUスクリプトを生成し、

実行できます。

リモート・サーバーに対するアンロードとロードの使用

ソースの結果セットがリモートのデータベース・サーバーに配置されている場合、エージェントを

使用してデータを転送する代わりに、データをファイルにアンロードしてからステージング領域に

ロードする方法があります。

"LKM SQL to Teradata (TTU)"はこのような手順に従い、OdiSqlUnloadツールを使用して任意のリモー

トRDBMSからデータをアンロードします。言うまでもありませんが、ソースのRDBMSに高速なア

ンロード・ユーティリティが提供されている場合、このKMを最適化できます。

パイプラインを使用したアンロードとロード

アンロード/ロード戦略を使用する場合、データを2回ステージングする必要があるため（1回目は一

時ファイルに、2回目は"C$"表に）、過剰なディスク領域使用と潜在的な効率の問題の原因になりま

す。より効率的な代替策は、"アンロード"ユーティリティと"ロード"ユーティリティの間にパイプラ

インを使用する方法です。残念ながら、ファイル・ベースのパイプライン（FIFO）をサポートして

いないオペレーティング・システムもあります。


51

Oracle Data Integratorが提供している"LKM SQL to Teradata (TTU)"は、この戦略を使用します。分離さ

れたプロセス（またはスレッド）の動作を効果的に制御するため、このナレッジ・モジュールはJython

で記述されています。OdiSqlUnloadツールはJythonオブジェクトとして呼び出すこともできます。

Teradataの統合戦略

次の表に、Teradata向けに最適化された統合ナレッジ・モジュールの一部を記載します。

IKM 説明

IKM Teradata Control Append Teradataターゲット表に対して、置換/追加モードでデータを統合します。

IKM Teradata Incremental Update Teradataターゲット表に対して、増分更新モードでデータを統合します。

IKM Teradata Slowly Changing Dimension データウェアハウス内で緩やかに変化するディメンション・タイプ2として使用され

ているTeradataターゲット表に対して、データを統合します。

IKM File to Teradata (TTU) このIKMはTeradataユーティリティの能力を利用して、ターゲットに直接ファイルを

ロードするよう設計されています。

IKM SQL to SQL Append ANSI-SQL92に準拠した任意のリモート・ステージング領域からANSI-SQL92のター

ゲット・データベースへ、置換/追加モードでデータを統合します。

IKM SQL to Teradata (TTU) TPUMP、FASTLOAD、またはMULTILOADといったTeradataユーティリティを使用

して、SQLに準拠したデータベースからTeradataデータベースのターゲット表にデー

タを統合します。

IKM Teradata Multi Statement 1つのSQLトランザクションで管理された複数文のリクエストを使用して、Teradata

データベースのターゲット表にデータを統合します

IKM Teradata to File (TTU) Teradataステージング領域からターゲット・ファイルに対して、置換モードでデータ

を統合します。

ターゲットとは異なるステージング領域を使用したIKM

ファイルからサーバーへの追加

ソースとなる単一ファイルからターゲット表へ、もっとも効率的な方法を使用して直接ロードを実

行することが望まれるケースがあります。Oracle Data Integratorでは、デフォルトで、ターゲット・

サーバーにステージング領域を配置しておき、"C$"表にファイルをステージングするLKMと、"C$"

表のソース・データをターゲット表に適用するIKMを使用してジョブを実行することが推奨されて

います。

データをステージングすることなくTeradataにファイルをロードする必要がある場合は、"IKM File to

Teradata (TTU)"ナレッジ・モジュールの使用が推奨されています。このナレッジ・モジュールを利用

すると、各自の統合戦略に応じて、Teradataユーティリティに適したスクリプトを生成できます。

サーバーからサーバーへの追加

ターゲットとは異なるステージング領域を使用しており、このステージング領域がRDBMSに設定さ

れている場合、ステージング領域から取得して変換したデータをリモートのターゲットに移動する

IKMを使用できます。この種のIKMはLKMに非常に近く、ほとんど同じルールに従っています。IKM

SQL to Teradata (TTU)は、この戦略を使用します。


52

サーバーからファイルまたはJMSへの追加

ターゲット・データ・ストアがファイルかJMSキュー、またはJMSトピックである場合は明らかに、

ターゲットとは異なる場所にステージング領域を設定する必要があります。したがって、ファイル

またはキューをターゲット・データ・ストアにする場合、特定の"マルチ接続"IKMを使用して、ステー

ジング領域からこのターゲットに変換データをエクスポートする必要があります。データをファイ

ルまたはキューにエクスポートする方法は、IKMによって異なります。たとえば、エージェントを

使用してステージング領域からレコードを選択し、標準のOracle Data Integrator機能を使用してファ

イルまたはキューにデータを書き込むことができます。またはターゲットがJMSベースでない場合、

Teradata FastExportなどの特定のアンロード・ユーティリティを使用することもできます。

詳しくは、次のIKMを参照してください。

IKM 説明

IKM Teradata to File (TTU) Teradataステージング領域からターゲット・ファイルに対して、置

換モードでデータを統合します。

IKM SQL to File Append Oracle Data Integratorのファイル・ドライバを使用して、SQLに準

拠した任意のステージング領域からASCIIファイルまたはバイナ

リ・ファイルにデータをエクスポートします。

Teradata環境でのエージェントの設定


一般的なデータウェアハウス実装では、本番で1つ以上のOracle Data Integratorエージェントを使用す

る必要があります。Teradata環境では通常、データウェアハウスへのデータ・ロードに使用されたホ

スト・マシン上にエージェントがインストールされます。エージェントはソース・データベースま

たはファイルに対する接続を必要とし、適切なロード・ユーティリティ（fastload、multiload、tpump）

を起動します。Oracle Data Integrator 11g以降では、Oracle Data IntegratorエージェントをOracle

WebLogic Serverにインストールして、クラスタ配置を利用した高可用性を実現できます。


53

付録II：追加情報

このドキュメントで使用された頭字語

3NF 第3正規形

API アプリケーション・プログラミング・インタフェース

ASCII American Standard Code for Information Interchange

CKM チェック・ナレッジ・モジュール

DDL データ記述言語

DML データ操作言語

DW データウェアハウス

EBCDIC Extended Binary-Coded Decimal Interchange Code

E¬LT 抽出、ロード、変換

ETL 抽出、変換、ロード

GUI グラフィカル・ユーザー・インタフェース

HTTP Hypertext Transport Protocol

IKM 統合ナレッジ・モジュール

IT 情報技術

JEE Java Enterprise Edition

JDBC Java Database Connectivity

JKM ジャーナル化ナレッジ・モジュール

JMS Java Message Services

JNDI Java Naming Directory Interface

JVM Java仮想マシン

KM ナレッジ・モジュール

LDAP Lightweight Directory Access Protocol

LKM ロード・ナレッジ・モジュール

ODS オペレーショナル・データ・ストア

OLTP オンライン・トランザクション処理


54

RDBMS リレーショナル・データベース管理システム

RI 参照整合性

RKM リバース・エンジニアリング・ナレッジ・モジュール

SOX 米国サーベンス・オクスリー法

SQL Simple Query Language

URL Unique Resource Locator

XML Extended Markup Language

データウェアハウス向けのOracle Data Integrator

ベスト・プラクティス

2010年8月

著者：ODI Product Management

共著者：ODI Product Development

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065

U.S.A.

海外からのお問い合わせ窓口：

電話：+1.650.506.7000

ファクシミリ：+1.650.506.7200

www.oracle.com

Copyright © 2010, Oracle and/or its affiliates.All rights reserved.本文書は情報提供のみを目的として提供されており、ここ

に記載される内容は予告なく変更されることがあります。本文書は一切間違いがないことを保証するものではなく、さらに、

口述による明示または法律による黙示を問わず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含

み、いかなる他の保証や条件も提供するものではありません。オラクルは本文書に関するいかなる法的責任も明確に否認し、

本文書によって直接的または間接的に確立される契約義務はないものとします。本文書はオラクルの書面による許可を前

もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信す

ることはできません。

OracleおよびJavaはOracleおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。

AMD、Opteron、AMDロゴおよびAMD Opteronロゴは、Advanced Micro Devicesの商標または登録商標です。IntelおよびIntel

XeonはIntel Corporationの商標または登録商標です。すべてのSPARC商標はライセンスに基づいて使用されるSPARC

International, Inc.の商標または登録商標です。UNIXはX/Open Company, Ltd.によってライセンス提供された登録商標です。

0410

Documents

データウェアハウス向けのOracle Data Integratorベ …...データウェアハウス向けのOracle Data Integratorベスト・プラクティス 7 図1：従来のETLとE-LTアプローチの比較