|
领略数据是节制任何企业的先决条件。但只有当这些常识可以或许被分享和流传时，领略才是有用的。有效的数据建模应该是任何企业架构师的首要存眷点。 在我的上一篇文章中，我认为领略一个企业的数据是指导一个企业的焦点。但领略只是问题的一半。另一半是可以或许记录这种领略并与他人分享。 假如没有对数据的配公道解，就谈不上跨系统或组织的共享数据。传统上，这是通过利用数据字典来完成的--这些文件旨在表明数据布局中每个字段的内容和名目。可悲的现实是，这些文档必需手动建设和更新，因此很少会举办更新。其功效是往往会呈现过期的、无用的文档和沮丧的架构师和开拓人员。但其实尚有更好的步伐。 正确完成建模 在已往的几十年里，数据建模的尽力凡是会合在干系数据建模或可扩展标志语言(XML)的建模上。只要数据存储在干系数据库中，干系数据建模就会很好，但除此之外，它很少会有其他的用途。并且XML也不能被靠得住地称为建模语言。XML是序列化数据的类型--即界说了如何将数据写入文件。XML为结构数据的序列化提供了一种名目，但它不是一个真正的模子。 我所说的“模子”指的是以数学为基本的形式类型。实际上，这意味着是可以利用形式化要领举办验证的对象。通俗地说，这意味着我们可以用数学运算来证明它是正确的，而且我们可以使验证进程自动化。而在XML模式中捕捉数据不切合此界说下的模子。但可以必定的是，我们可以利用软件来验证该XML名目是否精采，是否切合一些XML模式的文档。但这还不敷以真正地对数据举办建模。 无论是计较机照旧人，假如差异时领略数据的语法(布局)和语义(寄义)，就无法领略数据。XML可以捕捉语法，但它不能天生捕捉语义。语义可以用XML名目编写，可是这些语义必需首先在一些矫正式的建模方案中被捕捉。换句话说，企业需要一个正式的本体。这种建模方案大多基于形式逻辑，凡是是民众逻辑或描写逻辑。 迄今为止，最常用的语义建模语言是基于描写逻辑的网络本体语言(OWL)。这意味着我们不只可以正式验证模子及其包括的数据，还可以通过对数据的推理来揣度新的事实，而且我们可以证明这些揣度的正确性。因为OWL是本体建模的事实上的尺度，所以我将把剩下的内容限制在OWL上。 可是等等!所有这些都不料味着你需要将你的数据存储为OWL。在你过于担忧如何将存储名目强加给不情愿的开拓人员之前，先听我说完。 数据模子和数据存储 军事筹谋者有一句格言：“业余喜好者担忧战术，而专业人士担忧后勤。”他们试图到达的焦点思想是，假如你只是拟定了一个压倒仇人防止的战斗打算，那并没有什么用处，可是，你也不能只让你本身的队伍得到执行打算所需的燃料和弹药。同样的，我们也可以说实现者凡是会担忧存储，而架构师会担忧模子。没有来由必需认为数据模子是应该由特定系统利用的存储技能来抉择的。一个界说精采的模子可以通过无损进程转换成任何需要的存储名目。 凡是，我们会从存储办理方案开始，然后回到数据名目。可能多种名目。约莫20年前，当XML首次被引入时，它被誉为了通用的数据互换名目。在这种环境下，需要互换数据的各类系统可以回收它们当前的存储模式(凡是是干系数据库)，并将数据转换成可扩展标志语言，以便与其他系统举办互换。其功效是企业和系统架构师会太过存眷于XML名目，而险些忽略了系统的预期成果或企业的整体互操纵性。 这个问题在国防部尤为严重。该部分支持着一个名副其实的需要手工建设和维护的XML类型。每一个XML模式都是单独维护的，每次更新时，都必需查抄每个相关的类型是否有潜在的影响(凡是是手动的)。除此之外，还必需在XML模式中为无法更新以切合新模式的系统举办配置。其功效是发生了一个杂乱的类型殽杂体，迫使人们必需把留意力会合在使XML协同事情上，而不是会合在XML应该促进的任务上。 与其从存储名目开始，然后确定如作甚信息互换来暗示它，还不如从与存储无关的数据模子(如OWL)开始，然后将其用作生成数据库模式和数据互换名目标基本。这不只可以让您专注于领略现有的数据(而不是一些开拓人员想的如何将它塞进数据库)，通过从基于模子来建设的多个数据暗示，可以最小化维护尾部。因为对企业数据的任何变动都只需要在主模子中手动变动，因而从该模子生成其他存储和互换模式时也可以确保这些模式之间的一致性。 |
