根据您的意见,这听起来像是在您的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