Oracle® Fusion Middleware

Oracle Data Integrator接続およびナレッジ・モジュール・ガイド

12c (12.2.1.2.0)

E82656-01(原本部品番号:E77142-01)

2016年9月

Oracle Fusion Middleware Oracle Data Integrator接続およびナレッジ・モジュール・ガイド, 12c (12.2.1.2.0)

E82656-01

Copyright © 2010, 2016, Oracle and/or its affiliates.All rights reserved.

原本著者: Laura Hofman Miquel、Aslam Khan

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

1 概要

- 1.1 用語

- 1.2 このガイドの使用方法

第I部 データベース、ファイルおよびXML

2 Oracle Database

- 2.1 概要

- 2.1.1 概念

- 2.1.2 ナレッジ・モジュール

- 2.2 インストールおよび構成

- 2.2.1 システム要件および動作要件

- 2.2.2 テクノロジ固有の要件

- 2.2.2.1 SQL*Loaderユーティリティの使用

- 2.2.2.2 外部表の使用

- 2.2.2.3 Oracle Streamsの使用

- 2.2.3 接続性要件

- 2.3 トポロジの設定

- 2.3.1 Oracleデータ・サーバーの作成

- 2.3.1.1 データ・サーバーの作成

- 2.3.2 Oracle物理スキーマの作成

- 2.4 統合プロジェクトの設定

- 2.5 Oracleモデルの作成およびリバース・エンジニアリング

- 2.5.1 Oracleモデルの作成

- 2.5.2 Oracleモデルのリバース・エンジニアリング

- 2.6 チェンジ・データ・キャプチャの設定

- 2.7 データ品質の設定

- 2.8 マッピングの設計

- 2.8.1 Oracleとの間でのデータのロード

- 2.8.1.1 Oracleからのデータのロード

- 2.8.1.2 Oracleへのデータのロード

- 2.8.2 Oracleへのデータの統合

- 2.8.3 ETL形式マッピングの設計

- 2.9 トラブルシューティング

- 2.9.1 Oracle Databaseのエラーのトラブルシューティング

- 2.9.2 一般的な問題および解決策

3 ファイル

- 3.1 概要

- 3.1.1 概念

- 3.1.2 ナレッジ・モジュール

- 3.2 インストールおよび構成

- 3.2.1 システム要件および動作要件

- 3.2.2 テクノロジ固有の要件

- 3.2.3 接続性要件

- 3.3 トポロジの設定

- 3.3.1 ファイル・データ・サーバーの作成

- 3.3.1.1 データ・サーバーの作成

- 3.3.2 ファイル物理スキーマの作成

- 3.4 統合プロジェクトの設定

- 3.5 ファイル・モデルの作成およびリバース・エンジニアリング

- 3.5.1 ファイル・モデルの作成

- 3.5.2 ファイル・モデルのリバース・エンジニアリング

- 3.5.2.1 デリミタ付きファイルのリバース・エンジニアリング

- 3.5.2.2 ウィザードを使用した固定ファイルのリバース・エンジニアリング

- 3.5.2.3 COBOLコピーブックのリバース・エンジニアリング

- 3.5.2.4 カスタマイズされたリバース・エンジニアリング

- 3.6 マッピングの設計

- 3.6.1 ファイルからのデータのロード

- 3.6.2 ファイルへのデータの統合

- 3.6.2.1 IKM SQL to File Append

- 3.6.2.2 IKM File to File (Java)

4 汎用SQL

- 4.1 概要

- 4.1.1 概念

- 4.1.2 ナレッジ・モジュール

- 4.2 インストールおよび構成

- 4.2.1 システム要件および動作要件

- 4.2.2 テクノロジ固有の要件

- 4.2.3 接続性要件

- 4.3 トポロジの設定

- 4.3.1 データ・サーバーの作成

- 4.3.2 物理スキーマの作成

- 4.4 統合プロジェクトの設定

- 4.5 モデルの作成およびリバース・エンジニアリング

- 4.5.1 データ・モデルの作成

- 4.5.2 データ・モデルのリバース・エンジニアリング

- 4.6 チェンジ・データ・キャプチャの設定

- 4.7 データ品質の設定

- 4.8 マッピングの設計

- 4.8.1 ANSI SQL-92準拠テクノロジとの間でのデータのロード

- 4.8.1.1 ANSI SQL-92準拠テクノロジからのデータのロード

- 4.8.1.2 ANSI SQL-92準拠テクノロジへのデータのロード

- 4.8.2 ANSI SQL-92準拠テクノロジでのデータの統合

- 4.8.3 ETL形式マッピングの設計

5 XMLファイル

- 5.1 概要

- 5.1.1 概念

- 5.1.2 XMLドライバの事前/事後処理サポート

- 5.1.3 ナレッジ・モジュール

- 5.2 インストールおよび構成

- 5.2.1 システム要件

- 5.2.2 テクノロジ固有の要件

- 5.2.3 接続性要件

- 5.3 トポロジの設定

- 5.3.1 XMLデータ・サーバーの作成

- 5.3.1.1 データ・サーバーの作成

- 5.3.2 XML用物理スキーマの作成

- 5.4 統合プロジェクトの設定

- 5.5 XMLファイルの作成およびリバース・エンジニアリング

- 5.5.1 XMLモデルの作成

- 5.5.2 XMLモデルのリバース・エンジニアリング

- 5.6 マッピングの設計

- 5.6.1 XMLマッピングに関する注意

- 5.6.1.1 XML構造のターゲット指定

- 5.6.1.2 XMLファイルとスキーマの同期化

- 5.6.1.3 サイズが大きいXMLファイルの処理

- 5.6.2 XMLとの間でのデータのロード

- 5.6.2.1 XMLスキーマからのデータのロード

- 5.6.2.2 XMLスキーマへのデータのロード

- 5.6.3 XMLへのデータの統合

- 5.7 トラブルシューティング

- 5.7.1 XMLで発生したエラーの検出

- 5.7.2 一般的なエラー

6 複合ファイル

- 6.1 概要

- 6.1.1 概念

- 6.1.2 複合ファイル・ドライバの事前/事後処理サポート

- 6.1.3 ナレッジ・モジュール

- 6.2 インストールおよび構成

- 6.2.1 システム要件

- 6.2.2 テクノロジ固有の要件

- 6.2.3 接続性要件

- 6.3 ネイティブ・フォーマット・ビルダーを使用したネイティブ・スキーマ記述ファイルの作成

- 6.4 トポロジの設定

- 6.4.1 複合ファイル・データ・サーバーの作成

- 6.4.1.1 データ・サーバーの作成

- 6.4.2 複合ファイル物理スキーマの作成

- 6.5 統合プロジェクトの設定

- 6.6 複合ファイル・モデルの作成およびリバース・エンジニアリング

- 6.6.1 複合ファイル・モデルの作成

- 6.6.2 複合ファイル・モデルのリバース・エンジニアリング

- 6.7 マッピングの設計

7 Microsoft SQL Server

- 7.1 概要

- 7.1.1 概念

- 7.1.2 ナレッジ・モジュール

- 7.2 インストールおよび構成

- 7.2.1 システム要件および動作要件

- 7.2.2 テクノロジ固有の要件

- 7.2.2.1 BULK INSERTコマンドの使用

- 7.2.2.2 BCPコマンドの使用

- 7.2.2.3 リンク・サーバーの使用

- 7.2.3 接続性要件

- 7.3 トポロジの設定

- 7.3.1 Microsoft SQL Serverデータ・サーバーの作成

- 7.3.1.1 データ・サーバーの作成

- 7.3.2 Microsoft SQL Server物理スキーマの作成

- 7.4 統合プロジェクトの設定

- 7.5 Microsoft SQL Serverモデルの作成およびリバース・エンジニアリング

- 7.5.1 Microsoft SQL Serverモデルの作成

- 7.5.2 Microsoft SQL Serverモデルのリバース・エンジニアリング

- 7.6 チェンジ・データ・キャプチャの設定

- 7.7 データ品質の設定

- 7.8 マッピングの設計

- 7.8.1 Microsoft SQL Serverとの間でのデータのロード

- 7.8.1.1 Microsoft SQL Serverからのデータのロード

- 7.8.1.2 Microsoft SQL Serverへのデータのロード

- 7.8.2 Microsoft SQL Serverでのデータの統合

8 Microsoft Excel

- 8.1 概要

- 8.1.1 概念

- 8.1.2 ナレッジ・モジュール

- 8.2 インストールおよび構成

- 8.2.1 システム要件および動作要件

- 8.2.2 テクノロジ固有の要件

- 8.2.3 接続性要件

- 8.3 トポロジの設定

- 8.3.1 Microsoft Excelデータ・サーバーの作成

- 8.3.2 Microsoft Excel物理スキーマの作成

- 8.4 統合プロジェクトの設定

- 8.5 Microsoft Excelモデルの作成およびリバース・エンジニアリング

- 8.5.1 Microsoft Excelモデルの作成

- 8.5.2 Microsoft Excelモデルのリバース・エンジニアリング

- 8.6 マッピングの設計

- 8.6.1 Microsoft Excelとの間でのデータのロード

- 8.6.1.1 Microsoft Excelからのデータのロード

- 8.6.1.2 Microsoft Excelへのデータのロード

- 8.6.2 Microsoft Excelでのデータの統合

- 8.7 トラブルシューティング

- 8.7.1 エラー・メッセージの解読

- 8.7.2 一般的な問題および解決策

9 Microsoft Access

- 9.1 概要

- 9.2 概念

- 9.3 ナレッジ・モジュール

- 9.4 固有の要件

10 Netezza

- 10.1 概要

- 10.1.1 概念

- 10.1.2 ナレッジ・モジュール

- 10.2 インストールおよび構成

- 10.2.1 システム要件および動作要件

- 10.2.2 テクノロジ固有の要件

- 10.2.3 接続性要件

- 10.3 トポロジの設定

- 10.3.1 Netezzaデータ・サーバーの作成

- 10.3.1.1 データ・サーバーの作成

- 10.3.2 Netezza物理スキーマの作成

- 10.4 統合プロジェクトの設定

- 10.5 Netezzaモデルの作成およびリバース・エンジニアリング

- 10.5.1 Netezzaモデルの作成

- 10.5.2 Netezzaモデルのリバース・エンジニアリング

- 10.6 データ品質の設定

- 10.7 マッピングの設計

- 10.7.1 Netezzaとの間でのデータのロード

- 10.7.1.1 Netezzaからのデータのロード

- 10.7.1.2 Netezzaへのデータのロード

- 10.7.2 Netezzaでのデータの統合

11 Teradata

- 11.1 概要

- 11.1.1 概念

- 11.1.2 ナレッジ・モジュール

- 11.2 インストールおよび構成

- 11.2.1 システム要件および動作要件

- 11.2.2 テクノロジ固有の要件

- 11.2.3 接続性要件

- 11.3 トポロジの設定

- 11.3.1 Teradataデータ・サーバーの作成

- 11.3.1.1 データ・サーバーの作成

- 11.3.2 Teradata物理スキーマの作成

- 11.4 統合プロジェクトの設定

- 11.5 Teradataモデルの作成およびリバース・エンジニアリング

- 11.5.1 Teradataモデルの作成

- 11.5.2 Teradataモデルのリバース・エンジニアリング

- 11.6 データ品質の設定

- 11.7 マッピングの設計

- 11.7.1 Teradataとの間でのデータのロード

- 11.7.1.1 Teradataからのデータのロード

- 11.7.1.2 Teradataへのデータのロード

- 11.7.2 Teradataでのデータの統合

- 11.7.3 ETL形式マッピングの設計

- 11.8 Teradata用のKMの最適化

- 11.8.1 1次索引および統計

- 11.8.2 Teradataユーティリティのサポート

- 11.8.3 名前付きパイプのサポート

- 11.8.4 最適化された一時表管理

12 Hypersonic SQL

- 12.1 概要

- 12.1.1 概念

- 12.1.2 ナレッジ・モジュール

- 12.2 インストールおよび構成

- 12.2.1 システム要件および動作要件

- 12.2.2 テクノロジ固有の要件

- 12.2.3 接続性要件

- 12.3 トポロジの設定

- 12.3.1 Hypersonic SQLデータ・サーバーの作成

- 12.3.2 Hypersonic SQL物理スキーマの作成

- 12.4 統合プロジェクトの設定

- 12.5 Hypersonic SQLモデルの作成およびリバース・エンジニアリング

- 12.5.1 Hypersonic SQLモデルの作成

- 12.5.2 Hypersonic SQLモデルのリバース・エンジニアリング

- 12.6 データ品質の設定

- 12.7 マッピングの設計

13 IBM Informix

- 13.1 概要

- 13.2 概念

- 13.3 ナレッジ・モジュール

- 13.4 固有の要件

14 IBM DB2 for iSeries

- 14.1 概要

- 14.1.1 概念

- 14.1.2 ナレッジ・モジュール

- 14.2 インストールおよび構成

- 14.2.1 システム要件および動作要件

- 14.2.2 テクノロジ固有の要件

- 14.2.3 接続性要件

- 14.3 トポロジの設定

- 14.3.1 DB2/400データ・サーバーの作成

- 14.3.1.1 データ・サーバーの作成

- 14.3.2 DB2/400物理スキーマの作成

- 14.4 統合プロジェクトの設定

- 14.5 IBM DB2/400モデルの作成およびリバース・エンジニアリング

- 14.5.1 IBM DB2/400モデルの作成

- 14.5.2 IBM DB2/400モデルのリバース・エンジニアリング

- 14.6 チェンジ・データ・キャプチャの設定

- 14.6.1 トリガー・ベースCDCの設定

- 14.6.2 ログ・ベースCDCの設定

- 14.6.2.1 動作の仕組み

- 14.6.2.2 CDCRTVJRNプログラムの詳細

- 14.6.2.3 iSeriesへのCDCコンポーネントのインストール

- 14.6.2.4 ネイティブ・ジャーナルでのCDCの使用

- 14.6.2.5 ジャーナル読取り時の問題

- 14.7 データ品質の設定

- 14.8 マッピングの設計

- 14.8.1 IBM DB2 for iSeriesとの間でのデータのロード

- 14.8.1.1 IBM DB2 for iSeriesからのデータのロード

- 14.8.1.2 IBM DB2 for iSeriesへのデータのロード

- 14.8.2 IBM DB2 for iSeriesでのデータの統合

- 14.9DB2 for iSeries固有の考慮事項

- 14.9.1 iSeriesの代替接続方法

- 14.9.1.1 クライアント・アクセスの使用

- 14.9.1.2 IBM JT/400およびネイティブ・ドライバの使用

- 14.10 トラブルシューティング

- 14.10.1 エラー・メッセージのトラブルシューティング

- 14.10.2 一般的な問題および解決策

- 14.10.2.1 接続エラー

15 IBM DB2 UDB

- 15.1 概要

- 15.2 概念

- 15.3 ナレッジ・モジュール

- 15.4 固有の要件

第II部 Business Intelligence

16 Oracle Business Intelligence Enterprise Edition

- 16.1 概要

- 16.1.1 概念

- 16.1.2 ナレッジ・モジュール

- 16.2 インストールおよび構成

- 16.2.1 システム要件および動作要件

- 16.2.2 テクノロジ固有の要件

- 16.2.3 接続性要件

- 16.3 トポロジの設定

- 16.3.1 Oracle BIデータ・サーバーの作成

- 16.3.1.1 データ・サーバーの作成

- 16.3.2 Oracle BI物理スキーマの作成

- 16.4 統合プロジェクトの設定

- 16.5 Oracle BIモデルの作成およびリバース・エンジニアリング

- 16.5.1 Oracle BIモデルの作成

- 16.5.2 Oracle BIモデルのリバース・エンジニアリング

- 16.6 データ品質の設定

- 16.7 マッピングの設計

- 16.7.1 Oracle BIとの間でのデータのロード

- 16.7.1.1 Oracle BIからのデータのロード

- 16.7.1.2 Oracle BIへのデータのロード

- 16.7.2 Oracle BIでのデータの統合

17 Oracle Business Intelligence Enterprise Editionデータ系統

- 17.1 概要

- 17.1.1 コンポーネント

- 17.1.2 系統のライフサイクル

- 17.1.2.1 系統の設定

- 17.1.2.2 系統のリフレッシュ

- 17.1.2.3 系統の使用

- 17.2 OBIEEサーバーへの系統のインストール

- 17.2.1 インストールの概要

- 17.2.2 要件

- 17.2.3 インストール手順

- 17.2.3.1 OBIEE系統ウィザードのインストールと起動

- 17.2.3.2 ウィザードを使用したOBIEE系統アーティファクトのデプロイ

- 17.2.4 インストール後の作業

- 17.3 OBIEEからのメタデータのエクスポートとOBIEE系統のリフレッシュ

- 17.4 既存のエクスポートからのOBIEE系統のリフレッシュ

- 17.4.1 OBIEEリポジトリ・ドキュメントのテキスト・ファイルへのエクスポート

- 17.4.2 OBIEE Webカタログ・レポートのテキスト・ファイルへのエクスポート

- 17.4.3 既存のエクスポートからのOBIEE系統のリフレッシュ

- 17.5 系統タスクの自動化

- 17.5.1 スクリプトの構成

- 17.5.2 系統のデプロイメントの自動化

- 17.5.3 系統のリフレッシュの自動化

- 17.6 OBIEEダッシュボードでの系統の使用

- 17.6.1 実行統計の表示

- 17.6.2 系統データの表示とフィルタリング

- 17.6.3 ダッシュボードの使用

- 17.6.4 系統と階層の使用

- 17.6.5 コンテキスト系統の使用

18 Oracle Hyperion Planning

- 18.1 概要

- 18.1.1 統合プロセス

- 18.1.2 ナレッジ・モジュール

- 18.2 インストールおよび構成

- 18.2.1 システム要件および動作要件

- 18.2.2 テクノロジ固有の要件

- 18.2.3 接続性要件

- 18.3 Hyperion Planning Adapterの設定

- 18.3.1 ODI Studio向けのAdapterの設定

- 18.3.2 ODIスタンドアロン・エージェント向けのAdapterの設定

- 18.4 トポロジの設定

- 18.4.1 Hyperion Planningデータ・サーバーの作成

- 18.4.2 Hyperion Planning物理スキーマの作成

- 18.5 Planningモデルの作成およびリバース・エンジニアリング

- 18.5.1 Planningモデルの作成

- 18.5.2 Planningモデルのリバース・エンジニアリング

- 18.6 マッピングの設計

- 18.6.1 メタデータのロード

- 18.6.2 データのロード

- 18.6.3 ロード・オプション

- 18.7 データベース表およびデータ・ロード列

- 18.7.1 Accounts

- 18.7.2 Employee

- 18.7.3 Entities

- 18.7.4 ユーザー定義ディメンション

- 18.7.5 属性ディメンション

- 18.7.6 UDA

- 18.7.7 データ・ロード列

19 Oracle Hyperion Essbase

- 19.1 概要

- 19.1.1 統合プロセス

- 19.1.2 ナレッジ・モジュール

- 19.2 インストールおよび構成

- 19.2.1 システム要件および動作要件

- 19.2.2 テクノロジ固有の要件

- 19.2.3 接続性要件

- 19.3 Hyperion Essbase Adapterの設定

- 19.3.1 ODI Studio向けのAdapterの設定

- 19.3.2 ODIスタンドアロン・エージェント向けのAdapterの設定

- 19.4 トポロジの設定

- 19.4.1 Hyperion Essbaseデータ・サーバーの作成

- 19.4.2 Hyperion Essbase物理スキーマの作成

- 19.5 Essbaseモデルの作成およびリバース・エンジニアリング

- 19.5.1 Essbaseモデルの作成

- 19.5.2 Essbaseモデルのリバース・エンジニアリング

- 19.6 マッピングの設計

- 19.6.1 メタデータのロード

- 19.6.2 データのロード

- 19.6.3 データの抽出

- 19.6.3.1 Essbaseのデータ抽出方法

- 19.6.3.2 Essbaseデータの抽出

- 19.6.3.3 メタデータからのメンバーの抽出

第III部 その他のテクノロジ

20 JMS

- 20.1 概要

- 20.1.1 概念

- 20.1.1.1 JMSメッセージの構造

- 20.1.1.2 JMS宛先の使用

- 20.1.2 ナレッジ・モジュール

- 20.2 インストールおよび構成

- 20.2.1 システム要件および動作要件

- 20.2.2 テクノロジ固有の要件

- 20.2.3 接続性要件

- 20.3 トポロジの設定

- 20.3.1 JMSデータ・サーバーの作成

- 20.3.1.1 データ・サーバーの作成

- 20.3.2 JMS物理スキーマの作成

- 20.4 統合プロジェクトの設定

- 20.5 JMSモデルの作成および定義

- 20.5.1 JMSモデルの作成

- 20.5.2 JMSデータストアの定義

- 20.6 マッピングの設計

- 20.6.1 JMSソースからのデータのロード

- 20.6.2 JMSターゲットでのデータの統合

- 20.7 JMS標準プロパティ

- 20.7.1 JMSプロパティの使用

- 20.7.1.1 JMSプロパティの宣言

- 20.7.1.2 ルーター上でのフィルタリング

- 20.7.1.3 クライアント上でのフィルタリング

- 20.7.1.4 ソース・データとしてのプロパティ値の使用

- 20.7.1.5 メッセージ送信時のプロパティの設定

21 JMS XML

- 21.1 概要

- 21.1.1 概念

- 21.1.1.1 JMSメッセージの構造

- 21.1.1.2 JMS宛先の使用

- 21.1.2 ナレッジ・モジュール

- 21.2 インストールおよび構成

- 21.2.1 システム要件および動作要件

- 21.2.2 テクノロジ固有の要件

- 21.2.3 接続性要件

- 21.3 トポロジの設定

- 21.3.1 JMS XMLデータ・サーバーの作成

- 21.3.1.1 データ・サーバーの作成

- 21.3.2 JMS XML物理スキーマの作成

- 21.4 統合プロジェクトの設定

- 21.5 JMS XMLモデルの作成およびリバース・エンジニアリング

- 21.5.1 JMS XMLモデルの作成

- 21.5.2 JMS XMLモデルのリバース・エンジニアリング

- 21.6 マッピングの設計

- 21.6.1 JMS XMLソースからのデータのロード

- 21.6.2 JMS XMLターゲットでのデータの統合

22 LDAPディレクトリ

- 22.1 概要

- 22.1.1 概念

- 22.1.2 ナレッジ・モジュール

- 22.2 インストールおよび構成

- 22.2.1 システムの要件

- 22.2.2 テクノロジ固有の要件

- 22.2.3 接続性要件

- 22.3 トポロジの設定

- 22.3.1 LDAPデータ・サーバーの作成

- 22.3.1.1 データ・サーバーの作成

- 22.3.2 LDAP用物理スキーマの作成

- 22.4 統合プロジェクトの設定

- 22.5 LDAPディレクトリの作成およびリバース・エンジニアリング

- 22.5.1 LDAPモデルの作成

- 22.5.2 LDAPモデルのリバース・エンジニアリング

- 22.6 マッピングの設計

- 22.6.1 LDAPとの間でのデータのロード

- 22.6.1.1 LDAPディレクトリからのデータのロード

- 22.6.1.2 LDAPディレクトリへのデータのロード

- 22.6.2 LDAPディレクトリでのデータの統合

- 22.7 トラブルシューティング

23 Oracle TimesTen In-Memory Database

- 23.1 概要

- 23.1.1 概念

- 23.1.2 ナレッジ・モジュール

- 23.2 インストールおよび構成

- 23.2.1 システム要件および動作要件

- 23.2.2 テクノロジ固有の要件

- 23.2.3 接続性要件

- 23.3 トポロジの設定

- 23.3.1 TimesTenデータ・サーバーの作成

- 23.3.1.1 データ・サーバーの作成

- 23.3.2 TimesTen物理スキーマの作成

- 23.4 統合プロジェクトの設定

- 23.5 TimesTenモデルの作成およびリバース・エンジニアリング

- 23.5.1 TimesTenモデルの作成

- 23.5.2 TimesTenモデルのリバース・エンジニアリング

- 23.6 データ品質の設定

- 23.7 マッピングの設計

- 23.7.1 TimesTenとの間でのデータのロード

- 23.7.1.1 TimesTenからのデータのロード

- 23.7.1.2 TimesTenへのデータのロード

- 23.7.2 TimesTenへのデータの統合

24 Oracle GoldenGate

- 24.1 概要

- 24.1.1 GoldeGate CDCプロセスの概要

- 24.1.2 ナレッジ・モジュール

- 24.2 インストールおよび構成

- 24.2.1 システム要件および動作要件

- 24.2.2 テクノロジ固有の要件

- 24.2.3 接続性要件

- 24.3 Oracle GoldenGate JKMの使用

- 24.3.1 トポロジの定義

- 24.3.1.1 ソース・データ・サーバーの定義

- 24.3.1.2 ソース物理スキーマの作成

- 24.3.1.3 ステージング・サーバーの定義

- 24.3.1.4 ステージング物理スキーマの作成

- 24.3.1.5 Oracle GoldenGateデータ・サーバーの定義

- 24.3.1.6 Oracle GoldenGate物理スキーマの作成

- 24.3.1.7 Oracle GoldenGate論理スキーマの作成

- 24.3.2 レプリケートされた表の作成

- 24.3.3 統合プロジェクトの設定

- 24.3.4 ソース・データストアのCDCの構成

- 24.3.4.1 モデルからのOracle GoldenGate物理スキーマの作成

- 24.3.5 Oracle GoldenGateプロセスの構成および開始(オフライン・モードのみ)

- 24.3.6 レプリケートされたデータを使用したマッピングの設計

- 24.4 拡張構成

- 24.4.1 初期ロードの方法

- 24.4.2 レプリケーション・パフォーマンスのチューニング

- 24.4.3 1つのソースと複数のステージングの構成(オフライン・モードのみ)

- 24.5 統合キャプチャ

- 24.5.1 統合キャプチャのデプロイメント・オプション

- 24.5.2 使用する適用方法の決定

- 24.5.2.1 非統合Replicat

- 24.6 異なるキャプチャおよび適用モードの併用

- 24.7 異なるプロセス・モードへの切替え

- 24.8 クラシック・モードから統合モードへのGoldenGate Extractのアップグレード

25 Oracle SOA Suite相互参照

- 25.1 概要

- 25.1.1 概念

- 25.1.1.1 一般原理

- 25.1.1.2 相互参照表の構造

- 25.1.1.3 相互参照表の構造の処理

- 25.1.2 ナレッジ・モジュール

- 25.1.3 SOA XREF KMプロセスの概要

- 25.1.3.1 ロード・フェーズ(LKM)

- 25.1.3.2 統合および相互参照フェーズ(IKM)

- 25.1.3.3 処理済レコードの更新/削除(LKM)

- 25.2 インストールおよび構成

- 25.2.1 システム要件および動作要件

- 25.2.2 テクノロジ固有の要件

- 25.2.3 接続性要件

- 25.3 SOA相互参照KMを使用したXREFの利用

- 25.3.1 トポロジの定義

- 25.3.2 プロジェクトの設定

- 25.3.3 相互参照KMを使用したマッピングの設計

- 25.4 ナレッジ・モジュール・オプションの参照情報

第IV部 付録

A Oracle Data Integrator Driver for LDAPの参照情報

- A.1 Oracle Data Integrator Driver for LDAPの概要

- A.2 LDAPの処理の概要

- A.2.1 LDAPからリレーショナルへのマッピング

- A.2.1.1 一般原理

- A.2.1.2 グループ化係数

- A.2.1.3 マッピング例外

- A.2.1.4 参照LDAPツリー

- A.2.2 リレーショナル・スキーマの管理

- A.2.2.1 リレーショナル・スキーマの格納

- A.2.2.2 リレーショナル構造内のデータへのアクセス

- A.3 インストールおよび構成

- A.3.1 ドライバの構成

- A.3.2 外部データベースを使用したデータの格納

- A.3.2.1 ドライバURLでのプロパティの受渡し

- A.3.2.2 ODI Studioでのプロパティの設定

- A.3.2.3 プロパティ・ファイルでのプロパティの設定

- A.3.3 LDAPディレクトリの接続構成

- A.3.4 表の別名の構成

- A.4 SQL構文

- A.4.1 SQL文

- A.4.1.1 DISCONNECT

- A.4.1.2 INSERT INTO

- A.4.1.3 SELECT

- A.4.1.4 UPDATE

- A.4.1.5 式、条件および値

- A.4.2 SQLファンクション

- A.5 実装されるJDBC API機能

B Oracle Data Integrator Driver for XMLの参照情報

- B.1 Oracle Data Integrator Driver for XMLの概要

- B.2 XMLの処理の概要

- B.2.1 XMLからSQLへのマッピング

- B.2.2 XML名前空間

- B.2.3 スキーマの管理

- B.2.3.1 スキーマの格納

- B.2.3.2 複数のスキーマ

- B.2.3.3 スキーマ内のデータへのアクセス

- B.2.3.4 大/小文字の区別

- B.2.3.5 ロード/同期化

- B.2.4 ロック

- B.2.5 XMLスキーマ(XSD)のサポート

- B.3 インストールおよび構成

- B.3.1 ドライバの構成

- B.3.2 複数のスキーマの自動作成

- B.3.3 外部データベースを使用したデータの格納

- B.4 ドライバ・コマンドの詳細

- B.4.1 CREATE FILE

- B.4.2 CREATE FOREIGNKEYS

- B.4.3 CREATE XMLFILE

- B.4.4 CREATE SCHEMA

- B.4.5 DROP FOREIGNKEYS

- B.4.6 DROP SCHEMA

- B.4.7 LOAD FILE

- B.4.8 SET SCHEMA

- B.4.9 SYNCHRONIZE

- B.4.10 UNLOCK FILE

- B.4.11 TRUNCATE SCHEMA

- B.4.12 VALIDATE

- B.4.13 WRITE MAPPING FILE

- B.5 SQL構文

- B.5.1 SQL文

- B.5.1.1 COMMIT

- B.5.1.2 CREATE TABLE

- B.5.1.3 DELETE

- B.5.1.4 DISCONNECT

- B.5.1.5 DROP TABLE

- B.5.1.6 INSERT INTO

- B.5.1.7 ROLLBACK

- B.5.1.8 SELECT

- B.5.1.9 SET AUTOCOMMIT

- B.5.1.10 UPDATE

- B.5.1.11 式、条件および値

- B.5.2 SQLファンクション

- B.6 実装されるJDBC API機能

- B.7 リッチ・メタデータ

- B.7.1 様々なデータベースに対してサポートされているユーザー指定型

- B.8 サポートされているXMLスキーマの機能

- B.8.1 データ型

- B.8.2 サポートされている要素

- B.8.2.1 all

- B.8.2.2 any

- B.8.2.3 anyAttribute

- B.8.2.4 anyType

- B.8.2.5 attribute

- B.8.2.6 attributeGroup

- B.8.2.7 choice

- B.8.2.8 complexContent

- B.8.2.9 complexType

- B.8.2.10 element

- B.8.2.11 extension

- B.8.2.12 group

- B.8.2.13 import

- B.8.2.14 include

- B.8.2.15 list

- B.8.2.16 restriction

- B.8.2.17 schema

- B.8.2.18 sequence

- B.8.2.19 simpleContent

- B.8.2.20 simpleType

- B.8.3 サポートされていない機能

- B.8.3.1 サポートされていない要素

- B.8.3.2 サポートされていない機能

- B.8.3.3 サポートされていないデータ型

C Oracle Data Integrator Driver for Complex Filesの参照情報

- C.1 Oracle Data Integrator Driver for Complex Filesの概要

- C.2 複合ファイルの処理の概要

- C.2.1 ネイティブ・スキーマの生成

- C.2.2 XMLからSQLへのマッピング

- C.2.3 JSONのサポート

- C.2.4 サポートされている機能

- C.3 ドライバの構成

- C.4 ドライバ・コマンドの詳細

- C.5 サポートされているJDBC APIおよびXMLスキーマの機能

D XMLおよび複合ファイル・ドライバの事前/事後処理サポート

- D.1 概要

- D.2 処理ステージの構成

- D.3 処理ステージの実装

- D.4 例: ZIPファイル内からXMLデータを読み取るためのGroovyスクリプト

- D.5 例: XMLデータを変換して異なる形式に書き込むためのGroovyスクリプト

- D.6 例: 認証を必要とするHTTPソースからデータを読み取るためのJavaクラス

- D.7 例: 構成XMLファイルに組み込まれたGroovyコード

はじめに

このドキュメントでは、Oracle Data Integratorで様々なテクノロジを操作する方法について説明します。

この章の内容は次のとおりです。

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

対象読者

このドキュメントは、Oracle Data Integratorのナレッジ・モジュールを使用して統合プロセスを行う開発者を対象としています。

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoまたはhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs (聴覚障害者向け)を参照してください。

関連ドキュメント

詳細は、Oracle Data Integratorライブラリの次のドキュメントを参照してください。

- Oracle Data Integratorリリース・ノート

- Oracle Data Integratorの理解

- Oracle Data Integratorの管理

- 『Oracle Data Integratorでの統合プロジェクトの開発』

- Oracle Data Integratorのインストールと構成

- Oracle Data Integratorのアップグレード

- Oracle Data Integratorアプリケーション・アダプタ・ガイド

- 『Oracle Data Integratorでのナレッジ・モジュールの開発』

- Oracle Warehouse BuilderからOracle Data Integratorへの移行

- Oracle Data Integratorツール・リファレンス

- Oracle Data Integratorデータ・サービスJava APIリファレンス

- Oracle Data Integratorオープン・ツールJava APIリファレンス

- Oracle Data IntegratorのためのSAP ABAP BWアダプタ・スタート・ガイド

- Oracle Data Integrator Java APIリファレンス

- Oracle Data IntegratorのためのSAP ABAP ERPアダプタ・スタート・ガイド

- Oracle Data Integrator 12cオンライン・ヘルプ([F1]を押すか、「ヘルプ」を選択してから、「検索」または「目次」を選択してメイン・メニューからJDeveloperヘルプ・センターを開いて、ODI Studioで入手可能)

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要

このドキュメントでは、Oracle Data Integratorで様々なテクノロジを操作する方法について説明します。

このブックには、次の部が含まれています。

- 第I部「データベース、ファイルおよびXML」

- 第I部「Business Intelligence」

- 第I部「その他のテクノロジ」

アプリケーション・アダプタの説明は別のガイドに含まれています。詳細は、『Oracle Data Integratorアプリケーション・アダプタ・ガイド』を参照してください。

この章では、Oracle Data Integratorのドキュメントで使用される用語の概要を提供し、Oracle Data Integratorのナレッジ・モジュールの基本的な使用手順を説明します。

この章には次の項が含まれます:

- 1.1項「用語」

- 1.2項「このガイドの使用方法」

1.1 用語

この項では、このドキュメントおよび「はじめに」に記載されている関連ドキュメントで使用されている共通用語の一部を定義します。

ナレッジ・モジュール

ナレッジ・モジュール(KM)は、Oracle Data Integratorのコンポーネントであり、特定のテクノロジに対して具体的なアクションを実行するためのコードの生成に使用されます。

JDBC、JMSまたはJCAなどの接続性レイヤーとナレッジ・モジュールを組み合せることで、テクノロジに対して定義済タスクを実行できます。たとえば、テクノロジへの接続、テクノロジからのデータの抽出、抽出したデータの変換、変換したデータのチェック、チェックしたデータの統合などです。

アプリケーション・アダプタ

Oracle Application Adapters for Data Integrationには、エンタープライズ・アプリケーションのデータを統合するための、固有のソフトウェア・コンポーネントが用意されています。Oracle Data Integratorでサポートされているエンタープライズ・アプリケーションには、Oracle E-Business Suite、Siebel、SAPなどがあります。

アダプタはナレッジ・モジュールのグループです。このグループには、添付されたOracle Data Integrator用テクノロジ定義も含まれる場合があります。

アプリケーション・アダプタの説明は別のガイドに含まれています。詳細は、『Oracle Data Integratorアプリケーション・アダプタ・ガイド』を参照してください。

1.2 このガイドの使用方法

このガイドでは、Oracle Data Integratorでサポートされているナレッジ・モジュールおよびテクノロジでの作業に関する概念情報および手順を提供します。

章ごとに、各テクノロジの構成方法、プロジェクトの設定方法、および統合操作を実行するためのテクノロジ固有のナレッジ・モジュールの使用方法について説明します。

一部のナレッジ・モジュールはテクノロジ固有のものではなく、業界標準をサポートしているテクノロジが必要になります。このようなナレッジ・モジュールは、汎用ナレッジ・モジュールと呼ばれます。たとえば、第4章「汎用SQL」および第20章「JMS」にリストされているナレッジ・モジュールは、それぞれ任意のANSI SQL-92準拠データベースおよび任意のJMS準拠メッセージ・プロバイダで動作するように設計されています。

これらの汎用ナレッジ・モジュールをどのような状況でテクノロジと併用できるかについては、テクノロジの章で説明します。ただし、パフォーマンスを向上させ、テクノロジ固有の機能の適用範囲を拡大するために、テクノロジ固有のナレッジ・モジュールを使用することをお薦めします。

ナレッジ・モジュールを使用する前に、Oracle Data Integrator Studioに含まれるナレッジ・モジュールの説明で、使用に関する詳細、制限事項および要件を確認することをお薦めします。また、ナレッジ・モジュールのオプションは、あらかじめデフォルト値で構成されているためすぐに使用できますが、これらのオプションおよびその説明についても確認しておくことをお薦めします。

このガイドの各章では、テクノロジおよびナレッジ・モジュールに付随する使用方法、オプション、制限事項および要件に関する重要な情報を提供します。

第I部

データベース、ファイルおよびXML

この部では、Oracle Data Integratorでのデータベース、ファイルおよびXMLファイルの使用方法について説明します。

第I部の内容は次のとおりです。

- 第2章「Oracle Database」

- 第3章「ファイル」

- 第4章「汎用SQL」

- 第5章「XMLファイル」

- 第6章「複合ファイル」

- 第7章「Microsoft SQL Server」

- 第8章「Microsoft Excel」

- 第9章「Microsoft Access」

- 第10章「Netezza」

- 第11章「Teradata」

- 第12章「Hypersonic SQL」

- 第13章「IBM Informix」

- 第14章「IBM DB2 for iSeries」

- 第15章「IBM DB2 UDB」

2 Oracle Database

この章では、Oracle Data IntegratorでのOracle Databaseの使用方法について説明します。

この章には次の項が含まれます:

- 2.1項「概要」

- 2.2項「インストールおよび構成」

- 2.4項「統合プロジェクトの設定」

- 2.5項「Oracleモデルの作成およびリバース・エンジニアリング」

- 2.6項「チェンジ・データ・キャプチャの設定」

- 2.7項「データ品質の設定」

- 2.8項「マッピングの設計」

- 2.9項「トラブルシューティング」

2.1 概要

Oracle Data Integrator (ODI)では、Oracle Databaseのデータがシームレスに統合されます。Oracle Data Integratorのすべての機能(リバース・エンジニアリング、チェンジ・データ・キャプチャ、データ品質およびマッピングなど)は、Oracle Databaseエンジンを使用した場合に最良の動作が得られるように設計されています。

2.1.1 概念

Oracle Databaseの概念は、Oracle Data Integratorの概念に次のようにマップされます。1つのOracleインスタンスはOracle Data Integratorの1つのデータ・サーバーに対応します。このインスタンス内で、1つのスキーマはOracle Data Integratorの1つの物理スキーマにマップされます。1つのスキーマ内の関連する一連のオブジェクトが1つのデータ・モデルに対応し、各表、ビューまたはシノニムが、その属性、列および制約とともにODIデータストアとして表示されます。

Oracle Data Integratorでは、Java Database Connectivity (JDBC)を使用してOracleデータベース・インスタンスに接続します。

2.1.2 ナレッジ・モジュール

Oracle Data Integratorには、Oracleデータを処理するためのナレッジ・モジュール(KM)が用意されています。これらのリストを表2-1に示します。KMでは、Oracle固有の機能が使用されます。Oracle Databaseでは、汎用SQL KMを使用することもできます。詳細は、第4章「汎用SQL」を参照してください。

表2-1 Oracle KM

ナレッジ・モジュール

説明

RKM Oracle

表、ビュー、列、主キー、一意でない索引および外部キーをリバース・エンジニアリングします。

JKM Oracle 11g Consistent (Streams)

Oracle Streamsを使用して、Oracle 11g表の一貫性セット・ジャーナル化を行うためのジャーナル化インフラストラクチャを作成します。

このKMは推奨されていません。

JKM Oracle Consistent

トリガーを使用してOracle表の一貫性セット・ジャーナル化を行うためのジャーナル化インフラストラクチャを作成します。

JKM Oracle Consistent (Update Date)

ソース表の「最終更新日」列に基づくトリガーを使用してOracle表の一貫性セット・ジャーナル化を行うためのジャーナル化インフラストラクチャを作成します。

JKM Oracle Simple

トリガーを使用してOracle表の単純なジャーナル化を行うためのジャーナル化インフラストラクチャを作成します。

JKM Oracle to Oracle Consistent (OGG Online)

CDCにOracle GoldenGateを使用する場合に、ODI CDCフレームワーク・インフラストラクチャを作成および管理します。詳細は、第24章「Oracle GoldenGate」を参照してください。

CKM Oracle

Oracle表で定義された制約と照合して、データの整合性をチェックします。

LKM File to Oracle (EXTERNAL TABLE)

EXTERNAL TABLE SQLコマンドを使用して、ファイルからOracleステージング領域へデータをロードします。

LKM File to Oracle (SQLLDR)

SQL*Loaderコマンド行ユーティリティを使用して、ファイルからOracleステージング領域へデータをロードします。

LKM MSSQL to Oracle (BCP SQLLDR)

BCPおよびSQL*Loaderユーティリティを使用して、Microsoft SQL ServerからOracleデータベース(ステージング領域)へデータをロードします。

LKM Oracle BI to Oracle (DBLINK)

データベース・リンクを使用して、任意のOracle BI物理レイヤーからOracleターゲット・データベースへデータをロードします。詳細は、第16章「Oracle Business Intelligence Enterprise Edition」を参照してください。

LKM Oracle to Oracle (DBLINK)

データベース・リンクを使用して、Oracleソース・データベースからOracleステージング領域データベースへデータをロードします。

LKM Oracle to Oracle Pull (DB Link)

データベース・リンクを使用して、Oracleソース・データベースからOracleステージング領域データベースへデータをロードします。ソース・データベースにビューを作成しません。また、ステージング・データベースにシノニムも作成しません。組込みKMです。

LKM Oracle to Oracle Push (DB Link)

データベース・リンクを使用してOracleターゲット表にデータをロードして統合します。ステージング・データベースにシノニムを作成しません。IKMの設定は無視されます。組込みKMです。

LKM Oracle to Oracle (datapump)

データポンプ形式の外部表を使用して、Oracleソース・データベースからOracleステージング領域データベースへデータをロードします。

LKM SQL to Oracle

任意のANSI SQL-92ソース・データベースからOracleステージング領域へデータをロードします。

LKM SAP BW to Oracle (SQLLDR)

SQL*Loaderユーティリティを使用して、SAP BWシステムからOracleステージングへデータをロードします。詳細は、『Oracle Data Integratorアプリケーション・アダプタ・ガイド』を参照してください。

LKM SAP ERP to Oracle (SQLLDR)

SQL*Loaderユーティリティを使用して、SAP ERPシステムからOracleステージングへデータをロードします。詳細は、『Oracle Data Integratorアプリケーション・アダプタ・ガイド』を参照してください。

IKM Oracle Incremental Update

増分更新モードでOracleのターゲット表にデータを統合します。フロー制御をサポートします。

IKM Oracle Incremental Update (MERGE)

MERGE文を使用して、増分更新モードでOracleのターゲット表にデータを統合します。フロー制御をサポートします。

IKM Oracle Incremental Update (PL SQL)

PL/SQLを使用して、増分更新モードでOracleのターゲット表にデータを統合します。フロー制御をサポートします。

IKM Oracle Insert

追加モードでOracleターゲット表にデータを統合します。単一のINSERT SQL文で、ターゲット表にデータが直接ロードされます。組込みKMです。

IKM Oracle Update

増分更新モードでOracleのターゲット表にデータを統合します。単一のUPDATE SQL文で、ターゲット表にデータが直接ロードされます。組込みKMです。

IKM Oracle Merge

増分更新モードでOracleのターゲット表にデータを統合します。単一のMERGE SQL文で、ターゲット表にデータが直接ロードされます。組込みKMです。

IKM Oracle Multi-Insert

複数表挿入文(MTI)を使用して、1つのソースのデータを1つ以上のOracleターゲット表に追加モードで統合します。このIKMを単一のマッピングで利用して、複数のターゲットをロードできます。組込みKMです。

IKM Oracle Multi Table Insert

複数表挿入文(MTI)を使用して、1つのソースのデータを1つ以上のOracleターゲット表に追加モードで統合します。フロー制御をサポートします。

IKM Oracle Slowly Changing Dimension

タイプ2の緩やかに変化するディメンションとして使用されるOracleのターゲット表に、データを統合します。フロー制御をサポートします。

IKM Oracle Spatial Incremental Update

MERGE DML文を使用して、増分更新モードでOracle (9i以上)のターゲット表にデータを統合します。このモジュールではSDO_GEOMETRYデータ型がサポートされます。フロー制御をサポートします。

IKM Oracle to Oracle Control Append (DBLINK)

制御追加モードで、1つのOracleインスタンスから別のOracleインスタンスのOracleターゲット表にデータを統合します。フロー制御をサポートします。

通常、このIKMはETL構成に使用されます。この構成では、ソース表とターゲット表は異なるOracleインスタンスにあり、マッピングのステージング領域は、ソース表の論理スキーマまたは第3のスキーマに設定されます。

SKM Oracle

Oracleデータベースのデータ・アクセスWebサービスを生成します。このSKMの使用方法の詳細は、『Oracle Data Integratorの管理』のデータ・サービスの生成およびデプロイに関する項を参照してください。

2.2 インストールおよび構成

Oracleナレッジ・モジュールの使用を開始する前に、この項の情報を必ず読んでください。

- システム要件および動作要件

- テクノロジ固有の要件

- 接続性要件

2.2.1 システム要件および動作要件

インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。

サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。

http://www.oracle.com/technology/products/oracle-data-integrator/index.html

2.2.2 テクノロジ固有の要件

Oracle用の一部のナレッジ・モジュールでは、このデータベース固有の機能が使用されます。この項では、これらの機能に関連する要件をリストします。

2.2.2.1 SQL*Loaderユーティリティの使用

この項では、OracleデータベースでSQL*Loaderユーティリティを使用する前に満たしておく必要がある要件を説明します。

- Oracle Data Integratorのエージェントを実行するマシンに、OracleクライアントおよびSQL*Loaderユーティリティがインストールされている必要があります。

- トポロジで定義されるサーバー名は、Oracleインスタンスへのアクセスに使用されるOracle TNS名と一致する必要があります。

- 特定のログ・ファイルがSQL*Loaderによって作成されます。エラーが発生した場合は、このファイルを参照することをお薦めします。制御ファイル(CTL)、ログ・ファイル(LOG)、廃棄ファイル(DSC)および不良ファイル(BAD)は、ソース・ファイルの物理スキーマで定義された作業ディレクトリにあります。

- ダイレクト・モードを使用するには、Oracle Data integratorのエージェントをターゲットのOracleサーバー・マシン上で実行する必要があります。ソース・ファイルもそのマシン上にあることが必要です。

2.2.2.2 外部表の使用

この項では、Oracleデータベースで外部表を使用する前に満たしておく必要がある要件を説明します。

- External Tableコマンドでロードするファイルは、Oracleインスタンスからアクセスできることが必要です。このファイルをサーバー・マシンのファイル・システム上に置くか、Unique Naming Conventionパス(UNCパス)からアクセス可能にするか、もしくはローカルで格納する必要があります。

- パフォーマンスの点から、ターゲット・サーバー・マシン上にOracle Data Integratorエージェントをインストールすることをお薦めします。

2.2.2.3 Oracle Streamsの使用

この項では、Oracle Streamsのジャーナル化ナレッジ・モジュールを使用するための要件を説明します。

注意:
最初に、Oracle Streamsの要件の包括的なリストが含まれている、『Oracle Databaseデータ・ウェアハウス・ガイド』のチェンジ・データ・キャプチャに関する項を参照することをお薦めします。

Oracle Streamsを使用してチェンジ・データ・キャプチャを設定する前に、次の要件を満たしておく必要があります。

- Oracle StreamsがOracle Databaseにインストールされている必要があります。

- OracleデータベースがSPFILEを使用して稼働する必要があります(AUTO_CONFIGURATIONオプションのみで必須)。

- AQ_TM_PROCESSESオプションをデフォルト値のままにしておくか、0および10以外の値に設定する必要があります。

- COMPATIBLEオプションを10.1以上に設定する必要があります。

- データベースがARCHIVELOGモードで稼働する必要があります。

- 適用およびキャプチャのプロセス数を考慮するために、PARALLEL_MAX_SERVERSを増やす必要があります。少なくとも、スタンドアロン構成の場合は6、低アクティビティの場合は9、高アクティビティの場合は21増やす必要があります。

- UNDO_RETENTIONを最低3600に設定する必要があります。

- STREAMS_POOL_SIZEを増やす必要があります。スタンドアロン構成の場合は100MB、低アクティビティの場合は236MB、高アクティビティの場合は548MB増やしてください。

- ODIモデルで定義された主キーのすべての列が、SUPPLEMENTAL LOG GROUPに含まれている必要があります。

- AUTO_CONFIGURATIONナレッジ・モジュール・オプションを使用する際に、上のすべての要件が自動的にチェックおよび設定されますが、一部のアクションは手動で設定する必要があります。詳細は、「Streams JKMの使用」を参照してください。
AUTO_CONFIGURATIONナレッジ・モジュール・オプションを使用せずにこのKMを実行するには、次のシステム権限が付与されている必要があります。

- 接続ユーザーに対するDBAロール

- 接続ユーザーに対するStreams管理者

- 作業スキーマに対するRESOURCEロール

- 作業スキーマに対するSELECT ANY TABLE

- 非同期モードでは、ジャーナル化されたシステムで最高のパフォーマンスが得られますが、追加のOracle Database初期化構成および追加の構成用権限が必要です。

- 非同期モードでは、ジャーナル化されたデータベースがARCHIVELOGに含まれている必要があります。このオプションをオンにする前に、まず、非同期AutoLog公開の概念を理解しておく必要があります。ARCHIVELOGモードでのデータベースの実行の詳細は、『Oracle Database管理者ガイド』を参照してください。サプリメンタル・ロギングの詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』の非同期チェンジ・データ・キャプチャに関する項を参照してください。これは、アーカイブを正しく管理し、アーカイブ・ファイルがアーカイブ・リポジトリから定期的に削除されていない場合にOracleインスタンスが停止するなどの一般的な問題を回避するのに役立ちます。

- 非同期モードを使用する場合は、インスタンスに接続するユーザーに、Oracle Streamsの管理認可を付与する必要があります。これは、この権限をすでに持っているユーザー(SYSTEMユーザーなど)としてログインしているときに、DMBS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGEプロシージャを使用して実行できます。

- 作業スキーマには、他のスキーマに格納されている表を参照するビューを作成できるように、SELECT ANY TABLE権限を付与する必要があります。

その他のすべての前提条件に関する詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』の「チェンジ・データ・キャプチャ」を参照してください。

2.2.3 接続性要件

この項では、Oracle Databaseに接続するための要件をリストします。

JDBCドライバ

Oracle Data Integratorは、Oracle Type 4 JDBCドライバのデフォルト・バージョンとともにインストールされます。このドライバではTCP/IPネットワーク・レイヤーが直接使用され、他のコンポーネントのインストールや構成は不要です。

Oracle JDBC OCIドライバを介して、またはODBCでもOracle Serverに接続できます。パフォーマンスの点から、Type 4ドライバの使用をお薦めします。

接続情報

Oracle DBAから次の情報を入手する必要があります。

- Oracle Databaseをホストするマシンのネットワーク名またはIPアドレス。

- Oracleリスナーのリスニング・ポート。

- Oracleインスタンス(SID)の名前。

- 接続先インスタンスのTNS別名。

- Oracleユーザーのログインおよびパスワード。

2.3 トポロジの設定

トポロジの設定には次が含まれます。

1. Oracleデータ・サーバーの作成

2. Oracle物理スキーマの作成

2.3.1 Oracleデータ・サーバーの作成

1つのOracleデータ・サーバーは、特定のOracleユーザー・アカウントに接続された1つのOracle Databaseインスタンスに対応します。このユーザーは、データ・サーバーの下に作成されたOracle Data Integratorの物理スキーマに対応する、このインスタンスの複数のスキーマにアクセスできます。

2.3.1.1 データ・サーバーの作成

『Oracle Data Integratorでの統合プロジェクトの開発』のデータ・サーバーの作成に関する項の説明に従って、標準の手順を使用してOracleテクノロジ用のデータ・サーバーを作成します。この項では、Oracleデータ・サーバーの定義に関する必須または固有のフィールドのみについて説明します。

1. 「定義」タブ:

- 名前: Oracle Data Integratorに表示されるデータ・サーバーの名前。

- Instance/dblink: このOracleインスタンスに使用されるTNS別名。データベース・リンクおよびSQL*Loaderの使用時に、Oracleインスタンスを識別するために使用されます。

- ユーザー/パスワード: ソース・スキーマでの選択権限、ターゲット・スキーマでの選択および挿入の権限、およびこのデータ・サーバーの下に作成されたOracle物理スキーマ内に示される作業スキーマでの選択、挿入およびオブジェクト作成の権限を持つOracleユーザー(およびユーザーのパスワード)。

2. 「JDBC」タブ:

- JDBCドライバ: oracle.jdbc.OracleDriver

- JDBC URL: jdbc:oracle:thin:@<network name or ip address of the Oracle machine>:<port of the Oracle listener (1521)>:<name of the Oracle instance>
Oracle JDBC Thinドライバを使用してOracle RACインスタンスに接続するには、次の例のようにOracle RACデータベースのURLを使用します。

jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=host1) (PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=host2) (PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=service)))

2.3.2 Oracle物理スキーマの作成

『Oracle Data Integratorの管理』の物理スキーマの作成に関する項の説明に従って、標準の手順を使用してOracle物理スキーマを作成します。

『Oracle Data Integratorの管理』の論理スキーマの作成に関する項の説明に従って、標準の手順を使用してこの物理スキーマ用の論理スキーマを作成し、特定のコンテキストで関連付けます。

2.4 統合プロジェクトの設定

Oracle Databaseを使用してプロジェクトを設定するには、標準の手順に従います。『Oracle Data Integratorでの統合プロジェクトの開発』の統合プロジェクトの作成に関する項を参照してください。

Oracle Databaseでの作業を開始するにあたり、使用するプロジェクトに次のナレッジ・モジュールをインポートすることをお薦めします。

- RKM Oracle

- CKM Oracle

- LKM SQL to Oracle

- LKM File to Oracle (SQLLDR)

- LKM File to Oracle (EXTERNAL TABLE)

- IKM Oracle Incremental Update

2.5 Oracleモデルの作成およびリバース・エンジニアリング

この項には次のトピックが含まれます:

- Oracleモデルの作成

- Oracleモデルのリバース・エンジニアリング

2.5.1 Oracleモデルの作成

『Oracle Data Integratorでの統合プロジェクトの開発』のモデルの作成に関する項の説明に従って、標準の手順を使用してOracleモデルを作成します。

2.5.2 Oracleモデルのリバース・エンジニアリング

Oracleでは、JDBCドライバの機能のみを使用する標準のリバース・エンジニアリング、およびRKMを使用してOracleディクショナリからオブジェクトの構造を直接取得する、カスタマイズされたリバース・エンジニアリングの両方がサポートされています。

通常は、標準のJDBCリバース・エンジニアリングを使用して作業を開始することを検討してください。Oracleで標準のリバース・エンジニアリングを使用すると、表、ビュー、列、主キーおよび参照が取得されます。

それ以外のメタデータを取得する場合に、カスタマイズされたリバース・エンジニアリングに切り替えることを検討してください。Oracleのカスタマイズされたリバース・エンジニアリングでは、表およびビューの構造(列、主キー、代替キー、索引、チェック制約、シノニムおよび参照)が取得されます。

標準のリバース・エンジニアリング

Oracleで標準のリバースエンジニアリングを実行するには、『Oracle Data Integratorでの統合プロジェクトの開発』のモデルのリバースエンジニアリングに関する項の説明に従って、通常の手順を使用します。

カスタマイズされたリバース・エンジニアリング

RKMを使用してOracleでカスタマイズされたリバースエンジニアリングを実行するには、『Oracle Data Integratorでの統合プロジェクトの開発』のモデルのリバースエンジニアリングに関する項の説明に従って、通常の手順を使用します。この項では、Oracleテクノロジ固有のフィールドのみについて説明します。

Oracleモデルの「リバース・エンジニアリング」タブでKM: RKM Oracle.<project name>を選択します。

2.6 チェンジ・データ・キャプチャの設定

ODI Oracleナレッジ・モジュールでは、チェンジ・データ・キャプチャ機能がサポートされています。ジャーナル化の設定方法およびキャプチャされた変更の使用方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』の「チェンジ・データ・キャプチャの使用」を参照してください。

Oracleジャーナル化ナレッジ・モジュールでは、単純ジャーナル化および一貫性セット・ジャーナル化がサポートされています。Oracle JKMでは、トリガーまたはOracle Streamsを使用して、ソース表でのデータ変更をキャプチャします。

Oracle Data Integratorには、Oracle表をジャーナル化するためのナレッジ・モジュールが用意されています。これらのリストを表2-2に示します。

表2-2 Oracleジャーナル化ナレッジ・モジュール

KM

説明

JKM Oracle 11g Consistent (Streams)

Oracle Streamsを使用して、Oracle 11g表の一貫性セット・ジャーナル化を行うためのジャーナル化インフラストラクチャを作成します。

JKM Oracle Consistent

トリガーを使用してOracle表の一貫性セット・ジャーナル化を行うためのジャーナル化インフラストラクチャを作成します。

JKM Oracle Consistent (Update Date)

ソース表の「最終更新日」列に基づくトリガーを使用してOracle表の一貫性セット・ジャーナル化を行うためのジャーナル化インフラストラクチャを作成します。

JKM Oracle Simple

トリガーを使用してOracle表の単純なジャーナル化を行うためのジャーナル化インフラストラクチャを作成します。

Oracle GoldenGateを使用して、Oracleデータベースの変更されたレコードを使用することもできます。詳細は、第24章「Oracle GoldenGate」を参照してください。

Streams JKMの使用

Streams KMはデフォルト値で機能します。推奨設定は次のとおりです。

- デフォルトでは、AUTO_CONFIGURATION KMオプションはYesに設定されています。Yesに設定されている場合、Oracleデータベースを自動で構成し、すべての前提条件を確実に満たすことができます。このオプションでは、データベースの初期化パラメータが自動的に変更されるため、本番環境での使用はお薦めしません。Oracle Data Integrator実行ログの「ジャーナルの作成」ステップをチェックして、正しく実行されなかった構成タスク(警告ステータス)を検出する必要があります。

- デフォルトでは、CONFIGURATION_TYPEオプションはLow Activityに設定されています。使用するデータベースのトランザクション・アクティビティが低レベルの場合は、このオプションをそのままにしておきます。
開発データベースなどのスタンドアロン・データベース、またはラップトップにインストールする場合は、このオプションをStandaloneに設定します。

データベースがトランザクション処理に集中的に使用される場合は、このオプションをHigh Activityに設定します。

- デフォルトでは、STREAMS_OBJECT_GROUPオプションはCDCに設定されています。入力した値は、このJKMを使用してジャーナル化された複数のCDCセットにまたがって共有できる、オブジェクト名の生成に使用されます。このオプションの値がCDCの場合は、表2-3にリストされている命名規則が適用されます。
このオプションに使用できるのは大文字のASCII文字のみで、15文字を超えることはできません。

表2-3 CDCグループ名の命名規則の例

キャプチャ・プロセス

ODI_CDC_C

キュー

ODI_CDC_Q

キュー表

ODI_CDC_QT

適用プロセス

ODI_CDC_A

- VALIDATEを使用すると、KMが正しく使用されていることを検証する追加のステップが有効になります。このオプションでは、一切の構成作業を伴わずに様々な要件がチェックされます(構成ステップの詳細は、AUTO_CONFIGURATIONオプションを参照)。要件が満たされていない場合は、エラー・メッセージがログに書き込まれ、JKMの実行はエラーのため停止します。
複雑なKMを最初からより簡単に使用できるように、このオプションはデフォルトでYesに設定されています。

更新日JKMの使用

このJKMでは、ジャーナル化されたすべての表に、最終更新日を含む列が存在することが前提になります。この列の名前は、UPDATE_DATE_COL_NAMEナレッジ・モジュール・オプションで指定されます。

2.7 データ品質の設定

Oracle Data Integratorには、Oracle表で定義された制約と照合してデータの整合性をチェックするためのOracle CKMが用意されています。詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』のフロー制御および静的制御に関する項を参照してください。

Oracle Data Integratorには、Oracleのチェックを実行するためのナレッジ・モジュールが用意されています。これらのリストを表2-4に示します。汎用SQL KMを使用することもできます。詳細は、第4章「汎用SQL」を参照してください。

表2-4 Oracle Database用チェック・ナレッジ・モジュール

推奨KM

説明

CKM Oracle

OracleのRowidを使用してレコードを識別します。

2.8 マッピングの設計

マッピングのソース、ステージング領域またはターゲットとしてOracleを使用できます。Oracleテクノロジに基づくETL形式のマッピングを作成することもできます。

マッピングまたはチェック用に選択したKMによって、このマッピングまたはチェックの機能およびパフォーマンスが決まります。この項に示す推奨事項は、Oracleデータ・サーバーに関連する様々な状況でのKMの選択に役立ちます。

2.8.1 Oracleとの間でのデータのロード

マッピングのソース、ターゲットまたはステージング領域としてOracleを使用できます。マッピングの「ロード・ナレッジ・モジュール」タブでの、Oracleと別のタイプのデータ・サーバー間でデータをロードするためのLKMの選択は、マッピングのパフォーマンスに関してきわめて重要です。

2.8.1.1 Oracleからのデータのロード

次のKMには、Oracleデータベースからターゲットまたはステージング領域のデータベースへデータをロードするための、最適化されたメソッドが実装されています。これらのKM以外に、汎用SQL KMまたは関係するもう一方のテクノロジ固有のKMも使用できます。

ターゲットまたはステージング領域のテクノロジ

KM

説明

Oracle

LKM Oracle to Oracle (dblink)

ソース・サーバー上にビューを作成し、ターゲット・サーバー上のこのビューにシノニムを作成します。

Oracle

LKM Oracle to Oracle Push (DB Link)

ソース・サーバー上にビューを作成しますが、ターゲット・サーバー上のこのビューにシノニムは作成しません。このKMでは、IKMの設定が無視されます。組込みKMです。

Oracle

LKM Oracle to Oracle Pull (DB Link)

ソース・サーバー上にビュー、またはターゲット・サーバー上のこのビューにシノニムを作成しません。組込みKMです。

Oracle

LKM Oracle to Oracle (datapump)

データポンプ形式の外部表を使用します。

2.8.1.2 Oracleへのデータのロード

次のKMには、ソースまたはステージング領域からOracleデータベースへデータをロードするための、最適化されたメソッドが実装されています。これらのKM以外に、汎用SQL KMまたは関係するもう一方のテクノロジ固有のKMも使用できます。

ソースまたはステージング領域のテクノロジ

KM

説明

Oracle

LKM Oracle to Oracle (dblink)

ソース・サーバー上にビュー、ターゲット上にシノニムを作成します。

Oracle

LKM Oracle to Oracle Push (DB Link)

ソース・サーバー上にビューを作成せず、ターゲット上にシノニムを作成します。組込みKMです。

Oracle

LKM Oracle to Oracle Pull (DB Link)

ソース・サーバー上にビューを作成せず、ターゲット上にシノニムを作成しません。組込みKMです。

SAP BW

LKM SAP BW to Oracle (SQLLDR)

Oracleのバルク・ローダーを使用します。ファイルをステージング領域にすることはできません。

SAP ERP

LKM SAP ERP to Oracle (SQLLDR)

Oracleのバルク・ローダーを使用します。ファイルをステージング領域にすることはできません。

ファイル

LKM File to Oracle (EXTERNAL TABLE)

外部表を使用してファイルのデータをロードします。

ファイル

LKM File to Oracle (SQLLDR)

Oracleのバルク・ローダーを使用します。ファイルをステージング領域にすることはできません。

Oracle

LKM Oracle to Oracle (datapump)

データポンプ形式の外部表を使用します。

Oracle BI

LKM Oracle BI to Oracle (DBLINK)

ターゲットのステージング表のシノニムを作成し、OBIEE移入コマンドを使用します。

MSSQL

LKM MSSQL to Oracle (BCP-SQLLDR)

BCPを使用してSQL Serverからデータをアンロードし、SQL*Loaderを使用してOracleへデータをロードします。

すべて

LKM SQL to Oracle

汎用LKMより高速です(統計を使用)。

2.8.2 Oracleへのデータの統合

Oracleには様々なデータ統合戦略があり、複数のモードを使用できます。マッピングの物理ダイアグラムのIKMの選択によって、統合のパフォーマンスおよび可能性が決まります。

次のKMには、Oracleターゲットにデータを統合するための、最適化されたメソッドが実装されています。これらのKM以外に、汎用SQL KMも使用できます。

モード

KM

説明

更新

IKM Oracle Incremental Update

Oracle用に最適化されています。フロー制御をサポートします。

更新

IKM Oracle Update

Oracle用に最適化されています。Oracle UPDATE文のKMです。組込みKMです。

更新

IKM Oracle Merge

Oracle用に最適化されています。Oracle MERGE文のKMです。組込みKMです。

更新

IKM Oracle Spatial Incremental Update

SDO_GEOMETRYデータ型がサポートされます。フロー制御をサポートします。

更新

IKM Oracle Incremental Update (MERGE)

バルク・セットベースのMERGE機能のため、データが大量にある場合にお薦めします。フロー制御をサポートします。

更新

IKM Oracle Incremental Update (PL SQL)

PL/SQLを使用し、増分更新モードでLONGおよびBLOBをサポートします。フロー制御をサポートします。

特定

IKM Oracle Slowly Changing Dimension

タイプ2の緩やかに変化するディメンションをサポートします。フロー制御をサポートします。

特定

IKM Oracle Multi Table Insert

複数表挿入文をサポートします。フロー制御をサポートします。

追加

IKM Oracle to Oracle Control Append (DBLINK)

DB*Linksを使用してOracle用に最適化されています。フロー制御をサポートします。

追加

IKM Oracle Insert

Oracle用に最適化されています。Oracle INSERT文のKMです。組込みKMです。フロー制御をサポートします。

追加

IKM Oracle Multi-Insert

Oracle用に最適化されています。各ターゲットに適用されるOracle複数ターゲットINSERT文のKMです。組込みKMです。

緩やかに変化するディメンションの使用

緩やかに変化するディメンションを使用する場合は、ターゲット・データベースの各列に対して「緩やかに変化するディメンション」の値を必ず設定してください。この値は、「サロゲート・キー」、「自然キー」、列の上書きまたは挿入、「現在のレコード・フラグ」、「開始タイムスタンプ」および「終了タイムスタンプ」列を識別するために、IKM Oracle Slowly Changing Dimensionで使用されます。

複数表挿入の使用

IKM Oracle Multi Table Insertは、複数表挿入文を使用して、1つのソースのデータを1対多のOracleターゲット表に統合するために使用します。このIKMは、パッケージ内で順序付けされているマッピングで使用する必要があります。このパッケージは、次の条件を満たす必要があります。

- パッケージの最初のマッピングには一時ターゲットがあり、KMオプションDEFINE_QUERYがYESに設定されている必要があります。
この最初のマッピングによって、複数表挿入文のSELECT句の構造(つまりソース・フロー)が定義されます。

- 後続のマッピングは、この一時データストアをソースとし、KMオプションIS_TARGET_TABLEがYESに設定されている必要があります。

- パッケージの最後のマッピングでは、複数表挿入文を実行するために、KMオプションEXECUTEがYESに設定されている必要があります。

- マッピングの一時マッピングを導出表として使用(下位選択)をtrueに設定しないでください。

大量のデータが追加される場合は、KMオプションOPTIMIZER_HINTを/*+ APPEND */に設定することを検討してください。

Spatialデータ型の使用

Oracle Spatialデータ型で増分更新操作を実行するには、トポロジでSDO_GEOMETRYデータ型を宣言し、IKM Oracle Spatial Incremental Updateを使用する必要があります。SDO_GEOMETREYデータ型の2つの列を比較するとき、ジオメトリが同等とみなされるエラー・マージンを定義するために、GEOMETRY_TOLERANCEオプションが使用されます。詳細は、Oracle Spatialユーザーズ・ガイドおよびリファレンスを参照してください。

2.8.3 ETL形式マッピングの設計

マッピングの設計方法に関する一般的な情報は、『Oracle Data Integratorでの統合プロジェクトの開発』のマッピングの作成に関する項を参照してください。この項では、ステージング領域がOracleデータベースまたは任意のANSI-92準拠データベースで、ターゲットがOracleデータベース上にあるETL形式マッピングの設計方法について説明します。

ETL形式マッピングでは、ターゲットとは異なるステージング領域内のデータが、ODIによって処理されます。Oracle Data Integratorでは、Oracleステージング領域からOracleターゲットへデータをロードするための2つの方法が提供されます。

- 複数接続IKMの使用

- LKMおよび単一接続IKMの使用

使用するKM戦略によって、フロー制御および静的制御がサポートされます。

複数接続IKMの使用

複数接続IKMでは、ステージング領域とソースが異なるデータ・サーバー上にある場合のターゲットの更新が可能です。

Oracle Data Integratorには、Oracleデータを処理するための複数接続IKMであるIKM Oracle to Oracle Control Append (DBLINK)が用意されています。また、汎用SQL複数接続IKMも使用できます。詳細は、第4章「汎用SQL」を参照してください。

複数接続IKMを使用する状況の詳細は、表2-5を参照してください。

ETL形式マッピングで複数接続IKMを使用するには、次のようにします。

1. 『Oracle Data Integratorでの統合プロジェクトの開発』のマッピングの作成に関する項の説明に従って、標準の手順を使用して、ステージング領域がOracle上またはANSI-92準拠テクノロジ、ターゲットがOracle上にあるマッピングを作成します。この項では、ETL形式固有の手順のみを説明します。

2. ソース表の論理スキーマまたは第3のスキーマに対するマッピングのステージング領域を変更します。ステージング領域の変更方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』の実行場所の構成に関する項を参照してください。

3. 物理ダイアグラムでアクセス・ポイントを選択します。このオブジェクトのプロパティ・インスペクタが開きます。

4. 「ロード・ナレッジ・モジュール」タブで、ソースからステージング領域にロードするLKMを選択します。使用できるLKMは表2-5を参照してください。

5. 必要な場合は、KMオプションを変更します。

6. 物理ダイアグラムでターゲットのタイトルをクリックしてターゲットを選択します。このオブジェクトのプロパティ・インスペクタが開きます。
「統合ナレッジ・モジュール」タブで、ステージング領域からターゲットにデータをロードするETL複数接続IKMを選択します。使用できるIKMは表2-5を参照してください。

KMオプションを設定する際には、次の点に注意してください。

- IKM Oracle to Oracle Control Append (DBLINK)に関する注意事項

- 大量のデータが追加される場合は、KMオプションOPTIMIZER_HINTを/*+ APPEND */に設定してください。

- ターゲット・スキーマ上に自動でdbリンクを作成するには、AUTO_CREATE_DB_LINKをtrueに設定してください。AUTO_CREATE_DB_LINKをfalse(デフォルト)に設定した場合は、この名前のリンクがターゲット・スキーマに存在する必要があります。

- FLOW_CONTROLおよびSTATIC_CONTROLオプションを「はい」に設定した場合は、「チェック・ナレッジ・モジュール」タブでCKMを選択します。FLOW_CONTROLをYesに設定した場合は、フロー表がターゲット上に作成されます。

LKMおよび単一接続IKMの使用

専用の複数接続IKMがない場合は、標準のエクスポートLKMと標準の単一接続IKMを組み合せて使用します。エクスポートLKMは、ステージング領域からターゲットへフロー表をロードするために使用します。単一接続IKMは、データ・フローをターゲット表に統合するために使用します。

Oracle Data Integratorでは、ETL形式マッピングのソースとして、任意のANSI SQL-92標準準拠テクノロジがサポートされます。ステージング領域およびターゲットはOracleです。

標準のエクスポートLKMおよび単一接続IKMを組み合せて使用する状況の詳細は、表2-5を参照してください。

ETL形式マッピングでLKMおよび単一接続IKMを使用するには、次のようにします。

1. 『Oracle Data Integratorでの統合プロジェクトの開発』のマッピングの作成に関する項の説明に従って、標準の手順を使用して、ステージング領域およびターゲットがOracle上にあるマッピングを作成します。この項では、ETL形式固有の手順のみを説明します。

2. ソース表の論理スキーマまたは第3のスキーマに対するマッピングのステージング領域を変更します。ステージング領域の変更方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』の実行場所の構成に関する項を参照してください。

3. 物理ダイアグラムでアクセス・ポイントを選択します。このオブジェクトのプロパティ・インスペクタが開きます。

4. 「ロード・ナレッジ・モジュール」タブで、ソースからステージング領域にロードするLKMを選択します。使用できるLKMは表2-5を参照してください。

5. 必要な場合は、KMオプションを変更します。

6. ステージング領域に対するアクセス・ポイントを選択します。このオブジェクトのプロパティ・インスペクタが表示されます。

7. 「ロード・ナレッジ・モジュール」タブで、ステージング領域からターゲットにロードするLKMを選択します。使用できるLKMは表2-5を参照してください。

8. 必要な場合は、KMオプションを変更します。

9. 「ターゲット」のタイトルをクリックしてターゲットを選択します。このオブジェクトのプロパティ・インスペクタが開きます。
「統合ナレッジ・モジュール」タブで、ターゲットを更新する標準単一接続IKMを選択します。使用できるIKMは表2-5を参照してください。

表2-5 Oracleデータを使用するETL形式マッピングのKMガイドライン

ソース

ステージング領域

ターゲット

エクスポートLKM

IKM

KM戦略

コメント

ANSI SQL-92標準準拠

Oracle

Oracle

なし

IKM Oracle to Oracle Control Append (DBLINK)

複数接続IKM

このKMは次の目的に使用します。

- 制御追加の実行

- パフォーマンス上の理由でのDB*Linksの使用

フロー制御および静的制御をサポートします。

ANSI SQL-92標準準拠

Oracleまたは任意のANSI SQL-92標準準拠データベース

Oracleまたは任意のANSI SQL-92標準準拠データベース

なし

IKM SQL to SQL Incremental Update

複数接続IKM

ターゲット側一時オブジェクトでの増分更新戦略が可能です。ターゲット・サーバーで一時オブジェクトを作成できない場合に、このKMを使用します。

アプリケーションの更新は、ソースからターゲットへ直接行われ、ターゲット上に一時オブジェクトは作成されません。フロー表がターゲットではなくステージング領域に作成される構成は、データ量が少ない場合のみ使用してください。

フロー制御および静的制御をサポートします。

Oracle

Oracle

Oracle

LKM to Oracle to Oracle (DBLINK)

IKM Oracle Slowly Changing Dimension

LKM + 標準IKM

na

Oracle

Oracle

Oracle

LKM to Oracle to Oracle (DBLINK)

IKM Oracle Incremental Update

LKM + 標準IKM

na

Oracle

Oracle

Oracle

LKM to Oracle to Oracle (DBLINK)

IKM Oracle Incremental Update (MERGE)

LKM + 標準IKM

na

2.9 トラブルシューティング

この項では、Oracleナレッジ・モジュールの使用時に発生する可能性がある問題のトラブルシューティングに関する情報を提供します。この章の内容は、次のとおりです。

- Oracle Databaseのエラーのトラブルシューティング

- 一般的な問題および解決策

2.9.1 Oracle Databaseのエラーのトラブルシューティング

通常、Oracle Data Integratorではエラーは次のように表示されます。

java.sql.SQLException: ORA-01017: invalid username/password; logon denied
at ...
at ...
...

java.sql.SQLExceptioncodeは、単純に、JDBCドライバを介してデータベースへの問合せが行われ、エラーが戻されたことを示しています。このエラーはデータベースまたはドライバのエラーであることが多く、次のように解明する必要があります。

まず、太字のテキスト部分のみに注目してください。Oracleのドキュメントでこれを検索してください。ここで(赤色で)示されているように、Oracle固有のエラー・コードが含まれている場合は、エラーをすばやく識別できます。

このようなエラーが実行ログで検出された場合は、データベースに送信されたSQLコードを分析して、エラーの原因を特定する必要があります。このコードは、エラーのあるタスクの「説明」タブに表示されます。

2.9.2 一般的な問題および解決策

この項では、一般的な問題および解決策について説明します。

- ORA-12154 TNS: サービス名を解決できませんでした。
TNS別名の解決。この問題は、OCIドライバの使用時、またはデータベース・リンクを使用したKMの使用時に発生する可能性があります。マシンのTNS別名の構成を確認してください。

- ORA-02019 リモート・データベースの接続の説明が見つかりません
存在しないデータベース・リンクを使用してKMが使用されています。データベース・リンク作成用のKMオプションを確認してください。

- ORA-00900 SQL文が無効です
ORA-00923 FROMキーワードが指定の位置にありません

マッピングで生成されたコードまたはプロシージャに入力したコードがOracleで無効です。通常、このエラーは、マッピング、フィルタまたは結合での入力エラーに関連します。典型的な例は、引用符が欠落している、またはカッコが閉じられていないなどです。

また、SQL以外の構文へのコールが原因の場合もよくあります。たとえば、次の構文を使用してOracleストアド・プロシージャをコールした場合です。

EXECUTE SCHEMA.PACKAGE.PROC(PARAM1, PARAM2).

ストアド・プロシージャの有効なSQLコールは次のとおりです。

BEGIN
SCHEMA.PACKAGE.PROC(PARAM1, PARAM2);
END;

EXECUTE SCHEMA.PACKAGE.PROC(PARAM1, PARAM2)はSQL*PLUS固有の構文であり、JDBCでは機能しません。

- ORA-00904 列名が無効です
マッピング、結合またはフィルタでの入力エラーです。列名でない文字列が列名として解釈されたか、列名にスペルミスがあります。

このエラーは、最近構造が変更されたデータストアに関連付けられているエラー表にアクセスした場合にも表示されることがあります。エラー表に変更を反映するか、エラー表を削除して次回の実行時にOracle Data Integratorで再作成されるようにする必要があります。

- ORA-00903 表名が無効です
使用される表(ソースまたはターゲット)がOracleスキーマに存在しません。コンテキストのマッピング論理スキーマまたは物理スキーマをチェックし、このコンテキストに対してアクセスされるスキーマにその表が物理的に存在することを確認してください。

- ORA-00972 識別子が長すぎます
Oracleのオブジェクト識別子には制限があります(通常30文字)。この制限を超えるとこのエラーが表示されます。マッピングの実行中に作成された表がこの制限を超えると、このエラーが発生します(詳細は実行ログを参照してください)。

Oracleテクノロジのトポロジをチェックし、オブジェクト名(表および列)の最大長がOracle構成に対応していることを確認してください。

- ORA-01790 式には対応する式と同じデータ型を持つ必要があります
(マッピングや結合において)暗黙的に変換できない2つの異なる値を結合しようとしています。これらの値に明示的な変換ファンクションを使用してください。

3 ファイル

この章では、Oracle Data Integratorでのファイルの使用方法について説明します。

この章には次の項が含まれます:

- 3.1項「概要」

- 3.2項「インストールおよび構成」

- 3.3項「トポロジの設定」

- 3.4項「統合プロジェクトの設定」

- 3.5項「ファイル・モデルの作成およびリバース・エンジニアリング」

- 3.6項「マッピングの設計」

3.1 概要

Oracle Data Integratorでは、ASCIIまたはEBCDICのデータを含む固定ファイルまたはデリミタ付きファイルがサポートされます。

3.1.1 概念

ファイル・テクノロジの概念は、Oracle Data Integratorの概念に次のようにマップされます。1つのファイル・サーバーは、Oracle Data Integratorの1つのデータ・サーバーに対応します。このファイル・サーバーで、ファイルが含まれるディレクトリが物理スキーマに対応します。ディレクトリ内のフラット・ファイルのグループがOracle Data Integratorモデルに対応し、この各ファイルがデータストアに対応します。ファイル内のフィールドはデータストアの列に対応します。

Oracle Data Integratorには、ファイル用の組込みドライバが用意されています。また、このドライバを使用し、ファイル・データ・モデルおよびトポロジで宣言されたメタデータを使用してファイルを統合するためのナレッジ・モジュールが用意されています。

ほとんどのテクノロジには、フラット・ファイルと相互作用するための固有の機能(データベース・ローダー、ユーティリティおよび外部表など)も含まれています。テクノロジ固有のナレッジ・モジュールを使用することで、Oracle Data Integratorでもこれらの機能を利用できます。ほとんどの場合において、パフォーマンスの観点から、フラット・ファイルの処理にはデータベース・ユーティリティを使用することをお薦めします。

ファイル・テクノロジは、(固定またはデリミタ付き)フラット・ファイルに関係することに留意してください。XMLファイルの説明は第5章「XMLファイル」に記載されています。

3.1.2 ナレッジ・モジュール

Oracle Data Integratorには、ファイル・ドライバを使用してファイル・データを処理するためのナレッジ・モジュール(KM)が用意されています。この項ではこれらのリストを提供します。

表3-1にリストされているSQL KMは汎用であり、あらゆるデータベース・テクノロジで使用できます。ローダーまたは外部表などの機能を使用するテクノロジ固有のKMは、対応するテクノロジの章にリストされています。

表3-1 SQL KM

ナレッジ・モジュール

説明

LKM File to SQL

ASCIIファイルまたはEBCDICファイルから、ステージング領域として使用される任意のANSI SQL-92準拠データベースへ、データをロードします。

IKM SQL to File Append

任意のANSI SQL-92準拠ステージング領域からターゲット・ファイルに、置換モードでデータを統合します。

IKM File to File (Java)

Java処理を使用してソース・ファイルからターゲット・ファイルにデータを統合します。複数のソース・ファイルを取得し、ログおよび不良ファイルを生成できます。詳細は、3.6.2.2項「IKM File to File (Java)」を参照してください。

3.2 インストールおよび構成

ファイル・テクノロジでの作業を開始する前に、この項の情報を必ず読んでください。

- システム要件および動作要件

- テクノロジ固有の要件

- 接続性要件

3.2.1 システム要件および動作要件

インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。

サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。

http://www.oracle.com/technology/products/oracle-data-integrator/index.html

3.2.2 テクノロジ固有の要件

ファイル・データ用の一部のナレッジ・モジュールでは、データベース固有の機能が使用されます。この項では、これらの機能に関連する要件をリストします。

データベース・ユーティリティ

ほとんどのデータベース・テクノロジには、フラット・ファイルと相互作用するための独自のユーティリティがあります。これらのすべてにおいて、ユーティリティを使用するマッピングを実行するエージェントからデータベース・クライアント・ソフトウェアにアクセスできる必要があります。次に例を示します。

- Oracle: SQL*Loader

- Microsoft SQL Server: bcp

- Teradata: FastLoad、MultiLoad、TPump、FastExport

テクノロジ固有のナレッジ・モジュールを使用することで、Oracle Data Integratorでこれらのユーティリティを利用できます。ナレッジ・モジュールの詳細およびデータベース・ユーティリティを使用するための要件は、このガイドのテクノロジ固有の章を参照してください。

IKM File to File (Java)の要件

IKM File to File (Java)では、ソース・ファイルを処理するためのJavaプログラムが生成、コンパイルおよび実行されます。このKMを使用するには、JDKが必要です。

3.2.3 接続性要件

この項では、フラット・ファイルに接続するための要件をリストします。

JDBCドライバ

Oracle Data Integratorには、フラット・ファイル用の組込みドライバが含まれています。このドライバはOracle Data Integratorとともにインストールされるもので、追加の構成は不要です。

3.3 トポロジの設定

トポロジの設定には次が含まれます。

1. ファイル・データ・サーバーの作成

2. ファイル物理スキーマの作成

3.3.1 ファイル・データ・サーバーの作成

ファイル・データ・サーバーは、ファイル・フォルダのセットです(それぞれのファイル・フォルダは1つの物理スキーマに対応します)。

Oracle Data Integratorには、デフォルトのFILE_GENERICデータ・サーバーが用意されています。このデータ・サーバーは、ほとんどのニーズに対応します。ほとんどの場合、ファイル・データ・サーバーの作成は不要で、必要なのはFILE_GENERICデータ・サーバーの下に物理スキーマを作成することのみです。

注意:
JDK 8からは、JDKにJDBC-ODBCブリッジが含まれなくなりました。
JDBC-ODBCブリッジは常に過渡的な製品であるとみなされてきました。一部のJDKバンドルのみに提供されていた、JREに含まれないサポート対象外の製品です。JDBC-ODBCブリッジの代わりに、データベースのベンダーが提供するJDBCドライバまたは市販のJDBCドライバを使用してください。

3.3.1.1 データ・サーバーの作成

『Oracle Data Integratorでの統合プロジェクトの開発』のデータ・サーバーの作成に関する項の説明に従って、標準の手順を使用してファイル・テクノロジ用のデータ・サーバーを作成します。この項では、ファイル・データ・サーバーの定義に関する必須または固有のフィールドのみについて説明します。

1. 「定義」タブ:

- 名前: Oracle Data Integratorに表示されるデータ・サーバーの名前。

- ユーザー/パスワード: これらのフィールドは、ファイル・データ・サーバーでは使用しません。

2. 「JDBC」タブで次の値を入力します。

- JDBCドライバ: com.sunopsis.jdbc.driver.file.FileDriver

- JDBC URL: jdbc:snps:dbfile?<property=value>&<property=value>&...
URLでは表3-2にリストされているプロパティを使用できます。

表3-2 JDBCファイル・ドライバのプロパティ

プロパティ

値

説明

DATA_CONTAINS_LINE_SEPARATOR

TRUE|FALSE

trueに設定すると、データの読取り時に、レコードに行セパレータとして設定されている文字(または連続する文字)が含まれている場合、それは改行とはみなされず、読み取られる'行サイズ'の文字数に達するまでデータが読み取られます。

ENCODING

<encoding_code>

ファイル・エンコーディング。サポートされているエンコーディングのリストは、http://java.sun.com/j2se/1.4.2/docs/guide/intl/encoding.doc.htmlにあります。デフォルトのエンコーディング値はISO8859_1です。

ERR_FILE_PATH

empty

ファイルの場所のパス。このパスはファイル・ドライバによって使用され、データの解析時にドライバによって検出されたエラーは<property value> + .errorに挿入されます。問題の原因となっている行は、<property value> + .badに挿入されます。したがって、問題が発生した場合、実際には2つのファイルが作成されます。

MULTIBYTES_MODE

0、1または2

0がデフォルトであり、マルチバイトに対して特別な処理を行わないことを示します。ドライバはファイルをバイト単位で読み取ります。

1は、ファイルにマルチバイト文字列が含まれることを示します。ドライバはマルチバイト・ファイルを文字単位で読み取ります。

2は、ファイルにマルチバイト文字とバイナリ・データが混在していることを示します。ドライバは、マルチバイト・ファイルのBINARY列はバイト単位で、それ以外の列は文字単位で読み取ります。

NO_PAD_DEL_NUMERIC

TRUE|FALSE

物理的な列の長さを一致させるための、空白による数値(integer、float)の左パディングを制限します。デフォルト値はFALSEです。

TRUNC_FIXED_STRINGS

TRUE|FALSE

固定ファイルのフィールド・サイズにあわせて文字列を切り捨てます。デフォルト値はFALSEです。

TRUNC_DEL_STRINGS

TRUE|FALSE

デリミタ付きファイルのフィールド・サイズにあわせて文字列を切り捨てます。デフォルト値はFALSEです。

注意:
TRUNC_FIXED_STRINGSおよびTRUNC_DEL_STRINGSプロパティは、INSERT文を介してファイル・ドライバにフィードされるデータの処理に影響を及ぼしますが、ファイル・ドライバがバッキング・ファイルから読み取るデータには影響を及ぼしません。

JDBC URLの例:

jdbc:snps:dbfile?ENCODING=ISO8859_1&TRUNC_FIXED_STRINGS=FALSE

3.3.2 ファイル物理スキーマの作成

『Oracle Data Integratorの管理』の物理スキーマの作成に関する項の説明に従って、標準の手順を使用してファイル物理スキーマを作成します。

物理スキーマでは、次のようにディレクトリのペアを設定する必要があります。

- ディレクトリ(スキーマ)。Oracle Data Integratorによって、ソースおよびターゲットのファイルの検索、およびソース・ファイルで検出された無効なレコードのエラー・ファイルの作成が行われる場所です。

- ディレクトリ(作業スキーマ)。Oracle Data Integratorによって、データ・スキーマ内のソースおよびターゲットに関連する一時ファイルが作成される可能性がある場所です。

注意:

- データ・スキーマおよび作業スキーマは、それぞれ1つのディレクトリに対応します。ファイルにアクセスするコンポーネントから、このディレクトリにアクセスできる必要があります。ディレクトリは、絶対パス(m:/public/data/files)、またはランタイム・エージェントかStudio起動ディレクトリを基準とした相対パス(../demo/files)のいずれかにできます。実行場所に依存しないパスを使用することをお薦めします。

- UNIXの場合は特に、これらの両ディレクトリでの読取り/書込み権限がエージェントに必要です。

- ファイルのパスは、WindowsとUNIXで異なることに注意してください。このディレクトリ情報を設定する際には、エージェントで使用するプラットフォームを考慮してください。

『Oracle Data Integratorの管理』の論理スキーマの作成に関する項の説明に従って、標準の手順を使用してこの物理スキーマ用の論理スキーマを作成し、特定のコンテキストで関連付けます。

3.4 統合プロジェクトの設定

ファイル・データベースを使用してプロジェクトを設定するには、標準の手順に従います。『Oracle Data Integratorでの統合プロジェクトの開発』の統合プロジェクトの作成に関する項を参照してください。

最初は、使用するプロジェクトに次のナレッジ・モジュールをインポートすることをお薦めします。

- LKM File to SQL

- IKM SQL to File Append

- IKM File to File (Java)

これらのナレッジ・モジュール以外に、使用する製品に関連する他のテクノロジ固有のファイル・ナレッジ・モジュールもインポートできます。

3.5 ファイル・モデルの作成およびリバース・エンジニアリング

この項には次のトピックが含まれます:

- ファイル・モデルの作成

- ファイル・モデルのリバース・エンジニアリング

3.5.1 ファイル・モデルの作成

ファイル・モデルは、ディレクトリに格納されているファイルに対応するデータストアのセットです。モデルは常に、論理スキーマに基づきます。特定のコンテキストで、論理スキーマは1つの物理スキーマに対応します。この物理スキーマのデータ・スキーマは、モデルで示されるすべてのファイルが(最終的にはサブディレクトリに)含まれているディレクトリです。

『Oracle Data Integratorでの統合プロジェクトの開発』のモデルの作成に関する項の説明に従って、標準の手順を使用してファイル・モデルを作成します。

3.5.2 ファイル・モデルのリバース・エンジニアリング

Oracle Data Integratorでは、特有の方法でファイルをリバース・エンジニアリングできます。ファイル・データベースでサポートされているリバース・エンジニアリングのタイプは次の4つです。

- デリミタ付きファイルのリバース・エンジニアリングは、ファイル・データストアごとに実行されます。

- ウィザードを使用した固定ファイルのリバース・エンジニアリングは、ファイル・データストアごとに実行されます。

- COBOLコピーブックのリバース・エンジニアリングは、そのファイルを記述するコピーブックが提供されている場合に、固定ファイルに使用できます。これはファイル・データストアごとに実行されます。

- カスタマイズされたリバース・エンジニアリングは、RKM (リバース・ナレッジ・モデル)を使用して、Microsoft Excelスプレッドシートからあるモデル内の各ファイル・データストアの列定義を取得し、手動入力することなくバッチでファイル・データストアを自動生成します。

注意:
組込みファイル・ドライバでは、Oracle Data Integratorモデルのメタデータが使用されます(フィールドのデータ型または長さ、ヘッダー行の数など)。ドライバ固有のタグは、Oracle Data Integratorで生成され、通常のSQLコマンドとともにドライバに渡されます。これらのタグで、ドライバによるファイルの読取りまたは書込み方法が制御されます。
同様に、Oracle Data Integratorでデータベース・ローダーおよびユーティリティが使用される場合には、モデル・メタデータを使用して、これらのローダーおよびユーティリティが制御されます。

ファイル定義とファイル・コンテンツの間の矛盾は、実行時の問題の原因となるため、リバース・エンジニアリング・プロセスの後で、ファイル定義に細心の注意を払うことが重要です。

3.5.2.1 デリミタ付きファイルのリバース・エンジニアリング

デリミタ付きファイルのリバース・エンジニアリングを実行するには、次のようにします。

1. 「モデル」アコーディオンで使用するファイル・モデルを右クリックして、「新規データストア」を選択します。データストア・エディタが開きます。

2. 「定義」タブで次のフィールドに入力します。

- 名前: このデータストアの名前。

- リソース名: サブディレクトリ(必要な場合)およびファイルの名前。フィールドの横の「参照」アイコンを使用してファイルを参照できます。

3. 「ファイル」タブに移動してファイルの詳細を指定します。次のようにフィールドを設定します。

- ファイル形式: 区切り

- ヘッダー(行数): ヘッダーの行数を入力します。ヘッダーがある場合、ヘッダーの最初の行はOracle Data Integratorによってファイルの列名に使用されます。

- 「レコード・セパレータ」を選択します。

- 「フィールド・セパレータ」として使用する文字を選択または入力します。

- ファイルで使用されている場合は「テキスト・デリミタ」を入力します。

- ファイルに小数点が含まれる場合は「小数点セパレータ」を入力します。

4. 「ファイル」メイン・メニューから「保存」を選択します。

5. データストア・エディタの「属性」タブに移動します。

6. エディタ・ツールバーで「リバース・エンジニアリング」をクリックします。

7. リバース・エンジニアリングされた属性のデータ型および長さを検証します。Oracle Data Integratorでは、ファイルの内容からフィールドのデータ型および長さが推測されますが、このプロセスでデフォルト値(たとえば、文字列フィールドの長さが50)や不正なデータ型が設定されることがあります。

8. 「ファイル」メイン・メニューから「保存」を選択します。

3.5.2.2 ウィザードを使用した固定ファイルのリバース・エンジニアリング

Oracle Data Integratorには、固定ファイルの列をグラフィカルに定義するためのウィザードが用意されています。

このウィザードを使用して固定ファイルをリバース・エンジニアリングするには、次のようにします。

1. 「モデル」アコーディオンで使用するファイル・モデルを右クリックして、「新規データストア」を選択します。データストア・エディタが開きます。

2. 「定義」タブで次のフィールドに入力します。

- 名前: このデータストアの名前。

- リソース名: サブディレクトリ(必要な場合)およびファイルの名前。フィールドの横の「参照」アイコンを使用してファイルを参照できます。

3. 「ファイル」タブに移動してファイルの詳細を指定します。次のようにフィールドを設定します。

- ファイル形式: 固定

- ヘッダー(行数): ヘッダーの行数を入力します。

- 「レコード・セパレータ」を選択します。

4. 「ファイル」メイン・メニューから「保存」を選択します。

5. データストア・エディタの「属性」タブに移動します。

6. エディタ・ツールバーで、「リバース・エンジニアリング」をクリックします。属性設定ウィザードが起動します。ファイルの最初のレコードが属性設定ウィザードに表示されます。

7. ルーラー(ファイルの内容の上部)をクリックし、属性を区切るマーカーを作成します。ルーラー内で右クリックすると、マーカーを削除できます。

8. 事前に生成された名前(C1、C2など)を使用して属性が作成されます。属性名を編集するには、属性ヘッダー行(ルーラーの下)をクリックします。

9. (右側の)プロパティ・パネルで、選択した属性のすべてのパラメータを編集できます。少なくとも、各属性の「属性名」、「データ型」および「長さ」を設定してください。

10. 属性の定義が完了したら「OK」をクリックします。

11. 「ファイル」メイン・メニューから「保存」を選択します。

3.5.2.3 COBOLコピーブックのリバース・エンジニアリング

COBOLコピーブックのリバース・エンジニアリングでは、COBOLコピーブック・ファイルに含まれるレガシー・ファイル構造の説明からレガシー・ファイル構造を取得できます。

COBOLコピーブックを使用して固定ファイルをリバース・エンジニアリングするには、次のようにします。

1. 「モデル」アコーディオンで使用するファイル・モデルを右クリックして、「新規データストア」を選択します。データストア・エディタが開きます。

2. 「定義」タブで次のフィールドに入力します。

- 名前: このデータストアの名前。

- リソース名: サブディレクトリ(必要な場合)およびファイルの名前。フィールドの横の「参照」アイコンを使用してファイルを参照できます。

3. 「ファイル」タブに移動してファイルの詳細を指定します。次のようにフィールドを設定します。

- ファイル形式: 固定

- ヘッダー(行数): ヘッダーの行数を入力します。

- 「レコード・セパレータ」を選択します。

4. 「ファイル」メイン・メニューから「保存」を選択します。

5. データストア・エディタの「属性」タブに移動します。

6. 固定形式のファイル・データストアを作成するか開きます。

7. データストア・エディタの「属性」タブに移動します。

8. ツールバー・メニューで「COBOLコピーブックのリバース・エンジニアリング」をクリックします。

9. 「COBOLコピーブックのリバース・エンジニアリング」ダイアログで次のフィールドに入力します。

- ファイル: コピーブック・ファイルの場所。

- 文字セット: コピーブック・ファイルの文字セット。

- 説明書式: (EBCDIC | ASCII): コピーブック・ファイルの書式。

- データ形式: (EBCDIC | ASCII): データ・ファイルの形式。

10. 「OK」をクリックします。

コピーブックに記述されている属性が、リバースエンジニアリングされて属性リストに表示されます。

注意:
コピーブックで宣言されているデータ型に対応するデータ型がOracle Data Integratorのファイル・テクノロジにない場合、そのデータ型を持つフィールドの属性は、データ型なしで表示されます。

3.5.2.4 カスタマイズされたリバース・エンジニアリング

このリバース・エンジニアリング手法では、Oracle Data Integratorは、あるモデル内の各ファイル・データストアの列定義が含まれているMicrosoft Excelスプレッドシートを読み込み、バッチでファイル・データストアを生成します。

file_repository.xlsというサンプル・ファイルがODIから提供されており、通常は/demo/excelサブディレクトリにあります。サンプル・ファイルの専用フォーマットに従って、使用するデータストアの情報を入力します。

次の手順は、使用するフラット・ファイルの構造の説明を使用して、このファイルが変更されていることを前提としています。

このファイルは、リバース・エンジニアリングを開始する前にクローズすることをお薦めします。

カスタマイズされたリバース・エンジニアリングを実行するには、次の手順を行います。

1. Excelスプレッドシート用のODBCデータソースの作成。ファイルの説明を含むExcelスプレッドシートに対応します。

2. Microsoft Excelスプレッドシートのデータ・サーバー、物理スキーマおよび論理スキーマの定義

3. カスタマイズされたリバース・エンジニアリングの実行。RKM File from Excel RKMを使用します。

Excelスプレッドシート用のODBCデータソースの作成

1. Microsoft ODBCデータソース・アドミニストレータを起動します。
64ビットJRE上で動作しているODIは、64ビットODBCのみと動作することに注意してください。

2. システムDSN(データ・ソース名)を追加します。

3. データ・ソース・ドライバとしてMicrosoft Excel Driver (*.xlsや*.xlsxなど)を選択します。

4. データ・ソースにODI_EXCEL_FILE_REPOという名前を付けて、/demo/excel/file_repository.xlsをデフォルトのワークブックとして選択します。それに応じたドライバのバージョンを間違いなく選択してください。たとえば、.xlsxファイルにはExcel 12.0を選択します。

Microsoft Excelスプレッドシートのデータ・サーバー、物理スキーマおよび論理スキーマの定義

1. トポロジ・ナビゲータで、次のパラメータを使用してMicrosoft Excelデータ・サーバーを追加します。

- 名前: EXCEL_FILE_REPOSITORY

- JDBCドライバ: Excel用の適切なJDBCドライバを選択します。

- JDBC URL: 選択されたJDBCドライバに必要なURLを入力します。

- 配列フェッチ・サイズ: 0

2. 残りのパラメータにはデフォルト値を使用します。「ファイル」メイン・メニューから「保存」を選択します。

3. 「テスト接続」をクリックして、データ・サーバーが実際のExcelファイルに接続するか確認します。

4. このデータ・サーバーに物理スキーマを追加します。「定義」タブではデフォルト値をそのまま使用します。

1. 物理スキーマの「コンテキスト」タブで「追加」をクリックします。

2. 新規行でリバース・エンジニアリングに使用するコンテキストを選択し、論理スキーマ列にEXCEL_FILE_REPOSITORYを入力します。この論理スキーマは自動的に生成されます。この名称は変更できないことに注意してください。

3. 「ファイル」メイン・メニューから「保存」を選択します。

カスタマイズされたリバース・エンジニアリングの実行

1. デザイナ・ナビゲータで、使用するプロジェクトにRKM File (FROM EXCEL)ナレッジ・モジュールをインポートします。

注意:
インポート時までにEXCEL_FILE_REPOSITORY論理スキーマが生成されない場合には、インポートされたRKMのカスタマイズ状態は「ユーザーが変更済」となります。EXCEL_FILE_REPOSITORYが生成されると、対応するRKMタスクの下にソース・コマンド・スキーマとして表示されます。

2. 既存のファイル・モデルを開きます(またはファイル・モデルを新しく生成します)。ファイル・モデルに通常定義するようにパラメータを定義します。テクノロジはMicrosoft Excelではなく、ファイルであることに注意してください。

3. 「リバース・エンジニアリング」タブで次のパラメータを設定します。

- 「カスタマイズ済」を選択します。

- コンテキスト: リバース・コンテキスト

- ナレッジ・モジュール: RKM File (FROM EXCEL)

4. ツールバー・メニューで「リバース・エンジニアリング」をクリックします。

5. 実行ログでリバースエンジニアリング・プロセスを確認できます。

注意:

- 必須Microsoft ExcelスキーマであるEXCEL_FILE_REPOSITORYは、自動的にRKM File (FROM EXCEL)によって使用されます。RKM File (FROM EXCEL)を使用した実際のファイル・モデルとは独立しています。

- Excelに関連した一般的なODBC例外を減らすための情報については、8.7.2項「一般的な問題および解決策」を参照してください。

3.6 マッピングの設計

ファイルをマッピングのソースまたはターゲットとして使用できますが、ステージング領域としては使用できません。

マッピングまたはチェック用に選択したKMによって、このマッピングまたはチェックの機能およびパフォーマンスが決まります。この項に示す推奨事項は、ファイル・データ・サーバーに関連する様々な状況でのKMの選択に役立ちます。

3.6.1 ファイルからのデータのロード

ファイルをマッピングのソースとして使用できます。「ロード・ナレッジ・モジュール」タブでのステージング領域にファイルをロードするためのLKMの選択は、マッピングのパフォーマンスに関してきわめて重要です。

LKM File to SQLでは、組込みファイル・ドライバを使用して、ファイル・データベースからステージング領域へデータがロードされます。このKM以外に、ステージング領域またはターゲットのテクノロジ固有のKMも使用できます。それらのKMではテクノロジ固有の最適化がサポートされており、ローダーや外部表などが使用されます。

このナレッジ・モジュールでは、組込みドライバに依存する他のKMと同様に、ドライバに添付されている次の2つの機能がサポートされています。

- 誤ったレコードの処理

- 複数レコード・ファイルのサポート

誤ったレコードの処理

Oracle Data Integratorの組込みドライバでは、ファイル・テクノロジに対する列レベルでのエラー処理機能が提供されます。Oracle Data Integratorでは、ファイルのロード時に複数の制御が実行されます。その中の1つでは、ファイルのデータがデータストア定義と一致するかどうかが検証されます。行の1つの値が列の説明と一致しない場合、属性エディタの「制御」タブにある「エラー発生時」オプションでは実行するアクションが定義され、残りの行の検証が続行されます。「エラー発生時」オプションに指定できる値は次のとおりです。

- エラーの拒否: エラーを含む行が.BADファイルに移動し、エラーの理由が.ERRORファイルに書き込まれます。
.BADおよび.ERRORファイルは、読み取られるファイルの名前に拡張子.BADおよび.ERRORを使用して、このファイルと同じ場所に保存されます。

- エラーの場合はNull(非アクティブ・トレース): エラーを含む行はフロー内に保持され、誤った値がNullに置き換えられます。

- エラーの場合はNull(アクティブ・トレース): エラーを含む行はフロー内に維持され、誤った値がNullに置き換えられます。さらに、エラーの理由が.ERRORファイルに書き込まれます。

複数レコード・ファイルのサポート

Oracle Data Integratorでは、複数のレコード書式を含むファイルを処理できます。ファイルには、たとえば注文を表す(5つの列で構成される)レコードおよび注文明細行を表す(データ型の異なる8つの列で構成される)他のレコードが含まれる場合があります。

Oracle Data Integratorでは、特定のレコード書式をそれぞれ異なるデータストアとみなすことで対処します。

例3-1 複数レコード・ファイル

この例では複数レコード・ファイルorders.txtを使用します。これには、注文および注文明細行の2つの異なるレコード・タイプが含まれます。

注文レコードの書式は次のとおりです。

REC_CODE,ORDER_ID,CUSTOMER_ID,ORDER_DATE

注文明細行レコードの書式は次のとおりです。

REC_CODE,ORDER_ID,LINE_ID,PRODUCT_ID,QTY

注文レコードはREC_CODE=ORDで識別されます。

注文明細行レコードはREC_CODE=LINで識別されます。

複数レコード・ファイルをマッピングのソースとして処理するには、次のようにします。

1. ソース・ファイルを含むディレクトリを指す論理スキーマを使用して、ファイル・モデルを作成します。

2. フラット・ファイルの異なるレコード書式および構造を識別します。例3-1では、注文および注文明細行の2つのレコード書式を識別できます。

3. 識別した各レコード書式について、次を行います。

1. レコード・タイプごとに、ファイル・モデル内にデータストアを作成します。
例3-1の場合は2つのデータストアを作成します。

2. データストア・エディタの「定義」タブで、「名前」フィールドに一意の名前を入力し、「リソース名」フィールドにフラット・ファイルの名前を入力します。リソース名は、このモデルのすべてのデータストアで同じです。
例3-1の場合は、データストアの名前としてORDERSおよびORDER_LINESを使用できます。両方のデータストアの「リソース名」フィールドにorders.txtと入力します。

3. 「ファイル」タブで、使用するフラット・ファイルの形式に応じて「ファイル形式」リストから「固定」または「区切り」を選択し、レコードおよびフィールドのセパレータを指定します。

4. 「属性」タブに、このレコード・タイプの属性定義を入力します。

5. 1つ以上の属性を使用してレコード・タイプを識別できます。レコード・コードは、ファイルで検出される要素を区別する際に使用される、フィールド値の内容です。レコード・コードは一意である必要があり、これにより複数のレコード・パターンを持つファイルの処理が可能になります。「レコード・コード」フィールドでは、複数の値をセミコロン(;)文字で区切って指定できます。
属性エディタで、「レコード・コード」フィールドの各レコード・タイプに対してレコード・コードを割り当てます。

例3-1の場合は、ORDERSデータストアのCODE_REC属性の「レコード・コード」フィールドにORDと入力し、ORDER_LINESデータストアのCODE_REC属性の「レコード・コード」フィールドにLINと入力します。

このように定義することで、ORDERSデータストアからデータを読み取る際に、ファイル・ドライバでは最初の属性に値ORDが含まれているレコードのみがフィルタ処理されます。ORDER_LINESデータストアでも同様です(最初の属性に値LINが含まれているレコードのみが戻されます)。

3.6.2 ファイルへのデータの統合

ファイルをマッピングのソースおよびターゲットとして使用できます。ファイルでのデータ統合戦略は、ステージング領域からファイルへのロードに関係します。「統合ナレッジ・モジュール」タブのIKMの選択によって、統合のパフォーマンスおよび可能性が決まります。

Oracle Data Integratorには、ファイル・データを統合するための2つの統合ナレッジ・モジュールが用意されています。

- IKM SQL to File Append

- IKM File to File (Java)

3.6.2.1 IKM SQL to File Append

IKM SQL to File Appendでは、ファイル・ドライバを使用して、ステージング領域からファイル・ターゲットへ切捨て挿入モードでデータを統合します。

このKMのオプションは次のとおりです。

- INSERT: マッピングのターゲット・データストアへのデータの挿入を自動的に試行します。

- CREATE_TARG_TABLE: ターゲット表を作成します。

- TRUNCATE: ターゲット・ファイルの内容を削除し、ターゲット・ファイルが存在しない場合にはファイルを作成します。

- GENERATE_HEADER: デリミタ付きファイルのヘッダー行を作成します。

このKM以外に、ステージング領域のテクノロジ固有のIKMも使用できます。それらのKMではテクノロジ固有の最適化がサポートされており、ローダーや外部表などが使用されます。

3.6.2.2 IKM File to File (Java)

IKM File to File (Java)は、File-to-Fileユースケースを処理するためのソリューションです。このIKMでは、ファイルを処理するためのJavaプログラムを生成することで統合のパフォーマンスが最適化されます。データストアのリソース名にワイルドカードが含まれる場合、複数のソース・ファイルを処理できます。このプログラムでは、複数のスレッドを使用して変換を実行できます。

IKM File to File (Java)には、ロギングおよびエラー処理のためのKMオプション(BAD_FILE)が用意されています。

このIKMでは、必要に応じてフィールドをテキスト・デリミタで囲むことができる、フラットなデリミタ付きファイルおよび固定ファイルがサポートされています。EBCDICおよびXML形式はサポートされていません。

IKM File to File (Java)の使用

IKM File to File (Java)を使用するには、ステージング領域がファイル・データ・サーバー上に存在する必要があります。これは、新しいマッピングを作成する際のデフォルト構成です。ステージング領域は、ファイル・テクノロジであるターゲット上に配置されます。

IKM File to File (Java)では、マッピングおよびフィルタがサポートされています。マッピングおよびフィルタは常にソースまたはステージング領域上で実行され、ターゲット上で実行されることはありません。マッピング式とフィルタを定義するときに、Java構文を使用します。マッピング式およびフィルタ条件は、改行を含めずに1行で記述する必要があることに注意してください。IKMでは、標準のJavaデータ型(文字列、数値および日付)がサポートされており、これらのデータ型に対してJava変換を使用できます。

次に、マッピング式の例を2つ示します。

- FIC.COL1.toLower()

- FIC.COL1+FIC.COL2

2番目の例では、COL1およびCOL2が数値の場合、IKMによって両方の数の合計が計算されます。それ以外の場合は、2つの文字列が連結されます。

次に、フィルタ条件の例を2つ示します。

- FIC.COL1.equals("ORDER")

- (FIC.COL1==FIC.COL2)&&(FIC.COL3 !=None)

次のオブジェクトおよび機能はサポートされていません。

- 結合

- データセット

- チェンジ・データ・キャプチャ(CDC)

- フロー制御

- ルックアップ

複数のファイルの処理

IKM File to File (Java)では、複数のソース・ファイルを処理できます。複数のソース・ファイルを指定するには、データストアのリソース名にワイルドカードを使用します。PROCESSED_FILE_PREFIXおよびPROCESSED_FILE_SUFFIX KMオプションを使用すると、処理後にファイル名を変更することでソース・ファイルを管理できます。

ロギング機能の使用

マッピングの完了後、Oracle Data IntegratorではKMオプションに従って次の出力ファイルが生成されます。

- ログ・ファイル: このファイルには、ソース・ファイル、ターゲット・ファイルおよび不良ファイルの名前、主要なKMオプションに設定された値のサマリー、エラー・メッセージ(ある場合)、処理された行に関する統計情報など、ロード・プロセスに関する情報が含まれます。

例3-2 ログ・ファイル

Source File: /xxx/abc.dat
Target File: /yyy/data/target_file.dat
Bad File: /yyy/log/target_file.bad

Header Number to skip: 1
Errors allowed: 3
Insert option: APPEND (could be REPLACE)
Thread: 1

ERROR LINE 100: FIELD COL1 IS NOT A DATE
ERROR LINE 120: UNEXPECTED ERROR

32056 Rows susccessfully read
2000 Rows not loaded due to data filter
2 Rows not loaded due to data errors

30054 Rows successfully loaded

- 不良ファイル: このファイルには、処理できなかった各行が記録されます。エラーが発生しなかった場合、不良ファイルは空になります。

KMオプション

このKMのオプションは次のとおりです。

- JAVA_HOMEは、JDKのbinディレクトリへのフル・パスを示します。このオプションが設定されていない場合は、ODI Javaホームが使用されます。

- APPENDは、Yesに設定されている場合、変換済のデータをターゲット・ファイルに追加します。Noに設定されている場合、ファイルは上書きされます。

- DISCARDMAXは、不良ファイルに破棄されるレコードの最大数を示します。破棄されたレコードの数が、このオプションで指定された数を上回る場合、マッピングは失敗します。

注意:
ロールバックはサポートされていません。挿入されたレコードはそのまま残ります。

- MAX_NB_THREADSは、データの処理に使用されるパラレル・スレッドの数を示します。

- BAD_FILEは不良ファイル名を示します。このオプションが設定されていない場合、不良ファイル名は自動的に生成され、不良ファイルはターゲットの作業スキーマに書き込まれます。

- SOURCE_ENCODINGは、ソース・ファイルの文字セット・エンコーディングを示します。デフォルトはマシンのデフォルトのエンコーディングです。

- TARGET_ENCODINGは、ターゲット・ファイルの文字セット・エンコーディングを示します。デフォルトはマシンのデフォルトのエンコーディングです。

- REMOVE_TEMPORARY_OBJECTSは、Yesに設定されている場合、ログ・ファイルおよび不良ファイルを削除します。

- PROCESSED_FILE_PREFIXは、処理後にソース・ファイル名に追加される接頭辞を示します。

- PROCESSED_FILE_SUFFIXは、処理後にソース・ファイル名に追加される接尾辞を示します。

4 汎用SQL

この章では、ANSI SQL-92構文をサポートしているテクノロジのOracle Data Integratorでの使用方法について説明します。

注意:
これは汎用情報の章です。この章の情報は、ANSI SQL-92構文をサポートしているテクノロジ(Oracle、Microsoft SQL Server、Sybase ASE、IBM DB2、Teradata、PostgreSQL、MySQL、Derbyなど)に適用できます。
ANSI SQL-92準拠の一部のテクノロジについては、このガイドの別の章で説明しています。特定のテクノロジのODI最適化およびデータベース・ユーティリティの利用方法に関する具体的な情報は、専用のテクノロジ関連の章を参照してください。

この章には次の項が含まれます:

- 4.1項「概要」

- 4.2項「インストールおよび構成」

- 4.3項「トポロジの設定」

- 4.4項「統合プロジェクトの設定」

- 4.5項「モデルの作成およびリバース・エンジニアリング」

- 4.6項「チェンジ・データ・キャプチャの設定」

- 4.7「データ品質の設定」

- 4.8項「マッピングの設計」

4.1 概要

Oracle Data Integratorでは、ANSI SQL-92標準準拠のテクノロジがサポートされます。

4.1.1 概念

ANSI SQL-92標準準拠テクノロジで使用される概念と、Oracle Data Integratorの概念のマッピングでは、Oracle Data Integratorのデータ・サーバーは、データを表形式で格納して処理するデータ処理リソースに対応します。このリソースは、テクノロジに応じて、データベース、インスタンス、サーバーなどと呼ばれます。このリソース内で、1つの下位区分が、1つのOracle Data Integrator物理スキーマにマップされます。この下位区分は、スキーマ、データベース、カタログ、ライブラリなどと呼ばれます。1つのスキーマ内の関連する一連のオブジェクトが1つのデータ・モデルに対応し、各表、ビューまたはシノニムが、その属性、列および制約とともにODIデータストアとして表示されます。

4.1.2 ナレッジ・モジュール

Oracle Data Integratorには、ANSI SQL-92標準準拠テクノロジに格納されているデータを処理するための、幅広いナレッジ・モージュールが用意されています。表4-1にリストされているナレッジ・モジュールは、汎用SQLナレッジ・モジュールであり、最も一般的なANSI SQL-92標準準拠のデータベースに適用されます。

また、特定のユーティリティを利用するために、Oracle Data Integratorには一部の特定データベース専用のナレッジ・モジュールも用意されています。ローダーまたは外部表などの機能を使用するテクノロジ固有のKMは、対応するテクノロジの章にリストされています。

表4-1 汎用SQL KM

ナレッジ・モジュール

説明

CKM SQL

データストアで定義された制約と照合して、データの整合性をチェックします。無効なレコードを拒否して、動的に作成されるエラー表に格納します。フロー制御および静的制御に使用できます。

ANSI SQL-92準拠のデータベースでデータの整合性をチェックする場合は、このKMの使用を検討してください。使用するデータベース固有のCKMが存在する場合は、かわりにそのCKMを使用してください。

IKM SQL Control Append

置換/追加モードでANSI SQL-92準拠ターゲット表にデータを統合します。CKMを使用してフロー・データをチェックする必要がある場合は、CKMを起動する前に一時的なステージング表が作成されます。フロー制御をサポートします。

置換モードで(データ整合性チェックを行って、もしくは行わずに)SQL準拠のターゲット表をロードする場合は、このIKMの使用を検討してください。

このIKMを使用するには、ステージング領域がターゲットと同じデータ・サーバー上にあることが必要です。

IKM SQL Incremental Update

増分更新モードでANSI SQL-92準拠のターゲット表にデータを統合します。このKMにより、データ・フローをステージングするための一時ステージング表が作成されます。次に、挿入するレコードと更新するレコードを判別するために、その内容がターゲット表と比較されます。また、CKMを起動してデータ整合性チェックを実行することもできます。このため、このKMを大量のデータに対して使用することはお薦めしません。フロー制御をサポートします。

ANSI SQL-92準拠のターゲット表をロードして、欠落しているレコードを挿入し、既存のレコードを更新する場合は、このKMの使用を検討してください。可能な場合は常に、パフォーマンスがより最適化されている、テクノロジ固有の増分更新IKMを使用してください。

このIKMを使用するには、ステージング領域がターゲットと同じデータ・サーバー上にあることが必要です。

IKM SQL Incremental Update (row by row)

増分更新モードでANSI SQL-92準拠のターゲット・データベースにデータを統合します。このIKMは、行ごとにデータを処理し、既存の行を更新し、存在しない行を挿入します。無効なデータはエラー表に分離され、再利用できます。このIKMをジャーナル化されたソース表と組み合せて使用する場合は、削除を同期できます。フロー制御をサポートします。

IKM SQL to File Append

ANSI SQL-92準拠ステージング領域からターゲット・ファイルへ、置換モードでデータを統合します。フロー制御をサポートします。

データを変換してターゲット・ファイルにエクスポートする場合は、このIKMの使用を検討してください。ソース・データストアが同じデータ・サーバー上にある場合は、余分なロード・フェーズ(LKM)を発生させないために、このデータ・サーバーをステージング領域として使用することをお薦めします。

このIKMを使用するには、ステージング領域がターゲットと異なる必要があります。

IKM SQL to SQL Control Append

任意のANSI-SQL92準拠のステージング領域からANSI-SQL92準拠のターゲット・データベースへデータを統合します。フロー制御をサポートします。

通常、このIKMはETL構成に使用されます。この構成では、ソース表とターゲット表は異なるデータベースにあり、マッピングのステージング領域は、ソース表の論理スキーマまたは第3のスキーマに設定されます。

IKM SQL to SQL Incremental Update

任意のANSI SQL-92準拠データベースから任意のANSI SQL-92準拠データベースのターゲット表へ、増分更新モードでデータを統合します。フロー制御をサポートします。

通常、このIKMはETL構成に使用されます。この構成では、ソース表とターゲット表は異なるデータベースにあり、マッピングのステージング領域は、ソース表の論理スキーマまたは第3のスキーマに設定されます。

IKM SQL Insert

追加モードでANSI SQL-92ターゲット表にデータを統合します。単一のINSERT SQL文で、ターゲット表にデータが直接ロードされます。組込みKMです。

IKM SQL Update

増分更新モードでANSI SQL-92のターゲット表にデータを統合します。単一のUPDATE SQL文で、ターゲット表にデータが直接ロードされます。組込みKMです。

IKM SQL Merge

増分更新モードでANSI SQL-92のターゲット表にデータを統合します。単一のMERGE SQL文で、ターゲット表にデータが直接ロードされます。組込みKMです。

LKM File to SQL

ASCIIファイルまたはEBCDICファイルから、ステージング領域として使用されるANSI SQL-92準拠データベースへ、データをロードします。エージェントを使用してソース・ファイルから選択されたデータを読み取り、動的に作成された一時ステージング表に結果を書き込みます。

ソース・データストアのいずれかがASCIIまたはEBCDICファイルの場合は、このLKMの使用を検討してください。可能であれば、パフォーマンスがより最適化されている、テクノロジ固有のLKMをターゲット・ステージング領域に使用してください。たとえば、Oracleデータベースにロードするときには、LKM File to Oracle (SQLLDR)またはLKM File to Oracle (EXTERNAL TABLE)を使用してください。

LKM SQL to File

ターゲット・フラット・ファイルにデータをロードおよび統合します。このLKMでは、IKMの設定が無視されます。組込みKMです。

LKM SQL to SQL

ANSI SQL-92準拠のデータベースからANSI SQL-92準拠のステージング領域へデータをロードします。エージェントを使用してソース・データベースから選択されたデータを読み取り、動的に作成された一時ステージング表に結果を書き込みます。

ソース・データストアがステージング領域と異なるSQL準拠のデータベース上にある場合は、このLKMの使用を検討してください。可能な場合は常に、パフォーマンスがより最適化されているテクノロジ固有のLKMを、ソースおよびターゲットのステージング領域に使用してください。たとえば、Oracleソース・サーバーからOracleステージング領域にロードするときには、LKM Oracle to Oracle (dblink)を使用してください。

LKM SQL to SQL (Built-in)

ANSI SQL-92準拠のデータベースからANSI SQL-92準拠のステージング領域へデータをロードします。エージェントを使用してソース・データベースから選択されたデータを読み取り、動的に作成された一時ステージング表に結果を書き込みます。ソース実行ユニットに指定された抽出オプションを使用してソース問合せが生成されます。組込みKMです。

LKM SQL to SQL (row by row)

ISO-92データベースからISO-92準拠のターゲット・データベースにデータをロードします。このLKMでは、Jythonスクリプトを使用してデータベースから選択されたデータを読み取り、動的に作成されたターゲット一時表に結果を書き込みます。これは、ステージング領域からターゲットへデータをロードし、処理された各行の状態を示します。

次のオプションがロギング・メカニズムに使用されます。

- MAX_ERRORS: エラーの最大数を指定します。
このオプションで指定したエラーの最大数に達すると、LKMプロセスが停止します。

大量のデータを扱う場合には、このナレッジ・モジュールはお薦めしません。バルク・ユーティリティ(SQL*LOADER、BULK INSERTなど)または直接リンク(DBLINKS、リンク・サーバーなど)を使用する他のモジュールの方が、通常効率的です。

LKM SQL to SQL (JYTHON)

ANSI SQL-92準拠のデータベースからANSI SQL-92準拠のステージング領域へデータをロードします。Jythonを使用してソース・データベースから選択されたデータを読み取り、動的に作成された一時ステージング表に結果を書き込みます。このLKMでは、提供されている基礎的なJythonコードを編集して、ソース・データベースとターゲット・ステージング領域の間のデフォルトJDBCデータ型バインディングを変更できます。

ソース・データストアがステージング領域と異なるANSI SQL-92準拠のデータベースにあり、独自のデータ型バインディング方法を指定する場合は、このLKMの使用を検討してください。

可能な場合は常に、パフォーマンスがより最適化されているテクノロジ固有のLKMを、ソースおよびターゲットのステージング領域に使用してください。たとえば、Oracleソース・サーバーからOracleステージング領域にロードするときには、LKM Oracle to Oracle (dblink)を使用してください。

LKM SQL Multi-Connect

ターゲット表に対する複数接続IKMの使用を有効にします。組込みIKMです。

RKM SQL (JYTHON)

任意のANSI SQL-92準拠データベースから、表、ビュー、システム表および列のJDBCメタデータを取得します。このRKMを使用して、JDBCメタデータをOracle Data Integratorメタデータに変換するための独自の戦略を指定することも可能です。

使用するJDBCドライバの特異性により、標準のJDBCリバースエンジニアリング・プロセスで問題が発生した場合は、このRKMの使用を検討してください。このRKMでは、JDBCドライバの特異性に合せて、基礎となるJythonコードを編集できます。

SKM SQL

ANSI SQL-92準拠データベースのデータ・アクセスWebサービスを生成します。データ・アクセス・サービスには、レコードの追加、削除、更新またはフィルタリングなどのデータ操作の他、変更されたデータの取得などのチェンジ・データ・キャプチャ操作が含まれます。データ操作は、データストアの制約による定義に従って、整合性チェックの影響を受けます。

データ操作またはチェンジ・データ・キャプチャのWebサービスを生成してサービス指向アーキテクチャ・インフラストラクチャにデプロイする場合は、このSKMの使用を検討してください。使用するデータベース固有のSKMが存在する場合は、かわりにそのSKMを使用してください。

4.2 インストールおよび構成

汎用SQLナレッジ・モジュールの使用を開始する前に、この項の情報を必ず読んでください。

- システム要件および動作要件

- テクノロジ固有の要件

- 接続性要件

4.2.1 システム要件および動作要件

インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。

サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。

http://www.oracle.com/technology/products/oracle-data-integrator/index.html

4.2.2 テクノロジ固有の要件

詳細は、特定のテクノロジに関する章の「テクノロジ固有の要件」の項を参照してください。

使用するテクノロジ専用の章がこのガイドに含まれていない場合は、使用するテクノロジのドキュメントでテクノロジ固有の要件を確認してください。

4.2.3 接続性要件

詳細は、特定のテクノロジに関する章の「接続性要件」の項を参照してください。

Java Database Connectivity (JDBC)は、データベースおよび他のデータソースに接続するための標準です。使用するテクノロジ専用の章がこのガイドに含まれていない場合は、使用するテクノロジのドキュメントを参照して、JDBC構成情報(ドライバ・ファイル、ドライバ名およびJDBC URL書式の要件を含む)を確認してください。

4.3 トポロジの設定

トポロジの設定には次が含まれます。

1. データ・サーバーの作成

2. 物理スキーマの作成

4.3.1 データ・サーバーの作成

『Oracle Data Integratorでの統合プロジェクトの開』のデータ・サーバーの作成に関する項の説明に従って、標準の手順を使用して、「物理アーキテクチャ」アコーディオン内にリストされているANSI SQL-92準拠テクノロジに基づくデータ・サーバーを作成します。

使用するテクノロジ専用の章がこのガイドに含まれている場合は、その章で詳細を確認してください。含まれていない場合は、そのテクノロジのドキュメントを参照してJDBCドライバ名およびJDBC URL書式を確認してください。

4.3.2 物理スキーマの作成

『Oracle Data Integratorの管理』の物理スキーマの作成に関する項の説明に従って、標準の手順を使用して物理スキーマを作成します。

使用するテクノロジ専用の章がこのガイドに含まれている場合は、その章で詳細を確認してください。

4.4 統合プロジェクトの設定

ANSI SQL-92準拠のデータベースを使用してプロジェクトを設定するには、標準の手順に従います。『Oracle Data Integratorでの統合プロジェクトの開発』の統合プロジェクトの作成に関する項を参照してください。

作業を開始するにあたって使用するプロジェクトにインポートする推奨のナレッジ・モジュールは、対応するテクノロジによって異なります。使用するテクノロジ専用の章がこのガイドに含まれている場合は、その章で詳細を確認してください。

4.5 モデルの作成およびリバース・エンジニアリング

この項には次のトピックが含まれます:

- データ・モデルの作成

- データ・モデルのリバース・エンジニアリング

4.5.1 データ・モデルの作成

『Oracle Data Integratorでの統合プロジェクトの開発』のモデルの作成に関する項の説明に従って、標準の手順を使用してANSI SQL-92準拠テクノロジに基づくデータ・サーバーを作成します。

使用するテクノロジ専用の章がこのガイドに含まれている場合は、その章で詳細を確認してください。

4.5.2 データ・モデルのリバース・エンジニアリング

ANSI SQL-92標準準拠テクノロジでは、JDBCドライバの機能のみを使用する標準のリバース・エンジニアリング、およびロギング機能を提供するRKMを使用するカスタマイズされたリバース・エンジニアリングの両方がサポートされています。

通常は、このRKM SQL (Jython)のかわりに標準のJDBCリバース・エンジニアリングを使用することを検討してください。ただし、独自のメタデータのリバース・エンジニアリング動作を追加してRKMを拡張する場合は、このRKMを土台として使用できます。

標準のリバース・エンジニアリング

ANSI SQL-92テクノロジで標準のリバースエンジニアリングを実行するには、『Oracle Data Integratorでの統合プロジェクトの開発』のモデルのリバースエンジニアリングに関する項の説明に従って、通常の手順を使用します。

使用するテクノロジ専用の章がこのガイドに含まれている場合は、その章で詳細を確認してください。

カスタマイズされたリバース・エンジニアリング

RKMを使用してANSI SQL-92テクノロジでカスタマイズされたリバースエンジニアリングを実行するには、『Oracle Data Integratorでの統合プロジェクトの開発』のモデルのリバースエンジニアリングに関する項の説明に従って、通常の手順を使用します。この項では、RKM SQL (Jython)の使用に固有のフィールドのみについて説明します。

このRKMでは、次のロギング・オプションが提供されます。

USE_LOG: リバース・エンジニアリングによってログ・ファイル内のログ詳細が処理されるように指定する場合は、Yesに設定します。

4.6 チェンジ・データ・キャプチャの設定

Oracle Data Integratorには、ANSI SQL-92準拠テクノロジ用のジャーナル化ナレッジ・モジュールは用意されていません。

4.7 データ品質の設定

Oracle Data Integratorには、ANSI SQL-92準拠の表で定義された制約と照合してデータの整合性をチェックするためのCKM SQLが用意されています。詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』のフロー制御および静的制御に関する項を参照してください。

4.8 マッピングの設計

ANSI SQL-92準拠テクノロジは、マッピングのソース、ステージング領域またはターゲットとして使用できます。また、ANSI SQL-92準拠テクノロジに基づくETL形式のマッピングを作成することもできます。

マッピングまたはチェック用に選択したKMによって、このマッピングまたはチェックの機能およびパフォーマンスが決まります。この項に示す推奨事項は、ANSI SQL-92準拠テクノロジに基づくデータ・サーバーに関連する様々な状況でのKMの選択に役立ちます。

4.8.1 ANSI SQL-92準拠テクノロジとの間でのデータのロード

マッピングのソース、ターゲットまたはステージング領域としてANSI SQL-92準拠テクノロジを使用できます。「ロード・ナレッジ・モジュール」タブでの、ANSI SQL-92準拠テクノロジと別のタイプのデータ・サーバー間でデータをロードするためのLKMの選択は、マッピングのパフォーマンスに関してきわめて重要です。

4.8.1.1 ANSI SQL-92準拠テクノロジからのデータのロード

表4-2にリストされている汎用KMでは、ANSI SQL-92準拠データベースからターゲットまたはステージング領域のデータベースへデータをロードするための方法が実装されます。これらのKM以外に、Oracle Data Integratorにはターゲットまたはステージング領域のデータベース固有のKMも用意されています。使用するテクノロジ専用の章がこのガイドに含まれている場合は、その章で詳細を確認してください。

表4-2 ANSI SQL-92準拠テクノロジからロードするためのKM

ソースまたはステージング領域

KM

説明

ANSI SQL-92準拠テクノロジ

LKM SQL to SQL

SQL-92からSQL-92へ転送するための標準KM。

ANSI SQL-92準拠テクノロジ

LKM SQL to SQL (Built-in)

JDBCを使用してエージェント経由でSQL-92からSQL-92へ転送するための組込みKM。

ANSI SQL-92準拠テクノロジ

LKM SQL to SQL (Jython)

Jythonを使用してソース・データベースから選択されたデータを読み取り、動的に作成された一時ステージング表に結果を書き込みます。このLKMでは、提供されている基礎的なJythonコードを編集して、ソース・データベースとターゲット・ステージング領域の間のデフォルトJDBCデータ型バインディングを変更できます。

ANSI SQL-92準拠テクノロジ

LKM SQL to SQL (row by row)

このLKMでは行ごとのロギングが使用されます。

ANSI SQL-92準拠テクノロジ

LKM SQL to File

SQL-92からフラット・ファイルへ転送するための組込みKM。

4.8.1.2 ANSI SQL-92準拠テクノロジへのデータのロード

表4-3にリストされている汎用KMには、ソースまたはステージング領域からANSI SQL-92準拠データベースへデータをロードするための方法が実装されています。これらのKM以外に、Oracle Data Integratorにはソースまたはステージング領域のデータベース固有のKMも用意されています。使用するテクノロジ専用の章がこのガイドに含まれている場合は、その章で詳細を確認してください。

表4-3 ANSI SQL-92準拠テクノロジへロードするためのKM

ソースまたはステージング領域

KM

説明

ファイル

LKM File to SQL

標準のKM。

ANSI SQL-92準拠テクノロジ

LKM SQL to SQL

標準のKM。

ANSI SQL-92準拠テクノロジ

LKM SQL to SQL (Built-in)

JDBCを使用してエージェント経由でSQL-92からSQL-92へ転送するための組込みKM。

ANSI SQL-92準拠テクノロジ

LKM SQL to SQL (Jython)

Jythonを使用してソース・データベースから選択されたデータを読み取り、動的に作成された一時ステージング表に結果を書き込みます。このLKMでは、提供されている基礎的なJythonコードを編集して、ソース・データベースとターゲット・ステージング領域の間のデフォルトJDBCデータ型バインディングを変更できます。

ANSI SQL-92準拠テクノロジ

LKM SQL to SQL (row by row)

このLKMでは行ごとのロギングが使用されます。

4.8.2 ANSI SQL-92準拠テクノロジでのデータの統合

ANSI SQL-92準拠テクノロジはマッピングのターゲットとして使用できます。「統合ナレッジ・モジュール」タブのIKMの選択によって、統合のパフォーマンスおよび可能性が決まります。

表4-4にリストされているKMには、ANSI SQL-92準拠のターゲットにデータを統合するための方法が実装されています。これらのKM以外に、Oracle Data Integratorにはソースまたはステージング領域のデータベース固有のKMも用意されています。詳細は、対応するテクノロジの章を参照してください。

表4-4 ANSI SQL-92準拠テクノロジにデータを統合するためのKM

ソースまたはステージング領域

KM

説明

ANSI SQL-92準拠テクノロジ

IKM SQL Control Append

データ・サーバー内部でバルク・データ移動を使用します。フロー制御をサポートします。

ANSI SQL-92準拠テクノロジ

IKM SQL Incremental Update

データ・サーバー内部でバルク・データ移動を使用します。フロー制御をサポートします。

ANSI SQL-92準拠テクノロジ

IKM SQL Incremental Update (row by row)

データ・サーバー内部でバルク・データ移動を使用して、行ごとにデータを処理します。フロー制御をサポートします。

ANSI SQL-92準拠テクノロジ

IKM SQL Insert

データ移動にSQL INSERT文を使用します。組込みKMです。

ANSI SQL-92準拠テクノロジ

IKM SQL Update

データ移動にSQL UPDATE文を使用します。組込みKMです。

ANSI SQL-92準拠テクノロジ

IKM SQL Merge

データ移動にSQL MERGE文を使用します。組込みKMです。

ANSI SQL-92準拠テクノロジ

IKM SQL to File Append

データ移動にエージェントを使用します。フロー制御をサポートします。

ANSI SQL-92準拠テクノロジ

IKM SQL to SQL Incremental Update

データ移動にエージェントまたはJYTHONを使用します。フロー制御をサポートします。

ANSI SQL-92準拠テクノロジ

IKM SQL to SQL Control Append

制御追加戦略にエージェントを使用します。フロー制御をサポートします。

4.8.3 ETL形式マッピングの設計

マッピングの設計方法に関する一般的な情報は、『Oracle Data Integratorでの統合プロジェクトの開発』のマッピングの作成に関する項を参照してください。この項では、ステージング領域およびターゲットがANSI SQL-92準拠であるETL形式マッピングの設計方法について説明します。

ETL形式マッピングでは、ターゲットとは異なるステージング領域内のデータが、ODIによって処理されます。Oracle Data Integratorでは、ANSI SQL-92準拠のステージング領域からANSI SQL-92準拠のターゲットへデータをロードするための2つの方法が提供されます。

- 複数接続IKMの使用

- LKMおよび単一接続IKMの使用

使用するKM戦略によって、フロー制御および静的制御がサポートされます。

複数接続IKMの使用

複数接続IKMでは、ステージング領域とソースが異なるデータ・サーバー上にある場合のターゲットの更新が可能です。

Oracle Data Integratorには、ANSI SQL-92準拠テクノロジ用の複数接続IKMであるIKM SQL to SQL Incremental UpdateおよびIKM SQL to SQL Control Appendが用意されています。

複数接続IKMを使用する状況の詳細は、表4-5を参照してください。

ETL形式マッピングで複数接続IKMを使用するには、次のようにします。

1. 『Oracle Data Integratorでの統合プロジェクトの開発』のマッピングの作成に関する項の説明に従って、標準の手順を使用して、ステージング領域およびターゲットがANSI SQL-92準拠であるマッピングを作成します。この項では、ETL形式固有の手順のみを説明します。

2. ソース表の論理スキーマまたは第3のスキーマに対するマッピングのステージング領域を変更します。ステージング領域の変更方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』の実行場所の構成に関する項を参照してください。

3. 物理ダイアグラムでアクセス・ポイントを選択します。このオブジェクトのプロパティ・インスペクタが開きます。

4. 「ロード・ナレッジ・モジュール」タブで、ソースからステージング領域にロードするLKMを選択します。使用できるLKMは表4-5を参照してください。

5. 必要な場合は、KMオプションを変更します。

6. 物理ダイアグラムでターゲットのタイトルをクリックしてターゲットを選択します。このオブジェクトのプロパティ・インスペクタが開きます。
「統合ナレッジ・モジュール」で、ステージング領域からターゲットにデータをロードするETL複数接続IKMを選択します。使用できるIKMは表4-5を参照してください。

KMオプションを設定する際には、次の点に注意してください。

- IKM SQL to SQL Incremental Updateに関する注意事項

- ターゲット・システム上に表を作成しない場合は、FLOW_CONTROL=falseおよびFLOW_TABLE_LOCATION=STAGINGを設定します。
ただし、この設定は行ごとの処理につながるため、パフォーマンスが著しく低下します。

- FLOW_CONTROLまたはSTATIC_CONTROLオプションをtrueに設定した場合は、「チェック・ナレッジ・モジュール」タブでCKMを選択します。FLOW_CONTROLをtrueに設定した場合は、FLOW_TABLE_LOCATIONの値に関係なく、フロー表がターゲット上に作成されます。

- FLOW_TABLE_LOCATIONオプションに指定できる値は次のとおりです。

値

説明

コメント

TARGET

オブジェクトがターゲット上に作成されます。

デフォルト値。

STAGING

オブジェクトはターゲット上ではなく、ステージング領域のみに作成されます。

フロー制御では使用できません。行ごとの処理につながるため、パフォーマンスが損なわれます。

NONE

ステージング領域とターゲットのどちらにもオブジェクトは作成されません。

フロー制御では使用できません。行ごとの処理につながるため、パフォーマンスが損なわれます。ジャーナル化されたデータソースの場合は、ソース・データを2回読み取る必要があります。

LKMおよび単一接続IKMの使用

専用の複数接続IKMがない場合は、標準のエクスポートLKMと標準の単一接続IKMを組み合せて使用します。エクスポートLKMは、ステージング領域からターゲットへフロー表をロードするために使用します。単一接続IKMは、データ・フローをターゲット表に統合するために使用します。

Oracle Data Integratorでは、ETL形式マッピングのソース、ステージング領域およびターゲットとして、任意のANSI SQL-92標準準拠テクノロジがサポートされています。

標準のLKMおよび単一接続IKMを組み合せて使用する状況の詳細は、表4-5を参照してください。

ETL形式マッピングでLKMおよび単一接続IKMを使用するには、次のようにします。

1. 『Oracle Data Integratorでの統合プロジェクトの開発』のマッピングの作成に関する項の説明に従って、標準の手順を使用して、ステージング領域およびターゲットがANSI SQL-92準拠であるマッピングを作成します。この項では、ETL形式固有の手順のみを説明します。

2. ソース表の論理スキーマまたは第3のスキーマに対するマッピングのステージング領域を変更します。ステージング領域の変更方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』の実行場所の構成に関する項を参照してください。

3. 物理ダイアグラムでアクセス・ポイントを選択します。このオブジェクトのプロパティ・インスペクタが開きます。

4. 「ロード・ナレッジ・モジュール」タブで、ソースからステージング領域にロードするLKMを選択します。使用できるLKMは表4-5を参照してください。

5. 必要な場合は、KMオプションを変更します。

6. ステージング領域に対するアクセス・ポイントを選択します。このオブジェクトのプロパティ・インスペクタが開きます。

7. 「ロード・ナレッジ・モジュール」タブで、ステージング領域からターゲットにロードするLKMを選択します。使用できるLKMは表4-5を参照してください。

8. 必要な場合は、オプションを変更します。

9. 「ターゲット」のタイトルをクリックしてターゲットを選択します。このオブジェクトのプロパティ・インスペクタが開きます。

10. 「統合ナレッジ・モジュール」タブで、ターゲットを更新する標準単一接続IKMを選択します。使用できるIKMは表4-5を参照してください。

表4-5 ANSI SQL-92標準準拠テクノロジに基づくETL形式マッピングのKMガイドライン

ソース

ステージング領域

ターゲット

エクスポートLKM

IKM

KM戦略

コメント

ANSI SQL-92標準準拠

ANSI SQL-92標準準拠データベース

ANSI SQL-92標準準拠データベース

なし

IKM SQL to SQL Incremental Update

複数接続IKM

ターゲット側一時オブジェクトでの増分更新戦略が可能です。ターゲット・サーバーで一時オブジェクトを作成できない場合に、このKMを使用します。

アプリケーションの更新は、ソースからターゲットへ直接行われ、ターゲット上に一時オブジェクトは作成されません。フロー表がターゲットではなくステージング領域に作成される構成は、データ量が少ない場合のみ使用してください。

フロー制御および静的制御をサポートします。

ANSI SQL-92標準準拠

ANSI SQL-92標準準拠データベース

ANSI SQL-92標準準拠データベース

なし

IKM SQL to SQL Control Append

複数接続IKM

このKMは、制御追加を実行する場合に使用します。

フロー制御および静的制御をサポートします。

ANSI SQL-92標準準拠

ANSI SQL-92標準準拠データベース

ANSI SQL-92標準準拠データベース

ANSI SQL-92標準準拠テクノロジからANSI SQL-92標準準拠テクノロジへロードする任意の標準KM

IKM SQL Incremental Update

単一接続IKM

増分更新戦略が可能です。

5 XMLファイル

この章では、Oracle Data IntegratorでのXMLファイルの使用方法について説明します。

この章には次の項が含まれます:

- 5.1項「概要」

- 5.2項「インストールおよび構成」

- 5.3項「トポロジの設定」

- 5.4項「統合プロジェクトの設定」

- 5.5項「XMLファイルの作成およびリバース・エンジニアリング」

- 5.6項「マッピングの設計」

- 5.7項「トラブルシューティング」

5.1 概要

Oracle Data Integratorでは、Oracle Data Integrator Driver for XMLを介したXMLファイル統合がサポートされます。

5.1.1 概念

XMLの概念は、次のようにOracle Data Integratorの概念にマップされます。1つのXMLファイルは、Oracle Data Integratorの1つのデータ・サーバーに対応します。このデータ・サーバー内で、単一のスキーマがXMLファイルの内容にマップされます。Oracle Data Integrator Driver for XML (XMLドライバ)により、XMLファイルの階層構造がリレーショナル・スキーマにロードされます。このリレーショナル・スキーマは、SQLを使用した問合せまたは変更が可能なスキーマ内にある一連の表です。XMLドライバでは、リレーショナル・スキーマをXMLファイルにアンロードして戻すこともできます。リレーショナル・スキーマは、表、列および制約とともに、ODIでデータ・モデルとしてリバース・エンジニアリングされます。このモデルは、ODI内で通常のリレーショナル・データ・モデルと同様に使用されます。リレーショナル・スキーマ内で変更されたデータをXMLファイルに書き込む必要がある場合は、XMLドライバによりリレーショナル・スキーマをファイルに同期化する機能が提供されています。

このドライバの詳細は、付録B「Oracle Data Integrator Driver for XMLの参照情報」を参照してください。

5.1.2 XMLドライバの事前/事後処理サポート

データをXMLドライバに提供する方法をカスタマイズできるようになりました。中間処理ステージを設定して、Oracle Data Integratorを使用して外部エンドポイントから取得されるデータを処理したり、データを外部エンドポイントに書き出すことができます。

XMLドライバの事前および事後処理ステージの構成および実装の詳細は、付録D「XMLおよび複合ファイル・ドライバの事前/事後処理サポート」を参照してください。

5.1.3 ナレッジ・モジュール

Oracle Data Integratorには、XMLデータを処理するためのIKM XML Control Appendが用意されています。このナレッジ・モジュールは、固有のXMLナレッジ・モジュールです。これには、リレーショナル・スキーマからファイルへデータを同期化するための固有のオプションが備えられています。

このKM以外に、XMLデータ・サーバーを任意のSQLデータ・サーバーとして使用することもできます。XMLデータ・サーバーでは、SQLデータ・サーバーをソース指定またはターゲット指定するテクノロジ固有のKMと汎用KMの両方がサポートされています。これらのKMの詳細は、第4章「汎用SQL」またはテクノロジの章を参照してください。

5.2 インストールおよび構成

XMLナレッジ・モジュールの使用を開始する前に、この項の情報を必ず読んでください。

- システム要件

- テクノロジ固有の要件

- 接続性要件

5.2.1 システム要件

インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。

サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。

http://www.oracle.com/technology/products/oracle-data-integrator/index.html

5.2.2 テクノロジ固有の要件

Oracle Data IntegratorでXMLファイルを使用するためのテクノロジ固有の要件はありません。

5.2.3 接続性要件

この項では、XMLデータベースに接続するための要件をリストします。

Oracle Data Integrator Driver for XML

XMLファイルへのアクセスは、Oracle Data Integrator Driver for XMLを介して行われます。このJDBCドライバはOracle Data Integratorとともにインストールされるもので、その他のコンポーネントのインストールや構成は不要です。

システム管理者から次の接続情報を入手する必要があります。

- 使用するXMLファイルに関連付けられているDTDまたはXSDファイルの場所

- 使用するXMLファイルの場所

5.3 トポロジの設定

トポロジの設定には次が含まれます。

1. XMLデータ・サーバーの作成

2. XML用物理スキーマの作成

5.3.1 XMLデータ・サーバーの作成

各XMLデータ・サーバーは、Oracle Data Integratorにアクセス可能な1つのXMLファイルに対応します。

5.3.1.1 データ・サーバーの作成

『Oracle Data Integratorでの統合プロジェクトの開発』のデータ・サーバーの作成に関する項の説明に従って、標準の手順を使用してXMLテクノロジ用のデータ・サーバーを作成します。この項では、ファイル・データ・サーバーの定義に関する必須または固有のフィールドのみについて説明します。

1. 「定義」タブ:

- 名前: Oracle Data Integratorに表示されるデータ・サーバーの名前。

- ユーザー/パスワード: これらのフィールドは、XMLデータ・サーバーでは使用しません。

2. 使用するドライバに応じて、「JDBC」タブに次の値を入力します。

- JDBCドライバ: com.sunopsis.jdbc.driver.xml.SnpsXmlDriver

- JDBC URL: jdbc:snps:xml?[property=value&property=value...]

表5-1に、Oracle Data Integrator Driver for XMLの主なプロパティをリストします。これらのプロパティは、JDBC URL内で指定できます。

これらのプロパティの詳細、およびすべてのプロパティの包括的なリストは、付録B「Oracle Data Integrator Driver for XMLの参照情報」を参照してください。

表5-1 JDBCドライバのプロパティ

プロパティ

値

説明

f

<XMLファイルの場所>

XMLファイル名。パス名には、バックスラッシュ"\"ではなくスラッシュ"/"を使用します。HTTP、FTPまたはファイルのURLを使用してファイルの場所を示すことができます。URLによって示されたファイルは読取り専用です。

d

<DTD/XSDファイルの場所>

記述ファイル。このファイルはDTDまたはXSDファイルです。HTTP、FTPまたはファイルのURLを使用してファイルの場所を示すことができます。URLによって示されたファイルは読取り専用です。

DTDまたはXSDファイルが存在しない場合、リレーショナル・スキーマはXMLファイルの内容のみを使用して作成されることに注意してください。DTDまたはXSDに記述されている使用可能な要素が1つのXMLファイル・インスタンスにすべて含まれていないことで、データ・モデルが不完全になる可能性があるため、このような構造からデータ・モデルをリバース・エンジニアリングすることはお薦めしません。

re

<ルート要素>

スキーマのルート表として選択する要素の名前。この値では大/小文字が区別されます。このプロパティは、WSDLファイルから特定のメッセージ定義をリバース・エンジニアリングする場合や、使用可能なルート要素がXSDファイル内に複数存在する場合などに使用できます。

ro

true | false

trueの場合は、XMLファイルが読取り専用モードで開きます。

s

<スキーマ名>

XMLファイルのロード先となるリレーショナル・スキーマの名前。このプロパティが欠落している場合、XMLファイル名の最初の5文字を名前とするスキーマが自動的に作成されます。

cs

true | false

大/小文字を区別するモードまたは区別しないモードで、XMLファイルがロードされます。区別しないモードの場合は、DTDファイル内のすべての要素名を区別できることが必要です(たとえば、同じファイル内にAbcとabcが存在する場合は、名前の競合が発生します)。

これらのプロパティを次の例に示します。

products.xsdによって説明される、PRODUCTSスキーマ内のPROD20100125_001.xmlに接続する場合の例は次のとおりです。

jdbc:snps:xml?f=/xml/PROD20100125_001.xml&d=/xml/products.xsd&s=PRODUCTS

staff_internal.dtdによって説明されるstaff_internal.xmlファイルに読取り専用モードで接続する場合の例は次のとおりです。スキーマ名はstaffになります。

jdbc:snps:xml?f=/demo/xml/staff_internal.xml&d=/demo/xml/staff_internal.dtd&ro=true&s=staff

5.3.2 XML用物理スキーマの作成

『Oracle Data Integratorの管理』の物理スキーマの作成に関する項の説明に従って、標準の手順を使用してXML物理スキーマを作成します。

URLで設定したスキーマ名が表示されます。「データ・スキーマ」および「作業スキーマ」の両方について、このスキーマを選択します。

『Oracle Data Integratorの管理』の論理スキーマの作成に関する項の説明に従って、標準の手順を使用してこの物理スキーマ用の論理スキーマを作成し、特定のコンテキストで関連付けます。

5.4 統合プロジェクトの設定

XMLデータベースを使用してプロジェクトを設定するには、標準の手順に従います。『Oracle Data Integratorでの統合プロジェクトの開発』の統合プロジェクトの作成に関する項を参照してください。

XMLでの作業を開始するにあたり、使用するプロジェクトに次のナレッジ・モジュールをインポートすることをお薦めします。

- LKM SQL to SQL

- LKM File to SQL

- IKM XML Control Append

5.5 XMLファイルの作成およびリバース・エンジニアリング

この項には次のトピックが含まれます:

- XMLモデルの作成

- XMLモデルのリバース・エンジニアリング

5.5.1 XMLモデルの作成

XMLファイル・モデルによって、一連のデータストアがグループ化されます。通常、各データストアはXMLファイル内の1つの要素を表します。

『Oracle Data Integratorでの統合プロジェクトの開発』のモデルの作成に関する項の説明に従って、標準の手順を使用してXMLモデルを作成します。XMLテクノロジおよびトポロジの構成時に作成されたXML論理スキーマを選択します。

5.5.2 XMLモデルのリバース・エンジニアリング

XMLでは、XMLドライバの機能のみを使用する標準のリバース・エンジニアリングがサポートされています。

URLのdtdまたはdパラメータでDTDまたはXSDファイルを参照して、XMLファイル構造の包括的な説明から構造をリバース・エンジニアリングすることをお薦めします。XSDまたはDTDのいずれも使用できない場合は、XMLインスタンス・ファイルを使用してリバース・エンジニアリングできます。この場合、リレーショナル・スキーマの構造は、XMLファイルに含まれるデータから推測されます。

標準のリバース・エンジニアリング

XMLで標準のリバースエンジニアリングを実行するには、『Oracle Data Integratorでの統合プロジェクトの開発』のモデルのリバースエンジニアリングに関する項の説明に従って、通常の手順を使用します。

標準のリバース・エンジニアリング・プロセスでは、XMLドライバによって生成されたリレーショナル・スキーマから表が自動的にリバース・エンジニアリングされます。これらの表には、自動的に次のものが含められます。

- 主キー(PK列): 要素の親子関係を保持します。

- 外部キー(FK列): 要素の親子関係を保持します。

- 順序識別子(ORDER列): XMLファイル内の要素の順序を保持します。

これらの追加の列により、階層XML構造のリレーショナル・スキーマへのマッピングが可能になります。詳細は、付録B「Oracle Data Integrator Driver for XMLの参照情報」の「XMLからSQLへのマッピング」を参照してください。

5.6 マッピングの設計

XMLをマッピングのソースまたはターゲットとして使用できます。

マッピングまたはチェック用に選択したKMによって、このマッピングまたはチェックの機能およびパフォーマンスが決まります。この項に示す推奨事項は、XMLデータ・サーバーに関連する様々な状況でのKMの選択に役立ちます。

5.6.1 XMLマッピングに関する注意

マッピングでXMLを使用する前に、次の注意事項をよく読んでください。

5.6.1.1 XML構造のターゲット指定

XMLモデルのデータストアをマッピングのターゲットとして使用する場合は、XML階層の親子関係および順序を保持するためにドライバで生成される列が確実にロードされるようにしてください。たとえば、リレーショナル・スキーマのREGION表に対応するregion要素のレコードを例5-1のようなXML構造に入力する場合は、REGION表の列REGION_IDおよびREGION_NAMEをロードする必要があります。これらの2つの列は、XML属性に対応します。

例5-1 XML構造

<country COUNTRY_ID="6" COUNTRY_NAME="Australia">
<region REGION_ID="72" REGION_NAME="Queensland">
</country>

例5-1では、XMLドライバによってREGION表に自動的に作成された追加の列もロードする必要があります。それらの列は次のとおりです。

- REGIONPK: この列により、各<region>要素を識別できます。

- REGIONORDER: この列により、XMLファイル内で<region>要素を順序付けできます(レコードは、リレーショナル・スキーマでは順序付けされませんが、XML要素では順序付けされます)。

- COUNTRYFK: この列により、<region>要素を<country>親要素との関係で配置できます。この値は、COUNTRY表のAustraliaレコードのCOUNTRY.COUNTRYPK値と同じです。

5.6.1.2 XMLファイルとスキーマの同期化

XMLファイルのデータとXMLスキーマのデータを完全に同期化するには、次のコマンドをコールする必要があります。

- データの読取りまたは更新のためにXMLモデルの表を使用する前に、XML論理スキーマでSYNCHRONIZE FROM FILEコマンドを使用することをお薦めします。この操作によって、XML階層のデータがXMLリレーショナル・スキーマに再ロードされます。このスキーマは、最初のアクセス時に組込みまたは外部のデータベース記憶域にロードされます。その後に行ったファイルへの変更は、このコマンドを発行しないかぎり、自動的にはスキーマへ同期されません。

- リレーショナル・スキーマへの変更を行った後、XML論理スキーマでSYNCHRONIZE ALLまたはSYNCHRONIZE FROM DATABASEコマンドをコールして、このスキーマをXML階層データにアンロードする必要があります。IKM XML Control Appendにはこの同期化コマンドが実装されています。

XMLスキーマを操作するマッピングおよびプロシージャの前(および後)に、パッケージ内のプロシージャでこれらのコマンドを実行する必要があります。

これらのコマンドの詳細は、付録B「Oracle Data Integrator Driver for XMLの参照情報」を参照してください。

5.6.1.3 サイズが大きいXMLファイルの処理

Oracle Data Integratorでは、サイズが大きいXMLファイルを高いパフォーマンスで処理できます。

デフォルトのドライバ構成では、リレーショナル・スキーマがメモリーの組込みエンジンに格納されます。サイズの大きいXMLファイルを処理する場合は、外部データベース記憶域の使用を検討することをお薦めします。

これらのコマンドの詳細は、B.2.3.1項「スキーマの格納」を参照してください。

5.6.2 XMLとの間でのデータのロード

XMLファイルは、マッピングのソースまたはターゲットとして使用できます。「ロード・ナレッジ・モジュール」タブでの、XMLファイルと別のタイプのデータ・サーバー間でデータをロードするためのLKMの選択は、マッピングのパフォーマンスに関してきわめて重要です。

5.6.2.1 XMLスキーマからのデータのロード

汎用SQL KMまたは関係するもう一方のテクノロジ固有のKMを使用して、XMLデータベースからターゲットまたはステージング領域のデータベースへデータをロードします。

XMLソースからステージング領域へのロードに使用できるKMの例を表5-2に示します。

表5-2 XMLからステージング領域へロードするためのKM

ステージング領域

KM

説明

Microsoft SQL Server

LKM SQL to MSSQL (BULK)

SQL Serverのバルク・ローダーを使用します。

Oracle

LKM SQL to Oracle

汎用LKMより高速です(統計を使用)。

すべて

LKM SQL to SQL

ANSI SQL-92のソースとANSI SQL-92のステージング領域の間でデータをロードするための汎用KMです。

5.6.2.2 XMLスキーマへのデータのロード

XMLスキーマをステージング領域として使用することはお薦めしません。ただし、XMLがマッピングのターゲットで、そのターゲットをステージング領域として使用する場合は例外です。この場合は、XMLスキーマにデータをロードする必要があることがあります。

汎用SQL KMまたは関係するもう一方のテクノロジ固有のKMを使用してソースまたはステージング領域からXMLスキーマへデータをロードします。

ソースからXMLステージング領域へのロードに使用できるKMの例を表5-3に示します。

表5-3 XMLスキーマにロードするためのKM

ソース

KM

説明

ファイル

LKM File to SQL

ANSI SQL-92のステージング領域にあるファイルにロードするための汎用KMです。

すべて

LKM SQL to SQL

ANSI SQL-92のソースとANSI SQL-92のステージング領域の間でデータをロードするための汎用KMです。

5.6.3 XMLへのデータの統合

XMLをマッピングのターゲットとして使用できます。XMLでのデータ統合戦略は、ステージング領域からXMLへのロードに関係します。「統合ナレッジ・モジュール」タブのIKMの選択によって、統合のパフォーマンスおよび可能性が決まります。

IKM XML Control Appendでは、データがXMLスキーマに統合されるほか、データをファイルに同期するオプションを使用できます。このKM以外に、汎用SQL KMまたは関係するもう一方のテクノロジ固有のKMも使用できます。汎用KMまたはテクノロジ固有のKMを使用する場合は、スキーマで行われた変更をXMLファイルに書き込むための同期化操作を手動で実行する必要があります。

次のデータ統合に使用できるKMの例を表5-4に示します。

- ステージング領域からXMLターゲットへの統合

- XMLステージング領域からXMLターゲットへの統合。この場合、ステージング領域はXMLターゲット上にあります。

表5-4 XMLファイルにデータを統合するためのKM

モード

ステージング領域

KM

説明

更新

XML

IKM SQL Incremental Update

汎用KM

追加

XML

IKM SQL Control Append

汎用KM

追加

すべてのRDBMS

IKM SQL to SQL Append

汎用KM

5.7 トラブルシューティング

この項では、Oracle Data IntegratorでのXMLの使用時に発生する可能性がある問題のトラブルシューティングに関する情報を提供します。この章の内容は、次のとおりです。

- XMLで発生したエラーの検出

- 一般的なエラー

5.7.1 XMLで発生したエラーの検出

通常、Oracle Data Integratorではエラーは次のように表示されます。

java.sql.SQLException: No suitable driver
at ...
at ...
...

このjava.sql.SQLExceptioncodeは、JDBCドライバを介して問合せが行われ、エラーが戻されたことを単純に示しています。このエラーはデータベースまたはドライバのエラーであることが多く、次のように解明する必要があります。

まず、太字のテキスト部分のみに注目してください。これは、XMLドライバのドキュメントで検索する必要があります。ここで示されているように、固有のエラー・コードが含まれている場合は、エラーをすばやく識別できます。

このようなエラーが実行ログで検出された場合は、データベースに送信されたSQLコードを分析して、エラーの原因を特定する必要があります。このコードは、エラーのあるタスクの「説明」タブに表示されます。

5.7.2 一般的なエラー

この項では、XMLの最も一般的なエラーおよび主な原因について説明します。この章の内容は、次のとおりです。

- No suitable driver
JDBC URLが不正です。URL構文が有効であることを確認してください。

- File <XML file> is already locked by another instance of the XML driver.
XMLファイルが別のユーザーまたはアプリケーションによってロックされています。XMLファイルを使用している可能性があるすべてのアプリケーションを閉じてください。該当するアプリケーションがクラッシュした場合は、XMLファイルのディレクトリに残っている.lckファイルを削除してください。

- The DTD file "xxxxxxx.dtd" doesn't exist
この例外は、コマンドLOAD FILEを使用してXMLファイルをロードしようとしたときに発生する可能性があります。このエラー・メッセージの原因として、次の2つが考えられます:

- DTDファイルのパスが間違っています。

- 対応するXMLファイルが(接続時などに)別のスキーマによってすでに開かれています。

- Table not found: S0002 Table not found: <table name> in statement [<SQL statement>]
アクセスしようとしている表がスキーマに存在しません。

- Column not found: S0022 Column not found: <column name> in statement [<SQL statement>]
アクセスしようとしている列が、文の中で指定された表に存在しません。

6 複合ファイル

この章では、Oracle Data Integratorでの複合ファイルの使用方法について説明します。

この章には次の項が含まれます:

- 6.1項「概要」

- 6.2項「インストールおよび構成」

- 6.3項「ネイティブ・フォーマット・ビルダーを使用したネイティブ・スキーマ記述ファイルの作成」

- 6.4項「トポロジの設定」

- 6.5項「統合プロジェクトの設定」

- 6.6項「複合ファイル・モデルの作成およびリバース・エンジニアリング」

- 6.7項「マッピングの設計」

6.1 概要

Oracle Data Integratorでは、複数のファイル・タイプがサポートされています。この章では、複合(またはネイティブ)ファイル形式の使用方法について説明します。ASCIIまたはEBCDICデータを含む単純な固定ファイルまたはデリミタ付きファイルの詳細は、第3章「ファイル」を参照してください。

複合ファイルのために、ファイル構造を記述するネイティブ・スキーマ記述ファイルを作成できます。Oracle Data Integratorでは、このネイティブ・スキーマ(nXSD)記述およびOracle Data Integrator Driver for Complex Filesを使用して、リバース・エンジニアリングおよび複合ファイルからの情報の読取りと書込みを実行できます。

ネイティブ・フォーマット・ビルダー・ウィザードを使用したネイティブ・スキーマ記述ファイルの作成方法の詳細は、6.3項「ネイティブ・フォーマット・ビルダーを使用したネイティブ・スキーマ記述ファイルの作成」を参照してください。複合ファイル・ドライバの参照情報は、付録C「Oracle Data Integrator Driver for Complex Filesの参照情報」を参照してください。

6.1.1 概念

Oracle Data Integrator Driver for Complex Files(複合ファイル・ドライバ)によって、ネイティブ・フォーマットがリレーショナル構造に変換され、このリレーショナル構造がデータ・モデルとしてOracle Data Integratorで公開されます。

複合ファイル・ドライバでは、ネイティブ・スキーマ(nXSD)の記述での定義に従い、ネイティブ・ファイルをXML構造に内部的に変換し、このXMLファイルから、Oracle Data Integratorによって消費されるリレーショナル・スキーマを生成します。全体的なメカニズムを図6-1に示します。

図6-1 複合ファイル・ドライバ・プロセス

複合ファイルに使用されるほとんどの概念とプロセスは、XMLファイルに使用されるものと同等です。主な違いは、ドライバによって内部的に使用されるが保持されないXML構造に、ネイティブ・ファイルを透過的に変換するステップです。

複合ファイル・テクノロジの概念は、Oracle Data Integratorの概念に次のようにマップされます。1つの複合ファイルは、Oracle Data Integratorの1つのデータ・サーバーに対応します。このデータ・サーバー内で、単一のスキーマが複合ファイルの内容にマップされます。

Oracle Data Integrator Driver for Complex File(複合ファイル・ドライバ)によって、ネイティブ・ファイルの複合構造がリレーショナル・スキーマにロードされます。このリレーショナル・スキーマは、SQLを使用した問合せまたは変更が可能なスキーマ内にある一連の表です。複合ファイル・ドライバでは、リレーショナル・スキーマを複合ファイルにアンロードすることもできます。リレーショナル・スキーマは、ODIで、データ・モデルとして、表、列および制約とともに、リバース・エンジニアリングされます。このモデルは、ODI内で通常のリレーショナル・データ・モデルと同様に使用されます。リレーショナル・スキーマ内で変更されたデータを複合ファイルに書き込む必要がある場合、リレーショナル・スキーマをファイルに同期化する、ドライバの機能を使用できます。

単純なフラット・ファイル形式(固定およびデリミタ付き)ではファイル・テクノロジを、XMLファイルではXMLテクノロジを使用することをお薦めします。詳細は、第3章「ファイル」および第5章「XMLファイル」を参照してください。

6.1.2 複合ファイル・ドライバの事前/事後処理サポート

データを複合ファイル・ドライバに提供する方法をカスタマイズできるようになりました。中間処理ステージを設定して、Oracle Data Integratorを使用して外部エンドポイントから取得されるデータを処理したり、データを外部エンドポイントに書き出すことができます。

複合ファイル・ドライバの事前および事後処理ステージの構成および実装の詳細は、付録D「XMLおよび複合ファイル・ドライバの事前/事後処理サポート」を参照してください。

6.1.3 ナレッジ・モジュール

複合ファイル・データ・サーバーを任意のSQLデータ・サーバーとして使用できます。複合ファイル・データ・サーバーでは、SQLデータ・サーバーをソース指定またはターゲット指定するテクノロジ固有のKMと汎用KMの両方がサポートされています。これらのKMの詳細は、第4章「汎用SQL」またはテクノロジの章を参照してください。

複合ファイル・データ・サーバーに書き込むとき、IKM XML Control Appendを使用することもできます。このナレッジ・モジュールには、複合ファイル・ドライバでサポートされている、リレーショナル・スキーマからファイルへデータを同期化するための特定のオプションが実装されています。

6.2 インストールおよび構成

複合ファイル・テクノロジでの作業を開始する前に、この項の情報を必ず読んでください。

- システム要件

- テクノロジ固有の要件

- 接続性要件

6.2.1 システム要件

インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。

サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。

http://www.oracle.com/technology/products/oracle-data-integrator/index.html

6.2.2 テクノロジ固有の要件

Oracle Data Integratorで複合ファイルを使用するためのテクノロジ固有の要件はありません。

6.2.3 接続性要件

この項では、複合ファイルに接続するための要件をリストします。

Oracle Data Integrator Driver for Complex Files

複合ファイルへのアクセスは、Oracle Data Integrator Driver for Complex Fileを介して行われます。このJDBCドライバはOracle Data Integratorとともにインストールされるもので、その他のコンポーネントのインストールや構成は不要です。

システム管理者から次の接続情報を入手する必要があります。

- ネイティブ・ファイルに関連付けられているネイティブ・スキーマ(nXSD)ファイルの場所

- ネイティブ複合ファイルの場所

6.3 ネイティブ・フォーマット・ビルダーを使用したネイティブ・スキーマ記述ファイルの作成

ネイティブ・フォーマット・ビルダー・ウィザードを使用してネイティブ・スキーマ(nXSD)記述ファイルを作成できます。複合ファイル・データ・サーバーを作成する場合、データ・サーバー・エディタからネイティブ・フォーマット・ビルダー・ウィザードを起動できます。

ネイティブ・フォーマット・ビルダーを使用してネイティブ・スキーマ記述ファイルを作成するには、次のようにします。

1. トポロジ・ナビゲータで、「物理アーキテクチャ」アコーディオンの「テクノロジ」ノードを開きます。

2. 複合ファイル・テクノロジを選択します。

3. 右クリックして「新規データ・サーバー」を選択します。

4. 「JDBC」タブで、「nXSDを編集します」ボタンをクリックします。ネイティブ・フォーマット・ビルダー・ウィザードが表示されます。

5. 画面上の指示に従って、ネイティブ・フォーマット・ビルダー・ウィザードを完了してネイティブ・スキーマ記述ファイルを作成します。

ネイティブ・スキーマ形式の詳細は、テクノロジ・アダプタ・ユーザーズ・ガイドのネイティブ・フォーマット・ビルダー・ウィザードに関する項を参照してください。

6.4 トポロジの設定

トポロジの設定には次が含まれます。

1. 複合ファイル・データ・サーバーの作成

2. 複合ファイル物理スキーマの作成

6.4.1 複合ファイル・データ・サーバーの作成

複合ファイル・データ・サーバーは、Oracle Data Integratorにアクセス可能な1つのネイティブ・ファイルに対応します。

6.4.1.1 データ・サーバーの作成

『Oracle Data Integratorでの統合プロジェクトの開発』のデータ・サーバーの作成に関する項の説明に従って、標準の手順を使用して複合ファイル・テクノロジ用のデータ・サーバーを作成します。この項では、複合ファイル・データ・サーバーの定義に関する必須または固有のフィールドのみについて説明します。

1. 「定義」タブ:

- 名前: Oracle Data Integratorに表示されるデータ・サーバーの名前。

- ユーザー/パスワード: これらのフィールドは、複合ファイル・データ・サーバーでは使用しません。

2. 「JDBC」タブで次の値を入力します。

- JDBCドライバ: oracle.odi.jdbc.driver.file.complex.ComplexFileDriver

- JDBC URL: jdbc:snps:complexfile

- nXSDを編集します: ネイティブ・スキーマ記述ファイルを作成する場合にネイティブ・フォーマット・ビルダー・ウィザードを起動します。
ネイティブ・フォーマット・ビルダー・ウィザードの詳細は、6.3項「ネイティブ・フォーマット・ビルダーを使用したネイティブ・スキーマ記述ファイルの作成」を参照してください。

- プロパティ: Oracle Data Integrator Driver for Complex Filesのネイティブ・ファイルの場所、ネイティブ・スキーマ、ルート要素およびスキーマ名などのプロパティを構成します。
表6-1に、Oracle Data Integrator Driver for Complex Filesの主なプロパティをリストします。これらのプロパティは、JDBC URL内で指定できます。

これらのプロパティの詳細、およびすべてのプロパティの包括的なリストは、付録C「Oracle Data Integrator Driver for Complex Filesの参照情報」を参照してください。

表6-1 複合ファイル・ドライバのプロパティ

プロパティ

値

説明

f

<ネイティブ・ファイルの名前>

ネイティブ・ファイルの場所。パス名には、バックスラッシュ"\"ではなくスラッシュ"/"を使用します。HTTP、FTPまたはファイルのURLを使用してファイルの場所を示すことができます。URLによって示されたファイルは読取り専用です。このパラメータは必須です。

d

<ネイティブ・スキーマ>

ネイティブ・スキーマ(nXSD)ファイルの場所。このパラメータは必須です。

re

<ルート要素>

スキーマのルート表として選択する要素の名前。この値では大/小文字が区別されます。このプロパティは、ネイティブ・スキーマの特定のセクションなどのリバース・エンジニアリングに使用できます。このパラメータは必須です。

s

<スキーマ名>

複合ファイルのロード先となるリレーショナル・スキーマの名前。このパラメータはオプションです。

このスキーマは、複合ファイル・データ・サーバーの下に物理スキーマを作成する際に選択されます。

6.4.2 複合ファイル物理スキーマの作成

『Oracle Data Integratorの管理』の物理スキーマの作成に関する項の説明に従って、標準の手順を使用して複合ファイル物理スキーマを作成します。

URLで設定したスキーマ名が表示されます。「データ・スキーマ」および「作業スキーマ」の両方について、このスキーマを選択します。

『Oracle Data Integratorの管理』の論理スキーマの作成に関する項の説明に従って、標準の手順を使用してこの物理スキーマ用の論理スキーマを作成し、特定のコンテキストで関連付けます。

6.5 統合プロジェクトの設定

複合ファイル・テクノロジを使用してプロジェクトを設定するには、標準の手順に従います。『Oracle Data Integratorでの統合プロジェクトの開発』の統合プロジェクトの作成に関する項を参照してください。

最初は、使用するプロジェクトに次のナレッジ・モジュールをインポートすることをお薦めします。

- LKM SQL to SQL

- IKM XML Control Append

これらのナレッジ・モジュール以外に、使用する製品に関連する他のテクノロジ固有のファイル・ナレッジ・モジュールもインポートできます。

6.6 複合ファイル・モデルの作成およびリバース・エンジニアリング

この項には次のトピックが含まれます:

- 複合ファイル・モデルの作成

- 複合ファイル・モデルのリバース・エンジニアリング

6.6.1 複合ファイル・モデルの作成

複合ファイル・モデルによって、一連のデータストアがグループ化されます。各データストアは通常、ネイティブ・スキーマを使用してネイティブ・ファイルから生成される中間XMLファイル内の要素を表します。

『Oracle Data Integratorでの統合プロジェクトの開発』のモデルの作成に関する項の説明に従って、標準の手順を使用して複合ファイル・モデルを作成します。

6.6.2 複合ファイル・モデルのリバース・エンジニアリング

複合ファイル・テクノロジでは、複合ファイル・ドライバの機能のみを使用する標準のリバース・エンジニアリングがサポートされます。

標準のリバース・エンジニアリング

複合ファイル・モデルで標準のリバースエンジニアリングを実行するには、『Oracle Data Integratorでの統合プロジェクトの開発』のモデルのリバースエンジニアリングに関する項の説明に従って、通常の手順を使用します。

このリバース・エンジニアリングでは、XMLファイルのリバース・エンジニアリングと同じプロセスが使用されます。データ・サーバーURLで提供されるネイティブ・スキーマ(nXSD)は、XML構造を記述するためのXSDファイルとして使用されます。詳細は、5.5.2項「XMLモデルのリバース・エンジニアリング」および「XMLからSQLへのマッピング」を参照してください。

6.7 マッピングの設計

複合ファイルをマッピングのソースまたはターゲットとして使用できます。

マッピングまたはチェック用に選択したKMによって、このマッピングまたはチェックの機能およびパフォーマンスが決まります。この項に示す推奨事項は、複合ファイル・データ・サーバーに関連する様々な状況でのKMの選択に役立ちます。

複合ファイル・データ・モデルは、XML構造と類似のマッピングで処理されます。たとえば、複合ファイルとXMLファイルでは同期モデルが同じであり、両方のテクノロジに同じナレッジ・モジュールを使用できます。

詳細は、第5章「XMLファイル」の5.6項「マッピングの設計」を参照してください。

7 Microsoft SQL Server

この章では、Oracle Data IntegratorでのMicrosoft SQL Serverの使用方法について説明します。

この章には次の項が含まれます:

- 7.1項「概要」

- 7.2項「インストールおよび構成」

- 7.3項「トポロジの設定」

- 7.4項「統合プロジェクトの設定」

- 7.5項「Microsoft SQL Serverモデルの作成およびリバース・エンジニアリング」

- 7.6項「チェンジ・データ・キャプチャの設定」

- 7.7「データ品質の設定」

- 7.8項「マッピングの設計」

7.1 概要

Oracle Data Integrator (ODI)では、Microsoft SQL Serverのデータがシームレスに統合されます。Oracle Data Integratorの機能(リバース・エンジニアリング、チェンジ・データ・キャプチャ、データ整合性チェックおよびマッピングなど)は、Microsoft SQL Serverを使用した場合に最良の動作が得られるように設計されています。

7.1.1 概念

Microsoft SQL Serverの概念は、Oracle Data Integratorの概念に次のようにマップされます。Microsoft SQL Serverの1つのサーバーは、Oracle Data Integratorの1つのデータ・サーバーに対応します。このサーバー内で、データベースと所有者の1つのペアは、Oracle Data Integratorの1つの物理スキーマにマップされます。1つのデータベース内の一連の関連オブジェクトは1つのデータ・モデルに対応し、各表、ビューまたはシノニムは、その属性、列および制約とともに、ODIデータストアとして示されます。

Oracle Data Integratorでは、Java Database Connectivity (JDBC)を使用してMicrosoft SQL Serverに接続します。

7.1.2 ナレッジ・モジュール

Oracle Data Integratorには、Microsoft SQL Serverデータを処理するためのナレッジ・モジュール(KM)が用意されています。これらのリストを表7-1に示します。これらのMicrosoft SQL Server固有のナレッジ・モジュール以外に、Microsoft SQL Serverでは、汎用SQL KMを使用することもできます。詳細は、第4章「汎用SQL」を参照してください。

表7-1 MSSQL KM

ナレッジ・モジュール

説明

IKM MSSQL Incremental Update

増分更新モードでMicrosoft SQL Serverのターゲット表にデータを統合します。

IKM MSSQL Slowly Changing Dimension

データ・ウェアハウスでタイプ2の緩やかに変化するディメンションとして使用されるMicrosoft SQL Serverのターゲット表に、データを統合します。

JKM MSSQL Consistent

トリガーを使用してMicrosoft SQL Server表の一貫したジャーナル化を行うためのジャーナル化インフラストラクチャを作成します。

JKM MSSQL Simple

トリガーを使用してMicrosoft SQL Server表の単純なジャーナル化を行うためのジャーナル化インフラストラクチャを作成します。

LKM File to MSSQL (BULK)

固有のBULK INSERT SQLコマンドを使用して、ファイルからMicrosoft SQL Serverステージング領域データベースへデータをロードします。

LKM MSSQL to MSSQL (BCP)

固有のBCP out/BCP inコマンドを使用して、Microsoft SQL Serverソース・データベースからMicrosoft SQL Serverステージング領域データベースへ、データをロードします。

LKM MSSQL to MSSQL (LINKED SERVERS)

固有のリンク・サーバー機能を使用して、Microsoft SQL Serverソース・データベースからMicrosoft SQL Serverステージング領域データベースへ、データをロードします。

LKM MSSQL to ORACLE (BCP SQLLDR)

BCPおよびSQLLDRユーティリティを使用して、Microsoft SQL ServerからOracleデータベース(ステージング領域)へデータをロードします。

LKM SQL to MSSQL (BULK)

固有のBULK INSERT SQLコマンドを使用して、任意のANSI SQL-92ソース・データベースからMicrosoft SQL Serverステージング領域データベースへデータをロードします。

LKM SQL to MSSQL

任意のANSI SQL-92ソース・データベースからMicrosoft SQL Serverステージング領域へデータをロードします。このLKMは、第4章「汎用SQL」に記載されている標準のLKM SQL to SQLと似ていますが、Microsoft SQL Serverの追加パラメータを指定できる点で異なります。

RKM MSSQL

Microsoft SQL Serverオブジェクトのメタデータ(表、ビュー、シノニム、列および制約)を取得します。

7.2 インストールおよび構成

Microsoft SQL Serverテクノロジでの作業を開始する前に、この項の情報を必ず読んでください。

- システム要件および動作要件

- テクノロジ固有の要件

- 接続性要件

7.2.1 システム要件および動作要件

インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。

サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。

http://www.oracle.com/technology/products/oracle-data-integrator/index.html

7.2.2 テクノロジ固有の要件

Microsoft SQL Server用の一部のナレッジ・モジュールでは、このデータベース固有の機能が使用されます。これらのナレッジ・モジュールの使用時には、次の制限が適用されます。これらのトピックの追加情報は、Microsoft SQL Serverのドキュメントを参照してください。

7.2.2.1 BULK INSERTコマンドの使用

この項では、Microsoft SQL ServerでBULK INSERTコマンドを使用する前に満たしておく必要がある要件を説明します。

- BULK INSERTコマンドでロードするファイルは、Microsoft SQL Serverインスタンスのマシンからアクセスできる必要があります。サーバーのファイル・システム上に置くか、UNC (Unique Naming Convention)パスからアクセスできるようにします。

- UNCファイル・パスはサポートされていますが、パフォーマンスの低下につながるためお薦めしません。

- パフォーマンスの点から、ターゲット・サーバー・マシン上にOracle Data Integratorのエージェントをインストールすることをお薦めします。

7.2.2.2 BCPコマンドの使用

この項では、Microsoft SQL ServerでBCPコマンドを使用する前に満たしておく必要がある要件を説明します。

- BCPユーティリティおよびMicrosoft SQL Serverのクライアント・ネットワーク・ユーティリティは、Oracle Data Integratorのエージェントを実行するマシン上にインストールする必要があります。

- トポロジで定義されるサーバー名は、これらのサーバーに使用されるMicrosoft SQL Serverクライアントの接続文字列と一致する必要があります。

- クライアント・ユーティリティで定義されるサーバー名には、空白を使用できません。

- UNCファイル・パスはサポートされていますが、パフォーマンスの低下につながるためお薦めしません。

- ターゲットのステージング領域データベースには、select into/bulk copyオプションが必要です。

- BCPプログラムによって生成されたファイルが空の場合は、実行が保留状態のままになります。

- パフォーマンスの点から、ターゲット・サーバー・マシン上にOracle Data Integratorのエージェントをインストールすることをお薦めします。

7.2.2.3 リンク・サーバーの使用

この項では、Microsoft SQL Serverでリンク・サーバーを使用する前に満たしておく必要がある要件を説明します。

- Microsoft SQL Serverのインスタンスに接続するためにトポロジで定義されたユーザーには、次の権限が必要です。

- ユーザーは、ステージング領域データベースのdb_ownerであることが必要です。

- ユーザーにはdb_ddladminロールが必要です。

- リンク・サーバーを自動作成するために、ユーザーにはsysdamin権限が必要です。

- MSDTCサービスは、両方のSQL Serverインスタンス(ソースおよびターゲット)で開始する必要があります。このサービスの構成に役立つヒントは次のとおりです。

- MSDTCサービスのログオン・アカウントは、ネットワーク・サービス・アカウントです(LocalSystemアカウントではありません)。

- MSDTCは、ネットワーク・トランザクションに対して有効であることが必要です。

- Windowsファイアウォールは、ネットワーク上でMSDTCサービスが許可されるように構成する必要があります。デフォルトでは、WindowsファイアウォールによってMSDTCプログラムがブロックされます。

- Microsoft SQL Serverは、MSDTCのスタートアップが完了した後に起動する必要があります。

MSDTCサービスの構成の詳細は、次のリンク先を参照してください。

- http://support.microsoft.com/?kbid=816701

- http://support.microsoft.com/?kbid=839279

7.2.3 接続性要件

この項では、Microsoft SQL Serverデータベースに接続するための要件をリストします。

JDBCドライバ

Oracle Data Integratorは、デフォルトのMicrosoft SQL Server Datadirectドライバとともにインストールされます。このドライバではTCP/IPネットワーク・レイヤーが直接使用され、他のコンポーネントのインストールや構成は不要です。かわりに、Microsoft for SQL Serverで提供されるドライバを使用することもできます。

7.3 トポロジの設定

トポロジの設定には次が含まれます。

1. Microsoft SQL Serverデータ・サーバーの作成

2. Microsoft SQL Server物理スキーマの作成

7.3.1 Microsoft SQL Serverデータ・サーバーの作成

1つのMicrosoft SQL Serverデータ・サーバーは、特定のユーザー・アカウントに接続されたMicrosoft SQL Serverの1つのサーバーに対応します。このユーザーには、データ・サーバーの下に作成されたOracle Data Integrator内の物理スキーマに対応する、このサーバー内の複数のデータベースへのアクセス権が付与されます。

7.3.1.1 データ・サーバーの作成

『Oracle Data Integratorでの統合プロジェクトの開発』のデータ・サーバーの作成に関する項の説明に従って、標準の手順を使用してMicrosoft SQL Serverテクノロジ用のデータ・サーバーを作成します。この項では、Microsoft SQL Serverデータ・サーバーの定義に関する必須または固有のフィールドのみについて説明します。

1. 「定義」タブ:

- 名前: Oracle Data Integratorに表示されるデータ・サーバーの名前

- サーバー: データ・サーバーの物理名

- ユーザー/パスワード: Microsoft SQL Serverユーザーおよびそのパスワード

2. 「JDBC」タブ:

- JDBCドライバ: weblogic.jdbc.sqlserver.SQLServerDriver

- JDBC URL: jdbc:weblogic:sqlserver://hostname:port[;property=value[;...]]

7.3.2 Microsoft SQL Server物理スキーマの作成

『Oracle Data Integratorの管理』の物理スキーマの作成に関する項の説明に従って、標準の手順を使用してMicrosoft SQL Server物理スキーマを作成します。

この物理スキーマ内の作業スキーマおよびデータ・スキーマは、それぞれデータベースと所有者のペアに対応します。作業スキーマは一時データベースを指し示し、データ・スキーマは統合するデータをホストするデータベースを指し示す必要があります。

『Oracle Data Integratorの管理』の論理スキーマの作成に関する項の説明に従って、標準の手順を使用してこの物理スキーマ用の論理スキーマを作成し、特定のコンテキストで関連付けます。

7.4 統合プロジェクトの設定

Microsoft SQL Serverデータベースを使用してプロジェクトを設定するには、標準の手順に従います。『Oracle Data Integratorでの統合プロジェクトの開発』の統合プロジェクトの作成に関する項を参照してください。

Microsoft SQL Serverでの作業を開始するにあたり、使用するプロジェクトに次のナレッジ・モジュールをインポートすることをお薦めします。

- IKM MSSQL Incremental Update

- IKM MSSQL Slowly Changing Dimension

- JKM MSSQL Consistent

- JKM MSSQL Simple

- LKM File to MSSQL (BULK)

- LKM MSSQL to MSSQL (BCP)

- LKM MSSQL to MSSQL (LINKED SERVERS)

- LKM MSSQL to ORACLE (BCP SQLLDR)

- LKM SQL to MSSQL (BULK)

- LKM SQL to MSSQL

- CKM SQL。この汎用KMは、SQL Serverの整合性チェックを実行するために使用します。

- RKM MSSQL

7.5 Microsoft SQL Serverモデルの作成およびリバース・エンジニアリング

この項には次のトピックが含まれます:

- Microsoft SQL Serverモデルの作成

- Microsoft SQL Serverモデルのリバース・エンジニアリング

7.5.1 Microsoft SQL Serverモデルの作成

『Oracle Data Integratorでの統合プロジェクトの開発』のモデルの作成に関する項の説明に従って、標準の手順を使用してMicrosoft SQL Serverモデルを作成します。

7.5.2 Microsoft SQL Serverモデルのリバース・エンジニアリング

Microsoft SQL Serverでは、JDBCドライバの機能のみを使用する標準のリバース・エンジニアリング、およびRKMを使用してメタデータ取得する、カスタマイズされたリバース・エンジニアリングの両方がサポートされています。

通常は、標準のJDBCリバース・エンジニアリングを使用して作業を開始することを検討してください。Microsoft SQL Serverで標準のリバース・エンジニアリングを使用すると、表、ビューおよび列が取得されます。

それ以外のメタデータを取得する場合に、カスタマイズされたリバース・エンジニアリングに切り替えることを検討してください。Microsoft SQL Serverのカスタマイズされたリバース・エンジニアリングでは、表、ビューおよびシノニムが取得されます。RKM MSSQLでも、ユーザー定義のデータ型を持つ列がリバース・エンジニアリングされ、ユーザー定義のデータ型が固有のデータ型に変換されます。

標準のリバース・エンジニアリング

Microsoft SQL Serverで標準のリバースエンジニアリングを実行するには、『Oracle Data Integratorでの統合プロジェクトの開発』のモデルのリバースエンジニアリングに関する項の説明に従って、通常の手順を使用します。

カスタマイズされたリバース・エンジニアリング

RKMを使用してMicrosoft SQL Serverでカスタマイズされたリバースエンジニアリングを実行するには、『Oracle Data Integratorでの統合プロジェクトの開発』のモデルのリバースエンジニアリングに関する項の説明に従って、通常の手順を使用します。この項では、Microsoft SQL Serverテクノロジ固有のフィールドのみについて説明します。

1. Microsoft SQL Serverモデルの「リバース・エンジニアリング」タブでKM: RKM MSSQL.<project name>を選択します。

2. COMPATIBLEオプションにMicrosoft SQL Serverのバージョンを入力します。このオプションによって、シノニムのリバースが有効になるかどうかが決まります。シノニムは、Microsoft SQLServerバージョン2005以上のみでサポートされています。

このRKMの使用時には、次の情報に注意してください。

- 接続ユーザーには、すべてのINFORMATION_SCHEMAビューに対するSELECT権限が必要です。

- リポジトリおよびモデルにユーザー定義のデータ型がある属性については、ネイティブ・データ型のみが保存されます。

- Microsoft .NET Frameworkの共通言語ランタイム(CLR)でアセンブリのクラスを介して実装されたユーザー定義のデータ型は、リバースされません。

7.6 チェンジ・データ・キャプチャの設定

ODI Microsoft SQL Serverナレッジ・モジュールでは、チェンジ・データ・キャプチャ機能がサポートされています。ジャーナル化の設定方法およびキャプチャされた変更の使用方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』の「チェンジ・データ・キャプチャの使用」を参照してください。

Microsoft SQL Serverジャーナル化ナレッジ・モジュールでは、単純ジャーナル化および一貫性セット・ジャーナル化がサポートされています。Microsoft SQL Server JKMでは、トリガーを使用してソース表でのデータ変更をキャプチャします。

Oracle Data Integratorには、Microsoft SQL Server表をジャーナル化するためのナレッジ・モジュールが用意されています。これらのリストを表7-2に示します。

表7-2 Microsoft SQL Serverのジャーナル化ナレッジ・モジュール

KM

説明

JKM MSSQL Consistent

トリガーを使用してMicrosoft SQL Server表の一貫したジャーナル化を行うためのジャーナル化インフラストラクチャを作成します。

JKM MSSQL Simple

トリガーを使用してMicrosoft SQL Server表の単純なジャーナル化を行うためのジャーナル化インフラストラクチャを作成します。

Oracle GoldenGateを使用すると、Microsoft SQL Serverでログ・ベースのチェンジ・データ・キャプチャを実行できます。詳細は、第24章「Oracle GoldenGate」を参照してください。

7.7 データ品質の設定

Oracle Data Integratorには、Microsoft SQL Serverの表で定義された制約と照合してデータの整合性をチェックするための汎用CKM SQLが用意されています。詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』のフロー制御および静的制御に関する項を参照してください。

詳細は、第4章「汎用SQL」を参照してください。

7.8 マッピングの設計

マッピングのソース、ステージング領域またはターゲットとしてMicrosoft SQL Serverを使用できます。

マッピングまたはチェック用に選択したKMによって、このマッピングまたはチェックの機能およびパフォーマンスが決まります。この項に示す推奨事項は、Microsoft SQL Serverデータ・サーバーに関連する様々な状況でのKMの選択に役立ちます。

7.8.1 Microsoft SQL Serverとの間でのデータのロード

マッピングのソース、ターゲットまたはステージング領域としてMicrosoft SQL Serverを使用できます。「ロード・ナレッジ・モジュール」タブでの、Microsoft SQL Serverと別のタイプのデータ・サーバー間でデータをロードするためのLKMの選択は、マッピングのパフォーマンスに関してきわめて重要です。

7.8.1.1 Microsoft SQL Serverからのデータのロード

Oracle Data Integratorには、Microsoft SQL Serverからターゲットまたはステージング領域のデータベースへデータをロードするための最適化されたメソッドを実装するナレッジ・モジュールが用意されています。これらの最適化されたMicrosoft SQL Server KMを表7-3にリストします。

これらのKM以外に、汎用SQL KMまたは関係するもう一方のテクノロジ固有のKMを使用して、Microsoft SQL Serverからターゲットまたはステージング領域のデータベースへデータをロードすることもできます。

表7-3 Microsoft SQL ServerからデータをロードするためのKM

ソースまたはステージング領域のテクノロジ

KM

説明

Microsoft SQL Server

LKM MSSQL to MSSQL (BCP)

固有のBCP out/BCP inコマンドを使用して、Microsoft SQL Serverソース・データベースからMicrosoft SQL Serverステージング領域データベースへ、データをロードします。

Microsoft SQL Server

LKM MSSQL to MSSQL (LINKED SERVERS)

固有のリンク・サーバー機能を使用して、Microsoft SQL Serverソース・データベースからMicrosoft SQL Serverステージング領域データベースへ、データをロードします。

Oracle

LKM MSSQL to ORACLE (BCP SQLLDR)

BCPおよびSQLLDRユーティリティを使用して、Microsoft SQL ServerからOracleデータベース(ステージング領域)へデータをロードします。

7.8.1.2 Microsoft SQL Serverへのデータのロード

Oracle Data Integratorには、ソースまたはステージング領域からMicrosoft SQL Serverデータベースへデータをロードするための最適化されたメソッドを実装するナレッジ・モジュールが用意されています。これらの最適化されたMicrosoft SQL Server KMを表7-4にリストします。

これらのKM以外に、汎用SQL KMまたは関係するもう一方のテクノロジ固有のKMも使用できます。

表7-4 Microsoft SQL ServerにデータをロードするためのKM

ソースまたはステージング領域のテクノロジ

KM

説明

ファイル

LKM File to MSSQL (BULK)

固有のBULK INSERT SQLコマンドを使用して、ファイルからMicrosoft SQL Serverステージング領域データベースへデータをロードします。

Microsoft SQL Server

LKM MSSQL to MSSQL (BCP)

固有のBCP out/BCP inコマンドを使用して、Microsoft SQL Serverソース・データベースからMicrosoft SQL Serverステージング領域データベースへ、データをロードします。

Microsoft SQL Server

LKM MSSQL to MSSQL (LINKED SERVERS)

固有のリンク・サーバー機能を使用して、Microsoft SQL Serverソース・データベースからMicrosoft SQL Serverステージング領域データベースへ、データをロードします。

SQL

LKM SQL to MSSQL (BULK)

固有のBULK INSERT SQLコマンドを使用して、任意のANSI SQL-92ソース・データベースからMicrosoft SQL Serverステージング領域データベースへデータをロードします。

SQL

LKM SQL to MSSQL

任意のANSI SQL-92ソース・データベースからMicrosoft SQL Serverステージング領域へデータをロードします。

7.8.2 Microsoft SQL Serverでのデータの統合

Oracle Data Integratorには、Microsoft SQL Server用に最適化されたデータ統合戦略を実装するナレッジ・モジュールが用意されています。これらの最適化されたMicrosoft SQL Server KMを表7-5にリストします。I

これらのKM以外に、汎用SQL KMも使用できます。

「統合ナレッジ・モジュール」タブのIKMの選択によって、統合のパフォーマンスおよび可能性が決まります。

表7-5 Microsoft SQL Serverにデータを統合するためのKM

KM

説明

IKM MSSQL Incremental Update

増分更新モードでMicrosoft SQL Serverのターゲット表にデータを統合します。

IKM MSSQL Slowly Changing Dimension

データ・ウェアハウスでタイプ2の緩やかに変化するディメンションとして使用されるMicrosoft SQL Serverのターゲット表に、データを統合します。

緩やかに変化するディメンションの使用

緩やかに変化するディメンションを使用する場合は、ターゲット・データベースの各列に対して「緩やかに変化するディメンション」の値を必ず設定してください。この値は、「サロゲート・キー」、「自然キー」、列の上書きまたは挿入、「現在のレコード・フラグ」、「開始タイムスタンプ」および「終了タイムスタンプ」列を識別するために、IKM MSSQL Slowly Changing Dimensionで使用されます。

8 Microsoft Excel

この章では、Oracle Data IntegratorでのMicrosoft Excelの使用方法について説明します。

この章には次の項が含まれます:

- 8.1項「概要」

- 8.2項「インストールおよび構成」

- 8.3項「トポロジの設定」

- 8.4項「統合プロジェクトの設定」

- 8.5項「Microsoft Excelモデルの作成およびリバース・エンジニアリング」

- 8.6項「マッピングの設計」

- 8.7項「トラブルシューティング」

8.1 概要

Oracle Data Integrator (ODI)では、保存されているデータがMicrosoft Excelのワークブックに統合されます。これにより、リバース・エンジニアリングと、スプレッドシートでの読取りおよび書込みの操作が可能になります。

Oracle Data Integratorでは、Open Database Connectivity (ODBC)を使用してMicrosoft Excelデータ・サーバーに接続します。詳細は、8.2.3項「接続性要件」を参照してください。

8.1.1 概念

各Microsoft Excelデータ・サーバーは、ローカル・ネットワーク経由でアクセス可能な1つのMicrosoft Excelワークブック(.xlsファイル)に対応します。このデータ・サーバーにの下に単一の物理スキーマが作成されます。

このスキーマ内で、1つのスプレッドシート、またはワークブックの特定の名前付き領域が、Oracle Data Integrator内の1つのデータストアとして表示されます。

8.1.2 ナレッジ・モジュール

Oracle Data Integratorには、Microsoft Excelテクノロジ固有のナレッジ・モジュール(KM)は用意されていません。汎用SQL KMを使用して、Microsoft Excelデータのデータ統合および変換の操作を実行できます。詳細は、第4章「汎用SQL」を参照してください。

注意:
Excelテクノロジをステージング領域として使用することはできず、増分更新およびフロー/静的チェックはサポートされません。このため、Excelテクノロジでは次のKMは機能しません。

- RKM SQL (JYTHON)

- LKM File to SQL

- CKM SQL

- IKM SQL Incremental Update

- IKM SQL Control Append

- LKM SQL to SQL (JYTHON)

8.2 インストールおよび構成

Microsoft Excelナレッジ・モジュールの使用を開始する前に、この項の情報を必ず読んでください。

- システム要件および動作要件

- テクノロジ固有の要件

- 接続性要件

8.2.1 システム要件および動作要件

インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。

サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。

http://www.oracle.com/technology/products/oracle-data-integrator/index.html

8.2.2 テクノロジ固有の要件

Oracle Data IntegratorでMicrosoft Excelファイルを使用するためのテクノロジ固有の要件はありません。

8.2.3 接続性要件

この項では、Microsoft Excelワークブックに接続するための要件をリストします。

Microsoft Excelデータにアクセスするための要件は次のとおりです。

- Microsoft Excel ODBCドライバのインストール

- Microsoft Excel ODBCデータソースの宣言

Microsoft Excel ODBCドライバのインストール

Microsoft Excelワークブックにアクセスできるのは、ODBC接続を使用した場合のみです。使用するシステムに、Excel用ODBCドライバがインストールされている必要があります。

Microsoft Excel ODBCデータソースの宣言

ODBCデータソースは、ODIからアクセスするそれぞれのMicrosoft Excelワークブック(.xlsファイル)に対して定義する必要があります。ODBCデータソースは、Microsoft ODBCデータソース・アドミニストレータで作成します。データソースの作成方法は、Microsoft Windowsオペレーティング・システムのドキュメントを参照してください。3.5.2.4項「カスタマイズされたリバース・エンジニアリング」の「Excelスプレッドシート用のODBCデータソースの作成」も参照してください。

8.3 トポロジの設定

トポロジの設定には次が含まれます。

1. Microsoft Excelデータ・サーバーの作成

2. Microsoft Excel物理スキーマの作成

8.3.1 Microsoft Excelデータ・サーバーの作成

各Microsoft Excelデータ・サーバーは、ローカル・ネットワーク経由でアクセス可能な1つのMicrosoft Excelワークブック(.xlsファイル)に対応します。

『Oracle Data Integratorでの統合プロジェクトの開発』のデータ・サーバーの作成に関する項の説明に従って、標準の手順を使用してMicrosoft Excelテクノロジ用のデータ・サーバーを作成します。この項では、Microsoft Excelデータ・サーバーの定義に関する必須または固有のフィールドのみについて説明します。

1. 「定義」タブ:

- 配列フェッチ・サイズ: 0

- バッチ更新サイズ: 1

2. 「JDBC」タブ:

- JDBCドライバ: Excel用の適切なJDBCドライバを選択します。

- JDBC URL: 選択されたJDBCドライバに必要なURLを入力します。

警告:

ODBC経由でMicrosoft Excelワークブックにアクセスするには、まず、そのワークブックがMicrosoft Excelセッションで現在開いていないことを確認する必要があります。開いている場合、予期しない結果につながる可能性があります。

8.3.2 Microsoft Excel物理スキーマの作成

『Oracle Data Integratorの管理』の物理スキーマの作成に関する項の説明に従って、標準の手順を使用してMicrosoft Excel物理スキーマを作成します。

Oracle Data Integratorで必要な物理スキーマは、各Microsoft Excelデータ・サーバーに対して1つのみであることに注意してください。異なるワークブックに接続する場合は、そのワークブックに対応するODBCデータソースに接続するために、異なるデータ・サーバーを作成する必要があります。

『Oracle Data Integratorの管理』の論理スキーマの作成に関する項の説明に従って、標準の手順を使用してこの物理スキーマ用の論理スキーマを作成し、特定のコンテキストで関連付けます。

注意:
Excel物理スキーマには作業スキーマはなく、データ・スキーマのみがあります。Microsoft Excelは、マッピングのステージング領域としては使用できません。

8.4 統合プロジェクトの設定

Microsoft Excelを使用してプロジェクトを設定するには、標準の手順に従います。『Oracle Data Integratorでの統合プロジェクトの開発』の統合プロジェクトの作成に関する項を参照してください。

Microsoft Excelでの作業を開始するにあたり、使用するプロジェクトに次の汎用SQL KMをインポートします。

- LKM SQL to SQL

- IKM SQL to SQL Append

これらのKMの詳細は、第4章「汎用SQL」を参照してください。

8.5 Microsoft Excelモデルの作成およびリバース・エンジニアリング

この項には次のトピックが含まれます:

- Microsoft Excelモデルの作成

- Microsoft Excelモデルのリバース・エンジニアリング

8.5.1 Microsoft Excelモデルの作成

Microsoft Excelモデルは、Microsoft Excelワークブック内の表に対応するデータストアのセットです。

『Oracle Data Integratorでの統合プロジェクトの開発』のモデルの作成に関する項の説明に従って、標準の手順を使用してMicrosoft Excelモデルを作成します。

8.5.2 Microsoft Excelモデルのリバース・エンジニアリング

Microsoft Excelでは、ODBCドライバの機能のみを使用する標準のリバース・エンジニアリングがサポートされています。

Oracle Data Integratorによるリバース・エンジニアリングの対象は次のとおりです。

- スプレッドシート: スプレッドシートはシステム表として表示されます。それぞれの表の名前にはスプレッドシートの名前が使用され、最後にドル記号($)が付きます。この表の列には、スプレッドシートの最初の行の名前が付けられます。新規レコードはスプレッドシートの最後に追加されます。

- スプレッドシートの名前付きセル範囲。これらは、セル範囲名と同じ名前の表として表示されます。名前の有効範囲によっては、表名の接頭辞としてスプレッドシートの名前が使用される場合があります(書式: <spreadsheet_name>$<zone_name>)。この場合の表の列名は、セル範囲の最初の行と同じになります。新規レコードは、名前付きセルの下に自動的に追加されることに注意してください。最初のヘッダー行のみを含むセル範囲に名前を付けることによって、ODIを使用してロードされる空の名前付きセル範囲を作成できます。
Microsoft Excelのほとんどのバージョンでは、単純にセル範囲を選択してから「範囲に名前を付ける」ポップアップ・メニューを使用して、その範囲に名前を付けることができます。名前に関する概念情報およびスプレッドシートのセル範囲の定義方法は、Microsoft Excelのドキュメントを参照してください。

標準のリバース・エンジニアリング

Microsoft Excelで標準のリバースエンジニアリングを実行するには、『Oracle Data Integratorでの統合プロジェクトの開発』のモデルのリバースエンジニアリングに関する項の説明に従って、通常の手順を使用します。

注意:
モデルの「リバース・エンジニアリング」タブの「リバース・エンジニアリングするオブジェクトの型」セクションで、スプレッドシートおよび名前付きセル範囲をリバース・エンジニアリングするために「表」および「システム表」を選択します。

8.6 マッピングの設計

Microsoft Excelファイルは、マッピングのソースまたはターゲットとして使用できますが、ステージング領域としては使用できません。

マッピングまたはチェック用に選択したKMによって、このマッピングまたはチェックの機能およびパフォーマンスが決まります。この項に示す推奨事項は、Microsoft Excelサーバーに関連する様々な状況でのKMの選択に役立ちます。

8.6.1 Microsoft Excelとの間でのデータのロード

マッピングのソースまたはターゲットとしてMicrosoft Excelを使用できます。マッピング・フロー・タブでの、Microsoft Excelと別のタイプのデータ・サーバー間でデータをロードするためのLKMの選択は、マッピングのパフォーマンスに関してきわめて重要です。

8.6.1.1 Microsoft Excelからのデータのロード

Oracle Data Integratorには、Microsoft Excel専用のナレッジ・モジュールは用意されていません。汎用SQL KMまたはステージング領域として使用するテクノロジ固有のKMを使用してください。次の表に、Microsoft Excelから任意のステージング領域へのデータのロードに使用できる汎用SQL KMの一部をリストします。

表8-1 Microsoft ExcelからロードするためのKM

ターゲットまたはステージング領域

KM

説明

Oracle

LKM SQL to Oracle

任意のISO-92データベースからOracleターゲット・データベースへデータをロードします。統計を使用します。

SQL

LKM SQL to SQL

ISO-92データベースからISO-92準拠のターゲット・データベースにデータをロードします。

Microsoft SQL Server

LKM SQL to MSSQL (bulk)

任意のISO-92データベースからMicrosoft SQL Serverターゲット・データベースへデータをロードします。バルク・ロードを使用します。

8.6.1.2 Microsoft Excelへのデータのロード

Microsoft Excelはステージング領域として使用できないため、LKMを使用してMicrosoft Excelにデータをロードすることはできません。Microsoft Excelへのデータの統合方法は、8.6.2項「Microsoft Excelでのデータの統合」を参照してください。

8.6.2 Microsoft Excelでのデータの統合

Oracle Data Integratorには、Microsoft Excel専用のナレッジ・モジュールは用意されていません。汎用SQL KMまたはステージング領域として使用するテクノロジ固有のKMを使用してください。ステージング領域からMicrosoft Excelへデータを統合するには、IKM SQL to SQL Appendなどを使用できます。

8.7 トラブルシューティング

この項では、Oracle Data IntegratorでのMicrosoft Excelテクノロジの使用時に発生する可能性がある問題のトラブルシューティングに関する情報を提供します。この章の内容は、次のとおりです。

- エラー・メッセージの解読

- 一般的な問題および解決策

8.7.1 エラー・メッセージの解読

通常、Oracle Data Integratorではエラーは次のように表示されます。

java.sql.SQLException: java.sql.SQLException: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified RC=Oxb
at ... ...

このjava.sql.SQLExceptionコードは、JDBC-ODBCブリッジを介して問合せが行われ、エラーが戻されたことを単純に示しています。このエラーはデータベースまたはドライバのエラーであることが多く、次のように解明する必要があります。

まず、イタリック体のテキスト部分のみに注目してください。これは、ODBCドライバまたはExcelのドキュメントで検索する必要があります。ここで太字のイタリック体で示されているように、固有のエラー・コードが含まれている場合は、エラーをすばやく識別できます。

このようなエラーが実行ログで検出された場合は、SQLコードを分析してエラーの原因を特定する必要があります。このコードは、エラーのあるタスクの「説明」タブに表示されます。

Excelの最も一般的なエラーおよび主な原因について、次項で説明します。

8.7.2 一般的な問題および解決策

この項では、一般的な問題および解決策について説明します。

- [Microsoft][ODBC Excel Driver] Invalid SQL statement; expected 'DELETE', 'INSERT', 'PROCEDURE', 'SELECT', or 'UPDATE'.
このエラーは、インストールされたODBCドライバの機能的制限によるものである可能性があります。Microsoft Office同梱のデフォルトODBCドライバなど、完全版のODBCドライバをインストールする必要があるかもしれません。

- Invalid Fetch Size
ODIに定義されているMicrosoft Excelデータ・サーバーの配列フェッチ・サイズが0に設定されていることを確認してください。

- [Microsoft][ODBC Excel Driver] Could not decrypt file.
パスワード保護されたMicrosoft Excelワークブックを、使用するJDBC-ODBC接続に対して開いたままとする必要があるかもしれません。

- UnknownDriverException
JDBCドライバが不正です。ドライバの名前を確認してください。

- [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified RC=0xb Datasource not found or driver name not specified
JDBC URLで指定されたODBCデータソースが不正です。

- The Microsoft Jet Database engine could not find the object <object name>
アクセスしようとしている表が存在しないか、Excelスプレッドシートで定義されていません。

- Too few parameters. Expected 1.
Excelスプレッドシートに存在しない列にアクセスしようとしています。

- Operation must use an updateable query.
このエラーは通常、Excel DSNの定義時に読取り専用オプションを選択解除しなかった場合に発生します。このオプションを選択解除して、マッピングを再実行してください。

9 Microsoft Access

この章では、Oracle Data IntegratorでのMicrosoft Accessの使用方法について説明します。

この章には次の項が含まれます:

- 9.1項「概要」

- 9.2項「概念」

- 9.3項「ナレッジ・モジュール」

- 9.4項「固有の要件」

9.1 概要

Oracle Data Integrator (ODI)では、Microsoft Accessデータベースのデータがシームレスに統合されます。Oracle Data Integratorの機能(マッピングなど)は、Microsoft Accessを使用した場合に最良の動作が得られるように設計されています。

9.2 概念

Microsoft Accessの概念は、Oracle Data Integratorの概念に次のようにマップされます。1つのMicrosoft AccessデータベースはOracle Data Integratorの1つのデータ・サーバーに対応します。このサーバー内で、スキーマがOracle Data Integrator物理スキーマにマップされます。

Oracle Data Integratorでは、Open Database Connectivity(ODBC)を使用してMicrosoft Accessデータベースに接続します。

9.3 ナレッジ・モジュール

Oracle Data Integratorには、Microsoft Accessデータを処理するためのIKM Access Incremental Updateが用意されています。このIKMでは、増分更新モードでMicrosoft Accessのターゲット表にデータが統合されます。

IKM Access Incremental Updateでは、一時的なステージング表を作成してデータ・フローをステージングし、その内容をターゲット表と比較して、挿入するレコードおよび更新するレコードを識別します。また、CKMを起動してデータ整合性チェックを実行することもできます。

Microsoft Accessのターゲット表をロードして、欠落しているレコードを挿入し、既存のレコードを更新する場合は、このKMの使用を検討してください。

このIKMを使用するには、ステージング領域がターゲットと同じデータ・サーバー上にあることが必要です。

このKMでは、Microsoft Access固有の機能が使用されます。Microsoft Accessデータベースでは、汎用SQL KMを使用することもできます。詳細は、第4章「汎用SQL」を参照してください。

注意:
MS Accessのリバース・エンジニアリングでは、主キーは取得されません。IKM Access Incremental Updateが正常に機能するためには、手動で主キー制約をデータストアに追加する必要があります。

9.4 固有の要件

Oracle Data IntegratorでMicrosoft Accessを使用するための固有の要件はありません。

10 Netezza

この章では、Oracle Data IntegratorでのNetezzaの使用方法について説明します。

この章には次の項が含まれます:

- 10.1項「概要」

- 10.2項「インストールおよび構成」

- 10.3項「トポロジの設定」

- 10.4項「統合プロジェクトの設定」

- 10.5項「Netezzaモデルの作成およびリバース・エンジニアリング」

- 10.6項「データ品質の設定」

- 10.7項「マッピングの設計」

10.1 概要

Oracle Data Integrator (ODI)では、Netezzaデータベースのデータがシームレスに統合されます。Oracle Data Integratorの機能(リバース・エンジニアリング、データ整合性チェックおよびマッピングなど)は、Netezzaを使用した場合に最良の動作が得られるように設計されています。

10.1.1 概念

Netezzaデータベースの概念は、Oracle Data Integratorの概念に次のようにマップされます。1つのNetezzaクラスタはOracle Data Integratorの1つのデータ・サーバーに対応します。このサーバー内で、データベースと所有者の1つのペアは、Oracle Data Integratorの1つの物理スキーマにマップされます。

Oracle Data Integratorでは、Java Database Connectivity (JDBC)を使用してNetezzaデータベースに接続します。

10.1.2 ナレッジ・モジュール

Oracle Data Integratorには、Netezzaデータを処理するためのナレッジ・モジュール(KM)が用意されています。これらのリストを表10-1に示します。これらのKMでは、Netezza固有の機能が使用されます。Netezzaデータベースでは、汎用SQL KMを使用することもできます。詳細は、第4章「汎用SQL」を参照してください。

表10-1 Netezza KM

ナレッジ・モジュール

説明

CKM Netezza

Netezza表で定義された制約と照合して、データの整合性をチェックします。無効なレコードを拒否して、動的に作成されるエラー表に格納します。フロー制御および静的制御に使用できます。

IKM Netezza Control Append

置換/追加モードでNetezzaのターゲット表にデータを統合します。CKMを使用してフロー・データをチェックする必要がある場合は、CKMを起動する前に一時的なステージング表が作成されます。

IKM Netezza Incremental Update

増分更新モードでNetezzaのターゲット表にデータを統合します。

IKM Netezza To File (EXTERNAL TABLE)

Netezzaのステージング領域からターゲット・ファイルにデータを統合します。Netezza固有のEXTERNAL TABLE機能が使用されます。

LKM File to Netezza (EXTERNAL TABLE)

EXTERNAL TABLE機能(dataobject)を使用して、ファイルからNetezzaサーバーのステージング領域へデータをロードします。

LKM File to Netezza (NZLOAD)

NZLOADを使用して、ファイルからNetezzaサーバー・ステージング領域へデータをロードします。

RKM Netezza

NetezzaデータベースからJDBCメタデータを取得します。このRKMを使用して、Netezza JDBCメタデータをOracle Data Integratorメタデータに変換するための独自の戦略を指定することも可能です。

Netezza JDBCドライバの特異性により、標準のJDBCリバースエンジニアリング・プロセスで問題が発生した場合は、このRKMの使用を検討してください。

10.2 インストールおよび構成

Netezzaナレッジ・モジュールの使用を開始する前に、この項の情報を必ず読んでください。

- システム要件および動作要件

- テクノロジ固有の要件

- 接続性要件

10.2.1 システム要件および動作要件

インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。

サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。

http://www.oracle.com/technology/products/oracle-data-integrator/index.html

10.2.2 テクノロジ固有の要件

Netezzaの一部のナレッジ・モジュールでは、NZLOADユーティリティが使用されます。

これらのナレッジ・モジュールには、次の要件および制限が適用されます。

- ソース・ファイルには、マッピングを実行するODIエージェントからアクセスできる必要があります。

- ランタイム・エージェント・マシンにNetezza Performance Serverクライアントがインストールされている必要があります。さらに、エージェントの起動時にNZLOADインストール・ディレクトリがPATH変数に含まれている必要があります。

- すべてのマッピングがステージング領域にあることが必要です。

- すべてのソース・フィールドがマップされ、Netezzaのターゲット表と同じ順序であることが必要です。

- 日付、時間、タイムスタンプおよび数値書式の指定がNetezzaのデータ型定義と一致する必要があります。

EXTERNAL TABLE機能を使用するKMでは、Netezzaサーバーからファイルにアクセスできることを確認してください。

10.2.3 接続性要件

この項では、Netezzaデータベースに接続するための要件をリストします。

JDBCドライバ

Oracle Data Integratorでは、Netezza JDBCを使用してNCR Netezzaデータベースに接続します。このドライバをOracle Data Integratorのdriversディレクトリにインストールする必要があります。

10.3 トポロジの設定

トポロジの設定には次が含まれます。

1. Netezzaデータ・サーバーの作成

2. Netezza物理スキーマの作成

10.3.1 Netezzaデータ・サーバーの作成

1つのNetezzaデータ・サーバーは、特定のNetezzaユーザー・アカウントに接続された1つのNetezzaクラスタに対応します。このユーザーは、データ・サーバーの下に作成されたOracle Data Integratorの物理スキーマに対応する、このクラスタの複数のデータベースにアクセスできます。

10.3.1.1 データ・サーバーの作成

『Oracle Data Integratorでの統合プロジェクトの開発』のデータ・サーバーの作成に関する項の説明に従って、標準の手順を使用してNetezzaテクノロジ用のデータ・サーバーを作成します。この項では、Netezzaデータ・サーバーの定義に関する必須または固有のフィールドのみについて説明します。

1. 「定義」タブ:

- 名前: Oracle Data Integratorに表示されるデータ・サーバーの名前

- サーバー: データ・サーバーの物理名

- ユーザー/パスワード: Netezzaユーザーおよびそのパスワード

2. 「JDBC」タブ:

- JDBCドライバ: org.netezza.Driver

- JDBC URL: jdbc:Netezza://<host>:<port>/<database>

注意:
Oracle Data Integratorが書込みアクセス権を持つのは、URLで指定されたデータベースのみです。

10.3.2 Netezza物理スキーマの作成

『Oracle Data Integratorの管理』の物理スキーマの作成に関する項の説明に従って、標準の手順を使用してNetezza物理スキーマを作成します。

注意:
この構成を実行する場合は、作業データベースとデータ・データベースの名前を一致させる必要があります。また、Netezzaでは、ドル記号($)は名前に対して無効な文字です。作業表およびジャーナル化要素接頭辞からドル記号($)を削除してください。

『Oracle Data Integratorの管理』の論理スキーマの作成に関する項の説明に従って、標準の手順を使用してこの物理スキーマ用の論理スキーマを作成し、特定のコンテキストで関連付けます。

10.4 統合プロジェクトの設定

Netezzaデータベースを使用してプロジェクトを設定するには、標準の手順に従います。『Oracle Data Integratorでの統合プロジェクトの開発』の統合プロジェクトの作成に関する項を参照してください。

Netezzaでの作業を開始するにあたり、使用するプロジェクトに次のナレッジ・モジュールをインポートすることをお薦めします。

- CKM NetezzaIKM Netezza Control AppendIKM Netezza Incremental UpdateIKM Netezza To File (EXTERNAL TABLE)LKM File to Netezza (EXTERNAL TABLE)LKM File to Netezza (NZLOAD)RKM Netezza

10.5 Netezzaモデルの作成およびリバース・エンジニアリング

この項には次のトピックが含まれます:

- Netezzaモデルの作成

- Netezzaモデルのリバース・エンジニアリング

10.5.1 Netezzaモデルの作成

『Oracle Data Integratorでの統合プロジェクトの開発』のモデルの作成に関する項の説明に従って、標準の手順を使用してNetezzaモデルを作成します。

10.5.2 Netezzaモデルのリバース・エンジニアリング

Netezzaでは、JDBCドライバの機能のみを使用する標準のリバース・エンジニアリング、およびカスタマイズされたリバース・エンジニアリングの両方がサポートされています。

通常は、標準のJDBCリバース・エンジニアリングを使用して作業を開始することを検討してください。

Netezza JDBCドライバの特異性によって、標準のJDBCリバース・エンジニアリング・プロセスで問題が発生した場合は、カスタマイズされたリバース・エンジニアリングへの切替えを検討してください。

標準のリバース・エンジニアリング

Netezzaで標準のリバースエンジニアリングを実行するには、『Oracle Data Integratorでの統合プロジェクトの開発』のモデルのリバースエンジニアリングに関する項の説明に従って、通常の手順を使用します。

カスタマイズされたリバース・エンジニアリング

RKMを使用してNetezzaでカスタマイズされたリバースエンジニアリングを実行するには、『Oracle Data Integratorでの統合プロジェクトの開発』のモデルのリバースエンジニアリングに関する項の説明に従って、通常の手順を使用します。この項では、Netezzaテクノロジ固有のフィールドのみについて説明します。

1. Netezzaモデルの「リバース・エンジニアリング」タブでKM: RKM Netezza.<project name>を選択します。

リバース・エンジニアリングによって、表、ビュー、属性、キーおよび外部キーが戻されます。

10.6 データ品質の設定

Oracle Data Integratorには、Netezza表で定義された制約と照合してデータの整合性をチェックするためのNetezza CKMが用意されています。詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』のフロー制御および静的制御に関する項を参照してください。

10.7 マッピングの設計

マッピングのソース、ステージング領域またはターゲットとしてNetezzaを使用できます。

マッピングまたはチェック用に選択したKMによって、このマッピングまたはチェックの機能およびパフォーマンスが決まります。この項に示す推奨事項は、Netezzaデータ・サーバーに関連する様々な状況でのKMの選択に役立ちます。

10.7.1 Netezzaとの間でのデータのロード

マッピングのソース、ターゲットまたはステージング領域としてNetezzaを使用できます。「ロード・ナレッジ・モジュール」タブでの、Netezzaと別のタイプのデータ・サーバー間でデータをロードするためのLKMの選択は、マッピングのパフォーマンスに関してきわめて重要です。

10.7.1.1 Netezzaからのデータのロード

汎用SQL KMまたは関係するもう一方のテクノロジ固有のKMを使用して、Netezzaデータベースからターゲットまたはステージング領域のデータベースへデータをロードします。

Netezzaのステージング領域からファイルへデータを抽出する場合は、IKM Netezza to File (EXTERNAL TABLE)を使用します。詳細は、10.7.2項「Netezzaでのデータの統合」を参照してください。

10.7.1.2 Netezzaへのデータのロード

Oracle Data Integratorには、ソースまたはステージング領域からNetezzaデータベースへデータをロードするための最適化されたメソッドを実装するナレッジ・モジュールが用意されています。これらの最適化されたNetezza KMを表10-2にリストします。これらのKM以外に、汎用SQL KMまたは関係するもう一方のテクノロジ固有のKMも使用できます。

表10-2 NetezzaにデータをロードするためのKM

ソースまたはステージング領域のテクノロジ

KM

説明

ファイル

LKM File to Netezza (EXTERNAL TABLE)

Netezza External表機能を使用して、ファイルからNetezzaのステージング領域データベースへデータをロードします。

ファイル

LKM File to Netezza (NZLOAD)

NZLOADバルク・ローダーを使用して、ファイルからNetezzaステージング領域データベースへデータをロードします。

10.7.2 Netezzaでのデータの統合

Oracle Data Integratorには、Netezza用に最適化されたデータ統合戦略を実装するナレッジ・モジュールが用意されています。これらの最適化されたNetezza KMを表10-3にリストします。これらのKM以外に、汎用SQL KMも使用できます。

「統合ナレッジ・モジュール」タブのIKMの選択によって、統合のパフォーマンスおよび可能性が決まります。

表10-3 Netezzaにデータを統合するためのKM

KM

説明

IKM Netezza Control Append

置換/追加モードでNetezzaのターゲット表にデータを統合します。

IKM Netezza Incremental Update

増分更新モードでNetezzaのターゲット表にデータを統合します。

このKMでは、処理の分布を定義するためのDISTRIBUTE_ONオプションが実装されます。処理パフォーマンスを最大にするためにデータを均等に分散するには、カーディナリティが高い(区別される値が多数存在する)列を選択することが重要です。

このような列の選択は、Netezzaの推奨に従ってください。有効なオプションは次のとおりです。

- [PK]: ターゲット表の主キー

- [UK]: マッピングの更新キー

- [RANDOM]: ランダム分布

- <列のリスト>: カンマ区切りの列のリスト

値が設定されていない場合(空の場合)、索引は作成されません。

このKMでは、統合後にターゲット上で統計を生成するために、ANALYZE_TARGETオプションも使用されます。

IKM Netezza to File (EXTERNAL TABLE)

外部表を使用して、Netezzaのステージング領域からファイルへデータを統合します。

このKMでは、オプションのBASE_TABLEオプションを使用して、外部表のテンプレートとして使用される表の名前が指定されます。

11 Teradata

この章では、Oracle Data IntegratorでのTeradataの使用方法について説明します。

この章には次の項が含まれます:

- 11.1項「概要」

- 11.2項「インストールおよび構成」

- 11.3項「トポロジの設定」

- 11.4項「統合プロジェクトの設定」

- 11.5項「Teradataモデルの作成およびリバース・エンジニアリング」

- 11.6「データ品質の設定」

- 11.7項「マッピングの設計」

- 11.8項「Teradata用のKMの最適化」

11.1 概要

Oracle Data Integrator (ODI)では、Teradataデータベースのデータがシームレスに統合されます。Oracle Data Integratorの機能(リバース・エンジニアリング、データ整合性チェックおよびマッピングなど)は、Teradataを使用した場合に最良の動作が得られるように設計されています。

11.1.1 概念

Teradataデータベースの概念は、Oracle Data Integratorの概念に次のようにマップされます。1つのTeradataサーバーはOracle Data Integratorの1つのデータ・サーバーに対応します。このサーバー内で、1つのデータベースはOracle Data Integratorの1つの物理スキーマにマップされます。

Oracle Data Integratorでは、Java Database Connectivity (JDBC)およびTeradataユーティリティを使用して、Teradataデータベースに接続します。

11.1.2 ナレッジ・モジュール

Oracle Data Integratorには、Teradataデータを処理するためのナレッジ・モジュール(KM)が用意されています。これらのリストを表11-1に示します。これらのKMでは、Teradata固有の機能が使用されます。Teradataデータベースでは、汎用SQL KMを使用することもできます。詳細は、第4章「汎用SQL」を参照してください。

表11-1 Teradata KM

ナレッジ・モジュール

説明

CKM Teradata

Teradata表で定義された制約と照合して、データの整合性をチェックします。無効なレコードを拒否して、動的に作成されるエラー表に格納します。フロー制御および静的制御に使用できます。

IKM File to Teradata (TTU)

このIKMは、Teradataユーティリティの能力を利用してファイルを直接ターゲットにロードするように設計されています。詳細は、11.8.2項「Teradataユーティリティのサポート」を参照してください。

IKM SQL to Teradata (TTU)

Teradataユーティリティ(FastLoad、MultiLoad、TPumpまたはParallel Transporter)を使用して、SQL準拠のデータベースからTeradataデータベースのターゲット表へ、データを統合します。詳細は、11.8.2項「Teradataユーティリティのサポート」を参照してください。

IKM Teradata Control Append

置換/追加モードでTeradataのターゲット表にデータを統合します。

IKM Teradata Incremental Update

増分更新モードでTeradataのターゲット表にデータを統合します。

IKM Teradata Slowly Changing Dimension

データ・ウェアハウスでタイプ2の緩やかに変化するディメンションとして使用されるTeradataのターゲット表に、データを統合します。

IKM Teradata to File (TTU)

置換モードでTeradataのステージング領域からターゲット・ファイルにデータを統合します。詳細は、11.8.2項「Teradataユーティリティのサポート」を参照してください。

IKM Teradata Multi Statement

1つのSQLトランザクションで管理される複数文リクエストを使用して、Teradataデータベース・ターゲット表にデータを統合します。詳細は、「複数文リクエストの使用」を参照してください。

IKM SQL to Teradata Control Append

ANSI-92準拠ソース・データベースからTeradataターゲット表へ、切捨て/挿入(追加)モードでデータを統合します。

通常、このIKMはETL構成に使用されます。この構成では、ソース表とターゲット表は異なるデータベースにあり、マッピングのステージング領域は、ソース表の論理スキーマまたは第3のスキーマに設定されます。

LKM File to Teradata (TTU)

Teradataのバルク・ユーティリティを使用して、ファイルからTeradataステージング領域データベースへデータをロードします。詳細は、11.8.2項「Teradataユーティリティのサポート」を参照してください。

LKM SQL to Teradata (TTU)

Teradataのネイティブ・バルク・ユーティリティを使用して、SQL準拠のソース・データベースからTeradataステージング領域データベースへデータをロードします。詳細は、11.8.2項「Teradataユーティリティのサポート」を参照してください。

RKM Teradata

DBCシステム・ビューを使用して、Teradataデータベースからメタデータを取得します。RKMでは、UNICODEの列がサポートされます。

11.2 インストールおよび構成

Teradataナレッジ・モジュールの使用を開始する前に、この項の情報を必ず読んでください。

- システム要件および動作要件

- テクノロジ固有の要件

- 接続性要件

11.2.1 システム要件および動作要件

インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。

サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。

http://www.oracle.com/technology/products/oracle-data-integrator/index.html

11.2.2 テクノロジ固有の要件

Teradataの一部のナレッジ・モジュールでは、次のTeradataツールおよびユーティリティ(TTU)が使用されます。

- FastLoad

- MultiLoad

- Tpump

- FastExport

- Teradata Parallel Transporter

これらのナレッジ・モジュールには、次の要件および制限が適用されます。

- Teradataユーティリティを、Oracle Data Integratorエージェントを実行するマシンにインストールする必要があります。

- トポロジで定義されるTeradataサーバーのサーバー名は、このサーバーに使用されるTeradata接続文字列(COP_n postfixを除く)と一致する必要があります。

- エージェントは、ターゲットのTeradataホストとは別のプラットフォームにインストールすることをお薦めします。エージェントがインストールされるマシンには、ターゲットTeradataサーバーへの非常に高いネットワーク・バンド幅が必要です。

- IKM File to Teradata (TTU)およびLKM File to Teradata (TTU)では、TTUで統合されるファイルのエンコーディングを指定するためのファイル文字セットのエンコーディング・オプションがサポートされています。このオプションを設定しない場合は、デフォルトのTTU文字セットが使用されます。
文字セットのエンコーディングの詳細は、Teradataのガイド『Getting Started: International Character Sets and the Teradata Database』を参照してください。

詳細は、Teradataのドキュメントを参照してください。

11.2.3 接続性要件

この項では、Teradataデータベースに接続するための要件をリストします。

JDBCドライバ

Oracle Data Integratorでは、Teradata JDBCドライバを使用してTeradataデータベースに接続します。Teradata JDBCゲートウェイが稼働しており、このドライバがOracle Data Integratorインストールにインストールされている必要があります。このドライバは次の場所にあります。

http://www.teradata.com/DownloadCenter/Group48.aspx

11.3 トポロジの設定

トポロジの設定には次が含まれます。

1. Teradataデータ・サーバーの作成

2. Teradata物理スキーマの作成

11.3.1 Teradataデータ・サーバーの作成

1つのTeradataデータ・サーバーは、特定のTeradataユーザー・アカウントに接続された1つのTeradataデータベースに対応します。このユーザーは、データ・サーバーの下に作成されたOracle Data Integratorの物理スキーマに対応する、このTeradataシステムの複数のデータベースにアクセスできます。

11.3.1.1 データ・サーバーの作成

『Oracle Data Integratorでの統合プロジェクトの開発』のデータ・サーバーの作成に関する項の説明に従って、標準の手順を使用してTeradataテクノロジ用のデータ・サーバーを作成します。この項では、Teradataデータ・サーバーの定義に関する必須または固有のフィールドのみについて説明します。

1. 「定義」タブ:

- 名前: Oracle Data Integratorに表示されるデータ・サーバーの名前

- サーバー: データ・サーバーの物理名

- ユーザー/パスワード: Teradataユーザーおよびそのパスワード

2. 「JDBC」タブ:

- JDBCドライバ: com.teradata.jdbc.TeraDriver

- JDBC URL: jdbc:teradata://<host>:<port>/<server>
URLのパラメータは次のとおりです。

- <host>: Teradata JDBCゲートウェイ・マシンのネットワーク名またはIPアドレス

- <port>: ゲートウェイのポート番号(通常7060)

- <server>: 接続するTeradataサーバーの名前

11.3.2 Teradata物理スキーマの作成

『Oracle Data Integratorの管理』の物理スキーマの作成に関する項の説明に従って、標準の手順を使用してTeradata物理スキーマを作成します。

『Oracle Data Integratorの管理』の論理スキーマの作成に関する項の説明に従って、標準の手順を使用してこの物理スキーマ用の論理スキーマを作成し、特定のコンテキストで関連付けます。

11.4 統合プロジェクトの設定

Teradataデータベースを使用してプロジェクトを設定するには、標準の手順に従います。『Oracle Data Integratorでの統合プロジェクトの開発』の統合プロジェクトの作成に関する項を参照してください。

Teradataでの作業を開始するにあたり、使用するプロジェクトに次のナレッジ・モジュールをインポートすることをお薦めします。

- CKM Teradata

- IKM File to Teradata (TTU)

- IKM SQL to Teradata (TTU)

- IKM Teradata Control Append

- IKM Teradata Incremental Update

- IKM Teradata Multi Statement

- IKM Teradata Slowly Changing Dimension

- IKM Teradata to File (TTU)

- IKM SQL to Teradata Control Append

- LKM File to Teradata (TTU)

- LKM SQL to Teradata (TTU)

- RKM Teradata

11.5 Teradataモデルの作成およびリバース・エンジニアリング

この項には次のトピックが含まれます:

- Teradataモデルの作成

- Teradataモデルのリバース・エンジニアリング

11.5.1 Teradataモデルの作成

『Oracle Data Integratorでの統合プロジェクトの開発』のモデルの作成に関する項の説明に従って、標準の手順を使用してTeradataモデルを作成します。

11.5.2 Teradataモデルのリバース・エンジニアリング

Teradataでは、JDBCドライバの機能のみを使用する標準のリバース・エンジニアリング、およびDBCシステム・ビューを使用してTeradataデータベースからメタデータを取得するためのRKMを使用する、カスタマイズされたリバース・エンジニアリングの両方がサポートされています。

通常は、標準のJDBCリバース・エンジニアリングを使用して作業を開始することを検討してください。Teradataで標準のリバース・エンジニアリングを使用すると、表および列が取得されます。

カスタマイズされたリバース・エンジニアリングは、できるかぎり、それ以外のメタデータを取得する場合に使用してください。Teradataのカスタマイズされたリバース・エンジニアリングでは、表、ビュー、列、キー(1次索引および2次索引)および外部キーが取得されます。記述情報(列タイトルおよび簡単な説明)もリバースエンジニアリングされます。

標準のリバース・エンジニアリング

Teradataで標準のリバースエンジニアリングを実行するには、『Oracle Data Integratorでの統合プロジェクトの開発』のモデルのリバースエンジニアリングに関する項の説明に従って、通常の手順を使用します。

カスタマイズされたリバース・エンジニアリング

RKMを使用してTeradataでカスタマイズされたリバースエンジニアリングを実行するには、『Oracle Data Integratorでの統合プロジェクトの開発』のモデルのリバースエンジニアリングに関する項の説明に従って、通常の手順を使用します。この項では、Teradataテクノロジ固有のフィールドのみについて説明します。

1. Teradataモデルの「リバース・エンジニアリング」タブでKM: RKM Teradata.<project name>を選択します。

2. データベース内の既存のFK制約をリバース・エンジニアリングする場合は、REVERSE_FKSオプションをtrueに設定します。

3. 表制約をリバース・エンジニアリングする場合は、REVERSE_TABLE_CONSTRAINTSをtrueに設定します。

4. UnicodeデータベースのVARCHARおよびCHARをそれぞれCHAR()CHARACTER SET UNICODEまたはVARCHAR()CHARACTER SET UNICODEとしてリバース・エンジニアリングする場合は、表作成でCHARACTER SET UNICODE句を使用するかどうかに関係なく、REVERSE_COLUMN_CHARACTER_SETをtrueに設定します。

リバース・エンジニアリングによって、表、ビュー、列、キー(1次索引および2次索引)および外部キーが戻されます。記述情報(列タイトルおよび簡単な説明)もリバース・エンジニアリングされます。

一意索引は次のようにリバースされることに注意してください。

- 一意の1次索引は主キーとみなされます。

- 1次索引は一意でない索引とみなされます。

- 2次の一意の1次索引は、代替キーとみなされます。

- 2次の一意でない1次索引は、一意でない索引とみなされます。

標準のJDBCインタフェースでサポートされていない特定のTeradataメタデータ(1次索引など)を取得するには、このRKMを使用できます。

11.6 データ品質の設定

Oracle Data Integratorには、Teradata表で定義された制約と照合してデータの整合性をチェックするためのTeradata CKMが用意されています。詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』のフロー制御および静的制御に関する項を参照してください。

Oracle Data Integratorには、Teradataのチェックを実行するためのナレッジ・モジュールが用意されています。これらのリストを表11-2に示します。

表11-2 Teradataデータベース用チェック・ナレッジ・モジュール

推奨KM

説明

CKM Teradata

Teradata表で定義された制約と照合して、データの整合性をチェックします。無効なレコードを拒否して、動的に作成されるエラー表に格納します。フロー制御および静的制御に使用できます。

このKMでは、次のTeradataの最適化がサポートされます。

- 1次索引

- 統計

11.7 マッピングの設計

マッピングのソース、ステージング領域またはターゲットとしてTeradataを使用できます。Teradataテクノロジに基づくETL形式のマッピングを作成することもできます。

マッピングまたはチェック用に選択したKMによって、このマッピングまたはチェックの機能およびパフォーマンスが決まります。この項に示す推奨事項は、Teradataデータ・サーバーに関連する様々な状況でのKMの選択に役立ちます。

11.7.1 Teradataとの間でのデータのロード

マッピングのソース、ターゲットまたはステージング領域としてTeradataを使用できます。「ロード・ナレッジ・モジュール」タブでの、Teradataと別のタイプのデータ・サーバー間でデータをロードするためのLKMの選択は、マッピングのパフォーマンスに関してきわめて重要です。

11.7.1.1 Teradataからのデータのロード

汎用SQL KMまたは関係するもう一方のテクノロジ固有のKMを使用して、Teradataデータベースからターゲットまたはステージング領域のデータベースへデータをロードします。

Teradataのステージング領域からファイルへデータを抽出する場合は、IKM File to Teradata (TTU)を使用します。詳細は、11.7.2項「Teradataでのデータの統合」を参照してください。

11.7.1.2 Teradataへのデータのロード

Oracle Data Integratorには、ソースまたはステージング領域からTeradataデータベースへデータをロードするための最適化された方法を実装するナレッジ・モジュールが用意されています。これらの最適化されたTeradata KMを表11-3にリストします。これらのKM以外に、汎用SQL KMまたは関係するもう一方のテクノロジ固有のKMも使用できます。

表11-3 TeradataにデータをロードするためのKM

ソースまたはステージング領域のテクノロジ

KM

説明

ファイル

LKM File to Teradata (TTU)

Teradataのバルク・ユーティリティを使用して、ファイルからTeradataステージング領域データベースへデータをロードします。

この方法では、固有のTeradataユーティリティを使用してステージング領域にファイルをロードするため、大量のデータを処理する場合は、標準のLKM File to SQLより効率的です。

ソースが大きいフラット・ファイルで、ステージング領域がTeradataデータベースの場合は、このLKMの使用を検討してください。

このKMでは、次のTeradataの最適化がサポートされます。

- 統計

- 最適化された一時表管理

SQL

LKM SQL to Teradata (TTU)

Teradataのネイティブ・バルク・ユーティリティを使用して、SQL準拠のソース・データベースからTeradataステージング領域データベースへデータをロードします。

このLKMでは、ソース・データがファイルまたは名前付きパイプにアンロードされ、指定されたTeradataユーティリティがコールされてこのファイルまたはパイプからステージング表に移入されます。名前付きパイプを使用すると、データをファイルに書き込む必要がありません。このLKMは、非常に大量の場合にお薦めします。

次のような場合は、このIKMの使用を検討してください:

- SQL準拠のデータベースのソース・データが大量にある

- ソースとターゲットの間でデータをステージングしたくない

- ステージング領域がTeradataデータベースである。

このKMでは、次のTeradataの最適化がサポートされます。

- Teradataユーティリティのサポート

- 名前付きパイプのサポート

- 最適化された一時表管理

11.7.2 Teradataでのデータの統合

Oracle Data Integratorには、Teradata用に最適化されたデータ統合戦略を実装するナレッジ・モジュールが用意されています。これらの最適化されたTeradata KMを表11-4にリストします。これらのKM以外に、汎用SQL KMも使用できます。

「統合ナレッジ・モジュール」タブのIKMの選択によって、統合のパフォーマンスおよび可能性が決まります。

表11-4 Teradataにデータを統合するためのKM

KM

説明

IKM Teradata Control Append

置換/追加モードでTeradataのターゲット表にデータを統合します。CKMを使用してフロー・データをチェックする必要がある場合は、CKMを起動する前に一時的なステージング表が作成されます。

置換モードで(データ整合性チェックを行って、もしくは行わずに)Teradataのターゲット表をロードする場合は、このIKMの使用を検討してください。

このIKMを使用するには、ステージング領域がターゲットのTeradata表と同じデータ・サーバー上にあることが必要です。

このKMでは、次のTeradataの最適化がサポートされます。

- 1次索引および統計

- 最適化された一時表管理

IKM Teradata Incremental Update

増分更新モードでTeradataのターゲット表にデータを統合します。このIKMにより、データ・フローをステージングするための一時ステージング表が作成されます。その後、その内容をターゲット表と比較して、挿入するレコードおよびそれ以外の更新するレコードを推測します。また、CKMを起動してデータ整合性チェックを実行することもできます。

挿入および更新は、最大のパフォーマンスを得るためにバルク・セットベースの処理で実行されます。そのため、このIKMは大量のデータ用に最適化されています。

Teradataのターゲット表をロードして、欠落しているレコードを挿入し、既存のレコードを更新する場合は、このIKMの使用を検討してください。

このIKMを使用するには、ステージング領域がターゲットと同じデータ・サーバー上にあることが必要です。

このKMでは、次のTeradataの最適化がサポートされます。

- 1次索引および統計

- 最適化された一時表管理

IKM Teradata Multi Statement

1つのSQLトランザクションで管理される複数文リクエストを使用して、Teradataデータベース・ターゲット表にデータを統合します。

IKM Teradata Slowly Changing Dimension

データ・ウェアハウスでタイプ2の緩やかに変化するディメンションとして使用されるTeradataのターゲット表に、データを統合します。このIKMは、ターゲット・データストアで設定される緩やかに変化するディメンション・メタデータに依存して、新しいバージョンとして挿入する必要があるレコード、または既存のバージョンとして更新する必要があるレコードを判別します。

挿入および更新はバルク・セットベースの処理で実行されるため、このIKMは大量のデータ用に最適化されています。

Teradataのターゲット表をタイプ2の緩やかに変化するディメンションとしてロードする場合は、このIKMの使用を検討してください。

このIKMを使用するには、ステージング領域がターゲットと同じデータ・サーバー上にあり、適切な緩やかに変化するディメンション・メタデータがターゲット・データストア上で設定されていることが必要です。

このKMでは、次のTeradataの最適化がサポートされます。

- 1次索引および統計

- 最適化された一時表管理

このKMには、COMPATIBLEオプションも含まれます。このオプションは、Teradataエンジンのメジャー・バージョン番号に対応します。このバージョンが12以上の場合、標準のINSERT文とUPDATE文ではなくMERGE文を使用して入力データ・フローがターゲット表にマージされます。

IKM Teradata to File (TTU)

置換モードでTeradataのステージング領域からターゲット・ファイルにデータを統合します。このIKMの場合、ステージング領域がTeradata上に存在する必要があります。Teradataのネイティブのユーティリティを使用して、ターゲット・ファイルにデータをエクスポートします。

データを変換してTeradataサーバーからターゲット・ファイルへエクスポートする場合は、このIKMの使用を検討してください。

このIKMを使用するには、ステージング領域がターゲットと異なる必要があります。Teradataの場所に設定する必要があります。

このKMでは、次のTeradataの最適化がサポートされます。

- Teradataユーティリティのサポート

IKM File to Teradata (TTU)

このIKMは、Teradataユーティリティの能力を利用してファイルを直接ターゲットにロードするように設計されています。ソースとして1つのファイル、およびターゲットとして1つのTeradata表に制限されます。

選択するユーティリティによって、置換モードまたは増分更新モードでデータを統合できます。

1つのフラット・ファイルをターゲット表にロードする場合は、このIKMの使用を検討してください。このIKMではTeradataユーティリティが使用されるため、大量のデータの処理に適しています。

このIKMを使用するには、ステージング領域をソース・ファイルのスキーマに設定する必要があります。

このKMでは、次のTeradataの最適化がサポートされます。

- 1次索引および統計

- Teradataユーティリティのサポート

- 最適化された一時表管理

IKM SQL to Teradata (TTU)

Teradataユーティリティ(TPUMP、FASTLOADまたはMULTILOAD)を使用して、SQL準拠のデータベースからTeradataデータベースのターゲット表へ、データを統合します。

このIKMは、Teradataユーティリティの能力を利用してソース・データを直接ターゲットにロードするように設計されています。すべてのソース表が同じデータ・サーバーに属し、かつ、このデータ・サーバーがステージング領域(ソース上のステージング領域)として使用される場合にのみ、使用できます。ソース・データはファイルまたは名前付きパイプにアンロードされ、その後、選択されたTeradataユーティリティによってターゲット表に直接ロードされます。名前付きパイプを使用すると、データをファイルに書き込む必要がありません。このIKMは、大量のデータの処理に適しています。

選択するユーティリティによって、置換モードまたは増分更新モードでデータを統合できます。

次のような場合は、このIKMの使用を検討してください:

- ソースで数回の変換を実行してターゲットをロードする

- すべてのソース表が(ステージング領域として使用される)同じデータ・サーバー上にある

- ソースとターゲットの間でデータをステージングしたくない

このIKMを使用するには、ステージング領域をソース・データ・サーバーのスキーマに設定する必要があります。

このKMでは、次のTeradataの最適化がサポートされます。

- 1次索引および統計

- Teradataユーティリティのサポート

- 名前付きパイプのサポート

- 最適化された一時表管理

IKM SQL to Teradata Control Append

ANSI-92準拠ソース・データベースからTeradataターゲット表へ、切捨て/挿入(追加)モードでデータを統合します。

通常、このIKMはETL構成に使用されます。この構成では、ソース表とターゲット表は異なるデータベースにあり、マッピングのステージング領域は、ソース表の論理スキーマまたは第3のスキーマに設定されます。詳細は、11.7.3項「ETL形式マッピングの設計」を参照してください。

緩やかに変化するディメンションの使用

緩やかに変化するディメンションを使用する場合は、ターゲット・データベースの各列に対して「緩やかに変化するディメンション」の値を必ず設定してください。この値は、「サロゲート・キー」、「自然キー」、列の上書きまたは挿入、「現在のレコード・フラグ」、「開始タイムスタンプ」および「終了タイムスタンプ」列を識別するために、IKM Teradata Slowly Changing Dimensionで使用されます。

複数文リクエストの使用

通常、複数文リクエストでは、単純なマッピングのパラレル実行が可能になります。Teradataのパフォーマンスは、スキャンの同期化、および一時ジャーナルの回避によって向上します。

次のようにKMのオプションを設定します。

- このKMを使用するマッピングは、パッケージ内で使用する必要があります。

- 複数文を介して表をロードするパッケージの最初のマッピングでは、INIT_MULTI_STATEMENTオプションをYESに設定します。

- 複数文を介して表をロードする後続のマッピングでは、このKMを使用して、INIT_MULTI_STATEMENTオプションをNOに設定する必要があります。

- 最後のマッピングでは、生成された複数文を実行するために、EXECUTEオプションをYESに設定する必要があります。

- STATEMENT_TYPEオプションで、各マッピングの文のタイプ(挿入または更新)を指定します。

- SQL_OPTIONオプションでは、問合せの最後に追加される追加のSQL文(例: QUALIFY句)を指定します。

複数文に関する次の制限に注意してください。

- 複数文がサポートされるのは、パッケージ内で使用する場合のみです。

- 一時索引はサポートされません。

- 行数に関して、更新は挿入とみなされます。

- 更新には単一のデータセットのみを含めることができます。

- 実行マッピング(EXECUTE = YES)のみで行数がレポートされます。

- ジャーナル化されたソース・データはサポートされません。

- フロー制御および静的制御は、いずれもサポートされません。

- SQL_OPTIONオプションは最後のデータセットのみに適用されます。

11.7.3 ETL形式マッピングの設計

マッピングの設計方法に関する一般的な情報は、『Oracle Data Integratorでの統合プロジェクトの開発』のマッピングの作成に関する項を参照してください。この項では、ステージング領域がTeradataデータベースまたは任意のANSI-92準拠データベースにあり、ターゲットがTeradataにあるETL形式マッピングの設計方法について説明します。

ETL形式マッピングでは、ターゲットとは異なるステージング領域内のデータが、ODIによって処理されます。Oracle Data Integratorでは、TeradataまたはANSI-92準拠のステージング領域からTeradataターゲットへデータをロードするための2つの方法が提供されます。

- 複数接続IKMの使用

- LKMおよび単一接続IKMの使用

使用するKM戦略によって、フロー制御および静的制御がサポートされます。

複数接続IKMの使用

複数接続IKMでは、ステージング領域とソースが異なるデータ・サーバー上にある場合のターゲットへのデータ統合が可能です。

Oracle Data Integratorには、Teradataデータを処理するための複数接続IKMであるIKM SQL to Teradata Control Appendが用意されています。また、汎用SQL複数接続IKMも使用できます。詳細は、第4章「汎用SQL」を参照してください。

複数接続IKMを使用する状況の詳細は、表11-5を参照してください。

ETL形式マッピングで複数接続IKMを使用するには、次のようにします。

1. 『Oracle Data Integratorでの統合プロジェクトの開発』のマッピングの作成に関する項の説明に従って、標準の手順を使用して、ステージング領域がANSI-92準拠であり、ターゲットがTeradata上にあるマッピングを作成します。この項では、ETL形式固有の手順のみを説明します。

2. ソース表の論理スキーマまたは第3のスキーマに対するマッピングのステージング領域を変更します。ステージング領域の変更方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』の実行場所の構成に関する項を参照してください。

3. 物理ダイアグラムでアクセス・ポイントを選択します。このオブジェクトのプロパティ・インスペクタが開きます。

4. 「ロード・ナレッジ・モジュール」タブで、ソースからステージング領域にロードするLKMを選択します。使用できるLKMは表11-5を参照してください。

5. 必要な場合は、KMオプションを変更します。

6. 物理ダイアグラムでターゲットのタイトルをクリックしてターゲットを選択します。このオブジェクトのプロパティ・インスペクタが開きます。

7. 「統合ナレッジ・モジュール」タブで、ステージング領域からターゲットにデータをロードするETL複数接続IKMを選択します。使用できるIKMは表11-5を参照してください。

IKM SQL to Teradata Control AppendのKMオプションを設定する際には、次の点に注意してください。

- ターゲット・システム上に表を作成しない場合は、FLOW_CONTROL=falseを設定します。FLOW_CONTROL=falseの場合、データは直接ターゲット表に挿入されます。

- FLOW_CONTROL=trueの場合、ターゲット表またはステージング領域にフロー表が作成されます。

- 以前の制御から拒否されたデータをリサイクルする場合は、RECYCLE_ERROR=trueを設定し、使用するマッピングに対して更新キーを設定します。

LKMおよび単一接続IKMの使用

専用の複数接続IKMがない場合は、標準のエクスポートLKMと標準の単一接続IKMを組み合せて使用します。エクスポートLKMは、ステージング領域からターゲットへフロー表をロードするために使用します。単一接続IKMは、データ・フローをターゲット表に統合するために使用します。

Oracle Data Integratorでは、ETL形式マッピングのソースおよびステージング領域として、任意のANSI SQL-92標準準拠テクノロジがサポートされています。ターゲットはTeradataです。

標準のLKMおよび単一接続IKMを組み合せて使用する状況の詳細は、表11-5を参照してください。

ETL形式マッピングでLKMおよび単一接続IKMを使用するには、次のようにします。

1. 『Oracle Data Integratorでの統合プロジェクトの開発』のマッピングの作成に関する項の説明に従って、標準の手順を使用して、ステージング領域がANSI-92準拠であり、ターゲットがTeradata上にあるマッピングを作成します。この項では、ETL形式固有の手順のみを説明します。

2. ソース表の論理スキーマまたは第3のスキーマに対するマッピングのステージング領域を変更します。ステージング領域の変更方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』の実行場所の構成に関する項を参照してください。

3. 物理ダイアグラムでアクセス・ポイントを選択します。このオブジェクトのプロパティ・インスペクタが開きます。

4. 「ロード・ナレッジ・モジュール」タブで、ソースからステージング領域にロードするLKMを選択します。使用できるLKMは表11-5を参照してください。

5. 必要な場合は、KMオプションを変更します。

6. ステージング領域に対するアクセス・ポイントを選択します。このオブジェクトのプロパティ・インスペクタが開きます。

7. 「ロード・ナレッジ・モジュール」タブで、ステージング領域からターゲットにロードするLKMを選択します。使用できるLKMは表11-5を参照してください。

8. 必要な場合は、オプションを変更します。

9. 「ターゲット」のタイトルをクリックしてターゲットを選択します。このオブジェクトのプロパティ・インスペクタが開きます。
「統合ナレッジ・モジュール」タブで、ターゲットを更新する標準単一接続IKMを選択します。使用できるIKMは表11-5を参照してください。

表11-5 Teradataデータを使用するETL形式マッピングのKMガイドライン

ソース

ステージング領域

ターゲット

エクスポートLKM

IKM

KM戦略

コメント

ANSI SQL-92標準準拠

ANSI SQL-92標準準拠

Teradata

なし

IKM SQL to Teradata Control Append

複数接続IKM

制御追加を実行する場合に推奨します。

フロー制御をサポートします。

ANSI SQL-92標準準拠

Teradataまたは任意のANSI SQL-92標準準拠データベース

Teradataまたは任意のANSI SQL-92標準準拠データベース

なし

IKM SQL to SQL Incremental Update

複数接続IKM

ターゲット側一時オブジェクトでの増分更新戦略が可能です。ターゲット・サーバーで一時オブジェクトを作成できない場合に、このKMを使用します。

アプリケーションの更新は、ソースからターゲットへ直接行われ、ターゲット上に一時オブジェクトは作成されません。フロー表がターゲットではなくステージング領域に作成される構成は、データ量が少ない場合のみ使用してください。

フロー制御および静的制御をサポートします。

ANSI SQL-92標準準拠

TeradataまたはANSI SQL-92標準準拠

Teradata

LKM SQL to Teradata (TTU)

IKM Teradata Incremental Update

LKM + 標準IKM

ANSI SQL-92標準準拠

Teradata

Teradata

LKM SQL to Teradata (TTU)

IKM Teradata Slowly Changing Dimension

LKM + 標準IKM

ANSI SQL-92標準準拠

ANSI SQL-92標準準拠

Teradata

LKM SQL to Teradata (TTU)

IKM SQL to Teradata (TTU)

LKM + 標準IKM

フロー制御を行わず、データが大量にある場合は、この戦略をお薦めします。

11.8 Teradata用のKMの最適化

この項では、Oracle Data Integratorナレッジ・モジュールに含まれるTeradata専用の最適化について説明します。

この項には次のトピックが含まれます:

- 1次索引および統計

- Teradataユーティリティのサポート

- 名前付きパイプのサポート

- 最適化された一時表管理

11.8.1 1次索引および統計

Teradataのパフォーマンスは、1次索引に大きく依存します。Teradata KMでは、一時表およびターゲット表用にカスタマイズされた1次索引(PI)がサポートされています。これは、Teradata LKM、IKMおよびCKMに当てはまります。一時表およびターゲット表の1次索引は、これらのKMでPRIMARY_INDEX KMオプションを使用して定義できます。次の値が使用されます。

- [PK]: PIは一時表またはターゲット表の主キーです。これはデフォルト値です。

- [NOPI]: 1次索引は指定されません(Teradata 13.0以上のみ)。

- [UK]: PIがマッピングの更新キーになります。これはデフォルト値です。

- <Column list>: これは、カンマ区切りの列名のリストに基づく任意のPIです。

- <Empty string>: 1次索引が指定されていません。TeradataエンジンでPIのデフォルト・ルール(一時表の最初の列)が使用されます。

選択したPI列について、Teradata MultiColumnStatisticsがオプションで収集されます。これは、デフォルトでtrueに設定されているCOLLECT_STATS KMオプションによって制御されます。

11.8.2 Teradataユーティリティのサポート

Teradataユーティリティ(TTU)では、Teradataエンジンから、あるいはTeradataエンジンへデータを転送する効率的な方法が提供されます。TTUをサポートするLKMまたはIKMを使用する場合、TERADATA_UTILITYオプションを使用してデータをロードするための方法を設定できます。

Teradataターゲット(IKM)またはステージング領域(LKM)へデータをプッシュする場合、このオプションは次の値をとります。

- FASTLOAD: Teradata FastLoadを使用します。

- MLOAD: Teradata MultiLoadを使用します。

- TPUMP: Teradata TPumpを使用します。

- TPT-LOAD: Teradata Parallel Transporter(ロード・オペレータ)を使用します。

- TPT-SQL-INSERT: Teradata Parallel Transporter (SQL挿入オペレータ)を使用します。

Teradataからファイルへデータをプッシュする場合、このオプションは次の値をとります。

- FEXP: Teradata FastExportを使用します。

- TPT: Teradata Parallel Transporterを使用します。

TTU KMを使用する場合、KMパラメータも考慮する必要があります。

- REPORT_NB_ROWS: このオプションを使用すると、ユーティリティで処理された行数がマッピングの「警告」ステップでレポートされます。

- SESSIONS: FastLoadセッションの数。

- MAX_ALLOWED_ERRORS: 許容エラーの最大数。これは、FastLoad/MultiLoad/TPumpのERRLIMITコマンドおよびTPTのErrorLimit属性に相当します。

- MULTILOAD_TPUMP_TYPE: MultiLoadまたはTPumpユーティリティで行われる処理。有効な値はINSERT、UPSERTおよびDELETEです。UPSERTおよびDELETEの場合、マッピングで更新キーが必要です。

ユーティリティとロード・オペレータの詳細と適切な選択については、Teradataのドキュメントを参照してください。

11.8.3 名前付きパイプのサポート

TTU KMを使用してSQLソースとTeradataとの間でデータを移動する場合、アンロード/ロード・プロセスでファイルのかわりに名前付きパイプを使用することでパフォーマンスが向上します。名前付きパイプは、NP_USE_NAMED_PIPEオプションをYESに設定するとアクティブにできます。名前付きパイプを使用する場合、次のオプションも考慮する必要があります。

- NP_EXEC_ON_WINDOWS: ランタイム・エージェントがWindowsプラットフォームで稼働する場合、このオプションをYESに設定します。

- NP_ACCESS_MODULE: 名前付きパイプで使用されるアクセス・モジュール。このアクセス・モジュールはプラットフォームに依存します。

- NP_TTU_STARTUP_TIME: TTUでパイプを使用してデータを受信できる秒数。これは、KMでTTUを起動した時点とKMで名前付きパイプへのデータのプッシュを始めた時点との遅延です。この遅延は、マシンの負荷によって異なります。

11.8.4 最適化された一時表管理

Data Integratorの一時的なステージング表の作成および削除によって、Teradataエンジンのリソースが消費される場合があります。ODI_DDL KMオプションによって、これらのDDL操作を制御する方法が提供されます。値は次のいずれかとなります。

- DROP_CREATE: 実行のたびに常にすべての一時表を削除して再作成します(デフォルトの動作)。

- CREATE_DELETE_ALL: 必要な場合(通常最初の実行時のみ)一時表を作成し、DELETE ALLを使用して一時表の内容を削除します。一時表は後続の実行で再利用されます。

- DELETE_ALL: 一時表を作成しません。すべての一時表についてDELETE ALLを発行するのみです。

- NONE: 一時表に対してDDLを発行しません。一時表は別途処理される必要があります。

12 Hypersonic SQL

この章では、Oracle Data IntegratorでのHypersonic SQLの使用方法について説明します。

この章には次の項が含まれます:

- 12.1項「概要」

- 12.2項「インストールおよび構成」

- 12.3項「トポロジの設定」

- 12.4項「統合プロジェクトの設定」

- 12.5項「Hypersonic SQLモデルの作成およびリバース・エンジニアリング」

- 12.6「データ品質の設定」

- 12.7項「マッピングの設計」

12.1 概要

Oracle Data Integrator (ODI)では、Hypersonic SQLデータベースのデータがシームレスに統合されます。Oracle Data Integratorの機能(リバースエンジニアリング、データ整合性チェックおよびマッピングなど)は、Hypersonic SQLを使用した場合に最良の動作が得られるように設計されています。

12.1.1 概念

Hypersonic SQLデータベースの概念は、Oracle Data Integratorの概念に次のようにマップされます。1つのHypersonic SQLサーバーはOracle Data Integratorの1つのデータ・サーバーに対応します。このサーバー内で、単一のOracle Data Integrator物理スキーマがデータベースにマップされます。

Oracle Data Integratorでは、Java Database Connectivity (JDBC)を使用してHypersonic SQLに接続します。

12.1.2 ナレッジ・モジュール

Oracle Data Integratorには、表12-1に示されている、Hypersonic SQLデータを処理するためのナレッジ・モジュール(KM)が用意されています。これらのKMでは、Hypersonic SQL固有の機能が使用されます。Hypersonic SQLデータベースでは、汎用SQL KMを使用することもできます。詳細情報を参照してください。

表12-1 Hypersonic SQLナレッジ・モジュール

ナレッジ・モジュール

説明

CKM HSQL

Hypersonic SQL表で定義された制約と照合して、データの整合性をチェックします。無効なレコードを拒否して、動的に作成されるエラー表に格納します。フロー制御および静的制御に使用できます。

SKM HSQL

Hypersonic SQLデータベースのデータ・アクセスWebサービスを生成します。

12.2 インストールおよび構成

Hypersonic SQLナレッジ・モジュールの使用を開始する前に、この項の情報を必ず読んでください。

- システム要件および動作要件

- テクノロジ固有の要件

- 接続性要件

12.2.1 システム要件および動作要件

インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。

サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。

http://www.oracle.com/technology/products/oracle-data-integrator/index.html

12.2.2 テクノロジ固有の要件

Oracle Data IntegratorでHypersonic SQLを使用するためのテクノロジ固有の要件はありません。

12.2.3 接続性要件

この項では、Hypersonic SQLデータベースに接続するための要件をリストします。

JDBCドライバ

Oracle Data Integratorは、Hypersonic SQL用JDBCドライバとともにインストールされます。このドライバではTCP/IPネットワーク・レイヤーが直接使用され、他のコンポーネントのインストールや構成は不要です。

12.3 トポロジの設定

トポロジの設定には次が含まれます。

1. Hypersonic SQLデータ・サーバーの作成

2. Hypersonic SQL物理スキーマの作成

12.3.1 Hypersonic SQLデータ・サーバーの作成

各Hypersonic SQLデータ・サーバーは、特定のHypersonic SQLユーザー・アカウントに接続された1つのHypersonic SQLデータベースに対応します。このユーザーは、データ・サーバーの下に作成されたOracle Data Integrator内の物理スキーマを介して、データベースにアクセスできます。

『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のデータ・サーバーの作成に関する項に記載されている標準の手順で、Hypersonic SQLテクノロジ用データ・サーバーを作成します。この項では、Hypersonic SQLデータ・サーバーの定義に関する必須または固有のフィールドのみについて説明します。

1. 「定義」タブ:

- 名前: Oracle Data Integratorに表示されるデータ・サーバーの名前

- サーバー: データ・サーバーの物理名

- ユーザー/パスワード: Hypersonic SQLユーザーおよびそのパスワード(通常sa)

2. 「JDBC」タブ:

- JDBCドライバ: org.hsqldb.jdbcDriver

- JDBC URL: jdbc:hsqldb:hsql://<host>:<port>
URLのパラメータは次のとおりです。

- <host>: Hypersonic SQLマシンのネットワーク名またはIPアドレス

- <port>: ポート番号

12.3.2 Hypersonic SQL物理スキーマの作成

『Oracle Data Integratorの管理』の物理スキーマの作成に関する項の説明に従って、標準の手順を使用して物理スキーマを作成します。

『Oracle Data Integratorの管理』の論理スキーマの作成に関する項の説明に従って、標準の手順を使用してこの物理スキーマ用の論理スキーマを作成し、特定のコンテキストで関連付けます。

12.4 統合プロジェクトの設定

Hypersonic SQLデータベースを使用してプロジェクトを設定するには、標準の手順に従います。『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』の統合プロジェクトの作成に関する項を参照してください。

Hypersonic SQLでの作業を開始するにあたり、使用するプロジェクトに次のナレッジ・モジュールをインポートすることをお薦めします。

- CKM HSQL

使用するプロジェクトに汎用SQL KMもインポートします。これらのKMの詳細を参照してください。

12.5 Hypersonic SQLモデルの作成およびリバース・エンジニアリング

この項には次のトピックが含まれます:

- Hypersonic SQLモデルの作成

- Hypersonic SQLモデルのリバース・エンジニアリング

12.5.1 Hypersonic SQLモデルの作成

『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のモデルの作成に関する項に記載されている標準の手順で、Hypersonic SQLモデルを作成します。

12.5.2 Hypersonic SQLモデルのリバース・エンジニアリング

Hypersonic SQLでは、JDBCドライバの機能のみを使用する標準のリバース・エンジニアリングがサポートされています。

Hypersonic SQLで標準のリバース・エンジニアリングを実行するには、『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のモデルのリバース・エンジニアリングに関する項に記載されている通常の手順を行います。

12.6 データ品質の設定

Oracle Data Integratorには、Hypersonic SQL表で定義された制約と照合してデータの整合性をチェックするためのHSQL CKMが用意されています。詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』のフロー制御および静的制御に関する項を参照してください。

Oracle Data Integratorには、表12-2に示されている、Hypersonic SQLのチェックを実行するためのナレッジ・モジュールが用意されています。

表12-2 Hypersonic SQLデータベース用チェック・ナレッジ・モジュール

推奨KM

説明

CKM HSQL

Hypersonic SQL表で定義された制約と照合して、データの整合性をチェックします。無効なレコードを拒否して、動的に作成されるエラー表に格納します。フロー制御および静的制御に使用できます。

12.7 マッピングの設計

マッピングのソース、ステージング領域またはターゲットとしてHypersonic SQLを使用できます。

マッピングまたはチェック用に選択したKMによって、このマッピングまたはチェックの機能およびパフォーマンスが決まります。この項に示す推奨事項は、Hypersonic SQLデータ・サーバーに関連する様々な状況でのKMの選択に役立ちます。

Oracle Data Integratorには、ロードまたは統合のためのHypersonic SQL専用のナレッジ・モジュールは用意されていません。これらのKMか、ソース、ターゲットまたはステージング領域として使用する他のテクノロジに固有のKMを使用してください。

13 IBM Informix

この章では、Oracle Data IntegratorでのIBM Informixの使用方法について説明します。

この章には次の項が含まれます:

- 13.1項「概要」

- 13.2項「概念」

- 13.3項「ナレッジ・モジュール」

- 13.4項「固有の要件」

13.1 概要

Oracle Data Integrator (ODI)では、IBM Informixデータベースのデータがシームレスに統合されます。Oracle Data Integratorの機能(リバースエンジニアリング、ジャーナル化およびマッピングなど)は、IBM Informixを使用した場合に最良の動作が得られるように設計されています。

13.2 概念

IBM Informixの概念は、Oracle Data Integratorの概念に次のようにマップされます。1つのIBM InformixサーバーはOracle Data Integratorの1つのデータ・サーバーに対応します。このサーバー内で、1人の所有者はOracle Data Integratorの1つの物理スキーマにマップされます。

Oracle Data Integratorでは、Java Database Connectivity (JDBC)を使用してIBM Informixデータベースに接続します。

13.3 ナレッジ・モジュール

Oracle Data Integratorには、IBM Informixデータを処理するためのナレッジ・モジュール(KM)が用意されています。これらのリストを表13-1に示します。これらのKMでは、IBM Informix固有の機能が使用されます。IBM Informixデータベースでは、汎用SQL KMを使用することもできます。詳細情報を参照してください。

表13-1 IBM Informixナレッジ・モジュール

ナレッジ・モジュール

説明

IKM Informix Incremental Update

増分更新モードでIBM Informixのターゲット表にデータを統合します。このIKMにより、データ・フローをステージングするための一時ステージング表が作成されます。その後、その内容をターゲット表と比較して、挿入するレコードおよびそれ以外の更新するレコードを推測します。また、CKMを起動してデータ整合性チェックを実行することもできます。

挿入および更新は、最大のパフォーマンスを得るためにバルク・セットベースの処理で実行されます。そのため、このIKMは大量のデータ用に最適化されています。

IBM Informixのターゲット表をロードして、欠落しているレコードを挿入し、既存のレコードを更新する場合は、このIKMの使用を検討してください。

このIKMを使用するには、ステージング領域がターゲットと同じデータ・サーバー上にあることが必要です。

JKM Informix Consistent

トリガーを使用してIBM Informix表の一貫したジャーナル化を行うためのジャーナル化インフラストラクチャを作成します。

IBM Informixでの一貫性セット・チェンジ・データ・キャプチャを有効にします。

このKMを使用するには、ソース・データベースでトランザクション・ロギングが有効になっている必要があります。

JKM Informix Simple

トリガーを使用してIBM Informix表の単純なジャーナル化を行うためのジャーナル化インフラストラクチャを作成します。

IBM Informixでの単純なチェンジ・データ・キャプチャを有効にします。

LKM Informix to Informix (SAME SERVER)

同じサーバー内にあるソースのInformixデータベースからターゲットのInformixステージング領域へ、データをロードします。

このLKMでは、ソース・データベース内のビューおよびステージング領域データベース内のシノニムが作成されます。この方法は通常、大量のデータを処理する場合に標準のLKM SQL to SQLより効率的です。

ソース表がIBM Informixデータベースにあり、ステージング領域が同じInformixサーバーのIBM Informixデータベースにある場合は、このLKMの使用を検討してください。

このKMを使用するには、両方のデータベースで同じロギング・モードが有効になっている必要があります。

RKM Informix

表、ビュー、列、主キーおよび一意でない索引について、IBM Informix固有のメタデータを取得します。このRKMは、基礎となるInformixカタログ表にアクセスしてメタデータを取得します。

デフォルトのJDBCリバースエンジニアリング・プロセスによって提供されていない追加のメタデータをInformixカタログから抽出する場合は、このRKMの使用を検討してください。

SKM Informix

IBM Informixデータベースのデータ・アクセスWebサービスを生成します。詳細は、SKM SQLに関する項を参照してください。

13.4 固有の要件

Oracle Data IntegratorでIBM Informixを使用するための固有の要件はありません。

14 IBM DB2 for iSeries

この章では、Oracle Data IntegratorでのIBM DB2 for iSeriesの使用方法について説明します。

この章には次の項が含まれます:

- 14.1項「概要」

- 14.2項「インストールおよび構成」

- 14.3項「トポロジの設定」

- 14.4項「統合プロジェクトの設定」

- 14.5項「IBM DB2/400モデルの作成およびリバース・エンジニアリング」

- 14.6項「チェンジ・データ・キャプチャの設定」

- 14.7「データ品質の設定」

- 14.8項「マッピングの設計」

- 14.9項「DB2 for iSeries固有の考慮事項」

- 14.10項「トラブルシューティング」

14.1 概要

Oracle Data Integrator (ODI)では、IBM DB2 for iSeriesのデータがシームレスに統合されます。Oracle Data Integratorの機能(リバース・エンジニアリング、チェンジ・データ・キャプチャ、データ整合性チェックおよびマッピングなど)は、IBM DB2 for iSeriesを使用した場合に最良の動作が得られるように設計されています。

14.1.1 概念

IBM DB2 for iSeriesの概念は、Oracle Data Integratorの概念に次のようにマップされます。1つのIBM DB2 for iSeriesサーバーは、Oracle Data Integratorの1つのデータ・サーバーに対応します。このサーバー内で、コレクションまたはスキーマがOracle Data Integrator物理スキーマにマップされます。1つのスキーマ内の関連する一連のオブジェクトが1つのデータ・モデルに対応し、各表、ビューまたはシノニムが、その属性、列および制約とともにODIデータストアとして表示されます。

Oracle Data Integratorでは、Java Database Connectivity (JDBC)を使用してIBM DB2 for iSeriesに接続します。

14.1.2 ナレッジ・モジュール

Oracle Data Integratorには、IBM DB2 for iSeriesデータを処理するためのナレッジ・モジュール(KM)が用意されています。これらのリストを表14-1に示します。これらの特定のIBM DB2 for iSeriesナレッジ・モジュールに加えて、IBM DB2 for iSeriesで汎用SQL KMを使用することもできます。詳細は、第4章「汎用SQL」を参照してください。

表14-1 DB2 for iSeries KM

ナレッジ・モジュール

説明

IKM DB2 400 Incremental Update

増分更新モードでIBM DB2 for iSeriesのターゲット表にデータを統合します。

IKM DB2 400 Incremental Update (CPYF)

増分更新モードでIBM DB2 for iSeriesのターゲット表にデータを統合します。このIKMはIKM DB2 400 Incremental Updateと似ていますが、セットベースのSQL操作ではなく、CPYF固有のOS/400コマンドを使用してターゲット表に書き込む点で異なります。

IKM DB2 400 Slowly Changing Dimension

データ・ウェアハウスでタイプ2の緩やかに変化するディメンションとして使用されるIBM DB2 for iSeriesのターゲット表に、データを統合します。

JKM DB2 400 Consistent

トリガーを使用してIBM DB2 for iSeries表の一貫したジャーナル化を行うためのジャーナル化インフラストラクチャを作成します。

JKM DB2 400 Simple

トリガーを使用してIBM DB2 for iSeries表の単純なジャーナル化を行うためのジャーナル化インフラストラクチャを作成します。

JKM DB2 400 Simple (Journal)

ジャーナルを使用してIBM DB2 for iSeries表の単純なジャーナル化を行うためのジャーナル化インフラストラクチャを作成します。

このKMは推奨されていません。

LKM DB2 400 Journal to SQL

IBM DB2 for iSeriesのソースからANSI SQL-92準拠ステージング領域のデータベースへデータをロードします。このLKMでは、ジャーナルに基づいてCDCインフラストラクチャをリフレッシュする際に、JKM DB2 400 Simple (Journal)でジャーナル化された表をソースとする場合があります。

このKMは推奨されていません。

LKM DB2 400 to DB2 400

CRTDDMFを使用してターゲット上にDDMファイルを作成し、CPYFを使用してソースからこのDDMファイルへデータを転送して、IBM DB2 for iSeriesのソース・データベースからIBM DB2 for iSeriesのステージング領域データベースへデータをロードします。

RKM DB2 400

IBM DB2 for iSeriesのメタデータ(物理ファイル、表、ビュー、外部キー、一意キー)を取得します。

14.2 インストールおよび構成

IBM DB2 for iSeriesテクノロジでの作業を開始する前に、この項の情報を必ず読んでください。

- システム要件および動作要件

- テクノロジ固有の要件

- 接続性要件

14.2.1 システム要件および動作要件

インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。

サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。

http://www.oracle.com/technology/products/oracle-data-integrator/index.html

14.2.2 テクノロジ固有の要件

IBM DB2 for iSeries用の一部のナレッジ・モジュールでは、このデータベース固有の機能が使用されます。これらのナレッジ・モジュールの使用時には、次の制限が適用されます。

これらのトピックの追加情報は、IBM DB2 for iSeriesのドキュメントを参照してください。

システム・コマンドの使用

この項では、IBM DB2 for iSeriesのナレッジ・モジュールでiSeries固有のコマンドを使用する前に満たしておく必要がある要件を説明します。

- CPYFまたはCPYFRMIPFなどのシステム・コマンドを使用するナレッジ・モジュールでは、iSeriesで稼働するエージェントがiSeriesシステムで稼働する必要があります。

ジャーナルでのCDCの使用

この項では、IBM DB2 for iSeriesでジャーナル・ベースのチェンジ・データ・キャプチャを使用する前に満たしておく必要がある要件を説明します。

- このジャーナル化方法では、特定のプログラムをインストールしてiSeriesシステムで実行する必要があります。詳細は、「チェンジ・データ・キャプチャの設定」を参照してください。

14.2.3 接続性要件

この項では、IBM DB2 for iSeriesシステムに接続するための要件をリストします。

JDBCドライバ

Oracle Data Integratorは、デフォルトのIBM DB2 Datadirectドライバとともにインストールされます。このドライバではTCP/IPネットワーク・レイヤーが直接使用され、他のコンポーネントのインストールや構成は不要です。iSeriesへのエージェントのインストール時にIBMによって提供されるドライバ(ネイティブ・ドライバなど)をかわりに使用することもできます。

14.3 トポロジの設定

トポロジの設定には次が含まれます。

1. DB2/400データ・サーバーの作成

2. DB2/400物理スキーマの作成

14.3.1 DB2/400データ・サーバーの作成

IBM DB2/400データ・サーバーは、特定のユーザー・アカウントに接続された1つのiSeriesサーバーに対応します。このユーザーには、データ・サーバーの下に作成されたOracle Data Integrator内の物理スキーマに対応する、このサーバー内の複数のデータベースへのアクセス権が付与されます。

14.3.1.1 データ・サーバーの作成

『Oracle Data Integratorでの統合プロジェクトの開発』のデータ・サーバーの作成に関する項の説明に従って、標準の手順を使用してIBM DB2/400テクノロジ用のデータ・サーバーを作成します。この項では、IBM DB2/400データ・サーバーの定義に関する必須または固有のフィールドのみについて説明します。

1. 「定義」タブ:

- 名前: Oracle Data Integratorに表示されるデータ・サーバーの名前

- ホスト (データ・サーバー): ホストの名前またはIPアドレス

- ユーザー/パスワード: DB2ユーザーおよびそのパスワード

2. 「JDBC」タブ:

- JDBCドライバ: weblogic.jdbc.db2.DB2Driver

- JDBC URL: jdbc:as400://<host>[;libraries=<library>][;<property>=<value>...]
URLのパラメータは次のとおりです。

- <host>: サーバーのネットワーク名またはIPアドレス

- <library>: アクセスするデフォルト・ライブラリまたはコレクション

- <property>=<value>: 接続プロパティ。利用可能なプロパティのリストについては、ドライバのドキュメントを参照してください。

14.3.2 DB2/400物理スキーマの作成

『Oracle Data Integratorの管理』の物理スキーマの作成に関する項の説明に従って、標準の手順を使用してIBM DB2/400物理スキーマを作成します。

この物理スキーマ内の作業スキーマおよびデータ・スキーマは、それぞれ1つのスキーマ(コレクションまたはライブラリ)に対応します。作業スキーマは一時スキーマを指す必要があり、データ・スキーマは統合するデータをホストするスキーマを指す必要があります。

『Oracle Data Integratorの管理』の論理スキーマの作成に関する項の説明に従って、標準の手順を使用してこの物理スキーマ用の論理スキーマを作成し、特定のコンテキストで関連付けます。

14.4 統合プロジェクトの設定

IBM DB2 for iSeriesデータベースを使用してプロジェクトを設定するには、標準の手順に従います。『Oracle Data Integratorでの統合プロジェクトの開発』の統合プロジェクトの作成に関する項を参照してください。

IBM DB2 for iSeriesでの作業を開始するにあたり、使用するプロジェクトに次のナレッジ・モジュールをインポートすることをお薦めします。

- IKM DB2 400 Incremental Update

- IKM DB2 400 Slowly Changing Dimension

- JKM DB2 400 Consistent

- JKM DB2 400 Simple

- RKM DB2 400

- CKM SQL

14.5 IBM DB2/400モデルの作成およびリバース・エンジニアリング

この項には次のトピックが含まれます:

- IBM DB2/400モデルの作成

- IBM DB2/400モデルのリバース・エンジニアリング

14.5.1 IBM DB2/400モデルの作成

『Oracle Data Integratorでの統合プロジェクトの開発』のモデルの作成に関する項の説明に従って、標準の手順を使用してIBM DB2/400モデルを作成します。

14.5.2 IBM DB2/400モデルのリバース・エンジニアリング

IBM DB2 for iSeriesでは、JDBCドライバの機能のみを使用する標準のリバース・エンジニアリング、およびRKMを使用してメタデータ取得する、カスタマイズされたリバース・エンジニアリングの両方がサポートされています。

通常は、標準のJDBCリバース・エンジニアリングを使用して作業を開始することを検討してください。

それ以外のメタデータを取得する場合に、カスタマイズされたリバース・エンジニアリングに切り替えることを検討してください。IBM DB2 for iSeriesのカスタマイズされたリバース・エンジニアリングでは、物理ファイル、データベース表、データベース・ビュー、列、外部キー、主キーおよび代替キーが取得されます。

標準のリバース・エンジニアリング

IBM DB2 for iSeriesで標準のリバースエンジニアリングを実行するには、『Oracle Data Integratorでの統合プロジェクトの開発』のモデルのリバースエンジニアリングに関する項の説明に従って、通常の手順を使用します。

カスタマイズされたリバース・エンジニアリング

RKMを使用してIBM DB2 for iSeriesでカスタマイズされたリバースエンジニアリングを実行するには、『Oracle Data Integratorでの統合プロジェクトの開発』のモデルのリバースエンジニアリングに関する項の説明に従って、通常の手順を使用します。この項では、IBM DB2/400テクノロジ固有のフィールドのみについて説明します。

IBM DB2/400モデルの「リバース」タブでKM: RKM DB2 400.<project name>を選択します。

14.6 チェンジ・データ・キャプチャの設定

Oracle Data Integratorでは、iSeriesでのチェンジ・データ・キャプチャを次の2つの方法で処理します。

- ジャーナル化された表でのトリガー・ベースCDC。この方法は、JKM DB2/400 SimpleまたはJKM DB2/400 Consistentで設定されます。このCDCは、他のシステムのCDCと同じです。詳細は、14.6.1項「トリガー・ベースCDCの設定」を参照してください。

- ネイティブiSeriesトランザクション・ジャーナルの読取りによるログ・ベースCDC。この方法は、JKM DB2/400 Journal Simpleで設定され、LKM DB2/400 Journal to SQLで使用されます。この方法では、一貫性セットCDCはサポートされず、プラットフォーム固有の構成が必要になります。詳細は、14.6.1項「トリガー・ベースCDCの設定」を参照してください。

14.6.1 トリガー・ベースCDCの設定

この方法では、単純ジャーナル化および一貫性セット・ジャーナル化がサポートされます。IBM DB2 for iSeries JKMでは、トリガーを使用してソース表でのデータ変更をキャプチャします。

Oracle Data Integratorには、トリガーを使用してIBM DB2 for iSeries表をジャーナル化するためのナレッジ・モジュールが用意されています。これらのリストを表14-2に示します。

ジャーナル化の設定方法およびキャプチャされた変更の使用方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』の「チェンジ・データ・キャプチャの使用」を参照してください。

表14-2 IBM DB2 for iSeriesジャーナル化ナレッジ・モジュール

KM

説明

JKM DB2 400 Consistent

トリガーを使用してIBM DB2 for iSeries表の一貫したジャーナル化を行うためのジャーナル化インフラストラクチャを作成します。

JKM DB2 400 Simple

トリガーを使用してIBM DB2 for iSeries表の単純なジャーナル化を行うためのジャーナル化インフラストラクチャを作成します。

14.6.2 ログ・ベースCDCの設定

この方法は、JKM DB2/400 Journal Simpleで設定され、LKM DB2/400 Journal to SQLで使用されます。これは、ジャーナル・コンテンツを取得するためのRPGプログラムも使用します。

14.6.2.1 動作の仕組み

iSeriesトランザクション・ジャーナルには、指定された期間のデータ変更の履歴がすべて含まれます。これは、iSeriesシステムによって、ジャーナル化される表について処理されます。ジャーナル化された表は、コレクションからの表、またはジャーナル・レシーバおよびジャーナルが作成されてジャーナル化が開始された表のいずれかです。

トランザクション・ジャーナルの読取りは、Oracle Data Integratorとともに提供されるジャーナル・リトリーバであるCDCRTVJRN RPGプログラムによって実行されます。このプログラムでは、Oracle Data Integrator CDCインフラストラクチャの表(J$表)およびその内容がトランザクション・ジャーナルからオンデマンドでロードされます。

このプログラムは、iSeriesシステム上でスケジュールするか、同じCDCRTVJRNという名前のストアド・プロシージャを介してKMでコールできます。このストアド・プロシージャはJKM DB2/400 Journal Simpleによって自動的に作成され、データの抽出が必要になったときにLKM DB2/400 Journal to SQLによって起動されます。

14.6.2.2 CDCRTVJRNプログラムの詳細

このプログラムは、指定された表のネイティブiSeriesジャーナルに接続し、変更されたデータ情報をOracle Data Integratorジャーナル(J$)内にキャプチャします。

このプログラムは次のように動作します。

1. ジャーナル化された表の属性の取得:

1. 表属性の取得: PK列、J$表名、最終のジャーナル読取り日付

2. 短縮名、レコード・サイズなどの拡張属性(QSYS.QADBXREFシステム表を使用)

3. iSeriesジャーナルの場所(QADBRTVFD() APIを使用)

2. PK列情報の取得:

1. 短縮名、データ型などのPK列属性(QSYS.QADBIFLDシステム表を使用)

2. 実際の物理長などの拡張属性(QUSLFLD() APIを使用)

3. 主キー列のデータの前処理(RPGからSQLへのデータ型変換)

3. J$表へのネイティブ・ジャーナル情報の抽出:

1. ネイティブ・ジャーナルの読取り(QJoRetrieveJournalEntries() APIを使用)

2. 生データのネイティブSQLデータへの変換およびJ$表へのキャプチャ

3. 変更回数の更新

このプログラムによって受け入れられるパラメータのリストを表14-3に示します。

表14-3 CDCRTVJRNプログラムのパラメータ

パラメータ

RPG型

SQL型

説明

SbsTName

A138

Char(138)

サブスクライバ表のフルネーム(書式は<Lib>.<Table>)。

例: ODILIB.SNP_SUBSCRIBERS

JrnTName

A138

Char(138)

ジャーナルから抽出が行われる表のフルネーム。

例: FINANCE.MY_COMPANY_ORDERS

JrnSubscriber

A50

Char(50)

現在のサブスクライバの名前。これは、事前にサブスクライバのリストに追加されている必要があります。

LogMessages

A1

Char(1)

スプール・ファイルへのログインをアクティブ化するフラグ。使用できる値は、Y(ロギングの有効化)およびN(ロギングの無効化)です。

14.6.2.3 iSeriesへのCDCコンポーネントのインストール

ネイティブ・ジャーナルの読取りを有効にするためにiSeriesシステムにインストールする主要コンポーネントは次の2つです。

- CDCRTVJRNプログラム。このプログラムは、iSeriesシステムにインストールされるアーカイブに含まれます。インストールの手順は後述の説明を参照してください。

- CDCインフラストラクチャ。これには標準のCDCオブジェクト(J$表、ビューなど)、およびJKMにより作成され、LKMによってジャーナルの読取りに使用されるCDCRTVJRNストアド・プロシージャが含まれます。このストアド・プロシージャにより、CDCRTVJRNプログラムが実行されます。

注意:
このプログラムは、このiSeriesデータ・サーバーのデフォルト作業ライブラリとしてトポロジで定義されたライブラリ内で設定する必要があります。下の例では、このライブラリをODILIBと呼んでいます。

CDCRTVJRNプログラムのインストール

CDCRTVJRNプログラムをインストールするには、次のようにします。

1. プログラムSAVFファイルの場所を特定します。これはODI_HOME/setup/manual/cdc-iseriesディレクトリにあるほか、Oracle Data Integrator Companion CDにも含まれています。

2. iSeriesシステムに接続します。

3. デフォルトの作業ライブラリが存在しない場合は、これを作成します。たとえば、次のコマンドを使用してODILIBライブラリを作成できます。

CRTLIB LIB(ODILIB)

4. このライブラリ内に、SAVFファイルと同じ名前の空の保存ファイルを作成します(必須)。次に例を示します。

CRTSAVF FILE(ODILIB/SAVPGM0110)

5. iSeriesシステムのライブラリ内に作成したファイルを上書きする形で、ローカルSAVFファイルをアップロードします。アップロード・プロセスがバイナリ・モードで実行されるようにしてください。
アップロードを実行するFTPコマンド・シーケンスの例を次に示します。

FTP 192.168.0.13
LCD /oracle/odi/setup/manual/cdc-iseries/
BI
CD ODILIB
PUT SAVPGM0110
BYE

- RSTOBJコマンドを使用して、保存ファイルからオブジェクトをリストアします。次に例を示します。

RSTOBJ OBJ(*ALL) SAVLIB(CDCSNPRELE) DEV(*SAVF) OBJTYPE(*ALL) SAVF(ODILIB/SAVPGM0110) RSTLIB(ODILIB)

- オブジェクトが正しくリストアされていることを確認します。ターゲット・ライブラリには、CDCRTVJRNというプログラム・オブジェクトが含まれている必要があります。
次のコマンドを使用してこのオブジェクトを表示します。

WRKOBJ OBJ(ODILIB/CDCRTVJRN)

CDCRTVJRNストアド・プロシージャ

このプロシージャは、CDCRTVJRNプログラムをコールするために使用します。これは、ジャーナル化が開始されるとき、JKM DB2/400 Journal Simple KMによって自動的に作成されます。ジャーナル化の起動の詳細は、「チェンジ・データ・キャプチャ」を参照してください。

このストアド・プロシージャの構文は、次を参照してください。

create procedure ODILIB.CDCRTVJRN(
SbsTName char(138), /* Qualified Subscriber Table Name */
JrnTName char(138), /* Qualified Table Name */
Subscriber char(50) , /* Subscriber Name */
LogMessages char(1) /* Create a Log (Y - Yes, N - No) */
)
language rpgle
external name 'ODILIB/CDCRTVJRN'

注意:
このストアド・プロシージャおよびプログラムは、このiSeriesデータ・サーバーのデフォルト作業ライブラリとしてトポロジで定義されたライブラリ内にインストールする必要があります。

14.6.2.4 ネイティブ・ジャーナルでのCDCの使用

プログラムをインストールしてCDCを設定したら、ネイティブ・ジャーナルを使用するために、LKM DB2/400 Journal to SQLを使用してiSeriesシステムからジャーナル化されたデータを抽出します。取得プロセスがトリガーされるのは、このLKMのRETRIEVE_JOURNAL_ENTRIESオプションがtrueに設定されている場合です。

14.6.2.5 ジャーナル読取り時の問題

この項では、このチェンジ・データ・キャプチャ方法の使用時に発生する可能性がある問題をリストします。

CDCRTVJRNプログラムの制限

CDCRTVJRNプログラムには、次の制限があります。

- iSeriesデータ・サーバーで指定されたユーザーによる、ソース表のジャーナル化およびiSeriesジャーナルの読取りが可能であることが必要です。

- ソース表にはOracle Data Integratorで定義された1つのPKが含まれている必要があります。

- Oracle Data Integratorで宣言されているPKは、データファイルの物理レコードの最初の4096オクテットに含まれている必要があります。

- PK内の列数は16以下であることが必要です。

- PKの列番号にPKの列名を追加した合計文字数は、255以下であることが必要です。

- ラージ・オブジェクト・データ型は、PKではサポートされません。PKでサポートされるSQLタイプは、SMALLINT、INTEGER、BIGINT、DECIMAL(パック形式)、NUMERIC(ゾーン形式)、FLOAT、REAL、DOUBLE、CHAR、VARCHAR、CHAR VARYING、DATE、TIME、TIMESTAMPおよびROWIDのみです。

- CDCRTVJRNの複数のインスタンスを同じシステム上で同時に起動しないでください。

- ジャーナル・エントリの使用日(SNP_SUBSCRIBERS.JRN_CURFROMDATE)が順序初期化の日付より前の場合には、iSeriesジャーナルで順序番号を再初期化すると、プログラムに深刻な影響を与える(プログラムが停止する)可能性があります。この問題を回避するには、SNP_SUBSCRIBERS.JRN_CURFROMDATEで、それよりも後の日付を手動で設定する必要があります。

CDCRTVJRNプログラムのトラブルシューティング

ジャーナル読取りプロセスは、次のどちらかの方法でトレース・モードに設定できます:

- LogMsgパラメータをYに設定して、問合せツールからCDCRTVJRNストアド・プロシージャをコールします。

- CREATE_SPOOL_FILE LKMオプションを強制的に1に設定して、マッピングを再起動します。

読取りプロセスのログは、WRKSPLFコマンドを使用して確認できるスプール・ファイルに格納されます。

また、DSPJRNコマンドを使用して、iSeriesジャーナルの未加工の内容を確認できます。

14.7 データ品質の設定

Oracle Data Integratorには、DB2/400で定義された制約と照合してデータの整合性をチェックするための汎用CKM SQLが用意されています。詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』のフロー制御および静的制御に関する項を参照してください。

詳細は、第4章「汎用SQL」を参照してください。

14.8 マッピングの設計

マッピングのソース、ステージング領域またはターゲットとしてIBM DB2 for iSeriesを使用できます。

マッピングまたはチェック用に選択したKMによって、このマッピングまたはチェックの機能およびパフォーマンスが決まります。この項に示す推奨事項は、IBM DB2 for iSeriesデータ・サーバーに関連する様々な状況でのKMの選択に役立ちます。

14.8.1 IBM DB2 for iSeriesとの間でのデータのロード

マッピングのソース、ターゲットまたはステージング領域としてIBM DB2 for iSeriesを使用できます。マッピング・フロー・タブでの、IBM DB2 for iSeriesと別のタイプのデータ・サーバー間でデータをロードするためのLKMの選択は、マッピングのパフォーマンスに関してきわめて重要です。

14.8.1.1 IBM DB2 for iSeriesからのデータのロード

Oracle Data Integratorには、IBM DB2 for iSeriesからターゲットまたはステージング領域のデータベースへデータをロードするための最適化された方法を実装するナレッジ・モジュールが用意されています。これらの最適化されたIBM DB2 for iSeries KMを表14-4にリストします。

これらのKM以外に、汎用SQL KMまたは関係するもう一方のテクノロジ固有のKMを使用して、IBM DB2 for iSeriesからターゲットまたはステージング領域のデータベースへデータをロードすることもできます。

表14-4 IBM DB2 for iSeriesからデータをロードするためのKM

ソースまたはステージング領域のテクノロジ

KM

説明

IBM DB2 for iSeries

LKM DB2 400 to DB2 400

CRTDDMFを使用してターゲット上にDDMファイルを作成し、CPYFを使用してソースからこのDDMファイルへデータを転送して、IBM DB2 for iSeriesのソース・データベースからIBM DB2 for iSeriesのステージング領域データベースへデータをロードします。

IBM DB2 for iSeries

LKM DB2 400 Journal to SQL

IBM DB2 for iSeriesのソースからANSI SQL-92準拠ステージング領域のデータベースへデータをロードします。このLKMでは、ジャーナルに基づいてCDCインフラストラクチャをリフレッシュする際に、JKM DB2 400 Simple (Journal)でジャーナル化された表をソースとする場合があります。

14.8.1.2 IBM DB2 for iSeriesへのデータのロード

Oracle Data Integratorには、ソースまたはステージング領域からIBM DB2 for iSeriesデータベースへデータをロードするための最適化された方法を実装するナレッジ・モジュールが用意されています。これらの最適化されたIBM DB2 for iSeries KMを表14-5にリストします。

これらのKM以外に、汎用SQL KMまたは関係するもう一方のテクノロジ固有のKMも使用できます。

表14-5 IBM DB2 for iSeriesにデータをロードするためのKM

ソースまたはステージング領域のテクノロジ

KM

説明

IBM DB2 for iSeries

LKM DB2 400 to DB2 400

CRTDDMFを使用してターゲット上にDDMファイルを作成し、CPYFを使用してソースからこのDDMファイルへデータを転送して、IBM DB2 for iSeriesのソース・データベースからIBM DB2 for iSeriesのステージング領域データベースへデータをロードします。

14.8.2 IBM DB2 for iSeriesでのデータの統合

Oracle Data Integratorには、IBM DB2 for iSeries用に最適化されたデータ統合戦略を実装するナレッジ・モジュールが用意されています。これらの最適化されたIBM DB2 for iSeries KMを表14-6にリストします。I

これらのKM以外に、汎用SQL KMも使用できます。

マッピング・フロー・タブのIKMの選択によって、統合のパフォーマンスおよび可能性が決まります。

表14-6 IBM DB2 for iSeriesにデータを統合するためのKM

KM

説明

IKM DB2 400 Incremental Update

増分更新モードでIBM DB2 for iSeriesのターゲット表にデータを統合します。

IKM DB2 400 Incremental Update (CPYF)

増分更新モードでIBM DB2 for iSeriesのターゲット表にデータを統合します。このIKMはIKM DB2 400 Incremental Updateと似ていますが、セットベースのSQL操作ではなく、CPYF固有のOS/400コマンドを使用してターゲット表に書き込む点で異なります。

IKM DB2 400 Slowly Changing Dimension

データ・ウェアハウスでタイプ2の緩やかに変化するディメンションとして使用されるIBM DB2 for iSeriesのターゲット表に、データを統合します。

緩やかに変化するディメンションの使用

緩やかに変化するディメンションを使用する場合は、ターゲット・データベースの各アトリビュートに対して「緩やかに変化するディメンション」の値を必ず設定してください。この値は、「サロゲート・キー」、「自然キー」、列の上書きまたは挿入、「現在のレコード・フラグ」、「開始タイムスタンプ」および「終了タイムスタンプ」列を識別するために、IKM DB2 400 Slowly Changing Dimensionで使用されます。

14.9DB2 for iSeries固有の考慮事項

この項では、iSeries環境でOracle Data Integratorを使用する場合に固有の考慮事項を説明します。

14.9.1 iSeriesの代替接続方法

ほとんどの場合は、組込みIBM DB2 Datadirectドライバの使用が適切です。このドライバではTCP/IPネットワーク・レイヤーが直接使用され、他のコンポーネントをクライアント・マシンにインストールする必要はありません。iSeries上のDB2への接続方法は他にもあります。

14.9.1.1 クライアント・アクセスの使用

ODBCを介して、マシンにインストールされているIBMクライアント・アクセス・コンポーネントに接続することも可能です。この方法では良いパフォーマンスが得られず、リバース・エンジニアリングおよび他の一部の機能がサポートされません。そのため、この方法はお薦めしません。

14.9.1.2 IBM JT/400およびネイティブ・ドライバの使用

このドライバはjt400.zipファイルとして表示されるもので、使用するOracle Data Integratorインストールのdriversディレクトリにコピーする必要があります。

DB2 for iSeriesをiSeriesマシンにインストールされているJavaアプリケーションと接続する場合は、JT/400ドライバ(jt400.jar)のかわりにJT/400ネイティブ・ドライバ(jt400native.jar)を使用することがIBM社によって推奨されています。ネイティブ・ドライバは、DB2システムへの最適化されたアクセスを提供しますが、機能するのはiSeriesマシンからアクセスした場合のみです。

1つの接続で両方のドライバをシームレスにサポートするために、Oracle Data Integratorには組込みDriver Wrapper for AS/400が用意されています。このラッパーでは、可能な場合はネイティブ・ドライバを介して接続し、それ以外の場合はJT/400ドライバを使用します。AS/400システムにインストールされたエージェントを実行する場合は、このラッパーを使用することをお薦めします。

このドライバ・ラッパーを使用してデータ・サーバーを構成するには、次のようにします。

1. 次の情報を使用して、ドライバおよびURLを、使用するAS/400サーバーに変更します。

- ドライバ: com.sunopsis.jdbc.driver.wrapper.SnpsDriverWrapper

- URL: jdbc:snps400:<machine_name>[;param1=value1[;param2=value2...]]

2. ランタイム・エージェントがiSeriesにデプロイされているjavaマシンについて、次のjavaプロパティを設定します。

- HOST_NAME: 現在のマシンを識別するホスト名の、カンマ区切りのリスト。

- HOST_IP: 現在のマシンのIPアドレス。

この値によって、データ・サーバーへのアクセスがiSeriesマシンまたはリモート・マシンのどちらから行われているかをラッパーが識別できます。

14.10 トラブルシューティング

この項では、Oracleナレッジ・モジュールの使用時に発生する可能性がある問題のトラブルシューティングに関する情報を提供します。この章の内容は、次のとおりです。

- エラー・メッセージのトラブルシューティング

- 一般的な問題および解決策

14.10.1 エラー・メッセージのトラブルシューティング

通常、Oracle Data Integratorのエラーは次のように表示されます。

java.sql.SQLException: The application server rejected the connection.(Signon was canceled.)
at ...
at ...
...

java.sql.SQLExceptioncodeは、単純に、JDBCドライバを介してデータベースへの問合せが行われ、エラーが戻されたことを示しています。このエラーはデータベースまたはドライバのエラーであることが多く、次のように解明する必要があります。

まず、太字のテキスト部分のみに注目してください。これは、DB2 for iSeriesのドキュメントで検索する必要があります。ここにシステム固有のエラー・コードが含まれている場合は、このコードを使用すると、エラーをすばやく識別できます。

このようなエラーが実行ログで検出された場合は、データベースに送信されたSQLコードを分析して、エラーの原因を特定する必要があります。このコードは、エラーのあるタスクの「説明」タブに表示されます。

14.10.2 一般的な問題および解決策

この項では、一般的な問題および解決策について説明します。

14.10.2.1 接続エラー

- UnknownDriverException
JDBCドライバが不正です。ドライバの名前を確認してください。

- The application requester cannot establish the connection.(<name or IP address>) Cannot open a socket on host: <name or IP address>, port: 8471 (Exception: java.net.UnknownHostException:<name or IP address>)
Oracle Data Integratorがデータベースに接続できません。原因は、マシン名またはIPアドレスが無効である、DB2/400サービスが起動していない、またはAS/400上のTCP/IPインタフェースが起動していない、のいずれかです。同じマシン名またはIPアドレスを使用してAS/400マシンのpingを試行し、システム管理者に依頼して適切なサービスが起動したことを確認してください。

- Datasource not found or driver name not specified
JDBC URLで指定されたODBCデータソースが不正です。

- The application server rejected the connection.(Signon was canceled.) Database login failed, please verify userid and password. Communication Link Failure. Comm RC=8001 - CWBSY0001 - ...
使用されているユーザー・プロファイルが無効です。このエラーは、無効なユーザー名または不正なパスワードを入力した場合に発生します。

- Communication Link Failure
ODBC接続でエラーが発生しました。詳細は、クライアント・アクセスのドキュメントを参照してください。

- SQL5001 - Column qualifier or table &2 undefined. SQL5016 - Object name &1 not valid for naming convention
使用するJDBC接続またはODBCデータソースが、不正な命名規則を使用するように構成されています。ODBCアドミニストレータを使用して正しい(*SQLまたは*SYS)命名規則が使用されるようにデータソースを変更するか、JDBC URLで適切なオプションを使用して命名規則を強制します(例: jdbc:as400://195.10.10.13;naming=system)。物理スキーマのローカル・オブジェクト・マスクでシステムの命名規則を使用する場合は、%SCHEMA.%OBJECTのかわりに%SCHEMA/%OBJECTを入力する必要があることに注意してください。

使用するアプリケーションが*SYS専用に設計されている場合を除いて、常に*SQLを使用する必要があります。Oracle Data Integratorでは、デフォルトで*SQL命名規則が使用されます。

- SQL0204 &1 in &2 type *&3 not found
アクセスしようとしている表が存在しません。これは、コンテキスト選択または一連の操作でのエラーに関連する可能性があります(たとえば、この表が別のマッピングで作成する必要がある一時表である場合など)。

- Hexadecimal characters appear in the target tables. Accentuated characters are incorrectly transferred.
iSeriesコンピュータによって、ファイル、表およびイベント・フィールド(列)に言語識別子またはCCSIDが添付されます。CCSID 65535は、ファイルまたはフィールドを言語非依存(つまり、16進データ)として識別する汎用コードです。そのため、ドライバによる変換は実行されません。ファイルのCCSIDを更新しない場合は、JDBC URLでフラグccsid=<ccsid code>およびconvert _ccsid_65535=yes|noを使用して変換を強制できます。詳細は、ドライバのドキュメントを参照してください。

- SQL0901 SQL system error
このエラーは、DB2/400システムの内部エラーです。

- SQL0206 Column &1 not in specified tables
マッピング、結合またはフィルタでの入力エラーです。列名でない文字列が列名として解釈されたか、列名にスペルミスがあります。

構造が最近変更されたデータストアに関連付けられているエラー表にアクセスした場合にも、このエラーが表示されることがあります。エラー表に変更を反映するか、エラー表を削除して次回の実行時にOracle Data Integratorで再作成されるようにする必要があります。

15 IBM DB2 UDB

この章では、Oracle Data IntegratorでのIBM DB2 UDBの使用方法について説明します。

この章には次の項が含まれます:

- 15.1項「概要」

- 15.2項「概念」

- 15.3項「ナレッジ・モジュール」

- 15.4項「固有の要件」

15.1 概要

Oracle Data Integrator (ODI)では、IBM DB2 UDBデータベースのデータがシームレスに統合されます。Oracle Data Integratorの機能(ジャーナル化、データ整合性チェックおよびマッピングなど)は、IBM DB2 UDBを使用した場合に最良の動作が得られるように設計されています。

15.2 概念

IBM DB2 UDBの概念は、Oracle Data Integratorの概念に次のようにマップされます。1つのIBM DB2 UDBデータベースは、Oracle Data Integratorの1つのデータ・サーバーに対応します。このサーバー内で、スキーマがOracle Data Integrator物理スキーマにマップされます。

Oracle Data Integratorでは、Java Database Connectivity (JDBC)を使用してIBM DB2 UDBデータベースに接続します。

15.3 ナレッジ・モジュール

Oracle Data Integratorには、IBM DB2 UDBデータを処理するためのナレッジ・モジュール(KM)が用意されています。これらのリストを表15-1に示します。これらのKMではIBM DB2 UDB固有の機能が使用されます。IBM DB2 UDBデータベースで汎用SQL KMを使用することもできます。詳細は、第4章「汎用SQL」を参照してください。

表15-1 DB2 UDB KM

ナレッジ・モジュール

説明

IKM DB2 UDB Incremental Update

増分更新モードでIBM DB2 UDBのターゲット表にデータを統合します。このIKMにより、データ・フローをステージングするための一時ステージング表が作成されます。次に、挿入する必要があるレコードおよび更新する必要があるレコードを判別するために、その内容がターゲット表と比較されます。また、CKMを起動してデータ整合性チェックを実行することもできます。

挿入および更新は、最大のパフォーマンスを得るためにバルク・セットベースの処理で実行されます。そのため、このIKMは大量のデータ用に最適化されています。

IBM DB2 UDBのターゲット表をロードして、欠落しているレコードを挿入し、既存のレコードを更新する場合は、このIKMの使用を検討してください。

このIKMを使用するには、ステージング領域がターゲットと同じデータ・サーバー上にあることが必要です。

IKM DB2 UDB Slowly Changing Dimension

データ・ウェアハウスでタイプ2の緩やかに変化するディメンションとして使用されるIBM DB2 UDBのターゲット表に、データを統合します。このIKMは、ターゲット・データストアで設定される緩やかに変化するディメンション・メタデータに依存して、新しいバージョンとして挿入する必要があるレコード、または既存のバージョンとして更新する必要があるレコードを判別します。

挿入および更新はバルク・セットベースの処理で実行されるため、このIKMは大量のデータ用に最適化されています。

IBM DB2 UDBのターゲット表をタイプ2の緩やかに変化するディメンションとしてロードする場合は、このIKMの使用を検討してください。

このIKMを使用するには、ステージング領域がターゲットと同じデータ・サーバー上にあり、適切な緩やかに変化するディメンション・メタデータがターゲット・データストア上で設定されていることが必要です。

JKM DB2 UDB Consistent

トリガーを使用してIBM DB2 UDB表の一貫したジャーナル化を行うためのジャーナル化インフラストラクチャを作成します。

IBM DB2 UDBでの一貫性のあるチェンジ・データ・キャプチャを有効にします。

JKM DB2 UDB Simple

トリガーを使用してIBM DB2 UDB表の単純なジャーナル化を行うためのジャーナル化インフラストラクチャを作成します。

IBM DB2 UDBでの単純なチェンジ・データ・キャプチャを有効にします。

LKM DB2 UDB to DB2 UDB (EXPORT_IMPORT)

固有のEXPORT / IMPORTコマンドを使用して、IBM DB2 UDBソース・データベースからIBM DB2 UDBステージング領域データベースへデータをロードします。

このモジュールでは、EXPORT CLPコマンドを使用して一時ファイルにデータを抽出します。その後、IMPORT CLPコマンドを使用してターゲットのDB2 UDBステージング表にデータをロードします。この方法は通常、大量のデータを処理する場合に標準のLKM SQL to SQLより効率的です。

ソース表がDB2 UDBデータベースにあり、ステージング領域が異なるDB2 UDBデータベースにある場合は、このLKMの使用を検討してください。

LKM File to DB2 UDB (LOAD)

固有のCLP LOADコマンドを使用して、ファイルからDB2 UDBステージング領域データベースへデータをロードします。

このLKMでは、ファイルの種類(固定またはデリミタ付き)に応じて、適切なLOADスクリプトが一時ディレクトリに生成されます。その後、CLPによってこのスクリプトが実行され、実行終了時に自動的に削除されます。この方法では固有のIBM DB2ローダーが使用されるため、大量のデータを処理する場合は、標準のLKM File to SQLより効率的です。

ソースが大きいフラット・ファイルで、ステージング領域がIBM DB2 UDBデータベースの場合は、このLKMの使用を検討してください。

LKM SQL to DB2 UDB

任意のANSI SQL-92標準準拠ソース・データベースからIBM DB2 UDBステージング領域へデータをロードします。このLKMは、第4章「汎用SQL」に記載されている標準のLKM SQL to SQLと似ていますが、IBM DB2 UDBの追加パラメータを指定できる点で異なります。

LKM SQL to DB2 UDB (LOAD)

CLP LOADコマンドを使用して、任意のANSI SQL-92標準準拠ソース・データベースからIBM DB2 UDBステージング領域へデータをロードします。

このLKMでは、一時ファイルにソース・データがアンロードされ、CLP LOADコマンドを使用してIBM DB2固有のローダーがコールされて、ステージング表が移入されます。この方法では固有のIBM DB2ローダーが使用されるため、通常、大量のデータを処理する場合は、LKM SQL to SQLまたはLKM SQL to DB2 UDBより効率的です。

汎用データベースに大量のソース・データがあり、ステージング領域がIBM DB2 UDBデータベースの場合は、このLKMの使用を検討してください。

SKM IBM UDB

IBM DB2 UDBデータベース用のデータ・アクセスWebサービスを生成します。詳細は、第4章「汎用SQL」のSKM SQLの説明を参照してください。

15.4 固有の要件

IBM DB2 UDB用の一部のナレッジ・モジュールでは、オペレーティング・システムのコールを使用してIBM CLPコマンド・プロセッサを起動し、効率的なロードを実行します。このようなナレッジ・モジュールの使用時には、次の制限が適用されます。

- Oracle Data Integratorのエージェントを実行するマシン上に、IBM DB2 UDB Command Line Processor (CLP)およびDB2 UDB Connectソフトウェアがインストールされている必要があります。

- トポロジで定義されるサーバー名は、これらのサーバーに使用されるIBM DB2 UDBの接続文字列と一致する必要があります。

- 一部のDB2 UDB JDBCドライバでは、ODIエージェントを実行するマシンにDB2 UDB Connectソフトウェアがインストールされている必要があります。

詳細は、IBM DB2のドキュメントを参照してください。

第II部

Business Intelligence

この部では、Oracle Data IntegratorでのBusiness Intelligenceの使用方法について説明します。

第II部の内容は次のとおりです。

- 第16章「Oracle Business Intelligence Enterprise Edition」

- 第17章「Oracle Business Intelligence Enterprise Editionデータ系統」

16 Oracle Business Intelligence Enterprise Edition

この章では、Oracle Data IntegratorでのOracle Business Intelligence Enterprise Editionの使用方法について説明します。

この章には次の項が含まれます:

- 16.1項「概要」

- 16.2項「インストールおよび構成」

- 16.3項「トポロジの設定」

- 16.4項「統合プロジェクトの設定」

- 16.5項「Oracle BIモデルの作成およびリバース・エンジニアリング」

- 16.6「データ品質の設定」

- 16.7項「マッピングの設計」

16.1 概要

Oracle Data Integrator (ODI)では、Oracle Business Intelligence Enterprise Edition (Oracle BI)のデータがシームレスに統合されます。

Oracle Data Integratorには、マッピングを使用し、Oracle BI物理レイヤーを介してADFビュー・オブジェクト(ADF-VO)のデータをリバース・エンジニアリングおよび抽出するための方法が用意されています。

16.1.1 概念

Oracle Business Intelligence Enterprise Editionの概念は、Oracle Data Integratorの概念に次のようにマップされます。1つのOracle BIサーバーは、Oracle Data Integratorの1つのデータ・サーバーに対応します。このサーバー内で、カタログ/所有者の1つのペアは、Oracle Data Integratorの1つの物理スキーマにマップされます。

Oracle Data Integratorは、バイパス接続プールを介してこのサーバーに接続し、ADFビュー・オブジェクトをサポートする物理ソースにアクセスします。

Oracle Data Integratorでは、Java Database Connectivity (JDBC)を使用してOracle BIサーバーに接続します。

16.1.2 ナレッジ・モジュール

Oracle Data Integratorには、表16-1に示されている、Oracle BIデータを処理するためのナレッジ・モジュール(KM)が用意されています。これらのKMでは、Oracle BI固有の機能が使用されます。

表16-1 Oracle BI KM

ナレッジ・モジュール

説明

RKM Oracle BI (Jython)

Oracle BIの表構造(列および主キー)を取得します。

LKM Oracle BI to Oracle (DBLink)

dblinkを使用して、Oracle BIソースからOracleデータベース領域へデータをロードします。

LKM Oracle BI to SQL

Oracle BIソースから任意のANSI SQL-92準拠データベースへデータをロードします。

IKM Oracle BI to SQL Append

Oracle BIソースからANSI-SQL92ターゲット・データベースへデータを統合します。

16.2 インストールおよび構成

Oracle BIナレッジ・モジュールの使用を開始する前に、この項の情報を必ず読んでください。

- システム要件および動作要件

- テクノロジ固有の要件

- 接続性要件

16.2.1 システム要件および動作要件

インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。

サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。

http://www.oracle.com/technology/products/oracle-data-integrator/index.html

16.2.2 テクノロジ固有の要件

Oracle Data IntegratorでOracle BIを使用するためのテクノロジ固有の要件はありません。

16.2.3 接続性要件

この項では、Oracle BIサーバーに接続するための要件をリストします。

JDBCドライバ

Oracle Data Integratorでは、Oracle BIネイティブ・ドライバを使用して、Oracle BIサーバーに接続します。このドライバをOracle Data Integratorのdriversディレクトリにインストールする必要があります。

バイパス接続プール

Oracle BIでは、ADFレイヤーをバイパスして基礎となるデータベースから直接データをフェッチするために、SQLバイパス・データベース接続を設定する必要があります。この接続プールの名前は、Oracle Data IntegratorでOracle BIデータ・サーバーを作成するために必要です。

16.3 トポロジの設定

トポロジの設定には次が含まれます。

1. Oracle BIデータ・サーバーの作成

2. Oracle BI物理スキーマの作成

16.3.1 Oracle BIデータ・サーバーの作成

各データ・サーバーは1つのOracle BIサーバーに対応します。Oracle Data Integratorは、バイパス接続プールを介してこのサーバーに接続し、ADFビュー・オブジェクトをサポートする物理ソースにアクセスします。これらの物理オブジェクトは、このサーバーで公開されるビュー・オブジェクトの下に配置されます。このサーバーは、複数のカタログとスキーマにアクセス可能なユーザーに接続されます。カタログとスキーマのペアは、データ・サーバーの下に作成される物理スキーマに対応します。

16.3.1.1 データ・サーバーの作成

『Oracle Data Integratorでの統合プロジェクトの開発』のデータ・サーバーの作成に関する項の説明に従って、標準の手順を使用してOracle BIテクノロジ用のデータ・サーバーを作成します。この項では、Oracle BIデータ・サーバーの定義に関する必須または固有のフィールドのみについて説明します。

1. 「定義」タブ:

- 名前: Oracle Data Integratorに表示されるデータ・サーバーの名前

- サーバー: このフィールドは空のままにします。

- ユーザー/パスワード: Oracle BIユーザーおよびそのパスワード

2. 「JDBC」タブ:

- JDBCドライバ: oracle.bi.jdbc.AnaJdbcDriver

- JDBC URL: jddbc:oraclebi://<host>:<port>
<host>は、Oracle BIサーバーがインストールされるサーバーです。デフォルトの<port>番号は9703です。

3. 「プロパティ」タブで、次のキーと値のペアを使用してJDBCプロパティを追加します。

- キー: NQ_SESSION.SELECTPHYSICAL

- 値: Yes

注意:
このオプションは、物理データへのアクセスに必要です。このオプションを使用した場合、Oracle BI接続は読取り専用になります。

4. 「フレックスフィールド」タブのCONNECTION_POOLフレックスフィールドで、バイパス接続プールの名前を設定します。

- 名前: CONNECTION_POOL

- 値: <connection pool name>

注意:
このバイパス接続プールは、Oracle BIサーバー自体でも定義する必要があります。

16.3.2 Oracle BI物理スキーマの作成

『Oracle Data Integratorの管理』の物理スキーマの作成に関する項の説明に従って、標準の手順を使用してOracle BI物理スキーマを作成します。

物理スキーマ内で、データ・スキーマおよび作業スキーマは、それぞれOracle BIのカタログとスキーマの1つのペアに対応します。

『Oracle Data Integratorの管理』の論理スキーマの作成に関する項の説明に従って、標準の手順を使用してこの物理スキーマ用の論理スキーマを作成し、特定のコンテキストで関連付けます。

16.4 統合プロジェクトの設定

Oracle BIサーバーを使用してプロジェクトを設定するには、標準の手順に従います。『Oracle Data Integratorでの統合プロジェクトの開発』の統合プロジェクトの作成に関する項を参照してください。

Oracle BIでの作業を開始するにあたり、使用するプロジェクトに次のナレッジ・モジュールをインポートすることをお薦めします。

- RKM Oracle BI (Jython)、LKM Oracle BI to Oracle (DBLink)、LKM Oracle BI to SQL、IKM Oracle BI to SQL Append

使用するプロジェクトに、関係する他のテクノロジに必要なナレッジ・モジュール(IKM、CKM)もインポートします。

16.5 Oracle BIモデルの作成およびリバース・エンジニアリング

この項には次のトピックが含まれます:

- Oracle BIモデルの作成

- Oracle BIモデルのリバース・エンジニアリング

16.5.1 Oracle BIモデルの作成

『Oracle Data Integratorでの統合プロジェクトの開発』のモデルの作成に関する項の説明に従って、標準の手順を使用してOracle BIモデルを作成します。

16.5.2 Oracle BIモデルのリバース・エンジニアリング

Oracle BIでは、カスタマイズされたリバース・エンジニアリングがサポートされています。

RKMを使用してOracle BIでカスタマイズされたリバースエンジニアリングを実行するには、『Oracle Data Integratorでの統合プロジェクトの開発』のモデルのリバースエンジニアリングに関する項の説明に従って、通常の手順を使用します。この項では、Oracle BIテクノロジ固有のフィールドのみについて説明します。

1. Oracle BIモデルの「リバース・エンジニアリング」タブでKM: RKM Oracle BI (Jython).<project name>を選択します。

このKMは、リバース・エンジニアリング・プロセスをトレースするためのUSE_LOGロギング・オプションを実装します。

16.6 データ品質の設定

Oracle BIサーバーでは、データ整合性チェックはサポートされていません。別のテクノロジを使用して、Oracle BIからステージング領域に抽出されたデータをチェックできます。

16.7 マッピングの設計

Oracle BIをマッピングのソースとして使用できます。

マッピング用に選択したKMによって、このマッピングの機能およびパフォーマンスが決まります。この項に示す推奨事項は、Oracle BIサーバーに関連する様々な状況でのKMの選択に役立ちます。

16.7.1 Oracle BIとの間でのデータのロード

「ロード・ナレッジ・モジュール」タブでの、Oracle BIと別のタイプのデータ・サーバー間でデータをロードするためのLKMの選択は、マッピングのパフォーマンスに関してきわめて重要です。

16.7.1.1 Oracle BIからのデータのロード

表16-2にリストされているナレッジ・モジュールを使用して、Oracle BIサーバーからターゲットまたはステージング領域のデータベースへデータをロードします。

表16-2 Oracle BIからデータをロードするためのKM

ステージング領域/ターゲット・テクノロジ

KM

説明

Oracle

LKM Oracle BI to Oracle (Dblink)

DBLinkを使用して、Oracle BIソースからOracleデータベース・ステージング領域へデータをロードします。

このナレッジ・モジュールを使用するには、ソースFusion Transaction DB(基礎となるデータ表を格納するデータベース)からOracleステージング領域へのDBLinkを、手動で作成する必要があります。このDBLinkの名前は、Oracleステージング領域のデータ・サーバー接続で指定したものと同じにする必要があります。

SQL

LKM Oracle BI to SQL

エージェントを介して、Oracle BIソースから任意のANSI SQL-92準拠ステージング領域データベースへデータをロードします。

SQL

IKM Oracle BI to SQL Append

エージェントを介して、Oracle BIソースから任意のANSI SQL-92準拠ステージング領域データベースへ、データをロードして統合します。

このKMを使用するには、ソースOracle BIサーバーのマッピングのステージング領域を設定する必要があります。

この構成では一時表は作成されず、データはソース表からターゲット表へ直接ロードされて統合されます。

16.7.1.2 Oracle BIへのデータのロード

Oracle BIをステージング領域として使用することはできません。Oracle BIをターゲット指定するLKMはありません。

16.7.2 Oracle BIでのデータの統合

Oracle BIをターゲットまたはステージング領域として使用することはできません。ナレッジ・モジュールを使用してOracle BIにデータを統合することはできません。

17 Oracle Business Intelligence Enterprise Editionデータ系統

この章では、Oracle Business Intelligence Enterprise Edition (OBIEE)とOracle Data Integrator (ODI)のメタデータを統合し、レポートからソースのデータ系統を構築する方法について説明します。

この章には次の項が含まれます:

- 17.1項「概要」

- 17.2項「OBIEEサーバーへの系統のインストール」

- 17.3項「OBIEEからのメタデータのエクスポートとOBIEE系統のリフレッシュ」

- 17.4項「既存のエクスポートからのOBIEE系統のリフレッシュ」

- 17.5項「系統タスクの自動化」

- 17.6項「OBIEEダッシュボードでの系統の使用」

17.1 概要

OBIEEのユーザーは、レポートに表示されるデータのソースを把握している必要があります。ODIを使用してソース・システムからデータ・ウェアハウスにこのデータがロードされると、Oracle Data Integrator Lineage for Oracle Business Intelligence機能を使用して、Oracle Data Integrator (ODI)メタデータをOracle Business Intelligence Enterprise Edition (OBIEE)と統合し、OBIEEの、レポートからソースのデータ系統ダッシュボードにこのメタデータを公開できます。

17.1.1 コンポーネント

OBIEE系統は、次のコンポーネントから構成されています。

- 系統表: これらの表は、OBIEEおよびODIメタデータの両方を統合します。これらはODI作業リポジトリに格納されます。

- OBIEEの系統アーティファクト: このパッケージ済のOBIEEアーティファクトは、系統情報にアクセスするためにOBIEEにデプロイされます。次のものがあります。

- 系統RPDには、系統表にアクセスするための物理、論理およびプレゼンテーション・レイヤーが含まれます。

- 系統Webカタログ・リクエストは、既存のダッシュボードで、レポートからソースのダッシュボードを作成するために使用されます。

- イメージは、これらのダッシュボードで使用されます。

- 次の系統タスクを自動化するための、コマンド行ツールおよびウィザード。

- OBIEEインスタンスでのOBIEEの系統アーティファクトのデプロイメント

- OBIEEインスタンスからのOBIEEメタデータの抽出

- ODIリポジトリでのOBIEEとODIメタデータの統合

17.1.2 系統のライフサイクル

この項では、OBIEE系統を使用する様々なフェーズと、これらのフェーズに関係するユーザーについて説明します。

17.1.2.1 系統の設定

OBIEEまたはODI管理者が系統プロセスを設定します。このプロセスの設定は1回行う必要があり、次のタスクで構成されます。

1. OBIEEの系統アーティファクトのデプロイ

2. 抽出/統合(リフレッシュ)プロセスの構成と自動化

17.1.2.2 系統のリフレッシュ

ODIまたはOBIEEのいずれかのメタデータが変更されると、系統表の内容をアクティブなOBIEEおよびODIシステムのメタデータと同期化するために、OBIEEまたはODIのプロジェクト・マネージャによって系統がリフレッシュされます。このリフレッシュ・プロセスには、次のことが含まれます。

1. OBIEEインスタンスからOBIEEメタデータを抽出します。

2. ODI作業リポジトリに格納されている系統表でOBIEEおよびODIメタデータを統合します。

このフェーズでは、ODIデータ・モデルとOBIEE物理データベースとの対応を指定する必要があります。このマッピングを行うことによって、Oracle Data Integrator内の既存のモデル定義がOBIEE内の既存のデータベースに対応していることを示します。これらの2つには、同じ表が含まれている必要があります。このマッピング情報を指定することによって、系統でOBIEEおよびODIメタデータを統合して、エンドツーエンドの系統を構築できるようにします。

17.1.2.3 系統の使用

系統は既存のダッシュボードを拡張するために使用されます。これらのダッシュボードには、データ系統を参照し、ODIセッションの実行統計を表示するための特定のリンクを作成できます。

パッケージ済のOBIEEの系統アーティファクトを使用して、独自のダッシュボードをカスタマイズすることもできます。

図17-1に、初期設定後の系統のライフサイクルを示します。

図17-1 系統のライフサイクル

BIEEメタデータが抽出され(1)、系統表でODIメタデータと統合されます(2)。系統表には、BIEEサーバーにデプロイされた系統アーティファクト経由で、エンド・ユーザーのダッシュボードからアクセスします(3)。

17.2 OBIEEサーバーへの系統のインストール

この項では、OBIEE系統のインストールに関する情報と手順について説明します。

- インストールの概要

- 要件

- インストールの手順

- インストール後の作業

17.2.1 インストールの概要

OBIEEサーバーに系統をインストールすると、OBIEEリポジトリとWebカタログに必要なOBIEEアーティファクトがデプロイされます。OBIEE系統アーティファクトには、系統RPD、系統Webカタログ・リクエストおよびダッシュボード・イメージがあります。これらのアーティファクトは、レポートとダッシュボードから系統の内容にアクセスするために使用されます。

インストールはOBIEE系統ウィザードを使用して実行されます。このウィザードを使用して、Oracle Business Intelligence Enterprise edition (OBIEE)のOracle Data Integrator (ODI)系統をインストール、構成およびリフレッシュします。

インストールと構成が完了した後、使用するOBIEEのバージョンによっては、インストール後の作業を実行する必要があります。

完全なインストール・フローは次のとおりです。

OBIEE 10gを使用する場合のインストール・フロー

OBIEE 10gを使用している場合、OBIEE系統ウィザードでは系統RPDのみをインストールします。系統Webカタログ・リクエストとダッシュボード・イメージをインストールするには、追加の作業を実行する必要があります。次のインストール・フローは、Webカタログ・リクエストとイメージのデプロイメントを含む、完全なインストール手順を示します。

1. 要件を確認します。

2. OBIEE系統ウィザードをインストールして起動します。
OBIEE系統ウィザードのかわりに系統のインストール・スクリプトを使用することもできます。詳細は、17.5.2項「系統のデプロイメントの自動化」を参照してください。

3. OBIEE系統ウィザードを使用して、OBIEEサーバーに系統をインストールし、OBIEE系統アーティファクトをデプロイします。詳細は、17.2.3.2項「ウィザードを使用したOBIEE系統アーティファクトのデプロイ」を参照してください。

4. OBIEE 10g WebカタログにWebカタログ・リクエストをデプロイします。17.2.4項「インストール後の作業」を参照してください。

5. イメージをデプロイします。17.2.4項「インストール後の作業」を参照してください。

6. ODI作業リポジトリへのBI物理レイヤー接続を更新します。17.2.4項「インストール後の作業」を参照してください。

OBIEE 11gを使用する場合のインストール・フロー

OBIEE 11gを使用している場合、OBIEE系統ウィザードでは系統RPDとWebカタログ・リクエストのみをインストールします。ダッシュボード・イメージをインストールするには、追加の作業を実行する必要があります。次のインストール・フローは、イメージのデプロイメントを含む、完全なインストール手順を示します。

1. 要件を確認します。

2. OBIEE系統ウィザードをインストールして起動します。
OBIEE系統ウィザードのかわりに系統のインストール・スクリプトを使用することもできます。詳細は、17.5.2項「系統のデプロイメントの自動化」を参照してください。

3. OBIEE系統ウィザードを使用して、OBIEEサーバーに系統をインストールし、OBIEE系統アーティファクトをデプロイします。詳細は、17.2.3.2項「ウィザードを使用したOBIEE系統アーティファクトのデプロイ」を参照してください。

4. イメージをデプロイします。17.2.4項「インストール後の作業」を参照してください。

5. ODI作業リポジトリへのBI物理レイヤー接続を更新します。17.2.4項「インストール後の作業」を参照してください。

17.2.2 要件

OBIEE系統をインストールする前に、次の要件を確認する必要があります。

- OBIEE系統ウィザードには、Java Runtime Environment 1.6 (JRE)が必要です。ウィザードを開始する前に、JAVA_HOMEが有効なJREを指し示していることを確認してください。

- 作業リポジトリはOracleデータベースに格納されている必要があります。

- アーティファクトをインストールする前に、BIサーバーとBIプレゼンテーション・サービス・コンポーネントを停止します。

- OBIEE RPDとWebcatのバックアップ・コピーを作成します。

- サーバーによって使用されるRPDファイルがBI管理ツールで開かれていないことを確認します。

- BI管理ツールがインストールされているマシンにOBIEE系統ウィザードまたはコマンド行ツールをインストールして実行します。

- 作業リポジトリ・スキーマを接続するために使用されるデータベース・ユーザーには、作業リポジトリをホストするスキーマにビューを作成するのに十分な権限が必要です。

17.2.3 インストール手順

この項ではインストール手順について説明しており、次のトピックがあります。

- OBIEE系統ウィザードのインストールと起動

- ウィザードを使用したOBIEE系統アーティファクトのデプロイ

注意:
インストール手順を実行したら、17.2.4項「インストール後の作業」で説明されている必要なインストール後の作業を実行してください。

17.2.3.1 OBIEE系統ウィザードのインストールと起動

OBIEE系統ウィザードは、<ODI_Home>/odi/misc/biee-lineageディレクトリ内のodiobilineage.zipファイルに含まれています。

OBIEE系統ウィザードを起動するには、次の手順を実行します。

1. zipファイルのコンテンツを、ディレクトリに解凍します。たとえば、このファイルのコンテンツをC:\biee_lineage\フォルダに解凍します。

2. /binサブフォルダから次のコマンドのいずれかを実行して、ウィザードを起動します。

- UNIXオペレーティング・システムでは、次のようにします。
./refreshlineage.sh

- Windowsオペレーティング・システムの場合:
refreshlineage.bat

installlineage.batスクリプトを使用してウィザードを起動することもできます。これらのスクリプトのいずれかをパラメータを指定せずに起動すると、OBIEE系統ウィザードが開きます。

注意:
OBIEE系統ウィザードのかわりに系統のインストール・スクリプトを使用して、コマンド行から系統アーティファクトをインストールすることもできます。インストールとエクスポートのオプションは、Windowsでのみサポートされています。系統のリフレッシュ・オプションは、WindowsとUnixの両方でサポートされています。詳細は、17.5.2項「系統のデプロイメントの自動化」を参照してください。

17.2.3.2 ウィザードを使用したOBIEE系統アーティファクトのデプロイ

この項では、OBIEEサーバーにOBIEE系統をインストールする方法およびOBIEE系統ウィザードを使用してOBIEEリポジトリとWebカタログに必要なOBIEE系統アーティファクトをデプロイする方法について説明します。

OBIEEサーバーに系統をインストールして必要なアーティファクトをデプロイするには、次のようにします。

1. 17.2.3.1項「OBIEE系統ウィザードのインストールと起動」で説明されているとおりにウィザードを起動します。
ウィザードには、一連の画面が表17-1に示されている順序で表示されます。

2. 表17-1の手順に従います。

インストール画面に関して詳細な情報が必要な場合は、「ヘルプ」をクリックしてオンライン・ヘルプを参照してください。

表17-1 OBIEE系統アーティファクトのデプロイ手順

番号

画面

画面が表示されるタイミング

説明および必要なアクション

1

「ようこそ」画面

毎回

「次へ」をクリックして続行します。

2

「アクションの選択」画面

毎回

「系統をOBIEEサーバーにインストール」を選択します。

「次へ」をクリックして続行します。

3

「OBIEEリポジトリ接続情報」画面

「アクションの選択」画面で「系統をOBIEEサーバーにインストール」または「メタデータをOBIEEからエクスポートして系統をリフレッシュする」が選択されている場合。

必要な系統アーティファクトをデプロイするために、次の接続情報を既存のOBIEEリポジトリに指定します。

- Oracleホーム: OBIEEインストール用のOracleホーム・ディレクトリを指定します。「参照」をクリックして、システムの既存のディレクトリを選択できます。例: C:/obiee11g/Oracle_BI1

- RPDファイルの場所: BIEEリポジトリ(RPD)ファイルの場所を入力します。

- ユーザー: OBIEEリポジトリ管理者のユーザー名を入力します。このフィールドはOBIEE 10gでのみ必須であり、OBIEE 11gでは無効です。

- パスワード: OBIEEリポジトリ管理者のパスワードを入力します。

「次へ」をクリックして続行します。

4

「OBIEE Webカタログ接続情報」画面

「アクションの選択」画面で「系統をOBIEEサーバーにインストール」またはOBIEEのメタデータをエクスポートして系統をリフレッシュするが選択されている場合。

OBIEE 10gを使用している場合、この画面は使用できません。手動で系統アーティファクトをインストールする必要があります。詳細は、17.2.4項「インストール後の作業」を参照してください。

必要な系統アーティファクトをインストールするために、次の接続情報をOBIEE Webカタログに指定します。

- OBIEEバージョン: OBIEEのバージョンが表示されます。このバージョンは、前の画面で選択したRPDから検出されます。

- Webカタログの場所: OBIEE Webカタログの場所を入力します。

- OBIEEインスタンス・ホーム: OBIEEインスタンスのホーム・ディレクトリを入力します。例: C:\OBIEE\Middleware\instances\instance1

- Webカタログ・フォルダ名: 系統アーティファクトがデプロイされるWebカタログ・フォルダの名前を入力します。例: /shared

「次へ」をクリックして続行し、系統アーティファクトをデプロイします。

5

「ウォレット情報」画面

毎回

「セキュアなウォレットにパスワードを格納する」チェック・ボックスを選択します。

ウォレット・パスワードを入力するか、新しいウォレット・パスワードを作成して、「OK」をクリックします。

「次へ」をクリックして続行します。

注意: パスワードをセキュアなウォレットに格納しない場合は、「セキュアなウォレットにパスワードを格納する」チェック・ボックスが選択されていないことを確認して、「次」をクリックします。

6

「アクション完了」画面

毎回

「終了」をクリックすると、ウィザードが完了します。

OBIEEサーバーに系統をインストールしたら、OBIEE系統アーティファクトをデプロイする必要があります。詳細は、17.2.4項「インストール後の作業」を参照してください。

17.2.4 インストール後の作業

この項では、インストール後の作業について説明します。これらの作業は、使用するOBIEEサーバーのバージョンによって異なります。

OBIEE 10gでは、次のインストール後の作業を実行する必要があります。

- OBIEE 10g WebカタログへのWebカタログ・リクエストのデプロイ

- ダッシュボード・イメージのデプロイ

- ODI作業リポジトリへのBI物理レイヤー接続の更新

OBIEE 11gでは、次のインストール後の作業を実行する必要があります。

- ダッシュボード・イメージのデプロイ

- ODI作業リポジトリへのBI物理レイヤー接続の更新

OBIEE 10g WebカタログへのWebカタログ・リクエストのデプロイ

注意:
この手順は、OBIEE 10gでのみ必要です。

Webカタログには、系統およびODIリポジトリ表に基づいてレポートを作成するための、OBIEE/ODI系統が付属しています。Webカタログ・リクエストをインポートするには、次の手順を実行します。

1. Webカタログに接続します。
Webカタログに接続するには、次のようにします。

1. 「スタート」→「すべてのプログラム」→「Oracle Business Intelligence」→「Catalog Manager」を選択します。

2. 「ファイル」→「カタログを開く」をクリックします。

3. BIサーバーで使用されるWebカタログのパスを入力します。

4. 「OK」をクリックします。

2. (オプションの手順)系統アーティファクトをインストールするカタログのバックアップ・コピーを作成します。
バックアップ・コピーを作成するには、次のようにします。

1. カタログを選択します。

2. 「ファイル」→「アーカイブ」を選択します。

3. アーカイブ・ファイルの名前を、たとえばwebcatalog_backup.catのように入力します。

4. 「OK」をクリックします。

3. カタログを展開し、ODIカタログ項目をインポートする共有フォルダを選択します。

4. 「ファイル」→「アンアーカイブ」を選択します。

5. 「カタログのアンアーカイブ」ウィンドウで、「アーカイブ・ファイル・パス」フィールドにODIカタログ・アーカイブ・ファイルの場所を入力します。このファイルは、系統のインストール・フォルダの/artifacts/10gサブフォルダにあります。

- OBIEE 10.1.3.3の場合は、artifacts/10godi_catalog_archive_10g.catと入力します。

- OBIEE 10.1.3.4の場合は、artifacts/10g/odi_catalog_archive_10_1_3_4.catと入力します。

6. 「OK」をクリックします。

ODIという名前の新しいフォルダがカタログ・フォルダに表示されます。

ダッシュボード・イメージのデプロイ

パッケージ済の要求では、分析アプリケーションをホストするアプリケーション・サーバーにデプロイする必要があるイメージを使用します。これらの作業は、使用するOBIEEサーバーのバージョンによって異なります。

- OBIEE 10gでは、ダッシュボード・イメージ(系統のインストール・フォルダの/artifacts/imagesサブフォルダにあるhie.gifとlin.gif)を、BI分析アプリケーションのデプロイメント・ディレクトリ下にあるresフォルダにコピーします。
次に例を示します。

<OC4J_HOME>\j2ee\home\applications\analytics\analytics\res

- OBIEE 11gでは、ダッシュボード・イメージ(系統のインストール・フォルダの/artifacts/imagesサブフォルダにあるhie.gifとlin.gif)を、BI分析アプリケーションのデプロイメント・ディレクトリ下にあるresフォルダにコピーします。
次に例を示します。

<DOMAIN_HOME>\servers\<SERVER_NAME>\tmp\_WL_user\analytics_11.1.1\7dezjl\war\res

ODI作業リポジトリへのBI物理レイヤー接続の更新

1. Oracle BI管理ツールを起動します。たとえば、「すべてのプログラム」→「Oracle Business Intelligence」→「管理」を選択します。

2. BIサーバーで使用するRPDファイル(.rpd)を開きます。

3. OBIEE物理レイヤーでORACLE_ODI_REPOSITORYデータベースを展開し、「接続プール」ノードをダブルクリックして、使用するODI作業リポジトリの構成に合わせて接続プールを編集します。

1. 「データ・ソース名」、「ユーザー名」および「パスワード」フィールドを更新します。

2. 「OK」をクリックします。

3. 物理スキーマを右クリックして、ODI作業リポジトリのスキーマに一致するようにスキーマの名前を変更します。

4. 「OK」をクリックして変更内容を保存します。

4. 名前を変更したスキーマを展開し、この更新された接続を次のようにしてテストします。

1. この物理スキーマのいずれかの表を右クリックし、行数を更新します。

2. 同じ表を再度右クリックし、「データの表示」を選択して、行数が更新されたデータを表示します。

17.3 OBIEEからのメタデータのエクスポートとOBIEE系統のリフレッシュ

この項では、OBIEEリポジトリとWebカタログからメタデータをエクスポートする方法およびそれをODIメタデータとともに系統に統合する方法について説明します。

OBIEEからメタデータをエクスポートして系統をリフレッシュするには、次のようにします。

1. 17.2.3.1項「OBIEE系統ウィザードのインストールと起動」で説明されているとおりにOBIEE系統ウィザードを起動します。

注意:
OBIEE 10gを使用している場合、Webカタログ・コンテンツを自動的にエクスポートすることはできません。このため、Webカタログ・コンテンツのエクスポートを手動で実行することが必要となります。詳細は、17.4.2項「OBIEE Webカタログ・レポートのテキスト・ファイルへのエクスポート」を参照してください。
このエクスポート・ファイルの場所をウィザードで指定します。

注意:
OBIEE系統ウィザードのかわりに、系統のリフレッシュ・スクリプトを使用することもできます。詳細は、17.5.3項「系統のリフレッシュの自動化」を参照してください。

ウィザードには、一連の画面が表17-2に示されている順序で表示されます。

2. 表17-2の手順に従います。

インストール画面に関して詳細な情報が必要な場合は、「ヘルプ」をクリックしてオンライン・ヘルプを参照してください。

表17-2 OBIEEからのメタデータのエクスポートおよび系統のリフレッシュの手順

番号

画面

画面が表示されるタイミング

説明および必要なアクション

1

「ようこそ」画面

毎回

「次へ」をクリックして続行します。

2

「アクションの選択」画面

毎回

「メタデータをOBIEEからエクスポートして系統をリフレッシュする」を選択します。

「次へ」をクリックして続行します。

3

「OBIEEリポジトリ接続情報」画面

「アクションの選択」画面で「系統をOBIEEサーバーにインストール」または「メタデータをOBIEEからエクスポートして系統をリフレッシュする」が選択されている場合。

メタデータを抽出するために、次の接続情報をOBIEEリポジトリに指定します。

- Oracleホーム: OBIEEインストール用のOracleホーム・ディレクトリを指定します。「参照」をクリックして、システムの既存のディレクトリを選択できます。例: C:/obiee11g/Oracle_BI1

- RPDファイルの場所: BIEEリポジトリ(RPD)ファイルの場所を入力します。

- ユーザー: OBIEEリポジトリ管理者のユーザー名を入力します。このフィールドはOBIEE 10gでのみ必須であり、OBIEE 11gでは無効です。

- パスワード: OBIEEリポジトリ管理者のパスワードを入力します。

「次へ」をクリックして続行します。

4

「OBIEE Webカタログ接続情報」画面

「アクションの選択」画面で「系統をOBIEEサーバーにインストール」またはOBIEEのメタデータをエクスポートして系統をリフレッシュするが選択されている場合。

OBIEE 10gを使用している場合、この画面で選択できるのは「Webカタログ・エクスポート・ファイル」のみです。

OBIEE Webカタログからメタデータを抽出するための接続情報を指定するか(OBIEE 11g)、Webカタログ・エクスポートの場所を指定します(OBIEE 10g)。

- OBIEEバージョン: OBIEEのバージョンを入力します。このバージョンは先に選択したRPDから選択されます。

- Webカタログの場所: メタデータのエクスポート元であるOBIEE Webカタログの場所を入力します。
OBIEE 10gを使用している場合、このフィールドは「Webカタログ・エクスポート・ファイル」フィールドに置き換えられます。17.4.2項「OBIEE Webカタログ・レポートのテキスト・ファイルへのエクスポート」で説明されている手順を使用して手動で作成したWebカタログ・エクスポート・ファイルを選択します。

- OBIEEインスタンス・ホーム: OBIEEインスタンスのホーム・ディレクトリを入力します。例: C:\OBIEE\Middleware\instances\instance1OBIEE 10gを使用している場合、このフィールドは使用できません。

- Webカタログ・フォルダ名: エクスポートする必要があるWebカタログ・フォルダの名前を入力します。例: /shared。OBIEE 10gを使用している場合、このフィールドは使用できません。

「次へ」をクリックして続行し、系統アーティファクトをインストールします。

5

「ODIリポジトリ接続情報」画面

「アクションの選択」画面で「メタデータをOBIEEからエクスポートして系統をリフレッシュする」または「系統のリフレッシュ」が選択されている場合。

次のODIリポジトリ接続情報を指定します。

Oracle Data Integrator接続

- ユーザー: ODIユーザー名を入力します。このユーザーにはスーパーバイザ権限が必要です。

- パスワード: ユーザーのパスワードを入力します。

データベース接続(マスター・リポジトリ)

- ユーザー: ODIマスター・リポジトリを保持するスキーマ(またはデータベース、ライブラリ)に接続するためのデータベース・ユーザー名を入力します。

- パスワード: ユーザーのパスワードを入力します。

- ドライバ名: マスター・リポジトリへの接続に使用するドライバの名前を入力します。

- URL: マスター・リポジトリへの接続に使用するURLを入力します。

作業リポジトリ

- 作業リポジトリ: 「選択」ボタンを使用して、マスター・リポジトリにアタッチされた作業リポジトリを選択します。この作業リポジトリに系統表が作成され、系統がこれらの表に統合されます。

「次へ」をクリックして続行します。

6

マッピング情報

「アクションの選択」画面で「メタデータをOBIEEからエクスポートして系統をリフレッシュする」または「系統のリフレッシュ」が選択されている場合。

この表を使用して、ODIデータ・モデルとOBIEE物理スキーマの間の対応マッピングを指定します。

1. 「BIマッピング - 物理DB、スキーマ、カタログ」リストから、マップするOBIEE物理スキーマを選択します。

2. 「ODIモデル」リストから、このOBIEEスキーマにマップするODIモデルを選択します。

3. 定義するマッピングごとに、「追加」をクリックします。これにより、表に新しい行が追加されます。

4. マッピングごとに前の手順を繰り返します。

「次へ」をクリックして続行します。

7

「ウォレット情報」画面

毎回

「セキュアなウォレットにパスワードを格納する」チェック・ボックスを選択します。

ウォレット・パスワードを入力するか、新しいウォレット・パスワードを作成して、「OK」をクリックします。

「次へ」をクリックして続行します。

注意: パスワードをセキュアなウォレットに格納しない場合は、「セキュアなウォレットにパスワードを格納する」チェック・ボックスが選択されていないことを確認して、「次」をクリックします。

8

「アクション完了」画面

毎回

「終了」をクリックしてウィザードを閉じます。

17.4 既存のエクスポートからのOBIEE系統のリフレッシュ

この項では、既存のエクスポートからOBIEE系統をリフレッシュする方法について説明します。この操作により、手動で作成されたOBIEEリポジトリとWebカタログのエクスポートがODIリポジトリ・メタデータとともに系統に統合されます。この項では、OBIEEリポジトリとWebカタログのエクスポート方法についても説明します。

この項には次のトピックが含まれます:

- OBIEEリポジトリ・ドキュメントのテキスト・ファイルへのエクスポート

- OBIEE Webカタログ・レポートのテキスト・ファイルへのエクスポート

- 既存のエクスポートからのOBIEE系統のリフレッシュ

17.4.1 OBIEEリポジトリ・ドキュメントのテキスト・ファイルへのエクスポート

この項では、OBIEEリポジトリ・メタデータを手動でエクスポートして、OBIEE系統に統合する方法について説明します。

OBIEEリポジトリ・ドキュメントをテキスト・ファイルにエクスポートするには、次のようにします。

1. Oracle BI管理ツールを開き、系統に含めるメタデータが格納されているOBIEEリポジトリに接続します。

2. OBIEE管理ツールで、「ツール」>「ユーティリティ」を選択します。

3. 「ユーティリティ」ダイアログで、「リポジトリ・ドキュメント」ユーティリティを選択し、「実行」をクリックします。

4. 一時ファイル(たとえば、c:\temp\repo_doc.txt)にリポジトリ・ドキュメントを保存します。
このリポジトリ・ドキュメントは必ずタブ区切りの値(*.txt)ファイル・タイプとして保存してください。

5. 保存をクリックします。

17.4.2 OBIEE Webカタログ・レポートのテキスト・ファイルへのエクスポート

この項では、OBIEE Webカタログ・メタデータを手動でエクスポートして、OBIEE系統に統合する方法について説明します。

OBIEE Webカタログ・レポートをテキスト・ファイルにエクスポートするには、次のようにします。

1. OBIEE Catalog Managerを開き、系統に含めるメタデータを含むカタログに接続します。

2. 系統に含めるレポートを含むカタログ・フォルダ(たとえば、/shared/Paint Demoまたは/shared/ODI)を選択します。

3. 「ツール」→「レポートの作成」を選択します。

4. 「カタログ・レポートの作成」ダイアログで、レポートに含める次の列を選択します: Owner、Request Folder、Request Name、Request Subject Area、Request Criteria Formula、Request Criteria Table、Request Criteria Column。
これらの列は、必ずこのとおりの順序で含まれるようにしてください。

5. 一時ファイル(たとえば、c:\temp\webcat_doc.txt)にレポートを保存します。

6. 「OK」をクリックします。

7. 「レポート・プレビュー」を確認し、「OK」をクリックします。

17.4.3 既存のエクスポートからのOBIEE系統のリフレッシュ

この項では、手動で作成された既存のOBIEEリポジトリとWebカタログのエクスポートから、OBIEE系統をリフレッシュする方法について説明します。

OBIEE系統をリフレッシュするには、次のようにします。

1. 17.2.3.1項「OBIEE系統ウィザードのインストールと起動」で説明されているとおりにOBIEE系統ウィザードを起動します。

注意:
OBIEE系統ウィザードのかわりに、系統のリフレッシュ・スクリプトを使用することもできます。詳細は、17.5.3項「系統のリフレッシュの自動化」を参照してください。

ウィザードには、一連の画面が表17-3に示されている順序で表示されます。

2. 表17-3の手順に従います。

インストール画面に関して詳細な情報が必要な場合は、「ヘルプ」をクリックしてオンライン・ヘルプを参照してください。

表17-3 OBIEE系統アーティファクトのリフレッシュ手順

番号

画面

画面が表示されるタイミング

説明および必要なアクション

1

「ようこそ」画面

毎回

「次へ」をクリックして続行します。

2

「アクションの選択」画面

毎回

「系統のリフレッシュ」を選択します。

「次へ」をクリックして続行します。

3

「OBIEEエクスポートの場所」画面

「アクションの選択」画面で「系統のリフレッシュ」が選択されている場合のみ。

OBIEEメタデータのエクスポートの場所を指定します。

- リポジトリ・エクスポート・ファイル: リポジトリ・エクスポート・ファイルの場所を入力します。詳細は、17.4.1項「OBIEEリポジトリ・ドキュメントのテキスト・ファイルへのエクスポート」を参照してください。

- Webカタログ・エクスポート・ファイル: Webカタログ・エクスポート・ファイルの場所を入力します。詳細は、17.4.2項「OBIEE Webカタログ・レポートのテキスト・ファイルへのエクスポート」を参照してください。

「次へ」をクリックして続行します。

4

「ODIリポジトリ接続情報」画面

「アクションの選択」画面で「メタデータをOBIEEからエクスポートして系統をリフレッシュする」または「系統のリフレッシュ」が選択されている場合。

次のODIリポジトリ接続情報を指定します。

Oracle Data Integrator接続

- ユーザー: ODIユーザー名を入力します。このユーザーにはスーパーバイザ権限が必要です。

- パスワード: ユーザーのパスワードを入力します。

データベース接続(マスター・リポジトリ)

- ユーザー: ODIマスター・リポジトリを保持するスキーマ(またはデータベース、ライブラリ)に接続するためのデータベース・ユーザー名を入力します。

- パスワード: ユーザーのパスワードを入力します。

- ドライバ名: マスター・リポジトリへの接続に使用するドライバの名前を入力します。

- URL: マスター・リポジトリへの接続に使用するURLを入力します。

作業リポジトリ

- 作業リポジトリ: 「選択」ボタンを使用して、マスター・リポジトリにアタッチされた作業リポジトリを選択します。この作業リポジトリに系統表が作成され、系統がこれらの表に統合されます。

「次へ」をクリックして続行します。

5

マッピング情報

「アクションの選択」画面で「メタデータをOBIEEからエクスポートして系統をリフレッシュする」または「系統のリフレッシュ」が選択されている場合。

この表を使用して、ODIデータ・モデルとOBIEE物理スキーマの間の対応マッピングを指定します。

1. 「BIマッピング - 物理DB、スキーマ、カタログ」リストから、マップするOBIEE物理スキーマを選択します。

2. 「ODIモデル」リストから、このOBIEEスキーマにマップするODIモデルを選択します。

3. 定義するマッピングごとに、「追加」をクリックします。これにより、表に新しい行が追加されます。

4. マッピングごとに前の手順を繰り返します。

「次へ」をクリックして続行します。

6

「ウォレット情報」画面

毎回

「セキュアなウォレットにパスワードを格納する」チェック・ボックスを選択します。

ウォレット・パスワードを入力するか、新しいウォレット・パスワードを作成して、「OK」をクリックします。

「次へ」をクリックして続行します。

注意: パスワードをセキュアなウォレットに格納しない場合は、「セキュアなウォレットにパスワードを格納する」チェック・ボックスが選択されていないことを確認して、「次」をクリックします。

7

「アクション完了」画面

毎回

「終了」をクリックしてウィザードを閉じます。

17.5 系統タスクの自動化

系統タスクを自動化するためのスクリプトも提供されています。これらのスクリプトはウィザードのかわりに使用でき、オプションの値はかわりにプロパティ・ファイルで指定する必要があります。

系統タスクを自動化するためのスクリプトは、系統のインストール・フォルダの/binサブフォルダにあります。

この項では、スクリプトを使用して系統タスクを自動化する方法および次の内容について説明します。

- スクリプトの構成

- 系統のデプロイメントの自動化

- 系統のリフレッシュの自動化

17.5.1 スクリプトの構成

スクリプトを開始する前に、プロパティ・ファイルで構成情報を指定する必要があります。このプロパティ・ファイルには、ウィザードのユーザー・インタフェースから入力する値が含まれます。

注意:
ウィザードを実行すると、系統のインストール・フォルダの/tmpサブフォルダにプロパティ・ファイルが自動的に生成されます。このプロパティ・ファイルは、コマンド行スクリプトでの作業の開始点として再利用できます。

図17-4に、プロパティ・ファイルで定義されるプロパティを示します。

表17-4 プロパティ

プロパティ

値

対象

説明

OBIEE_VERSION

<10g|11g>

インストール|エクスポート|リフレッシュ

OBIEEサーバーのバージョン。

OBIEE_RPD

<rpd_file_location>

インストール|エクスポート

BIサーバーのリポジトリ(.rpd)ファイルの場所。

OBIEE_WEBCAT

<web_catalog_folder>

インストール|エクスポート(OBIEE 11gでのみ必須)

BIサーバーにより使用されるWebカタログ・フォルダの場所。

OBIEE_RPD_PASS

<rpd_file_pwd>

インストール|エクスポート

RPDファイルのパスワード。

OBIEE_RPD_USER

<rpd_file_username>

インストール|エクスポート

OBIEE 10gでのみ必須

RPDファイルのユーザー名。

OBIEE_RPD_EXPORT_FILE

<rpd_export_file_location>

リフレッシュ

系統をリフレッシュするために使用されるOBIEEリポジトリ・ドキュメント・エクスポート・ファイルの場所。

OBIEE_WEBCAT_EXPORT_FILE

<webcat_export_file_location>

リフレッシュ

系統をリフレッシュするために使用されるOBIEE Webカタログ・レポートの場所。

OBIEE_ORACLE_HOME

<obiee_oracle_home>

インストール|エクスポート

BIサーバーのOracleホーム・ディレクトリ。

OBIEE_INSTANCE_HOME

<obiee_instance_home>

インストール|エクスポート

OBIEE 11gでのみ必須

BIサーバー・インスタンス・ホーム・ディレクトリ。

ODI_MASTER_URL

<odi_master_url>

エクスポート|リフレッシュ

ODIマスター・リポジトリに接続するためのJDBC URL。

ODI_MASTER_DRIVER

<odi_master_driver>

エクスポート|リフレッシュ

ODIマスター・リポジトリに接続するためのDBドライバ。

ODI_SUPERVISOR_PASS

<odi_supervisor_pwd>

エクスポート|リフレッシュ

スーパーバイザ権限を持つODIユーザーのODIパスワード。

ODI_SUPERVISOR_USER

<odi_supervisor_user>

エクスポート|リフレッシュ

スーパーバイザ権限を持つODIユーザー。

ODI_MASTER_USER

<odi_master_user>

エクスポート|リフレッシュ

ODIマスター・リポジトリのユーザー名。

ODI_MASTER_PASS

<odi_master_password>

エクスポート|リフレッシュ

ODIマスター・リポジトリのパスワード。

ODI_SECU_WORK_REP

<odi_work_rep>

エクスポート|リフレッシュ

系統表を格納している作業リポジトリの名前。

OBIEE_WEBCAT_FOLDER_TO_EXPORT

<webcat_folder_to_export>

インストール|エクスポート

レポート内にエクスポートするWebカタログ・フォルダ。例: /shared/ODI

INSTALL_ODI_LINEAGE

<yes|no>

スクリプトでのみ使用

BIEEサーバーにODIアーティファクトをデプロイする場合はyesに設定します。

EXPORT_OBIEE_METADATA

<yes|no>

スクリプトでのみ使用

BIメタデータをフラット・ファイルとしてエクスポートする場合はyesに設定します。系統メタデータをリフレッシュするのみの場合はnoに設定します。

例17-1に、サンプル・プロパティ・ファイルを示します。

例17-1 プロパティ・ファイル

# Version of BIEE Server. Values: 10g / 11g
OBIEE_VERSION=10g

# The location of the repository documentation (.rpd) file of the BI Server
OBIEE_RPD=C:/obiee11g/instances/instance2/bifoundation/ OracleBIServerComponent/coreapplication_obis1/repository/TechDemo_11g.rpd

# The location of the Web Catalog folder used by the BI Server.
# Required only for OBIEE 11g.
OBIEE_WEBCAT=C:/obiee11g/instances/instance2/bifoundation/ OracleBIPresentationServicesComponent/coreapplication_obips1/catalog/TechDemo

# The OBIEE Repository user. Required only for OBIEE 10g.
OBIEE_RPD_USER=Administrator
# The password of the OBIEE Repository user
OBIEE_RPD_PASS=<obiee password>

# The location of the exported Repository Documentation file
OBIEE_RPD_EXPORT_FILE=c:/odi/lineage/run/repo_doc.txt
# The location of the exported Web catalog file
OBIEE_WEBCAT_EXPORT_FILE=c:/odi/lineage/run/webcat_doc.txt

# The BI Server Oracle Home directory
OBIEE_ORACLE_HOME=C:/obiee11g/Oracle_BI1
# The BI Server Instance Home directory. Required only for OBIEE 11g.
OBIEE_INSTANCE_HOME=C:/obiee11g/instances/instance2

# The JDBC URL to connect to the ODI Master Repository
ODI_MASTER_URL=jdbc:oracle:thin:@localhost:1521:orcl
# The JDBC Driver to connect to the ODI Master Repository
ODI_MASTER_DRIVER=oracle.jdbc.OracleDriver
# The Database user for the schema that contains the ODI master repository.
ODI_MASTER_USER=MASTER_REPO
# This user's password
ODI_MASTER_PASS=<master_password>

# The ODI user with SUPERVISOR privileges
ODI_SUPERVISOR_USER=SUPERVISOR
# The ODI Password of the ODI User with SUPERVISOR privileges
ODI_SUPERVISOR_PASS=<supervisor password>

# Work Repository containing the lineage
ODI_SECU_WORK_REP=WORK_REP1

# The Web Catalog folder to export in the report. Eg: /shared/ODI
OBIEE_WEBCAT_FOLDER_TO_EXPORT=/shared/ODI

# Option to deploy ODI Artifacts on the BI Server.
INSTALL_ODI_LINEAGE=no
# Option to export BI Metadata as flat files
EXPORT_OBIEE_METADATA=yes

パスワードのエンコード

パスワードをプレーン・テキストで保存しないようにするには、encode.[sh|cmd] <password>コマンドを使用して、プロパティ・ファイルにパスワードをエンコードして保存します。パスワードがエンコードされると、プロパティ名がODI_MASTER_REPO_ENCODED_PASS、ODI_SUPERVISOR_ENCODED_PASSおよびOBIEE_RPD_ENCODED_PASSに変更されます。

17.5.2 系統のデプロイメントの自動化

系統のインストール・スクリプトにより、OBIEEサーバーに次のODIアーティファクトがデプロイされます。

- 系統RPD

- 系統Webカタログ(11g OBIEEのみ)

スクリプトでは、OBIEEツールを使用して、系統RPDと系統WebカタログのBIEEサーバー・コンポーネントとのマージを行います。

注意:
このスクリプトを実行した後は、17.2.4項「インストール後の作業」で説明されている作業を実行する必要があります。

構文

スクリプトの構文は、次のとおりです。

installlineage.bat [-propertyFile=property_file] [-prop_name=prop_value [...]] [-usage]

説明:

- propertyfileは、系統アーティファクトをインストールするために必要なすべてのプロパティを含むプロパティ・ファイルを表します。詳細は、17.5.1項「スクリプトの構成」を参照してください。値が指定されない場合、ユーザーから必要な情報を収集するために、ユーザー・ウィザードが起動されます。プロパティ・ファイル内のすべてのプロパティは、コマンド行オプション-propName=propValueでプロパティ値を指定することによってオーバーライドできます。

- prop_nameは、指定できるプロパティを表します。prop_valueに指定される値により、プロパティ・ファイルで指定された値がオーバーライドされます(値がある場合)。

- prop_valueは、prop_nameプロパティの値を表します。これにより、プロパティ・ファイルで指定された値がオーバーライドされます(値がある場合)。

- usageにより、使用方法の詳細が印刷されます。

- walletPasswordは、ウォレット・パスワードの値を表します。このオプションを指定しない場合、コマンドラインでパスワードを入力するように求められます。このオプションは、系統ツールをコマンドライン・モードで実行する場合にのみ有効であり、UIウィザード・モードで実行する場合には使用できません。

17.5.3 系統のリフレッシュの自動化

系統のリフレッシュ・スクリプトによって、プロパティ・ファイルで定義されるEXPORT_OBIEE_METADATAオプションに設定された値に応じて、次のいずれかの操作が実行されます。

- メタデータのエクスポートとリフレッシュ(EXPORT_OBIEE_METADATAオプションがYesに設定されている場合)

- 系統メタデータのリフレッシュ(EXPORT_OBIEE_METADATAオプションがNoに設定されている場合)

refreshlineage.shを使用するには、repo_doc.textおよびwebcat_doc.txtファイルをターゲットLinuxマシンに手動でコピーする必要があります。

構文

スクリプトの構文は、次のとおりです。

refreshlineage  [-propertyFile=property_file] [-mappingFile=mapping_file] [-prop_name=prop_value [...]] [-usage]

説明:

- propertyfileは、系統メタデータをエクスポートして統合するために必要なすべてのプロパティを含むプロパティ・ファイルを表します。詳細は、17.5.1項「スクリプトの構成」を参照してください。値が指定されない場合、ユーザーから必要な情報を収集するために、ユーザー・ウィザードが起動されます。プロパティ・ファイル内のすべてのプロパティは、コマンド行オプション-prop_name=prop_valueでプロパティ値を指定することによりオーバーライドできます。

- mappingfileは、BI_PHYSICAL_DB、BI_PHYSICAL_SCHEMAおよびBI_PHYSICAL_CATALOGへのモデル・コードのマッピングを表します。このマッピングは、カンマ区切りの値(.csv)ファイルの形式で指定する必要があります。

- walletPasswordは、ウォレット・パスワードの値を表します。このオプションを指定しない場合、コマンドラインでパスワードを入力するように求められます。このオプションは、系統ツールをコマンドライン・モードで実行する場合にのみ有効であり、UIウィザード・モードで実行する場合には使用できません。

注意:
propertyfileオプションおよびmappingfileオプションを指定しない場合、ユーザー入力を行うためのUIウィザードが表示されます。それ以外の場合は、スクリプトはコマンド行自体から実行され、系統をリフレッシュするためにプロパティ・ファイルとマッピング・ファイルから値を取得し、UIウィザードは表示されません。

例17-2に、サンプル・マッピング・ファイルを示します。

例17-2 マッピング・ファイル

# (c) Copyright Oracle.  All rights reserved.
# Sample Mapping File for ODI-OBIEE Metadata Lineage
# Format: BI Physical DB, BI Physical Schema, BI Physical Catalog, ODI Model ID
# Note: Lines starting with # are considered as comments.
DB-1,Schema-1,Catalog-1,model1
DB-2,Schema-2,Catalog-2,model2

17.6 OBIEEダッシュボードでの系統の使用

BIEEサーバーにデプロイされたOBIEE系統アーティファクトを使用することにより、様々なシナリオが可能になります。この項では、最も一般的な使用例を示します。

- 実行統計の表示

- 系統データの表示とフィルタリング

- ダッシュボードの使用

- 系統と階層の使用

- コンテキスト系統の使用

17.6.1 実行統計の表示

このシナリオでは、OBI-EEダッシュボード内でODIの実行統計を表示します。

ODI統計を追加するには、RuntimeStatsリクエストを系統Webカタログからダッシュボードに挿入します。図17-2に示すように、統計が表示されます。

図17-2 ランタイム統計

17.6.2 系統データの表示とフィルタリング

このシナリオでは、系統データを表示し、結果をフィルタ処理します。

このようなダッシュボードを作成するには、PromptLineageダッシュボード・プロンプトとLineageRequestColumnsリクエストをダッシュボードに追加します。図17-3に示すように、いずれのオブジェクトも系統Webカタログ内にあります。

図17-3 系統Webカタログ

図17-4に生成されるダッシュボードを示します。

図17-4 生成されるダッシュボード

17.6.3 ダッシュボードの使用

このダッシュボードでは、次のものを使用してフィルタ処理を行えます。

- 列のソース(ODI列またはOBI-EE論理、物理、プレゼンテーションまたはリクエスト列)

- 表および列を含むOBI-EEフォルダ/カタログまたはODIプロジェクト

- 列を含むリクエストまたは表

「実行」をクリックして、フィルタ処理された列のリストを表示します。

17.6.4 系統と階層の使用

このリクエストから、次のボタンのいずれかをクリックして、各列の系統と階層を表示できます。

系統

階層

系統の使用

系統アイコンを使用して、列の系統にドリルダウンできます。系統には、次のようなパスがあります。

>リクエストの列で使用されるOBIEEプレゼンテーション列

>プレゼンテーション列で使用されるOBIEE論理列

>プレゼンテーション列で使用されるOBIEE物理列

>OBIEE物理列に対応するODI列

> ODIソース列は、ODIマッピングを使用して特定のODIターゲット列をロードするために使用します。ソース列が他のODIマッピングのターゲットである場合、このパスは再帰できます。

系統の各レベルについて、ダッシュボードに次のものが表示されます。

- (ターゲット)列のタイプ、カタログ、表名および列名

- (ソース)列のタイプ、カタログ、表名および列名

- ソース列とターゲット列間の変換式

- 式がODIマッピングである場合、この変換のODIランタイム統計(実行統計)をドリルダウンできます。

- ビュー内で系統をクリックすることにより、系統の任意の点でドリルダウンできます。

図17-5に、ダッシュボードに表示される1つの系統レベルを示します。

図17-5 系統レベル

階層の使用

階層では、特定のリクエスト列の系統全体が、階層表示として示されます。図17-6に階層列系統を示します。

図17-6 階層列系統

17.6.5 コンテキスト系統の使用

任意のダッシュボードでLineageRequestColumnsを使用してコンテキスト系統リンクを作成できます。このコンテキスト系統リンクにより、特定のリクエストの系統を表示するダッシュボードが開きます。

コンテキスト系統を作成するには、次のようにします。

1. ダッシュボードを編集します。

2. 次のコードを使用して、テキスト・オブジェクトを挿入します。

<p><font class=Nav onclick="JavaScript:GoNavEx(event, '<lineage_requests_folder>/LineageRequestColumns','','Target Column','Catalog','<your_request_folder>','Target Column','Table Name','<your_request_name>');"><img src="res/lin.gif" alt="Navigate Metadata Lineage">&nbsp;Metadata Lineage</font>

このコードでは、使用する構成に応じて、次の項目を設定する必要があります。

- <lineage_requests_folder>は、LineageRequestColumnsリクエストが含まれるフォルダです。このフォルダは、OBIEE系統リクエストがデプロイされたフォルダです。

- <your_request_folder>は、系統を表示するリクエストが含まれるフォルダです。

- <your_request_name>は、系統を表示するリクエストの名前です。

たとえば、系統リクエストが/shared/ODIフォルダにインストールされ、/shared/ODI Customer Demo/Customer Per Countries Chartリクエストの系統を表示する場合、コードは次のようになります。

<p><font class=Nav onclick="JavaScript:GoNavEx(event, '/shared/ODI/LineageRequestColumns','','Target Column','Catalog','/shared/ODI  Customer Demo','Target Column','Table Name','Customer Per Countries Chart');"><img src="res/lin.gif" alt="Navigate Metadata Lineage">&nbsp;Metadata Lineage</font>

3. コードを保存する前に、図17-7に示されているように、「テキスト・プロパティ」エディタで「HTMLマークアップを含む」が選択されていることを確認してください。

図17-7 「テキスト・プロパティ」エディタ

このテキストによって、特定のリクエストの列系統を開くリンクがダッシュボードに作成されます。

4. 「OK」をクリックします。

図17-8に示されているように、メタデータ系統オブジェクトがダッシュボードに追加されます。

図17-8 ダッシュボード上のテキスト・オブジェクト

メタデータ系統をクリックすると、図17-9に示されているダッシュボードが表示されます。

図17-9 メタデータ系統をクリックしたときに表示される内容

18 Oracle Hyperion Planning

この章では、Oracle Data IntegratorでのOracle Hyperion Planningの使用方法について説明します。

この章には次の項が含まれます:

- 18.1項「はじめに」

- 18.2項「インストールおよび構成」

- 18.3項「Hyperion Planning Adapterの設定」

- 18.4項「トポロジの設定」

- 18.5項「Planningモデルの作成およびリバース・エンジニアリング」

- 18.6項「マッピングの設計」

- 18.7項「データベース表およびデータ・ロード列」

18.1 はじめに

Oracle Data Integrator Adapter for Hyperion Planningを使用すると、Oracle Data Integratorを介してOracle Hyperion Planningと任意のデータベースを接続して統合できます。このアダプタには、Planning、Oracle Hyperion Workforce PlanningおよびOracle Hyperion Capital Expense Planningアプリケーションにメタデータおよびデータをロードするための、一連のOracle Data Integratorナレッジ・モジュール(KM)が用意されています。

18.1.1 統合プロセス

Oracle Data Integrator Adapter for Hyperion Planningを使用してPlanningアプリケーションにメタデータおよびデータをロードするには、次のタスクを行います。

- 環境の設定: データ・サーバーおよびスキーマの定義。
18.4項「トポロジの設定」を参照してください。

- アダプタのリバース・エンジニアリング・ナレッジ・モジュール(RKM)を使用したPlanningアプリケーションのリバース・エンジニアリング。
18.5項「Planningモデルの作成およびリバース・エンジニアリング」を参照してください。

- アダプタの統合ナレッジ・モジュール(IKM)を使用した、Planningアプリケーションへのメタデータおよびデータのロード。
18.6項「マッピングの設計」を参照してください。

18.1.2 ナレッジ・モジュール

Oracle Data Integratorには、Hyperion Planningデータを処理するためのナレッジ・モジュール(KM)が用意されています。これらのリストを表18-1に示します。これらのKMでは、Hyperion Planning固有の機能が使用されます。Hyperion Planningデータベースでは、汎用SQL KMを使用することもできます。

表18-1 Hyperion Planningナレッジ・モジュール

ナレッジ・モジュール

説明

RKM Hyperion Planning

Planningアプリケーションをリバース・エンジニアリングし、Oracle Data Integratorマッピングでターゲットとして使用されるデータ・モデルを作成します。

各ディメンション(標準ディメンションおよび属性ディメンション)は、適切な列を含むディメンションと同名のデータストアとしてリバースされます。UDAのロードでは「UDA」という名前のデータストアが作成されます。

IKM SQL to Hyperion Planning

Planningアプリケーションにメタデータおよびデータをロードします。

18.2 インストールおよび構成

Oracle Data Integrator Adapter for Planningの使用を開始する前に、この項の情報を必ず読んでください。

- システム要件および動作要件

- テクノロジ固有の要件

- 接続性要件

- Hyperion Planning Adapterの設定

18.2.1 システム要件および動作要件

インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。

サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。

http://www.oracle.com/technology/products/oracle-data-integrator/index.html

18.2.2 テクノロジ固有の要件

Oracle Data Integrator Adapter for Planningを使用するためのテクノロジ固有の要件はありません。

18.2.3 接続性要件

Oracle Data Integrator Adapter for Planningを使用するための接続性固有の要件はありません。

18.3 Hyperion Planning Adapterの設定

次の項では、ODI StudioおよびODIスタンドアロン・エージェント向けのHyperion Planning Adapterを設定する方法を説明します。

18.3.1 ODI Studio向けのAdapterの設定

Hyperion Planning Adapterを設定する前に、ODI Studioを終了します。

1. Oracle Hyperion Planningディレクトリで、HspJS.jarを見つけます。

2. ODIからHspJS.jarに直接アクセスできない場合は、ODIがアクセスできる場所にHspJS.jarをコピーします。

3. HspJS.jarを含むように<ODI_HOME>/odi/studio/bin/odi.confファイルを変更します。
次に例を示します。

AddJavaLibFile /server/lib/HspJS.jar

18.3.2 ODIスタンドアロン・エージェント向けのAdapterの設定

Hyperion Planning Adapterを設定する前に、ODIエージェントを終了します。

1. Oracle Hyperion Planningディレクトリで、HspJS.jarを見つけます。

2. <DOMAIN_HOME>/libディレクトリにコピーします。
詳細は、Oracle® Fusion Middleware Oracle Data Integratorのインストールと構成のスタンドアロン・コロケート・エージェントのドメインの構成を参照してください。

18.4 トポロジの設定

トポロジの設定には次が含まれます。

1. Hyperion Planningデータ・サーバーの作成

2. Hyperion Planning物理スキーマの作成

18.4.1 Hyperion Planningデータ・サーバーの作成

『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のデータ・サーバーの作成に関する項に記載されている標準の手順で、Hyperion Planningテクノロジ用データ・サーバーを作成します。この項では、Hyperion Planningデータ・サーバーの定義に関する必須または固有のフィールドのみについて説明します。

1. 「定義」タブ:

- 名前: データ・サーバー定義の名前を入力します。

- サーバー(データ・サーバー): Planningアプリケーションのホスト名およびRMIポート番号を入力します。書式: <host>:<port>

2. 「接続」の下に、Planningサーバーに接続するためのユーザー名およびパスワードを入力します。

注意:
「テスト」ボタンは、Hyperion Planningデータ・サーバー接続では機能しません。このボタンは、JDBCドライバを装備する関係テクノロジのみで機能します。

18.4.2 Hyperion Planning物理スキーマの作成

『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』の物理スキーマの作成に関する項に記載されている標準の手順で、Hyperion Planning物理スキーマを作成します。

データ・サーバーの下で、モデルの基礎となるアプリケーションおよび論理スキーマに対応する物理スキーマを定義できます。

『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』の論理スキーマの作成に関する項に記載されている標準の手順で、この物理スキーマ用の論理スキーマを作成し、特定のコンテキストで関連付けます。

18.5 Planningモデルの作成およびリバース・エンジニアリング

この項には次のトピックが含まれます:

- Planningモデルの作成

- Planningモデルのリバース・エンジニアリング

18.5.1 Planningモデルの作成

『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のモデルの作成に関する項に記載されている標準の手順で、Planningモデルを作成します。

18.5.2 Planningモデルのリバース・エンジニアリング

Planningアプリケーションをリバース・エンジニアリングすると、アプリケーション内の各ディメンション用データストアを含む、Oracle Data Integratorモデルが作成されます。なお、Year/Period/Version/Scenarioはリバース・エンジニアリングされません。

RKMを使用して、Hyperion Planningでカスタマイズされたリバース・エンジニアリングを実行するには、『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のモデルのリバース・エンジニアリングに関する項に記載されている通常の手順を行います。この項では、Hyperion Planningテクノロジ固有のフィールドのみについて説明します。

1. Planningモデルの「リバース」タブでRKM Hyperion Planningを選択します。

RKMは、(論理スキーマおよびコンテキストによって特定される)アプリケーションに接続し、次をインポートします。

- アプリケーション内のディメンションごとに1つのデータストア(ディメンションと同じ名前を使用)

- UDAロード用のUDAという名前のデータストア

18.6 マッピングの設計

Planningアプリケーションをモデルとしてリバース・エンジニアリングした後、データおよびメタデータをアプリケーションにロードするためのマッピングのターゲットとして、このモデル内でデータストアを使用できます。

マッピング用に選択したKMによって、このマッピングの機能およびパフォーマンスが決まります。この項に示す推奨事項は、Hyperion Planningに関連する様々な状況でのKMの選択に役立ちます。

この項には次のトピックが含まれます:

- メタデータのロード

- データのロード

- ロード・オプション

18.6.1 メタデータのロード

Oracle Data Integratorには、PlanningアプリケーションにメタデータをロードするためのIKM SQL to Hyperion Planningが用意されています。

メタデータはディメンションのメンバーで構成されます。メンバーのデータ値をロードする前に、メンバー(つまりメタデータ)をロードする必要があります。たとえば、5名の新規従業員の給与データをロードする場合は、Oracle Hyperion Essbaseデータベースにデータをロードする前に、Planningリレーショナル・データベースにこれらの従業員を(メンバーとして)ロードします。

メンバーのロード先として使用できるのは、Planningに存在するディメンションのみです。ロードするディメンションごとに、別個のマッピングを使用する必要があります。マッピングを結合すると、複数のディメンションに一度にメタデータをロードできます。

注意:
以下の点に注意する必要があります。

- アプリケーションにディメンション・メンバーをロードした後、Essbaseデータベースをリフレッシュする必要があります。Essbaseデータベースのリフレッシュは、IKM SQL to Hyperion PlanningのREFRESH_DATABASEオプションをYesに設定した場合に実行されます。「ロード・オプション」を参照してください。

- IKM SQL to HyperionのREFRESH_DATABASEオプションをYesに設定していて、Essbaseデータベースのリフレッシュ操作でエラーが発生して失敗する場合でも、「オペレータ」タブには、リフレッシュ操作が成功したと表示されます。ただし、エラーはログ・ファイルに報告されます。Essbaseデータベースのリフレッシュに失敗し、「オペレータ」タブに成功と表示される場合は、ログ・ファイルでエラーを確認してください。

Planningアプリケーションにメタデータをロードするには、次のようにします。

1. マッピングを作成します。「フロー」タブで、必ずIKM SQL to Hyperion Planningを選択してください。

2. 18.6.3項「ロード・オプション」に記載されているロード・オプションを指定します。

3. マッピングを実行して、アプリケーションにメタデータをロードします。

4. 次の手順でディメンションを検証します。

1. Planning Webにログオンします。

2. 管理→ディメンションを選択します。

18.6.2 データのロード

Oracle Data Integratorには、PlanningアプリケーションにデータをロードするためのIKM SQL to Hyperion Planningが用意されています。

Planningですでに作成済の、選択したディメンション・メンバーにデータをロードできます。Planning、Workforce PlanningまたはCapital Expense Planningアプリケーションにデータをロードするには、あらかじめそのアプリケーションを設定しておく必要があります。

データをロードする前に、メンバー(メタデータ)がPlanningリレーショナル・データベースおよびEssbaseデータベース内に存在することを確認してください。メンバーが存在しない場合、データ・ロードは失敗します。(これには、視点で指定されたドライバ・メンバーおよびメンバーも含まれます。)必要であれば、メタデータをロードしてからEssbaseデータベースをリフレッシュして、メンバーを同期化します。

Planning、Workforce PlanningまたはCapital Expense Planningアプリケーションにデータをロードする前に、Planning内で関連するデータ・ロードおよびドライバ・ディメンションを設定しておく必要があります。Planning内でデータ・ロードおよびドライバ・ディメンションを設定した後、データをロードするメンバーの視点を決定する必要があります。

Planningアプリケーションにデータをロードするには、次のようにします。

1. Planningで、ロードするデータのパラメータを次のように指定します。

1. 管理→データ・ロード管理を選択します。

2. 使用可能なデータ・ロード・ディメンションとしてディメンションを選択し、実行をクリックします。

3. 使用可能なドライバ・ディメンションとして、Essbaseデータベースのデータのロード先ディメンション(例: Accountディメンション)を選択します。

4. データとともにロードするドライバ・ディメンションのメンバーを選択します。
Hyperion Planningデータ・ロードを設定した後、Hyperion Planning RKMを使用してリバース・エンジニアリング・プロセスを実行します。リバース・エンジニアリングにより、データ・ロードに必要な追加の列(フィールド)とともに、データ・ロード・ディメンションのデータストアが取得および更新されます。

5. 保存をクリックします。

2. Oracle Data Integrator Studioで、ロードするデータのマッピングを実行します。

注意:
メタデータおよびデータのロードには、同じマッピングを使用できます。IKM SQL to Hyperion Planningのオプションのリストは、18.6.3項「ロード・オプション」を参照してください。

3. オペレータ・ログで、マッピングが正常に実行されたかどうかを確認します。

4. 次のどちらかの方法で、データ・ロードを検証します:

- Planningデータ・フォームを作成してデータを取得します。

- Oracle Essbase Administration Servicesで、ブロックが適切なキューブに作成されていることを確認します。

18.6.3 ロード・オプション

IKM SQL to Hyperion Planningでは、Oracle Data Integrator Adapter for Hyperion Planningによるデータのロード方法を定義するための、次のオプションがサポートされています。

- LOAD_ORDER_BY_INPUT
有効な値: YesまたはNo。デフォルト: No。Yesに設定すると、入力レコードと同じ順序でメンバーがロードされます。

- SORT_PARENT_CHILD
有効な値: YesまたはNo。デフォルト: No。Yesに設定すると、ロードされるレコードは、子より先にすべての親を挿入する形でソートされます。

- LOG_ENABLED
有効な値: YesまたはNo。デフォルト: No。Yesに設定すると、ロード・プロセスの実行中に、LOG_FILE_NAMEオプションで指定されたファイルへのロギングが行われます。

- LOG_FILE_NAME
ログの保存先となるファイルの名前。デフォルト値: Java temp folder/ dimension.log

- MAXIMUM_ERRORS_ALLOWED
ロード・プロセスを停止する基準となる最大エラー数。デフォルト値: 0

0または負の数に設定すると、エラーの数にかかわらずロード・プロセスは続行します。

- LOG_ERRORS
使用できる値: YesまたはNo。デフォルト: No

Yesに設定すると、ERROR_LOG_FILEプロパティで指定されたファイルにエラー・レコードが記録されます。

- ERROR_LOG_FILE
エラー・レコードが記録されるファイルの名前。デフォルト値: Java temp folder/ dimension.err

- ERR_COL_DELIMITER
エラー・レコード・ファイルに使用される列デリミタ。デフォルト値: カンマ(,)

- ERR_ROW_DELIMITER
エラー・レコード・ファイルに使用される行デリミタ。デフォルト値: \r\n

注意:
行デリミタおよび列デリミタの値は、16進数で指定することもできます。0xで始まる値は16進数として扱われます。たとえば、0x0041は文字Aとして扱われます。

- ERR_TEXT_DELIMITER
エラー・レコード・ファイル内の列データに使用されるテキスト・デリミタ。

- ERR_LOG_HEADER_ROW
使用できる値: YesまたはNo。デフォルト: Yes

Yesに設定すると、行ヘッダーが(すべての列名とともに)エラー・レコード・ファイルに記録されます。

- REFRESH_DATABASE
Yesに設定すると、ロード操作の完了時にキューブのリフレッシュが起動します。

使用できる値: YesまたはNo。デフォルト: No

18.7 データベース表およびデータ・ロード列

IKM SQL to Hyperion Planningでは、表に列をロードしてデータストアを作成します。次の各項では、各データストア内の列について説明します。

- Accounts

- Employee

- Entities

- ユーザー定義ディメンション

- 属性ディメンション

- UDA

データ・ロード列は、ディメンションへのデータのロードに使用される列です。

18.7.1 Accounts

Accounts表の列の説明を表18-2に示します。Planningでのデータ・ロード用にアプリケーションが設定されている場合に、Accountディメンション・データのロード用に表示される追加の列の説明は、18.7.7項「データ・ロード列」を参照してください。

表18-2 Accounts

列

説明

Account

ロードする勘定科目メンバーの名前を指定します。そのメンバーが存在する場合、メンバーのプロパティは変更されます。存在しない場合は、レコードが追加されます。これは必須フィールドです。

このフィールドの値は、次の要件を満たす必要があります:

- 一意

- 英数字

- 80文字以下

- メンバー名にタブ、二重引用符(")またはバックスラッシュ(\)を含めることはできません。

- メンバー名の先頭に次の文字は使用できません: ' \ < | , = @ _ + - { } ( )

- 値としてEssbaseの予約語(Children、Parent、$$$UNIVERSE $$$、#MISSING、#MIなど)は使用できません。Essbaseの予約語の詳細は、Hyperion Essbase - System 9データベース管理者ガイドまたはEssbaseのオンライン・ヘルプを参照してください。
この値は文字列として渡されます。

Parent

ロードするメンバーの親の名前を指定します。ディメンションに階層を作成する場合に使用します。

メンバーのデータをロードしてアプリケーションの親メンバーとは異なる親メンバーを指定すると、指定した親値を使用してメンバーが更新されます。

例: 使用するPlanningアプリケーションのメンバー1の親値がメンバーAである場合に、メンバー1をメンバーBという親値とともにロードすると、メンバーBがメンバー1の親になります。メンバー1およびその子孫はメンバーAからメンバーBに移動します。この列が空のままの場合は、ロード時に無視されます。

次のいずれかの状況が発生した場合、レコードはロードされません。

- 指定された親が、ロードされるメンバーの子孫である。

- 指定された親がPlanningアプリケーションに存在しない。

Default Alias

ロードするメンバーの別名を指定します。プロパティを変更する場合に値を指定しないと、別名はPlanningアプリケーション内で変更されません。値として<NONE>または<none>を指定すると、Planningアプリケーション内の別名は削除されます。

正常にロードするには、この列の値が次の要件を満たす必要があります:

- 一意

- 英数字

- 80文字以下

- メンバー名にタブ、二重引用符(")またはバックスラッシュ(\)を含めることはできません。

- メンバー名の先頭に次の文字は使用できません: ' \ < | , = @ _ + - { } ( )

- 値としてEssbaseの予約語(Children、Parent、$$$UNIVERSE $$$、#MISSING、#MIなど)は使用できません。Essbaseの予約語の詳細は、Hyperion Essbase - System 9データベース管理者ガイドまたはEssbaseのオンライン・ヘルプを参照してください。

この値は文字列として渡されます。デフォルト値: NULL文字列

Additional Alias

ロードするメンバーの別名を指定できます。Alias列は、Planningで定義されたAlias表と同数存在します。複数の別名列に対する値は、デフォルトの別名列についてリストしたものと同じ要件を満たす必要があります。

Data Storage

ロードするメンバーの記憶域属性を指定します。

有効な値は次のとおりです。

- Store

- Dynamic Calc

- Dynamic Calc and Store

- Shared

- Never Share(デフォルト)

- Label Only

この値は文字列として渡されます。

Two Pass Calculation

ロードするメンバーにTwo-Pass Calculation関連の属性があるかどうかを示すブール値。有効な値: 0 (False。デフォルト)またはその他の任意の数字(True)。値は、Data Storageの値がDynamic CalcまたはDynamic Calc and Storeの場合にのみ有効です。それ以外の場合、レコードは拒否されます。

Account Type

ロードするメンバーの勘定科目タイプを指定します。有効な値: Revenue、Expense、Asset、Liability、EquityおよびSaved Assumption。デフォルト値として、ロードするメンバーの親の値またはExpense(メンバーがルート・ディメンションに追加される場合)が使用されます。

Time Balance

勘定科目タイプがSaved Assumptionのメンバーに対してのみ、またはレコードが拒否された場合に、タイプを指定します。有効な値: Flow、First、Balance、Averageおよび2つの平均化オプション(Actual_365およびActual_Actual)。(Actual_365では、各月を実際の日数および2月を28日とみなし、Actual_Actualではうるう年の2月を29日とみなします。)

デフォルト値として、ロードするメンバーの親の値またはFlow(メンバーがルート・ディメンションに追加される場合)が使用されます。この値は文字列として渡されます。勘定科目タイプごとのTime Balanceのデフォルト値は次のとおりです。

- Revenue: Flow

- Expense: Flow

- Asset: alance

- Liability: Balance

- Equity: Balance

注意: Time BalanceがFlowの場合は有効なSkip Valueが設定されているレコードがロードされますが、Skip Valueはすべての勘定科目タイプに対して無効です。

Skip Value

Skip Valueとして、Time Balanceプロパティ用に設定されるスキップ・オプションを指定します。Time BalanceプロパティがFirst、BalanceまたはAverageに設定されている場合は、次のスキップ・オプションを使用できます。

- None: 親値の計算時に、ゼロ、および#missing値が考慮されます。

- Missing: 親値の計算時に#missing値が除外されます。

- Zeros: 親値の計算時にゼロ値が除外されます。

- Missing and Zeros: 親値の計算時に、#missing値およびゼロ値が除外されます。

注意: Time BalanceがFlowの場合は有効なSkip Valueが設定されているレコードがロードされますが、Skip Valueはすべての勘定科目タイプに対して無効です。

Data Type

データの格納値を指定します。有効な値は次のとおりです。

- Currency: メンバーのデータ値をデフォルト通貨で格納および表示します。

- Non-currency: メンバーのデータ値を数値として格納および表示します。

- Percentage: データ値を数値として格納し、メンバーのデータ値をパーセンテージとして表示します。

- Smart list / enumeration: データ値を数値として格納し、メンバーのデータ値を文字列として表示します。

- Date: メンバーのデータ値をmm/dd/yyyyまたはdd/ mm/yyyyの書式で格納および表示します。

- Text: メンバーのデータ値をテキストとして格納および表示します。

- Unspecified: メンバーのデータ値を未指定として格納および表示します。

デフォルト値として、ロードするメンバーの親の値またはCurrency(メンバーがルート・ディメンションに追加される場合)が使用されます。

Exchange Rate Type

為替レートを指定します。この列は、Data Type列に指定された値に依存します。有効な値は次のとおりです。

- Data TypeがCurrencyの場合: Average、EndingおよびHistorical

- Data TypeがNon-currencyまたはPercentageの場合: None
この値は文字列として渡されます。デフォルト値として、ロードするメンバーの親の値、または(メンバーがルート・ディメンションに追加される場合は)次の値が使用されます。

- Revenue: Average

- Expense: Average

- Asset: Ending

- Liability: Ending

- Equity: Ending

- Saved Assumption: None

Use 445

Planningアプリケーションで選択された配布を示します。アプリケーションに配布が設定されていない場合、この列は表示されません。

有効な値: 0および1(または0以外の任意の数字)。デフォルト値: 1

Variance Reporting

勘定科目タイプがSaved Assumptionの勘定科目メンバーに対して、またはレコードが拒否された場合に値を指定します。有効な値は次のとおりです。

- Expense: Saved Assumptionを経費として指定します。予算額から実額を差し引いて差額が算出されます。

- Non-Expense: Saved Assumptionを収益として指定します。実額から予算額を差し引いて差額が算出されます。

この値は文字列として渡されます。デフォルト値は、ロードするメンバーの親から取得されるか、(メンバーがルート・ディメンションに追加される場合は)勘定科目タイプの値に基づきます。

勘定科目タイプごとの設定値は次のとおりです。

- Revenue: Non-Expense

- Expense: Expense

- Asset: Non-Expense

- Liability: Non-Expense

- Equity: Non-Expense

Source Plan Type

ロードするメンバーに割り当てられるプラン・タイプのプラン・タイプ名を指定します。有効な値は、Planningアプリケーションで指定されている任意のプラン・タイプです。

この値は文字列として渡されます。デフォルト値は、ロードされるメンバーの親から取得されます。親のソース・プランがメンバーに対して無効な場合、指定されたプラン・タイプはそのメンバーに対してアプリケーション内で選択されず、メンバーを最初に使用するプラン・タイプが使用されます。メンバーがルート・ディメンションにロードされる場合は、そのメンバーを使用する最初のプラン・タイプが使用されます。

メンバーの親を更新または保存する際には、ロードされるメンバーに関連付けられているソース・プラン・タイプが新しい親に対して有効かどうかが検証されます。メンバーのソース・プラン・タイプが親メンバーの有効なプラン・タイプでない場合は、The source plan type is not in the subset of valid plan types.というエラー・メッセージが表示されます。

メンバーのソース・プラン・タイプが親メンバーに対して有効で、メンバー自体に対して無効な場合、メンバーは保存されますがソース・プラン・タイプは(Plan 1、Plan 2、Plan 3、Wrkforce、Capexの順序で)最初の有効なプラン・タイプに設定されます。

注意: アダプタでソース・プラン・タイプが指定されていても、それが親に対して無効な場合は、レコードが拒否されます。

Plan Type(Plan1)

ロードされるメンバーがPlan1で使用されるかどうかを示すブール値。有効な値: 0 (False)またはその他の任意の数字(True)。デフォルト値: True。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

Aggregation(Plan1)

Plan1に関して、ロードされるメンバーの集計オプションを指定します。この列は、Planningアプリケーションがこのプラン・タイプに対して有効な場合のみ使用できます。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

この値は文字列として渡されます。有効な値は次のとおりです。

- +(デフォルト)

- *

- /

- %

- ~

- Never

Plan Type(Plan 2)

ロードされるメンバーがPlan2で使用されるかどうかを示すブール値。有効な値: 0 (False)またはその他の任意の数字(True)。デフォルト値: True。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

Aggregation(Plan2)

Plan2に関して、ロードされるメンバーの集計オプションを指定します。この列は、Planningアプリケーションがこのプラン・タイプに対して有効な場合のみ使用できます。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

この値は文字列として渡されます。有効な値は次のとおりです。

- +(デフォルト)

- *

- /

- %

- ~

- Never

Plan Type(Plan3)

ロードされるメンバーがPlan3で使用されるかどうかを示すブール値。有効な値: 0 (False)またはその他の任意の数字(True)。デフォルト値: True。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

Aggregation(Plan3)

Plan3に関して、ロードされるメンバーの集計オプションを指定します。この列は、Planningアプリケーションがこのプラン・タイプに対して有効な場合のみ使用できます。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

この値は文字列として渡されます。有効な値は次のとおりです。

- +(デフォルト)

- *

- /

- %

- ~

- Never

Plan Type(Wrkforce)

Workforce Planning用: Plan Type (Wrkforce)列は、ロードされるメンバーがWorkforce Planningで使用されるかどうかを示すブール値です。有効な値: 0 (False)またはその他の任意の数字(True)。デフォルトは「True」です。列の実際の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

Aggregation(Wrkforce)

Workforce Planning用: Aggregation (Wrkforce)列は、Workforce Planningに関して、ロードされるメンバーの集計オプションを指定します。この列は、Planningアプリケーションがこのプラン・タイプに対して有効な場合のみ使用できます。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

この値は文字列として渡されます。有効な値は次のとおりです。

- +(デフォルト)

- *

- /

- %

- ~

- Never

Plan Type (Capex)

Capital Expense Planning用: Plan Type (Capex)列は、ロードされるメンバーがCapital Expense Planningで使用されるかどうかを示すブール値です。有効な値: 0 (False)またはその他の任意の数字(True)。デフォルトは「True」です。列の実際の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

Aggregation (Capex)

Capital Expense Planning用: Capital Expense Planningに関して、ロードされるメンバーの集計オプションを指定します。この列は、Planningアプリケーションがこのプラン・タイプに対して有効な場合のみ使用できます。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

この値は文字列として渡されます。有効な値は次のとおりです。

- +(デフォルト)

- *

- /

- %

- ~

- Never

Custom Attribute

カスタム属性のメンバー値を指定します。カスタムの名前は、Planningアプリケーションでのカスタム属性の名前によって決まります。カスタム属性列の数は、Accountディメンションに対して定義される属性の数によって異なります。プロパティを変更する場合に値を指定しないと、カスタム属性はPlanningアプリケーション内で変更されません。値として<NONE>または<none>を指定すると、Planningアプリケーション内のカスタム属性は削除されます。この値は文字列として渡されます。

Member Formula

ディメンション・メンバーに対して定義されるメンバー式値を指定します。デフォルトでは、ディメンションまたはディメンション・メンバーにメンバー式は関連付けられていません。SharedまたはLabel Onlyに設定されているディメンション・メンバーのメンバー式は、ロードできません。

UDA

更新するユーザー定義属性のリストを指定します。Planning内で、またはUDAターゲットを使用して、ディメンション・メンバーのUDAを定義する必要があります。

Smart Lists

Planningアプリケーションで定義されるユーザー定義のスマート・リストの名前を指定します。この値は文字列として渡されます。Smart Listsのデフォルトは<None>です。スマート・リストは、(データ・ロードではなく)メタデータまたはディメンションのロードで使用され、スマート・リストの(値ではなく)名前と特定のディメンション・メンバーとの関連付けを定義します。1つのディメンションに複数のスマート・リストを関連付けられますが、各ディメンション・メンバーに関連付けられるスマート・リストは1つのみです。

Workforce Planningアプリケーションでは、次の事前定義済スマート・リストを使用できます。

- None

- Status

- FT_PT

- HealthPlan

- TaxRegion

- Month

- Performance

- Position

- EmployeeType

Description

ロードされるメンバーの説明を指定します。デフォルトでは、Description列は空です。

注意: この列の値が未入力の場合や、この列が関連付けられていない場合は、説明を伴わずに新規メンバーがロードされ、既存のメンバーの説明は変更されません。この列の値として<NONE>を入力すると、メンバーに関する既存の説明はすべて削除され、メンバーとともに説明がロードされることもありません。

Operation

次のいずれかの値を指定します。

- Update(デフォルト): ロードされるメンバーを追加、更新または移動します。

- Delete Level 0: ロードされるメンバーに子がない場合は、そのメンバーを削除します。

- Delete Idescendants: ロードされるメンバーおよびその子孫をすべて削除します。

- Delete Descendants: ロードされるメンバーの子孫を削除しますが、メンバー自体は削除しません。

注意: メンバーを削除すると、メンバー自体、メンバーのデータ、および関連付けられているすべてのプランニング・ユニットが永久に削除され、リストア不能になります。

18.7.2 Employee

Employee表の列の説明を表18-3に示します。アプリケーションがPlanningでのデータ・ロード用に設定されている場合に、Employeeディメンション・データのロード用に表示される追加の列の説明は、18.7.7項「データ・ロード列」を参照してください。

表18-3 Employee

列

説明

Employee

ロードする勘定科目メンバーの名前を指定します。そのメンバーが存在する場合、メンバーのプロパティは変更されます。存在しない場合は、レコードが追加されます。これは必須フィールドです。

このフィールドの値は、次の要件を満たす必要があります:

- 一意

- 英数字

- 80文字以下

- メンバー名にタブ、二重引用符(")またはバックスラッシュ(\)を含めることはできません。

- メンバー名の先頭に次の文字は使用できません: ' \ < | , = @ _ + - { } ( )

- 値としてEssbaseの予約語(Children、Parent、$$$UNIVERSE $$$、#MISSING、#MIなど)は使用できません。Essbaseの予約語の詳細は、Hyperion Essbase - System 9データベース管理者ガイドまたはEssbaseのオンライン・ヘルプを参照してください。

この値は文字列として渡されます。

Parent

ロードするメンバーの親の名前を指定します。ディメンションに階層を作成する場合に使用します。

メンバーのデータをロードしてアプリケーションの親メンバーとは異なる親メンバーを指定すると、指定した親値を使用してメンバーが更新されます。

例: 使用するPlanningアプリケーションのメンバー1の親値がメンバーAである場合に、メンバー1をメンバーBという親値とともにロードすると、メンバーBがメンバー1の親になります。メンバー1およびその子孫はメンバーAからメンバーBに移動します。この列が空のままの場合は、ロード時に無視されます。

次のいずれかの状況が発生した場合、レコードはロードされません。

- 指定された親が、ロードされるメンバーの子孫である。

- 指定された親がPlanningアプリケーションに存在しない。

Default Alias

ロードするメンバーの別名を指定します。プロパティを変更する場合に値を指定しないと、別名はPlanningアプリケーション内で変更されません。値として<NONE>または<none>を指定すると、Planningアプリケーション内の別名は削除されます。

正常にロードするには、この列の値が次の要件を満たす必要があります:

- 一意

- 英数字

- 80文字以下

- メンバー名にタブ、二重引用符(")またはバックスラッシュ(\)を含めることはできません。

- メンバー名の先頭に次の文字は使用できません: ' \ < | , = @ _ + - { } ( )

- 値としてEssbaseの予約語(Children、Parent、$$$UNIVERSE $$$、#MISSING、#MIなど)は使用できません。Essbaseの予約語の詳細は、Hyperion Essbase - System 9データベース管理者ガイドまたはEssbaseのオンライン・ヘルプを参照してください。

この値は文字列として渡されます。デフォルト値: NULL文字列

Additional Alias

ロードするメンバーの別名を指定できます。Alias列は、Planningで定義されたAlias表と同数存在します。複数の別名列に対する値は、デフォルトの別名列についてリストしたものと同じ要件を満たす必要があります。

Data Storage

ロードするメンバーの記憶域属性を指定します。

有効な値は次のとおりです。

- Store

- Dynamic Calc

- Dynamic Calc and Store

- Shared

- Never Share(デフォルト)

- Label Only

この値は文字列として渡されます。

Valid for Consolidation

この列は無視されます。

Two Pass Calculation

ロードするメンバーにTwo-Pass Calculation関連の属性があるかどうかを示すブール値。有効な値: 0 (False。デフォルト)またはその他の任意の数字(True)。値は、Data Storageの値がDynamic CalcまたはDynamic Calc and Storeの場合にのみ有効です。それ以外の場合、レコードは拒否されます。

Data Type

データの格納値を指定します。有効な値は次のとおりです。

- Currency: メンバーのデータ値をデフォルト通貨で格納および表示します。

- Non-currency: メンバーのデータ値を数値として格納および表示します。

- Percentage: データ値を数値として格納し、メンバーのデータ値をパーセンテージとして表示します。

- Smart list / enumeration: データ値を数値として格納し、メンバーのデータ値を文字列として表示します。

- Date: メンバーのデータ値をmm/dd/yyyyまたはdd/ mm/yyyyの書式で格納および表示します。

- Text: メンバーのデータ値をテキストとして格納および表示します。

- Unspecified: メンバーのデータ値を未指定として格納および表示します。

デフォルト値として、ロードするメンバーの親の値またはCurrency(メンバーがルート・ディメンションに追加される場合)が使用されます。

Custom Attribute

カスタム属性のメンバー値を指定します。カスタムの名前は、Planningアプリケーションでのカスタム属性の名前によって決まります。カスタム属性列の数は、Employeeディメンションに対して定義される属性の数によって異なります。プロパティを変更する場合に値を指定しないと、カスタム属性はPlanningアプリケーション内で変更されません。値として<NONE>または<none>を指定すると、Planningアプリケーション内のカスタム属性は削除されます。この値は文字列として渡されます。

Aggregation(Plan1)

Plan1に関して、ロードされるメンバーの集計オプションを指定します。この列は、Planningアプリケーションがこのプラン・タイプに対して有効な場合のみ使用できます。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

この値は文字列として渡されます。有効な値は次のとおりです。

- +(デフォルト)

- *

- /

- %

- ~

- Never

Aggregation(Plan2)

Plan2に関して、ロードされるメンバーの集計オプションを指定します。この列は、Planningアプリケーションがこのプラン・タイプに対して有効な場合のみ使用できます。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

この値は文字列として渡されます。有効な値は次のとおりです。

- +(デフォルト)

- *

- /

- %

- ~

- Never

Aggregation(Plan3)

Plan3に関して、ロードされるメンバーの集計オプションを指定します。この列は、Planningアプリケーションがこのプラン・タイプに対して有効な場合のみ使用できます。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

この値は文字列として渡されます。有効な値は次のとおりです。

- +(デフォルト)

- *

- /

- %

- ~

- Never

Aggregation(Wrkforce)

Workforce Planning用: Aggregation (Wrkforce)列は、Workforce Planningに関して、ロードされるメンバーの集計オプションを指定します。この列は、Planningアプリケーションがこのプラン・タイプに対して有効な場合のみ使用できます。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

この値は文字列として渡されます。有効な値は次のとおりです。

- +(デフォルト)

- *

- /

- %

- ~

- Never

Aggregation (Capex)

Capital Expense Planning用: Capital Expense Planningに関して、ロードされるメンバーの集計オプションを指定します。この列は、Planningアプリケーションがこのプラン・タイプに対して有効な場合のみ使用できます。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

この値は文字列として渡されます。有効な値は次のとおりです。

- +(デフォルト)

- *

- /

- %

- ~

- Never

Member Formula

ディメンション・メンバーに対して定義されるメンバー式値を指定します。デフォルトでは、ディメンションまたはディメンション・メンバーにメンバー式は関連付けられていません。SharedまたはLabel Onlyに設定されているディメンション・メンバーのメンバー式は、ロードできません。

UDA

更新するユーザー定義属性のリストを指定します。Planning内で、またはUDAターゲットを使用して、ディメンション・メンバーのUDAを定義する必要があります。

Smart Lists

Planningアプリケーションで定義されるユーザー定義のスマート・リストの名前を指定します。この値は文字列として渡されます。Smart Listsのデフォルトは<None>です。スマート・リストは、(データ・ロードではなく)メタデータまたはディメンションのロードで使用され、スマート・リストの(値ではなく)名前と特定のディメンション・メンバーとの関連付けを定義します。1つのディメンションに複数のスマート・リストを関連付けられますが、各ディメンション・メンバーに関連付けられるスマート・リストは1つのみです。

Workforce Planningアプリケーションでは、次の事前定義済スマート・リストを使用できます。

- None

- Status

- FT_PT

- HealthPlan

- TaxRegion

- Month

- Performance

- Position

- EmployeeType

Description

ロードされるメンバーの説明を指定します。デフォルトでは空です。

注意: この列の値が未入力の場合や、この列が関連付けられていない場合は、説明を伴わずに新規メンバーがロードされ、既存のメンバーの説明は変更されません。この列の値として<NONE>を入力すると、メンバーに関する既存の説明はすべて削除され、メンバーとともに説明がロードされることもありません。

Operation

次のいずれかの値を指定します。

- Update(デフォルト): ロードされるメンバーを追加、更新または移動します。

- Delete Level 0: ロードされるメンバーに子がない場合は、そのメンバーを削除します。

- Delete Idescendants: ロードされるメンバーおよびその子孫をすべて削除します。

- Delete Descendants: ロードされるメンバーの子孫を削除しますが、メンバー自体は削除しません。

注意: メンバーを削除すると、メンバー自体、メンバーのデータ、および関連付けられているすべてのプランニング・ユニットが永久に削除され、リストア不能になります。

18.7.3 Entities

Entities表の列の説明を表18-4に示します。アプリケーションがPlanningでのデータ・ロード用に設定されている場合に、Entitiesデータのロード用に表示される追加の列の説明は、18.7.7項「データ・ロード列」を参照してください。

表18-4 Entities

列

説明

Entity

ロードするメンバーの名前を指定します。そのメンバーが存在する場合、メンバーのプロパティは変更されます。そのメンバーが存在しない場合は、レコードが追加されます。この列は必須です。

正常にロードするには、この列の値が次の要件を満たす必要があります:

このフィールドの値は、次の要件を満たす必要があります:

- 一意

- 英数字

- 80文字以下

- メンバー名にタブ、二重引用符(")またはバックスラッシュ(\)を含めることはできません。

- メンバー名の先頭に次の文字は使用できません: ' \ < | , = @ _ + - { } ( )

- 値としてEssbaseの予約語(Children、Parent、$$$UNIVERSE $$$、#MISSING、#MIなど)は使用できません。Essbaseの予約語の詳細は、Hyperion Essbase - System 9データベース管理者ガイドまたはEssbaseのオンライン・ヘルプを参照してください。

この値は文字列として渡されます。

Parent

ロードするメンバーの親の名前を指定します。ディメンションに階層を作成する場合に使用します。

このロード方法を使用してアプリケーションのメンバーを更新する際に、アプリケーションでの親メンバーとは異なる親メンバーを指定すると、メンバーは、フロー・ダイアグラムで指定された新しい親値を使用して更新されます。

例: 使用するPlanningアプリケーションのメンバー1の親値がメンバーAである場合に、メンバー1をメンバーBという親値とともにロードすると、アプリケーションが更新され、メンバーBがメンバー1の親になります。メンバー1およびその子孫はメンバーAからメンバーBに移動します。この列が空のままの場合は、ロード時に無視されます。

次のいずれかの状況が発生した場合、レコードはロードされません。

- 指定された親が、ロードされるメンバーの子孫である。

- 指定された親がPlanningアプリケーションに存在しない。

Default Alias

ロードするメンバーの別名を指定します。プロパティを変更する場合に値を指定しないと、別名はPlanningアプリケーション内で変更されません。値として<NONE>または<none>を指定すると、Planningアプリケーション内の別名は削除されます。

正常にロードするには、この列の値が次の要件を満たす必要があります:

- 一意

- 英数字

- 80文字以下

- メンバー名にタブ、二重引用符(")またはバックスラッシュ(\)を含めることはできません。

- メンバー名の先頭に次の文字は使用できません: ' \ < | , = @ _ + - { } ( )

- 値としてEssbaseの予約語(Children、Parent、$$$UNIVERSE $$$、#MISSING、#MIなど)は使用できません。Essbaseの予約語の詳細は、Hyperion Essbase - System 9データベース管理者ガイドまたはEssbaseのオンライン・ヘルプを参照してください。

この値は文字列として渡されます。デフォルト値: NULL文字列

Additional Alias

Additional Alias列では、ロードするメンバーの別名を指定できます。Alias列は、Planningで定義されたAlias表と同数存在します。複数の別名列に対する値は、デフォルトの別名列についてリストしたものと同じ要件を満たす必要があります。

Data Storage

ロードするメンバーの記憶域属性を指定します。

有効な値は次のとおりです。

- Store

- Dynamic Calc

- Dynamic Calc and Store

- Shared

- Never Share(デフォルト)

- Label Only

この値は文字列として渡されます。

Two Pass Calculation

Planningアプリケーションで、ロードされるメンバーにTwo-Pass Calculation属性が関連付けられているかどうかを示すブール値。有効な値: 0 (False。デフォルト)またはその他の任意の数字(True)。値は、Data Storageの値がDynamic CalcまたはDynamic Calc and Storeの場合にのみ有効です。それ以外の場合、レコードは拒否されます。

Data Type

データの格納値を指定します。有効な値は次のとおりです。

- Currency: メンバーのデータ値をデフォルト通貨で格納および表示します。

- Non-currency: メンバーのデータ値を数値として格納および表示します。

- Percentage: データ値を数値として格納し、メンバーのデータ値をパーセンテージとして表示します。

- Smart list / enumeration: データ値を数値として格納し、メンバーのデータ値を文字列として表示します。

- Date: メンバーのデータ値をmm/dd/yyyyまたはdd/ mm/yyyyの書式で格納および表示します。

- Text: メンバーのデータ値をテキストとして格納および表示します。

- Unspecified: メンバーのデータ値を未指定として格納および表示します。

デフォルト値として、ロードするメンバーの親の値またはCurrency(メンバーがルート・ディメンションに追加される場合)が使用されます。

Base Currency

ロードされるエンティティの基準通貨を指定します。これは、Planningアプリケーションで定義された通貨のコードとなります。デフォルト値はUSDです。この列は、アプリケーションが多通貨として定義されている場合にのみ表示されます。

Plan Type(Plan1)

ロードされるメンバーがPlan1で使用されるかどうかを示すブール値。有効な値: 0 (False)またはその他の任意の数字(True。デフォルト)。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

Aggregation(Plan1)

Plan1に関して、ロードされるメンバーの集計オプションを指定します。この列は、Planningアプリケーションがこのプラン・タイプに対して有効な場合のみ使用できます。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

この値は文字列として渡されます。有効な値は次のとおりです。

- +(デフォルト)

- *

- /

- %

- ~

- Never

Plan Type(Plan2)

ロードされるメンバーがPlan2で使用されるかどうかを示すブール値。有効な値: 0 (False)またはその他の任意の数字(True)。デフォルト値: True。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

Aggregation(Plan2)

Plan2に関して、ロードされるメンバーの集計オプションを指定します。この列は、Planningアプリケーションがこのプラン・タイプに対して有効な場合のみ使用できます。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

この値は文字列として渡されます。有効な値は次のとおりです。

- +(デフォルト)

- *

- /

- %

- ~

- Never

Plan Type(Plan 3)

ロードされるメンバーがPlan3で使用されるかどうかを示すブール値。有効な値: 0 (False)またはその他の任意の数字(True)。デフォルト値: True。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

Aggregation(Plan3)

Plan3に関して、ロードされるメンバーの集計オプションを指定します。この列は、Planningアプリケーションがこのプラン・タイプに対して有効な場合のみ使用できます。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

この値は文字列として渡されます。有効な値は次のとおりです。

- +(デフォルト)

- *

- /

- %

- ~

- Never

Aggregation(Wrkforce)

Workforce Planning用: Aggregation (Wrkforce)列は、Workforce Planningに関して、ロードされるメンバーの集計オプションを指定します。この列は、Planningアプリケーションがこのプラン・タイプに対して有効な場合のみ使用できます。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

この値は文字列として渡されます。有効な値は次のとおりです。

- +(デフォルト)

- *

- /

- %

- ~

- Never

Aggregation (Capex)

Capital Expense Planning用: Capital Expense Planningに関して、ロードされるメンバーの集計オプションを指定します。この列は、Planningアプリケーションがこのプラン・タイプに対して有効な場合のみ使用できます。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

この値は文字列として渡されます。有効な値は次のとおりです。

- +(デフォルト)

- *

- /

- %

- ~

- Never

Custom Attribute

カスタム属性のメンバー値を指定します。カスタムの名前は、Planningアプリケーションでのカスタム属性の名前によって決まります。カスタム属性列の数は、Entityディメンションに対して定義される属性の数によって異なります。プロパティを変更する場合に値を指定しないと、カスタム属性はPlanningアプリケーション内で変更されません。値として<NONE>または<none>を指定すると、Planningアプリケーション内のカスタム属性は削除されます。この値は文字列として渡されます。

Member Formula

ディメンション・メンバーに対して定義されるメンバー式値を指定します。デフォルトでは、ディメンションまたはディメンション・メンバーにメンバー式は関連付けられていません。SharedまたはLabel Onlyに設定されているディメンション・メンバーのメンバー式は、ロードできません。

UDA

更新するユーザー定義属性のリストを指定します。Planning内で、またはUDAターゲットを使用して、ディメンション・メンバーのUDAを定義する必要があります。

Smart Lists

Planningアプリケーションで定義されるユーザー定義のスマート・リストの名前を指定します。この値は文字列として渡されます。Smart Listsのデフォルトは<None>です。スマート・リストは、(データ・ロードではなく)メタデータまたはディメンションのロードで使用され、スマート・リストの(値ではなく)名前と特定のディメンション・メンバーとの関連付けを定義します。1つのディメンションに複数のスマート・リストを関連付けられますが、各ディメンション・メンバーに関連付けられるスマート・リストは1つのみです。

Workforce Planningアプリケーションでは、次の事前定義済スマート・リストを使用できます。

- None

- Status

- FT_PT

- HealthPlan

- TaxRegion

- Month

- Performance

- Position

- EmployeeType

Description

ロードされるメンバーの説明を指定します。デフォルトでは空です。

注意: この列の値が未入力の場合や、この列が関連付けられていない場合は、説明を伴わずに新規メンバーがロードされ、既存のメンバーの説明は変更されません。この列の値として<NONE>を入力すると、メンバーに関する既存の説明はすべて削除され、メンバーとともに説明がロードされることもありません。

Operation

次のいずれかの値を指定します。

- Update(デフォルト): ロードされるメンバーを追加、更新または移動します。

- Delete Level 0: ロードされるメンバーに子がない場合は、そのメンバーを削除します。

- Delete Idescendants: ロードされるメンバーおよびその子孫をすべて削除します。

- Delete Descendants: ロードされるメンバーの子孫を削除しますが、メンバー自体は削除しません。

注意: メンバーを削除すると、メンバー自体、メンバーのデータ、および関連付けられているすべてのプランニング・ユニットが永久に削除され、リストア不能になります。

18.7.4 ユーザー定義ディメンション

ユーザー定義ディメンション表の列の説明を表18-5に示します。

表18-5 ユーザー定義ディメンション

列

説明

Entity

ロードするメンバーの名前を指定します。そのメンバーが存在する場合、メンバーのプロパティは変更されます。そのメンバーが存在しない場合は、レコードが追加されます。この列は必須です。

正常にロードするには、この列の値が次の要件を満たす必要があります:

このフィールドの値は、次の要件を満たす必要があります:

- 一意

- 英数字

- 80文字以下

- メンバー名にタブ、二重引用符(")またはバックスラッシュ(\)を含めることはできません。

- メンバー名の先頭に次の文字は使用できません: ' \ < | , = @ _ + - { } ( )

- 値としてEssbaseの予約語(Children、Parent、$$$UNIVERSE $$$、#MISSING、#MIなど)は使用できません。Essbaseの予約語の詳細は、Hyperion Essbase - System 9データベース管理者ガイドまたはEssbaseのオンライン・ヘルプを参照してください。

この値は文字列として渡されます。

Parent

ロードするメンバーの親の名前を指定します。ディメンションに階層を作成する場合に使用します。

このロード方法を使用してアプリケーションのメンバーを更新する際に、アプリケーションでの親メンバーとは異なる親メンバーを指定すると、メンバーは、フロー・ダイアグラムで指定された新しい親値を使用して更新されます。

例: 使用するPlanningアプリケーションのメンバー1の親値がメンバーAである場合に、メンバー1をメンバーBという親値とともにロードすると、アプリケーションが更新され、メンバーBがメンバー1の親になります。メンバー1およびその子孫はメンバーAからメンバーBに移動します。この列が空のままの場合は、ロード時に無視されます。

次のいずれかの状況が発生した場合、レコードはロードされません。

- 指定された親が、ロードされるメンバーの子孫である。

- 指定された親がPlanningアプリケーションに存在しない。

Default Alias

ロードするメンバーの別名を指定します。プロパティを変更する場合に値を指定しないと、別名はPlanningアプリケーション内で変更されません。値として<NONE>または<none>を指定すると、Planningアプリケーション内の別名は削除されます。

正常にロードするには、この列の値が次の要件を満たす必要があります:

- 一意

- 英数字

- 80文字以下

- メンバー名にタブ、二重引用符(")またはバックスラッシュ(\)を含めることはできません。

- メンバー名の先頭に次の文字は使用できません: ' \ < | , = @ _ + - { } ( )

- 値としてEssbaseの予約語(Children、Parent、$$$UNIVERSE $$$、#MISSING、#MIなど)は使用できません。Essbaseの予約語の詳細は、Hyperion Essbase - System 9データベース管理者ガイドまたはEssbaseのオンライン・ヘルプを参照してください。

この値は文字列として渡されます。デフォルト値: NULL文字列

Additional Alias

Additional Alias列では、ロードするメンバーの別名を指定できます。Alias列は、Planningで定義されたAlias表と同数存在します。複数の別名列に対する値は、デフォルトの別名列についてリストしたものと同じ要件を満たす必要があります。

Data Storage

ロードするメンバーの記憶域属性を指定します。

有効な値は次のとおりです。

- Store

- Dynamic Calc

- Dynamic Calc and Store

- Shared

- Never Share(デフォルト)

- Label Only

この値は文字列として渡されます。

Two Pass Calculation

Planningアプリケーションで、ロードされるメンバーにTwo-Pass Calculation属性が関連付けられているかどうかを示すブール値。有効な値: 0 (False。デフォルト)またはその他の任意の数字(True)。値は、Data Storageの値がDynamic CalcまたはDynamic Calc and Storeの場合にのみ有効です。それ以外の場合、レコードは拒否されます。

Data Type

データの格納値を指定します。有効な値は次のとおりです。

- Currency: メンバーのデータ値をデフォルト通貨で格納および表示します。

- Non-currency: メンバーのデータ値を数値として格納および表示します。

- Percentage: データ値を数値として格納し、メンバーのデータ値をパーセンテージとして表示します。

- Smart list / enumeration: データ値を数値として格納し、メンバーのデータ値を文字列として表示します。

- Date: メンバーのデータ値をmm/dd/yyyyまたはdd/ mm/yyyyの書式で格納および表示します。

- Text: メンバーのデータ値をテキストとして格納および表示します。

- Unspecified: メンバーのデータ値を未指定として格納および表示します。

デフォルト値として、ロードするメンバーの親の値またはCurrency(メンバーがルート・ディメンションに追加される場合)が使用されます。

Aggregation(Plan1)

Plan1に関して、ロードされるメンバーの集計オプションを指定します。この列は、Planningアプリケーションがこのプラン・タイプに対して有効な場合のみ使用できます。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

この値は文字列として渡されます。有効な値は次のとおりです。

- +(デフォルト)

- *

- /

- %

- ~

- Never

Aggregation(Plan2)

Plan2に関して、ロードされるメンバーの集計オプションを指定します。この列は、Planningアプリケーションがこのプラン・タイプに対して有効な場合のみ使用できます。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

この値は文字列として渡されます。有効な値は次のとおりです。

- +(デフォルト)

- *

- /

- %

- ~

- Never

Aggregation(Plan3)

Plan3に関して、ロードされるメンバーの集計オプションを指定します。この列は、Planningアプリケーションがこのプラン・タイプに対して有効な場合のみ使用できます。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

この値は文字列として渡されます。有効な値は次のとおりです。

- +(デフォルト)

- *

- /

- %

- ~

- Never

Aggregation(Wrkforce)

Workforce Planning用: Aggregation (Wrkforce)列は、Workforce Planningに関して、ロードされるメンバーの集計オプションを指定します。この列は、Planningアプリケーションがこのプラン・タイプに対して有効な場合のみ使用できます。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

この値は文字列として渡されます。有効な値は次のとおりです。

- +(デフォルト)

- *

- /

- %

- ~

- Never

Aggregation (Capex)

Capital Expense Planning用: Capital Expense Planningに関して、ロードされるメンバーの集計オプションを指定します。この列は、Planningアプリケーションがこのプラン・タイプに対して有効な場合のみ使用できます。列の名前は、Planningアプリケーションでのプラン・タイプ名によって異なります。

この値は文字列として渡されます。有効な値は次のとおりです。

- +(デフォルト)

- *

- /

- %

- ~

- Never

Custom Attribute

カスタム属性のメンバー値を指定します。カスタムの名前は、Planningアプリケーションでのカスタム属性の名前によって決まります。カスタム属性列の数は、Entityディメンションに対して定義される属性の数によって異なります。プロパティを変更する場合に値を指定しないと、カスタム属性はPlanningアプリケーション内で変更されません。値として<NONE>または<none>を指定すると、Planningアプリケーション内のカスタム属性は削除されます。この値は文字列として渡されます。

Member Formula

ディメンション・メンバーに対して定義されるメンバー式値を指定します。デフォルトでは、ディメンションまたはディメンション・メンバーにメンバー式は関連付けられていません。SharedまたはLabel Onlyに設定されているディメンション・メンバーのメンバー式は、ロードできません。

UDA

更新するユーザー定義属性のリストを指定します。Planning内で、またはUDAターゲットを使用して、ディメンション・メンバーのUDAを定義する必要があります。

Smart Lists

Planningアプリケーションで定義されるユーザー定義のスマート・リストの名前を指定します。この値は文字列として渡されます。Smart Listsのデフォルトは<None>です。スマート・リストは、(データ・ロードではなく)メタデータまたはディメンションのロードで使用され、スマート・リストの(値ではなく)名前と特定のディメンション・メンバーとの関連付けを定義します。1つのディメンションに複数のスマート・リストを関連付けられますが、各ディメンション・メンバーに関連付けられるスマート・リストは1つのみです。

Workforce Planningアプリケーションでは、次の事前定義済スマート・リストを使用できます。

- None

- Status

- FT_PT

- HealthPlan

- TaxRegion

- Month

- Performance

- Position

- EmployeeType

Description

ロードされるメンバーの説明を指定します。デフォルトでは空です。

注意: この列の値が未入力の場合や、この列が関連付けられていない場合は、説明を伴わずに新規メンバーがロードされ、既存のメンバーの説明は変更されません。この列の値として<NONE>を入力すると、メンバーに関する既存の説明はすべて削除され、メンバーとともに説明がロードされることもありません。

Operation

次のいずれかの値を指定します。

- Update(デフォルト): ロードされるメンバーを追加、更新または移動します。

- Delete Level 0: ロードされるメンバーに子がない場合は、そのメンバーを削除します。

- Delete Idescendants: ロードされるメンバーおよびその子孫をすべて削除します。

- Delete Descendants: ロードされるメンバーの子孫を削除しますが、メンバー自体は削除しません。

注意: メンバーを削除すると、メンバー自体、メンバーのデータ、および関連付けられているすべてのプランニング・ユニットが永久に削除され、リストア不能になります。

18.7.5 属性ディメンション

属性ディメンション表の列の説明を表18-6に示します。

注意:
Parent、Default AliasおよびAdditional Alias列は、Planning 9.3.1以降のみで使用可能です。

表18-6 属性ディメンション

列

説明

Entity

ロードするメンバーの名前を指定します。そのメンバーが存在する場合、メンバーのプロパティは変更されます。そのメンバーが存在しない場合は、レコードが追加されます。この列は必須です。

正常にロードするには、この列の値が次の要件を満たす必要があります:

このフィールドの値は、次の要件を満たす必要があります:

- 一意

- 英数字

- 80文字以下

- メンバー名にタブ、二重引用符(")またはバックスラッシュ(\)を含めることはできません。

- メンバー名の先頭に次の文字は使用できません: ' \ < | , = @ _ + - { } ( )

- 値としてEssbaseの予約語(Children、Parent、$$$UNIVERSE $$$、#MISSING、#MIなど)は使用できません。Essbaseの予約語の詳細は、Hyperion Essbase - System 9データベース管理者ガイドまたはEssbaseのオンライン・ヘルプを参照してください。

この値は文字列として渡されます。

Parent

ロードするメンバーの親の名前を指定します。ディメンションに階層を作成する場合に使用します。

このロード方法を使用してアプリケーションのメンバーを更新する際に、アプリケーションでの親メンバーとは異なる親メンバーを指定すると、メンバーは、フロー・ダイアグラムで指定された新しい親値を使用して更新されます。

例: 使用するPlanningアプリケーションのメンバー1の親値がメンバーAである場合に、メンバー1をメンバーBという親値とともにロードすると、アプリケーションが更新され、メンバーBがメンバー1の親になります。メンバー1およびその子孫はメンバーAからメンバーBに移動します。この列が空のままの場合は、ロード時に無視されます。

次のいずれかの状況が発生した場合、レコードはロードされません。

- 指定された親が、ロードされるメンバーの子孫である。

- 指定された親がPlanningアプリケーションに存在しない。

Default Alias

ロードするメンバーの別名を指定します。プロパティを変更する場合に値を指定しないと、別名はPlanningアプリケーション内で変更されません。値として<NONE>または<none>を指定すると、Planningアプリケーション内の別名は削除されます。

正常にロードするには、この列の値が次の要件を満たす必要があります:

- 一意

- 英数字

- 80文字以下

- メンバー名にタブ、二重引用符(")またはバックスラッシュ(\)を含めることはできません。

- メンバー名の先頭に次の文字は使用できません: ' \ < | , = @ _ + - { } ( )

- 値としてEssbaseの予約語(Children、Parent、$$$UNIVERSE $$$、#MISSING、#MIなど)は使用できません。Essbaseの予約語の詳細は、Hyperion Essbase - System 9データベース管理者ガイドまたはEssbaseのオンライン・ヘルプを参照してください。

この値は文字列として渡されます。デフォルト値: NULL文字列

Additional Alias

Additional Alias列では、ロードするメンバーの別名を指定できます。Alias列は、Planningで定義されたAlias表と同数存在します。複数の別名列に対する値は、デフォルトの別名列についてリストしたものと同じ要件を満たす必要があります。

Operation

次のいずれかの値を指定します。

- Update(デフォルト): ロードされるメンバーを追加、更新または移動します。

- Delete Level 0: ロードされるメンバーに子がない場合は、そのメンバーを削除します。

- Delete Idescendants: ロードされるメンバーおよびその子孫をすべて削除します。

- Delete Descendants: ロードされるメンバーの子孫を削除しますが、メンバー自体は削除しません。

注意: メンバーを削除すると、メンバー自体、メンバーのデータ、および関連付けられているすべてのプランニング・ユニットが永久に削除され、リストア不能になります。

18.7.6 UDA

UDA表の列の説明を表18-7に示します。

表18-7 UDA

列

説明

Dimension

UDAのディメンション名を指定します。UDAは、Planningアプリケーションに存在するディメンションにのみ関連付けることができます。そのUDAが存在する場合、メンバーのプロパティは変更されます。存在しない場合は、レコードが追加されます。この列は必須です。

UDA

ロードするUDAの値を指定します。

Dimension

ロードするUDAの値を指定します。正常にロードするには、この列の値が次の要件を満たす必要があります:

正常にロードするには、この列の値が次の要件を満たす必要があります:

- 一意

- 英数字

- 80文字以下

- メンバー名にタブ、二重引用符(")またはバックスラッシュ(\)を含めることはできません。

- メンバー名の先頭に次の文字は使用できません: ' \ < | , = @ _ + - { } ( )

- 値としてEssbaseの予約語(Children、Parent、$$$UNIVERSE $$$、#MISSING、#MIなど)は使用できません。Essbaseの予約語の詳細は、Hyperion Essbase - System 9データベース管理者ガイドまたはEssbaseのオンライン・ヘルプを参照してください。

この値は文字列として渡されます。デフォルト値: NULL文字列

Operation

次のいずれかの値を指定します。

- Update(デフォルト): ロードされるメンバーを追加、更新または移動します。

- Delete Level 0: ロードされるメンバーに子がない場合は、そのメンバーを削除します。

- Delete Idescendants: ロードされるメンバーおよびその子孫をすべて削除します。

- Delete Descendants: ロードされるメンバーの子孫を削除しますが、メンバー自体は削除しません。

注意: メンバーを削除すると、メンバー自体、メンバーのデータ、および関連付けられているすべてのプランニング・ユニットが永久に削除され、リストア不能になります。

18.7.7 データ・ロード列

Account、Employee、Entitiesおよびユーザー定義ディメンションにデータをロードするためのこれらの列は、アプリケーションがPlanningでのデータ・ロード用に設定されている場合に表示されます。

表18-8 データ・ロード列

列

説明

Data Load Cube Name

データのロード先となるプラン・タイプの名前を指定します。この値は文字列として渡されます。有効な値は、Planningアプリケーションで指定されている任意のプラン・タイプです。次に例を示します。

- Plan1

- Plan2

- Plan3

- Wkforce

- Capex

Driver Member

Planning、Oracle Hyperion® Workforce PlanningまたはOracle Hyperion® Capital Expense Planningアプリケーションがデータ・ロード用に設定された際に選択されたドライバ・メンバーの名前を指定します。ドライバ・ディメンションは、ロードごとに1つ設定できます。ドライバ・ディメンションおよびドライバ・ディメンション・メンバーは、Planningの「データ・ロード管理」ページで定義されます。ドライバ・メンバーは、データのロード先となるメンバーです。ドライバ・メンバー列の数は、Oracle Hyperion® Planning - System 9で選択したドライバ・メンバーの数によって異なります。この値は数値を表す文字列、または(スマート・リストがこの列に表示されるメンバーにバインドされている場合は)スマート・リスト値を表す文字列として渡されます。

注意: このロード方法のSmart Listフィールドは、この列には影響しません。

Point-of-View

データをロードする共通部分の特定に必要な、その他の全ディメンションの名前を指定します。この値は文字列として渡されます。データ・ロードにより、POVで定義されたディメンション・パラメータに基づいて、製品間レコードの作成が自動的に実行されます。たとえば、従業員のSmart List属性値が長期間変わらない場合(ステータスが12ヶ月間フルタイムの場合など)、この属性値をデータ入力で指定する必要があるのは1度のみで、関連する共通部分の各セルのデータ・レコードは、ロード・ファイルによって作成され、ロードされます。

列

説明

Data Load Cube Name

データのロード先となるプラン・タイプの名前を指定します。この値は文字列として渡されます。有効な値は、Planningアプリケーションで指定されている任意のプラン・タイプです。次に例を示します。

- Plan1

- Plan2

- Plan3

- Wkforce

- Capex

Driver Member

Planning、Oracle Hyperion® Workforce PlanningまたはOracle Hyperion® Capital Expense Planningアプリケーションがデータ・ロード用に設定された際に選択されたドライバ・メンバーの名前を指定します。ドライバ・ディメンションは、ロードごとに1つ設定できます。ドライバ・ディメンションおよびドライバ・ディメンション・メンバーは、Planningの「データ・ロード管理」ページで定義されます。ドライバ・メンバーは、データのロード先となるメンバーです。ドライバ・メンバー列の数は、Oracle Hyperion® Planning - System 9で選択したドライバ・メンバーの数によって異なります。この値は数値を表す文字列、または(スマート・リストがこの列に表示されるメンバーにバインドされている場合は)スマート・リスト値を表す文字列として渡されます。
注意: このロード方法のSmart Listフィールドは、この列には影響しません。

Point-of-View

データをロードする共通部分の特定に必要な、その他の全ディメンションの名前を指定します。この値は文字列として渡されます。データ・ロードにより、POVで定義されたディメンション・パラメータに基づいて、製品間レコードの作成が自動的に実行されます。たとえば、従業員のSmart List属性値が長期間変わらない場合(ステータスが12ヶ月間フルタイムの場合など)、この属性値をデータ入力で指定する必要があるのは1度のみで、関連する共通部分の各セルのデータ・レコードは、ロード・ファイルによって作成され、ロードされます。

19 Oracle Hyperion Essbase

この章では、Oracle Data IntegratorでのOracle Hyperion Essbaseの使用方法について説明します。

この章には次の項が含まれます:

- 19.1項「はじめに」

- 19.2項「インストールおよび構成」

- 19.3項「Hyperion Essbase Adapterの設定」

- 19.4項「トポロジの設定」

- 19.5項「Essbaseモデルの作成およびリバース・エンジニアリング」

- 19.6項「マッピングの設計」

19.1 はじめに

Oracle Data Integrator Adapter for Oracle Hyperion Essbaseを使用すると、実質的にあらゆるソースまたはターゲットとEssbaseをOracle Data Integratorで接続して統合できます。このアダプタには、Essbaseアプリケーションでのメタデータとデータのロードと抽出、およびデータの計算を行うための、一連のOracle Data Integratorナレッジ・モジュール(KM)が用意されています。

19.1.1 統合プロセス

Oracle Data Integrator Adapter for Essbaseを使用して、Essbaseアプリケーションで次のデータ統合タスクを実行できます。

- メタデータおよびデータのロード

- メタデータおよびデータの抽出

このアダプタを使用して、次のタスクに関係するメタデータやデータのロードまたは抽出を行います。

- 環境の設定: データ・サーバーおよびスキーマの定義。
19.4項「トポロジの設定」を参照してください。

- リバース・エンジニアリング・ナレッジ・モジュール(RKM)を使用したEssbaseアプリケーションのリバース・エンジニアリング。
19.5項「Essbaseモデルの作成およびリバース・エンジニアリング」を参照してください。

- ロード・ナレッジ・モジュール(LKM)を使用したメタデータおよびデータの抽出。
19.6項「マッピングの設計」を参照してください。

- 統合ナレッジ・モジュール(IKM)を使用したEssbaseアプリケーションでのメタデータおよびデータの統合。
19.6項「マッピングの設計」を参照してください。

19.1.2 ナレッジ・モジュール

Oracle Data Integratorには、Hyperion Essbaseデータを処理するためのナレッジ・モジュール(KM)が用意されています。これらのリストを表19-1に示します。これらのKMではHyperion Essbase固有の機能が使用されます。Hyperion Essbaseデータベースで汎用SQL KMを使用することもできます。

表19-1 Hyperion Essbaseナレッジ・モジュール

ナレッジ・モジュール

説明

RKM Hyperion Essbase

Essbaseアプリケーションをリバース・エンジニアリングし、Oracle Data Integratorマッピングでターゲットまたはソースとして使用されるデータ・モデルを作成します。

IKM SQL to Hyperion Essbase (DATA)

Essbaseアプリケーションにデータを統合します。

IKM SQL to Hyperion Essbase (METADATA)

Essbaseアプリケーションにメタデータを統合します。

LKM Hyperion Essbase DATA to SQL

Essbaseアプリケーションから、ステージング領域として使用される任意のSQL準拠データベースへ、データをロードします。

LKM Hyperion Essbase METADATA to SQL

Essbaseアプリケーションから、ステージング領域として使用される任意のSQL準拠データベースへ、メタデータをロードします。

19.2 インストールおよび構成

Oracle Data Integrator Adapter for Essbaseの使用を開始する前に、この項の情報を必ず読んでください。

- システム要件および動作要件

- テクノロジ固有の要件

- 接続性要件

19.2.1 システム要件および動作要件

インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。

サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。

http://www.oracle.com/technology/products/oracle-data-integrator/index.html

19.2.2 テクノロジ固有の要件

Oracle Data Integrator Adapter for Essbaseを使用するためのテクノロジ固有の要件はありません。

19.2.3 接続性要件

Oracle Data Integrator Adapter for Essbaseを使用するための接続性固有の要件はありません。

19.3 Hyperion Essbase Adapterの設定

次の項では、ODI StudioおよびODIスタンドアロン・エージェント向けのHyperion Essbase Adapterを設定する方法を説明します。

19.3.1 ODI Studio向けのAdapterの設定

設定処理を開始する前に、ODI Studioを終了します。

1. Oracle Hyperion Essbaseディレクトリで、ess_japi.jarを見つけます。

2. ODIからess_japi.jarに直接アクセスできない場合は、ODIがアクセスできる場所にess_japi.jarをコピーします。

3. ess_japi.jarを含むように<ODI_HOME>/odi/studio/bin/odi.confファイルを変更します。
次に例を示します。

AddJavaLibFile /server/lib/ess_japi.jar

19.3.2 ODIスタンドアロン・エージェント向けのAdapterの設定

設定処理を開始する前に、ODIエージェントを終了します。

1. Oracle Hyperion Essbaseディレクトリで、ess_japi.jarを見つけます。

2. <DOMAIN_HOME>/libディレクトリにコピーします。

詳細は、Oracle® Fusion Middleware Oracle Data Integratorのインストールと構成のスタンドアロン・コロケート・エージェントのドメインの構成を参照してください。

19.4 トポロジの設定

トポロジの設定には次が含まれます。

1. Hyperion Essbaseデータ・サーバーの作成

2. Hyperion Essbase物理スキーマの作成

19.4.1 Hyperion Essbaseデータ・サーバーの作成

『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のデータ・サーバーの作成に関する項に記載されている標準の手順で、Hyperion Essbaseテクノロジ用データ・サーバーを作成します。この項では、Hyperion Essbaseデータ・サーバーの定義に関する必須または固有のフィールドのみについて説明します。

1. 「定義」タブ:

- 名前: データ・サーバー定義の名前を入力します。

- サーバー(データ・サーバー): Essbaseサーバー名を入力します。

注意:
Essbaseサーバーがデフォルト・ポート(1423)以外のポートで稼働している場合は、Essbaseサーバーの詳細を<Essbase Server hostname>:<port>という書式で指定してください。

2. 「接続」の下に、Essbaseサーバーに接続するためのユーザー名およびパスワードを入力します。

注意:
「テスト」ボタンは、Essbaseデータ・サーバー接続では機能しません。このボタンは、JDBCドライバを装備する関係テクノロジのみで機能します。

19.4.2 Hyperion Essbase物理スキーマの作成

『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』の物理スキーマの作成に関する項に記載されている標準の手順で、Hyperion Essbase物理スキーマを作成します。

「アプリケーション」(「カタログ」)および「アプリケーション」(「作業カタログ」)の下でEssbaseアプリケーションを指定し、「データベース」(「スキーマ」)および「データベース」(「作業スキーマ」)の下で、選択したアプリケーションに関連付けられているEssbaseデータベースを指定します。

『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』の論理スキーマの作成に関する項に記載されている標準の手順で、この物理スキーマ用の論理スキーマを作成し、特定のコンテキストで関連付けます。

19.5 Essbaseモデルの作成およびリバース・エンジニアリング

この項には次のトピックが含まれます:

- Essbaseモデルの作成

- Essbaseモデルのリバース・エンジニアリング

19.5.1 Essbaseモデルの作成

『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のモデルの作成に関する項に記載されている標準の手順で、Essbaseモデルを作成します。

19.5.2 Essbaseモデルのリバース・エンジニアリング

Essbaseアプリケーションをリバース・エンジニアリングすると、アプリケーション内の各ディメンション用データストアおよびデータ用データストアを含む、Oracle Data Integratorモデルが作成されます。

RKMを使用して、Hyperion Essbaseでカスタマイズされたリバース・エンジニアリングを実行するには、『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のモデルのリバース・エンジニアリングに関する項に記載されている通常の手順を行います。この項では、Hyperion Essbaseテクノロジ固有のフィールドのみについて説明します。

1. Essbaseモデルの「リバース」タブでRKM Hyperion Essbaseを選択します。

2. 表19-2に示されているKMオプションを設定します。

表19-2 RKM Hyperion Essbaseのオプション

オプション

使用できる値

説明

MULTIPLE_DATA_COLUMNS

- いいえ(デフォルト)

- はい

このオプションがNoに設定されている場合、データ抽出/ロード・モデル用に作成されるデータストアには、標準ディメンションごとに1つの列、および単一のデータ列が含まれます。このオプションがYesに設定されている場合、データ抽出/ロード・モデル用に作成されるデータストアには、DATA_COLUMN_DIMENSIONオプションで指定されたディメンションを除く標準ディメンションごとに1つの列、およびDATA_COLUMN_MEMBERSオプションに対してカンマ区切りのリストで指定された数のデータ列が含まれます。

DATA_COLUMN_DIMENSION

Account

このオプションは、MULTIPLE_DATA_COLUMNSがYesに設定されている場合のみ適用されます。

データ列ディメンション名を指定します。たとえば、データ列はディメンションAccountまたはTimeなどに分散しています。

DATA_COLUMN_MEMBERS

Account

このオプションは、MULTIPLE_DATA_COLUMNSがYesに設定されている場合のみ適用されます。

必要なデータ列メンバーをカンマ(,)で区切ります。

たとえば、データ列ディメンションがAccountで、メンバーがSales,COGSに設定されている場合、データ抽出/ロード用データストアには、そのデータ列ディメンションを除く各ディメンションに対して1つの列、およびカンマ区切りの値で指定されたデータ列メンバーごとに1つの列が含まれます。次に例を示します。EssbaseアプリケーションにディメンションAccount、Scenario、Product、MarketおよびYearがあり、データ列ディメンションがAccountおよびデータ列メンバーがSales, COGSと指定されている場合、データストアには次の列が含まれます。

- Scenario(文字列)

- Product(文字列)

- Market(文字列)Year(文字列)

- Sales(数値)

- COGS(数値)

EXTRACT_ATTRIBUTE_MEMBERS

- いいえ(デフォルト)

- はい

このオプションがNoに設定されている場合、データ抽出/ロード・モデル用に作成されるデータストアには、標準ディメンションごとに1つの列、および単一のデータ列が含まれます。属性ディメンションは含まれません。

このオプションがYesに設定されている場合、データ・モデルには次の列が含まれます。

- それぞれの標準ディメンションに対して1つの列が作成されます。

- MULTIPLE_DATA_COLUMNオプションの値に応じて、1つ以上のデータ列が作成されます。

- 関連付けられているそれぞれの属性ディメンションに対して1つの列が作成されます。

RKMは、(論理スキーマおよびコンテキストによって特定される)アプリケーションに接続し、アプリケーションのディメンションに従ってこれらのデータストアの一部またはすべてをインポートします。

19.6 マッピングの設計

Essbaseアプリケーションをモデルとしてリバース・エンジニアリングした後、このモデル内のデータストアを次として使用できます。

- データおよびメタデータをアプリケーションにロードするためのマッピングのターゲット

- メタデータおよびデータをアプリケーションから抽出するためのマッピングのソース

マッピング用に選択したKMによって、このマッピングの機能およびパフォーマンスが決まります。この項に示す推奨事項は、Hyperion Essbaseに関連する様々な状況でのKMの選択に役立ちます。

この項には次のトピックが含まれます:

- メタデータのロード

- データのロード

- データの抽出

19.6.1 メタデータのロード

Oracle Data Integratorには、EssbaseアプリケーションにメタデータをロードするためのIKM SQL to Hyperion Essbase (METADATA)が用意されています。

メタデータはディメンションのメンバーで構成されます。メンバーのデータ値をロードする前に、メンバー(つまりメタデータ)をロードする必要があります。

メンバーのロード先として使用できるのは、Essbaseに存在するディメンションのみです。ロードするディメンションごとに、別個のマッピングを使用する必要があります。マッピングを結合すると、複数のディメンションに一度にメタデータをロードできます。

1. 注意:
列の追加または削除によってメタデータ・データストアを変更して、メタデータ・ロードの実行に使用されるディメンション作成ルールと一致させることもできます。たとえば、デフォルト・データストアにParentNameおよびChildNameの列が含まれており、使用するルールが世代別ディメンション作成ルールの場合、メタデータ・データストアを変更して世代別ディメンション作成ルール内の列と一致させることができます。サンプル内のloadMarketsマッピングは、世代別ディメンション作成ルールを使用したメタデータ・ロードの実行例です。

表19-3に、IKM SQL to Hyperion Essbase (METADATA)のオプションをリストします。これらのオプションにより、アダプタによるEssbaseアプリケーションへのメタデータのロード方法が定義されます。

表19-3 IKM SQL to Hyperion Essbase (METADATA)のオプション

オプション

値

説明

RULES_FILE

空白(デフォルト)

メタデータをロードまたは作成するためのルール・ファイルを指定します。ルール・ファイルがEssbaseサーバー上にある場合はファイル名のみを指定しますが、それ以外の場合はOracle Data Integratorエージェントに対する完全修飾ファイル名を指定します。

RULE_SEPARATOR

,(デフォルト)

(オプション)ルール・ファイルのルール・セパレータを指定します。

有効な値は次のとおりです。

- カンマ

- タブ

- スペース

- カスタム文字(例: @、#、^)

RESTRUCTURE_DATABASE

- KEEP_ALL_DATA(デフォルト)

- KEEP_INPUT_DATA

- KEEP_LEVEL0_DATA

- DISCARD_ALL_DATA

Essbaseキューブにメタデータをロードした後、データベースを再構築します。

有効な値は次のとおりです。

- KEEP_ALL_DATA(すべてのデータを保持)

- KEEP_INPUT_DATA(入力データのみを保持)

- KEEP_LEVEL0_DATA(レベル0のデータのみを保持)

- DISCARD_ALL_DATA(すべてのデータを破棄)

注意: このオプションは、Essbaseリリース9.3以上に適用されます。Essbaseリリース9.3より前のリリースでは、このオプションは無視されます。

PRE_LOAD_MAXL_SCRIPT

空白(デフォルト)

Essbaseキューブにメタデータをロードする前にMAXLスクリプトを実行する場合は、このオプションを有効にします。

MAXLスクリプト・ファイルの完全修飾パス名を(空白を含めずに)指定します。

注意: このオプションを正常に実行するには、Oracle Data Integratorエージェントが稼働するマシンにEssbaseクライアントをインストールして構成する必要があります。

POST_LOAD_MAXL_SCRIPT

空白(デフォルト)

Essbaseキューブにメタデータをロードした後にMAXLスクリプトを実行する場合は、このオプションを有効にします。

MAXLスクリプト・ファイルの完全修飾パス名を(空白を含めずに)指定します。

注意: このオプションを正常に実行するには、Oracle Data Integratorエージェントが稼働するマシンにEssbaseクライアントをインストールして構成する必要があります。

ABORT_ON_PRE_MAXL_ERROR

- いいえ(デフォルト)

- はい

このオプションは、PRE_LOAD_MAXL_SCRIPTオプションを有効にした場合のみ適用されます。

ABORT_ON_PRE_MAXL_ERRORオプションをYesに設定すると、ロード前のMAXLスクリプトの実行中にエラーが発生した場合には、ロード・プロセスが中断されます。

LOG_ENABLED

- いいえ(デフォルト)

- はい

このオプションをYesに設定すると、IKMプロセスの中でLOG_FILE_NAMEオプションで指定したファイルへのロギングが行われます。

LOG_FILE_NAME

<?=java.lang.System.getProperty ("java.io.tmpdir")?>/Extract_<% =snpRef.getFrom()%>.log(デフォルト)

IKMプロセスのイベントを記録するファイル名を指定します。

ERROR_LOG_FILENAME

<?=java.lang.System.getProperty ("java.io.tmpdir")?>/Extract_<% =snpRef.getFrom()%>.log(デフォルト)

IKMプロセスのエラー・レコードを記録するファイル名を指定します。

19.6.2 データのロード

Oracle Data Integratorには、EssbaseアプリケーションにデータをロードするためのIKM SQL to Hyperion Essbase (DATA)が用意されています。

Essbaseで作成済の、選択したディメンション・メンバーにデータをロードできます。データ・ロードを正常に行うには、標準のディメンション・メンバーすべてが必要であり、これらが有効なメンバーである必要があります。Essbaseアプリケーションにデータをロードするには、あらかじめEssbaseアプリケーションを設定しておく必要があります。

カスタム・ターゲットを作成してロード・ルールと一致させることもできます。

データをロードする前に、メンバー(メタデータ)がEssbaseディメンション内に存在することを確認してください。メンバーが欠落しているレコードのデータ・ロードは失敗し、(ロギングが有効な場合は)その情報がエラー・レコードとして記録され、データ・ロード・プロセスは最大エラーしきい値に達するまで続行されます。

注意:
列の追加または削除によってデータ・データストアを変更して、データ・ロードの実行に使用されるデータ・ロード・ルールと一致させることもできます。

表19-4に、IKM SQL to Hyperion Essbase (DATA)のオプションをリストします。これらのオプションにより、アダプタによるEssbaseアプリケーションへのデータのロードおよび統合の方法が定義されます。

表19-4 IKM SQL to Hyperion Essbase (DATA)

オプション

値

説明

RULES_FILE

空白(デフォルト)

(オプション)データ・ロードのパフォーマンスを強化するルール・ファイルを指定します。

ルール・ファイルがEssbaseサーバー上にない場合は、完全修飾ファイル名を指定します。

ルール・ファイル・オプションが指定されていない場合は、APIベースのデータ・ロードが使用されます。ただし、APIは指定できません。

RULE_SEPARATOR

,(デフォルト)

(オプション)ルール・ファイルのルール・セパレータを指定します。

有効な値は次のとおりです。

- カンマ

- タブ

- スペース

- カスタム文字(例: @、#、^)

GROUP_ID

整数

複数のデータ・ロードをパラレル実行する場合は、多数のマッピングで同じGROUP_IDが使用されるように設定できます。このGROUP_IDはパラレル・ロードの管理に使用され、これによって、GROUP_IDの最終マッピングの完了時にデータ・ロードをコミットすることができます。パラレルASOキューブへのロードの詳細は、Essbaseデータベース管理者ガイドを参照してください。

BUFFER_ID

1–1000000

1つの集計記憶域データベースに複数のデータ・ロード・バッファを配置できます。時間を節約するために、同時に複数のデータ・ロード・バッファにデータをロードできます。アクティブにできるデータベースのデータ・ロード・コミット操作は常に1つのみですが、複数のデータ・ロード・バッファを同じコミット操作でコミットでき、この処理はバッファを個別にコミットするより高速です。パラレルASOキューブへのロードの詳細は、Essbaseデータベース管理者ガイドを参照してください。

BUFFER_SIZE

0-100

Essbaseでは、増分データ・ロードの実行時に集計記憶域キャッシュを使用してデータをソートします。

データ。データ・ロード・バッファが使用できるキャッシュの割合は、パーセンテージ(0から100%)を指定して制御できます。デフォルトでは、データ・ロード・バッファのリソース使用量が100に設定されているため、データベースに作成されたすべてのデータ・ロード・バッファの合計リソース使用量を100以下にする必要があります。たとえば、使用量が90のバッファがある場合は、10より大きいサイズの別のバッファを作成できません。値が0の場合は、Essbaseによって自己決定されるデフォルトのロード・バッファ・サイズが使用されます。

バッファ・サイズ。

CLEAR_DATABASE

- なし(デフォルト)

- すべて

- Upper Blocks

- Non-Input Blocks

Essbaseキューブにデータをロードする前にEssbaseキューブからデータを消去する場合は、このオプションを有効にします。

有効な値は次のとおりです。

- None: データベースの消去は行われません。

- All: すべてのデータ・ブロックの入力データが消去されます。

- Upper Blocks: 統合されたすべてのレベル・ブロックが消去されます。

- Non-Input Blocks: 計算から導出された値を含むブロックが消去されます。

注意: ASOアプリケーションの場合、Upper BlocksおよびNon-Input Blocksオプションは適用されません。

CALCULATION_SCRIPT

空白(デフォルト)

(オプション)Essbaseキューブにデータをロードした後に実行する計算スクリプトを指定します。

計算スクリプトがEssbaseサーバー上にない場合は、完全修飾ファイル名を指定します。

RUN_CALC_SCRIPT_ONLY

- いいえ(デフォルト)

- はい

このオプションは、CALCULATION_SCRIPTオプションで計算スクリプトを指定した場合のみ適用されます。

RUN_CALC_SCRIPT_ONLYオプションをYesに設定した場合は、計算スクリプトのみが実行され、ターゲットEssbaseキューブにデータはロードされません。

PRE_LOAD_MAXL_SCRIPT

空白(デフォルト)

Essbaseキューブにデータをロードする前にMAXLスクリプトを実行する場合は、このオプションを有効にします。

MAXLスクリプト・ファイルの完全修飾パス名を(空白を含めずに)指定します。

注意: Oracle Data Integratorエージェントを実行するマシンにEssbaseクライアントをインストールして構成する必要があります。

POST_LOAD_MAXL_SCRIPT

空白(デフォルト)

Essbaseキューブにデータをロードした後にMAXLスクリプトを実行する場合は、このオプションを有効にします。

MAXLスクリプト・ファイルの完全修飾パス名を(空白を含めずに)指定します。

注意: Oracle Data Integratorエージェントを実行するマシンにEssbaseクライアントをインストールして構成する必要があります。

ABORT_ON_PRE_MAXL_ERROR

- いいえ(デフォルト)

- はい

このオプションは、PRE_LOAD_MAXL_SCRIPTオプションを有効にした場合のみ適用されます。

ABORT_ON_PRE_MAXL_ERRORオプションをYesに設定すると、ロード前のMAXLスクリプトの実行中にエラーが発生した場合には、ロード・プロセスが中断されます。

MAXIMUM_ERRORS_ALLOWED

1(デフォルト)

設定したエラーの最大数に基づいてデータ・ロードを停止するには、このオプションを有効にします。

このオプションで指定する値は、データ・ロード・プロセス中に許容されるエラー・レコード数のしきい値です。このしきい値に達すると、データ・ロード・プロセスは中断します。たとえば、デフォルト値1は、1つのエラー・レコードが検出された時点でデータ・ロード・プロセスが停止することを意味します。値として5を指定した場合は、5つ目のエラー・レコードが検出された時点でデータ・ロード・プロセスが停止します。値として0(無限大)を指定した場合は、エラー・レコードが検出されてもデータ・ロード・プロセスは続行します。

COMMIT_INTERVAL

1000(デフォルト)

コミット間隔は、完全なバッチでEssbaseキューブにロードされるレコードのチャンク・サイズです。

Essbaseキューブ内のレコードのコミット間隔を設定するには、このオプションを有効にします。

コミット間隔を変更すると、Essbaseデータベースの設計に基づくデータ・ロードのパフォーマンスを向上させることができます。

LOG_ENABLED

- いいえ(デフォルト)

- はい

このオプションをYesに設定すると、IKMプロセスの実行中に、LOG_FILENAMEオプションで指定したファイルへのロギングが行われます。

LOG_FILENAME

<?=java.lang.System.getProperty("java.io.tmpdir")?/<%=snpRef.getTargetTable("RES_NAME")%>.log (デフォルト)

IKMプロセスのイベントを記録するファイル名を指定します。

LOG_ERRORS

- いいえ(デフォルト)

- はい

このオプションをYesに設定すると、IKMプロセスの実行中に、ERROR_LOG_FILENAMEオプションで指定したファイルにエラー・レコードの詳細が記録されます。

ERROR_LOG_FILENAME

<?=java.lang.System.getProperty(java.io.tmpdir")?>/<%=snpRef.getTargetTable("RES_NAME")%>.err

IKMプロセスのエラー・レコード詳細を記録するファイル名を指定します。

ERR_LOG_HEADER_ROW

- いいえ(デフォルト)

- はい

このオプションをYesに設定すると、列名を含むヘッダー行がエラー・レコード・ファイルに記録されます。

ERR_COL_DELIMITER

,(デフォルト)

エラー・レコード・ファイルに使用する列デリミタを指定します。

ERR_ROW_DELIMITER

\r\n(デフォルト)

エラー・レコード・ファイルに使用する行デリミタを指定します。

ERR_TEXT_DELIMITER

'(デフォルト)

エラー・レコード・ファイル内の列データに使用するテキスト・デリミタを指定します。

たとえば、テキスト・デリミタを二重引用符(")に設定した場合は、エラー・レコード・ファイル内のすべての列が二重引用符で区切られます。

19.6.3 データの抽出

この項には次のトピックが含まれます:

- Essbaseのデータ抽出方法

- Essbaseデータの抽出

- メタデータからのメンバーの抽出

19.6.3.1 Essbaseのデータ抽出方法

Oracle Data Integrator Adapter for Essbaseでは、データ抽出のための問合せおよびスクリプトがサポートされます。一般的な手順でデータを抽出するには、抽出問合せを作成してアダプタに提供します。アダプタによって抽出問合せの出力が解析されてステージング領域に移入される前に、列の検証が実行されます。検証時のメタデータ出力問合せの結果に基づいて、アダプタによって抽出問合せが実行されます。アダプタによって実際に出力問合せが解析されるのは、列の検証結果が正常な場合のみです。

抽出の完了後、結果を検証します。抽出問合せによってすべての出力列のデータが抽出されたことを確認してください。

Essbaseでサポートされている次の問合せおよびスクリプトを使用して、データを抽出できます。

- レポート・スクリプトを使用したデータ抽出

- MDX問合せを使用したデータ抽出

- 計算スクリプトを使用したデータ抽出

レポート・スクリプトを使用したデータ抽出

レポート・スクリプトによって生成されたレポートを解析することで、データを抽出できます。レポート・スクリプトは、(Oracle Data Integratorが実行される)クライアント・コンピュータおよび(Essbaseが実行される)サーバー上に配置できます。レポート・スクリプトを使用してデータを抽出した場合、列の検証は実行されません。そのため、レポート・スクリプトの出力列は、ソース・モデル内の対応する関連列に直接マップされます。ただし、レポート・スクリプトを使用してデータ抽出を開始する前に、次のタスクを完了しておく必要があります。

- レポート・スクリプトのすべての書式設定を抑制します。レポート・スクリプトの最初の行として、{ROWREPEAT SUPHEADING SUPFORMAT SUPBRACKETS SUPFEED SUPCOMMAS NOINDENTGEN TABDELIMIT DECIMAL 15}という行を挿入します。

- レポート・スクリプトによって生成される列の数は、ソース・モデルの関連する列数以上であることが必要です。

- LKMオプションで列デリミタ値を設定する必要があります。

MDX問合せを使用したデータ抽出

MDX問合せは、XMLベースのデータ抽出メカニズムです。MDX問合せを指定して、Essbaseアプリケーションからデータを抽出できます。ただし、MDX問合せを使用してデータ抽出を開始する前に、次のタスクを完了しておく必要があります。

- ディメンション列の名前をEssbaseキューブのディメンションと一致させる必要があります。

- タイプ1のデータ抽出の場合、データ列のすべての名前が単一の標準ディメンションの有効なメンバーであることが必要です。

- タイプ1のデータ抽出の場合、データ・ディメンションを下位レベルの軸、つまり列の軸(0)に配置することをお薦めします。最下位レベルの軸に指定されていない場合、メモリー使用率が高くなります。

- 列がソース・モデルの対応する属性ディメンションに関連付けられている場合は、MDX問合せでも同じ属性ディメンションを選択する必要があります。

- MDX問合せのスクリプトは、クライアント・コンピュータまたはサーバー上に配置できます。

計算スクリプトを使用したデータ抽出

計算スクリプトでは、Essbaseアプリケーションからより速くデータを抽出するためのオプションが提供されます。ただし、計算スクリプトを使用してデータを抽出するには、次の制限に注意する必要があります。

- 計算スクリプトを使用したデータ抽出は、BSOアプリケーションのみでサポートされます。

- 計算スクリプトを使用したデータ抽出は、Essbaseリリース9.3以上のみでサポートされます。

- DataExportDimHeaderオプションをONに設定します。

- DataExportColHeaderを使用する場合は、このオプションの設定をデータ列ディメンションと一致させます(複数のデータ列を抽出する場合)。

- データの抽出に使用するOracle Data Integratorエージェントを、Essbaseサーバーと同じマシン上で実行する必要があります。

- クライアント・コンピュータ上の計算スクリプトにアクセスする場合は、ファイルの完全修飾パス(C:\Essbase_Samples\Calc_Scripts \calcall.cscなど)を指定する必要があります。一方、サーバー上の計算スクリプトにアクセスする場合は、ファイル名のみで構いません。

19.6.3.2 Essbaseデータの抽出

Oracle Data Integratorには、Essbaseアプリケーションからデータを抽出するためのLKM Hyperion Essbase DATA to SQLが用意されています。

Essbase内の選択されたディメンション・メンバーのデータを抽出できます。Essbaseアプリケーションからデータを抽出するには、あらかじめEssbaseアプリケーションを設定しておく必要があります。

表19-5に、LKM Hyperion Essbase Data to SQLのオプションをリストします。これらのオプションにより、Oracle Data Integrator Adapter for Essbaseによるデータの抽出方法が定義されます。

表19-5 LKM Hyperion Essbase DATA to SQLのオプション

オプション

値

説明

PRE_CALCULATION_SCRIPT

空白(デフォルト)

(オプション)Essbaseキューブからデータを抽出する前に実行する計算スクリプトを指定します。

EXTRACTION_QUERY_TYPE

- ReportScript(デフォルト)

- MDXQuery

- CalcScript

抽出問合せのタイプ(レポート・スクリプト、MDX問合せまたは計算スクリプト)を指定します。

出力列に入力されるすべてのデータをフェッチする、有効な抽出問合せを指定してください。

最初のレコード(計算スクリプトの場合は最初の2つのレコード)には、抽出されるデータのメタ情報が含まれます。

EXTRACTION_QUERY_FILE

空白(デフォルト)

抽出問合せの完全修飾ファイル名を指定します。

EXT_COL_DELIMITER

\t(デフォルト)

抽出問合せの列デリミタを指定します。

このオプションに値を指定しなかった場合は、列デリミタとしてスペース(" ")が使用されます。

EXTRACT_DATA_FILE_IN_CALC_SCRIPT

空白(デフォルト)

このオプションは、EXTRACTION_QUERY_TYPEオプションで問合せタイプとしてCalcScriptを指定した場合のみ適用されます。

計算スクリプトによってデータが抽出される、完全修飾されたファイルの場所を指定します。

PRE_EXTRACT_MAXL

空白(デフォルト)

Essbaseキューブからデータを抽出する前にMAXLスクリプトを実行する場合は、このオプションを有効にします。

POST_EXTRACT_MAXL

空白(デフォルト)

Essbaseキューブからデータを抽出した後にMAXLスクリプトを実行する場合は、このオプションを有効にします。

ABORT_ON_PRE_MAXL_ERROR

- いいえ(デフォルト)

- はい

このオプションは、PRE_EXTRACT_MAXLオプションを有効にした場合のみ適用されます。

ABORT_ON_PRE_MAXL_ERRORオプションをYesに設定すると、抽出前のMAXLスクリプトの実行中にエラーが発生した場合には、ロード・プロセスが中断されます。

LOG_ENABLED

- いいえ(デフォルト)

- はい

このオプションをYesに設定すると、LKMプロセスの実行中に、LOG_FILE_NAMEオプションで指定したファイルへのロギングが行われます。

LOG_FILENAME

<?=java.lang.System.getProperty ("java.io.tmpdir")?/<% =snpRef.getTargetTable("RES_NAME")%>.log (デフォルト)

LKMプロセスのイベントを記録するファイル名を指定します。

MAXIMUM_ERRORS_ALLOWED

1(デフォルト)

設定したエラーの最大数に基づいて抽出を停止するには、このオプションを有効にします。

LOG_ERRORS

- いいえ(デフォルト)

- はい

このオプションをYesに設定すると、LKMプロセスの実行中に、ERROR_LOG_FILENAMEオプションで指定したファイルにエラー・レコードの詳細が記録されます。

ERROR_LOG_FILENAME

<?=java.lang.System.getProperty(java.io.tmpdir")?>/<%=snpRef.getTargetTable("RES_NAME")%>.err

LKMプロセスのエラー・レコード詳細を記録するファイル名を指定します。

ERR_LOG_HEADER_ROW

- いいえ(デフォルト)

- はい

このオプションをYesに設定すると、列名を含むヘッダー行がエラー・レコード・ファイルに記録されます。

ERR_COL_DELIMITER

,(デフォルト)

エラー・レコード・ファイルに使用する列デリミタを指定します。

ERR_ROW_DELIMITER

\r\n(デフォルト)

エラー・レコード・ファイルに使用する行デリミタを指定します。

ERR_TEXT_DELIMITER

'(デフォルト)

エラー・レコード・ファイル内の列データに使用するテキスト・デリミタを指定します。

たとえば、テキスト・デリミタを二重引用符(")に設定した場合は、エラー・レコード・ファイル内のすべての列が二重引用符で区切られます。

DELETE_TEMPORARY_OBJECTS

- いいえ(デフォルト)

- はい

一時オブジェクト(表、ファイルおよびスクリプト)を統合後に保持するには、このオプションをNOに設定します。

このオプションはデバッグに便利です。

19.6.3.3 メタデータからのメンバーの抽出

Oracle Data Integratorには、Essbaseアプリケーション内のディメンションからメンバーを抽出するためのLKM Hyperion Essbase METADATA to SQLが用意されています。

Essbaseアプリケーションで選択されたディメンションからメンバーを抽出するには、あらかじめEssbaseアプリケーションを設定してメタデータをロードしておく必要があります。ディメンションからメンバーを抽出する前に、そのディメンションがEssbaseデータベース内に存在することを確認してください。最上位メンバーがディメンションに含まれていない場合、レコードは一切抽出されません。

表19-6に、LKM Hyperion Essbase METADATA to SQLのオプションをリストします。これらのオプションにより、Oracle Data Integrator Adapter for Oracle Hyperion Essbaseによるディメンション・メンバーの抽出方法が定義されます。

表19-6 LKM Hyperion Essbase METADATA to SQL

オプション

値

説明

MEMBER_FILTER_CRITERIA

IDescendants(デフォルト)

抽出するメンバーをディメンション階層から選択するには、このオプションを有効にします。次の選択基準を指定できます。

- IDescendants

- Descendants

- IChildren

- Children

- Member_Only

- Level0

- UDA

MEMBER_FILTER_VALUE

空白(デフォルト)

指定されたフィルタ基準を適用するメンバーの名前を指定するには、このオプションを有効にします。メンバーを指定しない場合、フィルタ基準はルート・ディメンション・メンバーに適用されます。MEMBER_FILTER_CRITERIA値がMEMBER_ONLYまたはUDAである場合、MEMBER_FILTER_VALUEオプションは必須であり、空の文字列にできません。

LOG_ENABLED

- いいえ(デフォルト)

- はい

このオプションをYesに設定すると、LKMプロセスの実行中に、LOG_FILE_NAMEオプションで指定したファイルへのロギングが行われます。

LOG_FILE_NAME

<?=java.lang.System.getProperty(java.io.tmpdir")?>/Extract_<%=snpRef.getFrom()%>.log

LKMプロセスのイベントを記録するファイル名を指定します。

MAXIMUM_ERRORS_ALLOWED

1(デフォルト)

設定したエラーの最大数に基づいて抽出を停止するには、このオプションを有効にします。

LOG_ERRORS

- いいえ(デフォルト)

- はい

このオプションをYesに設定すると、LKMプロセスの実行中に、ERROR_LOG_FILENAMEオプションで指定したファイルにエラー・レコードの詳細が記録されます。

ERROR_LOG_FILENAME

<?=java.lang.System.getProperty(java.io.tmpdir")?>/Extract_<%=snpRef.getFrom()%>.err

LKMプロセスのエラー・レコード詳細を記録するファイル名を指定します。

ERR_LOG_HEADER_ROW

- いいえ(デフォルト)

- はい

このオプションをYesに設定すると、列名を含むヘッダー行がエラー・レコード・ファイルに記録されます。

ERR_COL_DELIMITER

,(デフォルト)

エラー・レコード・ファイルに使用する列デリミタを指定します。

ERR_ROW_DELIMITER

\r\n(デフォルト)

エラー・レコード・ファイルに使用する行デリミタを指定します。

ERR_TEXT_DELIMITER

- 空白(デフォルト)

- \"

- \"

エラー・レコード・ファイル内のデータ列に使用するテキスト・デリミタを指定します。たとえば、テキスト・デリミタを二重引用符(")に設定した場合は、エラー・レコード・ファイル内のすべての列が二重引用符で区切られます。

DELETE_TEMPORARY_OBJECTS

- いいえ(デフォルト)

- はい

一時オブジェクト(表、ファイルおよびスクリプト)を統合後に保持するには、このオプションをNOに設定します。

このオプションはデバッグに便利です。

第III部

その他のテクノロジ

この部では、Oracle Data Integratorでのその他のテクノロジの使用方法について説明します。

第III部の内容は次のとおりです。

- 第20章「JMS」

- 第21章「JMS XML」

- 第22章「LDAPディレクトリ」

- 第23章「Oracle TimesTen In-Memory Database」

- 第24章「Oracle GoldenGate」

- 第25章「Oracle SOA Suite相互参照」

20 JMS

この章では、Oracle Data IntegratorでのJava Message Services (JMS)の使用方法について説明します。

この章には次の項が含まれます:

- 20.1項「はじめに」

- 20.2項「インストールおよび構成」

- 20.3項「トポロジの設定」

- 20.4項「統合プロジェクトの設定」

- 20.5項「JMSモデルの作成および定義」

- 20.6項「マッピングの設計」

- 20.7項「JMS標準プロパティ」

20.1 はじめに

Oracle Data Integratorには、JMS宛先を統合するための、単純で透過的な方法が用意されています。この章では、テキスト・ペイロードを使用するJMSメッセージのバッチ・モードでの処理について説明します。XMLペイロードの処理の説明は、第21章「JMS XML」を参照してください。

20.1.1 概念

JMSナレッジ・モジュールは、最も一般的なJMS準拠のミドルウェア(Oracle Service Bus、Sonic MQなど)に適用されます。これらのほとんどのナレッジ・モジュールには、メッセージを確実に配信するためのトランザクション処理が含まれます。

20.1.1.1 JMSメッセージの構造

この項では、JMS宛先のメッセージの構造を説明します。

JMSメッセージは次の3つのセクションで構成されます。

- ヘッダー

- プロパティ

- ペイロード

ヘッダー

ヘッダーのヘッダー・フィールドには、メッセージ関連の標準メタデータが含まれます。標準メタデータには、宛先(JMSDestination)メッセージID (JMSMessageID)メッセージ・タイプ(JMSType)などがあります。

プロパティ

プロパティ・セクションには、メッセージ関連の追加のメタデータが含まれます。これらのメタデータはプロパティであり、次の3つのグループに分けられます。

- オプションのJMSヘッダーであるJMS定義のプロパティ。名前の先頭にJMSXが付きます(JMSXUserID、JMSXAppIDなど)。

- プロバイダ固有のプロパティ。ルーター・ベンダー固有のプロパティです。名前の先頭にJMS_<vendor name>が付きます。

- アプリケーション固有のプロパティ。これらのプロパティは、メッセージを送信するアプリケーションに依存します。メッセージ・ペイロードに含まれないユーザー定義の情報です。

ヘッダー・セクションおよびプロパティ・セクションでは、次のような一連のヘッダー・フィールドおよびプロパティが提供されます。

- 固有のJavaデータ型(boolean、string、shortなど)が指定されている。

- アクセスして読取りまたは書込み(もしくはその両方)を行える。

- JMSセレクタを介してルーター上でフィルタリングするために使用できる。

ペイロード

ペイロード・セクションにはメッセージの内容が含まれます。この内容は、テキスト、XML、バイナリなど、何でも構いません。

20.1.1.2 JMS宛先の使用

Oracle Data Integratorでは、JMS宛先によって配信されるJMSテキストおよびバイト・メッセージの処理が可能です。各メッセージはデータ行のコンテナとして扱われ、JMSキューまたはJMSトピック・テクノロジを介して処理されます。

JMSキューまたはJMSトピック・テクノロジでは、各JMS宛先がフラット・ファイル・データストアと同様に定義されます。宛先内の各メッセージは、データストアのレコードです。

トポロジでは、単一の物理スキーマを使用して、各JMSルーターがJMSトピックまたはキューのデータ・サーバーとして定義されます。つまり、1つのデータ・サーバーを使用してトピックにアクセスし、別のデータ・サーバーを使用してキューにアクセスするために、JMSルーターは2回定義される可能性があります。

各JMS宛先(トピックまたはキュー)は、リソース名がJMS宛先の名前(ルーターで定義されたキューまたはトピックの名前)と一致する、JMSデータストアとして定義されます。モデルによって、異なるトピックまたはキューに関連するメッセージ構造がグループ化されます。

JMSデータストア構造は、同様にフラット・ファイル(デリミタ付きまたは固定幅)に定義されます。メッセージのプロパティまたはヘッダー・フィールドは、JMS固有のデータ型を使用して、このフラット・ファイル構造内で追加の擬似列として宣言できます。宛先内の各メッセージは、JMSデータストアのレコードとして処理されます。

メッセージの処理

JMS宛先は通常のファイル・データストアとして、また、メッセージはこれらのデータストアの行として処理されます。これらのテクノロジにより、メッセージ・セット全体が生成され、各マッピング内で消費されます。

メッセージのパブリッシュおよび消費には、JMS宛先からのメッセージの削除またはJMS宛先へのメッセージのポストをファイナライズするためのコミットアクションが必要です。コミットは、特に、読取り時に重要です。コミットしない場合、メッセージは読み取られますが、消費されません。JMSトピック/キューに残り、後で再度読み取られます。

メッセージの内容および擬似列はどちらも、マッピング内で通常の(マッピング、フィルタなどの)属性として使用できます。一部の擬似列(MESSAGE_IDプロパティを表す擬似列など)は読取り専用であり、ヘッダー・フィールドの一部のプロパティはナレッジ・モジュール・オプションを介して使用(または設定)されます。

Data Integratorでは、メッセージ・ペイロード(属性)として、またはアプリケーション・プロパティなどのプロパティ(擬似列)を介して、情報を転送できます。

プロパティを使用した情報伝達は、メッセージを生成または消費するサード・パーティ・アプリケーションによって制限されます。

メッセージのフィルタリング

次の2つの方法で、JMS宛先のメッセージをフィルタ処理できます。

- データストアの属性および擬似列を使用して、フィルタを定義する。この場合、メッセージの消費後に、Data Integratorによってフィルタリング操作が実行されます。これは、このフィルタで拒否されるメッセージも消費される可能性があることを意味します。

- メッセージ・セレクタ(MESSAGE_SELECTOR KMオプション)を定義する。このタイプのフィルタでは、メッセージのプロパティまたはヘッダー・フィールドのみを使用できます。このフィルタはルーターによって処理され、フィルタ条件を満たすメッセージのみが消費されるため、転送されるメッセージの数が削減されます。

20.1.2 ナレッジ・モジュール

Oracle Data Integratorには、表20-1に示されている、JMSメッセージを処理するためのナレッジ・モジュール(KM)が用意されています。

表20-1 JMSナレッジ・モジュール

ナレッジ・モジュール

説明

IKM SQL to JMS Append

任意のSQL準拠ステージング領域からJMS準拠のメッセージのキューまたはトピックへ、テキストまたはバイナリ形式でデータを統合します。

データを変換してターゲットのJMSキューまたはトピックにエクスポートする場合は、このIKMの使用を検討してください。ほとんどのソース・データストアが同じデータ・サーバー上にある場合は、余分なロード・フェーズ(LKM)を発生させないために、このデータ・サーバーをステージング領域として使用することをお薦めします。

このIKMを使用するには、ステージング領域がターゲットと異なる必要があります。

LKM JMS to SQL

テキストまたはバイナリのJMS準拠メッセージのキューまたはトピックから、ステージング領域として使用される任意のSQL準拠データベースへ、データをロードします。エージェントを使用してソース・キュー/トピックから選択されたメッセージを読み取り、動的に作成された一時ステージング表に結果を書き込みます。

メッセージを確実に配信するために、メッセージのコンシューマ(またはサブスクライバ)は、IKMによってデータが実際にターゲットに統合されるまで、読取りをコミットしません。

ソース・データストアの1つがテキストまたはバイナリのJMSメッセージの場合は、このLKMの使用を検討してください。

20.2 インストールおよび構成

JMSナレッジ・モジュールの使用を開始する前に、この項の情報を必ず読んでください。

- システム要件および動作要件

- テクノロジ固有の要件

- 接続性要件

20.2.1 システム要件および動作要件

インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。

サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。

http://www.oracle.com/technology/products/oracle-data-integrator/index.html

20.2.2 テクノロジ固有の要件

JMS宛先へのアクセスは、通常、JNDIサービス経由で行われます。JNDIおよびJMSの構成および固有の要件は、接続先のJMSプロバイダによって異なります。詳細は、JMSプロバイダ固有のドキュメントを参照してください。

20.2.3 接続性要件

Oracle Data Integratorには、JMSプロバイダ専用のドライバは含まれていません。このプロバイダの接続性要件は、JMSプロバイダのドキュメントを参照してください。

20.3 トポロジの設定

トポロジの設定には次が含まれます。

1. JMSデータ・サーバーの作成

2. JMS物理スキーマの作成

20.3.1 JMSデータ・サーバーの作成

各JMSデータ・サーバーは、ローカル・ネットワーク経由でアクセス可能な1つのJMSプロバイダまたはルーターに対応します。

JMSデータ・サーバーにはJMSキューとJMSトピックの2タイプがあります。

- JMSキュー・データ・サーバーは、JMSルーター内の複数のキューへのアクセスに使用されます。

- JMSトピック・データ・サーバーは、JMSルーター内の複数のトピックへのアクセスに使用されます。

20.3.1.1 データ・サーバーの作成

『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のデータ・サーバーの作成に関する項に記載されている標準の手順で、JMSキュー・テクノロジまたはJMSトピック・テクノロジ用のデータ・サーバーを作成します。この項では、JMSキューまたはJMSトピック・データ・サーバーの定義に関する必須または固有のフィールドのみについて説明します。

1. 「定義」タブ:

- 名前: Oracle Data Integratorに表示されるデータ・サーバーの名前。

- ユーザー/パスワード: ここでは使用しません。これらのフィールドは空のままにします。

2. 「JNDI」タブ:

- JNDI認証: このフィールドをNoneに設定します。

- JNDIユーザー: JNDIディレクトリに接続するためのユーザー名を入力します(オプションの手順)。

- パスワード: このユーザーのパスワード(オプションの手順)。

- JNDIプロトコル: リストから「JNDI」プロトコルを選択します(オプションの手順)。

- JNDIドライバ: JNDIプロバイダに接続するための初期コンテキスト・ファクトリjavaクラスの名前。例(LDAPの場合): com.sun.jndi.ldap.LdapCtxFactory

- JNDI URL: <JMS_RESOURCE>。例(LDAPの場合):ldap://<host>:<port>/<dn>

- JNDIリソース: JMSキューまたはトピックの接続ファクトリに対応するJNDIリソースの論理名。
たとえば、メッセージ・キューにアクセスする場合はQueueConnectionFactory、トピックにアクセスする場合はTopicConnectionFactoryを指定します。これらのパラメータはJNDIディレクトリおよびプロバイダ固有のものです。

20.3.2 JMS物理スキーマの作成

『Oracle Data Integratorの管理』の物理スキーマの作成に関する項の説明に従って、標準の手順を使用してJMS物理スキーマを作成します。

注意:
各JMSデータ・サーバーに必要な物理スキーマは、1つのみです。

『Oracle Data Integratorの管理』の論理スキーマの作成に関する項の説明に従って、標準の手順を使用してこの物理スキーマ用の論理スキーマを作成し、特定のコンテキストで関連付けます。

20.4 統合プロジェクトの設定

JMSを使用してプロジェクトを設定するには、標準の手順に従います。『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』の統合プロジェクトの作成に関する項を参照してください。

JMSでの作業を開始するにあたり、使用するプロジェクトに次のナレッジ・モジュールをインポートすることをお薦めします。

- IKM SQL to JMS Append

- LKM JMS to SQL

20.5 JMSモデルの作成および定義

この項には次のトピックが含まれます:

- JMSモデルの作成

- JMSデータストアの定義

注意:
JMSモデルをリバース・エンジニアリングすることはできません。データストアを作成するには、JMSモデルを作成してJMSデータストアを定義する必要があります。

20.5.1 JMSモデルの作成

『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のモデルの作成に関する項に記載されている標準の手順で、JMSモデルを作成します。

JMSモデルは、ルーターのトピックまたはキューに対応する一連のデータストアです。各データストアは特定のキューまたはトピックに対応します。データストアの構造によって、このキューまたはトピックのメッセージ構造が定義されます。モデルは常に、論理スキーマに基づきます。特定のコンテキストで、論理スキーマは1つのJMS物理スキーマに対応します。この物理スキーマに対応するデータ・スキーマには、トピックまたはキューが含まれます。

20.5.2 JMSデータストアの定義

Oracle Data Integrator内の各データストアは、1つのJMSトピックまたはキューです。このトピックまたはキューに含まれる各メッセージは、データストアの1つの行です。

JMSメッセージではあらゆるタイプの情報が伝達されるため、メタデータを取得する方法はありません。そのため、リバース・エンジニアリングは不可能です。

データストアの構造を定義するには、次のいずれかを行います。

- データストアをファイル・データストアとして作成し、メッセージ構造を手動で宣言します。

- メッセージのリバース・エンジニアリングを自動化するために、Excelスプレッドシートを介してファイル・リバース・エンジニアリングを使用します。このリバース・エンジニアリング方法の詳細は、第3章「ファイル」を参照してください。

- 別のモデルからJMSモデルへデータストアを複製します。

重要:
データストアのリソース名は、それらのデータに対応するメッセージを伝達するJMS宛先の名前(論理JNDI名)と同一にする必要があります。通常、これらの名前では大/小文字が区別されます。

擬似列としてのJMSプロパティの宣言

プロパティ擬似列は、メッセージのプロパティまたはヘッダー・フィールドを表します。これらの擬似列は、JMS固有のデータ型を使用して、Oracle Data Integratorモデル内でJMSデータストアの属性として定義されます。JMS固有のデータ型は、JMS_xxx(例: JMS String、JMS Long、JMS Intなど)と呼ばれます。

これらのプロパティ擬似列を定義するには、単純に、プロパティと同じ名前の、JMS固有の適切なデータ型が指定された追加の属性を宣言します。

標準、プロバイダ固有またはアプリケーション固有のプロパティのような名前で擬似列を定義した場合、擬似列はそのようなプロパティとしてメッセージで消費またはパブリッシュされます。擬似列が標準またはプロバイダ固有のJMSプロパティ・セットにリストされていない場合は、アプリケーション固有の追加のプロパティとみなされます。

たとえば、マッピングで、CUSTOMERというJMSキューから消費された、またはJMSキューにプッシュされたメッセージのJMSPriorityデフォルト・プロパティを使用または設定するには、CUSTOMERデータストアに(大/小文字を区別して)JMSPriorityという属性を追加します。この属性では、JMSキュー・テクノロジに対してJMS Intデータ型を使用できます。

警告:

- プロパティ擬似列は、定義して、JMSデータストアのメッセージ・ペイロードを構成する属性の後にデリミタ付きファイル形式で配置する必要があります。列定義の「順序」フィールドを使用して、これらの列を配置します。データストア定義の最後に表示されているかぎり、擬似列自体の順序は重要ではありません。

- 擬似列名では大/小文字が区別されます。

JMSプロパティの詳細は、次を参照してください。

- 20.7項「JMS標準プロパティ」

- 20.7.1項「JMSプロパティの使用」

20.6 マッピングの設計

JMSをマッピングのソースまたはターゲットとして使用できます。ステージング領域としては使用できません。

マッピングまたはチェック用に選択したKMによって、このマッピングまたはチェックの機能およびパフォーマンスが決まります。この項に示す推奨事項は、JMSメッセージに関連する様々な状況でのKMの選択に役立ちます。

20.6.1 JMSソースからのデータのロード

JMSをマッピングのソースまたはターゲットとして使用できます。JMSメッセージ・キューまたはトピックのデータは、ステージング領域として使用される任意のSQL準拠データベースにロードできます。マッピング・フロー・タブでの、JMSと別のタイプのデータ・サーバー間でデータをロードするためのLKMの選択は、マッピングのパフォーマンスに関してきわめて重要です。

Oracle Data Integratorには、JMSソースからステージング領域へデータをロードするためのLKM JMS to SQLが用意されています。このLKMは、テキストまたはバイナリのJMS準拠メッセージ・キューまたはトピックから、ステージング領域として使用される任意のSQL準拠データベースへ、データをロードします。

JMS固有のオプションは、表20-2を参照してください。

20.6.2 JMSターゲットでのデータの統合

Oracle Data Integratorには、JMS用に最適化されたデータ統合戦略を実装するIKM SQL to JMS Appendが用意されています。このIKMは、任意のSQL準拠ステージング領域からJMS準拠のメッセージ・キューまたはトピックへ、テキストまたはバイナリ形式でデータを統合します。このIKMのJMS固有のKMオプションは、表20-2を参照してください。

マッピング・フロー・タブのIKMの選択によって、統合のパフォーマンスおよび可能性が決まります。

JMSナレッジ・モジュール・オプション

JMS IKMおよびLKMのJMS固有のKMオプションは、表20-2を参照してください。

このLKMのJMS固有のオプションは、IKM SQL to JMS Appendのオプションと類似しています。異なるのは次の2点のみです。

- DELETE_TEMPORARY_OBJECTSオプションは、LKMのみで使用できます。

- PUBLISHオプションは、IKMのみで使用できます。

表20-2 JMS固有のKMオプション

オプション

用途

説明

PUBLISH

書込み

宛先に新規メッセージをパブリッシュする場合は、このオプションをチェックします。このオプションは、デフォルトでYesに設定されています。

JMS_COMMIT

読取り/書込み

メッセージの公開または消費をコミットします。ルーター上で公開または消費をコミットしないためには、このオプションを選択解除します。このオプションは、デフォルトでYesに設定されています。

JMS_COMMIT=1

読取り/書込み

ドライバで使用可能なすべてのメッセージの読取りが完了した直後にJMS読取り操作をコミットします。

JMSサーバーでは、一部のクライアントによってメッセージ読取りが消費されたとみなされます。

JMS_COMMIT=0:

読取り/書込み

JMSドライバはメッセージを読み取りますが、JMS読取りは、JMSサーバーによって実行されたとみなされません。これは、対応するODIセッション(必ずしもインタフェースであるとは限りません)が正常に終了すると発生します。

セッションが失敗すると、メッセージは消費されません。

JMSDELIVERYMODE

書込み

JMS配信モード(1: 非永続、2: 永続)。永続メッセージはサーバーに残り、サーバーのクラッシュ時にリカバリされます。

JMSEXPIRATION

書込み

サーバー上でのメッセージの有効期限をミリ秒で指定します(0から4 000 000 000)。0の場合、メッセージの有効期限が切れることはありません。

警告:この有効期限を過ぎると、メッセージは期限切れとみなされ、トピックまたはキューからなくなります。マッピングの開発時には、このパラメータをゼロに設定することをお薦めします。

JMSPRIORITY

書込み

メッセージの相対的優先度: 0(最低)から9(最高)。

SENDMESSAGETYPE

書込み

送信するメッセージのタイプ(1 - BytesMessage、2 - TextMessage)。

JMSTYPE

書込み

メッセージの名前(オプション)。

CLIENTID

読取り

サブスクライバ識別文字列。このオプションは、JMS互換のためにのみ記述されます。

公開には使用されません。

DURABLE

読取り

D: セッションは永続的です。切断後もサブスクライバ定義がルーター上に残ることを示します。

MESSAGEMAXNUMBER

読取り

取得されるメッセージの最大数(0から4 000 000 000)。0: すべてのメッセージが取得されます。

MESSAGETIMEOUT

読取り

最初のメッセージの待機時間をミリ秒で示します(0から4 000 000 000)。MESSAGETIMEOUTが0の場合、タイムアウトは発生しません。

MESSAGETIMEOUTおよびMESSAGEMAXNUMBERの両方をゼロにすることはできません。MESSAGETIMEOUT= 0でMESSAGEMAXNUMBER =0の場合、MESSAGETIMEOUTの値として1が使用されます。

警告:このタイムアウト値が小さすぎると、マッピングによってメッセージが取得されない可能性があります。

NEXTMESSAGETIMEOUT

読取り

後続の各メッセージの待機時間をミリ秒で示します(0から4 000 000 000)。デフォルト値は1000です。

警告:この値が小さすぎると、マッピングによってトピックまたはキューにあるメッセージの一部のみが取得される場合があります。

MESSAGESELECTOR

読取り

ISO SQL構文のメッセージ・セレクタ。メッセージ・セレクタの詳細は、20.7.1項「JMSプロパティの使用」を参照してください。

20.7 JMS標準プロパティ

この項では、メッセージ・ヘッダーに含まれるJMSプロパティおよび使用方法について説明します。

Oracle Data Integratorでは、JMS標準プロパティに対応する擬似列を表20-3の説明に従って宣言する必要があります。

JMSタイプおよびアクセス・モード列では、Oracle Data IntegratorまたはJavaプログラムのこれらのプロパティの使用が参照されます。Oracle Data Integratorでは、これらのプロパティの一部がIKMオプションを介して使用されるため、擬似列値をマッピングで設定しないでください。

これらのプロパティのJavaプログラムでの使用方法は、http://java.sun.com/products/jms/を参照してください。

表20-3 メッセージ・ヘッダーの標準JMSプロパティ

プロパティ

JMS型

アクセス(読取り/書込み)

説明

JMSDestination

JMS String

R

メッセージの宛先(トピックまたはキュー)の名前。

JMSDeliveryMode

JMS Integer

R/W (IKMオプションによって設定)

配信モード: 1 = 非永続、または2 = 永続。永続メッセージは、ルーターがクラッシュした場合でも失われることはありません。

このプロパティは、メッセージの送信時にJMSDELIVERYMODE KMオプションによって設定されます。

JMSMessageID

JMS String

R

メッセージの一意の識別子。この識別子はルーターによって内部的に使用されます。

JMSTimestamp

JMS Long

R

メッセージ送信操作の日時。この時間は、UTC標準形式で格納されます(1)。

JMSExpiration

JMS Long

R/W (IKMオプションによって設定)

メッセージの有効期限の日時。この時間は、UTC標準形式で格納されます(1)。

このプロパティを設定するには、JMSEXPIRATION KMオプションを使用する必要があります。

JMSRedelivered

JMS Boolean

R

メッセージが再送されたかどうかを示します。これは、メッセージ・コンシューマがメッセージ受信の確認に失敗した場合に発生します。

JMSPriority

JMS Int

R/W

メッセージの返信の送信先となる宛先(トピックまたはキュー)の名前。

JMSCorrelationID

JMS String

R/W

メッセージの相関ID。これは、このメッセージがこの返信を生成するメッセージのJMSMessageIDである場合があります。また、アプリケーション固有の識別子である場合もあります。

JMSType

JMS String

R/W (IKMオプションによって設定)

メッセージ・タイプ・ラベル。このタイプは、メッセージを実用的に説明する文字列値です(例: SalesEvent、SupportProblem)。

このプロパティを設定するには、JMSTYPE KMオプションを使用する必要があります。

表20-4に、JMS標準のオプションのJMS定義プロパティをリストします。

表20-4 メッセージ・ヘッダーのオプションJMSプロパティ

プロパティ

JMS型

アクセス(読取り/書込み)

説明

JMSXUserID

JMS String

R

クライアント・ユーザーID。

JMSXAppID

JMS String

R

クライアント・アプリケーションID。

JMSSXProducerTXID

JMS String

R

本番セッションのトランザクションID。このIDは、2つのJMSコミット操作の間にプロデューサが宛先に送信したすべてのメッセージで同一です。

JMSSXConsumerTXID

JMS String

R

現在の消費セッションのトランザクションID。このIDは、2つのJMSコミット読取り操作の間にコンシューマが宛先から読み取ったメッセージのバッチで同一です。

JMSXRcvTimestamp

JMS Long

R

メッセージの受信日時。この時間は、UTC標準形式で格納されます(1)。

JMSXDeliveryCount

JMS Int

R

メッセージの受信回数。常に1に設定されます。

JMSXState

JMS Int

R

メッセージの状態。常に2(準備完了)に設定されます。

JMSXGroupID

JMS String

R/W

メッセージが属するグループのID。

JMSXGroupSeq

JMS Int

R/W

メッセージ・グループ内のメッセージの順序番号。

(1): UTC(協定世界時)標準は、1970年1月1日から経過したミリ秒数です。

20.7.1 JMSプロパティの使用

メッセージには、内容の他にも一連のプロパティが添付されます。これらは、プロバイダ固有のプロパティ、アプリケーション固有(ユーザー定義)のプロパティまたはJMS標準プロパティです。

JMSプロパティはOracle Data Integratorで補足情報として使用され、メッセージのフィルタ処理などに使用されます。

20.7.1.1 JMSプロパティの宣言

JMSデータストアの定義の際に、マッピングで使用するJMSプロパティに対応する擬似列を追加する必要があります。詳細は、「擬似列としてのJMSプロパティの宣言」を参照してください。

20.7.1.2 ルーター上でのフィルタリング

このタイプのフィルタリングでは、フィルタはJMS読取り問合せの送信時に指定されます。メッセージ・セレクタ・フィルタと一致するメッセージのみが取得されます。メッセージ・セレクタは、Oracle Data IntegratorでMESSAGE_SELECTOR KMオプションを使用して指定されます。

注意:
ルーターのフィルタリングはJMSの必須機能ではありません。使用できない場合があります。JMSプロバイダのドキュメントを参照して、使用できることを確認してください。

MESSAGE_SELECTORはSQLのWHERE構文でプログラムされます。次の(比較、ブールおよび数値)演算子がサポートされています。

+、-、*、/、=、>、<、<>、>=、<=、OR、AND、BETWEEN、IN、NOT、LIKE、IS NULL

注意:

- IS NULL句では、空の値を持つプロパティは処理されますが、存在しないアプリケーション固有プロパティは処理されません。
たとえば、セレクタCOLOR IS NULLが定義されている場合、アプリケーション固有プロパティCOLORが空の値とともに指定されているメッセージは、正しく消費されます。同じトピックまたはキューにある別のメッセージにこのプロパティが指定されていない場合、そのメッセージでは例外が発生します。

例

優先度が5より高いすべてのメッセージをフィルタ処理する場合

JMSPriority > 5

優先度が6より低く、タイプがSales_Eventのすべてのメッセージをフィルタ処理する場合

NOT JMSPriority < 6 AND JMSType = 'Sales_Event'

20.7.1.3 クライアント上でのフィルタリング

フィルタリングはメッセージの受信後に実行され、ステージング領域で実行する必要がある標準のOracle Data Integratorマッピング・フィルタを作成することによって設定されます。フィルタでは、ソースJMSデータストアの擬似列が使用されます。Oracle Data Integratorデータストアで定義された擬似列は、JMSプロパティを表します。詳細は、「擬似列としてのJMSプロパティの宣言」を参照してください。この方法でフィルタ処理されたメッセージは、キューまたはトピックから消費されたとみなされます。

20.7.1.4 ソース・データとしてのプロパティ値の使用

JMSプロパティの値は、マッピングのソース・データとして使用できます。これは、マッピングでソースJMSデータストアの擬似列を指定することで実行されます。詳細は、「擬似列としてのJMSプロパティの宣言」を参照してください。

20.7.1.5 メッセージ送信時のプロパティの設定

JMSデータストアをターゲット指定するマッピングで擬似列の値をマップすることで、メッセージの送信時にJMSプロパティを指定できます。一部のプロパティはKMオプションを使用して設定されます。詳細は、20.7項「JMS標準プロパティ」を参照してください。

21 JMS XML

この章では、XMLペイロードを使用するJava Message Services (JMS)のOracle Data Integratorでの使用方法について説明します。

この章には次の項が含まれます:

- 21.1項「はじめに」

- 21.2項「インストールおよび構成」

- 21.3項「トポロジの設定」

- 21.4項「統合プロジェクトの設定」

- 21.5項「JMS XMLモデルの作成およびリバース・エンジニアリング」

- 21.6項「マッピングの設計」

21.1 はじめに

Oracle Data Integratorには、JMS宛先を統合するための、単純で透過的な方法が用意されています。この章では、XMLペイロードを使用するJMSメッセージの処理について説明します。バッチ・モードでのテキスト・ペイロードの処理の説明は、第20章「JMS」を参照してください。

21.1.1 概念

JMS XMLナレッジ・モジュールは、最も一般的なJMS準拠のミドルウェア(Oracle Service Bus、Sonic MQなど)に適用されます。これらのほとんどのナレッジ・モジュールには、メッセージを確実に配信するためのトランザクション処理が含まれます。

21.1.1.1 JMSメッセージの構造

JMSメッセージの構造の詳細は、21.1.1.1項「JMSメッセージの構造」を参照してください。

21.1.1.2 JMS宛先の使用

Oracle Data Integratorでは、JMS宛先によって配信されるXMLメッセージの処理が可能です。各メッセージはXMLデータのコンテナとして扱われ、JMS XMLキューまたはJMS XMLトピック・テクノロジを介して処理されます。

JMS XMLキューまたはJMS XMLトピック・テクノロジでは、各メッセージ・ペイロードに完全なXMLデータ構造が含まれます。この構造は、Oracle Data Integrator XML Driverを使用して、モデルとして表示されるリレーショナル・スキーマ(XMLスキーマ)にマップされます。

注意:
この方法は、XMLファイルの処理と非常に似ています。JMS XMLでは、メッセージ・ペイロードがXMLファイルです。XMLファイルの処理およびXMLドライバの詳細は、第5章「XMLファイル」および付録B「Oracle Data Integrator Driver for XMLの参照情報」を参照してください。

トポロジでは、単一の物理スキーマを使用して、各JMS宛先がJMS XMLトピックまたはキューのデータ・サーバーとして定義されます。XML形式のメッセージを配信する各トピックまたはキューに対して、データ・サーバーと物理スキーマの1つのペアが宣言されます。

XMLメッセージの構造は、データ・モデルとして表示されるリレーショナル構造(XMLスキーマと呼ぶ)にマップされます。このモデル内の各データストアは、XMLファイルの一部(一般的には要素タイプ)を表します。

メッセージの処理

各XMLメッセージは1つのOracle Data Integratorモデルに対応するため、JMS XMLメッセージの消費または生成時には、モデル全体を1つの単位として使用およびロードする必要があります。XMLメッセージの処理単位はパッケージです。

モデル内でメッセージのプロパティまたはヘッダー・フィールドを宣言したり、マッピング内で属性として使用することはできません。ただし、メッセージ・セレクタでの使用やKMオプションを介した設定は可能です。

XMLメッセージの消費

受信XMLメッセージの処理は、パッケージ単位で次のように実行されます。

1. JMSメッセージとXMLスキーマの同期化: この操作では、メッセージの読取りおよびXMLスキーマの生成が行われます。通常、メッセージに最初にアクセスするマッピングによって実行されます。

2. データの抽出: 一連のマッピングにより、XMLスキーマのデータストアがソースとして使用されます。このデータを使用できるのは、セッションの終了、新規の同期化アクションによる別のメッセージの読取り、またはJMS読取りのコミットの実行が発生するまでです。

3. JMS読取りのコミット: この操作では、メッセージ消費の検証およびXMLスキーマの削除が行われます。XMLメッセージからデータを抽出する最後のマッピングで実行する必要があります。

XMLメッセージの生成

XMLメッセージを生成するには、パッケージが次のタスクを実行できるように設計されている必要があります。

1. XMLスキーマの初期化: この操作では、生成するXMLメッセージに対応する空のXMLスキーマが作成されます。この操作は、通常、構造をロードする最初のマッピングで実行されます。

2. データのロード: 一連のマッピングによって、XMLスキーマにデータがロードされます。

3. XMLスキーマとJMSの同期化: この操作では、XMLスキーマがXMLメッセージに変換され、JMS宛先に送信されます。この操作は、通常、スキーマをロードする最後のマッピングで実行されます。

メッセージのフィルタリング

サーバー上のメッセージをフィルタ処理するためのメッセージ・セレクタ(MESSAGE_SELECTOR KMオプション)を定義することで、JMS XML宛先のメッセージをフィルタ処理できます。このタイプのフィルタでは、メッセージのプロパティまたはヘッダー・フィールドのみを使用できます。フィルタはサーバーによって処理されるため、Data Integratorで読み取られる情報量が削減されます。XMLスキーマから抽出されたデータを使用して、マッピングでデータをフィルタ処理することもできます。これらのフィルタは、メッセージがXMLスキーマと同期化された後、Data Integratorで処理されます。

21.1.2 ナレッジ・モジュール

Oracle Data Integratorには、表21-1に示されている、XMLメッセージを処理するためのナレッジ・モジュール(KM)が用意されています。

表21-1 JMS XMLナレッジ・モジュール

ナレッジ・モジュール

説明

IKM SQL to JMS XML Append

任意のANSI SQL-92標準準拠ステージング領域からJMS準拠のメッセージのキューまたはトピックへ、XML形式でデータを統合します。

LKM JMS XML to SQL

XMLのJMS準拠メッセージのキューまたはトピックから、ステージング領域として使用される任意のANSI SQL-92標準準拠データベースへ、データをロードします。

21.2 インストールおよび構成

JMSナレッジ・モジュールの使用を開始する前に、この項の情報を必ず読んでください。

- システム要件および動作要件

- テクノロジ固有の要件

- 接続性要件

21.2.1 システム要件および動作要件

インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。

サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。

http://www.oracle.com/technology/products/oracle-data-integrator/index.html

21.2.2 テクノロジ固有の要件

JMS宛先へのアクセスは、通常、JNDIサービス経由で行われます。JNDIおよびJMSの構成および固有の要件は、接続先のJMSプロバイダによって異なります。詳細は、JMSプロバイダ固有のドキュメントを参照してください。

注意:
デフォルトでは、JMS XMLドライバ読取り操作の固定レコード・セパレータとして、4つの連続する';'が使用されます。XMLデータにも4つ以上の連続する';'文字が含まれている場合は、エラーが発生するため、レコード・セパレータを別の値に設定する必要があります。これを行うには、Doracle.odi.jmsxmlColSepString JVMオプションを使用します。たとえば、Doracle.odi.jmsxmlColSepString="????"を指定すると、JMS XMLドライバ・レコード・セパレータが";;;;"ではなく"????"に設定されます。
このオプションは、次の場所で設定する必要があります。

- Studioの場合、odi.conf parameterファイルでこのパラメータを設定します。新しいAddVMOptionエントリを追加します。

- 12c Standalone/Colocated Agentの場合、instance.shスクリプトでODI_INSTANCE_OPTIONSを使用します。

- 11g Standalone Agentの場合、odiparamsファイルでODI_ADDITIONAL_JAVA_OPTIONSを使用します。

- JEEエージェントの場合、startManagedWeblogicスクリプトでこれをJAVA_OPTIONSに追加します。

21.2.3 接続性要件

この項では、JMS XMLデータベースに接続するための要件をリストします。

Oracle Data Integratorには、JMSプロバイダ専用のドライバは含まれていません。このプロバイダの接続性要件は、JMSプロバイダのドキュメントを参照してください。

XML構成

XMLコンテンツへのアクセスは、Oracle Data Integrator JDBC for XMLドライバを介して行われます。このドライバは、Oracle Data Integratorとともにインストールされます。

XMLコンテンツを説明するDTDファイルの場所は、システム管理者に問い合せてください。

21.3 トポロジの設定

トポロジの設定には次が含まれます。

1. JMS XMLデータ・サーバーの作成

2. JMS XML物理スキーマの作成

21.3.1 JMS XMLデータ・サーバーの作成

各JMS XMLデータ・サーバーは、ローカル・ネットワーク経由でアクセス可能な1つのJMSプロバイダまたはルーターに対応します。

JMS XMLデータ・サーバーには、JMSキューXMLとJMSトピックXMLの2タイプがあります。

- JMSキューXMLデータ・サーバーは、JMSルーター内の単一のキューに接続してXMLメッセージを統合するために使用されます。

- JMSトピックXMLデータ・サーバーは、JMSルーター内の単一のトピックに接続してXMLメッセージを統合するために使用されます。

Oracle Data Integrator JMSドライバにより、XMLコンテンツを含むメッセージがメモリー内のリレーショナル・スキーマにロードされます。このスキーマは、XMLメッセージの階層構造を表し、リレーショナル構造をアンロードしてJMSメッセージに戻すことができます。

21.3.1.1 データ・サーバーの作成

『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のデータ・サーバーの作成に関する項に記載されている標準の手順で、JMSキューXMLテクノロジまたはJMSトピックXMLテクノロジ用のデータ・サーバーを作成します。

JMSキューXMLまたはJMSトピックXMLデータ・サーバーの作成手順は、XMLデータ・サーバーの作成手順と同じですが、JNDI接続を定義する際に、「JNDI URL」でJMS XML固有の情報を指定する必要があります。詳細は、5.3.1項「XMLデータ・サーバーの作成」を参照してください。

この項では、JMSキューXMLまたはJMSトピックXMLデータ・サーバーの定義に関する必須または固有のフィールドのみについて説明します。

1. 「定義」タブ:

- 名前: Oracle Data Integratorに表示されるデータ・サーバーの名前。

- ユーザー/パスワード: ここでは使用しません。これらのフィールドは空のままにします。

2. 「JNDI」タブ:

- JNDI認証: 認証モードをリストから選択します。

- JNDIユーザー: JNDIディレクトリに接続するためのユーザー名を入力します(オプション)。

- パスワード: このユーザーのパスワード(オプション)。

- JNDIプロトコル: リストから「JNDI」プロトコルを選択します(オプション)。

- JNDIドライバ: JNDIプロバイダに接続するための初期コンテキスト・ファクトリjavaクラスの名前。次に例を示します。
com.sun.jndi.ldap.LdapCtxFactory

- JNDI URL: <JMS_RESOURCE>?d=<DTD_FILE>&s=<SCHEMA>&JMS_DESTINATION=<JMS_DESTINATION_NAME>
JNDI URLのプロパティの説明は、表21-2を参照してください。

- JNDIリソース: JMSキュー(またはトピック)の接続ファクトリに対応するJNDIリソースの論理名。

注意:
メッセージ・キューにアクセスする場合はQueueConnectionFactory、トピックにアクセスする場合はTopicConnectionFactoryを指定します。これらのパラメータはJNDIディレクトリ固有のものです。

表21-2 JNDI URLのプロパティ

パラメータ

値

説明

d

<DTDファイルの場所>

UNC形式のDTDファイルの場所(相対または絶対)。パス名にはスラッシュ"/"を使用し、ファイル・パスにはバックスラッシュ"\"を使用しないでください。このパラメータは必須です。

re

<ルート要素>

スキーマのルート表として選択する要素の名前。この値では大/小文字が区別されます。このパラメータは、WSDLファイルの特定のメッセージ定義をリバース・エンジニアリングする場合や、使用可能なルート要素がXSDファイル内に複数存在する場合に使用できます。

ro

true | false

trueの場合は、XMLファイルが読取り専用モードで開きます。

s

<スキーマ名>

XMLファイルのロード先となるリレーショナル・スキーマの名前。この値は、このデータ・サーバーに添付されている物理スキーマの設定値と一致する必要があります。このパラメータは必須です。

cs

true | false

大/小文字を区別するモードまたは区別しないモードで、XMLファイルがロードされます。大/小文字を区別しないモードの場合は、DTDファイル内のすべての要素名を区別できることが必要です(たとえば、同じファイルにAbcとabcを含めることはできません)。大/小文字を区別するパラメータは、スキーマの永続パラメータです。スキーマの作成後に変更することはできません。大/小文字を区別しないモードでXMLファイルを開く場合、XMLファイルの大/小文字は保持されます。

JMSXML_ROWSEPARATOR

5B23245D

異なるXMLコンテンツの行セパレータ(改行)として使用される文字列の16進コード。デフォルト値の5B23245Dは、文字列[#$]に相当します。

JMS_DESTINATION

JNDIキュー名またはトピック名

JMSキューまたはトピックのJNDI名。このパラメータは必須です。

transform_nonasciiまたはtna

ブール値(true|false)

非ASCIIを変換します。非ASCII文字を保持するにはfalseに設定します。デフォルトはtrueです。このパラメータは必須ではありません。

例

LDAPディレクトリをJNDIプロバイダとして使用する場合は、次のパラメータを使用する必要があります。

- JNDIドライバ: com.sun.jndi.ldap.LdapCtxFactory

- JNDI URL: ldap://<ldap_host>:<port>/<dn>?d=<DTD_FILE>&s=<SCHEMA>&JMS_DESTINATION=<JMS_DESTINATION_NAME>

- JNDIリソース: <Name of the connection factory>

21.3.2 JMS XML物理スキーマの作成

『Oracle Data Integratorの管理』の物理スキーマの作成に関する項の説明に従って、標準の手順を使用してJMS XML物理スキーマを作成します。

注意:
スキーマおよび作業スキーマの名前として、JMSキューXMLまたはJMSトピックXMLデータ・サーバーのJNDI URLのs=<schema name>プロパティで定義されたスキーマ名を使用してください。

注意:
各JMS XMLデータ・サーバーに必要な物理スキーマは、1つのみです。

『Oracle Data Integratorの管理』の論理スキーマの作成に関する項の説明に従って、標準の手順を使用してこの物理スキーマ用の論理スキーマを作成し、特定のコンテキストで関連付けます。

21.4 統合プロジェクトの設定

JMS XMLを使用してプロジェクトを設定するには、標準の手順に従います。『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』の統合プロジェクトの作成に関する項を参照してください。

JMS XMLでの作業を開始するにあたり、使用するプロジェクトに次のナレッジ・モジュールをインポートすることをお薦めします。

- IKM SQL to JMS XML Append

- LKM JMS XML to SQL

21.5 JMS XMLモデルの作成およびリバース・エンジニアリング

この項には次のトピックが含まれます:

- JMS XMLモデルの作成

- JMS XMLモデルのリバース・エンジニアリング

21.5.1 JMS XMLモデルの作成

『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のモデルの作成に関する項に記載されている標準の手順で、JMSキューXMLまたはJMSトピックXMLモデルを作成します。

JMSキューXMLまたはJMSトピックXMLの各モデルは一連のデータストアに対応し、各データストアはXMLファイルのエントリ・レベルを表します。これらのモデルには、JMSメッセージの構造を説明するデータストアが含まれます。各モデルには、1つのトピックまたはキューのメッセージ構造が含まれます。このモデルの構造は、標準のリバース・エンジニアリングを使用して、データ・サーバー定義で指定されたDTDまたはXMLファイルからリバース・エンジニアリングされます。

21.5.2 JMS XMLモデルのリバース・エンジニアリング

JMS XMLでは、XMLドライバの機能のみを使用する標準のリバース・エンジニアリングがサポートされています。

JMSキューXMLまたはJMSトピックXMLで標準のリバース・エンジニアリングを実行するには、『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のモデルのリバース・エンジニアリングに関する項に記載されている通常の手順を行います。

Oracle Data Integratorでは、XMLデータから生成されたデータストアに次の属性が自動的に追加されます。

- 主キー(PK属性): 親子関係に使用されます。

- 外部キー(FK属性): 親子関係に使用されます。

- 順序識別子(ORDER属性): XMLファイルでのデータの表示順序を取得できます。

これらの追加の属性により、スキーマに格納されたリレーショナル構造でのXML階層構造のマッピングが可能になります。詳細は、付録B「Oracle Data Integrator Driver for XMLの参照情報」を参照してください。

21.6 マッピングの設計

マッピングまたはチェック用に選択したKMによって、このマッピングまたはチェックの機能およびパフォーマンスが決まります。この項に示す推奨事項は、XMLメッセージに関連する様々な状況でのKMの選択に役立ちます。

21.6.1 JMS XMLソースからのデータのロード

JMS XMLをマッピングのソースまたはターゲットとして使用できます。XMLメッセージ・キューまたはトピックのデータは、ステージング領域として使用される任意のANSI SQL-92標準準拠データベースにロードできます。マッピング・フロー・タブでの、JMS XMLと別のタイプのデータ・サーバー間でデータをロードするためのLKMの選択は、正常なデータ抽出を行うためにきわめて重要です。

Oracle Data Integratorには、JMS準拠メッセージのキューまたはトピックから、ステージング領域として使用される任意のANSI SQL-92標準準拠データベースにXMLでデータをロードするためのLKM JMS XML to SQLが用意されています。このLKMは、エージェントを使用して、選択されたメッセージをソース・キューまたはトピックから読み取り、動的に作成される一時ステージング表に結果を書き込みます。メッセージを確実に配信するために、メッセージ消費者(またはサブスクライバ)では、IKMによってデータが実際にターゲットに統合されるまで、読取りをコミットしません。ソース・データストアの1つがXML JMSメッセージである場合は、このLKMの使用を検討してください。

JMSプロバイダからXMLメッセージをロードするには、次の手順に従う必要があります。

- JMS XMLソースからXMLメッセージを読み取る最初のマッピングでLKM JMS XML to SQLを使用し、その際にSYNCHRO_JMS_TO_XML LKMオプションをYesに設定する必要があります。このオプションによって、キューまたはトピックから取得されるメッセージから、XMLスキーマが作成およびロードされます。

- 最後のマッピングで、JMS_COMMITをYesに設定して、メッセージの消費をコミットする必要があります。

このナレッジ・モジュールのJMS固有のオプションは、表21-3を参照してください。

21.6.2 JMS XMLターゲットでのデータの統合

Oracle Data Integratorには、JMS XML用に最適化されたデータ統合戦略を実装するIKM SQL to JMS XML Appendが用意されています。このIKMは、任意のANSI SQL-92標準準拠ステージング領域からJMS準拠のメッセージのキューまたはトピックへ、XML形式でデータを統合します。

このIKMを使用するには、ステージング領域がターゲットと異なる必要があります。

JMS XMLターゲットにXMLデータを統合するには、次の手順に従う必要があります。

- XMLスキーマをロードする最初のマッピングで、ROOT_TABLE (XMLファイルのルート要素に対応するモデルの表)の値を指定し、さらにINITIALIZE_XML_SCHEMAオプションをYesに設定する必要があります。

注意:
XMLスキーマのルート表は、通常、JMS XMLモデルの階層ツリー表示の最上位にあるデータストアに対応します。そのため、ROOT_TABLEパラメータには、このデータストアのリソース名の値を使用する必要があります。

- マッピングによるデータストアのロードは、階層の順序に従って、階層の最上位から下位へ行う必要があります。XMLスキーマ階層の後続レベルをロードするマッピングでは、現在の階層レベルを上位レベルにリンクする外部キー属性をロードする必要があります。
たとえば、階層の2番目のレベル(ルート表の下のレベル)をロードする場合、外部キー属性を0(ゼロ)に設定する必要があります。これは、ルート表の初期化時にIKMによってルート表の主キーに設定される値が0であるためです。

- 最後のマッピングでは、XMLスキーマをJMSプロバイダに送信する必要があります。そのために、SYNCHRO_JMS_TO_XMLパラメータをYesに設定します。

例

XMLファイル形式によって次のデータストア階層のスキーマが生成されるとします。

+ GEOGRAPHY_DIM (GEO_DIMPK, ...)
|
+--- COUNTRY (GEO_DIMFK, COUNTRYPK, COUNTRY_NAME, ...)
|
+--- REGION (COUNTRYFK, REGIONPK, REGION_NAME, ...)

この階層では、GEOGRAPHY_DIMがルート表で、そのGEOGRAPHY_DIMPK属性が初期化時に0に設定されます。この表は、GEOGRAPHY_DIM、COUNTRY、REGIONの順にロードする必要があります。

- XML階層の2番目のレベル(COUNTRY)のロード時に、このレベルをルート表のレベルとリンクするFKフィールドが0に設定されていることを確認します。上のモデルでは、COUNTRYのロード時に、0に設定されているCOUNTRY.GEOGRAPHY_DIMFKをロードする必要があります。

- また、REGIONのレコードをCOUNTRYレベルにリンクする必要があります。そのためには、COUNTRY内の親レコードに対応する値を指定して(REGION.COUNTRYFK = COUNTRY.COUNTRYPK)、REGION.COUNTRYFK属性をロードします。

XMLスキーマへのデータのロードの詳細は、付録B「Oracle Data Integrator Driver for XMLの参照情報」を参照してください。

このIKMのJMS固有のKMオプションは、表21-3を参照してください。XMLメッセージ固有のオプションは太字で表記されています。

JMS XMLナレッジ・モジュール・オプション

JMS XMLのLKMおよびIKMのKMオプションは、表21-3を参照してください。XMLメッセージ固有のオプションは太字で表記されています。

ほとんどのオプションはLKMとIKMで同じですが、次の点のみ異なります。

- INITIALIZE_XML_SCHEMAおよびROOT_TABLEオプションは、IKMのみで使用できます。

- DELETE_TEMPORARY_OBJECTSおよびJMS_COMMITオプションは、LKMのみで使用できます。

- ルーター(JMS XML)上でメッセージ消費をコミットするには、JMS_COMMITをYesに設定します。

表21-3 JMS固有のKMオプション

オプション

用途

説明

CLIENTID

読取り

サブスクライバ識別文字列。

公開には使用されません。

DURABLE

読取り

D: セッションは永続的です。切断後もサブスクライバ定義がルーター上に残ることを示します。

INITIALIZE_XML_SCHEMA

書込み

空のXMLスキーマを初期化します。スキーマをロードする最初のマッピングで、このオプションをYESに設定する必要があります。

JMSDELIVERYMODE

書込み

JMS配信モード(1: 非永続、2: 永続)。永続メッセージはサーバーに残り、サーバーのクラッシュ時にリカバリされます。

JMSEXPIRATION

書込み

サーバー上でのメッセージの有効期限をミリ秒で指定します(0から4 000 000 000)。0の場合、メッセージの有効期限が切れることはありません。

警告: この有効期限を過ぎると、メッセージは期限切れとみなされ、トピックまたはキューからなくなります。マッピングの開発時には、このパラメータをゼロに設定することをお薦めします。

JMSPRIORITY

書込み

メッセージの相対的優先度: 0(最低)から9(最高)。

JMSTYPE

書込み

メッセージの名前(オプション)。

MESSAGEMAXNUMBER

読取り

取得されるメッセージの最大数(0から4 000 000 000)。0: すべてのメッセージが取得されます。

MESSAGESELECTOR

読取り

ルーター上でフィルタリングするための、ISO SQL構文のメッセージ・セレクタ。メッセージ・セレクタの詳細は、20.7.1項「JMSプロパティの使用」を参照してください。

MESSAGETIMEOUT

読取り

最初のメッセージの待機時間をミリ秒で示します(0から4 000 000 000)。MESSAGETIMEOUTが0の場合、タイムアウトは発生しません。

MESSAGETIMEOUTおよびMESSAGEMAXNUMBERの両方をゼロにすることはできません。MESSAGETIMEOUT= 0でMESSAGEMAXNUMBER =0の場合、MESSAGETIMEOUTの値として1が使用されます。

警告: このタイムアウト値が小さすぎると、マッピングによってメッセージが取得されない可能性があります。

NEXTMESSAGETIMEOUT

読取り

後続の各メッセージの待機時間をミリ秒で示します(0から4 000 000 000)。デフォルト値は1000です。

警告: この値が小さすぎると、マッピングによってトピックまたはキューにあるメッセージの一部のみが取得される場合があります。

ROOT_TABLE

書込み

XMLモデル階層のルートであるデータストアのリソース名。スキーマの最初のマッピング・ロードにのみ適用できるオプション(INITIALIZE_XML_SCHEMA=true)。ROOT_TABLE<>''およびINITIALIZE_XML_SCHEMA=trueの場合、IKMによってXMLスキーマのルート要素のレコードが挿入されます。

警告: XML構造のルート表への移入を行うマッピングがない場合にのみ使用してください。そうでない場合、重複するルート要素が発生します。

SENDMESSAGETYPE

書込み

送信するメッセージのタイプ(1 - BytesMessage、2 - TextMessage)。

SYNCHRO_XML_TO_JMS

書込み

XMLスキーマからXMLメッセージを生成し、このメッセージを送信します。スキーマXMLへの書込みを行う最後のマッピングで、このオプションをYESに設定する必要があります。

22 LDAPディレクトリ

この章では、Oracle Data IntegratorでのLDAPディレクトリの使用方法について説明します。

この章には次の項が含まれます:

- 22.1項「はじめに」

- 22.2項「インストールおよび構成」

- 22.3項「トポロジの設定」

- 22.4項「統合プロジェクトの設定」

- 22.5項「LDAPディレクトリの作成およびリバース・エンジニアリング」

- 22.6項「マッピングの設計」

- 22.7項「トラブルシューティング」

22.1 はじめに

Oracle Data Integratorでは、Oracle Data Integrator Driver for LDAPを使用したLDAPディレクトリ統合がサポートされています。

22.1.1 概念

LDAPの概念は、Oracle Data Integratorの概念に次のようにマップされます。1つのLDAPディレクトリ・ツリー、より具体的には、このLDAPツリーのエントリ・ポイントは、Oracle Data Integratorの1つのデータ・サーバーに対応します。このデータ・サーバー内で、単一のスキーマがLDAPディレクトリ・ツリーのコンテンツにマップされます。

Oracle Data Integrator Driver for LDAP (LDAPドライバ)により、LDAPツリーの階層構造がリレーショナル・スキーマにロードされます。このリレーショナル・スキーマは、標準のSQL文を使用した問合せまたは変更が可能な一連の表です。

リレーショナル・スキーマは、表、列および制約とともに、ODIでデータ・モデルとしてリバース・エンジニアリングされます。このモデルは、ODI内で通常のリレーショナル・データ・モデルと同様に使用されます。リレーショナル・スキーマ・データで実行されたすべての変更(挿入/更新)は、ドライバによって、ただちにLDAPデータに反映されます。

このドライバの詳細は、付録A「Oracle Data Integrator Driver for LDAPの参照情報」を参照してください。

22.1.2 ナレッジ・モジュール

Oracle Data Integratorには、LDAPテクノロジ専用のナレッジ・モジュール(KM)は用意されていません。LDAPは、SQLデータ・サーバーとして使用できます。LDAPデータ・サーバーでは、SQLデータ・サーバーをソース指定またはターゲット指定するテクノロジ固有のKMと汎用KMの両方がサポートされています。これらのKMの詳細は、第4章「汎用SQL」またはテクノロジの章を参照してください。

22.2 インストールおよび構成

LDAPテクノロジでの作業を開始する前に、この項の情報を必ず読んでください。

- システム要件

- テクノロジ固有の要件

- 接続性要件

22.2.1 システムの要件

インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。

サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。

http://www.oracle.com/technology/products/oracle-data-integrator/index.html

22.2.2 テクノロジ固有の要件

Oracle Data IntegratorでLDAPディレクトリを使用するためのテクノロジ固有の要件はありません。

22.2.3 接続性要件

この項では、LDAPデータベースに接続するための要件をリストします。

Oracle Data Integrator Driver for LDAP

LDAPディレクトリへのアクセスは、Oracle Data Integrator Driver for LDAPを介して行われます。このJDBCドライバは、Oracle Data Integratorとともにインストールされます。

LDAPディレクトリに接続するには、次の接続情報についてシステム管理者に問い合せてください。

- ディレクトリに接続するためのURL。

- ディレクトリに接続するためユーザーおよびパスワード。

- 基本識別名(ベースDN)。これは、ODIがアクセスするLDAPツリー内の場所です。

参照LDAPツリー構造およびドライバの外部記憶域データベースへの接続が必要になる場合もあります。これらの概念および構成パラメータの詳細は、付録B「Oracle Data Integrator Driver for XMLの参照情報」を参照してください。

22.3 トポロジの設定

トポロジの設定には次が含まれます。

1. LDAPデータ・サーバーの作成

2. LDAP用物理スキーマの作成

22.3.1 LDAPデータ・サーバーの作成

各LDAPデータ・サーバーは、Oracle Data Integratorにアクセス可能な1つのLDAPツリーに対応します。

22.3.1.1 データ・サーバーの作成

『Oracle Data Integratorでの統合プロジェクトの開発』のデータ・サーバーの作成に関する項の説明に従って、標準の手順を使用してLDAPテクノロジ用のデータ・サーバーを作成します。この項では、LDAPデータ・サーバーの定義に関する必須または固有のフィールドのみについて説明します。

1. 「定義」タブ:

- 名前: Oracle Data Integratorに表示されるデータ・サーバーの名前。

- ユーザー/パスワード: LDAPディレクトリ・ユーザーの名前およびパスワード。

2. 使用するドライバに応じて、「JDBC」タブに次の値を入力します。

- JDBCドライバ: com.sunopsis.ldap.jdbc.driver.SnpsLdapDriver

- JDBC URL: ドライバでサポートされるURL書式は次の2つです。

- jdbc:snps:ldap?<property>=<value>[&<property>=<value>...]

- jdbc:snps:ldap2?<property>=<value>[&<property>=<value>...]

この2つのURLでは、表22-1に示されている主要なプロパティが受け入れられます。これらのプロパティの詳細な説明およびJDBCドライバの全プロパティの包括的なリストは、付録Aの「ドライバの構成」の項を参照してください。

注意:
最初のURLでは、LDAPディレクトリのパスワードをエンコードする必要があります。2番目のURLでは、LDAPディレクトリのパスワードをエンコードせずに指定できます。最初のURLを使用して、LDAPディレクトリのパスワードを保護することをお薦めします。

表22-1 JDBC URLのプロパティ

プロパティ

値

説明

ldap_auth

<認証モード>

LDAPディレクトリの認証方式。表A-1のauthプロパティを参照してください。

ldap_url

<LDAP URL>

LDAPディレクトリのURL。URLには空白を含めないでください。URLに空白がある場合は、その空白を%20に置き換えてください。

表A-1のurlプロパティを参照してください。

ldap_user

<LDAPユーザー名>

LDAPディレクトリのユーザー名。表A-1のuserプロパティを参照してください。

ldap_password

<LDAPユーザー・パスワード>

LDAPディレクトリ・ユーザーのパスワード。jdbc:snps:ldap URL構文を使用する場合は、このパスワードをエンコードする必要があります。

表A-1のpasswordプロパティを参照してください。

ldap_basedn

<ベースDN>

LDAPディレクトリのベースDN。ベースDNには空白を含めないでください。ベースDNに空白がある場合は、その空白を%20に置き換えてください。

表A-1のbasednプロパティを参照してください。

URLの例

ユーザーorcladminを使用して、サーバーOHOST_OIDおよびポート3060にあるOracle Internet Directoryに接続し、ベースDN dc=us,dc=oracle,dc=comからこのディレクトリ・ツリーにアクセスする場合は、次のURLを使用できます。

jdbc:snps:ldap?ldap_url=ldap://OHOST_OID:3060/
&ldap_basedn=dc=us,dc=oracle,dc=com
&ldap_password=ENCODED_PASSWORD
&ldap_user=cn=orcladmin

22.3.2 LDAP用物理スキーマの作成

『Oracle Data Integratorの管理』の物理スキーマの作成に関する項の説明に従って、標準の手順を使用してLDAP物理スキーマを作成します。

『Oracle Data Integratorの管理』の論理スキーマの作成に関する項の説明に従って、標準の手順を使用してこの物理スキーマ用の論理スキーマを作成し、特定のコンテキストで関連付けます。

22.4 統合プロジェクトの設定

LDAPデータベースを使用してプロジェクトを設定するには、標準の手順に従います。『Oracle Data Integratorでの統合プロジェクトの開発』の統合プロジェクトの作成に関する項を参照してください。

作業を開始するにあたり、使用するプロジェクトに次のナレッジ・モジュールをインポートすることをお薦めします。

- LKM SQL to SQL

- LKM File to SQL

- IKM SQL Control Append

22.5 LDAPディレクトリの作成およびリバース・エンジニアリング

この項には次のトピックが含まれます:

- LDAPモデルの作成

- LDAPモデルのリバース・エンジニアリング

22.5.1 LDAPモデルの作成

データ・モデルによって、一連のデータストアがグループ化されます。各データストアは、1つのディレクトリに関連して、1つのクラスまたはクラスのグループを表します。通常、クラスは表に、属性は列にマップされます。詳細は、付録Aの「LDAPからリレーショナルへのマッピング」の項を参照してください。

『Oracle Data Integratorでの統合プロジェクトの開発』のモデルの作成に関する項の説明に従って、標準の手順を使用してLDAPモデルを作成します。

22.5.2 LDAPモデルのリバース・エンジニアリング

LDAPでは、LDAPドライバの機能のみを使用する標準のリバース・エンジニアリングがサポートされています。

LDAPドライバのリバース・エンジニアリング・プロセスによってLDAPツリーがリレーショナル・データベース構造に変換させる際に、ツリー内のオブジェクト・セットに基づいて表が構成されます。

これらの2つの間のマッピングを維持するためには、これらの表の名前に、この元の構造を反映させる必要があります。その結果として表名は元のLDAPオブジェクト名で構成され、マッピングのデータストア名には適さない、非常に長い名前になる可能性があります。

この解決策として、短く分かりやすい表名の別名を含む別名ファイルを作成します。詳細は、付録Aの「表の別名の構成」の項を参照してください。

標準のリバース・エンジニアリング

LDAPで標準のリバースエンジニアリングを実行するには、『Oracle Data Integratorでの統合プロジェクトの開発』のモデルのリバースエンジニアリングに関する項の説明に従って、通常の手順を使用します。

標準のリバース・エンジニアリング・プロセスでは、LDAPツリーのコンテンツがリレーショナル・データベース構造に自動的にマップされます。これらの表には、ディレクトリ階層をマップするための主キーおよび外部キーの列が自動的に含まれます。

また、リバース・エンジニアリング・プロセスでは、下位のLDAPエントリ・ポイントからLDAPツリー構造のルートを表すROOT表も作成されます。

詳細は、付録Aの「LDAPプロセスの概要」の項を参照してください。

22.6 マッピングの設計

LDAPエントリをマッピングのソースまたはターゲットとして使用できます。

マッピングまたはチェック用に選択したKMによって、このマッピングまたはチェックの機能およびパフォーマンスが決まります。この項に示す推奨事項は、LDAPデータ・サーバーに関連する様々な状況でのKMの選択に役立ちます。

22.6.1 LDAPとの間でのデータのロード

LDAPディレクトリは、マッピングのソースまたはターゲットとして使用できます。「ロード・ナレッジ・モジュール」タブでの、LDAPエントリと別のタイプのデータ・サーバー間でデータをロードするためのLKMの選択は、マッピングのパフォーマンスに関してきわめて重要です。

22.6.1.1 LDAPディレクトリからのデータのロード

汎用SQL KMまたは関係するもう一方のテクノロジ固有のKMを使用して、LDAPデータベースからターゲットまたはステージング領域のデータベースへデータをロードします。

LDAPソースからステージング領域へのロードに使用できるKMの例を表22-2に示します。

表22-2 LDAPからステージング領域へロードするためのKM

ステージング領域

KM

説明

Microsoft SQL Server

LKM SQL to MSSQL (BULK)

SQL Serverのバルク・ローダーを使用します。

Oracle

LKM SQL to Oracle

汎用LKMより高速です(統計を使用)。

Sybase

LKM SQL to Sybase ASE (BCP)

Sybaseのバルク・ローダーを使用します。

すべて

LKM SQL to SQL

汎用KM

22.6.1.2 LDAPディレクトリへのデータのロード

LDAPディレクトリをステージング領域として使用することはお薦めしません。

22.6.2 LDAPディレクトリでのデータの統合

LDAPをマッピングのターゲットとして使用できます。「統合ナレッジ・モジュール」タブのIKMの選択によって、統合のパフォーマンスおよび可能性が決まります。

汎用SQL KMまたは関係するもう一方のテクノロジ固有のKMを使用して、LDAPディレクトリにデータを統合します。

ステージング領域からLDAPターゲットへのデータの統合に使用できるKMの例を表22-3に示します。

表22-3 LDAPディレクトリにデータを統合するためのKM

モード

KM

説明

追加

IKM SQL to SQL Append

汎用KM

22.7 トラブルシューティング

この項では、Oracle Data IntegratorでのLDAPの使用時に発生する可能性がある問題のトラブルシューティングに関する情報を提供します。この章の内容は、次のとおりです。

- リレーショナル・モデルで実行されたSQL操作(挿入、更新、削除)がLDAPディレクトリに伝播されない。
リレーショナル・モデルの格納に外部RDBMSを使用している可能性があります。

- java.util.MissingResourceException: Can't find bundle for base name ldap_....
プロパティ・バンドル・ファイルがないか、不正なディレクトリにある、もしくはファイル名が不正です。

- java.sql.SQLException: A NamingException occurred saying: [LDAP: error code 32 ....
接続プロパティ・バンドルが正しくない可能性があります。バンドル・ファイルでプロパティ値を確認してください。

- java.sql.SQLException: A NamingException occurred saying: [LDAP: error code 49 - Invalid Credentials]
認証プロパティが正しくない可能性があります。パスワードを確認してください。

- java.sql.SQLException: Exception class javax.naming.NameNotFoundException occurred saying: [LDAP: error code 32 - No Such Object].
LDAPツリー・エントリ・ポイントが正しくない可能性があります。LDAP URLのターゲットDistinguishedNameを確認してください。

- java.sql.SQLException: No suitable driver
このエラー・メッセージは、URLを処理できるドライバが登録されていないことを示します。JDBC URLが正しくない可能性があります。URL構文が有効であることを確認してください。A.3項「インストールおよび構成」を参照してください。

23 Oracle TimesTen In-Memory Database

この章では、Oracle Data IntegratorでのOracle TimesTen In-Memory Databaseの使用方法について説明します。

この章には次の項が含まれます:

- 23.1項「はじめに」

- 23.2項「インストールおよび構成」

- 23.3項「トポロジの設定」

- 23.4項「統合プロジェクトの設定」

- 23.5項「TimesTenモデルの作成およびリバース・エンジニアリング」

- 23.6「データ品質の設定」

- 23.7項「マッピングの設計」

23.1 はじめに

Oracle TimesTen In-Memory Database (TimesTen)には、リアルタイムのデータ管理機能が備えられています。業界標準インタフェースを介してアクセスする、メモリーが最適化されたアーキテクチャ上に構築された、アプリケーション層データベースおよびトランザクション管理が用意されています。オプションのデータ・レプリケーションおよびOracleキャッシュによって製品を拡張すると、複数ノードおよび複数層構成が可能になり、これにより、ネットワーク接続され、大容量のメモリーを利用できる最新のコンピューティング・プラットフォームが持つパフォーマンスを最大限に活用できます。

Oracle TimesTen In-Memory Databaseは、メモリーが最適化されたリレーショナル・データベースです。TimesTenは、アプリケーション層にデプロイされ、標準のSQLインタフェースを使用して、物理メモリーに完全に格納されたデータベースで動作します。インメモリー・データベースの高可用性は、リアルタイム・トランザクション・レプリケーションを介して提供されます。

TimesTenでは、JDBC (Java Database Connectivity)およびPL/SQL (Oracle procedural language extension for SQL)を含む、様々なプログラミング・インタフェースがサポートされています。

23.1.1 概念

TimesTenの概念は、次のようにOracle Data Integratorの概念にマップされます。1つのOracle TimesTen In-Memory Databaseインスタンスは、Oracle Data Integratorの1つのデータ・サーバーに対応します。このデータベース・インスタンス内で、データベースと所有者のペアが1つのOracle Data Integrator物理スキーマに対応します。1つのデータベース内の一連の関連オブジェクトは1つのデータ・モデルに対応し、各表、ビューまたはシノニムは、その属性、列および制約とともに、ODIデータストアとして示されます。

Oracle Data Integratorでは、Java Database Connectivity (JDBC)を使用してOracle TimesTen In-Memory Database ODBC DSNに接続します。

23.1.2 ナレッジ・モジュール

Oracle Data Integratorには、表23-1に示されている、TimesTenデータを処理するためのナレッジ・モジュール(KM)が用意されています。これらのKMではTimesTen固有の機能が使用されます。TimesTenデータベースでは、汎用SQL KMを使用することもできます。詳細は、第4章「汎用SQL」を参照してください。

表23-1 TimesTen KM

ナレッジ・モジュール

説明

IKM TimesTen Incremental Update (MERGE)

増分更新モードでTimesTen JDBCドライバを使用して、ステージング領域からTimesTenのターゲット表にデータを統合します。たとえば、存在しない行は挿入され、既存の行は更新されます。

LKM SQL to TimesTen

TimesTen JDBCドライバを使用して、ANSI SQL-92ソースからTimesTenのステージング表にデータをロードします。

LKM File to TimesTen (ttBulkCp)

ttBulkCpユーティリティを使用して、ファイルからTimesTenのステージング表へデータをロードします。

23.2 インストールおよび構成

TimesTenナレッジ・モジュールの使用を開始する前に、この項の情報を必ず読んでください。

- システム要件および動作要件

- テクノロジ固有の要件

- 接続性要件

23.2.1 システム要件および動作要件

インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。

サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。

http://www.oracle.com/technology/products/oracle-data-integrator/index.html

23.2.2 テクノロジ固有の要件

TimesTenの一部のナレッジ・モジュールでは、ttBulkCpユーティリティが使用されます。

これらのナレッジ・モジュールには、次の要件および制限が適用されます。

- ジョブを実行するODIエージェントのホストには、TimesTen Clientユーティリティがインストールされている必要があります(TTBULKCP)。

- データ変換は、ステージング領域またはターゲットで実行される必要があります。

- エージェント・マシン上に、次の正しいODBCエントリが作成される必要があります。

- クライアントDSN: クライアントDSNにより、リモート・データベースが指定され、TimesTen Clientが使用されます。クライアントDSNは、ホスト名とDSNのペアを指定することにより、間接的にTimesTenデータベースを参照します。ホスト名はTimesTen Serverが実行されているサーバー・マシンを表し、DSNはサーバー・ホスト上のTimesTenデータベースを指定するサーバーDSNを表します。

- サーバーDSN: サーバーDSNは常にシステムDSNとして定義され、クライアント・アプリケーションがアクセスする、そのサーバー上の各データベースのサーバー・システム上で定義されます。サーバーDSNの形式および属性は、Data Manager DSNのものと似ています。

23.2.3 接続性要件

この項では、TimesTenデータベースに接続するための要件をリストします。

Microsoft Excelデータにアクセスするための要件は次のとおりです。

- TimesTen ODBCドライバのインストール

- TimesTen ODBCデータソースの宣言

- JDBCドライバ

- ODIエージェント

TimesTen ODBCドライバのインストール

Microsoft Excelワークブックにアクセスできるのは、ODBC接続を使用した場合のみです。使用するシステムに、TimesTen用ODBCドライバがインストールされている必要があります。

TimesTen ODBCデータソースの宣言

ODBCデータソースは、ODIからアクセスするそれぞれのMicrosoft Excelワークブック(.xlsファイル)に対して定義する必要があります。ODBCデータソースは、Microsoft ODBCデータソース・アドミニストレータで作成します。データソースの作成方法は、Microsoft Windowsオペレーティング・システムのドキュメントを参照してください。

JDBCドライバ

Oracle Data Integratorでは、TimesTen JDBCドライバを使用してTimesTenデータベースに接続します。このドライバをOracle Data Integratorのdriversディレクトリにインストールする必要があります。

ODIエージェント

ジョブを実行するODIエージェントには、TimesTen JDBCドライバおよびODBCドライバがインストールされ、構成されている必要があります。

23.3 トポロジの設定

トポロジの設定には次が含まれます。

1. TimesTenデータ・サーバーの作成

2. TimesTen物理スキーマの作成

23.3.1 TimesTenデータ・サーバーの作成

TimesTenデータ・サーバーはTimesTenデータベースに対応します。

23.3.1.1 データ・サーバーの作成

『Oracle Data Integratorでの統合プロジェクトの開発』のデータ・サーバーの作成に関する項の説明に従って、標準の手順を使用してTimesTenテクノロジ用のデータ・サーバーを作成します。この項では、TimesTenデータ・サーバーの定義に関する必須または固有のフィールドのみについて説明します。

1. 「定義」タブ:

- 名前: Oracle Data Integratorに表示されるデータ・サーバーの名前

- サーバー: データ・サーバーの物理名

- ユーザー/パスワード: TimesTenユーザーおよびそのパスワード

2. 「JDBC」タブ:

- JDBCドライバ: org.TimesTen.Driver

- JDBC URL: jdbc:timesten:direct:dsn=<DSNname>
DSNnameは、エージェントを実行するマシン上で構成されているODBCデータソースの名前です。

注意:
Oracle Data Integratorが書込みアクセス権を持つのは、URLで指定されたデータベースのみです。

23.3.2 TimesTen物理スキーマの作成

『Oracle Data Integratorの管理』の物理スキーマの作成に関する項の説明に従って、標準の手順を使用してTimesTen物理スキーマを作成します。

『Oracle Data Integratorの管理』の論理スキーマの作成に関する項の説明に従って、標準の手順を使用してこの物理スキーマ用の論理スキーマを作成し、特定のコンテキストで関連付けます。

23.4 統合プロジェクトの設定

TimesTenデータベースを使用してプロジェクトを設定するには、標準の手順に従います。『Oracle Data Integratorでの統合プロジェクトの開発』の統合プロジェクトの作成に関する項を参照してください。

TimesTenでの作業を開始するにあたり、使用するプロジェクトに次のナレッジ・モジュールをインポートすることをお薦めします。

- CKM SQL

- IKM SQL Control Append

- IKM TimesTen Incremental Update (MERGE)

- LKM SQL to TimesTen

- LKM File to TimesTen (ttBulkCp)

- RKM SQL (Jython)

23.5 TimesTenモデルの作成およびリバース・エンジニアリング

この項には次のトピックが含まれます:

- TimesTenモデルの作成

- TimesTenモデルのリバース・エンジニアリング

23.5.1 TimesTenモデルの作成

『Oracle Data Integratorでの統合プロジェクトの開発』のモデルの作成に関する項の説明に従って、標準の手順を使用してTimesTenモデルを作成します。

23.5.2 TimesTenモデルのリバース・エンジニアリング

TimesTenでは、JDBCドライバの機能のみを使用する標準のリバース・エンジニアリング、およびカスタマイズされたリバース・エンジニアリングの両方がサポートされています。

通常は、標準のJDBCリバース・エンジニアリングを使用して作業を開始することを検討してください。

TimesTen JDBCドライバの特異性によって、標準のJDBCリバース・エンジニアリング・プロセスで問題が発生した場合は、カスタマイズされたリバース・エンジニアリングへの切替えを検討してください。

標準のリバース・エンジニアリング

TimesTenで標準のリバースエンジニアリングを実行するには、『Oracle Data Integratorでの統合プロジェクトの開発』のモデルのリバースエンジニアリングに関する項の説明に従って、通常の手順を使用します。

カスタマイズされたリバース・エンジニアリング

RKMを使用してTimesTenでカスタマイズされたリバースエンジニアリングを実行するには、『Oracle Data Integratorでの統合プロジェクトの開発』のモデルのリバースエンジニアリングに関する項の説明に従って、通常の手順を使用します。この項では、TimesTenテクノロジ固有のフィールドのみについて説明します。

1. TimesTenモデルの「リバース・エンジニアリング」タブでKM: RKM SQL (Jython).<project name>を選択します。

リバース・エンジニアリングによって、表、ビュー、属性、キーおよび外部キーが戻されます。

23.6 データ品質の設定

Oracle Data Integratorには、TimesTen表で定義された制約と照合してデータの整合性をチェックするためのCKM SQLが用意されています。詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』のフロー制御および静的制御に関する項を参照してください。

詳細は、第4章「汎用SQL」を参照してください。

23.7 マッピングの設計

マッピングのソース、ステージング領域またはターゲットとしてTimesTenを使用できます。

マッピングまたはチェック用に選択したKMによって、このマッピングまたはチェックの機能およびパフォーマンスが決まります。この項に示す推奨事項は、TimesTenデータ・サーバーに関連する様々な状況でのKMの選択に役立ちます。

23.7.1 TimesTenとの間でのデータのロード

マッピングのソース、ターゲットまたはステージング領域としてTimesTenを使用できます。「ロード・ナレッジ・モジュール」タブでの、TimesTenと別のタイプのデータ・サーバー間でデータをロードするためのLKMの選択は、マッピングのパフォーマンスに関してきわめて重要です。

23.7.1.1 TimesTenからのデータのロード

汎用SQL KMまたは関係するもう一方のテクノロジ固有のKMを使用して、TimesTenデータベースからターゲットまたはステージング領域のデータベースへデータをロードします。

TimesTenステージング領域からTimesTenの表にデータを抽出するには、IKM TimesTen Incremental Update (MERGE)を使用します。詳細は、23.7.1.1項「TimesTenからのデータのロード」を参照してください。

23.7.1.2 TimesTenへのデータのロード

Oracle Data Integratorには、ソースまたはステージング領域からTimesTenデータベースへデータをロードするための最適化された方法を実装するナレッジ・モジュールが用意されています。これらの最適化されたTimesTen KMを表23-2にリストします。これらのKM以外に、汎用SQL KMまたは関係するもう一方のテクノロジ固有のKMも使用できます。

表23-2 TimesTenにデータをロードするためのKM

ソースまたはステージング領域のテクノロジ

KM

説明

SQL

LKM SQL to TimesTen

TimesTen JDBCドライバを使用して、ANSI SQL-92ソースからTimesTenのステージング表にデータをロードします。

ファイル

LKM File to TimesTen (ttBulkCp)

ttBulkCpユーティリティを使用して、ファイルからTimesTenのステージング表へデータをロードします。

23.7.2 TimesTenへのデータの統合

Oracle Data Integratorには、TimesTen用に最適化されたデータ統合戦略を実装するナレッジ・モジュールが用意されています。これらの最適化されたTimesTen KMを表23-3にリストします。これらのKM以外に、汎用SQL KMも使用できます。

「統合ナレッジ・モジュール」タブのIKMの選択によって、統合のパフォーマンスおよび可能性が決まります。

表23-3 TimesTenにデータを統合するためのKM

KM

説明

IKM TimesTen Incremental Update (MERGE)

増分更新モードでTimesTen JDBCドライバを使用して、ステージング領域からTimesTenのターゲット表にデータを統合します。たとえば、存在しない行は挿入され、既存の行は更新されます。

24 Oracle GoldenGate

この章では、Oracle Data Integratorマッピングで使用するためにソース・トランザクション・システムでの変更をキャプチャしてステージング・サーバーでレプリケートするための、Oracle GoldenGateの使用方法について説明します。

この章には次の項が含まれます:

- 24.1項「はじめに」

- 24.2項「インストールおよび構成」

- 24.3項「Oracle GoldenGate JKMの使用」

- 24.4項「拡張構成」

- 24.5項「統合キャプチャ」

- 24.6項「異なるキャプチャおよび適用モードの併用」

- 24.7項「異なるプロセス・モードへの切替え」

- 24.8項「クラシック・モードから統合モードへのGoldenGate Extractのアップグレード」

24.1 はじめに

Oracle GoldenGate (OGG)製品によるソリューションでは、継続的な可用性を実現し、リアルタイムの情報を提供する主要なビジネス・アプリケーションが提供されます。異種のデータベースや環境間で、キャプチャ、ルーティング、変換および配信をリアルタイムに行うことが保証されます。

Oracle GoldenGateナレッジ・モジュールを使用するには、Oracle GoldenGateの概念およびアーキテクチャを理解しておく必要があります。詳細は、OTNにあるOracle GoldenGateのドキュメントを参照してください。

http://www.oracle.com/technetwork/middleware/goldengate/overview/index.html

24.1.1 GoldeGate CDCプロセスの概要

Oracle Data Integratorでは、Oracle GoldenGateを使用してソース・データベースの変更をキャプチャして、ODI CDCフレームワークで処理できます。Oracle Data Integratorでは、Oracle GoldenGateを使用してソース・データベースからステージング・データベースへ、データをレプリケートします。このステージング・データベースには、ソース表のコピーおよびODI Changed Data Capture (CDC)インフラストラクチャが含まれ、どちらもOracle GoldenGateを使用してロードされます。

ステージング・データベースはOracleまたはTeradataスキーマに格納されます。ソース・データベースとして使用できるのは、Oracle、Microsoft SQL Server、DB2 UDBまたはSybase ASEです。この章の<database>という表記は、これらのソース・データベース・テクノロジのいずれかを意味します。

GoldenGateでのCDCの設定は、次の手順で行われます。

1. ソース表のレプリカは、Oracle Data Integratorの共通フォーマット・デザイナ機能などを使用して、ステージング・データベースに作成されます。

2. Oracle Data Integrator Changed Data Capture (CDC)は、JKM <database> to Oracle Consistent (OGG Online)またはJKM <database> to Teradata Consistent (OGG Online)のいずれかを使用して、ソース表でアクティブ化されます。

3. ジャーナルが、オンライン・モードまたはオフライン・モードのどちらかで開始されます。

- オンライン・モード: オンライン・モードでジャーナルを開始するとGoldenGateキャプチャ(Extract)プロセスが構成および開始されてソース・データベースの変更がキャプチャされ、対応する配信(Replicat)プロセスがステージング・データベースの変更をレプリケートします。変更は、レプリケートされたソース表とCDCインフラストラクチャの両方にレプリケートされます。
GoldenGateのキャプチャおよび配信プロセスは、GoldenGate JAgentインタフェースを使用してデプロイおよび開始されます。GoldenGate JAgentを使用すると、Oracle Data IntegratorとOracle GoldenGateの間の通信が簡単になります。

- オフライン・モード: オフライン・モードでジャーナルを開始すると、Oracle GoldenGate構成ファイルが作成され、ステージング・データベースにCDCインフラストラクチャが設定されます。この段階では、ソース・データをキャプチャするためのアクティブなプロセスは開始されません。
生成された構成ファイルを使用してOracle GoldenGateキャプチャ・プロセスが構成され、ソース・データベースからの変更のキャプチャが開始されます。また、対応する配信プロセスが構成され、ステージング・データベースへのこれらの変更のレプリケートが開始されます。変更は、レプリケートされたソース表とCDCインフラストラクチャの両方にレプリケートされます。

GoldenGateを任意に構成して、ステージング表へのソース・データの初期ロードを実行できます。

4. ODIマッピングでは、レプリケートされた表をソースとして使用し、キャプチャされた変更を任意のODIシナリオ内でシームレスに使用できます。

24.1.2 ナレッジ・モジュール

Oracle Data Integratorには、表24-1に示されている、ソースからステージング・データベースにオンライン・データをレプリケートするためのナレッジ・モジュールが用意されています。他のCDC JKMと同様に、Oracle GoldenGate JKMはソース・サーバーのデータをジャーナル化します。

JKM <database> to Oracle Consistent (OGG Online)とJKM <database> to Teradata Consistent (OGG Online)では、次の同じタスクが実行されます。

- レプリケートされた表で、ODI CDCフレームワーク・インフラストラクチャの作成および管理を行います。

- ジャーナルがオンライン・モードで開始された場合は、GoldenGate JAgentを使用してGoldenGateサーバーのOracleキャプチャおよび配信プロセスを構成および開始します。

- ジャーナルがオフライン・モードで開始された場合は、Oracle GoldenGateキャプチャおよび配信プロセスを設定するパラメータ・ファイルおよび設定を完了する方法を説明するReadme.txtを生成します。

- ソース・データベースの構成をチェックするための追加の手順を提供し、構成を修正するためのヒントを提示します。

表24-1 Oracle GoldenGateナレッジ・モジュール

ナレッジ・モジュール

説明

JKM Oracle to Oracle Consistent (OGG Online)

Oracleステージング・サーバーで一貫性セット・ジャーナル化のインフラストラクチャを作成し、Oracleソースからこのステージング・サーバーへデータをレプリケートするためのOracle GoldenGateの構成を生成します。

JKM DB2 UDB to Oracle Consistent (OGG Online)

Oracleステージング・サーバーで一貫性セット・ジャーナル化のインフラストラクチャを作成し、IBM DB2 UDBソースからこのステージング・サーバーへデータをレプリケートするためのOracle GoldenGateの構成を生成します。

JKM Sybase ASE to Oracle Consistent (OGG Online)

Oracleステージング・サーバーで一貫性セット・ジャーナル化のインフラストラクチャを作成し、Sybase ASEソースからこのステージング・サーバーへデータをレプリケートするためのOracle GoldenGateの構成を生成します。

JKM MSSQL to Oracle Consistent (OGG Online)

Oracleステージング・サーバーで一貫性セット・ジャーナル化のインフラストラクチャを作成し、Microsoft SQL Serverソースからこのステージング・サーバーへデータをレプリケートするための、Oracle GoldenGateの構成を生成します。

JKM Oracle to Teradata Consistent (OGG Online)

Teradataステージング・サーバーで一貫性セット・ジャーナル化のインフラストラクチャを作成し、Oracleソースからこのステージング・サーバーへデータをレプリケートするためのOracle GoldenGateの構成を生成します。

JKM DB2 UDB to Teradata Consistent (OGG Online)

Teradataステージング・サーバーで一貫性セット・ジャーナル化のインフラストラクチャを作成し、IBM DB2 UDBソースからこのステージング・サーバーへデータをレプリケートするためのOracle GoldenGateの構成を生成します。

JKM Sybase ASE to Teradata Consistent (OGG Online)

Teradataステージング・サーバーで一貫性セット・ジャーナル化のインフラストラクチャを作成し、Sybase ASEソースからこのステージング・サーバーへデータをレプリケートするためのOracle GoldenGateの構成を生成します。

JKM MSSQL to Teradata Consistent (OGG Online)

Teradataステージング・サーバーで一貫性セット・ジャーナル化のインフラストラクチャを作成し、Microsoft SQL Serverソースからこのステージング・サーバーへデータをレプリケートするためのOracle GoldenGateの構成を生成します。

24.2 インストールおよび構成

Oracle GoldenGateナレッジ・モジュールの使用を開始する前に、この項の情報を必ず読んでください。

- システム要件および動作要件

- テクノロジ固有の要件

24.2.1 システム要件および動作要件

インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。

サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。

http://www.oracle.com/technology/products/oracle-data-integrator/index.html

プラットフォームでサポートされるソースおよびステージング・データベースのバージョンに関して、OTNにあるOracle GoldenGateのドキュメントも参照してください。

24.2.2 テクノロジ固有の要件

キャプチャおよび配信プロセスを実行するには、ソースおよびステージング・サーバーの両方にOracle GoldenGateをインストールしておく必要があります。Oracle GoldenGateをインストールすると、GoldenGateのプロセスの実行および管理に必要なすべてのコンポーネントがインストールされます。

キャプチャまたは配信を開始するには、Oracle GoldenGateのManagerプロセスがそれぞれのシステムで稼働している必要があり、リソース管理のために、キャプチャまたは配信の実行中も稼働していることが必要です。

オンライン・ジャーナル化を実行するためには、Oracle GoldenGateのインスタンス上にOracle GoldenGate JAgentプロセスを構成し、実行する必要があります。

Oracle GoldenGateには固有の要件およびインストール手順があり、Oracle GoldenGate JKMを使用して構成されるキャプチャおよび配信プロセスを開始する前に、このインストール手順を実行しておく必要があります。詳細は、OTNにあるOracle GoldenGateのドキュメントを参照してください。

24.2.3 接続性要件

ソース・データベースがOracleの場合、Oracle Data IntegratorでOracle GoldenGateデータを使用するための接続性要件はありません。

ソース・データベースがIBM DB2 UDB、Microsoft SQL ServerまたはSybase ASEの場合、Oracle GoldenGateではODBCドライバを使用してソース・データベースに接続します。使用するシステムにODBCドライバをインストールして、データソースを宣言する必要があります。また、KMオプションSRC_DSNで、データソース名(DSN)を設定する必要があります。

24.3 Oracle GoldenGate JKMの使用

Oracle Data Integrator統合プロジェクトでJKM <database> to Oracle Consistent (OGG Online)またはJKM <database> to Teradata Consistent (OGG Online)を使用するには、次の手順を実行する必要があります。

1. トポロジの定義

2. レプリケートされた表の作成

3. 統合プロジェクトの設定

4. ソース・データストアのCDCの構成

5. Oracle GoldenGateプロセスの構成および開始(オフライン・モードのみ)

6. レプリケートされたデータを使用したマッピングの設計

24.3.1 トポロジの定義

この工程には、ステージング・データ・サーバー、ソース・データ・サーバー、およびこれらのサーバーに添付される物理スキーマと論理スキーマをOracle Data Integratorで宣言することが含まれます。

この構成でトポロジを定義するには、次のタスクを実行します。

1. ソース・データ・サーバーの定義

2. ソース物理スキーマの作成

3. ステージング・サーバーの定義

4. ステージング物理スキーマの作成

5. Oracle GoldenGateデータ・サーバーの定義

6. Oracle GoldenGate物理スキーマの作成

7. Oracle GoldenGate論理スキーマの作成

24.3.1.1 ソース・データ・サーバーの定義

Oracle GoldenGateが変更をキャプチャするソース・データ・サーバーを定義する必要があります。

標準の手順で、使用するソース・テクノロジのデータ・サーバーを作成します。詳細は、このガイドの、使用するソース・テクノロジに対応する章を参照してください。

- 2.3.1項「Oracleデータ・サーバーの作成」

- 7.3.1項「Microsoft SQL Serverデータ・サーバーの作成」

このデータ・サーバーは、ソース・データベース・インスタンスを表します。

24.3.1.2 ソース物理スキーマの作成

24.3.1.1項「ソース・データ・サーバーの定義」で作成したデータ・サーバーの下に、物理スキーマを作成します。『Oracle Data Integratorの管理』の物理スキーマの作成に関する項の説明に従って、標準の手順を使用します。

『Oracle Data Integratorの管理』の論理スキーマの作成に関する項の説明に従って、標準の手順を使用してこの物理スキーマ用の論理スキーマを作成し、特定のコンテキストで関連付けます。

24.3.1.3 ステージング・サーバーの定義

OracleまたはTeradataテクノロジ用のデータ・サーバーを作成します。詳細は、次の情報を参照してください:

- 2.3.1項「Oracleデータ・サーバーの作成」

- 11.3.1項「Teradataデータ・サーバーの作成」

24.3.1.4 ステージング物理スキーマの作成

『Oracle Data Integratorの管理』の物理スキーマの作成に関する項の説明に従って、標準の手順を使用してOracleまたはTeradataの物理スキーマを作成します。

注意:
ステージング・サーバーで定義された物理スキーマのデータ・スキーマには、Oracle GoldenGateプロセスによってキャプチャおよびレプリケートされた、変更されたレコードが含まれます。ODI CDCインフラストラクチャの格納には、作業スキーマが使用されます。

『Oracle Data Integratorの管理』の論理スキーマの作成に関する項の説明に従って、標準の手順を使用してこの物理スキーマ用の論理スキーマを作成し、特定のコンテキストで関連付けます。

24.3.1.5 Oracle GoldenGateデータ・サーバーの定義

Oracle GoldenGateデータ・サーバーはOracle Data Integrator (ODI)のOracle GoldenGate JAgentプロセスに対応しています。Oracle GoldenGate JAgentプロセスを使用すると、ODIとOracle GoldenGateサーバーの間の通信が簡単になります。ソースとターゲット両方のOracle GoldenGateサーバーのJAgentプロセスを作成する必要があります。

『Oracle Data Integratorでの統合プロジェクトの開発』のデータ・サーバーの作成に関する項の説明に従って、標準の手順を使用してOracle GoldenGateテクノロジ用のデータ・サーバーを作成します。この項では、Oracle GoldenGateデータ・サーバーの定義に関する必須または固有のフィールドのみについて説明します。

1. 「定義」タブ:

- 名前: Oracle Data Integratorに表示されるデータ・サーバーの名前。

- ホスト: JAgentプロセスが実行されているサーバーのホスト名またはIPアドレス。

- JMXポート: JAgentプロセスのポート番号。

- マネージャ・ポート: Oracle GoldenGateマネージャ・インスタンスのポート番号。

- JMXユーザー: JAgentに接続するユーザー名。

- パスワード: ユーザー資格証明のパスワード。

- インストール・パス: Oracle GoldenGateのインストール場所のパス。モデルからキャプチャ・プロセス定義を作成する際にはこのパスを使用する必要があります。

24.3.1.6 Oracle GoldenGate物理スキーマの作成

ODIのOracle GoldenGate物理スキーマは、Oracle GoldenGateでCDCを実行するGoldenGateのキャプチャおよび配信プロセスに対応しています。ソースGoldenGateサーバーにキャプチャ・プロセスを、ターゲットGoldenGateサーバーに配信プロセスを構成するには、Oracle GoldenGate物理スキーマを定義する必要があります。

24.3.1.5項「Oracle GoldenGateデータ・サーバーの定義」で作成したOracle GoldenGateデータ・サーバーに物理スキーマを作成します。『Oracle Data Integratorの管理』の物理スキーマの作成に関する項の説明に従って、標準の手順を使用します。この項では、Oracle GoldenGateのキャプチャおよびレプリケート・プロセスを構成するための物理スキーマ作成に必須または固有のフィールドのみについて説明します。

注意:
別の方法として、Oracle GoldenGate物理スキーマをモデルから作成することもできます。モデルからの物理スキーマ作成方法の詳細は、24.3.4.1項「モデルからのOracle GoldenGate物理スキーマの作成」を参照してください。

GoldenGateキャプチャ・プロセスのフィールド

GoldenGateキャプチャ・プロセスは、ソースGoldenGateサーバーに構成する必要があります。

1. 「プロセス定義」タブで次のように設定します。

- プロセス・タイプ: 構成するプロセスのタイプ。プロセス・タイプとして「キャプチャ」を選択します。

- 名前: Oracle Data Integratorのプロセス(物理スキーマ)の名前。プロセス名は8文字以内にする必要があり、使用できるのは大文字のみです。

- 証跡ファイル・パス: Oracle GoldenGate証跡ファイルの場所。ファイル名の部分に使用できるのは2文字のみです。

- リモート証跡ファイル・パス: リモート証跡ファイルの場所。ファイル名の部分に使用できるのは2文字のみです。

- 証跡ファイル・サイズ: Oracle GoldenGate証跡ファイルのサイズ(MB)。

- レポート・フェッチ: レポート情報にフェッチ統計を含めることができます。

- レポート数頻度: 特定の間隔における合計操作数をレポートします。間隔が指定されていない場合は、パラメータ・ファイルにエントリが追加されません。

- パラメータを選択: 使用可能なOracle GoldenGateパラメータのリスト。サポートされているデータベースのパラメータのみがリストされます。パラメータを選択して「追加」をクリックします。選択されたパラメータのテンプレートが、テキスト・ボックスに追加されます。
GoldenGateのパラメータの詳細は、OTNのOracle GoldenGateリファレンス・ガイドを参照してください。

配信プロセスのフィールド

GoldenGateの配信プロセスは、ターゲットGoldenGateサーバーで構成する必要があります。

1. 「プロセス定義」タブで次のように設定します。

- プロセス・タイプ: 構成するプロセスのタイプ。プロセス・タイプとして「配信」を選択します。

- 名前: Oracle Data Integratorのプロセス(物理スキーマ)の名前。プロセス名は7文字以内にする必要があり、使用できるのは大文字のみです。

- 証跡ファイル・パス: 証跡ファイルの場所。ファイル名の部分に使用できるのは2文字のみです。

- 破棄ファイルのパス: 破棄ファイルの場所。

- 定義ファイル・パス: 定義ファイルの場所。

- レポート詳細: レポート情報に衝突数を含めることができます。

- レポート数頻度: 特定の間隔における合計操作数をレポートします。間隔が指定されていない場合は、パラメータ・ファイルにエントリが追加されません。

- パラメータを選択: 使用可能なOracle GoldenGateパラメータのリスト。サポートされているデータベースのパラメータのみがリストされます。パラメータを選択して「追加」をクリックします。
GoldenGateのパラメータの詳細は、OTNのOracle GoldenGateリファレンス・ガイドを参照してください。

24.3.1.7 Oracle GoldenGate論理スキーマの作成

24.3.1.6項「Oracle GoldenGate物理スキーマの作成」で作成したGoldenGate物理スキーマ(GoldenGateキャプチャおよび配信プロセス)の論理スキーマを作成します。キャプチャ・プロセスと配信プロセスの両方に論理スキーマを作成する必要があります。

論理スキーマを作成するには、次のようにします。

1. トポロジ・ナビゲータで、「論理アーキテクチャ」アコーディオンの「テクノロジ」ノードを開きます。

2. Oracle GoldenGateを右クリックして、「新規論理スキーマ」を選択します。

3. 「論理スキーマ名」を入力します。

4. 論理スキーマをアタッチする「キャプチャ」または「配信」のどちらか適切なプロセス・タイプを選択します。

5. 左側の列の各コンテキストについて、右側の列で既存の物理スキーマを選択します。この物理スキーマはこのコンテキストの論理スキーマと自動的に関連付けられます。必要なすべてのコンテキストについてこの操作を繰り返します。

6. 「ファイル」メニューから、「保存」をクリックします。

24.3.2 レプリケートされた表の作成

Oracle GoldenGateにより、ソース内で変更されたレコードがステージング・サーバーにレプリケートされます。このレプリケーションを実行するには、ソース表の構造をステージング・サーバーにレプリケートする必要があります。

これらのソース表をレプリケートするには、次のようにします。

1. OracleまたはTeradataテクノロジを使用して新規データ・モデルを作成します。このモデルでは、24.3.1.4項「ステージング物理スキーマの作成」の手順で作成した論理スキーマを使用する必要があります。
モデル作成の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』のモデルの作成に関する項を参照してください。

このデータ・モデルをリバース・エンジニアリングする必要はありません。

2. このモデルの新規ダイアグラムを作成し、レプリケートするソース表をこのダイアグラムに追加します。

3. DDLスクリプトを生成し、これらのスクリプトを実行してステージング・データ・サーバー内に表を作成します。

4. ソース・データの初期ロードを実行すると、このデータをステージング表にレプリケートできます。この初期ロードは、ODIで共通フォーマット・デザイナのインタフェースINの生成機能を使用して実行できます。もしくは、ソース・データストアのCDCの構成の際に、初期ロードを実行するキャプチャまたは配信プロセスを指定するか、USE_OGG_FOR_INIT JKMオプションをYesに設定して初期ロードを実行するためのプロセスを作成し、Oracle GoldenGateを使用して、この初期ロードを実行できます。

注意:
ダイアグラム、DDLの生成、およびインタフェースINの生成機能の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』の共通フォーマット・デザイナによるデータ・モデルの作成に関する項を参照してください。

24.3.3 統合プロジェクトの設定

Oracle GoldenGateの機能を使用してプロジェクトを設定するには、標準の手順に従います。『Oracle Data Integratorでの統合プロジェクトの開発』の統合プロジェクトの作成に関する項を参照してください。

使用するソース・データ・サーバーおよびステージング・サーバーのテクノロジに応じて、使用するプロジェクトに次のいずれかのKMをインポートします。

- JKM Oracle to Oracle Consistent (OGG Online)

- JKM DB2 UDB to Oracle Consistent (OGG Online)

- JKM Sybase ASE to Oracle Consistent (OGG Online)

- JKM MSSQL to Oracle Consistent (OGG Online)

- JKM Oracle to Teradata Consistent (OGG Online)

- JKM DB2 UDB to Teradata Consistent (OGG Online)

- JKM Sybase ASE to Teradata Consistent (OGG Online)

- JKM MSSQL to Teradata Consistent (OGG Online)

24.3.4 ソース・データストアのCDCの構成

ソース・データストアに対してチェンジ・データ・キャプチャを構成する必要があります。この構成は一貫性セット・ジャーナル化の設定に似ており、次の手順を使用して実行します。

1. ソース・データストアを含むデータ・モデルを編集します。データ・モデルの「ジャーナル化」タブで、「ジャーナル化モード」を「一貫性セット」に設定し、適切なJKM <database> to Oracle Consistent (OGG Online)またはJKM <database> to Teradata Consistent (OGG Online)を選択します。
プロセス選択ドロップダウン・リストを使用して、次のGoldenGateプロセス(物理スキーマ)を選択します。

- キャプチャ・プロセス

- 配信プロセス

- 初期ロード・キャプチャ・プロセス

- 初期ロード配信プロセス

既存のGoldenGateプロセスを使用しない場合は、<Process Name> フィールドの横の「作成」ボタンを使用してここから新規プロセスを作成できます。モデルからのGoldenGateプロセス作成方法の詳細は、24.3.4.1項「モデルからのOracle GoldenGate物理スキーマの作成」を参照してください。

次のようにKMのオプションを設定します。

- ONLINE: このオプションをtrueに設定すると、JKMでCDCインフラストラクチャが構成され、GoldenGateのキャプチャおよび配信プロセスが構成および開始されます。このオプションをfalseに設定すると、JKMでCDCインフラストラクチャが生成され、GoldenGateのキャプチャおよび配信プロセスを設定するために必要な構成ファイルが生成されます。また、GoldenGateのプロセスを構成および開始するための手順を説明したReadme.txtも生成されます。
オンラインおよびオフライン・モードの詳細は、24.1.1項「GoldeGate CDCプロセスの概要」を参照してください。

構成ファイルを使用してGoldenGateのプロセスを構成および開始する方法の詳細は、24.3.5項「Oracle GoldenGateプロセスの構成および開始(オフライン・モードのみ)」を参照してください。

- LOCAL_TEMP_DIR: Oracle GoldenGateの構成ファイルが生成される一時フォルダのフル・パス。

- SRC_DSN: データソースの名前。このKMオプションは、ODBCドライバを使用する場合は必須です。このオプションは、JKM Oracle to Oracle Consistent (OGG Online)には含まれていません。

注意:
Sybaseユーザーのみ: データソース名を定義する際には、次のようにデータソース名にデータベース・サーバー名を追加する必要があります。
DSN_name@SYBASE_DBSERVER

- USE_OGG_FOR_INIT: オフライン・モードのみに適用可能。Oracle GoldenGateプロセスを生成して、レプリケートされた表の初期ロードを実行します。レプリケートされた表の作成時にOracle Data Integratorでこの初期ロードを実行した場合、このオプションはNOのままで構いません。

- USE_INTEGRATED_REPLICAT_MODE: このKMオプションは、配信モードがクラシックまたは統合Replicatの場合に必要です。
値

True: 統合Replicatモードを使用します。

False: クラシック・モードを使用します(デフォルト値)。

このパラメータが実装されているのは、次のKMのみです。

KM_JKM DB2 UDB to Oracle Consistent (OGG Online).xml

KM_JKM MSSQL to Oracle Consistent (OGG Online).xml

KM_JKM Oracle to Oracle Consistent (OGG Online).xml

KM_JKM Sybase ASE to Oracle Consistent (OGG Online).xmlKM_JKM DB2 UDB to Oracle Consistent (OGG Online).xml

KM_JKM MSSQL to Oracle Consistent (OGG Online).xml

KM_JKM Oracle to Oracle Consistent (OGG Online).xml

KM_JKM Sybase ASE to Oracle Consistent (OGG Online).xml

2. レプリケートするデータストアまたはモデル(すべてのデータストアをレプリケートする場合)を選択して右クリックし、「チェンジ・データ・キャプチャ」→「CDCに追加」を選択します。

3. モデルを選択して右クリックし、「チェンジ・データ・キャプチャ」→「サブスクライバ」→「サブスクライブ」を選択します。このモデルのサブスクライバを追加します。

4. モデルを選択して右クリックし、「チェンジ・データ・キャプチャ」→「ジャーナルの開始」を選択します。ジャーナルがオンライン・モードで開始される(JKMのONLINEオプションがtrueに設定されている)と、JKMではCDCインフラストラクチャが作成され、Oracle GoldenGateプロセスが構成および開始されます。ジャーナルがオフライン・モードで開始される(JKMのONLINEオプションがfalseに設定されている)と、JKMではCDCインフラストラクチャが作成され、Oracle GoldenGateプロセスを構成するために必要な構成ファイルが生成されます。また、GoldenGateのプロセスを構成および開始するための手順を説明したReadme.txtも生成されます。
GoldenGateプロセスを構成および開始する方法の詳細は、24.3.5項「Oracle GoldenGateプロセスの構成および開始(オフライン・モードのみ)」を参照してください。

ジャーナルの起動アクションの結果は、次のように確認できます。

- ジャーナルをオンライン・モードで開始すると、Oracle GoldenGateプロセスが構成および開始されます。ソース・データストアで変更されたデータがステージング表でキャプチャおよびレプリケートされます。

- ジャーナルをオフライン・モードで開始すると、Oracle GoldenGateの構成ファイルおよびReadme.txtファイルが、LOCAL_TEMP_DIR KMオプションで指定されたディレクトリに生成されます。これらのファイルを使用してOracle GoldenGateプロセスの構成および開始(オフライン・モードのみ)を行えます。

- CDCインフラストラクチャが正しく設定されます。ジャーナル化されたデータストアが「モデル」アコーディオンに表示され、ジャーナル化のアクティブ・フラグが設定されます。モデルを右クリックして「チェンジ・データ・キャプチャ」→「ジャーナル・データ」を選択すると、これらのデータストアのジャーナル化されたデータにアクセスできます。

CDCの概念情報および詳しい手順は、『Oracle Data Integratorでの統合プロジェクトの開発』のジャーナル化の使用方法に関する項を参照してください。

注意:
このCDC構成では一貫性セット・ジャーナル化がサポートされていますが、CDCにデータストアを追加した後に、モデルの「ジャーナル化表」タブでデータストアを順序付けする必要はありません。

24.3.4.1 モデルからのOracle GoldenGate物理スキーマの作成

モデル・エディタの「ジャーナル化」タブから、次のGoldenGateプロセスのOracle GoldenGate物理スキーマを作成できます。

- キャプチャ・プロセス

- 配信プロセス

- 初期キャプチャ・プロセス(初期ロード用に使用されるキャプチャ・プロセス)

- 初期配信プロセス(初期ロード用に使用される配信プロセス)

モデルからOracle GoldenGate物理スキーマを作成する際には、JAgentおよびモデル詳細からデフォルト値が導出されます。

モデルからOracle GoldenGate物理スキーマを作成するには、次のようにします。

1. デザイナ・ナビゲータで、「モデル」パネルを展開します。

2. 物理スキーマの作成に使用するモデルが含まれている「モデル」フォルダを展開します。

3. モデルを右クリックして「開く」を選択します。

4. モデル・エディタの「ジャーナル化」タブをクリックします。

5. 「キャプチャ・プロセス」フィールドの横の「作成」ボタンをクリックします。

6. 適切なJAgentおよびコンテキストを選択します。

7. 「プロセス名」および「論理プロセス名」を入力します。

8. 「OK」をクリックして、キャプチャ・プロセスを作成および選択します。

警告:

キャプチャ・プロセスに対して生成された物理スキーマは手動で変更する必要があります。物理スキーマの「リモート証跡ファイル・パス」プロパティではキャプチャ・インスタンスのパスが使用されるので、配信インスタンスのパスを使用するように変更する必要があります。

9. 「配信プロセス」フィールドの横の「作成」ボタンをクリックします。

10. 適切なJAgentおよびコンテキストを選択します。

11. 「プロセス名」および「論理プロセス名」を入力します。

12. 配信プロセスのターゲット・データベース論理スキーマを選択します。

13. 「OK」をクリックします。

14. 同様に、「初期ロード・キャプチャ・プロセス」および「初期ロード配信プロセス」フィールドの横の「作成」ボタンをクリックして、それらの物理スキーマを作成します。

24.3.5 Oracle GoldenGateプロセスの構成および開始(オフライン・モードのみ)

注意:

- このセクションは、ジャーナルがオフライン・モードで開始された場合にのみ該当します。つまり、JKMのONLINEオプションがfalseの場合のみです。

- JAgentへの接続には、Oracle GoldenGateのプロセスをオフライン・モードで構成する必要はありません。ただし、必要な情報はトポロジで入手可能であることが必要です。

JKMにより、LOCAL_TEMP_DIR内に、ソースおよびターゲット・オブジェクト・グループと同じ名前のフォルダが生成されます。このフォルダには次のものが含まれます。

- Readme.txtファイル: Oracle GoldenGateプロセスの構成および開始の詳細な手順が含まれています。

- srcフォルダ: ソース・サーバーのOracle GoldenGateのインストール・ディレクトリにアップロードする構成ファイルが含まれています。

- stgフォルダ: ステージング・サーバーのOracle GoldenGateのインストール・ディレクトリにアップロードする構成ファイルが含まれています。

それぞれの構成用にカスタマイズされた詳細な手順は、READMEファイルに含まれています。

これらの手順の内容は次のとおりです。

1. srcフォルダからソース・サーバーへ、ファイルをアップロードまたはコピーします。

2. stgフォルダからステージング・サーバーへ、ファイルをアップロードまたはコピーします。

3. ggsciコマンド行を使用して、キャプチャ・プロセス開始用のJKMによって生成されたOBEYファイルをソース・サーバーで実行します。

4. defgenコマンド行を使用して、ソース・サーバーで定義ファイルを生成します。

5. この定義ファイルをステージング・サーバーにコピーします。

6. 初期ロード・オプションを使用する場合:

- ggsciコマンド行を使用して、初期ロード用のJKMによって生成されたOBEYファイルをステージング・サーバーで実行します。

- ggsciコマンド行を使用して、初期ロード用のJKMによって生成されたOBEYファイルをソース・サーバーで実行します。

7. 最後に、ggsciコマンド行を使用して、配信プロセス開始用のJKMによって生成されたOBEYファイルをステージング・サーバーで実行します。

OBEYファイル、ggsciおよびdefgenユーティリティの詳細は、OTNにあるOracle GoldenGateのドキュメントを参照してください。

24.3.6 レプリケートされたデータを使用したマッピングの設計

レプリケートされたデータのデータをマッピングのソースとして使用できます。この処理は、一貫性セット・モードでジャーナル化されたソース・データストアを使用する場合と似ています。詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』の変更データの使用: 一貫性セット・ジャーナル化に関する項を参照してください。

24.4 拡張構成

この項には、拡張構成に関する次の内容が含まれています。

- 初期ロードの方法

- レプリケーション・パフォーマンスのチューニング

- 1つのソースと複数のステージングの構成(オフライン・モードのみ)

24.4.1 初期ロードの方法

ステージング表には、構成のレプリカおよびソース表のデータが含まれます。Oracle GoldenGateプロセスでは、ソース表での変更がキャプチャされ、ターゲットに適用されます。ただし、ステージング表には、最初にソース表の元のコンテンツをロードしておく必要があります。この初期ロードは、次の方法で実行できます。

- Oracle GoldenGateを使用: 特定のGoldenGateプロセスにより、ソース表のコンテンツ全体がステージング表にロードされます。

- Oracle Data Integratorを使用: Oracle Data Integratorの共通フォーマット・デザイナの「インタフェースINの生成」オプション。この方法では、ODIマッピングを使用してデータを転送します。

- データベースのバックアップ/リストア・ツールを使用して、データおよび構造をコピー。

24.4.2 レプリケーション・パフォーマンスのチューニング

次のKMオプションを使用して、レプリケーションのパフォーマンスを改善できます。

- COMPATIBLE: このOracle固有のオプションは、PURGEキーワードの使用および統計(DBMS_STATSまたはANALYZEを使用)の収集方法に影響を及ぼします。この値を、使用するステージング・サーバーのデータベースのバージョンに設定します。

- NB_APPLY_PROCESS: ステージング・サーバーで作成されるOracle GoldenGateの配信プロセスの数。

- TRAIL_FILE_SIZE: Oracle GoldenGateのTrailファイルのサイズをメガバイトで指定します。

NB_APPLY_PROCESSおよびTRAIL_FILE_SIZEパラメータによるパフォーマンス・チューニングの詳細は、OTNにあるOracle GoldenGateのドキュメントを参照してください。

24.4.3 1つのソースと複数のステージングの構成(オフライン・モードのみ)

1つのソースと複数のステージングの構成は、オフライン・ジャーナル化モードでのみ行えます。

単一のソースで変更をキャプチャし、複数のステージング・サーバーにレプリケートする構成を設定できます。この設定方法および一般的な構成を次の例に示します。

レプリケーションのソースとしてソース・サーバーSRCを使用し、STG1およびSTG2の両ステージング・サーバーにレプリケートします。

1. ソース・モデルを編集して、STG1の論理スキーマが選択されていることを確認します。

2. ジャーナルをオフライン・モードで開始しReadmeの指示に従って、SRCおよびSTG1のOracle GoldenGateのプロセスを設定します。

3. ソース・モデルを再び編集して、STG2の論理スキーマを選択します。

4. ジャーナルをオフライン・モードで開始しReadmeの指示に従って、SRCおよびSTG2のOracle GoldenGateのプロセスを設定します。

注意:
SRCで構成を再度再生しても、キャプチャ・プロセス、証跡ファイルまたは定義ファイルは再作成されません。単に、新規のOracle GoldenGate Datapumpプロセスが作成され、データがSTG2にプッシュされます。

24.5 統合キャプチャ

統合キャプチャ・モードでは、Oracle GoldenGateのExtractプロセスでデータベース・ログマイニング・サーバーと直接通信し、データの変更を論理変更レコード(logical change records: LCR)の形式で受け取ります。

統合キャプチャの利点は、次のとおりです。

統合キャプチャでは、データベース・ログマイニング・サーバーを使用してOracle REDOストリームにアクセスするため、アーカイブ・ログの様々なコピーまたはオンライン・ログの様々なミラー・バージョン間の切替えを自動的に行うことができます。

- データベースと完全に統合され、Oracle RAC、ASM、およびTDEと連携するために追加の手順を実行する必要がない

- 表を高速にフィルタ処理できる

- Point-in-TimeリカバリとRAC統合をより効率的に処理できる

- Oracle Recovery Manager (RMAN)がExtractに必要なアーカイブ・ログを自動的に保持するため、統合されたログ管理が可能になる

- マルチテナント・コンテナ・データベースからのキャプチャがサポートされる

- 統合キャプチャと統合適用は両方ともデータベース・オブジェクトなので、オブジェクトの命名は、Oracle Databaseオブジェクトの場合と同じルールに従う

- リリース11.2.0.4以降のソース・データベース(ソース互換性が11.2.0.4以上に設定されている)では、ログマイニング・サーバーによってDDLのキャプチャが非同期に実行され、特別なトリガー、表、またはその他のデータ・オブジェクトをインストールする必要がない

- バージョン11.2.0.4よりも前のOracle 11gソース・データベースでExtractが統合モードになっている場合は、DDLトリガーとサポート・オブジェクトが必要になる

- Oracle GoldenGateのアップグレードは、ユーザー・アプリケーションを停止する必要なしに実行できる

- 図24-1 統合キャプチャ・モードのExtractの構成

24.5.1 統合キャプチャのデプロイメント・オプション
統合キャプチャには、マイニング・データベースのデプロイ場所に応じて使用されるデプロイメント・オプションが2つあります。マイニング・データベースは、ログマイニング・サーバーがデプロイされるデータベースです。
ローカル・デプロイメント

ローカル・デプロイメントの場合、ソース・データベースとマイニング・データベースは同じです。ソース・データベースは、次の操作が行われるデータベースです。

- REDOストリームをマイニングし、変更がキャプチャされる

- ログマイニング・サーバーがデプロイされる

統合キャプチャはデータベースと完全に統合されるため、このモードでは、特別な設定が不要です。

ダウンストリーム・デプロイメント

ダウンストリーム・デプロイメントでは、ソース・データベースとマイニング・データベースは異なるデータベースです。ダウンストリーム・マイニング構成を使用する場合は、ソース・データベースとマイニング・データベースのプラットフォームが同じである必要があります。たとえば、ソース・データベースが64ビットWindowsで稼働している場合、ダウンストリーム・データベースも64ビットWindowsプラットフォームで実行する必要があります。

1. ダウンストリーム・データベースでログマイニング・サーバーを作成します。

2. REDOログをダウンストリーム・マイニング・データベースに配布して、その場所でキャプチャを実行するために、ソース・データベースでREDO転送を構成します。

注意:
キャプチャのオーバーヘッドや変換によるその他のオーバーヘッドおよび本番サーバーの他の処理を軽減するには、キャプチャにダウンストリーム・マイニング・サーバーを使用することをお薦めしますが、これにはログの転送や他の構成が必要です。

24.5.2 使用する適用方法の決定

Replicatプロセスを使用すると、レプリケートされたデータをOracleターゲット・データベースに適用することができます。Oracle GoldenGateプロセスの詳細は、WindowsおよびUNIXにおけるOracle GoldenGateの管理を参照してください。

Oracleターゲット・データベースでは、Replicatを非統合モードまたは統合モードのいずれかで実行できます。次の項では、これらのモードについて説明するとともに、各モードでサポートされるデーターベース・バージョンを示します。

24.5.2.1 非統合Replicat

非統合モードでは、Replicatプロセスは標準SQLを使用して、データをターゲット表に直接適用します。

Replicatの調整された構成を使用して、非統合Replicatでトランザクションを並行して適用することができます。詳細は、WindowsおよびUNIXにおけるOracle GoldenGateの管理を参照してください。

非統合Replicatは、次の場合に使用します。

- Oracleターゲット・データベースがOracle 11.2.0.4よりも前のバージョンである

- 統合Replicatモードでサポートされていない機能を広範に使用する必要がある

非統合モードでは、Replicatは次のように機能します。

1. Oracle GoldenGateの証跡を読み取ります。

2. データのフィルタリング、マッピング、および変換を実行します。

3. ソース・データベースのDMLまたはDDLトランザクションを表すSQL文を作成します(コミットされた順に)。

4. Oracle Call Interface (OCI)を介して、SQLをターゲットに適用します。

図24-2 非統合Replicatの構成

24.5.2.1.1 統合Replicat

統合モードにおいて、Replicatプロセスでは、Oracleデータベース内で使用可能な適用処理機能が使用されます。このモードでは、Replicatは次のように機能します。

- Oracle GoldenGateの証跡を読み取ります。

- データのフィルタリング、マッピング、および変換を実行します。

- ソース・データベースのDMLトランザクションを表す論理変更レコード(logical change records: LCR)を作成します(コミットされた順に)。DDLは、Replicatにより直接適用されます。

- 軽量ストリーミング・インタフェースを使用して、データベース・インバウンド・サーバーと呼ばれるターゲット・データベースのバックグラウンド処理にアタッチします。

- LCRをインバウンド・サーバーに転送し、データをターゲット・データベースに適用します。

図24-3 統合Replicatの構成

単一のReplicat構成内で、適用サーバーと呼ばれるインバウンド・サーバーの複数の子プロセスがトランザクションを並列に適用し、元のトランザクションのアトミック性を保持します。この並列度は、Replicatプロセスの構成時、または必要に応じて動的に、ターゲット・システムのサポートに応じて増加できます。

図24-4 2つの並列適用サーバーの統合Replicat

統合Replicatはトランザクションを非同期に適用します。高速のスループットを達成するために、相互依存性のないトランザクションを安全に実行して順不同でコミットできます。相互依存性があるトランザクションは、ソースと同じ順序で確実に適用されます。

インバウンド・サーバーのリーダー・プロセスでは、ターゲット・データベースで定義されている制約(主キー、一意キー、外部キー)に基づいて、ワークロードのトランザクション間の相互依存性が計算されます。また、バリア・トランザクションとDDL操作は自動的に管理されます。コーディネータ・プロセスでは、複数のトランザクションが調整され、適用サーバー間の順序が管理されます。

インバウンド・サーバーが構成済機能または列タイプをサポートしていない場合、Replicatはインバウンド・サーバーとの通信を停止して、インバウンド・サーバーがキューのトランザクションを完了するのを待機し、その後、OCIを介して、トランザクションを直接適用モードでデータベースに適用します。Replicatは、直接トランザクションの適用後に統合モードで処理を再開します。

Replicatでは、次の機能が直接モードで適用されます。

- DDL操作

- 順序操作

- TABLEまたはMAPパラメータ内のSQLEXECパラメータ

- EVENTACTIONS処理

- UDTに関する注意: ExtractがUSENATIVEOBJSUPPORTを使用してUDTをキャプチャすると、統合Replicatにより、インバウンド・サーバーでUDTが適用されます。そうでない場合は、ReplicatによってUDTが直接処理されます。

注意:
トランザクションは、直接適用モードでシリアルに適用されるため、このような操作を多用すると、統合Replicatモードのパフォーマンスが低下する場合があります。統合Replicatは、適用処理のほとんどが統合モードで実行可能な場合に、最高のパフォーマンスを発揮します。
ユーザー・イグジットは統合モードで実行されます。ユーザー・イグジットにより予期しない結果が発生する場合がありますが、終了コードは、レプリケーション・ストリームのデータによって異なります。

24.5.2.1.2 統合Replicatの要件

統合Replicatを使用するには、次の条件を満たす必要があります。

- Oracleターゲット・データベースがOracle 11.2.0.4以上である必要があります。

- 表間の依存性の計算およびターゲットでの同時トランザクションのスケジューリングをサポートするには、サプリメンタル・ロギングをソース・データベースで有効にする必要があります。

- サプリメンタル・ロギングは任意の時点で有効化できますが、その前に、Oracle GoldenGateプロセスを開始します。

24.6 異なるキャプチャおよび適用モードの併用

次のキャプチャおよび適用モードを一緒に使用できます。

- クラシック・キャプチャ(Oracleまたは非Oracleソース)および非統合Replicat

- クラシック・キャプチャ(Oracleまたは非Oracleソース)および統合Replicat

- 統合キャプチャおよび非統合Replicat

- 統合キャプチャおよび統合Replicat

統合キャプチャおよびクラシック・キャプチャを同じソースOracle GoldenGateインスタンス内で同時に使用し、統合Replicatおよび非統合Replicatを同じターゲットOracle GoldenGateインスタンス内で同時に使用できます。

クラシック・キャプチャ・モードと統合キャプチャ・モード間、および非統合Replicatモードと統合Replicatモード間では、DDLまたはDMLは調整されないため、この構成では、適切なプロセス・グループ内にオブジェクトを慎重に配置する必要があります。各Extractグループでは、表のデータ型および属性に基づいて、処理モードに適したオブジェクトを処理する必要があります。一方のExtractのオブジェクトに、もう一方のExtractのオブジェクトのDMLまたはDDL依存性を含めることはできません。同じタイプの分離をReplicat構成に適用する必要があります。

Oracleバージョンによってサポートされる場合、推奨されるOracle GoldenGate構成は、1つの統合キャプチャをOracleソースで使用し、Oracleターゲットのソース・データベースごとに、1つの統合Replicatを使用することです。統合キャプチャは、クラシック・キャプチャよりも特定のデータ型を完全にサポートします。インバウンド・サーバーを使用するか、必要時に直接適用に切り替えることで、1つの統合Replicat構成ですべてのOracleデータ型をサポートし、ソース・トランザクションの完全性を保持します。必要に応じて、並列度設定を目的の適用パフォーマンス・レベルに調整できます。

ターゲット・データベースが統合ReplicatをサポートしないOracleバージョンか、Oracle以外のデータベースの場合は、調整済のReplicat構成を使用できます。詳細は、WindowsおよびUNIXにおけるOracle GoldenGateの管理を参照してください。

24.7 異なるプロセス・モードへの切替え

プロセス・モードを切り替えることができます。たとえば、クラシック・キャプチャから統合キャプチャ、統合キャプチャからクラシック・キャプチャに切り替えることができます。手順は、「WindowsおよびUNIXにおけるOracle GoldenGateの管理」を参照してください。

24.8 クラシック・モードから統合モードへのGoldenGate Extractのアップグレード

GoldenGate 11.2.1でIntegrated Extractを実行するには、次の要件を満たす必要があります。

- Oracle RDBMSがバージョン11.2.0.3以上である

- RDBMS (Database)パッチが適用されている

- Integrated Extract 11.2.x向けの、11.2.0.3 Database固有のバンドル・パッチ

- REDO互換性を11.2.0.3に設定し、DBバージョンに一致させる必要がある

次の項では、アップグレード手順について説明します。

1. RAC環境とOGGバージョン11.2.1.0.23+を使用している場合は、手順a～dを実行します。11.2.1.0.23よりも前のOGGバージョンを使用している場合は、これらの手順をスキップし、手順2に進んでください。

1. 実行中のExtractに対して、次のコマンドを発行します。

2. SEND extract <extract name> tranlogoptions prepareforupgradetoie

3. Extractが停止している場合、次の行をパラメータ・ファイルに追加した後、Extractを起動します。

4. TRANLOGOPTIONS PREPAREFORUPGRADETOIE

5. ggserr.logファイルまたは対応するExtractレポート・ファイルで、変更が有効になったことによりアップグレードの続行が可能になったことを示すINFO GG-01873メッセージを監視します。

注意:
INFOメッセージが表示された場合、Extractは、キャプチャされる表のすべてのRACノードでコミット済みトランザクションを処理する必要があります。別の方法として、ダミーの表をExtractパラメータ・ファイルに追加することができ、すべてのスレッドからこの表でDMLを実行すると、すべてのスレッドの現在のチェックポイントがExtractコミット境界に設定されます。

Example from report file:
2014-06-05 17:06:09  INFO    OGG-01873  The parameter TRANLOGOPTIONS PREPAREFORUPGRADETOIE has taken effect. Proceed to the next step in the upgrade process.
Example from ggserr.log file:
2014-06-05 17:06:09  INFO    OGG-01873  Oracle GoldenGate Capture for Oracle, src.prm:  The parameter TRANLOGOPTIONS PREPAREFORUPGRADETOIE has taken effect.

6. メッセージが表示された後、Extractを停止してdbloginを実行し、次のように、Integrated Extractへの変換を実行します。

3. Extractデータベースに接続し、次の権限をGG管理ユーザーに付与します。

4. SQL>exec dbms_goldengate_auth.grant_admin_privilege('<ggadmin>')

5. GGSCIにログインします。

6. アップグレードが可能かどうかを確認します。

7. GGSCI> DBLOGIN USERID <ID> PASSWORD <PW>
GGSCI> INFO <extract_name> UPGRADE

8. 既存のトランザクションがオープンしている場合は、アップグレードに失敗することがあります。

9. GGSCI>stop extract <extract_name>
GGSCI>dblogin userid <ggadmin>,password <password>

10. データベースにExtractをまだ登録していない場合は、登録を完了します。

11. GGSCI>register extract <extract_name> database

GGSCI>alter extract <extract_name>,upgrade integrated tranlog

GGSCI>start extract <extract_name>

25 Oracle SOA Suite相互参照

この章では、Oracle Data IntegratorでのOracle SOA Suite相互参照の使用方法について説明します。

この章には次の項が含まれます:

- 25.1項「はじめに」

- 25.2項「インストールおよび構成」

- 25.3項「SOA相互参照KMを使用したXREFの利用」

- 25.4項「ナレッジ・モジュール・オプションの参照情報」

25.1 はじめに

Oracle Data Integratorの機能(複数のソース表から1つのターゲット表へのロードおよび相互参照の処理を行うマッピングなど)は、Oracle SOA Suite相互参照を使用した場合に最良の動作が得られるように設計されています。

25.1.1 概念

相互参照は、サービス指向アーキテクチャに基づいて構築されたOracle Fusion Middlewareの機能で、Oracle BPEL Process ManagerおよびOracle Mediator(以前はEnterprise Service Bus (ESB))を介して使用できます。通常、疎結合の統合で利用されます。統合の様々な関連アプリケーションのランタイム相関を管理するために使用されます。

25.1.1.1 一般原理

Oracle SOA Suiteの相互参照機能では、異なるアプリケーションで作成された対応するエンティティの識別子を関連付けることができます。たとえば、相互参照を使用して、あるアプリケーションで作成された顧客エンティティ(ネイティブIDはCust_100)を、別のアプリケーションにおける同一顧客のエンティティ(ネイティブIDはCT_001)に関連付けることができます。

相互参照(XREF)機能を使用すると、エンティティのネイティブ・キーのアプリケーション間でのマッピングが簡単になります。たとえば、異なるERPシステムの同じ注文を相互に関連付けます。

相互参照の実装では、データベース・スキーマを使用して、システムとデータストアの間でレコードを参照するための相互参照情報を格納します。

相互参照の詳細は、『Oracle SOA Suite開発者ガイド』の相互参照の使用に関する項を参照してください。

データのターゲット表へのロード後にソース表データを更新または削除するオプション機能も統合に必要です。これによって、ステータス・フィールドなどの一部の属性の更新またはターゲット・システムへ正常に処理された後のソース・レコードのパージがバルク統合でサポートされることが必要になります。

25.1.1.2 相互参照表の構造

XREFデータは複数の相互参照表に次の2つの形式で格納されます。

- 汎用(レガシー)表 - 表名はXREF_DATAであり、表構造にすべてのエンティティの相互参照が格納されます。表形式は次のとおりです。

XREF_TABLE_NAME  NOT NULL VARCHAR2(2000)
XREF_COLUMN_NAME NOT NULL VARCHAR2(2000)
ROW_NUMBER NOT NULL VARCHAR2(48)
VALUE  NOT NULL VARCHAR2(2000)
IS_DELETED  NOT NULL VARCHAR2(1)
LAST_MODIFIED NOT NULL TIMESTAMP(6)

この表には、複数のエンティティの相互参照が格納されます。この表では、

- XREF_TABLE_NAMEは、相互参照表の名称です。

- XREF_COLUMN_NAMEは、移入される列の名称です。この列名(アプリケーション名など)は、相互参照表の一意の識別子として使用されます。

- ROW_NUMBERには、アプリケーションに関係なく、特定のエンティティ・インスタンスの一意の識別子(行番号)が格納されます。

- VALUEは、アプリケーションの特定のエンティティのレコード識別子の値です。

すべてのアプリケーションに共通の生成済識別子が格納される、COMMONと呼ばれる特定のXREF_COLUMN_NAMEエントリが存在します。

たとえば、SIEBELとEBSの両方に存在するORDERは、汎用表において、次のようにマップされます。

表25-1 XREF_DATAの例(一部)

XREF_TABLE_NAME

XREF_COLUMN_NAME

ROW_NUMBER

VALUE

ORDER

SIEBEL

100012345

SBL_101

ORDER

EBS

100012345

EBS_002

ORDER

COMMON

100012345

COM_100

- カスタム(新規)表構造 - この表は1つのエンティティに固有であり、カスタム構造を持ちます。次に例を示します。

ROW_ID  VARCHAR2(48) NOT NULL PK,
APP1   VARCHAR2(100),
APP2   VARCHAR2(100),
...
COMMON   VARCHAR2(100),
LAST_MODIFIED  TIMESTAMP NOT NULL

説明:

- APP1やAPP2などの列は、異なるアプリケーションのPK値を格納し、同じソース・レコードにリンクするために使用されます。

- ROW_ID(行番号)は、XREFデータ表内のレコードを一意に識別するために使用されます。

- COMには統合レイヤーに共通の値が保持され、相互参照を確立するために関連アプリケーション間で渡されます。

SIEBELとEBSの両方に存在するORDERは、カスタムXREF_ORDER表に次のようにマップされます。

表25-2 カスタム表: XREF_ORDERSの例(一部)

ROW_ID

SIEBEL

EBS

COMMON

100012345

SBL_101

EBS_002

COM_100

詳細は、25.3.3項「相互参照KMによるマッピングの設計」および25.4項「ナレッジ・モジュール・オプションの参照情報」を参照してください。

25.1.1.3 相互参照表の構造の処理

IKM SQL Control Append (SOA XREF)には、これらの2つの構造を処理するための、次のパラメータがあります。

- XREF_DATA_STRUCTURE: XREF_DATA汎用表を使用する場合はこのオプションをlegacyに設定し、カスタム表構造を使用する場合はnewに設定します。

汎用表構造を使用する場合は、次のオプションを設定する必要があります。

- XREF_TABLE_NAME: XREF_DATA表のXREF_TABLE_NAME列に挿入される値。前述の例(表25-1を参照)では、このオプションはORDERです。

- XREF_COLUMN_NAME: XREF_DATA表のXREF_COLUMN_NAME列に挿入される値。この値は、現在のマッピングのターゲットであるアプリケーションに対応します。前述の例(表25-1を参照)では、ターゲット設定されているシステムに応じて、このオプションの値はSIEBELまたはEBSのいずれかとなります。

カスタム表構造を使用する場合は、次のオプションを使用する必要があります。

- XREF_DATA_TABLE: 相互参照表の名称。デフォルトはXREF_DATAです。前述の例(表25-2を参照)では、この表名はXREF_ORDERです。

- XREF_DATA_TABLE_COLUMN: 現在のマッピングのターゲットであるアプリケーションの相互参照を格納する列の名称。前述の例(表25-2を参照)では、ターゲット設定されているシステムに応じて、このオプションの値はSIEBELまたはEBSのいずれかとなります。

25.1.2 ナレッジ・モジュール

Oracle Data Integratorには、SOA相互参照(XREF)を処理するためのナレッジ・モジュール(KM)が用意されています。これらのリストを表25-3に示します。

これらの新しいナレッジ・モジュールでは、SOA相互参照をサポートするためのパラメータが導入されています。これらのパラメータの詳細は、25.1.1.2項「相互参照表の構造」および25.3.3項「相互参照KMによるマッピングの設計」を参照してください。

表25-3 SOA XREF KM

ナレッジ・モジュール

説明

LKM SQL to SQL (SOA XREF)

このKMでは、LKM SQL to SQL (ESB XREF)が置き換えられます。

このKMでは、標準ISOソースから任意のISO-92データベースへのデータのロード中の相互参照がサポートされています。

オプションSRC_UPDATE_DELETE_ACTIONに応じて、このLKMでは、ソース・レコードのDELETEまたはUPDATEを実行できます。

LKM SQL to SQL (SOA XREF)は、同じマッピングでIKM SQL Control Append (SOA XREF)と組み合せて使用する必要があります。

LKM MSSQL to SQL (SOA XREF)

このKMでは、LKM MSSQL to SQL (ESB XREF)が置き換えられます。

このKMは、Microsoft SQL Server用に最適化されたバージョンのLKM SQL to SQL (SOA XREF)です。

IKM SQL Control Append (SOA XREF)

このKMでは、IKM SQL Control Append (ESB XREF)が置き換えられます。

このKMでは、任意のISO-92準拠データベース・ターゲット表における、切捨て/挿入(追加)モードでのデータ統合中の相互参照がサポートされています。また、このKMではデータ制御も提供されます。無効なデータはエラー表に分離され、リサイクルできます。ターゲットにデータをロードするとき、このKMでは、別のデータベース上のPK/GUID XREF表への移入も行います。

このIKM SQL Control Append (SOA XREF)は、LKM SQL to SQL (SOA XREF)またはLKM MSSQL to SQL (SOA XREF)と組み合せて使用する必要があります。

25.1.3 SOA XREF KMプロセスの概要

Oracle Data Integratorとの統合の実行中に相互参照表をロードするには、SOA XREFナレッジ・モジュールを使用する必要があります。これらのナレッジ・モジュールでは、システム間での情報の抽出またはロード中に相互参照表がロードされます。

注意:
ソース・システムとターゲット・システム間の相互参照を保持するには、LKMとIKMによってサポートされている相互参照を組み合せて使用するする必要があります。

全プロセスは次の3つの主なフェーズに分けられます。

1. ロード・フェーズ(LKM)

2. 統合および相互参照フェーズ(IKM)

3. 処理済レコードの更新/削除(LKM)

25.1.3.1 ロード・フェーズ(LKM)

ロード・フェーズでは、ソース表からの列を使用してソース主キーが作成されます。このソース主キーは、VARCHAR値を返すユーザー定義のSQL式を使用して導出されます。この式はSRC_PK_EXPRESSION KMオプションで指定されます。

たとえば、ソースの注文明細表(マッピングではOLINEという別名)に次の式を使用できます。

TO_CHAR(OLINE.ORDER_ID) || '-' || TO_CHAR(OLINE.LINE_ID)

この値を最終的に使用して相互参照表に対する移入が行われます。

25.1.3.2 統合および相互参照フェーズ(IKM)

統合フェーズでは、ターゲット表に対して共通IDが作成されます。共通IDの値は、XREF_SYS_GUID KMオプションの式から導出されます。この式の例は次のとおりです。

- データベース順序(<SEQUENCE_NAME>. NEXTVAL)

- グローバル一意IDを戻す関数(Oracleの場合はSYS_GUID()、SQL Serverの場合はNewID() )

この共通IDは、UD1フラグでマークされたターゲット表のターゲット列にも自動的にプッシュされます。

共通IDもソース主キーも相互参照表にプッシュされます。さらに、IKMによって、ソース主キーおよび共通IDの間の相互参照を作成する一意の行番号値が相互参照表にプッシュされます。この行番号値は、XREF_ROWNUMBER_EXPRESSION KMオプションから導出されます。このオプションでは通常、共通IDと同様の式を使用して一意の識別子が生成されます。

相互参照KMの複数マッピングで同一ソース行が複数ターゲット表のロードに使用される場合、同じ共通IDが再利用されます(再導出されません)。これによって、一意のソース行と異なるターゲット行との間の相互参照を作成できます。

25.1.3.3 処理済レコードの更新/削除(LKM)

オプションのこのフェーズ(SRC_UPDATE_DELETE_ACTION KMオプションでパラメータ化)では、正常に処理されたソース・レコードを基にソース・レコードの削除または更新を行います。

- SRC_UPDATE_DELETE_ACTIONがDELETE値をとる場合、マッピングで処理されたソース・レコードは削除されます。

- SRC_UPDATE_DELETE_ACTIONがUPDATE値をとる場合、ソース表のソース列は、すべての処理済のソース・レコードの式で更新されます。この動作は次のKMオプションによってパラメータ化されます。

- SRC_UPD_COL: 更新するソース列の名称

- SRC_UPD_COL_EXPRESSION: 列で更新する値の生成に使用される式

ソース表とは異なる表から、削除および更新操作を実行できます。これを行うには、LKMで次のKMオプションを設定する必要があります。

- SRC_PK_LOGICAL_SCHEMA: 影響を与えるソース表が含まれているOracle Data Integrator論理スキーマ

- SRC_PK_TABLE_NAME: 影響を与えるソース表の名称

- SRC_PK_TABLE_ALIAS: この表の別名

25.2 インストールおよび構成

SOA XREFナレッジ・モジュールの使用を開始する前に、この項の情報を必ず読んでください。

- システム要件および動作要件

- テクノロジ固有の要件

- 接続性要件

25.2.1 システム要件および動作要件

インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。

サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。

http://www.oracle.com/technology/products/oracle-data-integrator/index.html

25.2.2 テクノロジ固有の要件

Oracle Data IntegratorでOracle SOA Suite相互参照を使用するためのテクノロジ要件はありません。Oracle DatabaseおよびMicrosoft SQl Serverの要件がOracle SOA Suite相互参照にも適用されます。詳細は、次の情報を参照してください:

- 第2章「Oracle Database」

- 第7章「Microsoft SQL Server」

25.2.3 接続性要件

Oracle Data IntegratorでOracle SOA Suite相互参照を使用するための接続性要件はありません。Oracle DatabaseおよびMicrosoft SQl Serverの要件がOracle SOA Suite相互参照にも適用されます。詳細は、次の情報を参照してください:

- 第2章「Oracle Database」

- 第7章「Microsoft SQL Server」

25.3 SOA相互参照KMを使用したXREFの利用

この項の内容は次のとおりです。

- トポロジの定義

- プロジェクトの設定

- 相互参照KMを使用したマッピングの設計

25.3.1 トポロジの定義

SOA XREF KMを使用したプロジェクトに固有のOracle Data Integratorでのトポロジの作成手順は、次のとおりです。

1. ソースおよびターゲットに対応するデータ・サーバー、物理スキーマおよび論理スキーマを作成します。

2. 次の項の説明に従って、OracleまたはMicrosoft SQL Serverテクノロジのデータ・サーバーおよび物理スキーマを作成します。

- 2.3.1項「Oracleデータ・サーバーの作成」および2.3.2項「Oracle物理スキーマの作成」

- 7.3.1項「Microsoft SQL Serverデータ・サーバーの作成」および7.3.2項「Microsoft SQL Server物理スキーマの作成」

このデータ・サーバーとこの物理スキーマは、相互参照表を含むOracleインスタンスおよびスキーマまたはMicrosoft SQL Serverデータベースを指し示す必要があります。

3. 相互参照表を含む物理スキーマを指し示す、XREFと呼ばれる論理スキーマを作成します。
詳細は、『Oracle Data Integratorの管理』の論理スキーマの作成に関する項を参照してください。

25.3.2 プロジェクトの設定

使用するプロジェクトに次のKMがまだインポートされていない場合は、これらをインポートします。

- IKM SQL Control Append (SOA XREF)

- Microsoft SQL Serverを使用する場合は、LKM SQL to SQL (SOA XREF)またはLKM MSSQL to SQL (SOA XREF)

25.3.3 相互参照KMを使用したマッピングの設計

複数のソース表からターゲット表へのロードとソースの1つとターゲットとの間の相互参照の処理の両方を行うマッピングを作成するには、次のようにします。

1. 相互参照を持つソースとターゲット・データストアとのマッピングを作成します。

2. 通常どおり結合、フィルタおよびマッピングを作成します。
共通IDのマッピング: ターゲット列で相互参照表の生成された共通IDをマップする場合は、この列のUD1フラグをチェックし、ダミーのマッピングを入力します。たとえば、'X'などの定数値です。

3. マッピングの物理ダイアグラムで、相互参照するソース表を含む実行ユニットに対するアクセス・ポイントを選択します。このオブジェクトのプロパティ・インスペクタが開きます。

4. ソース・データストアがMicrosoft SQL Serverにある場合は、「ロード・ナレッジ・モジュール」タブで、LKM SQL to SQL (SOA XREF)またはLKM MSSQL to SQL (SOA XREF)を選択します。

5. 次のようにKMのオプションを指定します。

- SRC_PK_EXPRESSIONで、XREF表に格納するソース主キー値を表す式を指定します。

ソース表に1つの属性のみがキーとして定義されている場合は、属性名(たとえばSEQ_NO)を入力します。

ソース・キーに複数の属性が含まれる場合は、キー値の導出に使用する式を指定します。たとえば、表にSEQ_NOとDOC_DATEの2つのキー属性があり、これらの属性を連結した値をソース値としてXREF表に格納する場合、SEQ_NO || DOC_DATEと入力します。このオプションは必須です。

- 必要な場合は、25.1.3.3項「処理済レコードの更新/削除(LKM)」の説明に従って、ソース表に影響を与えるSRC_UPDATE_DELETE_ACTIONを設定します。

6. マッピングの物理ダイアグラムで、ステージング領域に対するアクセス・ポイントを選択します。このオブジェクトのプロパティ・インスペクタが開きます。

7. 「統合ナレッジ・モジュール」タブで、IKM SQL Control Append (SOA XREF)を選択します。

8. 次のようにKMのオプションを指定します。

- XREF_DATA_STRUCTURE: 新しいXREF_DATA表構造を使用する場合は、Newを入力します。それ以外の場合は、Legacyを入力してレガシーXREF_DATA表を使用します。デフォルトはNewです。25.1.1.3項「相互参照表の構造の処理」の説明に従って、使用している表の構造に応じてオプションを構成します。

- XREF_SYS_GUID_EXPRESSION: 共通IDの導出に使用される式を入力します。この式の例は次のとおりです。

- データベース順序(<SEQUENCE_NAME>.NEXTVAL)

- グローバル一意IDを戻す関数(Oracleの場合はSYS_GUID()、SQL Serverの場合はNewID() )

- XREF_ROWNUMBER_EXPRESSION: これは、行番号列にプッシュされる値です。順序に変更する必要がない場合、デフォルト値GUIDを使用します。

- FLOW_CONTROL: CKM Oracleを使用できるようにする場合、YESに設定します。

注意:
ターゲット表に共通IDのプレースホルダがなく、たとえば、ターゲット属性の1つにソース識別子を移入する場合、どのソース識別子をどの属性に移入するかを示すには、ODIの標準マッピング・ルールを使用する必要があります。
共通IDをロードするターゲット属性がターゲット表の一意キーの場合、マップされる必要があります。その属性にダミーのマッピングを設定する必要があります。実行時、このダミー・マッピングは、統合ナレッジ・モジュールで生成された共通識別子で上書きされます。このターゲット属性にUD1フラグを必ず設定します。

25.4 ナレッジ・モジュール・オプションの参照情報

この項では、次のナレッジ・モジュールに関するKMオプションをリストします。

- LKM SQL to SQL (SOA XREF)

- LKM MSSQL to SQL (SOA XREF)

- IKM SQL Control Append (SOA XREF)

表25-4 LKM SQL to SQL (SOA XREF)

オプション

値

必須

説明

SRC_UPDATE_DELETE_ACTION

NONE|UPDATE|DELETE

はい

データのターゲットへの統合後ソース・レコードに対して行うアクションを示します。詳細は、25.1.3.3項「処理済レコードの更新/削除(LKM)」を参照してください。

SRC_PK_EXPRESSION

連結式

はい

1つの大きなvarchar列に合うようPKからの値を連結する式。例: ソースの注文明細表(マッピングではOLINEという別名)に次の式を使用できます。

TO_CHAR(OLINE.ORDER_ID) || '-' || TO_CHAR(OLINE.LINE_ID)

SRC_PK_LOGICAL_SCHEMA

ソース表の論理スキーマの名前

いいえ

ソース表の論理スキーマの名前を示します。ソース表は、処理後レコードを削除または更新する表です。論理スキーマは、実行時にコンテキストに従って実際の物理スキーマを解決するために使用されます。例: ORDER_BOOKING。このオプションは、SRC_UPDATE_DELETE_ACTIONがUPDATEまたはDELETEに設定されている場合にのみ必要です。

SRC_PK_TABLE_NAME

ソース表名。デフォルトはMY_TABLE。

いいえ

処理後にレコードを削除または更新するソース表名を示します。例: ORDERS。このオプションは、SRC_UPDATE_DELETE_ACTIONがUPDATEまたはDELETEに設定されている場合にのみ必要です。

SRC_PK_TABLE_ALIAS

ソース表の別名。デフォルトは

MY_ALIAS

いいえ

このマッピング内でのソース表の別名を示します。ソース表は、処理後レコードを削除または更新する表です。例: ORD。このオプションは、SRC_UPDATE_DELETE_ACTIONがUPDATEまたはDELETEに設定されている場合にのみ必要です。

SRC_UPD_COL

別名が付けられたソース列名

いいえ

更新フラグ・インジケータを保持し、別名が付けられたソース列名。SRC_UPDATE_DELETE_ACTIONが式リテラルSRC_UPD_EXPRESSIONでUPDATEに設定されている場合、この列の値は、統合後更新されます。列に使用される別名は、ソース表に対して定義されているものと一致する必要があります。例: ORD.LOADED_FLAG。このオプションは、SRC_UPDATE_DELETE_ACTIONがUPDATEに設定されている場合にのみ必要です。

SRC_UPD_EXPRESSION

リテラルまたは式

いいえ

SRC_UPD_COLの更新に使用されるリテラルまたは式。この値は、SRC_UPDATE_DELETE_ACTIONがUPDATEに設定されている場合、統合後のこの列の更新に使用されます。例: RECORDS PROCESSED。このオプションは、SRC_UPDATE_DELETE_ACTIONがUPDATEに設定されている場合にのみ必要です。

DELETE_TEMPORARY_OBJECTS

Yes|No

はい

一時オブジェクト(ファイルおよびスクリプト)を統合後保持する場合、このオプションをNOに設定します。デバッグに便利です。

LKM MSSQL to SQL (SOA XREF)

LKM MSSQL to SQL (SOA XREF)オプションの詳細は、表25-4を参照してください。

表25-5 IKM SQL Control Append (SOA XREF)

オプション

値

必須

説明

INSERT

Yes|No

はい

マッピングのターゲット・データストアへのデータの挿入を自動的に試行します。

COMMIT

Yes|No

はい

ターゲット・データストアに挿入されたすべてのデータをコミットします。

FLOW_CONTROL

Yes|No

はい

フロー制御を行う場合、このオプションを選択します。

RECYCLE_ERRORS

Yes|No

はい

以前の制御から拒否されたデータをリサイクルする場合、このオプションを選択します。

STATIC_CONTROL

Yes|No

はい

ターゲット・データの挿入または更新後にターゲット表を制御する場合、このオプションを選択します。

TRUNCATE

Yes|No

はい

ターゲット・データストアを切り捨てる場合、このオプションを選択します。

DELETE_ALL

Yes|No

はい

ターゲット・データストアのすべての行を削除する場合、このオプションを選択します。

CREATE_TARG_TABLE

Yes|No

はい

ターゲット表を作成する場合、このオプションを選択します。

DELETE_TEMPORARY_OBJECTS

Yes|No

はい

一時オブジェクト(表、ファイルおよびスクリプト)を統合後保持する場合、このオプションをNOに設定します。デバッグに便利です。

XREF_TABLE_NAME

XREF表名

レガシーXREF表構造を使用する場合は、はい。

XREF表で使用する表名。例: ORDERS。詳細は、25.1.1.3項「相互参照表の構造の処理」を参照してください。

XREF_COLUMN_NAME

列名

レガシーXREF表構造を使用する場合は、はい。

XREF表でリテラルとして使用する主キー列名。詳細は、25.1.1.3項「相互参照表の構造の処理」を参照してください。

XREF_SYS_GUID_EXPRESSION

SYS_GUID()

はい

XREF表(列名"VALUE")の共通IDの移入に使用される式を入力します。有効な例: SYS_GUID()、MY_SEQUENCE.NEXTVALなど。

XREF_ROWNUMBER_EXPRESSION

SYS_GUID()

はい

XREF表の行番号の移入に使用される式を入力します。Oracleの例: SYS_GUID()、MY_SEQUENCE.NEXTVALなど。

XREF_DATA_STRUCTURE

New|Legacy

はい

新しいXREF_DATA表構造を使用する場合は、Newを入力します。それ以外の場合は、Legacyを入力してレガシーXREF_DATA表を使用します。デフォルトはNewです。詳細は、25.1.1.3項「相互参照表の構造の処理」を参照してください。

XREF_DATA_TABLE

XREF表名

いいえ。カスタムXREF表構造で使用できます。

相互参照情報を格納する表の名称を入力します。デフォルトはXREF_DATAです。詳細は、25.1.1.3項「相互参照表の構造の処理」を参照してください。

XREF_DATA_TABLE_COLUMN

XREFデータ表の列名

カスタムXREF表構造を使用する場合は、はい。

新しいXREFデータ構造のみ: ソース・キー値を格納するXREFデータ表の列名を入力します。詳細は、25.1.1.3項「相互参照表の構造の処理」を参照してください。

第IV部

付録

第IV部は、次の付録で構成されます。

- 付録A「Oracle Data Integrator Driver for LDAPの参照情報」

- 付録B「Oracle Data Integrator Driver for XMLの参照情報」

- 付録C「Oracle Data Integrator Driver for Complex Filesの参照情報」

A Oracle Data Integrator Driver for LDAPの参照情報

この付録では、Oracle Data Integrator Driver for LDAPの使用方法を説明します。

この付録には次の項が含まれます:

- A.1項「Oracle Data Integrator Driver for LDAPの概要」

- A.2項「LDAPの処理の概要」

- A.3項「インストールおよび構成」

- A.4項「SQL構文」

- A.5項「実装されるJDBC API機能」

A.1 Oracle Data Integrator Driver for LDAPの概要

Oracle Data Integrator Driver for LDAP (LDAPドライバ)とともにOracle Data Integrator使用すると、複雑なLDAPツリーを標準のSQL問合せで操作できます。

LDAPドライバでは次がサポートされます。

- LDAPエントリ、そのオブジェクト・クラスおよび属性の操作

- 標準のSQL (Structured Query Language)構文

- 相関サブ問合せ、内部および外部結合

- ORDER BYおよびGROUP BY

- COUNT、SUM、MIN、MAX、AVGおよびその他のファンクション

- すべての標準SQLファンクション

- 参照整合性(外部キー)

- ディレクトリへの持続的変更

A.2 LDAPの処理の概要

LDAPドライバは次のように機能します。

1. ドライバは、LDAPからリレーショナルへのマッピングを使用して、(接続時に)LDAP構造およびデータをリレーショナル・スキーマにロードします。

2. ユーザーは、通常のSQL文を介してデータを操作して、リレーショナル・スキーマを使用します。リレーショナル・スキーマ・データで実行されたすべての変更(挿入/更新)は、ドライバによって、ただちにLDAPデータに反映されます。

A.2.1 LDAPからリレーショナルへのマッピング

LDAPからリレーショナルへのマッピングは、複雑ですが自動化されたプロセスで、リレーショナル構造の生成に使用されます。LDAPサーバーでは標準の方法でメタデータ情報が提供されないため、LDAPツリーからデータのイントロスペクションを使用して、このマッピングが実行されます。したがって、自動マッピングは、このプロセスのソースとして使用されるLDAPツリーのコンテンツで実行されます。

この項には次のトピックが含まれます:

- 一般原理

- グループ化係数

- マッピング例外

- 参照LDAPツリー

A.2.1.1 一般原理

LDAPドライバでは、次の方法で、LDAP要素がリレーショナル・スキーマにマップされます。

- 各LDAPクラスまたはクラスの組合せは、1つの表にマップされます。LDAPツリーの各エントリは、表内の1つのレコードにマップされます。

- クラス・インスタンスの各属性は、1つの列にマップされます。

- エントリ間の階層関係は、外部キーを使用してマップされます。階層レベルを表す表は、<tablename>PKと呼ばれる主キーを使用して作成されます。レコードは、<parent_level_tablename>FK columnを介してその親表を参照します。LDAPツリー構造のルートは、一意のレコードのROOTPK列を含む、ROOTと呼ばれる表にマップされます。

- 1つのエントリに対して複数の値が設定されている属性(たとえば、複数のemail属性が設定されているPersonエントリ)は、<parent_tablename><attribute_name>と呼ばれるサブ表としてマップされます。各サブ表には、親表とリンクするための<parent_tablename>FK columnが含まれます。

図A-1は、PersonインスタンスとリンクされているOrganizationalUnitエントリを含むLDAPツリーを示しています。ここでは、特定のPersonエントリに複数の電子メール・アドレスが設定されています。

図A-1 LDAPツリーの例

このLDAPツリーは、次のリレーショナル構造にマップされます。

- ROOT表は階層のルートを表し、1つのROOTPK列が含まれます。

- ORGANIZATIONALUNIT表は、ツリーの様々なorganizationalUnitインスタンスを表します。ここには、ORGANIZATIONALUNITPK主キー列およびorganizationalUnitインスタンスの属性(cn、telephoneNumberなど)が含まれます。ROOTFK外部キー列によってROOT表にリンクされます。

- PERSON表は、personクラスのインスタンスを表します。ここには、PERSONPK主キー列、ORGANIZATIONALUNIT表にリンクするためのORGANIZATIONALUNITFKおよびPERSONインスタンスの属性(telephoneNumber、description、cn)が含まれます。

- email属性はPERSON_EMAIL表として表示され、EMAIL列、およびemail属性のリストをPERSONレコードにリンクするPERSONFKが含まれます。

図A-2は、生成されるリレーショナル構造を示しています。

図A-2 図A-1のLDAPツリーの例からマップされたリレーショナル構造

A.2.1.2 グループ化係数

LDAPディレクトリでは、複数のクラス定義から属性を継承することでクラス・エントリが指定されることがよくあります。リレーショナル・マッピングの手順では、この状態を変換するために、LDAPドライバによってLDAPエントリ内のクラスの組合せがそれぞれ結合され、新しい表が生成されます。

たとえば、Personクラスの一部のエントリは、ManagerまたはBoardMemberクラスのどちらか(もしくは両方)のインスタンスでもある可能性があります。この場合、マッピング手順でPERSON表(Personのインスタンス用)が作成されますが、さらに、LDAPツリーに存在するクラスの組合せに応じてMANAGER_PERSON、BOARDMEMBER_PERSON、BOARDMEMBER_MANAGER_PERSONなどの表が生成されます。

生成される表を不必要に増加させないために、この動作をパラメータ化できます。これを行うには、グループ化係数パラメータを使用して、同じ表にインスタンスがグループ化された状態で残る分岐クラスの数を定義します。生成される表には、IS_<classname>という名前のフラグ列が含まれ、この列の値によって、インスタンスの所属先となるクラスのサブセットが決まります。たとえば、IS_<classname>が1に設定された場合、レコードが表すインスタンスは<classname>に属します。

クラスの組合せごとに1つの表が作成される動作は、グループ化係数が0の場合に相当します。グループ化係数が1の場合、分岐クラスが1つのみのインスタンスが同じ表に残ります。

この例では、グループ化係数が2以上の場合、社内のすべてのPersonインスタンス(Person、ManagerおよびBoardMemberクラス・インスタンスを含む)がPERSON表にグループ化されます。IS_MANAGERおよびIS_BOARDMEMBER列によって、ManagerクラスまたはBoardMemberクラス(もしくは両方)にも含まれるPERSONレコードが決定します。

A.2.1.3 マッピング例外

この項では、マッピング処理の特定の状況について説明します。

- 表名の長さ制限および競合: 状況によっては、名前の長さ制限によってオブジェクト名の競合が発生する可能性があります。このような状況を回避するために、LDAPドライバでは、オブジェクト名の3桁の接尾辞が自動生成されます。

- キー列: 現在のレコード(元のLDAPクラス・インスタンス)の識別子として使用できる相対識別名(RDN)を含む追加のSNPSLDAPKEY列を、ドライバで自動的に作成できます。これを行うには、key_column URLプロパティをtrueに設定します。LDAPツリーのコンテンツを更新するDMLコマンドを実行する場合は、このSNPSLDAPKEY列をロードする必要があります。この列は、LDAPインスタンスに基づく表のみに作成されます。複数値のインスタンス属性に対応する表には、これらの列は作成されません。

- 大/小文字の区別: これは、RDBMSおよびLDAPサーバーに対して大/小文字の区別を強制するcase_sens URLプロパティで設定します。

- 特殊文字: LDAPでは、属性またはクラス名に英数字以外の文字が含まれる可能性があります。これらの文字は、マップ時にアンダースコア(_)に変換されます。例外: 最初の文字が英数字以外の場合、その文字はxに変換されます。

- 予約済SQLキーワード: リレーショナル構造で、表名または列名とSQLキーワードとの間の名前の競合を回避するために、SQLキーワードと名前が一致する生成済の表および列の名前が自動的に変更されます(名前の後にアンダースコアが追加されます)。たとえば、SELECTという名前のクラスはSELECT_という名前の表にマップされます。

A.2.1.4 参照LDAPツリー

LDAPサーバーでは標準の方法でメタデータ情報が提供されないため、LDAPツリーからデータのイントロスペクションを使用して、LDAPからリレーショナルへのマッピング・プロセスがデフォルトで実行されます。

LDAPドライバでは、LDAPからリレーショナルへのマッピング・プロセスに対して、実際のデータを含むLDAPツリーのかわりに参照LDAPツリーを使用することもできます。

この参照LDAPツリーは、ドライバURLのldap_metadataプロパティを使用して構成します。このプロパティにより、運用LDAPツリーの階層構造を厳密に反映しながらも付随するデータ量は伴わないLDAPツリーへの接続情報を含む、.propertiesファイルが指定されます。

この手法には次の利点があります。

- ディレクトリ管理者は、参照LDAPツリーを運用LDAPツリーの不変の定義として使用できます。

- 参照LDAPツリーには実際のLDAPツリーのスケルトンを構成する少数のインスタンスが含まれ、この小さい参照ツリーでは、LDAPからリレーショナルへのマッピング・プロセスがより速く実行されます。これは大規模な運用LDAPディレクトリにとって特に重要であり、手順を実行するための処理時間とリソースが削減されます。

一方、参照LDAPツリーの正確な構造を設計する上で、この手法の使用には次の制約があります。

- オプションのLDAPインスタンス属性を、参照エントリ内ですべてインスタンス化する必要があります。これらの属性が運用LDAPディレクトリ・エントリにない場合でも、後で使用するためには、参照LDAPツリー内で宣言する必要があります。

- 運用LDAPディレクトリに存在するすべての複数値属性は、参照LDAPツリーでも同様にインスタンス化する必要があります。たとえば、運用LDAPディレクトリのいずれかのPersonインスタンスに2つのtelephoneNumber属性がある場合は、参照LDAPツリーでも、この汎用Personクラスで少なくとも2つのtelephoneNumber属性をインスタンス化する必要があります。

注意:
複数の属性フィールドをマップするための追加の表および列が強制的に作成されるため、生成されるリレーショナル構造は、これらの問題による直接的な影響を受けます。そのため、参照LDAPツリーの設計時には、これらの問題を考慮する必要があります。

A.2.2 リレーショナル・スキーマの管理

この項には次のトピックが含まれます:

- リレーショナル・スキーマの格納

- リレーショナル構造内のデータへのアクセス

A.2.2.1 リレーショナル・スキーマの格納

LDAPからリレーショナルへのマッピングによって生成されたリレーショナル構造は、仮想マッピングで管理されるか、外部データベースに格納されます。

仮想マッピングでは、ランタイム・エージェントのメモリーにリレーショナル構造が格納されるため、その他のコンポーネントは不要です。リレーショナル構造は、ドライバによってLDAPツリー構造に透過的にマップされます。LDAPドライバに使用できるSQLコマンドおよびファンクションのリストは、「SQL構文」を参照してください。

注意:
大規模なLDAPツリー構造に対する仮想マッピングでは、大量のメモリーが必要になります。

外部データベースには、任意のリレーショナル・データベース管理システムを使用できます。ドライバは、JDBCを介してこのエンジンに接続し、リレーショナル・スキーマの格納に使用します。この方法には次の利点があります。

- 選択した外部データベース・エンジンの処理および格納能力の利用。

- 外部データベース・エンジンの特定のSQL文、プロシージャおよびファンクションへのアクセス。

- リレーショナル構造の柔軟な持続性。このスキーマ・コンテンツは、LDAPドライバへの接続のクローズ後も持続可能です。

外部記憶域の設定方法の詳細は、A.3.2項「外部データベースを使用したデータの格納」を参照してください。

A.2.2.2 リレーショナル構造内のデータへのアクセス

リレーショナル内の表でのDML操作は、標準のSQL文で実行されます。

リレーショナル・データへの変更は、選択した記憶域に応じて、次のようにディレクトリに伝播されます。

- 仮想マッピングを使用する場合は、挿入、更新および削除のすべての要求が自動的に元のLDAPサーバーに自動コミット・モードで伝播されます。明示的なCOMMITまたはROLLBACK文は、Oracle Data Integrator driver for LDAPにはまったく影響しません。

- 外部データベースを使用してリレーショナル構造を格納する場合は、あらゆるタイプのDML文をドライバで使用できます。ただし、変更は元のLDAPサーバーに伝播されないため、注意が必要です。

A.3 インストールおよび構成

Oracle Data Integrator driver for LDAPは、Oracle Data Integratorのインストール時に自動的にインストールされます。次の各項では、拡張構成の説明および参照情報を示します。

この項には次のトピックが含まれます:

- ドライバの構成

- 外部データベースを使用したデータの格納

- LDAPディレクトリの接続構成

- 表の別名の構成

注意:
JNDIを使用して、LDAPディレクトリへの接続に必要なライブラリおよびドライバをOracle Data Integratorのクラスパスに追加する必要があります。

注意:
外部データベース・エンジンを使用する場合は、さらに、外部データベースへの接続に使用するJDBCドライバおよび.propertiesファイルをクラスパスに含めておく必要があります。

A.3.1 ドライバの構成

この項ではドライバの構成について説明します。

- ドライバ名: com.sunopsis.ldap.jdbc.driver.SnpsLdapDriver

- ドライバでサポートされる2つのURL書式:

- jdbc:snps:ldap?<property=value>[&...]

- jdbc:snps:ldap2?<property=value>[&...]

最初のURLでは、LDAPディレクトリのパスワードをエンコードする必要があります。2番目のURLでは、LDAPディレクトリのパスワードをエンコードせずに指定できます。

注意:
最初のURLを使用して、LDAPディレクトリのパスワードを保護することをお薦めします。

LDAPドライバでは、確立された接続に応じて様々なプロパティを使用します。図A-3に、使用されるプロパティとその状況を示します。

図A-3 LDAPドライバのプロパティ・ファイル

LDAPドライバはLDAPディレクトリに接続します。この接続は、先頭がldap_のプロパティを使用して構成できます。例: ldap_basednLDAPディレクトリにドライバURLでプロパティを渡すかわりに、LDAPディレクトリへの接続を構成するためのプロパティ・ファイルを使用できます。このプロパティ・ファイルは、ドライバURLのldap_propsプロパティで指定する必要があります。

付随するデータ量を伴わないLDAPツリーの階層構造を使用する場合は、参照LDAPツリーを使用できます。参照LDAPツリーへの接続は、先頭がlm_のプロパティを使用して構成します。例: lm_basednドライバURLでlm_プロパティを渡すかわりに、プロパティ・ファイルを使用できます。このプロパティ・ファイルは、ドライバURLのldap_metadataプロパティで指定する必要があります。詳細は、A.2.1.4項「参照LDAPツリー」を参照してください。

LDAPドライバの外部データベースへの接続を構成するには、先頭がdb_のプロパティを使用します。例: db_url外部データベースにドライバURLでプロパティを渡すかわりに、外部データベースへの接続を構成するためのプロパティ・ファイルを使用できます。このプロパティ・ファイルは、ドライバURLのdb_propsプロパティで指定する必要があります。詳細は、A.3.2項「外部データベースを使用したデータの格納」を参照してください。

表A-1に、ドライバURLで渡すことができるプロパティを示します。

表A-1 URLプロパティ

プロパティ

必須

種類

デフォルト

説明

db_propsまたはdp

いいえ

文字列(ファイルの場所)

空の文字列

外部データベースの接続構成を含む.propertiesファイルの名前。このファイルの内容の詳細は、A.3.2項「外部データベースを使用したデータの格納」を参照してください。

注意: このプロパティには、.propertiesファイルの名前をファイル拡張子なしで含める必要があります。

注意: この.propertiesファイルをランタイム・エージェントのクラスパスに含める必要があります。

注意: この表にリストされているすべてのdb_プロパティを使用して、外部データベースの接続構成を指定できます。

ldap_propsまたはlp

いいえ

文字列(ファイルの場所)

N/A

ディレクトリの接続構成を含む.propertiesファイルの名前。このファイルの内容の詳細は、A.3.3項「LDAPディレクトリの接続構成」を参照してください。

注意: このプロパティには、.propertiesファイルの名前をファイル拡張子なしで含める必要があります。

注意: この.propertiesファイルをランタイム・エージェントのクラスパスに含める必要があります。

注意: この表にリストされているすべてのldap_プロパティを使用して、LDAPディレクトリの接続構成を指定できます。

ldap_metadataまたはlm

いいえ

文字列(ファイルの場所)

N/A

参照LDAPツリーのディレクトリの接続構成を含む.propertiesファイルの名前。このファイルの内容の詳細は、A.3.3項「LDAPディレクトリの接続構成」を参照してください。参照ツリーの説明は、A.2.1.4項「参照LDAPツリー」を参照してください。

注意: このプロパティには、.propertiesファイルの名前をファイル拡張子なしで含める必要があります。

注意: この.propertiesファイルをランタイム・エージェントのクラスパスに含める必要があります。

注意: この表に後出するすべてのlm_プロパティを使用して、参照LDAPディレクトリの接続構成を指定できます。

case_sensまたはcs

いいえ

ブール値(true | false)

false

LDAPおよびRDBMSの両方の管理オブジェクトについて、大/小文字を区別するモードを有効または無効にします。

alias_bundleまたはab

いいえ

文字列(ファイルの場所)

空の文字列

プロパティ・ファイルへの絶対パスとファイル拡張子の両方を含むプロパティ・ファイルのフルネーム。プロパティ・ファイルは、LDAPからリレーショナルへのマッピングの別名のリストが含まれているファイルです。このファイルが存在しない場合は、ドライバによって作成されます。詳細は、A.3.4項「表の別名の構成」を参照してください。

注意: ファイル拡張子は.propertiesである必要はありません。

alias_bundle_encodingまたはabe

いいえ

文字列(エンコーディング・コード)

デフォルトのエンコーディング

別名バンドル・ファイル・エンコーディング。このエンコーディングは、alias_bundleファイルの読取りおよび上書き時に使用されます。定義されていない場合は、デフォルトのエンコーディングが使用されます。

サポートされているエンコーディングのリストは、次のURLにあります: http://java.sun.com/j2se/1.3/docs/guide/intl/encoding.doc.html

grouping_factorまたはgf

いいえ

整数

2

単一のリレーショナル表マッピングを設定するためにグループ化されるオブジェクト・クラスの数を決定します。詳細は、A.2.1.2項「グループ化係数」を参照してください。

key_columnまたはkc

いいえ

ブール値(true | false)

false

trueに設定すると、SNPSLDAPKEYという名前の技術的な列が作成され、各LDAPエントリの相対識別名(RDN)が格納されます。詳細は、A.2.1.3項「マッピング例外」を参照してください。

numeric_idsまたはni

いいえ

ブール値(true | false)

true

trueに設定すると、すべての内部の主キーおよび外部キーがNUMERIC型になります。それ以外の場合はVARCHAR型になります。

id_lengthまたはil

いいえ

整数

10 / 30

内部の主キーおよび外部キーの列の長さ。デフォルトは、列型がNUMERICの場合は10、VARCHARの場合は30です。

table_prefixまたはtp

いいえ

文字列

N/A

現在の接続のリレーショナル表に追加される接頭辞。

ldap_auth

いいえ

文字列

simple

LDAPディレクトリの認証方式。A.3.3項「LDAPディレクトリの接続構成」のauthプロパティを参照してください。

ldap_url

はい

文字列

N/A

LDAPディレクトリのURL。A.3.3項「LDAPディレクトリの接続構成」のurlプロパティを参照してください。

ldap_user

いいえ

文字列

空の文字列

LDAPディレクトリのユーザー名。A.3.3項「LDAPディレクトリの接続構成」のuserプロパティを参照してください。

ldap_password

いいえ

文字列

空の文字列

LDAPディレクトリ・ユーザーのパスワード。A.3.3項「LDAPディレクトリの接続構成」のpasswordプロパティを参照してください。

ldap_basedn

いいえ

文字列

N/A

LDAPディレクトリのベースDN。A.3.3項「LDAPディレクトリの接続構成」のbasednプロパティを参照してください。

lm_auth

いいえ

文字列

simple

参照LDAPの認証方式。A.3.3項「LDAPディレクトリの接続構成」のauthプロパティを参照してください。

lm_url

はい

文字列

N/A

参照LDAP URL。A.3.3項「LDAPディレクトリの接続構成」のurlプロパティを参照してください。

lm_user

いいえ

文字列

空の文字列

参照LDAPディレクトリのユーザー名。A.3.3項「LDAPディレクトリの接続構成」のuserプロパティを参照してください。

lm_password

いいえ

文字列

空の文字列

参照LDAPディレクトリ・ユーザーのパスワード。A.3.3項「LDAPディレクトリの接続構成」のpasswordプロパティを参照してください。

lm_basedn

いいえ

文字列

N/A

参照LDAPディレクトリのベースDN。A.3.3項「LDAPディレクトリの接続構成」のbasednプロパティを参照してください。

db_driver

はい

文字列

N/A

外部データベースのJDBCドライバ。A.3.2項「外部データベースを使用したデータの格納」のdriverプロパティを参照してください。

db_url

はい

文字列

N/A

外部データベースのJDBC URL。A.3.2項「外部データベースを使用したデータの格納」のurlプロパティを参照してください。

db_user

いいえ

文字列

空の文字列

外部データベース・ユーザー。A.3.2項「外部データベースを使用したデータの格納」のuserプロパティを参照してください。

db_password

いいえ

文字列

空の文字列

外部データベースのパスワード。A.3.2項「外部データベースを使用したデータの格納」のpasswordプロパティを参照してください。

db_schema

いいえ

文字列

空の文字列

外部データベースのスキーマ。A.3.2項「外部データベースを使用したデータの格納」のschemaプロパティを参照してください。

db_catalog

いいえ

文字列

空の文字列

外部データベース・カタログ。A.3.2項「外部データベースを使用したデータの格納」のcatalogプロパティを参照してください。

db_drop_on_disconnectまたはdb_dod

いいえ

ブール値(true|false)

true

切断時に外部データベースから表をドロップします。A.3.2項「外部データベースを使用したデータの格納」のdrop_on_disconnectプロパティを参照してください。

db_load_modeまたはdb_lm

いいえ

文字列

ci

外部データベースのロード方法。A.3.2項「外部データベースを使用したデータの格納」のload_modeプロパティを参照してください。

page_size

いいえ

整数

1000

このページ・サイズ制限を適用してLDAPサーバーからデータを読み取ります。

transform_nonasciiまたはtna

いいえ

ブール値(true|false)

true

非ASCIIを変換します。非ASCII文字を保持するにはfalseに設定します。

URLの例

ここにURLの例をリストします。

- jdbc:snps:ldap?lp=ldap_mir&ldap_basedn=o=tests&gf=10&lf=
ldap_mir .propertiesファイルで指定されているLDAPディレクトリに接続し、ldapバンドルのbasednプロパティをオーバーライドしてグループ化係数10を使用します。一般情報(重要)が標準の出力に送信されます。

- jdbc:snps:ldap?lp=ldap_ours&lm=generic&ab=c:/tmp/aliases.txt&gf=10&kc=true
ldap_ours .propertiesファイルを使用してLDAPディレクトリに接続します。リレーショナル・モデルの作成には、lmプロパティで指定されている汎用ディレクトリ・ツリーを使用します。リレーショナル構造の作成には別名バンドル・ファイルを使用します。最大グループ化係数10を使用します。SNPSLDAPKEYフィールドに対するキー列の作成を有効にして、リレーショナル・モデルでの更新要求を可能にします。

- jdbc:snps:ldap?lp=ldap_mir&dp=mysql_mir_ldap&ldap_basedn=dc=tests&lm=ldap_mir&lm_basedn=dc=model&ab=d:/temp/mapldap.txt&
ldap_mir .propertiesファイルを使用してLDAPディレクトリに接続します。ldap basednプロパティをオーバーライドします。同じディレクトリのdc=modelサブツリーを使用してマッピングを実行します。別名バンドルを使用します。lmデータベース・プロパティ(ロード・モード)をオーバーライドします。グループ化係数0を指定して、グループ化しない(グループ化を無効にする)ことを示します。完全なトレース・ロギングをアクティブにします。

- hydraroidマシンのLDAPディレクトリに接続します。LDAPサーバーの接続情報(URL、ベースDN、ユーザーおよびパスワード)は、URL内でldap_xxxという書式で指定されています。

jdbc:snps:ldap?ldap_url=ldap://hydraroid:389/dc=localhost,dc=localdomain&ldap_password=KPLEKFMJKCLFJMDFDDGPGPDB&ldap_user=cn=orcladmin&ldap_basedn=ou=applications

A.3.2 外部データベースを使用したデータの格納

LDAPからリレーショナルへのマッピングによって生成されたLDAPツリーのリレーショナル構造は、ランタイム・エージェントのメモリーまたは外部データベースに格納されます。

注意:
外部記憶域がサポートされるテクノロジのリストには、次のOracle Technical Network (OTN)からアクセスできます。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html

外部記憶域は、表A-2に示す一連のプロパティで構成されます。

外部記憶域プロパティは、次の複数の方法で渡すことができます。

- ドライバURLでのプロパティの受渡し

- ODI Studioでのプロパティの設定

- プロパティ・ファイルでのプロパティの設定

A.3.2.1 ドライバURLでのプロパティの受渡し

ドライバURLでプロパティを直接設定できます。この方法を使用する場合は、プロパティに接頭辞としてdb_を付ける必要があります。たとえば、Oracleデータベースに接続する場合は、driverパラメータでOracle JDBCドライバ名を次のように指定します。

db_driver=oracle.jdbc.OracleDriver.

A.3.2.2 ODI Studioでのプロパティの設定

プロパティは、トポロジ・ナビゲータのデータ・サーバー・エディタの「プロパティ」タブで指定できます。この方法を使用する場合は、プロパティに接頭辞としてdb_を付ける必要があります。たとえば、driverパラメータを設定するとします。

1. 「キー」列にdb_driverと入力します。

2. Oracleデータベースに接続している場合は、「値」列にoracle.jdbc.OracleDriverと入力します。

A.3.2.3 プロパティ・ファイルでのプロパティの設定

外部データベース・プロパティ・ファイルでプロパティを設定できます。プロパティ・バンドルとも呼ばれるこのプロパティ・ファイルは、.properties拡張子を持つテキスト・ファイルであり、ここに含まれる一連の行には、それぞれ、<property>=<value>のペアがあります。この外部データベース・プロパティ・ファイルには、リレーショナル・データベース・スキーマへのJDBC接続のプロパティが含まれています。このプロパティ・ファイルは、JDBC URLのdb_propsプロパティを使用して参照されます。

注意:
LDAPドライバによって外部プロパティ・バンドル・ファイルがロードされるのは、ランタイム起動時の1回のみであることを理解することが重要です。これらのファイルでエラーが発生した場合は、Oracle Data Integratorを終了して再ロードしてから、再テストすることをお薦めします。

この方法を使用する場合は、次のことに注意してください。

- プロパティ・ファイルのプロパティには接頭辞は付けず、表A-2に示すように使用します。

- db_propsプロパティはプロパティ・ファイルの名前に設定し、.properties拡張子は付けません。たとえば、クラスパスにprod_directory.propertiesファイルがある場合は、このファイルをdb_props=prod_directoryのように参照する必要があります。
db_propsプロパティは、外部データベース・プロパティ・ファイルに接続情報が格納されているデータベース・スキーマに、スキーマをロードする必要があることを示します。

- プロパティ・ファイルはLDAP接続を使用してエージェントによってデプロイする必要があります。プロパティ・ファイルの場所は、使用するエージェントによって異なります。

- ローカル・エージェント(Studio): 外部DBプロパティ・ファイルを<user.dir>/odi/oracledi/userlibフォルダに配置します。

- スタンドアロン・エージェント: 外部DBプロパティ・ファイルをoracledi/agent/driversフォルダに配置します。

- JavaEEエージェント: 外部DBプロパティ・ファイルをJARまたはZIPファイルに圧縮し、Java EEエージェントによって生成されたテンプレートに追加する必要があります。詳細は、『Oracle Data Integratorの管理』のJava EEアプリケーション・サーバー(Oracle WebLogic Server)でのエージェントのデプロイに関する項を参照してください。

- プロパティ・バンドル・ファイルを使用する場合は、Oracle Data Integratorのクラスパスにそのプロパティ・バンドルが存在することを確認する必要があります。通常は、このバンドルをdriversディレクトリにインストールする必要があります。

注意:
LDAPドライバでは、外部データベースへの接続時にJDBC接続が使用されます。この外部データベースにアクセスするためのJDBCドライバも、必ずODIクラスパスに配置してください。

外部データベースのプロパティをURLで設定またはオーバーライドできます。これらのプロパティには、接頭辞として文字列db_を付ける必要があります。次に例を示します。

jdbc:snps:ldap?ldap_url=ldap://localhost:389/&ldap_basedn=o=company&db_driver=oracle.jdbc.OracleDriver&db_url=<external_db_url>

外部記憶域を構成するためのプロパティを、表A-2に示します。

表A-2 外部記憶域構成のプロパティ

プロパティ

必須

種類

デフォルト

説明

driver

はい

文字列

N/A

JDBCドライバ名。

url

はい

文字列

N/A

JDBC URL。

user

いいえ

文字列

空の文字列

データベースへの接続に使用するログイン。

password

いいえ

文字列

空の文字列

暗号化されたデータベース・ユーザー・パスワード。

注意: パスワードを暗号化するには、encode.batコマンドを使用します。詳細は、Oracle Data Integratorのインストールと構成を参照してください。

schema

いいえ

文字列

空の文字列

LDAPツリーを格納するデータベース・スキーマ。Microsoft SQLServerにはこのプロパティを使用せず、かわりにカタログ・プロパティを使用してください。

catalog

いいえ

文字列

空の文字列

LDAPツリーを格納するデータベース・カタログ。Microsoft SQL Server専用です。このプロパティをschemaプロパティと同時に使用しないでください。

drop_on_disconnectまたはdod

いいえ

ブール値(true | false)

true

trueの場合は、切断時に外部データベースから表がドロップされます。falseに設定すると、表がデータベース内に保持されます。

load_modeまたはlm

いいえ

文字列

ci

ロード方法。次の値を使用できます。

- n (none): モデルおよび表のマッピングが、メモリー内のみに作成されます。

- dci (drop_create_insert): 名前の競合を発生させる可能性がある表をすべてドロップした後、表を作成してリレーショナル・モデルにLDAPツリーをロードします。

- ci(create_insert): リレーショナル表を作成し、既存の表に対して例外をスローした後、リレーショナル・モデルにLDAPツリーをロードします。

unicode

いいえ

ブール値(true | false)

MS SQL Serverの場合:

unicode = trueの場合はNVARCHARが使用されます。

unicode = falseまたは未設定の場合は、VARCHARが使用されます。

varchar_lengthまたはvl

いいえ

整数

255

文字列データの格納に使用されるリレーショナル構造のすべての列のサイズ。

次に、外部のOracleデータベースに接続するための外部データベース.propertiesファイルの例を示します。

driver=oracle.jdbc.OracleDriver
url=jdbc:oracle:thin:@hydraro:1521:SNPTST1
user=LDAP_T_1
password=ENCODED_PASSWORD
schema=LDAP_T_1

A.3.3 LDAPディレクトリの接続構成

Oracle Data Integrator driver for LDAPは、表A-3に示すプロパティを使用して、LDAPデータまたは参照LDAPツリーを含むディレクトリ・サーバーに接続します。これらのプロパティは、プロパティ・バンドル・ファイルまたはドライバURLで指定できます。

ディレクトリ接続を構成するためのプロパティの詳細を、表A-3に示します。

表A-3 ディレクトリ接続のプロパティ

プロパティ

必須

種類

デフォルト

説明

auth

いいえ

文字列

simple

認証方式。

url

はい

文字列

N/A

ディレクトリに接続するためのURL。LDAP URL。

注意: このドライバでは、LDAPS (LDAP over SSL)プロトコルがサポートされます。LDAPS URLは、ldaps://で始める必要があります。LDAPSを使用してサーバーに接続するには、javaマシンに証明書を手動でインストールする必要があります。詳細は、JVMで提供されるkeytoolプログラムを参照してください。

user

いいえ

文字列

空の文字列

LDAPサーバーのユーザー・ログイン名。authが設定されている場合のみ必須です。

注意: JDBC Driver for LDAPとの接続を作成するためにuserおよびpasswordプロパティを指定した場合は、LDAPディレクトリの接続にこれらのプロパティが使用されます。

password

いいえ

文字列

空の文字列

LDAPサーバーのユーザー・ログイン・パスワード。authが設定されている場合のみ必須です。

注意: URL構文のjdbc:snps:ldap2以外では、パスワードを暗号化する必要があります。

注意: パスワードを暗号化するには、encode.batコマンドを使用します。詳細は、Oracle Data Integratorのインストールと構成を参照してください。

basedn

いいえ

文字列

N/A

LDAPツリーへの接続に使用するベースDN。ベースDNは、LDAPディレクトリ・ツリーの最上位レベルです。指定されていない場合は、LDAP URLで指定されたベースDNが使用されます。

LDAPプロパティ・ファイルの内容の例を次に示します。

url=ldap://ours:389
user=cn=Directory Manager
password=ENCODED_PASSWORD
basedn=dc=oracle,dc=com

A.3.4 表の別名の構成

LDAPドライバでは、表の別名を使用することで、Oracle Data Integratorでのモデル表名の定義をある程度柔軟に行えます。これは特に、LDAPツリーのナビゲートに使用されるアルゴリズムによって、LDAPオブジェクト・クラス階層に基づく長い複合名が生成される場合に役立ちます。RDBMS固有のオブジェクト名の長さの制約に関連する問題を回避するために、LDAPドライバでは別名を設定して使用できます。

注意:
「物理アーキテクチャ」アコーディオンにあるテクノロジ・エディタの「その他」タブで、「最大表名長」および「最大列名長」のデフォルト値を変更することもできます。

表の別名のファイルを作成するには、次のようにします。

1. LDAPドライバ・データ・サーバーのURLにalias_bundle (ab)プロパティを含め、別名テキスト・ファイルの名前を指定するように設定します。次に例を示します。
jdbc:snps:ldap?.....&ab=C:/tmp/aliases.txt&....

alias_bundleプロパティを指定すると、接続時にドライバによって別名ファイルが作成されます。通常、ユーザーは、最初に、LDAPドライバを介して接続し、LDAPドライバでは、リバース・エンジニアリング操作によって作成される潜在的な表名のリストが含まれたこのファイルを作成します。

2. LDAPデータ・サーバーへの接続をテストします。

3. テキスト・ファイルが作成され、正しく構成されていることを検証します。リストは、<original table name > = <desired alias name>という値で構成されます。例A-1は、ユーザーが短縮名を指定した後に抽出される別名ファイルを示しています。詳細は、手順4を参照してください。

例A-1 別名ファイル

INETORGPERSON_ORGANIZATIONALPERSON_PERSON_BISOBJECT_MAIL = PERSONMAIL
ORGANIZATIONALUNIT_RFC822MAILMEMBER = ORG_228MAIL
INETORGPERSON_ORGANIZATIONALPERSON_PERSON = ORG_PERSON
ORGANIZATIONALUNIT_MEMBER = ORG_UN_MEMBER
ORGANIZATIONALUNIT = ORG_UNIT
ROOT = ROOT
....

4. 別名テキスト・ファイルで、最初に導出される複合名を置き換えるための別名(短いテキスト値)を追加して、ファイルを保存します。

5. 同じLDAPデータ・サーバーに再接続します。リレーショナル・スキーマが作成され、今回は、別名を使用してリレーショナル表名が定義されます。

6. ここで、22.5.2項「LDAPモデルのリバース・エンジニアリング」の説明に従って、LDAPディレクトリをリバース・エンジニアリングします。Oracle Data Integratorによってデータストアが作成され、別名ファイルでは表名が別名として定義されます。

注意:
LDAPディレクトリのオブジェクト・クラス構造または属性セットになんらかの変更が適用されている場合は、ドライバによってこのファイルが再書込みされ、表名リストには新規または変更されたエントリが含まれます。

A.4 SQL構文

A.4.1項「SQL文」に示すSQL文は、Oracle Data Integrator driver for LDAPを使用する場合に使用できます。これらの文を使用すると、標準のSQL文を介してリレーショナル・データ構造およびデータを管理できます。

注意:

- 外部データベースを使用する場合は、後出のコマンドのかわりに専用の問合せエンジン構文を使用できます。

- LDAPドライバは、自動コミット・モードで独自に動作します。COMMITまたはROLLBACKコマンドによる明示的なトランザクション管理は許可されません。

- 外部データベースを使用してLDAPツリーのデータを格納する場合、DDL文は一時表のみで実行できます。

表A-4は、リストされているDML操作を特定のキー・フィールドで実行する場合に適用される推奨事項をまとめたものです。

表A-4 キー・フィールドでのDML操作

列のタイプ

挿入

更新

削除

外部キー

マスター表の参照制約および順序付きの表の移入操作に注意します。

不可

マスター表の参照制約および順序付きの削除要求に注意します。

主キー

スレーブ表の参照制約および順序付きの表の移入操作に注意します。

不可

スレーブ表の参照制約および順序付きの削除要求に注意します。

IS_xxx

元のオブジェクト・クラスに正しいフラグ値を関連付けるように注意します。

不可

OK

Key_Column

正しいLDAP構文でRDN値を設定するように注意します。

不可

OK

A.4.1 SQL文

任意の数のコマンドを組み合せることができます。セミコロン(;)を使用して各コマンドを区切ることができますが、使用しなくても構いません。

A.4.1.1 DISCONNECT

DISCONNECT

この接続を閉じます。

注意

- JDBCインタフェースを使用している場合は、このコマンドをコールする必要はありません。接続が閉じる際に自動的にコールされます。

- 切断後は、この接続で他の問合せを実行することはできません。

A.4.1.2 INSERT INTO

1つ以上の新しいデータ行を表に挿入します。

INSERT INTO <table_name> [ ( <column_name> [,...] ) ]
{ VALUES (<expression> [,...]) | <SELECT Statement> }

A.4.1.3 SELECT

スキーマ内の1つ以上の表から情報を取得します。

SELECT [DISTINCT] { <select_expression> | <table_name>.* | * } [, ... ]
[ INTO <new_table> ]
FROM <table_list>
[ WHERE <expression> ]
[ GROUP BY <expression> [, ...] ]
[ ORDER BY <order_expression> [, ...] ]
[ { UNION [ALL] | {MINUS|EXCEPT} | INTERSECT } <select_statement>
]

<table_list> ::=
<table_name> [ { INNER | LEFT [OUTER] } JOIN <table_name> ON <expression> ]
[, ...]

<select_expression> ::=
{ <expression> | COUNT(*) | {COUNT | MIN | MAX | SUM | AVG}
(<expression>) <column_alias>}

<order_expression> ::=
{ <column_number> | <column_alias> | <select_expression> } [ ASC | DESC ]

A.4.1.4 UPDATE

データベース内の表のデータを変更します。

UPDATE table SET column = <expression> [, ...] [WHERE <expression>]

A.4.1.5 式、条件および値

<expression> ::=
[NOT] <condition> [ { OR | AND } <condition>
]

<condition> ::=
{ <value> [ || <value> ]
| <value> { = | < | <= | > | >= | <> | != | IS [NOT] } <value>
| EXISTS(<select_statement>)
| <value> BETWEEN <value> AND <value>
| <value> [NOT] IN ( {<value> [, ...] | selectStatement } )
| <value> [NOT] LIKE <value> [ESCAPE] value }

<value> ::=
[ + | - ] { term [ { + | - | * | / } term ]
| ( condition )
| function ( [parameter] [,...] )
| selectStatement giving one value

<term> ::=
{ 'string' | number | floatingpoint | [table.]column | TRUE | FALSE | NULL }

<string> ::=

- 開始および終了には、単一の「'」を使用します。「'」で開始した文字列内に「'」を作成するには、「''」を使用します。

- LIKEでは、任意の数(0を含む)の文字と一致させる場合は%を使用し、1つの文字と完全に一致させる場合は_を使用します。%自体の検索には\%、_自体の検索には\_を使用するか、ESCAPE句を使用してその他の任意のエスケープ文字を設定できます。

<name> ::=

- 名前の先頭は文字で、後に任意の数の文字または数字が続きます。文字列および引用符で囲まれた識別子以外の小文字は、大文字に変換されます。名前では大/小文字は区別されません。

- 識別子(表または列など)を引用符で囲んで、名前として使用できます。引用符で囲まれた識別子は、「"」で始まり「"」で終わります。引用符で囲まれた識別子の中に「"」を作成するには、「""」を使用します。引用符で囲まれた識別子を使用することで、大/小文字が混在する表および表名を作成できます。例: CREATE TABLE "Address" ("Nr" INTEGER,"Name" VARCHAR); SELECT * FROM "Address"。引用符で囲まれた識別子は文字列ではありません。

<values> ::=

- 日付値は「'」で始まり「'」で終わります。書式はyyyy-mm-ddです(java.sql.Dateを参照)。

- 時間値は「'」で始まり「'」で終わります。書式はhh:mm:ssです(java.sql.Timeを参照)。

- バイナリ・データは「'」で始まり「'」で終わります。書式は16進値です。たとえば'0004ff'は、最初が0、2番目が4、最後が255 (0xff)の3バイトです。

A.4.2 SQLファンクション

表A-5に数値ファンクションを示します。

表A-5 数値ファンクション

ファンクション

説明

ABS(d)

double値の絶対値を戻します。

ACOS(d)

角度のアーク・コサインを戻します。

ASIN(d)

角度のアーク・サインを戻します。

ATAN(d)

角度のアーク・タンジェントを戻します。

ATAN2(a,b)

a/bのタンジェントを戻します。

BITAND(a,b)

a & bを戻します。

BITOR(a,b)

a | bを戻します。

CEILING(d)

d以上の最小整数を戻します。

COS(d)

角度のコサインを戻します。

COT(d)

角度のコタンジェントを戻します。

DEGREES(d)

ラジアンを角度に変換します。

EXP(d)

e (2.718...)のd乗を戻します。

FLOOR(d)

d以下の最大整数を戻します。

LOG(d)

eを底とする自然対数を戻します。

LOG10(d)

10を底とする対数を戻します。

MOD(a,b)

aをbで割った剰余を戻します。

PI()

円周率(3.1415...)を戻します。

POWER(a,b)

aのb乗を戻します。

RADIANS(d)

角度をラジアンに変換します。

RAND()

0.0以上1.0未満の乱数xを戻します。

ROUND(a,b)

aを小数点以下b桁に丸めます。

SIGN(d)

dが0未満の場合は-1、dが0の場合は0、dが0より大きい場合は1を戻します。

SIN(d)

角度のサインを戻します。

SQRT(d)

平方根を戻します。

TAN(d)

角度の三角関数タンジェントを戻します。

TRUNCATE(a,b)

aを小数点以下b桁に切り捨てます。

表A-6に文字列ファンクションを示します。

表A-6 文字列ファンクション

ファンクション

説明

ASCII(s)

sの左端の文字のASCIIコードを戻します。

BIT_LENGTH(s)

文字列の長さをビット数で戻します。

CHAR(c)

ASCIIコードがcの文字を戻します。

CHAR_LENGTH(s)

文字列の長さを文字数で戻します。

CONCAT(str1,str2)

str1とstr2を連結して戻します。

DIFFERENCE(s1,s2)

s1とs2の発音の差を戻します。

HEXTORAW(s1)

16進数からRAWに変換された文字列を戻します。

INSERT(s,start,len,s2)

startからlen文字分をs2に置き換えて、文字列を戻します。

LCASE(s)

sを小文字に変換します。

LEFT(s,count)

sの左端からcount文字分を戻します。

LENGTH(s)

sの文字数を戻します。

LOCATE(search,s,[start])

startから開始して、s内でsearchが検出された最初の索引(1=左、0=見つからない)を戻します。

LTRIM(s)

sの先頭の空白をすべて削除します。

OCTET_LENGTH(s)

文字列の長さをバイト数で戻します。

RAWTOHEX(s)

変換された文字列を戻します。

REPEAT(s,count)

sをcount回分繰り返して戻します。

REPLACE(s,replace,s2)

sに出現するすべてのreplaceをs2に置き換えます。

RIGHT(s,count)

sの右端からcount文字分を戻します。

RTRIM(s)

末尾の空白をすべて削除します。

SOUNDEX(s)

sの発音を表す4文字のコードを戻します。

SPACE(count)

count個分のスペースで構成される文字列を戻します。

SUBSTR(s,start[,len])

(SUBSTRINGの別名)

SUBSTRING(s,start[,len])

start (1=左)からlen文字分のサブストリングを戻します。

SUBSTRING(s FROM start [FOR len])という構文もあります。

TRIM

TRIM([{LEADING | TRAILING | BOTH}] FROM s): 先頭または末尾(もしくは両方)のスペースをsから削除します。

UCASE(s)

sを大文字に変換します。

LOWER(s)

sを小文字に変換します。

UPPER(s)

sを大文字に変換します。

表A-7に、日時ファンクションを示します。

表A-7 日時ファンクション

ファンクション

説明

CURDATE()

現在の日付を戻します。

CURTIME()

現在の時間を戻します。

CURRENT_DATE

現在の日付を戻します。

CURRENT_TIME

現在の時間を戻します。

CURRENT_TIMESTAMP

現在のタイムスタンプを戻します。

DATEDIFF(s, d1,d2)

日時d1から日時d2までの経過時間を、sで指定された単位で戻します。sには次の値を使用できます。'ms'='ミリ秒'、'ss'='秒','mi'='分','hh'='時間'、'dd'='日'、'mm'='月'、'yy' = '年'。

DAYNAME(date)

曜日の名前を戻します。

DAYOFMONTH(date)

月の日付(1から31)を戻します。

DAYOFWEEK(date)

週の曜日(1は日曜日)を戻します。

DAYOFYEAR(date)

その年の何日目か(1から366)を戻します。

EXTRACT

EXTRACT ({YEAR | MONTH | DAY | HOUR | MINUTE | SECOND} FROM <datetime>): <datetime>値から適切な部分を抽出します。

HOUR(time)

時間(0から23)を戻します。

MINUTE(time)

分(0から59)を戻します。

MONTH(date)

月(1から12)を戻します。

MONTHNAME(date)

月の名前を戻します。

NOW()

現在の日時をタイムスタンプとして戻します。

QUARTER(date)

四半期(1から4)を戻します。

SECOND(time)

秒(0から59)を戻します。

WEEK(date)

その年の何週目か(1から53)を戻します。

YEAR(date)

年を戻します。

日付値は「'」で始まり「'」で終わります。書式はyyyy-mm-ddです(java.sql.Dateを参照)。時間値は「'」で始まり「'」で終わります。書式はhh:mm:ssです(java.sql.Timeを参照)。

表A-8にシステム・ファンクションを示します。

表A-8 システム・ファンクション

ファンクション

説明

IFNULL(exp,value)

expがNULLの場合はvalueを戻し、NULLでない場合はexpを戻します。

CASEWHEN(exp,v2,v2)

expがtrueの場合はv1を戻し、trueでない場合はv2を戻します。

CONVERT(term,type)

expを別のデータ型に変換します。

COALESCENCE(e1,e2,e3,...)

e1がNULLでない場合はe1を戻し、そうでない場合はe2を評価します。e2がNULLの場合はe2を戻し、そうでない場合はe3を評価し、以降、同様に続きます。

NULLIF(v1,v2)

v1がv2と等しくない場合はv1を戻し、等しい場合はNULLを戻します。

CASE WHEN

CASE WHEN文には次の2つの構文があります。

CASE v1 WHEN v2 THEN v3 [ELSE v4] END: v1がv2と等しい場合はv3を戻し、等しくない場合はv4またはNULL (ELSEが指定されていない場合)を戻します。

CASE WHEN e1 THEN v1[WHEN e2 THEN v2] [ELSE v4] END: e1がtrueの場合はv1を戻します。それ以外にも条件と値が設定されている場合は、これを繰り返します。いずれの条件とも一致しない場合は、v4またはNULL (ELSEが指定されていない場合)を戻します。

CAST(term AS type)

expを別のデータ型に変換します。

表A-9に、システムおよび接続ファンクションを示します。

表A-9 システムおよび接続ファンクション

ファンクション

説明

DATABASE()

この接続のデータベース名を戻します。

USER()

この接続のユーザー名を戻します。

IDENTITY()

この接続によって挿入された最後のID値を戻します。

A.5 実装されるJDBC API機能

表A-10に、Oracle Data Integrator driver for LDAPのJDBC API機能をリストします。

表A-10 JDBC APIの機能

機能グループ

JDBCのバージョン

サポート

バッチ更新

2.0コア

はい

Blob/Clob

2.0コア

いいえ

JNDIデータソース

2.0オプション

いいえ

フェイルオーバー・サポート

-

いいえ

トランザクション・セーブポイント

3.0

いいえ

Unicodeサポート

-

いいえ

分散トランザクション

2.0オプション

いいえ

接続プーリング

2.0オプション

いいえ

クラスタ・サポート

-

いいえ

次の表に、Oracle Data Integrator driver for LDAPでサポートされているJDBCクラスを示します。

表A-11 JDBCクラス

JDBCクラス

JDBCのバージョン

サポート

Array

2.0コア

いいえ

Blob

2.0コア

いいえ

Clob

2.0コア

いいえ

CallableStatement

1.0

はい

Connection

1.0

はい

ConnectionPoolDataSource

2.0オプション

いいえ

DatabaseMetaData

1.0

はい

DataSource

2.0オプション

いいえ

Driver

1.0

はい

PreparedStatement

1.0

はい

Ref

2.0コア

いいえ

RowSet

2.0オプション

いいえ

ResultSet

1.0

はい

ResultSetMetaData

1.0

はい

Statement

1.0

はい

Struct

2.0コア

いいえ

XAConnection

2.0オプション

いいえ

XADataSource

2.0オプション

いいえ

B Oracle Data Integrator Driver for XMLの参照情報

この付録では、Oracle Data Integrator driver for XMLの使用方法を説明します。

この付録には次の項が含まれます:

- B.1項「Oracle Data Integrator Driver for XMLの概要」

- B.2項「XMLの処理の概要」

- B.3項「インストールおよび構成」

- B.4項「ドライバ・コマンドの詳細」

- B.5項「SQL構文」

- B.6項「実装されるJDBC API機能」

- B.7項「リッチ・メタデータ」

- B.8項「サポートされているXMLスキーマの機能」

B.1 Oracle Data Integrator Driver for XMLの概要

Oracle Data Integrator Driver for XML(XMLドライバ)では、XMLドキュメントがJDBCデータソースとして処理されます。これにより、XMLドキュメントをOracle Data Integratorでデータ・サーバーとして使用することが可能になります。

Oracle Data Integrator Driver for XMLとともにOracle Data Integrator使用すると、XMLファイルへの変更を標準のSQL構文で実行できます。これらの操作はトランザクション内で発生し、コミットまたはロールバックが可能です。

Oracle Data Integrator driver for XMLでサポートされている機能は次のとおりです。

- 標準のSQL (Structured Query Language)構文

- 相関サブ問合せ、内部および外部結合

- ORDER BYおよびGROUP BY

- COUNT、SUM、MIN、MAX、AVGおよびその他のファンクション

- 標準のSQLファンクション

- トランザクション管理

- 参照整合性(外部キー)

- XMLデータに対して行った変更のXMLファイルへの保存

B.2 XMLの処理の概要

XMLドライバは次のように機能します。

1. ドライバは、XMLからSQLへのマッピングを使用して、(接続時またはユーザー・リクエストに応じて)XML構造およびデータをリレーショナル・スキーマにロードします。

2. ユーザーは、通常のSQL文、またはドライバ操作用の特定のドライバ・コマンドを介してデータを操作し、リレーショナル・スキーマを使用します。

3. XMLドライバは、切断時またはユーザー・リクエストに応じて、スキーマに格納されているデータおよび構造を元のXMLファイルに同期化します。

B.2.1 XMLからSQLへのマッピング

XMLからSQLへのマッピングは複雑なプロセスで、階層構造(XML)をリレーショナル構造(スキーマ)にマップするために使用されます。このマッピングは自動的に行われます。

要素および属性のマッピング

XMLドライバでは、XMLの要素および属性が次のようにマップされます。

- 要素は、同じ名前の表としてマップされます。

- 属性は、属性と似た名前の列としてマップされます。各列は、属性の要素を表す表内に作成されます。

階層および順序のマッピング

次のように、リレーショナル構造には追加のデータが表示されます。

- XML要素の階層、または要素間の1対多関係をマップするために、要素に対応するそれぞれの表には、XMLドライバによって次のような追加の列が生成されます。

- <element_name>PK: 要素を識別するための列です。

- <parent_element_name>FK: 階層内で現在の要素を親とリンクするための列です。親要素の<element_name>PK値と一致する値が含まれます。XML再帰の場合、親要素または親要素の祖先を同じ表に配置できます。

- XMLファイルの要素とは異なり、(特定の列を使用して順序を定義していないかぎり)表のレコードは順序付けされません。要素の順序を保持するために、ドライバでは<element_name>ORDERという名前の列も生成されます。リレーショナル・スキーマに新しい行を追加する場合は、親要素の下に要素が正しく順序付けされるように、ORDER列が正しく設定されていることを確認してください。

- 階層のルートは、ルート要素と同じ名前のルート表によって識別されます。この表には、次の列を持つ単一のレコードが含まれます。

- <root_element_name>PK: レベル1のすべてのサブ要素は、このPKエントリを参照します。

- SNPSFILENAME: この列には、このスキーマにロードされたXMLファイルの名前が含まれます。

- SNPSFILEPATH: この列には、XMLファイルのパスが含まれます。

- SNPSLOADDATE: この列には、ファイルがスキーマにロードされた日時が含まれます。

この表の値はドライバによって管理されるため、変更しないでください。

マッピング例外

この項では、追加のデータのマッピングに関する特定の状況について説明します。

- #PCDATAのみを含む要素は、表としてはマップされず、それぞれの親要素を表す表の列としてマップされます。これらの列は、<element_name>_DATAという名前になります。

- リスト属性は、リンク(PK、FK)を含む新しい表として、リストが含まれている要素を表す表にマップされます。

- 表名または列名とSQL予約キーワードとの間の名前の競合を回避するために、SQL予約キーワードと名前が一致するXML要素および属性の名前は、リレーショナル構造内で自動的に変更されます(名前の後にアンダースコアが追加されます)。たとえば、SELECTという名前の要素はSELECT_という名前の表にマップされます。同期化操作の実行時には、これらの要素が元の名前でXMLファイルにリストアされます。

ドライバによって作成される追加のオブジェクトは、XMLファイルの整合性を保つために使用されます。XMLファイルと同期化させるには、これらのレコードをリレーショナル・スキーマにロードする必要があります。

B.2.2 XML名前空間

XMLドライバでは、XMLの属性および要素に対して指定されるXML名前空間(xmlns:)がサポートされています。

構文<namespace>:<element or attribute name>を使用して名前空間とともに指定された要素または属性は、構文<namespace>_<element or attribute name>を使用して、名前空間を接頭辞とする表または列としてマップされます。XMLデータを元のファイルに同期化する際には、名前空間の情報が自動的に生成されます。

注意:
v3モードでは、表名に接頭辞の<namespace>_が付きません。

B.2.3 スキーマの管理

スキーマは、一連のリレーショナル表を保持するコンテナであり、Oracleデータベースおよび他のRDBMシステムで使用される概念に対応します。各スキーマは、一連のXMLファイル・インスタンス全体を正常に解析して抽出できる、1つの汎用リレーショナル構造です。識別された要素および属性は、適切なリレーショナル表およびフィールドに挿入されます。

このスキーマは、XMLドライバによって、XMLインスタンス・ファイル、DTDファイルまたはXSDファイルから生成されます。DTDまたはXSDファイルからスキーマを生成することをお薦めします。

XMLデータ・サーバーURLの定義で参照できるのは、単一のDTDまたはXSDファイルのみです。そのため、アーティファクトに他のDTDまたはXSDファイルへの参照が含まれる場合は、このDTDまたはXSDがマスターDTDまたはXSDファイルとみなされます。状況によっては、複数のスキーマが必要になる可能性があります。その場合は、add_schema_bundleプロパティを使用してください。

B.2.3.1 スキーマの格納

スキーマは、組込みエンジンまたは外部データベースに格納できます。

- 組込みエンジンの場合、その他のコンポーネントを実行する必要はありません。XMLスキーマはドライバ内のメモリーに格納されます。このドライバで使用できるSQLコマンドおよびファンクションの詳細は、「SQL構文」を参照してください。

- 外部データベースとして、リレーショナル・データベース管理システムを使用できます。ドライバは、JDBCを介してこのエンジンに接続し、スキーマの格納に使用します。これによって、次のことが可能になります。

- RDBMSエンジンの処理および格納能力の利用

- RDBMSの文およびファンクションの利用

- スキーマの格納の持続

詳細は、B.3.3項「外部データベースを使用したデータの格納」を参照してください。

B.2.3.2 複数のスキーマ

同じJDBC接続で、複数のスキーマを処理して複数のXMLファイルに同時にロードできます。スキーマのCREATE、TRUNCATE、SETおよびLOAD FILE INTO操作を実行できます。JDBCドライバに接続すると、URLで指定されたスキーマに接続します。SET SCHEMAコマンドを使用すると、現在のスキーマを別のスキーマに設定できます。詳細は、B.4項「ドライバ・コマンドの詳細」を参照してください。

デフォルト・スキーマは、一時データの格納に使用される特定のスキーマです。デフォルト・スキーマは読取り専用で、XMLファイルの格納には使用できません。各XMLファイルに対して1つのスキーマを作成することをお薦めします。

ドライバへの接続の作成時に、XML構造が異なる追加のスキーマを自動的に作成することもできます。詳細は、B.3.1項「ドライバの構成」を参照してください。

B.2.3.3 スキーマ内のデータへのアクセス

スキーマ内のデータはSQL言語を使用して処理されます。

現在のスキーマとは別のスキーマ内の表にアクセスできます。別のスキーマの表にアクセスするには、表名の先頭にスキーマ名およびピリオド(.)を付けます。次に例を示します。

SELECT col1, schema2.table2.col2, table1.col3 FROM table1, schema2.table2.

この問合せでは、現在のスキーマのtable1、およびschema2のtable2からデータが戻されます。

注意:
他方のスキーマも現在のスキーマと同じ記憶領域(組込みエンジンまたは外部データベース)に格納されている必要があります。

B.2.3.4 大/小文字の区別

スキーマでは大/小文字を区別できません。スキーマ内の要素(表および列)は、すべて大文字で表記されます。XMLファイルの要素名に小文字が含まれている場合、これらの文字は大文字に変換されます。要素がXMLファイルに同期化される際には、これらの名前が元の大/小文字を使用して作成されます。

B.2.3.5 ロード/同期化

通常、スキーマはXMLファイルへの接続時に自動的に作成され、XMLファイルに含まれているデータとともにロードされます。特定のドライバ・コマンドを使用して、スキーマの作成およびスキーマ内のデータ・ロードを強制的に実行できます。詳細は、B.4項「ドライバ・コマンドの詳細」を参照してください。データの同期化プロセスも、SYNCHRONIZEコマンドを使用して強制的に実行できます。詳細は、B.4.9項「SYNCHRONIZE」を参照してください。

B.2.4 ロック

ドライバは、XMLファイルにアクセスする際にファイルをロックして、他のドライバ・インスタンスがそのファイルに接続するのを防ぎます。ロック・ファイルの名前はXMLファイルと同じですが、拡張子.lckが使用されます。

ドライバが不正に切断された場合、ファイルがロックされたままになることがあります。このロックを削除するには、.lckファイルを削除します。UNLOCK FILEコマンドを使用して、XMLファイルのロックを解除することもできます。

B.2.5 XMLスキーマ(XSD)のサポート

XMLドライバでは、XMLファイルの構造を記述するためにXSDがサポートされています。詳細は、B.8項「サポートされているXMLスキーマの機能」を参照してください。

また、XMLドライバでは、XMLファイル内で指定されたXSDスキーマに対するドキュメントの検証もサポートされています。この操作は、ドライバ固有のVALIDATEコマンドでも実行できます。

B.3 インストールおよび構成

Oracle Data Integrator driver for XMLは、Oracle Data Integratorとともに自動的にインストールされます。次の各項では、拡張構成の説明および参照情報を示します。

この項には次のトピックが含まれます:

- ドライバの構成

- 複数のスキーマの自動作成

- 外部データベースを使用したデータの格納

注意:
外部データベース記憶域を使用する場合は、さらに、外部データベースへの接続に使用するJDBCドライバおよび.propertiesファイルをクラスパスに含めておく必要があります。

B.3.1 ドライバの構成

この項ではドライバの構成について説明します。

- ドライバ名: com.sunopsis.jdbc.driver.xml.SnpsXmlDriver

- URL構文: jdbc:snps:xml?f=<filename>[&s=<schema>&<property>=<value>...]

URLのプロパティの詳細を表B-1に示します。

表B-1 ドライバのプロパティ

プロパティ

必須

種類

デフォルト

説明

blank_attribute_as_columnまたはbaac

いいえ

ブール値(true | false)

false

このオプションをtrueに設定した場合、自身の子要素を持たないXMLファイルの空の要素は、表ではなく列とみなされます。

fileまたはf

はい

文字列(ファイルの場所)

-

XMLファイル名。パス名には、バックスラッシュ"\"ではなくスラッシュ"/"を使用します。HTTP、FTPまたはファイルのURLを使用してファイルの場所を示すことができます。URLによって示されたファイルは読取り専用です。

XMLファイルの場合、このプロパティが欠落していると、XMLドライバによってリレーショナル・スキーマがDTD/XSDファイルに基づいて作成され、XMLファイルの検索は行われません。

dtdまたはd

いいえ

文字列(ファイルの場所)

-

記述ファイル。このファイルはDTDまたはXSDファイルです。HTTP、FTPまたはファイルのURLを使用してファイルの場所を示すことができます。URLによって示されたファイルは読取り専用です。

URLで指定されているDTDまたはXSDファイルは、XMLファイル内で指定されているDTDまたはXSDファイルより優先されます。参照は、絶対パスを使用して作成する必要があります。

XMLファイルに関してこのプロパティが欠落しており、XMLファイル内でもDTDまたはXSDが参照されていない場合、ドライバでは、XMLファイルに似た名前に拡張子.dtdの付いたものがDTDファイル名であると自動的にみなされます。

generate_dtd URLプロパティの設定によっては、DTDファイルがXMLファイル構造に基づいて作成される場合があります。

DTDまたはXSDファイルが存在しない場合、リレーショナル構造はXMLファイルの内容のみを使用して構築されます。DTDまたはXSDに記述されている使用可能な要素が1つのXMLファイル・インスタンスにすべて含まれていないことで、データ・モデルが不完全になる可能性があるため、このような構造からデータ・モデルをリバース・エンジニアリングすることはお薦めしません。

root_eltまたはre

いいえ

文字列

-

スキーマのルート表として選択する要素の名前。この値では大/小文字が区別されます。このプロパティは、WSDLファイルから特定のメッセージ定義をリバース・エンジニアリングする場合や、使用可能なルート要素がXSDファイル内に複数存在する場合などに使用できます。

重要: このプロパティは、XMLインスタンス・ファイルのルート要素のルート要素定義として機能する、XSDまたはDTDファイルの要素の指定のみに使用されます。

read_onlyまたはro

いいえ

ブール値(true | false)

false

XMLファイルを読取り専用モードで開きます。

schemaまたはs

いいえ

文字列

-

XMLファイルのロード先となるスキーマの名前。このプロパティが欠落している場合は、XMLファイル名に基づいて、スキーマ名が自動的に生成されます。

XMLデータ・サーバーのURLでこのプロパティが指定されていない場合は、XMLドライバによってスキーマ名が自動的に作成されます。このスキーマの名前として、XMLファイル名の最初の5文字が使用されます。

注意: スキーマへの接続を複数作成することはできません。すでに使用中のスキーマに接続しようとした場合、後続の接続は失敗します。

重要: スキーマ名は大文字で指定する必要があります。

重要: XML要素名と同じスキーマ名を使用することは禁止されています。

standaloneまたはst

いいえ

ブール値(true | false)

false

このオプションをtrueに設定すると、この接続のスキーマは、他のすべてのスキーマから完全に分離されます。このオプションでは、各スキーマを分離したまま複数の接続に対して同じスキーマ名を指定できます。このオプションを使用すると、このスキーマの表に他のスキーマからアクセスできません。また、この接続で他のスキーマの表にもアクセスできません。スキーマは、この接続のみに制限されます。他の接続はこのスキーマを参照できません。このオプションはインメモリーHSQL中間データベースに対してのみアクティブです。このオプションを使用すると、すべてのステージング・スキーマで、インメモリーに完全に新しいHSQLインスタンスが作成されるため、エージェントによるメモリー消費量が増大します。ジョブが相互にオーバーラップすることを避けるために、同じトポロジを備えたパラレル・ジョブに対して使用する場合は便利です。注意: 外部データベースを使用する場合、このオプションは適用されません。データ・サーバーの「スタンドアロン」プロパティがtrueに設定されている場合は、データを格納するためのターゲット・データストアとして使用したり、データを書き出したりすることができません。その理由は、「スタンドアロン」インスタンスが完全に分離されるためです。

注意: 「スタンドアロン」プロパティは、次の場合に使用できます。

- f=パラメータがJDBC接続URLまたはプロパティに存在しない

- LOAD FILEコマンドを使用して、同じファイルを並行してロードしようとしていない
その理由は、ソース・ファイルの読取り前に、ソース・ファイル上のすべての操作が完了するまで、ドライバによってソース・ファイルがロックされるためです。したがって、パラレル・セッションがある場合は、最初のセッションが完了するまで、最初のセッションによってファイルがロックされます。

注意: f=パラメータが存在する場合、接続を開くと即座に、ドライバによってファイルがロックされ、f=パラメータが読み取られます。ファイルへのすべての接続が閉じられたときにのみ、ファイルがロック解除されます。明示的なUNLOCKコマンドはありませんが、操作の目的を明確にしてから、注意してこのコマンドを使用してください。

ns_prefix_generationまたはnspg

いいえ

auto | xml | xsd

auto

このオプションは、名前空間接頭辞の生成方法およびXMLファイルへの書込み方法を定義します。

- auto(デフォルト): 接頭辞は、可能な場合は名前空間名自体から自動的に生成され、それ以外の場合はns1、ns2のように生成されます。

- xml: 名前空間接頭辞は、ソースXMLファイルから取得されます(存在する場合)。

- xsd: 名前空間接頭辞は、XSDファイルから取得されます(存在する場合)。

xsdオプション値は、複数のXSDファイルで異なる名前空間を参照するために、類似した接頭辞が使用されていないことを前提としています。

no_default_nsまたはndns

いいえ

ブール値(true | false)

false

このプロパティをtrueに設定すると、デフォルトの名前空間エントリがないターゲット・ファイルが生成されます。

no_closing_tagsまたはnct

いいえ

ブール値(true | false)

false

このプロパティをtrueに設定すると、終了タグのない空のタグが生成されます(例: <element/>)。falseに設定すると、空の要素が<element></element>のように生成されます。v1_compatibilityプロパティを使用している場合、このプロパティはデフォルトでtrueになります。

db_propsまたはdp

いいえ

文字列

-

このプロパティは、メモリー・エンジンのかわりに外部データベースを使用してスキーマを格納するために使用します。

db_propsプロパティは、db_propsプロパティと似た名前で拡張子が.propertiesの外部データベース・プロパティ・ファイルに接続情報が格納されているデータベース・スキーマに、スキーマをロードする必要があることを示します。このプロパティ・ファイルは、アプリケーションのクラスパスに配置する必要があります。

load_data_on_connectまたはldoc

いいえ

ブール値(true | false)

true

JDBC接続の実行時に、スキーマにデータを自動的にロードします。falseに設定した場合は、接続後にSYNCHRONIZE文を使用してデータをロードする必要があります。

このオプションは、すべてのデータをロードせずに接続をテストしたりメタデータを参照するのに役立ちます。

drop_on_discまたはdod

いいえ

ブール値(true | false)

false

JDBC接続を閉じる際に、スキーマを自動的にドロップします。

trueの場合、スキーマは組込みエンジンに格納され、常にドロップされます。

trueで、かつ、データが外部データベースにある場合、メモリー内のスキーマへの現在の参照のみがドロップされ、表は外部データベースに残ります。このことは、このスキーマに再度接続しようとすると、(データがメモリーにロードされるときのように)最初から開始するのではなく、外部データベース内の表が再利用されることを意味します。

ignore_unknown_elementsまたはiue

いいえ

ブール値(true | false)

false

関連付けられているDTD (Document Type Definition)またはXSD (XMLスキーマ定義)ファイルには存在しないXMLファイルの要素をすべて無視します。

useimplicitmaxvalue

いいえ

ブール値(true | false)

false

このプロパティをtrueに設定した場合、XSDでmaxOccursが指定されていない要素は、maxOccurs ="unbounded"とみなされます。それ以外の場合、maxOccursが指定されていない要素はmaxOccurs=1とみなされます。

generate_dtdまたはgd

いいえ

yes | no | auto

auto

XMLファイルの構造に基づいてDTDファイルを作成する必要があるかどうかを定義します。

- auto: DTDファイルが存在しない場合はこれを作成し、存在する場合は何も実行しません。

- yes: 常にDTDファイルを作成します。既存のDTDファイルは上書きされます。

- no: 状況にかかわらずDTDファイルを作成しません。DTDファイルが存在する必要があります。

警告: このオプションを使用して作成されたDTDファイルには、XMLファイルに出現するXML要素の定義のみが含まれるため、完全でない可能性があります。

java_encodingまたはje

いいえ

文字列(エンコーディング・コード)

UTF8

ターゲット・ファイルのエンコーディング(例: ISO8859_1)。サポートされているエンコーディングのリストは、次のURLにあります。http://download.oracle.com/javase/6/docs/technotes/guides/intl/encoding.doc.html。

Javaエンコーディングを指定する場合は、XMLエンコーディングも指定する必要があります。

useimplicitmaxvalueまたはuimv

いいえ

ブール値(true | false)

false

このプロパティをyesに設定した場合、XSDでmaxOccursが指定されていない要素は、複数値(maxOccurs ="unbounded")とみなされます。

xml_encodingまたはxe

いいえ

文字列(エンコーディング・コード)

UTF8

生成されたXMLファイル内に、ISO-8859-1: <?xml version="1.0" encoding="ISO-8859-1"?>などのタグで指定されるエンコーディング。サポートされているエンコーディングのリストは、次のURLにあります。http://download.oracle.com/javase/6/docs/technotes/guides/intl/encoding.doc.html。

XMLエンコーディングを指定する場合は、Javaエンコーディングも指定する必要があります。

v1_compatibilityまたはv1

いいえ

ブール値(true | false)

false

このプロパティをtrueに設定すると、XMLからSQLへのマッピングがバージョン1.xのように実行されます。このプロパティは互換性のために提供されています。

compat_mode

いいえ

文字列

v3

マッピング・モードとの互換性を示します。このプロパティに指定できる値は次のとおりです。

- v1は、1.x互換性モードのv1_compatibility=trueに対応します。

- v2は、カスタム記述されたXSDパーサーを使用する10g/11g互換性モードを示します。
DTDを使用する場合やXMLファイルのみを使用する場合は、JDBC URLでcompat_mode=v2を指定する必要があります。次に例を示します。

jdbc:snps:xml?file=/tmp/myfile.xml&compat_mode=v2

jdbc:snps:xml?f=/tmp/myfile.xml&compat_mode=v2

- v3は、XDK XSDパーサーとの互換性を示します。
DTDを使用する場合やXMLファイルのみを使用する場合、compat_mode=v3はサポートされていません。たとえば、次の構文はサポートされていません。

jdbc:snps:xml?file=/tmp/myfile.xml&compat_mode=v3

jdbc:snps:xml?f=/tmp/myfile.xml&compat_mode=v3

compat_mode=v3の場合、v1_compatibilityプロパティは無視されます。

numeric_idsまたはni

いいえ

ブール値(true | false)

true

trueに設定すると、すべての内部の主キーおよび外部キーがNUMERIC型になります。それ以外の場合はVARCHAR型になります。

id_lengthまたはil

いいえ

整数

10 / 30

内部の主キーおよび外部キーの列の長さ。デフォルトは、列型がNUMERICの場合は10、VARCHARの場合は30です。

no_batch_updateまたはnobu

いいえ

ブール値(true | false)

false

この接続にはバッチ更新は使用されません。バッチ更新を設定するコマンドは送信されません。これにより、このJDBC機能をサポートしていない外部データベースに関するエラーの発生を回避し、バッチ更新の使用に関するエラーをデバッグできます。

add_schema_bundleまたはasb

いいえ

文字列

-

追加のスキーマ・バンドル・ファイル。このプロパティは、接続時に追加のスキーマを作成する必要があることを示します。これらの追加のスキーマに関する記述は、add_schema_bundleプロパティに拡張子.propertiesが付いた名前の追加のスキーマ・プロパティ・ファイルに含まれます。追加のスキーマ・プロパティ・ファイルには、有効なJDBCドライバのURLのリストが含まれます。このファイルでは、プロパティ名は無視されます。値のリストのみが考慮されます。

これらの追加のスキーマはすべて、drop_on_disconnectオプションがデフォルトでtrueに設定された状態で作成されます。

追加のスキーマ・プロパティ・ファイルの内容は、たとえば次のようになります。

addschema_1=jdbc:snps:xml?f=c:/myfile.xml&ro=true&s=myschema1 addschema_2=jdbc:snps:xml?file=c:/myfile2.xml&s=myschema2 addschema_3=jdbc:snps:xml?d=c:/myfile3.dtd&s=myschema3

add_schema_pathまたはasp

いいえ

文字列(ディレクトリ)

-

一連のXSDファイルを含むディレクトリ。このディレクトリの各XSDファイルに対し、そのXSDに基づいて組込みエンジンまたは外部データベース記憶域に追加のスキーマが作成されます。これらの追加のスキーマに対するオブジェクトは、外部データベース記憶域には作成されません。スキーマ名は、生成されるデフォルト名です(ファイル名の最初の5文字を大文字で表記)。

注意: このオプションはv3モードではサポートされていません。

transform_nonasciiまたはtna

いいえ

ブール値(true|false)

true

非ASCIIを変換します。非ASCII文字を保持するにはfalseに設定します。

max_table_name_lengthまたはmtnl

いいえ

整数

-

表名の最大長(内部/外部DBでサポートされている値に無関係)。

max_column_name_lengthまたはmcnl

いいえ

整数

-

列名の最大長(内部/外部DBでサポートされている値に無関係)。

case_sensまたはcs

いいえ

ブール値(true | false)

true

表名および列名で大文字と小文字が区別されるかどうかを示します。名前比較はこれに基づいて実行されます。

表B-2にURLのサンプルを示します。

B-2 URLのサンプル

URLのサンプル

アクション

jdbc:snps:xml

デフォルトのスキーマに接続します。

jdbc:snps:xml?f=/tmp/myfile.xml&ro=true&d=/tmp/mydtd.dtd

/tmp/mydtd.dtd DTDを使用して、/tmp/myfile.xmlファイルを読取り専用モードで開きます。

jdbc:snps:xml?file=/tmp/myfile.xml

/tmp/myfile.xmlファイルを読取り/書込みモードで開きます。

jdbc:snps:xml?s=myschema

スキーマmyschemaに直接接続します。

B.3.2 複数のスキーマの自動作成

ドライバへの接続の作成時に、XML構造が異なる追加のスキーマを自動的に作成できます。これは、次の方法で実行します。

- add_schema_bundle URLプロパティで、作成する別の追加スキーマに対応するJDBC URLのリストが含まれているプロパティ・ファイルを宣言します。

- add_schema_path URLプロパティで、一連のXSDファイルが含まれているディレクトリを宣言します。各XSDファイルに対して、XMLスキーマの記述に基づいて追加のスキーマが組込みエンジン内に作成されます。

- 追加の有効なドライバURLをaddschema_X (Xは数字)という名前のJDBCプロパティとして指定します。addschema_XというJDBCプロパティで検出されたURLごとに、追加のスキーマが作成されます。

これらのすべての追加スキーマは、最後の接続が閉じられると自動的にドロップされます。

B.3.3 外部データベースを使用したデータの格納

ほとんどの場合、XMLドライバでは、XMLスキーマのリレーショナル・スキーマ・マッピングを組込みエンジンに格納します。リレーショナル・スキーマを外部リレーショナル・データベースに格納することもできます。

次の場合は、外部記憶域を使用します。

- XMLドライバによって導出されたリレーショナル・スキーマに、XMLドライバを使用して、大規模XMLファイルをロードする場合

- XMLドライバの組込みエンジンによるファイルの処理に要する時間全体を短縮する場合

- ODIリポジトリへのタイムアウトを防ぐため。XMLファイルの処理に要する時間は、次の点により異なります。

- XMLファイル構造の複雑さ

- XMLファイルの内容の長さ

- ホスト・サーバーのRAMリソース

- ホスト・サーバーのCPUリソース

外部記憶域を使用する前に、外部記憶域の使用による影響を理解していること、およびODIのタイムアウトを、パフォーマンスの要件を満たす値に増加したことを確認してください。

注意:
外部記憶域用にサポートされるRDBMSには、Oracle、Microsoft SQL Server、MySQLおよびHypersonic SQL 2.0などがあります。外部記憶域がサポートされるテクノロジの完全なリストには、次のOracle Technical Network (OTN)からアクセスできます。
http://www.oracle.com/technology/products/oracle-data-integrator/index.html

これらのスキーマは、JDBCドライバのURLで指定されているプロパティを使用して作成されるスキーマに加えて作成されます。

外部記憶域は、表B-3に示す一連のプロパティで構成されます。これらのプロパティは、次の複数の方法で渡すことができます。

- ドライバURLでのプロパティの受渡し

- ODI Studioでのプロパティの設定

- プロパティ・ファイルでのプロパティの設定

ドライバURLでのプロパティの受渡し

ドライバURLでプロパティを直接設定できます。この方法を使用する場合は、プロパティに接頭辞としてdp_を付ける必要があります。たとえば、Oracleデータベースに接続する場合は、driverパラメータでOracle JDBCドライバ名を次のように指定します。

dp_driver=oracle.jdbc.OracleDriver.

ODI Studioでのプロパティの設定

プロパティは、トポロジ・ナビゲータのデータ・サーバー・エディタの「プロパティ」タブで指定できます。この方法を使用する場合は、プロパティに接頭辞としてdp_を付ける必要があります。たとえば、driverパラメータを設定するとします。

1. 「キー」列にdp_driverと入力します。

2. Oracleデータベースに接続している場合は、「値」列にoracle.jdbc.OracleDriverと入力します。

プロパティ・ファイルでのプロパティの設定

外部データベース・プロパティ・ファイルでプロパティを設定できます。プロパティ・バンドルとも呼ばれるこのプロパティ・ファイルは、.properties拡張子を持つテキスト・ファイルであり、ここに含まれる一連の行には、それぞれ、<property>=<value>のペアがあります。この外部データベース・プロパティ・ファイルには、リレーショナル・データベース・スキーマへのJDBC接続のプロパティが含まれています。このプロパティ・ファイルは、JDBC URLのdb_propsプロパティを使用して参照されます。この方法を使用する場合は、次のことに注意してください。

- プロパティ・ファイルのプロパティには接頭辞は付けず、表B-3に示すように使用します。

- db_propsプロパティは.properties拡張子を含むプロパティ・ファイルの名前に設定します。db_propsプロパティは、外部データベース・プロパティ・ファイルに接続情報が格納されているデータベース・スキーマに、スキーマをロードする必要があることを示します。

- プロパティ・ファイルはXML接続を使用してエージェントによってデプロイする必要があります。プロパティ・ファイルの場所は、使用するエージェントによって異なります。

- ローカル・エージェント(Studio): 外部DBプロパティ・ファイルを<user.dir>/odi/oracledi/userlibフォルダに配置します。

- スタンドアロン・エージェント: 外部DBプロパティ・ファイルをdomain_home/libフォルダに配置します。

- JavaEEエージェント: 外部DBプロパティ・ファイルをJARまたはZIPファイルに圧縮し、Java EEエージェントによって生成されたテンプレートに追加する必要があります。詳細は、『Oracle Data Integratorの管理』のJava EEアプリケーション・サーバー(Oracle WebLogic Server)でのエージェントのデプロイに関する項を参照してください。

- プロパティ・ファイルをXMLドライバを使用するOracle Data Integratorのクラスパスに設定する必要があります。通常、このファイルはカスタム・ドライバでインストールできます。

注意:
XMLドライバでは、外部データベースへの接続時にJDBC接続が使用されます。この外部データベースにアクセスするためのJDBCドライバも、必ずODIクラスパスに配置してください。

外部データベースのプロパティをURLで設定またはオーバーライドできます。これらのプロパティには、接頭辞として文字列dp_を付ける必要があります。次に例を示します。

jdbc:snps:xml?file=/temp/payload.xml&dp_driver=<external_db_driver>&dp_url=<external_db_url>

外部記憶域を構成するためのプロパティを、表B-3に示します。

表B-3 外部データベース・プロパティ・ファイルのプロパティ

プロパティ

必須

種類

デフォルト

説明

driver

はい

文字列

-

JDBCドライバ名。

重要: ドライバ・クラス・ファイルをjavaアプリケーションのクラスパスに配置する必要があります。

url

はい

文字列

-

JDBC URL。

user

はい

文字列

-

データベースへの接続に使用するログイン。

password

はい

文字列

-

暗号化されたユーザー・パスワード。

注意: パスワードを暗号化するには、encode.batコマンドを使用します。詳細は、Oracle Data Integratorのインストールと構成を参照してください。

schema

はい

文字列

-

リレーショナル・スキーマおよびXMLデータを格納するデータベース・スキーマ。

MS SQLServerについて、次のことに注意してください。

- スキーマが指定されていない場合、表はユーザーのデフォルト・スキーマの下に作成されます

- スキーマが指定されている場合、表はそのスキーマの下に作成されます

v3モード使用時の制限: 外部データベースの使用時は、提供されたスキーマ名か、計算されたスキーマ名が存在することを確認してください。schemaドライバ・プロパティの値は、外部データベースのschemaプロパティ値と一致する必要があります。そうでない場合は、エラーが発生します。

catalog

はい

文字列

-

Microsoft SQL Server専用です。XMLのデータおよび情報を格納するデータベース・カタログです。

drop_on_connectまたはdoc

いいえ

文字列(Y|N)

N

すでに存在する場合、データベース・スキーマから表をドロップします。Nに設定すると、既存の表が保持されます。

create_tablesまたはct

いいえ

(Y | N | AUTO)

AUTO

Y: 一貫してスキーマに表を作成します。

N: 状況にかかわらずスキーマに表を作成しません

AUTO: 表が存在しない場合は、表を作成します。

create_indexesまたはci

いいえ

文字列(Y|N)

Y

Y: 表のPKおよびFKに索引を作成します。

N: 索引を作成しません。この値によって、INSERTは速くなりますが、データのSELECTは大幅に遅くなります。RDBの記憶域も節約されます。

numeric_scaleまたはns

いいえ

整数

空

XMLからSQLへのマッピング時に生成される数値列のスケール。

truncate_before_loadまたはtbl

いいえ

文字列(Y|N)

Y

Y: 接続時にすべてのデータを切り捨てます。

N: 既存のデータを保持します。

ids_in_dbまたはiidb

いいえ

文字列(Y|N)

Y

Y: 将来接続を追加するために、データベース内の識別子(カウンタ)を保持します。

N: 識別子を保持しません。以後、追加することはできません。

drop_tables_on_drop_schemaまたはdtods

いいえ

文字列(Y|N)

Y

Y: DROP SCHEMAによって、データベース・スキーマへの参照がドライバから消去され、さらに、すべての表がドロップされます。

N: DROP SCHEMAによって、データベース・スキーマへの参照がドライバから消去されますが、表はデータベース・スキーマ内に保持されます。

use_prepared_statementsまたはups

いいえ

文字列(Y|N)

Y

Y: データベース接続でプリペアド文を使用して、ドライバ操作(ファイルのロード/アンロード)が実行されます。

N: プリペアド文を使用しません。

通常、プリペアド文を使用した方が処理は速くなります。このオプションを使用するには、データベースおよびドライバで、プリペアド文がサポートされている必要があります。

use_batch_updateまたはubu

いいえ

文字列(Y|N)

Y

Y: データベース接続でバッチ更新を使用します。

N: バッチ更新を使用しません。

通常、データの挿入はバッチ更新を使用した方が速くなります。次の条件が満たされている場合にのみtrueに設定してください。

- データベースおよびドライバがバッチ更新をサポートしている

- データベースがプリペアド文をサポートしている

- use_prepared_statementsパラメータがYesに設定されている

注意: ここで指定したバッチ更新オプションは、スキーマ内のデータのロードのみに使用されます。スキーマ内のデータの操作にバッチ更新を使用するには、使用するJavaアプリケーションでバッチ更新オプションを指定する必要があります。

batch_update_sizeまたはbus

いいえ

整数

30

バッチ更新のサイズ。use_batch_updateプロパティがtrueに設定されている場合は、このサイズのバッチ単位でレコードがデータベース・スキーマに書き込まれます。

commit_periodicallyまたはcp

いいえ

文字列(Y|N)

Y

XMLファイルからデータベース・スキーマへデータをロードする際に、定期的にCOMMITが送信されます。定期的にCOMMITを送信することで、大きいXMLデータ・ファイルをロードする際のデータベース・ログの過負荷を防ぎます。

次の条件が満たされている場合にのみtrueに設定してください。

- データベースがバッチ更新をサポートしている

- データベースがプリペアド文をサポートしている

- use_prepared_statementsパラメータがYesに設定されている

- use_batch_updatesパラメータがYesに設定されている

注意: ここで指定したコミット・オプションは、スキーマ内のデータのロードのみに使用されます。スキーマでトランザクションを実行する際にコミットするには、使用するJavaアプリケーションでコミットを指定する必要があります。

num_inserts_before_commitまたはnibc

いいえ

整数

1000

commit_periodicallyプロパティがtrueに設定されている場合のCOMMITの間隔(レコード数)。

reserve_chars_for_columnまたはrcfc

いいえ

整数

3

長いXML名は、JDBCドライバによって戻される列名の最大許容サイズに従って、RDBMSの最大許容サイズにあうように切り捨てられます。

ただし、状況によっては、より少ない文字数を使用して、ドライバで生成される名前を短くする必要があります。減らす文字の数は、reserve_chars_for_column値で定義されます。

たとえば、最大30文字のデータベースでこのプロパティを3(デフォルト)に設定すると、すべての列名が27文字以下になります。

reserve_chars_for_tableまたはrcft

いいえ

整数

3

reserve_chars_for_column (rcfc)と同じですが、RDBMSスキーマに作成された表の名前に適用されます。

varchar_lengthまたはvl

いいえ

整数

255

文字列データの格納に使用されるリレーショナル構造のすべての列のサイズ。

このプロパティは、注釈要素やドキュメント要素には適用されません。これらの要素には、かわりにdlvcを使用する必要があります。

default_type_varcharまたはdtvc

いいえ

文字列(Y|N)

N

Yesに設定すると、XML注釈要素およびドキュメント要素を格納する列のリレーショナル・スキーマで使用されるデフォルトのデータ型は、サイズ255のVARCHARとなります。この列の長さはdlvcプロパティを使用して指定します。falseに設定すると、LONGデータ型となります(使用されている場合)。Oracleなどの、同じ表内で複数のLONG列がサポートされていないテクノロジでは、このプロパティをyesに設定する必要があります。

default_length_varcharまたは

dlvc

いいえ

整数

255

XMLアノテーションおよびドキュメント要素の格納に使用されるVARCHAR列のデフォルトの長さ。このプロパティは、dtvcがyesに設定されている場合にのみ有効となります。

次に例を示します。

default_length_varchar=2000 2000は、必要な新しいデフォルトの列サイズです。

numeric_lengthまたはnl

いいえ

整数

10

数値データの格納に使用されるリレーショナル構造のすべての列のサイズ。

unicode

いいえ

ブール値(true | false)

MS SQL Serverの場合:

unicode = trueの場合はNVARCHARが使用されます。

unicode = falseまたは未設定の場合は、VARCHARが使用されます。

multi_user_safeまたはmus

いいえ

ブール値(true | false)

false

これを使用して、行IDの生成方法を制御します。multi_user_safeをtrueに設定した場合、各ID生成のタスクはDBに割り当てられます。falseに設定した場合、データ・ロードの開始時に、ID表に格納されているIDが取得され、格納されたそのデータがメモリー内に移されます。これは、データ・ロードの終了時にDBにプッシュされます。

次のサンプルは、Oracle Databaseを外部記憶域として使用した場合のプロパティ・ファイルの例です。

driver=oracle.jdbc.OracleDriver
url=jdbc:oracle:thin:@HOST:PORT:SID
user=USER_NAME
password=ENCODED_PASSWORD
schema=USER_NAME
drop_on_connect=Y
create_tables=AUTO
create_indexes=Y
truncate_before_load=Y
ids_in_db=Y
drop_tables_on_drop_schema=Y
use_prepared_statements=Y
use_batch_update=Y
batch_update_size=30
commit_periodically=Y
num_inserts_before_commit=1000
reserve_chars_for_column=3
reserve_chars_for_table=3

次のサンプルは、Microsoft SQL Serverデータベースを外部記憶域として使用した場合のプロパティ・ファイルの例です。

driver=com.microsoft.jdbc.sqlserver.SQLServerDriver
url=jdbc:microsoft:sqlserver://SERVER_NAME:PORT;SelectMethod=cursor
user=USER_NAME
password=ENCODED_PASSWORD
schema=OWNNER_NAME
drop_on_connect=Y
create_tables=AUTO
create_indexes=Y
truncate_before_load=Y
ids_in_db=Y
drop_tables_on_drop_schema=Y
use_prepared_statements=Y
use_batch_update=Y
batch_update_size=30
commit_periodically=Y
num_inserts_before_commit=1000
reserve_chars_for_column=3
reserve_chars_for_table=3

B.4 ドライバ・コマンドの詳細

注意:
これらのコマンド内のSCHEMAという語は、物理アーキテクチャに存在するXMLドライバ・データ・サーバーURLでs=....を使用して設定されている文字列値を表します。

この項に示す文はXMLドライバ固有のものであり、XMLファイルおよびスキーマの管理を可能にします。これらの文は、XMLドライバへのJDBC接続で、標準のSQL文として起動できます。

スキーマに格納されているデータを操作するには、標準のSQL構文を使用できます。この構文は、組込みエンジンのSQL構文、または使用する外部データベース・エンジンのSQL構文です。

表記規則

このマニュアルでは次の表記規則を使用します。

- [ A ]は、Aがオプションであることを意味します。

- [ A | B ]は、AまたはBだがパラメータがオプションであることを意味します。

- { B | C }は、BまたはCを使用する必要があることを意味します。

- [A] [B]は、順序付けされていない一連の引数を意味します。

- ( および )は、記号「(」および「)」を意味します。

- キーワードは大文字です。

この項では、次のドライバ固有のコマンドについて説明します。

- CREATE FILE

- CREATE FOREIGNKEYS

- CREATE XMLFILE

- CREATE SCHEMA

- DROP FOREIGNKEYS

- DROP SCHEMA

- LOAD FILE

- SET SCHEMA

- SYNCHRONIZE

- UNLOCK FILE

- TRUNCATE SCHEMA

- VALIDATE

- WRITE MAPPING FILE

- COMMIT

- CREATE TABLE

- DELETE

- DISCONNECT

- DROP TABLE

- INSERT INTO

- ROLLBACK

- SELECT

- SET AUTOCOMMIT

- UPDATE

B.4.1 CREATE FILE

EMPTYオプションが指定されている場合、関連するXSDまたはDTDファイルに存在するすべての要素(オプションの要素を含む)が含まれる空のXMLインスタンス・ファイルを作成します。ただし、これらのファイルで宣言されているXML属性は、作成されたXMLインスタンス・ファイルでは参照されません。

これらの属性の処理方法は、compat_mode v1/v2とv3では異なります。v1/v2モードでは属性は書き出されませんが、v3モードでは属性も書き出されます。

CREATE [EMPTY] FILE <file_name> [FROM SCHEMA <schema_name>]
[JAVA_ENCODING <java_encoding>  XML_ENCODING <xml_encoding>]
[NO_CLOSING_TAGS] [NO_DEFAULT_NS]

パラメータ

FROM SCHEMA

XMLファイルへのデータの書込みに使用するスキーマを指定します。

JAVA_ENCODING

生成されるファイルのエンコーディング。

XML_ENCODING

ファイルのxmlタグで生成されるエンコーディング。

生成されるタグの例: <?xml version="1.0" encoding="ISO-8859-1"?>

JavaおよびXMLのエンコーディングは、常に一緒に指定する必要があります。

NO_CLOSING_TAGS

このパラメータを指定すると、終了タグのある空のタグが生成されます。デフォルトでは、<element></element>として空の要素が生成されます。no_closing_tagsパラメータでは、<element/>が生成されます。

NO_DEFAULT_NS

このパラメータを指定すると、デフォルトの名前空間エントリがないターゲット・ファイルが生成されます。

注意

- ファイル名にスペースが含まれる場合は、名前を二重引用符で囲んでください。

- エンコーディング値には特殊文字が含まれている可能性があるため、値を二重引用符で囲んでください。

B.4.2 CREATE FOREIGNKEYS

データベースのリレーショナル・スキーマの表を結合するすべての外部キーを物理的に作成します。このコマンドは、スキーマで整合性制約を強制するのに役立ちます。

注意:
要求されると、ドライバは、常に、リレーショナル構造マッピングに対応する仮想外部キーを戻します。データベース・レベルで強制された実際の外部キーは戻しません。

CREATE FOREIGNKEYS

注意

CREATE FOREIGNKEYSを使用すると、それ以後LOAD FILEを実行できなくなります。

B.4.3 CREATE XMLFILE

デフォルトのスキーマ・データまたは特定のスキーマから、<file_name>というXMLファイルを生成します。

CREATE XMLFILE <file_name> [FROM SCHEMA <schema_name>]
[JAVA_ENCODING <java_encoding> XML_ENCODING <xml_encoding>]
[NO_CLOSING_TAGS][NO_DEFAULT_NS]

パラメータ

FROM SCHEMA

XMLファイルへのデータの書込みに使用するスキーマを指定します。

JAVA_ENCODING

生成されるファイルのエンコーディング。

XML_ENCODING

ファイルのxmlタグで生成されるエンコーディング。生成されるタグの例: <?xml version="1.0" encoding="ISO-8859-1"?>

JavaおよびXMLのエンコーディングは、常に一緒に指定する必要があります。

NO_CLOSING_TAGS

このパラメータを指定すると、終了タグのある空のタグが生成されます。デフォルトでは、<element></element>として空の要素が生成されます。no_closing_tagsパラメータでは、<element/>が生成されます。

NO_DEFAULT_NS

このパラメータを指定すると、デフォルトの名前空間エントリがないターゲット・ファイルが生成されます。

注意

- ファイル名にスペースが含まれる場合は、名前を二重引用符で囲んでください。

- エンコーディング値には特殊文字が含まれている可能性があるため、値を二重引用符で囲んでください。

B.4.4 CREATE SCHEMA

<schema_name>に、空のスキーマ、または<dtd/xsd_name>として指定された記述ファイルの構造をマップする表のスキーマを作成します。

注意:
このコマンドは、外部データベースでは使用できません。

CREATE SCHEMA <schema_name> [WITH DTD <dtd/xsd_name>] [REPLACE]
[ROOTELT <root element>] [READONLY] [COMPAT_MODE <compatibility mode>]
[JAVA_ENCODING <java_encoding> XML_ENCODING <xml_encoding>]

パラメータ

WITH DTD

スキーマで構造が作成される記述ファイル(DTDまたはXSD)を指定します。

REPLACE

既存のスキーマ構造を新しいものに置き換える必要があるかどうかを指定します。

ROOTELT

XMLファイルのルートとみなされる記述ファイルの要素。この要素名では大/小文字が区別されます。

READONLY

ロードされるスキーマに対してデータの挿入、削除または更新を実行できません。

COMPAT_MODE

マッピング・モードとの互換性を示します。このプロパティに指定できる値は次のとおりです。

- v1は、1.x互換性モードのv1_compatibility=trueに対応します。

- v2は、10g/11gモードです。これはデフォルトのモードです。
DTDを使用する場合やXMLファイルのみを使用する場合は、JDBC URLでcompat_mode=v2を指定する必要があります。次に例を示します。

jdbc:snps:xml?d=/tmp/myDTD.dtd&compat_mode=v2

jdbc:snps:xml?f=/tmp/myfile.xml&compat_mode=v2

- v3は、XDK XSDパーサーとの互換性を示します。DTDを使用する場合やXMLファイルのみを使用する場合、compat_mode=v3はサポートされていません。たとえば、次の構文はサポートされていません。

- jdbc:snps:xml?d=/tmp/myDTD.dtd&compat_mode=v3

- jdbc:snps:xml?f=/tmp/myfile.xml&compat_mode=v3

compat_mode=v3の場合、v1_compatibilityプロパティは無視されます。

注意:
SYNCHRONIZEコマンドを使用した場合、v3オプションで作成されたDBスキーマのみがv3モードでDTD/XSDを解析します。v3モードでは、DBプロパティに対応するスキーマ名の値のすべての制限が、スキーマ名などに適用されます。

JAVA_ENCODING

スキーマから生成されるターゲットXMLファイルのエンコーディング。

注意: JavaおよびXMLのエンコーディングは、常に一緒に指定する必要があります。

XML_ENCODING

ターゲット・ファイルのXMLタグで生成されるエンコーディング。生成されるタグの例: <?xml version="1.0" encoding="ISO-8859-1"?>

注意

- XMLファイルのデータはロードされません。このコマンドはLOAD FILEと似ていますが、XMLファイルのデータはロードしません。

- XMLファイルが関連付けられていないため、スキーマは読取り専用モードで作成されます。

- 接続スキーマは、新規作成されたスキーマに自動的に切り替わりません。

- ファイル名にスペースが含まれる場合は、名前を二重引用符で囲んでください。

- エンコーディング値には特殊文字が含まれている可能性があるため、値を二重引用符で囲んでください。

B.4.5 DROP FOREIGNKEYS

データベースのリレーショナル・スキーマの表にあるすべての外部キーをドロップします。このコマンドは、スキーマのすべての整合性制約をドロップするのに役立ちます。

DROP FOREIGNKEYS

B.4.6 DROP SCHEMA

既存のスキーマをドロップします。<schema_name>が指定されていない場合は、現在のスキーマがドロップされます。スキーマへの保留状態の接続がある場合は、スキーマをドロップできません。既存の接続があるスキーマをドロップしようとすると、例外が発生します。

DROP SCHEMA [<schema_name>]

B.4.7 LOAD FILE

<file_name> XMLファイルを、指定された<schema_name> XMLスキーマにロードします。ON SCHEMAパラメータでスキーマ名が指定されていない場合、このXMLファイル名を使用してスキーマ名が生成されます。指定された名前または生成された名前のスキーマが見つかると、そのスキーマのプロパティが継承されます。指定された名前または生成された名前が実行時に存在しない場合、LOAD FILEコマンドで指定されたプロパティのみを含む新しいXML JDBC URLが作成されます。このスキーマは、現在のスキーマのプロパティのいずれも継承しません。

LOAD FILE <file_name> [WITH DTD <dtd/xsd_name> | INSERT_ONLY] [ON SCHEMA <schema_name>] [REPLACE] [READONLY] [ROOTELT <root element>] [AUTO_UNLOCK] [DB_PROPS <external database properties>]

INSERT_ONLYが存在しない場合は、次の手順に従ってください。

i) ON SCHEMAを使用して、コマンドにスキーマ識別子が提供されているかどうかを確認する

ii) 提供されていない場合は、XMLファイル名を使用して、スキーマ識別子(最初の5文字)を生成する

このスキーマがすでに存在し、コマンドにREPLACEオプションがない場合、ドライバによってエラーが返されます。このスキーマがすでに存在し、REPLACEオプションがある場合は、既存のスキーマが破棄された後、スキーマが再作成され、ファイルからスキーマにデータがロードされます。

スキーマが存在しない場合、新しいスキーマを作成し、ファイルをロードします。

INSERT_ONLYが存在する場合は、次の手順に従ってください。

i) 現在のスキーマを使用する

ii) ON SCHEMAが提供されている場合は、その名前のスキーマが存在するかどうかを確認する。存在する場合は、そのスキーマを使用します。そうでない場合は、現在のスキーマを引き続き使用します。ファイルをこのスキーマに読み込みます。

パラメータ

WITH DTD

スキーマで構造が作成される記述ファイル(DTDまたはXSD)を指定します。

INSERT_ONLY

スキーマがすでに存在する場合は、スキーマにXMLファイルのデータを追加します。新規のXMLファイルには、既存のスキーマに関する有効な記述ファイルが必要です。

ON SCHEMA

<schema_name>に強制的にファイルをロードします。現在のスキーマは、コマンドの実行後に自動的に<schema_name>に設定されないため、注意してください。

REPLACE

同じ名前の既存のスキーマ構造を、ロード中のスキーマ構造に置き換える必要があるかどうかを指定します。

READONLY

ロードされるスキーマに対してデータの挿入、削除または更新を実行できません。

ROOTELT

XMLファイルのルートとみなされる記述ファイルの要素。この要素名では大/小文字が区別されます。

AUTO_UNLOCK

AUTO_UNLOCKを指定しない場合、XMLファイルがすでに別のドライバ・インスタンスによってロックされていると、例外が発生します。このパラメータを使用すると、ファイルがロックされている場合にロックが自動的に解除されます。

DB_PROPS

<external database properties>.propertiesというプロパティ・ファイルで識別される外部データベースのファイルをロードします。

注意

- ファイル名は二重引用符で囲みます。

- スキーマが指定されていない場合、スキーマ名はファイル名に基づいて自動的に生成されます。

- 接続スキーマは、ロードされたスキーマに自動的に切り替わりません。

- XMLファイルがすでに別のスキーマで開いている場合は、例外が発生します。

B.4.8 SET SCHEMA

現在のスキーマを<schema_name>に設定します。

SET SCHEMA <schema_name>

注意

スキーマの名前を指定する必要があります。

B.4.9 SYNCHRONIZE

スキーマ内のデータをファイルのデータと同期化します。

SYNCHRONIZE [ALL | SCHEMA <schema_name>] [FROM FILE/FROM DATABASE]
[IGNORE CONFLICTS]

パラメータ

ALL

すべてのスキーマを同期化します。

SCHEMA

<schema_name>のみを同期化します。

FROM FILE

ファイルからスキーマへ、強制的にデータをロードします。スキーマでの変更はすべて消去されます。

FROM DATABASE

スキーマからファイルへ、強制的にデータをロードします。ファイルでの変更はすべて消去されます。

IGNORE CONFLICTS

FROM FILE/DATABASEが指定されていない場合は、データが変更された場所(FILEまたはDATABASE内)が自動的に判別され、未変更のデータが更新されます。FILEとDATABASEの両方が変更されている場合は、競合エラーが発生します。IGNORE CONFLICTSパラメータを使用すると、エラーは発生せず、SYNCHRONIZE ALLを実行している場合はそれ以降のスキーマが同期化されます。

注意:
スキーマが更新済としてマークされるのは、データ変更(更新、削除、挿入、ドロップ)がそのスキーマへの接続で実行された場合のみです。指示が別のスキーマへの接続から出された場合は、更新済としてマークされません。

B.4.10 UNLOCK FILE

別のドライバ・インスタンスによって<file_name>がロックされている場合に、このファイルをロック解除します。

UNLOCK FILE <file_name>

B.4.11 TRUNCATE SCHEMA

現在のスキーマまたは<schema_name>からすべてのデータを消去します。

TRUNCATE SCHEMA [<schema_name>]

B.4.12 VALIDATE

XMLファイル<file_name>が正しい形式であることを確認し、XMLスキーマ(XSD)がXMLファイルで参照される場合はこのスキーマと照合して、XMLファイル<file_name>の内容を検証します。ファイルが有効でない場合は、コマンドによって例外が戻されます。実行される検証の詳細は、次を参照してください。

http://xerces.apache.org/xerces2-j/features.html#validation.schema

VALIDATE [FILE <file_name>] [ERROR_ON_WARNING|IGNORE_ON_WARNING]
[ERROR_ON_ERROR|IGNORE_ON_ERROR]
[ERROR_ON_FATAL_ERROR|IGNORE_ON_FATAL_ERROR] [VERBOSE]

パラメータ

FILE <file_name>

検証するXMLファイルの名前。

ERROR_ON_WARNING | IGNORE_ON_WARNING

XSD検証警告(範囲外の値など)を無視するか、エラーを生成します。デフォルト値はIGNORE_ON_WARNINGです。

ERROR_ON_ERROR | IGNORE_ON_ERROR

XSD検証エラー(適合しない属性または要素など)を無視するか、エラーを生成します。デフォルト値はERROR_ON_ERRORです。

ERROR_ON_FATAL_ERROR | IGNORE_ON_FATAL_ERROR

XSD検証の致命的エラー(不正なXMLなど)を無視するか、エラーを生成します。デフォルト値はERROR_ON_FATAL_ERRORです。

VERBOSE

エラーの詳細およびエラーが発生した行の番号をJavaコンソールに表示します。デフォルトでは、コンソールには何も表示されません。

B.4.13 WRITE MAPPING FILE

要素/属性名から表/表.列名へのマッピングを要素/属性ごとに指定されたファイルに書き出します。マッピング・ファイルは、XSD/DTDファイルに作成されたリレーショナル構造を理解するために役立ちます。このコマンドは、スキーマがv3モードで作成されているときにのみ使用できます。そうでない場合は例外がスローされます。

WRITEMAPPINGFILE FILE <file-path> [FROM SCHEMA <schema-name>]
[JAVA_ENCODING <java_encoding> XML_ENCODING <xml-encoding>]

パラメータ

file_p ath

生成されるマッピング・ファイルの名前。

FROM_SCHEMA

オプションのFROM SCHEMAパラメータを指定しない場合、現在のスキーマが使用されます。

JAVA_ENCODING

ISO8859_1など、生成されたファイルのエンコーディング。サポートされているエンコーディングのリストは、次のURLにあります。http://download.oracle.com/javase/6/docs/technotes/guides/intl/encoding.doc.html。

Javaエンコーディングを指定する場合は、XMLエンコーディングも指定する必要があります。

XML_ENCODING

生成されたファイルのxmlタグのエンコーディング。

生成されるタグの例: <?xml version="1.0" encoding="ISO-8859-1"?>

サポートされているエンコーディングのリストは、次のURLにあります。http://download.oracle.com/javase/6/docs/technotes/guides/intl/encoding.doc.html。

XMLエンコーディングを指定する場合は、Javaエンコーディングも指定する必要があります。

例B-1 マッピング・ファイル

<?xml version = '1.0' encoding = 'UTF-8'?>
<personnel xmlns:x2r="http://www.oracle.com/odi/xml-mapping" x2r:tableName="PERSONNEL">
<person x2r:tableName="PERSON" id="ID" select="SELECT_">
<email x2r:tableName="EMAIL"></email>
<link x2r:tableName="LINK" manager="MANAGER" subordinates="SUBORDINATES"></link>
<name x2r:tableName="NAME">
<given x2r:columnName="GIVEN"></given>
<family x2r:columnName="FAMILY"></family>
</name>
<url x2r:tableName="URL" href="HREF"></url>
</person>
</personnel>

B.5 SQL構文

この項に示す文は、組込みエンジンを使用してXMLスキーマを格納する場合に使用できます。これらの文を使用すると、標準のSQL文を介してスキーマのデータおよびデータ構造を管理できます。

この項には次のトピックが含まれます:

- SQL文

- SQLファンクション

注意:
外部データベースを使用している場合は、この構文のかわりにデータベース・エンジンの問合せ構文を使用できます。

B.5.1 SQL文

任意の数のコマンドを組み合せることができます。セミコロン(;)を使用して各コマンドを区切っても構いません。

この項では、次のコマンドについて説明します。

- COMMIT

- CREATE TABLE

- DELETE

- DISCONNECT

- DROP TABLE

- INSERT INTO

- ROLLBACK

- SELECT

- SET AUTOCOMMIT

- UPDATE

- 式、条件および値

B.5.1.1 COMMIT

スキーマのトランザクションを終了し、変更を永続化します。

COMMIT [WORK]

B.5.1.2 CREATE TABLE

リレーショナル・スキーマに表およびその制約を作成します。

CREATE TABLE <table_name>
( <columnDefinition> [, ...] [, <constraintDefinition>...])

<columnDefinition> ::=
<column_name> <datatype> [(anything)] [[NOT] NULL] [IDENTITY] [PRIMARY KEY]

<constraintDefinition> ::=
[ CONSTRAINT <constraint_name> ]
UNIQUE ( <column_name> [,<column>...] ) |
PRIMARY KEY ( <column_name> [,<column_name>...] ) |
FOREIGN KEY ( <column_name> [,<column_name>...] )
REFERENCES <referenced_table> ( <column_name> [,<column_name>...] )

注意

- IDENTITY列は、自動的に増加する整数の列です。接続に対してIDENTITY列に最後に挿入された値は、IDENTITY()ファンクションを使用して取得できます。

- 有効なデータ型は、BIT、TINYINT、BIGINT、LONGVARBINARY、VARBINARY、BINARY、LONGVARCHAR、CHAR、NUMERIC、DECIMAL、INTEGER、SMALLINT、FLOAT、REAL、DOUBLE、VARCHAR、DATE、TIME、TIMESTAMP、OBJECTです。

B.5.1.3 DELETE

リレーショナル・スキーマの表の行を削除します。このファンクションでは標準のSQL構文が使用されます。

DELETE FROM <table_name> [ WHERE <expression> ]

B.5.1.4 DISCONNECT

この接続を閉じます。

DISCONNECT

注意

- JDBCインタフェースを使用している場合は、このコマンドをコールする必要はありません。接続が閉じる際に自動的にコールされます。

- 切断後は、この接続で他の問合せを実行することはできません。

B.5.1.5 DROP TABLE

リレーショナル・スキーマから表、データおよび索引を削除します。

DROP TABLE <table_name>

B.5.1.6 INSERT INTO

1つ以上の新しいデータ行を表に挿入します。

INSERT INTO <table_name> [ ( <column_name> [,...] ) ]
{ VALUES (<expression> [,...]) | <SELECT Statement> }

B.5.1.7 ROLLBACK

最後のCOMMITまたはROLLBACK以降に行われた変更を元に戻します。

ROLLBACK

B.5.1.8 SELECT

スキーマ内の1つ以上の表から情報を取得します。

SELECT [DISTINCT] { <select_expression> | <table_name>.* | * } [, ... ]
[  INTO <new_table> ]
FROM <table_list>
[  WHERE <expression> ]
[  GROUP BY <expression> [, ...] ]
[  ORDER BY <order_expression> [, ...] ]
[  { UNION [ALL] | {MINUS|EXCEPT} | INTERSECT } <select_statement> ]

<table_list> ::=
<table_name> [ { INNER | LEFT [OUTER] } JOIN <table_name>
ON <expression> ]  [, ...]

<select_expression> ::=
{ <expression> | COUNT(*) | {COUNT | MIN | MAX | SUM | AVG}
(<expression>) <column_alias>}

<order_expression> ::=
{ <column_number> | <column_alias> | <select_expression> } [ ASC | DESC ]

B.5.1.9 SET AUTOCOMMIT

接続の自動コミット・モードをオンまたはオフに切り替えます。オンにすると、すべての文が個別のトランザクションとしてコミットされます。オフにすると、文はCOMMITまたはROLLBACKのどちらかで終了するトランザクションにグループ化されます。新しい接続は、デフォルトで自動コミット・モードになります。

SET AUTOCOMMIT { TRUE | FALSE }

B.5.1.10 UPDATE

データベース内の表のデータを変更します。

UPDATE table SET column = <expression> [, ...] [WHERE <expression>]

B.5.1.11 式、条件および値

<expression> ::=
[NOT] <condition> [ { OR | AND } <condition> ]

<condition> ::=
{ <value> [ || <value> ]
| <value> { = | < | <= | > | >= | <> | != | IS [NOT] } <value>
| EXISTS(<select_statement>)
| <value> BETWEEN <value> AND <value>
| <value> [NOT] IN ( {<value> [, ...] | selectStatement } )
| <value> [NOT] LIKE <value> [ESCAPE] value }

<value> ::=
[ + | - ] { term [ { + | - | * | / } term ]
| ( condition )
| function ( [parameter] [,...] )
| selectStatement_giving_one_value

<term> ::=
{ 'string' | number | floatingpoint | [table.]column | TRUE | FALSE | NULL }

<string> ::=

- 開始および終了には、単一の「'」を使用します。「'」で開始した文字列内に「'」を作成するには、「''」を使用します。

- LIKEでは、任意の数(0を含む)の文字と一致させる場合は%を使用し、1つの文字と完全に一致させる場合は_を使用します。%自体の検索には\%、_自体の検索には\_を使用するか、ESCAPE句を使用してその他の任意のエスケープ文字を設定できます。

<name> ::=

- 名前の先頭は文字で、後に任意の数の文字または数字が続きます。文字列および引用符で囲まれた識別子以外の小文字は、大文字に変換されます。名前では大/小文字は区別されません。

- 識別子(表または列など)を引用符で囲んで、名前として使用できます。引用符で囲まれた識別子は、「"」で始まり「"」で終わります。引用符で囲まれた識別子の中に「"」を作成するには、「""」を使用します。引用符で囲まれた識別子を使用することで、大/小文字が混在する表および表名を作成できます。例: CREATE TABLE "Address" ("Nr" INTEGER, "Name" VARCHAR); SELECT * FROM "Address"。引用符で囲まれた識別子は文字列ではありません。

<values> ::=

- 日付値は「'」で始まり「'」で終わります。書式はyyyy-mm-ddです(java.sql.Dateを参照)。

- 時間値は「'」で始まり「'」で終わります。書式はhh:mm:ssです(java.sql.Timeを参照)。

- バイナリ・データは「'」で始まり「'」で終わります。書式は16進値です。たとえば'0004ff'は、最初が0、2番目が4、最後が255 (0xff)の3バイトです。

B.5.2 SQLファンクション

表B-4に数値ファンクションをリストします。

表B-4 数値ファンクション

ファンクション

説明

ABS(d)

double値の絶対値を戻します。

ACOS(d)

角度のアーク・コサインを戻します。

ASIN(d)

角度のアーク・サインを戻します。

ATAN(d)

角度のアーク・タンジェントを戻します。

ATAN2(a,b)

a/bのタンジェントを戻します。

CEILING(d)

d以上の最小整数を戻します。

COS(d)

角度のコサインを戻します。

COT(d)

角度のコタンジェントを戻します。

DEGREES(d)

ラジアンを角度に変換します。

EXP(d)

e (2.718...)のd乗を戻します。

FLOOR(d)

d以下の最大整数を戻します。

LOG(d)

eを底とする自然対数を戻します。

LOG10(d)

10を底とする対数を戻します。

MOD(a,b)

aをbで割った剰余を戻します。

PI()

円周率(3.1415...)を戻します。

POWER(a,b)

aのb乗を戻します。

RADIANS(d)

角度をラジアンに変換します。

RAND()

0.0以上1.0未満の乱数xを戻します。

ROUND(a,b)

aを小数点以下b桁に丸めます。

SIGN(d)

dが0未満の場合は-1、dが0の場合は0、dが0より大きい場合は1を戻します。

SIN(d)

角度のサインを戻します。

SQRT(d)

平方根を戻します。

TAN(d)

角度の三角関数タンジェントを戻します。

TRUNCATE(a,b)

aを小数点以下b桁に切り捨てます。

BITAND(a,b)

a & bを戻します。

BITOR(a,b)

a | bを戻します。

表B-5に文字列ファンクションをリストします。

表B-5 文字列ファンクション

ファンクション

説明

ASCII(s)

sの左端の文字のASCIIコードを戻します。

CHAR(c)

ASCIIコードがcの文字を戻します。

CONCAT(str1,str2)

str1とstr2を連結して戻します。

DIFFERENCE(s1,s2)

s1とs2の発音の差を戻します。

INSERT(s,start,len,s2)

startからlen文字分をs2に置き換えて、文字列を戻します。

LCASE(s)

sを小文字に変換します。

LEFT(s,count)

sの左端からcount文字分を戻します。

LENGTH(s)

sの文字数を戻します。

LOCATE(search,s,[start])

startから開始して、s内でsearchが検出された最初の索引(1=左、0=見つからない)を戻します。

LTRIM(s)

sの先頭の空白をすべて削除します。

REPEAT(s,count)

sをcount回分繰り返して戻します。

REPLACE(s,replace,s2)

sに出現するすべてのreplaceをs2に置き換えます。

RIGHT(s,count)

sの右端からcount文字分を戻します。

RTRIM(s)

末尾の空白をすべて削除します。

SOUNDEX(s)

sの発音を表す4文字のコードを戻します。

SPACE(count)

count個分のスペースで構成される文字列を戻します。

SUBSTRING(s,start[,len])

start (1=左)からlen文字分のサブストリングを戻します。

UCASE(s)

sを大文字に変換します。

LOWER(s)

sを小文字に変換します。

UPPER(s)

sを大文字に変換します。

表B-6に日時ファンクションをリストします。

日付値は一重引用符(')で始まり、一重引用符(')で終わります。書式はyyyy-mm-ddです(java.sql.Dateを参照)。時間値は一重引用符(')で始まり、一重引用符(')で終わります。書式はhh:mm:ssです(java.sql.Timeを参照)。

表B-6 日時ファンクション

ファンクション

説明

CURDATE()

現在の日付を戻します。

CURTIME()

現在の時間を戻します。

DAYNAME(date)

曜日の名前を戻します。

DAYOFMONTH(date)

月の日付(1から31)を戻します。

DAYOFWEEK(date)

週の曜日(1は日曜日)を戻します。

DAYOFYEAR(date)

その年の何日目か(1から366)を戻します。

HOUR(time)

時間(0から23)を戻します。

MINUTE(time)

分(0から59)を戻します。

MONTH(date)

月(1から12)を戻します。

MONTHNAME(date)

月の名前を戻します。

NOW()

現在の日時をタイムスタンプとして戻します。

QUARTER(date)

四半期(1から4)を戻します。

SECOND(time)

秒(0から59)を戻します。

WEEK(date)

その年の何週目か(1から53)を戻します。

YEAR(date)

年を戻します。

表B-7にシステム・ファンクションをリストします。

表B-7 システム・ファンクション

ファンクション

説明

IFNULL(exp,value)

expがNULLの場合はvalueを戻し、NULLでない場合はexpを戻します。

CASEWHEN(exp,v2,v2)

expがtrueの場合はv1を戻し、trueでない場合はv2を戻します。

CONVERT(term,type)

expを別のデータ型に変換します。

CAST(term AS type)

expを別のデータ型に変換します。

B.6 実装されるJDBC API機能

表B-8に、Oracle Data Integrator Driver for XMLに実装されているJDBC API機能をリストします。

表B-8 JDBC APIの機能

機能グループ

JDBCのバージョン

サポート

バッチ更新

2.0コア

はい

Blob/Clob

2.0コア

はい

JNDIデータソース

2.0オプション

はい

フェイルオーバー・サポート

-

はい

トランザクション・セーブポイント

3.0

はい

Unicodeサポート

-

いいえ

分散トランザクション

2.0オプション

いいえ

接続プーリング

2.0オプション

いいえ

クラスタ・サポート

-

いいえ

表B-9にJDBC Javaクラスをリストします。

表B-9 JDBC Javaクラス

JDBCクラス

JDBCのバージョン

サポート

Array

2.0コア

いいえ

Blob

2.0コア

はい

CallableStatement

1.0

はい

Clob

2.0コア

はい

Connection

1.0

はい

ConnectionPoolDataSource

2.0オプション

いいえ

DatabaseMetaData

1.0

はい

DataSource

2.0オプション

いいえ

Driver

1.0

はい

Ref

2.0コア

いいえ

ResultSet

1.0

はい

ResultSetMetaData

1.0

はい

RowSet

2.0オプション

いいえ

Statement

1.0

はい

Struct

2.0コア

いいえ

PreparedStatement

1.0

はい

XAConnection

2.0オプション

いいえ

XADataSource

2.0オプション

いいえ

B.7 リッチ・メタデータ

XMLスキーマに基づくRDB構造を作成する場合は、ドライバにメタデータを提供できる柔軟性が必要です。たとえば、要素/属性が同じローカル名を持つ場合、RDB表/列の名前が競合する可能性があります。

ODI XMLドライバは、x2rネームスペース(http://www.oracle.com/odi/xml-mapping)の属性を要素/属性(x2r:tableName/x2r:columnName)にアタッチします。競合する名前がメタデータ属性を持たない場合は、競合しない表/列の名前が取得されるまで、増分する番号がそれらに追加されます。

新しいオブジェクト・モデルは、要素/属性ごとにxpathとtable/table.columnの名前の間のマップを保持します。

2つの異なる場所に同じ名前および同じタイプの要素が2つ存在する場合、データの格納には同じ表が使用されますが、データを区別するために親要素へのFK参照が使用されます。新しい実装によって新しい表が作成されます。表B-10に表の属性を示します。

表B-10 表の属性

属性

種類

説明

x2r:tableName

文字列

ローカル名が一致するリストまたは列挙であるRDB表/属性に解決される要素にアタッチされます。

x2r:columnName

文字列

ローカル名が一致する属性にアタッチされるか、列にマップされるが、ローカル名が互いに一致するか、それを包含するタイプの属性と一致する要素の属性にアタッチされます。

x2r:columnDataType

文字列

提供されるマッピング表からデータ型情報を文字列として提供できます。

ドライバが列または属性にマップする要素にのみアタッチできます。このパラメータが指定されている場合、ユーザーはデータ型に必要なx2r:columnLengthまたはx2r:columnPrecision (あるいはその両方)を指定する必要もあります。

x2r:columnLength

整数

列の長さ。

デフォルトでは、ドライバにハードコードされている値が使用されます。JDBC URLでは、VARCHARとNUMERICのグローバル・オーバーライド・オプションがあります。この属性を指定した場合、デフォルト値とグローバル・オーバーライドの両方がオーバーライドされます。

ドライバが列または属性にマップする要素にのみアタッチできます。

x2r:columnPrecision

整数

列の精度。これを使用できるデータ型の場合のみ、ドライバによって使用されます。適用される値の決定時には、columnLengthと同じロジックが使用されます。

ドライバが列または属性にマップする要素にのみアタッチできます。

次の例に、リッチ・メタデータを含むXSDを示します。

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:x2r="http://www.oracle.com/odi/xml-mapping">
<xs:element name="root">
<xs:complexType>
<xs:sequence>
<!--  Example for redefining table name  -->
<xs:element name="person" maxOccurs="unbounded" x2r:tableName="CUSTOMER">
<xs:complexType>
<xs:sequence>
<!--  Example for redefining column name  -->
<xs:element name="given" type="xs:string" x2r:columnName="FIRST"/>
<xs:element name="last" type="xs:string"/>
<!--  Example for redefining column length  -->
<xs:element name="address" type="xs:string" x2r:columnLength="400"/>
<!--  Example for redefining column type  -->
<xs:element name="notes" type="xs:string" x2r:columnDataType="CLOB"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

B.7.1 様々なデータベースに対してサポートされているユーザー指定型

表B-11に、様々なデータベースに対してサポートされているユーザー指定型の詳細を示します。これ以外の型名を使用すると、例外が発生します。

表B-11 各データベースに対してサポートされているユーザー指定型

種類

HSQL

Oracle

MySQL

MS SQL Server

SMALLINT

X

X

X

INTEGER

X

X

REAL

X

X

NUMERIC

X

X

NUMBER

X

FLOAT

X

X

X

DOUBLE

X

X

DECIMAL

X

X

CHAR

X

X

X

X

NCHAR

X

X

X

VARCHAR

X

X

X

X

VARCHAR2

X

NVARCHAR2

X

BLOB

X

X

X

CLOB

X

X

NCLOB

X

TEXT

X

X

DATE

X

X

X

TIME

X

X

X

TIMESTAMP

X

X

X

X

B.8 サポートされているXMLスキーマの機能

ドライバでは、XMLスキーマ(XSD)仕様の一部がサポートされています。この項では、サポートされている要素をリストします。

XMLスキーマ仕様の詳細は、W3Cの仕様(http://www.w3.org/TR/xmlschema-1/)を参照してください。

この項には次のトピックが含まれます:

- データ型

- サポートされている要素

- サポートされていない機能

B.8.1 データ型

サポートされているデータ型は次のとおりです。

- 文字列に変換されるデータ型: string、normalizedString、token、nmtoken、nmtokens、anyUri、id、idref、date、datetime、time、hexBinary

- 整数列に変換されるデータ型: int、positiveInteger、negativeInteger、nonNegativeInteger、onPositiveInteger、long、unsignedLong、unsignedInt、short、unsignedShort、byte、unsignedByte、boolean(ブール値は0または1の数値列に変換されますが、入力ファイルからtrueまたはfalseの値を取得できます。)

- 小数列に変換されるデータ型(小数点以下2桁): decimal、float、double

B.8.2 サポートされている要素

この項では、スキーマのすべての要素をリストします。サポートされている構文要素は、太字で表記されています。サポートされていない構文要素は、通常のフォントで表記されています。これらは、ドライバによって無視されます。

この項では、次のスキーマ要素について説明します。

- All

- any

- anyAttribute

- anyType

- Attribute

- AttributeGroup

- Choice

- ComplexContent

- ComplexType

- Element

- Extension

- Group

- Import

- Include

- List

- Restriction

- Schema

- Sequence

- SimpleContent

- SimpleType

注意:
理想としては、XMLドライバを使用して生成または更新されたXMLファイルは、生成後にVALIDATEコマンドを使用して、対応するXSDファイルと照合して検証する必要があります。

B.8.2.1 all

この要素は、子要素を順序付けせずに、それぞれ0回または1回出現させることができることを示します。

子要素の必須プロパティ(minOccurs=1)は、ドライバでは管理されないため注意してください。データのチェック、およびXSDとの照合によるXMLコンテンツの検証を実行することで、これを管理する必要があります。

<all
id=ID
maxOccurs=1
minOccurs=0|1
any attributes
>
(annotation?,element*)
</all>

B.8.2.2 any

この要素を使用すると、スキーマで指定されていない要素を使用してXMLドキュメントを拡張できます。

<any
id=ID
maxOccurs=(nonNegativeInteger|unbounded):1
minOccurs=nonNegativeInteger:1
namespace=((##any|##other)|List of (anyURI|(##targetNamespace|##local))):##any
processContents=(lax|skip|strict):strict
any attributes
>
(annotation?)
</any>

B.8.2.3 anyAttribute

この要素を使用すると、スキーマで指定されていない属性を使用してXMLドキュメントを拡張できます。

<anyAttribute
id=ID
namespace=((##any|##other)|List of (anyURI|(##targetNamespace|##local))):##any
processContents=(lax|skip|strict):strict
any attributes
>
(annotation?)
</anyAttribute>

B.8.2.4 anyType

このXMLスキーマ・タイプは、すべてのXMLスキーマ・タイプのルート・タイプです。

<xsd:element name="something" type="xsd:anyType"/>

B.8.2.5 attribute

この要素は属性を定義します。

<attribute
default=string
id=ID
name=NCName
type=QName
use=optional|prohibited|required
ref=QName
fixed=string
form=qualified|unqualified
any attributes
>
(annotation?,(simpleType?))
</attribute>

この要素のuse属性は、属性に対してドライバによってマップされる列が必須かどうかを定義します。

B.8.2.6 attributeGroup

この要素は、一連の属性を定義します。

<attributeGroup
id=ID
name=NCName
ref=QName
any attributes
>
(annotation?),((attribute|attributeGroup)*,anyAttribute?))
</attributeGroup>

B.8.2.7 choice

この要素では、中に含まれている要素のうち1つのみが出現可能になります。

<choice
id=ID
maxOccurs=nonNegativeInteger|unbounded
minOccurs=nonNegativeInteger
any attributes
>
(annotation?,(element|group|choice|sequence|any)*)
</choice>

子要素の一意性は、ドライバでは管理されません。データのチェック、およびXSDとの照合によるXMLコンテンツの検証を実行することで、これを管理する必要があります。

B.8.2.8 complexContent

この要素は、複合型での拡張または制限を定義します。

<complexContent
id=ID
mixed=true|false
any attributes
>
(annotation?,(restriction|extension))
</complexContent>

B.8.2.9 complexType

この要素は、複合型を定義します。

<complexType
name=NCName
id=ID
abstract=true|false
mixed=true|false
block=(#all|list of (extension|restriction))
final=(#all|list of (extension|restriction))
any attributes
>
(annotation?,(simpleContent|complexContent|((group|all|choice|sequence)?,((attribute|attributeGroup)*,anyAttribute?))))
</complexType>

B.8.2.10 element

この要素は、XMLファイルの要素を定義します。

<element
name=NCName
maxOccurs=nonNegativeInteger|unbounded
minOccurs=nonNegativeInteger
type=QName
id=ID
ref=QName
substitutionGroup=QName
default=string
fixed=string
form=qualified|unqualified
nillable=true|false
abstract=true|false
block=(#all|list of (extension|restriction))
final=(#all|list of (extension|restriction))
any attributes
>
annotation?,((simpleType|complexType)?,(unique|key|keyref)*))
</element>

注意:
この要素のmaxOccursおよびminOccurs属性は、XMLからSQLへのマッピングに使用されます。子要素が単純型で単一値(1回のみ出現)の場合、この要素は、親要素に対応する表の単純列にマップされます。それ以外の場合は、親要素の表にリンクされる表が作成されます。
要素内にminOccursまたはmaxOccursへの参照が記述されていない場合、その要素は単一値とみなされ、列に変換されます。この動作は、useImplicitMaxValue URLプロパティを使用して変更できます。このプロパティをyesに設定した場合、XSDでmaxOccursが指定されていない要素は、複数値(maxOccurs ="unbounded")とみなされます。

注意:
名前が同じで型が異なる複数のサブ要素の使用は、XMLドライバではサポートされていません。そのような構造を持つXSDは、正しく処理されません。

B.8.2.11 extension

この要素は、既存のsimpleTypeまたはcomplexType要素を拡張します。

<extension
id=ID
base=QName
any attributes
>
(annotation?,((group|all|choice|sequence)?,((attribute|attributeGroup)*,anyAttribute?)))
</extension>

B.8.2.12 group

この要素は、複合型の定義で使用される要素のグループを定義します。

<group
id=ID
name=NCName
ref=QName
maxOccurs=nonNegativeInteger|unbounded
minOccurs=nonNegativeInteger
any attributes
>
(annotation?,(all|choice|sequence)?)
</group>

B.8.2.13 import

この要素は、ターゲット名前空間が異なる複数のスキーマをドキュメントに追加します。

<import
id=ID
namespace=anyURI
schemaLocation=anyURI
any attributes
>
(annotation?)
</import>

B.8.2.14 include

この要素は、ターゲット名前空間が同じ複数のスキーマをドキュメントに追加します。

<include
id=ID
schemaLocation=anyURI
any attributes
>
(annotation?)
</include>

B.8.2.15 list

この要素は、単純型要素を、指定されたデータ型の値のリストとして定義します。

<list
id=ID
itemType=QName
any attributes
>
(annotation?,(simpleType?))
</list>

B.8.2.16 restriction

この要素は、simpleType、simpleContentまたはcomplexContentでの制限を定義します。

<restriction
id=ID
base=QName
any attributes
>
Content for simpleType:
(annotation?,(simpleType?,(minExclusive|minInclusive|maxExclusive|maxInclusive|
totalDigits|fractionDigits|length|minLength|maxLength|enumeration|whiteSpace|
pattern)*))
Content for simpleContent:
(annotation?,(simpleType?,(minExclusive|minInclusive|maxExclusive|maxInclusive|
totalDigits|fractionDigits|length|minLength|maxLength|enumeration|whiteSpace|
pattern)*)?, ((attribute|attributeGroup)*,anyAttribute?))
Content for complexContent:
(annotation?,(group|all|choice|sequence)?, ((attribute|attributeGroup)*,anyAttribute?))
</restriction>

B.8.2.17 schema

この要素は、スキーマのルート要素を定義します。

<schema
id=ID
attributeFormDefault=qualified|unqualified
elementFormDefault=qualified|unqualified
blockDefault=(#all|list of (extension|restriction|substitution))
finalDefault=(#all|list of (extension|restriction|list|union))
targetNamespace=anyURI
version=token
xmlns=anyURI
any attributes
>
((include|import|redefine|annotation)*,(((simpleType|complexType|group|
attributeGroup)|element|attribute|notation),annotation*)*)
</schema>

B.8.2.18 sequence

この要素は、子要素を順序に従って表示する必要があることを指定します。各子要素は0回以上出現可能です。

<sequence
id=ID
maxOccurs=nonNegativeInteger|unbounded
minOccurs=nonNegativeInteger
any attributes
>
(annotation?,(element|group|choice|sequence|any)*)
</sequence>

次の点に注意してください。

- 順序は、ドライバでは管理されません。ドライバによって生成されるxxx_ORDER列をロードして、順序を管理する必要があります。

- maxOccursおよびminOccurs属性はドライバでは管理されません。データのチェック、およびXSDとの照合によるXMLコンテンツの検証を実行することで、これを管理する必要があります。

B.8.2.19 simpleContent

この要素には、テキストのみの複合型または単純型に関する拡張または制限がコンテンツとして含まれます。

<simpleContent
id=ID
any attributes
>
(annotation?,(restriction|extension))
</simpleContent>

B.8.2.20 simpleType

この要素は、単純型要素を定義します。

<simpleType
name=NCName
id=ID
any attributes
>
(annotation?,(restriction|list|union))
</simpleType>

B.8.3 サポートされていない機能

XMLドライバでは、次の要素および機能はサポートおよび実装されていません。

B.8.3.1 サポートされていない要素

次のスキーマ要素は、XMLドライバではサポートされていません。

- Key/keyRef/Unique: これらの要素を使用すると、スキーマで制約を定義できます。これらの要素およびその子要素(selector、field)は、無視されます。

- Redefine: redefine要素は、単純型、複合型、グループおよび属性グループを外部スキーマから再定義します。この要素はサポートされていません。

v3モードで、サポートされていないXSD要素が検出された場合には、エラーが発生します。

警告:

XSDに含まれるAny句またはAnyAttribute句によって許可されるXMLファイル内の要素および属性は、ファイルをロードする際にエラーを引き起こす可能性があります。

B.8.3.2 サポートされていない機能

v3モードでは、マルチパス解析がサポートされています。他のモードでは、マルチパス解析はサポートされません。

B.8.3.3 サポートされていないデータ型

次のデータ型はサポートされていません。

- gYear

- gYearMonth

- gMonth

- gMonthDay

- gDay

- language

- ENTITY

- ENTITIES

- NOTATION

- IDREFS

C Oracle Data Integrator Driver for Complex Filesの参照情報

この付録では、Oracle Data Integrator driver for Complex Filesの使用方法を説明します。

この付録には次の項が含まれます:

- C.1項「Oracle Data Integrator Driver for Complex Filesの概要」

- C.2項「複合ファイルの処理の概要」

- C.3項「ドライバの構成」

- C.4項「ドライバ・コマンドの詳細」

- C.5項「サポートされているJDBC APIおよびXMLスキーマの機能」

C.1 Oracle Data Integrator Driver for Complex Filesの概要

Oracle Data Integrator Driver for Complex Files(複合ファイル・ドライバ)では、複合(またはネイティブ)フォーマットのファイルがJDBCデータソースとして処理されます。これにより、複合ファイルをOracle Data Integratorでデータ・サーバーとして使用することが可能になります。

複合ファイル・ドライバとともにOracle Data Integratorを使用すると、複合ファイルへの変更を標準のSQL構文で実行できます。これらの操作はトランザクション内で発生し、コミットまたはロールバックが可能です。

Oracle Data Integrator driver for Complex Filesでサポートされている機能は次のとおりです。

- 標準のSQL (Structured Query Language)構文

- 相関サブ問合せ、内部および外部結合

- ORDER BYおよびGROUP BY

- COUNT、SUM、MIN、MAX、AVGおよびその他のファンクション

- 標準のSQLファンクション

- トランザクション管理

- 参照整合性(外部キー)

- 変更の複合ファイルへの保存

C.2 複合ファイルの処理の概要

複合ファイル・ドライバでは、ネイティブ・スキーマ・ファイルを使用します。このファイルは、nXSD形式で記述され、ネイティブ・ファイルの構造およびネイティブ・ファイルをXMLファイルに変換する方法を示します。

複合ファイル・ドライバでは、ネイティブ・スキーマ(nXSD)の記述での定義に従い、ネイティブ・ファイルをXML構造に内部的に変換し、このXMLファイルから、Oracle Data Integratorによって消費されるリレーショナル・スキーマを生成します。図C-1に、全体的なメカニズムを示します。

図C-1 複合ファイル・ドライバの処理

XML構造から始まる処理の2番目の部分は、Oracle Data Integrator Driver for XMLの機能に正確に対応しています。

複合ファイル・ドライバは次のように機能します。

1. 複合ファイルはネイティブ・スキーマ(nXSD)ファイルを使用して中間XMLファイルに変換されます。中間XMLファイルに対して物理ファイルは作成されず、ストリーミングXML構造が作成されることに注意してください。

2. ドライバは、XMLからSQLへのマッピングを使用して、XML構造およびデータをリレーショナル・スキーマにロードします。

3. ユーザーは、通常のSQL文、またはドライバ操作用の特定のドライバ・コマンドを介してデータを操作し、リレーショナル・スキーマを使用します。

4. 複合ファイル・ドライバは、切断時またはユーザー・リクエストに応じて、スキーマに格納されているデータおよび構造を元の複合ファイルに同期化します。

C.2.1 ネイティブ・スキーマの生成

ネイティブ・スキーマは、手動で作成することも、Fusion Middlewareテクノロジ・アダプタの一部として利用可能なネイティブ・フォーマット・ビルダー・ウィザードを使用して生成することもできます。ネイティブ・スキーマ形式およびネイティブ・フォーマット・ビルダー・ウィザードの詳細は、テクノロジ・アダプタ・ユーザーズ・ガイドのネイティブ・フォーマット・ビルダー・ウィザードに関する項を参照してください。

C.2.2 XMLからSQLへのマッピング

XMLからSQLへのマッピングは複雑なプロセスで、階層構造(XML)をリレーショナル構造(スキーマ)にマップするために使用されます。このマッピングは自動的に行われます。詳細は、B.2.1項「XMLからSQLへのマッピング」を参照してください。

C.2.3 JSONのサポート

JSON形式のフラット・ファイルは、nXSD形式を介してサポートされています。nXSDファイルは、手動で作成することも、ネイティブ・フォーマット・ビルダー・ウィザードを使用して作成することもできます(詳細は、「ネイティブ・スキーマの生成」を参照してください)。nXSD注釈のないXSDファイルを使用する場合は、ドライバが入力ファイルの解析用にJSONトランスレータを使用できるように、追加のJDBCプロパティtt=jsonまたはtranslator_type=jsonを指定する必要があります。

C.2.4 サポートされている機能

複合ファイル・ドライバは、XMLドライバと同じ機能をサポートしています。

- 組込みエンジンまたは外部データベースへのスキーマの格納が、XMLドライバと同じ方法でサポートされます。詳細は、B.2.3.1項「スキーマの格納」およびB.3.3項「外部データベースを使用したデータの格納」を参照してください。

- 複数のスキーマがサポートされ、次の点が異なります。

- 接続時には、ネイティブ・スキーマ・ファイルに基づいて、単一のスキーマのみを作成できます。

- B.3.2項「複数のスキーマの自動作成」で示されている、接続時に複数のスキーマの作成を可能にするパラメータはサポートされていません。これには、add_schema_bundle、add_schema_pathおよびaddschema_Xが含まれます。

- 接続後、CREATE SCHEMAおよびLOAD FILEコマンドを使用して追加のスキーマを作成できます。

- XMLドライバと同様に、大/小文字の区別が管理されます。詳細は、B.2.3.4項「大/小文字の区別」を参照してください。

- 複合ファイル・ドライバでのロード/同期化は、XMLドライバと同じように機能します。ロード/同期化操作はネイティブ・ファイルに自動的に伝播します。詳細は、B.2.3.5項「ロード/同期化」を参照してください。

- ロックがサポートされています。複合ファイルは接続時にロックされ、切断時にロック解除されます。UNLOCK FILEコマンドがサポートされています。

C.3 ドライバの構成

Oracle Data Integrator driver for Complex Filesは、Oracle Data Integratorとともに自動的にインストールされます。次の各項では、拡張構成の説明および参照情報を示します。

この項ではドライバの構成について説明します。

- ドライバ名: oracle.odi.jdbc.driver.file.complex.ComplexFileDriver

- URL構文: jdbc:snps:complexfile?f=<native file location>&d=<native schema>&re=<root element name>[&s=<schema name>&<property>=<value>...]

URLのプロパティの詳細を表C-0に示します。

表C-1 ドライバのプロパティ

プロパティ

必須

種類

デフォルト

説明

fileまたはf

はい

文字列(ファイルの場所)

-

ネイティブ・ファイルの場所。パス名には、バックスラッシュ"\"ではなくスラッシュ"/"を使用します。HTTP、FTPまたはファイルのURLを使用してファイルの場所を示すことができます。URLによって示されたファイルは読取り専用です。このパラメータは必須です。

dtdまたはd

はい

文字列(ファイルの場所)

-

ネイティブ・スキーマ(nXSD)ファイルの場所。このパラメータは必須です。

root_eltまたはre

はい

文字列

-

スキーマのルート表として選択する要素の名前。この値では大/小文字が区別されます。このプロパティは、ネイティブ・スキーマの特定のセクションなどのリバース・エンジニアリングに使用できます。このパラメータは必須です。

read_onlyまたはro

いいえ

ブール値(true | false)

false

ネイティブ・ファイルを読取り専用モードで開きます。

schemaまたはs

いいえ

文字列

-

複合ファイルのロード先となるリレーショナル・スキーマの名前。このパラメータは必須です。

このスキーマは、複合ファイル・データ・サーバーの下に物理スキーマを作成する際に選択されます。

注意: スキーマへの接続を複数作成することはできません。すでに使用中のスキーマに接続しようとした場合、後続の接続は失敗します。

重要: スキーマ名は大文字で指定する必要があります。既存のXML要素と似た名前を付けることはできません。

standalone

いいえ

ブール値(true | false)

false

このオプションをtrueに設定すると、この接続のスキーマは、他のすべてのスキーマから完全に分離されます。このオプションでは、各スキーマを分離したまま複数の接続に対して同じスキーマ名を指定できます。このオプションを使用すると、このスキーマの表に他のスキーマからアクセスできません。また、この接続で他のスキーマの表にもアクセスできません。

注意: このオプションは、外部データベースを使用する場合には適用できません。

translator_typeまたはtt

いいえ

文字列(json)

-

このオプションをjsonに設定した場合、xsdではnXSD注釈が不要になり、入力ファイルの解析用にJSONトランスレータが自動的に使用されます。

db_propsまたはdp

いいえ

文字列

-

このプロパティは、メモリー・エンジンのかわりに外部データベースを使用してスキーマを格納するために使用します。

詳細は、B.3.3項「外部データベースを使用したデータの格納」を参照してください。

load_data_on_connectまたはldoc

いいえ

ブール値(true | false)

true

JDBC接続の実行時に、スキーマにデータを自動的にロードします。falseに設定した場合は、接続後にSYNCHRONIZE文を使用してデータをロードする必要があります。

このオプションは、すべてのデータをロードせずに接続をテストしたりメタデータを参照するのに役立ちます。

drop_on_discまたはdod

いいえ

ブール値(true | false)

false

JDBC接続を閉じるとき、スキーマを自動的にドロップします。

trueの場合、スキーマは組込みエンジンに格納され、常にドロップされます。

スキーマが外部データベースに格納されている場合、ドライバはデータベース・スキーマのドロップを試行しますが、このスキーマ内に表がまだ存在していると失敗する可能性があります。スキーマのドロップ時に自動的にすべての表が確実にドロップされるようにするには、外部データベースのプロパティ・ファイルでdrop_tables_on_drop_schemaプロパティを指定します。詳細は、B.3.3項「外部データベースを使用したデータの格納」を参照してください。

useimplicitmaxvalue

いいえ

ブール値(true | false)

false

このプロパティをtrueに設定した場合、スキーマでmaxOccursが指定されていない要素は、maxOccurs ="unbounded"とみなされます。それ以外の場合、maxOccursが指定されていない要素はmaxOccurs=1とみなされます。

java_encodingまたはje

いいえ

文字列(エンコーディング・コード)

UTF8

ターゲット・ファイルのエンコーディング(例: ISO8859_1)。サポートされているエンコーディングのリストは、次のURLにあります: http://java.sun.com/j2se/1.3/docs/guide/intl/encoding.doc.html

numeric_idsまたはni

いいえ

ブール値(true | false)

true

trueに設定すると、すべての内部の主キーおよび外部キーがNUMERIC型になります。それ以外の場合はVARCHAR型になります。

id_lengthまたはil

いいえ

整数

10 / 30

内部の主キーおよび外部キーの列の長さ。デフォルトは、列型がNUMERICの場合は10、VARCHARの場合は30です。

numeric_scaleまたはns

いいえ

整数

空

リレーショナル・スキーマで生成される数値列のスケール。

no_batch_updateまたはnobu

いいえ

ブール値(true | false)

false

この接続にはバッチ更新は使用されません。バッチ更新を設定するコマンドは送信されません。これにより、このJDBC機能をサポートしていない外部データベースに関するエラーの発生を回避し、バッチ更新の使用に関するエラーをデバッグできます。

transform_nonasciiまたはtna

いいえ

ブール値(true|false)

true

非ASCIIを変換します。非ASCII文字を保持するにはfalseに設定します。

これらのプロパティを次の例に示します。

products.nxsdによって説明されるPROD20100125_001.csvファイルに接続し、このファイルをリレーショナル構造としてPRODUCTスキーマで公開します。

jdbc:snps:complexfile?f=/infiles/PROD20100125_001.csv&d=/infiles/products.nxsd&re=root&s=PRODUCTS

C.4 ドライバ・コマンドの詳細

複合ファイル・ドライバは、XMLドライバと同じドライバ・コマンドをサポートしています。XMLドライバでサポートされているドライバ・コマンドの詳細は、B.4項「ドライバ・コマンドの詳細」を参照してください。

このルールには次の例外があります。

- 複合ファイル・ドライバの構文では、CREATE FILEやLOAD FILEなどのXMLファイルに関連するコマンドは、ネイティブ・ファイルに適用されます。たとえば、コマンドCREATE FILEによって、スキーマ・コンテンツからネイティブ・フォーマット・ファイルが作成されます。

- VALIDATEはサポートされていません。

- CREATE FILEはサポートされていますが、NO_CLOSING_TAGSおよびNO_DEFAULT_NSパラメータは無視されます。

- CREATE SCHEMAには、WITH DTDパラメータが必要です。

- LOAD FILEには、WITH DTDパラメータが必要です。

C.5 サポートされているJDBC APIおよびXMLスキーマの機能

複合ファイル・ドライバは、XMLドライバと同じJDBC機能をサポートしています。詳細は、B.5項「SQL構文」を参照してください。

D XMLおよび複合ファイル・ドライバの事前/事後処理サポート

この付録では、XMLおよび複合ファイルのOracle Data Integratorドライバの事前および事後処理ステージを構成および実装する方法について説明します。

この付録の内容は次のとおりです。

- D.1項「概要」

- D.2項「処理ステージの構成」

- D.3項「処理ステージの実装」

- D.4項「例: ZIPファイル内からXMLデータを読み取るためのGroovyスクリプト」

- D.5項「例: XMLデータを変換して異なる形式に書き込むためのGroovyスクリプト」

- D.6項「例: 認証を必要とするHTTPソースからデータを読み取るためのJavaクラス」

- D.7項「例: 構成XMLファイルに組み込まれたGroovyコード」

D.1 概要

データをXMLおよび複合ファイル・ドライバに提供する方法をカスタマイズできるようになりました。中間処理ステージを設定して、Oracle Data Integratorを使用して外部エンドポイントから取得されるデータを処理したり、データを外部エンドポイントに書き出すことができます。

1つのターミナル・ステージおよびゼロ以上のジャンクション・ステージを構成できます。ターミナル・ステージは外部エンドポイントからデータを読み取り、データを外部エンドポイントに書き込みます。ターミナル・ステージは外部エンドポイントからソース・データを読み取り、処理用にジャンクション・ステージに渡します。ジャンクション・ステージを構成して、ターミナル・ステージから渡されたデータを処理できます。

ソース・データに任意の形式を指定できます。XMLドライバまたは複合ファイル・ドライバに達するまで必ずしもXMLまたは複合ファイルである必要はありません。ただし、データが最終的にXMLドライバまたは複合ファイル・ドライバに渡される場合、データを必要な形式にする必要があります。つまり、データがXMLドライバに渡される場合、データ・サーバーに構成されているXSDに準拠する有効なXMLである必要があります。同様に、データが複合ファイル・ドライバに渡される場合、データがnXSDファイルで定義されているパターンと完全に一致する必要があります。

D.2 処理ステージの構成

XMLファイル形式のODI JDBCドライバに対する中間処理ステージの完全な構成。構成XMLファイルのXSDも含める必要があります。

入力パイプライン構成の場合、最初のステージは最初に入力を処理します。最後のステージはデータをドライバに提供します。この最後のステージは、XMLまたは複合ファイル・ドライバで想定される形式に準拠する出力である必要があります。

出力パイプライン構成の場合、最後のステージは出力を書き出します。最初のステージはドライバからデータを受け入れます。このデータは、データサーバーのXSDと同じ形状です。

構成を含むXMLファイルを作成した後、XMLドライバまたは複合ファイル・ドライバのpipeline_config_fileまたはpcfプロパティがXMLファイルの絶対ファイル位置を指していることを確認します。

例D-1に、サンプルの構成XMLファイルを示します。

例D-1 サンプルの構成XMLファイル

<?xml version="1.0" encoding="UTF-8"?>
<pipeline xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="pre-post.xsd">

<input-stages>
<io-stage name="restInput">
<codeDefinition>
<javaClass>com.company.org.InputProcessor</javaClass>
</codeDefinition>
<debugOutput>http://tempuri.org</debugOutput>
</io-stage>
<stage name="BufferInputStage">
<codeDefinition>
<javaClass>com.company.org.BufferingClass</javaClass>
</codeDefinition>
<props>
<property name="bufferSizeBytes">2340</property>
</props>
</stage>
<stage name="UnzipStage">
<codeDefinition>
<code>[Groovy text in Base64 encoded form]</code>
</codeDefinition>
</stage>
</input-stages>
<output-stages>
<io-stage name="restOut">
<codeDefinition>
<javaClass>com.company.org.OutputProcessor</javaClass>
</codeDefinition>
<debugOutput>http://tempuri.org</debugOutput>
</io-stage>
<stage name="SevenZipOutputStage">
<codeDefinition>
<code>[Groovy text in Base64 encoded form]</code>
</codeDefinition>
</stage>
<stage name="BufferOutputStage">
<codeDefinition>
<javaClass>com.company.org.PushOutput</javaClass>
</codeDefinition>
<debugOutput>/scratch/jsmith/view_storage/tmp/bufferout.txt</debugOutput>
</stage>
</output-stages>
</pipeline>

D.3 処理ステージの実装

XMLドライバおよび複合ファイル・ドライバの事前または事後のデータ処理サポートは、3つの異なる方法で実装される可能性があります。

- Groovyコード
Groovyコードを構成XMLファイルに直接指定します。このGroovyコードはデータサーバー構成の一部で、再利用できません。Base64でエンコードされた文字列またはCDATAセクション内のプレーン・テキスト文字列としてGroovyコードを指定できます。

例は、D.7項「例: 構成XMLファイルに組み込まれたGroovyコード」を参照してください。

- Javaクラス
Javaクラスの完全修飾名を指定します。このJavaクラスは、実行時にODIエージェントのクラスパスで使用できる必要があります。

ODI Studioの場合、JARで作成され、USER_HOME/odi/oracledi/userlibディレクトリに配置される可能性があります。

スタンドアロンまたはコロケート・エージェントの場合、このJARをDOMAIN_HOME/libディレクトリに配置するか、スクリプトのいずれかを使用してクラスパスにコード化する必要があります。

JEEエージェントの場合、共有ライブラリとしてデプロイする必要があり、ODIエージェント・アプリケーションはこの共有ライブラリに依存する必要があります。

例は、D.6項「例: 認証を必要とするHTTPソースからデータを読み取るためのJavaクラス」を参照してください。

- Groovyスクリプト
Groovyスクリプトの名前を指定します。Javaクラスのすべての要件は、このGroovyスクリプトにも適用されます。例外として、MyGroovySource.groovyなどのスクリプトの名前を指定するか、/home/groupuser/name/MyCustomGroovy.groovyなどのスクリプトへの絶対パスを指定する場合があります。

前者の場合、ClassLoaderを使用してJavaクラス・リソースとしてスクリプトを参照します。クラス・リソースの通常のロケータ・パターンは、これに適用されます。たとえば、ファイルがJARにない場合、ファイル名を/MyGroovySource.groovyとして指定する必要があります。JARのサブディレクトリにある場合、ロケータは/com/foo/MyGroovySource.groovyになります。絶対パスを使用する場合、GroovyスクリプトはプレーンJavaファイルとしてアクセスされます。

例は、次の項を参照してください。

- D.4項「例: ZIPファイル内からXMLデータを読み取るためのGroovyスクリプト」

- D.5項「例: XMLデータを変換して異なる形式に書き込むためのGroovyスクリプト」

注意:
次の事項に注意してください。

- XMLドライバ・スキーマがドロップされないかぎり、組み込まれたGroovyコードまたは絶対パスを介して配置されたGroovyスクリプト・ファイルの変更は選択されません。Javaクラスまたはクラスパスを介して配置されたGroovyスクリプト・ファイルの場合、JVMを再起動して変更を選択する必要があります。

- インラインGroovyコード、GroovyスクリプトまたはJavaクラスは、パブリックAPIに示されているようにすべてJavaインタフェースに準拠する必要があります。ODIドライバは構成に設定されている順序で結果コードのチェーンを適用し、データが構成されているように複数のステージに流れます。

D.4 例: ZIPファイル内からXMLデータを読み取るためのGroovyスクリプト

ZIPファイル内からXMLデータを読み取るためのGroovyスクリプトの例は、次のとおりです。

例D-2 Groovyスクリプト: ZIPファイル内からのXMLデータの読取り

import java.io.IOException
import java.io.InputStream;
import java.util.Properties;
import java.util.logging.Logger;

import oracle.odi.jdbc.drivers.common.pipeline.api.Stage;
import oracle.odi.jdbc.drivers.common.pipeline.api.TerminalStreamInputStage;

class FileFromZip extends TerminalStreamInputStage {

public FileFromZip(Properties pStageProperties, String pDataserverUrl,
Properties pDataserverProperties, String pJavaEncoding,
Logger pLogger, String pDebugLocation, String pDebugEncoding, String pStageName) {

super(pStageProperties, pDataserverUrl, pDataserverProperties,
pJavaEncoding, pLogger, pDebugLocation, pDebugEncoding, pStageName);
}

@Override
public InputStream readSource() throws IOException {
def zipFile = new java.util.zip.ZipFile(new File(getStageProperties().get("ZIP_FILE")))
def zipEntry = zipFile.entries().find { !it.directory && getStageProperties().get("XML_FILE").equalsIgnoreCase(it.name)}
return zipFile.getInputStream(zipEntry)
}

@Override
public void close() throws IOException {
// TODO Auto-generated method stub

}

}

D.5 例: XMLデータを変換して異なる形式に書き込むためのGroovyスクリプト

XMLデータを変換して異なる形式に書き出すためのGroovyスクリプトの例は、次のとおりです。

例D-3 Groovyスクリプト: XMLデータの変換および異なる形式への書込み

package oracle.odi.jdbc.driver

import groovy.xml.MarkupBuilder;

import java.io.IOException;
import java.io.OutputStream
import java.util.Properties;
import java.util.logging.Logger;

import oracle.odi.jdbc.drivers.common.pipeline.api.JunctionStreamOutputStage;
import oracle.odi.jdbc.drivers.common.pipeline.api.Stage;

class TransformXmlOutput extends JunctionStreamOutputStage {

private OutputStream output

public TransformXmlOutput(Properties pStageProperties, String pDataserverUrl,
Properties pDataserverProperties, String pJavaEncoding, Logger pLogger, String pDebugLocation,
String pDebugEncoding, String pStageName) {
super(pStageProperties, pDataserverUrl, pDataserverProperties, pJavaEncoding, pLogger,
pDebugLocation, pDebugEncoding, pStageName);
}

@Override
public OutputStream writeOutput(OutputStream out) {
System.out.println("In TransformXmlOutput writeOutput")
def Writer w = new BufferedWriter(new OutputStreamWriter(out))
System.out.println("Created writer")
output = pipeInput { input ->
// Perform transformation
System.out.println("Piping")
def builder = new MarkupBuilder (w);
def cars = new XmlSlurper().parse(input)

System.out.println("Parsed XML")

builder.mkp.xmlDeclaration(version: "1.0", encoding: "utf-8")

builder.html(xmlns:"http://www.w3.org/1999/xhtml") {
head {
title "Cars collection"
}
body {
h1("Cars")
ul(){
cars.car.each{car ->
li(car.@name.toString() + "," + car.country + "," + car.description + ", Age: " + (2012 - car.@year.toInteger()) + " years")
}
}
}
}
w.flush()
System.out.println("Closing connectedStage")
closeConnectedStage();
}
}

@Override
public void close() throws IOException {
System.out.println("Closing TransformXmlOutput")
if(output!= null) {
output.flush();
output.close()
}
}

public static OutputStream pipeInput(Closure read) {

PipedInputStream input = new PipedInputStream()
PipedOutputStream output = new PipedOutputStream(input)
getThreadsSource.submit {
try{
read(input)
} catch (Exception e) {
System.out.println("Exception in thread")
e.printStackTrace();
throw e;
} finally {
output.flush()
}
}
return output
}
}

D.6 例: 認証を必要とするHTTPソースからデータを読み取るためのJavaクラス

認証を必要とするHTTPソースからデータを読み取るためのJavaクラスの例は、次のとおりです。

例D-4 Javaクラス: 認証を必要とするHTTPソースからのデータの読取り

/**
*
*/
package oracle.odi.jdbc.driver.xml;

import java.io.ByteArrayInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.net.URL;
import java.net.URLConnection;
import java.util.Properties;
import java.util.logging.Logger;

import oracle.odi.jdbc.drivers.common.pipeline.api.TerminalStreamInputStage;

/**
* @author jsmith
*
*/
public class FromHttpBasicAuthJava extends TerminalStreamInputStage {

/**
* @param pStageProperties
* @param pDataserverUrl
* @param pDataserverProperties
* @param pJavaEncoding
* @param pLogger
* @param pDebugLocation
* @param pDebugEncoding
* @param pStageName
*/
public FromHttpBasicAuthJava(Properties pStageProperties, String pDataserverUrl,
Properties pDataserverProperties, String pJavaEncoding,
Logger pLogger, String pDebugLocation, String pDebugEncoding,
String pStageName) {
super(pStageProperties, pDataserverUrl, pDataserverProperties,
pJavaEncoding, pLogger, pDebugLocation, pDebugEncoding,
pStageName);
}

/* (non-Javadoc)
* @see oracle.odi.jdbc.drivers.common.pipeline.api.TerminalStreamInputStage#readSource()
*/
@Override
public InputStream readSource() throws IOException {
String username = (String)(getStageProperties().get("username"));
String password = (String)(getStageProperties().get("password"));
byte[] credential = org.apache.commons.codec.binary.Base64.encodeBase64(
(username + ":" + password).getBytes());

//pass encoded user name and password as header
URL url = new URL ("http://localhost:18000/get");
URLConnection conn = url.openConnection();
conn.setRequestProperty ("Authorization", "Basic " + new String(credential));
urlStream = conn.getInputStream();
StringBuilder result = new StringBuilder();
byte[] read;
int bytesRead;
while(true) {
read = new byte[1024];
if((bytesRead = urlStream.read(read)) == -1) {
break;
} else
result.append(new String(read, 0, bytesRead));
}

return new ByteArrayInputStream(result.toString().getBytes());
}

/* (non-Javadoc)
* @see oracle.odi.jdbc.drivers.common.pipeline.api.Stage#close()
*/
@Override
public void close() throws IOException {
if(urlStream != null)
urlStream.close();
}

private InputStream urlStream = null;
}

D.7 例: 構成XMLファイルに組み込まれたGroovyコード

Base64文字列として組み込まれたGroovyコードを使用した構成XMLの例は、次のとおりです。

例D-5 Base64文字列として組み込まれたGroovyコードを使用した構成XMLファイル

<?xml version="1.0" encoding="UTF-8"?>

<pipeline xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="pre-post.xsd">

<input-stages>
<io-stage name="fromZip">
<codeDefinition>
<code>
CgppbXBvcnQgamF2YS5pby5JT0V4Y2VwdGlvbgppbXBvcnQgamF2YS5pby5JbnB1dFN0cmVhbTsKaW1wb3J0IGphdmEudXRpbC5Qcm9wZXJ0aWVzOwppbXBvcnQgamF2YS51dGlsLmxvZ2dpbmcuTG9nZ2VyOwoKaW1wb3J0IG9yYWNsZS5vZGkuamRiYy5kcml2ZXJzLmNvbW1vbi5waXBlbGluZS5hcGkuU3RhZ2U7CmltcG9ydCBvcmFjbGUub2RpLmpkYmMuZHJpdmVycy5jb21tb24ucGlwZWxpbmUuYXBpLlRlcm1pbmFsU3RyZWFtSW5wdXRTdGFnZTsKCmNsYXNzIEZpbGVGcm9tRnJvbVppcCBleHRlbmRzIFRlcm1pbmFsU3RyZWFtSW5wdXRTdGFnZSB7CgoJcHVibGljIEZpbGVGcm9tRnJvbVppcChQcm9wZXJ0aWVzIHBTdGFnZVByb3BlcnRpZXMsIFN0cmluZyBwRGF0YXNlcnZlclVybCwKCQkJUHJvcGVydGllcyBwRGF0YXNlcnZlclByb3BlcnRpZXMsIFN0cmluZyBwSmF2YUVuY29kaW5nLAoJCQlMb2dnZXIgcExvZ2dlciwgU3RyaW5nIHBEZWJ1Z0xvY2F0aW9uLCBTdHJpbmcgcERlYnVnRW5jb2RpbmcsIFN0cmluZyBwU3RhZ2VOYW1lKSB7CgkJc3VwZXIocFN0YWdlUHJvcGVydGllcywgcERhdGFzZXJ2ZXJVcmwsIHBEYXRhc2VydmVyUHJvcGVydGllcywKCQkJCXBKYXZhRW5jb2RpbmcsIHBMb2dnZXIsIHBEZWJ1Z0xvY2F0aW9uLCBwRGVidWdFbmNvZGluZywgcFN0YWdlTmFtZSk7Cgl9CgoJQE92ZXJyaWRlCglwdWJsaWMgSW5wdXRTdHJlYW0gcmVhZFNvdXJjZSgpIHRocm93cyBJT0V4Y2VwdGlvbiB7CgkJZGVmIHppcEZpbGUgPSBuZXcgamF2YS51dGlsLnppcC5aaXBGaWxlKG5ldyBGaWxlKGdldFN0YWdlUHJvcGVydGllcygpLmdldCgiWklQX0ZJTEUiKSkpCgkJZGVmIHppcEVudHJ5ID0gemlwRmlsZS5lbnRyaWVzKCkuZmluZCB7ICFpdC5kaXJlY3RvcnkgJiYgZ2V0U3RhZ2VQcm9wZXJ0aWVzKCkuZ2V0KCJYTUxfRklMRSIpLmVxdWFsc0lnbm9yZUNhc2UoaXQubmFtZSl9CgkJcmV0dXJuIHppcEZpbGUuZ2V0SW5wdXRTdHJlYW0oemlwRW50cnkpCgl9CgoJQE92ZXJyaWRlCglwdWJsaWMgdm9pZCBjbG9zZSgpIHRocm93cyBJT0V4Y2VwdGlvbiB7CgkJLy8gVE9ETyBBdXRvLWdlbmVyYXRlZCBtZXRob2Qgc3R1YgoKCX0KCn0K
</code>
</codeDefinition>
<props>
<property name="ZIP_FILE">/home/myuser/files/personal.zip</property>
<property name="XML_FILE">personal.xml</property>
</props>
</io-stage>
</input-stages>
</pipeline>