WO2011099082A1 - データベース管理システム - Google Patents

データベース管理システム Download PDF

Info

Publication number
WO2011099082A1
WO2011099082A1 PCT/JP2010/000895 JP2010000895W WO2011099082A1 WO 2011099082 A1 WO2011099082 A1 WO 2011099082A1 JP 2010000895 W JP2010000895 W JP 2010000895W WO 2011099082 A1 WO2011099082 A1 WO 2011099082A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
data
unit
update
search
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2010/000895
Other languages
English (en)
French (fr)
Inventor
宮澤隆幸
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2011553654A priority Critical patent/JP5377672B2/ja
Priority to CN201080039794.2A priority patent/CN102754083B/zh
Priority to PCT/JP2010/000895 priority patent/WO2011099082A1/ja
Publication of WO2011099082A1 publication Critical patent/WO2011099082A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2308—Concurrency control

Definitions

  • the present invention relates to a database management system.
  • the search requesting transaction uses the data updated by another transaction and the log file to restore the data before the update.
  • counters are provided in the base table data part and the index part.
  • the data in the base table data part is updated and the counter value is incremented by one.
  • the counter value in the index part is incremented by one.
  • the index part is searched according to the search condition, and the value of the counter of the search part is stored together with the search result.
  • the base table data part is searched, and the counter of the data corresponding to the search result is compared with the stored counter value.
  • the present invention provides a database management system capable of determining at a low processing cost whether or not data has been updated by another transaction performing an update process during the search process of one transaction. Objective.
  • a database management system includes an input unit that inputs a transaction request including an update request and a search request for structured document data stored in a database and a transaction start request, and the structure according to the update request.
  • An update unit that executes an update process of data to be updated in structured document data
  • a search unit that executes a search process of the data to be searched in the structured document data according to the search request
  • the transaction A transaction management unit that allocates one transaction ID for each transaction at the time of a transaction start request, a first storage unit that stores a log of update processing in a first transaction, and the update unit The data is updated when the data is updated.
  • the data is retrieved by the second storage unit that stores the update information indicating that the data has been updated in association with the transaction ID, and the search unit in a second transaction different from the first transaction.
  • the update information of the data to be searched exists in the second storage unit, the log of the transaction that updated the data is read from the log storage unit and the data is restored. A part.
  • the present invention it is possible to determine at a low processing cost whether or not another transaction has performed an update process during a transaction search process and the data has been updated.
  • Diagram showing the time relationship between the update process by one transaction and the search process by another transaction The block diagram showing the database management system concerning a 1st embodiment
  • a flowchart showing general processing of the transaction management unit 102 An example diagram representing an XML document
  • Example diagram showing the structure of an XML document The figure which shows the data of each XML document in the database Flow chart showing update processing of database management system Flowchart showing search and restoration processing of database management system
  • a transaction is a collection of one or a plurality of processes including update processing and search processing for a database requested by a user as one processing unit.
  • a transaction may be an update process.
  • a transaction may be only a search process.
  • the database management system performs an update process and a search process for XML document data stored in the database.
  • FIG. 1 is a diagram showing a time relationship between an update process (transaction 1) using one transaction and a search process (transaction 2) using another transaction.
  • Transactions 1 and 2 occur randomly. For example, since data is searched using a database at the start of a transaction, if the content of data is updated by another transaction (transaction 1) during the execution of search processing in one transaction (transaction 2), the output The search result at the time and the content of the data may become inconsistent.
  • the database management system 10 determines whether or not data has been updated by another transaction during the processing of one transaction, and restores the database searched by the transaction.
  • FIG. 2 is a block diagram showing the database management system 10 according to the first embodiment.
  • the database management system 10 includes an input unit 101, a transaction management unit 102, an update unit 103, a search unit 104, a log management unit 105, a buffer management unit 106, a second storage unit 107, and a restoration unit 108.
  • a first storage unit 109 that stores a transaction log, a database 110, and an output unit 111.
  • the log includes update processing contents, search processing contents, and transactions by transactions.
  • the database 110 stores data such as XML documents. Processing corresponding to the transaction accepted by the input unit 101 is performed on the database 110. For example, if the transaction is a search, the search unit 104 searches for data requested from the database 110. If the transaction is an update, the update unit 103 updates the requested data with respect to the database 110.
  • Such transaction processing is managed by the transaction management unit 102.
  • the log management unit 105 records a transaction log in the first storage unit 109.
  • the database management system 10 may update the data retrieved by the transaction by another transaction executed in parallel with the transaction. There is.
  • the update information in the second storage unit 107 is used to determine whether or not there is data that may be updated by another transaction executed in parallel with the transaction. Judgment. If it is determined that the data exists, the update processing content of the transaction that updated the data is read from the first storage unit 109, and the restoration processing to the data before the update is performed.
  • the input unit 101 receives a data update request, a transaction request including a search request, and a transaction start request from a plurality of users.
  • the input unit 101 can accept requests from a plurality of users in parallel.
  • the update unit 103 reads out data stored in the database 110 via the buffer management unit 106 and performs update processing.
  • the update unit 103 causes the second storage unit 107 to store update information indicating that the data has been updated when the data update is completed.
  • the search unit 104 reads data stored in the database 110 via the buffer management unit 106 and performs a search process.
  • the transaction management unit 102 manages the update process by the update unit 103 and the search process by the search unit 104 as a series of transactions.
  • FIG. 3 is a flowchart showing general processing of the transaction management unit 102.
  • the transaction management unit 102 receives a transaction request and a transaction start request from the input unit 101 (S301).
  • the transaction management unit 102 assigns one transaction ID for one transaction (S302).
  • the transaction management unit 102 assigns transaction IDs in the order in which the input unit 101 receives requests.
  • the transaction management unit 102 stores therein the transaction ID of a transaction that has not been committed or aborted (S303).
  • the transaction management unit 102 determines whether or not all the update processing and search processing included in the transaction have succeeded (S304). If successful, the transaction is committed (S305). If it fails, the transaction is aborted (S306).
  • the transaction management unit 102 holds a transaction ID that is currently being processed.
  • the log management unit 105 records an update process or search process log by transaction in the first storage unit 109 at the end of each process.
  • the restoration unit 108 determines whether or not there is a possibility that the data to be searched is updated by another transaction executed in parallel when the search processing by the search unit 104 is performed in one transaction. The determination is made using the update information in the second storage unit 107.
  • the restoration unit 108 reads a transaction log from the first storage unit 109 when the determination is true. Restore the data using the transaction log.
  • the output unit 111 outputs search results.
  • FIG. 4 is an example diagram showing an XML document.
  • delivery form data described by an XML document having a document ID is taken as an example.
  • 4A and 4B each represent one XML document.
  • Each XML document is assigned a document ID for identifying each XML document. For example, the document ID “1” is assigned to the XML document in FIG. 4A, and the document ID “2” is assigned to the XML document in FIG. 4B.
  • FIG. 5 is an example diagram showing the structure of an XML document.
  • the structure of the XML document is a tree structure, and an item ID that is an identification number is assigned to each tag and text item.
  • the numbers in square brackets in FIG. 5 are item IDs.
  • the item ID “5” is attached to the “name” tag
  • the item ID “6” is attached to the text “name”.
  • the same item ID is assigned to a tag having the same name in the same hierarchy.
  • the item ID of the “product name” tag in the XML document in FIG. 4A is “13”
  • the item ID of the “product name” tag in the XML document in FIG. 4B is also “13”. is there.
  • FIG. 6 shows the data of each XML document in the database 110 and includes document structure information and partial data.
  • the partial data is data obtained by disassembling the XML document, and includes text information and index information of the XML document.
  • Document structure information is information describing the document structure of an XML document with an item ID.
  • the document structure information of an XML document with document ID “1” (hereinafter, document 1) is “1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22 ".
  • the “company name” item in the document 1 does not exist. Therefore, the document structure information of the document 2 is “1, 2, 3, 4, 5, 6, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22.
  • the item ID “7” of the tag “company name” and the item ID “8” of the text are not included in the structure information.
  • the index information is information indicating in what document and in what item each character formed by dividing a text string exists.
  • Examples of the character string dividing method include an “N-gram method” and a “morpheme analysis method”. For example, as shown in FIG. 6, the index information of “XX” in the document 1 is ““ XXX ”, 1, 6, 1”. This indicates that the character string “XX” exists at the “1” character of the item ID “6” of the document 1.
  • the database 110 stores XML document data in the form of document structure information and partial data. That is, an XML document as shown in FIG. 4 is created from the document structure information and the partial data.
  • the database 110 stores document structure information and partial data by attaching a partial data ID to each of the document structure information and partial data.
  • a partial data ID is attached to the document structure information
  • the partial data ID “2” is attached to the text information.
  • the database 110 stores a time data table in which each item ID is associated with the last update time that is the time when the item ID was last updated separately from the data of the XML document. . Thereby, the last update time which is the time when each item of each XML document was last updated by the update unit 103 is known.
  • FIG. 7 is a flowchart showing the update process of the database management system 10.
  • the input unit 101 receives a request from the user (S501). For example, in the input unit 101, the user “changes the customer information name of the document 1 from“ XX Taro ”to“ XX Jiro ”and sets the customer ID of the customer information of the document 2 as the customer ID. A request such as “change from“ 02345678 ”to“ 03345678 ”and commit the transaction” is accepted. The input unit 101 outputs the request to the transaction management unit 102 and the update unit 103.
  • the transaction management unit 102 assigns one transaction ID to one transaction executed in accordance with the request, and outputs a log such as the transaction start time to the log management unit 105 (S502).
  • the update unit 103 analyzes the update request and identifies the partial data ID to be updated. At this time, the update unit 103 has information that the partial data ID “2” may be specified in the design stage if the text (“Taro Taro” etc.) is updated.
  • the update unit 103 requests the buffer management unit 106 to read the partial data with the specified partial data ID from the database 110, execute the update process, and output a log such as update contents and update time to the log management unit 105. (S503).
  • the update unit 103 reads the partial data ID “2” of the document 1, updates “Taro XX” in the document 1 to “Jiro XX”, and also sets the partial data ID “2” of the document 1 at time t 1.
  • the update log “change the item ID“ 6 ”to“ Jiro ”” is output to the log management unit 105.
  • the partial data ID “4” of the document 1 is read, the “Taro” in the document 1 is updated to “Jiro”, and the item ID “4” of the partial data ID “2” of the document 2 is “02345678” at time t2.
  • An update log “change from“ 03345678 ”to“ 03345678 ” is output to the log management unit 105.
  • the log management unit 105 records the update log in the first storage unit 109. The same process is performed for document 2.
  • the update unit 103 updates the time data table of the updated item. For example, the update unit 103 updates the last update time of the item ID “6” of the document 1 to t1. The last update time of the item ID “4” of the document 2 is updated to t2.
  • the update unit 103 stores the partial data ID of the partial data updated by one transaction in the second storage unit 107 in association with the transaction ID (S504). For example, the update unit 103 updates the partial data ID “2” and the partial data ID “4” of the document 1 and the partial data ID “2” of the document 2 by the transaction with the transaction ID “1”. Update information is stored in the second storage unit 107.
  • the database management system 10 performs the update process.
  • FIG. 8 is a flowchart showing search and restoration processing of the database management system 10.
  • the input unit 101 receives a data search request from the user (S601). For example, the input unit 101 accepts a request from the user such as “Start a transaction, search for a document whose customer information name is“ Taro XX ”or“ XX Hanako ”, and commit the transaction”.
  • the input unit 101 outputs a data search request to the transaction management unit 102 and the search unit 104.
  • the transaction management unit 102 assigns a transaction ID to a transaction executed according to the transaction start request, outputs the transaction start time to the log management unit 105, and stores the transaction ID and the start time in the second storage unit 107.
  • the search unit 104 makes an inquiry to the transaction management unit 102, identifies a transaction that has not been committed or aborted when the search request is input, and determines the start time of the transaction with the earliest start time as the determination reference time. (S602).
  • the above-described “name of customer information of document 1 is changed from“ Taro ”to“ Jiro ”and customer ID of customer information of document 2 is changed from“ 02345678 ”to“ 03345678 ”. It is assumed that only the transaction (transaction ID “1”) that has been subjected to the update process “change to” is being executed (before committing or before aborting).
  • the determination reference time is the start time (set to t0) of the transaction ID “1”.
  • the search unit 104 specifies partial data to be searched from the search request (S603). At this time, the search unit 104 has information that the partial data ID “2” may be specified at the design stage if the search is for text (such as “Taro XXX”). For example, the search unit 104 analyzes a search request “search for a document whose customer information name is“ XX Taro ”or“ XX Hanako ”” and sets the partial data ID “2” of all document IDs. Identify as search target.
  • the search unit 104 searches for the requested search target data from among the specified partial data IDs of the search target, and acquires the last update time of the data from the time data table via the buffer management unit 106 (S604). .
  • the search unit 104 outputs the acquired result to the restoration unit 108.
  • the restoration unit 108 determines, for each item, whether or not the last update time of the item ID item ID of the received partial data ID is later than the determination reference time (S605).
  • the restoration unit 108 determines that the last update time of the item ID “6” of the partial data ID “2” of the document 1 is greater than the determination reference time t0. It is also determined whether it is later. Since the last update time of the item ID “6” of the partial data ID “2” of the document 1 is t1 at the time of inputting the search request, the final update of the partial data ID “2” of the item ID “6” of the document 1 is performed. The time is after t0.
  • the restoration unit 108 determines that the last update time of the item ID “6” of the partial data ID “2” of the document 2 is later than the determination reference time t0. It is determined whether or not. Since the item ID “6” of the partial data ID “2” of the document 2 is not updated by the update transaction of the transaction ID “1” at the time of inputting the search request, the partial data ID “2” of the document 2 is not updated. The last update time of the item ID “6” is before t0.
  • the restoration unit 108 When the last update time is earlier than the determination reference time (No determination in step S605), the restoration unit 108 outputs the search result to the output unit 111 and ends the process. For example, the restoration processing unit 108 outputs the document 2 as an XML document to the output unit 111 in a state where the item ID “6” of the partial data ID “2” of the document 2 is “XX Hanako”.
  • the restoration unit 108 searches the second storage unit 107, and the partial data to be searched is stored in the second storage as update information. It is determined whether it exists in the part 107 (S606).
  • the restoration unit 108 determines whether or not the partial data ID “2” of the document 1 exists in the second storage unit 107.
  • the restoration unit 108 If there is no update information related to the partial data to be searched in the second storage unit 107 (No in step S606), the restoration unit 108 outputs the search result as it is to the output unit 111, and ends the search process.
  • the restoration unit 108 sets the transaction ID for updating the partial data to be searched for to the second storage unit 107. Get from.
  • the restoration unit 108 reads the transaction update content of the acquired transaction ID from the first storage unit 109 via the log management unit 105. From the read log, a restoration process is performed to return the partial data to be searched to the partial data before the update process (S607).
  • the restoration unit 108 acquires the transaction ID “1” of the transaction in which the partial data ID “2” of the document 1 is updated from the second storage unit 107.
  • the restoration unit 108 reads the update processing log of the transaction ID “1” from the first storage unit 109 via the log management unit 105.
  • Update log exists.
  • the restoration unit 108 performs a restoration process for returning the data “XX Jiro” from the update log to “Taro XX”, which is the data before the update process.
  • the restoration unit 108 restores the item ID “6” of the partial data ID “2” of the document 1 to “XX Jiro” in the search result, and outputs it to the output unit 111.
  • the output unit 111 displays the search result with the partial data restored.
  • the database management system 10 can determine whether or not the data has been updated by the update process of another transaction during the search process with a small processing cost.
  • the present invention is not limited to the above-described embodiment as it is, and can be embodied by modifying constituent elements without departing from the scope of the invention in the implementation stage.
  • various inventions can be formed by appropriately combining a plurality of components disclosed in the embodiment. For example, some components may be deleted from all the components shown in the embodiment.
  • constituent elements over different embodiments may be appropriately combined.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

　トランザクション管理部（１０２）は、更新部（１０３）による更新処理、及び、検索部（１０４）による検索処理をトランザクションとして管理し、トランザクション開始要求時にトランザクションＩＤを割り当てる。第１の記憶部は、トランザクションによる更新処理のログを記憶する。記憶部（１０７）は、更新部（１０３）によりデータが更新された場合に、データの更新がなされたことを示す更新情報をトランザクションＩＤに対応付けて記憶する。復元部（１０８）は、検索部（１０４）により検索された際に、検索対象となるデータの更新情報が、記憶部（１０７）に存在するか否かを判定し、判定が真の場合に、データを更新したトランザクションを第１の記憶部から読み出し、データの復元処理を行う。

Description

データベース管理システム
　本発明は、データベース管理システムに関する。
　複数のトランザクション間で、更新処理や検索処理が並行して実行される場合において、データの整合性を保つために、データベースを管理するデータベース管理システムがある。
　このようなデータベース管理システムでは、一のトランザクションにより更新が行われた場合、その更新がコミットまたはアボートされるまでは他のトランザクションに対しては更新前のデータをユーザに提示する。この処理を行うため、一のトランザクションの更新処理によりデータが更新された場合は、更新内容を記録したログファイルを作成する。別のトランザクションで検索要求がなされると、他のトランザクションによる、コミットまたはアボート前のデータ更新の有無を判定する。
　データの更新が行われたと判定した場合、検索要求したトランザクションは、別のトランザクションにより更新されたデータとログファイルとを用いて、更新前のデータを復元する。
　データ更新の有無を判定する方法として、例えば特許文献１では、実表データ部とインデックス部とにカウンタを設ける。更新要求がなされると、実表データ部中のデータを更新し、カウンタの値を１増加させる。インデックス部中のカウンタの値を１増加させる。
　別のトランザクションにより検索要求がなされると、検索条件に従ってインデックス部を検索し、検索結果とともに検索箇所のカウンタの値を記憶する。次に実表データ部を検索し、検索結果に対応するデータのカウンタと記憶したカウンタの値とを比較する。
　両カウンタが同値の場合、検索要求を行ったトランザクションは、検索結果を出力する。同値でない場合は、再度インデックス部から検索をやり直す。
特許第４０４７５５７号公報
　上述したデータベース管理システムでは、インデックス部にカウンタという付加情報を設けなければならず、処理コストが増大する。
　本発明では、一のトランザクションの検索処理中に別のトランザクションが更新処理を行ってデータの更新が行われたか否かを、少ない処理コストで判定することが可能なデータベース管理システムを提供することを目的とする。
　本発明の一側面に係るデータベース管理システムは、データベースに記憶される構造化文書データの更新要求及び検索要求を含むトランザクション要求及びトランザクションの開始要求を入力する入力部と、前記更新要求に従って、前記構造化文書データ中の更新対象となるデータの更新処理を実行する更新部と、前記検索要求に従って、前記構造化文書データ中の検索対象となる前記データの検索処理を実行する検索部と、前記トランザクションを複数管理し、前記トランザクションの開始要求時に一の前記トランザクションにつき一のトランザクションＩＤを割り当てるトランザクション管理部と、第１のトランザクションにおける更新処理のログを記憶する第１の記憶部と、前記更新部により前記データが更新された場合に、前記データの更新がなされたことを示す更新情報を前記トランザクションＩＤに対応付けて記憶する第２の記憶部と、第１のトランザクションとは別の第２のトランザクションにおける前記検索部により前記データが検索された際、検索対象となる前記データの更新情報が、前記第２の記憶部に存在する場合に、前記データを更新したトランザクションのログを前記ログ記憶部から読み出し、前記データの復元処理を行う復元部とを備える。
　本発明によれば、一のトランザクションの検索処理中に別のトランザクションが更新処理を行ってデータの更新が行われたか否かを、少ない処理コストで判定することができる。
一のトランザクションによる更新処理と別のトランザクションによる検索処理の時間関係を表す図 第１の実施の形態に係るデータベース管理システムを表すブロック図 トランザクション管理部１０２の一般的な処理を表すフローチャート ＸＭＬ文書を表す一例図 ＸＭＬ文書の構造を表す一例図 データベース内の各々のＸＭＬ文書のデータを示す図 データベース管理システムの更新処理を表すフローチャート データベース管理システムの検索及び復元処理を表すフローチャート
　以下、本発明の実施の形態について図面を参照して説明する。
　既出の図に関して前述したものと同様の要素には同一の符号を付して詳細な説明は適宜省略する。
　（第１の実施の形態）
　トランザクションとは、ユーザから要求されたデータベースに対する更新処理及び検索処理からなる一又は複数の処理を一の処理単位としてまとめたものである。トランザクションは、更新処理の場合もある。トランザクションは、検索処理のみの場合もある。
　第１の実施の形態に係るデータベース管理システムは、データベースに記憶されるＸＭＬ文書のデータに対する更新処理及び検索処理を行う。
　図１は、一のトランザクションによる更新処理（トランザクション１）と別のトランザクションによる検索処理（トランザクション２）の時間関係を表す図である。
　トランザクション１および２はランダムに発生する。例えば、トランザクション開始時のデータベースを用いてデータの検索を行うため、一のトランザクション（トランザクション２）における検索処理の実行中に、別のトランザクション（トランザクション１）によってデータの内容が更新されると、出力時点の検索結果とデータの内容とが不整合な状態となることが生じる。本実施の形態に係るデータベース管理システム１０は、一のトランザクションの処理中に別のトランザクションによりデータの更新が行われたか否かを少ない処理コストで判定し、トランザクションが検索するデータベースの復元を行う。
　図２は、第１の実施の形態に係るデータベース管理システム１０を表すブロック図である。
　データベース管理システム１０は、入力部１０１と、トランザクション管理部１０２と、更新部１０３と、検索部１０４と、ログ管理部１０５と、バッファ管理部１０６と、第２の記憶部１０７と、復元部１０８と、トランザクションのログを記憶する第１の記憶部１０９と、データベース１１０と、出力部１１１とを含む。ログは、トランザクションによる更新処理内容と検索処理内容とトランザクションとを含む。
　データベース１１０には、例えばＸＭＬ文書などのデータを記憶している。このデータベース１１０に対して、入力部１０１が受け付けるトランザクションに応じた処理を行う。例えば、トランザクションが検索である場合には、検索部１０４がデータベース１１０から要求されたデータを検索する。トランザクションが更新である場合には、更新部１０３が、データベース１１０に対して要求されたデータを更新する。
　このようなトランザクション処理はトランザクション管理部１０２によって管理される。この場合、ログ管理部１０５が、トランザクションのログを第１の記憶部１０９に記録している。
　トランザクションとして、データの検索要求がなされた場合、データベース管理システム１０は、トランザクションにより検索するデータの中に、該トランザクションと並行して実行されている他のトランザクションにより更新されている場合が生じる可能性がある。
　このため、本実施形態では、トランザクションと並行して実行されている他のトランザ
クションにより更新されている可能性のあるデータが存在するか否かを、第２の記憶部１０７にある更新情報を用いて判定する。存在すると判定した場合には、そのデータについて更新を行ったトランザクションの更新処理内容を第１の記憶部１０９から読みだし、更新前のデータへの復元処理を行う。
　入力部１０１は、複数のユーザから、データの更新要求、検索要求を含むトランザクション要求、及びトランザクションの開始要求を受け付ける。入力部１０１は、複数のユーザからの要求を並行して受け付けることができる。
　更新部１０３は、バッファ管理部１０６を介して、データベース１１０に記憶されているデータを読み出し、更新処理を行う。更新部１０３は、データの更新が完了した時点で、該データが更新されたことを示す更新情報を第２の記憶部１０７に記憶させる。検索部１０４は、バッファ管理部１０６を介して、データベース１１０に記憶されているデータを読み出し、検索処理を行う。
　トランザクション管理部１０２は、更新部１０３による更新処理や、検索部１０４による検索処理を一連のトランザクションとして管理する。図３は、トランザクション管理部１０２の一般的な処理を表すフローチャートである。トランザクション管理部１０２には、入力部１０１からのトランザクション要求及びトランザクション開始要求が入力される（Ｓ３０１）。トランザクション管理部１０２は、一のトランザクションにつき、一のトランザクションＩＤを割り当てる（Ｓ３０２）。トランザクション管理部１０２は、入力部１０１が要求を受け付けた順番にトランザクションＩＤを割り当てる。トランザクション管理部１０２は、コミット又はアボートされていないトランザクションのトランザクションＩＤを内部に記憶する（Ｓ３０３）。トランザクション管理部１０２は、トランザクションに含まれる更新処理や検索処理が全て成功したか否かを判定する（Ｓ３０４）。成功した場合はトランザクションをコミットする（Ｓ３０５）。失敗した場合は、トランザクションをアボートする（Ｓ３０６）。
　すなわち、トランザクション管理部１０２は、現在処理を実行中のトランザクションＩＤを保持している。
　ログ管理部１０５は、トランザクションによる更新処理や検索処理のログを各々の処理終了の時点で第１の記憶部１０９に記録する。復元部１０８は、一のトランザクションにおいて、検索部１０４による検索処理が行われる際に、検索対象となるデータが、他の並行して実行されるトランザクションにより更新された可能性があるか否かを第２の記憶部１０７の更新情報を用いて判定する。
　復元部１０８は、該判定が真の場合に、第１の記憶部１０９からトランザクションのログを読み出す。トランザクションのログを用いて、データの復元を行う。出力部１１１は、検索結果を出力する。
　図４は、ＸＭＬ文書を表す一例図である。本実施の形態では、文書ＩＤを持つＸＭＬ文書により記述された納品書のデータを例とする。図４（ａ）及び（ｂ）は、それぞれ一のＸＭＬ文書を表している。各々のＸＭＬ文書には、各々のＸＭＬ文書を識別するための文書ＩＤが付されている。例えば、図４（ａ）のＸＭＬ文書には文書ＩＤ「１」が付され、図４（ｂ）のＸＭＬ文書には文書ＩＤ「２」が付される。
　図５は、ＸＭＬ文書の構造を表す一例図である。ＸＭＬ文書の構造は木構造であり、各々のタグ及びテキストの項目には、識別番号である項目ＩＤが付されている。図５の大括弧内の数字が項目ＩＤである。例えば、図４（ａ）に示す文書ＩＤが１のＸＭＬ文書において、「氏名」のタグには項目ＩＤ「５」が付され、「氏名」のテキストには、項目ＩＤ「６」が付される。各々のＸＭＬ文書において、同一階層の同一名のタグには同一の項目ＩＤが付される。例えば、図４（ａ）のＸＭＬ文書の「商品名」のタグの項目ＩＤは「１３」であり、図４（ｂ）のＸＭＬ文書の「商品名」のタグの項目ＩＤも「１３」である。
　図６は、データベース１１０内の各々のＸＭＬ文書のデータを示すもので、文書構造情報と、部分データとを含む。部分データとは、ＸＭＬ文書を分解したデータであり、ＸＭＬ文書のテキスト情報と索引情報とを含む。
　文書構造情報とは、ＸＭＬ文書の文書構造を項目ＩＤで記述した情報である。例えば、図６に示すように、文書ＩＤ「１」のＸＭＬ文書（以下、文書１）の文書構造情報は、「１，２，３，４，５，６，７，８，９，１０，１１，１２，１３，１４，１５，１６，１７，１８，１９，２０，２１，２２」と表わされる。文書ＩＤ「２」のＸＭＬ文書（以下、文書２）には、文書１における「会社名」の項目が存在しない。そのため、文書２の文書構造情報は、「１，２，３，４，５，６，９，１０，１１，１２，１３，１４，１５，１６，１７，１８，１９，２０，２１，２２」と表わされ、「会社名」のタグの項目ＩＤ「７」及びテキストの項目ＩＤ「８」は、構造情報に含まれない。
　テキスト情報とは、テキストの内容と項目ＩＤとを対応付けた情報である。例えば、図６に示すように、文書１のテキスト情報には、「４＝“０１２３４５６７”」等がある。これは項目ＩＤ「４」のテキストは、「０１２３４５６７」であることを示している。
　索引情報とは、テキストの文字列を分割してできた各々の文字が、どの文書の、どの項目の、何番目に存在するかを示す情報である。文字列の分割方法には、「Ｎグラム法」や「形態素解析法」等がある。例えば、図６に示すように、文書１における「○○」の索引情報は「“○○”,１,６,１」である。これは、「○○」という文字列は、文書１の項目ＩＤ「６」の「１」文字目に存在することを示している。
　データベース１１０は、ＸＭＬ文書のデータを、文書構造情報と部分データの状態で記憶している。すなわち、文書構造情報と部分データとから、図４に表したようなＸＭＬ文書が作成される。
　さらに、本実施の形態において、データベース１１０は、文書構造情報と部分データの各々に部分データＩＤを付して、文書構造情報及び部分データを記憶している。例えば、文書構造情報には、部分データＩＤ「１」が付され、テキスト情報には、部分データＩＤ「２」が付される。
　また、データベース１１０は、各々の項目ＩＤと、該項目ＩＤの更新が最後に行われた時刻である最終更新時刻とを対応付けた時刻データテーブルを、ＸＭＬ文書のデータとは別に記憶している。これにより、各々のＸＭＬ文書の各々の項目が、更新部１０３により最後に更新された時刻である最終更新時刻が分かる。
　図７は、データベース管理システム１０の更新処理を表すフローチャートである。入力部１０１は、ユーザからの要求を受けつける（Ｓ５０１）。例えば、入力部１０１には、ユーザから、「トランザクションを開始し、文書１の顧客情報の氏名を“○○太郎”から“○○次郎”に変更して、文書２の顧客情報の顧客ＩＤを“０２３４５６７８”から“０３３４５６７８”に変更して、トランザクションをコミットせよ」といった要求を受け付ける。入力部１０１は、該要求をトランザクション管理部１０２と更新部１０３とに出力する。
　トランザクション管理部１０２は、該要求に従って実行される一のトランザクションに、一のトランザクションＩＤを割り当て、トランザクションの開始時刻等のログをログ管理部１０５に出力する（Ｓ５０２）。
　更新部１０３は、更新要求を解析し、更新対象となる部分データＩＤを特定する。その際、更新部１０３には、テキスト（「○○太郎」等）の更新であれば部分データＩＤ「２」と特定すれば良いという情報を設計段階で持たせておく。
更新部１０３は、バッファ管理部１０６に要求して、特定した部分データＩＤの部分データをデータベース１１０から読み出し、更新処理を実行し、更新内容や更新時刻等のログをログ管理部１０５に出力する（Ｓ５０３）。
　例えば、更新部１０３は、文書１の部分データＩＤ「２」を読み出し、その中の「○○太郎」を「○○次郎」に更新するとともに、時刻ｔ１に、文書１の部分データＩＤ「２」の項目ＩＤ「６」を“○○次郎”に変更」という更新ログをログ管理部１０５に出力する。文書１の部分データＩＤ「４」を読み出し、その中にある「太郎」を「次郎」に更新するとともに、時刻ｔ２に、文書２の部分データＩＤ「２」の項目ＩＤ「４」を“０２３４５６７８”から“０３３４５６７８”に変更」という更新ログをログ管理部１０５に出力する。ログ管理部１０５は、更新ログを第１の記憶部１０９に記録する。文書２についても同様の処理を行う。
　このとき、更新部１０３は更新した項目の時刻データテーブルを更新する。例えば、更新部１０３は、文書１の項目ＩＤ「６」の最終更新時刻をｔ１に更新する。文書２の項目ＩＤ「４」の最終更新時刻をｔ２に更新する。
　更新部１０３は、一のトランザクションによって更新された部分データの部分データＩＤをトランザクションＩＤに対応付けて、第２の記憶部１０７に記憶させる（Ｓ５０４）。部分データ例えば、更新部１０３は、トランザクションＩＤ「１」のトランザクションによって、文書１の部分データＩＤ「２」と部分データＩＤ「４」、及び文書２の部分データＩＤ「２」が更新されたという更新情報を第２の記憶部１０７に記憶させる。
　以上のようにして、データベース管理システム１０は、更新処理を行う。
　図８は、データベース管理システム１０の検索及び復元処理を表すフローチャートである。入力部１０１は、ユーザからのデータの検索要求を受けつける（Ｓ６０１）。例えば、入力部１０１には、ユーザから「トランザクションを開始し、顧客情報の氏名が“○○太郎”もしくは“××花子”である文書を検索し、トランザクションをコミットせよ」といった要求を受け付ける。入力部１０１は、データの検索要求をトランザクション管理部１０２と検索部１０４とに出力する。
　トランザクション管理部１０２は、トランザクション開始要求に従って実行されるトランザクションにトランザクションＩＤを割り当て、トランザクション開始時刻をログ管理部１０５に出力するとともに、トランザクションＩＤとその開始時刻を第２の記憶部１０７に記憶させる。
　検索部１０４は、トランザクション管理部１０２に問い合わせ、検索要求の入力時点にコミットまたはアボートされていないトランザクションを特定し、該トランザクションの中で最も開始時刻の早いトランザクションの開始時刻を判定基準時刻と決定する（Ｓ６０２）。
　例えば、検索要求の入力時に、上述した「文書１の顧客情報の氏名を“○○太郎”から“○○次郎”に変更して、文書２の顧客情報の顧客ＩＤを“０２３４５６７８”から“０３３４５６７８”に変更する」という更新処理を行ったトランザクション（トランザクションＩＤ「１」）のみが実行途中（コミット前かアボート前）であるとする。判定基準時刻は、トランザクションＩＤ「１」の開始時刻（ｔ０とする）である。
　そして、「文書１の顧客情報の氏名を“○○太郎”から“○○次郎”に変更する」という更新処理が時刻ｔ１に行われた後に、「顧客情報の氏名が“○○太郎”もしくは“××花子”である文書を検索せよ」という検索要求が入力部１０１に入力されたとする。
　検索部１０４は、検索要求から、検索対象となる部分データを特定する（Ｓ６０３）。その際、検索部１０４には、テキスト（「○○太郎」等）の検索であれば部分データＩＤ「２」と特定すれば良いという情報を設計段階で持たせておく。例えば、検索部１０４は、「顧客情報の氏名が“○○太郎”もしくは“××花子”である文書を検索せよ」という検索要求を解析し、全ての文書ＩＤの部分データＩＤ「２」を検索対象として特定する。
　検索部１０４は、特定した検索対象の部分データＩＤの中から要求された検索対象のデータを探し、該データの最終更新時刻を、バッファ管理部１０６を介して時刻データテーブルから取得する（Ｓ６０４）。検索部１０４は、取得した結果を復元部１０８に出力する。復元部１０８は、受け取った部分データＩＤの項目ＩＤの項目の最終更新時刻が、判定基準時刻より後であるか否かを一の項目ごとに判定する（Ｓ６０５）。
　例えば、顧客情報の氏名が「○○太郎」である文書の検索において、復元部１０８は、文書１の部分データＩＤ「２」の項目ＩＤ「６」の最終更新時刻が、判定基準時刻ｔ０よりも後であるか否かを判定する。検索要求の入力時点において、文書１の部分データＩＤ「２」の項目ＩＤ「６」の最終更新時刻はｔ１であるので、文書１の項目ＩＤ「６」の部分データＩＤ「２」の最終更新時刻はｔ０より後である。
　顧客情報の氏名が「××花子」である文書の検索において、復元部１０８は、文書２の部分データＩＤ「２」の項目ＩＤ「６」の最終更新時刻が、判定基準時刻ｔ０よりも後であるか否かを判定する。検索要求の入力時点において、トランザクションＩＤ「１」の更新トランザクションによって、文書２の部分データＩＤ「２」の項目ＩＤ「６」の更新は行われていないので、文書２の部分データＩＤ「２」の項目ＩＤ「６」の最終更新時刻はｔ０より前である。
　最終更新時刻が、判定基準時刻より前の場合（ステップＳ６０５においてＮｏの判定）、復元部１０８は、検索結果を出力部１１１に出力し、処理を終了する。例えば、復元処理部１０８は、文書２の部分データＩＤ「２」の項目ＩＤ「６」は「××花子」の状態で、文書２をＸＭＬ文書として出力部１１１に出力する。
　最終更新時刻が、判定基準時刻より後の場合（ステップＳ６０５においてＹｅｓの判定）、復元部１０８は、第２の記憶部１０７を検索し、検索対象の部分データが、更新情報として第２の記憶部１０７に存在するか否かを判定する（Ｓ６０６）。
　例えば、復元部１０８は、文書１の部分データＩＤ「２」が、第２の記憶部１０７に存在するか否かを判定する。
上述したトランザクションＩＤ「１」の更新トランザクションにより「文書１の顧客情報の氏名を“○○太郎”から“○○次郎”に変更する」という更新が行われたため、第２の記憶部１０７には、文書ＩＤ「１」の部分データＩＤ「２」が、更新情報として存在する。
　検索対象の部分データに関する更新情報が第２の記憶部１０７に存在しない場合（ステップＳ６０６においてＮｏの判定）、復元部１０８は、検索結果をそのまま出力部１１１に出力し、検索処理を終了する。
　検索対象の部分データに関する更新情報が第２の記憶部１０７に存在する場合（ステップＳ６０６においてＹｅｓの判定）、復元部１０８は、検索対象の部分データを更新したトランザクションＩＤを第２の記憶部１０７から取得する。復元部１０８は、取得したトランザクションＩＤのトランザクションの更新内容を、ログ管理部１０５を介して、第１の記憶部１０９から読み出す。読み出したログから、検索対象の部分データを更新処理前の部分データへ戻す復元処理を行う（Ｓ６０７）。
　例えば、復元部１０８は、文書１の部分データＩＤ「２」を更新したトランザクションのトランザクションＩＤ「１」を第２の記憶部１０７から取得する。復元部１０８は、ログ管理部１０５を介して、トランザクションＩＤ「１」の更新処理のログを第１の記憶部１０９から読み出す。該ログには、上述したように、「トランザクションＩＤ「１」のトランザクションにより、時刻ｔ１に、文書１の部分データＩＤ「２」の項目ＩＤ「６」を“○○次郎”に変更」という内容の更新ログが存在する。そのため、復元部１０８は、更新ログから、「○○次郎」というデータを更新処理前のデータである「○○太郎」へ戻す復元処理を行う。
　復元部１０８は、検索結果のうち、文書１の部分データＩＤ「２」の項目ＩＤ「６」を「○○次郎」に復元し、出力部１１１に出力する。出力部１１１は、部分データが復元された検索結果を表示する。
　なお、トランザクション管理部１０２は、第２の記憶部１０７に記憶されている部分データＩＤに対応するトランザクションをコミット又はアボートした場合、該部分データを消去するのが望ましい。
　これにより、データベース管理システム１０は、検索処理中に他のトランザクションの更新処理によりデータの更新が行われたか否かを、少ない処理コストで判定することが可能となる。
　なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
１０１　入力部
１０２　トランザクション管理部
１０３　更新部
１０４　検索部
１０５　ログ管理部
１０６　バッファ管理部
１０７　第２の記憶部
１０８　復元部
１０９　第１の記憶部
１１０　データベース

Claims (4)

  1. データベースに記憶される構造化文書データの更新要求及び検索要求を含むトランザクション要求及びトランザクションの開始要求を入力する入力部と、
    前記更新要求に従って、前記構造化文書データ中の更新対象となるデータの更新処理を実行する更新部と、
    前記検索要求に従って、前記構造化文書データ中の検索対象となる前記データの検索処理を実行する検索部と、
    前記トランザクションを複数管理し、前記トランザクションの開始要求時に一の前記トランザクションにつき一のトランザクションＩＤを割り当てるトランザクション管理部と、
    第１のトランザクションにおける更新処理のログを記憶する第１の記憶部と、
    前記更新部により前記データが更新された場合に、前記データの更新がなされたことを示す更新情報を前記トランザクションＩＤに対応付けて記憶する第２の記憶部と、
    第１のトランザクションとは別の第２のトランザクションにおける前記検索部により前記データが検索された際、検索対象となる前記データの更新情報が、前記第２の記憶部に存在する場合に、前記データを更新したトランザクションのログを前記ログ記憶部から読み出し、前記データの復元処理を行う復元部と
    を備えることを特徴とするデータベース管理システム。
  2. 前記データベースは、
    前記構造化文書データの構造情報を表す文書構造情報と、前記構造化文書データのテキスト内容を表すテキスト情報と、前記テキストを分割した文字の索引を表す索引情報とを含む部分データを記憶し、
    前記第２の記憶部は、
    前記更新部により更新された前記データを特定する部分データを更新情報として記憶する
    ことを特徴とする、請求項１記載のデータベース管理システム。
  3. 前記部分データは、識別子である部分データＩＤを有し、
    前記第２の記憶部は、
    前記更新部により更新された前記データを特定する前記部分データの前記部分データＩＤを記憶し、
    前記復元部は、
    前記検索の際に、検索対象となる前記データを特定する前記部分データの部分データＩＤが前記第２の記憶部に存在するか否かを判定する
    ことを特徴とする、請求項２記載のデータベース管理システム。
  4. 前記トランザクション管理部は、
    前記部分データに対応付けられた前記トランザクションをコミット又はアボートした場合、前記第２の記憶部の前記部分データを消去する
    ことを特徴とする、請求項３記載のデータベース管理システム。
PCT/JP2010/000895 2010-02-15 2010-02-15 データベース管理システム Ceased WO2011099082A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2011553654A JP5377672B2 (ja) 2010-02-15 2010-02-15 データベース管理システム
CN201080039794.2A CN102754083B (zh) 2010-02-15 2010-02-15 数据库管理系统
PCT/JP2010/000895 WO2011099082A1 (ja) 2010-02-15 2010-02-15 データベース管理システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/000895 WO2011099082A1 (ja) 2010-02-15 2010-02-15 データベース管理システム

Publications (1)

Publication Number Publication Date
WO2011099082A1 true WO2011099082A1 (ja) 2011-08-18

Family

ID=44367396

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/000895 Ceased WO2011099082A1 (ja) 2010-02-15 2010-02-15 データベース管理システム

Country Status (3)

Country Link
JP (1) JP5377672B2 (ja)
CN (1) CN102754083B (ja)
WO (1) WO2011099082A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10002158B2 (en) 2014-11-04 2018-06-19 International Business Machines Corporation Apparatus and method for processing a query

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104375995A (zh) * 2013-08-13 2015-02-25 苏州广海信息科技有限公司 一种数据库管理系统
CN106775468B (zh) * 2016-12-06 2020-01-10 曙光信息产业(北京)有限公司 分布式事务的实现方法和系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002351727A (ja) * 2001-05-29 2002-12-06 Fujitsu Ltd データベース管理システム，データベース管理処理方法，データベース管理システム用のプログラムおよびその記録媒体
JP2004046357A (ja) * 2002-07-09 2004-02-12 Toshiba Corp 文書編集方法、文書編集システム、サーバ装置および文書編集プログラム
JP2005025432A (ja) * 2003-07-01 2005-01-27 Fujitsu Ltd トランザクション処理方法，トランザクション制御装置およびトランザクション制御プログラム
JP2005234945A (ja) * 2004-02-20 2005-09-02 Toshiba Corp 同時実行制御方法及び装置
JP2009175854A (ja) * 2008-01-22 2009-08-06 Fujitsu Ltd データ整合性を確保するためのプログラム、方法及びコンピュータ・システム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002351727A (ja) * 2001-05-29 2002-12-06 Fujitsu Ltd データベース管理システム，データベース管理処理方法，データベース管理システム用のプログラムおよびその記録媒体
JP2004046357A (ja) * 2002-07-09 2004-02-12 Toshiba Corp 文書編集方法、文書編集システム、サーバ装置および文書編集プログラム
JP2005025432A (ja) * 2003-07-01 2005-01-27 Fujitsu Ltd トランザクション処理方法，トランザクション制御装置およびトランザクション制御プログラム
JP2005234945A (ja) * 2004-02-20 2005-09-02 Toshiba Corp 同時実行制御方法及び装置
JP2009175854A (ja) * 2008-01-22 2009-08-06 Fujitsu Ltd データ整合性を確保するためのプログラム、方法及びコンピュータ・システム

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
KIN'YA FUJIZUKA: "Enterprise Riyo ga Kasoku suru Nidai Open-Source RDBMS PostgreSQL to MySQL no 'Mechanism' to 'Chigai' o Shiru", COMPUTERWORLD GET TECHNOLOGY RIGHT, vol. 2, no. 8, 1 August 2005 (2005-08-01), pages 78 - 83 *
KIN'YA FUJIZUKA: "Open-Source DB no Kihon Kozo o Shiru", NIKKEI SYSTEM KOCHIKU, 26 September 2004 (2004-09-26), pages 198 - 203 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10002158B2 (en) 2014-11-04 2018-06-19 International Business Machines Corporation Apparatus and method for processing a query
US10120894B2 (en) 2014-11-04 2018-11-06 International Business Machines Corporation Apparatus and method for processing a query

Also Published As

Publication number Publication date
CN102754083B (zh) 2015-08-05
JPWO2011099082A1 (ja) 2013-06-13
CN102754083A (zh) 2012-10-24
JP5377672B2 (ja) 2013-12-25

Similar Documents

Publication Publication Date Title
US8290991B2 (en) Atomic deletion of database data categories
EP2784665B1 (en) Program and version control method
CN105630863B (zh) 用于多版本并发提交状态的事务控制块
CA2941074C (en) Managing storage of individually accessible data units
JP5922716B2 (ja) 個別にアクセス可能なデータユニットの記憶の取り扱い方法
US9916313B2 (en) Mapping of extensible datasets to relational database schemas
US8214411B2 (en) Atomic deletion of database data categories
US8473955B2 (en) Reducing processing overhead and storage cost by batching task records and converting to audit records
US20120078859A1 (en) Systems and methods to update a content store associated with a search index
CN109902130A (zh) 一种数据存储方法、数据查询方法和装置、存储介质
US20060069672A1 (en) Query forced indexing
US8055646B2 (en) Prevention of redundant indexes in a database management system
CN107958023A (zh) 数据同步方法、数据同步装置和计算机可读存储介质
JPWO2010084754A1 (ja) データベースシステム、データベース管理方法、及びデータベース構造
JP5377672B2 (ja) データベース管理システム
CN106503186A (zh) 一种数据管理方法、客户端及系统
JP2015176407A (ja) 検索装置、検索方法、検索用プログラムおよび検索用データ構造
JP7274293B2 (ja) 情報処理装置、情報処理方法及びプログラム
JP2020194335A (ja) 情報処理システム
US8037113B2 (en) Techniques for file system searching
JP2009037359A (ja) データ登録検索方法、データ登録検索プログラムおよびデータベースシステム
JP4825504B2 (ja) データ登録・検索システムおよびデータ登録・検索方法
JP2003208346A (ja) データベース更新情報の反映システムおよびそのためのプログラム
US20170262512A1 (en) Search processing method, search processing apparatus, and non-transitory computer-readable recording medium storing search processing program
JP5226445B2 (ja) データベースに対する問合せを処理する装置、処理方法、プログラムおよび記録媒体

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201080039794.2

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10845687

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2011553654

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10845687

Country of ref document: EP

Kind code of ref document: A1