Star-Schema设计对于数据仓库是否必不可少？还是可以使用另一种设计模式进行数据仓库？

解决方案

关于星型模式的事情是，它们是大多数人想对数据仓库执行的各种事情的自然模型。例如，很容易生成具有不同粒度级别的报告(例如，月，日或者年)。将典型的业务数据插入星型架构也很有效，这也是数据仓库的常见且重要的功能。

我们当然可以使用所需的任何类型的数据库，但是除非我们非常了解业务领域，否则如果使用星型模式，则报告运行效率可能会不及它们。

星型模式用于启用对大量数据的高速访问。通过减少满足可能针对主题区域进行的任何查询所需的联接数量，可以实现高性能。这是通过允许维度表中的数据冗余来完成的。

我们必须记住，星型模式是仓库顶层的一种模式。所有模型还涉及仓库堆栈底部的暂存方案，有些还包括持久性转换的合并暂存区，在此区域中，所有源系统都合并到3NF建模的方案中。各个主题领域都位于此之上。

顶层星型模式的替代方案包括一个变体，即雪花模式。 Dan Linstedt提出的Data Vault Modeling也是一种可能值得调查的新方法。

星型模式非常适合数据仓库的最后一层。我们如何到达那里还有另一个问题。据我所知，有两个大阵营，比尔·伊蒙和拉尔夫·金博尔。如果/当我们决定与明星同行时，我们可能想看看这两个家伙的理论。

此外，某些报告工具真的很喜欢星型架构设置。如果我们被锁定在特定的报告工具中，则可能会驱动仓库中的报告市场。

在数据仓库系统中使用星型模式可以为我们带来一些好处，并且在大多数情况下，将其用于顶层是合适的。我们可能还具有可操作的数据存储(ODS)的标准化结构，该结构可保存"当前状态"并简化诸如数据确认之类的操作。但是，在某些合理的情况下，这是不希望的。我曾经有过构建带有和不带有ODS层的系统的机会，并且在每种情况下都有选择架构的特定原因。

无需深入研究数据仓库架构，也无需启动Kimball与Inmon的火焰之战，星型模式的主要好处是：

• 大多数数据库管理系统在查询优化器中都具有执行"星型转换"的功能，这些功能使用位图索引结构或者索引交集来快速进行谓词解析。这意味着在解决选择之前，无需点击事实表(通常比索引大很多)就可以从星型模式中进行选择。
• 对星型模式进行分区相对简单，因为只需要对事实表进行分区(除非我们有一些圣经上的大尺寸标注)。分区消除意味着查询优化器可以忽略可能无法参与查询结果的分区，从而节省了I / O。
• 在星型模式下，缓慢地更改尺寸比雪花更容易实现。
• 与雪花或者E-R模式相比，该模式更容易理解，并且涉及的联接较少。报告团队将为此而爱我们
• 星型模式更易于使用，(更重要的是)在临时查询工具(例如业务对象或者报表生成器)中使其表现良好。作为开发人员，我们几乎无法控制这些工具生成的SQL，因此我们需要为查询优化程序提供尽可能多的帮助。星型模式为查询优化器提供了很少的机会来弄错它。

通常，除非有特殊原因，否则报告层将使用星型模式。如果我们有多个源系统，则可能要使用规范化或者雪花模式实施操作数据存储以累积数据。这比较容易，因为ODS通常不执行历史记录。在星型模式中跟踪历史状态，这比使用规范化结构更容易做到。规范化或者雪花化的操作数据存储反映了"当前"状态，并且不具有任何数据固有的历史视图。

ODS加载过程与数据清理和合规性有关，使用标准化结构更容易做到这一点。一旦我们在ODS中拥有了干净的数据，维度和事实负载就可以使用通用或者相对简单的机制相对简单地跟踪历史记录(随时间的变化)。使用星型模式更容易做到这一点。例如，许多ETL工具都提供了内置的工具来缓慢改变尺寸，并且实现通用机制相对简单。

通过这种方式对系统进行分层，可以将职责分离，业务和数据清理逻辑在ODS中进行处理，而星型架构负载则用于处理历史状态。

没有它是可能的。但是，我们将使自己的生活变得艰苦-组织将希望使用DW之上的标准工具，而这些工具将具有星形模式-将大量精力花费在将圆钉固定在圆孔中。

许多数据库级别的优化都假设我们拥有星型架构；我们将花费大量时间进行优化和重组，以使数据库对非常规布局进行"正确的处理"。

确保利弊大于利..

(听起来我以前去过那里吗？)

-D

星型模式是关系数据库的逻辑数据模型，可以满足常规数据仓库的需求；如果提供了关系环境，则星型或者雪花型将是一种良好的设计模式，在许多DW设计方法中都是硬接线的。

但是，除了关系数据库引擎之外，还有其他引擎，它们可以用于有效的数据仓库。多维存储引擎对于OLAP任务(例如TM1)可能非常快。在这种情况下，我们将无法应用星型模式设计。需要特殊逻辑模型的其他示例包括XML数据库或者面向列的数据库(例如实验性C存储)。