根據您的意見,這聽起來像是在您的ETL過程中錯過了一步。
對於呼叫中心/聯絡中心,我可能會開始了與事實表是這樣的:
CallFactID - unique key just for ETL purposes only
AssociateID - call center associate who initially took the call
ProductID - product that the user is calling about
CallTypeID - General, Complaint, Misc, etc
ClientID - company/individual that is calling
CallDateID - linked to your Date (by day) Dimension
CallTimeOfDayID - bucketed id for call time based on business rules
CallStartTimestamp - ANSI timestamp of start time
CallEndTimestamp - ANSI timestamp of end time
CallDurationTimestamp - INTERVAL data type, or integer in seconds, call duration
你的維度表將被:
AssociateDim
ProductDim
CallTypeDim
ClientDim
DateDim
TimeOfDayDim
你的ETL需要建立尺寸第一。如果您的源系統中有關係模型,那麼通常只需在「查找」表中查找各種事物,例如「產品」表或「關聯」表,並將任何有意義的關係非規範化爲屬性。例如,關係產品表可能看起來像:
PRODUCTS: ProductKey,
ProductName,
ProductTypeKey,
ProductManufacturerKey,
SKU,
UPC
你會進入非規範化一般產品尺寸此通過查找產品類型和製造商,像落得:
PRODUCTDIM: PRODUCTID (DW surrogate key),
ProductKey,
ProductName,
ProductTypeDesc,
ManufacturerDesc,
ManufacturerCountry,
SKU,
UPC
對於只存在於您的交易(通話記錄)表中但基數較低的屬性,可以通過在這些表上執行SELECT DISTINCT
來創建維度。
一旦你加載了所有的維度,你就會根據自然鍵(你已經保存在維度中)對每個維度進行查找來加載事實,然後將該鍵分配給事實行。
有關ETL與DW Star Schemas有關的更詳細指南,我強烈建議Ralph Kimball的書The Data Warehouse ETL Toolkit。
只是爲了補充一點,當我加載倉庫時,我需要先將其加載,然後將其加載新鮮。 – 2012-07-23 17:57:02
需要更多背景。由於您加載的順序可能會導致FK值按照該順序自然下降。在源數據中找到一個實例,其中兩行具有相同的客戶和不同的地理位置,並查看這些模糊的值。如果它們仍然是相同的,那麼你可能裝載不正確。更簡單地說,你的dimGeography表中有多少個'Texas'條目? – 2012-07-23 19:40:34
同意@WilliamToddSalzman。你很可能只是「幸運」。但是,請注意,如果您的維度中的每行都有一行,則該數據值可能不屬於維度 - 例如,如果您有DimTransactionNumber。 – 2012-07-23 22:57:35