星型模式devise
Star-Schemadevise对于数据仓库是不可或缺的吗？ 或者你可以用另一种devise模式来做数据仓库吗？
将星型模式用于数据仓库系统可以带来诸多好处，在大多数情况下，将它们用于顶层是合适的。 您也可能拥有一个运营数据存储（ODS） – 一个标准化的结构，可以保存“当前状态”，并且便于操作，如数据确认。 但是，在有些情况下，这是不可取的。 我有机会build立有ODS层和没有ODS层的系统，并且在每种情况下都有select架构的具体原因。
没有进入数据仓库体系结构的底层，或者开始Kimball vs. Inmon火焰战争，星型模式的主要优点是：
-
大多数数据库pipe理系统在查询优化器中都有设备来执行使用位图索引结构或索引交集来实现快速谓词parsing的“星形转换”。 这意味着从星型模式中进行select可以在命中表（通常比索引大得多）之前完成，直到解决select。
-
分割一个星型模式是相对简单的，因为只有事实表需要分区（除非你有一些圣经上的大尺寸）。 分区消除意味着查询优化器可以忽略不可能参与查询结果的分段，这节省了I / O。
-
在一个星型模式上， 缓慢变化的维度比雪花更容易实现。
-
模式更容易理解，并且往往涉及比雪花或ER模式更less的连接。 你的报告团队会为此而爱你
-
Star模式更容易使用，（更重要的是）可以使用诸如Business Objects或Report Builder之类的即席查询工具更好地执行。 作为开发人员，您几乎不能控制这些工具生成的SQL，所以您需要尽可能多地为查询优化器提供帮助。 星型模式使得查询优化器相对来说很less有错误的机会。
通常情况下，您的报告层将使用星型模式，除非您有特定的原因不要。 如果您有多个源系统，则可能需要使用规范化或雪花模式实施“ 操作数据存储”以累积数据。 这比较容易，因为ODS通常不会做历史。 历史状态在星型模式中进行追踪，这比规范化的结构要容易得多。 规范化或雪花化的操作数据存储体现了“当前”状态，并不具有数据固有的历史视图。
ODS加载过程涉及数据清理和符合性，这对于规范化的结构更容易实现。 一旦在ODS中有干净的数据，维度和事实负载就可以相对简单地使用通用或相对简单的机制来跟踪历史（随着时间的变化） 这对于星型模式来说要简单得多，许多ETL工具（例如）为缓慢变化的维度提供了内置的工具，并且实现一个通用的机制是相对简单的。
以这种方式分层系统提供了职责分离 – 在ODS中处理业务和数据清理逻辑，星形架构负载处理历史状态。
关于数据仓库文献中关于数据仓库架构应该应用星型架构devise的问题，目前还存在争议。
简而言之， Kimball主张非常高度的使用数据仓库中的Star-Schemadevise，而Inmon首先要使用规范化的3NFdevise构build企业数据仓库，然后在数据仓库中使用Star-Schemadevise。
另外在这里你也可以说雪花图案devise是另一种方法。
第四个devise可以是数据仓库build模方法。
星型模式用于高速访问大量数据。 通过减less所需的连接数量来实现高性能，从而可以针对主题区域进行查询。 这是通过在维度表中允许数据冗余来完成的。
您必须记住，星型模式是仓库顶层的模式。 所有模型还涉及在仓库堆栈的底部登台架构，还有一些还包括一个持久的变换合并登台区域，其中所有源系统都合并到一个3NFbuild模模式中。 不同的学科领域坐在这上面。
顶级星形模式的替代品包括变体，这是一个雪花模式。 Dan Linstedt提出的Data Vaultbuild模也是一种可能需要调查的新方法。
关于星型模式的事情是，他们是大多数人想要用数据仓库做的事情的天然模型。 例如，生成具有不同粒度级别（例如月份或date或年份）的报告很容易。 将典型业务数据插入星型模式也是有效的，这也是数据仓库的一个常见和重要的特性。
您当然可以使用任何types的数据库，但是除非您了解自己的业务领域，否则如果您使用了星型模式，您的报告可能无法高效运行。
星型模式非常适合数据仓库的最后一层。 你如何到达另一个问题。 据我所知，有两大阵营，比尔·伊蒙（Bill Inmon）和拉尔夫·金博尔（Ralph Kimball）。 如果/当你决定和一个明星一起去时，你可能想看看这两个人的理论。
此外，一些报告工具真的像星型架构设置。 如果您被locking到特定的报告工具，那么可能会推动仓库中报告集市的外观。
星型模式是适合常规数据仓库需求的关系型数据库的逻辑数据模型; 如果给定关系环境，星形或雪花模式将是一个很好的devise模式，在许多DWdevise方法中都是硬连线的。
然而除了关系数据库引擎之外，它们还可以用于高效的数据仓库。 多维存储引擎对于OLAP任务可能非常快（例如，TM1）。 在这种情况下，我们不能应用星型模式devise。 其他需要特殊逻辑模型的例子包括XML数据库或列式数据库（例如实验性C存储） ）。
有可能没有。 然而，你将会为自己付出生命 – 你的组织会希望使用生活在DW之上的标准工具，而这些工具将会期望一个星型模式 – 将花费大量精力在一个圆孔。
很多数据库级的优化假设你有一个星型模式; 你将花费大量的时间进行优化和重组，让你的数据库用你不太明显的布局来做“正确的事情”。
确保专业人员胜过..
（这听起来像我以前去过吗？）
-D
有三个问题需要解决。
1）如何从操作源系统中获取数据，而不会通过连接内部和表之间的表格来施加不当的压力，在我们提取时清理数据，创build派生等。
2）如何将来自不同来源的数据（来自不同部门的一些遗留文件，某些文件）合并为一个完整的，准确的，有效存储的整体，对业务进行build模，而不反映源系统的结构。 请记住，系统更换/更换速度较快，但业务的基本模式变化缓慢。
3）如何构build数据，以尽可能快速，准确地满足特定业务部门的特定分析和报告要求。
解决这三个非常不同的问题需要不同的架构层来解决它们
分段层我们复制源的结构，但每晚只加载来自源的已更改数据。 一旦数据从分段层进入下一层，数据就被丢弃。 查询是具有简单的data_timefilter的单表查询。 对来源影响很小。
企业层这是一个面向业务的第三范式数据库。 数据从分段层提取（并随后丢弃）到企业层，在那里进行清理，集成和规范化。
演示文稿（星型模式）图层在这里，我们对模型进行build模以满足特定要求。 数据是故意去规范化，以减less连接的数量。 可能在企业层中占据多个表的层次结构被折叠成单个维度表，并且多个事务表可以被合并到单个事实表中。
你总是面对这三个问题。 如果你select去掉企业层，你仍然需要解决第二个问题，但是你必须在星型模式层做，而且我认为这是错误的。
