这是一个比喻的用法，用于描述不同的系统使用不同的数据模型导致的数据不能很好的在系统之间流动的问题。

首先从阻抗失调的本意说起。这原本是一个电学的概念。简单的例子就是，一个220V，15W的灯泡在110V电压下不能最高效的工作，因为电流不能以最高效的方式流动。

同样，当数据在使用不同的模型的系统之间流动的时候，由于不同的模型描述能力不同，往往也不能很好的流动。一个典型的例子就是关系数据库到面向对象应用之间的数据流动。为了实现比较好的流动，用户往往需要编写大量的包装代码，或者说映射（比如ORM）。这种映射也指出了解决阻抗失调问题的方法——使用描述能力强的映射来提高数据流动的效率。当然这里的效率不仅仅是系统执行的效率，更多的包含了开发效率——构建这种映射总是很麻烦的。并且随着数据库系统的复杂度和软件系统的复杂度不断提升，这种映射往往变得十分复杂。那么如何进行有效的映射呢？

想吧，想出来就牛B了。

当然，这并不是说我对语义网或者RDF标准存在质疑。我是说，如果想把语义网推向应用，是否应该存在一种入门门槛更低的东西来帮助推广应用。其实建模应该是一个相对简单的过程，就像用面向对象语言书写类那样，是否RDF也能那么简单和容易。或者出现一种类似XAML那样的中介语言，通过他们进行比较容易的编写，然后再使用标准工具转换成RDF。毕竟，简单才是美好的。

今天读了Arnon Resenthal的Pragmatics and Open Problems for Inter-schema Constraint Theory。里面的Comparing DB and AI Mediation Approaches to Data Exchange和Unifying Data Exchange Theory and Business Objects' Update两个小结给我印象深刻。

前面一小节对比了数据库领域常用的数据映射方法和人工智能领域常用的信息集成方法进行数据集成的比较。看了之后才发现自己已经忘了原本我是搞信息集成的了。数据库领域的模式集成，模式映射方法把模式处理为一些对象。方法根据对象的特征进行处理，得到需要的信息，并用这些信息和其他的模式进行匹配进而进行为数据级别的应用提供支持。而信息集成方法则似乎更人性化一些，由于本体本身已经具有了相当的信息，处理方法似乎也不会把所要处理的本体当成模式一类的对象，而是更多的考虑本体自身的特点并且映射他们到全局本体。其实无论是模式匹配和映射还是本体匹配和映射，他们最终处理问题的方法都是类似的，只不过数据库可能还需要自己构建全局模式，而人工智能则需要更多的考虑各个本体自身的一些信息。不过由于我一贯对本体的印象比较好，因此总感觉本体的方法看起来更COOL一点。

而对于Business Object到模式的映射和更新，文中描述的内容似乎距离现实具有一些距离。毕竟，在ActiveObject以及LINQ这类相当好用的ORM映射工具的帮助下，开发者开发数据驱动应用已经相当容易了。不过文中似乎更倾向于从数据库理论的角度出发，描述如何让Business Object 更好的支持数据库的诸多约束。这种约束从一定程度上描述了业务规则以及业务行为。很有趣，不过思路还理不清，毕竟进入这行时间太短，软件开发又离开一段时间了。

胡言乱语一番，自己都没有想明白，呵呵。Data Exchange，说到底还是数据啊。

我靠……，太牛了，不愧是外国人……

整体模式匹配和传统的模式匹配方法不同。传统的模式匹配方法一般只会考虑被匹配的模式的信息，比如元素的名字，相关描述，关系重复模式和所包含的数据等等。这样做的问题是由于模式本身是十分简洁的，那么几个模式所蕴含的信息可能根本不足以提供足够的线索来进行匹配。因此，整体模式匹配被提出了。整体模式匹配把大量的模式作为一个整体进行模式匹配，能够比较充分的利用各个模式所蕴含的信息，因此可以取得比较好的结果，当然是相对传统的方法来说。

具体的内容还没有研究，不过据我所知整体模式匹配更多的使用的是基于统计方法的数据挖掘技术。就我浅显的认识来看，更多的应该是仅仅利用了文本聚类技术。至于怎么利用其他的信息，还需要看看的说。

写这篇日志的时候我才想起来，整体模式匹配的方法采用的技术和过去的方法差距比较大，是不是应该对已经写好的文章的部分进行一些修改来适应这个方法。嗯，应该应该。

模式转换的目的是将使用不同数据模型描述的模式转换为使用公共数据模型描述的模式。这样做的好处是减低模式匹配过程中的复杂度，让模式匹配过程可以专注于处理使用相同数据模型描述的异构模式，而不需要处理不同的数据模型带来的麻烦。

模式映射的主要价值在于查询转换（Query Transformation），也就是把集成模式上的查询装换为被集成模式上的查询。

模式集成过程中得到模式映射并不是一个单独的过程，而是伴随着把被集成模式转换为统一格式的过程和把被集成模式集成到集成模式的过程的同时得到的。前面的过程得到了全局模型到本地模型的映射，而后一个过程得到了全局对象到本地对象的映射。

首先需要说明的是，这个所说的框架、模型和模式都是在看研究性论文的时候经常提到的概念，可能和软件工程领域的对应概念并不完全一致。并且因为水平有限，我的理解也可能是不正确的。

首先说说框架。所谓框架，应该就是一种处理流程。典型的框架可能是下面这样的：

这个图片可能看不清楚，不过不重要。框架就是一个解决某一个问题的处理流程。我们熟悉的ASP.NET框架，Rails框架也都是这类的框架——他们解决的是如何搭建web应用的问题。ASP.NET和Rails都规定了一系列的处理流程，从获得用户请求，到把请求定向到适当的类，如何调用用户定义的函数处理问题，再到把处理结果发送给用户。

所谓模型，是一种描述问题的工具。这里需要注意的是我所说的模型并不是所谓“数学建模”、“软件建模”得到的模型，而是另外一种模型，比如对象模型，关系模型等等。这类模型是一些规定，这些规定描述了如何去描述一个概念，同时还规定了一系列的操作，这些操作描述了概念之间如何进行交互。比较典型的就是关系模型，他描述了使用很多很多的属性（数据库字段）来描述一个概念（数据库表），以及这些概念之间的关系，比如Union（对应union操作符），Project（对应select columnname from tablename）等等。模型是一种工具，他是用来帮助人们记录和分析问题的。其他的常用模型还包括对象模型，UML模型等等。

最后是模式。可以认为使用模型建模得到的东西就是模式，比如一个数据库设计，一个软件类设计等等。需要注意的是虽然MySQL管他的数据库叫做模式，但是一个运行中的数据库并不是一个模式，而是一个模式的一个具体实例。因为同一个模式可以有很多个实现，比如Northwind数据库在很多人的机器上都有，但是都是用的Northwind数据库模式。

这里的模式是所谓的Schema，而不是设计模式所谓的Pattern。Schema是用来描述概念和概念之间关系的，而Pattern更多的用于描述概念实例之间的关系，比如某些数据具有一些特定的模式（Pattern），比如电话号码总是【区号-号码】这种模式。另外还有一些被称为模式的东西既不是Schema又不是Pattern，今天吃晚饭的时候还在想这个问题，现在忘了……