物理表の別名
Oracle Analyticsでは、セマンティック・モデルの物理レイヤーに表の別名を作成できます。 表の別名は、1つの表にセマンティック・モデルで複数の異なるロールがある場合に役立ちます。
ベスト・プラクティス
1つの表に複数のロールがあることがよくあります。 表は、ファクト表としてディメンションとして使用したり、特定の属性を取得するために別のディメンションを拡張したり、他の2つの表を結合するためのヘルパー表として使用できます。
多くの場合、各ロールには異なる物理結合セットが付属しています。 表の単一インスタンスですべての結合を構成すると、データ整合性の問題が発生します。 このような問題を回避するために、表の別名を使用し、いくつかの基本ルールに従うことができます。
-
別名に一貫性のあるネーミング規則を使用します
別名には、元の表の名前と別名のロールの表示の両方を含める必要があります。 これにより、開発者はどの表が使用されているかをすぐに把握し、別名の目的を理解できます。
-
オリジナル表に物理結合を定義しません
別名の作成から開始します。 各物理表には少なくとも1つの別名が必要です。 別名のみが使用され、元の表は使用されません。 このようにして、将来他のロールに対して同じ表の新しいインスタンスが必要な場合は、各別名の違いとロールを簡単に識別できます。
-
表が使用されるコンテキストに応じて異なる物理結合が必要な場合に、追加の別名を作成します。
次に、2つの一般的な例を示します
例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 ManagerIDとProduct ManagerIDと等しい必要があることを意味します。 これらのマネージャは2人の異なる従業員であるため、問合せでレコードが返されないため、これは不可能です。かわりに、前述の図で説明したように、解決策は
Employee表の2つの別名を持つことです。 1つの別名がMarket表と結合され、もう1つの別名がProduct表に結合されます。 これらの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と等しくありませんが、どちらもカレンダ表の同じ日付列に結合されます。解決策は、Order表に対して2つの別名を作成することです: ファクトの1つの別名とディメンションの2番目の別名。 別名では、図は次のようになります:
図ceal_table_alias_example2_with.jpgの説明これで、Order表のディメンション別名がカレンダ・ディメンションに結合されていないため、結合間に競合はありません。
また、
Fact_W_ORDER_FとDim_W_ORDER_Dを結合する必要はありません。 まれな状況を除き、同じ表の2つの別名を結合しないでください。 これを行うと、データの整合性には影響しませんが、役に立たず、パフォーマンスに影響します。かわりに、ビジネス・モデルの
Order Dimensionに2つの論理表ソースを作成します。Invoice Fact Starには1つの論理表ソースを使用し、Order Fact Starにはもう1つの論理表ソースを使用します。
図ceal_table_alias_logical_tables.jpgの説明
サマリー
- 物理表ごとに少なくとも1つの別名を作成してください。
- 必要に応じて、モデル内の表の様々なロールおよび必要な様々なタイプの結合に基づいて、追加の別名を作成します。
- 例外はありますが、ほとんどの場合、同じ表の2つの別名を結合しないでください。