次の方法で共有

Azure Synapse Analytics の専用 SQL プールのユーザー定義スキーマ

この記事では、T-SQL ユーザー定義スキーマを使用して専用 SQL プールでソリューションを開発するためのいくつかのヒントを提供することに重点を置いています。

アプリケーション境界のスキーマ

従来のデータ ウェアハウスでは、多くの場合、ワークロード、ドメイン、またはセキュリティに基づいてアプリケーション境界を作成するために、個別のデータベースが使用されます。

たとえば、従来の SQL Server データ ウェアハウスには、ステージング データベース、データ ウェアハウス データベース、一部のデータ マート データベースが含まれる場合があります。 このトポロジでは、各データベースは、アーキテクチャのワークロードとセキュリティの境界として動作します。

これに対し、専用 SQL プールは、1 つのデータベース内でデータ ウェアハウス ワークロード全体を実行します。 複数データベース間の結合は許可されません。 専用 SQL プールでは、ウェアハウスで使用されるすべてのテーブルが 1 つのデータベース内に格納されることを想定しています。

注

SQL プールでは、どのような種類のデータベース間クエリもサポートされていません。 そのため、このパターンを利用するデータ ウェアハウスの実装を変更する必要があります。

推奨事項

ユーザー定義スキーマを使用してワークロード、セキュリティ、ドメイン、機能の境界を統合するための推奨事項を次に示します。

  • 専用 SQL プール内の 1 つのデータベースを使用して、データ ウェアハウス ワークロード全体を実行します。
  • 既存のデータ ウェアハウス環境を統合して、1 つの専用 SQL プール データベースを使用します。
  • ユーザー定義スキーマを利用して、以前にデータベースを使用して実装した境界を提供します。

ユーザー定義スキーマが以前に使用されていない場合は、自由に始められます。 専用 SQL プール データベースのユーザー定義スキーマの基礎として、古いデータベース名を使用します。

スキーマが既に使用されている場合は、いくつかのオプションがあります。

  • 従来のスキーマ名を削除し、新たに開始します。
  • レガシ スキーマ名を保持するため、テーブル名の先頭にレガシ スキーマ名を付加します。
  • 以前のスキーマ構造を再作成するために、追加のスキーマにテーブルのビューを実装することで、レガシ スキーマ名を保持します。

注

最初の検査オプションでは、3は最も魅力的なオプションのように見えるかもしれません。 しかし、細部にこそ問題が潜んでいます。 ビューは専用 SQL プールで読み取り専用です。 データまたはテーブルの変更は、ベース テーブルに対して実行する必要があります。 オプション 3 では、システムにビューのレイヤーも導入されています。 アーキテクチャでビューを既に使用している場合は、この追加の考慮事項を考える必要があります。

例：

データベース名に基づいてユーザー定義スキーマを実装します。

CREATE SCHEMA [stg]; -- stg previously database name for staging database
GO
CREATE SCHEMA [edw]; -- edw previously database name for the data warehouse
GO
CREATE TABLE [stg].[customer] -- create staging tables in the stg schema
(       CustKey BIGINT NOT NULL
,       ...
);
GO
CREATE TABLE [edw].[customer] -- create data warehouse tables in the edw schema
(       CustKey BIGINT NOT NULL
,       ...
);

従来のスキーマ名をテーブル名の先頭に追加することで保持します。 ワークロード境界にスキーマを使用します。

CREATE SCHEMA [stg]; -- stg defines the staging boundary
GO
CREATE SCHEMA [edw]; -- edw defines the data warehouse boundary
GO
CREATE TABLE [stg].[dim_customer] --pre-pend the old schema name to the table and create in the staging boundary
(       CustKey BIGINT NOT NULL
,       ...
);
GO
CREATE TABLE [edw].[dim_customer] --pre-pend the old schema name to the table and create in the data warehouse boundary
(       CustKey BIGINT NOT NULL
,       ...
);

ビューを使用して、従来のスキーマ名を保持します。

CREATE SCHEMA [stg]; -- stg defines the staging boundary
GO
CREATE SCHEMA [edw]; -- stg defines the data warehouse boundary
GO
CREATE SCHEMA [dim]; -- edw defines the legacy schema name boundary
GO
CREATE TABLE [stg].[customer] -- create the base staging tables in the staging boundary
(       CustKey    BIGINT NOT NULL
,       ...
)
GO
CREATE TABLE [edw].[customer] -- create the base data warehouse tables in the data warehouse boundary
(       CustKey    BIGINT NOT NULL
,       ...
)
GO
CREATE VIEW [dim].[customer] -- create a view in the legacy schema name boundary for presentation consistency purposes only
AS
SELECT  CustKey
,       ...
FROM    [edw].customer
;

注

スキーマ戦略の変更には、データベースのセキュリティ モデルのレビューが必要です。 多くの場合、スキーマ レベルでアクセス許可を割り当てることで、セキュリティ モデルを簡略化できる場合があります。 より詳細なアクセス許可が必要な場合は、データベース ロールを使用できます。

次のステップ

開発についてのその他のヒントは、開発の概要に関するページをご覧ください。