事实表中是否允许文本字段？
在某些情况下，我可以在事实表中拥有文本字段（例如描述）吗？
我目前有一个会议事件事实表（粒度：每次会议的行），具有多个维度，例如日期、客户、位置等。我需要将会议主题放入事实表中。 即使这不是一种措施，这也可以吗（我还没有看到任何这样的例子）。 无法将其移动到单独的维度，因为它始终与事实具有相同的大小（行数）。
根据过去的经验有什么想法或建议吗？
谢谢
Are there any cases where I can have a textual field such as a description in a fact table?
I currently have a fact table of meeting events (grain: row per meeting) with a number of dimensions such as date, client, location etc. I need to put the meeting subject in the fact table. Is this ok even though it is not a measure (I have not seen any examples of this). Can't move it to a separate dimension as it will always be the same size (no of rows) as the fact.
Any ideas or advice from past experience?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
它可以以“退化维度”的形式存在：一个维度如此微不足道，以至于无需为其创建表。 一个常见的例子是发票编号：它们不是指标，但因为它们非常独特，所以对具有 128 位 CHAR(16) 字段的发票表使用 32 位 FK 是一种错误的经济做法，与事实表一样多的记录。 应谨慎执行此操作，因为它们会使事实表行变宽。
如果您有多个退化维度，那么垃圾维度通常是更好的选择。 当然，如果有一个维度可以合理地附加文本，那就更好了。
It can, in the form of a "degenerate dimension:" a dimension so insignificant that there's no need to create a table for it. A common example would be invoice numbers: they're not metrics, but because they're so unique it'd be a false economy to have 32-bit FK to an Invoices table with a 128-bit CHAR(16) field, with as many records as your fact table. This should be done cautiously, as they make fact table rows wider.
Junk dimensions are usually a better option, if you have more than a couple degenerate dimensions. Of course, if there's a dimension to which you could reasonably attach the text instead, that's better still.
您所描述的内容听起来像是从其他维度派生的维度，而不是事实表。 我已经这样做过很多次了，我有一个主键、外键组合和一个表示名称的字符串列的结构。 我想到了产品定义作为一个例子。 运输位置（及其各种查找绑定）是另一个。
考虑以下示例：
地点：劳德代尔堡、西棕榈滩、迈阿密
每个地点可能有多个运送地点。 运输地点具有多种属性，如包装系统、传送带系统、产品重量范围、拾取类型。 所有这些都在查找表中。
因此，我有一个名为 ShippingLocation 的表，其中包含以下列
- ShippingLocationId(PK)
- 包装系统 ID (FK)
- 传送带类型 ID (FK)
- 产品重量范围 ID (FK)
- ShippingLocationName VarChar (200)
对我来说，运送位置的名称应该与定义运送位置及其属性的位置相同，这似乎非常合乎逻辑。 我在这里看到的唯一可能的标准化是我可以将其带到一对一的表中。 IMO，这是一种无用的标准化。
What you are describing sounds like a dimension derived from other dimensions rather than a fact table. I have done this many times where I have a structure of a primary key, a combination of foreign keys and a string column to denote a name. Product Definition comes to mind as an example. Shipping location (with its various lookups tied in) comes in as another.
Consider the following example:
Locations: Fort Lauderdale, West Palm Beach, Miami
Each location may have multiple shipping locations. A shipping location has various attributes as in Packing system, Converyor belt system, Product Weight Range, Types of Pickups. All of these are in lookup tables.
So, I have a table called ShippingLocation with the following columns
- ShippingLocationId(PK)
- PackagingSystemId (FK)
- ConveyorBeltTypeId (FK)
- ProductWeightRangeId (FK)
- ShippingLocationName VarChar (200)
It seems very logical to me that the name of the shipping location would be in the same place where the shipping location is defined and it's attributes are defined. The only possible normalization I see here is that I can take it to a 1-to-1 table. IMO, that is a useless normalization.