通常有两类形式:模板驱动和模式驱动。
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之间互相转换的起点。
