Ambarlar arası bağımlılıkları geliştirme ve dağıtma

Bu makalede, Visual Studio Code'da SQL veritabanı projelerini kullanarak ambarlar arası bağımlılıkları modellemeyi ve dağıtmayı öğreneceksiniz. Mevcut iki ambar projesinden başlayıp veritabanı başvurularını ve gerektiğinde dağıtım öncesi ve dağıtım sonrası betiklerini kullanarak aralarında tek yönlü bağımlılıklar yapılandırabilirsiniz.

Bu makale , Visual Studio Code'da ambar projeleri geliştirme başlığındaki kavramları temel alır ve tek bir ambar projesi oluşturup yayımlama konusunda zaten rahat olduğunuzu varsayar.

Önkoşullar

Başlamadan önce şunları yaptığınızdan emin olun:

• Aynı çalışma alanında iki Doku Ambarı oluşturun.
  • Yeni bir örnek ambar oluşturmak için bkz. Microsoft Fabric'te örnek Ambar oluşturma.
• Visual Studio Code'da her ambar için bir veritabanı projesi oluşturun veya ayıklayın.
  • Mevcut ambarınız veya yeni bir ambarınız için veritabanı projesi oluşturmak için bkz. Visual Studio Code'da ambar projeleri geliştirme.
• Visual Studio Code'u iş istasyonunuza yükleyin.
• Veritabanı projeleri oluşturmak ve yayımlamak için .NET SDK'sını yükleyin.
• İki Visual Studio Code uzantısı yükleyin: SQL Veritabanı Projeleri ve SQL Server (mssql)...
  • "SQL Veritabanı Projeleri" veya "SQL Server (mssql)" araması yaparak gerekli uzantıları doğrudan Visual Studio Code marketinden yükleyebilirsiniz.
• Ambar projeleri Visual Studio Code'da doğrulanabilir, derlenebilir ve yayımlanabilir.

Uyarı

Bu makale, Visual Studio Code'daki ambar projelerine ve bunları Git'te normal kod projeleri olarak nasıl sürüm oluşturduğunuza odaklanır. Çalışma alanları ve ambar öğeleri için Doku Git tümleştirmesi , Doku Veri Ambarı ve Git tümleştirme belgeleriyle Kaynak denetiminde ayrı olarak ele alınmıştır. Makalede, Doku çalışma alanınızın dağıtım hedefi olduğu ve T-SQL şemasının Git'te sürüm denetimi yaptığınız bir veya daha fazla Visual Studio Code projesinde yer aldığı varsayılır.

Bu makale bir Lakehouse'un SQL analitik uç noktası için depolararası geliştirmeyi kapsamaz. Lakehouse tabloları ve SQL uç noktası nesneleri, ambar projelerinin olduğu gibi kaynak denetiminde izlenen nesneler değildir. Fabric yerel deneyimlerinde ve istemci araçlarında tam git tümleştirmesi ve dağıtım desteği için Ambar öğelerini veritabanı projeleriyle kullanın.

Senaryo: Zava Analytics alanlar arası depolar

Zava Analytics iki iş alanı kullanır:

• Satış – müşteri siparişleri, gelir ve işlem hattı ölçümleri.
• Pazarlama – kampanyalar, kanallar ve etkileşim ölçümleri.

Her alan adı şunu içerir:

• Aynı çalışma alanında bir Doku Ambarı :

  • ZavaSalesWarehouse
  • ZavaMarketingWarehouse

• Visual Studio Code'da veritabanı projesi :

  • Zava.Sales.Warehouse
  • Zava.Marketing.Warehouse

Uçtan uca ELT ve raporlama oluşturmak için her etki alanının diğer etki alanındaki verilere erişmek için salt okunur görünümlere sahip olması gerekir:

• Sales müşteri tarafından pazarlama etkileşimi gerekiyor.
• Marketing kampanyaya göre satış performansına ihtiyaç duyar.

Şunları yapmanız gerekir:

• Veritabanı referansları aracılığıyla tek yönlü ambarlar arası bağımlılıklar oluşturun.
• Döngüsel bağımlılıklardan kaçının.
• Her iki ambardaki nesnelerin birbirine bağımlı olduğu durumlar için dağıtım öncesi ve sonrası betikleri kullanın.

Ambarlar arasındaki bağımlılıkların tek yönlü olduğundan emin olun

Her ambar çifti için, mantıksal bağımlılığın yönünü seçin.

Örnek:

• Sales görevlendirme verilerine bağlıdır Marketing .
• Marketing Sales gerekli olan nesnelere bağımlı değildir.

Uygulamada:

Zava.Sales.Warehouse bir veritabanı referansınaZava.Marketing.Warehouse sahiptir.

• Depodaki Sales T-SQL şu şekilde üç parçalı adları kullanabilir:

  SELECT * FROM ZavaMarketingWarehouse.Marketing.CampaignEngagement
  

• Zava.Marketing.Warehousedağıtım zamanında bağımlılık döngüsünü zorlayacak nesnelere başvurmazSales.

Tip

Her ambar çifti için basit bir ok diyagramı (Sales → Marketing) çizin. Aynı nesne türü için her iki yönü işaret eden oklar bulursanız, büyük olasılıkla bazı mantığı yeniden düzenlemeniz veya dağıtım öncesi ve sonrası betiklere taşımanız gerekir.

Döngüsel bağımlılıklardan kaçının

A Ambar ve B Ambar, motorun tek bir dağıtımda çözümleyemeyeceği şekilde birbirine bağımlı olduğunda bir döngüsel bağımlılık meydana gelir.

Sorun örneği (bunu yapmayın):

• ZavaSalesWarehouse.dbo.CustomerRollup görünüm:

  CREATE VIEW dbo.CustomerRollup AS
  SELECT  c.CustomerId,
          c.TotalRevenue,
          m.LastCampaignId
  FROM    dbo.CustomerRevenue AS c
  LEFT OUTER JOIN   
          ZavaMarketingWarehouse.dbo.CustomerEngagement AS m
          ON c.CustomerId = m.CustomerId;
  

• ZavaMarketingWarehouse.dbo.CampaignAttribution görünüm:

  CREATE VIEW dbo.CampaignAttribution AS
  SELECT  m.CampaignId,
          SUM(s.TotalRevenue) AS RevenueAttributed
  FROM    dbo.Campaigns AS m
  LEFT OUTER JOIN    
          ZavaSalesWarehouse.dbo.CustomerRollup AS s
          ON m.CampaignId = s.LastCampaignId
  GROUP BY m.CampaignId;
  

Bu anti-paternde:

• CustomerRollup içinde Satış, CustomerEngagementPazarlama'ya bağlıdır.
• CampaignAttribution Pazarlama, CustomerRollupSatış'a bağlıdır.

Bu anti-patern bir döngü oluşturur: Satış görünümü → Pazarlama görünümü → Yeniden satış görünümü.

Rehber:

Ambarlar arasındaki karşılıklı bağımlılıkları normal şema düzeyinde nesneler olarak modellemeyin. Bu tür bir mantığa gerçekten ihtiyacınız varsa bağımlılığın bir tarafını şuraya taşıyın:

• Dağıtım sonrası betiği veya
• Sorgulama esnasında iki ambarı birleştiren aşağı akış semantik modeli veya raporu.

Dağıtıma duyarlı depolar arası mantık için dağıtım öncesi ve sonrası komut dosyalarını kullanın.

Ambar dağıtımları tam şema farklılaştırma işlemleridir (nesne başına kısmi dağıtımlar olmadığından), ambarlar arası öğeleri dikkatli bir şekilde işleyin.

Ambar A ve Ambar B'nin birbirine bağlı nesnelere ihtiyacı varsa:

• Her ambar projesinde çekirdek tabloları ve çekirdek görünümleri tutun.
• Döngüler oluşturan köprü görünümlerini veya yardımcı program nesnelerini tek bir projede dağıtım öncesi veya dağıtım sonrası betiklere taşıyın.
• Bu betiklerin idempotent olduğundan ve yeniden çalıştırılması güvenli olduğundan emin olun.

Örnek desenler:

• Dağıtım öncesi betiği: Bunu bozacak şema değişikliklerini uygulamadan önce geçici olarak ambarlar arası görünümü bırakın.
• Dağıtım sonrası betiği: Her iki ambar da dağıtıldıktan sonra çapraz ambar görünümünü yeniden oluşturun veya güncelleştirin.

Örüntü 1: Veritabanı referansları yoluyla doğrudan çapraz depo referansları

Bu düzende, Veritabanı Başvuruları'nı kullanarak doğrudan veritabanı projelerinde tek yönlü bağımlılıkları modellemeniz gerekir.

1. Adım: Mevcut iki ambar projesinden başlayın

Zaten sahip olmanız gerekenler:

• Zava.Sales.Warehouse → dağıtıldı ZavaSalesWarehouse
• Zava.Marketing.Warehouse → dağıtıldı ZavaMarketingWarehouse

Her proje , Visual Studio Code'da ambar projeleri geliştirme adımları kullanılarak oluşturulmuş veya ayıklanmış.

2. Adım: Satıştan Pazarlamaya veritabanı referansı ekleme

• Visual Studio Code'da Veritabanı Projeleri görünümünü açın.
• Projeye sağ tıklayın Zava.Sales.Warehouse .
• Veritabanı Başvurusu Ekle...'yi seçin.
• Bunlardan birini seçin:
  • Geçerli çalışma alanında veritabanı projesi (Bu şekilde başvuruda bulunılan bir veritabanı projesi de Visual Studio Code'da açık olmalıdır) veya
  • Veri katmanı uygulaması (.dacpac) (Ambar için bir .dacpac oluşturduysanız, Marketing oluşturulmuş varsayılır).
• Başvuru seçeneklerini ayarlayın:
  • Başvuru türü: Aynı sunucu, farklı veritabanı.
  • Veritabanı adı veya değişkeni: SQLCMD değişkeni kullanın, örneğin [$(MarketingWarehouseName)].
• Sales projesini kaydedin ve yeniden oluşturun.

.sqlproj Dosyasında şuna benzer bir girdi görmeniz gerekir:

<ItemGroup>
  <ArtifactReference Include="..\Zava.Marketing.Warehouse\bin\Debug\Zava.Marketing.Warehouse.dacpac">
    <DatabaseVariableLiteralValue>$(MarketingWarehouseName)</DatabaseVariableLiteralValue>
  </ArtifactReference>
</ItemGroup>
<ItemGroup>
  <SqlCmdVariable Include="MarketingWarehouseName">
    <DefaultValue>ZavaMarketingWarehouse</DefaultValue>
  </SqlCmdVariable>
</ItemGroup>

Tip

Uzak ambar adı için bir SQLCMD değişkeni kullanmak, ambar adlarının farklı olabileceği Geliştirme/Test/Üretim gibi tüm ortamlarınızda aynı projeyi yeniden kullanmanıza olanak tanır.

3. Adım: Satış'ta ambarlar arası görünüm oluşturma

Projede, Sales projesine bir görünüm ekleyin ve bu görünüm Marketing deposundan okuma yapsın.

-- schema/Views/dbo.CustomerEngagementFact.sql
CREATE VIEW [dbo].[CustomerEngagementFact] AS
SELECT
    s.CustomerId,
    s.TotalRevenue,
    m.LatestChannel,
    m.LastEngagementDate
FROM dbo.CustomerRevenue AS s
JOIN [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] AS m
    ON s.CustomerId = m.CustomerId;

Önemli noktalar:

• Üç parçalı ad [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] , Doku SQL düzenleyicisindeki ambarlar arası sorgular için kullanılan T-SQL deseni ile eşleşir.
• DacFx, dış veritabanını veritabanı başvurusu aracılığıyla çözümler.

SQL71501 çözümlenmemiş referans hataları olmadığından emin olmak için projeyi oluşturun.

4. Adım: Pazarlama ambarını ve ardından Satışları yayımlama

Dağıtım sorunlarını önlemek için:

• Derleme ve yayımlamaZava.Marketing.Warehouse öncelikle:
  • Projeye sağ tıklayın → Derle.
  • Projeyi sağ tıklatın → Yayımla'yı seçin → seçin ZavaMarketingWarehouse.
• Dağıtım başarılı olduktan sonra Marketingderleyin ve yayımlayınZava.Sales.Warehouse:
  • Projeye sağ tıklayın → Derle.
  • Projeyi sağ tıklatın → Yayımla'yı seçin → seçin ZavaSalesWarehouse.

Sonuçta elde edilen dağıtım akışı:

Zava.Marketing.Warehouse (dış bağımlılık yok) → Zava.Sales.Warehouse (bağımlıdır Marketing)

Artık, ZavaSalesWarehouse içindeki herhangi bir T-SQL sorgusu, çapraz depo T-SQL kullanarak depodan Marketing dahili olarak okunan dbo.CustomerEngagementFact görünümünü kullanabilir.

Model 2: Dağıtım öncesi ve sonrası betiklerle yönetilen ambarlar arası bağımlılıklar

Bazı Zava Analytics senaryolarında her iki etki alanında da birbirine bağlı toplu nesneler gerekebilir. Örneğin:

• Sales, pazarlama kampanyası başına satış geliri sağlamak için pazarlama kampanyası verilerini kullanan bir görünüm istiyor.
• Pazarlama, pazarlama kampanyası verimliliği sağlamak için satış geliri verilerini kullanan bir görünüm istiyor.

Bu nesnelerin her ikisinin de tam model dağıtımına katılan normal görünümler olmasını istemezsiniz, çünkü bu döngüsel bağımlılık veya kırılgan dağıtım sıralamasını riske eder.

Bunun yerine şunları yapın:

• Her bir ambarın çekirdek modelini bağımsız bırakın.
• Her iki şema da kurulduktan sonra daha fazla depo arası görünüm oluşturmak için bir projede dağıtım sonrası script'leri kullanın.

1. Adım: Derleme zamanı doğrulaması için veritabanı referansları ekleme

Model 1'e benzer referansları ayarlayın, ancak her iki proje için de:

• Zava.Sales.Warehouse içinde, [$(MarketingWarehouseName)] aracılığıyla Pazarlama'ya bir referans ekleyin.
• Zava.Marketing.Warehouse içinde, betiklerde kullanılan çapraz ambar görünümlerinin derleme zamanı doğrulamasını istiyorsanız, isteğe bağlı olarak [$(SalesWarehouseName)] aracılığıyla Sales'e bir referans ekleyin.

Dosyalarda .sqlproj şunları ayarlayabilirsiniz:

<SqlCmdVariable Include="SalesWarehouseName">
  <DefaultValue>ZavaSalesWarehouse</DefaultValue>
</SqlCmdVariable>

2. Adım: Çekirdek nesneleri normal proje nesneleri olarak oluşturma

Örnek:

• Sales proje:

  • dbo.CustomerRevenue tablosu
  • dbo.SalesByCampaign görünüm (yalnızca yerel tabloları kullanarak)

• Marketing proje:

  • dbo.Campaigns tablosu
  • dbo.CampaignStats görünüm (yalnızca yerel tabloları kullanarak)

Bu nesneler veri depoları arası çapraz sorgular kullanmaz. Sonraki adımda, çapraz ambar referanslarını tanıtacağız.

3. Adım: Dağıtım sonrası ambarlar arası köprü görünümleri betiği ekleme

Köprü nesnelerini barındırmak için bir ambar seçin; genellikle birleşik çıktıyı en yoğun kullanan domain. Varsayalım ki Sales bu etki alanıdır.

• ProjedeSales: Projeye sağ tıklayın ve ardından Ekle → Dağıtım Sonrası Betiği.
• Betiği PostDeployment_CrossWarehouse.sqlolarak adlandırın.
• Betikte, IF EXISTS / DROP / CREATE desenlerini kullanarak çapraz ambar görünümlerini idem-potent kılmak için oluşturun veya değiştirin.

Sales içinde Marketing ambar nesnelerine referans veren bir betik örneği:

-- PostDeployment_CrossWarehouse.sql

-- Ensure object can be recreated safely
IF OBJECT_ID('dbo.CampaignRevenueBridge', 'V') IS NOT NULL
    DROP VIEW [dbo].[CampaignRevenueBridge];
GO

CREATE VIEW [dbo].[CampaignRevenueBridge] AS
SELECT
    c.CampaignId,
    c.CampaignName,
    m.Channel,
    SUM(s.TotalRevenue) AS Revenue
FROM [$(MarketingWarehouseName)].[dbo].[Campaigns] AS c
JOIN [$(MarketingWarehouseName)].[dbo].[CampaignEngagement] AS m
    ON c.CampaignId = m.CampaignId
JOIN dbo.SalesByCampaign AS s
    ON s.CampaignId = c.CampaignId
GROUP BY
    c.CampaignId,
    c.CampaignName,
    m.Channel;
GO

Burada:

• Çekirdek Sales ve Marketing ambar projeleri bağımsız kalır ve tek başına dağıtılabilir.
• Köprü görünümü, dağıtım sonrası betiği aracılığıyla şema dağıtımından sonra oluşturulur.
• Dağıtım birden çok kez çalıştırılırsa, betik güvenli bir şekilde düşüp görünümü yeniden oluşturur.

4. Adım: (İsteğe bağlı) Kırılgan bağımlılıkları korumak için dağıtım öncesi betikleri kullanma

Daha gelişmiş senaryolarda şunları yapabilirsiniz:

• Şema değişikliklerini engelleyebilecek depolar arası görünümleri (örneğin, sütunları yeniden adlandırıyorsanız) kaldırmak veya devre dışı bırakmak için bir dağıtım öncesi betiği kullanın.
• DacFx'in şema farkını uygulamasına izin verin.
• Ambarlar arası görünümleri yeniden oluşturmak veya güncelleştirmek için dağıtım sonrası betiğini kullanın.

Önemli

Dağıtım öncesi ve sonrası betikler dağıtım planının bir parçası olarak çalışır ve şunlar olmalıdır:

• İdempotent, yani birden çok kez çalıştırılması güvenlidir.
• DacFx tarafından üretilen son şemayla uyumludur.
• İlkenizle çakışan yıkıcı değişikliklerden kurtulun BlockOnPossibleDataLoss .

5. Adım: Betikle yönetilen bağımlılıklar için yayımlama sırası

Zava Analytics için yaygın bir desen:

• Temel projeleri yayımlama:
  • Zava.Marketing.Warehouse (çekirdek şema)
  • Zava.Sales.Warehouse (çekirdek şema + dağıtım sonrası ambarlar arası betik)
• Satış dağıtım sonrası betiğinin, kendi şeması ve başvurulan Marketing şema dağıtıldıktan sonra köprü görünümlerini oluşturmasına izin verin.

İkiden fazla ambar eklerseniz, bu düzeni katmanlar halinde yineleyin. Normal proje nesneleri aracılığıyla hiçbir zaman döngüsel bağımlılıklar oluşturmayın.

Öğrenmeye devam et

• Doku Veri Ambarı ve Doku git tümleştirme belgeleriyle kaynak denetiminde bu desenleri kaynak denetimi ve CI/CD kılavuzuyla birleştirin.
• Zava Analytics senaryosunu Geliştirme/Test/Üretim ortamlarını içerecek şekilde genişletin, birden fazla ambar üzerinde yayımlama sırasını düzenlemek amacıyla dağıtım işlem hatlarını veya harici CI/CD'yi kullanarak.

İlgili içerik

• Geliştirme ve dağıtım iş akışları