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

Question

我希望能够在业务的所有领域共享数据，从而降低基础设施的总体复杂性。

问题

我们的问题是，我们目前有4个主要应用程序都连接到我们的CRM应用程序(MicrosoftDynamicy2011)：

​

​

我们公司的决策者目前希望将我们的客户关系管理升级到最新的版本，然后，随着新的升级发布(每2-3年一次)，保持最新的状态。几乎我们所有的应用程序都是与Microsoft Dynamic严格集成的，因此每一次升级都是非常昂贵和危险的。我想设计另一种方法，以减少这种费用和风险。

Research

2006年，罗杰·塞申斯撰写了一篇题为“通往企业架构的更好途径”(这里)的文章，其中概述了改善业务IT系统的方法。他讨论的中心主题之一是降低复杂性，通过以不同的方式安排死亡，他表明，通过将技术划分为部分而不是让任何技术与任何其他技术相连接，您可以成倍地降低系统的复杂性。Jeanne Ross也对这个主题(这里)做了很好的介绍，她谈到了拥有一个在业务领域之间共享核心数据和服务的数字化平台，以便降低整个系统的复杂性，并提高响应当前和未来业务需求的灵活性。

结论

当我反思Session和Ross的经验教训时，我相信，如果我们想每隔2-3年对这项技术进行一次彻底的改革，我们就需要将微软动力( Microsoft Dynamic)从体系结构的中心转移出来。我们只需要将其替换为允许我们的核心数据(主要是客户数据)在应用程序之间共享的东西。我知道数据仓库经常用于聚合整个组织的数据。这个能行吗？

​

​

我知道数据仓库主要用于报告，所以我不知道与数据仓库的直接连接是否是理想的。但是，每个应用程序都不需要更新数据仓库中的任何数据。他们只需要能够获取他们的ID，在每个应用程序的数据库中建立全局、数据仓库实体(customers)和各种特定于单元的实体之间的关系。

问题

这三个选项中的哪一个将满足我的需要：(1)所有应用程序直接连接到的数据仓库，(2)通过夜间更新将数据输入到每个特定应用程序的数据库的数据仓库，还是(3)其他的东西？

谢谢

Answer 1

您所追求的是一个数据集成体系结构--这并不一定意味着一个数据仓库。您所描述的模式称为“集线器和辐条”，它非常常见--我想说，您肯定在解决您所描述的集成问题方面走上了正确的道路。

此页更深入地讨论了这个问题和模式，并有一节讨论了数据仓库和数据集成之间的区别。您已经注意到，您知道数据仓库通常用于报告--这是事实，而且正如链接所讨论的那样，数据仓库也被大量用于分析。它们传统上是商业智能工作的数据源。这可能意味着它们并不总是关注您感兴趣的数据类型--即您的系统需要运行的操作数据，但对于报告或分析目的可能不感兴趣。或者，它们的功能可能无法满足您的需要--例如，如果您需要更快地更新应用程序，传统的通宵ETL加载可能不是最好的解决方案。

所有这一切都是说，数据仓库绝对可以用作数据中心-- EDW成为您的“主数据”源，任何需要在EDW数据上运行的数据质量进程，以及ETL进程都会将校正后的数据发回不同的源--但是研究数据集成的主题可能比数据仓库的主题更适合您，即使两者有许多相似之处，而且可能重叠。

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