【发布时间】：2010-09-11 17:19:31
【问题描述】：
星型架构设计对于数据仓库来说是否必不可少？或者你能用另一种设计模式做数据仓库吗？
【问题讨论】：
-
从技术上讲，您可以将所有内容放在一个表中，即没有维度表的事实表，以及实际的维度数据而不是键。但这会很快变得非常大，因此是单一级别的标准化。
标签： database design-patterns data-warehouse star-schema dimensional-modeling
【发布时间】：2010-09-11 17:19:31
【问题描述】：
将star schemas 用于数据仓库系统可为您带来多项好处，并且在大多数情况下，将它们用于顶层是合适的。您可能还拥有一个操作数据存储 (ODS) - 一种规范化的结构，它保存“当前状态”并促进诸如数据整合之类的操作。然而，在某些合理的情况下，这是不可取的。我有机会构建有和没有 ODS 层的系统，并且在每种情况下选择架构都有特定的原因。
无需深入了解数据仓库架构的细节或引发 Kimball 与 Inmon 的激烈战争，星型模式的主要好处是：
大多数数据库管理系统 在查询优化器中有设施 做“星变” 使用Bitmap Index 结构或 Index Intersection 快速 谓词解析。这意味着在解决选择之前，可以在不触及事实表（通常比索引大得多）的情况下从星型模式中进行选择。
Partitioning 星型模式相对简单，因为只需要对事实表进行分区（除非您有一些符合圣经的大维度）。 Partition elimination 表示查询优化器可以忽略不可能参与查询结果的分区，从而节省 I/O。
Slowly changing dimensions 在星型架构上比雪花更容易实现。
与 snowflake 或 E-R 架构相比，该架构更易于理解，并且涉及的连接更少。您的报告团队会因此而爱上您
星型模式更易于使用，并且（更重要的是）可以与 Business Objects 或 Report Builder 等临时查询工具配合使用。作为开发人员，您对这些工具生成的 SQL 几乎没有控制权，因此您需要为查询优化器提供尽可能多的帮助。星型模式使查询优化器出错的机会相对较少。
您的报告层通常会使用星型模式，除非您有特定的理由不这样做。如果您有多个源系统，您可能希望使用规范化或雪花模式来实现 Operational Data Store 来积累数据。这更容易，因为 ODS 通常不做历史记录。在星型模式中跟踪历史状态，这比使用规范化结构更容易做到。规范化或雪花状操作数据存储反映了“当前”状态，并且不包含数据中固有的任何历史视图。
ODS 加载过程涉及数据清理和一致性，这对于规范化结构更容易实现。一旦您在 ODS 中拥有干净的数据，维度和事实负载就可以使用通用或相对简单的机制相对简单地跟踪历史记录（随时间的变化）；使用星型模式更容易做到这一点，许多 ETL 工具（例如）提供了用于缓慢变化维度的内置工具，并且实现通用机制相对简单。
以这种方式分层系统提供了职责分离 - 业务和数据清理逻辑在 ODS 中处理，星型模式负载处理历史状态。
【讨论】：
数据仓库文献中一直存在关于应该在数据仓库架构中何处应用Star-Schema 设计的争论。
简而言之，Kimball 非常提倡在数据仓库中仅使用 Star-Schema 设计，而 Inmon 首先希望使用 normalized 3NF 设计构建企业数据仓库，然后在数据集市中使用 Star-Schema 设计.
除了这里你还可以说Snowflake schema design是另一种方法。
第四种设计可能是Data Vault Modeling 方法。
【讨论】：
星型模式用于实现对大量数据的高速访问。通过减少满足可能针对主题区域进行的任何查询所需的连接数量，可以实现高性能。这是通过允许维度表中的数据冗余来实现的。
您必须记住，星型模式是仓库顶层的模式。所有模型还涉及仓库堆栈底部的暂存模式，有些还包括一个持久转换的合并暂存区域，其中所有源系统都合并到 3NF 建模模式中。各种学科领域位于此之上。
顶级星型模式的替代方案包括一种变体，即雪花模式。 Dan Linstedt 提出的Data Vault Modelling 是一种新方法，也可能需要进行一些调查。
【讨论】：
关于星型模式的一点是，它们是大多数人想用数据仓库做的事情的自然模型。例如，很容易生成具有不同粒度级别（例如月、日或年）的报告。将典型的业务数据插入星型模式也很有效，这也是数据仓库的常见且重要的特性。
您当然可以使用任何类型的数据库，但除非您非常了解自己的业务领域，否则如果您使用星型模式，您的报告可能无法像它们那样有效地运行。
【讨论】：
-
它基本上是SQL中的面向对象设计;)
星型模式非常适合数据仓库的最后一层。你如何到达那里是另一个问题。据我所知，有两大阵营，比尔·英蒙和拉尔夫·金博尔的阵营。如果/当您决定选择明星时，您可能想看看这两个家伙的理论。
此外，一些报告工具非常喜欢星型模式设置。如果您被锁定在特定的报告工具中，这可能会推动报告集市在您的仓库中的外观。
【讨论】：
-
+1 - Kimball vs. Inmon 是一场伟大的宗教战争。恕我直言，这种宗教分歧的存在清楚地表明，这两种论点都没有说服力。我已经构建了有和没有 ODS 层的系统 - 并且有充分的理由做出架构决策。
-
现在还有 Data Vault Modeling (en.wikipedia.org/wiki/Data_Vault_Modeling) 作为数据集市下方的一层。
星型模式是适合常规数据仓库需求的关系数据库的逻辑数据模型；如果给定了关系环境，星型或雪花模式将是一种很好的设计模式，在许多 DW 设计方法中都是固定的。
然而，除了关系数据库引擎之外，还有其他一些引擎，它们可以用于高效的数据仓库。多维存储引擎对于 OLAP 任务（例如 TM1）可能非常快；在这种情况下，我们不能应用星型模式设计。其他需要特殊逻辑模型的示例包括 XML 数据库或面向列的数据库（例如，实验性的 C-store)）。
【讨论】：
-
“除了关系数据库引擎”...有趣。他们对数据使用什么设计模式？星型模式还是其他类型的设计？
-
多维 (MOLAP) 数据库将其数据存储在各种多维数组结构中。从概念上讲，在我的解释中，在构建数据仓库时，我们首先构建概念数据模型（带有维度和数据立方体），然后我们将其映射到逻辑级别（表和约束），然后在物理级别（文件磁盘，由 DBMS 处理）。然而，MOLAP 引擎将概念模型直接映射到物理级别。由于星型模式是关系型 dws 的逻辑模型，因此在 MOLAP 环境中省略。
可以不用。然而，你会让自己的生活变得艰难——你的组织将希望使用位于 DW 之上的标准工具，并且这些工具将期望一个星型模式——将花费大量精力将方形钉子安装在圆形中洞。
很多数据库级别的优化都假设你有一个星型模式；您将花费大量时间进行优化和重组，以使数据库使用您的非星形布局做“正确的事情”。
确保利大于弊..
（听起来像我以前去过那里吗？）
-D
【讨论】：
我们需要解决三个问题。
1) 如何通过连接表内和表间的表、在提取时清理数据、创建派生等，从可操作的源系统中取出数据而不给它们施加过度压力。
2) 如何将来自不同来源的数据（一些来自不同部门的遗留数据、一些基于文件的数据）合并为一个完整、准确、高效存储的整体，该整体对业务进行建模，并且不反映源系统的结构。请记住，系统更改/更换相对较快，但业务的基本模型变化缓慢。
3) 如何构建数据以满足业务中特定人员/部门的特定分析和报告要求，尽可能快速准确地进行。
这三个截然不同的问题的解决方案需要不同的架构层来解决它们
暂存层 我们复制源的结构，但每晚只加载来自源的更改数据。一旦数据从暂存层进入下一层，数据就会被丢弃。查询是带有简单 data_time 过滤器的单表查询。对源的影响很小。
企业层 这是一个面向业务的第三范式数据库。数据从暂存层提取（然后丢弃）到企业层，在那里进行清理、集成和规范化。
表示（星型模式）层 在这里，我们对尺寸进行建模以满足特定要求。数据被故意去规范化以减少连接的数量。企业层中可能占用多个表的层次结构被折叠成单个维度表，多个事务表可以合并成单个事实表。
您总是面临这三个问题。如果选择去掉企业层，还是要解决第二个问题，但是必须在星型层做，在我看来，这是做错的地方。
【讨论】：