はじめに
優れたセマンティック モデルの作成は、データ アナリストが Microsoft Power BI で実行できる最も重要なタスクの 1 つです。 このジョブを適切に行うことで、データを理解しやすくなり、役に立つ Power BI レポートの作成が容易になります。
このモジュールに含まれているページは教育目的であり、データ ファイルは提供されません。 ラボで実際のデータを使用する機会があります。
優れたセマンティック モデルには、次のような利点があります。
データの探索が高速になります。
集計を簡単に作成できます。
レポートの正確さが向上します。
レポートの作成にかかる時間が短くなります。
後でレポートを保守するのが容易になります。
すべてのデータは異なっていて、そのデータの使用方法も異なるため、優れたセマンティック モデルを作成するための決まった規則を示すことは困難です。 一般に、実行が高速で使用法が簡潔なため、より小さいセマンティック モデルが適切です。 ただし、より小さいセマンティック モデルとはどういうものかを定義することは、ヒューリスティックで主観的な概念であるため、同様に困難です。
通常、より小さいセマンティック モデルの構成では、ユーザーが表示できるテーブルがより少なく、各テーブルの列もより少なくなります。 すべての必要なテーブルを営業データベースからインポートしたとしても、テーブルの数が全部で 30 個もあっては、ユーザーにとって直観的であるとはいえません。 それらのテーブルを 5 個に圧縮すると、セマンティック モデルはユーザーにとって直観的になりますが、テーブルを開いて 100 列表示されると、ユーザーが圧倒される可能性があります。 必要のない列を削除して管理しやすい数にすると、ユーザーがすべての列の名前を読む可能性が高くなります。 まとめると、セマンティック モデルを設計するときは簡潔さを目指す必要があります。
次の画像は、セマンティック モデルの例です。 ボックスにはデータのテーブルが含まれ、ボックス内の各行項目は列です。 ボックスを接続している線は、テーブル間のリレーションシップを表します。 このような単純なモデルでも、これらのリレーションシップは複雑になる可能性があります。 セマンティック モデルは簡単に無秩序になる可能性があり、モデル内のテーブルの合計数が徐々に増える可能性があります。 セマンティック モデルを簡潔で、包括的で、正確な状態に保つには、継続的な作業が必要です。
テーブル間のリレーションシップは、主キーと外部キーによって定義されます。 主キーは、一意の null ではない各データ行を識別する列です。 たとえば、Customers テーブルがある場合、一意の各顧客を識別するインデックスを作成できます。 最初の行の ID は 1、2 番目の行の ID は 2、というようになります。 各行には一意の値が割り当てられ、この単純な値つまり主キーによって参照できます。 異なるテーブルの行を参照するときは、このプロセスが重要になります。それを行うのが外部キーです。 異なるテーブルの間に共通する主キーと外部キーが存在していると、テーブル間にリレーションシップが形成されます。
Power BI を使用すると、データ ソースが異なるテーブルの間にリレーションシップを作成できます。これは強力な機能であり、1 つのテーブルは Microsoft Excel から取得し、もう 1 つはリレーショナル データベースから取得できます。 次に、それら 2 つのテーブルの間のリレーションシップを作成して、統合されたセマンティック モデルとして扱います。
データ スキーマを構成するリレーションシップについて学習したので、スキーマ デザインの 1 つの種類であるスター スキーマを調べることができます。これは、ハイ パフォーマンスと使いやすさに最適化されたスキーマです。
スター スキーマ
スター スキーマを設計して、データを簡素化することができます。 データを簡素化する方法はこれだけではありませんが、よく使用される方法です。そのため、Power BI を使用するすべてのデータ アナリストは、それを理解しておく必要があります。 次の図で示すように、スター スキーマでは、セマンティック モデル内の各テーブルが、ディメンションまたはファクト テーブルとして定義されます。
ファクト テーブルには、販売注文、製品数、価格、トランザクションの日時、数量など、観測データまたはイベント データの値が含まれます。 ファクト テーブルは、複数の値を繰り返し含むことができます。 たとえば、1 つの製品が、異なる日付で異なる顧客に対し、複数の行に複数回出現していてもかまいません。 これらの値を集計して、ビジュアルを作成できます。 たとえば、合計販売注文のビジュアルは、ファクト テーブルに含まれるすべての販売注文を集計したものです。 ファクト テーブルには、数値と日付が格納されている列が含まれるのが一般的です。 数値は、売上高などの測定単位であったり、顧客 ID などのキーであったりします。 日付は、注文日や出荷日など、記録されている日時を表します。
ディメンション テーブルには、ファクト テーブルのデータに関する詳細 (製品、場所、従業員、注文の種類など) が含まれます。 これらのテーブルは、キー列を介してファクト テーブルに接続されます。 ディメンション テーブルは、ファクト テーブル内のデータをフィルター処理およびグループ化するために使用されます。 一方、ファクト テーブルには、売上や収益などの測定可能なデータが含まれ、各行はディメンション テーブルの値の一意の組み合わせを表しています。 合計販売注文のビジュアルでは、製品ごとに合計販売注文が表示されるように、データをグループ化できます。ここで、製品はディメンション テーブルのデータです。
個々の売上など、ファクト テーブルでは多くのイベントが発生するため、ファクト テーブルはディメンション テーブルよりはるかに大きくなります。 フィルター処理やグループ化に使用できる項目の数は限られているので、通常、ディメンション テーブルのサイズは小さくなります。 たとえば、年に含まれる月の数は限られており、米国は特定の数の州のみで構成されます。
ファクト テーブルとディメンション テーブルに関するこの情報を検討すると、どうすれば Power BI でこのビジュアルを作成できるのだろうと思うかもしれません。
次のセマンティック モデルに示すように、関連するデータが Employee と Sales という 2 つのテーブルに存在します。 Sales テーブルには集計できる販売注文の値が含まれているので、これはファクト テーブルと考えられます。 Employee テーブルには、販売注文をフィルター処理する特定の従業員名が含まれるため、このテーブルはディメンション テーブルとなります。 2 つのテーブルに共通の列は、Employee テーブルの主キーである EmployeeID です。この列に基づいて、2 つのテーブル間にリレーションシップを確立できます。
このリレーションシップを作成する場合は、次の図に示すように、要件に応じてビジュアルをビルドできます。 2 つのテーブルの共通点を念頭に置きつつも、このリレーションシップを確立しなかった場合は、ビジュアルのビルドが難しくなります。
スター スキーマおよび基になるセマンティック モデルは、整理されたレポートの基盤です。これらの接続とデザインの作成に時間を費やすほど、レポートの作成と保守が簡単になります。