Esquemas definidos pelo usuário para pools de SQL dedicados no Azure Synapse Analytics

  • Artigo

Este artigo se concentra em fornecer várias dicas para usar esquemas definidos pelo usuário do T-SQL para desenvolver soluções no pool de SQL dedicado.

Esquemas para limites de aplicativo

Os data warehouses tradicionais normalmente usam bancos de dados separados para criar limites de aplicativo com base na carga de trabalho, domínio ou segurança.

Como exemplo, um data warehouse tradicional do SQL Server pode incluir um banco de dados de preparo, um banco de dados do data warehouse e alguns bancos de dados do data mart. Nesta topologia, cada banco de dados funciona como uma carga de trabalho e limite de segurança na arquitetura.

Por outro lado, o pool de SQL dedicado executa toda a carga de trabalho do data warehouse em um só banco de dados. Junções cruzadas de banco de dados não são permitidas. Portanto, o pool de SQL dedicado espera que todas as tabelas usadas pelo warehouse sejam armazenadas em um só banco de dados.

Observação

O pool de SQL não oferece suporte a nenhum tipo de consulta cruzada de banco de dados. Consequentemente, implementações de data warehouse que utilizam esse padrão precisarão ser revisadas.

Recomendações

A seguir estão recomendações para consolidar limites funcionais, de carga de trabalho, segurança e domínio usando esquemas definidos pelo usuário:

  • Use um banco de dados em um pool de SQL dedicado para executar toda a carga de trabalho do data warehouse.
  • Consolide seu ambiente de data warehouse existente para usar um banco de dados do pool de SQL dedicado.
  • Utilize esquemas definidos pelo usuário para fornecer o limite implementado anteriormente usando bancos de dados.

Se os esquemas definidos pelo usuário não foram usados antes, então você tem uma área limpa. Use um nome antigo do banco de dados como base para os esquemas definidos pelo usuário no banco de dados do pool de SQL dedicado.

Se os esquemas já foram usados, então você tem algumas opções:

  • Remover os nomes de esquema herdados e começar do zero.
  • Manter os nomes de esquema herdados acrescentando o nome do esquema herdado ao nome da tabela.
  • Manter os nomes de esquema herdados implementando exibições sobre a tabela em um esquema extra para recriar a estrutura do esquema antigo.

Observação

Na primeira inspeção, a opção 3 pode parecer a opção mais atraente. No entanto, o detalhe é traiçoeiro. As exibições estão no modo somente leitura no pool de SQL dedicado. Qualquer modificação nos dados ou na tabela precisariam ser executados em relação à tabela base. A opção 3 também apresenta uma camada de modos de exibição em seu sistema. Talvez você queira pensar um pouco sobre isso se já estiver usando modos de exibição em sua arquitetura.

Exemplos:

Implementar esquemas definidos pelo usuário com base em nomes de banco de dados:

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
,       ...
);

Manter nomes de esquema herdados acrescentando-os ao nome da tabela. Usar esquemas para o limite de carga de trabalho:

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
,       ...
);

Manter nomes de esquema herdados usando modos de exibição:

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
;

Observação

Qualquer alteração na estratégia de esquema precisa de uma revisão do modelo de segurança para o banco de dados. Em muitos casos, você poderá simplificar o modelo de segurança ao atribuir permissões no nível do esquema. Se forem necessárias permissões mais granulares, então você poderá usar funções de banco de dados.

Próximas etapas

Para obter mais dicas de desenvolvimento, confira visão geral de desenvolvimento.