分布式数据库的数据模型对应形式与相容性

关系模型的基本概念是关系、元组和属性。可以将一个关系看成是一张二维表，表的每一列称为属性，每一行即实际内容，称为元组。标准关系模型中，属性类型是有限制的，如限制String、Integer等。元组的结构由数据定义语言（DDL）定义，存取则由数据操纵语言（DML）负责。

面向对象概念里，所有实体称为对象，且它们是类的实例。对象的结构和行为是通过其所属类上定义的一组性质和方法来确定的。性质的类型可以是任意一种基本型（如String、Integer），也可以是复杂的型（如Array、List、Set等）。方法是存取性质的唯一接口。

可以给出以下对应形式。

●关系（relations）和类（classes）对应。

●属性（attributes）和性质（properties）对应。

●元组（tuples）和实例（instances）对应。

那么，我们碰到的第一个问题是如何将关系模式中的关系定义翻译成面向对象模式中的类定义。第二个问题是如何把关系模型中的数据映射成面向对象数据模型中的数据。后者比前者更复杂。

如果将面向对象数据模型作为一个全局数据模型，且存放在外部数据库系统里的信息可以映射为全局对象数据库里的对象，就有必要为它们赋予全局唯一的标识，要构造全局标识到外部数据库的本地标识的映射。

1.从关系模式映射到面向对象模式

如何将关系模式映射到对象模式，称为正向映射。

关系可以映射到类。类中的实例对应相应关系中的元组。关系的每个属性映射到相应类的性质。这种映射只考虑语法变换，而不考虑语义扩展问题。

假设有一个关系数据库模式S=｛R1，…，RN｝，其中，S为一个数据库，且是关系Ri（1≤i≤N）的集合。Ri（ai，1，ai，2，…，ai，k），1≤i≤N是其中一个关系的模式。

可以按如下规则将整个关系数据模式映射到面向对象模式：

∀Ri∈S，∃Ci，ci，j property_of Ci，1≤j≤ki：ci，j corresponds_to ai，j，ai，j attribute_of Ri

这里用了几个联系（relationship），其语义可以从字面理解，例如property_of表示c是类C的性质，corresponds_to表示类的性质和关系的属性对应，attribute_of表示a是关系R的属性。

这个规则说明，对S里的每个关系，都会找到一个类，使得该关系的属性和类的性质对应。

面向对象数据库中的性质ci，j的值是从对应关系数据库的对应属性ai，j导出的，所以必须提供存取ai，j中存放值的方法。为了便于说明问题，可以只考虑读（数据）方法，记作get（a）：v，其中a是对应于该对象代表的元组的属性名。

2.两种数据模型的比较

为了说明关系数据模型和面向对象数据模型间的区别，我们先来看看关系数据模型。在关系数据模型里，数据存放在表里，表的属性用基本数据类型来定义。我们常将此称为第一范式（1NF）。对这种表再作一些限制，形成关系的2NF或3NF。规范化的过程是一个原始关系的分解过程。分解是为了获得查询结果而必须实施关系间的连接运算。

面向对象数据模型和关系数据模型的比较如表15.2所示。

表15.2　面向对象数据模型和关系数据模型的比较

①BCNF（Boyce-Codd Normal Form，Boyce-Codd范式）

3.如何重构复杂值

下面用例子来说明如何重构复杂值。

【例15.6】 令R1（a，b）为一个关系，a为其主键；R2（a，c，d）为另一个关系，其中a为其外键。假设关系R2在其他上下文中不出现，即R2中不存在其他外键，也不存在将R2的键作为外键的情况。把这两个关系组合起来到一个类，结构可以表示如下：

C（a，b，t：｛［c，d］｝）

这里C的第三个性质t是一个集合（［c，d］），原因是R2中的几个元组对应于R1中的一个元组。这个集合里的元素是元组，以维持R2中c和d间的依赖关系。

在映射中，可以将关系R1称为基关系（base relation），因为其中包含主键，将R2称为依赖关系。当有几种依赖关系时，会发生两种情况：存在其他关系包含基关系的主键作为（唯一的）外键，或者存在关系拥有外键其中包含依赖关系的主键。前者可以用集合值表示性质，后者可以用嵌套的复杂值表示性质。我们用例子来说明。

【例15.7】 R1（a，b）和R2（a，c，d）的定义如前，R3（a，c，e）为另一个关系，其主键为a，R2的主键c为其外键。假设关系R2和R3在其他上下文中不出现。下面是这三个关系组合成类的形式：

C（a，b，s：｛［c，d，t：｛e｝］｝）

这样就可以从关系中重构一个类，这个类可以理解如下。

类C有三个性质：a、b和s，赋予a和b原子值；s为一个集合，这个集合里的每个元素是一个三元组，分别为c、d和t，t是一个集合。

例15.6中类的读对象方法可以记作：

get（R，｛keyattr｝，［attr］）：｛［attrval］｝

其中：R是一个依赖关系；｛keyattr｝是基关系的主键集；［attr］是希望检索的属性值的元组。例如，get（R2，｛a｝，［c，d］）：｛［c，d］｝发送给类C的一个实例，它对应于R1中的一个元组，返回的是R2中适当的元组集。

可以采用一个通用的记法：

get（〈［R，｛keyattr｝］〉，［attr］）：｛［attrval］｝

使用基于参考（即指针）的联系替代基于值的联系。

【例15.8】 令R1（a，b）为一个关系，其主键为a；R2（a，c，d）为另一个关系，a为其外键。假设R2为其他上下文所需要的关系（例如R2里还有其他外键），而我们无法将这两个关系映射到一个类。这样，面临多种选择，如下。

选择1 C1（a，b，r：｛ref C2｝），C2（a，c，d）；

选择2 C1（a，b），C2（a，c，d，r：ref C1）；

选择3 C1（b，r：｛ref C2｝），C2（a，c，d，s：ref C1）；

选择4 C1（b，r：｛ref C2｝），C2（c，d，s：ref C1）。

这里，ref C表示指向（参考）类C的一个实例，即指向对象标识。同理，我们把关系R1称为基关系，因为主键在其中；R2称为依赖关系。

以选择1为例，它表示将这些关系映射成两个类C1和C2，C1是一个复杂类，其性质有三个：a、b和r，r是一个指针集，每个元素指向类C2里的对象实例。C2则是由关系R2的三个属性（都是原子值）构成的类。

类似地，我们可以提供新的存取方法：

get（Rd，｛keyattr｝）：｛ref Cd｝（get（Rb，｛keyattr｝）：ref Cb respectively）

这里，Rd是依赖关系，｛keyattr｝是基关系Rb的主键集，ref Cd（ref Cb）是指向对应于依赖关系（基关系）的类Cd（Cb）的实例的指针。

这个方法可以理解如下，如果要读一个对象，则包含两个参量：基关系的键和依赖关系（这里记作Rd），据此分别读取基关系和依赖关系里的值。

【例15.9】 R1（a，b）、R2（a，c）和R3（c，d）的定义如前。其中，R2的作用仅在R1和R3之间建立联系，因此可用如下形式来表示：(www.chuimin.cn)

C1（a，b，r：｛ref C3｝），C3（c，d，s：｛ref C1｝）

这里，类C1和C3对应关系R1和R3。为了有效实施前面例子的映射，我们必须提供更普适的存取方法，其形式如下：

get（〈［R，｛keyattr｝］〉）：｛ref C｝

关系的键属性在这里作为变元表出现。

4.模式重构

前面讨论了关系数据模型向面向对象数据模型的转换，但没有讨论具体元组向具体对象的映射，下面对此进行讨论。

可以从一个关系模式集S=｛R1，R2，…，Rd｝中选出一个子集S′。对S′中的每个关系R，可以定义一个相应的类C。显然，类C的外延和R的外延一一对应，即对R中的每个元组，生成C中的对象。存放在关系R∈S\S′^[10]里的数据可以用复合存取方法来存取。

面向对象数据模型里，OID是对象的唯一标识。关系数据库里的标识机制是基于键值的。将键值映射到OID是一件复杂的事。要注意的是，面向对象数据模型里的OID是不变的，而关系数据模型里的键值是可变的。

当为一个关系生成类时，必须为关系中的每个元组创建一个OID。下面讨论相关策略。

数据库初始化时就生成类的实例，在添加或删除关系中的元组时，要在相应的视图中反映出来。

按要求生成类的实例时，也要生成相关的方法，以便能将关系数据库的查询触发对类中实例的存取。

注意，如果OID是从键值导出的话，那么关系数据库中的键值变化要传递给面向对象数据库里的对象标识。

还要注意如何将关系数据库里的属性在对象实例里表示出来，有以下几种可能。

●当数据库初始化时将所有属性存储为类的性质，从而使得关系数据库里属性的所有变化都要传递给类实例的性质。

●属性值存储在类的性质值里。

●关于属性值的访问都通过方法实现。

5.面向对象数据建模语言

当将关系型数据转换成面向对象数据时，面向对象数据建模语言很重要。下面以VML为例来介绍面向对象数据建模语言，VML是VODAK系统定义的建模语言。

1）对象类型、数据类型和继承

（1）对象类型。

如前所述，类型（型）用于描述对象的结构和程序行为，这是一种抽象数据类型，称为对象类型（object types）。每个对象类型的定义有一个唯一的型标识来定义。对象类型的定义包括性质定义集和方法定义集。每个性质定义包括性质的名和类型。每个方法定义用方法名（signature）及其实现来描述。

性质可以定义为公共的，也可以定义为私有的。私有性质只在对象类型定义的范围内有效。公共性质可以在对象类型外被访问。方法也可定义为公有与私有。

（2）数据类型。

数据类型（data types）用于定义性质、形式参数，方法的结果可以是基本类型（primitive type），也可以是复杂类型（complex type），后者是在前者的基础上构造的。

（3）继承

在VML中，对象类型可以通过特指的方式从其他对象类型导出。导出的对象类型称为子型（subtypes），反之，其原型则称为超型（supertypes）。VML用subtypeOf表示特指。

2）对象、类和实例

（1）对象。

对象代表现实世界物质或非物质的实体。对象由对象标识符OID来标识。

（2）类和实例。

系统里的每个对象定义为某个类的实例。这些对象的结构性质和方法通过与类关联的实例类型（instance-type）来定义。

在VML中，并不把类看作为一个型，而是看作为一个对象，它具有如下特点。

（a）汇集其所有的实例；

（b）与对象类型关联，其关系可记作instance-type-of于该类。

6.元类

若把类也看作为对象，那么它们也是其他类的实例，这种类称为元类（metaclass）。元类是类的抽象，用于描述这些类的共有性质。这样，我们可以形成一个3级体系：实例级，由类的实例构成；类级，由类对象构成；元类级，由类的元类构成。

一个元类（也是类）的实例的共同性质由其实例类型（instance-type）来定义。此外，几个类的实例的共同性质可以在元类级来定义，即这些类的元类通过instance-instance-type来定义。换言之，可以在“祖辈”里描述共同性质。其他单独的性质和方法则可以在（元）类级通过对象类型来添加，这个对象类型称为own-type。

粗略来说，任意对象的结构和行为可以确定如下。

●和对象（如果它同时也是一个类）相关的own-type。

●和对象的类相关的instance-type。

●和对象的元类相关的instance-instance-type。

注意，这三个类型可以是其他类型的子型，所以不仅拥有这些型直接定义的性质和行为，还有从其超型继承来的性质与行为。

如图15.3所示，元类M用于定义类及其实例的共同性质。类C1和类C2按其定义可保证具有与元类M相关的实例类型指定的行为。C1和C2的实例有不同的接口，因为与C1和C2相关的实例类型指定的定义有所不同。但是，这些接口有一个公共部分，对应于元类M的instance-instance-type指定的定义。初始对象和类结构由一些预定义的元类及其对象类型构成（包括元类）。

图15.3　元类决定类及其实例的结构与行为

由图15.3可以看到两个层面，类层与元类层。类层的概念类似于面向对象的概念，元类描述的是类的抽象。

7.消息传递和方法的执行

按照经典的面向对象概念，对象的性质只能通过执行定义在该对象上的方法来实现。而方法的执行是通过向对象发送消息来调用的，可以记作obj→m（args）。其语义可以表述如下。

●若方法m定义在对象obj上，则使用消息和实际参数args进行调用。

●若方法m并非定义在对象obj上，则执行消息obj→NoMethod（m，args），将方法m及其参数传递给用户指定的方法No Method。方法No Method的实现决定了方法m的未来执行。