我的问题是：
业务逻辑是否应该存储在数据仓库数据存储中？还是应该只存在于报告应用程序中？
举一个更具体的例子：
在 CRM 操作系统中，存在线索和机会、线索状态和机会阶段的抽象概念。这些概念非常常见，很好理解，并在不同的 CRM 工具中使用。
业务用户可以合法地提出问题，例如，从“原始潜在客户”状态到“内部销售合格潜在客户”状态的所有潜在客户的转化率是多少。
那么对于数据仓库设计者来说，问题就变成了： 1. 当有人在调用后将潜在客户状态从 x 更改为 y 时，那应该是某处事实表中的一行吗？（可能与调用在同一行）如果是，那么我们在事实表中存储抽象的业务概念，而不仅仅是现实世界的事件。2. 更大的问题是，数据仓库是否应该知道“潜在客户”和“机会”之类的术语？如果是—— 2. 事实表是否应该有 old_status 和 new_status 列？3. 或者，状态变化是否应该作为一个缓慢变化的维度来处理？
如果业务逻辑直接存储在数据仓库中，很多业务问题就会变得更容易提出。（引导状态转换指标、机会阶段推进速度指标等）但它似乎更易变化，实施起来更复杂，并且可能会污染“动词是事实，名词是维度”的范式。
我应该如何处理这个设计，这里的最佳实践和指导原则是什么？
最大限度
我的回答是肯定的——你应该将业务逻辑存储在数据仓库中。这首先是数据仓库的想法之一。如果您有数十份报告显示或过滤潜在客户，想象一下将某人定为潜在客户的规则是否会发生变化。此外，如果您必须使用不同的工具/系统访问 DWH 数据怎么办 - 您需要复制所有逻辑。最后，计算这种标签可能很耗时，这就是为什么您希望在 DWH 中预先计算所有内容以使报告快速运行。
要回答您的第一个问题 - 是的，您应该选择 SCD。有几种方法，您应该选择最适合您要求的方法 - 这完全取决于用户想要如何分析数据（这是设计应该开始的地方。
我的方法一直是在数据库层中存储尽可能多的业务逻辑。这样做的原因是，如果您更改报告层，那么您需要重写所有业务规则。您更有可能更改报告层，而不是数据库层，因为这是您的部门看到的，而不是数据库。此外，我看到许多公司使用多种不同的 BI 报告解决方案，这意味着数据库是唯一可以存储规则而无需重复它们的地方。当我在这里谈论数据库层时，我也指的是多维数据集。