Star-Schema设计对数据仓库是否必不可少？或者您可以使用其他设计模式进行数据仓库吗？
答案 0 :(得分：94)
将star schemas用于数据仓库系统可以获得多种好处，在大多数情况下，将它们用于顶层是合适的。您可能还有一个操作数据存储（ODS） - 一种保持“当前状态”的标准化结构，并促进数据构造等操作。然而，在合理的情况下，这是不可取的。我有机会建立有和没有ODS层的系统，并且在每种情况下都有选择架构的具体原因。
不进入数据仓库架构的细分或启动Kimball vs. 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中处理，星型模式加载处理历史状态。
答案 1 :(得分：9)
关于 在数据仓库架构中应该应用Star-Schema设计的数据仓库文献中一直存在争论。
简而言之，Kimball主张在数据仓库中仅使用Star-Schema设计，而Inmon首先想要使用normalized 3NF设计构建Enterprise Datawarehouse，然后使用Star -schema设计在数据集市中。
此外，您还可以说Snowflake schema design是另一种方法。
第四种设计可能是Data Vault Modeling方法。
答案 2 :(得分：8)
星型模式用于实现对大量数据的高速访问。通过减少对可能针对主题区域进行的任何查询进行饱和所需的连接量来实现高性能。这是通过在维度表中允许数据冗余来完成的。
您必须记住，星型模式是仓库顶层的模式。所有模型还涉及仓库堆栈底部的暂存模式，还有一些模型还包括持久转换的合并暂存区域，其中所有源系统都合并到3NF建模模式中。各个主题领域都在此之上。
顶级星型模式的替代方案包括变体，即雪花模式。 Dan Linstedt提出了Data Vault Modelling提出的一种可能会进行一些调查的新方法。
答案 3 :(得分：7)
关于星型模式的事情是它们是大多数人想要用数据仓库做的事情的自然模型。例如，很容易生成具有不同粒度级别的报告（例如，月份或日期或年份）。将典型业务数据插入星型模式也很有效，这也是数据仓库的一个常见且重要的特性。
您当然可以使用您想要的任何类型的数据库，但除非您非常了解您的业务领域，否则您的报告可能无法像使用星型模式那样高效运行。
答案 4 :(得分：6)
星型模式非常适合数据仓库的最后一层。你是如何到达那里的另一个问题。据我所知，有两个大阵营，比尔英森和拉尔夫金博尔。如果/当你决定选择明星时，你可能想看看这两个人的理论。
此外，一些报告工具非常喜欢星型模式设置。如果您被锁定在特定的报告工具中，那么这可能会推动报告市场在您的仓库中的样子。
答案 5 :(得分：4)
星型模式是适合常规数据仓库需求的关系数据库的逻辑数据模型;如果给出了关系环境，那么星形或雪花模式将是一个很好的设计模式，在许多DW设计方法中都是硬连线的。
然而，除了关系数据库引擎之外，它们还可以用于高效的数据仓库。对于OLAP任务，多维存储引擎可能非常快（例如TM1）;在这种情况下，我们无法应用星型模式设计。需要特殊逻辑模型的其他示例包括XML数据库或面向列的数据库（例如，实验C-store)）。
答案 6 :(得分：3)
有可能没有。但是，您将为自己的生活变得艰难 - 您的组织将希望使用生活在DW之上的标准工具，并且这些工具将期望一个星型模式 - 将花费大量精力来安装一个方形的钉子孔。
许多数据库级优化都假设您有一个星型模式;你将花费大量时间进行优化和重组，让数据库用你不太明星的布局做“正确的事情”。
确保优点胜过缺点..
（听起来我以前去过那里吗？）
-D
答案 7 :(得分：1)
我们需要解决三个问题。
1）如何将数据从操作源系统中取出而不会对它们施加不必要的压力，方法是在它们之间和之间连接表，在我们提取时清理数据，创建派生等。
2）如何将来自不同来源的数据 - 一些遗留的，一些基于文件的，来自不同部门的数据合并为一个整体的，准确的，有效存储的整体，为业务建模，而不反映源系统的结构。请记住，系统更换/更换相对较快，但业务的基本模型变化缓慢。
3）如何快速准确地构建数据以满足业务中特定人员/部门的特定分析和报告要求。
解决这三个非常不同的问题需要不同的架构层来解决它们
分段图层 我们复制了源的结构，但每晚只加载来自源的更改数据。一旦数据从暂存层进入下一层，数据就会被丢弃。查询是具有简单data_time过滤器的单表查询。对来源的影响很小。
企业层 这是面向业务的第三范式数据库。数据从暂存层提取（然后丢弃）到企业层，在那里进行清理，集成和规范化。
演示文稿（星型模式）图层 在这里，我们通过尺寸模型来满足特定要求。故意将数据去标准化以减少连接数。可能占用企业层中多个表的层次结构将折叠为单个维度表，并且可以将多个事务表合并为单个事实表。
你总是面临这三个问题。如果您选择取消企业层，您仍然需要解决第二个问题，但您必须在星型模式层中执行此操作，而在我看来，这是一个错误的地方。