企业数据建模应避免的十个错误

不管您是刚要准备开始企业数据建模，还是正在进行，或是已经完成了企业数据建模，我都希望你能通过阅读本文有所收获。下面要介绍的是企业数据建模的时候需要避开的十个错误。列举的都是一些建模团队最容易遇见的典型错误，并未按优先级或出现频率对这些错误进行排序。

1.业务需求收集和数据建模过程中未将信息的“真正”用户包含进来

你在制造业里提出以下建议的话，人们一定会以为你疯了，例如：某个产品在没有对客户需求及期望有很好理解的情况下就开始投入生产，或者以某个产品规格就直接定案。

同理，在企业数据建模中，模型的用户是信息客户或者知识型员工，正是这些人需要用模型所代表的信息进行业务决策或者进行工作。如果这些人没有被包含进业务需求采集与审阅工作中，那么就不能达到他们对模型及数据等等的需求和期望。这样的建模就如同空中楼阁，没有根基，那么这个模型也就不能很好的用在实际中，结果就是“马马虎虎”甚至更糟。让用户使用很糟糕的模型----这几乎是绑架用户。

2.建立新的数据模型的时候，仅依靠组织现存的数据库、系统、应用软件、工具与流程进行。

组织现存的数据库、系统、应用软件、工具和流程代表的是过去的业务信息需求。这些系统反应的是过去业务的工作方式，由于现存的结构与模型的一些缺点，它们可能勉强能够运转。有时，为了应对一些没有满足的需求而存在很多变通的方案，以及“隐藏的信息工厂”，这些内容，IT部门并不知晓。其实这些变通方案和隐藏信息工厂存在的唯一使命就是告诉人们，现有的结构并不能满足业务需求。在建立新的数据模型的时候，如果仅仅根据组织现存的一些东西将会导致数据模型也不能支持当前或者将来业务对信息的需求。

3.数据定义时的用户满意度调查中没有包含“知识型员工”

一些优秀的实践证明，应该对“知识型员工”对数据定义的接受能力、理解能力以及满意程度做一些调查。调查的内容应该包括他们对于数据元素的名称、描述、用途、含义、业务规则、关系以及其他的一些属性的理解进行调查。如果那些使用数据模型的信息用户不能轻松理解数据定义，那么他们必然不能应用信息来做强健的业务决策。

4.没有在数据模型业务需求的定义、审核、签署发布中包含与之层次对等的知识型员工

在业务需求收集流程中将所有的知识型员工都包含进来或许不太实际。曾经有过很多人都想将所有知识性员工包含进来，结果都找不出可行的方案。然而却有另一种很好的方法，那就是将不同领域、不同部门的执行员工的代表包含进来。这些被包括进来的每个人都一定要来自组织中足够基层的地方，这样他们才能对他们供职的业务功能或者部门的运作细节足够了解。例如，你不能因为CFO参加了业务需求模块就说你已经有了财务模块方面的代表性人员。

5.采用别人定义、管理的数据名、数据定义和模型时，你的组织可能会对它们失去控制。

业界有很多供应商在销售数据。这些数据对组织来说可能因为能够带来更远的眼光或者能够作为企业已经有的数据的一个“信息”补充而成为一些有价值的资源。然而，在将这些外部数据作为模型计划中的一部分时一定要多加小心。这些外部数据提供商提供的数据的名称、定义和关系可能不在你组织的控制之内，而且不能代表你自己的所有需求。因此你应该在你的模型中对这些数据进行标识，通过一个类结构来表明这些数据的供应者、数据结构、名称与关系等。通过这种方法可以让你在一些不在你组织控制之内的变化发生时，不至于遭受破坏性的损失。

6.从模型中排除一些属性，而这些属性却属于目标领域模型范畴

虽然这句话看起来有点愚蠢，但是一些项目经理却真的可能这么干。为了管理工作的范畴以及保证模型或者应用系统能够在指定日期前完成构架，排除一些属性是个不小的诱惑。有的管理者会“催促”开发的过程并对已经完成的项目质量漠不关心。然而将模型中排除一些与目标领域模型相关的属性一般会导致无限次的数据清洗，而且会要有不在IT监控范围内的附加数据库。这样做会在对那些不包含在数据模型中的附加属性进行定义与建模时引起混乱。

7.没有为不属于企业数据模型范围的属性、实体、关系和业务流程的定义和应用定义流程。

通常这不是一种与企业数据建模有关的活动，然而它对于组织的整体数据或信息功能而言却很重要，这方面的数据管理往往被忽略了。信息管理是一个重要的课题，不应该轻视。一个强健的流程应该有对属性、实体、关系和业务规则的定义与应用进行管理，即便这些事情不属于企业数据模型的范畴。如果没有这类流程，混乱就会接踵而至，组织就会回到一种组织冗余的状态，并且要为不属于数据项的矛盾数据进行存储。

8.没有将现实世界的对象或者现实用一种通用的方法建模，因此模型就不能在应对现实世界的变化时很有弹性的避免破坏性改变。

十几年前，email还没有成为日常的商务交流工具。那时候，组织的数据模型并没有将此作为一种数据元素。如今email成了业务交流中必不可少的一部分，之前组织很随意地将其与新的数据点连接起来。一些新的变通方案和简易修复手段被用来应对这种新的业务需求。例如把email地址存在文本里或在表的备注字段等等。这个例子强调的是这些组织的数据模型没有足够的弹性来支持现实世界的变化。要是这些组织前瞻性的使用通用对象来建模例如“通信类别”，那么加上一种新的数据元素就很简单了，对模型破坏性的改变也就可以避免了。

9.未规范化的模型会导致知识性员工不能阅读并理解模型。

关系理论中说过规范化的目的是：用一种能够将数据元素存储在唯一的一个位置的方法组织它们，除了外键——这是数据共享的部分。在模型实际应用时偶尔会有这种情况：为了系统运行的优化而不遵守规范化的原则。组织不能仅仅为了帮助知识型员工理解模型或者为了提高物理数据库的运行，就不做规范化的相关工作。

10.没有将数据与信息质量机制加入到模型中

时间戳、审计追踪以及历史数据等应该加入到模型中去。这些概念对于避免过期信息的成倍累积来说很重要。标准化和其他相关理论对于在模型中构建数据与信息质量机制来说非常关键。

结束语

本文讨论的内容显然不能够涵盖所有的实际数据建模中的话题。不过大多数项目都有个共同点，就是当要实际应用时都会要个优先级排序，并且都考虑不够长远。这样的思路不会引领一个好的业务项目实践，应该尽量避免。