1.1.1.       从对象模式到数据库模式的映射

对象关系型映射的第二部分中，类被映射为基本表（称之为类表），标量属性被映射为列，指针与索引属性被映射为主/外键关系。例如：

     Classes                     Tables

   ============             =================

   class A {                Table A:

      String b;                Column b

      C      c;     ==>        Column c_fk

      String f;                Column f

   }

   class C {                Table C:

      String d;     ==>        Column d

      String e;                Column e

   }                           Column c_pk

我们注意到上面的基本表由主键（C.c_pk）和外键（A.c_fk）连接。由于主元素与子元素间的关系是一对一的，所以主键也可以映射到任一基本表中。如果二者关系是一对多的，主键必须在两表中的“一个”中，无论其是否为子元素或父元素。例如，如果SalesOrder元素含有复合的Item元素，那么主键必须映射到SalesOrder（父元素）表中。但是如果每个Item元素含有一个Part元素，主键必须映射到Part（子元素）表中，因为一个part元素可以出现在多个项目中。

我们在映射递归出现的元素时，可以使用主外键关系。例如，你定义了如下元素类型;

   <!ELEMENT A (A?, B, C)>

   <!ELEMENT B (#PCDATA)>

   <!ELEMENT C (#PCDATA)>

在这个例子中，A可以视为其自身的子元素。对A的映射，与对其他复合元素引用的映射原理一样，这里可以使用主/外键关系。在递归的情况中，唯一不同的时外键与主键指向相同的基本表。例如，元素A可以被映射为如下的类中：

   class A

   {

      A      a; // Nullable

      String b;

      String c;

   }

而后，映射到如下基本表中，该基本表中a_fk为指向含有子元素A的列的外键。

   Table A

   =======

   Column a_pk

   Column a_fk

   Column b

   Column c

         主键列的来源有二。其一，如上例所示，主键可以视为映射的一部分。其二，已存在的一列或几列可以被视为主键。例如，若SalesOrder元素类型含有一个子元素Number，该元素类型可以被映射为主键列。

         若主键列被创建为映射的一部分，他的值必须由数据库或数据转换软件构造。针对这一点，更好的数据库设计方案取代了用数据列作为主键，但在使用XML时仍旧存在缺陷，即，创建的关键字字段往往在源数据外没有具体含义。因此，当存在生成主键的数据被转换到XML文档中时，要么存在一个没有具体含义的主键（如果主键值被转换），要么根本不存在主键（如果关键字没有被转换）。在后者的情况中，重新定义源数据时不可能的，如果数据被更新并作为XML文档返回到数据库中，这将会是一个不容忽视的问题。

1.1.2.       后记

在我们讨论更加复杂的映射步骤前，我们需要提及几件事情。首先，名称在映射中可以改变。也就是说，DTD，对象模式，关系型模式均可以使用不同的名字。例如：与类相比，下面的DTD使用了不同的名字：

                DTD                                   Classes

   ===============================             =====================

   <!ELEMENT Part (Number, Price)>             class PartClass {    

   <!ELEMENT Number (#PCDATA)>         ==>        String numberProp;

   <!ELEMENT Price (#PCDATA)>                     float  priceProp;

                                               }

相对于基本表，它同样使用了不同的名字：

         Classes                           Tables

   =====================             ==================

   class PartClass {                 Table PRT

      String numberProp;     ==>        Column PRTNUM

      float  priceProp;                 Column PRTPRICE

   }

其次，在应说过程中，数据类型可以被改变。即，DTD，对象模式，和数据库模式均可以使用不同的数据类型。例如，下面的DTD与相应的类相比，对Price元素使用了不同的数据类型：

                DTD                                   Classes

   ===============================             =====================

   <!ELEMENT Part (Number, Price)>             class Part {   

   <!ELEMENT Number (#PCDATA)>         ==>        String number;

   <!ELEMENT Price (#PCDATA)>                     float  price;

                                               }

与相应的基本表相比，使用了不同的数据类型：

         Classes                           Tables

   =====================             ==================

   class Part {                 Table Parts

      String number;     ==>        Column number VARCHAR(50)

      float  price;                 Column price DECIMAL(10,2)

   }

这种不同所需的是数据类型间已经定义的转换规则。尽管会有精度的损失问题有限，这种做法并不值得鼓励。最后，在映射过程中引入的对象是概念层面上的。即，当在XML文档与关系型数据库间转换数据时，并不需要实例化对象。（这并不意味着对象不能被实例化。是否需要实例化对象具体要视实际应用而定。）

1.1.        基本映射

构造对象关系型映射需要两个步骤。首先，一个XML模式（以DTD为例）被映射到对象模式，然后对象模式被映射到数据库模式。这两个映射可以任选其一，组合成一个直接的DTD到数据库的映射，这种做法被当今大多数软件所使用。

考虑如下这个例子，映射所使用的对象对每一个DTD模式都是特定的，而非从DOM中得到的对象。实际上，这些对象在XML文档中模仿数据，同时，DOM模仿XML文档结构。举个例子，下图表示一个数据具体型对象的对象树和DOM，二者可以由上文中的XML文档样例构造：

    SalesOrder                  Document

     /      \                       |

   Item    Item                  Element_______

                          ______/ /  \ \______ \_________

                         /       /    \       \          \

                    Element  Element  Element  Element   Element

                       |        |        |    /  |  \ \    etc.

                     Text     Text     Text  /   |   \ \_______

                                            /    |    \        \

                                      Element Element Element  Attr

                                         |       |       |       |

                                       Text    Text    Text    Text

当你考虑数据是如何在数据库中存储时，这一差别将极其重要。当存储数据具体型对象时，你需要得到SalesOrders 和 Items两个基本表；当存储DOM对象时，你需要得到Document, Element, Text, 和Att这几个基本表。二者最重要的区别在于非XML应用可以使用数据具体型基本表而不能使用DOM具体型基本表。

1.1.1.       从DTD到对象模式的映射

映射首先识别元素类型就是数据类型。元素类型中的PCDATA只读内容被称作简单元素类型；这一术语借鉴于XML模式。这种元素类型拥有一个单独的数值，它等同于面向对象编程语言中的标量数据类型。（请注意这里的“标量”意为由单一数值构成。在一些语言中，“标量”数据类型——在有些情况下用“对象”表示。最明显的例子是JAVA语言中的String数据类型）。属性类型同样也是简单类型。

那些拥有有元素或者复合内容的，或还拥有属性的元素类型被称为复合数据类型；该术语同样借鉴于XML模式。这种复合数据类型拥有结构性的值，它等同于面向对象编程语言中的类的概念，或等同于C语言中的结构概念。请注意一个拥有空内容但有属性的元素类型仍旧是复合元素类型。其原因是属性值同样提供结构并且其近似于PCDATA只读的子元素。

对象关系型映射首先将简单类型映射到标量数据类型。据个例子，元素类型Title可以被映射成一个字符串值String，元素类型可以被映射成一个浮点类型值float。然后将复杂类型映射到类，在复合类型的内容模型中的每一个元素类型被映射到类中的一个属性值。每一个属性值的数据类型就是映射所涉及的元素类型。例如：对Title元素的引用可以被映射成一个字符串String类型属性值，对Price元素的引用可以被映射成一个浮点类型float属性值。对复合元素的引用，通常可以被映射成为该复合元素被映射成的类中的一个对象的指针或索引。

映射的最后步骤就是将属性值映射成为特性值，特性值的数据类型由属性值的数据类型决定。请注意：属性值类似于在内容模型中对元素类型的引用。这是因为，属性值就像内容模型中的引用一样，对于给定的元素类型是局部的。唯一概念上的不同是属性类型是局部定义的，而非像元素类型那样是全局层面上定义的。（如DTD）

例如，下面的例子中简单元素类型B、D、E和属性F都被映射成String，复杂元素类型A、C被映射到类A和类C中。内容模型及A和C的属性被映射成为类A和类C的属性。在内容模型里，对A和C中的B、D、E的引用被映射为String特性（因为B、D、E均被映射为String类型），属性F同样被映射成String特性。在A的内容模型中，对C的引用被映射为一个类型指针所指向的类C的一个对象，因为元素类型C被映射为类C。

              DTD                         Classes

   =========================           =============

   <!ELEMENT A (B, C)>                 class A {

   <!ELEMENT B (#PCDATA)>                 String b;

   <!ATTLIST A                  ==>       C      c;

          F CDATA #REQUIRED>              String f;

                                       }

   <!ELEMENT C (D, E)>                 class C {

   <!ELEMENT D (#PCDATA)>       ==>       String d;

   <!ELEMENT E (#PCDATA)>                 String e;

                                       }

在这里需要反复强调的一点是，在内容模型中对元素类型引用的映射，与映射元素类型本身是不同的。元素类型映射为数据类型，然而元素类型引用则映射为结构化数据类型（类）的特性。当你考虑一种元素类型被两种不同内容模型所引用时，上述的不同就显而易见了。既然如此，每个引用必须被单独的映射，根据元素类型被映射为何种数据类型而决定结果特性的数据类型。

例如，注意下面例子中Title和Section两个元素类型。在Chapter和Appendix两个内容模型中都引用了Title和Section两个元素类型。每个引用所涉及的元素类型都被单独的进行映射。Chapter中Title的引用（即 类特性）被映射为String类型，这是因为，Title元素类型只含有PCDATA，并且其被映射为一个字符串String。Chapter中Section的引用（即 类特性）被映射为一个Section对象，这是因为Section元素类型是一个复合元素类型并被映射为一个Section类。

                     DTD                                      Classes

   =========================================               =============

   <!ELEMENT Chapter (Title, Section+)>                    class Chapter {

   <!ELEMENT Appendix (Title, Section+)>          ==>         String    title;

   <!ELEMENT Title (#PCDATA)>                                 Section[] sections;

   <!ELEMENT Section (#PCDATA | p | b | i)*>               }

                                                           class Appendix {

                                                              String    title;

                                                              Section[] sections;

                                                           }还有一点需要强调，简单元素类型及属性可以被映射为除String以外的其他数据类型。例如，一个名位Quantity的元素类型可以被映射为一个整形数据类型（integer）。当从一个DTD中进行映射时，需要人们的手动干预，因为我们不可能由一个PCDATA只读元素类型推测我们所需的目标数据类型。但是，当从一个XML模式中进行映射时，目标数据类型就是可知的，因为XML模式本身含有数据类型。

从DTD到数据库的映射    

翻译：张以维  邮箱：vane914@126.com

Copyright (c) 2000-2005 by Ronald Bourret

来源：http://www.rpbourret.com/xml/DTDToDatabase.htm

内容概要

1           总述

2           基于表格的映射

3           对象－关系型映射

3.1          基本映射

3.1.1     从DTD到对象模式的映射

3.1.2     从对象模式到数据库模式的映射

3.1.3     后记

3.2          复杂内容模型的映射

3.2.1     映射顺序

3.2.2     映射选择

3.2.3     对重复子元素的映射

3.2.4     对可选子元素的映射

3.2.5     对子组的映射

3.3          组合内容的映射

3.4          映射次序

3.4.1     同属次序、等级次序、文档次序

3.4.2     同属次序的映射

3.4.2.1    次序特性与列值

3.4.2.2    次序在映射中的存储

3.5          映射属性

3.5.1     单值、多值属性的映射

3.5.2     ID/IDREF的映射

3.5.3     符号属性的映射

3.5.4     ENTITY/ENTITIES属性的映射

3.6          交替映射

3.6.1     从复杂元素类型到标量类型的映射

3.6.2     从复杂元素类型到XML列值的映射

3.6.3     从标量特性到属性表的映射

3.7          总结

4           模式的生成

4.1          从DTD模式生成关系型数据库模式

4.2          从数据库模式中生成DTD模式

5           XML模式到数据库的映射

6           相关文章

1.         总述

在XML领域内有一个普遍的问题，那就是如何将XML映射到数据库中去。本文将讨论两种映射：基于表格的映射和关系对象型（基于对象）的映射。两种映射将数据模仿在XML文档中，而并非局限于文档本身。这样的映射为以数据为中心的文档提供了一个很好的选择，而对以文档为中心的文档则不然。（基于表格的映射根本不能应付复合内容，而复合内容的对象关系型映射又是极其没有效率的。）

用于在XML文档与数据库间（特别是关系型数据库）转换数据的软件一般都是基于上述两种映射原理。这种关系的一种重要特性就是双向性。即，映射即可以将数据从XML文档中转移向数据库，又可以将数据从数据库中转移向XML文档。这一特性使得映射可以做为规范映射，作用于可以构建XML查询语言的非XML数据库。即，规范性映射将定义虚拟XML文档，该文档可以被诸如XQuery等语言查询。

除了用于在XML文档与数据库中转换数据外，对象关系型映射还用于“数据绑定”，即在XML文档与对象间进行数据编组与反编组。

2.         基于表格的映射

以下是一个典型的XML文档与表格间的映射例子：

   <A>                    

      <B>

         <C>ccc</C>             Table A

         <D>ddd</D>             -------

         <E>eee</E>          C     D     E

      </B>                  ---   ---   ---

      <B>             <=>   ...   ...   ...

         <C>fff</C>         ccc   ddd   eee

         <D>ggg</D>         fff   ggg   hhh

         <E>hhh</E>         ...   ...   ...

      </B>

   </A>

该映射为基于表格的映射。它将文档看作一个单独基本表格或一组基本表格的集合。即，文档结构为二者其一。

   <Table>

      <Row>

         <Column_1>...</Column_1>

         ...

         <Column_n>...</Column_n>

      </Row>

      ...

      <Row>

         <Column_1>...</Column_1>

         ...

         <Column_n>...</Column_n>

      </Row>

   </Table>

或:

   <Tables>

      <Table_1>

         <Row>

            <Column_1>...</Column_1>

            ...

            <Column_n>...</Column_n>

         </Row>

         ...

      </Table_1>

      ...

      <Table_n>

         <Row>

            <Column_1>...</Column_1>

            ...

            <Column_m>...</Column_m>

         </Row>

         ...

      </Table_n>

   </Tables>

声明：列值可以表示PCDATA只读元素或属性。

这种映射的明显优点是简单且便于理解。因为该映射关系符合关系型数据库的基本表与结果集的结构，并且基于此映射关系的代码书写也非常简单。以上代码执行效率高且可测量性好，并且对于在数据库间一次转换一个基本表的应用而言非常有益。

但该种映射存在一些缺陷，最值得注意的就是该映射关系只能应用于XML文档中非常小的一个子集。此外，该映射不能保存物理结构（如字符和实体引用，CDATA片断，字符编译，或者永久声明）、文档信息（如文档类型或DTD）、注解或处理说明等。

       尽管基于表格的映射存在局限性，但它还是被广泛应用，如，被用于中间件（在XML文档与关系型数据库间进行数据的转换）、网络应用服务器及支持XML的数据库（用于返回XML结果集）及很多自制应用中。该映射的一个重要用途是在关系型数据库中实现XQuery查询功能，每个基本表以虚拟的XML文档形式被处理，并通过XQuery语言被查询检索。