Enterprise Engineering Forum

企业工程论坛
Categorized as: 企业/业务建模,模型与建模   Tagged as: ,, , , , ,

札记:本体及数据、信息、领域、企业建模与模型

Author: 余彤鹰,  Source: 企业工程论坛,  Published: 2011-02-28

Excerpt: 围绕着计算机应用领域的“本体”(ontology)的基本概念,讨论了数据/信息建模与数据字典、模型驱动设计(DDD)的领域建模、企业建模等概念。

本体概念

计算机应用领域的本体(ontology)概念,因其哲学渊源[1]和人工智能(AI)出身,充满了神秘色彩,常让人觉得高不可攀。在概念划分时,也往往冠以“计算机科学”与“信息科学”这样的高帽子。实际上,我认为它是一个比较简单明了的概念,与普通的数据字典、词汇表、各种通用建模技术或体系等有着本质、密切的关系。

公认计算机科学(人工智能)领域本体概念的确立,是来自Thomas R. Gruber在1992年左右的工作[2],他借鉴哲学的本体(Ontology)概念,在人工智能、知识表达研究的背景下导入了这个新概念:

“An ontology is an explicit specification of a conceptualization.”

直译就是:“本体是概念(化)的明确规范。”这里conceptualization稍微有些费解,中文的基本译法是“概念化”,字面上看是个过程,这可能更让人困惑。Gruber进一步明确:

“A conceptualization is an abstract, simplified view of the world that we wish to represent for some purpose.”

即:conceptualization是我们为了某种目的而希望表达的,世界的抽象、简化视图。这里“本体”是作为一种实体(可数的)来定义的,conceptualization,主要是指某种具体的、有目的的概念化(概念抽取与表述)过程的结果,也就是一系列具体的概念表述(规定、约定)。有人喜欢在这个定义中添加“形式化”与“共享”,从本质上理解,这并非必要。所谓“形式化”,可以理解为“明确规定”方式和程度的一种体现,例如,也可以有“形式化本体”和“非形式化本体”这样的不同本体概念。所谓“共享”,有助于理解人们为何要建立本体,但它是非本质的:本质的、决定本体的是“目的”。理解本体概念中的目的非常重要,因为在现实世界无限性、连续性和动态性背景之下,“目的”是使概念化过程达成某种确定性结果至关重要的条件。

经过上述讨论,我们可以这样解读Gruber的本体概念:本体是一种明确表述的概念规范,是为某种目的而建立的、世界的简化和抽象的视图。按照对模型的一般性理解,本体无疑就是一种模型。建立本体的过程,就是一个建模的过程。

数据字典

数据字典(Data Dictionary)算得上信息系统开发中的骨灰级概念。虽然概念有些老,但在真实的计算机应用开发中,它始终是重要的基础要素之一。

计算机应用开发中的数据字典,核心就是某种受控词汇表。其基本的简单形式之一,是词汇字符串加编码——前者应当是用户可读的文本,后者加以适当约束(例如唯一性约束),作为适合计算机处理的编码(大陆也常见“信息/数据编码”这一说法)。在这个基础上,最基本的扩展,是增加说明文本(或描述、解释)及别名等。附加在数据字典上的典型信息,通常还会包括数据定义(对应到计算机支持的数据结构)及相关的操作规则(约束等)。再进一步,就涉及这些数据项之间的关系,从基本的分类到更具体的语义(问题域语义与计算机操作语义)和相互间的关联关系等。

在信息系统开发的过程中,这一数据字典成为连接问题领域的“意义/概念”和计算机程序的桥梁,它通常会建成计算机可直接处理的形式(但未必直接包含在应用系统中)。它的内容必须受到控制。另一方面,作为纯粹应用系统开发中的数据字典,其中包含的条目,并不一定都来自“问题领域”,也可能是软件系统本身所需。与“本体”的基本定义比较,我们至少可以明确:数据字典和本体是非常接近的。我们甚至可以这样理解:如果说,某些数据字典过于简单,没有包含某些“公认”的本体内容,那正是它的目的所决定的,因而,依然可以看作是一种简单的本体。此外,与典型的本体创建活动相比,数据字典常常是限定在一个特定的系统范围之内,而本体则是“先于”、“独立于”具体应用系统而开发的。

数据建模与数据模型

(Data Modeling)是软件工程的一个基本概念,它比数据字典要更广泛和重要,后者实际上可以看作是数据建模的一部分。

过去几十年,数据建模始终与数据库(主要是关系型数据库)的发展紧密关联,在实践、技术和理论方面都有非常丰富的积累。数据建模的结果(输出),是数据模型(data model)。在实践和理论中,数据模型并不是单一的概念,可能泛指很多类型的模型,例如数据结构,数据库模型,逻辑的、概念的、语义的、物理的数据模型等等。我观察,这个领域的实践与技术虽然丰富,却并没有形成相对完善统一的理论体系。各种概念、方法常常有不同的渊源和各自的实践领域、技术基础,而它们之间的关系(比如在基本概念的使用上)常常是不清晰的。

数据建模方面,最有代表性的基本概念,可能就是概念层、逻辑层、物理层的三层架构。一般而言,可以这样理解:它们是计算机所要储存、处理的数据,在三种不同抽象层次上的描述。概念数据模型(conceptual data model)描述计算机系统将要处理的问题领域中的事物,它本身常常采用实体联系模型(E-R Model)。逻辑数据模型(logical data model)描述的是计算机组织数据的逻辑结构,关系数据模型(relational data model)是逻辑模型最常见的类型,其内容呈现为具体的表、列、键及各种约束的定义。物理数据模型(physical data model)是逻辑数据模型的实现,任何一种可实际运行的数据库平台,都包含自己的物理数据模型。而平台的使用(应用开发)者,基本上只工作在逻辑层,仅通过平台提供的接口间接地操纵物理层。

这三个层次,逻辑层是一个中介,物理模型和概念(信息)模型是它的两面:对计算机的那一面,呈现物理数据(从语义上说,是计算机操作语义);对人的那一面,呈现为可理解的信息,也就是语义——在业务或应用中的意义。概念模型,也常常被看作是“语义模型”或“信息模型”,它与“本体”基本上处于同样的相对位置。概念建模最常用的E-R模型被看作本体模型的一种。一个完整的数据建模系统,把问题领域(例如,企业的业务/需求,属于所谓“现实世界”)的事物与在计算机上如何描述与储存联系了起来。

传统的数据建模与“地道的”本体不同的一个基本点,也许就是“物理数据”的实现。数据建模通常都联系到具体的应用系统,甚至多数就是作为特定系统开发的一部分,而本体的设计/维护,通常只是针对某种特定目的(或应用领域,这常常是很笼统的),但并不针对某个具体应用系统。任何一个建立起来的本体系统,也包含着物理储存方案,但它会被看作是与本体的应用严格分离的——而数据建模作为一个系统自身的需求,可以与物理实现最紧密地捆绑在一起。基于本体的应用,本质上,就是数据独立、面向信息()的系统。(对此类系统的讨论,可见综合信息系统开发途径与策略分析等)

数据建模领域的信息工程方法及其分支(比如信息规划或信息资源规划,参见信息工程与信息系统架构向企业架构的发展等文),实际上也是一种将数据建模与特定的应用开发/实现隔离策略的尝试。这一实践,与“本体”具有更大的重叠性,但从企业应用开发实践的角度看,这一分支的发展却非常有限。换一个角度,也许可以说,作为一种特定分支发展受限的同时,其中合理的原理或要素,已经通过其它途径发展了。

领域建模与领域模型

在近年的计算机软件领域流行的领域建模与领域模型(Domain Modeling and Domain Model)大概还不能算是建模领域的一种独立概念,它们是这几年流行的软件开发方法体系“领域驱动设计”(Domain-Driven Design, DDD)中的概念。DDD的基本思想,是要把应用系统的开发直接建立在对应用所涉及的问题域(即领域,或简称域)的明确描述——模型上。它的具体发展和实践,则是发源于面向对象技术(OO)阵营。从概念和原理上看,它无疑是一种模型驱动软件系统开发(MDSD),因而也可纳入软件领域的模型驱动工程(MDE)之中。

从道理上不难理解,所谓的“领域模型”,与传统数据建模中的概念模型的地位非常相似[3]。虽然DDD自然产生与发展条件决定了,它带有强烈的面向对象技术特点,与特定的软件系统架构风格联系得非常紧密,尤其是近年流行的基于ORM(对象-关系映射)概念的中间件技术。客观地看,这一方面使得DDD具有非常强的实践性、实用性,另一方面,也限制了它的空间,使它处于一种具体的开发技术(风格)的位置上,而并不像其名字所暗示的那么广泛。

企业建模与企业参考模型

在企业工程相关领域,传统的研究与实践,主要使用企业建模、企业参考模型与企业参考架构(框架)概念。但这个领域同样有一些研究,围绕着本体,即“企业本体”(enterprise ontology)的概念,例如我们介绍过的,简·迪茨的企业工程等。这个领域的传统概念“企业参考模型”,与企业本体也很接近,实际上,它们都是要构造一些基础性、通用性的企业模型,换言之,企业本体就是一种通用企业参考模型。Zachman的企业架构框架,也被称为一种企业本体。

我们对与企业工程的研究,强调企业模型与企业应用(信息系统)的衔接(参见企业工程的内容与企业架构的定位企业应用探索十五年之路线图等文),直接继承和沿用企业模型这个基本概念,并且将它与信息系统中的数据建模(概念建模)联系起来。我们从更一般化、多角度立场上去理解和运用企业模型这个基本概念,研究它的工作方式,围绕一般事物建模和通用企业模型框架等展开。这在实质上看,是一种“本体化”路径,但我们是在本体概念流行之外建构体系,因此,在我们的概念体系中,一直没有引进“本体”概念。虽然从多年前语义网热开始,我们就一直在观察、追踪,但只是从原理的角度加以借鉴、吸收。

若干讨论

我们搜集了一些与本体密切相关的重要模型概念,将它们与本体的关系绘制成一个示意图。它主要基于较为宽泛的本体及模型概念理解(留意这个图很难展表现这些概念之间的复杂关系)。这个图至少给出这样一种信息:所有这些重要的模型概念,都可以从本体研究那里找到重叠或借鉴的东西。

本体(ontologies)及一些相关的模型概念

对计算机领域的本体,从语言(许多专门的本体建模语言)到形式或结构、内容构成要素等等,都已经形成了许多具体原则。以“完备本体”的标准来衡量其他领域对于概念或词汇建模的一些工作(例如:著名的英文词汇及其关系数据库WordNet),则往往发现许多“不足”,因而有人喜欢强调诸如此类的系统不是本体。

从更深的层次看,搞清楚它们描述内容的范围、方法及其具体限制等等,才是更重要的,或者说,看到所有这些工作的相同(重叠)与不同之处才是最重要的,而不是拘泥于概念的纯粹性或规范性、完备性。

从本体的角度看信息系统开发中的各种受控词汇表、数据词典或数据/信息建模及其模型,是很有意义的。与“完备的”本体相比,它们可能在形式、内容(比如词汇)描述的深度或完善程度方面有所区别。另一方面,我们也可以认为,任何有具体目的的本体,实际上都是一种“领域模型”,虽然这个领域有时相当宽泛,例如许多为“知识表达”这样的综合目的建立的基础本体或上层本体。

企业建模的情形稍微复杂一些。在我们的应用途径中,这个体系本身就有类似本体与本体应用的不同层次。这也涉及本体概念的相对性问题。

本体是一个相对概念。前面讨论的Gruber的本体概念中的“世界”(the world),其本身就是相对性的。从理解的角度,我们可以把它缩小为“问题域”或“应用域”,或者所谓“论域”。

本体实践中最基本的课题之一,是“边界”(范围)与“演化”问题。一方面,现实世界本身不是一成不变的,因而,应用中的本体也需要变化;另一方面,哪些概念具有通用性,应该纳入本体,哪些不是,会是最繁琐和难解的问题;而在实际应用中,这一问题还必然地与现实世界的变化,以及应用系统边界的变化与不确定性联系在一起。这既是本体应用中的难点与要点,也是所有建模与模型研究中的难点与要点。流行的“模型驱动”概念,我们所提出的模型驱动机制与模型驱动系统,都是围绕着这一点。

计算机科学领域的本体,是一个广受关注,获得大量研究的课题。一名专门的本体研究者,对于什么是本体,会有非常严格的判断标准。但从本质理解和发展的方向上,把这样一些本体研究领域之外的概念联系起来,却是非常有意义的。本体研究领域的大量工作,可能会是一个很好的基础或枢纽。以目前的情形来看,这些分散、重叠而又不同一的概念的大量存在,显示了计算机应用这个领域的复杂性和某种不成熟特征,但我们有充分的理由相信,它们之间具备固有的协调性。

注释

[1] 为了区分,在英文中习惯将哲学的本体作为专有名词,写作Ontology,加以区别
[2] Gruber, Thomas R. (1993) A translation approach to portable ontology specifications
[3] 为突出这一点,在前面的描述中,我刻意用了“问题领域”一词——这并不是传统数据建模领域的习惯

Copyright

  本发布物版权归原作者所有,经原作者许可在企业工程论坛(EE-Forum.org)公开发布,并允许个人及公益性机构非牟利性使用及传播。传播中需保持从标题、署名到各项内容及此声明包括链接地址等完整内容不变。引用或摘编文中内容或观点应符合公认准则。其它机构,或牟利性使用,请预先取得作者许可。保留一切未说明的权利。
  详细说明见: http://www.ee-forum.org/about/copyright ,管理者电子邮箱:admin(at)ee-forum(.)org

Cite Style

GB7714 style: 余彤鹰. 札记:本体及数据、信息、领域、企业建模与模型[EB/OL]. 企业工程论坛, http://www.ee-forum.org/wp/pub/ty/2011-02-p2491.html, 2011-02-28[2017-12-11 10:16]

Chicago style: 余彤鹰, "札记:本体及数据、信息、领域、企业建模与模型", 企业工程论坛, http://www.ee-forum.org/wp/pub/ty/2011-02-p2491.html(accessed 2017-12-11 10:16)

Posted by   2011-02-28(Original)   Hits 16530   Modified 2011-03-01(Locked)
Prev Post: 
Next Post: 

Related Entries:

漫谈计算机领域的本体论(ontology)
思于模型
企业建模与模型的一些讨论观点(一)
简·迪茨的企业工程研究
企业建模与模型的一些讨论观点(二)

12 Comments

  1. 什么是数据独立、面向信息(模型)的系统,希望博主能举几个例子

  2. 你说的那种面向数据库的应用有些冷,关系数据库都有在面临抛弃

    • 也许现在讲面向数据库的话题,特别是关系型,会有技术流的人瞧不起,尤其是OO folks,潮流派的,大家都在讲云,讲移动终端……但企业信息系统从来就没脱离过这个基础。一些非关系数据库,比如所谓键-值(key-value)数据库的出现是必然也是必要的,可以留意它们的背景。它们是应互联网带来的大量不同于传统局域网应用需求而出现的。我不认为它们是来全面“取代”关系数据库的。
      关系数据库的理论,尤其是应用理论的确需要发展。商业产品可以被取代。但基础技术和基础原理不会。不管云怎么飘,终端怎么移动,综合企业应用的基础都必须存在

  3. 所谓“共享”,有助于理解人们为何要建立本体,但它是非本质的:本质的、决定本体的是“目的”。理解本体概念中的目的非常重要,因为在现实世界无限性、连续性和动态性背景之下,“目的”是使概念化过程达成某种确定性结果至关重要的条件。
    =======================================================
    先赞一句,老余又奉献了这么好的文章,读之如吃大餐。
    “共享”是建立本体的目的之一,虽然它的确不是本体自身的目的。
    哈,这话前后有点矛盾呢。
    建立本体的一个用途就是为了数据交换服务的,因为数据交换的各方对同一对象的表达在概念层面都有着不同的标识命名,在数据层面都有不同的数据结构。
    比如在电子政务中的公民,在公安局和民政局的同一信息,就会有不同的叫法。
    如果能建立起对数据交换各方而言:一个标准的、抽象的本体,无疑具有重大的意义。

  4. 我们搜集了一些与本体密切相关的重要模型概念,将它们与本体的关系绘制成一个示意图。它主要基于较为宽泛的本体及模型概念理解(留意这个图很难展表现这些概念之间的复杂关系)。这个图至少给出这样一种信息:所有这些重要的模型概念,都可以从本体研究那里找到重叠或借鉴的东西。

    从更深的层次看,搞清楚它们描述内容的范围、方法及其具体限制等等,才是更重要的,或者说,看到所有这些工作的相同(重叠)与不同之处才是最重要的,而不是拘泥于概念的纯粹性或规范性、完备性。

    ====================================================
    在老余举出的这些相关概念中,我觉的缺了术语体系(术语学),也许这个可以看作字典、词汇表和分类法中的一部分吧。

    在企业架构中,划分出业务平台一层,它的特征是与技术平台无关。
    业务平台要求能够制定对企业本体(企业工程)的描述语言,它与IT语言无关。但既然它可以对所有的行业企业模型进行表述,所以它又是一种企业本体的元语言,还不是领域语言。
    领域语言才是与行业有关的语言,它的精髓应该就是要回答何以能形成一个独立的行业语义框架,所谓的行业本体,也许这就是我多年一直要追踪抓住的“在逃犯”。
    据我所知,目前研究领域语言,都没有达到这一层认识。一个典型例子是,研究行业术语的,还有所谓的语义网,还是停留在对图书检索中使用的上下位概念,集合/元素关系,整体/部分等关系津津乐道,这些关系是概念之间的逻辑关系,是分析命题。这些逻辑分析概念中,没有与行业的任何关系。
    而康德早就指出,我们的全部问题是应该回答:必然的综合语句如何可能?这个关键问题。
    把这个哲学问题进行语言学转向,就是要回答:
    何以一些概念术语它们构成了一个完整的语义框架,可以成为一个行业的本体。
    我现在应该说,已经找到了“在逃犯”的出生户口了,抓到他就不难了。

    • 补充得好。术语学(terminology )当然可以列进去。

      领域专用语言(DSL)这个概念本身就联系着某些悖论。相比之下,“本体”这个概念显得很纯粹和基本。在国外,它代表一个方向。

      (请余山兄注册一个用户,我们可在研讨厅进行内部讨论,也方便编辑评论等等:-)

Leave a Response

You must be logged in to post a comment.