数据仓库中的交叉引用事实和维度答案

【问题标题】：Cross reference Facts and Dimensions in Data warehouse数据仓库中的交叉引用事实和维度
【发布时间】：2011-04-29 01:42:18
【问题描述】：

我正在尝试为许可供应商设计一个数据仓库，该供应商在电子商务和其他各种场所销售许可。他们想要跟踪的是销售、产品生命周期和活动。这意味着存在不同的销售类型（例如新购买、促销购买、续订）和许可证的不同事件/状态，例如 - 可以安装、续订、激活、注册许可证。许可证可以多次续订（在不同的日期）。

所以我认为我的维度会非常简单 - 日期、产品、来源、销售类型和事件/状态。我会有两个事实表；一个用于销售，另一个用于事件，它们都具有维度表的外键。我的事实表将是一个累积事实表，其中每个事件都会添加一个新行 - 因此，可以重复许可证。但是，要求声明他们能够交叉引用这两个事实以及 saletype 和 event 维度。例如，如果有人看到产品“A”在美国电子商务商店的“新购买”类型有 100 次销售，那么他们想看看“那些”100 个许可证中有多少也被激活了......然后他们可能会想看看，在激活的人中，有多少人注册了……然后（回到 saletype）有多少人注册了，有多少人“更新了”。而且我不能真正定义层次结构，因为你可以有很多这些组合......

我该怎么做？在我阅读的过程中，我发现似乎没有办法根据许可证本身来关联这两个事实（这是我需要做的）。

另外，我还在想也许我可以有 1 个事实表，并且我可以“技术上”将 saletype 和 eventtype 组合成一个大的 eventtype 维度。因此，事实表中将是一个大的事务事实表，其中将具有事件维度的 eventid 外键。但是，所以现在我有一个事实表，其中包含发生在许可证上的每个事件的一行。许可证是重复的，一个事件可以为一个事件出现多次（在不同的日期）。那么，如果我选择查看某个活动的总数，我如何才能查看其中有多少许可证也适用于不同的活动？

我需要提供所有这些数字作为度量，以便业务用户可以即时查看它们（使用他们想要使用的任何 OLAP 浏览器）

注意：我使用的是 SQL server 分析服务和 SQL server 2008 r2

仅供参考，这就是我现在所拥有的：

DimProducts（PK：ProductID 和其他属性）
DimDate（PK：DateKey 和其他属性）
DimEvent（PK：EventID 和其他属性）
FactLicenses(FK: ProductID; FK: DateKey; FK: EventID, and License Field(varchar))

所以我有一个重复的许可证，每次许可证发生问题（安装、激活、续订、取消、续订（再次））时都会发生一个事件。可能有一个具有相同 eventID 的许可证，但从不在同一个DateKey，表的主键是DateKey + EventID + License

编辑：

所以，我在很多地方读到，在这种情况下的事实表应该是一个累积的事实表，它有多个指向相同（类型）维度（即日期）的列，我应该为每一个创造角色扮演维度。但是，您如何解释许可证可以多次续订以及可以多次安装等事实...？

【问题讨论】：

至少对我来说太复杂了。你能不能让它更短更简单......例如，包括你创建的表结构作为一个例子，以更好地理解你，然后提出一些例子来问你的问题。因为我目前也在做 BI。
缩短它会破坏目的 - 我想我已经展示了我需要详细建模的业务场景（我也已经说明了我的表结构）。
@MR：不，我的意思不是你的场景，你的解释:)
hmm - 哪个部分令人困惑？哪一部分应该解释的更清楚？

标签： ssas data-warehouse business-intelligence

【解决方案1】：

从那以后，我回到了 Ralph Kimball 的书，并找到了一个可以为我解决这个问题的案例研究。我还将销售类型和事件类型合并为一个主要组。因此，考虑到这一点，仍然有两组事情——许可证可能发生一次的事情，以及许可证可能多次发生的事情。许可证曾经可能发生的所有事情现在都存储在累积事实表中。然后将可能多次发生在许可证上的所有内容存储在不同的表中（每个实体或可能发生的事件“类型”的不同表）。

这有效地解决了我的问题，因为在分析服务中，我现在能够建立一种称为“引用”关系的东西，其中关系是“许可证”。因此，与不同表相关的任何维度都可以通过原始累积事实表（具有许可证列）链接。

感谢您的意见，任何尝试回答的人。

【讨论】：

您能告诉我们您在 Kimball 的书中找到了哪些案例研究吗？谢谢。

【解决方案2】：

我认为您的设计已经适应了这种类型的分析，尽管您的情况实际上是由两个查询组成的。

如果您想通过对产品“A”和来源“美国”的 SALES 事实表中的值求和来找出销售数量和价值，则第一种情况是。例如：

SELECT COUNT(*) TOTAL_UNIT_SALES, SUM(FCT_SALES.VALUE) TOTAL_VALUE
FROM   FCT_SALES, DIM_PRODUCTS, DIM_SOURCES
WHERE  FCT_SALES.PRODUCT_FK = DIM_PRODUCTS.PRODUCT_SK
AND    DIM_PRODUCTS.NAME = 'A'
AND    FCT_SALES.SOURCE_FK = DIM_SOURCES.SOURCE_SK
AND    DIM_SOURCES.NAME = 'USA';

第二种方法是对同一组维度外键的 EVENTS 事实表中的记录进行透视或求和，以找出每种类型发生了多少事件。例如：

SELECT SUM(CASE WHEN DIM_SALE_TYPES.NAME = 'NEW' THEN 1 ELSE 0 END) TOTAL_NEW_SALES
,      SUM(CASE WHEN DIM_SALE_TYPES.NAME = 'ACTIVATION' THEN 1 ELSE 0 END) TOTAL_ACTIVATIONS
,      SUM(CASE WHEN DIM_SALE_TYPES.NAME = 'REGISTRATION' THEN 1 ELSE 0 END) TOTAL_REGISTRATIONS
FROM   FCT_EVENTS, DIM_PRODUCTS, DIM_SOURCES, DIM_SALE_TYPES
WHERE  FCT_EVENTS.PRODUCT_FK = DIM_PRODUCTS.PRODUCT_SK
AND    DIM_PRODUCTS.NAME = 'A'
AND    FCT_EVENTS.SOURCE_FK = DIM_SOURCES.SOURCE_SK
AND    DIM_SOURCES.NAME = 'USA'
AND    FCT_EVENTS.SALE_TYPE_FK = DIM_SALE_TYPES.SALE_TYPE_SK;

【讨论】：

但是从 SSAS 的角度来看，我该怎么做呢？我事先不知道他们会要求这样的组合，所以我需要准备好措施，以便当用户浏览多维数据集（通过 excel 或其他方式）时，这些数字是可用的。我不确定我是否可以期望他们编写查询。另一方面，我不确定我能否对所有可能的组合进行计算测量......
我不熟悉 SSAS，但任何支持 OLAP 的 BI 工具都可以从维度模型生成这些类型的查询。我要说的是，分析查询通常在单个事实表上，因此不需要交叉引用它们——即使在它们基于多个事实表的情况下，该工具也应该能够根据约束执行此操作。
它不会完全起作用。因为日期键可以不同。例如 - 在 4 月购买的许可证可以在 5 月安装。所以实际销售日期是 4 月，而活动销售日期是 5 月。因此，如果我加入所有原始维度（来自第一个查询），它仍然缺少许可证。 5 月可能还有其他安装，这些安装与 4 月购买的许可证无关。我不能真正将许可证用作连接（在 SSAS 查询中），因为它不是维度。
您似乎仍在考虑将事实表连接在一起 - 实际上这不会发生。在我看来，两个事实表查询之间唯一共享的维度是 Product 和 Source 维度。其余维度键（包括日期键）与查询的特定目的相关，即美国 4 月份的总销售额或美国 5 月份的总许可证激活量。如果我想“深入”特定销售以查看其事件（激活、注册等），我只需使用共享维度键来查询另一个事实表。
那行不通。仅维度本身是不够的，因为相同的维度可能具有较少的许可证（它的子集）。我可以让许可证本身成为一个退化的维度，但我仍然不清楚如何让它发挥作用....

【解决方案3】：

我强烈建议将许可证添加为单独的维度。它可以与某些唯一标识符相关联，例如许可证号或激活密钥吗？

【讨论】：

是的，它可以——我已经这样做了，但我仍然在努力建立一个事实表和另一个事实表之间的连接，特别是在 sql server 分析服务中......