前段
Power BI のデータモデルは スタースキーマ を前提とする。
スタースキーマ にするということは、各テーブルを ディメンションテーブル と ファクトテーブル に分けることを意味する。
Power BI ユーザーであれば、何度も ↑ の公式ページを読んでいることでしょう。
- もしまだ読んだことがないという方は、読んでみよう。
- 内容がよくわからなくても、とにかく読んでみよう。
- 一読してわかる人なんていないのだから、読んでみよう。
- 読んだことある人も定期的に(数か月に一度)読み直してみよう。
定期的に読むことを勧めるのには理由がある。
最初は何を言っているのかわからなかった文章が、ある時わかるようになるからだ。もちろん、それには理由がある。ある時わかるようになる人は、その間、地道に Power BI を触り、実践してきた人だ。逆に言うと、地道にひとつずつベストプラクティスに従って、手を動かしてきた人は、最初はわからなかったことがわかるようになるのだ。
わかるようになることが、ひとつのバロメーターとなる。
Power BI を始めて数年間経つのに、上記の公式ドキュメントが理解できないということは、ベストプラクティスを無視してきた可能性がある。心当たりがある人は、"Power BI ベストプラクティス" で検索することから始めてみるといいかもしれない。個人的には以下の3つをまずは押さえることをお勧めする。
- スタースキーマ
- 日付テーブル
- タイムインテリジェンス
これらがわからないという方は、ひとつずつ学習していくのが、近道であり王道です。
【本編】よく聞かれるのです
さて、この記事の本編。
- 「ディメンションになりうるものはどんな値?」
- 「ディメンションに分けるものはどうやって判断するの?」
最初にスタースキーマを説明すると、必ずこういった質問をされる。
慣れてくると、ソースデータやローデータ (Raw Data) をじーっと見つめた時、これとこれをディメンションテーブルに分けなきゃだって、自然と判断ができるようになってくる。その時、自分の中でどうやって判断しているか、これを言語化するのは最初は難しかった。のだけど、今は次のように説明している。
ディメンションになりうる値
BI で使用するデータの値の種類を大別すると、以下の3つに分けられる。
- 日付(日付と時刻)
- テキスト(文字列)
- 集計対象の値(数値)
まずはこれを覚える。試しに手元のデータを上記の 1 ~ 3 に分けてみると、上記に当てはまるということがわかるでしょう。
上記の 3 つに分けることができたら、簡単。
ディメンションになりうるものは、1. 日付 と 2. テキスト です。
もし日付テーブルを理解していて、DAX で日付テーブルを作成しようと思っているのであれば、Power Query エディターでは、2. テキストのみに注目しましょう。
テキストにも種類がある
次に、テキスト (文字列) の分類。テキストには 短いテキスト と 長いテキスト がある。
- 短いテキスト:カテゴリーとして使用できるもの。商品名、分類などの名称、1行を一言で説明する単語等で、複数行に繰り返し登場する
- 長いテキスト:コメントなどの文、または文章。繰り返し登場しない
BI では長いテキストは使いづらい。BI の本来は、数値の集計。アンケート結果や広く意見を求めたデータなどでは、コメントは大事なものとなるが、1行ごとに値が異なるので、その文字列を集計することはできない。つまり、1行ずつ読むしかないのだ。あるいは、AI によってテキスト解析をして、文字列を何らかのデータに変換する必要が出てくる。よく言われる「ネガポジ分析」「ネガポジ判定」はこれに当たる。行ごとのテキストをひとつずつ、AI に渡して、文または文章が全体として、ネガティブ (否定的) なのかポジティブ (肯定的) なのかを数値化する。数値化することで、集計が可能になるということだ。
日常業務に必要な BI では、長いテキストは不要となることが多いので、今回は対象外とする。
接客業やサービス業で、日常的にアンケート回答を集めている場合もあるでしょう。そういった場合は、素のテキストが大きくネガティブに触れたことをトリガーとして、対応が求められる。つまり顧客対応のきっかけに気付くことができるように、データを利用して自動化するということ。BI ツールを利用することでこれが可能にもなるが、BI の本来の目的(=集計)とは少しズレるので、今回は例外とする。あしからず。
ということで、
「1列に繰り返し登場する短いテキスト(文字列)」
がディメンションになりうるということになる。
ディメンションって何に使うの?
BI では、グラフとしてビジュアライズする際に、各種の値を使用する。ディメンションに含まれる値も当然ビジュアルで使用されることになる。では、ビジュアル (グラフ) 上で、どんな風使用されるのか?
個人的観測だが、意外とこれが説明できない人が多い印象。なので、大事なことだと言える。
言葉で説明すると、ディメンションの値が使用されるのは以下となる。
- テーブルやマトリックスで区分として使う。集計値は区分ごとの値になる
- 棒グラフにて、底面に使用する。縦棒グラフなら X 軸。横棒グラフなら Y 軸。一方の軸に集計値を指定することで、ディメンションごとの値が集計される
- 各グラフにて、凡例として指定する。指定したディメンションごとに色が分かれる
- スライサーにして使用することで、ページのグラフにフィルターをかける
習うより慣れよ。順に見ていこう。
テーブル名 | 種類 | 備考 |
---|---|---|
Customers | ディメンション | 顧客テーブル |
Products | ディメンション | 商品テーブル |
Persons | ディメンション | 担当者テーブル |
Dates | ディメンション | 日付テーブル |
Sales | ファクト | 売上テーブル |
テーブルに集計値と共に使用することで、ディメンションごとの集計をする
[区分名] は Products テーブルの列
[受注額] は [Sales] テーブルの売上を合計するメジャー
[総計%] は [受注額] が総計に対して何%かを表すメジャー
このテーブルでは、区分名がディメンションテーブルの値なので、[区分名] ごとの [受注額] および [総計%] が集計されていることがおわかりいただけるだろう。もしこのテーブルから [区分名] を除くと、以下のようなビジュアルになる。
[区分名] がなくなったことで、ファクトである [Sales] テーブルの売上の総合計が [受注額] として表示され、[総計%] は 100% となる。テーブルに集計値 (メジャー) と共に使用することで、ディメンションごとの集計がされるとは、こういうことだ。
棒グラフの底面に使用する
ここでいう底面とは、棒グラフの棒の根元がどこから生えているか?である。従って、横棒グラフの場合は Y 軸が底面となる
X 軸に [区分名]
Y 軸に [受注額] メジャー
を指定している。
なお、データラベルには [総計%] を指定している。
勘のいい方はお気付きだろうが、先ほどのテーブルを縦棒グラフにしたイメージだ。
棒グラフの底面にディメンションの値を指定することで、ディメンションごとの集計値が棒の高さ(あるいは長さ)で表示される。
グラフの凡例として使用し、色を分ける
X 軸に [Dates] テーブルの [Month] 列
Y 軸に [受注額] メジャー
凡例に [Persons] テーブルの [所属] 列
をそれぞれ指定している。
凡例にディメンションテーブルの値を指定することで、「東京本社」「大阪支社」「北九州支社」と値の種類の数だけ、色分けを行うことができるわけだ。ちなみに X 軸に指定している [Month] 列も 日付テーブルである [Dates] テーブルの列なので、こちらもまたディメンションの値の使い方となる。
故に、'Dates'[Month] と 'Persons'[所属] の二つのディメンション (軸) によって、集計された値の大きさが、棒グラフの色を塗っていることになる。
スライサーにして使用することで、ページのグラフにフィルターをかける
スライサーの例なので、もう一度ページ全体を示す。
左上にスライサーが配置されており、'Dates'[Year] が指定されている。画像は [Year] = 2021 でフィルターがかかっていることになる。
スライサーの選択を変更することで、ページ上にある他のビジュアルにフィルターをかけることになり、データが集計されていることがわかる。スライサーにディメンションを指定することで、ユーザーがディメンションを自由に指定することが可能となり、BI の主要な機能であるインタラクティブなレポートを実現することになる。
まとめ
ディメンションの代表的な使用方法を紹介しました。
「こんなビジュアルが必要だから、こういうディメンションを用意する」
というのは、逆算的なアプローチとなる。
通常は、まずビジネスモデルやビジネスロジックに応じてデータモデリングをすることが、最初のステップとなる。そうして、ビジュアライズを進めていった後、どうしても必要な表現が出てきて、それにはこんなディメンションが必要だよねと、ディメンションテーブルを別途用意するということはある。
いずれにしても、ビジュアライズにおいて、ディメンションがどんなふうに使われるのか?を理解しておくことは、とても大事なことだ。
最後にひとつ。
この記事に書いたことが、スタースキーマが必要な 唯一の 理由ではないということは、勘違いされると困るので、付け加えておきたい。
今回は以上です。
皆様が学んだり、考えたりするきっかけになれば、幸いです🫡