具有事务性自由格式字段的DW无事实事实表

Question

我正在从事务表重构Factless Fact表。有明显的共享目标，如组织，状态，服务，ServiceAction，发送日期等。但是，我正在尝试解决2个问题：

1. 在“交易”表上，有“电话”，“电子邮件”，“chkbxRequestReceipt”等值的“自由格式输入”字段。它们都直接与TransactionKey相关。如果我将这些字段从事实表中拉出到它们自己的暗淡中，它会创建一个1-1暗淡的事实关系，这似乎是不正确的。

2. ServiceAction dim在事实表上是1个字段，但随后分为3个不同的昏暗表。这样做是因为服务几乎没有共同的领域。每个ServiceAction都有1个Transaction。因此，3个服务表中的行总和=“事务表”的总行数。

有人能就这种模型的最佳方式提出建议吗？

Answer 1

1. 您可以将电话，电子邮件，chkbxRequestReceipt视为Degenerate Dimension（或多个退化维度）。简并维度是没有维度表的维度。当事实表具有事务级别粒度时，您具有退化维度。

2. 关于ServiceAction的三个表格。我的建议是将它们放在同一个维度表中，但我知道你会有一个包含很多NULL的表。如果您只是手动编写报表，则三个表不是问题，但如果您使用利用维模型自动生成SQL代码的工具，那么您可能需要一个维度表。

您甚至可以认为在事实表上有三个不同的维度共享相同的列，这将起作用，但如果业务用户可以创建自己的报告，则可能会有点混乱。无论如何，在这种情况下，您还需要创建第四维AllSerivceAction，以防您需要创建要显示所有来电的报告以及有关ServiceAction的信息

Answer 2

1) Not every data item necessarily belongs in a dimensional model. Dimensions are supposed to be the things you would analyse your measures by. Are your users going to look at any of your measures by phone number, email address, or whether a receipt was requested? If not, these things quite likely don't belong in your dimensional model. They might belong in a normalized warehouse layer or a reporting database, if you also have those.

If someone insists that these must be available within the dimensional model (and their reasoning is sound - say, they do analysis using more obvious dimensions first, and occasionally they then need to look at one of these data items to take action on something odd they've found):

• First of all check whether these should be attributes on existing dimensions. Maybe email address and phone belong to a dimension like Org, or perhaps a Customer or Person dimension you haven't mentioned. If they belong together conceptually but don't fit with an existing dimension in your model, it's worth thinking about whether there's a dimension you should be adding. You've mentioned these are free text, so you might well need to manage the data quality as part of your ETL process if you go this way.
• If they don't make sense on another dimension, or if you have any free text fields with things like comments/notes, then Ralph Kimball's method of dealing with free text fields is to shove them in a dimension so that people can add them in when they need to.

2) It's honestly difficult to judge whether this is correct from the information given. Without knowing more about what a Service is, what a ServiceAction is, what fields exist in your ServiceAction dimension, etc. I wouldn't want to guess at a suitable design for this. I'll happily revisit this if more information is added.