数据仓库设计 - 多个查找值答案

【问题标题】：Data warehouse design - Multiple lookup values数据仓库设计 - 多个查找值
【发布时间】：2018-07-18 07:35:09
【问题描述】：

寻找有关数据仓库架构设计的输入。这是场景：

我有一个当前基于 UserId 加入的操作表和用户表，以获取有关执行操作的用户的详细信息。

Action Table:
    UserId   Action
    123      Test001

User Table:
    UserId    UserName
    123       Adam

现在，我们必须将用户迁移到新的用户管理系统 (UMS)，它的工作原理如下：

现有用户将迁移到 UMS 并分配新的 UserId（我们称其为 Modern UserId，现有 UserId 为 Legacy UserId）。因此，为新操作传入的新记录将携带新的 UserId。
在 UMS 中创建的新用户将只有 Modern UserId，而 Legacy UserId 将运行。
迁移的用户将同时拥有 Legacy UserId 和 Modern UserId。

现在，当我们进行报告时，我们必须公开历史数据和新操作数据。想知道理想的架构设计应该是什么，以便我们可以报告历史和新操作并将它们映射到正确的用户。

平台：SQL Server 2016、分析服务

如果您需要更多详细信息，请告诉我。

【问题讨论】：

有关用户 ID 迁移的详细信息会很有用，如果您可以使用映射表，或者如果您可以更改架构以在新表中为旧版用户 ID 添加一列，技术细节将被清除.听起来你有一个映射，但我不确定你的数字 2，这个过程是如何工作的，表中的 legacyid 是否有空间，或者这将是一个辅助过程
我的上游正在进行迁移，所以我没有更多详细信息。但是，我可以灵活地更改操作表和用户表的模式，并在我们的 ETL 过程中根据需要执行任何查找。目前没有映射表，但我想避免映射表，看看我们是否可以在 Action 表和 User 表上添加像 UniqueAgentId 这样的列，以便可以在该单个列上完成连接，但不确定这是否是最好的方法在实施、维护和性能方面。
这只是另一个提供另一个属性的源系统 - 向 User 表添加另一个列。您需要在某处进行某种映射才能知道将其附加到哪个记录
谢谢尼克。我想避免另一个 JOIN 所以有没有我可以在不使用映射表的情况下采取的方法。
数据库中充满了连接。没有映射表的系统之间的id怎么匹配？

标签： sql-server data-warehouse star-schema schema-design

【解决方案1】：

您没有向我们提供有关如何完成此操作的详细信息的任何其他信息，因此sql-server 标记在这里并不能真正帮助我们。这更像是一个建模问题。

当您谈到列的新 id 时，必须在创建所述密钥期间采取某种方式来确保完整性，该过程将在某种程度上决定您必须提供解决方案的方法。

用户表看起来是一个具有唯一值的表，并且创建了“现代密钥”的创建位置，如果您可以编辑此表，则应在此处添加“旧密钥”。这将成为您的映射表，映射表不必是单独的对象。

【讨论】：

同意，当您的上游团队执行向 UMS 的迁移时，他们应该以某种方式保留旧用户 ID 和现代用户 ID 之间的映射。在仓库的下游，我建议您将两个 ID 保留在 User 维度表中，但在该表中生成一个代理键，该代理键将用作主键（它可以只是一个增量整数）。这样，无论用户是现代用户还是旧用户，您都可以将代理键用作 Action 事实表中的外键。

【解决方案2】：

同意前面的回答。当您的上游团队执行向 UMS 的迁移时，他们应该以某种方式保留旧用户 ID 和现代用户 ID 之间的映射。在仓库的下游，我建议您将两个 ID 保留在 User 维度表中，但在该表中生成一个代理键，该代理键将用作主键（它可以只是一个增量整数）。这样，无论用户是现代用户还是旧用户，您都可以将代理键用作 Action 事实表中的外键。

这是我为您的表格设计数据模型的建议：

DIM_USER
- USER_KEY (pk)
- USER_ID
- USER_ID_LEGACY
- USERNAME
- ....

DIM_ACTION
- ACTION_KEY (pk)
- ACTION
- ....

FACT_ACTION
- USER_KEY
- ACTION_KEY
- ....

【讨论】：

谢谢，我终于做了一个类似于你提到的方法。我使用 ISNULL(ModernUserId, LegacyUserId) 作为用户维度表中的键列。