データ モデリングの主要概念について説明する
分析モデルを使用すると、分析をサポートするためにデータを構造化できます。 モデルは、関連するデータ テーブルに基づいており、分析またはレポートの対象である数値 ("メジャー" と呼ばれる) と、それらを集計するエンティティ ("ディメンション" と呼ばれる) を定義します。 たとえば、モデルには、売上 (収益や数量など) の数値メジャーと、製品、顧客、時間のディメンションを含むテーブルが含まれる場合があります。 これにより、1 つ以上のディメンションにわたって売上メジャーを集計できます (たとえば、顧客別の合計収益を識別したり、1 か月あたりの製品別に販売された商品の合計を識別したりします)。 概念的には、モデルは多次元構造を形成します。これは一般に "キューブ" と呼ばれます。この構造では、ディメンションが交差するポイントは、それらのディメンションの集計メジャーを表します。
Note
通常、分析モデルは "キューブ" と呼ばれますが、3 次元より多い (または少ない) 可能性があります。3 つ以上を視覚化するのは簡単ではありません。
テーブルとスキーマ
"ディメンション" テーブルは、数値メジャーを集計するエンティティ (製品や顧客など) を表します。 各エンティティは、一意のキー値を持つ行によって表されます。 残りの列はエンティティの属性を表します。たとえば、製品には名前とカテゴリが含まれていて、顧客には住所と都市が含まれています。 ほとんどの分析モデルでは、"時間" ディメンションを含めて、時間の経過とともにイベントに関連付けられている数値メジャーを集計できるようにするのが一般的です。
モデルのさまざまなディメンションによって集計される数値メジャーは、"ファクト" テーブルに格納されます。 ファクト テーブルの各行は、数値メジャーが関連付けられた記録済みのイベントを表します。 たとえば、次のスキーマの Sales テーブルは、個々の商品の売上トランザクションを表し、販売数量と収益の数値を含めます。
この種類のスキーマは、ファクト テーブルが 1 つ以上のディメンション テーブルに関連しているため、スター スキーマと呼ばれます (1 つのファクト テーブルに関連する 5 つのディメンションがあると想像してください。スキーマは 5 つの角を持つ星になります)。 さらに詳細を含む追加のテーブルに関連するディメンション テーブルにおいて、より複雑なスキーマを定義できます (たとえば、Product テーブルに関連する別個の Category テーブルで、製品カテゴリの属性を表すことができます。この場合の設計は、スノーフレーク スキーマと呼ばれます。ファクトとディメンションのテーブルのスキーマは、分析モデルを作成するために使用されます。このモデルでは、すべてのディメンションのメジャー集計が事前に計算されるため、分析とレポートのアクティビティのパフォーマンスが、毎回集計を計算するよりもはるかに高速になります)。
属性階層
分析モデルについて最後に考慮すべき事項は、階層ディメンション内の異なるレベルで集計された値をすばやく "ドリルアップ" または "ドリルダウン" できる属性 "階層" の作成です。 たとえば、これまでに説明したディメンション テーブルの属性について考えてみましょう。 Product テーブルでは、各カテゴリに複数の名前付き製品が含まれる階層を形成できます。 同様に、Customer テーブルでは、各都市の複数の名前付き顧客を表す階層を形成できます。 最後に、Time テーブルで、年、月、日の階層を形成できます。 モデルは、階層の各レベルに対して事前に集計された値を使用して構築できます。たとえば、年別の売上合計を表示し、ドリルダウンして月別の売上合計の詳細な内訳を表示することで、分析の範囲をすばやく変更できます。
Microsoft Power BI での分析モデリング
1 つ以上のデータ ソースからインポートできるデータのテーブルから分析モデルを定義するには、Power BI を使用します。 次に、Power BI Desktop の [モデル] タブのデータ モデリング インターフェイスを使用して、分析モデルを定義できます。ファクトおよびディメンション テーブル間のリレーションシップの作成、階層の定義、テーブル内のフィールドのデータ型と表示形式の設定、その他のデータ プロパティの管理などにより、分析用に充実したモデルを定義できるようになります。
