pra*_*ash 5 data-warehouse dimensional-modeling amazon-redshift
我正在尝试在平面OLTP表上创建尺寸模型（不在3NF中）。
有些人认为维度模型表不是必需的，因为报告的大多数数据都显示为单个表。但是该表包含的内容超出了我们所需的300列。我还是应该将平面表划分为维度和事实，还是直接在报表中使用平面表？
当纯粹为了报告目的而创建表时（这在数据仓库中很常见），通常会使用非标准化数据创建宽而平坦的表，因为：
\n\n此数据格式非常适合报告，但不适合应用程序的正常数据存储\xe2\x80\x94 用于 OLTP 的数据库应使用规范化表。
\n\n不要担心有大量列\xe2\x80\x94 这对于数据仓库来说是很正常的。然而，300 列听起来确实相当大，并且表明它们不一定被明智地使用。因此，您可能需要检查它们是否是必需的。
\n\n许多列的一个很好的例子是拥有可以轻松编写 WHERE 子句的标志，例如WHERE customer_is_active不必连接到另一个表并确定他们在过去 30 天内是否使用过该服务。这些列每天都需要重新计算，但是对于查询数据来说非常方便。
底线：使用数据仓库时，您应该将易用性置于性能之上。然后，了解如何使用数据仓库系统（例如 Amazon Redshift）来优化访问，该系统旨在非常有效地处理此类数据。
\n您已经问了一个有关数据仓库的数据库建模的通用问题，它将为您提供通用的答案，而这些答案可能不适用于您正在使用的数据库平台-如果您想要可以使用的答案那么我建议您更具体一些。
问号表明您正在使用Amazon Redshift，并且该数据库的答案与SQL Server和Oracle等传统关系数据库不同。
首先，您需要了解Redshift与常规关系数据库的区别：
1）这是一个大规模并行处理（MPP）系统，它由一个或多个节点组成，数据分布在这些节点上，每个节点通常完成回答每个查询所需的一部分工作。因此，跨节点分布数据的方式变得很重要，通常的目的是使数据以相当均匀的方式分布，以便每个节点为每个查询执行大约相等的工作量。
2）数据以列格式存储。这与SQL Server或Oracle的基于行的格式完全不同。在列式数据库中，数据的存储方式使大型聚合类型查询的效率大大提高。这种类型的存储部分抵消了维表的原因，因为在行中存储重复数据（附件）是相对高效的。
Redshift表通常使用一列（分布键）的值分布在节点上。或者，它们可以随机但均匀分布，或者Redshift可以在每个节点上制作数据的完整副本（通常仅使用很小的表即可完成）。
因此，在决定是否创建尺寸时，您需要考虑这是否真的会带来很多好处。如果数据中有定期更新的列，则最好将它们放在另一个较小的表中，而不是更新一个较大的表。但是，如果数据主要是仅追加（不变）的，那么创建尺寸就没有任何好处。对数据进行分组和汇总的查询将在单个表上高效。
除非两个表都以相同的值（例如，用户ID）进行分配，否则在Redshift上，JOIN可能变得非常昂贵-如果不是，则Redshift将必须在节点周围物理复制数据才能运行查询。因此，如果必须具有维度，则需要将最大的维度表与事实表分配在同一键上（请记住，每个表只能分布在一个列上），那么可能需要分配任何其他维度作为ALL（复制到每个节点）。
我的建议是只使用一个表，除非您迫切需要创建维（例如，如果某些列经常更新）。