100 个事实的事实表设计指南答案

【问题标题】：Fact table design guidance for 100s of facts100 个事实的事实表设计指南
【发布时间】：2016-04-28 05:37:11
【问题描述】：

我正在尝试为医疗保健应用程序创建一个数据集市。数据集市中的事实基本上是与心脏相关的测量和发现，我们有 100 多个。从 1000 起，每种考试类型可以达到 20000 人。

我想知道我对事实表的设计选择是什么：

谷物：每种检查类型每位患者 1 行。

我能想到的一些选择-

1) 包含 1000 列或更多列的宽大事实表。

2) 基于 EAV 的设计 - 单独的 Measure 维度表。该外键将进入事实表，度量值将在事实表中。因此，事实表的粒度将更改为每次测量每个检查类型每个患者 1 行。

3) 根据子组等其他一些标准，为每种考试类型创建更小的多个事实表。但最终用户将跨子组查询该考试类型，不建议使用事实连接。

4) 还有其他想法吗？

任何意见将不胜感激。

【问题讨论】：

【解决方案1】：

1.包含 1000 列或更多列的宽大事实表。

如果直接在数据仓库中执行查询，则一个非常宽的事实表可为最终用户提供最大的灵活性。但是，应考虑一些注意事项，因为您可能会遇到一些限制，具体取决于平台。

SQL Server 2014 限制如下：

每行字节数 8,060。行溢出存储可能是一种解决方案，但它仅支持少数通常与事实性质无关的列类型，即 varchar、nvarchar、varbinary、sql_variant。内存中 OLTP 也不支持。 https://technet.microsoft.com/en-us/library/ms186981(v=sql.105).aspx
每个非宽表的列数 1024。宽表和稀疏列是解决方案，因为每个宽表的列限制为 30,000。但是，同样的每行字节数限制适用。 https://technet.microsoft.com/en-us/library/cc280604(v=sql.120).aspx
每个 SELECT/INSERT/UPDATE 语句的列数 4,096
每个表的非聚集索引 999

2。基于 EAV 的设计 - 单独的 Measure 维度表。该外键将进入事实表，度量值将在事实表中。因此，事实表的粒度将更改为每次测量每个检查类型每个患者 1 行。

根据 Kimball 的说法，EAV 设计称为事实标准化。当一些测量非常冗长，但对于给定的事实人口稀少并且没有在事实之间进行计算时，这可能是有意义的。

因为事实因此被归一化：

可扩展性非常简单，即无需修改数据结构即可轻松添加新测量值。
最好提取一次检查的所有测量值并将测量值显示为屏幕上的行。
很难在多个测量值之间提取/聚合/进行计算（例如，平均 HDL 与 CHOL 的比率）并将测量值/聚合/计算呈现为列，即需要复杂的 WHERE/PIVOTING 或多连接。 SQL 使得在不同行中的事实之间进行计算变得困难。
如果主要最终用户平台是 OLAP 多维数据集，那么事实规范化是有意义的。立方体允许跨任何维度进行计算。
如果数据格式为平面样式 CSV，则数据导入可能会出现问题。

这里也讨论了这个问题Should I use EAV model?。

3) 根据子组等其他一些标准，为每种考试类型创建更小的多个事实表。但最终用户将跨子组查询该考试类型，不建议使用事实连接。

在某些情况下，多个较小的事实表完全合理。原因之一是如果您达到了平台设置的一些物理限制，例如每行字节数。

事实可以按主题领域进行分组，例如测量组/子组，或按使用频率。每个表都可以放在单独的文件组和驱动器上以最大化 I/O。

此外，您可以在不同的事实表中重复测量以减少事实表连接的需要，即将一个测量放在特定的测量子组事实表和常用的测量事实表中。

但是，如果对数据加载有一些特定要求，则应考虑一些注意事项。例如，如果您的 ETL 中的一条记录错误输出到一个事实表，您可能希望确保删除其他事实表中的相应记录并将其暂存到您的错误表中，这样您就不会得到任何虚假信息.如果最终用户在前端工具中有自己的计算，则尤其如此。

如果您使用 OLAP 多维数据集，那么多个事实表实际上会成为特定事实表的度量值组的来源。

就事实到事实的联接而言，您（BI 应用程序）绝不应该发出通过事实表的外键将两个事实表联接在一起的 SQL。相反，应该使用钻取两个事实表的技术，其中分别创建来自两个或多个事实表的答案集，并将结果排序合并到公共行标题属性值上以产生正确的结果。

4) 还有其他想法吗？

SQL XML 或某种 NoSQL 可能是一种选择，但存在相同的查询/聚合/计算/表示问题。

【讨论】：