事实表中是否允许使用文本字段？答案

【问题标题】：Are textual fields ever allowed in fact tables?事实表中是否允许使用文本字段？
【发布时间】：2010-11-05 23:52:09
【问题描述】：

在任何情况下，我可以在事实表中使用文本字段（例如描述）？

我目前有一个会议事件的事实表（粒度：每次会议的行），其中包含日期、客户、位置等多个维度。我需要将会议主题放在事实表中。这可以吗，即使它不是衡量标准（我还没有看到任何这样的例子）。无法将其移动到单独的维度，因为它的大小（行数）始终与事实相同。

过去的经验有什么想法或建议？

谢谢

【问题讨论】：

我对数据仓库领域一窍不通，但我参加过一些关于它的讨论。在这种情况下，将您的主题移动到“垃圾维度”不是正常惯例吗？
我确实查看了垃圾维度，它看起来确实是一个解决方案，但以下内容让我非常震惊：“如果垃圾维度中的行数接近或超过事实上的行数表，设计应明确重新评估。”。在我的示例中就是这种情况。 ralphkimball.com/html/designtipsPDF/DesignTips2003/…

标签： data-warehouse multidimensional-array fact

【解决方案1】：

它可以，以“退化维度”的形式：一个如此微不足道的维度，以至于没有必要为它创建一个表。一个常见的例子是发票号码：它们不是度量标准，但因为它们是如此独特，所以对具有 128 位 CHAR(16) 字段的 Invoices 表使用 32 位 FK 是一种错误的经济方式，其中与事实表一样多的记录。应谨慎执行此操作，因为它们会使事实表行更宽。

如果您有多个退化维度，垃圾维度通常是更好的选择。当然，如果您可以合理地将文本附加到某个维度，那就更好了。

【讨论】：

【解决方案2】：

您所描述的内容听起来像是从其他维度而不是事实表派生的维度。我已经做过很多次了，我有一个主键结构，一个外键组合和一个字符串列来表示一个名称。以产品定义为例。运输地点（与各种查找相关）作为另一个输入。

考虑以下示例：地点：劳德代尔堡，西棕榈滩，迈阿密

每个地点可能有多个送货地点。运输地点具有各种属性，如包装系统、传送带系统、产品重量范围、取件类型。所有这些都在查找表中。

所以，我有一个名为 ShippingLocation 的表，其中包含以下列
- ShippingLocationId(PK)
- PackagingSystemId (FK)
- ConveyorBeltTypeId (FK)
- ProductWeightRangeId (FK)
- ShippingLocationName VarChar (200)

在我看来，发货地点的名称与定义发货地点及其属性的位置相同，这似乎很合乎逻辑。我在这里看到的唯一可能的标准化是我可以把它带到一个一对一的表中。 IMO，这是一个无用的规范化。

【讨论】：

不确定。每天有 100 多个新会议，每个会议都有一个主题。如果我将会议放到一个维度中，我会让我的事实表中的每一行（它可能是一个无事实的事实表）一对一地映射到维度中的一行。这肯定不对？？？
运输地点示例绝对是一个维度，因为它是我要分组的东西，而不是事件或交易。然而，会议是一个事件。它比我要分组的内容更详细。