Azure SQL Data Warehouse でのテーブルの設計Designing tables in Azure SQL Data Warehouse

Azure SQL Data Warehouse でのテーブル設計について重要な概念を説明します。Learn key concepts for designing tables in Azure SQL Data Warehouse.

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

スター スキーマは、データをファクト テーブルとディメンション テーブルに編成します。A star schema organizes data into fact and dimension tables. 一部のテーブルは、ファクト テーブルまたはディメンション テーブルに移動する前に統合またはステージング データに使用されます。Some tables are used for integration or staging data before it moves to a fact or dimension table. テーブルを設計する際には、テーブルのデータがファクト、ディメンション、統合のいずれのテーブルに属するかを決定します。As you design a table, decide whether the table data belongs in a fact, dimension, or integration table. この決定は、適切なテーブル構造体および配布を通知します。This decision informs the appropriate table structure and distribution.

  • ファクト テーブルには、一般にトランザクション システムで生成された後、データ ウェアハウスに読み込まれる定量的データが含まれています。Fact tables contain quantitative data that are commonly generated in a transactional system, and then loaded into the data warehouse. たとえば、小売業では販売トランザクションを毎日生成した後、そのデータを分析のためにデータ ウェアハウス ファクト テーブルに読み込みます。For example, a retail business generates sales transactions every day, and then loads the data into a data warehouse fact table for analysis.

  • ディメンション テーブルには、変化する可能性はあるが通常は変更頻度が低い属性データが含まれます。Dimension tables contain attribute data that might change but usually changes infrequently. たとえば、顧客の名前と住所はディメンション テーブルに格納され、その顧客のプロファイルが変更された場合にのみ更新されます。For example, a customer's name and address are stored in a dimension table and updated only when the customer's profile changes. 大規模なファクト テーブルのサイズを最小限に抑えるために、顧客の名前と住所をファクト テーブルのすべての行に格納する必要はありません。To minimize the size of a large fact table, the customer's name and address do not need to be in every row of a fact table. 代わりに、ファクト テーブルとディメンション テーブルで顧客 ID を共有できます。Instead, the fact table and the dimension table can share a customer ID. クエリで 2 つのテーブルを結合して、顧客のプロファイルとトランザクションに関連付けることができます。A query can join the two tables to associate a customer's profile and transactions.

  • 統合テーブルは、統合またはステージング データの場所を提供します。Integration tables provide a place for integrating or staging data. 統合テーブルは、通常のテーブル、外部テーブル、または一時テーブルとして作成できます。You can create an integration table as a regular table, an external table, or a temporary table. たとえば、ステージング テーブルにデータを読み込み、ステージングでデータの変換を実行してから、データを運用環境テーブルに挿入できます。For example, you can load data to a staging table, perform transformations on the data in staging, and then insert the data into a production table.

スキーマとテーブルの名前Schema and table names

スキーマは、同じ方法で使用されるテーブルをグループ化するのに良い方法です。Schemas are a good way to group tables, used in a similar fashion, together. 複数のデータベースをオンプレミス ソリューションから SQL Data Warehouse に移行する場合は、ファクト テーブル、ディメンション テーブル、および統合テーブルのすべてを SQL Data Warehouse 内の 1 つのスキーマに移行すると一番うまくいきます。If you are migrating multiple databases from an on-prem solution to SQL Data Warehouse, it works best to migrate all of the fact, dimension, and integration tables to one schema in SQL Data Warehouse. たとえば、すべてのテーブルを、wwi と呼ばれる 1 つのスキーマ内の WideWorldImportersDW サンプル データ ウェアハウスに格納できます。For example, you could store all the tables in the WideWorldImportersDW sample data warehouse within one schema called wwi. 次のコードは、wwi と呼ばれるユーザー定義スキーマを作成します。The following code creates a user-defined schema called wwi.

CREATE SCHEMA wwi;

SQL Data Warehouse 内のテーブルの構成を表示するには、テーブル名のプレフィックスとして fact、dim、および int を使用できます。To show the organization of the tables in SQL Data Warehouse, you could use fact, dim, and int as prefixes to the table names. 次の表に、WideWorldImportersDW のスキーマ名とテーブル名の一部を示します。The following table shows some of the schema and table names for WideWorldImportersDW.

WideWorldImportersDW テーブルWideWorldImportersDW table テーブルの種類Table type SQL Data WarehouseSQL Data Warehouse
CityCity DimensionDimension wwi.DimCitywwi.DimCity
順序Order ファクトFact wwi.FactOrderwwi.FactOrder

テーブルの永続性Table persistence

テーブルは、データを Azure Storage に永続的に格納するか、Azure Storage に一時的に格納するか、またはデータ ウェアハウスの外部にあるデータ ストアに格納するかのいずれかです。Tables store data either permanently in Azure Storage, temporarily in Azure Storage, or in a data store external to data warehouse.

通常のテーブルRegular table

通常のテーブルは、データ ウェアハウスの一部として Azure Storage にデータを格納します。A regular table stores data in Azure Storage as part of the data warehouse. セッションが開いているかどうかに関係なく、テーブルとデータが保持されます。The table and the data persist regardless of whether a session is open. この例では、2 つの列を含む通常のテーブルを作成します。This example creates a regular table with two columns.

CREATE TABLE MyTable (col1 int, col2 int );  

一時テーブルTemporary table

一時テーブルは、セッション中のみ存在します。A temporary table only exists for the duration of the session. 一時テーブルを使用して、一時的な結果を他のユーザーが確認できないようにしたり、クリーンアップの必要性を減らしたりすることもできます。You can use a temporary table to prevent other users from seeing temporary results and also to reduce the need for cleanup. 一時テーブルはローカル ストレージを使用して高速のパフォーマンスを提供します。Temporary tables utilize local storage to offer fast performance. 詳しくは、一時テーブルに関する記事をご覧ください。For more information, see Temporary tables.

外部テーブルExternal table

外部テーブルは、Azure Storage BLOB または Azure Data Lake Store にあるデータを指します。An external table points to data located in Azure Storage blob or Azure Data Lake Store. CREATE TABLE AS SELECT ステートメントと組み合わせて使用する場合は、外部テーブルから選択するとデータが SQL Data Warehouse にインポートされます。When used in conjunction with the CREATE TABLE AS SELECT statement, selecting from an external table imports data into SQL Data Warehouse. このため、外部テーブルはデータを読み込むのに役立ちます。External tables are therefore useful for loading data. 読み込みのチュートリアルについては、「PolyBase を使用して Azure Blob Storage から Azure SQL Data Warehouse にデータを読み込む」をご覧ください。For a loading tutorial, see Use PolyBase to load data from Azure blob storage.

データの種類Data types

SQL Data Warehouse では、最もよく使用されるデータ型がサポートされています。SQL Data Warehouse supports the most commonly used data types. サポートされるデータ型の一覧については、CREATE TABLE ステートメントの「data types in CREATE TABLE reference (CREATE TABLE 内のデータ型のリファレンス)」を参照してください。For a list of the supported data types, see data types in CREATE TABLE reference in the CREATE TABLE statement. データ型の使用に関するガイダンスについては、「データ型」を参照してください。For guidance on using data types, see Data types.

分散テーブルDistributed tables

SQL Data Warehouse の基本的特徴は、複数のディストリビューションにわたるテーブルを格納して操作できる方法にあります。A fundamental feature of SQL Data Warehouse is the way it can store and operate on tables across distributions. SQL Data Warehouse では、データを分散するための 3 つの方法 (ラウンド ロビン (既定値)、ハッシュ、レプリケート) がサポートされています。SQL Data Warehouse supports three methods for distributing data, round-robin (default), hash and replicated.

ハッシュ分散テーブルHash-distributed tables

ハッシュ分散テーブルは、ディストリビューション列内の値に基づいて行を分散します。A hash distributed table distributes rows based on the value in the distribution column. ハッシュ分散テーブルは、大規模なテーブルのクエリでハイパフォーマンスを達成するように設計されています。A hash distributed table is designed to achieve high performance for queries on large tables. ディストリビューション列を選択する際に検討すべきいくつかの要素があります。There are several factors to consider when choosing a distribution column.

詳細については、「Design guidance for distributed tables (分散テーブルの設計ガイダンス)」を参照してください。For more information, see Design guidance for distributed tables.

レプリケート テーブルReplicated tables

レプリケート テーブルには、すべてのコンピューティング ノードで使用可能なテーブルの完全なコピーが含まれています。A replicated table has a full copy of the table available on every Compute node. レプリケート テーブルの結合ではデータ移動が不要であるため、レプリケート テーブルではクエリが高速に実行されます。Queries run fast on replicated tables since joins on replicated tables do not require data movement. ただし、レプリケーションには余分なストレージが必要であり、大きなテーブルには適していません。Replication requires extra storage, though, and is not practical for large tables.

詳しくは、レプリケート テーブルを使用するための設計ガイダンスに関する記事をご覧ください。For more information, see Design guidance for replicated tables.

ラウンドロビン テーブルRound-robin tables

ラウンドロビン テーブルは、すべてのディストリビューションにわたって均等にテーブル行を分散させます。A round-robin table distributes table rows evenly across all distributions. これらの行は、ランダムに分散されます。The rows are distributed randomly. ラウンドロビン テーブルへのデータの読み込みは高速です。Loading data into a round-robin table is fast. ただし、クエリは他の分散方法より多くのデータ移動を要求できます。However, queries can require more data movement than the other distribution methods.

詳細については、「Design guidance for distributed tables (分散テーブルの設計ガイダンス)」を参照してください。For more information, see Design guidance for distributed tables.

テーブルの一般的な分散方法Common distribution methods for tables

テーブル カテゴリは、多くの場合、テーブルの分散について選択するオプションを決定します。The table category often determines which option to choose for distributing the table.

テーブル カテゴリTable category 推奨される分散オプションRecommended distribution option
ファクトFact クラスター化列ストア インデックスによるハッシュ分散を使用します。Use hash-distribution with clustered columnstore index. 2 つのハッシュ テーブルが同じディストリビューション列に結合される場合にパフォーマンスが向上します。Performance improves when two hash tables are joined on the same distribution column.
DimensionDimension 小さなテーブルにはレプリケートを使用します。Use replicated for smaller tables. 各コンピューティング ノードに保存するにはテーブルが大きすぎる場合は、ハッシュ分散を使用します。If tables are too large to store on each Compute node, use hash-distributed.
ステージングStaging ステージング テーブルにはラウンド ロビンを使用します。Use round-robin for the staging table. CTAS での読み込みが高速です。The load with CTAS is fast. データがステージング テーブルに格納されたら、INSERT...SELECT を使用してデータを運用環境テーブルに移動します。Once the data is in the staging table, use INSERT...SELECT to move the data to production tables.

テーブルのパーティションTable partitions

パーティション テーブルでは、データ範囲に基づいてテーブル行が格納され、操作が実行されます。A partitioned table stores and performs operations on the table rows according to data ranges. たとえば、day、month、または year でテーブルをパーティション分割できます。For example, a table could be partitioned by day, month, or year. クエリ スキャンをあるパーティション内のデータに制限するパーティション除外によってクエリ パフォーマンスを向上させることができます。You can improve query performance through partition elimination, which limits a query scan to data within a partition. パーティションを切り替えてデータを維持することもできます。You can also maintain the data through partition switching. SQL Data Warehouse のデータは既に分散されているため、パーティションが多すぎるとクエリ パフォーマンスが低下することがあります。Since the data in SQL Data Warehouse is already distributed, too many partitions can slow query performance. 詳しくは、パーティション分割のガイダンスに関する記事をご覧ください。For more information, see Partitioning guidance. 空でないテーブル パーティションにパーティションを切り替えるとき、既存のデータが切り詰められる場合は、ALTER TABLE ステートメントに TRUNCATE_TARGET オプションを使用することを検討してください。When partition switching into table partitions that are not empty, consider using the TRUNCATE_TARGET option in your ALTER TABLE statement if the existing data is to be truncated. 以下のコードは、既存のデータを上書きして、変換された 1 日のデータを SalesFact にスイッチインします。The below code switches in the transformed daily data into the SalesFact overwriting any existing data.

ALTER TABLE SalesFact_DailyFinalLoad SWITCH PARTITION 256 TO SalesFact PARTITION 256 WITH (TRUNCATE_TARGET = ON);  

列ストア インデックスColumnstore indexes

既定では、SQL Data Warehouse には、テーブルがクラスター化列ストア インデックスとして格納されます。By default, SQL Data Warehouse stores a table as a clustered columnstore index. この形式のデータ ストレージでは、大きなテーブルに対する高いデータ圧縮およびクエリ パフォーマンスが実現されます。This form of data storage achieves high data compression and query performance on large tables. クラスター化列ストア インデックスは、通常は最適な選択肢ですが、場合によっては、クラスター化インデックスまたはヒープが適切なストレージ構造体の場合もあります。The clustered columnstore index is usually the best choice, but in some cases a clustered index or a heap is the appropriate storage structure. ヒープ テーブルは、最終的なテーブルに変換されるステージング テーブルなどの一時的なデータを読み込むのに特に役立ちます。A heap table can be especially useful for loading transient data, such as a staging table which is transformed into a final table.

列ストア機能の一覧については列ストア インデックスの新機能に関する記事をご覧ください。For a list of columnstore features, see What's new for columnstore indexes. 列ストア インデックスのパフォーマンスを向上させるには、列ストア インデックスの行グループの品質の最大化に関する記事をご覧ください。To improve columnstore index performance, see Maximizing rowgroup quality for columnstore indexes.

統計Statistics

クエリ オプティマイザーでは、クエリ実行のプランの作成時に列レベルの統計が使用されます。The query optimizer uses column-level statistics when it creates the plan for executing a query. クエリのパフォーマンスを向上させるには、個々の列、特にクエリの結合で使用される列の統計を作成することが重要です。To improve query performance, it's important to have statistics on individual columns, especially columns used in query joins. 統計の作成は、自動的に行われます。Creating statistics happens automatically. ただし、統計の更新は自動的には行われません。However, updating statistics does not happen automatically. 大量の行が追加または変更された後に統計を更新します。Update statistics after a significant number of rows are added or changed. たとえば、読み込みの後に統計を更新します。For example, update statistics after a load. 詳しくは、統計のガイダンスに関する記事をご覧ください。For more information, see Statistics guidance.

主キーと一意キーPrimary key and unique key

PRIMARY KEY は、NONCLUSTERED と NOT ENFORCED が両方とも使用されている場合にのみサポートされます。PRIMARY KEY is only supported when NONCLUSTERED and NOT ENFORCED are both used. UNIQUE 制約は、NOT ENFORCED が使用されている場合にのみサポートされます。UNIQUE constraint is only supported with NOT ENFORCED is used. SQL Data Warehouse のテーブル制約に関する記事を確認してください。Check SQL Data Warehouse Table Constraints.

テーブルを作成するためのコマンドCommands for creating tables

テーブルは、新しい空のテーブルとして作成することができます。You can create a table as a new empty table. テーブルを作成し、SELECT ステートメントの結果を使用して値を設定することもできます。You can also create and populate a table with the results of a select statement. テーブルを作成するための T-SQL コマンドを次に示します。The following are the T-SQL commands for creating a table.

T-SQL ステートメントT-SQL Statement 説明Description
CREATE TABLECREATE TABLE すべてのテーブル列およびオプションを定義して空のテーブルを作成します。Creates an empty table by defining all the table columns and options.
CREATE EXTERNAL TABLECREATE EXTERNAL TABLE 外部テーブルを作成します。Creates an external table. テーブルの定義は、SQL Data Warehouse に格納されます。The definition of the table is stored in SQL Data Warehouse. テーブル データは Azure Blob Storage または Azure Data Lake Store に格納されます。The table data is stored in Azure Blob storage or Azure Data Lake Store.
CREATE TABLE AS SELECTCREATE TABLE AS SELECT SELECT ステートメントの結果を使用して新しいテーブルに値が設定されます。Populates a new table with the results of a select statement. テーブルの列とデータ型は、SELECT ステートメントの結果に基づきます。The table columns and data types are based on the select statement results. データをインポートするには、このステートメントで外部テーブルから選択できます。To import data, this statement can select from an external table.
CREATE EXTERNAL TABLE AS SELECTCREATE EXTERNAL TABLE AS SELECT 外部の場所に SELECT ステートメントの結果をエクスポートして、新しい外部テーブルを作成します。Creates a new external table by exporting the results of a select statement to an external location. その場所は Azure Blob Storage または Azure Data Lake Store です。The location is either Azure Blob storage or Azure Data Lake Store.

ソース データをデータ ウェアハウスに配置するAligning source data with the data warehouse

データ ウェアハウス テーブルは、別のデータ ソースからデータを読み込むことで設定されます。Data warehouse tables are populated by loading data from another data source. 読み込みの実行を成功させるには、ソース データ内の列の数とデータ型が、データ ウェアハウス内のテーブル定義と合致している必要があります。To perform a successful load, the number and data types of the columns in the source data must align with the table definition in the data warehouse. 配置するデータの取得は、テーブルの設計の最大の難関となる可能性があります。Getting the data to align might be the hardest part of designing your tables.

データが複数のデータ ストアから読み込まれる場合は、データ ウェアハウスにデータを読み込み、統合テーブルに格納できます。If data is coming from multiple data stores, you can bring the data into the data warehouse and store it in an integration table. データが統合テーブルに格納されたら、SQL Data Warehouse の機能を使用して変換操作を実行できます。Once data is in the integration table, you can use the power of SQL Data Warehouse to perform transformation operations. データの準備ができたら、それを運用テーブルに挿入できます。Once the data is prepared, you can insert it into production tables.

サポートされていないテーブルの機能Unsupported table features

SQL Data Warehouse では他のデータベースで提供されるテーブル機能の多くがサポートされますが、すべてサポートされるわけではありません。SQL Data Warehouse supports many, but not all, of the table features offered by other databases. 次の一覧は、SQL Data Warehouse でサポートされていないテーブル機能の一部を示しています。The following list shows some of the table features that are not supported in SQL Data Warehouse.

テーブル サイズのクエリTable size queries

60 個の各ディストリビューションでテーブルによって消費される領域と行を簡単に識別する方法の 1 つが、DBCC PDW_SHOWSPACEUSED です。One simple way to identify space and rows consumed by a table in each of the 60 distributions, is to use DBCC PDW_SHOWSPACEUSED.

DBCC PDW_SHOWSPACEUSED('dbo.FactInternetSales');

ただし、DBCC コマンドを使用できるのは極めて限定的です。However, using DBCC commands can be quite limiting. 動的管理ビュー (DMV) には、DBCC コマンドよりも詳しい情報が表示されます。Dynamic management views (DMVs) show more detail than DBCC commands. このビューの作成から開始します。Start by creating this view.

CREATE VIEW dbo.vTableSizes
AS
WITH base
AS
(
SELECT 
 GETDATE()                                                             AS  [execution_time]
, DB_NAME()                                                            AS  [database_name]
, s.name                                                               AS  [schema_name]
, t.name                                                               AS  [table_name]
, QUOTENAME(s.name)+'.'+QUOTENAME(t.name)                              AS  [two_part_name]
, nt.[name]                                                            AS  [node_table_name]
, ROW_NUMBER() OVER(PARTITION BY nt.[name] ORDER BY (SELECT NULL))     AS  [node_table_name_seq]
, tp.[distribution_policy_desc]                                        AS  [distribution_policy_name]
, c.[name]                                                             AS  [distribution_column]
, nt.[distribution_id]                                                 AS  [distribution_id]
, i.[type]                                                             AS  [index_type]
, i.[type_desc]                                                        AS  [index_type_desc]
, nt.[pdw_node_id]                                                     AS  [pdw_node_id]
, pn.[type]                                                            AS  [pdw_node_type]
, pn.[name]                                                            AS  [pdw_node_name]
, di.name                                                              AS  [dist_name]
, di.position                                                          AS  [dist_position]
, nps.[partition_number]                                               AS  [partition_nmbr]
, nps.[reserved_page_count]                                            AS  [reserved_space_page_count]
, nps.[reserved_page_count] - nps.[used_page_count]                    AS  [unused_space_page_count]
, nps.[in_row_data_page_count] 
    + nps.[row_overflow_used_page_count] 
    + nps.[lob_used_page_count]                                        AS  [data_space_page_count]
, nps.[reserved_page_count] 
 - (nps.[reserved_page_count] - nps.[used_page_count]) 
 - ([in_row_data_page_count] 
         + [row_overflow_used_page_count]+[lob_used_page_count])       AS  [index_space_page_count]
, nps.[row_count]                                                      AS  [row_count]
from 
    sys.schemas s
INNER JOIN sys.tables t
    ON s.[schema_id] = t.[schema_id]
INNER JOIN sys.indexes i
    ON  t.[object_id] = i.[object_id]
    AND i.[index_id] <= 1
INNER JOIN sys.pdw_table_distribution_properties tp
    ON t.[object_id] = tp.[object_id]
INNER JOIN sys.pdw_table_mappings tm
    ON t.[object_id] = tm.[object_id]
INNER JOIN sys.pdw_nodes_tables nt
    ON tm.[physical_name] = nt.[name]
INNER JOIN sys.dm_pdw_nodes pn
    ON  nt.[pdw_node_id] = pn.[pdw_node_id]
INNER JOIN sys.pdw_distributions di
    ON  nt.[distribution_id] = di.[distribution_id]
INNER JOIN sys.dm_pdw_nodes_db_partition_stats nps
    ON nt.[object_id] = nps.[object_id]
    AND nt.[pdw_node_id] = nps.[pdw_node_id]
    AND nt.[distribution_id] = nps.[distribution_id]
LEFT OUTER JOIN (select * from sys.pdw_column_distribution_properties where distribution_ordinal = 1) cdp
    ON t.[object_id] = cdp.[object_id]
LEFT OUTER JOIN sys.columns c
    ON cdp.[object_id] = c.[object_id]
    AND cdp.[column_id] = c.[column_id]
)
, size
AS
(
SELECT
   [execution_time]
,  [database_name]
,  [schema_name]
,  [table_name]
,  [two_part_name]
,  [node_table_name]
,  [node_table_name_seq]
,  [distribution_policy_name]
,  [distribution_column]
,  [distribution_id]
,  [index_type]
,  [index_type_desc]
,  [pdw_node_id]
,  [pdw_node_type]
,  [pdw_node_name]
,  [dist_name]
,  [dist_position]
,  [partition_nmbr]
,  [reserved_space_page_count]
,  [unused_space_page_count]
,  [data_space_page_count]
,  [index_space_page_count]
,  [row_count]
,  ([reserved_space_page_count] * 8.0)                                 AS [reserved_space_KB]
,  ([reserved_space_page_count] * 8.0)/1000                            AS [reserved_space_MB]
,  ([reserved_space_page_count] * 8.0)/1000000                         AS [reserved_space_GB]
,  ([reserved_space_page_count] * 8.0)/1000000000                      AS [reserved_space_TB]
,  ([unused_space_page_count]   * 8.0)                                 AS [unused_space_KB]
,  ([unused_space_page_count]   * 8.0)/1000                            AS [unused_space_MB]
,  ([unused_space_page_count]   * 8.0)/1000000                         AS [unused_space_GB]
,  ([unused_space_page_count]   * 8.0)/1000000000                      AS [unused_space_TB]
,  ([data_space_page_count]     * 8.0)                                 AS [data_space_KB]
,  ([data_space_page_count]     * 8.0)/1000                            AS [data_space_MB]
,  ([data_space_page_count]     * 8.0)/1000000                         AS [data_space_GB]
,  ([data_space_page_count]     * 8.0)/1000000000                      AS [data_space_TB]
,  ([index_space_page_count]  * 8.0)                                   AS [index_space_KB]
,  ([index_space_page_count]  * 8.0)/1000                              AS [index_space_MB]
,  ([index_space_page_count]  * 8.0)/1000000                           AS [index_space_GB]
,  ([index_space_page_count]  * 8.0)/1000000000                        AS [index_space_TB]
FROM base
)
SELECT * 
FROM size
;

テーブル領域の概要Table space summary

次のクエリはテーブルごとに行と領域を返します。This query returns the rows and space by table. これにより、最大規模のテーブルや、各テーブルがラウンド ロビン、レプリケート、ハッシュ分散のいずれかであるかを確認できます。It allows you to see which tables are your largest tables and whether they are round-robin, replicated, or hash -distributed. ハッシュ分散テーブルの場合、クエリによってディストリビューション列が表示されます。For hash-distributed tables, the query shows the distribution column.

SELECT 
     database_name
,    schema_name
,    table_name
,    distribution_policy_name
,      distribution_column
,    index_type_desc
,    COUNT(distinct partition_nmbr) as nbr_partitions
,    SUM(row_count)                 as table_row_count
,    SUM(reserved_space_GB)         as table_reserved_space_GB
,    SUM(data_space_GB)             as table_data_space_GB
,    SUM(index_space_GB)            as table_index_space_GB
,    SUM(unused_space_GB)           as table_unused_space_GB
FROM 
    dbo.vTableSizes
GROUP BY 
     database_name
,    schema_name
,    table_name
,    distribution_policy_name
,      distribution_column
,    index_type_desc
ORDER BY
    table_reserved_space_GB desc
;

ディストリビューションの種類別のテーブル領域Table space by distribution type

SELECT 
     distribution_policy_name
,    SUM(row_count)                as table_type_row_count
,    SUM(reserved_space_GB)        as table_type_reserved_space_GB
,    SUM(data_space_GB)            as table_type_data_space_GB
,    SUM(index_space_GB)           as table_type_index_space_GB
,    SUM(unused_space_GB)          as table_type_unused_space_GB
FROM dbo.vTableSizes
GROUP BY distribution_policy_name
;

インデックスの種類別のテーブル領域Table space by index type

SELECT 
     index_type_desc
,    SUM(row_count)                as table_type_row_count
,    SUM(reserved_space_GB)        as table_type_reserved_space_GB
,    SUM(data_space_GB)            as table_type_data_space_GB
,    SUM(index_space_GB)           as table_type_index_space_GB
,    SUM(unused_space_GB)          as table_type_unused_space_GB
FROM dbo.vTableSizes
GROUP BY index_type_desc
;

ディストリビューション領域の概要Distribution space summary

SELECT 
    distribution_id
,    SUM(row_count)                as total_node_distribution_row_count
,    SUM(reserved_space_MB)        as total_node_distribution_reserved_space_MB
,    SUM(data_space_MB)            as total_node_distribution_data_space_MB
,    SUM(index_space_MB)           as total_node_distribution_index_space_MB
,    SUM(unused_space_MB)          as total_node_distribution_unused_space_MB
FROM dbo.vTableSizes
GROUP BY     distribution_id
ORDER BY    distribution_id
;

次の手順Next steps

データ ウェアハウスにテーブルを作成した後、次の手順はテーブルへのデータの読み込みです。After creating the tables for your data warehouse, the next step is to load data into the table. 読み込みのチュートリアルについては、「Azure SQL Data Warehouse へのデータの読み込み」を参照してください。For a loading tutorial, see Loading data to SQL Data Warehouse.