主鍵和約束條件

Question

在我從OLTP數據庫構建的全新數據倉庫中，我刪除了所有IDENTITY列並將它們更改爲INT列。

什麼是關於最佳實踐以下特別是因爲倉庫規格化：

1. 主鍵
   - >這個現在可能是一個組合鍵，因爲好幾桌走到了一起
   - >我需要遵循OLTP的關鍵結構？
   
   
2. 約束
   - >有一些約束（NOT NULL）與比特列的默認值（0）
   

Answer 1

對於主鍵，可以考慮使用替代的或替代的密鑰;您需要迎合緩慢變化的尺寸，例如如果您在過去5年中對每位已婚/未婚銷售人員的平均銷售情況進行了報告，則您需要註冊一個事實，即有人未婚2年，然後結婚3年。這意味着您的數據倉庫將對同一個人有兩個維度錶行。以下OLTP結構將是困難的:)

約束不是一個問題;數據倉庫針對讀取進行了大量優化（假設您將其作爲批處理進行填充），並且約束條件在讀取操作中並不是真正的因素。您通常可以繞過DW填充作業的任何約束問題，並在必要時處理報告工具中的空值等。確保默認值符合您的概念數據模型並且不會在DW客戶端工具中引入問題更重要。

Answer 2

我要說約2： bit列 - >工作的布爾列 - >只有1/0（真/假）允許 - >約束OK

Answer 3

對於尺寸表：

• 保留代理自動增量（身份）PK，日期維度除外（見下文）。
• 確保您有一個備用的「自然鍵」以允許緩慢更改尺寸（類型2）。
• 尺寸表中不允許有空值，用冗長的「n/a，未輸入，未知值」替換它們。
• 如果可能，請更改布爾標誌（1/0）以詳細說明「是，否」它報告/業務用戶友好。
• 擺脫計算的字段並將其替換爲值，或者至少保留計算的字段 - 取決於數據庫。
• 如果可以的話，實施星型模式，交換空間以獲得速度。只有在必須的情況下才會有雪花。
• 檢查您的查詢，如果WHERE子句中有函數，則向維度表中添加一列並預先計算值。
• 這是很容易的分區日期維度，如果PK的樣子20090619.
• 擺脫的檢查約束和默認值，將其移至符合ETL過程的階段。檢查和默認設置會減慢加載速度，一旦你完成加載，它們就不起作用。

對於事實表：

• 請考慮一個替代的自動增量（標識）PK，以便輕鬆分區，如果使用複合PK，你可以做一個組合唯一的非聚集代替。

• 在安全的地方爲您的外鍵準備腳本，在加載事實表之前放下鍵是爲了加快加載速度。有些人使用外鍵「僅邏輯」運行DW，他們在加載後使用「查找孤兒」查詢。

ETL

• 通過各個階段的設計你的ECCD（ETL）過程：提取物，潔淨，符合，交付。
• 如果可能的話，爲了審覈和調試目的，在每個階段後保留中間結果（文件）。
• 記錄ETL，如果使用腳本使用版本控制，以便可以將腳本版本與歸檔（中間）文件相匹配。
• 有一個數據血統圖，Excel總比沒有好。保留版本。