我正在尝试在扁平的OLTP表上创建维度模型（不在第三正式化范式中）。
有些人认为维度模型表不是必需的，因为报告的大部分数据都来自单个表。但是该表包含比我们需要的更多列，例如300列。我应该仍然将扁平表分离为维度和事实，还是直接在报告中使用扁平表。
2个回答
8
您提出了一个关于数据仓库数据库建模的普遍问题，这将得到一些通用答案，可能不适用于您正在使用的数据库平台 - 如果您想获得可以使用的答案，我建议您更具体地说明问题。
问题标签表明您正在使用Amazon Redshift，该数据库的答案与传统的关系型数据库（如SQL Server和Oracle）不同。
首先，您需要了解Redshift与常规关系型数据库的区别：
1）它是一个大规模并行处理（MPP）系统，由分布在多个节点上的数据组成，每个节点通常执行回答每个查询所需的一部分工作。因此，数据在节点之间的分布方式变得重要起来，通常的目标是使数据分布相对均匀，以便每个节点对每个查询执行大致相等的工作量。
我的建议是，除非您有迫切需要创建维度（例如经常更新的列），否则请坚持使用单个表。
问题标签表明您正在使用Amazon Redshift，该数据库的答案与传统的关系型数据库（如SQL Server和Oracle）不同。
首先，您需要了解Redshift与常规关系型数据库的区别：
1）它是一个大规模并行处理（MPP）系统，由分布在多个节点上的数据组成，每个节点通常执行回答每个查询所需的一部分工作。因此，数据在节点之间的分布方式变得重要起来，通常的目标是使数据分布相对均匀，以便每个节点对每个查询执行大致相等的工作量。
2) 数据以列式格式存储。这与SQL Server或Oracle的行式格式完全不同。在列式数据库中，数据以使大型聚合类型查询更加高效的方式存储。这种存储方式部分抵消了维度表的原因，因为在行中存储重复数据（属性）相对高效。
Redshift表通常使用一个列的值（分布键）分布在节点上。或者它们可以随机但均匀地分布，或者Redshift可以在每个节点上进行完全复制（通常仅针对非常小的表）。
因此，在决定是否创建维度时，您需要考虑这是否实际上会带来很多好处。如果数据中有经常更新的列，则最好将其放入另一个较小的表中，而不是更新一个大表。但是，如果数据基本上是追加的（不变的），则创建维度没有任何好处。对数据进行分组和聚合的查询将在单个表上高效执行。
JOINs在Redshift上可能会非常昂贵，除非两个表基于相同的值进行分布（例如用户ID）- 如果它们没有，则Redshift将不得不在节点之间物理复制数据以便运行查询。因此，如果必须有维度，则需要将最大的维度表与事实表分布在相同的键上（记住每个表只能分布在一列上），然后任何其他维度可能需要分布为ALL（复制到每个节点）。我的建议是，除非您有迫切需要创建维度（例如经常更新的列），否则请坚持使用单个表。
- Nathan Griffiths
9
SQL Server和Oracle都支持列式表存储，并且在MPP SQL Server（Azure SQL Data Warehouse）中是默认设置。 - David Browne - Microsoft
嗨，David，我在这里问了一个问题，你是说我们应该在Azure数据仓库中使用big wide还是dim/fact？这个问题更多地是针对redshift的。谢谢。https://stackoverflow.com/questions/54001693/microsoft-azure-data-warehouse-flat-tables-or-star-schema - user10503656
顺便提一下，似乎Azure数据仓库更喜欢使用Dim和Facts，https://learn.microsoft.com/en-us/azure/sql-data-warehouse/sql-data-warehouse-tables-overview，我想确认一下。 - user10503656
1@sparc_spread 如果您的查询模式有些不可预测，其中一个或多个“维度”列将在查询WHERE子句中用作过滤器，例如columnA =“SomeValue”，则交错排序键非常有用。如果您有一组可预测的列将按特定顺序进行过滤，则复合排序键可能是更好的选择。不要在包含增量键值（标识值）或时间戳的列上创建交错排序键。请参见https://docs.aws.amazon.com/redshift/latest/dg/t_Sorting_data.html。 - Nathan Griffiths
@NathanGriffiths 好的，再次感谢你提供的帮助！ - sparc_spread
显示剩余4条评论
5
当创建纯粹用于报告目的的表格时（如数据仓库中的典型情况），通常会创建宽而平的表格，其中包含非规范化数据，因为：
- 它更容易查询 - 它避免了对于普通用户来说可能令人困惑和容易出错的JOIN操作 - 查询运行速度更快（特别是对于使用列式数据存储的数据仓库系统）
这种数据格式非常适合报告，但不适合用于应用程序的正常数据存储 - 用于OLTP的数据库应该使用规范化的表格。
不要担心有大量的列 - 这在数据仓库中很正常。然而，300列听起来相当大，这表明它们不一定被明智地使用。因此，您可能需要检查它们是否是必需的。
许多列的一个很好的例子是具有使编写WHERE子句变得容易的标志，例如“WHERE customer_is_active”，而不必连接到另一个表并弄清楚他们在过去30天内是否使用了服务。这些列需要每天重新计算，但对于查询数据非常方便。
底线：在使用数据仓库时，您应该把易用性放在性能之上。然后，通过使用Amazon Redshift等数据仓库系统来优化访问，这些系统专门设计用于非常高效地处理此类数据。
- 它更容易查询 - 它避免了对于普通用户来说可能令人困惑和容易出错的JOIN操作 - 查询运行速度更快（特别是对于使用列式数据存储的数据仓库系统）
这种数据格式非常适合报告，但不适合用于应用程序的正常数据存储 - 用于OLTP的数据库应该使用规范化的表格。
不要担心有大量的列 - 这在数据仓库中很正常。然而，300列听起来相当大，这表明它们不一定被明智地使用。因此，您可能需要检查它们是否是必需的。
许多列的一个很好的例子是具有使编写WHERE子句变得容易的标志，例如“WHERE customer_is_active”，而不必连接到另一个表并弄清楚他们在过去30天内是否使用了服务。这些列需要每天重新计算，但对于查询数据非常方便。
底线：在使用数据仓库时，您应该把易用性放在性能之上。然后，通过使用Amazon Redshift等数据仓库系统来优化访问，这些系统专门设计用于非常高效地处理此类数据。
- John Rotenstein
2
@HardyWest 我的回答并不特定于Amazon Redshift。人们发现从宽、扁平的表格中查询更容易。这些表格可以从更复杂的数据模型中生成。这样，源数据就以适合数据的格式存储，而“易于查询”的表格可以为人类生成。两全其美！ - John Rotenstein
好的，谢谢。希望您能给出针对AWS Redshift的具体答案，我们公司正在考虑迁移到这个平台。我知道Microsoft SSAS Cube更喜欢使用dim/fact模式，但他们可能会有不同意见。然而，这只是Microsoft的观点。Hadoop也更喜欢使用大型宽表。有时，提供针对AWS技术的答案可以消除所有争论 :) - user10503656
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接