データフローを使用してディメンショナル モデルを作成するためのベスト プラクティス
ディメンショナル モデルの設計は、データフローを使用して実行できる最も一般的なタスクの 1 つです。 この記事では、データフローを使用して、ディメンショナル モデルを作成するためのベスト プラクティスをいくつか取り上げます。
ステージング データフロー
データ統合システムにおける重要な課題の 1 つに、ソース運用システムからの読み取り数の削減があります。 従来のデータ統合アーキテクチャでこの削減を行うには、"ステージング データベース" と呼ばれる新しいデータベースを作成します。 ステージング データベースの目的は、定期的なスケジュールに基づいてデータ ソースからステージング データベースにデータをそのまま読み込むことです。
続いて、データ統合の残りの部分で、追加の変換を行い、それをディメンショナル モデル構造に変換するためのソースとしてステージング データベースを使用します。
データフローを使用してこれと同じアプローチを採用することをお勧めします。 ソース システムからデータをそのまま (および必要なテーブルに対してのみ) 読み込むことのみ担当する一連のデータフローを作成します。 その結果は、データフローのストレージ構造 (Azure Data Lake Storage または Dataverse) に格納されます。 この変更により、ソース システムからの読み取り操作は最小限に抑えられます。
次に、ステージング データフローからデータを取得する他のデータフローを作成できます。 この方法の利点は次のとおりです。
- ソース システムからの読み取り操作の数を減らし、その結果、ソース システムの負荷を軽減します。
- オンプレミスのデータ ソースが使用されている場合は、データ ゲートウェイの負荷を軽減します。
- ソース システムのデータが変更された場合に備えて、調整の目的でデータの中間コピーを保持します。
- 変換のデータフローをソースに依存しないようにします。
ステージング データフローとステージング ストレージが強調され、ステージング データフローによってデータ ソースからアクセスされているデータと、Cadavers または Azure Data Lake Storage に格納されているエンティティを示しているイメージ。 次に、エンティティが他のデータフローと共に変換されていることが示されています。これらはクエリとして送信されます。
変換データフロー
変換データフローをステージング データフローから分離した場合、変換はソースから独立したものとなります。 この分離は、ソース システムを新しいシステムに移行する場合に役立ちます。 この場合に必要なのは、ステージング データフローを変更することだけです。 変換データフローは、ステージング データフローからのみ供給されるため、問題なく動作します。
この分離は、ソース システムの接続速度が遅い場合にも役立ちます。 変換データフローでは、ソース システムから低速接続で送られるレコードの取得に長時間待機する必要はありません。 ステージング データフローでは、その部分が既に実行されており、データは変換レイヤーの準備ができています。

階層型アーキテクチャ
階層型アーキテクチャは、各アクションを別々の層で実行するアーキテクチャです。 ステージングと変換のデータフローは、2 つの層の多層データフロー アーキテクチャにすることができます。 アクションを層で実行することによって、必要なメンテナンスを最小限に抑えることができます。 何かを変更する場合、それが配置されている層でその変更を行うだけで済みます。 他の層はすべて正常に動作し続けます。
次のイメージは、データフローの多層アーキテクチャを示しています。それらのエンティティはその後、 Power BI データセットで使用されます。

計算されたエンティティを可能な限り使用する
データフローの結果を別のデータフローで使用する場合、計算されたエンティティの概念を使用しています。これは、"既に処理され、格納されている" エンティティからデータを取得することを意味します。 データフロー内でも同じことが発生することがあります。 あるエンティティを別のエンティティから参照する場合、計算されたエンティティを使用できます。 これは、複数のエンティティで実行する必要がある、共通の変換 と呼ばれる一連の変換がある場合に便利です。

前のイメージでは、計算されたエンティティはソースから直接データを取得します。 ただし、ステージングと変換のデータフローからなるアーキテクチャでは、計算されたエンティティがステージング データフローから提供される可能性があります。

スター スキーマを作成する
最適なディメンショナル モデルは、モデルのデータに対するクエリの実行時間が最小になるように設計されたディメンションとファクト テーブルを備え、データ ビジュアライザーで理解しやすいスター スキーマ モデルです。
運用システムと同じレイアウトのデータを BI システムに取り込むことは推奨されません。 データ テーブルを再構築する必要があります。 いくつかのテーブルは、説明情報を保持するディメンション テーブルの形式にする必要があります。 また、集計可能なデータを保持するためのファクト テーブルの形式にする必要があるテーブルもあります。 ファクト テーブルとディメンション テーブルを形成するための最適なレイアウトは、スター スキーマです。 詳細については、「スター スキーマと Power BI での重要性を理解する」を参照してください。

ディメンションに一意のキー値を使用する
ディメンション テーブルを作成するときは、それぞれにキーがあることを確認してください。 このキーにより、ディメンション間に多対多の (つまり、"弱い") リレーションシップが存在しないことが保証されます。 キーを作成するには、何らかの変換を適用して、列または列の組み合わせがディメンション内で一意の行を返すようにします。 続いて、その列の組み合わせに、データフロー内のエンティティのキーのマークを付けることができます。

大規模なファクト テーブルの増分更新を実行する
ファクト テーブルは常に、ディメンショナル モデル内の最大のテーブルです。 これらのテーブルに転送される行の数を減らすことをお勧めします。 非常に大きなファクト テーブルがある場合は、そのエンティティに対して増分更新を使用するようにしてください。 増分更新は、Power BI データセットおよびデータフロー エンティティで行うことができます。
増分更新を使用すると、データの一部 (変更された部分) のみを更新できます。 更新するデータの部分と永続化する部分を選択するための複数のオプションがあります。 詳細については、Power BI データフローでの増分更新の使用に関する記事を参照してください。

ディメンションとファクト テーブルを作成するための参照
多くの場合、ソース システムには、データ ウェアハウスでファクトとディメンションの両方のテーブルを生成するために使用するテーブルがあります。 これらは、計算されたエンティティおよび中間のデータフローに適したテーブルです。 プロセスの共通部分—データのクリーニング、余分な行や列の削除など—は、1 回の実行で済みます。 これらのアクションの出力からの参照を使用することによって、ディメンションとファクト テーブルを作成できます。 この方法では、共通の変換に対して計算されたエンティティが使用されます。
