营销有声读物:对象与关系之间的矛盾：“阻抗失配”效应

Count()方法得到所有满足下面条件的Owner数：
Select Count(*) From CarOwners Where CarOwners.Fkey_Car=Car.CarID AND Car.VIN=:vin)

Get（index）方法得到所有满足下面条件的Owner的Name：
Select Person.Name
From Car, CarOwners, Owner, Person
Where CarOwners.Fkey_Car=Car.CarID
And CarOwners.Fkey_Owner=Owner.OwnerID
And Owner.Fkey_Person=Person.PersonID
其他“阻抗失配”效应的复杂度

在混合使用面向对象应用和关系型数据库时，还需要考虑到以下的几个问题。

需要将类转换为一个或多个底层的表格

这个任务是将类中的每一个属性对应成为表格中的列。如果类和表格能够一一对应的话，这种转换就十分简单，但是大多数的对象模型都需要把多个表格进行分解，并从中抽取一部分作为类的属性。还可能有很多类都会映射到相同的表中并根据自身类的需要对表的语义进行解释（这就需要一个新列用来存放类名及其作用的行）。

ID生成——生成对象ID并将其插入关系数据库

对象ID的生成过程十分重要，在关系数据库中通过Save()方法生成不重复键时需要Object ID。在一一对应的类与表之间，最好的方法就是使用关系数据库引擎生成一个ID号，并将它作为对象的ID。但是一个类可能会跨越多个表，它的Save()方法可能会需要把多个关系ID作为一组来调用。生成的ID必须是持久性的，这样才能在打开对象时获取表中的行来生成实例。因此，为了维护对象ID和关系ID的联系必须另外创建一个表。

值的检验

如果原先基于SQL，使用关系数据库的应用采用外部数据检验的方式，那么应用的数据检验代码就不需要进行改动而直接用到面向对象应用中来。

手动编写持久性代码与操作的顺序

你必须对数据在应用级的完整性有足够的认识。如果你要实现Save()方法，其内部包括的操作（插入，更新，删除）必须遵守特定的顺序才能保证应用级的数据完整性。

注意并发性

会对应用级数据完整性产生影响的另外一个因素是应用访问的并发性。你必须确定关系数据库提供的数据锁定级别与类的方法中对数据的锁定能够协调一致。

注意模式的演变

因为使用到了对象－关系映射，所以必须注意对象模式和关系模式在演变的同时能否保持映射的同步。对象模式和关系模式之间在发展时可能存在的不协调性会使得这种同步变得十分地复杂。

保证两种应用都能使用

前面提到的问题都取决于原来的应用和新开发的面向对象应用能否同时协调地运行关系数据库上。

市场提供的解决方案

在市场上通常有四种方法来处理“阻抗失配”问题。

使用关系数据库的面向对象功能

使用对象－关系映射工具

采用对象数据库

采用后关系型数据库

1. 使用关系数据库的面向对象功能

虽然关系数据库提供商为在他们的数据引擎中添加面向对象的功能做出了很大的努力，但是他们到现在为止仍然没有从根本上解决“阻抗失配”这个问题。他们提供的方案没有一个用真正的面向对象概念实现。在很多的情况下，他们自己就会陷入自相矛盾的窘境当中。继承，多态和封装这些概念并不是很容易地集成到关系数据库提供商的核心技术当中。最后，开发人员还是被限制在关系数据库之上对类对象层进行管理。

2．使用对象关系映射工具

很多数据库提供商和第三方开发商都提供“对象－关系映射”工具来处理应用中的类与关系数据库中表的联系。这些工具可能会包含一些缓存运行组件用来增强数据库操作（插入，更新，删除，选取和并发需求）的性能和完整性，生成唯一标识ID的方法，为特定语言（JavaBeans，COM对象）生成绑定。这种工具在把关系模式向基于对象的应用转换时十分有效。

但是在问题变得复杂的情况下，这些映射工具这会把责任重新推给开发人员。当需要把多表映射为一个类或多类映射为一个表时和需要生成唯一标识ID时，开发人员还是要负责对象的映射工作。

3．采用对象数据库

处理“阻抗失配”问题的另外一个方法就是采用对象数据库。这种数据库的优势就是它们完全支持OO的概念。

但市场是还有一些顾虑：

对象数据库的市场份额还比较小

向关系数据库提交的事务也应该在面向对象数据库得以实现

基于SQL的应用与关系数据库产品之间存在的“阻抗失配”效应。

还有一个考虑就是终端用户在桌面上运行的决策支持系统一般都是通过ODBC使用SQL查询来与数据库进行互联，因此需要把基于对象的数据按照关系表的方法表示出来。一些面向对象数据库提供商采用在中间层设置关系－对象映射策略来克服这个“阻抗失配”效应。

4．采用后关系数据库

后关系型数据库（即事务型多维数据库）实现了联合数组技术，使用这种技术可以将数据同时映射为对象模型和关系模型。使用后关系型数据库就不再需要其它的对象－关系映射工具和中间层了。InterSystems公司的Caché就是后关系型产品。

在Caché数据库中，类的方法（如前例中的Save()方法）直接映射给对象开发人员，这些方法由数据库中管理联合数组的指令进行实现。同时，Caché数据库引擎可以将相同的数据（联合数组）通过ODBC和JDBC以关系表的方式表示出来。像Insert等SQL数据定义语言，数据管理语言和数据控制语言都能映射为实现对象方法的数据库指令。因为Caché的多维数据引擎能够以两种方式（SQL和对象）实现对数据的直接存取，所以Caché大大消除了前面提到的ID生成，并发访问等问题。

开发人员可以通过两种方式对数据进行直接同步的存取（包括对并发访问的管理），这就意味着不论是基于SQL的应用还是基于对象的应用都可以在Caché上运行，同时，Caché的关系映射功能还可以满足终端用户使用他们喜欢的基于SQL的前端决策支持工具。

结论

我们已经对能够解决面向对象语言与关系数据库之间“阻抗失配”效应的几种方法进行了评述：使用关系数据库提供的部分面向对象支持，使用对象－关系映射工具，采用对象数据库，采用后关系型数据库（事务型多维数据库）。

在对这些技术进行评测时需要考虑到的几点是：

该技术是不是易于掌握，能否与原应用集成以满足立即应用

该技术能否满足未来应用的数据库的需要

该技术是否有足够的灵活性，方便与新兴的技术进行结合，如XML，SOAP等

该技术是否能够允许开发人员在正确的逻辑屋实现其代码，换句话说就是本该在数据库执行的代码是不是必须转移到应用服务器或中间层

该技术能否提供足够的可性能和扩展性

该技术在解决开发问题时是否有用

有一件事我们可以肯定：当今的市场十分清楚的意识到面向对象技术是开发新应用和对原有应用进行升级所必须的技术。已经对关系数据库投入大量资金的企业应该考虑他们是否采取短期，中期长期的迁移计划以消除对象和关系模式之间固有的“阻抗失配”效应。

例1a - 列出Car VINs和他们的所有者：面向对象方法

objCar=Open Car(vin);
owner_count=objCar.Owners.Count()
For (i=0; i      owner_name=objCar.Owners.Get(i).Name;
}

例1b - 列出Car VINs和他们的所有者：SQL方法

Select Car.VIN,Person.Name
From Car, CarOwners, Owner, Person
Where CarOwners.Fkey_Car=Car.CarID
      And CarOwners.Fkey_Owner=Owner.OwnerID
      And Owner.Fkey_Person=Person.PersonID
      And Car.VIN=:vin

例2a - 登记新Car: 面向对象方法

// somehow we acquired the car's VIN, make, model and list of owners
// use a class method rather than an instance method to validate
rc = Car.IsValidVin(vin)
// if rc indicates an error, logic to reject goes here
// now assume an owners[i] array and this is where the logic for validating them goes
// instantiate a new car
objCar = New Car;
// assign the properties
objCar.VIN = vin;
objCar.Model=model;
objCar.Make=make;
// now register the car
objCar.RegisterNew(vin)
// assign the Owners
      For (i = 1; i < count; i++) {
obj.Car.Owners.SetAt[i] = owner[i]
}
// make it persistent
objCar.Save()

例2b - 登记新Car: SQL方法