data-warehouse - 100 个事实的事实表设计指南

Question

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

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

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

我能想到的一些选择——

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

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

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

4）还有其他想法吗？

任何输入将不胜感激。

score 4 · Accepted Answer

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 设计称为Fact Normalization。当一些测量非常冗长，但对于给定事实的填充稀疏并且在事实之间没有进行计算时，这可能是有意义的。

因为事实被归一化，所以：

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

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

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

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

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

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

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

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

4）还有其他想法吗？

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

1 回答 1