我正在研究金融数据集市结构。而且我对这样做的更好方法有一些疑问。源系统数据库 Dynamics AX 2009 具有三个用于客户交易的表。一张用于未结交易的表，客户仍需要为服务/产品付费；一张用于结算交易的表，其中保存着客户已经支付的款项；最后是一个包含所有客户交易的表，包含从开放到结算的交易以及作为客户到银行或分类账账户的其他交易。
我想到了两个选项，首先我将维护一个代表三个表的事实表，即未结交易的事实、任何客户交易的事实和结算交易的事实。其次是创建一个事实来保存所有事务，为此我必须对三个表进行完全连接。我不确定这两种方法，因为第一种方法似乎是从生产中复制表并创建正确的维度。在第二个中，我将创建一个庞大的事实表，其中数据会不断变化，因为开放事务在结算时会在源系统上被删除。
另一个疑问，我是否应该使用 scd（缓慢变化的维度）结构创建一个事实来维护历史数据？（开始日期、结束日期、标志）
从给出的信息很难说这是否需要一个或多个事实表。但是，您应该用来决定的关键点是所有信息是否都处于相同的粒度。考虑你想要的事实表的粒度，你应该找到一个答案，你需要一个表还是多个表。
如果所有信息都处于相同的粒度——即所有相同的维度适用于您考虑放入同一个事实表的所有度量——那么它们可能都存在于同一个事实表中。如果您发现某些维度不适用于某些度量，那么您可能需要重新考虑您的设计。您可能需要多个事实表，或者您可能需要将所有度量降低到最低粒度并将层次结构组合成单个维度（如果您当前将它们拆分为多个维度）。
虽然有人提到在单独的多维数据集中进行度量可能会使比较事物变得困难，但请记住，每个事实表不需要一个多维数据集。您可以在单个多维数据集中拥有多个 Fact 表，有时这在您需要能够比较共享某些维度但不共享其他维度的度量时非常有用。这比将不同粒度的数据强制放入一个 Fact 表要好得多。
此外，听起来您要建模的是组织的销售分类帐。我建议通过 Google 进行挖掘，因为您很可能能够找到讨论销售分类帐结构的维度数据仓库设计的材料，而不是重新发明轮子。如果您对您尝试建模的会计概念没有充分的理解，我特别建议您寻找一个参考架构来工作，或者在阅读会计概念（特别是销售分类账）时失败。了解帐户结构应该可以帮助您了解事实表的粒度需要是什么，如何对维度进行建模等等。
这是 Kimball 建模技术的一个非常有用的精简版，其中讨论了颗粒、不同类型的事实表以及许多其他主题：
我认为您应该只使用一个事实表（一个多维数据集）并使用一个维度来区分打开/结算/等。交易。这就是维度的用途：它们帮助您对度量进行分类并获得对它们的特定视图。这种方法还将打开更多使用立方体创建知识的可能性。带有用于打开/结算/等的单独立方体。交易时，将这些数据进行对比将更难或不可能。
由于数据不断变化，您应该考虑在给定时间内更新事实表，并在需要时重建您的多维数据集。
是否使用 scd 实际上取决于您处理的数据及其用途。是否有商业案例声称它？有技术用途吗？我认为这是您必须自己决定的事情。