Tableau の LOD 表現が複雑すぎて誰も手を付けられなくなっていませんか？

詳細レベル（LOD: Level of Detail）表現は、真に複数の粒度（Grain）が混在する集計課題に対する正当なアプローチです。しかし同時に、上流から届いたデータの粒度が狂っている場合の「緊急パッチ」としても多用されがちです。そしてワークブックを脆く壊れやすいものにしているのは、まさにこの後者の使われ方です。

LOD 表現が何を肩代わりしてしまっているのか

• 特定時点の状態の復元： FIXED と日付ロジックを組み合わせ、ソース側で上書きされて失われた履歴を再現している。
• 欠落したディメンションの補完： 結合すべき適切な主キーが存在しないため、連結キーに対して FIXED を実行している。
• 1 つのテーブル内に混在する 2 つの粒度： 適切に設計されたファクトテーブルであれば発生しないデータの重複を、EXCLUDE で無理やり打ち消している。
• ブリッジテーブルのないリレーションシップ： 本来ブリッジテーブルが果たすべき多対多の解決を、INCLUDE が肩代わりしている。

これらはすべて、ビューが表示されるクエリ実行時に毎回評価されます。さらに複数のデータソースをブレンドすると、その計算負荷は何倍にも跳ね上がります。

なぜその負担がアナリストに押し付けられるのか

• その場しのぎの LOD 表現はどれも、その週の締め切りまでに正しい数字を出すための最短ルートでした。
• それらのロジックはワークブックの内部に隠蔽されており、外部のエンジニアからレビューされることも再利用されることもありません。
• アナリストは計算式の書き方を工夫できても、上流のデータウェアハウスに存在しないディメンションを追加することはできません。

本来その処理が行われるべき場所

• 履歴管理、サロゲートキー、粒度の確定はウェアハウスの責務： LOD 表現の中でこれらを処理すると、ビューを描画するたびにゼロから再計算されます。
• 1 箇所の中央基盤に集約すべき： データウェアハウスやデータハブ側で 1 度だけ解決し、すべてのワークブックが標準化されたテーブルを参照すべきです。
• 「DWH の改修は高額で時間がかかる」と思われるかもしれませんが： その見積もりは手作業でパイプラインを構築することを前提としています。専用の自動化プラットフォームを活用すれば、モデルからパイプラインが自動生成されるため、必要なコストと期間は劇的に圧縮されます。

完成したモデルが届いたときに変わること

Datavault Builder は、Snowflake、Databricks、BigQuery、Synapse、SQL Server、Oracle、Exasol、PostgreSQL 上のデータウェアハウス内で粒度、キー、履歴を根本解決します。

• PIT（Point-in-Time）テーブル： 「3 月時点の数値」といった過去時点の問い合わせを、複雑な LOD 式ではなく、単純なテーブル結合で瞬時に返します。
• ブリッジテーブル： Tableau が接続する前に、多対多のリレーションシップを上流側で解決します。
• 明示的なサロゲートキー： 文字列連結によるあいまいな結合ではなく、単一キーによる高速なリレーションシップが確立されます。
• ファクトテーブルごとの単一の粒度： データの二重計上が原理的に発生しなくなるため、EXCLUDE による辻褄合わせが完全に不要になります。
• 残る LOD は真にビジュアライズに必要なものだけとなり、同僚がひと目で理解できるほどシンプルになります。

上流チームに何を要求すべきか

「現在の LOD 表現は、特定時点の状態の復元や粒度の不整合をクエリ実行時に無理やり解決するために使われています。計算式を単純な集計で済ませられるよう、ウェアハウス側で PIT テーブルと単一粒度のファクトテーブルを整備してもらえませんか？」

このように伝えることで、本来必要だった LOD 表現と、データ構造の不備を補うために無理やり使っていた LOD 表現を切り分け、根本解決に向かうことができます。