星型模式设计

Question

星型模式设计对于数据仓库至关重要吗？或者你可以用另一种设计模式来做数据仓库吗？

Answer 1

将star schemas用于数据仓库系统可以带来诸多好处，在大多数情况下，将它们用于顶层是合适的。您也可能拥有一个运营数据存储（ODS） - 一种标准化的结构，可保存“当前状态”并便于操作，如数据确认。但是，在有些情况下，这是不可取的。我曾经有机会构建带有或不带有ODS层的系统，并且在每种情况下都有选择架构的具体原因。

没有进入数据仓库架构的subtlties或开始博尔与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工具（例如）提供了用于缓慢变化维度的内置工具，并且实现通用机制相对简单。

分层这样的系统providies职责的分离 - 业务和数据清理逻辑在ODS处理和星型模型的负载处理历史状态。

Answer 2

关于星型模式的事情是，他们是这样的东西大多数人都希望有一个数据仓库做一个自然的模型。例如，生成具有不同粒度级别（例如月份或日期或年份）的报告很容易。将典型的业务数据插入星型模式也是有效的，这也是数据仓库的一个常见且重要的特性。

你当然可以用任何一种你想要的，但除非你知道你的业务领域非常好，很可能您的报表将不能有效，因为他们可以，如果你用了一个星型模式运行的数据库。

Answer 3

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

您必须记住，星型模式是仓库顶层的模式。所有模型还涉及在仓库堆栈底部登台架构，还有一些还包括一个持久变换的合并登台区域，其中所有源系统都合并到3NF建模架构中。各个主题领域都位于此之上。

顶级模式的替代方案包括一个变体，这是一个雪花模式。 Dan Linstedt提出的一种新方法也可以进行一些调查。

Answer 4

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

此外，一些报告工具非常喜欢星型架构设置。如果您被锁定到特定的报告工具，那么这可能会推动仓库中报告集市的外观。

Answer 5

可能没有。然而，你会为自己付出生命 - 你的组织会希望使用生活在DW之上的标准工具，并且这些工具会期望一个星型模式 - 将花费大量精力在一轮中安装一个方形栓钉孔。

许多数据库级别的优化假设您有一个星型模式;您将花费大量的时间进行优化和重组，以便让数据库以您不太明朗的布局来做“正确的事情”。

确保利大于弊..

（听起来是不是像我以前去过那里？）

-D

Answer 6

星型模式是关系一个逻辑数据模型符合常规数据仓库需求的数据库;如果给出了关系环境，则星型或雪花型架构将成为一种很好的设计模式，在许多DW设计方法中都是硬连线的。

然而有比关系型数据库引擎等过了，他们可用于高效的数据仓库。多维存储引擎对于OLAP任务可能非常快（例如，TM1）;我们不能在这种情况下应用星型模式设计。其他需要特殊逻辑模型的例子包括XML数据库或列式数据库（例如实验C-store)）。

Answer 7

有一个在datawarehousing litterature正在进行的辩论有关其中在数据仓库架构的Star-Schema设计应适用。

总之Kimball倡导者非常高仅使用在数据仓库的星型模式设计，同时Inmon首先要建立使用normalized 3NF设计企业数据仓库，后来使用星型模式设计的数据集市。

另外在这里你也可以说Snowflake schema design是另一种方法。

第四种设计可能是Data Vault Modeling的方法。

Answer 8

我们需要解决三个问题。

1）如何获得数据输出的操作源系统的不施压，它们由内和它们之间的连接表，清洗数据作为我们提取，创建派生等

2）如何合并来自不同来源的数据 - 来自不同部门的一些遗留文件，基于文件的文件，形成一个完整的，准确的，高效存储的整体，用于对业务进行建模，而不反映源系统的结构。请记住，系统更换/更换速度相对较快，但业务的基本模式变化缓慢。

3）如何构建数据以尽可能快速和准确地满足特定业务部门的特定分析和报告要求。

解决这三个非常不同的问题需要不同的体系结构层来解决这些问题

临时层 我们复制的来源结构，而只是改变了从源数据每天晚上被加载。一旦数据从暂存层进入下一层，数据就会被丢弃。查询是带有简单数据时间过滤器的单表查询。对来源影响很小。

企业层 这是一个面向业务的第三范式数据库。数据从分段层提取（并随后丢弃）到企业层，在那里进行清理，集成和规范化。

演示文稿（星型模式）图层 在这里，我们用尺寸模型来满足特定要求。数据有意解除标准化以减少连接数量。可能在企业层中占用多个表的层次结构会折叠为单个维度表，并且多个事务表可能会合并到单个事实表中。

你总是面对这三个问题。如果您选择取消企业层，您仍然需要解决第二个问题，但是您必须在星型模式层中执行此操作，并且在我看来，这是做错的地方。