Power BI における「データモデリング」について @ Power BI 勉強会 for Beginners | 2019.09.14

スズキ レイ Twitter : @_suzukirei 現在はとあるグローバル企業の事業企画部門に所属 • Power BI を使った事業データの分析 • 社内における Power BI の布教活動 • Office365 の活用推進 • RPA（UiPath）の活用推進 ビジネス側でITやっているので情シスとは常に戦争状態。 社内はみんな ITチンパンジー。 そんな「猿の惑星」で不毛な争いを繰り返す毎日。

弊社の取り組み 今年はじめから全社で Power BI の本格的な活用開始。 社内で推進体制を構築し、データドリブン経営の実現をする! ・・・はずだった。 • 3Q たった今もこれといった成果なし • Power BI を使いこなせる人がなかなか育たない • Excel や Access のスキルがある人も躓く General User 共有レポートの閲覧のみ（300名） Power User データウェアハウスへの接続可能（30名） Middle User Power BI Desktop でレポート作成可能（70名） どうやら、ある「概念」が理解できていない?

今日のテーマ 皆さんが業務で手にするデータは、ほとんどの場合、データ分析用の形になってない! Power BI でデータ分析をするためにはデータを分析用に加工したり整形しなければならない! つまり、『 データモデリング 』をする必要がある。 Dim Table Dim Table Fact Table Dim Table Dim Table Dim Table Data Source Data Model データモデリング

データモデリング とは?

データモデリングとは? データモデリングとは、ある方法論に従ってデータを構造化していくことであり、広義には、あらゆるデータソース （文書ファイル、ハイパーテキスト、オブジェクトデータ等）と関連付けの方法による構造化が対象となりますが、 狭義にはリレーショナル・データベースの関係モデル（関数従属性）を使って事業のデータ構造を表すことです。 データモデリング → データを関係性も含めて構造化すること データモデル → 構造化されたデータの塊 『 データモデリング ～佐藤正美氏、若手エンジニアにデータモデリングを語る～ 』より

例えるなら データモデルは例えるならドラマや小説の登場人物相関図のようなもの。 それぞれの登場人物（テーブル）の定義やその関係（リレーション）を構造化したもの。 ≒ ©小学館

データモデリングの適性 データモデリングには目的に応じて様々な手法があります。目的に合わないモデリング手法を採用すると その後の集計や可視化でうまくいかなくなることが多くなります。 Single Big Table（大福帳モデリング） 業務システムそのまま（ERモデリング） A B C D E F G H … ZZ 1 2 3 4 5 … 9999 • 一行に属性と値すべて情報を記録する大きなテーブル • Access & Excel 族がよくやる → クエリが重くなる、拡張性が低い、集計が複雑になる Master Table Code Table Data Table Data Table Data Table Master Table Master Table • 業務システム（OLTP）のデータモデルをそのまま再現 • Data Lake から取得したデータでやりがち → 拡張性が低い、構造が理解しづらい

ディメンショナルモデリングのすすめ

分析の基本概念 物事は見る角度によってその見え方が違う。 事実（Fact）の全体像を把握するためには様々な次元（Dimension）から検証する必要がある。 Fact

ディメンショナルモデリングとは? ラルフ・キンボール氏によって理論化されたデータ分析のためのモデリング手法。 ファクトテーブルを中心にディメンションテーブルを周囲に配置する スタースキーマ を基本とする。 Fact Table Dim Table Dim Table Dim Table Dim Table Dim Table 分析対象となる データ 分析断面となる データ Dim Table • 分析対象となるデータのテーブルを ファクトテーブル として中心に配置 • 分析断面となるデータのテーブルを ディメンションテーブル として周囲に配置 • ファクト から ディメンションに対して 多対一 のリレーションを設定

ファクトテーブル と ディメンションテーブル ファクトテーブル ディメンションテーブル 内容 出来事や状態を記録したデータ ≒ トランザクションデータ 例）売上、在庫、注文、契約など 物事を定義したデータ ≒ マスターデータ 例）部署、社員、製品、日付など 目的 集計 フィルター、グループ化 構造 集計可能な値の項目と ディメンション側でキーとなる項目 ファクト側に対応する一意のキー項目と 属性を記述した項目 スタースキーマを作成するためにはデータを分析対象となる ファクトテーブル と 分析の断面（切り口）となる ディメンションテーブル に適切に分けることが重要となります。

その他のスキーマ スノーフレークスキーマ Fact Table Dim Table Dim Table Dim Table Dim Table Dim Table ギャラクシースキーマ Dim Table Dim Table Fact Table Dim Table Dim Table Dim Table Dim Table Dim Table Dim Table Dim Table Fact Table ディメンショナルモデリングにはスタースキーマ以外にもいくつかスキーマがあります。 • ディメンションテーブルが正規化されているスキーマ • 公式ドキュメントにはあまりおすすめしないと書いてある • 粒度の違うファクトテーブルを中間テーブルでつなぐ • 予算と実績、売上と原価、などで使われる

ディメンショナルモデリングにすべき理由 • パフォーマンス = フィルタやグループ化、集計処理が最適化される • 拡張性 ＝ 要件の追加に対応しやすい • わかりやすさ = モデルの構造を作成者以外が見ても直感的に理解できる ※ 公式サンプルでもデータセット８個中、スタースキーマ ４、スノーフレークスキーマ ３、ギャラクシースキーマ １

まとめ • 業務で取得できるデータは分析用になってないことが多い • 必ず分析用に「モデリング」をすること • データ分析のモデリング手法は「ディメンショナルモデリング」がおすすめ • 「スタースキーマ」が基本 • テーブルをファクトとディメンションに適切に分け、リレーションを設定すること • メジャーを定義するところまでがモデリングです • そのために Power Query や DAX をしっかりと使いこなせるようになること • この知識は Modern Excel においても重要になります • とにかくサンプルデータを自分で作っていろいろ試してみましょう!

Q & A

Q & A Q : データモデリングのオススメの本があれば教えてください。 分析のデータモデリングに関する初心者向けの書籍は私の知る限りはではないです。 エンジニア向けで一番有名なのはラルフ・キンボール著『データウェアハウス・ツールキット』ですが、 これはデータウェアハウスの設計理論書なので内容はとても難しいです（しかも日本語版は絶版）。 今回参考にしたスライドやWebサイトなどは以下で共有いたします。 • スター スキーマと Power BI での重要性を理解する（公式ドキュメント） https://docs.microsoft.com/ja-jp/power-bi/guidance/star-schema • ディメンショナルモデリングのすすめ（スライド） https://speakerdeck.com/ojima_h/deimensiyonarumoderingufalsesusume • ディメンショナルモデリング:スタースキーマ https://el.jibun.atmarkit.co.jp/dwbi/2011/06/5-d4bd.html

Q & A Q:業務システムのデータをPowerBIに入れる場合、モデリングでどこまでをSQLの世界でViewをつくってやるか、 どこからをPowerBIの世界で「モデリング」をやるかで迷うのですが、何かアドバイスはありますか? 同様のご質問をいくつかいただいたのでまとめて回答します。 正確には、御社のデータ活用の運用体制やアーキテクチャ、あなたのユーザ権限、分析対象となるデータの構造、 などなどによりベストな方法は変わるので「場合によります」が答えなのですが、あえて言い切るのであれば、 なるべくデータソース側、つまり Power BI に取り込む前のデータベースサーバやETL処理の過程において モデリングをしてしまったほうがパフォーマンス上は有効だと思います。

Q & A Q:システムからデータを持ってくる場合、複合主キーになっていることがほとんどかと思います。 一方でPowerBIでは複数キーでのJOINはできないとの理解です。対象方法についてアドバイス欲しいです。。 複合主キーを一つに統合して新たな主キー列を作成します。 それをデータソース側（SQL Server で View作成など）でやるか、Power Query でやるか、DAXでやるか、 という問題がありますが、パフォーマンス上はなるべくデータソース側、次に Power Query というのが 最近、Microsoftの中の人から示された見解です。 YouTube : Where to create your columns in Power BI https://www.youtube.com/watch?v=ZSUCmi6h5SY

Q & A Q:スノーフレークをやめた方が良いとのことですが、その場合、複数Dim tableをJOINしたViewを 作っておくということでしょうか? やめた方が良いというわけではないのですが、パフォーマンスが落ちると公式ドキュメントに書いてありました。 ディメンションテーブルはできればフラット化（非正規化）して一つにまとめたほうがよいようです。 ※ もちろん場合によるので絶対ではないです。 Q:モデリングについては、BIにおいて一般論でしょうか。 BIツールと呼ばれるものの中には、１テーブルしかない ものなどもあります。 最近のBIツールはディメンショナルモデルを前提としているものが主流なので「一般論」だと思います。 もちろん１テーブルにモデリングする製品でも要件が満たされるのであれば問題ないと思いますが、 高度なデータ分析をするためにはディメンショナルモデリングができる必要があります。

Happy Modeling !