怎样将数据库设计移植到主数据管理系统

一道曙光

看这个画面，X公司希望用一个方法来保证所有方面的一致性并可以纠正数据的错误。显然，X公司没有购买一个单独的系统，这个系统可以维持和管理数据所有的需求。创建一个单独的系统对用户的开发时间和再训练有重大意义。

X公司能够做的是窗一个主数据的中心储存库，这个中心储存库能够让没有系统自己的主数据按照正常的间隔返回到自身。这样做可以不移动X公司内的详细目录中系统的任何东西。

  在X公司内这个给终端用户提供了一个单独的系统，这个系统可以展示关于产品信息的完全集。这个单独的表述层和公司的corporate-dashboard模版类型数据显示的观念相似，现在它们都非常流行。

  下一步就是允许它们使用这个系统来管理数据，并且将它们的变化返回到相关的系统中中。当然，在这种情况下仅仅只有一部分人有权利来更新数据。

X公司现在有了一个单独的系统，这个系统对所有产品的信息提供了一个复合的视图，并且允许按照统一的方法改变系统下面的所有东西。

另外，没有系统现在和其他的会话都经过中心系统；比如，LabelMan将更新的产品X的标签送到中心系统中，在中心系统中ProdMan收集它们并更新关于X产品自己的信息。在技术方面来说，这意味着如果系统下的任何被改变了，需要被检查的仅仅只是它们连接到中心系统。对于X公司来说，这个更简单并且是更值得借鉴的管理方案。

中心系统和系统下的连接可以通过两种方式完成，一种是使用用户代码接口，你可以用任何你喜欢的语言来使用它，一种是技术平台，比如EAI或者ETL，这个就取决于你的应用程序平台了。

没有灵魂的木偶

在这点来说，在X公司里，中心系统仅在一个引用点引用所有主数据的时候才起作用。系统本身不能创建任何数据；它只简单的合成了数据的看法，这些数据存储在系统和可以更新数据的方法中。

但是，在添加一个新产品的时候，当它出现在中心系统时X公司依然需要手动添加这个产品到没有系统中，并且每个系统都有自身的一套用户接口和命名约定。

如果X公司决定更新它的中心系统以便允许它可以创建新的产品，在一个完整的形式中，在用户被返回到中心系统之前，这些模版骨架可以被适当的系统下的用户进程。为了促进它并确保每个人都知道哪个记录是哪个，X公司需要为它的产品引进一种新的命名约定，ID可以通过中心系统产生，ID可以直接指向这个数据。

新的改进

当X公司正在进行的IT计划，所有的系统都要更新。既然现在中心系统在适当的位置，每个系统不再需要存储它自己的主数据集作为自己的元数据，但是，它可以从中心系统中生动的负载它。另外，这些系统的一些功能性可以从系统的根本移动到中心系统。在某些例子中，在一段时间后甚至可以将整个程序移动。

利用密匙管理X公司的产品现在可以经过中心系统完成，先前由ProdMan完成的关键功能现在在那个系统中不再被使用，也许扩展ProdMan现在变得很多余了。

X公司如何获利？

X公司的IT计划受益匪浅，因为它可以加速执行和结合新系统。每个新工具仅仅和自身的功能性和特殊数据相关，这些数据可以从中心系统装载支持物。

X公司商业获益因为它有所有数据的正确的数据用来帮助决定和计划。X公司同样可以可以给它的用户和提供者提供超值服务。

更新各种信息，比如用户地址或者产品名字，现在只用在中心系统中更新一次，这比在没有程序中更新一次好的多，因为后者有很大的风险。