 |
||||||||||||||||
|
||||||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||||||
|
||||||||||||||||
| 開発者にとってのBIツール統合化によるメリット | ||||||||||||||||
|
開発者にとってのメリットとして、各ベンダー共通に見られる項目にはメタデータ統合があります（表3）。これには、分析モデルの作成／レポートの開発／KPI評価基準の設定といった、一連のBIアプリケーション開発に必要なデータの種類や構造、属性を統合化されたBIツール全体で共有するというものです。
表3：各社のメタデータ統合 この統合により、データソースに変更があっても、作成済みのレポートをそのまま継続して利用できる、あるいは新規の分析モデルの作成に既存の分析モデルを部品化して再利用するといったことが可能になります。 BIツールは、業務アプリケーションと異なり、短いサイクルでアプリケーションを変更・拡張していくスパイラル・アプローチでの開発が理想とされています。しかしそのためには、アプリケーションの変更・拡張における生産性の問題の解決が重要な課題となってきました。 メタデータ統合は、開発者に対してスパイラル・アプローチの採用を促し、より満足度の高いBIツールの開発に効果があると期待されます。 しかしメタデータ統合のアプローチにも、各社の間では特徴的な違いがみられます。その中でもオラクルとビジネスオブジェクツは、セントラル・データウェアハウスを重視し、ETLツールにメタデータ統合の重要な役割を与えています。 図3は「第2回：データを中心に統合化するOracle」で使用されたオラクルのETLツールOracle Warehouse Builder 10gの図です。この図の特徴的なところは、メタデータだけではなく、ETL処理ロジックまですべての要素がOracle Databaseの中に物理的に格納される点です。  図3：Oracle Warehouse Builder 10g（再掲） （画像をクリックすると別ウィンドウに拡大図を表示します） オラクルのビジネスの中心がデータベースである以上、当然のアプローチといえますが、Oracle Warehouse Builder 10gで開発するETL処理はPL/SQLプログラムとして、データ構造はOracle Databaseの物理スキーマとして、分析モデルはOracle DiscovererのEnd User Layerとして、直接生成することができます。 従ってOracle Databaseのユーザであれば、既存の技術やスキルの延長線上でメタデータ統合のメリットを得られるという考え方がオラクルの特徴であり、同時に主要な差別化の項目となっています。 図4は「第5回：End To Endの包括的なBI・EPMを提供するBusinessObjects XI」で使用されたビジネスオブジェクツのメタデータ統合の図です。この図の特徴的なところは、ETLツールとBIツールの間でメタデータを共有することで実現しようとしていることです。またオラクルと異なり、メタデータを物理的なデータベースに依存しない論理的なレベルで管理するようになっています。  図4：信頼できる情報はEnd to Endの統合から（再掲） ビジネスオブジェクツは、今回の連載に登場したベンダーの中で唯一、ETLモジュールを独立した製品として販売しています。その上オラクルとは異なり、自社のデータベース製品は持ちません。このような製品構成からくる特徴として、物理的なデータベースには依存しないETLツールとBIツール間の密接な連携によるメタデータ統合を行っています。 従ってビジネスオブジェクツは、セントラル・データウェアハウスを構築した上で、データ構造の整備・保守を優先したBIアプリケーションの開発・拡張を求めるユーザ企業を主要なターゲットとして、統合化を行っていると考えられます。 |
||||||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
-
-
連載
