US20110082833A1

US20110082833A1 - Database parallel editing method

Info

Publication number: US20110082833A1
Application number: US12/864,872
Authority: US
Inventors: Kunio Kamimura
Original assignee: Individual
Current assignee: Individual
Priority date: 2007-06-06
Filing date: 2009-06-03
Publication date: 2011-04-07
Also published as: CN102216910A; US20100198789A1; CN101765831B; CN101765831A; WO2008149552A1; US9678996B2; JPWO2008149552A1; JP4573277B2; US20130226886A1; US20110161292A1; CN102216910B

Abstract

Conventionally and generally, a plurality of computers access a database provided in a server. According to the inventions, generally-called full-fledged “parallel DB edit” using computers permanently holding duplicate DBs is presented. Computers exchange edit information on the duplicate DBs, and the duplicate DBs of the computers synchronize with one another. Each of all the relevant PCs takes out the local-edit records in the other PCs in a unique order (such as the order of arrival at the server) and updates the local original DB thereof. The edit information including the same contents is processed in the same order with the same logic, and then the local original DBs are updated. Therefore, the resultant local original DBs of the PCs also synchronize with one another. The synchronization is established not along with real time axis but along the common time axis which is the order of edit records. As a result, “substantially on-line operation” in which edit records are frequently taken in and updated and “substantially off-line operation” involving long update cycles can be mixed-ly carried out.

Description

TECHNICAL FIELD

The present invention realizes parallel edit to database (hereinafter “DB” and “parallel DB edit” respectively).

BACKGROUND ART

There are typical operation types of DB.
“Single DB access” is an operation which operates DB only by one computer. Since only this computer can perform edit to DB, access competition is easily avoided. But, it is not suitable for an operation in which plural computers to access a DB.
“DB access by server” is an operation, in which terminal computers (hereinafter “PCs”) access a server computer (hereinafter “server”) that manages DB. Each PC accesses DB through procedure of the server. Since only one PC accesses DB directly, it is easy to prevent access competitions. Pessimistic cursor (Non-patent literature 1) and transaction lock (Non-patent literature 2) are used.
“Power-up newspaper sales”, which was developed under a control of the author, only permits parallel accesses of reading. “Editorial right” should be acquired before edit to a PC, in this system. And only one PC edits at a time. This is also a lock.
But, if it is impossible to communicate to the server, it is impossible to access data. It is also impossible to get or release a lock. It will be a big restriction, since communications are frequently impossible for mobile devices. It is impossible to realize a request of continuations of mission critical tasks, such as medical and financial activities and relief at the time of a disaster. Even if communications are possible, inferior communications environment is insufficient for practical usage, because of extremely long response (that may be a result of re-transmissions and so on).
By the art of cache which creates copies for temporal working, it is tried to increase efficiency of procedure and communications. By ADO.NET of Microsoft, PC makes a copy of data (that is necessary for the present work) from server, cuts connections to the server and performs edit. After the edit, PC connects to the server again and sends results of the edit to the server. If target information of the edit were already changed by other terminal computers, the later (this) results of edit are judged to be invalid. It is possible to interpret it as “when a lock failed as a result, the edit was judged invalid”. It is a kind of editing lock. This is called “Optimistic concurrency control” (Non-patent literature 3 and Non-patent literature 4). However, there might be inconvenience, at some occasions. That is as follows;
(1) Since a copy is created for every edit, the copying procedure and communications to the server are excessive work (p 19 of Non-patent literature 1). For lessening them, it is necessary to restrict the range of the copy. However, it requires full knowledge of structure of the target (by the application program) information.
(2) It is difficult to estimate that “information of cache is valid till when”. If amount of cache is lessened in order to increase efficiency of copy, a possibility that the copy will be used for the next edit is lessened. Large volume of cache is also a problem. Even if a portion of cache was edited, “optimistic concurrency control” makes this cache invalid.
(3) It is difficult to detect that “information operated (input, updated, deleted) by a PC is amended (deleted, re-updated, re-input) by other PCs”. This problem is common to “DB access by server” and “Cache”. Result of judgment about validity of edit (by this PC) becomes clear at the time of the “sending up”. But, it is difficult to timely detect the changing of information that was input in the past and judged once effective at the time.
Other investigations are shown below. Non-patent literature 5 is a invention about file cache. When a collision (that is “competition” of the present invention) of among edits is detected, edit will be simply refused (10th line of lower right of p. 7 of Non-patent literature 5) and this is recorded. Patent document 1 (“means of resolution” and paragraph 36) shows the following. When collisions of edits to DB are detected, DB (of server) that was correctly updated is sent in. In patent document 2, edit of later time is judged valid. In patent document 1, edit of more early time is judged valid. Neither of them resolves the above problem.
Patent document 3 is an invention about conditions of starting synchronization of database. It describes synchronization method that “synchronizations are performed by changing editorial information”. This is merely a general concept of synchronization.
Patent document 4 is an invention of which purpose is to keep all data of edit when competition of edit occurs. Original is updated only when there is no competition. Purpose and contents (of this document) differ from the present invention. Although Patent document 5, 6, 7, 8, and 9 were investigated, all differ from the present invention.

[Patent document 1] Patent application (JP) H9-91184, A
[Patent document 2] Patent application (JP) 2004-13867, A
[Patent document 3] Patent application (JP) 2004-86800, A
[Patent document 4] Patent application (JP) 2006-284998, A
[Patent document 5] Patent application (JP) H11-161535, A
[Patent document 6] Patent application (JP) application document 2005-503606, A
[Patent document 7] Patent application (JP) 2005-508050, A
[Patent document 8] Patent application (JP) H8-16447, A
[Patent document 9] Patent application (JP) 2000-501532, A
[Non-patent literature 1] William R. Vaughn, Translated by Top Studio, Yukio Ito as editorial supervision “Windows™, database programming”, ADO.NET Specialization lecture Volume VB.NET, 4 Apr. 2003 (First Edition), SHOEISHA.
[Non-patent literature 2] C&R Laboratory, “Super illustration: SQL handbook”, (First Edition), 12, Aug., 2005
[Non-patent literature 3] MSDN subscriptions library, “Outline of, data concurrency control on AD.NET”, January 2007, (Disk File URL: second-help://MS.MSDNQTR.v80. ja/MS.MSDN.v80/MS.VisualStudio.v80.ja/dv_raddata/html/d5293 098-4a88-4110-abd2-34d9e6661664.htm))
[Non-patent literature 4] MSDN subscriptions library, “Tutorial: A process of a concurrency exception”, January 2007, (Disk File URL: ms-help://MS.MSDNQTR.v80. ja/MS.MSDN.v80/MS.VisualStudio.v80.ja/dv_raddata/html/73ee9 759-0a90-48a9-bf7b-9d6fc17bff93.htm)
[Non-patent literature 5] “A World-wide Distributed File System SKINNY”, IPSJ SIG Notes 95-S-70-1, (Academic Publication IPSJ SIG Notes Vol. 95, No. 79 ISSN 0919-6072

DESCRIPTION OF THE INVENTION

Problems to be solved by the Invention

Full-fledged parallel DB access is clarified. Problems of conventional parallel DB edit based on cache are solved.

Means for Solving the Problem

The present invention is explained using the following examples.

(1) Preparation

Plural PCs have “duplicate DB”s (hereinafter “Local-original-DB”s), which are copy of initial state of the original DB (hereinafter “Global-original-DB”). These local-original-DBs have initials of ordinal numbers which identify versions that can be used to identify turns of their updating. It is possible to judge validity of editorial contents by these versions.

(2) Local Edit

Each PC performs local edit to each local-original-DB. Before the edit, a copy of local-original-DB for temporal editing work is created. The edit is performed to this copy. Further at the time of edit, a set of “edit records”, which records contents of editing work, is created. This set of “edit records” includes at least “contents of the editing work”. In addition to this, the “edited version” may be included.
“Contents of editing work” are general editorial contents. For example, “what information was changed how”, “what information was added”, “what information was deleted”, and so on. “Edited version” is a version of local-original-DB, which was target of the edit. Strictly saying, it (“edited version”) is a version of the local-original-DB, which was the original of “copy to be target of the edit”.

(3) Sending “Edit Records” to Server

Each PC transmits “edit records” to server. When “edit records” and “edited version” are recorded separately, “edited version” with information indicating related “edit records” is also sent. Simple and realistic way is a operation, in which “edit records” includes “edited version.

(4) Receiving “Edit Records” by Server

The server records sets of “edit records” that arrived from PCs, and their turns of arriving.
(5) Receiving “Edit Records” from Server
PC asks the server for sending “edit records” that are not yet received. And PC receives them, and their turns by which they arrived to the server. If “edited version” is specified to “edit records”, PC also receives this.

(6) Renewal of Local-Original-DB

PC takes out sets of “edit records” by turns specified to them, judges validity of them, and tries to update the local-original-DB by contents of them. If version has been set, version of local-original-DB is updated.
All PCs have same initial local-original-DBs. Each PC takes out sets of “edit records” in their turns (by which they arrived to the server), and updates each local-original-DB. Each local-original-DB is updated, using same edit information, in same order, by same procedure logic. Each local-original-DB will be same as results.
This mechanism enables that “each local-original-DB of PC synchronizes each other, without updating global-original-DB of server”.
Main point is that “unique turn is attached to each set of edit records created by each PC”. Though turns (by which they were sent up to the server) are used here, it is possible to change these turns or to set other turns by another method. It is possible to change turns (by which they were sent up to the server), by another criteria (for example, priorities assigned to operators, and so on). It is sufficient, if “all PCs use same turns, by which each PC takes out and updates each local-original-DB”.
For example, another method is the following. Turn (or time) of a set of “edit records” is determined by server or a specified PC, and is notified (to a PC that creates or is holding the “edit records”). PC (that creates or is holding the “edit records”) writes this turn into the “edit records” that will be exchanged among them. It is sufficient, if “all PCs use same turns, by which each PC takes out and updates each local-original-DB”.
Since each PC updates reach duplicate DB at each convenient occasion, progresses of updating of local-original-DB of PCs vary in real time. However, local-original-DBs are in same status, if they were at just after updating by a specific “edit records”. That is, each local-original-DB of any PC synchronizes each other on common axis that are turns assigned to sets of “edit records”.
Here, all PCs should have same “criteria of judging validity” and same “procedure of updating local-original-DB”. However, there is no restriction to these procedures, if they are same. Each set of “edit records” is judged by same criteria, and all or some of them are judged valid or invalid. They are used to update local-original-DB in same manner. Then, each local-original-DB of any PC synchronizes each other on common axis that are turns assigned to sets of “edit records”.
A series of operations of a PC are explained. We assume that this PC received “edit records” of the latest from server and updated local-original-DB. This PC performs an editing work to this local-original-DB, and sends up the “edit records”. During this editing work, there is a possibility that another computer sent “edit records” to the server.
After the sending up of the previous et of “edit records”, sets of “edit records” (which are not yet received till then) are received from server. They are taken out by the specified turns and are used to try updating the local-original-DB.
Finally, set of “edit records” that was sent up previously is taken out, and is judged about its validity, by investigating its “no-change range to be confirmed”. When it is judged invalid, operator of this PC confirms the fact and the reasons, and tries to edit on the latest information again if necessary. If there are records of the previous input, it is easy to input them again.
An operator of PC needs to know correctly, about “whether information inputted by him became valid or not” and “in what situation the information became invalid”. This information is very important, because, “when offline edit is carried out in parallel DB access, the answer to whether edit is effective cannot be obtained instantly. It becomes clear at the time of next synchronization.” Even when information becomes invalid, all can be seen in PC, because all the sets of “edit records” are in this PC. “Process of judging the validity” and “situation of updating of local-original-DB” can be seen inside this PC. From this situation, it is possible to determine whether information should be input again, or should be abandoned.
The followings are itemized main points of the present invention.
(Updating 1) Each PC receives sets of “edit records” (that are not yet received) in order.
(Updating 2) Received sets of “edit records” are taken out by their specified turns and are used for updating local-original-DB.
(Edit 1) Each PC updates local-original-DB. A set of “edit records” of this updating will be sent up to server.
(Premise 1) The contents of initial “local-original-DB” of each PC are the same.
(Premise 2) “Edit records” that is used for updating of local-original-DB by each PC are the same.
(Premise 3) Turns assigned to sets of “edit records” used for updating of local-original-DB by each PC are the same.
(Premise 4) Each PC uses same logic for updating local-original-DB.
The above explanation did not explain about updating of global-original-DB. Even if global-original-DB exists only as an initial of local-original-DB, there is no problem. If a program of PC can make initial DB, server does not need to have initial. Each local-original-DB of each PC synchronizes mutually. Thus, we can say that each local-original-DB synchronizes to virtual (not existing) global-original-DB. Of course global-original-DB can exist actually. Global-original-DB will be updated by edit information. When local-original-DB of a certain PC was damaged, this PC can make copy from global-original-DB or from local-original-DB of any other PC. It is also possible to re-create newest local-original-DB, from initial global-original-DB and all “edit records” till then.

(Substantially On-Line Operation)

The present invention does not specify details of criteria for judging validity of “edit records”, nor details of updating procedure of local-original-DB″. However, it is natural to decide that edits based on old information are invalid. For lessening a possibility of edit of PC to be judged invalid, this PC will act as follows;
It receives “edit records” to the latest, before the editing work. Next it updates local-original-DB. It edits the latest local-original-DB. Finally, it sends up the “edit records”, immediately after the edit.
If updated frequently, local-original-DB will always be maintained at the latest state. It can be called “substantially on-line operation”.

(Substantially Off-Line Operation)

Suppose that information of rare competition of edit is treated. There is very small possibility that “edit to be judged invalid”, even if time from “updating local-original-DB by (Updating 1) and (Updating 2)” to “sending up of edit by (Edit 1)” is very long. For example, when each organization of a company inputs debit slips, these records will be modified only if mistakes of input or handling are found. Most of these modifications will be done at the PC that input these records. In such cases, the substantially off-line operation (that has long period from “updating” to “sending up recorded editing contents”) has very few problems. Even if connection to Internet is impossible, debit slips can be inputted slowly. It is enough to send them up collectively, becoming near the settlement or inspections.

(Improvement-1) Expansion of Inclusions of “Edit Records”

“Edit records” can include general “editorial contents” and “edited versions”, which were mentioned previously, and furthermore can include “range of version control” and “no-change range to be confirmed”, which are explained in detail later. When setting versions to (one or plural) parts of DB, there are necessity to show “what version is treated” and “what part is corresponding to this version”. “Range of version control” shows this.
If “edit records” include general editorial contents and further include “edited version”, “range of version control” and “no-change range to be confirmed”, they can be handled in a simple way. However, they are not necessarily included in “edit records”. When they are recorded separately, correspondences among them should be grasped by other PCs.

(Improvement-2) Introduction of “No-Change Range to be Confirmed”

“No-change range to be confirmed” is a range of affecting this edit. If information on this range has been changed, this means that “this edit becomes meaningless”. Various settings of “no-change range to be confirmed” are possible, depending on information treated by DB, especially depending on characteristics of information that is a target of edit. It is natural that “no-change range to be confirmed” includes information of target of edit. For relational DB (hereinafter, “RDB”), assumed are target table to be edited, tables logically related to the table to be edited, some records in them, or whole of DB.

(Improvement-3) Manipulation of “Edit Records” and Turn Assigned

There is no necessity that “edit records” and a turn assigned to each set of “edit records” should be the original contents at the time that they were sent up. If all PCs use same sets of “edit records” and same turns that are assigned to them, each local-original-DB (to which these “edit records” were applied) synchronizes each other on common axis that are turns assigned to sets of “edit records”.
Server or PC which performs administrative tasks may analyze “edit records” and delete “portions which are repealed because of errors” or “redundant portions which perform nothing after all”. There is no problem, even if a whole set of “edit records” is deleted by deleting portions of errors or redundant portions. Suppose that, turns (assigned to sets of “edit records”) were changed. If a sequence (by which these sets will be used for updating each local-original-DB) is same at all PCs, local-original-DB of each PC synchronizes each other on common axis that are turns assigned to sets of “edit records”.
There is no necessity that a unit, which is assigned a version and is managed about edit, should be actual DB. If “range of version control” is set to a portion (in which influence of updating is closely related) and version is assigned to each portion, edits and version transition will be easily managed.
Set up of “range of version control” depends on structure and contents of information treated by DB, and needs knowledge of them. For “RDB”, assumed are records, tables, a group of tables logically related to the table, some specified record among them, or whole of DB.
By reading DB as “range of version control”, processes already explained in this specification are applicable. It is sufficient, if “editorial contents”, “edited version”, “no-change range to be confirmed” are recorded corresponding to each “range of version control”.
For DB of medical information, a lump of individual medical records in DB of medical information can be “range of version control”. If one or a few lines of table are information for an individual, a version is set up to them. DB contains many sets of personal information. A version is set up to each of them. “Edit records” can include single or plural sets of “editorial contents”, “edited version” and “no-change range to be confirmed”. Each set is corresponding to each individual. “No-change range to be confirmed” can be set up appropriately according to the contents of updating. For example, it is set up to all records of an individual or to a information (that is a record, when the DB is RDB) updated. If each table is constituted information of individual, version can be set up for each table.
It can be used for managing information of individual, not only medical information but also social security, bank account, loan, and so on. It can also be used for management of offender information, which may be edited by plural sections. It is useful for handling individual information, such as “developed management of resident registration”, at which residents can edit some parts of their data by themselves. Local-original-DB can be created only for limited portion of personal information that is permitted by the authority of each PC, as explained in “(Improvement-8) Limitation of range of local-original-DB” later. And, only information within the limits on the authority is sent to each PC. Thus, there is no fear that hacked is information beyond the authority,
When many sets of “edit records” gathered in server are not necessary for (an operator of) specific PC, it is sufficient that the local-original-DB synchronizes with only a part of global-original-DB. One implementation for this is a method skipping un-necessary “edit records”, after receiving all “edit records”. If server picks up “edit records” necessary for each PC and sends them to PC, communication volume will be decreased. When some unnecessary “edit records” are included, there is no problem if they are excluded by procedure of PC. If “edit records” (managed by server) were classified by “range of version control” included in edit information, listing up of “edit records” (which should be sent to PC) can be judged quickly.

(Improvement-5) Timing of Setting Version

Version is set up to whole of the original DB (global-original-DB or local-original-DB) or to “range of version control”. Method of setting up them can be selected according to characteristic of information treated, or convenience of operation.
A version may be updated when the contents of local-original-DB are actually updated. Or, a version may be updated, whenever the original DB is tried to be updated by each “edit records”. It does not depend on existence of valid updating.
(Improvement-6) Development: Reception Time of Edit by Server is used as a Version
Reception time of edit by server can be used as a version. “Version” that is explained in this specification will be read as reception time. Previously, version was explained as an ordinal number that identifies a turn in a sequence. There is no problem because time is also an original number.

(Improvement-7) Development: Access Time for Synchronization to Server is Used as a Version

From server, obtained is the time, at which the PC accessed server and confirmed existence of “edit records” that had not yet been received. This time can be used as a version. At each confirmation, this time is set as version of local-original-DB, even if there are no un-received “edit records”. If there are sets of “edit records” that are not yet received, PC receives them, updates local-original-DB and sets up “this time” as a version of the local-original-DB. Since priority is given to an editing work to local-original-DB with newer synchronization access, this rule is easy to be understood and can be convinced, by persons who operate one DB by competition.
It is simple to explain, if we assume that local-original-DB synchronizes with whole of (virtual or existing) global-original-DB. However, it is more practical that local-original-DB covers only some portion of global-original-DB. Although not only medical information but whole DB is generally huge, DB is an aggregate of personal information, as explained in “(Improvement-4) Introduction of range of version control”. Local-original-DB of a patient's computer should have only this patient's information. Local-original-DB of a doctor's computer should have only the information of patients in charge. That is, there is no necessity that local-original-DB synchronizes to whole of global-original-DB. It is sufficient that local-original-DB synchronizes to some portions that are necessary for the PC. Thus, size of local-original-DB becomes small and the operation of synchronization (that maintains contents to the newest) becomes light.

(Improvement-9) A Variation on Assigning Turns to Sets of “Edit Records”

Server (or PC) that manages turn will be introduced. PC which created a set of “edit records” asks a turn to this server and writes assigned turn into the set. Even if sets of “edit records” are exchanged among PCs directly, turns included in (written into) these sets are unique. Time can be written into a set of this “edit records”, instead of the turn. Needed is such a plan in which a specified PC manages time, against time difference among PCs.

(Improvement-10) Temporary Prohibition of Edit

It is convenient forbidding temporarily other edits, if parallel editing work by other computer is impossible, such as a case in which data structure of DB will be changed. For explanation, assumed is the following situation: There is an edit (X). Parallel edits (to this edit) are prohibited. That is, editing work by other PC is prohibited from “the start of edit (X)” to “sending up to server after completing the edit (X)”. After X was sent, prohibition of parallel edit is canceled, from edit to local-original-DB that is updated by received “edit records (X)”.
One is a method repealing (by server) edits sent up in this prohibition period. This is a positive way, by which edit X is employed efficiently and makes no inconsistency. However, labor for making edits that are repealed, becomes useless.
Another is a method telling prohibition period. PC of edit X can directly notify other PCs, or notify server that notifies other PCs.
PC which performs edit X tells prohibition of edits by other PCs to server, before performing edit X, at a time of requiring the “latest edit records” to server. After that, server tells the “prohibition of edit” to other PCs which requires the “latest edit records”. Or, server tells it with response to inquiry of un-received “edit records”, etc.
After prohibition of edit was notified from server, PC does not perform editing work, though this PC can update local-original-DB. And, PC requests the latest “edit records” to server, and receives sets of “edit records” to X. PC updates local-original-DB by “edit records X”. After that, this PC starts editing work.
<Correspondence with Claims of the Original Submission>
“Parallel edit” of this specification is the following, “PC keeps and edits a local-original-DB inside. This local-original-DB (intuitively “duplicate DB”) is a copy of some parts of or whole of (virtual or existing) global-original-DB (intuitively “the original DB”). Edit information to duplicate DB kept by each PC is exchanged among PCs. Each PC updates each duplicate DB. Duplicated DB of each PC synchronizes each other, because each PC uses same edit information, in same sequence and updates each duplicate DB. Claim 1 expresses this. Claim 2 expresses Claim 1 as an apparatus.
At Claim 3, a procedure confirming validity of “edit records” was added to the process D of Claim 1. At Claim 4, a concept of “no-change range to be confirmed” was added to Claim 3. By this concept, “procedure of confirming validity of edit records is performed. At Claim 5, a concept of “version of duplicate DB” was added to Claim 3. By this concept, “procedure of confirming validity of edit records is performed. Claim 6 is a case, in which a version is set up to a “part of information” or a “combination of information” of duplicate DB.
At “Claim 7”, a mechanism, by which version of duplicate DB is updated even if the validity is denied, is added to “Claim 5”. “Claim 8” is “Claim 5” with a process of setting a time as version of duplicate DB. By server, this time was written into “edit records” which was sent up. “Claim 9” is “Claim 5” with a process of setting a time as version of duplicate DB. This time is the time at which PC accessed the server. This time was given from server.

EFFECT OF THE INVENTION

“DB access by server” has a problem, that is, “data access is impossible when communication to server is impossible”. At mobile situation, communications are frequently impossible. This is a big restriction to DB operation. It is impossible to realize a request of continuations of mission critical tasks, such as medical and financial activities and relief at the time of a disaster.
Parallel DB edit solves this problem. But, pointed were several problems of a method based on cache technology.
The present invention creates local-original-DB (that will synchronize with virtual or existing global-original-DB) used as permanent cache. And local-original-DB will be synchronized to the global-original-DB, when required (at immediately before starting edit to local-original-DB, etc). This solves problems of conventional method of creating a copy for each edit. The problems are “excessive load”, “judging validity of cache” and so on.
When the conventional methods were used, it was difficult to detect that information operated by a PC is amended by other PCs. However, this full-fledged “parallel DB (access) edit” can detect it easily. After operator scrutinizes situation of edits, suitable action can be taken. Possible is to re-input data that became invalid, or to re-input partially updated data, or to accept the fact that the data became invalid.
There is no necessity that “object to be kept and synchronized by local-original-DB should be whole of the global-original-DB”. It is sufficient if “the object is a portion of information (of the DB) that is necessary for the computer”. There are examples of medical information. Local-original-DB of a patient's computer only has this patient's information. Local-original-DB of a doctor's computer only has the information of patients in charge. Thus, solved is an appropriate amount of cache that was a problem of the conventional methods.
Procedures, such as a procedure of judging validity of “edit records”, and a procedure of updating of local-original-DB, are performed by PC, not by the server. The followings are listed as the strong points of this mechanism.
(1) After receiving necessary sets of “edit records” and their turns, there is no need to communicate with the server. This makes quick responses to subsequent operations of a user.
(2) Procedure of updating local-original-DB is performed in PC. This PC can investigate range of information (records) affected by a specific edit in detail.
Further, this PC can show more detailed information responding to operator's request.
(3) Generally saying in many cases, each computer has unused capacities.
Procedures are performed more quickly than they are placed in the server to which processing loads are concentrated. This makes quick responses to operations by users, with synergistic effects of above (1).
We can choose freely from “substantially on-line operation” to “substantially off-line operation”, adjusting interval of updating of local-original-DB. “Substantially on-line operation” that updates local-original-DB frequently is good for a case in which information with much edit access is treated. If data updating is performed by a computer that initially input the original data (such as debit slips), or if data is not updated, “substantially off-line operation” can be used. This has no problem even if interval of updating of local-original-DB is extended extremely. There is no problem if these edits are sent up collectively, becoming near the settlement or inspections.
Each PC can choose “substantially off-line operation” or “substantially on-line operation” according to each situation. Possible is mixed operation in which both types of PCs exist simultaneously. It is a good point.

BRIEF EXPLANATION OF FIGURE

FIG. 1. General structure of a computer

FIG. 2. Relation among server and PC

FIG. 3. Process of sending up “edit records” that was performed to local-original-DB, to server

FIG. 4. Process of receiving “edit records” from server

FIG. 5. Process of updating local-original-DB by “edit records”

FIG. 6. Simplified example

DESCRIPTION OF NOTATIONS

0100 Computer
0102 Communication Unit
0103 Arithmetic Unit
0104 Main Memory Unit
0105 DB (database) in Main Memory Unit
0106 Secondary Memory
0107 Input/output Unit
0108 Monitor Unit
0109 Bus
0110 Communications Network
0111 DB (database) in Secondary Memory
0201 PC
0202 Communications Network such as Internet
0203 Server
0204 Memory Unit of PC
0205 Memory Unit of Server
0206 Local-original-DB
0207 Initial global-original-DB
0208 Edit records
0209 DB for temporal working
0210 “Edit records” n
0210 “Edit records” n+1
0211 “Edit records” m
0213 Means of editing
0214 Means of updating
0215 Means of sending
0216 Means of receiving
0217 Means of controlling sending and receiving
0218 “Edit records” 1
0219 “Edit records” m
0220 Means of sending
0221 Means of receiving
0222 Means of controlling sending and receiving
0301 Reserve memory area for “recording editorial contents”
0302 Specify editing target information in local-original-DB
0303 Specify a “range of version control” to which this “edit records” belongs, and write it into this “edit records”
0304 Fetch version of this “range of version control”, and write it into this “edit records”
0305 Specify “no-change range to be confirmed” corresponding to the editing target information, and write it into this “edit records”
0306 Write editorial contents and information specifying editing target information, into this “edit records”
0307 Create temporal working DB that was made by applying the editorial contents (mentioned above) to local-original-DB
0308 Send “edit records” to server
0401 Notify server the last “edit records” of the previous time
0402 Receive list of “set of edit records after the previous time”, from server
0403 Receive edit records
0404 Put received “edit records” into unsettled list of “edit records”
0405 Confirm whether it is under “no-editing status” or not
0501 Pick out an “edit records” from unsettled list of “edit records”
0502 Judge a validity of this “edit records” against the current local-original-DB, by this “no-change range to be confirmed” and “edited version”
0503 Update local-original-DB
0504 Update version of local-original-DB
0602 PC-A
0603 PC-B
0604 Initial DB
0605 Update local-original-DB of PC-A
0606 Update local-original-DB of PC-B
0608 Copy of record Z in PC-A
0609 Copy of record Z in PC-A
0610 Getting initial global-original-DB by PC-A
0611 Getting initial global-original-DB by PC-B
0612 Synchronization by PC-A
0613 Edit by operator of PC-A
0614 Sending “edit records” by PC-A. This is called “sending up edit records”
0616 Confirmation (notification to PC-A) and synchronization (by PC-A). Here (and at explanations of any other notations), synchronization is getting to the latest set of “edit records” and turns assigned to them.
0617 Synchronization (by PC-B)
0618 Edit by a operator of PC-B.
0619 Sending “edit records” by PC-B. This is called “sending up edit records”
0621 Confirmation (notification to PC-B) and synchronization (by PC-B)
0622 Synchronization by PC-B
0623 Modification on copy of record Z of PC-A by “edit records” by PC-B

BEST MODE OF CARRYING OUT THE INVENTION

The present invention can be implemented as a program of computer. FIG. 1 shows typical structure of computer 0101. Arithmetic Unit 0103, Main Memory Unit 0104, Secondary Memory 0106, Input/output Unit 0107, and Monitor Unit 0108 are connected by bus 0109. When exchanging data between other computers, it is connected to communication network 0101 via communication unit 0102. “Database” referred by each claim is DB 0111 in secondary memory 0106 or DB 0105 in main memory unit 0104.
Program recorded in secondary memory 0106 is loaded in main memory unit 0104 at invoking. Arithmetic unit 0103 works as instructed by the program. As a result, computer is reconfigured as an aggregate of means that are intended by the program developer.
After loading (some parts of or whole of) DB to main memory unit 0104, program handles DB in general cases. Parts (or whole) of DB 0111 in secondary memory 0106 will be loaded as DB 0105 in main memory 0104. Operations are performed to this DB 0105 and the editorial contents will be written into DB 0111 in secondary memory 9195. But usually, it is assumed that DB is in secondary memory 0106. At discussion, there is no distinction between it and DB 0105 loaded to main memory 0104. Thus, FIG. 2 simply shows DB in memory unit 0204, 0205.
PC 0201 receives sets of “edit records” 0218, 0219 (which were placed in server 0203), and updates Local-original-DB 0206. FIG. 2 explains this case. PC 0201 is connected to server 0203 via communications network such as Internet 0202. Though generally there are plural PCs, FIG. 2 shows one PC.
PC 0201 has memory unit 0204, in which local-original-DB 0206 is recorded. Initial of local-original-DB is a copy of initial global-original-DB 0207. “Means of editing” 0213 performs edit under instructions of an operator. At this time, local-original-DB 0206 does not be edited directly. Results of this edit will be temporal working DB 0209. Simultaneously, “edit records” 0208 will be created. This set of “edit records” contain “edited version”, which is a version that was set to the local-original-DB.
“Means of sending” 0215 sends “edit records” 0208 to server 0203 via communications network 0202. “Means of receiving” 0221 of server 0203 receives them, which are added to a sequence of “edit records” 1 (0218) and “edit records” m (0219). “Edit records” include “edited version”, and so on. If “edited version” is sent to server (aside from “edit records”), server records correspondence among them.
When PC 0201 tries to update local-original-DB 0206, PC at first asks server for sending “edit records” that are not yet received. After notification (by PC 0201) of the version of the last “edit records” received, “means of controlling sending and receiving” selects “edit records” that are after the notified version. And “means of sending” 0220 sends them from server. “Means of controlling sending and receiving” 0217 manages cooperation among receiving and sending by a PC. “Means of controlling sending and receiving” 0222 manages cooperation among receiving and sending by a server.
“Receiving means” 0216 of PC 0201 receives “edit records” n (0210), “edit records” n+1 (2011) and “edit records” m (0212), which will be recorded in memory unit 0204. “Updating means” 0214 takes out them in order of their turns, evaluates their validity, updates local-original-DB 0206 and updates its version.
FIG. 3 shows a process of sending up (to server) “records of edits” (namely, “edit records”) to local-original-DB that is held by PC. At first, “reserve memory area for recording editorial contents” 0301. Specify editing target information in local-original-DB (0302). Specify a “range of version control” to which this “edit records” belongs, and write it into this “edit records” (0303). Further, fetch version of this “range of version control”, and write it into this “edit records” (0304). Specify “no-change range to be confirmed” corresponding to the editing target information, and write it into this “edit records” (0305). Write “editorial contents” and “information specifying editing target information” into this “edit records” (0306). And, create temporal working DB that was made by applying the editorial contents (mentioned above) to local-original-DB (0307). Send “edit records” to server (0308).
FIG. 4 shows process of receiving sets of “edit records” and “turns that were assigned to them”, from server. At first, notify server the last “edit records” of the previous time (0401). From the server, receive a list of “edit records” that are after the previous time (0402). According to this list, receive “edit records” (0403), and put received “edit records” to unsettled list of “edit records” (0404). Finally, confirm whether it is under “no-editing status” or not (0405). Even if it is under “no-editing status”, “means of updating” 0214 updates (as shown in FIG. 5) local-original-DB by “edit records” that are received from server. However, “edit of local-original-DB 0206 by editing means 0213 (and procedure of FIG. 3)” and “sending edit records to server” will not be invoked.
FIG. 5 shows process of “means of updating” 0214 that updates local-original-DB by “edit records” received from server. Pick out an “edit records” from unsettled list of “edit records”, that is a list of “edit records” n (0210), “edit records” n+1 (2011), “edit records” m (0212) (0501). Judge validity of (edit records) against the current local-original-DB, by this “no-change range to be confirmed” and “edited version” (0502). When valid, update local-original-DB (0503), and update version of local-original-DB (0504). Repeat these processes for all “edit records” in the list of unsettled “edit records”.
If a set of “edit records” includes “edited version”, which is a time at which server received it, this is set as version of local-original-DB. If a version is a time at which server was asked about existence of “edit records” that are not yet received (by a PC), this time is obtained by the process 4 of FIG. 4. This time is set as version of local-original-DB, at the last of processes of FIG. 5 (just before the ending).
FIG. 6 shows transitions of a version, as an example. DB of FIG. 6 is RDB. Version is integer. “No-change range to be confirmed” is a record that has been edited. Here, each record keeps “version of record” that was the “edited version” at the time of the edit to this record.
PC-A 0602 and PC-B 0603 get (0610) initial global-original-DB 0604 as their local-original- DBs 0605, 0606. Base versions of them are zero, because they are copies of initial global-original-DB 0604 in server. After that, edit 1 to 6 were sent up. These were sent up by PCs other than PC-A0602 and PC-B0603. In FIG. 2, PC-A 0602 accesses again to server, and gets the latest edit and its turn (0612). At this time, getting edit 1, version of local-original-DB changes to 1.
Now suppose that, “operator of PC-A 0602 edits copy of record Z 0608 contained in local-original-DB 0605” (0613). At this time, “version of record” of edited “copy of record Z 0608” becomes 1, because base version of local-original-DB 0605 is 1. This set of “edit records” is sent (0614), and is recorded as edit 7. Immediately after this, PC-A 0602 receives “edit 2 to edit 6”, which were sent up after “edit 1” (that was already received).
PC-A confirms that the set previously sent up became “edit 7”, and investigates “edits to 7” in their turns, by “judging validity of edits” (that has been specified beforehand). Here, suppose that “edit 7” is judged valid. Base version of local-original-DB 0605 is changed to 7.
On the other hand, PC-B 0603 gets “edit 1” to “edit 6” (that is the latest edit at the time of this synchronization 0617) from server 0601, updates local-original-DB 0606 and sets 6 as its base version. After that, suppose that operator of PC-B 0603 edited “copy of record Z” 0609. At this time, “version of record” of “copy of record Z” 0609 changed to 6. This is sent up to server (0619), and was recorded as edit 8.
And, “edit 9” is sent up. After that, PC-A 0602 accesses server 0601 and gets “edit 8 and edit 9”, which were sent up after “edit 7” (that was already received) (0622). “Edit 8 and edit 9” are took out according to their turns. Validity of these edits will be judged, and local-original-DB 0608 will be updated. Here, base version of duplicate DB 0608 changes to 9, because the local-original-DB 0608 was updated by “edit 9”. At this time, contents of “copy of record Z” (that was edited by PC-B 0603) become valid in local-original-DB 0605 of PC-A 0602. PC-A 0602 finds out that “copy of record Z 0608 (that was edited previously by PC-A 0602) became invalid”.

INDUSTRIAL APPLICABILITY

As a popular operation, plural computers access a database placed in server. But problem is that “edit is impossible if access to server is impossible”. The present invention shows full-fledged parallel DB edit in which permanent duplicate DBs are kept in computers. This is applicable to a situation in which communications are frequently impossible, such as mobile device and mission critical tasks, for example medical and financial activities and relief at the time of a disaster.

Claims

1. A method of editing database, comprising;

(A) holding a duplication of whole or a part of a database,

(B) a process of sending “edit records” of edit on said copy, to another apparatus, and

(C) a process of receiving “edit records” on said copy, from another apparatus, and

(D) a process of executing the following sequence of steps;

fetching a set of “edit records” in order of turns assigned by exterior, or specified to each set of “edit records”, and

updating said copy of database by said set of “edit records”.

2. Apparatus editing database, comprising;

(A) means of holding a duplication of whole or a part of a database, and

(B) means of sending “edit records” of edit on said copy, to another apparatus, and

(C) means of receiving “edit records” on said copy, from another apparatus, and

(D) means of executing the following sequence of steps;

updating said copy of database by said set of “edit records”.

3. A method of editing database, comprising; A method to edit database, comprising;

(A) holding a duplication of whole or a part of a database,

(D1) a process of executing the following sequence of steps;

fetching “edit records” in order of turns assigned by exterior, or specified to each set of “edit records”,

judging validity of said set of “edit records”, and

updating said copy of database by said valid set of “edit records”.

4. A method of editing database, comprising;

(B1) a process of

setting mapping between “edit records” of edit on said copy and “no-change range to be confirmed” which indicates range of information affected, and

sending said “edit records” to another apparatus, and

(C1) a process of receiving “edit records” on said copy and “no-change range to be confirmed” mapped to said edit records, from another apparatus, and

(D2) a process of executing the following sequence of steps;

fetching edit records in order of ordinal number assigned by exterior, or specified to the edit records,

judging validity of said edit records by “no-change range to be confirmed” mapped said edit records and

updating said copy of database by said valid edit records.

5. A method of editing database, comprising;

(A) holding a duplication of whole or a part of a database,

(B2) a process of

setting mapping between “edit records” of edit on said copy and a version which is assigned to said copy, and

sending said “edit records” to another apparatus, and

(C2) a process receiving a set of “edit records” on said copy and a version mapped to said set of “edit records” from another apparatus, and

(D3) a process of executing the following sequence of steps;

fetching a set of “edit records” in order of turns assigned by exterior, or specified to each set of “edit records”,

judging validity of said set of “edit records” by version mapped said edit records and

updating said copy of database by said valid set of “edit records”, and

updating its version.

6. A method of editing database, comprising;

(A) holding a duplication of whole or a part of a database,

(B3) a process of

setting mapping between “edit records” of edit on said duplication and a version which is assigned to a part of said information or combination of information of said copy, and

sending said “edit records” to another apparatus, and

(C2) a process receiving a set of “edit records” on said duplication and a version mapped to said set of “edit records”, from another apparatus, and

(D3) a process executing the following sequence of steps;

fetching a set of “edit records” in order of turns assigned by exterior, or specified to said set of “edit records”,

judging validity of said set of “edit records” by version mapped said set of “edit records” and

updating said duplication of database by said valid edit records, and

updating its version.

7. A method editing database, comprising;

(A) holding a duplication of whole or a part of a database,

(B2) a process of

setting mapping between edit records of editing work on said duplication and a version which is assigned to said copy, and

sending said edit records to another apparatus, and

(C2) a process receiving edit records on said copy and a version mapped to said edit records from another apparatus, and

(D4) a process executing the following sequence of steps;

judging validity of said edit records by version mapped said edit records, and

updating version of said duplication of database, and updating said duplication of database by said valid edit records.

8. A method of editing database, comprising;

(A) holding a duplication of whole or a part of a database,

(B2) a process of

setting mapping between “edit records” of editing work on said duplication and a version which is assigned to said duplication, and

sending said edit records to another apparatus, and

(C3) a process of receiving a set of “edit records” on said duplication and date and time mapped to said “edit records” from another apparatus, and

(D5) a process of executing the following sequence of steps;

judging validity of said set of “edit records” by version mapped to said set of “edit records”, and

updating said duplication by said valid set of “edit records”, and.

setting date and time assigned to said set of “edit records” as version of said duplication.

9. A method to edit database, comprising;

(A) holding a duplication of whole or a part of a database,

(B2) a process of

setting mapping between “edit records” of edit on said duplication and a version which is assigned to said duplication, and

sending said “edit records” to another apparatus, and

(C4) a process of sequence of steps;

receiving set of “edit records” on said duplication and version mapped to said set of “edit records” from another apparatus, further

receiving date and time, and

(D3) a process of executing the following sequence of steps;

judging validity of said set of “edit records” by version mapped to said set of “edit records”,

updating said duplication of database by said valid set of “edit records”, and

setting date and time that are received by process (C4) as version of said duplication.