如何高效地进行数据建模

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

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

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

正确完成建模

在过去的几十年里，数据建模的努力一般集中在关系数据建模或可扩展标记语言(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的类层次结构。

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