ビジネス・モデル・デザイン
Oracle Analyticsでは、セマンティック・モデルの論理レイヤーを様々な方法で構成できます。 Oracleでは、一貫性チェックおよびランタイム・エラーを回避するために、ここで説明するベスト・プラクティスに従うことをお薦めします。
ビジネス・モデルのベスト・プラクティス
-
ビジネス・モデルでスター・スキーマを使用します
物理レイヤーのデータ構造は、様々な形式にすることができます。 物理レイヤーにスター・スキーマを持つことは、パフォーマンスに役立ちますが、必須ではありません。 ただし、物理レイヤーの構造に関係なく、ビジネス・モデルは「常に」スター・スキーマである必要があります。
各論理表には、同じ論理表ソース内に複数の物理表を含めることも、複数の論理表ソースに分割することもできます。
-
ディメンションごとに個別のディメンション論理表を使用します
-
ディメンションを1つの論理表に結合またはマージしません
-
ファクトごとに個別のファクト論理表を使用します
"Facts - Stuff"というファクト論理表が1つになることはありません
-
複合ファクトに個別の論理表を使用します
複合ファクトは、複数のファクト表のメトリックを結合する導出式を配置する場所です。 たとえば、ファクト・オーダーとファクト商談がある場合、ファクト複合商談&オーダーという別の論理表に、式「# Opportunities/ # Orders」の計算を含めます。
-
表タイプを示す論理表名の接頭辞
たとえば、ディメンション表にはD、ファクト表にはFを使用します。
-
可能な場合は、一意のビジネス列をディメンション主キーとして割り当てます
-
プレゼンテーション名を使用するように論理列の名前を変更します
-
論理レイヤーで使用される列のみを保持します
-
論理ファクト表に論理主キーを割り当てません
論理主キーは、ディメンション表でのみ必要です。
-
必要に応じて、ファクトを様々なグループに分けるためのダミー・メジャーを作成します
-
ほぼすべてのファクト論理列に集計ルール・セットがあることを確認します。
