如何高效地进行数据建模

理解数据是控制任何企业的先决条件。但只有当这些知识能够被分享和传播时，理解才是有用的。有效的数据建模应该是任何企业架构师的首要关注点。

理解数据是控制任何企业的先决条件。但只有当这些知识能够被分享和传播时，理解才是有用的。有效的数据建模应该是任何企业架构师的首要关注点。

在我的上一篇文章中，我认为理解一个企业的数据是指导一个企业的核心。但理解只是问题的一半。另一半是能够记录这种理解并与他人分享。

[[278085]]

如果没有对数据的共同理解，就谈不上跨系统或组织的共享数据。传统上，这是通过使用数据字典来完成的--这些文件旨在解释数据结构中每个字段的内容和格式。可悲的现实是，这些文档必须手动创建和更新，因此很少会进行更新。其结果是往往会出现过时的、无用的文档和沮丧的架构师和开发人员。但其实还有更好的办法。

正确完成建模

在过去的几十年里，数据建模的努力通常集中在关系数据建模或可扩展标记语言(XML)的建模上。只要数据存储在关系数据库中，关系数据建模就会很好，但除此之外，它很少会有其他的用途。而且XML也不能被可靠地称为建模语言。XML是序列化数据的规范--即定义了如何将数据写入文件。XML为构造数据的序列化提供了一种格式，但它不是一个真正的模型。

我所说的“模型”指的是以数学为基础的形式规范。实际上，这意味着是可以使用形式化方法进行验证的东西。通俗地说，这意味着我们可以用数学运算来证明它是正确的，并且我们可以使验证过程自动化。而在XML模式中捕获数据不符合此定义下的模型。但可以肯定的是，我们可以使用软件来验证该XML格式是否良好，是否符合一些XML模式的文档。但这还不足以真正地对数据进行建模。

无论是计算机还是人，如果不同时理解数据的语法(结构)和语义(含义)，就无法理解数据。XML可以捕获语法，但它不能天生捕获语义。语义可以用XML格式编写，但是这些语义必须首先在一些更正式的建模方案中被捕获。换句话说，企业需要一个正式的本体。这种建模方案大多基于形式逻辑，通常是公共逻辑或描述逻辑。

迄今为止，最常用的语义建模语言是基于描述逻辑的网络本体语言(OWL)。这意味着我们不仅可以正式验证模型及其包含的数据，还可以通过对数据的推理来推断新的事实，并且我们可以证明这些推断的正确性。因为OWL是本体建模的事实上的标准，所以我将把剩下的内容限制在OWL上。

但是等等!所有这些都不意味着你需要将你的数据存储为OWL。在你过于担心如何将存储格式强加给不情愿的开发人员之前，先听我说完。

数据模型和数据存储

军事策划者有一句格言：“业余爱好者担心战术，而专业人士担心后勤。”他们试图达到的核心思想是，如果你只是制定了一个压倒敌人防御的战斗计划，那并没有什么用处，但是，你也不能只让你自己的部队获得执行计划所需的燃料和弹药。同样的，我们也可以说实现者通常会担心存储，而架构师会担心模型。没有理由必须认为数据模型是应该由特定系统使用的存储技术来决定的。一个定义良好的模型可以通过无损过程转换成任何需要的存储格式。

通常，我们会从存储解决方案开始，然后回到数据格式。或者多种格式。大约20年前，当XML首次被引入时，它被誉为了通用的数据交换格式。在这种情况下，需要交换数据的各种系统可以采用它们当前的存储模式(通常是关系数据库)，并将数据转换成可扩展标记语言，以便与其他系统进行交换。其结果是企业和系统架构师会过度关注于XML格式，而几乎忽略了系统的预期功能或企业的整体互操作性。

这个问题在国防部尤为严重。该部门支持着一个名副其实的需要手工创建和维护的XML规范。每一个XML模式都是单独维护的，每次更新时，都必须检查每个相关的规范是否有潜在的影响(通常是手动的)。除此之外，还必须在XML模式中为无法更新以符合新模式的系统进行设置。其结果是产生了一个混乱的规范混合体，迫使人们必须把注意力集中在使XML协同工作上，而不是集中在XML应该促进的任务上。

与其从存储格式开始，然后确定如何为信息交换来表示它，还不如从与存储无关的数据模型(如OWL)开始，然后将其用作生成数据库模式和数据交换格式的基础。这不仅可以让您专注于理解现有的数据(而不是一些开发人员想的如何将它塞进数据库)，通过从基于模型来创建的多个数据表示，可以最小化维护尾部。因为对企业数据的任何更改都只需要在主模型中手动更改，因而从该模型生成其他存储和交换模式时也可以确保这些模式之间的一致性。

企业数据建模

如果你关注的只是企业，那么很明显，你对数据的关注已经跨越了整个企业，现在你可能会认为对企业中的所有数据进行建模的前景是相当令人望而生畏的。但不要害怕，如果你足够小心的话，这也可以成为一项你可以安全地委托给许多人的任务。

创建一个单一的企业数据模型通常是徒劳的。对于一个群体来说，有太多的数据需要建模，有太多相互竞争的利益集团试图将模型推向他们喜欢的方向，并坚持认为并没有其他方法能够适合他们。但是使用OWL开发的本体是模块化的，这意味着你可以集成来自不同来源的多个模型。不是创建一个覆盖整个企业的单一模型，而是针对每个不同的利益集团(业务领域、开发团队等)。可以为它关心的数据定义自己的本体。

不幸的是，这几乎肯定会导致数据模型的重叠，但对不同对象会有不同的建模。这个问题的解决方案是采用一个通用的上层本体，企业中的每个本体都应该从这个本体中派生出来。一个通用的上层本体不会阻止所有的互操作性问题，但是有了一个好的上层本体，它会通过阻止完全荒谬的构造来约束这些问题，比如将“位置”变成一种“事件”(不，说真的，我已经看到这种情况了)。

有许多候选的上层本体可用，它们中的大多数会试图将所有信息分成五到六个顶级类别。但是，这些本体中的大多数都会遇到这样的问题：有些本体所拥有的数据类并不适合他们的基本类，结果就会产生像将位置作为事件类型这样的错误。在我的经验中，基本形式本体论(BFO)应该是其中最深思熟虑的。在我使用BFO的几年中，我几乎没有发现一个案例，其中所考虑的数据会不符合BFO的类层次结构。

无论如何，企业架构师必须在其特定环境中选择一个最有效的数据建模理念。不管你选择什么样的数据建模理念，请记住，你有义务捕获企业中所有数据的语法和语义。