慢慢改變事實表？

Question

背景） 我已經通過建立一個事實表我們的庫存數據的歷程，將在理論作爲我們的倉庫夜間快照。所記錄的是諸如數量，重量，位置，狀態等信息。數據非常精細，在許多情況下與單個實體沒有特別的關聯（我們的源數據庫將庫存數據記錄爲具有三個主鍵：牌照又名托盤，產品和包裝類型 - 所以它基本上有3個業務密鑰，沒有代理鍵）。

的目標是能有我們的倉庫管理系統的數據的100％準確的娛樂，這是可見的，任何一個歷史上的今天。因此，我可以查看8月4日1234號產品XYZ有多少托盤。

問題1） 現在，我已經建立了這個事實表結構看起來像一個漸變維度，類型2.這是錯的？我一直在積累快照事實表，並開始質疑我的設計。這種情況下的最佳做法是什麼？

問題2） 如果我的設計沒問題，我該如何配置Analysis Services以便識別FACT表中的DateStart和DateEnd列？我發現了一些關於如何爲維度配置的信息，但它似乎不適用於事實表。

僅供參考 - 我的事實表的結構（約列加註釋）：

CREATE TABLE [dbo].[FactInventory](  
[id] [int] IDENTITY(1,1) NOT NULL, (fact table only surrogate key) 
[DateStart] [datetime] NULL, (record begin date) 
[DateEnd] [datetime] NULL,  (record end date) 
[CreateDate] [datetime] NULL, (create date of the inventory record in src db) 
[CreateDateId] [int] NULL,  (create date dimension key) 
[CreateTimeId] [int] NULL,  (create time dimension key) 
[LicensePlateId] [int] NULL,  (pallet id dimension key) 
[SerialNumberId] [int] NULL,  (serial number id dimension key) 
[PackagedId] [int] NULL,   (packaging type id dimension key) 
[LotId] [int] NULL,   (inventory lot id dimension key) 
[MaterialId] [int] NULL,   (product id dimension key) 
[ProjectId] [int] NULL,   (customer project id dimension key) 
[OwnerId] [int] NULL,  (customer id dimension key) 
[WarehouseId] [int] NULL,  (warehouse id dimension key) 
[LocationId] [int] NULL,  (location id dimension key) 
[LPStatusId] [int] NULL,  (licenseplate status id dimension key) 
[LPTypeId] [int] NULL, (licenseplate type id dimension key) 
[LPLookupCode] [nvarchar](128) NULL, (licenseplate non-system name) 
[PackagedAmount] [money] NULL, (inventory amount - measure) 
[netWeight] [money] NULL, (inventory netWeight - measure) 
[grossWeight] [money] NULL, (inventory grossWeight - measure) 
[Archived] [bit] NULL, (inventory archived yes/no - dimension) 
[SCDChangeReason] [nvarchar](128) NULL (auditing data for changes) 

Answer 1

通常，在快照事實表中，您沒有更改。

您通常具有用於測量的粒度，而不是DateStart/DateEnd的日期/時間維度。同樣，你沒有任何SCD信息。事實快照被採用並且日期和時間維度被附加到這些事實。如果這些事實每個月重複一次，那就這樣吧。

處理確定在給定時間哪些事實是有效的處理比您真正想要DW或ETL處理更多的處理 - 這種設計（生效日期等）更有效地用於實時OLTP類型系統中完整的歷史保存在現場系統中。 DW的要點是優化報告，而不是空間，因此有一個直接的快照日期/時間維度，它允許您在沒有大量日期算術或比較的情況下輕鬆地對數據進行索引和潛在分區。

就您的尺寸模型而言，要小心不要屈服於太多的尺寸問題。請記住，維度不必與現實世界中的實體相對應。應該通過1）查詢需求，2）數據關聯性和變更行爲，3）業務組織來通知維度屬性如何分組到維度表中。您可能需要考慮使用一個或多個垃圾尺寸。

Answer 2

在進一步討論之前，是真的庫存緩慢變化的事實呢？

編輯：那麼，爲什麼不每天只快照每一件產品，因爲這是你想要的。

的問題是，事實表獲得大和你扔什麼東西都往事實表不必要的。理想情況下，事實表將只包含維度和外部關鍵字的外鍵，而僅涉及到事實。但一些你列出列的樣子，他們在尺寸表，而

例如，車牌信息的一個歸屬。狀態，類型和查找代碼。同樣使用netWeight/grossWeight。它們應該可以從產品維度和PackagedAmount中導出。

CREATE TABLE [dbo].[FactInventory](  
[id] [int] IDENTITY(1,1) NOT NULL, (fact table only surrogate key) 
[day] [int] NULL,    (day dimension key, grain of a day) 
[CreateDateId] [int] NULL,  (create date dimension key) 
/* I take these are needed? 
* [CreateTimeId] [int] NULL,  (create time dimension key) 
* [CreateDate] [datetime] NULL, (create date of the inventory record in src db) 
*/ 
[LicensePlateId] [int] NULL,  (pallet id dimension key) 
/* Now THESE dimension columns...possibly slowly changing dimensions? 
[LPStatusId] [int] NULL,    (licenseplate status id dimension key) 
[LPTypeId] [int] NULL,    (licenseplate type id dimension key) 
[LPLookupCode] [nvarchar](128) NULL, (licenseplate non-system name) 
*/ 
[SerialNumberId] [int] NULL,  (serial number id dimension key) 
[PackagedId] [int] NULL,   (packaging type id dimension key) 
[LotId] [int] NULL,    (inventory lot id dimension key) 
[MaterialId] [int] NULL,   (product id dimension key) 
[ProjectId] [int] NULL,   (customer project id dimension key) 
[OwnerId] [int] NULL,   (customer id dimension key) 
[WarehouseId] [int] NULL,  (warehouse id dimension key) 
[LocationId] [int] NULL,   (location id dimension key) 
[PackagedAmount] [money] NULL, (inventory amount - measure) 
[netWeight] [money] NULL,  (inventory netWeight - measure) 
[grossWeight] [money] NULL,  (inventory grossWeight - measure) 
[Archived] [bit] NULL,   (inventory archived yes/no - dimension) 
[SCDChangeReason] [nvarchar](128) NULL (auditing data for changes)