Power BIの差別化要素2 -モデリング機能

Power BIの差別化要素その2は、モデリング機能となります。実は、BIツールのテクノロジーはそれぞれ異なることから、モデリングについての比較は料金体系(コスト)やビジュアル(グラフ)の良し悪しと比較すると、殆ど言及されていないのが現状です。しかしながら、実際にツールを使用し始めると、モデリング機能がBIレポートのクエリパフォーマンス、DAX式の書き方の難易度、使い勝手等の点において最も重要な要素となってきます。今回はPower BIにおけるモデリング機能とは何かについて解説していきます。

f:id:marshal115:20210421224032p:plain

  •  ツール費用(無料)
  • モデリング機能(データモデル、複合モデル)
  • ETL機能( Power Queryによるステップ記録機能で完全自動化)
  • Excelで分析」機能
  • 時系列操作関数の扱いやすさ
  • 関数言語(Excelから継承した関数の数々)及びクエリ言語
  • 計算エンジン(SSAS Tabularモデルをベースとした強力な分析エンジン)
  • Microsoftの他のサービスとの連携
  • 1つのテクノロジー(BIとしてのExcel
  • SaaS型BIソリューション

モデリング機能

Power BIやExcel Power Pivotを使用する場合、データモデルという言葉が出てきます。データモデルは以前の記事で分析・レポーティング用に複数のデータセットに関係性を持たせたものと解説しています。

AccessRDB*1を知っている人は分かると思いますが、テーブル同士(=データセット同士)にリレーションを張った状態がデータモデルとなります。データモデルには様々なパターンがありますが、スタースキーマスノーフレークが最も有名でしょう。(下記説明は専門的なものになるため、不明の方は読み飛ばして頂いても構いません)

f:id:marshal115:20210421224403p:plain

上図はスノーフレーク(左)とスタースキーマ(右)ですが、見ての通り、スノーフレークは取引テーブル(Sales)に対して複数のディメンションテーブル*2同士までも紐付けられた状態(dCategory-dSubCategory-dProduct)のものであり、一方のスタースキーマは複数のディメンションテーブルが直接Salesとリレーションが構築された状態のモデルとなります。

なお、上の例はスノーフレークを非正規化することで、データモデルをスタースキーマに変換した結果を表したものです。スタースキーマはBIレポートを作る際に最も重要なモデリングであるため、データモデルがスノーフレークとなっていた場合、可能な限りスタースキーマに変換することが推奨されます。

ここまで説明して、あまり意味を理解できない方は下記だけ覚えておいてください。Power BIにおいて、

スタースキーマモデルを作ることがベストプラクティス

であり、如何なる時もスタースキーマに拘ってください(下図も同様)。

f:id:marshal115:20210421235112p:plain

複数のファクトテーブル

スタースキーマは下図のように、真ん中のファクト(取引実績)テーブルを周りのDim(ディメンション)テーブルが”スター”の形で囲んでいることから名前が由来しています。

f:id:marshal115:20200416005230p:plain

売上実績だけであれば、上記のような形になりますが、ビジネスの世界では在庫、仕入、その他様々な形でファクトテーブルが存在します。そのため、複数のファクトテーブルを更に多くのディメンションテーブルが囲うことも珍しくなく、むしろ現実世界ではこちらが普通となります。気が付ければ、下記のような複雑(そう)なモデルが出来上がっていたこともあり得ます。

f:id:marshal115:20210422000336p:plain
こちらの例では、ファクトテーブルが計6つあり、計算されたテーブル(Calculated Table)*3を含めれば7つも存在します。

複雑そうに見えますが、実際には最初からこのような複雑なモデルになっているわけでなく、完成品・仕掛品・原材料・部品・売上実績等の取引実績が増えたことがファクトテーブルの増加要因であり、結果としてこれらのテーブルに紐づくディメンションテーブルも増加したのです。

ただし、このモデルが本当に複雑かどうかと言えば、作った本人から言わせると「スタースキーマ」に併せて作っているため、複雑そうに見えるだけで実は難しくない、ということになります。

Power BIの強みは、これらのテーブル同士を同じ切り口(あるいはテーブル内)で同時に見ることが可能なことであり、そのためのモデリング機能があるから、差別化要因となっているのです。

同じ切り口から分析

上記複雑(そう)なデータモデルを分かりやすくしたのが下図になります。この例では、①~④までは全て取引実績であり、図の通り、時系列ベースでは同時に推移を見ることができます。

f:id:marshal115:20210422001735p:plain

このモデリング機能を持っていない場合、下図(左)の「通常のExcel」のように、データを集計してPivotを作っても、別々のテーブルでしか結果を見ることができず、VLOOKUP等の関数で紐付けを行う必要が出てきます。

一方、データモデルを活用すれば、ディメンションテーブルが両方のファクトテーブルの項目を同時にフィルターしてくれるため、Excelの例で言えば1つのPivotを作れば2つの指標を同時に観測することができるようになるわけです。

f:id:marshal115:20210422002535p:plain

上記はExcelで解説を行いましたが、実はExcelもPower BIと同じ機能(データモデル)を持っており、残念ながらExcelが実はBIツールであることを知っている人は殆どいないのが実情です。

このように、データモデルは複数のテーブルを(理論的に)結合し、同じ切り口で分析を可能にしてくれますが、タースキーマとして構築されたデータモデルは更にクエリパフォーマンスがスノーフレークよりも高くなることが重要となります。データモデルのテクノロジーはインメモリデータベース*4であり、データの圧縮効果も得られることから、Power BIを使う大きなインセンティブの1つであると言えます。

まとめ

  • データモデルはPower BIにおける差別化要因の1つ
  • 理由は複数のテーブルにリレーションを張ることができ、パフォーマンスの最適化及び分析の切り口を増やしてくれる等が挙げられる
  • 如何なる時でも、スタースキーマがベストプラクティスである
  • データモデルはPower BIでも、Excelでも使用することができる

Power BIの差別化要因のうち、データモデルが大きな割合を占めていることを殆どの人は知りません。なぜならば、Power BIを単なる可視化ツールとして利用している場合、複雑なモデルを作る必要がないためです。Power BIのヘビーユーザー、あるいは常にビジネス上の問題をBIで解決する必要がある人は、データモデルの構築にも細心の注意を払っており、正しいモデリングがその後のDAXの書き方を簡単にしてくれるだけでなく、BIレポートの動作パフォーマンスまでも最適化してくれることを知っています。

*1:Relational Databaseの略

*2:商品マスタ、日付テーブル、店舗マスタ等

*3:既に存在するファクトテーブルやディメンションテーブルを使って、DAX(Data Analysis eXpressionの略、Power BIの言語)で新たにテーブルを作り出したテーブル

*4:データを全てメモリ上に読み込み、アクセス速度を最速化にしたテクノロジー