在任何情况下,我可以在事实表中拥有文本字段,例如描述?
我目前有一个会议事件的事实表(粒度:每次会议的行),其中包含日期、客户、位置等多个维度。我需要将会议主题放在事实表中。这可以吗,即使它不是衡量标准(我还没有看到任何这样的例子)。无法将其移动到单独的维度,因为它的大小(行数)始终与事实相同。
过去的经验有什么想法或建议吗?
谢谢
在任何情况下,我可以在事实表中拥有文本字段,例如描述?
我目前有一个会议事件的事实表(粒度:每次会议的行),其中包含日期、客户、位置等多个维度。我需要将会议主题放在事实表中。这可以吗,即使它不是衡量标准(我还没有看到任何这样的例子)。无法将其移动到单独的维度,因为它的大小(行数)始终与事实相同。
过去的经验有什么想法或建议吗?
谢谢
它可以以“退化维度”的形式出现:一个如此微不足道的维度,以至于无需为其创建表。一个常见的例子是发票号码:它们不是度量标准,但因为它们是如此独特,所以将 32 位 FK 用于具有 128 位 CHAR(16) 字段的 Invoices 表是一种错误的经济,与事实表一样多的记录。这应该谨慎进行,因为它们会使事实表行更宽。
如果您有多个退化维度,垃圾维度通常是更好的选择。当然,如果有一个维度可以合理地附加文本,那就更好了。
您所描述的听起来像是从其他维度而不是事实表派生的维度。我已经做过很多次了,我有一个主键结构,一个外键组合和一个字符串列来表示一个名称。以产品定义为例。运输位置(与其各种查找相关联)作为另一个出现。
考虑以下示例: 地点:劳德代尔堡、西棕榈滩、迈阿密
每个地点可能有多个发货地点。运输地点具有各种属性,如包装系统、传送带系统、产品重量范围、取件类型。所有这些都在查找表中。
所以,我有一个名为 ShippingLocation 的表,其中包含以下列
- ShippingLocationId(PK)
- PackagingSystemId (FK)
- ConveyorBeltTypeId (FK)
- ProductWeightRangeId (FK)
- ShippingLocationName VarChar (200)
在我看来,运输地点的名称与定义运输地点及其属性的位置相同,这似乎很合乎逻辑。我在这里看到的唯一可能的标准化是我可以把它带到一个一对一的表中。IMO,这是一个无用的规范化。