Delen via

Door de gebruiker gedefinieerde schema's voor toegewezen SQL-pools in Azure Synapse Analytics

  • Artikel

Dit artikel richt zich op het bieden van verschillende tips voor het gebruik van door de gebruiker gedefinieerde T-SQL-schema's voor het ontwikkelen van oplossingen in een toegewezen SQL-pool.

Schema's voor toepassingsgrenzen

Traditionele datawarehouses gebruiken vaak afzonderlijke databases om toepassingsgrenzen te maken op basis van workload, domein of beveiliging.

Een traditioneel SQL Server-datawarehouse kan bijvoorbeeld een faseringsdatabase, een datawarehousedatabase en een aantal datamart-databases bevatten. In deze topologie werkt elke database als een workload en beveiligingsgrens in de architectuur.

Een toegewezen SQL-pool voert daarentegen de volledige datawarehouse-workload uit binnen één database. Joins tussen databases zijn niet toegestaan. Gedelegeerde SQL-pool verwacht dat alle tabellen die door het datawarehouse worden gebruikt, worden opgeslagen in één enkele database.

Notitie

SQL-pool biedt geen ondersteuning voor query's voor meerdere databases van welke aard dan ook. Daarom moeten datawarehouse-implementaties die gebruikmaken van dit patroon herzien worden.

Aanbevelingen

Hieronder volgen aanbevelingen voor het consolideren van workloads, beveiliging, domein en functionele grenzen met behulp van door de gebruiker gedefinieerde schema's:

  • Gebruik één database in een toegewezen SQL-pool om uw volledige datawarehouseworkload uit te voeren.
  • Voeg uw bestaande datawarehouse-omgeving samen om één toegewezen SQL-pooldatabase te gebruiken.
  • Maak gebruik van door de gebruiker gedefinieerde schema's om de grens te definiëren die eerder is geïmplementeerd met behulp van databases.

Als door de gebruiker gedefinieerde schema's nog niet eerder zijn gebruikt, hebt u een schone lei. Gebruik de oude databasenaam als basis voor uw door de gebruiker gedefinieerde schema's in de toegewezen SQL-pooldatabase.

Als schema's al zijn gebruikt, hebt u een aantal opties:

  • Verwijder de verouderde schemanamen en begin nieuw.
  • Behoud de verouderde schemanamen door de verouderde schemanaam vooraf te plaatsen aan de tabelnaam.
  • Behoud de verouderde schemanamen door weergaven over de tabel in een extra schema te implementeren om de oude schemastructuur opnieuw te maken.

Notitie

Bij eerste inspectieoptie 3 lijkt het misschien wel de meest aantrekkelijke optie. De duivel zit in de details. Weergaven zijn alleen-lezen in een toegewezen SQL-pool. Wijzigingen in gegevens of tabellen moeten worden uitgevoerd op basis van de basistabel. Optie 3 introduceert ook een laag van zicht in uw systeem. Misschien wilt u hier wat extra over nadenken als u al weergaven in uw architectuur gebruikt.

Voorbeelden:

Door de gebruiker gedefinieerde schema's implementeren op basis van databasenamen:

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

Behoud verouderde schemanamen door deze vooraan de tabelnaam toe te voegen. Gebruik schema's voor de grens van de werkbelasting:

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

Verouderde schemanamen behouden met behulp van weergaven:

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
;

Notitie

Elke wijziging in de schemastrategie heeft een beoordeling van het beveiligingsmodel voor de database nodig. In veel gevallen kunt u het beveiligingsmodel mogelijk vereenvoudigen door machtigingen toe te wijzen op schemaniveau. Als er meer gedetailleerde machtigingen zijn vereist, kunt u databaserollen gebruiken.

Volgende stappen

Zie ontwikkelingsoverzicht voor meer ontwikkelingstips.