WO2009147846A1 - データベース並行編集の競合解消方式 - Google Patents

データベース並行編集の競合解消方式 Download PDF

Info

Publication number
WO2009147846A1
WO2009147846A1 PCT/JP2009/002490 JP2009002490W WO2009147846A1 WO 2009147846 A1 WO2009147846 A1 WO 2009147846A1 JP 2009002490 W JP2009002490 W JP 2009002490W WO 2009147846 A1 WO2009147846 A1 WO 2009147846A1
Authority
WO
WIPO (PCT)
Prior art keywords
version
database
edit
editing
record
Prior art date
Application number
PCT/JP2009/002490
Other languages
English (en)
French (fr)
Inventor
上村邦夫
Original Assignee
株式会社 アテナテレコムラボ
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
Priority claimed from PCT/JP2008/001424 external-priority patent/WO2008149552A1/ja
Priority claimed from PCT/JP2008/001506 external-priority patent/WO2009147701A1/ja
Application filed by 株式会社 アテナテレコムラボ filed Critical 株式会社 アテナテレコムラボ
Priority to JP2010515774A priority Critical patent/JP5543918B2/ja
Priority to US12/995,158 priority patent/US9678996B2/en
Publication of WO2009147846A1 publication Critical patent/WO2009147846A1/ja
Priority to US12/688,854 priority patent/US8171003B2/en
Priority to US13/714,422 priority patent/US20130110777A1/en
Priority to US13/726,549 priority patent/US20130179652A1/en
Priority to US13/802,740 priority patent/US20130204842A1/en
Priority to US15/449,961 priority patent/US20170177647A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/273—Asynchronous replication or reconciliation

Definitions

  • the present invention solves editing conflicts that occur when a database (hereinafter “DB”) is edited in parallel (hereinafter “parallel DB editing”) for a plurality of replicas.
  • DB database
  • parallel DB editing parallel DB editing
  • a database is placed in a server computer (hereinafter “server”), and an operation is performed in which a plurality of terminal computers (hereinafter “PC”) access.
  • server server computer
  • PC terminal computers
  • a vestigec lock cursor Non-Patent Document 1
  • Non-Patent Document 2 a transaction lock
  • Non-Patent Document 3 also uses an edit lock (Non-Patent Document 4 and Non-Patent Document 5), and OODB products Cache (Non-Patent Document 6) and ObjectStore (Non-Patent Document 7) also use an edit lock.
  • OODB products Cache Non-Patent Document 6
  • ObjectStore Non-Patent Document 7
  • Patent Document 1 is also an edit lock.
  • Non-Patent Document 8 Non-Patent Document 9
  • this method is referred to as “first-come-first-served” for comparison with other methods. This “first-come-first-served” sometimes causes the following inconveniences.
  • Patent Document 3 based on the editing time in the duplicate DB, the competing editing versions are “re-referenced from the earliest time (Step S604)” (paragraph 0065 and paragraph 0079 in Patent Document 3), and “Update content information with the oldest date and time to the latest version” (paragraph 0097). In other words, the one that was edited first is given priority. In the present application, this method is referred to as “first editing priority” for comparison with other methods.
  • Patent Document 4 also has the same problem because the update time is valid for the previous update.
  • Patent Document 6 is an invention relating to a condition for starting the synchronization of a database, and the synchronization method merely shows a general synchronization concept of “synchronizing by notifying each other of update information”.
  • edit record in the present application
  • the order of application to the DB differs for each PC for various reasons (delay due to error retransmission, transmission timing deviation, etc.).
  • delay due to error retransmission, transmission timing deviation, etc. There is a possibility that a serious problem is expected that the contents of each replicated DB are different. However, no countermeasure has been shown for this.
  • Patent Document 7 is an invention for the purpose of “holding all update data” when an editing conflict occurs.
  • the original is updated only when there is no conflict, and the object and contents are different from the present invention.
  • Non-Patent Document 10 is an invention related to file caching, and when it detects an edit conflict (competition in this application), it simply rejects the edit (10th line from the lower right on page 7 of Non-Patent Document 10). Therefore, it is not determined which of the edited editing is effective as in the present application.
  • Patent Literature 8 Patent Literature 9
  • Patent Literature 10 Patent Literature 11
  • Patent Literature 12 were also investigated, none of them can be applied to the contradiction resolution by parallel DB editing, which is the purpose of the present application.
  • Japanese Patent Laid-Open No. 11-272534 Japanese Patent Laid-Open No. 61-134553 JP 2005-216167 A JP 9-91184
  • Japanese Laid-Open Patent Publication No. 2006-284998 Japanese Patent Laid-Open No. 11-161535 JP 2005-503606 Gazette JP 2005-508050 A JP-A-8-16447 Special table 2000-501532 gazette William R.
  • An object of the present application is to solve an “editing conflict” that occurs when DB replication exists in a plurality of PCs and parallel DB editing is performed on these PCs in parallel.
  • first-come-first-priority "first-edit priority”
  • unconditional overwrite method which are extensions of the cache technology.
  • the replica DB held by each PC is positioned as a temporary replica as a cache, and it is estimated that some problems are ignored.
  • the present application proposes a full-fledged “parallel DB editing” in which each PC permanently holds a duplicate DB, and clarifies a method of editing conflict resolution suitable for this. Also consider application to cache technology.
  • editing conflicts in parallel DB editing are resolved with a policy of “prioritizing editing based on the latest information”.
  • the case used for full-fledged parallel database editing and its application to cache technology will be described. Below, it demonstrates based on one example of application.
  • Preparation A replica DB (hereinafter “local original DB”) in an initial state of an original DB (hereinafter “global original DB”) is placed on a plurality of PCs.
  • this local original DB an initial version, that is, an order number for identifying the update order, is set.
  • this order number is an integer, and it is natural to set “0” as the initial value. In this application, this version is used to resolve conflicts.
  • Each PC updates the version of the duplicate DB at their respective (possibly operator's) convenience. Details of this will be described below.
  • Edited contents are general edited contents such as which information has been changed in what manner, which information has been added, and which information has been deleted.
  • Edited version is the version of the local original DB to be edited, strictly speaking, the version of the local original DB that is the replication source of the work DB to be edited.
  • the “invariant confirmation range” is a range of information assumed by this editing. If this range of information is changed before the edit is finalized, this indicates that the edit is meaningless.
  • the “invariant confirmation range” can be specified in various ways according to the characteristics of information handled by the DB, particularly the information to be edited. In general operation, the information to be edited seems to be in the “invariant confirmation range”, but it is not always necessary to enter it. In the case of a relational DB (hereinafter “RDB”), a table to be edited, a group of tables logically related to the object to be edited, a part of the records, or the entire DB can be considered.
  • RDB relational DB
  • the usability of the DB is improved. If the “invariant confirmation range” is small, many parallel editing can be performed without any problem. Therefore, it is preferable to set the indispensable minimum information (combination) as the invariable range.
  • the server records the edit records that have arrived from the PC together with the order of arrival.
  • the PC requests the server to send unedited edit records, and receives these edit records, the corresponding edit versions, and if necessary the invariant confirmation range and version setting range. To do. At the same time, the order of arrival of edit records to the server is received. If the server records the arrival order in the edit record that arrives from the PC, the communication procedure is simplified.
  • the local original DB update PC retrieves the edit records received from the server in the specified order, and determines the validity of the edit records. Details of this determination procedure will be described later in “Effectiveness Determination Procedure”. Then, the local original DB is updated to update its version. If the version is an integer, it is natural to increase the value one by one from the initial value “0”. Note that the PC processes all the specified editing records to the end (no new editing work is entered on the way). Accordingly, the local original DB may be updated at a stretch until the last editing record received from the server, and the version may be updated thereafter (by the number of processed editing records).
  • Each PC updates its local original DB when it is convenient, so when viewed in real time, the progress of the version of the local original DB of each PC varies. However, the order in which the versions are updated is the same. If the versions are the same, the contents of the local original DB are the same. That is, the version corresponds to a time common to each PC in parallel DB access. In other words, in the present invention, the local original DB of each PC is synchronized in the time called version.
  • the condition that Y is invalid with respect to X is when one of the following two conditions is satisfied. If at least one X is invalid, Y is determined to be invalid, and the local original DB is not updated by Y.
  • condition that Y is valid for X is when one of the following two conditions is satisfied. Note that Y is valid when valid for all X, and updating of the local original DB by Y is executed.
  • the edit record Y that has been uploaded is taken out, the invariable confirmation range is investigated, and the relationship with the edit X is evaluated by the “validity determination procedure”. If it is invalid through one X, Y is judged invalid. The operator of this PC confirms the fact of the invalidation and the reason thereof, and tries to edit again (for the latest information) if necessary. If there is a record of the original input that has been invalidated, it is easy to enter the contents again. If it is valid, the local original DB is updated with the edit record Y.
  • edit record and its order The edit record and its order transmitted from the operation server to the PC do not necessarily have to be the contents that the PC is up, and it is not necessary to keep the up order. If the edit record and the order are the same for all PCs, these local original DBs are synchronized.
  • the server or the PC in charge of management work may analyze the contents of the edit record, and delete a portion that becomes invalid due to an error or a redundant portion (same as nothing to do after all). There is no problem even if the editing records of errors or redundant editing records are deleted and the order of editing records is reduced. Even if the order of editing and recording is intentionally changed in consideration of the priority of the operator, the local original DB is synchronized.
  • the “local original DB” is updated using a series of edits received from the server.
  • the “local original DB” By updating the “local original DB” with the same initial value of the “local original DB”, the same order and contents of the edit records applied to it, and the same logic, the “local original DB” of the PC that has received up to the same edit record The contents of the “original DB” match.
  • the “local original DB” of each PC is synchronized. It can be said that it is synchronized with the virtual global original DB.
  • a global original DB exists in the server, and each PC has a local original DB that is a copy of the PC.
  • each PC creates an edit record and sends it to the server.
  • C The server confirms the editing conflict in the order of arrival of the editing records from the PC, updates the global original DB with the editing determined to be valid, and updates the version.
  • D With the information from the server, each PC updates, that is, synchronizes with, its local original DB.
  • the unit for assigning the introduction version of the version setting range and managing editing is an actual DB. If the influence of the information modification is closely related to the “version setting range” and a version is set for each, the editing and version transition of the range can be managed.
  • the setting of the optimal version setting range depends on the structure and contents of information to be handled.
  • RDB a record, a table, a table group logically related to the table, a specific record group among them, a whole DB, or the like is assumed.
  • the procedure described above can be applied by replacing DB with a version setting range. There is no problem even if editing for a plurality of version setting ranges is described in one editing record. For each version setting range, “edited contents”, “edited version”, “invariable confirmation range”, etc. may be described.
  • the medical personal information will be described as an example.
  • the personal medical record is set as the version setting range in the medical information DB. If one or more rows in the table are personal information, a version is set for this chunk.
  • the DB has a lot of personal information, and a version is set for each.
  • In the edit record there are one or more sets of “edit contents”, “edit version”, and “invariant confirmation range” for each individual.
  • the “invariant confirmation range” may be set appropriately according to the content and purpose of the correction, whether it is the entire personal record or the corrected information (record for RDB). If a table is configured for each personal information, a version is set for each table.
  • Version assignment timing A version is assigned to the entire DB original (global original DB or local original DB), or the “version setting range” in the DB original. And can be selected according to operational circumstances.
  • the version is updated when the original DB or the version setting range is changed in the change record determined to be valid.
  • the version is the same until it is updated with the next valid editing record, and the version of the local original DB synchronized during this period is the same.
  • updating the version is a method of “updating the version by all edit records regardless of validity or invalidity”.
  • the version is different between before and after invalid editing, and the version of the local original DB synchronized later is advanced even if the contents of the original DB are the same.
  • the server updates the global original DB
  • the time of the access from a PC is used as the version of the original DB, and if necessary, it is synchronized with the local original DB and the global original DB of the PC and simultaneously (That is, the latest access time) is also synchronized. Since editing to a local original DB with a newer synchronous access is given priority, it is a rule that can be easily understood and understood by those who operate one DB in competition.
  • the local original DB is synchronized with the entire (virtual or real) global original DB.
  • the medical information DB described above has a large amount of personal information.
  • the doctor's computer has a local original DB that holds information on the patient (several) patients, and the personal computer has a local original DB that holds only the personal information of the person.
  • Y is not invalidated by another editing record.
  • (X update cancellation condition 2) X updated the invariant confirmation range of Y.
  • (X update cancellation condition 3) “x ⁇ y”.
  • (X update cancellation condition 4) “y ⁇ nx”. Before the version update by X is transmitted, the local original DB to be edited by Y is updated (to y).
  • the timing of X being canceled is related to the timing of Y's up to the server. If the Y-up is before the X-up (nx), X is determined to be invalid when the “local original DB” is updated by X, and the cancellation is not canceled.
  • Update records for invalidating X are limited by (X update cancellation condition 1). In other words, an edit whose edit version is determined to be invalid is not a factor for canceling the previous edit.
  • (X update cancellation condition 2) indicates that the designation of the invariant confirmation range affects the possibility of update cancellation. By not increasing the invariant confirmation range carelessly, the possibility of canceling the update can be reduced.
  • X update cancellation conditions 3 and 4 are the X editing period, that is, “while the version of the local original DB to be edited X is updated (to x) and then X is uploaded to the server”. In this case, the version of “local original DB” is updated (to y), and this is the editing target of Y.
  • the possibility of canceling X can be reduced by speeding up editing (X) by X PC.
  • any PC can attempt to update the local original DB again.
  • the version becomes nx or later if the local original DB is updated to the end of the fetched edit record.
  • the prohibition is canceled after X arrives, the local original DB is updated using X, and the version is nx or later. Therefore, the version of the edit record for these is nx ⁇ y, and the “edit cancellation condition” does not occur.
  • the server updates the global original DB
  • the primary keys given by the PCs to the new record collide, the problem is solved by replacing them so that there is no duplication.
  • the PC synchronizes the copy DB at hand with the original DB, the new primary key information is transmitted.
  • Primary key duplication avoidance method 1 By previously assigning a range of primary keys that can be newly assigned to each PC from the server or management PC, it is possible to avoid collision of primary keys of new records. A method of preventing a collision by using a UUID as a primary key is also possible.
  • a record (K) for recording the next primary key is set in the DB. This K value is used as the primary key of the newly created record (Z), and then the K value is updated. If the update of K is enabled in accordance with the “prioritize editing for more recent information” rule, the addition of the record is complete, but if it is determined to be invalid, the update of the K value is disabled. The addition of record (Z) is also treated as invalid.
  • Claim 2 specifies the database version update process.
  • Claim 3 specifies the concept of the version setting range. Here, it is simply referred to as “specified range of information”, but various specification methods are assumed, such as when specified in advance by the system or when specified for editing records. It is not limited to the method.
  • Claim 4 corresponds to a method of using the time when the server accepts the edit record, or a method of using the synchronous access time to the server instead of the version. This does not limit the method of specifying the “specified time”.
  • the fifth aspect corresponds to an operation in which update is canceled, and steps D and E are inserted between steps B and C.
  • Claim 6 specifies the concept of “invariant confirmation range” in claim 1.
  • Claim 7 corresponds to the case where the global original DB is updated in the server.
  • a process F for transmitting information of the global original DB updated from the server to each PC is added. The time when the edit record arrives at the server is used as the database version.
  • claim 9 adds the synchronous access time to the server as the version of the local original DB.
  • the tenth aspect of the present invention adds the time of downloading the edit record from the server to the updated version of the local original DB.
  • claim 11 includes a step of notifying other computers of “stop of editing, stop of editing up, or stop of updating of local original DB”.
  • the criterion of “prioritizing editing based on the latest information” according to the present invention is an idea that “a judgment based on the latest information is more likely”, and is a criterion that is easily accepted by humans who handle data.
  • 0405 Compare nx and y [0406] Cancel the update of the local original DB by the extracted past edit version (X) 0407 Update local original DB with edit record (Y) to be processed 0408 Update local original DB version 0501 PC 0502 Communication networks such as the Internet 0503 server 0504 (PC) storage device 0505 (server) storage device 0506 Local original DB 0507 Global Original DB 0508 Editing record 0509 Work DB 0510 Local original DB update information 0511 Editing means 0512 Update method 0513 Transmission means 0515 Receiving means 0515 Transmission / reception management means 0516 Local original DB update information 0517 Update means 0518 Transmission method 0519 Receiving means 0520 Transmission / reception management means 0601 Edit record received 0602 Extract edit version (y) and invariant confirmation range from edit record (Y) to be processed 0603 Takes out past edit record (X) in which information of immutable confirmation range was changed [0604] The editing version (x) of the past editing record
  • editing is up. 1016 Confirmation (notification to PC-A) and synchronization (by PC-A).
  • the synchronization is new editing and acquisition of the order thereof, and the same applies to the description of other symbols.
  • 1017 Synchronization (by PC-B) 1018 Editing (by PC-B operator) 1019 Send edit (by PC-B).
  • editing is up. 1021 Confirmation (notification) (to PC-B) and synchronization (by PC-B).
  • FIG. 1 shows the configuration of a typical computer 0101.
  • An arithmetic device 0103, a main storage device 0104, a secondary storage device 0106, an input / output device 0107, and a display device 0108 are connected by a bus 0109.
  • the “database” mentioned in each claim is the DB 0111 in the secondary storage device 0106 or the DB 0105 in the main storage operation 0104.
  • the program is recorded in the secondary storage device 0106.
  • the program is activated, the program is expanded to the main storage operation 0104, and the arithmetic unit 0103 operates according to the procedure specified in the program.
  • the computer is reconfigured into a collection of means for realizing the operation intended by the program developer.
  • a DB operation by a program is performed after all or a part of the DB is expanded to the main memory operation 0104.
  • the DB 0105 in which all or part of the DB 0111 in the secondary storage device 0106 is expanded to the main memory operation 0104 is operated, and the editing result is written in the DB 0111 in the secondary storage device 0106.
  • the DB is in the secondary storage device 0106 and will be discussed without distinction from the DB 0105 expanded in the main storage operation 0104. Therefore, in FIGS. 2 and 5, the storage devices 0204, Display as the middle DB.
  • a PC 0201 is connected to a server via a communication network 0202 such as the Internet.
  • a communication network 0202 such as the Internet.
  • the PC 0201 has a storage device 0204, in which a local original DB 0206 is recorded.
  • the initial value of the local original DB 0206 is a copy of the global initial original DB 0207 of the storage device 0205 of the server 0203.
  • the editing unit 0213 performs editing in response to an instruction from the operator of the PC 0201. At this time, the local original DB 0206 is not directly edited, and the editing result is set as the work DB 0209. At the same time, edit record 0208 is created. In this edit record, an edit version, that is, a version set in the local original DB is recorded.
  • the edit record 0208 is sent to the server 0203 via the communication network 0202 by the transmission means 0215.
  • the server 0203 is received by the receiving means 0221 and added to the columns of the edit record 10218 and the edit record m0219. It is assumed that an edit version is recorded in the edit record. If an edit version is sent to the server separately from the edit record, the server records their correspondence.
  • the PC 0201 When the PC 0201 attempts to update the local original DB 0206, it first requests the server to transmit an unreceived edit record. When the PC 0201 notifies the last version of the edit record received so far, the transmission / reception management unit selects the subsequent edit record and sends it from the server by the transmission unit 0220.
  • the PC transmission / reception cooperative work is performed by the transmission / reception management unit 0217, and the server transmission / reception cooperative work is performed by the transmission / reception management unit 0222.
  • the edit records 0210, 2011, 0212 received by the receiving unit 0216 by the PC 0201 are recorded in the storage device 0204.
  • the update unit 0214 extracts them in order, determines the validity, updates the local original DB 0206, and updates the version.
  • the update procedure of the local original DB 0206 by the update unit 0214 of the PC 0201 in FIG. 2 is shown in FIGS.
  • the PC 0201 first receives “unreceived edit record” 0301 and then “enters the unprocessed edit record list” 0302. This is repeated for all unreceived editing records.
  • the list of unprocessed edit records corresponds to edit record n0210, edit record n + 1021, and edit record m0212 in FIG.
  • the procedure is as follows. It is assumed that the version setting range is specified in the edit record. “Specify edit version (x) of past edit record (X) taken out and edit version (y) of edit record (Y) to be processed” 0401 In process 0401, it is designated as the edit record (Y) to be processed For the version setting range that is present, “specify edit version (x) of past edit record (X) and edit version (y) of edit record (Y) to be processed”. And later versions are compared against this.
  • the server In the case of operation using the version when the server receives the edit record, the server records the reception time in the edit record. Then, in “update the version of the local original DB” 0408, the PC records the reception time recorded in the editing record used for the update as the updated version of the local original DB 0408.
  • the PC accesses the server, obtains the time from the server to confirm whether there is an unreceived edit record, and uses the time as the version of the original DB, “Receive unreceived edit record” 0301 Get the access time to the server before, during, or during "Entering the list of unprocessed edit records” 0302. Considering the time lag for each PC, it is desirable to receive this time from the server. Then, this time is recorded, and after updating the local original DB 0407 with the last editing record of the received editing record, the recorded time is recorded as a version of the local original DB 0408.
  • a PC 0501 is connected to a server 0503 via a communication network 0502 such as the Internet.
  • a communication network 0502 such as the Internet.
  • the PC 0501 has a storage device 0504, in which a local original DB 0506 is recorded.
  • the editing unit 0511 performs editing in response to an instruction from the operator of the PC 0501.
  • the local original DB 0506 is not directly edited, and the editing result is the work DB 0509.
  • edit record 0508 is created.
  • an edit version that is, a version set in the local original DB is recorded.
  • the edit record 0508 is sent to the server 0503 via the communication network 0502 by the transmission means 0513.
  • the server 0503 receives the reception unit 0519, determines the validity with the version recorded in the editing record, and updates the global original DB 0507.
  • local original DB update information 0516 is created.
  • the local original DB update information 0516 is sent to the PC 0501 by the transmission means 0518 of the server, received by the reception means 0514, and recorded in the storage device 0504.
  • the updating unit 0512 updates the local original DB 0506 using the local original DB update information 0510. Coordination work for PC transmission reception is performed by transmission / reception management means 0515, and server transmission reception cooperation work is performed by transmission / reception management means 0520.
  • FIG. 8 illustrates a procedure for transmitting “up prohibition” from the server to the PC for preventing update cancellation.
  • the server receives “edit record transmission request (with last last number) received” 0801 from the PC, the server determines whether it is “up prohibited” 0802. Based on a request from a certain PC, if the server is in the state of prohibiting up, “notify up prohibition” 0803 is sent to the PC that has requested transmission of the edit record. If the upload is not prohibited, “unsent, that is, create a list of edit records after the last final number” 0804, “send” 0805 to the PC, and finally send “completion notice” 0806.
  • FIG. 9 illustrates a procedure for transmitting “edit prohibited” from the server to the PC for preventing update cancellation.
  • the server When “Receiving edit record transmission request (with last last number)” 0901 from the PC, the server “creates a list of edit records that have not been sent (that is, after the last last number)” 0902 and sends these to the PC. Send “0903. After this, the server determines whether the editing is “prohibited editing (in the local original DB)” 0904. If updating is prohibited based on a request from a certain PC, “notify editing prohibited” 0905 is sent to the PC that has requested the editing record transmission, and finally “completion notification” 0906 is sent.
  • FIG. 10 shows another embodiment.
  • the DB in FIG. 10 is an RDB
  • the version setting range is the entire DB
  • the version is an integer
  • the invariant confirmation range is only the edited record
  • “operation without canceling update” is set.
  • the edit version at the time of editing this record is recorded as “record version” for each record.
  • “retrieve past edit record (X) whose invariant confirmation range information has been changed” is extracted. “Comparison of edit version (x) of past edit record (X) and edit version (y) of edit record (Y) to be processed” 0401 ⁇ ⁇ ⁇ can be performed.
  • the global initial original DB, the edit record, and the arrival order (up order) are recorded on the server.
  • the vertical axis of the server shows the most recent edit at that time.
  • the PC-A 1002 and the PC-B 1003 acquire the global initial original DB 1004 1010 and 1011 respectively, and make them the local original DBs 1005 and 1006 respectively. Since the global initial original DB 1004 of the server is copied, the base version of both is 0. Thereafter, edits 1 to 6 are uploaded to the server 1001, which is an edit uploaded by a PC other than the PC-A 1002 and PC-B 1003.
  • PC-A 1002 accesses the server once again, and obtains the latest editing order 1012 at that time. At this time, since edit 1 is captured, the version of the local original DB 1005 becomes 1.
  • the PC-B 1003 acquires from the server 1001 the edit 6 (latest as of this synchronous 1017) from the edit 1, and updates the local original DB 1006 to 6 as the base version. Thereafter, it is assumed that the operator of the PC-B 1003 has edited 1018 “duplicate record Z 1009”. At this time, the record version of “duplicate record Z 1009” becomes 6, and the edit record is uploaded to the server 1019 and recorded as edit 8.
  • the PC-A 1002 accesses the server 1001, and acquires the editing 8 and the editing 9 uploaded after the editing 7 (already acquired) 1022. Then, edit 8 and edit 9 are applied to the local original DB 1008 in order, “edit validity determination” is performed, and the local original DB 1008 is updated.
  • the edit 9 is reflected in the local original DB 1008, the base version of the manufactured DB 1008 becomes 9.
  • the content of the copy 1009 of the record Z edited by the PC-B 1003 becomes valid in the local original DB 1005 of the PC-A 1002, and the content of the copy 1008 of the record Z edited by the PC-A 1002 becomes invalid. It turns out (with PC-A1002).
  • the conflict resolution method of the present application is a mechanism that “priorizes editing based on the latest information”, and even in full-fledged “parallel DB editing” in which a computer permanently holds a replication DB, the computer temporarily stores the replication DB. It is also effective in cases where This method has a feature that “editing based on old information is determined to be invalid”.
  • This method has a feature that “editing based on old information is determined to be invalid”.
  • This method has a feature that “editing based on old information is determined to be invalid”.
  • “almost offline operation” in which editing is performed slowly after information synchronization and the editing records are sent together may be used.
  • the method of the present application enables parallel editing of databases in a wide range of application fields.

Landscapes

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

Abstract

データベースの変更編集の競合解消方法として「より最新の情報に基づく編集を優先」する仕組みを示す。この方法は、計算機が永続的に複製ＤＢを保持する本格的な「並行ＤＢ編集」においても、計算機が一時的に複製ＤＢを保持するケースにおいても有効である。この方法には「古い情報に基づく編集は無効と判定される」特徴がある。競合が予想される情報を編集する場合は「最新の情報との同期、編集、編集記録の送信」を迅速に行う「ほぼオンライン運用」により、この編集が無効となる可能性を小さくする事が出来る。逆に競合が予想されない情報を編集する場合は、情報の同期の後でゆっくり編集を行い、編集記録をまとめて送信する「ほぼオフライン運用」で良い。

Description

データベース並行編集の競合解消方式
本発明はデータベース（以下「ＤＢ」）の、複数の複製に対して、並行して編集（以下「並行ＤＢ編集」）が行われた場合に発生する、編集の競合を解決するものである。
一般的にはサーバー計算機（以下「サーバー」）にデータベースが置かれ、複数の端末計算機（以下「ＰＣ」）がアクセスする運用が行われている。アクセスの競合を防ぐため、ベシミステックロックカーソル（非特許文献１）やトランザクションのロック（非特許文献２）が用いられている。
MVCC（非特許文献３）も編集ロック（非特許文献４、非特許文献５）を用い、OODB製品のCache（非特許文献６）とObjectStore（非特許文献７）も編集ロックを用いている。リレーショナルＤＢ（RDB）のPostgreSQLでは「同時に起こりうる更新を避けるためには適切なLOCK TABLE 文を使用する」（非特許文献５）とあり、これも編集ロックである。特許文献１も編集ロックである。
作業用の複製を作成して処理を行うキャシュの技術で、処理や通信の効率化を図る試みも行われている。マイクロソフトのADO.NETは、ＰＣに当面の作業に必要なデータをサーバーからコピーし、サーバーとの接続を切断してから編集作業を行う。編集後に改めてサーバーと接続し編集内容をサーバーに送る。もし編集対象の情報が既に他のＰＣから変更されていれば、後からの（この）編集を無効にする。これは「オプティミスティック同時実行制御」（非特許文献８および非特許文献９）と呼ばれている。「ロックが結果として失敗した場合にはその編集を無効とする」と考えれば、編集ロックの一種とも言える。本願では、他の方法との比較のため、この方法を「先着優先」と呼ぶ。この「先着優先」では、時として以下に示す不都合が生じる事がある。
（１）最新情報を基にした編集が無効となるケースが存在する。最新情報を基にした編集はその時点での最善の判断の可能性が高いので、これが無効になると実際の運用においては問題となる。
例えば、ＰＣ－Ｘの操作者は朝９時に必要なデータをサーバーからコピーし、「この顧客は冷やかしなので、親切な対応は不要」と書き込みその後しばらく放置したとする。一方ＰＣ－Ｙの操作者は、お昼の１２時に「この顧客から高額な取引の提案有り」との情報を得て、「契約に向け、最大限の接待を行う」と書き込み、サーバーにアップしたとする。しかし、その１分前にＰＣ－Ｘからの編集がアップされると、ＰＣ－Ｙの編集のアップは後からなので無効となる。最新情報を元にしたＰＣ－Ｙの編集が、ＰＣ－Ｘの操作者の気まぐれな操作で妨害されている。
（２）編集毎にコピーを作成（非特許文献１のp19）するので、そのコピー作成の処理と通信がオーバーヘッドとなる。このオーバーヘッドを少なくするには、コピーの範囲を制限する必要があるが、これにはアプリケーションが対象とする情報の構造を熟知している必要がある。これはキャシュに基づく方法に共通する問題である。
特許文献２でも、指定した範囲のレコードが更新されていると後からの更新を無効としている。具体的には、引用発明の頁（６）の下部に「他の処理によって当該レコードを更新されている事が判明すると・・・更新は拒否され」とある。これは「先着優先」であり、ＡＤＯ.ＮＥＴと同じ問題を抱えている。
特許文献３では、複製ＤＢでの編集時刻を基に、競合する編集のバージョンを、「時刻の早い順からバージョンをふり直す（ステップＳ６０４）」（特許文献３の段落００６５、段落００７９）、そして「日時が最も古いコンテンツ情報を最新のバージョンに更新する」（段落００９７）としている。つまり、先に編集した方を優先としている。本願では、他の方法との比較のため、この方法を「先編集優先」　と呼ぶ。
「先編集優先」でも問題が生じる場合がある。例えば、ある時点（例えば１年前）の編集結果があるＰＣの中に存在しており、ある日突然サーバーにアップされて有効になると、他のＰＣによって過去１年間に編集されアップされていた編集内容が全て無効になってしまう。この様な運用は通常は許されないと思われる。なお、特許文献４も更新時刻が先の更新を有効としており、同じ問題を抱えている。
特許文献５では更新時刻が後の更新を有効としている。本願では、他の方法との比較のため、この方法を「無条件上書き」と呼ぶ。この文献ではＰＣでの修正がほぼリアルタイムに他のＰＣに伝わる運用を前提としているので、後からの編集はそれまでの編集状況を全て把握した上での修正と推定される。この条件ならば「無条件上書き」でも問題は無いと思われる。
しかし本願の様に、複数のＰＣが並行して、それぞれが保持する複製ＤＢの内容を変更するケースでは、他のＰＣでの編集状況が即時には伝わらない。この状況、単に更新時刻が後であれば常に上書きする「無条件上書き」を適用するならば、ＰＣの操作者には直接は理解出来ない理由で編集の有効性が決定される事になる。編集の時刻を決定するＰＣ毎の時計がずれる事も、意図的にずらされる可能性も考える必要がある。「無条件上書き」を並行編集に適用するには、検討を要する多くの問題がある。
その他の調査結果を以下に示す。特許文献６はデータベースの同期を起動する条件に関する発明であり、同期の方法については「更新情報を互いに通知し合って同期」と言う一般的な同期の概念を示しているにすぎない。平行して作成された更新（本願では「編集記録」）を互いに通知するだけでは、様々な理由（エラー再送などによる遅れ、送信タイミングのずれ等）により、ＤＢに適用する順番がＰＣ毎に異なる可能性があり、それぞれの複製ＤＢの内容が異なるという重大な問題が予想される。しかし、これについての対策は示されていない。
特許文献７は、編集の競合が起きた際に「全ての更新データを保持する」ことを目的とした発明である。競合が無いときにのみ原本を更新するのであり、本発明とは目的も内容も異なる。
非特許文献１０は、ファイルのキャシュに関する発明で、編集の衝突（本願での競合）を検出した場合は単純に編集を拒否する（非特許文献１０の７頁の右下から１０行目）のみであり、本願の様に衝突した編集のうちどれを有効にするかの判定は行わない。
特許文献８、特許文献９、特許文献１０、特特許文献１１、特許文献１２についても調査したが、いずれも本願の目的である、並行ＤＢ編集による矛盾の解決には適用出来ない。
特開平１１－２７２５３４号公報 特開昭６１－１３４８５３号公報 特開２００５－２１６１６７号公報 特開平９－９１１８４号広報 特開２００４－１３８６７号広報 特開２００４－８６８００号広報 特開２００６－２８４９９８号広報 特開平１１－１６１５３５号公報 特表２００５－５０３６０６号公報 特表２００５－５０８０５０号公報 特開平８－１６４４７号公報 特表２０００－５０１５３２号公報 William R. Vaughn, 株トップスタジオ訳、伊藤由紀子監修、Windows（登録商標）データベースプログラミング ADO.NET専修講座 VB.NET 編、2003年８月４日初版発行、翔泳社 超図解ＳＱＬハンドブック、Ｃ＆Ｒ研究所、２００５年８月１２日初版発行 「主な機能とメリット」、[online]、2007年4月22日検索、インターネット（URL:http://www.sonicsoftware.co.jp/products/object_store/function.html） 「MVCC（多版型同時実行制御）9.1. はじめに」、[online]、2007年4月22日検索、インターネット（URL:http://www.postgresql.jp/document/pg721doc/user/ mvcc.html　#MVC　C-INTRO） 「9.5. アプリケーションレベルでのデータの一貫性チェック」、[online]、2007年4月22日検索、インターネット（http://www.postgresql.jp/document/pg721doc/user/applevel-consistency.html） 「Cache Technology Guide」、[online]、2007年4月22日検索、インターネット（URL: http://www.intersystems.co.jp/cache/technologyguide/technologyguide.html） 「主な機能とメリット」、[online]、2007年4月22日検索、インターネット（URL:http://www.sonicsoftware.co.jp/products/object_store/function.html） 「ADO.NET におけるデータ同時実行制御の概要」、2007年１月、MSDNサブスクリプションライブラリー（msdn subscriptions Library）、ディスクファイル（URL:ms-help://MS.MSDNQTR.v80.ja/MS.MSDN.v80/MS.VisualStudio.v80.ja/dv_raddata/html/d5293098-4a88-4110-abd2-34d9e6661664.htm） 「チュートリアル : 同時実行例外の処理」、2007年１月、MSDNサブスクリプションライブラリー（msdn subscriptions Library）、ディスクファイル（URL: ms-help://MS.MSDNQTR.v80.ja/MS.MSDN.v80/MS.VisualStudio.v80.ja/dv_raddata/html/73ee9759-0a90-48a9-bf7b-9d6fc17bff93.htm） 「世界規模分散ファイルシステムSKINNY 」、情報処理学会研究報告, 95-OS-70, (学術刊行物　情処研報 Vol. 95, No.79 ISSN 0919-6072
本願の目的は、ＤＢ複製が複数のＰＣに有り、これらに対して並行して並行ＤＢ編集が行われた場合に発生する、「編集の競合」を解決する事にある。キャシュ技術の延長である「先着優先」、「先編集優先」、「無条件上書き方式」を検討したが、これらには様々な問題があった。各ＰＣが保持する複製ＤＢは、キャシュとしての一時的な複製として位置付けられ、多少の問題は無視する割り切りと推定される。本願では、各ＰＣが永続的に複製ＤＢを保持する、いわば本格的な「並行ＤＢ編集」を提案するとともに、これに適した、編集の競合の解決方法を明らかにする。また、キャシュ技術への適用も検討する。
本発明では、並行ＤＢ編集における編集の衝突を「より最新の情報に基づく編集を優先」する方針で解決する。そして本格的な並行ＤＢ編集に用いたケースや、キャシュ技術への適用を説明する。以下では一つの適用例に基づいて説明する。
（１）準備
複数のＰＣに、原本ＤＢ（以下「グローバル原本ＤＢ」）の初期状態の複製ＤＢ（以下「ローカル原本ＤＢ」）を置く。このローカル原本ＤＢには初期のバージョン、つまり更新の順番を識別する順序数、が設定されている。
この順序数の簡単な実現例は整数で、初期値として「０」を設定するのが自然である。本願ではこのバージョンを用いて衝突の解決が行う。各ＰＣはそれぞれの（多分操作者の）都合の良い時に複製ＤＢの更新を行い、バージョンを更新する。この詳細を以下で説明する。
（２）ローカル編集
各ＰＣはそれが保持するローカル原本ＤＢに対するローカルな編集を行う。この編集の前にローカル原本ＤＢの作業用の複製を作成し、編集はこの複製に対して行う。また、編集時にはその「編集記録」を作成する。この編集記録には「編集内容」「編集バージョン」「不変確認範囲」などが記録される。
「編集内容」はどの情報をどの様に変更したか、どの情報を追加したか、どの情報を削除したか、などの一般的な編集内容である。「編集バージョン」は編集対象のローカル原本ＤＢのバージョン、厳密に言えば、編集対象の作業ＤＢの複製元となったローカル原本ＤＢのバージョン、である。
「不変確認範囲」はこの編集が前提とする情報の範囲である。もしこの編集が確定する前にこの範囲の情報の変更されてしまえば、この編集は無意味になる事を示している。「不変確認範囲」はＤＢが扱う情報、特にその編集する対象の情報の特性に応じて様々な指定が可能である。一般的な運用では、編集対象の情報は「不変確認範囲」にはいると思われるが、必ず入れる必要は無い。リレーショナルＤＢ（以下「ＲＤＢ」）の場合には、編集対象のテーブル、編集対象と論理的に関連しているテーブル群、そのなかの一部のレコード、またはＤＢ全体などが考えられる。
情報の性質に応じて適切な不変確認範囲が設定する事により、ＤＢの使い勝手が良くなる。「不変確認範囲」が小さければ多くの並行編集が問題なく行えるので、必要不可欠な最小限の情報（の組み合わせ）を不変範囲として設定するのが良い。
（３）サーバーへの編集記録の送信
各ＰＣは「編集記録」をサーバーに送信する。「編集記録」と「編集バージョン」および「不変確認範囲」を分けて記録している場合には、「編集記録」との対応を明示して「編集バージョン」および「不変確認範囲」も送信する。なお、「編集記録」の中に「編集バージョン」と「不変確認範囲」も、さらには後で説明する「バージョン設定範囲」も、記録しておくと、通信手順が簡単になる。
（４）サーバーによる編集記録の受信
サーバーは、ＰＣから到着した編集記録を、その到着の順番と共に記録しておく。
（５）サーバーからの編集記録の受信
ＰＣはサーバーに対して、未受信の編集記録の送信を要求し、これらの編集記録、と対応する編集バージョン、必要なら不変確認範囲やバージョン設定範囲を受信する。同時に編集記録のサーバーへの到着の順番を受信する。サーバーがＰＣから到着した編集記録にその到着の順番を記録すると、通信手順が簡単になる。
（６）ローカル原本ＤＢの更新
ＰＣは指定された順番でサーバーから受信した編集記録を取り出し、編集記録の有効性を判定する。この判定手順の詳細は後の「有効性の判定手順」で説明する。そしてローカル原本ＤＢを更新してそのバージョンを更新する。バージョンが整数なら初期値の「０」から順番に１個ずつ上げていくのが自然である。なお、ＰＣは指定された編集記録を全て最後まで処理する（途中で新たな編集作業は入れない）。従って、サーバーから受信した最後の編集記録まで一気にローカル原本ＤＢを更新しその後での後で（処理した編集記録の数だけ）バージョンを更新しても良い。
＜　バージョンと言う時間での同期　＞
全てのＰＣは、各ＰＣにおけるローカルな編集の編集記録を、サーバーへの到着順で取り出し、ローカル原本ＤＢを更新しそのバージョンを更新する。同じ情報を同じ順番で用いて、同じロジックで処理するので、結果として得られる各ＰＣのローカル原本ＤＢとそのバージョンは同期する。グローバル原本ＤＢを更新しなくても、グローバル原本ＤＢが存在しなくても、各ＰＣのローカル原本ＤＢが同期するのはこの仕掛けによる。
各ＰＣはそれぞれの都合の良い時に、それぞれのローカル原本ＤＢの更新を行うので、実時間で見ると、各ＰＣのローカル原本ＤＢのバージョンの進み方は様々である。しかし、バージョンが更新される順番は同じであり、同じバージョンならローカル原本ＤＢの内容は同じである。つまり、バージョンが、並行ＤＢアクセスにおける各ＰＣに共通の時間に相当する。つまり本発明ではバージョンと言う時間で各ＰＣのローカル原本ＤＢが同期する。
ＤＢ全体に対してひとつのバージョンを設定する場合の説明は以上であるが、後で説明する、情報のグループを「バージョン設定範囲」として設定する場合は、その範囲の情報が更新（追加、変更、削除）された時に、その範囲のバージョンを更新し、それぞれの範囲に対してバージョンを記録する。
＜　有効性の判定手順　＞
「編集記録の有効性の判定」が本発明の重要な部分である。編集記録（Ｙ）により「ローカル原本ＤＢ」の更新を試みる場合には、まず、Ｙに指定された「不変確認範囲」の情報を更新した過去の編集記録を調査し、これらの全てに対してＹが有効と判定された時に、Ｙを有効と判定する。ここで説明のため、Ｙに指定された「不変確認範囲」の情報を更新した過去の編集記録のひとつをＸとし、以下の記号を用いる。
ｙ：Ｙの編集バージョン＝Ｙの編集対象であった「ローカル原本ＤＢ」のバージョン。
ｘ：Ｘの編集バージョン＝Ｘの編集対象であった「ローカル原本ＤＢ」のバージョン。
ｎｘ：Ｘに基づく更新により設定された原本のバージョン。当然「ｘ＜ｎｘ」。
ＹがＸに対して無効である条件は、以下二つのどれかを満たした場合である。なお、少なくとも一つのＸに対して無効であれば、Ｙは無効と判定され、Ｙによるローカル原本ＤＢの更新は実行されない。
（Ｙが無効となる条件１）ＸがＹの「不変確認範囲」の情報を更新しており、かつ「ｙ＜ｘ」。つまり、Ｙの編集バージョンがＸより古いので、Ｙを無効と判定する。
（Ｙが無効となる条件２）ＸがＹの「不変確認範囲」の情報を更新しており、かつ「ｙ＝ｘ」。つまり、編集バージョンが一致した場合は、先着のＸを有効としＹを無効と判定する。
従来の「先着優先」や「先編集優先」の方法では、古い情報に基づく編集が最新の情報に基づく編集よりも優先される問題があったが、本発明では以上の２条件でこれらの問題を排除している。
逆に、ＹがＸに対して有効である条件は以下２つのどれかを満たした場合である。なお、全てのＸに対して有効な場合にＹが有効となり、Ｙによるローカル原本ＤＢの更新は実行される。
（Ｙが有効となる条件１）ＸがＹの「不変確認範囲」の情報を更新していない場合は、この条件だけでＹはＸに対して有効。
（Ｙが有効となる条件２）ＸがＹの「不変確認範囲」の情報を更新しており、かつ「ｘ＜ｙ」の場合、ＹはＸに対して有効となる。
全てのＸに対して有効な場合にＹが有効となり、Ｙによりローカル原本ＤＢを更新する。編集バージョンが新しい編集を優先する原則を厳密に適用する場合には、ｙとｎｘの関係によりその更新手順が分かれる。
「（ｘ＜）ｎｘ＜=ｙ」の場合：Ｙの編集対象のローカル原本ＤＢにはＸの変更が含まれている。従って、Ｘによる更新を生かしたままＹによる更新を実行する。
「（ｘ＜）ｙ＜ｎｘ」の場合：Ｘの変更が含まれていないローカル原本ＤＢに対してＹが行われでいる。従って「より最新の情報に基づく編集を優先」する思想を厳密に適用するならば、Ｘによる更新を取り消した後にＹによる更新を実行する。なお、「（ｘ＜）ｙ＜ｎｘ」の条件を、Ｘの「編集の取り消し条件」と呼ぶ。
実は、上記の（Ｙが有効となる条件２）でＹが有効となった場合に、上記「（ｘ＜）ｙ＜ｎｘ」の条件の確認を行わず、直ちに、Ｘによる更新を生かしたままＹによる上書き更新を実行する方法が実用的である。当然、「編集バージョンが新しい編集を優先する」原則に外れる場合が生じる可能性があるが、一度適用された更新が取り消される事は無いのは運用上都合が良い。有効性の判定手順が単純明快で並行ＤＢアクセスの関係者にとってデータベースの動作に対する理解が容易であるし、システムの開発も容易になる。なお「更新の取り消しが有る運用」の詳細については後で説明する。
＜一般的な動作の流れ＞
あるＰＣに注目した一連の動作例を以下で説明する。このＰＣがサーバーから最新の編集記録を受信し、ローカル原本ＤＢを更新したとする。その後、他のＰＣから編集記録がサーバーにアップされた後に、このＰＣがローカル原本ＤＢに対する編集を行ったとする。これを編集記録Ｙとしてサーバーにアップし、次にそれまでの（未受信の）編集記録をサーバーから受信し、編集記録を指定された順番で取り出し、ローカル原本ＤＢの更新を試みる。この過程でいくつかの編集（例えば編集Ｘ）は有効と判定されローカル原本ＤＢが更新される。
最後に先程アップした編集記録Ｙが取り出され、その不変確認範囲を調査し、編集Ｘなどとの関係を「有効性の判定手順」で評価する。一つのＸに介して無効ならＹは無効と判定される。このＰＣの操作者は、無効となった事実とその理由を確認し、必要が有れば（最新の情報に対して）再度の編集を試みる。無効になった元の入力の記録があれば、その内容を再び入力するのは容易である。有効なら編集記録Ｙでローカル原本ＤＢを更新する。
＜ほぼオンライン運用とほぼオフライン運用＞
ＰＣの操作者は「古い情報に基づく編集は無効と判定される可能性が高い」事を理解していれば良い。編集を行うＰＣが、その編集が無効と判定される可能性を出来るだけ少なくするには、編集の直前に最新の編集記録まで受信してローカル原本ＤＢを更新し、この最新のローカル原本ＤＢに対して編集を行い、編集後は速やかに編集記録をアップすると良い。頻繁に更新を行えば、ローカル原本ＤＢは常に最新の状態に保たれるので、「ほぼオンライン運用」と言う事が出来る。
しかし、編集の競合が稀な情報を扱う場合には、ローカル原本ＤＢの更新から編集のアップまでの時間を長くしても編集が無効となる可能性は小さい。例えば、会社の組織ごとに支払伝票を入力するケースでは、レコードを修正するのは入力ミスや処理ミスを発見した場合であり、修正するとしてもレコードを入力した計算機で行う事が多い。この様なケースでは、更新から編集アップまでの期間を極端に長くした「ほぼオフライン運用」でも問題は無い。たとえインターネット接続が出来ない状況でも支払伝票をゆっくり入力し、決算や検査の近くなってからまとめてアップすれば良い。
＜＜　課題を解決するための手段の全容　＞＞
発明の全容を実施例のバリエーションも含めて以下で説明する。
（１）編集記録とその順番の操作
サーバーがＰＣに伝える編集記録とその順番は、必ずしもＰＣがアップした内容である必要も、アップの順番を守る必要も無い。編集記録とその順番が全てのＰＣで同じであれば、これらのローカル原本ＤＢは同期する。
サーバー又は管理業務を担当するＰＣが編集記録の内容を分析し、エラーとなって無効とされる部分や、冗長（結局は何もしないのと同じ）な部分を削除しても良い。エラーの編集記録や冗長な編集記録を削除して、編集記録の順番を詰めても問題は無い。操作者の優先順位などを考慮して意図的に編集記録の順番を変更したとしても、ローカル原本ＤＢは同期する。
（２）サーバーによるグローバル原本ＤＢの更新
先の例では、サーバーから受け取った一連の編集を用いて「ローカル原本ＤＢ」を更新している。「ローカル原本ＤＢ」の初期値が同じ、それに適用する編集記録の順番とその内容が同じ、かつ同じロジックで「ローカル原本ＤＢ」の更新を行う事により、同じ編集記録まで受信したＰＣの「ローカル原本ＤＢ」の内容は一致する。「グローバル原本ＤＢ」は存在しないが、各ＰＣの「ローカル原本ＤＢ」は同期している。仮想のグローバル原本ＤＢと同期していると言える。
グローバル原本ＤＢを実際にサーバーに置き、サーバーがこのグローバル原本ＤＢを更新する運用も可能である。その要点は以下である。
（a）グローバル原本ＤＢがサーバーに有り、各ＰＣはその複製であるローカル原本ＤＢを持っている。
（b）各ＰＣはそのローカル原本ＤＢに対して編集を行う際には、編集記録を作成しサーバーに送る。
（c）サーバーは、ＰＣからの編集記録の到着順に、編集の競合を確認し、有効と判定された編集でグローバル原本ＤＢを更新し、そのバージョンを更新する。
（d）サーバーからの情報で、各ＰＣはそれぞれのローカル原本ＤＢとバージョンを更新、つまり同期、する。
原本ＤＢをサーバーに置くと処理の説明は簡単だが、実際の処理は逆に複雑になる。ひとつは、処理過程をＰＣに通知するのが困難、つまり、どの編集が無効と判定され、それがどの様にして無効と判定されたかを、その編集を行ったＰＣの操作者に伝えるのが困難な事である。先の「ローカル原本ＤＢ」を各ＰＣが更新する方法ならば、各ＰＣの内部で全ての編集の有効または無効の状況が把握出来るが、サーバーが原本ＤＢを更新する場合は、その状況を詳しく各ＰＣに伝えるには複雑な処理が必要である。
サーバーがグローバル原本ＤＢを更新する運用なら「サーバーの処理プログラムの更新で更新処理のアップグレード出来る」長所があるが、以上の処理の複雑さとのバランスを考え、扱うデータの特性や利用者の便宜などを考え、適切な運用を選択する事になる。
（２．１）ＰＣへの通知
グローバル原本ＤＢを更新する場合は、最新のグローバル原本ＤＢと各ローカル原本ＤＢを同期する必要がある。グローバル原本ＤＢのデータ量が多いと考えるのが常識的であり、その全体を送るのは非現実的である。編集記録（とその順番）を各ＰＣに送れば、各ＰＣでローカル原本ＤＢを更新するのと同じであり、グローバル原本ＤＢをサーバーが更新するメリットは小さい。結局、グローバル原本ＤＢ更新の差分情報を送るのが現実的である。
（２．２）キャシュへの適用
キャシュ技術を用いて「各ＰＣにおける編集の前に、サーバーからグローバル原本ＤＢの必要な部分のコピーを作成し、このコピーに対して編集を行う」方法に対しても、本願の「より最新の情報に基づく編集を優先」する方法が適用出来る。編集に必要なコピーを作成するときに、グローバル原本ＤＢのバージョンも取得する。編集記録にはこのバージョンを編集バージョンとして設定しサーバーに送る。サーバーはこの編集バージョンを元に有効性を判定する。これにより、ＡＤＯ．ＮＥＴで見られたような、古いバージョンに対する編集の突然のアップによって最新のバージョンに対する編集が妨害されるケースは排除される。
（３）サーバー機能の配置
先に説明した、各ＰＣが「ローカル原本ＤＢ」を更新する方法では、編集記録をサーバーに集めた。サーバーがグローバル原本ＤＢを更新する方法も説明した。どちらのサーバーも必要な機能が提供できるなら専用サーバーでもレンタルサーバーでも良い。本明細書でのＰＣのひとつが、同時に本明細書のサーバーの機能を提供しても何ら問題は無い。
（４）バージョン設定範囲の導入
バージョンを付与し編集を管理する単位が実際のＤＢである必要は無い。情報修正の影響が密接に関係している部分を「バージョン設定範囲」とし、これ毎にバージョンを設定すれば、その範囲に関する編集とバージョンの推移が管理できる。
最適なバージョン設定範囲の設定は、扱う情報の構造や内容に依存する。ＲＤＢの場合にはレコード、テーブル、テーブルと論理的に関連しているテーブル群、そのなかの特定のレコード群、又はＤＢ全体などが想定される。
以上で説明した手順は、ＤＢをバージョン設定範囲と読み替える事により、適用出来る。なお、複数のバージョン設定範囲に対する編集がひとつの編集記録に記載されていても問題は無い。バージョン設定範囲毎に「編集内容」「編集バージョン」「不変確認範囲」などが記載されていれば良い。
医療の個人情報を例に説明する。医療情報のＤＢで、個人の医療記録をバージョン設定範囲として設定する。テーブルの１行又は数行が個人の情報なら、これの固まりに対してバージョンを設定する。ＤＢには、多数の個人情報があり、それぞれにバージョンが設定される。編集記録には、個人毎の「編集内容」「編集バージョン」「不変確認範囲」のセットが単数または複数存在する。「不変確認範囲」はこの個人記録全体でも、修正した情報（ＲＤＢならレコード）でも、修正内容と目的に応じて適切に設定すれば良い。個人情報毎にテーブルを構成していれば、テーブル毎にバージョンが設定される。
医療情報だけでなく、社会保証や銀行口座やローンなどの情報を個人毎に管理する事にも利用出来る。複数の部署で編集すると思われる犯罪者情報の管理にも使える。さらには、住民みずから一部のデータの編集が可能な「発展した形態の住民基本台帳の管理」など、個人対応の情報を扱う場合にも便利である。「（５）ローカル原本ＤＢの複製範囲」で説明する様に、ＰＣ毎にその権限で読み込める範囲の個人情報についてのローカル原本ＤＢを作成する事として、権限の範囲内の情報のみがこのＰＣに送られるなら、権限外の情報がハッキングされる恐れも無い。
（４．１）　バージョン付与のタイミング
ＤＢ原本（グローバル原本ＤＢ又はローカル原本ＤＢ）全体、またはその中の「バージョン設定範囲」に対してバージョンが付与されるが、その付与方法は、扱う情報の特性や運用の都合に応じて選択する事が出来る。
「有効とされた編集でバージョンを更新」する方法は、有効と判定された変更記録で、原本ＤＢまたはバージョン設定範囲が変更された時に、バージョンを更新する。次に有効な編集記録で更新されるまでは同じバージョンであり、この期間に同期されたローカル原本ＤＢのバージョンは同じである。
有効な変更記録で原本ＤＢの内容が変更されなくても、バージョンを更新するのが「有効または無効に関わらず全ての編集記録でバージョンを更新」する方法である。無効な編集のアップの前後でバージョンが異なり、原本ＤＢの内容が同じでも後から同期されたローカル原本ＤＢのバージョンの方が進んでいる。
（４．２）　編集のサーバー受け付け時刻への発展
サーバーが編集記録を受け付けた時刻をバージョンとして利用する方法も可能である。以上で説明したバージョンはこの受け付け時刻と読み替える事になる。バージョンは一連の順番を識別するための順序数と説明したが、時刻も順序を表すので何ら問題は無い。
（４．３）　サーバーへの同期アクセス時刻への発展
ＰＣが、サーバーにアクセスし、未受信の編集記録の有無を確認した時刻をサーバーから取得し、その時刻を原本ＤＢのバージョンとする方法も可能である。ローカル原本ＤＢを更新する場合では、各ＰＣは（未受信の編集の有無、およびその有効性に関係なく）サーバーに問い合わせた時刻（例えばサーバーが通知した時刻）をローカル原本ＤＢのバージョンとする。
サーバーがグローバル原本ＤＢを更新する場合は、あるＰＣからアクセスが有った時にその時刻を原本ＤＢのバージョンとし、（必要ならば）そのＰＣのローカル原本ＤＢとグローバル原本ＤＢと同期し、同時にバージョン（つまり直近のアクセス時刻）も同期する。同期アクセスがより新しいローカル原本ＤＢに対する編集が優先されるので、一つのＤＢを競争で操作する関係者にとって理解しやすくまた納得出来るルールである。
（５）ローカル原本ＤＢの複製範囲
本願の説明を簡単にするには、ローカル原本ＤＢが（仮想の又は実在する）グローバル原本ＤＢの全体と同期すると都合が良い。しかし実際の利用を考えると、ローカル原本ＤＢはグローバル原本ＤＢ一部と同期する方が現実的である。例えば、先に説明した医療情報のＤＢは多数の個人情報を持っている。このうち、ＰＣ毎にその権限で読み込める範囲の個人情報についてのローカル原本ＤＢを作成すれば十分であり、ローカル原本ＤＢがグローバル原本ＤＢ全体と同期する必要は無い。医者の計算機には担当の（複数の）患者の情報を保持するローカル原本ＤＢが存在し、個人の計算機にはその人の個人情報のみを保持するローカル原本ＤＢが存在する。
ローカル原本ＤＢがグローバル原本ＤＢの一部のみと同期している場合は、特定のＰＣにとってはサーバーに集められた編集記録の多くは必要無い。ＰＣで全ての編集記録を受信した後で、不要な編集記録をスキップするのがひとつの方法である。サーバー側でＰＣ毎に必要な編集記録を抜いて送ると通信量が削減されるし、権限外の情報へのハッキングも防げる。たとえ、不必要な編集記録が残っていてもＰＣ側の処理で除外すれば良い。編集情報に記録されたバージョン設定範囲を元にして、サーバーの管理する編集記録を分類しておくとＰＣに送るべき編集記録を迅速に判定する事が出来る。
（６）　更新の取り消しが有る運用
先の説明では「更新の取り消しが無い運用」を扱っていたが、編集バージョンが新しい編集を優先する原則を厳密に適用すると、（Yが有効となる条件２）において、Yによる「ローカル原本ＤＢ」の更新の前に、Xによる更新を取り消す場合が有る。これは「（x＜）y＜nx」の「編集の取り消し条件」が成立した場合である。
（６．１）更新の取り消しの分析その１
Yにより、過去の更新（上記X）が取り消されるのは、少なくとも以下の全ての条件を満たす必要が有る。なお、以下の（Xの更新の取り消し条件３と４）は上記の「編集の取り消し条件」に相当する。
（Xの更新の取り消し条件１）別の編集記録によっても、Yは無効とならない。
（Xの更新の取り消し条件２）Yの不変確認範囲をXが更新していた。
（Xの更新の取り消し条件３）「x＜y」。Yの編集バージョンがXの後。なお、これが成立しない場合はＹが無効であり、Ｘの取り消し要因とはならない。
（Xの更新の取り消し条件４）「y＜nx」。Xによるバージョンの更新が伝わる前に、Yの編集対象のローカル原本ＤＢの（yへの）更新が行われた。
Xが取り消されるのは、この条件に加えてさらにYのサーバーへのアップのタイミングが関係する。もしYのアップがXのアップ（nx）よりも前なら、Xによる「ローカル原本ＤＢ」の更新の際に、Xは無効と判定され、取り消しには至らない。
（Xの更新の取り消し条件１）により、Xを無効にする更新記録は限定される。つまり、編集バージョンが古く無効と判定された編集は、それまでの編集を取り消す要因にはならない。
（Xの更新の取り消し条件２）は、不変確認範囲の指定が更新の取り消しの可能性を左右する事を示している。不変確認範囲を不用意に大きくしない事により、更新取り消しの可能性を小さくする事が出来る。
（Xの更新の取り消し条件３と４）は、Xの編集期間、つまり「Xの編集対象のローカル原本ＤＢのバージョンが（xに）更新されてから、Xがサーバーにアップされる間」に、「ローカル原本ＤＢ」のバージョンが（yに）更新され、これがYの編集対象となったケースである。XのＰＣによる編集（X）のアップを迅速に行う事により、Ｘの取り消しの可能性を小さくできる。
（６．２）　更新の取り消し防止方法
データベースの構造を変更するなど、更新の取り消しを防止したいケースがある。
（更新の取り消し防止方法その１：アップ禁止）
Ｘの編集期間に他のＰＣからの編集がアップされなければ、この期間に他のＰＣがそのローカル原本ＤＢを更新（Ｙ）してもバージョンはｘになるだけで、ｘより後になる事は無い。つまり（Xの更新の取り消し条件３）が成立しない。Ｘのアップ（ｎｘ）の後のローカル原本ＤＢの更新（Ｙ）なら、（Xの更新の取り消し条件４）が成立しない。つまり、Ｘの編集期間に他のＰＣからアップを禁止すれば、Ｘが取り消しは防止出来る。
（更新の取り消し防止方法その２：更新禁止）
Ｘの編集期間に他のＰＣからの編集がアップされても、他のＰＣがローカル原本ＤＢを更新するのを禁止すれば、Ｘの取り消しは防止出来る。サーバーから編集記録を送らないのもひとつの方法であり、編集記録を送ったとしてもその編集記録によるローカル原本ＤＢの更新（Ｙ）を禁止する方法でも良い。
Ｘのアップ後は再び、どのＰＣもローカル原本ＤＢの更新試みる事が出来る。この時、サーバーから取り込まれる編集記録にはＸが含まれるので、取り込んだ編集記録の最後まで用いてローカル原本ＤＢを更新すれば、そのバージョンはｎｘ以降となる。ローカル原本ＤＢの更新が禁止れさていたＰＣでは、Ｘ到着後にこの禁止が解除され、Ｘまで用いてローカル原本ＤＢを更新しバージョンはｎｘ以降となる。従って、これらに対する編集記録のバージョンは nx＜yとなり、「編集の取り消し条件」は発生しない。
「サーバーへの同期アクセス時刻」をバージョンとして用いる方法の場合は、ＰＣからの要求に対して、サーバーから「アクセスロック中」を返して、アクセス時刻の通知を行わない事で、同じ効果が得られる。
（更新の取り消し防止方法その３：編集禁止）
Ｘの編集期間に他のＰＣからの編集がアップされ、他のＰＣがローカル原本ＤＢを更新しても、この更新したローカル原本ＤＢに対する編集を禁止すれば、Ｘの取り消しは防止出来る。サーバーから編集記録を送った時などに、その編集記録により更新したローカル原本ＤＢに対する編集の禁止を通知する。
（６．３）更新の取り消しの分析その２
ある編集記録（上記のＸ）による更新が取り消しになった場合、この取り消しを完璧に行うには、以下の処理が必要になる。
（取り消から派生する処理１）Ｘにより無効とされた編集記録の有無を調査し、あれば有効か無効化の再評価を行う。
（取り消から派生する処理２）操作者がＸにより無効とされた編集記録を参照し再度入力した情報があるなら、その入力を見直す。
（取り消から派生する処理３）Ｘによる更新を前提とした編集、つまりＸによる更新で設定されたバージョン以降を編集バージョンとする編集記録の有効性を再評価する。
上記（処理１）と（処理３）の一部を自動的に実行する事は可能である。しかし、（処理２）など、操作者の協力が必要な部分が有るので完全な自動実行は困難である。Ｘの取り消しの後、上記（処理１）（処理２）（処理３）の派生処理は実行せず、Ｘの取り消し事実を正確に操作者に伝え、その後は操作者の判断により再入力にゆだねるのが現実的である。無効になった事実、その対象と理由が明確に伝われば、操作者は合理的に対応する事が出来る。
取り消しの派生処理を行わない事により、Ｘを無効とした判定が再度覆る事は無い。従って、これに対応して、操作者は再入力などの適切な操作を行う事が出来る。
（７）　情報の追加と削除
情報が新規に作成されたときも、編集記録を作成し、その時点の対象ＤＢのバージョンを編集バージョンとして記録する。ＤＢの情報の削除においても「削除対象、削除の事実、影響範囲、バージョン」を編集記録とする。この編集（削除）は無効になる可能性があるので、この段階ではローカル原本ＤＢから実際に削除する事は出来ない。有効と判定された後ならば実際に削除する事も可能である。
（７．１）　情報追加に関する補足
ＲＤＢにおいてレコードに主キー（ＩＤ）を設定するには、他のレコードとキーが重複してはならない。並行ＤＢアクセスではこのための配慮必要である。つまり、複数のＰＣが並行してレコードを追加する事により、同じ主キーのレコードが存在する事態を引き起こしてはならない。
サーバーがグローバル原本ＤＢを更新する場合なら、各ＰＣが新規レコードに与えた主キーが衝突した場合は、重複が無い様に付け替えることで問題は解決する。ＰＣが手元の複製ＤＢを原本ＤＢと同期する事により、新しい主キーの情報が伝わる。
グローバル原本ＤＢを置かず、各ＰＣがローカル原本ＤＢを更新する場合には、主キーの衝突を回避する方法がいくつか存在する。
（主キー重複回避方法１）
あらかじめ、サーバーや管理ＰＣから各ＰＣに、新規に割り当て可能な主キーの範囲を有り当てておく事により、新規レコードの主キーの衝突を回避する事が出来る。主キーをＵＵＩＤにして、衝突を防止する方法も可能である。
（主キー重複回避方法２）
次の主キーを記録しておくレコード（Ｋ）をＤＢ内に設定する。新規に作成するレコード（Ｚ）の主キーにこのＫの値を用い、その後Ｋの値を更新する。Ｋの更新が「より最新の情報を対象にした編集を優先する」ルールに照らして有効とされればレコードの追加は完了だが、無効と判断された場合はＫの値の更新が無効になり、レコード（Ｚ）の追加も無効として処理する。
（主キー重複回避方法３）
編集記録による「ローカル原本ＤＢ」の更新時に、新規レコードの主キーの衝突を検出した場合、編集バージョンの新しい編集記録のものを採用する。これは、編集バージョンの確認により有効と判定されても、さらに内容チェックにより無効と判定されるケースが存在する事を意味する。情報の整合性を保証するためには、さらなる検討が必要である。
＜＜出願時の請求項との対応＞＞
各ＰＣがそれぞれのローカル原本ＤＢを更新するケースとサーバーによるグローバル原本ＤＢを更新するケースでも原本ＤＢ（グローバル原本ＤＢまたはローカル原本ＤＢ）を更新する処理は共通である。これを請求項１に示す。グローバル原本ＤＢ、その複製ＤＢ、ローカル原本ＤＢ、作業ＤＢなどを包含する概念としてデータベースと言う言葉を用いている。これの方法「より最新の情報に基づく編集を優先」する方法であり、計算機が永続的に複製ＤＢを保持する本格的な「並行ＤＢ編集」のみならず、計算機が一時的に複製ＤＢを保持するケースでも有効である。
データベースのバージョン更新処理を明記したのが請求項２である。バージョン設定範囲の概念を明記したのが請求項３である。ここでは単に「指定された情報の範囲」としているが、あらかじめシステムで事前に指定されている場合や、編集記録に指定されている場合など、様々な指定方法を想定しており、特定の指定方法に限定するものではない。
請求項４は、バージョンの代わりに、サーバーが編集記録を受け付けた時刻を利用する方法や、サーバーへの同期アクセス時刻を利用する方法に対応する。これは「指定された時刻」の指定方法を限定するものではない。請求項５は更新の取り消しが有る運用に対応するもので、工程ＢとＣの間に工程ＤとＥが挿入れさている。請求項１に「不変確認範囲」の概念を明記したのが請求項６である。
サーバーにおいてグローバル原本ＤＢを更新するケースに対応するのが請求項７であり、請求項１に加え、サーバーから各ＰＣに更新されたグローバル原本ＤＢの情報を送信する工程Ｆが追加されている。編集記録がサーバーに到着した時刻をデータベースのバージョンとするのが、請求項８である。
請求項２をベースに、サーバーへの同期アクセス時刻をローカル原本ＤＢのバージョンとする事を加えたのが請求項９である。請求項１０はサーバーから編集記録をダウンロードした時刻を更新されたローカル原本ＤＢのバージョンとする事を加えたものである。請求項１をベースに、他の計算機に「編集の停止、または編集アップの停止、またはローカル原本ＤＢの更新停止」を通知する工程を加えたのが請求項１１である。
従来のキャシュ技術の延長で並行ＤＢ編集お行おうとすると、編集毎にコピーを作成するので、そのコピーの処理と通信がオーバーヘッドとなる問題があった。ＰＣ毎のローカル原本ＤＢを永続的に利用する方法により、この問題を解決する。ローカル原本ＤＢは各ＰＣが作成した編集記録に基づき更新される。なお、膨大なＤＢの全てを複製したローカル原本ＤＢを作成する必要は無く、計算機に必要な部分のみを保持するローカル原本ＤＢで十分である。
従来のキャシュの技術に基づく「先着優先」方法では、最新情報を基にした判断が無効となるケースが存在したが、本発明の「より最新の情報に基づく編集を優先」する方針に基づいた方法でこれらの問題が解決される。
従来の「先編集優先」の方法では、ある時点で有効と判定された編集が、後から到着した編集により無効とされるケースが有り運用上問題であった。しかし本願の「更新の取り消しが無い運用」を用いれば問題は無い。なお、本願の「更新の取り消しが有る運用」でも、取り消しが発生するのはごく限られた状況である。ローカル原本ＤＢを同期して編集して編集記録をアップする周期を短くする事により、取り消しの可能性を小さくする事が出来る。
本発明の「より最新の情報に基づく編集を優先」する基準は、「より最新の情報に基づく判断はより確からしい」と考える思想であり、データを扱う人間に受け入れやすい基準である。
本発明のバージョン設定範囲の概念により、ＤＢを実際に分割する事なく、ＤＢを分割したのと同様に、情報の更新の管理が明確になる。さらに「不変確認範囲」の概念により、本当に解決すべき競合のみを的確に検出できる。
ローカル原本ＤＢのバージョンを、（最後に）適用した編集記録がサーバーで受け付けられた日時、または、計算機が（最後に）編集記録の有無を確認した日時とする事により、「より最新の情報に基づく編集を優先」をより重視した運用が可能になる。
本発明ではさらに、編集、編集アップ、ローカル原本ＤＢの更新の停止により、更新の取り消しを防止する仕掛けを明らかにした。
一般的な計算機の構成 ＰＣのローカル原本ＤＢを更新するケース ローカル原本ＤＢの更新手順（その１） ローカル原本ＤＢの更新手順（その２） サーバーのグローバル原本ＤＢを更新するケース グローバル原本ＤＢの更新手順（その１） グローバル原本ＤＢの更新手順（その２） アップ禁止をサーバーからＰＣに伝える手順 編集禁止をサーバーからＰＣに伝える手順 単純化した実施例
0100    計算機
0102    通信装置
0103    演算装置
0104    主記憶装置
0105    主記憶装置内のＤＢ（データベース）
0106    二次記憶装置
0107    入出力装置
0108    表示装置
0109    バス
0110    通信網
0111    二次記憶装置内のＤＢ（データベース）
0201      ＰＣ
0202      インターネットなどの通信網
0203      サーバー
0204      （ＰＣの）記憶装置
0205      （サーバーの）記憶装置
0206      ローカル原本ＤＢ
0207      グローバル初期原本ＤＢ
0208      編集記録
0209      作業ＤＢ
0210      編集記録ｎ
0210      編集記録ｎ＋１
0211      編集記録ｍ
0213      編集手段
0214      更新手段
0215      送信手段
0216      受信手段
0217      送受信管理手段
0218      編集記録１
0219      編集記録ｍ
0220      送信手段
0221      受信手段
0222      送受信管理手段
0301      未受信の編集記録を受信
0302      未処理の編集記録のリストにいれる
0303      未処理の編集記録リストからひとつ編集記録（Ｙ）を取り出し
0304      処理対象の編集記録（Ｙ）から編集バージョン（y）と不変確認範囲を取り出す
0305      不変確認範囲の情報を変更した過去の編集記録（Ｘ）を取り出す
0401      過去の編集記録（Ｘ）の編集バージョン（ｘ）と処理対象の編集記録（Ｙ）の編集バージョン（y）を比較する
0402      ｘとｙを比較
0403      不変確認範囲の情報を変更した過去の編集記録（Ｘ）を（再び）順に取り出す
0404      取り出した過去の編集記録（Ｘ）により、更新されたローカル原本ＤＢのバージョン（ｎｘ）を特定する
0405      ｎｘとｙを比較
0406      取り出した過去の編集バージョン（Ｘ）によるローカル原本ＤＢの更新を取り消す
0407      処理対象の編集記録（Ｙ）でローカル原本ＤＢを更新する
0408      ローカル原本ＤＢのバージョンを更新
0501      ＰＣ
0502      インターネットなどの通信網
0503      サーバー
0504      （ＰＣの）記憶装置
0505      （サーバーの）記憶装置
0506      ローカル原本ＤＢ
0507      グローバル原本ＤＢ
0508      編集記録
0509      作業ＤＢ
0510      ローカル原本ＤＢ更新情報
0511      編集手段
0512      更新手段
0513      送信手段
0515      受信手段
0515      送受信管理手段
0516      ローカル原本ＤＢ更新情報
0517      更新手段
0518      送信手段
0519      受信手段
0520      送受信管理手段
0601      編集記録を受信
0602      処理対象の編集記録（Ｙ）から編集バージョン（y）と不変確認範囲を取り出す
0603      不変確認範囲の情報を変更した過去の編集記録（Ｘ）を取り出し
0604      取り出した過去の編集記録（Ｘ）の編集バージョン（ｘ）と処理対象の編集記録（Ｙ）の編集バージョン（y）を比較する
0605      ｘとｙを比較
0701      不変確認範囲の情報を変更した過去の編集記録を再び順に取り出す
0702      取り出した過去の編集記録（Ｘ）により、更新されたクローバル原本ＤＢのバージョン（ｎｘ）を特定する
0703      ｎｘとｙを比較
0704      取り出した過去の編集バージョン（Ｘ）によるクローバル原本ＤＢの更新を取り消す
0705      処理対象の編集記録（Ｙ）でローカル原本ＤＢを更新する
0706      クローバル原本ＤＢのバージョンを更新する    
0801      編集記録の送信要求（前回最終番号付き）を受信
0802      アップ禁止中の確認
0803      アップ禁止を通知
0804      未送信、つまり前回最終番号以降の、編集記録のリストを作成
0805      送信
0806      完了通知
0901      編集記録の送信要求（前回最終番号付き）を受信
0902      未送信の編集記録のリストを作成
0903      送信
0904      編集禁止中の判定
0905      編集禁止を通知
0906      完了通知
1002    ＰＣ－Ａ
1003    ＰＣ－Ｂ
1004    初期ＤＢ
1005    （ＰＣ－Ａの）ローカル原本ＤＢ更新
1006    （ＰＣ－Ｂの）ローカル原本ＤＢ更新
1008    （ＰＣ－Ａの）レコードＺの複製
1009    （ＰＣ－Ｂの）レコードＺの複製
1010    （ＰＣ－Ａによる）グローバル初期原本ＤＢの取得
1011    （ＰＣ－Ｂによる）グローバル初期原本ＤＢの取得
1012    （ＰＣ－Ａによる）同期
1013    （ＰＣ－Ａの操作者による）編集
1014    （ＰＣ－Ａによる）編集の送信。つまり編集のアップ。
1016    （ＰＣ－Ａへの）確認（通知）と（ＰＣ－Ａによる）同期。なお、同期とは新たな編集とその順番の取得であり、他の記号の説明においても同じである。
1017    （ＰＣ－Ｂによる）同期
1018    （ＰＣ－Ｂの操作者による）編集
1019    （ＰＣ－Ｂによる）編集の送信。つまり編集のアップ。
1021    （ＰＣ－Ｂへの）確認（通知）と（ＰＣ－Ｂによる）同期。
1022    （ＰＣ－Ｂによる）同期
1023    （ＰＣ－Ｂの編集に基づくＰＣ－ＡのレコードＺの複製の）修正
本発明の方法は計算機のプログラムとして実現出来る。図１に典型的な計算機0101の構成を示す。演算装置0103、主記憶装置0104、二次記憶装置0106、入出力装置0107、表示装置0108がバス0109で接続されている。他の計算機とデータを交換する場合は通信装置0102を介して通信網0101に接続する。各請求項で言及している「データベース」が、二次記憶装置0106内のＤＢ0111又は主記憶操作0104の内部のＤＢ0105である。
プログラムは二次記憶装置0106に記録され、起動されると主記憶操作0104に展開され、プログラムに指定された手順で演算装置0103が動作する。この結果として計算機は、プログラム開発者が意図した動作を実現する手段の集合体に再構成される。
プログラムによるＤＢの操作は、ＤＢの全体または一部を主記憶操作0104に展開してから行うのが一般的である。二次記憶装置0106内のＤＢ0111の全部又は一部を主記憶操作0104に展開したＤＢ0105を操作し、その編集結果を二次記憶装置0106内のＤＢ0111に書き込む。しかし通常は、ＤＢは二次記憶装置0106内に有るとし、主記憶操作0104に展開したＤＢ0105と区別せず議論するので、図２および図５では単に、記憶装置0204, 0205, 0504, 0505の中のＤＢとして表示する。
複数のＰＣ0201が作成した編集記録をサーバー0203集め、ＰＣ0201がサーバーに集められた編集記録を受信し、ＰＣのローカル原本ＤＢ0206を更新するケースを図２で説明する。ＰＣ0201がインターネットなどの通信網0202を介して、サーバーと接続している。一般にＰＣは複数存在するが、図２では１台のみを示している。
ＰＣ0201には記憶装置0204が有り、ローカル原本ＤＢ0206が記録されている。ローカル原本ＤＢ0206の初期値は、サーバー0203の記憶装置0205のグローバル初期原本ＤＢ0207をコピーしたものである。ＰＣ0201の操作者の指示を受けて編集手段0213が編集を行うが、この時にはローカル原本ＤＢ0206を直接編集する事はせず、編集結果を作業ＤＢ0209とする。同時に編集記録0208を作成する。この編集記録には、編集バージョンつまり、ローカル原本ＤＢに設定されているバージョンが記録される。
編集記録0208は送信手段0215により通信網0202を介してサーバー0203に送られる。サーバー0203は受信手段0221により受信し、編集記録１0218, 編集記録ｍ0219の列に加えられる。編集記録には編集バージョンなどが記録されているとする。もし、編集記録とは別に編集バージョンがサーバーに送られてきた場合には、サーバーは両者の対応を記録する。
ＰＣ0201がローカル原本ＤＢ0206の更新試みる場合は、まずサーバーに未受信の編集記録の送信を要求する。ＰＣ0201がそれまでに受信した編集記録の最後のバージョンを通知すると、送受信管理手段がそれ以降の編集記録を選別し、送信手段0220によりサーバーから送る。ＰＣの送信の受信の協調作業は送受信管理手段0217により行われ、サーバーの送信の受信の協調作業は送受信管理手段0222により行われる。
ＰＣ0201が受信手段0216により受信した編集記録0210, 2011, 0212は記憶装置0204に記録される。更新手段0214がこれらを順番に取り出して、有効性を判定してローカル原本ＤＢ0206を更新し、そのバージョンを更新する。
図２のＰＣ0201の更新手段0214による、ローカル原本ＤＢ0206の更新手順を図３と図４に示す。ＰＣ0201はまず「未受信の編集記録を受信」0301しては、「未処理の編集記録のリストにいれる」0302。これを全ての未受信の編集記録に対して繰り返す。未処理の編集記録のリストが図２の編集記録ｎ0210, 編集記録ｎ＋１0211, 編集記録ｍ0212に相当する。
次に「未処理の編集記録リストからひとつ編集記録（Ｙ）を取り出し」0303、この「処理対象の編集記録（Ｙ）から編集バージョン（y）と不変確認範囲を取り出す」0304、そしてこの「不変確認範囲の情報を変更した過去の編集記録（Ｘ）を取り出す」0305、「過去の編集記録（Ｘ）の編集バージョン（ｘ）と処理対象の編集記録（Ｙ）の編集バージョン（y）を比較する」0401。「ｘとｙを比較」0402し、ｙ＜ｘまたはｙ＝ｘの場合は処理対象の編集記録（Ｙ）を無効とし、更新処理は行わない。そして次の未処理の編集記録に移る（0303に移る）。
ｙ＞ｘの場合は、このＸに対してＹが有効なので次の過去の編集記録の調査に移る（0305に移る）。「不変確認範囲の情報を変更した過去の編集記録（Ｘ）を特定」0305が全て完了して、全てに対して未処理の編集記録（Ｙ）が有効な時、有効と判定され次の処理に移る（0403に移る）。
次に「不変確認範囲の情報を変更した過去の編集記録を編集記録（Ｘ）を（再び）順に取り出す」0403。有れば「取り出した過去の編集記録（Ｘ）により、更新されたローカル原本ＤＢのバージョン（ｎｘ）を特定する」0404。「ｎｘとｙを比較」0405し、ｙ＜ｎｘの場合に「取り出した過去の編集バージョン（Ｘ）によるローカル原本ＤＢの更新を取り消す」0406。
「不変確認範囲の情報を変更した過去の編集記録を再び取り出す」0403で全ての過去の編集記録を取り出し処理が完了した後で、「処理対象の編集記録（Ｙ）でローカル原本ＤＢを更新」0407し、「ローカル原本ＤＢのバージョンを更新」0408する。
バージョン設定範囲が指定されており、不変確認範囲と一致する場合は、以下の手順となる。なお、バージョン設定範囲は編集記録に指定されているものとする。「取り出した過去の編集記録（Ｘ）の編集バージョン（ｘ）と処理対象の編集記録（Ｙ）の編集バージョン（y）を特定する」0401処理では、処理対象の編集記録（Ｙ）に指定されているバージョン設定範囲について「過去の編集記録（Ｘ）の編集バージョン（ｘ）と処理対象の編集記録（Ｙ）の編集バージョン（y）を特定する」。そしてこれ以降のバージョンの比較はこれに対して行われる。
サーバーが編集記録を受け付けた時刻をバージョンとする運用の場合は、サーバーが編集記録にその受付時間を記録する。そしてＰＣは「ローカル原本ＤＢのバージョンを更新」0408において、更新に用いた編集記録に記録されている受付時間を、更新されたローカル原本ＤＢのバージョンとして記録する0408。
ＰＣが、サーバーにアクセスし、未受信の編集記録の有無を確認した時刻をサーバーから取得し、その時刻を原本ＤＢのバージョンとする運用の場合は、「未受信の編集記録を受信」0301と「未処理の編集記録のリストにいれる」0302の前後または途中で、サーバーへのアクセス時間を取得する。ＰＣ毎の時間のズレを考えると、この時間はサーバーから貰うのが望ましい。そしてこの時間を記録しておき、受信した編集記録の最後の編集記録で「ローカル原本ＤＢを更新」0407した後、記録しておいた時間をローカル原本ＤＢのバージョンとして記録する0408。
サーバーでグローバル原本ＤＢを更新するケースを図５で説明する。ＰＣ0501がインターネットなどの通信網0502を介して、サーバー0503と接続している。一般にＰＣは複数存在するが、図５では１台のみを示している。
ＰＣ0501には記憶装置0504が有り、ローカル原本ＤＢ0506が記録されている。ＰＣ0501の操作者の指示を受けて編集手段0511が編集を行うが、この時にはローカル原本ＤＢ0506を直接編集する事はせず、編集結果を作業ＤＢ0509とする。同時に編集記録0508を作成する。この編集記録には、編集バージョンつまり、ローカル原本ＤＢに設定されているバージョンが記録される。
編集記録0508は送信手段0513により通信網0502を介してサーバー0503に送られる。サーバー0503は受信手段0519により受信し、編集記録に記録されていたバージョンで有効性を判定し、グローバル原本ＤＢ0507を更新する。この時、ローカル原本ＤＢ更新情報0516を作成する。ローカル原本ＤＢ更新情報0516はサーバーの送信手段0518によりＰＣ0501に送られ、受信手段0514により受信され、記憶装置0504に記録される。更新手段0512はこのローカル原本ＤＢ更新情報0510を用いて、ローカル原本ＤＢ0506を更新する。ＰＣの送信の受信の協調作業は送受信管理手段0515により行われ、サーバーの送信の受信の協調作業は送受信管理手段0520により行われる。
サーバー0503でグローバル原本ＤＢを更新する手順を図６と図７に示す。ＰＣ0501からの「編集記録を受信」0601し、この「処理対象の編集記録（Ｙ）から編集バージョン（y）と不変確認範囲を取り出す」0602。そしてこの「不変確認範囲の情報を変更した過去の編集記録（Ｘ）を取り出し」0603、「取り出した過去の編集記録（Ｘ）の編集バージョン（ｘ）と処理対象の編集記録（Ｙ）の編集バージョン（y）を比較する」0604。「ｘとｙを比較」0605し、ｙ＜ｘまたはｙ＝ｘの場合は処理対象の編集記録（Ｙ）を無効とし、更新処理は行わない。
ｙ＞ｘの場合は、このＸに対してＹが有効なので次の過去の編集記録の調査に移る（0603に移る）。「不変確認範囲の情報を変更した過去の編集記録（Ｘ）を取り出す」0603が全て完了して、全てに対して未処理の編集記録（Ｙ）が有効な時、有効と判定され次の処理に移る（0701に移る）。
次に、「不変確認範囲の情報を変更した過去の編集記録を再び順に取り出す」0701。有れば「取り出した過去の編集記録（Ｘ）により、更新されたグローバル原本ＤＢのバージョン（ｎｘ）を特定する」0702。「ｎｘとｙを比較」0703し、ｙ＜ｎｘの場合に「取り出した過去の編集バージョン（Ｘ）によるグローバル原本ＤＢの更新を取り消す」0704。
「不変確認範囲の情報を変更した過去の編集記録を再び取り出す」0701で全ての過去の編集記録を取り出し処理が完了した後で、「処理対象の編集記録（Ｙ）でローカル原本ＤＢを更新」0705し、「クローバル原本ＤＢのバージョンを更新」0706する。
更新の取り消し防止のための「アップ禁止」をサーバーからＰＣに伝える手順を説明したのが図８である。ＰＣから「編集記録の送信要求（前回最終番号付き）を受信」0801したとき、サーバーは「アップ禁止中」0802であるかを判定する。あるＰＣからの要請に基づき、サーバーがアップ禁止中の状態であれば、編集記録の送信要求したＰＣに対して「アップ禁止を通知」0803する。アップ禁止中でなければ「未送信、つまり前回最終番号以降の、編集記録のリストを作成」0804し、これらをＰＣに対して「送信」0805し、最後に「完了通知」0806を送る。
更新の取り消し防止のための「編集禁止」をサーバーからＰＣに伝える手順を説明したのが図９である。ＰＣから「編集記録の送信要求（前回最終番号付き）を受信」0901すると、サーバーは「未送信（つまり前回最終番号以降）の編集記録のリストを作成」0902し、これらをＰＣに対して「送信」0903する。この後で、サーバーは「（ローカル原本ＤＢの）編集禁止中」0904であるかを判定する。あるＰＣからの要請に基づき、更新禁止中であれば、編集記録の送信要求をしたＰＣに対して「編集禁止を通知」0905し、最後に「完了通知」0906を送る。
＜単純化した実施例＞
図１０にもう一つの実施例を示す。図１０のＤＢはＲＤＢで、バージョン設定範囲をＤＢ全体、バージョンは整数、不変確認範囲は編集したレコードのみとし、「更新の取り消しを行わない運用」としている。
また、レコード毎にこのレコードを編集した時点の編集バージョンを「レコードバージョン」として記録している。これにより編集解消のレコードのバージョンと処理対象の編集記録（Ｙ）の編集バージョン（y）を比較するだけで、「不変確認範囲の情報を変更した過去の編集記録（Ｘ）を取り出す」0305と「過去の編集記録（Ｘ）の編集バージョン（ｘ）と処理対象の編集記録（Ｙ）の編集バージョン（y）を比較する」0401 の処理が行える。
この様に単純化されているが、バージョンの移り変わりを見るには都合が良い。図１０ではサーバーに、グローバル初期原本ＤＢ、編集記録とその到着順（アップ順）が記録されている。サーバーの縦軸はその時点で最も新しい編集を示している。
ＰＣ－Ａ1002とＰＣ－Ｂ1003はそれぞれグローバル初期原本ＤＢ1004を取得1010, 1011し、それぞれのローカル原本ＤＢ1005, 1006としている。サーバーのグローバル初期原本ＤＢ1004をコピーしているので、どちらもベースバージョンは０である。その後、サーバー1001に編集１から編集６がアップされているが、これはＰＣ－Ａ1002、ＰＣ－Ｂ1003以外のＰＣ－がアップした編集である。
図２では、ＰＣ－Ａ1002はもう一度サーバーにアクセスしその時の最新の編集しその順番を取得している1012。このとき、編集１を取り込むので、ローカル原本ＤＢ1005のバージョンは１になる。
さて、ＰＣ－Ａ1002の操作者が、ローカル原本ＤＢ1005内のレコードＺの複製1008を編集したとする1013。この時、ローカル原本ＤＢ1005のベースバージョンが1なので、編集された「レコードＺの複製1008」のレコードバージョンが１にセットされる。この編集記録がサーバーにアップされ1014、編集７として記録される。この直後に、ＰＣ－Ａ1002は、（既に取得してある）編集１より後にアップされた、編集２から編集６を取得し、さらにＰＣ－Ａ1002先のアップ1014が編集７となった事を確認する。あらかじめ指定された「編集の有効性の判定」に基づき編集７までを順番に調査し、ローカル原本ＤＢ1005を更新する。ここでは、編集７が有効と判定されたとし、ローカル原本ＤＢ1005のベースバージョンが７になる。
一方、ＰＣ－Ｂ1003はサーバー1001から、編集１から（この同期1017時点での最新の）編集６を取得し1017、ローカル原本ＤＢ1006を更新してベースバージョンを６とする。その後ＰＣ－Ｂ1003の操作者が、「レコードＺの複製1009」を編集した1018とする。この時、「レコードＺの複製1009」のレコードバージョンが６になり、編集記録がサーバーにアップされ1019、編集８として記録される。
その後別のＰＣ－から編集９がアップされた後、ＰＣ－Ａ1002がサーバー1001にアクセスし、（既に取得してある）編集７より後にアップされた編集８と編集９を取得する1022。そしてローカル原本ＤＢ1008に編集８と編集９を順番に適用し、「編集の有効性の判定」を行い、ローカル原本ＤＢ1008を更新する。ここでローカル原本ＤＢ1008に編集９が反映されるので、製ＤＢ1008のベースバージョンが９になる。この時点で、先にＰＣ－Ｂ1003が編集したレコードＺの複製1009の内容がＰＣ－Ａ1002のローカル原本ＤＢ1005で有効になり、先にＰＣ－Ａ1002が編集したレコードＺの複製1008内容が無効になった事が（ＰＣ－Ａ1002で）判明する。
データベースを複数の計算機から並行して編集出来ると使い勝手は良いが、並行編集の競合解消が問題である。本願の競合解消方法は「より最新の情報に基づく編集を優先」する仕組みであり、計算機が永続的に複製ＤＢを保持する本格的な「並行ＤＢ編集」においても、計算機が一時的に複製ＤＢを保持するケースにおいても有効である。この方法には「古い情報に基づく編集は無効と判定される」特徴がある。競合が予想される情報を編集する場合は「最新の情報との同期、編集、編集記録の送信」を迅速に行う「ほぼオンライン運用」により、この編集が無効となる可能性を小さくする事が出来る。逆に競合が予想されない情報を編集する場合は、情報の同期の後でゆっくり編集を行い、編集記録をまとめて送信する「ほぼオフライン運用」で良い。本願の方法により、幅広い応用分野でのデータベースの並行編集が可能となった。

Claims (11)

  1. データベースの編集方法であって、
    （工程Ａ）データベースに対する編集記録を受信し、該編集記録のバージョン、つまり該編集記録に対して記録されている「編集対象のデータベースのバージョン」、を取り出し、
    （工程Ｂ）それまでに、該データベースの複製に適用された編集記録のバージョンよりも、工程Ａの該編集記録のバージョンの方が新しい場合に、
    （工程Ｃ）工程Ａの該編集記録を用いて該データベースの更新を行う、
    一連の工程を特徴とする方法。
  2. データベースの編集方法であって、
    （工程Ａ）データベースに対する編集記録を受信し、該編集記録のバージョン、つまり該編集記録に対して記録されている「編集対象のデータベースのバージョン」、を取り出し、
    （工程Ｂ）それまでに、該データベースの複製に適用された編集記録のバージョンよりも、工程Ａの該編集記録のバージョンの方が新しい場合に、
    （工程Ｃ１）工程Ａの該編集記録を用いて該データベースの更新を行い、該データベースに記録されていたバージョンを更新する、
    一連の工程を特徴とする方法。
  3. データベースの編集方法であって、
    （工程Ａ）データベースに対する編集記録を受信し、該編集記録のバージョン、つまり該編集記録に対して記録されている「編集対象のデータベースのバージョン」、を取り出し、
    （工程Ｂ）それまでに、該データベースの複製に適用された編集記録のバージョンよりも、工程Ａの該編集記録のバージョンの方が新しい場合に、
    （工程Ｃ２）工程Ａの該編集記録を用いて該データベースの更新を行い、指定された情報の範囲に対して記録されていたバージョンを更新する、
    一連の工程を特徴とする方法。
  4. データベースの編集方法であって、
    （工程Ａ）データベースに対する編集記録を受信し、該編集記録のバージョンつまり該編集記録に対して記録されている「編集対象のデータベースのバージョン」、を取り出し、
    （工程Ｂ）それまでに、該データベースの複製に適用された編集記録のバージョンよりも、工程Ａの該編集記録のバージョンの方が新しい場合に、
    （工程Ｃ３）工程Ａの該編集記録を用いて該データベースの更新を行い、指定された時刻を該データベースのバージョンとして記録する、
    一連の工程を特徴とする方法。
  5. データベースの編集方法であって、
    （工程Ａ）データベースに対する編集記録を受信し、該編集記録のバージョン、つまり該編集記録に対して記録されている「編集対象のデータベースのバージョン」、を取り出し、
    （工程Ｂ）それまでに、該データベースの複製に適用された編集記録のバージョンよりも、工程Ａの該編集記録のバージョンの方が新しい場合に、
    （工程Ｄ）それまでに該データベースの複製に適用された編集記録のなかで、これらの編集記録の適用により更新された後の該データベースのバージョンが、工程Ａの該編集記録に記録されたバージョンより新しい編集記録を特定し、
    （工程Ｅ）工程Ｄで特定された該編集記録により該データベースの複製に対して行った更新を元に戻し、
    （工程Ｃ）工程Ａの前記編集記録を用いて該データベースの更新を行う、
    一連の工程を特徴とする方法。
  6. データベースの編集方法であって、
    （工程Ａ）データベースに対する編集記録を受信し、該編集記録のバージョン、つまり該編集記録に対して記録されている「編集対象のデータベースのバージョン」、を取り出し、
    （工程Ｂ１）Ａの該編集記録に指定された不変確認範囲に対し、それまでに適用された編集記録のバージョンよりも、Ａの該編集記録のバージョンの方が新しい場合に
    （工程Ｃ）工程Ａの該編集記録を用いて該データベースの更新を行う、
    一連の工程を特徴とする方法。
  7. データベースの編集方法であって、
    （工程Ａ）データベースに対する編集記録を受信し、該編集記録のバージョン、つまり該編集記録に対して記録されている「編集対象のデータベースのバージョン」、を取り出し、
    （工程Ｂ）それまでに、該データベースの複製に適用された編集記録のバージョンよりも、工程Ａの該編集記録のバージョンの方が新しい場合に、
    （工程Ｃ）工程Ａの該編集記録を用いて該データベースの更新を行う、
    一連の工程と、
    （工程Ｆ）更新した該データベースの情報を、他の計算機に送信する工程、
    を特徴とする方法。
  8. データベースの編集方法であって、
    （工程Ａ）データベースに対する編集記録を受信し、該編集記録のバージョン、つまり該編集記録に対して記録された「編集対象のデータベースに記録されていたバージョン」、を取り出し、
    （工程Ｂ）それまでに、該データベースの複製に適用された編集記録のバージョンよりも、工程Ａの該編集記録のバージョンの方が新しい場合に、
    （工程Ｃ４）工程Ａの該編集記録を用いて該データベースの更新を行い、該編集記録が到着した時刻を該データベースのバージョンとする工程、
    一連の工程と、
    （工程Ｆ）最新の該データベースの情報を、他の計算機に送信する工程、
    を特徴とする方法。
  9. データベースの編集方法であって、
    （工程Ａ１）データベースに対する編集記録で未受信の編集記録の有無を調査し、あれば未受信の該編集記録を受信し、該編集記録のバージョン、つまり該編集記録に対して記録されている「編集対象のデータベースのバージョン」、を取り出し、
    （工程Ｂ２）それまでに、該データベースの複製に適用された編集記録のバージョンよりも、工程Ａ１で受信した該編集記録のバージョンの方が新しい場合に、
    （工程Ｃ５）工程Ａ１で受信した該編集記録を用いて該データベースの更新を行い、工程Ａ１で未受信の編集記録の有無を調査した時刻を該データベースのバージョンとして記録する工程、
    を特徴とする方法。
  10. データベースの編集方法であって、
    （工程Ａ１）データベースに対する編集記録で未受信の編集記録の有無を調査し、あれば未受信の該編集記録を受信し、該編集記録のバージョン、つまり該編集記録に対して記録されている「編集対象のデータベースのバージョン」、を取り出し、
    （工程Ｂ２）それまでに、該データベースの複製に適用された編集記録のバージョンよりも、工程Ａ１で受信した該編集記録のバージョンの方が新しい場合に、
    （工程Ｃ６）工程Ａ１で受信した該編集記録を用いて該データベースの更新を行い、工程Ａ１で未受信の該編集記録を受信した時刻を該データベースのバージョンとして記録する工程、
    を特徴とする方法。
  11. データベースの編集方法であって、
    （工程Ａ）データベースに対する編集記録を受信し、該編集記録のバージョン、つまり該編集記録に対して記録されている「編集対象のデータベースのバージョン」、を取り出し、
    （工程Ｂ）それまでに、該データベースの複製に適用された編集記録のバージョンよりも、工程Ａの該編集記録のバージョンの方が新しい場合に、
    （工程Ｃ）工程Ａの編集記録を用いて該データベースの更新を行う、
    一連の工程と、
    （工程Ｇ）他の計算機に対し、編集の停止、または編集アップの停止、またはローカル原本ＤＢの更新停止を通知する工程、
    を特徴とする方法。
PCT/JP2009/002490 2007-06-06 2009-06-03 データベース並行編集の競合解消方式 WO2009147846A1 (ja)

Priority Applications (7)

Application Number Priority Date Filing Date Title
JP2010515774A JP5543918B2 (ja) 2008-06-04 2009-06-03 データベース並行編集の競合解消方式
US12/995,158 US9678996B2 (en) 2007-06-06 2009-06-03 Conflict resolution system for database parallel editing
US12/688,854 US8171003B2 (en) 2007-06-06 2010-01-15 Method and apparatus for changing reference of database
US13/714,422 US20130110777A1 (en) 2007-06-06 2012-12-14 Synchronization of data edited in parallel
US13/726,549 US20130179652A1 (en) 2007-06-06 2012-12-25 Support for synchronization of data edited in parallel
US13/802,740 US20130204842A1 (en) 2007-06-06 2013-03-14 Method and system for synchronization of data edited in parallel
US15/449,961 US20170177647A1 (en) 2008-06-04 2017-03-05 Parallel database editing

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JPPCT/JP2008/001424 2008-06-04
PCT/JP2008/001424 WO2008149552A1 (ja) 2007-06-06 2008-06-04 データベース矛盾解消方式
PCT/JP2008/001506 WO2009147701A1 (ja) 2008-01-08 2008-06-12 データベースへの平行アクセスプログラム
JPPCT/JP2008/001506 2008-06-12

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US12/995,158 A-371-Of-International US9678996B2 (en) 2007-06-06 2009-06-03 Conflict resolution system for database parallel editing
US13/714,422 Continuation-In-Part US20130110777A1 (en) 2007-06-06 2012-12-14 Synchronization of data edited in parallel

Publications (1)

Publication Number Publication Date
WO2009147846A1 true WO2009147846A1 (ja) 2009-12-10

Family

ID=41397796

Family Applications (5)

Application Number Title Priority Date Filing Date
PCT/JP2008/001719 WO2009147704A1 (ja) 2007-06-06 2008-07-01 テーブルとテーブル項目の平行編集プログラム
PCT/JP2008/001900 WO2009147705A1 (ja) 2008-06-04 2008-07-15 データベース接続プログラムおよび装置
PCT/JP2009/002491 WO2009147847A1 (ja) 2007-06-06 2009-06-03 データベース並行編集方式
PCT/JP2009/002501 WO2009147851A1 (ja) 2007-06-06 2009-06-03 データベースのデータ項目の平行編集方式
PCT/JP2009/002490 WO2009147846A1 (ja) 2007-06-06 2009-06-03 データベース並行編集の競合解消方式

Family Applications Before (4)

Application Number Title Priority Date Filing Date
PCT/JP2008/001719 WO2009147704A1 (ja) 2007-06-06 2008-07-01 テーブルとテーブル項目の平行編集プログラム
PCT/JP2008/001900 WO2009147705A1 (ja) 2008-06-04 2008-07-15 データベース接続プログラムおよび装置
PCT/JP2009/002491 WO2009147847A1 (ja) 2007-06-06 2009-06-03 データベース並行編集方式
PCT/JP2009/002501 WO2009147851A1 (ja) 2007-06-06 2009-06-03 データベースのデータ項目の平行編集方式

Country Status (2)

Country Link
JP (1) JPWO2009147705A1 (ja)
WO (5) WO2009147704A1 (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8171003B2 (en) 2007-06-06 2012-05-01 Kunio Kamimura Method and apparatus for changing reference of database
KR20150111935A (ko) * 2013-01-30 2015-10-06 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 콘텐트 큐레이션을 위한 애플리케이션 프로그래밍 인터페이스
JP2018510430A (ja) * 2015-04-01 2018-04-12 アリババ グループ ホウルディング リミテッド データベースのための遠隔データ同期方法及び装置
US10105700B2 (en) 2013-07-17 2018-10-23 The Johns Hopkins University Microfluidic chip for analysis of cell motility and methods for using same
CN111523291A (zh) * 2020-04-21 2020-08-11 四川川大智胜软件股份有限公司 一种低空雷达多席位空域数据编辑方法
JP7475086B1 (ja) 2023-02-03 2024-04-26 株式会社ミヤワキ 編集方法、編集装置及びプログラム

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5356351B2 (ja) * 2010-09-30 2013-12-04 ヤフー株式会社 ストレージサーバ、ファイル同期システム、ファイル衝突処理方法及びプログラム

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000284998A (ja) * 1999-03-31 2000-10-13 Ricoh Co Ltd データ更新制御システム、データ更新制御方法、その方法を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05233405A (ja) * 1992-02-18 1993-09-10 Hitachi Ltd データベース変更監視方式
JPH07191898A (ja) * 1993-12-27 1995-07-28 Fujitsu Ltd データベース排他制御装置
CA2152528C (en) * 1994-07-29 2000-04-18 Chung-Hwa Herman Rao Distributed systems with replicated files
JP3534596B2 (ja) * 1997-12-05 2004-06-07 富士通株式会社 インテリジェントネットワーク内のデータベースの同期方法と装置
JP4187302B2 (ja) * 1998-03-25 2008-11-26 富士通株式会社 リレーショナルデータベース同期方法およびそのプログラムを記録した記録媒体
JP2000020370A (ja) * 1998-06-29 2000-01-21 Sharp Corp データ同期処理装置
JP2000194592A (ja) * 1998-12-25 2000-07-14 Nippon Telegr & Teleph Corp <Ntt> デ―タベ―スシステム、デ―タベ―スアクセスシステム、およびデ―タベ―スアクセスプログラムを記録した記録媒体
JP2000222268A (ja) * 1999-01-29 2000-08-11 Hitachi Ltd 複数のコンピュータ間におけるファイルの同期方法
US6938070B2 (en) * 2001-12-17 2005-08-30 Dassault Systemes Conflict resolution for collaborative work system
JP4279499B2 (ja) * 2002-03-01 2009-06-17 シャープ株式会社 情報処理装置
JP2007179105A (ja) * 2005-12-26 2007-07-12 World Planning:Kk 共有データベースの制御システム及び共有データベースの制御方法並びにコンピュータプログラム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000284998A (ja) * 1999-03-31 2000-10-13 Ricoh Co Ltd データ更新制御システム、データ更新制御方法、その方法を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ANDREW S. TANENBAUM: "DISTRIBUTED SYSTEMS", PEARSON EDUCATION JAPAN, 20 October 2003 (2003-10-20), pages 614 - 634, 698-701 *
MARK DODGE: "Microsoft Office Excel 2003", OFFICIAL MANUAL, 12 July 2004 (2004-07-12), pages 535 - 548 *

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8171003B2 (en) 2007-06-06 2012-05-01 Kunio Kamimura Method and apparatus for changing reference of database
KR20150111935A (ko) * 2013-01-30 2015-10-06 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 콘텐트 큐레이션을 위한 애플리케이션 프로그래밍 인터페이스
KR102283274B1 (ko) 2013-01-30 2021-07-28 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 콘텐트 큐레이션을 위한 애플리케이션 프로그래밍 인터페이스
US10105700B2 (en) 2013-07-17 2018-10-23 The Johns Hopkins University Microfluidic chip for analysis of cell motility and methods for using same
JP2018510430A (ja) * 2015-04-01 2018-04-12 アリババ グループ ホウルディング リミテッド データベースのための遠隔データ同期方法及び装置
US10877990B2 (en) 2015-04-01 2020-12-29 Advanced New Technologies Co., Ltd. Remote database synchronization
CN111523291A (zh) * 2020-04-21 2020-08-11 四川川大智胜软件股份有限公司 一种低空雷达多席位空域数据编辑方法
CN111523291B (zh) * 2020-04-21 2023-04-18 四川川大智胜软件股份有限公司 一种低空雷达多席位空域数据编辑方法
JP7475086B1 (ja) 2023-02-03 2024-04-26 株式会社ミヤワキ 編集方法、編集装置及びプログラム

Also Published As

Publication number Publication date
WO2009147704A1 (ja) 2009-12-10
WO2009147847A1 (ja) 2009-12-10
WO2009147705A1 (ja) 2009-12-10
WO2009147851A1 (ja) 2009-12-10
JPWO2009147705A1 (ja) 2011-10-20

Similar Documents

Publication Publication Date Title
US9678996B2 (en) Conflict resolution system for database parallel editing
US11003689B2 (en) Distributed database transaction protocol
US10970260B2 (en) Moving data between partitions
CN108932282B (zh) 一种数据库迁移方法、装置和存储介质
US9251163B2 (en) File sharing system and file sharing method
US10795881B2 (en) Table replication in a database environment
JP4414381B2 (ja) ファイル管理プログラム、ファイル管理装置、ファイル管理方法
WO2009147846A1 (ja) データベース並行編集の競合解消方式
US10430281B2 (en) Space efficient cascading point in time copying
US20110035428A1 (en) Tracking file contents
CN108021338B (zh) 用于实现两层提交协议的系统和方法
US11599504B2 (en) Executing a conditional command on an object stored in a storage system
US20130041868A1 (en) Data synchronization
US20060004877A1 (en) Method and system for data processing with data replication for the same
JP5543918B2 (ja) データベース並行編集の競合解消方式
JP4855537B2 (ja) データベース並行編集方式
US20170177647A1 (en) Parallel database editing
JP5543899B2 (ja) データベースのデータ項目の平行編集方式
JP4923140B2 (ja) データベース並行編集方式
WO2009147701A1 (ja) データベースへの平行アクセスプログラム
US9424261B2 (en) Techniques to take clean database file snapshot in an online database
JP5543901B2 (ja) データベース並行編集方式
JP4855538B2 (ja) データベースのデータ項目の平行編集方式
WO2004031957A1 (ja) データベース複製方法、データベース複製装置、データベース創成方法およびデータベース創成装置
US20130110777A1 (en) Synchronization of data edited in parallel

Legal Events

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

Ref document number: 09758113

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2010515774

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 12995158

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09758113

Country of ref document: EP

Kind code of ref document: A1