Power BIのレポート作成に慣れてくると、複数のテーブルを扱う機会が増えてきます。そうすると、データに関するトラブルも少しずつ増えていきます。
たくさんのテーブルがある場合、Power BIにインポートすること自体はそれほど難しくありません。しかし、それぞれのテーブルを正しくリレーションさせなければ、データ同士の関連性を適切に設定することができません。
そのため、テーブルが増えてきた場合には、今一度、第37回で学んだファクトテーブルとディメンションテーブルの関係性を見直す作業が必要になります。場合によっては、テーブルそのものを変更しなければならないケースもあります。その場合は、Power Query上でデータを加工したり、そもそもインポートする元データの設定を変更したりする必要があります。
そこで今回は、リレーションの練習問題を3問用意しました。使うのは、これまでの回で登場したデータばかりですので、実際にPower BIで手を動かしてもよいですし、頭の中で考えるだけでも構いません。どのテーブルとどのテーブルを、どの列で関連付ければよいのか。まずは自分で考えてみてください。答え合わせは、このあとに書きます。
問題1。サンプルデータの「取引先マスタ」と「販売実績」に、第41回で作成したDAXの「カレンダー」テーブルを加えた、3つのテーブルがあります。どのテーブルとどのテーブルを、どの列でつなげばよいでしょうか。
問題2。練習データ「05_expense」の「経費申請」と「社員マスタ」に、同じく「カレンダー」を加えた3つのテーブルの場合は、どうでしょうか。
問題3。少し意地悪な問題です。「販売実績」と「経費申請」を両方インポートしたとき、この2つのテーブルを直接リレーションさせることはできるでしょうか。
それでは、答え合わせをしていきましょう。
問題1の答えです。「取引先マスタ」の「取引先名」と「販売実績」の「取引先名」を1対多でつなぎます。そして、「カレンダー」の「Date」と「販売実績」の「販売日」を、同じく1対多でつなぎます。マスタとカレンダーという2つのディメンションテーブルが、ファクトテーブルである「販売実績」を取り囲む。まさに、スタースキーマの形ですね。
問題2の答えです。「社員マスタ」の「社員ID」と「経費申請」の「社員ID」、「カレンダー」の「Date」と「経費申請」の「申請日」をつなぎます。ポイントは、社員の「名前」ではなく「ID」でつなぐことです。名前は同姓同名がありえますから、リレーションには、値が重複しない列、つまりキーとなる列を使います。
問題3の答えです。直接はつなげません。2つのテーブルには共通の列がありませんし、そもそもファクトテーブル同士を直接つなぐ形は、設計として避けるべきです。
では、どうするか。両方のテーブルが共通して持っている「日付」に注目します。「カレンダー」の「Date」から、「販売実績」の「販売日」と「経費申請」の「申請日」の両方に、1対多のリレーションを張るのです。こうすれば、カレンダーテーブルが共通のディメンションとして働き、「同じ月の売上と経費を並べたグラフ」のような分析ができるようになります。
今回は、Power BIの操作方法だけではなく、データベースにおけるテーブル同士の関係性についての学習でした。この考え方は、テーブルの数が増えて、リレーションが複雑になってきたときほど効いてきます。ぜひ、自分のデータでも「どれがファクトで、どれがディメンションか」を意識してみてください。