3

谢谢：这里的两个答案都非常有帮助，但我只能选择一个。我非常感谢您的建议！

我们的数据仓库将比传统的分析报告更多地用于工作流报告。我们的用户更关心“当前情况”而不是历史。（尽管历史也很重要。）我们是一个没有成本或相关计算的政府实体。大多只是给定位置内和具有相关历史的人数。

我们正在使用 Oracle，我发现尽可能使用星型连接具有明显的优势，并且希望将所有内容重新架构为与我们的业务使用合理的星型模式非常相似。这个 DW 中的速度至关重要，许多测试已经向我证明了星型模式方法。

我们的“person”表是关键——它包含超过 400 万条记录，将是查询中最常用的来源。 它可以在具有多个维度（如年龄、性别、隶属关系、位置等）的恒星中心看到。这是一个很长的表，特别是当我将它加入地址和联系信息时。

但是，当我们开始查看历史时，它更像是一个维度表。例如，有两个不同的历史记录表，其人员键指向人员表。一个拥有超过 2000 万条记录，另一个拥有近 5000 万条记录，并且每天都在增长。

这个表是事实表还是维度表？一个可以同时工作吗？如果是这样，那会是一个很大的性能问题吗？查询更多维度而不是事实是否很常见？如果使用 person 表作为维度的 DIFFERENT 事实表实际上只有 60,000 条记录（小得多），会发生什么情况。

我认为我的问题是我们的数据及其使用不符合星型模式的常用示例。

澄清： 下面添加了一些好的想法，但也许我遗漏了太多，无法很好地解释。这里有更多信息：

我们处理选民数据库。除了按不同群体统计选民人数外，我们没有任何措施：按政党、按年龄、按地点统计选民人数；按选票类型和选举、选票状态和选举等统计选民人数。我们确实有“投票历史”日志以及活动审计日志（地址变更、政党等）。我们有关于哪些选民是选举工作人员的信息以及所有相关信息。我想我稍后会谈到外围的东西。

现在我专注于我们的两个主要“业务流程”：选民登记（即选民）和选举投票率。首先，选民是事实。其次，选民是一个维度，还有政党、选举和选票类型。（如果有人担心 - 不，我们不知道人们如何投票。只是他们这样做。哈哈）

我希望这能澄清一点。

4

3 回答 3

1

如果可能的话，我的建议是重构这些表，使它们更符合真正的星型模式。尽管 5000 万条记录听起来很多（考虑事务系统时），但我们有多个事实表，其中包含多达 5 亿行。假设您的硬件是为这种类型的工作指定的，那么将您的表组合成一个大的事实表应该没有任何问题（假设它们都在同一个主题领域内）。

话虽如此，请确保您考虑了在选择高度非规范化结构时应考虑的其他因素。由于减少了必要的连接，星型模式是报告数据的绝佳设计，但是，在更新表和磁盘空间时，您通常会为此付出高昂的代价。当您说您正在考虑将此模式用于更多的工作流应用程序，而不是主要用于分析时，那么我会确保考虑到更新。需要实时更新还是接近实时更新？如果是这样，你可能不想再考虑明星了。

最后，是的，在某些情况下，我们只查询我们的维度表，通常当应用程序需要特定的项目列表（即产品、客户等）时，这是一种有效的用途，但是，更好的解决方案可能会利用 ODS 而不是我们的星型模式。

我的发现就像我试图让我的模式看起来像 Inmon 或 Kimball 教科书中的东西一样，如果没有一些现实世界的定制，它几乎永远不会起作用。

编辑 我肯定对 ODS 的引用更加具体。

操作数据存储（或“ODS”）是一种数据库，旨在整合来自多个来源的数据，以使分析和报告更容易。由于数据来自多个来源，因此集成通常涉及清理、解决冗余和检查业务规则的完整性。ODS 通常设计为包含具有有限历史的低级别或原子（不可分割）数据（例如交易和价格），这些数据是“实时”或“近乎实时”捕获的，而不是存储在数据库中的大量数据。数据仓库通常不那么频繁。

根据该概念的创始人比尔·英蒙 (Bill Inmon) 的说法，ODS 是“一个面向主题的、集成的、易变的、当前价值的、仅详细的数据集合，以支持组织对最新、可操作的需求。 、综合的、集体的信息。”

ODS 与 Inmon 对企业数据仓库的定义不同，它具有有限的历史，并且比 EDW 更频繁地更新。在实践中，ODS 往往更能反映源结构，以加快实施并提供更真实的生产数据表示。

http://en.wikipedia.org/wiki/Operational_data_store

于 2009-10-28T16:25:24.693 回答
1

大型“人”（客户）维度在电信、银行、保险等领域很常见。Kimball 在 CRM 章节 (6) 下有一个名为“大型变化的客户维度”的部分。它展示了如何创建“小尺寸”。经常更改或经常分析的属性（列）被分成单独的小维度表。这些小维度通过事实表连接，因此事实表为这些表中的每一个分别提供了一个 FK。

在我看来，您的示例与此接近。

作为一般规则，维度表是很少更改的对象（人员、帐户、时间、产品、商店）的查找表，事实表捕获这些对象之间交互的活动（历史）。事实表包含您想要汇总的度量（总销售额、工作小时数、生产的零件数量等）。

澄清后：
我想说 Voter 实际上是一个一致的维度——对于所有数据集市（业务流程）来说都是通用的。其他符合标准的维度是：日期、派对、选举、投票站。小维度将是 Demographic 和 GeoArea。事实表将是：RegistrationEvent（谁在何时何地注册）和 ElectionEvent（谁何时何地在哪个选举中投票，使用什么）。
Dimension Voter 和 fact RegistrationEvent 从捕获选民登记和其他变化的操作系统加载。
这是简化的，但我希望它能抓住基本思想。

于 2009-10-28T17:03:06.600 回答
1

好的 - 这不是一个完整的“答案”，但它很接近。

请注意这个描述 Kimball 讲座的博客条目：http: //database-geek.com/2005/03/28/a-day-with-ralph-kimball-part-2/

我挣扎的原因是这是一个“退化”的维度。我的选民 regnum 和相关信息与我的“登记”事实表是一对一的。因此，Kimball 似乎可以将其放入事实表中。

所以现在我只是研究当一个事实表被另一个事实表使用时会发生什么。

编辑：另外，我发现谷歌搜索“怪物维度”这个词非常有帮助。这很像一个缓慢变化的客户维度。只要我愿意雪花，就可以实现我所需要的——查询voter的时候加入star join，并且不造成使用voter作为各种事实表的维度的问题。

编辑：这是我的最终结论：如上所述，重点是促进业务流程，而不是符合教科书的图表。

我们的业务是这样的，绝对没有理由拆分选民表（有一个用于“注册”的事实表和一个用于“选民”的维度） - 当使用该表进行查询时，我们将需要所有属性以及所有标志和文本信息。我不想将属性单独分解为“事实”（如 Kimball 为客户和订单展示的书籍），因为这些属性在附加到事实时与附加到维度时的含义不同。此外，选民在其他多个地方被用作属性，其中一些确实适合传统明星。

我的主要目的是速度。所以我选择了一种修改后的格式——很像雪花——选民是多个表的中心，当我正确索引所有内容时，oracle 可以使用星型连接。然后，我使用选民作为我所有其他“明星”的维度。在每种情况下，我都进行了设置，这样即使不是“教科书”，也可以使用星形连接来连接大多数表（如果不是所有表）。

再次感谢您的帮助！

于 2009-10-28T20:48:24.393 回答