物理レイヤーの計画

物理スキーマ・タイプについて

データ・ソースをモデリングする場合、任意の物理ソースのモデルを重複するディメンション・サブセットに分割できます。

各物理モデルは、ソースの形状を反映します。たとえば、スノーフレークや正規化などです。

スター・スキーマ

スター・スキーマは、複数のディメンション表への結合関係を持つファクト表がそれぞれ1つずつあるディメンション・スキーマ(スター)のセットです。スターをビジネス・モデルにマップする際にはまず、物理ファクト列を1つ以上の論理ファクト表にマップします。次に、そのスターの物理ファクト表に結合するそれぞれの物理ディメンション表について、物理ディメンション列を適切な適合済論理ディメンション表にマップします。
スノーフレーク・スキーマ

スノーフレーク・スキーマはスター・スキーマと同様ですが、各ディメンションが、結合された複数の表で構成される点が異なります。スター・スキーマと同様に、まず、物理ファクト列を1つ以上の論理ファクト表にマップします。次に、それぞれのディメンションについて、スノーフレーク物理ディメンション表を1つの論理表にマップします。そのためには、複数の論理表ソースを使用するか、結合がある1つの論理表ソースを使用します。
正規化スキーマ

正規化スキーマでは、データ保存の冗長性を最小限に抑え、データの更新を最適化するために、データ・エンティティが複数の表に分散されます。正規化スキーマをビジネス・モデルにマップする前に、ファクトとディメンションに関して分散構造を理解する方法を理解しておく必要があります。

構造を分析したら、ファクト列を持つ表を選択し、物理ファクト列を1つ以上の論理ファクト表にマップします。次に、その物理ファクト列のセットに関連するそれぞれのディメンションについて、ディメンション列を含む分散物理表を1つの論理表にマップします。そのためには、スノーフレーク・スキーマと同様に、複数の論理表ソースを使用するか、結合がある1つの論理表ソースを使用します。まず特定のファクト・セットをマップし、次に関連するディメンションをマップした後、次のファクト・セットに進むため、正規化スキーマのマッピングは反復プロセスです。

1つの物理表にファクト列とディメンション列の両方がある場合は、その表が果たす複数の役割を処理するために、物理別名表の作成が必要になることがあります。
完全非正規化スキーマ

このタイプのディメンション・スキーマは、ファクトとディメンションを列として1つの表に結合し、他のタイプのスキーマとは異なる方法でマップされます。完全非正規化スキーマを星形のビジネス・モデルにマップする際には、1つの物理ファクト表の物理ファクト列をビジネス・モデル内の複数の論理ファクト表にマップします。次に、物理ディメンション列を適切な適合済論理ディメンション表にマップします。

データ・ソースの表構造の特定

セマンティック・モデルを構築する場合、論理表をデータ・ソース内の基礎となる物理表にマップします。表をマップするには、ビジネス・モデルに関連する物理データ・ソースのコンテンツを特定しておく必要があります。

物理データ・ソースの次のコンテンツを特定します:

各表のコンテンツの特定
各表の詳細レベルの特定
各集計表の表定義の特定。これによって、集計ナビゲーションを設定できます。Oracle Analytics問合せエンジンには、次のものが必要です:
- 表のグループ化基準となる列(集計レベル)。
- 集計のタイプ: SUM、AVG、MIN、MAXまたはCOUNT。
各列のコンテンツの特定
メジャーの計算方法の特定
データベースに定義されている結合の特定

この情報を確認するには、データ・ソースの実装時に作成されたデータ要素を説明する使用可能なドキュメントに移動します。または、各データ・ソースのDBAと協力してこの情報を収集することもできます。

すべてのデータ要素を完全に理解するには、データを使用または所有するユーザー、またはデータを作成するアプリケーションの開発者に問い合せることができます。

物理レイヤーの設計のヒント

このトピックの情報を使用すると、セマンティック・モデルの物理レイヤーの設計に役立ちます。

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

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

物理レイヤーを設計する場合は、次のヒントを使用します:

物理レイヤーでは表の別名を使用して、次のような無関係な結合を削除してください:
- 別名を使用することによって、複数のディメンションにまたがる物理結合(ディメンション間の循環結合)をすべて削除します。
- 物理表の別名を作成することによって、物理レイヤーの論理表ソースにおける循環結合(ディメンション間の循環結合)をすべて削除します。
  
  循環結合では、同じ表の異なる結合を使用して結果を取得します。たとえば、出荷先住所の参照に使用されるCustomer表があり、Customer表への別の結合を使用して請求先住所を参照するとします。循環結合を防ぐには、物理レイヤーに別名表を作成して、それぞれの結合で用途ごとに1つの表インスタンスのみが使用されるようにします。
循環結合を削除しないと、誤ったレポート結果を取得する可能性があります。また、循環結合によって問合せのパフォーマンスが低下する可能性もあります。
ある論理表ソースでは結合を内部結合として実行し、別の論理表ソースでは外部結合として実行する必要がある場合は、別名表を使用して別々の物理結合を作成してください。
すぐには使用しないものの、削除はしない表を物理レイヤーにインポートできます。論理レイヤーですぐに使用しない表を特定するには、物理表に別名を割り当ててから、論理レイヤーにマップします。
SELECT文は、モデリングの問題に対する解決策が他にない場合にのみ使用します。物理表またはマテリアライズド・ビューを作成してください。SELECT文には、基礎となるデータ・ソースに送信される固定されたSQL文が含まれているため、Oracle Analytics問合せエンジンは最適化されたSQLを生成できません。
行レベルのセキュリティ制御をデータベースとセマンティック・モデルのどちらで設定するかを決定します。この決定によって、接続プールとキャッシュを共有するかどうかが決まります。また、開発に含める個々のソース・データベースの数が制限される場合があります。