弁財天

ゴフマン「専門家を信じるのではなく、自分自身で考えて判断せよ」

メタデータ変換アシスタント(Oracle Discoverer Metadata Conversion Assistant) update2

さて、Oracle Discoverer Metadata Conversion Assistantを評価する話が来た。

ちらっと見てあぁダメだーと思ってしまったわけだけど、その理由を書いておく。
移行ツールがエキスポートファイル(.eex)を入力にしてるとこだ。

このエキスポートファイル(.eex)てオレも最初使えるかと思ったんだよね。しかし驚くことなかれ現行システムは(.eex)へエキスポートしようとする無限ループしてハングアップするのだ。

まぁ、要するに前のベンダーから貰った時点で壊れていたのだ。 文字化けしてる列項目があっておかしいとは思っていたんだよね。 定義が壊れてるのか、それとも文字化けのような壊れた定義がエキスポートを暴走させるのかは不明だ。

これが現在EUL5表を解析しようなどという無茶な方法を試みている理由なのだよ。

まぁ、しかしこのページは、どの機能や仕様が問題になるのか非常に手がかりになったぞw

オプション 説明
CreateAggregatedCols

TRUE:メジャー列に対し、 SUM 、 MIN 、 MAX 、 AVG、 COUNTなどの集計に関する列が作成されます。
FALSE:メジャー列における集計対象の列が、EULのデフォルトの集計プロパティ・セットに基づいて作成されます。 (詳細については、『 Oracle Business Intelligence Discoverer管理ガイド』を参照してください。)

集計の選択についてOracle Discovererと同様の操作性をエンドユーザーに提供するには、このオプションを使用して、Oracle Discovererでサポートされているデフォルトの集計それぞれに対する個別の列を論理レイヤー内に作成します。 この値を TRUEに設定すると、メタデータの移行時に、Oracle Discovererでサポートされている集計すべてが生成されます。 FALSEに設定した場合は、Oracle Discovererの DEFAULT AGGREGATIONで設定された集計ファンクション・セットにより列が作成されます。

CreateSeperateRPDs

TRUE:ビジネス・エリアごとに個別のリポジトリが生成されます。
FALSE:すべてのビジネス・エリアが、単一のリポジトリに移行されます。

ExcludeJoins 移行時にスキップされる JOIN_IDについてのカンマ区切りリストが作成されます。
ConsiderMultiplePaths TRUE:移行アシスタントにおいて、通常は移行時にスキップされる結合への対応が可能となります。
FALSE:移行アシスタントでは、移行時にスキップされる結合に対応できません。
IncludePathsForFolders

これは、スキップ対象の結合のうち、移行時に対応できるようにする必要のある各結合についての folder_idが含まれたカンマ区切りリストです(このIDは <Filename >.exceptionログで確認できます)。 このオプションは ConsiderMultiplePaths = FALSEとあわせて使用します。

ConsiderMultiplePaths = TRUEの場合は、 ExcludeJoinsプロパティで設定されている結合を除き、スキップ対象の結合すべてが考慮されます。

接続プール・パラメータ

DataSourceName、Username

注:Passwordパラメータは含まれません。 このパラメータについては、セキュリティの確保と維持のため、移行後に入力する必要があります。

MigrationConfig.propertiesファイルの例:

Oracle Discoverer Oracle BI EE
EUL

Oracle BI EEメタデータ・リポジトリ( .rpd)ファイルにマッピングされます。

ビジネス・エリア Presentation Catalog(Oracle BI Answersではサブジェクト・エリアとも呼ばれる)にマッピングされます。
シンプル・フォルダ データベースの表またはビューにマッピングされます。 つまり、各単一フォルダは、Physicalレイヤーの物理表、Business Model and Mappingレイヤーの論理表、およびPresentationレイヤーのプレゼンテーション表に移行されることになります。 Oracle Discovererのユーザーに対して表示されるように設定されている表については、Presentationレイヤーへの移行のみがおこなわれます。
複合フォルダ

複数のシンプル・フォルダからのアイテムが結合されます。 複合フォルダを説明する場合によく取り上げられるのが、データベース・ビューのフォルダとよく似ているという点です。 Oracle Discovererの管理という観点からいえば、複合フォルダは、エンドユーザーのメタデータ・ビューを簡易化するために、アイテムを論理グループにまとめる場合に役立ちます。 エンドユーザーの側から見ると、1つのフォルダを開くだけでレポートに必要なアイテムすべてを取得できるため、タスクが簡単になるという利点があります。

複合フォルダは、論理レイヤー内の論理表にマッピングされます。各論理表には、ベース・フォルダと各ベース・フォルダ間の結合が含まれた論理表ソースがあります。 マッピングされた複合フォルダは、これらのベース・フォルダ(ディメンション)に結合されます。 Presentationレイヤーで表示される複合フォルダには、以下のようなマッピングが使用されます。

複合フォルダにおけるアイテムの参照は、論理レイヤーの対応するベース・フォルダから取得されます。

複合フォルダ内でOracle Discovererの管理計算を作成する場合、その複合フォルダに相当する論理表が論理レイヤーに作成されます。 複数の実表からのアイテムが含まれた計算が作成されると、該当する論理フォルダはPresentationレイヤーに移行されます。 ただし、単一のベース・フォルダに基づいておこなわれた管理計算については、対応する論理フォルダに移行され、複合フォルダには移行されません。

注:別の複合フォルダのアイテムに基づく複合フォルダは、自動的に移行することはできません。

カスタム・フォルダ フォルダの作成における柔軟性が向上します( UNION 、 INTERSECT 、 および MINUSなどの集合演算子を使用したSQL文の作成など)。 カスタム・フォルダを作成するためにUIにSQL文を入力すると、SQL文で参照されるアイテムが含まれたフォルダが作成されます。 Oracle BI EEでは、カスタム・フォルダは、 SELECTの許可された表タイプを使用してPhysicalレイヤーに移行されます。 これは、OPAQUEビューとも呼ばれています。
アイテム

問合せを構築する基本的な要素です。 各アイテムは、データベース表/ビューの列にマッピングされるか、またはOracle Discoverer Administratorにおける計算から作成されます。 この計算は、PL/SQLファンクションに基づいておこなうことができます。

Oracle Discovererのアイテムは、Oracle BI EEのPhysicalレイヤー内にある物理列、Business Model and Mappingレイヤー内の論理列、およびPresentationレイヤー内のプレゼンテーション列に移行されます。 エンドユーザー対して非表示となっているアイテムは、Presentationレイヤーでは表示されません。

Oracle Discovererで問合せを作成する場合、エンドユーザーは、各アイテムに対するデフォルトの集計を選択するか、使用可能な集計ファンクションのリストから選択できます。 Oracle BI EEメタデータでは、論理レイヤー内の特定の列に対してデフォルトの集計を指定できますが、指定した集計は、Oracle BI Answersワークシートの作成時に(Oracle Discovererと同じ方法で)変更できません。 この場合は、別の列を作成し、必要な集計を定義する必要があります。

Oracle PL/SQLファンクションまたはOracle分析ファンクションに基づいてOracle Discovererで計算されたアイテムは、Oracle BI EEメタデータに移行されます。このメタデータでは EVALUATEファンクションと EVALUATE_AGGRファンクションが使用されています。 これらの計算については、論理表ソースの物理マッピングで設定されている計算式を使用して、論理列として作成されます。

結合

問合せを作成するために使用されるフォルダ間の関係を定義します。 結合の定義は、通常、基盤となるデータベース・オブジェクトに対応するキー列を使用しておこなわれます。 Oracle DiscovererとOracle BI EE間のメタデータ・モデルには相違点があるため、結合タイプに違いがあっても自動的な移行が可能な場合もあります。 メタデータのこの領域では、Oracle DiscovererとOracle BI EEのメタデータの違いが明らかとなります。

この2つのおもな相違点は、Oracle Discovererでは、論理的なBusiness Model and Mappingレイヤーが1つ以上のスター・スキーマ・モデル(データウェアハウス設計用の一般的なデータ・モデル)に基づいている必要があるという点です。 スター・スキーマ・モデルの変形版として、スノーフレーク・モデルがよく知られています。このモデルでは、通常、ディメンションの階層レベルが個別の表として示されます。 この場合、移行アシスタントでは、ファクト表のスノーフレーク・ディメンションは最下位レベルのディメンションまでが閉じられています。

Physicalレイヤーは、スター・スキーマではモデル化する必要はないため、Oracle Discovererメタデータからの結合情報を使用して作成されます。

 必須条件

ほかのフォルダに対する複数の結合パスが含まれているOracle Discovererフォルダについては、同一の基本物理オブジェクトに基づいてオブジェクトの別名を作成することで対応できますが、代替の結合パスが必要となります。

 重複結合 Oracle Discovererのメタデータに重複結合に関する定義がある場合は、Oracle Discovererで作成される重複結合のうちの1つだけが移行時の考慮対象となります。 ただし、検出された重複結合は、すべて移行ログ・ファイルに記録されます。

 

条件

メタデータの条件を作成できます。 条件には、必須とオプションの2つがあります。 必須条件は問合せ可能なデータを制限する効果があり、エンドユーザー対しては表示されません。 オプション条件については、エンドユーザーの必要に応じて定義できます。SQL構文に精通していないユーザーでも、使用可能な条件のリストから各自のレポートにドラッグすることで、事前定義された条件(レポートに複雑なロジックを含める条件など)をオプションとして使用できます。

 必須条件

変換は、フォルダのタイプに基づいておこなわれます。 シンプル・フォルダとカスタム・フォルダの場合、必須条件は論理表ソースの WHERE句セクションにおける"コンテンツ・フィルタ"として移行されます。 複合フォルダの場合は、すべてのユーザーがOracle BI EEグループ EVERYONEに移行されるため、複合フォルダに関する必須条件は、このユーザー・グループに対する"セキュリティ・フィルタ"として適用されます。

 オプション条件

現時点では移行できません。

注:将来的には、ワークブックの移行を実現する際に、オプション条件がWeb Catalogの"保存済フィルタ"として永続化されるようにすることを予定しています。

集計計算対象のアイテム Oracle BI EEで使用可能な EVALUATEファンクションの1種を使用して移行されます。
アイテム階層

エンドユーザーに対して関連データ全体のドリル・パスを提供するもので、Oracle BI EEディメンションに移行されます。 Oracle Discovererのアイテム階層におけるレベルは、関連するディメンション・レベルに移行されます。

複数の階層に対するドリル・パスは、Oracle BI EEのディメンション・レベル・プロパティにおける優先ドリル・パス・プロパティのエントリに移行されます。 単一のフォルダに基づく階層はすべて、そのフォルダで作成された単一のディメンションに移行されます。 複合フォルダに基づくアイテム階層は移行されません。これは、Oracle BI EE内のディメンションはディメンション表に関連づけられている必要があるためです。 複数の表にまたがる階層については、優先ドリル・パスを適宜設定することで移行されます。

注:アイテム・クラスとサマリー・フォルダは移行されません。

Oracle Discovererの"テンプレート"日付階層については、Oracle BI EE内に対応するオブジェクトがありません。そのため、実際の階層のみがOracle BI EEのディメンションに移行されます。

現在のディスカバラ10.1.2.3 CP7+だっけか?はサポートが終了してる。その.eexエキスポートが日本ローカルな文字化け問題で無限ループしてるのか、定義自体が壊れてしまっているのかはもはや不明て誰もサポートできないだろう。

Oracle社側の話はともかく、この状況は次期環境にWebLogic+BIEE(11.1.1.7+)を採用できないことを意味している。 業務アプリはTomcaやJBossでも動作するだろう。ディスカバラーが問題だったのだ。

なので、OracleにはEUL5表の情報だけで、サーバーサイドで「そこそこ」移行できるツールをつくってほすい。

なぜかできなかったはずのeexフルエキスポートができるようになったので評価作業を再開。

Oracle Discoverer Metadata Conversion Assistant(MigrateEUL.exe)の評価である。 ここ

Oracle Business Intelligence Developer Client Tools Installer (11.1.1.7.0)
Download for Microsoft Windows x86 (32-bit): (182M) (cksum 1549113500)
ここ

…\Oracle Business Intelligence Enterprise Edition Plus Client Tools\oraclebi\orahome\bidoundation\server\bin\MigrateEUL.exe に導入される単発のバッチ.exe w

さっそく実行。

L:¥eex_export>c:MigrateEUL.exe フルエクスポート.eex

        Oracle BI SE - EE Migration Assistant    Version 11.1.1.2.8


Reading Configuration File...

Error reading configuration !!! Reverting to defaults...[DONE]

Parsing EUL export file L:¥eex_export¥フルエクスポート.eex...[DONE]


Repository creation started...


Processing Business Area : 共通....[DONE]

Processing Business Area : ほげ....[DONE]

Processing Business Area : ほげ....[DONE]

Processing Business Area : ほげ....[DONE]

Processing Business Area : ほげ....[DONE]

Processing Business Area : ほげ....[DONE]

Processing Business Area : ほげ....[DONE]

Processing Business Area : ほげ....[DONE]

Processing Business Area : The Discoverer V5 EUL....[DONE]

All Business Area(s) processed


        The migrated repository is saved at L:¥eex_export¥フルエクス
ポート.rpd

        Migration log is saved at L:¥eex_export¥フルエクスポート.migr
ation.log


                ------------------------------------------
                        EUL MIGRATION SUCCESSFUL
                ------------------------------------------



L:¥eex_export>
L:¥eex_export>ls -ltr
total 251632
drwxr-xr-x 1 Administrator なし         0 Oct 28 15:55 check
-rw-r--r-- 1 Administrator なし    144347 Oct 28 15:55 エクスポートログ.txt
-rw-r--r-- 1 Administrator なし 244385866 Oct 28 15:57 フルエクスポート.eex
-rw-r--r-- 1 Administrator なし         0 Oct 31 11:37 フルエクスポート.rpd
-rw-r--r-- 1 Administrator なし   9087932 Oct 31 11:46 フルエクスポEチErpd
-rw-r--r-- 1 Administrator なし   3373292 Oct 31 11:46 EntityMapping.txt
-rw-r--r-- 1 Administrator なし    574081 Oct 31 11:46 フルエクスポート.migratio
n.log
-rw-r--r-- 1 Administrator なし     78465 Oct 31 11:46 フルエクスポート.exceptio
n.log
-rw-r--r-- 1 Administrator なし       222 Oct 31 11:46 フルエクスポート.rpd.Log

L:¥eex_export>

00_ほげ項マスタ and 00_ほげ款マスタ share more than one COMMON DIMENSION(S)

** CASE OF MULTIPLE COMMON DIMENSIONS b/w 00_ほげ項マスタ and 00_ほげ款マスタ Join : 00_ほげ款マスタ -> 00_ほげ項マスタ has been skipped for folder 00_ほげ項マスタ

うーむ。JOIN条件がことごとくエラーになって移行できない。

*** Join : ほげ表 -> 01_ほげ cannot be created!!!
Physical Join is based on ほげ表.ほげ区分 which is a Calculation that cannot be migrated to the Physical Layer!!!

** Skipping Join : ほげ -> ほげ : ほげ.ほげ区分 と ほげ.ほげ区分 間の結合 The folder ほげテーブル is already linked to ほげマスタ. Circular References cannot be migrated!!!

うーむ。現行アプリのディスカバラーの定義が論理矛盾してて移行できないw

このマイグレーション・ツールはフォルダーだけのマイグレーションで、その上位のワークシートは自分で移行しなければならない。しかしそのフォルダーですらまともに移行できないのか。うむむ。これでは1円入札されても、ちょっと考えてしまいますな。

投稿されたコメント:

コメント
コメントは無効になっています。