Oracle BIサーバーとOracle BIリポジトリのアーキテクチャについて

Oracle BIサーバーとOracle BIリポジトリのアーキテクチャによって、ユーザーが複雑なフェデレーテッド・データ・ソースに対する単純な論理SQL問合せを送信できる抽象化のレイヤーが提供されます。

この項では、次の項目について説明します。

Oracle BIサーバーのアーキテクチャについて

Oracle BIサーバーは、Oracle Business Intelligenceのコンポーネントであり、基礎となるデータ・ソースのユーザー・リクエストと問合せを処理します。

Oracle BIサーバーは、論理データ・モデルを維持し、そのモデルへのODBC接続またはネイティブAPI (Oracle DatabaseのOCIなど)を使用したアクセスをクライアントに提供します。

Oracle BIサーバーでは、Oracle BIリポジトリ内のメタデータを使用して、次の2つのタスクを実行します。

論理SQL問合せを解析し、適切なデータ・ソースに対する対応する物理問合せを作成します。
物理結果セットを変換および結合し、最終的な計算を実行します。

管理ツール・クライアントは、Oracle BIリポジトリの作成や編集に使用できるWindowsアプリケーションです。管理ツールは、オフライン・モードでリポジトリに直接接続することも、Oracle BIサーバーを経由してリポジトリに接続することもできます。オンライン・モードで使用できるのは一部のオプションのみです。詳細は、オンラインとオフラインのリポジトリ・モードの使用を参照してください。

この図は、Oracle BIサーバーが問合せクライアント、データ・ソース、Oracle BIリポジトリおよび管理ツールとどのように連携するかを示しています。

GUID-81B2D421-2EAA-4F22-811F-9BE7803CF0C2-default.gifの説明が続きます。

図GUID-81B2D421-2EAA-4F22-811F-9BE7803CF0C2-default.gifの説明

この例は、Oracle BIサーバーが論理SQL問合せをどのように解析および変換するかを示しています。

論理リクエストから複雑な物理問合せへの変換

Oracle BIサーバーが次の単純なクライアント・リクエストを受け取るとします。

SELECT
"D0 Time"."T02 Per Name Month" saw_0,
"D4 Product"."P01 Product" saw_1,
"F2 Units"."2-01 Billed Qty (Sum All)" saw_2
FROM "Sample Sales"
ORDER BY saw_0, saw_1

Oracle BIサーバーはその後、次のように論理SQL問合せを高度な物理問合せに変換します。

WITH SAWITH0 AS (
select T986.Per_Name_Month as c1, T879.Prod_Dsc as c2,
   sum(T835.Units) as c3, T879.Prod_Key as c4
from
   Product T879 /* A05 Product */ ,
   Time_Mth T986 /* A08 Time Mth */ ,
   FactsRev T835 /* A11 Revenue (Billed Time Join) */
where ( T835.Prod_Key = T879.Prod_Key and T835.Bill_Mth = T986.Row_Wid)
group by T879.Prod_Dsc, T879.Prod_Key, T986.Per_Name_Month
)
select SAWITH0.c1 as c1, SAWITH0.c2 as c2, SAWITH0.c3 as c3
from SAWITH0
order by c1, c2

Oracle BIリポジトリのレイヤーについて

Oracle BIリポジトリのレイヤーにより、オブジェクトとその関係が定義されます。

Oracle BIリポジトリには次のレイヤーがあります。

物理レイヤー。このレイヤーでは、Oracle BIサーバーが各物理データ・ソースに対するネイティブな問合せを作成するために必要とするオブジェクトとリレーションシップが定義されます。このレイヤーを作成するには、データ・ソースから表、キューブおよびフラット・ファイルをインポートします。

アプリケーションの論理動作を物理モデルから切り離すと、複数の物理ソースを同じ論理オブジェクトにフェデレートできるため、集計ナビゲーションやパーティション化のほか、ディメンションの適合や物理ソース内の変更からの分離が可能になります。また、この分離によって、ポータブルなOracle BIアプリケーションの作成も可能になります。
ビジネス・モデルとマッピング・レイヤー。このレイヤーでは、データのビジネス・モデルまたは論理モデルが定義され、ビジネス・モデルと物理スキーマ間のマッピングが指定されます。このレイヤーによって、ユーザーから見える分析動作が決まり、ユーザーが使用できるオブジェクトおよびリレーションシップのスーパーセットが定義されます。ソース・データ・モデルの複雑さも認識されなくなります。

ビジネス・モデルの各列は、物理レイヤーの1つ以上の列にマップします。実行時に、Oracle BIサーバーがビジネス・モデルに対する論理SQL問合せを評価し、マッピングを使用して、必要な物理問合せを生成するための物理表、ファイルおよびキューブの最適なセットを決定します。多くの場合、マッピングには計算と変換が含まれ、複数の物理表が結合されることがあります。
プレゼンテーション・レイヤー。このレイヤーは、カスタマイズされた、ロール・ベースのセキュアなビジネス・モデルのビューをユーザーに表示する方法を提供します。また、ビジネス・モデルとマッピング・レイヤーに抽象化のレベルを加え、プレゼンテーション・サービスやその他のクライアントでリクエストを作成するユーザーに表示されるデータのビューを提供します。

1つのビジネス・モデルにマップする複数のサブジェクト・エリアをプレゼンテーション・レイヤーに作成することで、ビジネス・モデルを管理可能な部分に効果的に分割できます。

管理ツールでリポジトリのレイヤーを作成する前に、ユーザーの分析要件に基づいて、ビジネス・モデルとマッピング・レイヤーの大まかな設計を作成しておくことが重要です。作業の指針となる概念設計を作成したら、メタデータ・オブジェクトを作成できます。

通常は、物理レイヤー、ビジネス・モデルとマッピング・レイヤー、プレゼンテーション・レイヤーの順にオブジェクトを作成します。ただし、どの段階でも各レイヤーの作業を行うことができます。3つのレイヤーがすべて完成したら、リポジトリのテストを開始する準備をする際に、セキュリティを設定できます。

この図は、論理SQL問合せがどのようにOracle BIリポジトリのレイヤーを通過するかを示しています。

GUID-6769CC4C-C435-4838-8EAB-42200F36E8B7-default.gifの説明が続きます。

図GUID-6769CC4C-C435-4838-8EAB-42200F36E8B7-default.gifの説明

単一のOracle BIリポジトリには、エンタープライズ全体の1つの統合モデルではなく、複数の独立セマンティック・モデルを格納できます。セマンティック・モデルは、1つのビジネス・モデル、プレゼンテーション・レイヤーと物理レイヤー内の関連オブジェクト、および変数、初期化ブロック、アプリケーション・ロールのようなその他の関連オブジェクトで構成されます。セマンティック・モデルは、共通エンタープライズ情報モデルとも呼ばれます。

複数のセマンティック・モデルのビジュアル表示は、マルチユーザー開発のスタイルについてを参照してください。