0

我是多维数据仓库的新手，我的工作场所负责开发用于报告目的的数据仓库解决方案，所以这可能是一个愚蠢的问题，但在这里......

我的事实表中的每条记录都有 FK 列，这些列链接到它们各自的维度表（例如 dimCustomer、dimGeography、dimProduct）。

在 ETL 过程中加载数据仓库时，我首先加载包含详细信息的维度表，然后加载事实表并进行查找转换以找到要放入事实表的 FK 值。这样做时，事实表中的每一行似乎都有相同值的 FK（例如，row1 在每列中的 FK 为 1，row2 的值为 2……等等）

我只是想知道这是否是典型的，或者我是否需要重新考虑仓库和 ETL 流程的设计。

任何建议将不胜感激。

谢谢

4

1 回答 1

2

根据您的评论，听起来您的 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对这些表执行操作来创建维度。

加载完所有维度后，您可以通过基于自然键（已保存在维度中）对每个维度进行查找来加载事实，然后将该键分配给事实行。

有关使用 DW 星型模式的 ETL 的更详细指南，我强烈推荐 Ralph Kimball 的书The Data Warehouse ETL Toolkit。

于 2012-07-24T12:56:39.190 回答