論理レイヤーの計画

この項のトピックを使用して、論理レイヤーのコンテンツを決定します。

トピック:

論理レイヤーのコンテンツを特定するためのガイドライン

この手順を使用して、セマンティック・モデルの論理レイヤーに含めるコンテンツを決定します。

ユーザーが問い合せる必要がある論理列を特定します。
各列のロールをメジャー列またはディメンション属性として特定します。
関連するロール、列間のリレーションシップおよびロジックに基づいて、論理列をディメンション・モデルに配置します。

ビジネスは関連するディメンション基準によって分析されるため、これらの関連するディメンションからビジネス・モデルを開発します。これらのディメンション・モデルは、Oracle Analytics問合せエンジンで使用する有効なビジネス・モデルの基盤となります。

すべてのディメンション・モデルがスター・スキーマに基づいて作成されるわけではありませんが、ビジネス・モデル・レイヤーでは単純なスター・スキーマを使用することをお薦めします。つまり、ディメンション・モデルは、様々なディメンション属性に関して表示される測定可能なファクトを表す必要があります。

ビジネス・モデルの要件を分析したら、ビジネス・モデルに含める必要がある具体的な論理表や階層を特定する必要があります。

論理ファクト表の特定

セマンティック・モデルの論理レイヤーには、定義に集計が組み込まれたメジャーを含む論理ファクト表が含まれます。

リレーショナル・モデルでは、論理ファクト表は物理ファクト表とは異なります。リレーショナル・モデルにおける物理表では、可能なかぎり最低のグレインでファクトが定義されます。論理ファクト表には様々なグレインのメジャーを格納できます。

ファクトから集計されるメジャーは、論理ファクト表で定義する必要があります。メジャーとは、ドル値や売上数量など、計算されたデータです。ディメンション値を使用してメジャーを指定できます。たとえば、特定の期間の特定の市場における特定の製品に関するドル合計を確認できます。

各メジャーには、SUM、AVG、MIN、MAXなどの独自の集計ルールがあります。ビジネスによっては、メジャーの値を比較し、比較を表す計算が必要な場合があります。特定のディメンションに集計ルールを指定できます。セマンティック・モデルで、ディメンション固有の複雑な集計ルールを定義できます。

論理レイヤーの表は、ファクト表またはディメンション表として明示的に指定されるわけではありません。Oracle Analytics問合せエンジンでは、結合の1の側の表がディメンション表として扱われ、結合の多側の表がファクト表として扱われます。

この図は、論理ダイアグラムにおけるファクト表への多対1結合を示しています。この論理ダイアグラムでは、すべての結合に、ファクト表から発する1の側を示す矢印があります。ファクト表を指す結合はありません。
論理レイヤー・ダイアグラム

論理ディメンション表の特定

ディメンション表には、ビジネス・エンティティ(顧客名、地域、住所、国など)を説明する属性が格納されています。

ビジネスでは、ファクトを使用して、時間、製品、市場など、確立されたディメンション別にパフォーマンスを測定します。各ディメンションには、一連の説明属性があります。ディメンション表には、各メンバーを特定する主キーが格納されています。

ディメンション表の属性によって、サービス・リクエストを分類する機能を提供するなど、数値データにコンテキストが提供されます。サービス・リクエストのディメンション表に格納される属性には、サービス・リクエストの所有者、領域、アカウント、優先度などがあります。

ビジネス・モデルのディメンションは、適合済ディメンションです。たとえば、特定のデータ・ソースに特定のCustomer表の5つの異なるインスタンスがある場合でも、ビジネス・モデルのCustomer表は1つのみです。適合性を実現するために、Customerの5つの物理ソース・インスタンスのすべてが1つのCustomer論理表にマップされ、必要に応じて論理表ソースで変換が行われます。適合済ディメンションによって、ユーザーは物理レイヤーの複雑さを感じることなく、様々なグレインの複数のファクト・ソースのデータを結合できます。適合済ディメンションにより、複数のデータ・ソースの組合せが可能になります。

ビジネス・モデルでは、生成された代理キーではなく、ディメンションとレベル・キーのビジネス・キーを使用します。たとえば、1076823のような値を持つCustomer Keyではなく、Oracleなどの値を持つCustomer Nameを使用してください。ビジネス・モデルでビジネス・キーを使用することで、そのディメンションのすべてのソースを、同じ論理キーとレベル・キーを持つ同じ論理ディメンション表に適合させることができます。

生成された代理キーは物理レイヤーに存在でき、そこではキーは結合に対する問合せのパフォーマンスの利点があるため有用です。論理レイヤーに代理キー列はありません。

ディメンションの特定

ディメンションは、ビジネスを定義する属性のカテゴリです。

一般的な属性としては、期間、製品、市場、顧客、仕入先、プロモーション条件、原材料、製造工場、輸送手段、メディアの種類、時刻などがあります。1つのディメンション内には多数の属性があります。たとえば、期間ディメンションには、属性として日、週、月、四半期および年を含めることができます。ディメンションに含まれる属性は、ビジネスをどのように分析するかによって決まります。

ディメンションには、ディメンション内のメンバー間のトップダウン・リレーションシップのセットである階層が含まれています。階層には2つのタイプがあります。

レベルベース階層(構造階層) - これらの階層では、同じタイプのメンバーが1つのレベルにのみ存在します。一方、親子階層のメンバーはすべて同じタイプです。Oracle Analyticsでは、時系列データをモデリングするための機能を備えた、時間ディメンション・レベルベース階層がサポートされています。

レベルベース階層では、下位レベルから上位レベルへとレベルがロールアップされます。たとえば、月を年にロールアップできます。このようなロールアップは階層要素全体で行われ、存在するビジネス・リレーションシップにまたがります。
親子階層(値階層) - これらの階層では、組織階層ツリーのマネージャ-従業員リレーションシップなど、実際には同一タイプの異なるメンバー間にビジネス・リレーションシップが存在します。親子階層には、明示的に指定されたレベルはありません。親子階層内の暗黙レベルの数に制限はありません。

階層を定義するには、すべての計算におけるロールアップ集計、およびレポートやダッシュボードにおけるドリルダウン・ナビゲーションを容易にするための含むリレーションシップをビジネスに指定します。たとえば、月が年にロールアップされ、集計表が月レベルに存在する場合、月レベルのすべてのデータを合計して年のデータを計算することで、その表を使用して年レベルの質問に回答できます。

モデリングのニーズに適した階層タイプを決定するには、次のことを考慮します:

すべて同じタイプのメンバーであるか(従業員、組立品、顧客など)、基本的にレベルに分類される異なるタイプのメンバーであるか(年/四半期/月、大陸/国/都道府県、ブランド/ライン/製品など)。
メンバーの属性セットが同じかどうか。たとえば、Employeesのような親子階層では、すべてのメンバーにHire Date属性があると考えられます。Timeのようなレベルベース階層では、DayタイプにはHoliday属性がありますが、MonthタイプにはHoliday属性がありません。
設計時にレベルが固定されているか(年-四半期-月)、実行時のビジネス・トランザクションによってレベルが増えたり減ったりする可能性があるか。たとえば、現在最下位の従業員が新たに最下位になる部下を雇用する場合はレベルを追加できます。
特定の階層タイプを必要とする制約がプライマリ・データ・ソースにあるかどうか。プライマリ・データ・ソースがある方法でモデル化されている場合、その他の要因とは無関係に、ビジネス・モデルで同じ階層タイプを使用する必要があります。

ディメンションに複数の階層が含まれる場合があります。複数の階層を持つディメンションは必ず、同じ列で終わる必要があります。たとえば、Timeディメンションには多くの場合、暦年を表す階層と会計年度を表す階層があります。

参照表の特定

多言語スキーマから翻訳されたフィールド情報を表示する必要がある場合は、物理レイヤーの参照表に対応する論理参照表を作成します。

参照表には、ベース表の行に対応する多言語データが格納されます。特定の論理参照表を使用する前に、その表を論理表の参照表の参照表として指定する必要があります。

参照表は、ある値セットをユーザーに表示し、対応する別の値セットを物理問合せで使用する場合に使用できます。参照表は、別のデータソースで検索される判読可能な値を提供するために使用できます。

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

論理レイヤーは、ビジネス・モデル別に情報を編成します。このレイヤーでは事実上、各ビジネス・モデルが別個のアプリケーションとなります。

各ビジネス・モデルで定義された論理スキーマには、論理表を少なくとも2つ含める必要があります。すべての論理表間の関係を定義する必要があります。

論理レイヤーを設計する場合:

可能であれば、論理ディメンション表とファクト表間に1対多の論理結合を持つビジネス・モデルを作成します。各ファクト表がそのディメンションに直接結合される単純なスター・スキーマのようなビジネス・モデルを作成してください。
すべての論理ファクト表を少なくとも1つの論理ディメンション表に結合します。ソースが完全非正規化表である場合は、その物理ファクト列を1つ以上の論理ファクト表にマップし、その物理ディメンション列を論理ディメンション表にマップする必要があります。
論理ディメンション内に階層を作成して、ディメンション属性間のリレーションシップを定義します。
レベルベース・メジャーを作成する際には、データ集計を使用して、適切なファクト・ソースすべてを階層内の適切なレベルにマップします。
集計ソースを別個の論理表ソースとして作成します。
階層内の各ディメンション・レベルに一意のレベル・キーを作成します。各論理ディメンション表には一意の主キーが必要です。このキーは、最下位階層レベルのレベル・キーとしても使用されます。
ディメンション階層の各論理レベルに正しい値が含まれていることを確認します。ファクト・ソースは、選択したフィールドの組合せとマップ先のディメンションのレベルに基づいて選択されます。これらの値を調整することによって、Oracle Analytics問合せエンジンで選択されるファクト・ソースを変更できます。

論理ファクト表

論理ファクト表には様々なグレインのメジャーを格納できます。論理ファクト表を分割する理由として単位を使用しないでください。
論理ファクト表にはキーを含めないでください。ただし、キーを必要とするクライアントから論理SQL問合せをOracle Analytics問合せエンジンに対して送信する必要がある場合を除きます。この場合は、論理ファクト表とプレゼンテーション・レイヤーの両方でキーを公開する必要があります。
論理ファクト表内の列はすべて集計メジャーです。ただし、外部クライアントで必要とされるキーや、区切りとして使用されるダミー列は除きます。その他の非集計列は、論理ディメンション表に存在する必要があります。
1つのビジネス・モデルで複数の論理ファクト表を使用できます。論理SQL問合せについては、複数の論理ファクト表が1つの表のように動作します。複数の論理ファクト表を使用する理由は、プレゼンテーション・レイヤーに小さいサブジェクト領域を自動的に作成し、ビジネス・モデル内でそれらを編成して簡素化するためです。

計算

計算は、次の方法で定義できます。

集計前に、論理表ソースで定義します。たとえば:

sum(col_A *( col_B))
集計後に、他の2つの論理列から派生した論理列で定義します。たとえば:

sum(col A) * sum(col B)

ワークブック、ダッシュボード、分析または論理SQL問合せで集計後の計算を定義することもできます。

外部結合のモデリング

この情報を使用して、外部結合をモデリングします。

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