我在这里遇到了以前从未遇到过的情况。
我有同一个 ERP 系统的多个实例，因卫星区域而异。
每个语言环境都分配有自己的 ID。
在每个卫星位置内，DB 模式与其他模式相同，表相同，值相同。
当组合来自两个或多个这些语言环境的表时，比如部件，它们的自然操作键将相同，但附加属性数据可能不同。因为我需要能够链接到一个部件，根据它来自哪个卫星区域，我想我在这里需要一个复合键 - 部件 ID 和卫星 ID。
现在这对于这个单一维度来说很好，但是，这个卫星 ID 在许多其他维度的其他地方以相同的方式使用。它也是许多事实表的主要切片器。
我应该如何对待这个属性？把它放在自己的维度，雪花？或者将值插入每个维度(重复)，然后让事实表将唯一的 FK 保存到卫星维度？
最佳答案
在理想的世界中，解决方案是在 ETL 过程中用代理键替换 Natural Operational Keys，这些代理键对于每个 PartID/SatelliteID(以及处于相同情况的每个维度，例如我怀疑时间维度您可以跳过代理键)。
当然，这不仅需要在维度表中添加此代理键，还需要在事实表中添加此代理键。
如果您需要按卫星报告，卫星 ID 列也将作为单独的维度出现。
这将是一个理想的解决方案。
一个快速而肮脏的解决方案可能是您建议在自然键旁边添加一个带有卫星 ID 的附加列，您需要为每个维度(同样除了时间维度)和事实表添加此列。然后您需要在每次加入时包括卫星 ID 列。
在这种情况下，在您的报告工具中，您需要将卫星 ID 作为复合 ID 的一部分，由自然操作 key 和卫星 ID 组成。
您还可以创建一个特定的卫星维度，您可以使用它来选择特定卫星的数据。
关于data-warehouse - 维度建模 - 用于各种维度复合键的通用属性，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/28071464/