JP4855537B2 - Database parallel editing method - Google Patents

Description

The present invention implements parallel editing (hereinafter referred to as “parallel DB editing”) for a database (hereinafter referred to as “DB”).

The following are listed as typical operation modes of DB.

"Single DB access"
Operation to operate DB with only one computer. Since it is only this computer that can edit the DB, it is easy to prevent access conflicts, but it is not suitable for operations in which a plurality of computers access the DB.

"Server DB access"
A server computer (hereinafter “server”) manages the DB, and a terminal computer (hereinafter “PC”) accesses the server and accesses the DB through server processing. Since only one PC directly accesses the DB, it is easy to prevent access conflicts, and a vestigec lock cursor (Non-Patent Document 1) and a transaction lock (Non-Patent Document 2) are used.

The system "Power-up Newspaper Sales" developed and directed by the author allows concurrent access for browsing only. However, “editing rights” are acquired before editing, and only one PC can be edited at the same time. This is also a lock.

However, in situations where communication with the server is not possible, data cannot be accessed and locks cannot be acquired or returned. Since cases in which communication is impossible in a mobile body frequently occur, the DB operation is a great restriction. In so-called mission-critical operations such as disaster relief, medical care, and finance, business execution is required even in situations where communication is impossible, but this cannot be met. Even if communication can be ensured, in a poor communication environment, the server response may become extremely long due to retransmission or the like, which may not be practical.

Attempts have been made to improve the efficiency of processing and communication by using a cache technology that performs processing by creating a working copy. Microsoft's ADO.NET copies the data necessary for the immediate work to the PC from the server, cuts the connection with the server, and then edits. After editing, connect to the server again and send the edited content to the server. If the information to be edited has already been changed from another terminal computer, later (this) editing is invalidated. . It can be said that it is a kind of editing lock if it is considered that “the editing is invalidated when the lock fails as a result”. This is called “optimistic concurrency control” (Non-Patent Document 3 and Non-Patent Document 4). However, the following inconveniences sometimes occur.

(1) Since a copy is created for each edit, the copy process and communication become overhead. (P19 of Non-Patent Document 1) To reduce this, it is necessary to limit the range of copying, but this requires a thorough understanding of the structure of information targeted by the application.

(2) It is difficult to estimate how long the cache information is valid. The smaller the cache amount with priority on copy efficiency, the more likely it is not usable in the next editing. In “optimistic concurrency control”, if even one place is changed, it becomes invalid, so it is also a problem to increase the cache amount.

(3) It is difficult to detect that information that a certain PC has operated (input, correction, deletion) in the past has been changed (deletion, recorrection, reinput) by the operation of another PC. This problem is common to both “server DB access” and “cache”. The determination result of the validity / invalidity of editing by the PC is known at the time of up-loading, but it is difficult to quickly grasp that the information that has been input before then has been determined to be valid has been changed.

Other survey results are shown below. Non-Patent Document 5 is an invention related to file caching, and when an editing conflict (competition in this application) is detected, editing is simply rejected (10th line from the lower right on page 7 of Non-Patent Document 5) and recorded. Create In Patent Document 1, when a server detects a DB editing collision, the server DB updated correctly is sent ("Solution means" and 36 levels). In Patent Document 2, an update with a later update time is valid, and in Patent Document 1, an update with a later update time is valid. Neither of them solves the above problem.

Patent Document 3 is an invention related to a condition for starting database synchronization, and the synchronization method merely shows a general synchronization concept of “synchronizing by notifying each other of update information”.

Patent Document 4 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. Patent Literature 5, Patent Literature 6, Patent Literature 7, Patent Literature 8, and Patent Literature 9 were also investigated, but all differ from the present invention.
JP 9-91184 A Japanese Laid-Open Patent Publication No. 2004-13867 JP 2004-86800 A JP 2006-284998 A JP 11-161535 A JP 2005-503606 Gazette Special table 2005-508050 gazette JP-A-8-16447 JP 2000-501532 A William R. Vaughn, translation of top studio, supervised by Yukiko Ito, Windows (registered trademark) Database Programming ADO.NET Special Course VB.NET, published on August 4, 2003, Shosuisha Super Illustrated SQL Handbook, C & R Laboratories, first published on August 12, 2005 "Outline of data concurrency control in ADO.NET", January 2007, MSDN subscription library (msdn subscriptions Library), disk file (URL: ms-help: //MS.MSDNQTR.v80.en/MS. MSDN.v80 / MS.VisualStudio.v80.en / dv_raddata / html / d5293098-4a88-4110-abd2-34d9e6661664.htm) “Tutorial: Handling Concurrency Exceptions”, January 2007, MSDN Subscriptions Library, disk file (URL: ms-help: //MS.MSDNQTR.v80.en/MS.MSDN.v80 /MS.VisualStudio.v80.en/dv_raddata/html/73ee9759-0a90-48a9-bf7b-9d6fc17bff93.htm) "World-wide distributed file system SKINNY", Information Processing Society of Japan Research Report, 95-OS-70, (Academic Publications Institute of Information Processing Vol. 95, No. 79 ISSN 0919-6072

Clarify full-scale parallel DB access and solve the problem of conventional parallel DB editing based on cache.

The present invention will be described using the following examples.

(1) 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. In this local original DB, an initial version, that is, an order number for identifying the update order, can be set. The effectiveness of editing can be determined using the version.

(2) Local editing Each PC performs local editing on its local original DB. Before this editing, a working copy of the local original DB is created, and editing is performed on this copy. Further, at the time of editing, an “editing record” is created in which the edited contents are recorded. At least “edit contents” are recorded in this edit record, but “edit version” or the like may be recorded in addition to this.

“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.

(3) Transmission of edit record to server Each PC transmits “edit record” to the server. When “edit record” and “edit version” are recorded separately, the correspondence with “edit record” is clearly indicated and “edit version” is also transmitted. It should be noted that the operation of recording the “edit version” in the “edit record” seems simple and realistic.

(4) Receiving edit records by the server The server records the edit records that have arrived from the PC together with the order of arrival.

(5) Receiving edit records from the server The PC requests the server to send unedited edit records, and receives these edit records and their order (arrival at the server). If an edit version is specified in the edit record, this is also received.

(6) Update of local original DB The PC extracts edit records in the specified order, determines the validity, and tries to update the “local original DB” based on the contents. When the version is set, the version of the local original DB is updated.

The initial local original DBs of all the PCs are the same, and edit records of local editing in each PC are taken out in the order of arrival at the server, and the local original DB is updated. Since the editing information of the same content is processed in the same order and with the same logic to update the local original DB, the resulting local original DB of each PC is the same. This is the reason why the local original DB of each PC is synchronized without updating the global original DB on the server.

Here, the point is to give a unique order to the edit records created on each PC. Here, the order up to the server is used, but this order may be changed or the order may be set by other methods. The order of uploading to the server may be changed according to its own criteria (for example, operator priority). It suffices if the order of taking out and updating the local original DB is the same on all related PCs.

As another method of assigning the order of editing records, for example, the server or a specific PC determines the order (or time) of the editing records (notifies the PC that creates or holds the editing records) and creates or holds the editing records. The PC which performs this may enter this order in the edit record and notify each other of the edit record. It suffices if the order of taking out and updating the local original DB is the same on all related PCs.

Since each PC updates the duplicate DB at their convenience, the progress of the update with the local original DB of each PC varies in real time, but after updating with a specific editing record The state of the local original DB is the same. That is, the local original DB of each PC is synchronized with the order of editing and recording as a common time axis.

It should be noted that the “validity determination criterion” and the “local original DB update processing method” need to be the same in all related PCs. However, if it is the same, there is no restriction on the processing. If it is determined that all or part of each edit record is valid or invalid and the local original DB is updated in the same manner, the local original DB of each PC is set with the order of the edit records as a common time axis. Are synchronized.

A series of operation examples focusing on a certain PC will be described. It is assumed that this PC receives the latest editing record from the server and updates the local original DB. The PC edits the local original DB and uploads the editing record. During this editing, the editing record may have been uploaded to the server from another computer.

After the previous editing record is updated, the previous (unreceived) editing record is received from the server, the editing records are taken out in the designated order, and the local original DB is updated. In this process, some edits are determined to be valid and the local original DB is updated.

Finally, the editing record that was uploaded earlier is taken out, the invariant confirmation range is investigated, and the validity is determined. If it is determined to be invalid, the operator of this PC confirms the fact of invalidity and the reason for the invalidation, 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.

It is necessary for the operator of the PC to accurately know “whether or not the information entered by the user has become valid” and “in what circumstances it has become invalid”. When offline editing is performed in parallel DB access, whether or not the editing is effective is not immediate, and is determined at the next synchronization, so these pieces of information are extremely important. Even if the information becomes invalid, all the edit records are on the PC, and the validity judgment and update of the local original DB can all be seen inside this PC. Can be judged from the situation.

The main points of the present invention are listed as follows.
(Update 1) Each PC receives unedited edit records in order.
(Update 2) The local original DB is updated using the received editing records in the designated order.
(Edit 1) Each PC updates the local original DB and uploads this edit record to the server.
(Premise 1) The contents of the initial local original DB of each PC are the same.
(Premise 2) The content of the edit record used for updating the local original DB on each PC is the same.
(Premise 3) The order of editing records used for updating the local original DB in each PC is the same.
(Premise 4) The logic used for updating the local original DB is the same on each PC.

In the above description, updating of the global original DB is not described. In fact, there is no problem even if the global original DB exists only as an initial value of the local original DB. If an initial value DB can be created by a PC program, the server need not have an initial value. Since the local original DB of each PC is synchronized with each other, it can be said that it is synchronized with a virtual (non-existent) global original DB. Of course, in addition to the above procedure, there is actually a global original DB, which may be updated with editing information. If the local original DB of a certain PC is damaged, the global original DB may be copied or the local original DB of another PC may be copied. It is also possible to re-create the latest local original DB from the initial global original DB and all the editing records so far.

(Almost online operation)
In the present invention, the criteria for determining the validity of the edit record and the update procedure of the local original DB are not particularly defined, but it is generally considered common to determine that editing based on old information is invalid. Therefore, in order to minimize the possibility that the editing PC determines that the editing is invalid, the latest editing record is received immediately before editing, the local original DB is updated, and this latest local original is updated. It is preferable to edit the DB and immediately edit the edit record after editing. If updated frequently, the local original DB is always kept up-to-date, so it can be said that “almost online operation”.

(Almost offline operation)
However, when handling information that rarely conflicts with editing, editing is possible even if the time from updating the local original DB by (Update 1) and (Update 2) to editing up by (Edit 1) is increased. Is unlikely to be invalid. For example, in the case where a payment slip is input for each organization of a company, the record is corrected when an input error or a processing error is found, and even if it is corrected, it is often performed by a computer that inputs the record. In such a case, there is no problem with “almost offline operation” in which the period from update to edit-up is extremely long. Even if you can't connect to the Internet, you can enter payment slips slowly and upload them together when it is close to the settlement or inspection.

(Improvement-1) Expansion of contents of editing record “Edited contents” include “version setting range” and “invariant confirmation range” described in detail later in addition to the general edited contents and “edited version” described above. Can be included in the edited content. When setting a version in the DB part (s), it is necessary to indicate which part of the version is being handled, and this is the “version setting range”.

In addition to general editing contents, the editing version, version setting range, and invariant confirmation range are recorded in the editing contents, but the handling of these information becomes simple. However, it is not always necessary to record the editing contents. Even if they are recorded separately, it is sufficient if these correspondences can be grasped by other computers.

(Improved-2) Introduction of invariant confirmation range "Invariant confirmation range" is a range that affects this editing, and changing the value of information in this range indicates that this editing becomes meaningless. ing. The “invariant confirmation range” can be variously specified in accordance with the information handled by the DB, particularly the characteristics of the information to be edited, but it is natural to put the information to be edited in the “invariant confirmation range”. 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 is assumed.

(Improved-3) Edit record and its order The edit record to be recorded in the operation server and its order do not necessarily have to be the contents and the order in which the PC is up. If the edit records and the order thereof are the same for all PCs, the local original DB to which these edit records are applied synchronizes with the order of the edit records as a common time axis.

The server or the PC in charge of management work may analyze the contents of the editing record, and delete a portion that becomes invalid due to an error or a redundant portion (same as doing nothing after all). There is no problem even if an error edit record or redundant edit record is deleted and the edit record is deleted as a result. Even if the order of editing and recording is changed, if the order used for (update of local original DB) processing in all PCs is the same, the local original DB of each PC is synchronized using the order of editing and recording as a common time axis.

(Improvement-4) A unit for assigning an introductory version of the version setting range and managing editing does not have to be an actual DB. If a part closely related to the influence of information correction is identified and set as a “version setting range”, and a version is set for each, it becomes easy to manage editing and version transition for that range.

Since the setting of the version setting range depends on the structure and contents of information handled by the DB, it cannot be determined without such knowledge, but in the case of RDB, it is logically related to records, tables, and tables. A table group, a specific record group among them, an entire DB, and the like are assumed.

By replacing DB with the version setting range, the procedure described in this specification can be applied as it is. Note that there is no problem even if editing records for a plurality of version setting ranges are described together 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. In the medical information DB, a set of personal medical records is set as the setting of the version setting range. If one or more rows in the table are personal information, a version is set for this. 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” corresponding to the individual. The “invariant confirmation range” may be set appropriately in accordance with the correction contents, whether it is the entire personal record or limited to the corrected information (record in the case of RDB). If a table is configured for each personal information, a version is set for each table.

In addition to medical information, it can also be used to manage information such as social guarantees, bank accounts and loans for each individual. It can also be used to manage criminal information that seems to be edited by multiple departments. Furthermore, it is also convenient when handling personal information such as “Management of the Basic Resident Register in a developed form” where some data can be edited by the residents. As explained in “(Improved-8) Limitation of Defense Range of Local Original DB”, creating a local original DB for personal information in the range that can be read with the authority for each PC, only information within the scope of authority. Is sent to this PC, there is no risk of unauthorized information being hacked.

Note that if a particular PC (operator) does not need many of the editing records collected on the server, it is sufficient that the local original DB is synchronized with only a part of the global original DB. To cope with this, one method is to skip unnecessary editing records after all editing records are received by the PC. The amount of communication is reduced if the necessary editing records are extracted and sent for each PC on the server side. If unnecessary editing records are mixed, there is no problem if they are excluded by the processing on the PC side. If the edit records managed by the server are classified based on the version setting range recorded in the edit information, the edit records to be sent to the PC can be quickly determined.

(Improved-5) Version grant timing A version is assigned to the whole DB original (global original DB or local original DB) or to the version setting range. Can be selected according to

The version may be updated when the contents of the local original DB are actually updated, or the version may be updated every time an attempt is made to change the original DB in the change record regardless of whether there is a valid update.

(Improved-6) The time when the development server accepts editing as the version may be used as the version. The version described in this specification will be read as this reception time. Previously, the version was described as an order number for identifying a sequence, but there is no problem because the time also represents the order.

(Improved-7) The development PC with the version of the synchronous access time to the server acquires the time (from the server, etc.) that accesses the server and confirms whether there is an unreceived edit record, and uses that time as the version. A method is also possible. For each confirmation, a new time of the local original DB is set as a version even if there is no unreceived edit record. If there are unreceived editing records, these are received, the local original DB is updated using them, and this time is set as the version of the local original DB. Since the editing of the local original DB with 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.

(Improved-8) Limitation of Defensive Range of Local Original DB Assuming that the local original DB is synchronized with the whole (virtual or real) global original DB, the description is simple. However, it is more practical that the range handled by the local original DB is a part of the global original DB. In general, the entire DB is not limited to medical information, but as described above in “(Improvement-4) introduction of version setting range”, it is an aggregate of individual information. The local original DB of the patient's own computer only needs to have this patient information, and the local original DB of the doctor's computer need only have the information of the patient in charge. That is, the local original DB does not need to be synchronized with the entire global original DB, and it is sufficient if it is synchronized with a necessary part thereof. As a result, the size of the local original DB is reduced, and the synchronization (keeping the contents up to date) becomes light.

(Improved-9) A server (or PC) for managing the variation order of the edit record ordering is placed. The PC that created the edit record queries this server for the order and writes the specified order to the edit record. Even if the edit records themselves are directly transmitted between the PCs, the order written here is unique. Instead of the order, the time may be entered in the editing record and used as the order. In consideration of the occurrence of a time lag for each PC, it is necessary to devise such that a specific PC manages the time.

(Improvement-10) Temporary prohibition of editing If editing cannot be performed in parallel with other computers, such as changing the data structure of the DB itself, it is convenient to temporarily prohibit other editing. good. In the following, for the sake of explanation, it is assumed that a certain editing (X) is prohibited from parallel editing with this editing. In other words, the period from the start of X editing until the X editing is completed and uploaded to the server is defined as the “editing prohibition period” of another PC. After the X is uploaded to the server, the prohibition is canceled from the parallel DB editing on the local original DB after taking in the editing record (X) record.

One method is a method in which the server invalidates the editing that has been uploaded to the prohibited section. It is a reliable method that makes use of X editing and does not cause contradictions. However, the effort on the side of creating this invalidated edit is wasted.

Another way is to tell you that it is a prohibited zone. The PC that performs the editing X may be directly transmitted to another PC, or the PC that performs the editing X may be transmitted to the server and may be transmitted from the server to each PC.

The PC that performs editing X informs the server that editing of other PCs is prohibited at the time of requesting the server for the latest editing record before performing editing X. The server that requested the latest editing record to the server may be notified of the prohibition of editing from the server, or may be notified together with a response to an inquiry about an unreceived editing record.

In the case where “edit prohibition is notified from the server”, this PC does not perform editing even if the local original DB is updated. Then, the server requests the server for the latest editing record, and sends up to the editing record X. At the same time, the release of the prohibition of editing is notified. After updating the local original DB with the edit record X, this PC starts editing for this.

<Correspondence with claims at the time of filing>
Parallel editing in this specification means that a copy of all or part of information in a global original DB (real or virtual) (intuitively DB original) is stored in a local original DB (intuitively in a PC). It is held as “Duplicate DB”) and edited. Editing information on the duplicate DB held by each PC is exchanged by the PC to update each duplicate DB. The reason why the replicated DBs of each PC are synchronized is that each PC updates each replicated DB using the same editing information in the same order. This is expressed in claim 1. Claim 2 is an expression of claim 1 by an apparatus.

A process for confirming the validity of the edit record is added to the process D of the first aspect. Claim 4 shows that the concept of “invariant confirmation range” that affects editing is added to claim 3, and the validity of the edit record is confirmed using this concept. Claim 5 shows that the concept of the version of the duplicate DB is added to claim 3, and the validity of the edit record is confirmed using this. Claim 6 is the case where the version is designated as a part of information or a combination of information in the replication DB.

The seventh aspect is based on the fifth aspect, and is added to update the version of the duplicate DB even if the validity is denied. Claim 8 is a method based on claim 5 in which the server enters the date and time of the upload in the uploaded edit record, and the PC uses this as the version of the duplicate DB. A ninth aspect of the present invention is a method based on the fifth aspect, wherein the time when the PC accesses the server (from the server) is used as a version of the duplicate DB.

In server DB access, there is a problem that data cannot be accessed in a situation where communication with the server is impossible. Cases in which communication is impossible with a mobile object frequently occur, which greatly restricts DB operations. In so-called mission-critical operations such as disaster relief, medical care, and finance, business execution is required even in situations where communication is impossible, but this cannot be met.

Parallel DB editing solves this problem, but several problems have been pointed out in the method based on the cache technology.

In the present application, a local original DB synchronized with a virtual or real global original DB is created and used as a permanent cache. Then, the local original DB is synchronized with the global original DB when necessary, such as immediately before editing the local original DB. As a result, problems such as the overhead of the conventional method of creating a copy for each editing and the determination of the cache validity are solved.

In addition, it is difficult to detect that information operated by a PC in the past has been changed by the operation of another PC, but this full-scale "parallel DB access editing" makes it easy. It became possible to detect. Appropriate action can be taken after the operator carefully examines the information editing status. The invalidated data can be re-inputted, partly corrected and re-inputted, the latest data can be corrected, or the invalidated data can be accepted.

Furthermore, the object to be held and synchronized by the local original DB does not have to be the entire global original DB, but only a part of information necessary for the computer. For example, in the case of medical information, the local original DB of the patient computer holds only the medical information of the individual patient, and the local original DB of the doctor computer holds only the medical information of the patient in charge. This solves the problem of the appropriate amount of cache, which was a problem with the conventional method.

Advantages of performing processing such as “determination of validity of editing record” and “update of local original DB” on the PC instead of the server are as follows.
(1) If the necessary editing records and their order are taken in, communication with the server is unnecessary, and the response corresponding to the subsequent user operation is quickened.
(2) Since the process of updating the local original DB is performed on this PC, the range of information (records) affected by specific editing can be investigated in detail. Further, more detailed information can be displayed according to the operator's request.
(3) Generally, the computing power of individual computers is often surplus, and the processing is faster than placing processing on a server where processing load is concentrated. The response corresponding to the user's operation is accelerated due to the synergistic effect with the above (1).

In addition, by adjusting the update interval of the local original DB, it is possible to freely select from “almost online operation” to “almost online operation”. When handling information with a lot of editing access, it is sufficient to perform “almost online operation” that frequently updates the local original DB, and data is entered even if there is no correction or correction, such as payment slip input. When there are many cases that are performed by a computer, there is no problem in “almost offline operation” in which the update interval of the local original DB is extremely extended. There is no problem even if the editing is uploaded after the closing of accounts and inspections.

It is convenient for a plurality of PCs to select “almost online operation” or “almost online operation” depending on the circumstances, and to operate both in a mixed manner.

General computer configuration Relationship between PC and server The process of uploading the edits made to the local original DB to the server The process of receiving edit records from the server The process of updating the local original DB with the edit record Simplified example

0100 Calculator
0102 Communication device
0103 Arithmetic unit
0104 Main memory
0105 DB (database) in main storage
0106 secondary storage
0107 I / O device
0108 display device
0109 Bus
0110 communication network
0111 DB (database) in secondary storage
0201 PC
0202 Communication network such as the Internet
0203 server
0204 (PC) storage device
0205 (server) storage device
0206 Local original DB
0207 Global Early Original DB
0208 Editing record
0209 Work DB
0210 Editing record n
0210 Editing record n + 1
0211 Editing record
0213 Editing means
0214 Update means
0215 Transmission means
0216 Receiving means
0217 Transmission / reception management means
0218 Editing record 1
0219 Editing record m
0220 Transmission means
0221 Receiving means
0222 Transmission / reception management means
0301 Allocate edit memory (memory area)
0302 Identifies information to be edited in the local original DB
0303 Specify the version setting range to which this information belongs and enter it in the edit record
0304 Get version of this version setting range and fill in edit record
0305 Specify the invariant confirmation range corresponding to the information to be edited and enter it in the edit record
0306 Information that identifies the information to be edited and the contents of the edit are entered in the edit record
0307 Create a work DB that applies the above edits to the local original DB
0308 Send edit record to server
0401 Notify server of last edit record
0402 Receive a list of edit records since last time from server
0403 Receive edit record
0404 Put received edit record in unprocessed edit record list
0405 Queries editing prohibited
0501 Take edit record from unprocessed edit record list
0502 Determines whether this edit record is valid for the current local original DB from the invariant confirmation range and edit version
0503 Update local original DB
0504 Update local original DB version
0602 PC-A
0603 PC-B
0604 Initial DB
0605 Local original DB update (of PC-A)
0606 Local original DB update (of PC-B)
0608 Copy of record Z (PC-A)
0609 Copy of record Z (PC-B)
0610 Acquisition of global initial original DB (by PC-A)
0611 Acquisition of global initial original DB (by PC-B)
0612 Synchronization (by PC-A)
0613 Editing (by PC-A operator)
0614 Send edit (by PC-A). In other words, editing is up.
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.
0617 Synchronization (by PC-B)
0618 Editing (by PC-B operator)
0619 Send edit (by PC-B). In other words, editing is up.
Confirmation (notification) (to PC-B) and synchronization (by PC-B).
0622 Synchronization (by PC-B)
0623 Modification of PC-A record Z copy based on PC-B edit

The method of the present invention can be realized as a computer program. 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. When exchanging data with another computer, it connects to the communication network 0101 via the communication device 0102. 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. When 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. As a result, the computer is reconfigured into a collection of means for realizing the operation intended by the program developer.

In general, 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. However, normally, it is assumed that 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 FIG. 2, the DB is simply displayed as the DB in the storage devices 0204 and 0205.

The case where the edit records 0218 and 0219 are placed in the server 0203, the PC 0201 receives the edit record, and the local original DB 0206 of the PC is updated will be described with reference to FIG. A PC 0201 is connected to a server 0203 via a communication network 0202 such as the Internet. In general, there are a plurality of PCs, but only one is shown in FIG.

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. In response to the operator's instruction, the editing unit 0213 performs editing. At this time, the local original DB 0206 is not directly edited, and the editing result is 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 edit record 10218 and edit record m0219 columns. An edit version and the like are recorded in the edit record. If an edit version is sent to the server separately from the edit record, the server records their correspondence.

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 record n0210, edit record n + 12011, and edit record m0212 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.

FIG. 3 shows a process of uploading an edit record (that is, “edit record”) performed on the local original DB held by the PC to the server. First, “Reserve editing record (memory area)” 0301 is executed. “Identify editing target information in local original DB” 0302 and “Identify the version setting range to which this information belongs and enter it in the editing record” 0303. Furthermore, “Obtain version of this version setting range and fill in edit record” 0304, “Identify invariant confirmation range corresponding to information to be edited and fill in edit record” 0305, “Identify information to be edited Information and editing contents are entered in the edit record "0306. Then, “Create a work DB to which the above editing is applied in the local original DB” 0307 and “Send editing record to server” 0308.

FIG. 4 shows a process of receiving from the server the editing record for the local original DB and the order designated for them. First, “notify the server of the last edit record of the last time” 0401 and “receive a list of edit records after the previous time from the server” 0402. According to this list, “Receive edit record” 0403 and “Place received edit record in unprocessed edit record list” 0404. Finally, “inquire when editing is prohibited” 0405. Even when editing is prohibited, the means 0214 for updating the local original DB with the editing record received from the server in FIG. 5 is activated, but the editing of the local original DB 0206 by the editing means 0213 (and the procedure in FIG. 3) and the editing record to the server are performed. Do not send.

FIG. 5 shows the processing steps of the updating means 0214 for updating the local original DB with the edit record received from the server. “Retrieve edit record from unprocessed edit record list (list of edit record n0210, edit record n + 12011, edit record m0212)” 0501, “With the invariable confirmation range and edit version of this edit record, If it is valid, “Update local original DB” 0503 and “Update local original DB version” 0504. This is performed for all edit records in the unprocessed edit record list.

If the time when the server accepted this edit record is recorded as the edit version in the edit record, this is the version of the updated local original DB. When the date when the server is inquired about whether or not there is an unrecorded edit record is used as the version, the time is acquired from the server in the process of FIG. 4, and the time is acquired at the end of the process of FIG. Set as version.

The change in version in one embodiment is illustrated in FIG. The DB in FIG. 6 is an RDB, and the version setting range is the entire DB, the version is an integer, and the invariant confirmation range is only the edited record. The edit version at the time of editing this record is recorded as “record version” for each record, and the validity of the edit is confirmed using this.

The PC-A 0602 and the PC-B 0603 obtain the global initial original DB 0604 0610 and 0611, respectively, and use them as the local original DBs 0605 and 0606, respectively. Since the global initial original DB 0604 of the server is copied, the base version of both is 0. Thereafter, edits 1 to 6 are uploaded to the server 0601. This is an edit uploaded by PCs other than PC-A0602 and PC-B0603. In FIG. 2, PC-A 0602 accesses the server again, and obtains the latest editing order at that time 0612. At this time, since the edit 1 is taken in, the version of the local original DB 0605 becomes 1.

Now, let us say that the operator of the PC-A 0602 has edited the copy 0608 of the record Z in the local original DB 0605 0613. At this time, since the base version of the local original DB 0605 is 1, the record version of the edited “copy of record Z 0608” is set to 1. This edit result is uploaded to the server and recorded as 0614 and edit 7. Immediately after this, PC-A0602 acquires edit 6 from edit 2 that was uploaded after edit 1 (which has already been acquired), and confirms that up 0614 ahead of PC-A0602 has become edit 7. To do. Based on the “determination of editing validity” specified in advance, edits up to edit 7 are examined in order, and the local original DB 0605 is updated. Here, it is determined that edit 7 is valid, and the base version of the local original DB 0605 is 7.

On the other hand, the PC-B 0603 acquires from the server 0601 the edit 6 (latest as of this synchronization 0617) from the edit 1 and updates the local original DB 0606 to 6 as the base version. Thereafter, it is assumed that the operator of the PC-B 0603 edits “Replica 0609 of record Z” 0618. At this time, the record version of “duplicate record Z 0609” becomes 6, and is uploaded to the server as an edit and is recorded as 0619 and edit 8.

Thereafter, after the editing 9 is uploaded from another PC, the PC-A 0602 accesses the server 0601 and acquires editing 8 and editing 9 uploaded after editing 7 (already acquired) 0622. Then, edit 8 and edit 9 are sequentially applied to the local original DB 0608, “edit validity determination” is performed, and the local original DB 0608 is updated. Here, since edit 9 is reflected in the local original DB 0608, the base version of the manufactured DB 0608 becomes 9. At this point, the contents of the copy 0609 of the record Z edited by the PC-B0603 become valid in the local original DB0605 of the PC-A0602, and the contents of the duplicate 0608 of the record Z edited by the PC-A0602 become invalid. It becomes clear (by PC-A0602).

A database is placed on a server and a plurality of computers access it in general. However, there is a problem that editing is not possible unless the server is accessed. The present invention proposes a full-fledged “parallel DB editing” in which a computer permanently holds a replicated DB, so that a mobile object that frequently occurs in a case where connection to a server is impossible, rescue in the event of a disaster, It can be used for so-called mission critical tasks such as medical care and finance.

Claims (8)

A device (hereinafter referred to as “own device”) that retains a copy of the entire “real or virtual database” or a part thereof (hereinafter referred to as “self copy”) and executes an update of the “self copy”.
at least,
(A) means for creating edited content (hereinafter referred to as “self-edited content”) for the “self-replicated”;
(B1) for holding different one or more devices (hereinafter "other device") is the said "self-device", "all or part of the replication of the database" s (hereinafter "other replication") On the other hand, one or more edit contents created by the “other device” (hereinafter “other edit contents” ) ,
One or a plurality of the “self-editing contents” created by the means (A) are collectively referred to as “editing contents group” below.
When a device that collects the “edit contents” of the “edit contents group” is a “server”,
Means for transmitting the “self-editing content” from the “self-device” to the server after the “self-editing content” is created by the means (A);
(C1) means for receiving the “other editing content” from the server;
(D1) means for updating the “self-duplicate” by using the individual “edit contents” of the series of the “edit contents group” in order and using the “order”.
(E1) Information for identifying the “order” of the means (D1) and corresponding to each “edit content” of the “edit content group” is referred to as “individual order information”.
When the order of arrival of the individual “edit contents” at the server (hereinafter referred to as “order of arrival at the server”) is the “individual order information” corresponding to the individual “edit contents”,
Means for acquiring from the server at least the “order of arrival at the server” which is the “individual order information” for the “self-edited content”;
Have
Furthermore, the means (D1) determines the validity of the edited content, and updates the “self-replicated” with the edited content determined to be valid.
Self-device characterized by. A device (hereinafter referred to as “own device”) that retains a copy of the entire “real or virtual database” or a part thereof (hereinafter referred to as “self copy”) and executes an update of the “self copy”.
at least,
(A) means for creating edited content (hereinafter referred to as “self-edited content”) for the “self-replicated”;
(B1) for holding different one or more devices (hereinafter "other device") is the said "self-device", "all or part of the replication of the database" s (hereinafter "other replication") On the other hand, one or more edit contents created by the “other device” (hereinafter “other edit contents” ) ,
One or a plurality of the “self-editing contents” created by the means (A) are collectively referred to as “editing contents group” below.
When a device that collects the “edit contents” of the “edit contents group” is a “server”,
Means for transmitting the “self-editing content” from the “self-device” to the server after the “self-editing content” is created by the means (A);
(C1) means for receiving the “other editing content” from the server;
(D1) means for updating the “self-duplicate” by using the individual “edit contents” of the series of the “edit contents group” in order and using the “order”.
(E2) Information for specifying the “order” of the means (D1) and corresponding to each “edit content” of the “edit content group” is referred to as “individual order information”,
When the order set in the server (hereinafter referred to as “set order”) for each “edit content” collected in the server is the “individual order information”,
Means for acquiring from the server at least the “set order” which is the “individual order information” for the “self-editing content”;
Have
Furthermore, the means (D1) determines the validity of the edited content, and updates the “self-replicated” with the edited content determined to be valid.
Self-device characterized by. A device (hereinafter referred to as “own device”) that retains a copy of the entire “real or virtual database” or a part thereof (hereinafter referred to as “self copy”) and executes an update of the “self copy”.
at least,
(A) means for creating edited content (hereinafter referred to as “self-edited content”) for the “self-replicated”;
(B2) the different one or more devices (hereinafter "other device") is held as "own device", singular or "all or a part of the replication of the databases" more (hereinafter "other replication") On the other hand, one or more edit contents created by the “other device” (hereinafter “other edit contents” ) ,
One or a plurality of the “self-editing contents” created by the means (A) are collectively referred to as “editing contents group” below.
When the “edited content group” is collected and the device that passes the “edited content group” to the own device and another device is a “server”,
Means for transmitting the “self-editing content” from the “self-device” to the server after the “self-editing content” is created by the means (A);
(C1) means for receiving the “other editing content” from the server;
(D1) means for updating the “self-duplicate” by using the individual “edit contents” of the series of the “edit contents group” in order and using the “order”.
(E3) Information for specifying the “order” of the means (D1) and corresponding to each “edit content” of the “edit content group” is referred to as “individual order information”,
The order in which each of the “edit contents” arrives at the “own apparatus” (hereinafter, “order of arrival at the own apparatus”) is defined as the “individual order information” corresponding to each of the “edit contents”. When
Means for obtaining at least the “order of arrival at the own device” which is the “individual order information” for the “self-edited content” by receiving the “edited content group” from the server;
Have
Furthermore, the means (D1) determines the validity of the edited content, and updates the “self-replicated” with the edited content determined to be valid.
Self-device characterized by. A device (hereinafter referred to as “own device”) that retains a copy of the entire “real or virtual database” or a part thereof (hereinafter referred to as “self copy”) and executes an update of the “self copy”.
at least,
(A) means for creating edited content (hereinafter referred to as “self-edited content”) for the “self-replicated”;
(B3) means for transmitting the “self-editing content” from the “self-device” to a device outside the “self-device” after the self-editing content is created by the means (A);
(C2) said different one or more devices (hereinafter "other device") is held as "own device", singular or "all or a part of the replication of the databases" more (hereinafter "other replication") On the other hand, when one or more edit contents created by the “other device” are “other edit contents”,
Means for receiving the “other editing content” from a device external to the “own device”;
(D2) When the “other editing contents” and one or more “self-editing contents” created by the means (A) are combined into an “editing content group”,
Means for updating the “self-duplicate” by using each of the “edit contents” of the series of “edit contents” in the “order”.
(E4) Information for specifying the “order” of the means (D2) and corresponding to each “edit content” of the “edit content group” is referred to as “individual order information”.
When the order number issued by the device that issues the order number (hereinafter referred to as “server”) to each “edit content” is the “individual order information” corresponding to each “edit content”,
Means for acquiring from the server at least the “order number” that is the “individual order information” for the “self-editing content”;
Have
Further, the means (D2) determines the validity of the edited content, and updates the “self-replicated” with the edited content determined to be valid.
Self-device characterized by. It is a program for causing a computer (hereinafter referred to as “self device”) to update a copy of the “real or virtual database” recorded on a recording medium or a part thereof (hereinafter referred to as “self replica”). And (A) creating the edited content (hereinafter “self-edited content”) for the “self-replicated”,
(B1) for holding different one or more devices (hereinafter "other device") is the said "self-device", "all or part of the replication of the database" s (hereinafter "other replication") On the other hand, one or more edit contents created by the “other device” (hereinafter “other edit contents” ) ,
One or a plurality of the “self-editing contents” created in the step (A) are collectively referred to as an “editing contents group” below.
When a device that collects the “edit contents” of the “edit contents group” is a “server”,
A step of transmitting the “self-editing content” from the “self-device” to the server after the “self-editing content” is created by the step (A);
(C1) receiving the “other editing content” from the server;
(D1) updating the “self-duplicate” by using the individual “edit contents” of the series of “edit contents group” in order, using the “order”.
(E1) Information for specifying the “order” in step (D1), and information corresponding to each “edit content” in the “edit content group” is referred to as “individual order information”.
When the order of arrival of the individual “edit contents” at the server (hereinafter referred to as “order of arrival at the server”) is the “individual order information” corresponding to the individual “edit contents”,
At least obtaining the “order of arrival at the server” which is the “individual order information” for the “self-edited content” from the server;
Have
Further, in step (D1), the validity of the edited content is determined, and the “self-replicated” is updated with the edited content determined to be valid.
A program characterized by It is a program for causing a computer (hereinafter referred to as “self device”) to update a copy of the “real or virtual database” recorded on a recording medium or a part thereof (hereinafter referred to as “self replica”). And (A) creating the edited content (hereinafter “self-edited content”) for the “self-replicated”,
(B1) for holding different one or more devices (hereinafter "other device") is the said "self-device", "all or part of the replication of the database" s (hereinafter "other replication") On the other hand, one or more edit contents created by the “other device” (hereinafter “other edit contents” ) ,
One or a plurality of the “self-editing contents” created in the step (A) are collectively referred to as an “editing contents group” below.
When a device that collects the “edit contents” of the “edit contents group” is a “server”,
A step of transmitting the “self-editing content” from the “self-device” to the server after the “self-editing content” is created by the step (A);
(C1) receiving the “other editing content” from the server;
(D1) updating the “self-duplicate” by using the individual “edit contents” of the series of “edit contents group” in order, using the “order”.
(E2) Information for specifying the “order” in the step (D1), and information corresponding to each “edit content” in the “edit content group” is referred to as “individual order information”.
When the order set in the server (hereinafter referred to as “set order”) for each “edit content” collected in the server is the “individual order information”,
At least obtaining the “set order” which is the “individual order information” for the “self-editing content” from the server;
Have
Further, in step (D1), the validity of the edited content is determined, and the “self-replicated” is updated with the edited content determined to be valid.
A program characterized by It is a program for causing a computer (hereinafter referred to as “self device”) to update a copy of the “real or virtual database” recorded on a recording medium or a part thereof (hereinafter referred to as “self replica”). And (A) creating the edited content (hereinafter “self-edited content”) for the “self-replicated”,
(B2) the different one or more devices (hereinafter "other device") is held as "own device", singular or "all or a part of the replication of the databases" more (hereinafter "other replication") On the other hand, one or more edit contents created by the “other device” (hereinafter “other edit contents” ) ,
One or a plurality of the “self-editing contents” created in the step (A) are collectively referred to as an “editing contents group” below.
When the “edited content group” is collected and the device that passes the “edited content group” to the own device and another device is a “server”,
A step of transmitting the “self-editing content” from the “self-device” to the server after the “self-editing content” is created by the step (A);
(C1) receiving the “other editing content” from the server;
(D1) updating the “self-duplicate” by using the individual “edit contents” of the series of “edit contents group” in order, using the “order”.
(E3) Information for specifying the “order” in step (D1), and information corresponding to each “edit content” in the “edit content group” is referred to as “individual order information”.
The order in which each of the “edit contents” arrives at the “own apparatus” (hereinafter, “order of arrival at the own apparatus”) is defined as the “individual order information” corresponding to each of the “edit contents”. When
Obtaining at least the “order of arrival at the own device”, which is the “individual order information” for the “self-edited content”, by receiving the “edited content group” from the server;
Have
Further, in step (D1), the validity of the edited content is determined, and the “self-replicated” is updated with the edited content determined to be valid.
A program characterized by It is a program for causing a computer (hereinafter referred to as “self device”) to update a copy of the “real or virtual database” recorded on a recording medium or a part thereof (hereinafter referred to as “self replica”). And (A) creating the edited content (hereinafter “self-edited content”) for the “self-replicated”,
(B3) After self-editing content is created in step (A),
Transmitting the “self-editing content” from the “own device” to a device external to the “own device”;
(C2) said different one or more devices (hereinafter "other device") is held as "own device", singular or "all or a part of the replication of the databases" more (hereinafter "other replication") On the other hand, when one or more edit contents created by the “other device” are “other edit contents”,
Receiving the “other editing content” from a device external to the “own device”;
(D2) When the “other editing contents” and one or more “self-editing contents” created in step (A) are combined into an “editing content group”,
Updating the “self-duplicate” by using each of the “edited contents” of the “edited content group” in the “order” in a series of ordered
(E4) Information for specifying the “order” in step (D2), and information corresponding to each “edit content” in the “edit content group” is referred to as “individual order information”.
When the order number issued by the device that issues the order number (hereinafter referred to as “server”) to each “edit content” is the “individual order information” corresponding to each “edit content”,
At least obtaining the “order number” that is the “individual order information” for the “self-editing content” from the server;
Have
Further, in step (D2), the validity of the edited content is determined, and the “self-replicated” is updated with the edited content determined to be valid.
A program characterized by

Images