理解数据是控制一家企业的先决条件。但只有当这些知识能够被分享和传播时，理解才是有用的。有效的数据建模应该是一家企业架构师的首要关注点。
　　在我的上一篇文章中，我认为理解一个企业的数据是指导一个企业的核心。但理解只是问题的一半。另一半是能够记录这种理解并与他人分享。
　　如果没有对数据的共同理解，就谈不上跨系统或组织的共享数据。传统上，这是通过使用数据字典来完成的--这些文件旨在解释数据结构中每个字段的内容和格式。可悲的现实是，这些文档须手动创建和更新，因此很少会进行更新。其结果是往往会出现过时的、无用的文档和沮丧的架构师和开发人员。但其实还有更好的办法。
　　正确完成建模
　　在过去的几十年里，数据建模的努力通常集中在关系数据建模或可扩展标记语言(XML)的建模上。只要数据存储在关系数据库中，关系数据建模就会很好，但除此之外，它很少会有其他的用途。而且XML也不能被可靠地称为建模语言。XML是序列化数据的规范--即定义了如何将数据写入文件。XML为构造数据的序列化提供了一种格式，但它不是一个真正的模型。
　　我所说的“模型”指的是以数学为基础的形式规范。实际上，这意味着是可以使用形式化方法进行验证的东西。通俗地说，这意味着我们可以用数学运算来证明它是正确的，并且我们可以使验证过程自动化。而在XML模式中捕获数据不符合此定义下的模型。但可以肯定的是，我们可以使用软件来验证该XML格式是否良好，是否符合一些XML模式的文档。但这还不足以真正地对数据进行建模。
　　无论是计算机还是人，如果不同时理解数据的语法(结构)和语义(含义)，就无法理解数据。XML可以捕获语法，但它不能天生捕获语义。语义可以用XML格式编写，但是这些语义须先在一些更正式的建模方案中被捕获。换句话说，企业需要一个正式的本体。这种建模方案大多基于形式逻辑，通常是公共逻辑或描述逻辑。
　　迄今为止，常用的语义建模语言是基于描述逻辑的网络本体语言(OWL)。这意味着我们不仅可以正式验证模型及其包含的数据，还可以通过对数据的推理来推断新的事实，并且我们可以证明这些推断的正确性。因为OWL是本体建模的事实上的标准，所以我将把剩下的内容限制在OWL上。
　　但是等等!所有这些都不意味着你需要将你的数据存储为OWL。在你过于担心如何将存储格式强加给不情愿的开发人员之前，先听我说完。
　　数据模型和数据存储
　　军事策划者有一句格言：“业余爱好者担心战术，而专业人士担心后勤。”他们试图达到的核心思想是，如果你只是制定了一个压倒敌人防御的战斗计划，那并没有什么用处，但是，你也不能只让你自己的部队获得执行计划所需的燃料和弹药。同样的，我们也可以说实现者通常会担心存储，而架构师会担心模型。没有理由须认为数据模型是应该由特定系统使用的存储技术来决定的。一个定义良好的模型可以通过无损过程转换成其他需要的存储格式。
　　通常，我们会从存储解决方案开始，然后回到数据格式。或者多种格式。大约20年前，当XML开始被引入时，它被誉为了通用的数据交换格式。在这种情况下，需要交换数据的多种系统可以采用它们当前的存储模式(通常是关系数据库)，并将数据转换成可扩展标记语言，以便与其他系统进行交换。其结果是企业和系统架构师会过度关注于XML格式，而差点忽略了系统的预期功能或企业的整体互操作性。
　　这个问题在国防部尤为严重。该部门支持着一个名副其实的需要手工创建和维护的XML规范。每一个XML模式都是单独维护的，每次更新时，都须检查每个相关的规范是否有潜在的影响(通常是手动的)。除此之外，还须在XML模式中为无法更新以符合新模式的系统进行设置。其结果是产生了一个混乱的规