データ ウェアハウスの基礎を理解する
最新のデータ ウェアハウスを構築するプロセスには、通常、次のような処理が含まれます。
- データ インジェスト - ソース システムからデータ ウェアハウスへデータを移動します。
- データ ストレージ - 分析用に最適化された形式でデータを格納します。
- データ処理 - 分析ツールで使用できる形式にデータを変換します。
- データ分析と配信 - データを分析して分析情報を取得し、それらの分析情報をビジネスに提供します。
Microsoft Fabric を使用すると、データ エンジニアとアナリストは、ローコードと従来のエクスペリエンスの両方を使用して、データの取り込み、格納、変換、視覚化をすべて 1 つのツールで行うことができます。
Fabric のデータ ウェアハウス エクスペリエンスを理解する
Fabric の "データ ウェアハウス" は、エンタープライズ データ ウェアハウスに期待される完全なトランザクション T-SQL 機能をサポートするリレーショナル データ ウェアハウスです。 これは、フル マネージドでスケーラブルかつ高可用性のデータ ウェアハウスであり、レイクハウスでのデータの格納とクエリに使用できます。 データ ウェアハウスを使用すると、Fabric ポータルまたは T-SQL コマンドを使用して、テーブルの作成、読み込み、変換、およびクエリを完全に制御できます。 SQL を使用してデータのクエリと分析を行うか、または Spark を使用してデータの処理と機械学習モデルの作成を行うことができます。
Fabric のデータ ウェアハウスでは、データ エンジニアとデータ アナリストのコラボレーションが促進され、同じエクスペリエンスで共同作業を行います。 データ エンジニアは、レイクハウスのデータの上にリレーショナル レイヤーを構築します。そこで、アナリストは T-SQL と Power BI を使用してデータを探索できます。
データ ウェアハウスを設計する
すべてのリレーショナル データベースと同様に、Fabric のデータ ウェアハウスには、後で分析を行うためにデータを格納するテーブルが含まれています。 ほとんどの場合、これらのテーブルは、多次元モデリング用に最適化されたスキーマとして編成されます。 このアプローチでは、イベント (販売注文など) に関連する数値データは、さまざまな属性 (日付、顧客、店舗など) でグループ化されます。 たとえば、特定の日付または特定の店舗で発生した販売注文に対して支払われた合計金額を分析できます。
データ ウェアハウス内のテーブル
通常、データ ウェアハウス内のテーブルは、大量のデータの効率的かつ効果的な分析をサポートする方法で編成されます。 多くの場合、この編成はディメンション モデリングと呼ばれ、ファクト テーブルとディメンション テーブルへのテーブルの構造化が含まれます。
ファクト テーブルには、分析する数値データが含まれています。 通常、ファクト テーブルには多数の行があり、これらは分析用のプライマリ データ ソースです。 たとえば、ファクト テーブルには、特定の日付または特定の店舗で発生した販売注文に対して支払われた合計金額が含まれている場合があります。
ディメンション テーブルには、ファクト テーブル内のデータに関する説明情報が含まれています。 通常、ディメンション テーブルには少数の行があり、ファクト テーブル内のデータのコンテキストを提供するために使用されます。 たとえば、ディメンション テーブルには、販売注文を行った顧客に関する情報が含まれている場合があります。
ディメンション テーブルには、属性列に加えて、テーブル内の各行を一意に識別する一意のキー列が含まれています。 実際、ディメンション テーブルには通常、次の "2 つの" キー列が含まれています。
- "代理キー" は、ディメンション テーブルの各行の一意の識別子です。 多くの場合、新しい行がテーブルに挿入されるときに、データベース管理システムによって自動的に生成される整数値です。
- "代替" キーは、多くの場合、トランザクション ソース システム内のエンティティの特定のインスタンスを識別するナチュラル キーまたビジネス キーです (製品コードや顧客 ID など)。
データ ウェアハウス内の代理キーと代替キーは異なる目的に対応するため、両方が必要です。 代理キーはデータ ウェアハウスに固有であり、データの一貫性と精度を維持するのに役立ちます。 一方、代替キーはソース システムに固有であり、データ ウェアハウスとソース システムの間の追跡可能性を維持するのに役立ちます。
特殊な種類のディメンション テーブル
特殊な種類のディメンションでは、追加のコンテキストが提供され、より包括的なデータ分析が可能になります。
"時間ディメンション" は、イベントが発生した期間に関する情報を提供します。 データ アナリストは、この表を使用して複数の時間間隔でデータを集計できます。 たとえば、時間ディメンションには、販売注文が行われた年、四半期、月、日の列が含まれる場合があります。
"スロー チェンジ ディメンション" は、時間の経過に伴うディメンション属性の変更 (顧客の住所や製品の価格の変更など) を追跡するディメンション テーブルです。 時間の経過に伴うデータの変更をユーザーが分析して理解できるため、データ ウェアハウスではこのテーブルが重要です。 スロー チェンジ ディメンションにより、データは最新かつ正確に保たれ、これはビジネス上の適切な意思決定を行う上で不可欠です。
データ ウェアハウス スキーマの設計
ビジネス アプリケーションで使用されるほとんどのトランザクション データベースでは、重複を減らすためにデータが "正規化" されます。 ただし、データ ウェアハウスでは、データのクエリに必要な結合の数を減らすために、ディメンション データは通常 "非正規化" されます。
多くの場合、データ ウェアハウスは "スター スキーマ" として編成されます。この場合、次の例に示すように、ファクト テーブルがディメンション テーブルに直接関連付けられます。
何らかの属性を使用して、ファクト テーブル内の数値をさまざまなレベルでグループ化できます。 たとえば、リージョン全体または 1 人の顧客に対する総売上高を確認できます。 各レベルの情報は、同じディメンション テーブルに格納できます。
ヒント
Fabric のスター スキーマの設計の詳細については、「スター スキーマとは」を参照してください。
レベルが多数ある場合や、一部の情報が異なるもので共有されている場合は、代わりに "スノーフレーク スキーマ" を使用することをお勧めします。 次に例を示します。
この場合、DimProduct テーブルは分割 (正規化) されて、製品カテゴリとサプライヤー用に個別のディメンション テーブルが作成されます。
- DimProduct テーブルの各行には、DimCategory テーブル内と DimSupplier テーブル内の対応する行のキー値が含まれています。
顧客と店舗の所在地に関する情報を含む DimGeography テーブルが追加されました。
- DimCustomer テーブルと DimStore テーブルの各行には、DimGeography テーブル内の対応する行のキー値が含まれています。