Fabric Data Warehouse内のテーブル

適用対象:✅ Microsoft Fabric の倉庫

この記事では、Microsoft Fabricでテーブルを設計するための重要な概念を解説します。

テーブルでは、データを論理的に行と列形式で整理します。 各行は一意なレコードを表し、各列はレコードのフィールドを表します。

テーブル カテゴリを決定する

スター スキーマ は、データを ファクト テーブル と ディメンション テーブル に編成します。 一部のテーブルは、ファクト テーブルまたはディメンション テーブルに移動する前に統合またはステージング データに使用されます。 テーブルを設計する際には、テーブルのデータがファクト、ディメンション、統合のいずれのテーブルに属するかを決定します。 この決定により、適切なテーブル構造体が通知されます。

  • ファクトテーブルには 、トランザクションシステムによって生成された定量的データが含まれ、その後データウェアハウスに読み込まれます。 たとえば、小売業では販売トランザクションを毎日生成した後、そのデータを分析のためにデータ ウェアハウス ファクト テーブルに読み込みます。

  • ディメンション テーブルには、変化する可能性はあるが通常は変更頻度が低い属性データが含まれます。 例えば、顧客の名前と住所をディメンションテーブルに保存し、顧客のプロフィールが変わった時のみ更新します。 大規模なファクト テーブルのサイズを最小限に抑えるために、ファクト テーブルのすべての行に顧客の名前と住所を格納する必要はありません。 代わりに、ファクト テーブルとディメンション テーブルで顧客 ID を共有できます。 クエリで 2 つのテーブルを結合して、顧客のプロファイルとトランザクションに関連付けることができます。

  • 統合テーブルは、統合またはステージング データの場所を提供します。 たとえば、ステージング テーブルにデータを読み込み、ステージングでデータの変換を実行してから、データを運用環境テーブルに挿入できます。

テーブルは、ウェアハウスの一部として OneLake にデータを格納します。 テーブルとデータは、セッションが開かれているかどうかにかかわらず保持されます。

倉庫内のテーブル

テーブルの構成を示すには、テーブル名の接頭辞としてfact、dim、またはintを使用します。 以下の表は、WideWorldImportersDW サンプルデータウェアハウスのスキーマおよびテーブル名の一部を示しています。

WideWorldImportersDW ソース テーブル名 テーブルの種類 データウェアハウスのテーブル名
市 ディメンション wwi.DimCity
注文 事実 wwi.FactOrder
  • テーブル名に / や \ を含めたり、末尾を . にしたりすることはできません。
  • Fabric Data Warehouseではセッションスコープ付きの一時的(#temp)テーブルを作成できます。 詳細については、Fabric Data Warehouseの一時テーブルを参照してください。

テーブルを作成する

テーブルは、新しい空のテーブルとして作成することができます、ウェアハウスでは。 テーブルを作成し、SELECT ステートメントの結果を使用して値を設定することもできます。 以下の表は、テーブルを作成するためのT-SQLコマンドを示しています。

T-SQL ステートメント 説明
テーブルを作成 すべてのテーブル列およびオプションを定義して空のテーブルを作成します。
SELECT としてテーブルを作成する SELECT ステートメントの結果を使用して新しいテーブルに値が設定されます。 テーブルの列とデータ型は、SELECT ステートメントの結果に基づきます。 データをインポートするには、このステートメントで外部テーブルから選択できます。

この例では、次の 2 つの列を含むテーブルを作成します。

CREATE TABLE MyTable (col1 int, col2 int );

Fabric Data Warehouse は、テーブルのIDENTITY 列をサポートしており、増分される連番を自動的に挿入できます。 始めるには、Fabric Data Warehouseの「IDENTITYを使う」欄をご覧ください。

同様に、既存のテーブルは ALTER TABLE (Transact-SQL) T-SQL構文で変更できます。

ウェアハウス内のビューのメタデータは、ビューが依存する基盤テーブルの変更により古くなることがあります。 ビューのメタデータを更新するには、 sys.sp_refreshview(Transact-SQL)を使用します。 SCHEMABINDINGで作成されたビューは、ビュー定義に影響を与える場合、基になるオブジェクトへの変更をブロックします。 SCHEMABINDINGを使用せずにビューを作成した場合は、ビューの定義に影響を与える基になるオブジェクトに変更を加えたときにsp_refreshviewを実行してください。 そうしないと、クエリ時に予期しない結果が返ってくるかもしれません。

スキーマ名

Warehouse では、カスタム スキーマの作成がサポートされています。 SQL Serverと同様に、スキーマは、同様の方法で使用されるオブジェクトをグループ化するのに適した方法です。 次のコードは、ユーザー定義スキーマと呼ばれるschemaを作成します。

  • スキーマ名に / や \ を含めたり、末尾を . にしたりすることはできません。
CREATE SCHEMA wwi;

データ型

Microsoft Fabricでは、最も一般的に使用される T-SQL データ型がサポートされています。

照合順序

Fabric ウェアハウスは、ワークスペースの照合順序設定に基づいて構成されます。既定では、大文字と小文字が区別される (CS) 照合順序Latin1_General_100_BIN2_UTF8。 新しい倉庫を作成する際には、ワークスペースの照合順序が使用されます。 詳細については、「Data Warehouse 照合順序」を参照してください。

サポートされているウェアハウスの照合順序は次のとおりです。

  • Latin1_General_100_BIN2_UTF8 (既定値)
  • Latin1_General_100_CI_AS_KS_WS_SC_UTF8

REST APIを使って、デフォルトでない照合順序でウェアハウスを作成できます。 詳細については、「ケースの区別をしない (CI) 照合順序でウェアハウスを作成する方法」を参照してください。

データベース作成時にコレーションを設定すると、その後のすべてのオブジェクト(テーブル、列など)がこのデフォルトのコレーションを引き継ぎます。 倉庫を作成した後は、コレーション設定を変更することはできません。

Statistics

クエリ オプティマイザーでは、クエリ実行のプランの作成時に列レベルの統計が使用されます。 クエリのパフォーマンスを向上させるには、個々の列、特にクエリの結合で使用される列の統計を作成することが重要です。 ウェアハウスでは、統計の自動作成がサポートされます。

統計の更新は自動的には行われません。 大量の行が追加または変更された後に統計を更新します。 たとえば、読み込みの後に統計を更新します。 詳細については、Fabric Data Warehouse の統計情報を参照してください。

主キー、外部キー、一意キー

Warehouseでは、PRIMARY KEYとUNIQUEの両方を使う場合に限り、NONCLUSTERED制約とNOT ENFORCED制約を使えます。

FOREIGN KEYはNOT ENFORCEDを使うときにしか使えません。

ソース データをデータ ウェアハウスに配置する

別のデータソースからデータを読み込むことで、ウェアハウステーブルを埋めることができます。 データを正しく読み込むためには、ソースデータの列の数とデータ型がウェアハウス内のテーブル定義と一致しなければなりません。

複数のデータストアからデータが来ている場合、そのデータをウェアハウスにポートして統合テーブルに保存できます。 データが統合テーブルにある場合、ウェアハウスの力を使って変換操作を実装できます。 データが準備されたら、それを本番テーブルに挿入できます。

制限事項

ウェアハウスでは、他のデータベースで提供されるテーブル機能の多くがサポートされますが、すべてサポートされるわけではありません。

  • グローバル一時テーブルは現在サポートされていません。

次の一覧は、現在サポートされていないテーブル機能の一部を示しています。

  • テーブルあたり最大 1,024 列
  • 計算列
  • インデックス付きビュー
  • パーティション化されたテーブル
  • シークエンス
  • スパース列
  • シノニム
  • トリガー
  • 一意のインデックス
  • ユーザー定義データ型
  • 外部テーブル

Fabric Data Warehouse は、オブジェクトやその定義に高速にアクセスできるように、ウェアハウス オブジェクトのメタデータをキャッシュします。 75万以上のオブジェクト(例:テーブル、ビュー、ストアドプロシージャ、関数)を持つ非常に大規模なウェアハウスでは、システムはメタデータをキャッシュしなくなりました。 代わりに、スキーマ操作はメタデータ ストアに直接クエリを実行します。 この設計によりシステムの安定性が保証され、非常に大規模なデータベースでのキャッシュ飢餓を防ぎます。 ただし、スキーマの更新操作は、メタデータ キャッシュが有効になっている小規模なウェアハウスに比べて時間がかかる場合があります。

重要

Fabric Warehouse DevelopmentでGit統合を使用する場合、テーブル制約や列を追加するには制限があります。

関連するコンテンツ

  • 最終更新: