Star-Schema 设计对数据仓库来说是必不可少的吗？或者你能用另一种设计模式做数据仓库吗？
S.Lott
问问题
35589 次
8 回答
96
为数据仓库系统使用星型模式可以获得几个好处，并且在大多数情况下，将它们用于顶层是合适的。您可能还拥有一个操作数据存储 (ODS) - 一种规范化的结构，它保存“当前状态”并促进诸如数据整合之类的操作。然而，在某些合理的情况下，这是不可取的。我曾经有机会构建带有和不带有 ODS 层的系统，并且在每种情况下选择架构都有特定的原因。
无需深入了解数据仓库架构的细节或发起 Kimball 与 Inmon 的激烈战争，星型模式的主要好处是：
大多数数据库管理系统在查询优化器中都有工具来执行“星形转换”，使用位图索引结构或 索引交集来快速解析谓词。这意味着在解决选择之前，可以在不触及事实表（通常比索引大得多）的情况下从星型模式中进行选择。
对星型模式进行分区相对简单，因为只需要对事实表进行分区（除非您有一些圣经中的大维度）。 分区消除意味着查询优化器可以忽略不可能参与查询结果的分区，从而节省 I/O。
在星形模式上实现缓慢变化的维度比在雪花模式上更容易实现。
与雪花或 ER 模式相比，该模式更易于理解，并且往往涉及更少的连接。您的报告团队会因此而爱上您
星型模式更易于使用，并且（更重要的是）可以很好地与诸如Business Objects或Report Builder之类的临时查询工具一起使用。作为开发人员，您对这些工具生成的 SQL 几乎没有控制权，因此您需要为查询优化器提供尽可能多的帮助。星型模式使查询优化器出错的机会相对较少。
通常，您的报告层会使用星型模式，除非您有特定的理由不这样做。如果您有多个源系统，您可能希望使用规范化或雪花模式来实现操作数据存储以累积数据。这更容易，因为 ODS 通常不做历史记录。在星型模式中跟踪历史状态，这比使用规范化结构更容易做到。标准化或雪花状操作数据存储反映了“当前”状态，并且不包含数据中固有的任何历史视图。
ODS 加载过程与数据清理和一致性有关，这对于规范化结构来说更容易实现。一旦您在 ODS 中拥有干净的数据，维度和事实负载就可以使用通用或相对简单的机制相对简单地跟踪历史记录（随时间的变化）；这使用星型模式要容易得多，许多 ETL 工具（例如）提供了用于缓慢变化维度的内置工具，并且实现通用机制相对简单。
以这种方式对系统进行分层提供了职责分离——业务和数据清理逻辑在 ODS 中处理，星型模式负载处理历史状态。
于 2008-09-21T13:46:24.540 回答
8
星型模式用于实现对大量数据的高速访问。通过减少满足可能针对主题区域进行的任何查询所需的连接数量，可以实现高性能。这是通过允许维度表中的数据冗余来完成的。
您必须记住，星型模式是仓库顶层的模式。所有模型还涉及仓库堆栈底部的暂存模式，有些还包括一个持久转换的合并暂存区域，其中所有源系统都合并到 3NF 建模模式中。各种主题领域位于此之上。
顶级星型模式的替代方案包括一种变体，即雪花模式。Dan Linstedt 提出的Data Vault Modeling也可能会进行一些调查。
于 2008-09-21T02:48:07.570 回答
7
关于星型模式的事情是，它们是大多数人想要用数据仓库做的事情的自然模型。例如，很容易生成具有不同粒度级别（例如月、日或年）的报告。将典型的业务数据插入星型模式也很有效，这也是数据仓库的一个常见且重要的特性。
您当然可以使用您想要的任何类型的数据库，但除非您非常了解您的业务领域，否则如果您使用星型模式，您的报告可能不会像它们那样有效地运行。
于 2008-09-21T02:25:28.140 回答
6
星型模式非常适合数据仓库的最后一层。你如何到达那里是另一个问题。据我所知，有两大阵营，比尔·英蒙和拉尔夫·金博尔的阵营。如果/当您决定选择明星时，您可能想看看这两个家伙的理论。
此外，一些报告工具非常喜欢星型模式设置。如果您被锁定在特定的报告工具中，那可能会推动报告集市在您的仓库中的样子。
于 2008-09-21T02:54:00.520 回答
4
星型模式是适合常规数据仓库需求的关系数据库的逻辑数据模型；如果给定了关系环境，星型或雪花模式将是一种很好的设计模式，在许多 DW 设计方法中都是硬连线的。
然而，除了关系数据库引擎之外，还有其他一些引擎，它们可以用于高效的数据仓库。多维存储引擎对于 OLAP 任务（例如 TM1）可能非常快；在这种情况下，我们不能应用星型模式设计。需要特殊逻辑模型的其他示例包括 XML 数据库或面向列的数据库（例如，实验性C 存储）。
于 2009-06-09T16:15:26.997 回答
3
没有它是可能的。但是，您会让自己的生活变得艰难——您的组织将希望使用位于 DW 之上的标准工具，并且这些工具将期望使用星型模式——将花费大量精力将方形钉子安装在圆形中洞。
许多数据库级优化假设您有一个星型模式；您将花费大量时间进行优化和重组，以使数据库使用您的非明星布局做“正确的事情”。
确保利大于弊。。
（听起来我以前去过那里吗？）
-D
于 2008-09-22T03:04:48.537 回答
2
我们需要解决三个问题。
1）如何通过连接它们内部和之间的表、在我们提取时清理数据、创建派生等来从操作源系统中获取数据而不给它们施加过度压力。
2) 如何将来自不同来源的数据——一些遗留的、一些基于文件的、来自不同部门的数据合并成一个完整的、准确的、有效存储的整体，对业务进行建模，并且不反映源系统的结构。请记住，系统更改/更换相对较快，但业务的基本模型变化缓慢。
3) 如何构建数据以满足业务中特定人员/部门的特定分析和报告要求，尽可能快速和准确。
这三个非常不同的问题的解决方案需要不同的架构层来解决它们
暂存层我们复制源的结构，但每晚只加载来自源的更改数据。一旦数据从暂存层进入下一层，数据就会被丢弃。查询是带有简单 data_time 过滤器的单表查询。对源的影响很小。
企业层 这是一个面向业务的第三范式数据库。数据从暂存层提取（然后丢弃）到企业层，在那里进行清理、集成和规范化。
表示（星型模式）层在这里，我们对维度进行建模以满足特定要求。数据被故意去规范化以减少连接的数量。在企业层中可能占用多个表的层次结构被折叠成单个维度表，并且多个事务表可以合并成单个事实表。
你总是面临这三个问题。如果选择去掉企业层，还是要解决第二个问题，但是必须在星型层做，在我看来，这是做错的地方。
于 2012-08-31T11:11:24.783 回答