LoginSignup
19
7

More than 1 year has passed since last update.

Power BIで複合主キーを扱う

Last updated at Posted at 2020-04-21

本記事の目的

Power BIを使っていて意外だったことに、「複合主キーに対するリレーションがはれない」ということがありました。
社内の業務システムでは複合主キーが多用されていて、結構困ります...。

他の方がどのように対処されているか気になっていますが、現状、解決策を残しておきますが、少し手間がかかります。
もっと賢い方法がありましたらアドバイスよろしくお願いします。

複合主キーとは

複合主キーとは複数のキーの組み合わせからなる主キーのことです。
(データモデルについては 別記事 で投稿しました。)

例として、全社で管理されている以下のような課題リストを想定します。
スクリーンショット 2020-04-21 23.06.36.png

ここでは様々なプロジェクトの課題を1つの表で管理しています(混沌)。

XXXプロジェクトとYYYプロジェクトでは、同じ課題ID「001」があります。
つまり課題のIDはプロジェクトごとに、別々に採番されていることが分かります。

言い換えると、この会社では「プロジェクト」と「課題ID」の両方を聞いて初めて、どの課題のことを指しているのか特定することができます。
スクリーンショット 2020-04-21 23.13.14.png
このとき主キーは「プロジェクト」と「課題ID」の組み合わせになり、このように2つ以上のキーからなる主キーのことを複合主キーと呼びます。

複合主キーによる結合

ここでもう一つ表を登場させます。
課題に対してどのようなアクションをとったかを管理するリストです。
スクリーンショット 2020-04-21 23.26.47.png

この表を見れば、どの課題に対してどのような対応をしたかが分かります。
ただしこの表には「課題内容」がないので、必要であれば先ほどのリストを参照しなければいけません。つまりこういうことです。

スクリーンショット 2020-04-21 23.32.01.png

課題対応リストにある手がかり(=外部キー)を使って、課題リストから必要な項目を参照し、取得することができます。

データベースの世界(SQL)では当然これができます。

join.sql
SELECT *
FROM 課題リスト JOIN 課題対応リスト
ON 課題リスト.プロジェクト = 課題対応リスト.プロジェクト
AND 課題リスト.課題ID = 課題対応リスト.課題ID

いくつ結合のための項目が増えようが、ANDでつなげてしまえばOKです。
ただしPower BIでは、残念ながらこれができません。

Power BIでの結合

Power BIでできるテーブルの結合は、1つのキーを使った結合のみです。
具体的にはこういう形です。

結合.PNG

上の例では2つのテーブルが1つのキーのペア「部門コード(所属部門コード)」を使って結合できています。

では2つのキーを使って結合しようとすると...そもそもできません。
スクリーンショット 2020-04-22 0.03.17.png

Power BIで複合主キーを扱う

考え方

解決策は、複合主キーを構成する複数項目を文字列連結するしかなさそうです。
事前にデータを加工する、ということです。
こうすれば、1つのキーで結合出来るようになります。
スクリーンショット 2020-04-22 0.31.20.png

もちろん、結合したいテーブルの数だけ同じ処理をする必要があります。
スクリーンショット 2020-04-22 0.31.26.png

操作手順

幸いPower BIにはPower Queryエディタという便利なツールがあるので、GUI操作で項目の文字列結合ができます。「列のマージ」を使います。

列のマージ1.PNG

これで2つの主キーが連結されて、複合主キーからシンプルな主キーになりました。
列のマージ1.PNG

ここまでの準備が完了すれば、あとは文字列連結した新しい主キーを使って、テーブル間を結合するだけです。

結合2.PNG

おまけ

文字列連結する前の元々の項目も重要な意味を持つ場合には、マスタテーブルを作っておくと便利そうです。
列のマージ3.PNG
これでマスタテーブルを結合しておけば、元のテーブルの項目「プロジェクト」や「課題ID」でスライサーを作ることもできるようになります。
列のマージ4.PNG

余談

複数テーブルを持つデータモデルを扱う場合、複合主キーはごくごく一般的であるため、Power BIで複合主キーによる結合ができないことは、個人的には意外でした。

Power Queryも確かに便利ですが、以下のような使い分けを意識しつつ、全てをPower BI側に寄せるのは避けた方が良いのかなと思います。

Power BI側では特定の目的のためのデータ加工を行う

Power BIはあくまでData Martの位置付けとして、特定のユーザが特定の目的で実施するデータ加工を行う。データ加工はPower Queryを使いながら頑張る。

共通で利用されるデータ加工はData Warehouse側で実施

複数の部門やユーザが共通的に行うデータ加工をPower BI側で各自で行うと効率が悪い。多くの利用者が共通に実施するようなデータ処理は、主にIT部門が担当するData Warehouse側に寄せる。(Microsoft製品でいえばAzure Synapseなど)

とはいえ、そのデータ加工が「特定の目的」なのか「共通の目的」なのかは当初は分からないことが多そうです。なので、はじめはPower BI側で実装してみて、共通に利用されそうであれば(あるいはどこかのタイミングで棚卸しをして)Data Warehouse側に組み込む、という流れになるのかなと思います。

19
7
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
19
7