ビジネス・モデルの設計

Oracle Analyticsでは、セマンティック・モデルの論理レイヤーを様々な方法で構成できます。一貫性チェックおよびランタイム・エラーを回避するために、ここで説明するベスト・プラクティスに従うことをお薦めします。

ビジネス・モデルのベスト・プラクティス

  • ビジネス・モデルでスター・スキーマを使用します

    物理レイヤーのデータ構造は、様々な形式になります。物理レイヤーにスター・スキーマを含めることは、パフォーマンスに役立ちますが、必須ではありません。ただし、物理レイヤーの構造に関係なく、ビジネス・モデルは常にスター・スキーマである必要があります。

    各論理表は、同じ論理表ソース内に複数の物理表を含めることも、複数の論理表ソースに分割することもできます。

    ceal_star_schema_logical_layer.jpgの説明が続きます
    図ceal_star_schema_logical_layer.jpgの説明

  • ディメンションごとに個別のディメンション論理表を使用します

  • ディメンションを1つの論理表に結合またはマージしません

  • ファクトごとに個別のファクト論理表を使用します

    「ファクト - 内容」という単一のファクト論理表を使用する必要はありません。

  • 複合ファクトに個別の論理表を使用します

    複合ファクトは、複数のファクト表のメトリックを組み合せた派生式を配置する場所です。たとえば、ファクト・オーダーとファクト商談がある場合、「ファクト複合商談とオーダー」という別の論理表に式「商談数/オーダー数」を使用した計算を含めます。

  • 表タイプを示す論理表名の接頭辞

    たとえば、ディメンション表には「D」、ディメンション表には「F」を使用します。


    sm_design_logical_table_labels.pngの説明が続きます
    図sm_design_logical_table_labels.pngの説明

  • 可能な場合は、一意のビジネス列をディメンション主キーとして割り当てます

  • プレゼンテーション名を使用するように論理列の名前を変更します

  • 論理レイヤーで使用される列のみを保持します

  • 論理ファクト表に論理主キーを割り当てません

    論理主キーはディメンション表でのみ必要です。

  • 必要に応じて、ファクトを様々なグループに分けるためのダミー・メジャーを作成します


    sm_design_logical_dummy_measure.pngの説明が続きます
    図sm_design_logical_dummy_measure.pngの説明

  • ほぼすべてのファクト論理列に集計ルール・セットがあることを確認します。