我在这里遇到了以前从未遇到过的情况。
我有同一个 ERP 系统的多个实例，因卫星区域设置而异。每个语言环境都分配有自己的 ID。
在每个卫星位置内，数据库模式与其他模式、相同的表、相同的值相同。
当组合来自这些语言环境中的两个或更多的表时，比如说部分，它们的自然操作键将是相同的，但附加的属性数据可能不同。由于我需要能够链接到一个部件，基于它来自哪个卫星区域设置，我想我需要一个复合键 - 部件 ID 和卫星 ID。
现在这对于这个单一维度来说是可以的，但是，这个卫星 ID 在许多其他维度的其他地方以相同的方式使用。它也是许多事实表的主要切片器。
我应该如何对待这个属性？把它放在它自己的维度里，雪花呢？或者将值推入每个维度（重复），然后让事实表将唯一的 FK 保存到卫星维度？
在理想的世界中，解决方案是在 ETL 过程Natural Operational Keys中用每个 PartID/SatelliteID 唯一的代理键替换（例如，对于处于相同情况的每个维度，我确实怀疑您的时间维度可以跳过代理键）。
当然，这不仅需要在维度表中添加此代理键，还需要为事实表添加此代理键。
如果您需要通过 Satellite 报告，Satellite ID 列也将作为单独的维度显示。
这将是一个理想的解决方案。
一个快速而肮脏的解决方案可能是您建议在自然键旁边添加一个带有卫星 ID 的附加列，您需要为每个维度（同样除了时间维度）和事实表添加此列。然后，您需要在每次加入时都包含 Satellite ID 列。
在这种情况下，在您的报告工具中，您需要将卫星 ID 作为复合 ID 的一部分，由自然操作密钥和卫星 ID 组成。
您还可以创建一个特定的卫星维度，您可以使用它来为特定的卫星选择数据。