Tableau セマンティックの共有ディメンション

関連テーブルと非関連テーブル

共有テーブルのもう 1 つの主要な概念は、関連テーブルと非関連テーブルの違いです。

2 つのテーブルが定義済みのリレーションで直接接続されている場合は、関連テーブルとみなされます。関連テーブル間のクエリは期待どおりに動作します。つまり、定義されたパスを使用して結合されます。

2 つのテーブルが完全に関連していない場合 (つまり、直接接続や共有接続がない場合)、システムはデータをどのように組み合わせるかを判断できず、クエリは失敗します。

場合によっては、テーブルは共有ディメンションを介してのみ接続されます。共有テーブルの項目を含めずに両方の結果テーブルの項目を照会し、項目が集計されていない場合、クロス結合が実行されます。つまり、1 つのファクトテーブルのすべての行が、他のすべての行と結合されます。これは、それらを揃えるための共有キーがないためです。

たとえば、Sales と Marketing の両方が共有 Products テーブルにリンクされていて、[Products].[Product Name] なしで [Sales].[Sales Quantity] と [Marketing].[Spend] を照会すると、すべての Sales 行がすべての Marketing 行と結合されます。

これを回避するには、クエリに [商品] や [日付] などの共有テーブルの項目を含める必要があります。これは結合キーとして機能し、2 つの事実の値をグループ化および集計するための共有軸となります。

ディメンションを共有することで、通常は孤立していたテーブルのデータを分析できます。ただし、クエリ内で正しく使用される場合のみ可能です。

ファクトツリーとその構造

ファクトツリーは、同じビジネス領域に属し、相互に接続されたテーブルのグループです。通常、ディメンションテーブルと共に 1 つ以上の結果テーブルが含まれます。

この構造は単なるモデリングの概念ではなく、クエリを実行するとシステムが自動的に構築します。ファクトツリーは、共有ディメンションを正しく評価するためにセマンティックレイヤーで内部的にテーブルを整理する方法です。

上記の図の例では、Marketing は共有テーブル Products and Dates に接続されている結果テーブルです。これはそのファクトツリーを形成します。Sales は同じ共有ディメンションに接続され、個別の結果ツリーを形成するもう 1 つの結果テーブルです。この構造により、システムは各ツリーがどのように独立して機能するかを把握しながら、ディメンションを共有してツリー間分析を行うことができます。

ファクトツリーはサイクルフリーである必要があります。循環ではあいまいさが生じます。システムが複数のパスを介して同じテーブルに到達できる場合、どのパスに従うべきか、検索条件と集計を正しく適用する方法がわからない可能性があります。このため、循環を導入する新しいリレーション ([マーケティング] を [サブカテゴリ] ([商品] からすでにアクセス可能) に直接接続するなど) を作成することはできません。

共有ディメンションによるクエリへの影響

共有ディメンションは、セマンティックモデルの構造化に役立つだけでなく、実行時のクエリの動作も制御し、正確な結果と一貫したロジックを保証します。

たとえば、マーケティング費用と販売数量の関係を分析しているとします。この 2 つの基準は、マーケティングとセールスという異なる結果テーブルから取得されます。グループ分けの基準となる共有コンテキストがないため、単独では意味のあるアライメントができません。共有参照を使用せずに両方の項目をクエリにドラッグすると、行を照合できず、誤解を招く結果が返されたり、失敗したりすることがあります。

ただし、[商品] と [日付] などの 2 つの共有ディメンションを取り込むと、状況は変わります。「商品と月ごとに、マーケティングにいくらかかり、何単位が販売されたか」を尋ねることができます。

Sales と Marketing の両方が Products and Dates (商品と日付) (共有テーブル) に接続されているため、両方の基準 (商品別、月別) を正しく調整し、意味のある集計結果を返すことができるようになりました。

フィルタリング動作

検索条件は、関連のないテーブルからデータが変更されないように適用されます。

• [マーケティング種別] などの結果固有の項目に検索条件を適用すると、その結果テーブルのみが絞り込まれ、他の結果や共有ディメンションは絞り込まれません。
• [商品名] や [日付] などの共有ディメンションに検索条件を適用すると、検索条件は、そのディメンションに接続されているすべての結果テーブルに適用されます。

この動作により、検索条件で関連しないレコードが削除されなくなります。たとえば、[Marketing Type (マーケティング種別)] 検索条件で [Online (オンライン)] を選択した場合、マーケティング支出のみが更新され、[Sales Quantity (販売数量)] は影響を受けません。

ファクトツリーはサイクルフリーである必要があります。循環ではあいまいさが生じます。システムが複数のパスを介して同じテーブルに到達できる場合、どのパスに従うべきか、検索条件と集計を正しく適用する方法がわからない可能性があります。このため、循環を導入する新しいリレーション ([マーケティング] を [サブカテゴリ] ([商品] からすでにアクセス可能) に直接接続するなど) を作成することはできません。

計算済み項目と結果ツリーの包含構造

計算項目は、結果ツリーの境界に従う必要があります。行レベルの計算項目を作成する場合は、次のようになります。

IF [Support].[Priority] <= 1 THEN "High" ELSE "Low"

-- その項目は、同じ結果ツリー内にある限り有効です (この場合はサポート)。これを使用して、パターンを分析したり、Customer や Product などのディメンションに対してサポート関連の活動を絞り込んだり (これらのディメンションが共有されている場合)、すべてが期待どおりに動作します。

ただし、次のような複数の結果テーブルにまたがる計算項目を作成しようとすると、次のようになります。

[Inventory].[Quantity] + [Sales].[Sales Quantity]

-- プラットフォームでエラーが発生します。2 つの異なる結果ツリーの行レベルのデータを結合しようとしますが、その式の一般的な詳細レベルを解決できません。各結果ツリーには、独立した粒度と絞り込みコンテキストがあります。

有効なクロスファクト計算を実現するには、各ファクトを個別に集計し、それらの集計をビューのレベルで組み合わせる必要があります。

SUM([Inventory].[Quantity]) + SUM([Sales].[Sales Quantity])

この式は、両方の基準が結合される前に集計され、集計の範囲が商品レベルまたはビュー内の任意のディメンションに設定されているため、使用できます。

共有ディメンションとファクトツリーの制限

• 結果テーブルは、相互に切断されたままである必要があります。直接結合することはできません。これらの間の接続は、共有ディメンションテーブルを介してのみ行われる必要があります。
• 行レベルの計算項目 (ディメンションまたは基準) は、1 つの結果ツリー内に完全に含まれている必要があります。
• 共有テーブルを別の共有テーブルに接続してから結果テーブルに接続することはできません。つまり、ファクトテーブルとそのディメンション間の接続パスには、1 つの共有テーブルのみが存在する可能性があります。たとえば、[商品] が [日付] に接続されている共有テーブル (別の共有テーブル) であり、両方が [セールス] に接続されている場合、この構造はサポートされていません。
• 同じクエリで複数の結果ツリーの項目を絞り込む場合、それらの検索条件は OR ではなく AND 条件を使用して組み合わせる必要があります。