星型模式设计对于数据仓库是必要的吗？还是可以使用其他设计模式进行数据仓库建设？
星型模式设计
63
- S.Lott
1
从技术上讲，您可以将所有内容放在一个表中，即一个没有维度表的事实表，并且实际的维度数据而不是键。但这会很快变得非常庞大，因此需要进行单层规范化。 - Neil McGuigan
8个回答
97
使用星型模式作为数据仓库系统可以带来多个好处，在大多数情况下，将它们用于顶层是合适的。您可能还拥有一个操作数据存储（ODS）-一个规范化结构，用于保存“当前状态”并促进数据确认等操作。但是，在某些情况下，这并不可取。我曾经建立过有和没有ODS层的系统，并且在每种情况下都有特定的架构选择原因。
不谈论数据仓库架构的细微差别或引发Kimball vs. Inmon争论，星型模式的主要好处包括：
大多数数据库管理系统都有查询优化器中的设施，可以执行“星形转换”，使用位图索引结构或索引交集进行快速谓词解析。这意味着可以在不命中事实表（通常比索引大得多）的情况下完成对星型模式的选择，直到选择被解决。
分区星型模式相对简单，因为只需要对事实表进行分区（除非您有一些超级大的维度）。分区消除意味着查询优化器可以忽略那些不可能参与查询结果的分区，从而节省I/O。
慢变化维度在星型模式上比雪花模式更容易实现。
该模式比雪花或E-R模式更易于理解，并且涉及的连接较少。你的报告团队会喜欢这个。
星型模式更易于使用，（更重要的是）可与诸如Business Objects或Report Builder等自助查询工具良好地配合使用。作为开发人员，您几乎无法控制这些工具生成的SQL，因此需要尽可能地帮助查询优化器。星型模式给查询优化器提供了相对较少的机会出错。
ODS加载过程涉及数据清洗和标准化，这在使用归一化结构时更容易完成。一旦您在ODS中拥有了干净的数据，维度和事实负载就可以使用通用或相对简单的机制轻松跟踪历史记录（随时间的变化）；这在使用星型模式时更容易完成。许多ETL工具（例如）提供内置设施，用于缓慢更改的维度和实现通用机制相对简单。
以这种方式分层系统提供了责任的分离 - 业务和数据清理逻辑在ODS中处理，而星型模式负载则处理历史状态。
- Nigel Campbell
8
星型模式用于实现对大量数据的高速访问。通过减少连接操作的次数，可以提高性能，以满足对主题区域可能进行的任何查询。这是通过在维度表中允许数据冗余来实现的。
你必须记住，星型模式是数据仓库顶层的一种模式。所有模型还包括位于数据仓库堆栈底部的分期模式，并且有些模型还包括一个持久转换合并的分期区域，将所有源系统合并为3NF模型化的模式。各个主题区域位于此之上。
作为顶层的星型模式的替代方案包括变体，即雪花模式。另外，还有一种新方法Data Vault Modelling，由丹·林斯特德提出，可能值得进一步研究。
你必须记住，星型模式是数据仓库顶层的一种模式。所有模型还包括位于数据仓库堆栈底部的分期模式，并且有些模型还包括一个持久转换合并的分期区域，将所有源系统合并为3NF模型化的模式。各个主题区域位于此之上。
作为顶层的星型模式的替代方案包括变体，即雪花模式。另外，还有一种新方法Data Vault Modelling，由丹·林斯特德提出，可能值得进一步研究。
- Mike McAllister
7
星型模式的好处在于它们是大多数人想要在数据仓库中完成的任务的自然模型。例如，可以轻松生成具有不同粒度级别（例如月、日或年）的报告。将典型的业务数据插入星型模式也非常高效，这是数据仓库的常见且重要特性。
当然，您可以使用任何类型的数据库，但除非您非常了解业务领域，否则您的报告可能无法像使用星型模式一样高效运行。
当然，您可以使用任何类型的数据库，但除非您非常了解业务领域，否则您的报告可能无法像使用星型模式一样高效运行。
- Mike
1
这其实就是在 SQL 中的面向对象设计 ;) - Hamish Grubijan
6
星型模式是数据仓库中最后一层的自然选择。如何到达这里是另一个问题。据我所知，有两个大派别，分别是Bill Inmon和Ralph Kimball。如果/当您决定采用星型模式，可以考虑这两位专家的理论。
此外，一些报告工具确实喜欢星型模式设置。如果您被锁定在特定的报告工具中，那么这可能会影响仓库中报告市场的外观。
- Josh McAdams
2
2+1 - Kimball vs. Inmon 是伟大的宗教战之一。在我看来，这种宗教分裂的存在清楚地表明两种观点都不具有说服力。我已经建立过具有和没有 ODS 层的系统，并对架构决策有充分理由。 - ConcernedOfTunbridgeWells
1现在还有数据保险库建模（http://en.wikipedia.org/wiki/Data_Vault_Modeling），可以作为您的数据集市下面的一层。 - Marcus D
4
Star schema是关系数据库的逻辑数据模型，适用于常规数据仓库需求；如果给定关系环境，则星型或雪花模式将是良好的设计模式，这在许多DW设计方法中都是硬编码的。
然而，除了关系数据库引擎外，还有其他可以用于高效数据仓库的引擎。多维存储引擎可能非常适合OLAP任务（例如TM1）；在这种情况下，我们不能应用星型模式设计。其他需要特殊逻辑模型的示例包括XML数据库或列导向数据库（例如实验性C-store)）。
然而，除了关系数据库引擎外，还有其他可以用于高效数据仓库的引擎。多维存储引擎可能非常适合OLAP任务（例如TM1）；在这种情况下，我们不能应用星型模式设计。其他需要特殊逻辑模型的示例包括XML数据库或列导向数据库（例如实验性C-store)）。
- csaba
2
除了关系型数据库引擎之外……有趣。他们用什么样的数据设计模式？星型模式还是其他类型的设计？ - S.Lott
多维(MOLAP)数据库将数据存储在各种多维数组结构中。在我的理解中，在构建数据仓库时，我们首先构建一个概念性的数据模型(包括维度和数据立方体)，然后将其映射到逻辑层(表和约束条件)，最后在物理层上实现它(由DBMS处理的磁盘文件)。然而，MOLAP引擎直接将概念模型映射到物理层。由于星型模式是关系型dws的逻辑模型，因此在MOLAP环境中被省略。 - csaba
3
可以不使用星型模式，但这会让工作变得更加困难--你的组织可能需要使用基于DW的标准工具，而这些工具需要一个星型模式--你将花费大量精力来适应这个不合适的布局。
很多数据库级别的优化都假设你有一个星型模式；你将花费大量时间来优化和重构以使DB能够正确处理你的非完整星型布局。
确保利弊得失相当。
（听起来像我之前去过那里吗？）
-D
很多数据库级别的优化都假设你有一个星型模式；你将花费大量时间来优化和重构以使DB能够正确处理你的非完整星型布局。
确保利弊得失相当。
（听起来像我之前去过那里吗？）
-D
- Dmitriy
2
有三个问题需要解决：
1) 如何在不对操作性源系统造成压力的情况下获得数据，而不必在其内部和之间联接表格、清洁提取的数据，创建衍生等。
2) 如何将来自不同来源（一些遗留的、一些基于文件的、来自不同部门）的数据合并为一个整体、准确、高效存储的模型，不反映源系统的结构。请记住，系统变化/被相对快速地替换，但业务的基本模型变化缓慢。
3) 如何快速、准确地组织数据以满足特定人员/部门的分析和报告要求。
解决这三个非常不同的问题需要不同的架构层来解决。
暂存层 我们复制源的结构，但只加载每晚的更改数据。一旦将数据从暂存层取出到下一层，数据就被删除了。查询是单表查询，具有简单的数据时间过滤器。对源影响很小。
企业层 这是一个面向业务的第三正态形式数据库。数据从暂存层中提取（然后删除），在企业层中进行清理、集成和规范化。
呈现（星型模式）层 在这里，我们建立维度模型以满足特定要求。数据被故意非规范化以减少联接数量。可能占用企业层多个表的层次结构被折叠成单个维度表，多个事务表可以合并为单个事实表。
你总是面临这三个问题。如果你选择放弃企业层，你仍然必须解决第二个问题，但你必须在星型模式层中解决它，在我看来，这是错误的做法。
1) 如何在不对操作性源系统造成压力的情况下获得数据，而不必在其内部和之间联接表格、清洁提取的数据，创建衍生等。
2) 如何将来自不同来源（一些遗留的、一些基于文件的、来自不同部门）的数据合并为一个整体、准确、高效存储的模型，不反映源系统的结构。请记住，系统变化/被相对快速地替换，但业务的基本模型变化缓慢。
3) 如何快速、准确地组织数据以满足特定人员/部门的分析和报告要求。
解决这三个非常不同的问题需要不同的架构层来解决。
暂存层 我们复制源的结构，但只加载每晚的更改数据。一旦将数据从暂存层取出到下一层，数据就被删除了。查询是单表查询，具有简单的数据时间过滤器。对源影响很小。
企业层 这是一个面向业务的第三正态形式数据库。数据从暂存层中提取（然后删除），在企业层中进行清理、集成和规范化。
呈现（星型模式）层 在这里，我们建立维度模型以满足特定要求。数据被故意非规范化以减少联接数量。可能占用企业层多个表的层次结构被折叠成单个维度表，多个事务表可以合并为单个事实表。
你总是面临这三个问题。如果你选择放弃企业层，你仍然必须解决第二个问题，但你必须在星型模式层中解决它，在我看来，这是错误的做法。
- Steve
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接