Schematy zdefiniowane przez użytkownika dla dedykowanych pul SQL w usłudze Azure Synapse Analytics

Ten artykuł koncentruje się na udostępnianiu kilku wskazówek dotyczących używania schematów zdefiniowanych przez użytkownika języka T-SQL do tworzenia rozwiązań w dedykowanej puli SQL.

Schematy granic aplikacji

Tradycyjne magazyny danych często używają oddzielnych baz danych do tworzenia granic aplikacji na podstawie obciążenia, domeny lub zabezpieczeń.

Na przykład tradycyjny magazyn danych SQL Server może obejmować tymczasową bazę danych, bazę danych magazynu danych i niektóre bazy danych składnic danych. W tej topologii każda baza danych działa jako granica obciążenia i zabezpieczeń w architekturze.

Natomiast dedykowana pula SQL uruchamia całe obciążenie magazynu danych w jednej bazie danych. Sprzężenia między bazami danych nie są dozwolone. Dedykowana pula SQL oczekuje, że wszystkie tabele używane przez magazyn będą przechowywane w jednej bazie danych.

Uwaga

Pula SQL nie obsługuje zapytań między bazami danych jakiegokolwiek rodzaju. W związku z tym implementacje magazynu danych wykorzystujące ten wzorzec będą musiały zostać zmienione.

Zalecenia

Poniżej przedstawiono zalecenia dotyczące konsolidowania obciążeń, zabezpieczeń, domeny i granic funkcjonalnych przy użyciu schematów zdefiniowanych przez użytkownika:

  • Użyj jednej bazy danych w dedykowanej puli SQL, aby uruchomić całe obciążenie magazynu danych.
  • Skonsoliduj istniejące środowisko magazynu danych, aby używać jednej dedykowanej bazy danych puli SQL.
  • Korzystaj ze schematów zdefiniowanych przez użytkownika , aby zapewnić granicę wcześniej zaimplementowaną przy użyciu baz danych.

Jeśli schematy zdefiniowane przez użytkownika nie były wcześniej używane, masz czystą tablicę. Użyj starej nazwy bazy danych jako podstawy schematów zdefiniowanych przez użytkownika w dedykowanej bazie danych puli SQL.

Jeśli schematy zostały już użyte, masz kilka opcji:

  • Usuń starsze nazwy schematów i zacznij od nowa.
  • Zachowaj starsze nazwy schematów przez wstępne oczekiwanie na starszą nazwę schematu do nazwy tabeli.
  • Zachowaj starsze nazwy schematów, implementując widoki w tabeli w dodatkowym schemacie, aby ponownie utworzyć starą strukturę schematu.

Uwaga

Przy pierwszej opcji inspekcji 3 może wydawać się najbardziej atrakcyjną opcją. Jednak diabeł jest w szczegółach. Widoki są tylko do odczytu w dedykowanej puli SQL. Wszelkie modyfikacje danych lub tabel muszą być wykonywane względem tabeli podstawowej. Opcja 3 wprowadza również warstwę widoków do systemu. Jeśli już używasz widoków w architekturze, możesz chcieć podać tę dodatkową myśl.

Przykłady:

Zaimplementuj schematy zdefiniowane przez użytkownika na podstawie nazw baz danych:

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

Zachowaj starsze nazwy schematów przez wstępne oczekiwanie na nazwę tabeli. Użyj schematów dla granicy obciążenia:

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

Zachowaj starsze nazwy schematów przy użyciu widoków:

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
;

Uwaga

Każda zmiana strategii schematu wymaga przeglądu modelu zabezpieczeń bazy danych. W wielu przypadkach można uprościć model zabezpieczeń, przypisując uprawnienia na poziomie schematu. Jeśli wymagane są bardziej szczegółowe uprawnienia, możesz użyć ról bazy danych.

Następne kroki

Aby uzyskać więcej porad dotyczących programowania, zobacz Omówienie programowania.