注意事項

本情報は、2020年7月7日時点での結論です。
今後の状況の変化、新たな知識獲得により、変更となる可能性があります。

概要

Tableau 2020.02以降で追加されたデータモデル機能について、エンタープライズとしての展開・管理は難しいという結論に至りました。もちろん、いくつかの前提にした場合の評価となります。

エンタープライズとしての展開・管理について

セルフサービスBIとして不特定多数の組織メンバーに共有することとして捉えております。統合管理の可否が重要な要素となります。
本記事においては、下記に示すデータ分析プロセスにおける「2.データモデリング」にフォーカスをあてて記載します。

番号	大分類	中分類
1	データプリパレーション
2	データモデリング
3	データ活用	データ可視化、データ解析、シミュレーション

データ分析の進め方について

データ分析の進め方としては、下記図のように、分析テーマを決定しKGI・KPIにて管理する方法を前提とします。単一テーブルのではなく、複数テーブルの利用により分析することなり、いわゆるマルチファクト分析となります。

引用元：【難しく考えない】KGIを分解してKPIを作る方法。誰でもできる目標達成計画を解説

データモデリングについて

データモデリングにおいては下記の要素があり、すべてをデータセットを管理できることが理想なのですが、Tableauではファクト間のリレーションシップ（ブレンドリレーションシップを想定）、および、メジャーについてレポート単位で管理する必要があります。レポート（シート）単位での管理となる場合には、管理工数が増大する懸念があります。

番号	要素	理想の管理単位	Tableauの管理単位
1	データソース	データセット	データセット
2	テーブル	データセット	データセット
3	ディメンションとファクトのリレーションシップ	データセット	データセット
4	ファクト間のリレーションシップ	データセット	レポート（シート）
5	メジャー	データセット	レポート（シート） ※

※単一テーブルに対しては計算列を追加することデータセットで管理可能だが、マルチファクトの分析時（例：粒度が異なるテーブルで率を求める場合）にはデータセットでは管理不可能。

Tableauにおける問題点

データモデリングに観点において、データセットとして統合管理が難しいTableauでは、エンタープライズとしての導入に注意が必要です。

ファクト間のファクト間のリレーションシップをレポートごとに設定する必要があり、メジャー作成をレポート作成者に委ねる必要があります。
Excelでデータ分析を実施していた際と同様に、レポートごとに数値が異なる結果となりレポートの妥当性を疑われる事態が発生すかもしれません。

番号	要素	理想の管理単位	Tableauの管理単位
4	ファクト間のリレーションシップ	データセット	レポート（シート）
5	メジャー	データセット	レポート（シート）

下記にて、Tableauでのデータモデルを利用した想定の手順を紹介します。

Tableau データモデルとは

Tablaeu 2020.02以降に導入された、論理レイヤーを追加したTablaeuにおけるデータモデリングです。
従来は第一正規形でデータモデルを保持することが多かったですが、リレーションシップを考慮したデータモデルで実装できるようになりました。

引用元：Tableau データモデル

ただ、マルチファクト分析を行うには、ディメンションテーブルが1つしかないファクトテーブルでなければならないという制約があります。この制約を満たせるケースはあまりないため、実際にはマルチファクト分析は実施できないと捉えていただいた方がよいかもしれません。
下記図では、見通しは日付ディメンションテーブルとのみリレーションシップを構築しており、見通しを日付粒度でのみ保持していることを示しております。

なお、Tablaeuは別のデータモデルとして、リレーションシップを考慮可能なキューブデータソースがありますが、そちらは変更とならないようです。

引用元：キューブデータソース

ブレンドリレーションシップの安易な利用を避けるべき

ブレンドリレーションシップの利用でエラーとなる事態があるようで、状況によってマルチファクト分析の利用を避ける必要がありそうです。

下記に示す記事にて、ブレンドリレーションシップシップがインメモリ方針であることから、メモリで処理できない場合にはエラーとなるそうです。データ抽出とライブ接続のいずれの場合にも注意が必要となりそうです。

300,000 個を超える一意の値を持つフィールドに対してデータブレンドを実行すると、メモリ不足エラーが発生
　　
　　
データブレンドはデータベース結合エンジンではなく、異なるデータソースからのデータを視覚化するためのインメモリ方式です。

引用元:数百万個の行をブレンドする際のメモリ不足エラー

ある分析テーマを例にとると

データの概要

下記のメジャーを、それぞれのファクトテーブルとして保持しており、ファクトテーブルでの粒度が異なるデータモデルを例として検討します。

Tableau Desktopにてデータモデルの作成

上記ファクトテーブルを、それぞれのデータモデルとして実装します。

次に、ブレンドリレーションシップを設定し、シートに表現します。

Tableau Onlineにてデータモデルのパブリッシュと利用

データソースごとに、Tableau Onlineに配置可能です。

Tableau Desktopから、Tablaeu Onlineのデータソースを利用可能です。

まとめ

分析テーマを設定するエンタープライズ展開では、Tableauのデータモデルでは管理が難しいというお話をしました。もちろん、可視化ツールとしては、とても優秀であることは間違いありません。データモデルの重要性をご理解いただければと幸いです。

Tablaeu Onineにてデータソースの共有を実施可能ですが、保守性はあまりよくありません。ディメンションテーブル等に変更があった場合にすべてのデータソースを変更する必要があり、データソースが数百を超えることが予想されエンタープライズでの利用においてメンテナンスコストは高くなります。

他の手段として、キューブデータソースを利用する案も検討したのですが、Tableau ServerとTableau Onlineから利用するのは難しそうです。