カーディナリティを削減する

  • 7 分

カーディナリティとは、列内の値の一意性を説明するために使用される用語です。 カーディナリティは、2 つのテーブル間のリレーションシップの文脈でも使用されます。その場合は、リレーションシップの方向を説明します。

列のカーディナリティ レベルを特定する

以前は、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 つの値のインスタンスが複数存在していてもかまいません。

  • 多対多 (:) - 複合モデルでは、テーブル間に多対多のリレーションシップを確立できます。これにより、テーブル内に一意の値を含めるという要件は取り除かれます。 さらに、リレーションシップを確立するためだけに新しいテーブルを導入するなどの以前の回避策も取り除かれます。

開発時に、モデル内のリレーションシップを作成および編集するため、モデルで新しいリレーションシップを構築する場合、選んだカーディナリティに関係なく、リレーションシップに参加するために使っている両方の列で、確実に同じデータ型が共有されているようにします。 一方の列がテキスト データ型で、他方の列が整数データ型である 2 つの列の間のリレーションシップを構築しようとすると、モデルは機能しません。

次の例では、Product および Sales テーブルの ProductID フィールドのデータ型は 整数です。 データ型が整数の列は、データ型がテキストの列よりもパフォーマンスが向上します。

ProductID のデータ型の確認方法を示すスクリーンショット。

カーディナリティ レベルを低減してパフォーマンスを向上させる

Power BI Desktop には、概要など、セマンティック モデルに読み込まれるデータを削減するために使用できるさまざまな手法が用意されています。 モデルに読み込まれるデータを作成すると、レポートのリレーションシップ カーディナリティが向上します。 このため、モデルに読み込まれるデータを最小限に抑えるよう努めることが重要です。 これは、大きなモデル、または時間の経過と共に増大することが予想されるモデルについて、特に言えることです。

モデルのサイズを縮小するための最も効果的な手法は、データ ソースの概要テーブルを使用することです。  詳細テーブルにすべてのトランザクションが含まれる場合、概要テーブルには、1 日、1 週間、またはひと月に 1 件のレコードが含まれます。 たとえば、それは、1 日あたりのすべてのトランザクションの平均である場合もあります。

たとえば、ソースの Sales ファクト テーブルには、注文明細行ごとに 1 行が格納されます。 日付、顧客、および製品別にグループ化し、個々のトランザクションの詳細を必要としない場合、すべての販売メトリックを集計することによって、大幅なデータ削減を実現できる可能性があります。

次に、月レベルで日付別にグループ化することによって、さらに大幅なデータ削減を実現するについて考えてみましょう。 これによって、モデルのサイズを 99% 縮小できる可能性があります。ただし、日にちレベルまたは個々の注文レベルでのレポートは作成できなくなります。 ファクト型データを集計することを決定した場合、常にデータの詳細とのトレードオフが伴います。 欠点は、詳細が存在しなくなるため、データを掘り下げることができなくなる可能性があるということです。  このトレードオフは、混合モデル設計を使用することによって軽減される可能性があります。

Power BI Desktop では、混合モード設計によって複合モデルが生成されます。 基本的に、これを使用することにより、各テーブルのストレージ モードを決定することができます。 このため、各テーブルの [ストレージ モード] プロパティを [インポート] または [DirectQuery] として設定できます。

モデルのサイズを縮小するための効果的な手法は、大きなファクト型テーブルの [ストレージ モード] プロパティを [DirectQuery] に設定することです。 この設計手法は、データの集計に使用される手法と組み合わると効果を発揮します。 たとえば、集計された販売データを使用して、ハイ パフォーマンスの "概要" レポートを作成することができます。 ドリルスルー ページを作成して、特定の (および絞り込んだ) フィルター コンテキストの詳細な販売データを表示し、コンテキスト内のすべての販売注文を表示することができます。 ドリルスルー ページには、販売注文データ (販売注文の詳細) を取得するための DirectQuery テーブルに基づくビジュアルが含まれます。

詳細については、「インポート モデリングのデータ削減手法」を参照してください。