物理表の別名

Oracle Analyticsでは、セマンティック・モデルの物理レイヤーの表の別名を作成できます。表の別名は、セマンティック・モデルで1つの表に複数の異なるロールがある場合に役立ちます。

ベスト・プラクティス

多くの場合、1つの表に複数のロールが含まれます。表は、ディメンションとして使用されることも、ファクト表として使用されることも、特定の属性を取得するために別のディメンションを拡張するために使用されることも、他の2つの表を結合するためのヘルパー表として使用されることもあります。

多くの場合、各ロールには異なる物理結合のセットが付属しています。表の1つのインスタンスですべての結合を構成すると、データの整合性の問題が発生します。表の別名を使用し、いくつかの基本ルールに従うと、このような問題を回避できます。

• 別名に一貫性のあるネーミング規則を使用します

  別名には、オリジナル表の名前と、別名のロールを示すものの両方を含める必要があります。こうすることで、開発者は一見して使用されている表をすぐに把握し、別名の目的を理解します。

• オリジナル表に物理結合を定義しません

  まず、別名を作成します。各物理表には、常に少なくとも1つの別名が必要です。別名のみが使用され、オリジナル表は使用されません。こうすることで、将来他のロールに同じ表の新しいインスタンスが必要になった場合に、各別名の違いとロールを簡単に識別できます。

  
  
  
  図sm_design_alias_table.pngの説明
  
  

• 表が使用されるコンテキストに応じて異なる物理結合が必要な場合は、追加の別名を作成します

  次に、2つの一般的な例を示します

  例1

  
  図ceal_table_alias_example1.jpgの説明

  例1は、Employee表の実装を示しています。表W_MARKET_Dには、Market Managerである従業員のキーが含まれます。表W_PRODUCT_Dには、Product Managerである従業員のキーが含まれます。別名がない場合、表W_EMPLOYEE_DはW_MARKET_DとW_PRODUCT_Dの両方に結合します。Market ManagerとProduct Managerの両方の名前を選択するレポートを作成する場合、物理SQLで生成されるWHERE句には、W_MARKET_D.EMP_ID=W_EMPLOYEE_D.ID文およびW_PRODUT_D.EMP_ID=W_EMPLOYEE_D.ID文が含まれます

  つまり、従業員のIDは、Market Manager IDとProduct Manager IDと同時に同じである必要があります。これらのマネージャは2人の異なる従業員であるため、これは不可能であり、この問合せではレコードが返されません。

  かわりに、前述の図で説明したように、解決策はEmployee表の別名を2つ持つことです。1つの別名がMarket表と結合され、もう1つの別名がProduct表に結合されます。これら2つの別名は、相互に完全に独立した2つの異なる表であるかのように見なされます。2つの別名を使用することで、2つの結合間に競合は発生しません。

  例2

  例2は3つの表を示しています。表W_ORDER_Fは、発注メトリックのファクト表(発注属性のディメンション)として使用され、Order Dateが含まれます。また、カレンダ表W_DAY_Dと、Order IDおよびInvoice Dateを含む請求書表W_INVOICE_Fもあります。請求書表は発注表に結合され、発注属性がInvoice Factメトリックのディメンションとして取得されます。Oracle Analyticsでは、ファクト表ごとに個別の副問合せが生成されることに注意してください。したがって、図に示すように、Order Fact StarとInvoice Fact Starを個別に考慮する必要があります。

  別名がない場合、図は次のようになります:

  
  図ceal_table_alias_example2.jpgの説明

  この構成では、Employeeの例と同様のデータ整合性の問題が発生します。つまり、Order DateはInvoice Dateと等しくありませんが、両方ともカレンダ表の同じ日付列に結合されます。

  解決策は、発注表に2つの別名(1つはファクトの別名、もう1つはディメンションの別名)を作成することです。別名がある場合、図は次のようになります:

  
  図ceal_table_alias_example2_with.jpgの説明

  発注表のディメンション別名がカレンダ・ディメンションに結合されていないため、結合間に競合は発生しません。

  また、Fact_W_ORDER_FをDim_W_ORDER_Dと結合する必要がないことに注意してください。まれな特定の状況を除き、同じ表の2つの別名を結合しないでください。これを行っても、データの整合性には影響しませんが、パフォーマンスに影響し、意味がありません。

  かわりに、ビジネス・モデルのOrder Dimensionに2つの論理表ソースを作成します。1つの論理表ソースをInvoice Fact Starに使用し、もう1つの論理表ソースをOrder Fact Starに使用します。

  
  図ceal_table_alias_logical_tables.jpgの説明

要約

• 物理表ごとに常に少なくとも1つの別名を作成します。
• 必要に応じて、モデル内の表の様々なロールおよび必要な様々なタイプの結合に基づいて、追加の別名を作成します。
• 例外もありますが、ほとんどの場合、同じ表の2つの別名を結合しないでください。