Esquemas definidos pelo utilizador para conjuntos de SQL dedicados no Azure Synapse Analytics

Este artigo centra-se em fornecer várias sugestões para utilizar esquemas definidos pelo utilizador do T-SQL para desenvolver soluções no conjunto de SQL dedicado.

Esquemas para limites de aplicações

Os armazéns de dados tradicionais utilizam frequentemente bases de dados separadas para criar limites de aplicações com base na carga de trabalho, domínio ou segurança.

Por exemplo, um armazém de dados de SQL Server tradicional pode incluir uma base de dados de teste, uma base de dados do armazém de dados e algumas bases de dados do data mart. Nesta topologia, cada base de dados funciona como uma carga de trabalho e limite de segurança na arquitetura.

Por outro lado, um conjunto de SQL dedicado executa toda a carga de trabalho do armazém de dados numa base de dados. Não são permitidas associações entre bases de dados. O Conjunto de SQL dedicado espera que todas as tabelas utilizadas pelo armazém sejam armazenadas numa base de dados.

Nota

O conjunto de SQL não suporta qualquer tipo de consultas entre bases de dados. Consequentemente, as implementações do armazém de dados que tiram partido deste padrão terão de ser revistas.

Recomendações

Seguem-se recomendações para consolidar cargas de trabalho, segurança, domínio e limites funcionais com esquemas definidos pelo utilizador:

• Utilize uma base de dados num conjunto de SQL dedicado para executar toda a carga de trabalho do armazém de dados.
• Consolide o ambiente do armazém de dados existente para utilizar uma base de dados de conjunto de SQL dedicada.
• Tire partido dos esquemas definidos pelo utilizador para fornecer o limite anteriormente implementado com bases de dados.

Se os esquemas definidos pelo utilizador não tiverem sido utilizados anteriormente, significa que tem uma folha limpa. Utilize o nome da base de dados antigo como base para os esquemas definidos pelo utilizador na base de dados do conjunto de SQL dedicado.

Se os esquemas já tiverem sido utilizados, tem algumas opções:

• Remova os nomes de esquema legados e comece de novo.
• Mantenha os nomes de esquema legados ao pré-aguardar o nome do esquema legado para o nome da tabela.
• Mantenha os nomes de esquema legados ao implementar vistas sobre a tabela num esquema extra para recriar a estrutura de esquema antiga.

Nota

Na primeira opção de inspeção 3 pode parecer a opção mais apelativa. No entanto, o diabo está nos detalhes. As vistas são lidas apenas no conjunto de SQL dedicado. Qualquer modificação de dados ou tabela teria de ser efetuada na tabela base. A opção 3 também introduz uma camada de vistas no seu sistema. Poderá querer pensar melhor se já estiver a utilizar vistas na sua arquitetura.

Exemplos:

Implementar esquemas definidos pelo utilizador com base nos nomes das bases 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
,       ...
);

Mantenha os nomes de esquema legados ao pré-os pendentes para o nome da tabela. Utilize esquemas para o limite da 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
,       ...
);

Mantenha os nomes de esquema legados com vistas:

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
;

Nota

Qualquer alteração na estratégia de esquema precisa de uma revisão do modelo de segurança da base de dados. Em muitos casos, poderá conseguir simplificar o modelo de segurança ao atribuir permissões ao nível do esquema. Se forem necessárias permissões mais granulares, pode utilizar funções de base de dados.

Passos seguintes

Para obter mais sugestões de desenvolvimento, veja Descrição geral do desenvolvimento.