Condividi tramite

Schemi definiti dall'utente per pool SQL dedicati in Azure Synapse Analytics

  • Articolo

Questo articolo è incentrato sull'uso di schemi T-SQL definiti dall'utente per sviluppare soluzioni nel pool SQL dedicato.

Schemi per i limiti dell'applicazione

I data warehouse tradizionali spesso usano database separati per creare i limiti dell'applicazione in base a carico di lavoro, dominio o di sicurezza.

Ad esempio, un data warehouse di SQL Server tradizionale potrebbe includere un database di gestione temporanea, un database del data warehouse e alcuni database del data mart. In questa topologia ogni database funziona come carico di lavoro e limite di sicurezza nell'architettura.

Al contrario, un pool SQL dedicato esegue tutto il carico di lavoro del data warehouse all'interno di un database. I join tra database non sono consentiti. Il pool SQL dedicato prevede pertanto che tutte le tabelle usate dal data warehouse siano archiviate all'interno di un database.

Nota

Il pool SQL non supporta query tra database di alcun tipo. Di conseguenza, le implementazioni di data warehouse che usano questo modello dovranno essere modificate.

Consigli

Di seguito sono riportati i consigli per consolidare carichi di lavoro, sicurezza, dominio e limiti funzionali usando schemi definiti dall'utente:

  • Usare un database in un pool SQL dedicato per eseguire l'intero carico di lavoro del data warehouse.
  • Consolidare l'ambiente data warehouse esistente per usare un database del pool SQL dedicato.
  • Sfruttare gli schemi definiti dall'utente per fornire il limite implementato in precedenza tramite database.

Se gli schemi definiti dall'utente non sono stati usati in precedenza, si avrà uno slate pulito. Usare il nome del database precedente come base per gli schemi definiti dall'utente nel database del pool SQL dedicato.

Se gli schemi sono già stati usati, sono disponibili alcune opzioni:

  • Rimuovere i nomi degli schemi legacy e ricominciare dall'inizio.
  • Mantenere i nomi degli schemi legacy premettendo il nome dello schema legacy al nome della tabella.
  • Mantenere i nomi degli schemi legacy implementando viste sulla tabella in uno schema aggiuntivo per ricreare la struttura dello schema precedente.

Nota

A prima vista, l'opzione 3 può sembrare quella più interessante. È tuttavia importante osservare i dettagli. Le viste sono di sola lettura nel pool SQL dedicato. Qualsiasi modifica di dati o tabelle dovrà essere eseguita sulla tabella di base. L'opzione 3 introduce anche un livello di viste nel sistema. È consigliabile valutare attentamente questo aspetto se si usano già viste nell'architettura.

Esempi:

Implementare schemi definiti dall'utente in base ai nomi di database:

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

Mantenere nomi di schemi legacy anteponendoli al nome della tabella. Usare schemi per il limite del carico di lavoro:

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

Mantenere i nomi di schemi legacy usando viste:

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

Qualsiasi modifica nella strategia relativa agli schemi richiede una revisione del modello di sicurezza per il database. In molti casi è possibile semplificare il modello di sicurezza assegnando le autorizzazioni a livello di schema. Se sono necessarie autorizzazioni più granulari, è possibile utilizzare i ruoli del database.

Passaggi successivi

Per altri suggerimenti sullo sviluppo, vedere la panoramica dello sviluppo.