IDC资讯中心
通常有两类形式:模板驱动和模式驱动。
1 模板驱动
在以模板驱动的映射中,没有预先定义文档结构和数据库结构之间的映射关系，而是使用将命令语句内嵌入模板的方法，让数据传输中间件来处理该模板。例如，下面的模板，在<selectstmt>元素中内嵌了select语句：
<?xml version="1.0"?>
<flightinfo>
<intro>the following flights have available seats:</intro>
<selectstmt>select airline, fltnumber, depart, arrive from
flights</selectstmt>
<conclude>we hope one of these meets your needs</conclude>
</flightinfo>
当数据传输中间件处理到该文档时,每个select语句都将被各自的执行结果所替换，得到下面的xml格式:
<?xml version="1.0"?>
<flightinfo>
<intro>the following flights have available seats:</intro>
<flights>
<row>
<airline>acme</airline>
<fltnumber>123</fltnumber>
<depart>dec 12, 1998 13:43</depart>
<arrive>dec 13, 1998 01:21</arrive>
</row>
…
</flights>
<conclude>we hope one of these meets your needs</conclude>
</flightinfo>
这种以模板驱动的映射可以相当的灵活。例如,有些产品可以允许你在任何结果集合中替换你想要的内容(包括在select中使用参数),而不是象上面的例子中简单地格式化结果。另外它还支持使用编程来进行构造，例如循环和条件判断结构。还有一些还支持select语句的参数化，例如通过http来传递参数。
目前，以模板驱动的映射只支持从一个关系型数据库转换成xml文档的情况。
2 模型驱动
在以模型驱动的映射中,利用xml文档结构对应的数据模型显式或隐式地将映射成数据库的结构，而且反之亦然。它的缺点是灵活性不够，但是却简单易用，这是因为它是基于具体的数据模型来进行映射的，通常能够为用户实现很多地转换工作。由于将数据从数据库转换成xml的结果依照了单个模型,
因此通常在这种方式下通常结合xsl来提供模板驱动的系统中所具有的灵活性。
在xml文档中的数据视图通常有两种模型:表格模型和特定数据对象模型。有时候也可能会出现其他的模型。例如，通过采用id和idref属性，一个xml文档可以用来一个指定的图形。不过，很多现有的中间件并不支持这些模型。
2.1 表格模型
许多中间件软件包都采用表格模型在xml和关系型数据库之间进行转换。它把xml的模型看成是一个单独的表格或者是一系列的表格。也就是说，xml的文档的结构和下面的例子相类似，其中在单个表格的情况下，<database>并不出现:
<database>
<table>
<row>
<column1>…</column1>
<column2>…</column2>
…
</row>
…
</table>
…
</database>
其中的术语"table"可理解为单个的结果集(当从数据库向xml中转换数据时)，或者是一个单独的表格或可更新的视图(当从xml向数据库转换数据时)。如果数据需要来自多个结果集(当数据来自数据库中时)或者与仅仅表达成一系列表格的集合(当转换数据到数据库时)相比，xml的文档包含有更深层次的嵌套元素，那么类似的转换几乎是不可能的。
2.2 特定数据对象模型
xml文档中第二种普遍的数据模型是特定数据对象的树型结构。在该模型中,元素类型通常对应对象，而xml中的内容模型、属性和pcdata则对应对象的属性。这种模型直接映射成面向对象的数据库和层次型数据库，当然借助于传统的对象-关系映射技术和sql
3 从数据库的结构生成dtd及其互逆过程
在xml文档和数据库之间转换数据时，一个普遍问题是：如何从数据库的结构(schema)生成xml的dtd,如果从xml的dtd产生数据库的结构。简而言之，这是非常直接的操作，但是产生的结果通常离许多用户的期望值还有一些距离。
(还要注意这通常是一次性操作，而大多数应用，尤其是所有的垂直性应用都结合了已知的dtd和关系型schema的集合。显而易见的特例是在关系数据库中存储随机xml文档或者将关系型数据发布为xml文档的工具;而在后面的情况中，dtd的作用并不明显。)
对于元素类型中每个有单一数值的属性和只包含有pcdata内容的子元素类型在该table中新建立一列（字段）。如果子元素类型或则属性是可选的，让该字段允许为空。
对于每个有多值的属性或则多仅含有pcdata内容的子元素类型，再建立一个分开的table来保存他们的值，通过它们的父表的主关键字连接到父表。
对于每个子元素，这些子元素本身还有元素或则混合内容，使用父表中的关键字将父元素表连接到子元素表中。
而下面则是一个从关系数据库的结构生成xml文档的过程（简化过的）：
对每个table，新建一个元素。
对表中的每列，建立一个属性或则只含pcdata的子元素
对每个包含有在主键/外键关键字关系中主键值的列，新建一个子元素。
例如，下面的过程(经简化）说明了如何从一个dtd生成一个关系型结构:
对于每种包含元素或者混合内容的元素类型，新建一个表格和一个主键字段。
对于每个包含混合内容的元素类型，创建一个单独的表格，其中存放未析数据，通过父元素主键链接到父表格。
对于此元素类型的每个单值属性和只包含未析数据内容、只出现一次的子元素，在该表格中创建一个字段。如果元素类型或者属性是可选的，可以让设置该字段为空值。
对于每个多值属性和多次出现的子元素，创建一个单独的表格来存储数值，并且通过父元素主键链接到父表格。
对每个有元素或者混合内容的子元素，通过父元素主键将父元素表格和子元素表格相连接。
下面的过程(经简化)说明了如何从一个关系型的结构生成一个dtd:
对于每个表格，新建一个元素；
对于表格中的每个字段，新建一个属性或者是只包含未析数据的子元素；
对于每个表格字段中提供主键的主键/外键的关系都新建一个子元素。
不幸的是，这些过程还存在着一些缺陷。例如，dtd中没有方法预先准确地规定数据类型或者字段长度。
因为任何的预先定义(例如通过读取一个示例文档)在读取其它“类型”的文档或者其他文档中包含有超过字长内容的文档时就会产生错误。(长久之策是使用xml schema文档的数据类型。)简单来说，当从一关系型结构生成dtd时，是没有办法预先判断子元素“应该”出现的顺序或者字段(如数据库内部的行标识)是否该进行完全转换。
在以上两种情况中都可能产生命名的冲突。
尽管有这样那样的缺陷，但是这些方法仍然能够很好地奠定在关系型结构和dtd之间互相转换的起点。
