OmniでJoinしたテーブルを分析する際の動きについて確認してみた

こんにちは、業務効率化ソリューション部のikumiです。
今回は、OmniでJoinを使用して分析した際の裏側の動きや挙動について確認しましたので、その内容について記載していきます。

OmniでJoinの定義をする方法

• まずはOmniのGUI上でJOINの作成をします
• 任意のWorkbookを開いて、基準となるビューテーブルのメニューから、 + New Join
  
• JOINの定義を作成し、Add
  • 今回は、ベースビュー：tran 、結合するテーブル：customer を選択
    
• IDEのrelationshipsファイルを確認すると、以下のようにJOINの定義がコード化されていることが確認できます
  
• では、ここからは実際Omniで生成されるクエリと合わせて、JOINの挙動を確認していきましょう

Viewファイルを元に分析したときの挙動について

• まずは、先ほどベースビューとして設定したtranテーブルからitem_kbnを選択
  
• 続いて、customerテーブルからCustomer ID Count Distinctを選択すると、JOINしたテーブルを使用した分析結果が正しく出力されました
  
• SQLを見てみますと、from句（ベースビュー）にtran、joinにcustomerが選択されているようです
  

• ここで、先ほどの手順を逆にして customer テーブルから Customer ID Count Distinct を先に選択してみます。
  • すると、既にJOINが定義されているにもかかわらず、tran テーブルの列が選択肢に表示されなくなります。
    
• SQLを確認すると、このクエリでは customer テーブルがFROM句（ベースビュー）として選ばれています。
  
• JOINの設定を振り返ると、join_from_view（結合の起点）が tran になっています。つまり、「tran → customer」という方向の結合は有効ですが、customer が起点（ベースビュー）になった場合の逆方向の結合が制限 されています。
  
• このような双方向からの結合を許可したい場合に、reversible オプションが役立ちます。

reversibleオプションについて

• reversible は、テーブル間の結合を「双方向」で利用可能にするかどうかを制御するオプションです
• このオプションには、relationship_typeに応じて以下の特徴があります。
  • many_to_one: 意図しないデータの重複（ファンアウト）を防ぐため、デフォルトではオフになっています
  • one_to_many: 実態は many_to_one の reversible をオンにした状態と同じであり、意図的にファンアウトを許容する設定です
  • one_to_one: どちらから結合しても行数は変わらない（列が増えるだけ）ため、常にオンとして扱われます
  • many_to_many: どちらから結合してもデータの形状が変わるのが前提の関係であるため、デフォルトでオンになります

• なお、ここで言う「意図しないデータの重複」とは、例えば1行1ユーザーの customer テーブルに対し、1ユーザーが複数行（複数決済）持つ tran テーブルを結合するケースを指します。
• このとき customer をベースに結合すると、結果のデータセットはユーザー単位で見ると複数行に増殖（ファンアウト）してしまいます。reversible は、こうしたデータの変形を意図的に受け入れるかどうかを設定するオプションとなります

公式Doc：reversibleパラメーター

reversibleオプションをオンにした場合の挙動について

• 今回のケースで、reversibleオプションをオンして動きを確認してみます
• 先ほどのJOINの設定を開き、reversibleオプションをオンにしてUpdateします
  
• 続いて、 「customer テーブルから Customer ID Count Distinct を選択」 → 「tranテーブルからitem_kbnを選択」 の順でクエリを作成しました
  • 今回はtranテーブルからアイテムを選ぶことができ、欲しい結果が得られています
    
• この状態でSQLを確認。customer テーブルがFROM句（ベースビュー）として選ばた状態で、JOINが作成されていることが確認できます
  

補足：実際にファンアウトして意図しない結果がでるのか？

• 例えば今回のケースのように、1人1行としたcustomer テーブルが増殖してしまい、レコード数＝ユーザー数の結果はSQLレベルではファンアウトしています
• ただし、Omniではプライマリーキーとrelationship_typeを正しく設定することで、シンメトリック集計が行われ意図しない結果を防げます！
• 実際に結果を確認しましょう。customerテーブルのレコード数は、ファンアウトしてtranテーブルのレコード数と一致するはずですが、Omni上ではOMNI_SYMMETRIC_COUNTが適用され、1人1行とした場合のレコード数が表示されています
  
• つまり、プライマリーキー!relationship_type！大事なので正しく設定してね！ということです

公式Doc：シンメトリック集計によるファンアウトの処理

Topicから分析したときの挙動について

• Topicsは、ビジネスユーザー向けに、既にJOINの定義などを完了させた分析環境を提供できる機能です
• Viewテーブルから分析したときとどう変化があるか確認するので、先ほど設定したreversibleオプションはオフに戻しておきます
• ここではTopicsの作成方法については割愛しますが、事前にtranテーブルをベースに、customerテーブルと結合したTopicを作成しています
  
• 作成したTopicを選択し、クエリを作成します
  • 今回は、いきなり 「customer テーブルから Customer ID Count Distinct を選択」 → 「tranテーブルからitem_kbnを選択」 の順でクエリを作成しました
  • そうすると、問題なくクエリの結果が得られました！
  • 今回注目してほしいのは、customer テーブルから分析を開始したのにも関わらず、FROM句（ベースビュー）にtranテーブルが選択されている、という点です
    
• つまり、Topicではベースビューをtranテーブルとして、結合した状態のデータセットを事前に作成するので、このような挙動になっています
• 分かりやすく言うと、tranテーブルの項目を選ばなくても常にJOINの定義だけはされた状態でクエリされます
  

参考：Topics関連ブログ「OmniのTopicsを作成してユーザーフレンドリーかつセキュアなBI基盤を作成する」

さいごに

今回は、JOINした際の挙動を一つ一つ紐解いて確認したことで、Omni上での動きがかなりよく理解することができました。
結論、ユーザーにはViewテーブルベースで自由に分析させるのではなく、分析をさせる場合は必ずTopicsから分析させるようにするというのがベストプラクティスだと思っています！