感谢：这里的两个答案都非常有用，但我只能选一个。我非常感谢你的建议！
我们的数据仓库将比传统的分析报告更多地用于工作流程报告。我们的用户关心“当前图片”远远超过历史。 （虽然历史也很重要。）我们是一个没有成本或相关计算的政府实体。主要是指在给定地点和相关历史中的人数。
我们正在使用Oracle，我发现尽可能使用星型连接有明显的优势，并希望将所有内容重新架构为与我们的业务用途合理的星型模式非常相似。这个DW的速度至关重要，许多测试已经证明了我的星型模式方法。
我们的“人”表是关键 - 它包含超过400万条记录，并且将成为查询中最常用的来源。可以在具有多个维度的星形中心看到（如年龄，性别，从属关系，地点等）。这是一个非常长的表，特别是当我加入地址和联系信息时。
然而，当我们开始查看历史时，它更像是维度表。例如，有两个不同的历史表，其中一个人员键指向人员表。一个拥有超过2000万条记录，另一个拥有近5000万条记录并且每天都在增长。
此表是事实表还是维度表？一个人可以同时工作吗？如果是这样，那会是一个很大的性能问题吗？查询维度而非事实更常见吗？如果使用person表作为维度的DIFFERENT事实表实际上只有60,000条记录（小得多），会发生什么。
我认为我的问题是我们的数据及其使用不适合常用的星型模式示例。
澄清：下面添加了一些好的想法，但也许我留下了太多的东西来真正解释清楚。这里有更多信息：
我们处理一个选民数据库。我们没有任何措施，除了各种群体的选民统计：按党，年龄，地点选举的选民;选民按选票类型和选举，选票状态和选举等计算。我们有一个“投票历史”日志以及一个活动审计日志（更改地址，参与方等）。我们有关于哪些选民是选举工作者以及所有相关信息的信息。我想我以后会接触周边的东西。
目前我专注于我们的两个主要“业务流程”：选民登记（选民登记）和选举投票率。首先，选民是一个事实。在第二种情况下，选民是一个维度，以及党，选举和投票类型。 （如果有人担心 - 不，我们不知道人们如何投票。只是他们这样做.LOL）
我希望稍微澄清一下。
答案 0 :(得分：1)
如果可能的话，我的建议是重构这些表格，使它们更符合真正的星型模式。尽管有5000万条记录听起来很多（当考虑事务系统时），但我们有多个事实表，其中有多达5亿行。假设您的硬件用于此类工作，那么将表组合成一个大的事实表（假设它们都在同一主题区域内）应该没有任何问题。
说到这一点，请确保在考虑选择高度非规范化结构时应考虑的其他因素。由于必要连接的减少，星型模式是一种用于报告数据的出色设计，但是，在更新表和磁盘空间时，通常会为此付出很大代价。当您说您正在考虑将此架构用于更多工作流应用程序时，而不是主要是分析时，那么我会确保考虑更新。是否需要实时或接近实时更新？如果是这样，你可能不想再考虑明星了。
最后，是的，在某些情况下，我们只查询维度表，通常当应用程序需要特定的项目列表（即产品，客户等）时，这是一个有效的用途，但是，更好的解决方案可能会利用ODS而不是我们的星型模式。
我发现的就像我试图让我的模式看起来像Inmon或Kimball教科书中的东西一样，如果没有一些现实世界的优化，它几乎永远不会有效。
修改 我确实更加具体地提到了消耗臭氧层物质。
运营数据存储（或“ODS”）是一个数据库，旨在整合来自多个来源的数据，以便更轻松地进行分析和报告。由于数据源自多个源，因此集成通常涉及清理，解决冗余以及检查业务规则的完整性。 ODS通常被设计为包含具有有限历史的低级别或原子（不可分割）数据（例如交易和价格），这些数据是“实时”或“接近实时”捕获的，而不是存储在数据库中的大量数据。数据仓库通常不太频繁。
根据概念的创始人比尔·因蒙（Bill Inmon）的说法，消耗臭氧层物质是“面向主题的，综合的，不稳定的，当前价值的，仅限于详细的数据集合，以支持组织需要达到这一目标。第二，运营，综合，集体信息。“
ODS与Inmon对企业数据仓库的定义不同，它具有有限的历史记录，并且比EDW更频繁。在实践中，ODS倾向于更多地反映源结构，以加快实施并提供更真实的生产数据表示。
答案 1 :(得分：1)
大型“人”（客户）维度在电信，银行，保险等领域经常出现.Kimball在CRM章节（6）下有一个名为“大变化客户维度”的部分。它显示了如何创建“minidimensions”。经常更改或经常分析的属性（列）被分解为单独的小维度表。这些迷你维度通过事实表连接，因此事实表分别为每个表格都有一个FK。
在我看来，你的例子接近于此。
作为一般规则，维度表是一个查找表，用于很少更改的对象（人员，帐户，时间，产品，商店）和事实表捕获这些对象之间交互的活动（历史记录）。事实表包含您希望汇总的度量（总销售额，工作小时数，生产的零件数量等）。
澄清后：
我会说Voter实际上是一个一致的维度 - 对所有数据集市（业务流程）都是通用的。其他一致的维度将是：日期，党，选举，投票站。小尺寸将是人口统计和地理区域。
事实表将是：RegistrationEvent（谁在何时何地注册）和ElectionEvent（谁在何时何地投票选举，使用什么）。
Dimension Voter和事实RegistrationEvent从操作系统加载，捕获选民登记和其他更改
这是简化的，但我希望它能抓住基本的想法。
答案 2 :(得分：1)
好的 - 这不是一个完整的“答案”，但它已经接近了。
请注意这篇描述Kimball讲座的博客文章： http://database-geek.com/2005/03/28/a-day-with-ralph-kimball-part-2/
我正在努力的原因是这是一个“退化”的维度。我的选民登记和相关信息与我的“登记”事实表是一对一的。所以看起来Kimball甚至可以把它扔进事实表中。
所以现在我只是在研究当另一个事实表使用事实表时会发生什么。
编辑：此外，我发现谷歌搜索“怪物维度”一词非常有帮助。这很像一个缓慢变化的客户维度。只要我愿意雪花，我就可以实现我所需要的 - 在查询选民时明星加入，并且不会导致使用选民作为各种事实表的维度的问题。编辑： 以下是我的最终结论：如上所述，重点是促进业务流程，而不是适合教科书图。
我们的业务是这样的，绝对没有理由拆分选民表（有“注册”的事实表和“选民”的维度） - 当查询该表时我们也会想要所有的属性作为所有标志和文本信息。我不想将这些属性单独分解为“事实”（就像Kimball的书籍显示给客户和订单），因为这些属性在附加到事实时意味着与它们附加到维度时不同的东西。此外，选民被用作多个其他地方的属性，其中一些适合传统的明星。
我的主要目的是SPEED。所以我选择了一种修改后的格式 - 很像雪花 - 其中选民是多个表的中心，当我将所有内容编入索引时，oracle可以使用星形连接。然后，我在所有其他“明星”中使用选民作为维度。在每种情况下，我都进行了设置，以便即使不是所有的表都可以使用星型连接进行连接，即使它不是“教科书”。
再次感谢您的帮助！