CN102737033A

CN102737033A - 数据处理设备及其数据处理方法

Info

Publication number: CN102737033A
Application number: CN2011100856812A
Authority: CN
Inventors: 金毅; 张皖川; 李磊; 王莉莉
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2011-03-31
Filing date: 2011-03-31
Publication date: 2012-10-17
Anticipated expiration: 2031-03-31
Also published as: US8719312B2; CN102737033B; US20120254252A1

Abstract

本发明公开了一种用于关系数据库的数据处理设备及其数据处理方法。用于关系数据库的数据处理方法，包括：选定所述关系数据库的至少一个表；将所述选定的至少一个表的每一个按列分割成两个以上的子表，其中至少一个子表包括至少两列；以及，分别将所述子表写成相应的行存储数据库的表。

Description

数据处理设备及其数据处理方法

技术领域

本发明涉及数据库技术，特别涉及一种用于关系数据库的数据处理设备及其数据处理方法。

背景技术

在20世纪70年代即已引入的关系数据库管理系统(DBMS或“关系模型”)是已知的现有数据库管理系统的基础，其通过形式代数及相关联的结构查询语言(“SQL”)的描述查询语言实现各种表中数据的交互。

通常RDBMS根据表中的关系存储模式存储数据，每个表在(例如盘、主存储器或其它存储器等的)数据存储机构中按页被存储为行的序列集合。许多系统进一步还创建作为额外数据结构的索引，以实现对特定一行或多行进行快速的随机访问。

SQL查询使用在两类数据库交互应用中，即OLTP(联机事务处理)和OLAP(联机分析处理)。OLTP应用处理联机事务处理，使用传统的行存储方案，与OLTP事务相关的信息能被有效添加到关系数据库的单个表或者从单个表进行检索。在OLAP情形下，对于具有简单关系的小型数据库，则行存储方案还可以以合理的效率响应针对信息的OLAP应用请求；但是在复杂的数据库查询中OLAP应用涉及从包含许多行的表内的仅几列搜索、检索到整合数据，如果仍使用行存储方案则还须针对无需扫描的任意维度或者没有预先计算的任何聚合对每个表进行全面扫描，结果导致行存储方案在OLAP应用下I/O效率非常低下。

发明内容

由于I/O效率对于商业数据库管理系统(DBMS)的性能起着非常重要的作用，本发明的目的是提供一种新颖的数据库管理系统及其数据处理方法，可以在传统的行存储模型基础上提高例如在OLAP应用环境下的I/O效率。

具体地，考虑到列存储DBMS易于实现高I/O效率和高压缩比、适于OLAP应用场景等优点，本发明致力于在应用更加广泛的行存储DBMS中引入列存储方案的优点，提出如下的改进方案。

根据本发明的一个方面，一种用于关系数据库的数据处理方法，包括：

选定所述关系数据库的至少一个表；

将所述选定的至少一个表的每一个按列分割成两个以上的子表，其中至少一个子表包括至少两列；以及，

分别将所述子表写成相应的行存储数据库的表。

相应地，一种用于关系数据库的数据处理设备，包括：

选定装置，被配置成选定所述关系数据库的至少一个表；

分割装置，被配置成将所述选定的至少一个表的每一个按列分割成两个以上的子表，其中至少一个子表包括至少两列；以及，

写入装置，被配置成将所述子表分别写成相应的行存储数据库的表。

相比现有技术中传统行存储模型(N阵列存储模型或简称NSM)，本发明的技术方案综合了行存储与列存储的特点，可以容易地在行存储DBMS(如DB2)中运行；并且，在传统的行存储模型的基础上仅作了编译和执行层面的修改即可提高OLAP环境下的I/O效率，为OLAP提供更好的工作负载，具体地，

1)当为了所有列中特别小的子集而却需要对许多行进行聚合计算时，只对列的子集进行读取能够显著节约I/O工作量。

2)改进缓存命中率以进一步提高内存中页的使用率。

3)对于只部分聚集在列级别或者一组列内的数据实现更高的数据压缩率。

附图说明

参照下面结合附图对本发明实施例的说明，会更加容易地理解本发明的以上和其它目的、特点和优点。在附图中，相同的或对应的技术特征或部件将采用相同或对应的附图标记来表示。

图1是示出可实现本发明的数据处理系统的框图。

图2示出根据本发明一个实施例的方法的流程图。

图3示出了根据本发明另一实施例的存储模型示意图。

图4是根据本发明再一实施例的存储模型示意图。

图5示出了作为数据库管理系统一部分的用于关系数据库的数据处理设备。

图6示出了实现用于数据查询及数据操作的数据库管理系统部分的典型配置的功能框图。

具体实施方式

下面参照附图来说明本发明的实施例。应当注意，为了清楚的目的，附图和说明中省略了与本发明无关的、本领域普通技术人员已知的部件和处理的表示和描述。

系统体系

现在参考附图，特别是图1，描述了可实现本发明的数据处理系统的框图。数据处理系统100是可实现本发明的计算机网络。数据处理系统100包含网络102，网络102是用于在不同的设备和数据处理系统100内连接到一起的计算机之间提供通信链接的媒介。

在所描述的例子中，服务器104与存储器106一起连接到网络102。此外，例如工作站、个人计算机、手机、PDA等的客户端108、110和112也被连接到网络102。在所描述的例子中，服务器104向客户端108、110和112提供如引导文件的数据、操作系统以及应用程序。分布式数据处理系统100可包括另外的服务器、客户端以及其它未显示的设备。在所描述的例子中，分布式数据处理系统100是因特网，网络102表示对使用TCP/IP协议套件来彼此通信的网络以及网关的集合。当然，分布式数据处理系统100还可被实现为不同类型的网络。

企图将图1作为例子，而不是作为本发明所述过程的结构限制。在不偏离本发明精神和范围的条件下，可对图1所示系统作出许多更改。

本发明可实现为如图1所示的服务器104的数据处理系统(数据库管理系统)。该数据处理系统可以是包括连接到系统总线的多个处理器的对称多处理器(SMP)系统。亦可使用单处理器系统。本发明还可实现为图1中客户端计算机的数据处理系统(数据库管理系统)。

存储模型

如图2所示，根据本发明的用于关系数据库的数据处理方法200，从步骤S201开始，首先选定所述关系数据库的至少一个表(步骤S202)。将所选定的至少一个表的每一个按列/垂直分割成两个以上的子表(步骤S203)，其中至少一个子表包括至少两列；然后分别将所述子表写成相应的行存储数据库的表(步骤S204)。

一个关系数据库可能包括多个表，本发明可根据优化方案针选定一个或多个表分别对其进行分割，也可以针对关系数据库的所有表进行分割。为简便起见，如图3所示仅针对关系数据库中的一个表T，将其按列分割即垂直分割为三个子表(T1、T2和T3)，这三个子表分别包括一列{C1}，两列{C2，C3}和三列{C4，C5，C6}，分别存储(c1)，(c2，c3)和(c4，c5，c6)的内容。

然后以行存储的方式分别将子表T1、T2和T3写成三个相应的行存储数据库的表(如图3中用3页分别存储三个子表)，即每个子表采用传统的行存储模型。这样表T中每行的内容按子表分割开，分别存储在T1、T2和T3中。在DBMS处理过程中DBMS则可根据需要只加载所需的子表Ti，而非必须整个表T，由此可以实现与列存储DBMS相似的优点，从本质上改善I/O效率。

具体地，根据应用需要，用户可通过DDL语句来创建表格，通过“CREATE TABLE DDL”的选择子句来定义子表。或者可以通过改编来改变子表。比如

----------------------------------------------------------

CREATE TABLE T(

c1 INTEGER NUT NULL，

c2 CHAR(10)，

c3 VARCHAR(1024)，

c4 DECIMAL NOT NULL，

c5 VARCHAR(1024)，

c6 VARCHAR(1024))

COLUMN GROUPED BY(MAIN T1(c1)，T2(c2，c3)，T3(c4，c5，c6))；

-------------------------------------------------------------

如图3所示，表T被列分组为3个子表，例如T1中，数据被组织为：

CREATE TABLE T1(c1INTEGER NUT NULL)。

例如子表T2和T3以如下方式分别存储(c2，c3)和(c4，c5，c6)的数据对象：

--------------------------------------------------------------

CREATE TABLE T2(c2CHAR(10)，c3VARCHAR(1024))；

CREATE TABLE T3(c4DECIMAL NOT NULL，

c5 VARCHAR(1024)，c6VARCHAR1024))；

--------------------------------------------------------------

可以理解，可以按照任意预定方式对表T进行分割。例如，按照各列的排列顺序将表T分割成2个以上的子表，亦可不按照各列排列顺序进行分割。无论以何种方式分割，由于均可使得DBMS只加载/抽取所需的子表而非全表来响应一个查询，由此均可获得优于传统行存储模型的有益效果。

优选地，在关系数据库中的每个表中会有用于联接的标识列，用于使得表格相互联接以支持不同的OLAP查询(例如星型/雪花模型数据库)。在对于联接操作而言，只有这些列是必要的。因此在本发明中可以将这些标识列分组为一个子表。DBMS可只选择这个子表用于联接操作。

更优选地，本发明的数据处理方法可针对所述选定的至少一个表的每一个，选取其中一列；然后基于所述选取的一列与其它各列一起被访问的频率将所述一列与其它各列分组在一起，形成相应子表，以实现在I/O效率方面较佳的一个分组子表。可以按照预定的被访问频率将所选定的第一个列与其它达到该预定被访问频率的其它列直接分组在一起；对于剩余的各列可以直接分组成另外的一个子表，或者可以按照上述方式继续分组。也可以采取以下近似计算方法来决定最佳的子表分割。

假设该表包括列{c1，c2，...，cn}，对于此表的查询为{Q1，Q2，......，Qm}。对于每一个查询Qi，需要一个由列Ci组成的子表。

步骤1：假设每个查询Qi发生的概率设为Pi。

步骤2：设置一子表方案S。基于针对查询Qi的方案S，可以获得所需的子表。然后得到在所需的子表中联接操作的发生次数Ji以及无用列的数目。

步骤3：循环每次查询，即可得到对于多余的联接操作J及无用列Ui的影响的综合估计。

J = Σ_{i = 1}^{m} J_{i} P_{i},

U = Σ_{i = 1}^{m} U_{i} P_{i}

步骤4：调整S的大小并重复步骤2和步骤3直至发现这样一个S值使得J和U均足够小，即获得最佳的子表方案S。

由于联接操作在复杂事件中发生，以上只是近似计算。在实践操作中，可以结合实际情况及经验来决定子表分割。

行重构

由于如上所述，分割后的每个子表采用传统的行存储模型，因此可以使用与普通行存储数据库表相同的方式对每个子表进行查询和一般的操作，还可以公知方式为各个子表建立作为额外数据结构的索引，以额外地实现查询加速。

进一步，由于表中每行的内容按子表被分割开并分别存储在不同的子表中，作为不同子表中的相应行，对此本发明提出了如下实施例对分布在不同子表中相应行进行重构以重现原数据库表的完整行。当然以下的实施例不仅可用于行重构，亦可方便地实现对每个子表的查询和其它操作。

第一实施例，在将各个子表写成行存储数据库表以存入存储装置时，可以为每一子表中的相应行添加相同的RID值。这样分布在不同子表中的同一行数据对象可以方便地利用相同的RID值进行关联，以实现行重构。

第二实施例，可以任意指定其中一个子表作为基准子表，将所述基准子表的相关行的行ID作为RID值添加到其它所有子表以作为其它所有子表的相应各行的行ID。图3额外地示出了所述第二实施例。

如图3所示，例如T1被指定为基准子表，子表T2和T3隐式地包含一个RID列(如图3中的附图标记301表示指向第一行的RID列，302表示指向第二行的RID列)，用于存储T1的RID值以保持每一行的水平关系。例如，当用户可通过以下方式插入数据时：

------------------------------------------------------------------

INSERT INTO T VALUES(1，′name′，′This is a test′，123.90，′Testvalue′，NULL)；

该数据将以以下形式被插入：

INSERT INTO T1VALUES(1)；

--假设该记录行ID是1200

INSERT INTO T2VALUES(1200，′name′，′This is a test′)；//隐性插入RID值

INSERT INTO T3VALUES(1200，123.90，′Test value′，NULL)；//隐性插入RID值

-------------------------------------------------------

与第一实施例类似，第二实施例同样用来为子表构建RID，这样DBMS可同样通过RID值选用合并联接操作来重构行的内容。在第一和第二实施例中，DBMS均能无需借助索引即可调入或修改所需的子表的内容，进行合并或散列联接，通常可以以比利用索引更快的速度实现行重构；而每一子表内部依然维持为普通表，因此其仅需要对传统的行存储DBMS做较少的代码变化。

第三实施例涉及对各个子表建立总索引，例如通过扩展索引叶级页结构以支持子表分组存储模型。具体是使用B+树结构或Hash索引，将索引叶级页上的行指针扩展至一个行指针列表，使其中每一叶级别索引项包括数量与所述子表数量相同的行指针RID值，以及并使每一索引项的各个行指针RID值分别包括与所述索引项相应的所述子表中相应行的行ID，从而为所述行存储数据库表建立总索引。该第三实施例实现了使索引支持行重构同时最小化索引扩展的成本。

用户可通过以下方式创建索引IDX：

CREATE INDEX IDX ON T(c1)；。

传统的B++树叶级页的索引项包括一个键值(Key)和一个行指针RID(RID即一对(pageNo，slotNo))，RID(pageNo，slotNo)作为行指针指向在磁盘中编入索引的行。

对于以N子表存储的行，该第三实施例使用该行内一一对应N子表的RID组作为行指针列表替换原索引项中的RID，如图4所示，仍以图3所示的子表为例，其中每一叶级别索引项包括键值(Key)以及数量与子表数量相同(即3个)的行指针RID以构成作为指针列表的行指针RID组，每一索引项的行指针RID组包括与所述索引项相应的子表中相应行的行ID。

因此，按照实现行重构的第三实施例可以轻易地将传统的B+树索引和/或散列索引改编为存储在列表中的索引行。这样对整个表建立索引，DBMS可通过检查对应的索引项来确定相关的页以及记录。具体在图4的索引树Idx1中，Key2对应的3个RID分别为(Page 1Slot 2)，(Page 230Slot 1)和(Page 1450Slot 2)，即这些RID作为行ID分别指向第1页第2个记录的相应行、第230页第1个记录的相应行和第1450页第2个记录的相应行，因此通过扩展索引叶级页结构能够轻松地对行重构。

数据处理设备

本发明还提供了一种作为数据库管理系统一部分的用于关系数据库的数据处理设备500，如图5所示，包括：选定装置510，被配置成选定所述关系数据库的至少一个表501；分割装置520，被配置成将所选定的至少一个表的每一个垂直分割成两个以上的子表，其中至少一个子表包括至少两列；以及，写入装置530，被配置成将所述子表分别写成相应的行存储数据库的表，存入到存储装置502。当然选定装置510如前所述可选定任意数量的关系数据库表。

分割装置520可按照如前所述的分割方式对表进行分割，例如可针对所述选定的至少一个表的每一个，选取其中一列；基于所述选取的一列与其它各列一起被访问的频率将所述一列与其它各列分组在一起，形成相应列表。

写入装置530还可按照如前所述的方式例如可为所述子表中的相应行创建RID，例如为每一相应行添加相同的RID值，以便写入相应的行存储数据库表，或者可指定其中一个所述子表作为基准子表，将所述基准子表的相关行的行ID作为RID值添加到其它所有子表，以使其它所有子表的相应行具有相同的RID值，从而方便DBMS实现对行的重构以及其它数据操作。

可替代地，为实现对行的重构以及额外地实现其它数据操作，数据处理设备500还可包括索引装置，该索引装置被配置成使用B+树结构或Hash索引为所述行存储数据库的表建立索引，其中每一叶级别索引项包括数量与所述子表数量相同的行指针RID值，每一索引项的行指针RID值包括与所述索引项相应的所述子表中相应行的行ID。

DBMS处理SQL查询的过程

图6示出了实现用于数据查询及数据操作的数据库管理系统部分的典型配置的功能框图。如图所示，数据库管理系统DBMS响应于SQL查询以通过对该SQL进行解析、优化和执行来产生的最终的结果集合。查询解析器601使用数据字典602中的信息将每个SQL查询转换为一系列SQL语意描述。查询优化器603响应于SQL查询以及来自查询解析器601和数据字典602的信息生成一组可能的访问计划，并基于一种特定访问计划成本估计而从中挑选足够有效的访问计划604。运行单元605在缓冲池607中根据所述访问计划604进行读写处理(即数据操作606)以产生结果集合。

数据字典通常包括具有数据元素的定义和表示的元数据。在DBMS的背景下，数据字典是表和视图的集合，并且保持与数据元素的定义相关的信息、用户名、行和特权、模式对象、存储过程、一般数据库结构和空间分配信息。在该实施例中，数据字典602包括表条目的集合，其中每个表条目包括属性或者字段定义的集合，特别是记录有目标数据库表的子表分组/分割信息，这样查询解析器601即可基于子表分组/分割信息将SQL查询修改为对所需目标子表的查询，一些无用的列在访问计划中会被I/O所跳过。然后查询优化器603基于子表分组/分割信息重写并利用子表的优势产生高效的访问计划，进而优化查询。

具体地，利用本发明的子表分组/分割存储模型，DBMS可以选择在访问计划的不同阶段将同一个表的不同的子表分别加载到内存。比如应用于常出现在OLAP查询中的多表联接，在访问计划中，一个表用于联接操作的列可以首先被加载以便与其他表进行联接，当所有复杂的联接操作完成后，同一表格的其他列能够进行加载，以用于第二处理程序，如计算聚合。这样就避免了在传统行存储模型中携带多余列进行全部查询操作的缺点，使得访问计划更加高效。

聚合查询

以下以一个基于LINEITEM的聚合操作为例说明，其包括15个列。

因为在WHERE语句中没有相应谓词，DBMS将选择表格扫描以选择满足条件的行。在传统的行存储DBMS中，15个列的全部的行的内容必须从磁盘中读取。而在传统的列存储DBMS中，只有四个列的内容会因此次查询而被加载。

根据本发明的子表分组/分割存储模型，例如优选将{L_QUANTITY，L_EXTENDEPRICE，L_DISCOUNT}分组为子表1，将{L_SHIPDATE，L_SHIPINSTRUCT，L_SHIPMODE}分组为子表2。然后本发明的DBMS应当只加载包含6列的这两个子表。

假设RID为8字节长，整数值为4字节长，分数值为12字节长，日期值为6字节长。然后表LINEITEM的行的长度为159字节。如果页容量为8KB，该表包含100000行，其将会存储在大约1941页中。为了完成此次查询，传统的行存储DBMS必须扫描全部1941页。

使用本发明的子表分组/分割存储模型，对于子表1，将会有3列进行存储。假设第一组的行的长度为52字节，使用8KB容量的页来存储100000行，则需要635页。进一步假设在子表2中的行的长度为59字节，则需要635页来存储100000行。为了完成此次查询，基于子表分组/分割存储的DBMS需要完整扫描1270页，而这是传统行存储DBMS工作量的65％。访问计划可以为：

FILTER1：L_DISCOUNT BETWEEN[dicount]-0.01 AND[discount]+0.01AND L_QUANTITY＜[quantity]

FILTER2：L_SHIPDATE＞＝[date value]AND L_SHIPDATE＜[datevalue]+interval 1 year

----------------------------------------------------------

另外，根据本发明亦可仅将一个子表中所需的4列分为一组，针对此次查询，I/O工作量将是传统行存储DBMS的32％。因此，通过根据本发明对表中的列进行合理分割/分组，I/O工作量可以明显减小。通常，对于产品系统而言，包含数十列的大表很常见。在表中的列容量越大，本发明的子表分组/分割存储模型可以带来的I/O性能越好。

其它有利技术效果

以下仅以实例的方式列举出根据本发明还可以带来的其它有利效果。

1)提高缓冲池的命中率

假设一个表包括N行，其中有M行在内存中进行缓冲，行R被选中的概率p(R)遵循均匀分布，即对于任意R，p(R)＝1/N。当传统的行DBMS加载一行，I/O发生的概率为1-M/N。此意味着随着M的增大，即越多的行被缓冲，I/O发生的概率会线性降低。

作为比较，根据本发明的子表分组/分割存储模型，将行内容分割划分到子表中，因为在子表中行的长度通常不长，在子表的一页中，行的数量会比较大。因此，如果被缓冲在内存中的页的数量为常量，本发明的DBMS从缓存中加载子表中一行的概率会大于一个普通表，显然这通过增加缓冲池的命中率直接降低了I/O负载。

2)可能的高压缩率

根据本发明的子表分组/分割存储模型，在一个子表中，如果行数值以较小的设定值为幅度而降低时，列的数量可以比较小。例如，列GENDER可以仅为MALE或FEMAILE。本发明的DBMS可以容易地获得稳定的字典，同时在子表中获得较高的压缩率。

3)容易在行存储DBMS中应用

根据本发明，只需对传统的行存储DBMS作出微小改变而无需实质性改变即可实现本发明的子表分组/分割存储模型。

例如，根据本发明，子表被视为存储在传统行存储模型下的普通表。对子表的操作和查询与普通行存储表相同。

第二，为实现行重构和/或加速索引，索引只在叶节点处被扩展，无需对索引方法及算法作出大的变化。

作为替代，重构行的设计只使用了一个隐式列，而不需要在DBMS的存储中进行特殊变化。

其它实施例

对本领域的普通技术人员而言，能够理解本发明的方法和装置的全部或者任何步骤或者部件，可以在任何计算设备(包括处理器、存储介质等)或者计算设备的网络中，以硬件、固件、软件或者它们的组合加以实现，这是本领域普通技术人员在阅读了本发明的说明的情况下运用他们的基本编程技能就能实现的，因此在这里省略了详细说明。

因此，基于上述理解，本发明的目的还可以通过在任何信息处理设备上运行一个程序或者一组程序来实现。所述信息处理设备可以是公知的通用设备。因此，本发明的目的也可以仅仅通过提供包含实现所述方法或者设备的程序代码的程序产品来实现。也就是说，这样的程序产品也构成本发明，并且存储有这样的程序产品的存储介质也构成本发明。显然，所述存储介质可以是任何公知的存储介质或者将来所开发出来的任何存储介质，因此也没有必要在此对各种存储介质一一列举。

在本发明的系统和方法中，显然，各部件或步骤是可以分解和/或重新组合的。这些分解和/或重新组合应视为本发明的等效方案。并且，执行上述系列处理的步骤可以自然地按照说明的顺序按时间顺序执行，但是并不需要一定按照时间顺序执行。某些步骤可以并行或彼此独立地执行。

以上描述了本发明的优选实施方式。本领域的普通技术人员知道，本发明的保护范围不限于这里所公开的具体细节，而可以具有在本发明的精神实质范围内的各种变化和等效方案。

Claims

1.一种用于关系数据库的数据处理方法，包括：

选定所述关系数据库的至少一个表；

分别将所述子表写成相应的行存储数据库的表。

2.根据权利要求1的数据处理方法，其中将所述选定的至少一个表的每一个按列分割成两个以上的子表的步骤包括：

针对所述选定的至少一个表的每一个，选取其中一列，

基于所述选取的一列与其它各列一起被访问的频率将该列与其它各列分组在一起，形成相应子表。

3.根据权利要求1的数据处理方法，其中将所述子表写成相应的行存储数据库的表的步骤还包括：为所述子表中的相应行创建RID。

4.根据权利要求3的数据处理方法，其中将所述子表写成相应的行存储数据库的表的步骤还包括：

为每一所述子表中的相应行添加相同的RID值。

5.根据权利要求3的数据处理方法，其中将所述子表写成相应的行存储数据库的表的步骤还包括：

指定其中一个所述子表作为基准子表，

将所述基准子表的各行的行ID作为RID值添加到其它所有子表作为其它所有子表的相应各行的行ID。

6.根据权利要求1的数据处理方法，其中还包括：

使用B+树结构或Hash索引为所述行存储数据库表建立索引，

使其中每一叶级别索引项包括数量与所述子表数量相同的行指针RID值，以及

使每一索引项的各个行指针RID值分别包括与所述索引项相应的所述子表中相应行的行ID。

7.一种用于关系数据库的数据处理设备，包括：

选定装置，被配置成选定所述关系数据库的至少一个表；

8.根据权利要求7的数据处理设备，其中，所述分割装置被进一步配置成：针对所述选定的至少一个表的每一个，选取其中一列；基于所述选取的一列与其它各列一起被访问的频率将所述一列与其它各列分组在一起，形成相应子表。

9.根据权利要求7的数据处理设备，其中所述写入装置还被配置成为所述子表中的相应行创建RID。

10.根据权利要求9的数据处理设备，其中所述写入装置还被配置成为每一所述子表中的相应行添加相同的RID值，以便写入相应的行存储数据库表。

11.根据权利要求9的数据处理设备，其中所述写入装置还被配置成指定其中一个所述子表作为基准子表，将所述基准子表的各行的行ID作为RID值添加到其它所有子表作为其它所有子表的相应各行的行ID。

12.根据权利要求7的数据处理设备，其中还包括：

索引装置，被配置成使用B+树结构或Hash索引为所述行存储数据库的表建立索引，其中每一叶级别索引项包括数量与所述子表数量相同的行指针RID值，每一索引项的各个行指针RID值分别包括与所述索引项相应的所述子表中相应行的行ID。