開發和部署跨倉庫依賴關係

在本文中，您將學習如何在 Visual Studio Code 中使用 SQL 資料庫專案來建模與部署跨倉庫相依關係。你從兩個現有的倉庫專案出發，並利用資料庫參考，必要時使用部署前和部署後的腳本，設定它們之間的單向相依關係。

本文建立在 Visual Studio Code 中開發倉庫專案的概念基礎上，假設你已經熟悉建立並發佈單一倉庫專案。

先決條件

開始之前，請確定您：

在同一工作區建立 兩個布料倉庫 。
- 若要建立新的範例倉儲，請參閱在 Microsoft Fabric 中建立範例倉儲。
在 Visual Studio Code 中為每個倉庫建立或擷取資料庫專案。
- 若要為現有倉庫或新倉庫建立資料庫專案，請參見 Visual Studio Code 中的「開發倉庫專案」。
在您的工作站上安裝 Visual Studio Code 。
安裝 .NET SDK 以建置和發佈資料庫專案。
安裝兩個 Visual Studio Code 延伸模組：SQL 資料庫專案和 SQL Server （mssql）。
- 您可以搜尋「SQL 資料庫專案」或「SQL Server （mssql）」，直接從 Visual Studio Code 市集中安裝所需的延伸模組。
倉庫專案會驗證、建置，並可發佈於 Visual Studio Code。

備註

本文重點介紹 Visual Studio Code 中的 倉庫專案 ，以及如何將它們作為一般程式碼專案在 Git 中版本化。 Fabric Git 整合與工作區及倉庫項目分別在Fabric Data Warehouse 的原始碼控管及 Git 整合文件中說明。文章假設您的 Fabric 工作區是部署目標，而 T-SQL 架構存在於一個或多個由您在 Git 中進行版本控制的 Visual Studio Code 專案中。

本文 不涵蓋Lakehouse 的 SQL 分析端點的跨倉庫開發。湖屋資料表和 SQL 端點物件在原始碼控制中不像倉庫專案那樣被追蹤。使用 Warehouse 項目搭配資料庫專案，完整整合 git 與部署，支援 Fabric 原生體驗與客戶端工具。

情境：Zava Analytics 跨域倉庫

Zava Analytics 使用兩個商業領域：

銷售 ——客戶訂單、營收及管線指標。
行銷 ——活動、通路與互動指標。

每個領域具備：

同一工作區的 布料倉庫 ：
- ZavaSalesWarehouse
- ZavaMarketingWarehouse
Visual Studio Code 中的 資料庫專案 ：
- Zava.Sales.Warehouse
- Zava.Marketing.Warehouse

為了建立端對端的 ELT 與報告，每個網域都需要 唯讀檢視 以存取另一個網域的資料：

Sales 需要顧客參與行銷活動。
Marketing 需要根據活動來獲得銷售表現數據。

您需要：

透過資料庫參考建立 單向跨倉庫相依 關係。
避免循環依賴。
在倉庫內的物件相互依賴的情況下，使用 部署前與部署後的腳本 。

確保倉庫間的相依性為單向

對於每對倉庫，選擇一個 邏輯相依方向：

範例：

Sales 依賴 Marketing 的參與度數據。
Marketing 不依賴於 Sales 部署時所需的任何物件。

在實踐中：

Zava.Sales.Warehouse 對 Zava.Marketing.Warehouse 有 資料庫參考。

倉庫中的 Sales T-SQL 可以使用三部分名稱，例如：

SELECT * FROM ZavaMarketingWarehouse.Marketing.CampaignEngagement

Zava.Marketing.Warehouse 不會參考Sales會在部署時強制依賴週期的物件。

小提示

對每對倉庫，繪製一個簡單的箭頭圖（Sales → Marketing）。如果你發現 同一類型的物件箭頭同時指向兩個方向，可能需要重構或將一些邏輯整合到部署前後的腳本中。

避免循環相依

當倉庫 A 和倉庫 B 彼此依賴，導致引擎無法在單一部署中解決時，就會出現循環依賴。

問題範例（請勿這麼做）：

ZavaSalesWarehouse.dbo.CustomerRollup 視圖

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 視圖：

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;

在這個反模式中：

CustomerRollup在銷售方面，則取決於CustomerEngagement行銷。
CampaignAttribution 行銷部門依賴CustomerRollup銷售部門。

這種反模式形成了一個循環：銷售視角→行銷觀點→銷售視角再次出現。

指導方針：

不要把 倉庫間的相互依賴 建模成一般的結構層級物件。如果你真的需要這種邏輯，將依賴的一方移到：

部署後的腳本，或
一個在查詢時將兩個倉庫連接起來的下游語意模型或報告。

使用部署前置與部署後的腳本來處理部署敏感的跨倉邏輯

由於倉庫部署是 完整的結構差異 操作（而非部分每個物件的部署），因此對跨倉庫項目請謹慎處理：

如果倉庫 A 和倉庫 B 都需要彼此依賴的物件：

將 核心資料表和核心檢視 保留在每個倉庫專案中。
將創建循環依賴的 橋接視圖或實用物件 移動到同一個項目的 部署前置或後置腳本 中。
確保這些腳本是冪等且可安全重複執行的。

範例模式：

部署前腳本：暫時移除跨倉庫視圖，再套用會導致其損壞的結構修改。
部署後腳本：兩個倉庫部署完成後，重新建立或更新跨倉庫視圖。

模式一：直接透過資料庫引用進行跨倉庫參照

在此模式中，你直接在資料庫專案中使用 Database References 來建模單向依賴關係。

步驟一：從兩個現有的倉庫專案開始

你應該已經有：

Zava.Sales.Warehouse →部署至 ZavaSalesWarehouse
Zava.Marketing.Warehouse →部署至 ZavaMarketingWarehouse

每個專案都是透過 Visual Studio Code 中「開發倉庫專案」的步驟建立或擷取完成的。

步驟 2：從銷售到行銷新增資料庫參考

在 Visual Studio Code 中，開啟 資料庫專案 檢視。
右鍵點擊專案 Zava.Sales.Warehouse 。
選擇 新增資料庫參考資料...。
請選擇以下之一：
- 目前工作區中的資料庫專案 （以此方式參考的資料庫專案也必須在 Visual Studio Code 中開啟），或
- 資料層應用程式 (.dacpac)（假設你已經建置了 .dacpac 並且倉庫已經建置了 Marketing）。
設定參考選項：
- 參考類型： 同一台伺服器，不同的資料庫。
- 資料庫名稱或變數： 例如，使用 SQLCMD 變數 [$(MarketingWarehouseName)]。
儲存並重建銷售專案。

在檔案中 .sqlproj ，你應該會看到類似這樣的條目：

<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>

小提示

使用 SQLCMD 變數作為 遠端倉庫名稱 ，可以讓你在所有環境（例如 Dev/Test/Prod）重複使用同一個專案，雖然倉庫名稱可能不同。

步驟 3：在銷售中建立跨倉庫視圖

在Sales專案中，新增一個從Marketing倉庫讀取的視圖：

-- 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;

重點︰

這個三部分名稱 [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] 與 Fabric SQL 編輯器中用於跨倉儲查詢的 T-SQL 模式相符。
DacFx 透過 資料庫參考來解析外部資料庫。

建立專案以確保 沒有SQL71501未解決的參考錯誤 。

步驟四：先發布行銷倉庫，接著是銷售

為避免部署問題：

建置與發佈Zava.Marketing.Warehouse 先：
- 右鍵點擊專案→ 建構。
- 右鍵點擊專案→ 發佈 →選擇 ZavaMarketingWarehouse。
部署成功後 Marketing ，請 建置並發佈Zava.Sales.Warehouse：
- 右鍵點擊專案→ 建構。
- 右鍵點擊專案→ 發佈 →選擇 ZavaSalesWarehouse。

最終的部署流程如下：

Zava.Marketing.Warehouse （無外部依賴）→ Zava.Sales.Warehouse （依賴於 Marketing）

現在，任何 T-SQL 查詢在 ZavaSalesWarehouse 中都可以使用 dbo.CustomerEngagementFact 視圖，該視圖透過跨倉庫 T-SQL 從 Marketing 倉庫內部讀取。

模式二：透過部署前後的腳本管理跨倉儲相依性

在某些 Zava Analytics 情境中， 兩個領域 可能需要相互依賴的聚合物件。例如：

銷售部門希望有一個利用行銷活動數據來提供每個行銷活動銷售收入的視角。
行銷部門希望有一個利用銷售收入數據來提供行銷活動效率的視角。

你不希望這兩個物件都只是參與完整模型部署的常規視圖，因為那會產生週期性相依或部署順序脆弱的風險。

相反地，你：

保持每個倉庫的核心模型獨立。
在同一專案中使用 部署後腳本，在兩個架構都到位後，創建更多跨倉庫視圖。

步驟 1：新增資料庫參考以進行編譯時驗證

設定類似模式1的參考，但適用於兩個專案：

在 Zava.Sales.Warehouse中，加入透過 [$(MarketingWarehouseName)] 的 Marketing 參考。
在 Zava.Marketing.Warehouse中，若你想在編譯時驗證腳本中使用的跨倉庫視圖，可選擇性地加入對銷售 [$(SalesWarehouseName)] 的參考。

在檔案 .sqlproj 中，你可以設定：

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

步驟二：將核心物件建立為一般專案物件

範例：

Sales 專案：
- dbo.CustomerRevenue 表
- dbo.SalesByCampaign 檢視（僅使用本地資料表）
Marketing 專案：
- dbo.Campaigns 表
- dbo.CampaignStats 檢視（僅使用本地資料表）

這些物件不使用跨倉庫查詢。下一步，我們會引入跨倉庫引用。

步驟 3：新增部署後腳本以支援跨倉庫橋接視圖

選擇一個倉庫來存放橋接物件；通常該倉庫是主要使用合併輸出結果的系統或域。假設 Sales 是該定義域。

在專案中Sales：右鍵點擊專案，然後新增→部署後腳本。
說出劇本 PostDeployment_CrossWarehouse.sql名稱。
在腳本中，使用IF EXISTS / DROP / CREATE模式來創建或修改跨倉庫視圖，以確保其為冪等性。

範例腳本在Sales中將參考Marketing倉庫物件：

-- 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

此處：

核心 Sales 與 Marketing 倉儲專案保持獨立且可獨立部署。
橋接視圖是在結構部署後透過部署後的腳本建立的。
若部署執行多次，則具有冪等性，因為腳本可以安全地丟棄並重建視圖。

步驟 4：（可選）使用部署前的腳本來保護脆弱的依賴項

在更進階的情境下，你可能會：

使用 部署前腳本 來刪除或停用可能阻擋結構變更的跨倉庫視圖（例如，如果你要重新命名欄位）。
讓 DacFx 套用結構差異。
使用 部署後腳本 來重建或更新跨倉庫視圖。

這很重要

部署前與部署後腳本作為部署計畫的一部分執行，必須具備：

冪等，意思是可以安全地多次運行。
與 DacFx 最終產生的架構相容。
避免與您的 BlockOnPossibleDataLoss 政策相衝突的破壞性變更。

步驟 5：發佈由腳本管理的相依項目順序

Zava Analytics 的一個常見模式：

發佈基礎專案：
- Zava.Marketing.Warehouse （核心架構）
- Zava.Sales.Warehouse （核心架構 + 跨倉庫部署後腳本）
讓 Sales 的部署後腳本在部署完自己的結構和相關的架構後，建立橋接視圖。

如果你引入超過兩個倉庫，就分層重複這個模式。切勿透過普通專案物件建立循環相依關係。

繼續學習

將這些模式與 原始檔控制及 CI/CD 指南 相結合，和 Fabric Data Warehouse 的原始檔控制及 Fabric git 整合文件。
將 Zava Analytics 情境擴展至開發 /測試/生產 環境，利用部署流程或外部 CI/CD 協調多個倉庫間的發佈訂單。

開發和部署工作流程

意見反應

此頁面對您有幫助嗎？

Last updated on 2025-12-09