カーディナリティを小さくする
カーディナリティは、列内の値の一意性を説明するために使用される用語です。 カーディナリティはモデル リレーションシップのコンテキストでも使用され、リレーションシップの方向を表します。
列のカーディナリティ レベルを特定する
以前は、Power Query を使用してメタデータを分析すると、表示 リボン タブの 列分布 オプションに、データの各列に含まれる別個かつ一意の項目の数に関する統計が表示されていました。
- 個別の値のカウント - 特定の列で検出された異なる値の合計数。
- 一意の値のカウント - 特定の列で 1 回だけ出現する値の合計数。
範囲内に多くの繰り返し値を持つ列 (一意な値の数が少ない) は、カーディナリティのレベルが低くなります。 逆に、範囲内に一意値が多い列 (一意な値の数が多い) は、カーディナリティのレベルが高くなります。
カーディナリティが小さいほどパフォーマンスが最適化されるため、セマンティック モデル内のカーディナリティの大きい列の数を減らすようにしてください。
リレーションシップのカーディナリティを小さくする
複数のテーブルをインポートすると、それらすべてのテーブルのデータを使用して分析を行うことが可能です。 それらのテーブル間のリレーションシップは、結果を正確に計算し、レポートに正しい情報を表示するために必要です。 Power BI Desktop では、これらのリレーションシップを簡単に作成できます。 実際、ほとんどの場合、自動検出機能によって自動的に実行されるため、何もする必要はありません。 ただし、場合によっては、リレーションシップを作成したり、リレーションシップを変更したりする必要が生じることがあります。 いずれにしても、Power BI Desktop におけるリレーションシップと、その作成および編集方法を理解しておくことが重要です。
リレーションシップを作成または編集するときに、他のオプションを構成できます。 既定では、Power BI Desktop はモデル データの評価に基づいて他のオプションを自動的に構成します。このオプションは、列のデータに基づいてリレーションシップごとに異なる場合があります。
リレーションシップには、さまざまなカーディナリティを設定できます。 カーディナリティは、リレーションシップの方向であり、各モデル リレーションシップは、カーディナリティの種類と共に定義する必要があります。 Power BI におけるカーディナリティのオプションは次のとおりです。
- 多対一 (*:1) - 最も一般的なリレーションシップです。 つまり、一方のテーブル内の列には、1 つの値の複数のインスタンスが存在していてもよく、関連するもう一方のテーブル (多くの場合、ルックアップ テーブルと呼ばれます) では 1 つの値のインスタンスは 1 つだけです。
- 一対一 (1:1) - 1 つのテーブルの列には特定の値のインスタンスが 1 つだけあり、もう一方の関連テーブルには特定の値のインスタンスが 1 つだけあります。
- 一対多 (1:*) - 1 つのテーブルの列には特定の値のインスタンスが 1 つだけ含まれますが、他の関連テーブルには値のインスタンスが複数含まれる場合があります。
- 多対多 (*:*) - 複合モデルでは、テーブル間に多対多のリレーションシップを確立できます。これにより、テーブル内に一意の値を含めるという要件は取り除かれます。 さらに、リレーションシップを確立するためだけに新しいテーブルを導入するなどの以前の回避策も取り除かれます。
開発中は、モデル内のリレーションシップを作成および編集します。そのため、モデル内に新しいリレーションシップを構築するときは、選択したカーディナリティに関係なく、リレーションシップに参加するために使用している両方の列のデータ型が同じであることを常に確認してください。 一方の列がテキスト データ型で、他方の列が整数データ型である 2 つの列の間のリレーションシップを構築しようとすると、モデルは機能しません。
次の例では、ProductID 列は Product テーブルと Sales テーブルの両方で整数データ型になっています。 データ型が整数の列は、データ型がテキストの列よりもパフォーマンスが向上します。
カーディナリティ レベルを低減してパフォーマンスを向上させる
Power BI Desktop では、集計など、セマンティック モデルに読み込まれるデータを削減するために使用できるさまざまな手法が提供されています。 モデルに読み込まれるデータを減らすと、レポートのリレーションシップのカーディナリティが向上します。 このため、モデルに読み込まれるデータを最小限に抑えるよう努めることが重要です。 これは特に、大規模なモデルや、時間の経過と共に大きくなることが予想されるモデルの場合に当てはまります。
モデルのサイズを縮小するための最も効果的な手法は、データ ソースの概要テーブルを使用することです。 詳細テーブルにはすべてのトランザクションが含まれる場合がありますが、概要テーブルには 1 日、1 週間、または 1 か月ごとに 1 つのレコードが含まれる場合があります。 たとえば、1 日あたりのすべての取引金額の合計などです。
たとえば、ソースの Sales ファクト テーブルには、注文明細行ごとに 1 行が格納されます。 日付、顧客、および製品別にグループ化し、個々のトランザクションの詳細を必要としない場合、すべての販売メトリックを集計することによって、大幅なデータ削減を実現できる可能性があります。
そこで、月レベルで集計することで、さらに大幅なデータ削減を実現できることを検討してください。 これによって、モデルのサイズを 99% 縮小できる可能性があります。ただし、日にちレベルまたは個々の注文レベルでのレポートは作成できなくなります。 ファクト データを集計する決定には、常にデータの詳細とのトレードオフが関係します。 欠点は、詳細が存在しなくなるため、データをドリルダウンする機能が失われる可能性があることです。 このトレードオフは、複合モデルを使用することで軽減できます。
Power BI Desktop では、複合モデルを使用して各テーブルのストレージ モードを決定できます。 このため、各テーブルのストレージ モード プロパティをインポートまたは DirectQuery として設定できます。
モデルのサイズを縮小するための効果的な手法は、大きなファクト テーブルの ストレージ モード プロパティを DirectQuery に設定することです。 この設計手法は、データの集計に使用される手法と組み合わると効果を発揮します。 たとえば、集計された販売データを使用して、ハイ パフォーマンスの "概要" レポートを作成することができます。 次に、特定の (かつ狭い) フィルター コンテキストの詳細な売上を表示するためのドリルスルー ページを作成し、コンテキスト内のすべての販売注文を表示することができます。 ドリルスルー ページには、販売注文データ (販売注文の詳細) を取得するための DirectQuery テーブルに基づくビジュアルが含まれます。
詳細については、インポート モデリングのデータ削減手法を参照してください。