データフローを使用してディメンショナル モデルを作成するためのベスト プラクティス

ディメンショナル モデルの設計は、データフローを使用して実行できる最も一般的なタスクの 1 つです。 この記事では、データフローを使用して、ディメンショナル モデルを作成するためのベスト プラクティスをいくつか取り上げます。

ステージング データフロー

データ統合システムにおける重要な課題の 1 つに、ソース運用システムからの読み取り数の削減があります。 従来のデータ統合アーキテクチャでこの削減を行うには、"ステージング データベース" と呼ばれる新しいデータベースを作成します。 ステージング データベースの目的は、定期的なスケジュールに基づいてデータ ソースからステージング データベースにデータをそのまま読み込むことです。

続いて、データ統合の残りの部分では、以後の変換にステージング データベースをソースとして使用し、それをディメンショナル モデル構造に変換します。

データフローを使用してこれと同じアプローチを採用することをお勧めします。 ソース システムからデータをそのまま (および必要なテーブルに対してのみ) 読み込むことのみ担当する一連のデータフローを作成します。 その結果は、データフローのストレージ構造 (Azure Data Lake Storage または Dataverse) に格納されます。 この変更により、ソース システムからの読み取り操作は最小限に抑えられます。

次に、ステージング データフローからデータを取得する他のデータフローを作成できます。 この方法の利点は次のとおりです。

• ソース システムからの読み取り操作の数を減らし、その結果、ソース システムの負荷を軽減します。
• オンプレミスのデータ ソースが使用されている場合は、データ ゲートウェイの負荷を軽減します。
• ソース システムのデータが変更された場合に備えて、調整の目的でデータの中間コピーを保持します。
• 変換のデータフローをソースに依存しないようにします。

ステージング データフローとステージング ストレージを強調表示する画像。ステージング データフローによってデータ ソースからアクセスされるデータと、Cadavers または Azure Data Lake Storage に格納されるテーブルが示されています。 続いて、テーブルが他のデータフローと一緒に変換され、クエリとして送信されます。

変換データフロー

変換データフローをステージング データフローから分離した場合、変換はソースから独立したものとなります。 この分離は、ソース システムを新しいシステムに移行する場合に役立ちます。 この場合に必要なのは、ステージング データフローを変更することだけです。 変換データフローは、ステージング データフローからのみ供給されるため、問題なく動作する可能性があります。

この分離は、ソース システムの接続速度が遅い場合にも役立ちます。 変換データフローでは、ソース システムから低速接続で送られるレコードの取得に長時間待機する必要はありません。 ステージング データフローでは、その部分が既に実行されており、データは変換レイヤーの準備ができています。

階層型アーキテクチャ

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

次の画像は、データフローの多層アーキテクチャを示しており、テーブルは Power BI セマンティック モデルで使用されています。

計算テーブルを可能な限り使用する

あるデータフローの結果を別のデータフローで使用する場合は、計算テーブルの概念を使用し、"既に処理および格納されている" テーブルからデータを取得します。 データフロー内でも同じことが発生することがあります。 あるテーブルを別のテーブルから参照する場合は、計算テーブルを使用します。 これは、複数のテーブルで実行する必要のある変換がセットで存在する場合に便利であり、共通の変換と呼ばれます。

前の画像では、計算テーブルはデータを直接ソースから取得しています。 ただし、ステージングと変換のデータフロー アーキテクチャでは、計算テーブルをステージング データフローから取得する可能性があります。

スター スキーマを作成する

最適なディメンショナル モデルは、モデルのデータに対するクエリの実行時間が最小になるように設計されたディメンションとファクト テーブルを備え、データ ビジュアライザーで理解しやすいスター スキーマ モデルです。

運用システムと同じレイアウトのデータを BI システムに取り込むことはお勧めしません。 データ テーブルを再構築する必要があります。 いくつかのテーブルは、説明情報を保持するディメンション テーブルの形式にする必要があります。 また、集計可能なデータを保持するためのファクト テーブルの形式にする必要があるテーブルもあります。 ファクト テーブルとディメンション テーブルを形成するための最適なレイアウトは、スター スキーマです。 詳細については、「スター スキーマと Power BI での重要性を理解する」を参照してください。

ディメンションに一意のキー値を使用する

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

大規模なファクト テーブルの増分更新を実行する

ファクト テーブルは常に、ディメンショナル モデル内の最大のテーブルです。 これらのテーブルに転送する行の数を減らすことをお勧めします。 非常に大きなファクト テーブルがある場合は、増分更新をテーブルに使用してください。 増分更新は、Power BI セマンティック モデルだけでなく、データフロー テーブルでも実行できます。

増分更新を使用すると、データの一部 (変更された部分) のみを更新できます。 更新するデータの部分と永続化する部分を選択するための複数のオプションがあります。 詳細については、Power BI データフローでの増分更新の使用に関する記事を参照してください。

ディメンションとファクト テーブルを作成するための参照

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