リポジトリ設計のガイドライン

ビジネス・モデルのニーズを分析し、ビジネスに必要なデータベース・コンテンツを特定したら、リポジトリの設計を行うことができます。

この項では、より効率的なリポジトリを実装するために役立つ設計のベスト・プラクティスを紹介します。

データベースをインポートしてテストするまで、パフォーマンス・チューニングに変更を加えないでください。パフォーマンス・チューニングの作業は、リポジトリの設定を完了する最終段階で実行します。これらの最終手順の詳細は、Oracle BIリポジトリの設定の完了を参照してください。

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

リポジトリに関する作業の全般的なヒント

BIリポジトリを構成する際には、次の設計方針に従うことをお薦めします。

オンライン・モードで作業する場合、1つの作業が完了するたびに作業の前後にオンライン・リポジトリのバックアップを保存します。必要に応じて、「ファイル」メニューの「名前を付けてコピー」を使用して、変更内容を含むオフライン・コピーを作成してください。
管理ツールの物理図を使用して、ソースと結合を確認します。
データベースとリポジトリのどちらで行レベルのセキュリティ制御を設定するかを決定します。この決定によって、接続プールとキャッシュを共有するかどうかが決まります。また、開発に含める個々のソース・データベースの数が制限される場合があります。詳細は、リポジトリ・オブジェクトへのデータ・アクセス・セキュリティの適用を参照してください。

管理ツールのほとんどの図には、作業の実行方法に関する情報を提供するヘルプが用意されています。ヘルプ・トピックにアクセスするには、ダイアログで「ヘルプ」ボタンをクリックするか、一部のメニューから「ヘルプ」を選択します。

物理レイヤーを設計する際のヒント

物理レイヤーには、物理データ・ソースに関する情報が格納されます。

物理レイヤーでスキーマを作成する際の最も一般的な方法は、データベースなどのデータ・ソースからメタデータをインポートする方法です。メタデータをインポートすると、インポート・プロセスで収集された情報に基づいて、多くのプロパティが自動的に構成されます。また、データ・ソースのメタデータには存在しない場合がある、物理データ・ソースの他の属性(結合関係など)を定義することもできます。

物理レイヤーには、マルチディメンション、リレーショナル、XMLソースなど、様々なタイプのデータ・ソースを含めることができます。サポートされるデータベースは、システム要件と動作要件を参照してください。

データ・ソースごとに、対応する接続プールが少なくとも1つずつあります。接続プールには、データ・ソースへの接続に使用されるデータ・ソース名(DSN)、許可される接続の数、タイムアウトなど、接続関連の詳細な管理情報が格納されています。詳細は、接続プールについてを参照してください。

物理レイヤーを設計する際のヒントは次のとおりです。

物理レイヤーでは表の別名を頻繁に使用して、次のような無関係な結合を削除することをお薦めします。
- 別名を使用することによって、複数のディメンションにまたがる物理結合(ディメンション間の循環結合)をすべて削除します。
- 物理表の別名を作成することによって、物理モデルの論理表ソースにおける循環結合(ディメンション間の循環結合)をすべて削除します。
  
  たとえば、出荷先住所の参照に使用できるCustomer表があり、別の結合を使用して請求先住所を参照できるとします。循環結合を避けるには、それぞれの結合で、用途ごとに1つのインスタンスが存在するように物理レイヤーに別名表を作成します。
循環結合を削除しなかった場合、レポート結果が正しくなくなることがあります。さらに、問合せのパフォーマンスが低下する可能性もあります。
ある論理表ソースでは結合を内部結合にし、別の論理表ソースでは外部結合にする必要がある場合は、別名表を使用して別の物理結合を作成することをお薦めします。
すぐには使用しないものの、削除はしたくない表を物理レイヤーにインポートできます。ビジネス・モデルとマッピング・レイヤーですぐに使用しない表を特定するには、物理表に別名を割り当ててから、ビジネス・モデル・レイヤーにマップします。

注意:
別名を割り当てた表の名前を表示するには、「ツール」→「オプション」→「一般」で「図の別名に対する元の名前の表示」を選択します。
不透明なビュー(1つのSELECT文で構成される物理レイヤー表)を使用するのは、モデリングの問題に対する解決策がそれ以外にない場合のみにしてください。物理表、またはマテリアライズド・ビューを作成することをお薦めします。不透明なビューには、基礎となるデータ・ソースに送信される固定されたSQL文が含まれるため、Oracle BIサーバーは、最適化された独自のSQLを生成できません。

ビジネス・モデルとマッピング・レイヤーを設計する際のヒント

ビジネス・モデルとマッピング・レイヤーでは、ビジネス・モデルによって情報が編成されます。このレイヤーでは事実上、各ビジネス・モデルが別個のアプリケーションとなります。

各ビジネス・モデルで定義された論理スキーマには、論理表を少なくとも2つ含める必要があります。すべての論理表間の関係を定義する必要があります。ビジネス・モデルのスキーマの詳細は、Oracle BIリポジトリのレイヤーについてを参照してください。ビジネス・モデルとマッピング・レイヤーの設定の詳細は、論理表、論理結合および論理列での作業を参照してください。

「ビジネス・モデルとマッピング」レイヤーの設計時には、次のヒントを使用してください。

可能であれば、論理ディメンション表とファクト表間に1対多の論理結合を持つビジネス・モデルを作成します。各ファクト表がそのディメンションに直接結合される単純なスター・スキーマのようなビジネス・モデルを作成してください。
すべての論理ファクト表を少なくとも1つの論理ディメンション表に結合する必要があります。ソースが完全非正規化表またはフラット・ファイルである場合は、その物理ファクト列を1つ以上の論理ファクト表にマップし、その物理ディメンション列を論理ディメンション表にマップする必要があります。
すべての論理ディメンション表にディメンション階層が関連付けられている必要があります。シナリオ・ディメンション(実績、予測、計画)のように階層のレベルが1つだけの場合でも、このルールが適用されます。
レベル・ベース・メジャーを作成する際には、集計内容を使用して、適切なファクト・ソースすべてを階層内の適切なレベルにマップしてください。メジャーの集計内容は、「論理列」ダイアログの「レベル」タブで設定します。

「論理列」ダイアログの「レベル」タブで集計内容を設定するのは、レベル・ベース・メジャーのみでかまいません。レベル・ベースでないメジャーについては、「論理レベル」フィールドを空白のままにしてください。
論理ファクト表にはキーを含めないでください。ただし、キーを必要とするクライアントから論理SQL問合せをOracle BIサーバーに対して送信する必要がある場合を除きます。この場合は、論理ファクト表とプレゼンテーション・レイヤーの両方でキーを公開する必要があります。
論理ファクト表内の列はすべて集計メジャーです。ただし、外部クライアントで必要とされるキーや、区切りとして使用されるダミー列は除きます。その他の非集計列は、論理ディメンション表に存在する必要があります。
1つのビジネス・モデルに複数の論理ファクト表を含めることができます。論理SQL問合せの場合は、複数の論理ファクト表が1つの表のように動作します。

複数の論理ファクト表を含める理由としては、次のようなものがあります。
- プロジェクトを割り当てます。詳細は、プロジェクトの設定を参照してください。
- プレゼンテーション・レイヤーに小さいサブジェクト・エリアを自動的に作成します。詳細は、論理的なスターとスノーフレークに基づくサブジェクト・エリアの自動作成を参照してください。
- わかりやすく編成します。
リレーショナル・ファクト表とは異なり、論理ファクト表には様々な単位のメジャーを含めることができます。論理ファクト表を分割する理由として単位を使用しないでください。
計算は、次のいずれかの方法で定義できます。
- 集計前に、論理表ソースで定義します。次に例を示します。
  
  sum(col_A *( col_B))
- 集計後に、他の2つの論理列から派生した論理列で定義します。次に例を示します。
  
  sum(col A) * sum(col B)
アンサーまたは論理SQL問合せで集計後計算を定義することもできます。
Oracle Scorecardと戦略管理を使用する予定がある場合は、KPIに使用するOracle BIリポジトリに時間ディメンションを少なくとも1つ実装することをお薦めします。この処理が必要なのは、スコアカードでKPIを使用して、時間の経過に伴う進捗とパフォーマンスを測定するためです。スコアカードのKPIによって使用されるディメンションは、個々のスコアカードによって自動的にインクルードされます。
集計ソースは、別個の論理表ソースとして作成する必要があります。ファクト集計については、「論理表ソース」ダイアログの「内容」タブを使用して、適切な論理レベルを各ディメンションに割り当ててください。
階層内の各ディメンション・レベルには一意のレベル・キーが必要です。各論理ディメンション表には一意の主キーが必要です。このキーは、最下位階層レベルのレベル・キーとしても使用されます。
ビジネス・モデルとマッピング・レイヤーで列の名前を変更すると、「論理列名の使用」プロパティが選択されているプレゼンテーション・レイヤー列について別名(シノニム)が自動的に作成されます。これは、論理列とプレゼンテーション列の名前が同期をとれるように、このオプションを選択したときに「プレゼンテーション・レイヤー」列の名前が自動的に変更されるために起こります。「論理列名の使用」が選択されていないときに、「プレゼンテーション」レイヤーの列の名前を直接変更すると別名が作成されます。
集計ナビゲーションに関する問題を回避するために、ディメンション階層の各論理レベルについて、「このレベルの要素数」フィールドに適切な値を入力してください。ファクト・ソースは、選択したフィールドの組合せとマップ先のディメンションのレベルに基づいて選択されます。これらの値を調整することによって、Oracle BIサーバーで選択されるファクト・ソースを変更できます。この値を設定する方法の詳細は、ディメンション内の論理レベルの作成を参照してください。

外部結合のモデリング

外部結合をモデリングする方法については、次のガイドラインを使用します。

外部結合の性質により、通常、外部結合を使用する問合せには時間がかかります。そのため、外部結合を使用するのは、必要な場合のみにしてください。可能であれば、レポート作成SQLで外部結合を使用しなくて済むように、ETL手法を使用してください。
外部結合は常に、ビジネス・モデルとマッピング・レイヤーで定義されます。物理レイヤーの結合では、内部または外部は指定されません。
外部結合は、論理表の結合を使用するか、論理表ソースで定義できます。使用する外部結合のタイプは、物理結合がビジネス・モデルの結合と論理表ソースの結合のどちらにマップするかによって決まります。
外部結合を定義する必要がある場合は、外部結合を使用するディメンションと外部結合を使用しないディメンションの2つの別個のディメンションを作成してみてください。外部結合を使用するディメンションには、それを明確に特定するような名前を付けて、クライアント・ユーザーができるだけそのディメンションを使用しないようにしてください。
複数の外部結合の使用は避けてください。論理外部結合と同じ効果を上げるには、かわりに論理結合を内部結合にし、設計時に分析設計者が対応する分析で「NULL値を含む」オプションを選択することをお薦めします。分析エディタの「NULL値を含む」オプションの詳細は、『Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』のnullの抑制の理解に関する項を参照してください。

プレゼンテーション・レイヤーを設計する際のヒント

プレゼンテーション・レイヤーでは、ビジネス・モデルのユーザー・ビューを設定します。

プレゼンテーション・レイヤーのフォルダや列の名前は、ローカライズされた言語で表示できます。プレゼンテーション・レイヤーは、ユーザー許可の設定に適したレイヤーです。プレゼンテーション・レイヤーにおける作業の詳細は、プレゼンテーション・レイヤーの作成およびメンテナンスを参照してください。

このレイヤーでは、次のような作業を行うことができます。

ビジネス・モデルとマッピング・レイヤーに存在する列の一部のみを表示できます。たとえば、キー列にはビジネス上の意味がないため除外できます。
ビジネス・モデルとマッピング・レイヤーの表構造とは異なる構造を使用して、列を編成できます。
ビジネス・モデルとマッピング・レイヤーの列名とは異なる列名を表示できます。
権限を設定して、個々のサブジェクト・エリア、表および列へのアクセスをユーザーに許可または禁止できます。
ODBCベースの問合せおよびレポート・ツールに論理キーをエクスポートできます。
1つのビジネス・モデルについて複数のサブジェクト・エリアを作成できます。
論理SQL問合せで使用可能なプレゼンテーション・オブジェクトの別名(シノニム)の一覧を作成できます。この機能を使用すると、既存のレポートに影響を与えることなく、プレゼンテーション列の名前を変更できます。

プレゼンテーション・レイヤーを設計する際のヒントは次のとおりです。

ビジネス・モデルとマッピング・レイヤーとプレゼンテーション・レイヤー間ですべての変更を自動的に同期することはできないため、ビジネス・モデルとマッピング・レイヤーが比較的安定してから、プレゼンテーション・レイヤーにカスタマイズを加えることをお薦めします。
サブジェクト・エリアを作成する際には、ビジネス・モデル全体をドラッグ・アンド・ドロップする、モデルの増分部分をドラッグ・アンド・ドロップする、論理スターまたはスノーフレークに基づいてサブジェクト・エリアを自動的に作成するなど、様々な方法があります。それぞれの方法は、サブジェクト・エリアの作成についてを参照してください。ビジネス・モデルの特定の部分が変更中でも、増分ドラッグ・アンド・ドロップは正しく機能します。
メンテナンス性を向上させるために、プレゼンテーション・レイヤーではなく、ビジネス・モデルとマッピング・レイヤーでオブジェクトの名前を変更することをお薦めします。プレゼンテーション・オブジェクトではなく論理オブジェクトにわかりやすい名前を指定することによって、複数のサブジェクト・エリアで名前を再利用できます。また、ビジネス・モデルに変更を組み込むためにサブジェクト・エリアを削除して再作成する必要がある場合でも、名前が保持されます。
プレゼンテーション階層のメンバーは、プレゼンテーション・レイヤーには表示されません。かわりに、アンサーで階層のメンバーを表示できます。
管理ツールを使用してプレゼンテーション・レイヤーのメタデータを更新することで、ネストされたフォルダをアンサーに表示できます。詳細は、BIコンポーザでのフォルダのネストを参照してください。
多数のオブジェクトのデータ・アクセス・セキュリティを設定する際には、個々の列の権限を設定するのではなく、ロールによってオブジェクト権限を設定することを検討してください。詳細は、リポジトリ・オブジェクトへのデータ・アクセス・セキュリティの適用を参照してください。
プレゼンテーション・オブジェクトの権限を設定する際には、NQSConfig.INIファイルを設定することによって、デフォルト権限を変更できます。詳細は、『Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のNQSConfig.INIファイルの構成設定に関する項を参照してください。