CN102754083B

CN102754083B - 数据库管理系统

Info

Publication number: CN102754083B
Application number: CN201080039794.2A
Authority: CN
Inventors: 宫泽隆幸
Original assignee: Toshiba Solutions Corp
Current assignee: Toshiba Digital Solutions Corp
Priority date: 2010-02-15
Filing date: 2010-02-15
Publication date: 2015-08-05
Anticipated expiration: 2030-02-15
Also published as: WO2011099082A1; CN102754083A; JPWO2011099082A1; JP5377672B2

Abstract

事务管理部(102)将更新部(103)涉及的更新处理和检索部(104)涉及的检索处理作为事务进行管理，在事务开始请求时分配事务ID。第一存储部存储事务涉及的更新处理的日志。在已由更新部(103)更新了数据的情况下，存储部(107)将示出已做出了数据更新的更新信息与事务ID相对应地存储。在由检索部(104)进行了检索时，复原部(108)对成为检索对象的数据的更新信息是否存在于存储部(107)进行判断，在判断为真的情况下，从第一存储部读取已更新了数据的事务，并进行数据的复原处理。

Description

数据库管理系统

技术领域

本发明涉及一种数据库管理系统。

背景技术

为了在多个事务间并行执行更新处理或检索处理时保证数据的一致性，存在一种对数据库进行管理的数据库管理系统。

在这种数据库管理系统中，在根据一个事务进行更新时，在该更新被提交或是中止以前，关于其他事务，向用户提示更新前的数据。为了进行该处理，在由一个事务的更新处理更新了数据时，制作记录有更新内容的日志文件。当用别的事务做出检索请求时，判断有无其他事务导致的、提交或是中止前的数据更新。

在判断为已进行了数据更新的情况下，检索请求的事务使用已被别的事务更新后的数据和日志文件来复原更新前的数据。

作为判断有无数据更新的方法，例如在专利文献1中，在实表数据部和变址(index)部中设置计数器。当做出更新请求时，更新实表数据部中的数据，并使计数器的值增加1。使变址部中的计数器的值增加1。

当由别的事务做出检索请求时，按照检索条件检索变址部，与检索结果一起存储检索之处的计数器的值。接着检索实表数据部，将与检索结果相对应的数据的计数器与已存储的计数器的值进行比较。

在两个计数器同值的情况下，进行了检索请求的事务就输出检索结果。在不是同值的情况下，再次从变址部开始重做检索。

现有技术文献

专利文献：

专利文献1：日本专利第4047557号公报

发明内容

发明所要解决的问题

在上述的数据库管理系统中，必须要在变址部中设置叫做计数器的附加信息，处理成本会增大。

本发明的目的在于，提供一种能用很少的处理成本来判断在一个事务的检索处理当中是否有别的事务进行更新处理并进行了数据更新的数据库管理系统。

用于解决问题的手段

本发明的实施方式涉及的数据库管理系统具备：数据库，存储文档数据和时刻数据表，所述文档数据包括文档结构信息和部分数据，所述文档结构信息表示结构化文档数据的结构信息，所述部分数据包括在所述结构化文档数据的文本中对同一层的同一名称的标签赋予同一项目ID而成的文本信息和索引信息，所述时刻数据表中将所述项目ID与其最终更新时刻相对应；输入部，输入事务请求以及事务的开始请求，所述事务请求包括针对所述数据库中存储的所述部分数据的更新请求和检索请求；更新部，按照所述更新请求，从所述数据库读取成为更新对象的所述部分数据，执行该读取出的所述部分数据中的对象数据的更新处理，并且，更新所述时刻数据表的、与所述对象数据相对应的所述项目ID的所述最终更新时刻；检索部，按照所述检索请求，从所述部分数据中检索成为检索对象的检索对象数据，并且从所述时刻数据表取得该检索对象数据的最终更新时刻；事务管理部，管理多个所述事务的执行，与按照所述请求而执行的一个事务相对应地分配一个事务ID；第一存储部，存储按照所述更新请求的事务而进行的所述数据库的更新处理的日志；第二存储部，在由所述更新部更新了所述数据库的情况下，将示出已做出了所述对象数据的更新的更新信息，与所述事务ID相对应地存储；以及复原部，按照所述检索请求的事务而由所述检索部检索所述数据库时，在所述最终更新时刻是所述更新处理的所述事务ID的开始时刻之前的情况下，输出该检索结果，在所述最终更新时刻是所述开始时刻之后且所述检索对象数据的所述更新信息存在于所述第二存储部中的情况下，从所述第一存储部读取具有与所述对象数据相对应的事务ID的所述更新处理的事务的所述日志，进行该对象数据的复原处理。

发明效果

根据本发明，能够用很少的处理成本来判断在一个事务的检索处理当中是否有别的事务进行更新处理并进行了数据更新。

附图说明

图1是表示一个事务涉及的更新处理与别的事务涉及的检索处理之间的时间关系的图。

图2是表示第一实施方式涉及的数据库管理系统的框图。

图3是表示事务管理部102的一般处理的流程图。

图4是表示XML文档的一例图。

图5是表示XML文档的结构的一例图。

图6是示出数据库内的各个XML文档的数据的图。

图7是表示数据库管理系统的更新处理的流程图。

图8是表示数据库管理系统的检索和复原处理的流程图。

具体实施方式

以下，参照附图，对本发明的实施方式进行说明。

关于已经出现过的附图，在与上述同样的要素上标记同一符号并适当省略详细的说明。

(第一实施方式)

所述事务，是将从用户请求的对数据库的更新处理和检索处理所构成的一个或多个处理汇集起来作为一个处理单位。事务也有是更新处理的情况。事务还有只是检索处理的情况。

第一实施方式涉及的数据库管理系统对数据库中存储的XML文档的数据进行更新处理和检索处理。

图1是表示一个事务涉及的更新处理(事务1)与别的事务涉及的检索处理(事务2)之间的时间关系的图。

事务1和事务2随机地发生。例如，由于使用事务开始时的数据库进行数据库的检索，因此，如果在一个事务(事务2)中正在执行检索处理时，数据库的内容被别的事务(事务1)更新，就会产生输出时刻的检索结果与数据库的内容不一致的状态。本实施方式涉及的数据库管理系统10用很少的处理成本来判断在一个事务的处理当中是否有别的事务进行了数据的更新，并进行事务所检索的数据库的复原。

图2是表示第一实施方式涉及的数据库管理系统10的框图。

数据库管理系统10包括输入部101、事务管理部102、更新部103、检索部104、日志管理部105、缓冲器管理部106、第二存储部107、复原部108、存储事务日志的第一存储部109、数据库110和输出部111。日志包括事务涉及的更新处理内容、检索处理内容以及事务。

在数据库110中存储有例如XML文档等数据。对该数据库110进行与输入部101受理的事务相应的处理。例如，在事务是检索的情况下，检索部104从数据库110中检索被请求的数据。在事务是更新的情况下，更新部对数据库110更新被请求的数据。

利用事务管理部102管理这样的事务处理。该情况下，日志管理部105将事务的日志记录在第一存储部109中。

在作为事务而做出了数据库的检索请求时，数据库管理系统10有可能产生下述情形：通过事务进行检索的数据中被与该事务并行执行的其他事务更新。

因此，在本实施方式中，使用第二存储部107中的更新信息，对是否存在有可能被与事务并行执行的其他事务更新的数据进行判断。在判断为存在的情况下，从第一存储部109读取已对该数据进行了更新的事务的更新处理内容，并进行向更新前的数据的复原处理。

输入部101从多个用户受理包括数据的更新请求和检索请求在内的事务请求以及事务的开始请求。输入部101能够并行受理来自多个用户的请求。

更新部103通过缓冲器管理部106读取数据库110中存储的数据，进行更新处理。更新部103在完成了数据更新的时刻，将示出该数据已被更新的更新信息存储在第二存储部107中。检索部104通过缓冲器管理部106读取数据库110中存储的数据，进行检索处理。

事务管理部102将更新部103涉及的更新处理和检索部104涉及的检索处理作为一系列的事务进行管理。图3是表示事务管理部102的一般处理的流程图。向事务管理部102输入来自输入部101的事务请求和事务开始请求(S301)。事务管理部102对一个事务分配一个事务ID(S302)。事务管理部102按照输入部101受理请求的顺序分配事务ID。事务管理部102将未提交或是未中止的事务的事务ID存储在内部(S303)。事务管理部102判断事务中包含的更新处理或检索处理是否已全部成功(S304)。在已成功的情况下，提交事务(S305)。在失败的情况下，中止事务(S306)。

即，事务管理部102保持有正在执行当前处理的事务ID。

日志管理部105将事务涉及的更新处理或检索处理的日志，在各自的处理结束的时刻，记录在第一存储部109中。在一个事务中利用检索部104进行检索处理时，复原部108使用第二存储部107的更新信息，对成为检索对象的数据是否存在已被并行执行的其他事务更新的可能性进行判断。

在该判断为真的情况下，复原部108从第一存储部109读取事务的日志。使用事务的日志进行数据的复原。输出部111输出检索结果。

图4是表示XML文档的一例图。在本实施方式中，将由具有文档ID的XML文档描述的货单的数据作为例子。图4(a)和图4(b)分别表示了一个XML文档。对各自的XML文档赋予用于识别各个XML文档的文档ID。例如，对图4(a)的XML文档赋予文档ID“1”，对图4(b)的XML文档赋予文档ID“2”。

图5是表示图4中示出的XML文档的结构的一例图。XML文档的结构是树形结构，对各自的标签和文本项目赋予作为识别号码的项目ID。图5的中括号内的数字是项目ID。例如，在图4(a)所示的文档ID为“1”的XML文档中，对“姓名”标签赋予项目ID“5”，对“姓名”文本赋予项目ID“6”。在各个XML文档中，对同一层的同一名称的标签赋予同一项目ID。例如，图4(a)的XML文档的“商品名”标签的项目ID是“13”，图4(b)的XML文档的“商品名”标签的项目ID也是“13”。

图6是示出数据库110内的各个XML文档的数据的图，包括文档结构信息和部分数据。所述部分数据，是将XML文档分解后的数据，包括XML文档的文本信息和索引信息。

所述文档结构信息，是用项目ID描述了XML文档的文档结构的信息。例如，如图6所示，将文档ID“1”的XML文档(以下称为文档1)的文档结构信息表示为“1，2，3，4，5，6，7，8，9，10，11，12，13，14，15，16，17，18，19，20，21，22”。在文档ID“2”的XML文档(以下称为文档2)中不存在文档1中的“公司名”项目。因此，将文档2的文档结构信息表示为“1，2，3，4，5，6，9，10，11，12，13，14，15，16，17，18，19，20，21，22”，“公司名”标签的项目ID“7”和文本项目ID“8”不包含在结构信息中。

所述文本信息，是将文本的内容与项目ID相对应而成的信息。例如，如图6所示，文档1的文本信息中有“4＝“01234567””等。这示出了项目ID“4“的文本是“01234567”。

所述索引信息，是示出将文本的字符串分割而成的各个字符存在于哪个文档的、哪个项目的、第几个的信息。字符串的分割方法有“N元语法(N-gram法)”或“形态分析法”等。例如，如图6所示，文档1中的“○○”的索引信息是““○○”，1，6，1”。这示出了“○○”这个字符串存在于文档1的项目ID“6”的第“1”个字符。

数据库110以文档结构信息和部分数据的状态存储着XML文档的数据。即，根据文档结构信息和部分数据制成如图4表示的XML文档。

另外，在本实施方式中，数据库110对文档结构信息和部分数据分别赋予部分数据ID，来存储文档结构信息和部分数据。例如，对文档结构信息赋予部分数据ID“1”，对文本信息赋予部分数据ID“2”。

此外，数据库110将时刻数据表与XML文档的数据相独立地加以存储，在时刻数据表中，将各个项目ID与最后进行该项目ID的更新的时刻即最终更新时刻相对应。这样就知道各个XML文档的各个项目被更新部103最后更新的时刻即最终更新时刻。

图7是表示数据库管理系统10的更新处理的流程图。输入部101受理来自用户的请求(S501)。例如，在输入部101中，从用户受理“开始事务，将文档1的顾客信息的姓名从“○○太郎”变更为“○○次郎”，将文档2的顾客信息的顾客ID从“02345678“变更为”03345678“，并请提交事务”这样的请求。输入部101向事务管理部102和更新部103输出该请求。

事务管理部102对按照该请求执行的一个事务分配一个事务ID，向日志管理部105输出事务的开始时刻等的日志(S502)。

更新部103分析更新请求，确定成为更新对象的部分数据ID。这时，使更新部103在设计阶段就具有“如果是文本(“○○太郎”等)的更新则确定为部分数据ID“2”即可”这样的信息。

更新部103向缓冲器管理部106请求，从而从数据库110读取所确定的部分数据ID的部分数据，执行更新处理，向日志管理部105输出更新内容或更新时刻等日志(S503)。

例如，更新部103读取文档1的部分数据ID“2”，将其中的“○○太郎”更新为“○○次郎”，并且向日志管理部105输出“在时刻t1，将文档1的部分数据ID“2”的项目ID“6”从“○○太郎”变更为“○○次郎””这样的更新日志。此外，更新部103读取文档2的部分数据ID“2”，将其中的“02345678”更新为“03345678”，并且向日志管理部105输出“在时刻t2，将文档2的部分数据ID“2”的项目ID“4”从“02345678”变更为“03345678””这样的更新日志。日志管理部105将更新日志记录在第一存储部109中。关于文档2也进行同样的处理。

这时，更新部103对更新后的项目的时刻数据表进行更新。例如，更新部103将文档1的项目ID“6”的最终更新时刻更新为t1。将文档2的项目ID“4”的最终更新时刻更新为t2。

更新部103将被一个事务更新后的部分数据的部分数据ID“2”与事务ID相对应地存储在第二存储部107中(S504)。例如，更新部103将“已被事务ID“1”的事务更新了文档1的部分数据ID“2”以及文档2的部分数据ID“2””这样的更新信息，存储在第二存储部107中。

数据库管理系统10如以上所述地进行更新处理。

图8是表示数据库管理系统10的检索和复原处理的流程图。输入部101受理来自用户的数据检索请求(S601)。例如，在输入部101中，从用户受理“开始事务，检索顾客信息的姓名是“○○太郎”或者“××花子”的文档，并请提交事务”这样的请求。输入部101向事务管理部102和检索部104输出数据的检索请求。

事务管理部102对按照事务开始请求而执行的事务分配事务ID，向日志管理部105输出事务开始时刻，并且将事务ID和其开始时刻存储在第二存储部107中。

检索部104询问事务管理部102，确定在检索请求的输入时刻未提交或是未中止的事务，将该事务中开始时刻最早的事务的开始时刻决定为判断基准时刻(S602)。

例如，假设在检索请求的输入时，只有进行了上述的“将文档1的顾客信息的姓名从“○○太郎”变更为“○○次郎”，将文档2的顾客信息的顾客ID从“02345678”变更为“03345678””这样的更新处理的事务(事务ID“1”)是执行中途(提交前或中止前)。判断基准时刻是事务ID“1”的开始时刻(设为t0)。

并且，假设在时刻t1进行了“将文档1的顾客信息的姓名从“○○太郎”变更为“○○次郎”这样的更新处理之后，向输入部101输入了“检索顾客信息的姓名是“○○太郎”或者“××花子”的文档”这个检索请求。

检索部104根据检索请求，确定成为检索对象的部分数据(S603)。这时，使检索部104在设计阶段就具有“如果是文本(“○○太郎”等)的检索则确定为部分数据ID“2”即可”这样的信息。例如，检索部104对“请检索顾客信息的姓名是“○○太郎”或者“××花子”的文档”这样的检索请求进行分析，确定全部文档ID的部分数据ID“2”作为检索对象。

检索部104从确定的检索对象的部分数据ID“2”中搜索被请求的检索对象的数据，通过缓冲器管理部106，从时刻数据表中取得该数据的最终更新时刻(S604)。检索部104将取得的结果输出到复原部108。复原部108对每一个项目判断所受理的部分数据ID“2”的项目ID“6”的项目的最终更新时刻是否比判断基准时刻往后(S605)。

例如，在顾客信息的姓名是“○○太郎”的文档的检索中，复原部108判断文档1的部分数据ID“2”的项目ID“6”的最终更新时刻是否比判断基准时刻t0往后。由于在检索请求的输入时刻，文档1的部分数据ID“2”的项目ID“6”的最终更新时刻是t1，因此，文档1的项目ID“6”的部分数据ID“2”的最终更新时刻比t0往后。

在顾客信息的姓名是“××花子”的文档的检索中，复原部108判断文档2的部分数据ID“2”的项目ID“6”的最终更新时刻是否比判断基准时刻t0往后。由于在检索请求的输入时刻，还未根据事务ID“1”的更新事务进行文档2的部分数据ID“2”的项目ID“6”的更新，因此，文档2的部分数据ID“2”的项目ID“6”的最终更新时刻比t0往前。

在最终更新时刻比判断基准时刻往前的情况下(步骤S605中“否”的判断)，复原部108向输出部111输出检索结果并结束处理。例如，复原处理部108在文档2的部分数据ID“2”的项目ID“6”是“××花子”的状态下，将文档2作为XML文档输出到输出部111。

在最终更新时刻比判断基准时刻往后的情况下(步骤S605中“是”的判断)，复原部108检索第二存储部107，判断检索对象的部分数据是否作为更新信息而存在于第二存储部107中(S606)。

例如，复原部108判断文档1的部分数据ID“2”是否存在于第二存储部107中。

由于已由上述的事务ID“1”的更新事务进行了“将文档1的顾客信息的姓名从“○○太郎”变更为“○○次郎””这样的更新，因此，第二存储部107中存在文档ID“1”的部分数据ID“2”作为更新信息。

在与检索对象的部分数据有关的更新信息不存在于第二存储部107中的情况下(步骤S606中“否”的判断)，复原部108将检索结果原样地输出到输出部111，并结束检索处理。

在与检索对象的部分数据有关的更新信息存在于第二存储部107中的情况下(步骤S606中“是”的判断)，复原部108从第二存储部107取得已更新了检索对象的部分数据的事务ID“1”。复原部108通过日志管理部105，从第一存储部109读取所取得的事务ID“1”的事务的更新内容。根据读取出的日志，进行将检索对象的部分数据恢复成更新处理前的部分数据的复原处理(S607)。

例如，复原部108从第二存储部107取得已更新了文档1的部分数据ID“2”的事务的事务ID“1”。复原部108通过日志管理部105，从第一存储部109读取事务ID“1”的更新处理的日志。在该日志中如上所述地存在“由事务ID“1”的事务，在时刻t1，将文档1的部分数据ID“2”的项目ID“6”变更为“○○次郎””这样的内容的更新日志。因此，复原部108根据更新日志，进行将“○○次郎”这个数据恢复成更新处理前的数据“○○太郎”的复原处理。

复原部108将检索结果中的文档1的部分数据ID“2”的项目ID“6”复原成“○○太郎”，并输出到输出部111。输出部111对部分数据已被复原后的检索结果进行显示。

再有，在提交或中止了与第二存储部107中存储的部分数据ID相对应的事务时，优选的是，事务管理部102删除该部分数据。

这样，数据库管理系统10就能用很少的处理成本来判断在检索处理过程中是否由其他事务的更新处理进行了数据的更新。

再有，本发明并不原样限定于上述实施方式，在实施阶段，可以在不脱离其主旨的范围内对结构要素变形后具体实施。此外，可以通过上述实施方式中公开的多个结构要素的适当组合来形成各种发明。例如，也可以从实施方式中示出的全部结构要素中删除几个结构要素。另外，也可以适当组合不同实施方式中的结构要素。

符号说明

101 输入部

102 事务管理部

103 更新部

104 检索部

105 日志管理部

106 缓冲器管理部

107 第二存储部

108 复原部

109 第一存储部

110 数据库

Claims

1.一种数据库管理系统，其特征在于，具备：

数据库，存储文档数据和时刻数据表，所述文档数据包括文档结构信息和部分数据，所述文档结构信息表示结构化文档数据的结构信息，所述部分数据包括在所述结构化文档数据的文本中对同一层的同一名称的标签赋予同一项目ID而成的文本信息和索引信息，所述时刻数据表中将所述项目ID与其最终更新时刻相对应；

输入部，输入事务请求以及事务的开始请求，所述事务请求包括针对所述数据库中存储的所述部分数据的更新请求和检索请求；

更新部，按照所述更新请求，从所述数据库读取成为更新对象的所述部分数据，执行该读取出的所述部分数据中的对象数据的更新处理，并且，更新所述时刻数据表的、与所述对象数据相对应的所述项目ID的所述最终更新时刻；

检索部，按照所述检索请求，从所述部分数据中检索成为检索对象的检索对象数据，并且从所述时刻数据表取得该检索对象数据的最终更新时刻；

事务管理部，管理多个所述事务的执行，与按照所述请求而执行的一个事务相对应地分配一个事务ID；

第一存储部，存储按照所述更新请求的事务而进行的所述数据库的更新处理的日志；

第二存储部，在由所述更新部更新了所述数据库的情况下，将示出已做出了所述对象数据的更新的更新信息，与所述事务ID相对应地存储；以及

复原部，按照所述检索请求的事务而由所述检索部检索所述数据库时，在所述最终更新时刻是所述更新处理的所述事务ID的开始时刻之前的情况下，输出该检索结果，在所述最终更新时刻是所述开始时刻之后且所述检索对象数据的所述更新信息存在于所述第二存储部中的情况下，从所述第一存储部读取具有与所述对象数据相对应的事务ID的所述更新处理的事务的所述日志，进行该对象数据的复原处理。

2.根据权利要求1所述的数据库管理系统，其特征在于，

所述部分数据具有作为标识符的部分数据ID，

所述第二存储部存储用于确定被所述更新部更新了的所述对象数据的所述部分数据的所述部分数据ID，

所述复原部在所述检索时，判断用于确定成为检索对象的所述检索对象数据的所述部分数据的部分数据ID是否存在于所述第二存储部中。