Sql server 从多个外部系统构建数据集市的最佳方法？

我正在计划为邮件/电子邮件/短信联系信息和历史构建一个SQL Server数据集市。每个数据段都位于不同的外部系统中。因此，电子邮件地址没有帐号，短信电话号码没有电子邮件地址等。换句话说，没有共享的主键。有些数据重叠，但除了在出现重复时保留最完整的版本外，我无能为力

是否有使用此数据构建数据集市的最佳实践？为每个外部键创建一个包含一列的键表是可以接受的做法吗？然后，可以分配一个唯一的主ID将其与其他数据集市表绑定

寻找我可能尚未想到的方法的想法/建议

---

谢谢。

电子邮件地址或电话号码本身听起来像是一把合适的商业钥匙。通常，“暂存”数据库用于从多个源加载数据，然后分配代理键并执行其他转换

---

您熟悉数据仓库方法和设计模式吗？如果你没有以前的知识或经验，那么考虑雇佣一些帮助。BI/数据仓库项目有很高的失败率，错误可能会很昂贵。

好吧，没有其他信息将不同的部分联系在一起，您的数据集市将非常初级。您将能够获得数据类型（短信、电子邮件、邮件），以及每种类型随时间变化的指标（“本周/月/季度/年，我们平均每天发送42.5条短信，每月发送8000封电子邮件！w00t！”）。只有电话号码和电子邮件地址，您的“其他数据集市”可能必须是电话公司名称或互联网域名。我想你可以从中链接到某种地理信息（互联网提供商的位置？），或者公司的财务信息。如果你还不知道你想朝哪个方向走，那就有点模糊了

老实说，这听起来像是高层人士对“数据集市”这个流行词下意识地做出反应，再加上听到了一些关于通信指标有多么重要的消息，所以他们在链的下游发送命令，“让我们一些数据集市对我们所有的电子邮件运行统计数据！”

---

你需要弄清楚你或你的雇主希望从这个项目中得到什么，然后弄清楚你目前收集的数据是否为你提供了获取这些信息的线索。现在听起来你是在倒退（“我有这个数据，它有什么用？”）。完全有可能您目前没有所需的数据，这意味着您需要购买（谁知道您是否可以）或开始收集数据，在这种情况下，您将在一段时间内没有好看的图表和趋势线供高层管理人员查看。。。正好符合Portas在第二段中给你的警告；）

在此处找到更多信息：

---

我们的目标是使联系信息、联系历史记录和行为更易于在中心位置访问，而不是使用一个包含多个系统数据的混乱Excel电子表格。我们目前无法轻松跟踪联系人历史记录。因此，我们希望将这些数据汇集到一个更易于每个人访问的中央环境中。问题在于数据是零散的，不容易访问。这就是我们希望改变的。它的规模较小，最初只供3人使用。尽可能简化数据收集。收到的电子邮件应该在某个地方的电子邮件服务器上，因此您应该能够从中提取信息。电话可能是在PBX系统中记录的，如果是数字系统，你应该能够从中获取信息。短讯服务。。。不知道你将如何记录这些信息，除非你有一个系统在两个人发短信之间。如果你这样做了，它应该有你可以提取的信息。所有这三种情况都需要有人知道如何进入每个系统的数据，并找出如何将数据传送到数据集市。每个系统可能存储了大量的信息历史记录，或者仅仅一个月的信息，除非你了解这个系统，否则没有办法知道。因此，假设它不存储永无止境的日志，您必须制定一个时间表，定期从每个系统中获取数据。然后，您必须为提取的数据进行适当的数据集市设计，以便生成所需的度量。顺便说一句，如果你目前没有记录联系人历史记录，那么你正在谈论在你的用户面前推出一个新的应用程序，诀窍是让他们真正正确地使用它。“细节中的魔鬼”好消息是，我们确实可以访问这些东西，并且知道我们正在处理的系统。关于联系方式，我更多的是从营销活动的角度讲。在我所在的部门里，我们确实可以访问这些数据。不过，您是对的，我们需要确保在我们的流程中记录活动收件人数据。我的问题主要是从最佳实践的角度，在联系联系数据时的技术问题。如果我们走这条路，在把它放在前面之前，这些都是我们想认真考虑的细节。啊，代理密钥可能是我想要的。谢谢我已经回顾了星型模式、ETL流程、多维数据集等。我当然非常感谢这些建议。由于该项目最初在测试环境中规模较小，我只是不认为现在聘请外部帮助是值得的。我们已经有了现场工作人员，一旦概念上完成，我们可能会将此传递给他们。我们现在正处于计划阶段。