次の方法で共有

Synapse SQL 内のユーザー定義スキーマ

以下のセクションでは、T-SQL ユーザー定義スキーマを使用して Synapse SQL 内でソリューションを開発するためのさまざまなヒントを紹介します。

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

従来の分析アーキテクチャでは、多くの場合、個別のデータベースを使用して、ワークロード、ドメイン、またはセキュリティに基づいてアプリケーションの境界を作成します。 たとえば、従来の SQL Server 分析インフラストラクチャには、ステージング データベース、分析データベース、データ マート データベースなどがあります。 このトポロジでは、各データベースは、アーキテクチャのワークロードとセキュリティの境界として動作します。

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

注

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

ユーザー定義スキーマの推奨事項

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

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

ユーザー定義スキーマが以前に使用されていない場合は、初期状態です。 Synapse SQL データベースのユーザー定義スキーマの基礎として、古いデータベース名を使用します。

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

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

注

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

例示

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

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

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

CREATE SCHEMA [stg]; -- stg defines the staging boundary
GO
CREATE SCHEMA [edw]; -- edw defines the analytics 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 analytics boundary
(       CustKey BIGINT NOT NULL
,       ...
);

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

CREATE SCHEMA [stg]; -- stg defines the staging boundary
GO
CREATE SCHEMA [edw]; -- stg defines the analytics 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 analytics tables in the analytics 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
;

注

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

より詳細なアクセス許可が必要な場合は、データベース ロールを使用できます。 データベース ロールの詳細については、データベース ロール とユーザーの管理 に関する記事を参照してください。

次のステップ

開発に関するその他のヒントについては、Synapse SQL の開発の概要に関する記事をご覧ください。