数据仓库是跨技术共享客户数据的好解决方案吗？

Question

我希望能够以降低我们基础架构整体复杂性的方式在我们业务的所有领域共享数据。

问题

我们的问题是，我们目前有4个主要应用程序都已连接到我们的CRM应用程序（Microsoft Dynamics 2011）：

我们公司的决策者目前希望将CRM升级到最新版本，然后，在发布新的升级时（每2-3年）保持最新。我们几乎所有的应用程序都与Microsoft Dynamics紧密集成在一起，因此每次升级都非常昂贵且有风险。我想设计另一种方法来减少这种费用和风险。

研究

[2006年，Roger Sessions写了一篇名为企业架构的更好路径（here）”的文章，概述了改善商业IT系统的方法。他讨论的中心主题之一是降低复杂性，并且通过以不同的方式安排裸片，他表明可以通过将技术划分为多个部分而不是让任何技术与任何其他技术连接来以指数方式降低系统的复杂性。珍妮·罗斯（Jeanne Ross）在这个主题上也做了精彩的演讲（here），她谈到要建立一个数字化平台，以便在业务领域之间共享核心数据和服务，从而降低整个系统的复杂性并提高响应的敏捷性。满足当前和未来的业务需求。

结论

[当我回顾Sessions和Ross的教训时，我有信心，如果我们希望每2-3年对技术进行一次大修，就需要将Microsoft Dynamics移出我们的体系结构中心。我们只需要将其替换为可以在应用程序之间共享我们的核心数据（主要是客户数据）的内容即可。我知道数据仓库通常用于在整个组织中汇总数据。这行得通吗？

我知道数据仓库主要用于报告，因此我不知道直接连接到数据仓库是否理想。但是，每个应用程序都不需要更新数据仓库中任何数据的能力。他们只需要具有获取ID的能力，即可在每个应用程序数据库中的全局数据仓库实体（客户）与各种特定于单位的实体之间建立关系。

问题

这三个选项中的哪一个可以满足我的需求：（1）所有应用程序直接连接到的数据仓库，（2）通过通宵更新将数据馈送到每个特定于应用程序的数据库的数据仓库，或者（3）其他？

感谢

Answer 1

您追求的是数据集成体系结构-不一定意味着数据仓库。您描述的模式称为“轮辐”，这很常见-我想说您肯定在解决所描述的集成问题的正确道路上。

This page更深入地探讨了这个问题和模式，并且其中有一节专门介绍数据仓库和数据集成之间的差异。您已经注意到，您知道数据仓库通常用于报告-的确如此，正如链接所讨论的，它们也大量用于分析。传统上，它们是商业智能工作的数据源。这可能意味着它们并不总是专注于您感兴趣的数据类型，即系统需要运行但对于报告或分析目的可能不感兴趣的操作数据。或者，它们的运行方式可能无法满足您的需求-例如，如果您需要更快地更新应用程序，传统的夜间ETL加载可能不是最佳解决方案。

所有这些都是说，数据仓库绝对可以用作数据中心-EDW成为您的“主数据”源，任何需要在EDW数据上运行的数据质量流程，而ETL流程将校正后的数据发回给各种来源-但是研究数据集成主题可能比数据仓库主题更好，即使两者有很多相似之处并且可能重叠。

如果您创建没有任何商业智能要求的数据仓库，它可能无法很好地用作数据仓库。一个非常合适的数据集成/主数据解决方案可能无法解决您对数据仓库的所有未来需求。同样，如果要在研究数据仓库最佳实践之后创建传统数据仓库，则它可能无法满足您的数据集成要求或无法以最佳方式满足它们。就像该链接所建议的那样，将这两个想法分开：解决数据集成问题，以及如果将来需要数据仓库，则可以使用数据集成解决方案来帮助填充它。