感谢:这里的两个答案都非常有帮助，但我只能选择一个。非常感谢您的建议!
与传统的分析报告相比，我们的数据仓库将更多地用于工作流报告。我们的用户关心“当前图片”远甚于历史。 (尽管历史也很重要。)我们是一个没有成本或相关计算的政府实体。大多数情况下只是统计给定地点内和具有相关历史记录的人数。
我们正在使用 Oracle，并且我发现尽可能使用星型连接具有明显的优势，并且希望将所有内容重新架构为尽可能接近星型模式，这对于我们的业务用途是合理的。此 DW 中的速度至关重要，许多测试已经向我证明了星型模式方法。
我们的“人”表是关键 - 它包含超过 400 万条记录并将成为查询中最常用的来源。它可以在具有多个维度的星形中心看到(例如年龄、性别、从属关系、地点等)。这是一个非常长的表格，尤其是当我将其加入地址和联系信息时。
然而，当我们开始看历史时，它更像是一个维表。例如，有两个不同的历史表，它们有一个指向 person 表的 person 键。一个拥有超过 2000 万条记录，另一个拥有近 5000 万条记录并且每天都在增长。
这张表是事实表还是维度表？一个可以同时工作吗？如果是这样，那会是一个大的性能问题吗？查询更多维度而不是事实是否很常见？如果使用人员表作为维度的不同事实表实际上只有 60,000 条记录(小得多)，会发生什么情况。
我认为我的问题是我们的数据及其使用不符合星型模式的常用示例。
澄清:下面添加了一些不错的想法，但也许我遗漏了太多内容，无法真正解释清楚。这里有更多信息:
我们处理选民数据库。除了按不同群体统计选民人数外，我们没有任何其他措施:按党派、按年龄、按地点统计选民人数；选民按选票类型和选举、选票状态和选举等进行计数。我们确实有一个“投票历史”日志以及一个事件审计日志(地址变更、政党等)。我们有关于哪些选民是选举工作人员的信息以及所有相关信息。我想我稍后会谈到外围的东西。
现在我主要关注我们的两个主要“业务流程”:选民登记(即选民。)和选举投票率。首先，选民是事实。在第二个维度中，选民是一个维度，还有政党、选举和选票类型。 (如果有人担心 - 不，我们不知道人们如何投票。只是他们这样做。大声笑)
我希望这能澄清一些事情。
最佳答案
如果可能，我的建议是重构这些表，使它们更符合真正的星型模式。虽然 5000 万条记录听起来很多(在考虑事务系统时)，但我们有多个事实表，其中包含多达 5 亿行。假设您的硬件是为此类工作指定的，那么将您的表组合成一个大型事实表应该不会有任何问题(假设它们都在同一主题领域内)。
话虽如此，请确保您考虑了在选择高度非规范化结构时应考虑的其他因素。由于减少了必要的连接，星型模式是一种用于报告数据的出色设计，但是，在更新表和磁盘空间时，您通常为此付出高昂的代价。当您说您正在考虑将此模式用于更多的工作流应用程序，而不是主要用于分析时，那么我会确保考虑到更新。需要实时更新还是接近实时更新？如果是这样，您可能又不想考虑星级。
最后，是的，在某些情况下我们只查询我们的维度表，通常当应用程序需要特定的项目列表(即产品、客户等)时，这是一种有效的使用，但是，更好的解决方案可能会利用ODS 而不是我们的星型模式。
我发现，尽管我试图让我的模式看起来像 Inmon 或 Kimball 教科书中的东西，但如果没有一些真实世界的定制，它几乎永远不会起作用。
编辑 我确实在提到 ODS 时更加具体。
运营数据存储(或“ODS”)是一种数据库，旨在集成来自多个来源的数据，以便更轻松地进行分析和报告。由于数据来自多个来源，因此集成通常涉及清理、解决冗余以及根据业务规则检查完整性。 ODS 通常设计为包含低级或原子(不可分割的)数据(例如交易和价格)，这些数据具有有限的历史记录，这些数据是“实时”或“接近实时”捕获的，而不是存储在 ODS 中的大量数据。数据仓库通常不太频繁。
根据该概念的创始人 Bill Inmon 的说法，ODS 是“一个面向主题的、集成的、易变的、当前值的、仅详细的数据集合，以支持组织对最新信息的需求第二，可操作的、综合的、集体的信息。”
ODS 与 Inmon 对企业数据仓库的定义不同，它的历史有限，更新频率高于 EDW。在实践中，ODS 往往更能反射(reflect)源结构，以加快实现速度并提供更真实的生产数据表示。
关于Oracle 数据仓库设计——充当维度的事实表？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1638076/