SQL Server 數據倉庫儲存過程位置

我們正在建構一個 Kimball 數據倉庫。我們有一個暫存數據庫和最終數據倉庫。

我們有一個創建表 CustomerTransaction 的儲存過程。放置儲存過程的最佳位置在哪裡？在暫存數據庫或數據倉庫中？或者每個位置的正面/負面是什麼？我剛開始創建數據倉庫並嘗試學習。

create procedure dbo.FactCustomerTransactionImport  -- should this be in StagingDB or datawarehouse DB?
as

insert into DWFinal.dbo.FactCustomerTransaction
(
    CustomerId, 
    Quantity, 
    Price, 
    Amount
)
select 
    CustomerId, 
    Quantity, 
    Price, 
    Quantity * Price as Amount
from StagingDB.dbo.CustomerTransaction

這是一個品味問題。我認為完全分解的主要原因是為了安全，其次是為了備份。

Staging我認為 ETL 活動，包括載入最終的星型模式表，是該層的一個方面。這就是我的倉庫中所有“繁重的工作”發生的地方。

以下是我通常如何分解數據倉庫。這些應該是不同的物理數據庫，如果數據量需要，可以是單獨的虛擬機或物理機。

• 每個重要數據源（CRM、OLTP 數據庫、電話系統等）都有一個單獨的數據庫。在這裡，我儲存了來自源系統的數據的直接副本，並進行了最少的修改。例如，我將記錄DateCaptured和DateModified為每條記錄，但不執行數據值或類型的清理。這個想法是盡可能快地獲取數據，以盡量減少源系統上的負載。

  • 原則上，可以隨意清除這些數據庫並從源系統重新填充，而無需更改倉庫的其餘部分。
  • 為每個來源使用單獨的數據庫可以讓使用者（即服務帳戶）擁有有限的訪問權限。我的Service_SalesforceReader使用者已經在數據庫中讀取和寫入權限Salesforce，而其他任何地方都沒有。
  • 寫入這些數據庫通常是通過專用的 ETL 應用程序進行的，並有一些 SQL 過程支持它們。

• 中間步驟的Staging數據庫；“ETL”中的“T”。這包括用於數據清理的查找表、用於分配合成鍵的表和用於 ETL 過程的日誌表。

  • 這裡的數據大部分是靜態的，可以從源控制（例如，國家程式碼）或源數據的轉換中重新創建，這些數據可以從那些系統中重新創建，儘管可能會創建不同的合成密鑰。只有倉庫團隊中的人員需要訪問此處。
  • 這個數據庫有 90% 的 SQL 過程。他們將數據格式化並轉換為星型模式佈局。將 ETL 邏輯保留在 Staging 中有一個客觀原因：安全性。只有倉庫管理員需要訪問這些程序，而許多人可能需要訪問倉庫層。

• 一個Warehouse數據庫，具有整潔的事實表和維度表。該層可能具有幫助特定消費者的視圖。例如，如果您有一個不能很好地處理連接的視覺化工具，那麼每個星可能都有一個視圖（可能是實體化的），所有維度都加入了。

  • 在我目前的倉庫中，我在這一層中擁有的唯一儲存過程是用於日誌記錄的，我不相信它們實際上會被使用。

在實踐中，您可能需要授予某些高級使用者對特定源數據庫的訪問權限，如果他們需要的數據沒有被納入星型模式。在這種情況下，您可能還需要授予對將Staging它們連結在一起的合成鍵表的訪問權限，以便它們可以從（例如）CustomerSK整數遍歷到 SalesforceAccountID字元串。這樣做會使您很難在不破壞人員流程的情況下更改任何內容，因此這應該是最後的手段。

引用自：https://dba.stackexchange.com/questions/220766