DATABASE CONTRADICTION SOLUTION METHOD

Provided is a database operation method which modifies references among database records. A record is fetched (0301), a reference destination record that is set to the record is specified (0302), “changing reference destination modification” that is set to the reference destination record is specified (0303), a reference destination modification process corresponding to the reference destination modification information is invoked (0304), and the newly obtained reference destination is set as a new reference destination of the fetched record (0305). Moreover, copies of the original database are created in plural number of computers and editorial contents on the copies are reflected to the original database by a database management method. A base version of a database is recorded for each record and editorial contents on newest base version are made to be valid.

Skip to: Description  ·  Claims  · Patent History  ·  Patent History
Description
TECHNICAL FIELD

The present invention dissolves structural inconsistency of the information recorded on the database.

BACKGROUND ART A General Background Art

Information contained in a database (DB) is a collection of records having references to other records in many cases. Referential integrity (see non-patent literature 1) means consistency of references of a relational database (RDB). Reference is a general concept common to various DBs expressing the relation among records. Object-oriented DBs also have referencing and referred records.

Some DBs have “chain delete function” or “chain update function” that delete or update other records in consequence of a deletion or modification of one record.

However, these referential integrity functions sometimes delete unexpected records, or do not modify records as expected. It is possible to disable referential integrity functions of DBs and implements similar functions on a user program that are invoked at their own trigger events. However, such program has to search all records having possibility to be deleted or updated, and needs heavy processing powers.

<DB Operation Types>

DB operation types are classified into the followings that are introduced just for simple explanations of this specification.

Single DB access: Only one computer accesses a DB.

Server DB access: Only one server computer accesses a DB. Other terminal computers first access the server that directly accesses records of a DB. It is equivalent with single DB access, from the view point that a DB is accessed directly by a single computer.

Parallel DB access: Original DB is copied to plural number of computers, of which reproduced DBs will be concurrently edited. And the original DB will be updated by reflecting these editorial contents. It is common to put the original DB on specific computer, such as server or a computer which performs administrative tasks. Because DB is concurrently accessed by plural number of computers, Parallel DB access is different form “single DB access” and “server DB access”. Range of DB reproduction is whole DB in some cases, or only a portion required for the present work in other cases. Subdividing original DB beforehand, it is possible to reduce operation tasks to update reproduced DB, i.e., operation to coincide the contents of reproduced DB with the original DB.

<Structural Inconsistency of DB>

If the inspection of referential integrity is omitted to improve speed of processing, structural inconsistency will be made, such that “referred record does not exist”, or “mistaken reference being set up” and so on. If these inconsistencies are left, it will be impossible to continue processing when program encounters them. This situation may occur at all DB operation types mentioned above.

Structural inconsistency is fate for parallel DB access, because it is impossible to investigate reproduced DB in other computers just before editing a reproduction DB. For example, there is a possibility to deleted or change a record, which is referred by other records of other computers. These inconsistencies are spread over reproduced DBs of other computers, by updating the original DB and synchronizing reproduced DBs with the original DB.

Plural computers probably concurrently edit same record in parallel DB access.

Updating the original DB by these edit contents, inconsistency will be found out. This is also “structural inconsistency of the information recorded on DB.”

<Current State of Parallel DB Access>

The system, “Power up news paper sales”, which was developed under directions by the author of this specification, permits parallel access only for read accesses. It blocks parallel write accesses, forcing computers to get “editorial right” before starting their edits to DB. This is called an “edit lock” in this specification.

Investigations about parallel DB access are explained below. MVCC (non-patent literature 1), which is one of on-line DB software, uses only “edit lock” for resolving edit competitions (non-patent literature 2 and 3), though it makes copy (a part) of DB for read access. Cache (non-patent literature 4) and ObjectStore (non-patent literature 5), which are OODB, use only “edit lock” for avoiding parallel editing work. PostgreSQL of RDB uses “SELECT FOR UPDATE” or “LOCK TABLE” command for avoiding simultaneous edits (non-patent literature 6), which is a “edit lock”. Patent document 1 also uses “edit lock”.

Patent documents 2, 3, 4, 5, and 6 were investigated, and neither is inapplicable to resolve inconsistency by parallel edit of DB. ADO.NET of Microsoft moves one step toward parallel DB access from operation of server DB access. It copies data required for the present work to a terminal computer from a server, and after it cuts connection with the server computer, it performs editing work. It connects with the server computer again after editing work, and editorial contents are sent up to the server computer. If the original contents are already changed from other terminal computers, the editorial contents will be invalid. This is called “optimistic concurrency control” (non-patent literature 7 and 8).

Although optimistic concurrency control is a kind of parallel DB access, there are two problems. One problem is that it ignores a possibility of inconsistency about referential integrity. For example, suppose that a terminal computer copied a record (R) from a server, deleting it, and notified it to the server about 10 seconds later from the copying time. This deletion will be valid, if there is no edit notification about R to server from other terminal computers during the 10 seconds period. However, if the reference to R from other records remains, or if reference is newly set up within above-mentioned 10 seconds, structural inconsistency will occur.

Another problem is that judgment based on the latest information will be invalid in some cases. It is a problem in actual DB operation, because the judgment based on the latest information might be the best.

For example, the operator of “computer A” wrote at 9:00 in the morning that “no need to send kind correspondence to this customer, he is a banter”, and left for a while. On the other hand, the operator of computer B acquires information that “the customer proposed big-ticket dealings” at 12:00 noon, writes in “The maximum entertainment should be performed to get a contract”, and send it up to the server. However, if “computer A” sends its editorial contents up to the server just one minute before, the edit by computer B will become invalid. This is the situation where “computer A” cannot oppose capricious operation of the operator of “computer B”.

Patent document 7 uses editorial time to reproduction databases and manipulates versions of edits such that, “re-number version number so as to increase from the early time (Step S604)”, (paragraph 0065 and 0097 of patent document 7), and “the latest version will be assigned to the oldest time of contents (paragraph 0097). That is, the previous edit has priority.

There is also a problem, even if earlier edit has priority. For example, suppose that a computer holds edit result at a certain time (for example, one year before). If it is sent up to a server suddenly one day and becomes effective, all editorial contents done in the past one year by other computers will be invalidity. It seems that such operation is not usually allowed.

<The Limit of Conventional Technology>

Though edit lock prevents the competition of edit to a record, it cannot prevent inconsistency caused by parallel DB access, inconsistency will be that, “there is no pointed record”, and “mistaken references are set up”. This structural inconsistency cannot be prevented by methods to choose valid editorial contents checking editing time or sending up time to the server. Thus, there will be problems such that “some edited records will be valid, though they are against operators expectations”.

<Conventional Technology about Referential Integrity>

Conventional technology about referential integrity was investigated. Patent document 8 removes restrictions of referential integrity temporarily and carries mass data entry, and after that, inspects referential integrity. Patent document 9 shows method to prevent another computer reading broken state of referential integrity temporary generated during editing work. Neither is inapplicable to the subject of the present invention.

When the main table changes, patent document 10 immediately notifies it to computers having record related to these changes. However, the server DB access is more simple and clearer than complicated this notification process. There is no value to use this kind of notification combined with the parallel DB access.

[Patent document 1] JP, 11-272534, A
[Patent document 2] JP, 11-161535, A
[Patent document 3] JP 2005-503606, A
[Patent document 4] JP 2005-508050, A
[Patent document 5] JP, 8-16447, A
[Patent document 6] JP 2000-501532, A
[Patent document 7] JP, 2005-216167, A
[Patent document 8] JP, 2006-79260, A
[Patent document 9] JP, 3185718, B
[Patent document 10] JP, 3612449, B
[Non-patent literature 1] “Main functions and merits”, [online], Apr. 22, 2007 search, the Internet (URL: http://www.sonicsoftware.co.jp/products/object_store/function.html)
[Non-patent literature 2] MVCC (multi-phase concurrency control), “9.1 First”, [online], Apr. 22, 2007 search, the Internet (URL:http://www.postgresql.jp/document/pg721doc/user/mvcc.html #MVC C-INTRO)
[Non-patent literature 3] “9.5. Consistency-of-data check in an application level”, [online], Apr. 22, 2007 search and the Internet (http://www.postgresql.jp/document/pg721doc/user/applevel-consistency.html)
[Non-patent literature 4] “Cache Technology Guide”, [online], Apr. 22, 2007 search, the Internet (URL: http://www.intersystems.co.jp/cache/technologyguide/technologyguide.html)
[Non-patent literature 5] “Main functions and merits”, [online], Apr. 22, 2007 search, the Internet (URL: http://www.sonicsoftware.co.jp/products/object_store/function.html)
[Non-patent literature 6] “9.5. Consistency-of-data check in an application level”, [online], Apr. 22, 2007 search and the Internet (http://www.postgresql.jp/document/pg721doc/user/applevel-consistency.html)
[Non-patent literature 7] “The outline of the data concurrency control in ADO.NET”, January, 2007, MSDN subscription library (MSDN subscriptions Library), Disk file, (URL:ms-help: //MS.MSDNQTR. v80.ja/MS.MSDN.v80/MS.VisualStudio.v80.ja/dv_raddata/html/d52930 98-4a88-4110-abd2-34d9e6661664.htm)
[Non-patent literature 8] “Tutorial: Processing of a concurrency exception”, January, 2007, a MSDN subscription library (MSDN subscriptions Library), A disk file, (URL: ms-help: //MS.MSDNQTR.v80.ja/MS.MSDN.v80/MS.VisualStudio.v80.ja/dvraddata/htm/73ee9759-0a90-48a9-bf7b-9d6fc17bff93.htm)
[Non-patent literature 9] “Referential integrity”, [online], January, 2007, [Jun. 6, 2007 search], Internet (URL:http://www.leasekin.com/rodan/makepos/02ac2kintro/tablekih on/p010130sansyouseigousei.htm)

DESCRIPTION OF THE INVENTION Problems to be Solved by the Invention

If DB is edited without fully investigating the reference relation among records in order to improve processing speed, “structural inconsistency of the information recorded on the database” will arise. This is a problem common to single DB access, server DB access, and parallel DB access.

In editing work of parallel DB access, it is evitable to generate structural inconsistency of DB, such as, lack of referential integrity, collision record edit, and so on. When plural computers add records to a table concurrently, major keys may conflict each other. These are also structural inconsistency.

It is still reasonable to realize parallel DB access. Single DB access has a problem in data sharing with other computers. Server DB access has fatal defect that “information cannot be accessed in the situation when connection to the server is broken”. Telecommunication is frequently impossible in a mobile situation. Mission critical business should be done, even if telecommunication is impossible. Delay caused by communication with server is also a problem.

There was no practical parallel DB access method for both reading and writing though it is ideal, because there was no reasonable method of solving “inconsistency of database structure caused by editing work on DB”. The present invention shows new method that permits temporal “structural inconsistency recorded in the database” and resolves it when needed.

Means for Solving the Problem <Introduction of Changing Reference Destination Information>

Operator of DB has clear intention how reference relation among records should be changed, and edits DB according to the intention. There will be no inconsistency if all the related references are changed as the intention. Since processing load will be huge if it is performed immediately after editing work on DB, the present invention specifies (writes) “changing reference destination information” to edited records. When reference to this record is detected, reference destination is changed (by the program) according to the directions of this “changing reference destination information.” Detailed explanation is shown below.

Setting a “Changing reference destination information” to a record is to specify a new record to which (other) records referring to this record should newly refer. At this time, “deleted mark” is attached to a record with “changing reference destination information”. Record with deleted mark is not displayed. It seemed to be the record is truly deleted for operator. This record will never be newly referred.

For example, a deleted mark is attached to the record “Tokyo” and the record “Japan” which is a generic concept of “Tokyo” is specified as the “changing reference destination information” of “Tokyo”. It is an operator's decision (or a program designer's decision) how changing reference destination information is specified. It is also possible to define a new record of “Not appointed”. This record can be set as new reference destination of “changing reference destination information”.

Handling a record referring to “Tokyo” (by program), inconsistency of this record will be gradually canceled by changing reference destination to “Japan” (or “Not appointed”) according to “changing reference destination information”.

A set of records referred is called the main table in RDB. Changing reference destination of a record of this table might be another record of this main table, or another record of another main table. In order to avoid an infinite loop of reference destination changes, there is an idea to create new main table and change a reference destination into the new table.

“Revival” can be specified as an advanced type of changing reference destination information. Suppose that deleted mark is attached to a certain record, of which “changing reference destination information” is “revival”. When a record referring to this record is detected, this record is revived by eliminating a delete mark.

Revival is possible, because deletion by attaching “deleted mark” is logical deletion and not actual deletion. Actual deletion of records can be postponed to the situation where record with delete marks becomes abundant and memory runs out by prolonged operation.

There is no problem if all changing of reference destinations are completed before actual deletion of records. If some changing of reference destinations are left to be not completed, a program will detect that a reference destination was actually deleted and a message is displayed. It will not become a big problem even if an operator specifies new reference destination, if few changing are left. If actual deletion will be done when there is less load of processing, there is no problem even if complete investigation and complete changing of reference destinations are done.

It is not necessary to specify “changing reference destination information”, if there is no necessity of correcting references caused by changing some records. As for records with city names, there is no necessity of changing references when “Tokyo” is changed to “Tokyo Metropolitan”.

Above is explained the method to permit generating inconsistency of referential integrity temporary and to solve gradually when required.

<Resolving Collisions Among Editing Work>

There may be a collision when a record is edited under parallel DB access. Although it is necessary to explain including a relation with changing reference destination information, first of all, a method of settlement of a simple collision is shown.

The present invention shows a mechanism which adopts editorial contents to the latest information, on the contrary to “optimistic concurrency control” or patent documents 7 that show mechanisms to use send-up-time to server or time of editing work.

Processes are as follow. (a) Update a version of the DB, whenever original DB is updated. (b) When making a copy from the original DB to a computer, set version number of the original DB to the reproduced DB as base version of it. (c) When a computer sends up the editorial contents on the reproduced DB to a computer (for example, server) managing the original DB, it also notifies (sends up) the base version of the reproduced DB. (d) When it collides with editorial contents from other terminal computers, editorial contents on reproduction DB with higher base version will be adopted. (e) If there are plural edits with same base version, one sent up earlier will be adopted. As a simple implementation, a computer (for example, server) managing original DB performs can perform above (d) (e). But another computer can perform them or plural computers share them, if the same result is obtained.

An editing computer performs a series of following steps. (Step 1) Make a reproduced DB by copying the original DB, or synchronize reproduced DB with the latest original DB. (Step 2) Edit the reproduced DB. (Step 3) Editorial contents over reproduction DB and version of it are sent up to a computer that manages original DB. Computer managing the original DB makes decisions on adoption of editorial contents by (d) and (e) mentioned above, after (Step 3). During (Step 2), there is no necessity to keep connection with a computer that manages original DB,

Suppose that computer B sends up editorial contents, while “computer A” is doing (Step 1) and (Step 2). In this situation, the computer that manages the original DB first set valid to editorial contents from B and update version of the original DB. When the editorial contents of A are sent up, it will be done to decide which editorial contents has priority. Comparing base versions of editorial contents of A and B, editorial contents with the latest base version will be adopted. If editorial contents of A are adopted, edition of B will be invalid. If both have same base versions, edition of B is adopted because it is sent up earlier, and editorial contents of A will be invalid.

If a base version of the original DB is newer than that of editorial contents at the send-up-time of said editorial contents, there is a possibility that another edit of newer base version might be sent up later and it might be valid.

On the contrary, if a base version of editorial contents is equal with a version of original DB at the send-up-time of said editorial contents, there is no possibility that another editorial contents of newer base version might be sent up later. This sending up is the first one among editorial contests for the same base version. Therefore, this sending up is adopted, the original DB is updated and, as a result, a version of this is updated only one.

If process at editing computer from (Step 1) to (Step 3) is done for a very short time, a possibility will be very small that a result of other editorial contents will be sent up and interrupt the process. After (Step 3), a reproduced DB is synchronized with the original DB, and a version of the original DB is acquired and set as a base version of the reproduction DB.

If base version is updated just one at this time, this computer can confirm that a previous result of editorial contents is set valid. Conversely, if the base version is updated more than two, there will be a possibility that the previous result of editorial contents becomes invalid or already invalid.

If process from (Step 1) to (Step 3) is done for a very short time, it becomes operation very close to on-line operation (such as server DB access). It is useful to edit a record, to which competitive editorial contents are expected.

On the contrary, when treating a record with very few possibilities of competitive editing work, a period of (Step 2) can be lengthened extremely, sufficient time for an input or editing work can be spent, and (Step 3) can be performed after it. Of course, while (Step 2), there is no necessity to keep connection with computers (for example, server etc.) managing the original DB.

For example, in a case which inputs debit slips of each organization of a company, a record will be edited when an input mistake and mishandling are discovered. Even if corrections are required, it will be done by the same computer that input original records in many cases.

In those cases, off-line operation with huge long period of (Step 2) has no problem. Even if we cannot connect with internet, we can input debit slips slowly. We can send them up as Step 3 when settlement of accounts or inspection becomes near.

Even if structural inconsistency of DB occurs by parallel editing work, inconsistency should be canceled by applying a method of the present invention (also including a method explained after this), when required.

As stated above, an operation near on-line or near off-line can be selected only by setting an execution cycle of (Step 1) to (Step 3). These two operations can exist simultaneously. These are some of good points of the present invention that resolves editorial collisions by assigning higher priority to editorial contents to the latest information. And, only changing an execution cycle from (Step 1) to (Step 3), a terminal computer can perform almost on-line at some specific time and almost off-line at another time. Mixture operation is also possible that a certain terminal computer is operated as almost on-line, and another terminal computer is operated as almost off-line.

In a method of “optimistic concurrency control” and patent documents 7, as explained previously, information send up from a computer of “being almost off-line operation” might block information send up from a computer of “being almost on-line operation.” However, as for editing work to the same record, priority is given to a result of editing work by “being almost on-line operation”, if the present invention is employed that priority is assigned to editing work on the newest information. What is necessary is just to perform as almost off-line operation, if you would like to validate results of editing work. What is necessary is just to perform as almost off-line operation, if you treat records with little competition of editing work, and wants to omit communication efforts and time.

It is easy to understand by man that we perform process from (Step 1) to (Step 3) for a short time to validate results of editing work, because it is very close to human sense that priority is given to judgment (editing work) based on newer information. This property is suitable for actual DB operation on which many persons make connections. This is another good point of resolving collision of editing work by “setting priority on editing work to newer information”.

By mechanism described above, simple competition of editing work to a record is resolved. Here, simple competition means that there is no record referring the records. Although versions were given to the original DB at above descriptions, versions can be set to tables or records of the original DB and used for managements. This is equivalent with subdividing the original DB.

<Resolving Collision of Changing Reference Destination Information>

Consideration is still required for collisions of editorial contents to records to be referred. For explanation, suppose that edit X and edit Y collide with each other, i.e., both set different “changing reference destination information” to same record. Suppose that edit X was adopted by a mechanism that higher priority is set to editorial contents to newer information.”

The problem is that a reference destination of some records will be changed by “changing reference destination information” set by edit Y, before judging that edit Y is invalid. An example is shown. Suppose that a computer made editorial contents Y. Here, Y changed reference destinations of some records by applying “changing reference destination information” by the editing work. After that, editorial contents Y becomes invalid, when editorial contents Y are sent up and editorial contents X are decided as valid. There is no guarantee that reference changing only by editorial contents X is equivalent with reference changing by first editorial contents Y and editorial contents X.

A process which solves this problem is shown below. After editing a record which can be referred, first this editorial contents should be sent up and update reproduced DB by synchronizing it with the original DB, before changing references in this computer based on changing reference destination information. After confirming that the editorial contents are valid, that is the base version is updated only one, references will be changed by applying reference destination information.

For the previous example, the computer that sent up editorial contents X, will check that editorial contents X have been adopted, and then changes references based on said editorial content. The computer that sent up editorial contents Y, can see that editorial contents Y become invalid and editorial contents X are adopted. If necessary, it will edit again. It can change references by using editorial contents X.

When there are multiple changes to one record, it will make inconsistency, if intermediate changing reference destination information is skipped and only last one is used for changing reference destination. Thus, base version (of reproduction DB) at a time of confirming or setting a reference should be recorded.

It is possible to record a base version for each reference when a record has plural references, but has a problem that management might be complicated because of huge information. And, this version will be written (recorded) to each record as record version that is a version wrote (recorded) to a record.

When a record is newly created, or when the contents of the record are partly changed, a base version (of reproduction DB) at the time is recorded (and updated) as a record version. Since setting or changing of reference destination is also changes of the contents, a record version is updated. When (at least one) reference destination is changed, or when the other changes are made, all the references of the record are checked. If changing reference destination information is set to a referenced record, a reference destination will be changed according to it. As a result, all references of this record were updated or checked in the reproduced DB of the base version recorded in the record.

Adding a record, a major key (ID) will be given to the record by the above structure.

Actually, DB has a record (K) that keeps the following major key. New record (Z) uses value of K as a major key, and a value of K is updated after that. Addition of a record will be completed, if renewal of K is valid by the rule “priority is set to editing work with newer information”. Addition of new record (Z) becomes invalid, when editorial contents K was decided as invalid and renewal of a value of K becomes invalid.

However, (Step 1) to (Step 3) should be done quickly for validating adding new record. It will narrow applicability of almost off-line operation. Therefore, when almost off-line operation is important, range of a major key (ID) should be assigned to each computer beforehand, where these range have no overlap.

EFFECT OF THE INVENTION

By the method using the changing reference destination information of the present invention, inconsistency of the referential integrity generated temporarily is gradually resolved, when required. And, process of editing work on DB becomes high-speed because there is no need to inspect of referential integrity for every editing work.

The collisions among editing work by parallel DB access can be resolved reasonably by the method that higher priority is assigned to editing work to newer information.” By this method, almost on-line or off-line operation can be freely changed according to the character of information to be treated. It is also the big feature that computers of different operations (almost on-line or off-line operation) can work together via a server, and it gives big flexibility when plural computers share a DB.

By combining “the method using changing reference destination information”, and “the method that higher priority is assigned to editorial contents for newer information”, the inconsistency generated by editing work by parallel DB access is resolved reasonably. Effect is demonstrated especially when we edit records which might be referred.

Parallel DB access has strong points, such as that “communication with other computers via DB is possible”, and “it is possible to handle DB even if communication to outer is impossible”, and “there is no delay of response by communication with a server”. However, it was difficult to implement parallel edits, because there was no method to resolve inevitable structural inconsistency. The present invention resolves these problems and make possible to implement practical parallel DB access systems. This invention can be applied to mobile DB access or mission critical business. It is also effective for cases reducing cost and effort to connect to networks every time.

BRIEF EXPLANATION OF FIGURES

FIG. 1 is a composition of a popular computer.

FIG. 2 is the composition of computer as a set of a means which provides functions realized by programs.

FIG. 3 is the process of changing a reference destination.

FIG. 4 is the process to set “changing reference destination information”.

FIG. 5 is the process of a terminal-side computer to set priority to editorial contents on the latest information.

FIG. 6 is the process of a server-side computer setting priority to edit for newer information.

FIG. 7 is the process of a terminal-side computer to edit records that has possibility to be referred by other records.

FIG. 8 shows examples 1, 2, and 3 of reference destination changes.

FIG. 9 shows example 4 of reference destination changes.

FIG. 10 shows example 5 of reference destination changes.

FIG. 11 shows an example of the DB version management.

Description of Notations 0101 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 Display Unit 0109 Bus 0110 Communications Network 0111 DB (Database) in Secondary Memory 0201 Transmitting Means 0202 Receiving Means 0203 Means for changing reference destination 0204 Means for setting “changing reference destination information” 0205 DB (Database) 0206 Means for judging validity of editorial contents 0301 Process to fetch record 0302 Process to specify “reference destination record” that is set to this record 0303 Process to specify “changing reference destination information” that is set to said reference destination record 0304 Process invoking process to change reference destination corresponding to this changing reference destination information 0305 Process setting newly obtained reference destination to the previously fetched (0301) record as new reference destination 0401 Process to fetch a record 0402 Process to specify “changing reference destination information” 0501 Process to synchronize reproduced DB with the original DB 0502 Process to record version of the original DB as base version of reproduced DB 0503 Editing work on reproduced DB 0504 Judgment 0505 Process to send up editorial contents and base version of DB edited to Server 0601 Process to fetch, in order, records that are edited and sent up 0602 Process to specify record version (NRV) of this record 0603 Process to specify a record version (ORV) of the original record corresponding to this record 0604 Comparison of record versions 0605 Process to make valid the record that is newly sent up to at the original DB 0606 Process to update version of the original DB just one 0701 Process to edit a record which may be referred to 0702 Process to send up base version (BV1) and editorial contents to server 0703 Process to synchronize reproduced DB with the original DB 0704 Process to acquire and record new base version (BV2) 0705 Comparison of BV2 and BV1 0801 Sub Table 0802 Main Table A 0803 Main Table B 0804 Term n 0901 Process to fetch a label of reference destination record 0902 Process to confirm whether character string of “Head Office”, which is specified beforehand, is contained or not 0903 Judgment 0904 Process to change reference destination 1001 Node P 1002 Node R 1003 Node Q 1004 Process to specify node 1005 Process to check whether table and record are specified 1006 Process to change reference destination of referring record 1007 Process to specify higher rank record 1101 Server 1102 Computer A 1103 Computer B 1104 Original DB 1105 Reproduced DB (inside of A) 1106 Reproduced DB (inside of B) 1107 Original of record X 1108 Reproduced record X (inside of A) 1109 Reproduced record X (inside of B) 1110 Synchronization (create new reproduced DB in A) 1111 Synchronization (create new reproduced DB in B) 1112 Synchronization (update No 1 on reproduced DB in A) 1113 Editing work (to reproduced X by A) 1114 Sending editorial contents (from A to server) 1115 Update of the original X (reflection of editing work by computer A) 1116 Confirmation (whether editing contents by A are valid) and synchronization 1117 Synchronization (update reproduced DB in B) 1118 Editing work (to reproduced X in B) 1119 Sending editorial contents (from B to server) 1120 Update the original X (reflection of editorial work by computer B) 1121 Confirmation (whether editorial contents by B are valid) and synchronization 1122 Synchronization (update No 2 of reproduced DB in A) 1123 Update the original X (reflection of editing work by computer B)

BEST MODE OF CARRYING OUT THE INVENTION

It will be considered as common to implement methods described in claims of the present invention as programs of a computer. FIG. 1 shows typical composition of computer 0101. Arithmetic unit 0103, main memory unit 0104, secondary memory 0106, input/output unit 0107, and display unit 0108 are connected by bus 0109. When exchanging data with other computers, it connects to communications network 0101 via communication unit 0102. The “database” which has been refereed by each claim is DB 0111 in secondary memory 0106, or DB 0105 in main memory unit 0104.

Programs are recorded in secondary memory 0106, invoked and loaded to main memory unit 0104, and arithmetic unit 0103 runs procedure specified by the programs. Thus, computer is reconstructed as aggregate of means to realize operations that program developer intended. FIG. 2 shows functional constitution realizing methods described in claims.

As for operation of DB by programs, it is common to carry out, after developing the whole or a part of DB to main memory operation 0104. DB 0105 which developed all or a part of DB 0111 in secondary memory 0106 to main memory unit 0104 is operated, and the results of editorial work will be written to DB 0111 in secondary memory 0106. However, it is natural to suppose that DB is in secondary memory 0106, and argue with no distinction from DB 0105 developed to main memory unit 0104, FIG. 2 shows DB 0205 as unified concept over both of them.

“Means for changing reference destination 0203” realizes “the process of changing reference into this record to another record by using information set to this record” of claim 1, or “process of removing a delete mark if a reference to this record, to which the delete mark was attached, is detected” of claim 2.

“Means for setting changing reference destination information 0204” realizes “the process of recording information that changes reference to a record into a reference to another record” of claim 3.

“Means for judging validity of editorial contents” (0206) realizes “the process to validate editorial contents of latest version among ‘plural combinations of editorial contents and base version, that is the version of original DB when reproduced DB is made, and to reflected it to the original database” of claim 4. This means should be in the computer with the process of judging validity of edits (for example, computer which mounts controlling functions, such as a server). Transmitting means 0201 and reception means 0202 are used for communication among computers.

FIGS. 3 to 7 illustrate processes of claim 1 to claim 5. FIG. 1 shows the process equivalent to claim 1. To process 0301 to fetch record, to process 0302 to specify reference destination record that is set to this record, to process 0303 to specify “changing reference destination information” that is set to said reference destination record, to process 0304 invoking process to change reference destination corresponding to this changing reference destination information, and to process 0305 setting newly obtained reference destination to the previously fetched (0301) record as new referenced destination. In the explanation so far, thought the contents of this process “to change reference destination” is only to acquire the reference destination, others are explained in examples.

FIG. 3 also corresponds to the process of claim 2. First to process 0301 to fetch record, to process 0302 to specify reference destination record that is set to this record, to process 0303 to specify “changing reference destination information” that is set to said reference destination record, and to process 0304 invoking process to change reference destination corresponding to this changing reference destination information. If “revival” is detected, the delete mark of this reference destination record will be removed. In this case, since there is no change in a reference destination, there is nothing at “process 0305 setting newly obtained reference destination to the previously fetched (0301) record as new referenced destination” (0305).

FIG. 4 is the procedure equivalent to claim 3. To process 0401 to fetch a record, to process 0402 to specify “changing reference destination information”, that is to set information for changing reference to the record into another record.

Editing computer performs procedure of FIG. 5, in order to implement the method to “set priority to editorial contents for the latest information” of the present invention. First, synchronize 0501 reproduced DB with the original DB. In an actual situation, there are cases to make new reproduced DB or to update it with difference information. Process 0502 to record version of the original DB as base version of reproduced DB. And process 0505 to repeat editing work 0503 on reproduced DB as required 0504, and to send up these editorial contents. Here, “send up these editorial contents” means send up contents of the editorial work and base version of DB edited to server.

Claim 4 is a process to judge validity or invalidity of editorial contents sent up. A record version is recorded for every record in order to specify editorial contents of a higher version. When a record is created, a base version (of reproduced DB) at that time is recorded as a record version. When, at least a part of, the contents of the record are corrected, a base version (of reproduced DB) at that time is recorded as a record version.

FIG. 6 illustrates a process of claim 4 in detail using this record version. To take 0601 out, in order, records which were edited and newly be sent up, to specify 0602 record version (NRV) of said record, to specify 0603 record version (ORV) of the original of said record, to compare 0604 these record versions. When NRV>ORV, newly sent-up record becomes valid at original DB 0605. When NRV=ORV or NRV<ORV, newly sent-up record becomes invalid and proceed to the next process. Update version of the original DB just one, after above processes for all newly sent-up records. Example 6 explains version management in detail.

Claim 5 is a process of editing a record to which may be referred from other records. FIG. 7 shows the flow. First, synchronizes 0501 reproduced DB of a computer with the original DB, just like the process of FIG. 5. Simultaneously to record 0502 version of the original DB as base version of reproduced DB.

Then, edit 0701a record which may be referred, and this editorial contents and base version (BV1) are sent 0702 up to server. Promptly after that, reproduced DB is synchronized 0703 with the original DB, new version of the original DB is acquired and recorded 0704 as new base version (BV2). If 0705 BV2 is the next of BV1, move to the next process because editing work to said record, to that may be referred, has been completed. If “changing reference destination information” exist at the reference destination of a record that will we treated by the next process, a reference destination will be changed according to this. If 0705 BV2 is not the next of BV1, editing work on record, to that may be referred, can be tried again.

Example 1 Example in which a Reference Destination is not Changed

FIG. 8 shows example of setting up of changing reference destination information and process of changing. Sub table 0801 of FIG. 8 has plural records and “term n” 0804 has reference to a record of the main table 0804.

Record with ID=a of sub table 0801 refers to record with ID=1 of main table A 0802.

Reference from a record of the sub table cannot be changed, since “changing reference destination information” of this record is “no setting”.

Example 2 Example of Revival

In FIG. 8, specification of “display=False” is equivalent to a “deletion flag.” If a record is not displayed on a screen, it is the same as being deleted for a user. In main table A 0802, records with ID=2, 3, and 4 are in deletion state (display=False). When processing a record with ID=b of sub table 0801, “display=True” is set because “revival” is detected while checking “changing reference destination information” of the record with ID=2 of main table A. Since revival work was completed by the above, “revival” is changed to “no setting.”

Example 3 Example Changing Reference

When “changing reference destination information” is “changing to record with ID=X (X is explanatory ID: major key)”, the corresponding changing process is to change reference to this record to the specified record. That is, reference to this record from sub table will be changed to reference to the record with X.

At the first time, record with ID=c in sub table 0801 of FIG. 8 refers record with ID=3 of main table A 0802. “Changing reference destination information” of this record is “to change to record=5”. And, “3”, that is a ID of A, is changed to “5” at “term n” of record with ID=c in sub table. It means that reference by record with ID=c is changed to ID=5.

<Preventing Circulation of Reference Change>

If the main table is changed drastically, circulation may occur in conversion of reference. In this case, circular reference can be prevented by the following method. First both conventional and new main tables are prepared. And switch reference to the conventional main table to reference to the new main table.

If changing reference destination information is; “Table specification=S” (S is temporary table name for explanation)+“New record=Y” (Y is temporary ID: major key for explanation), the corresponding process to change reference destination is to change reference to this record into reference to record Y in the specified table S.

At the beginning, record with ID=d of sub table 0801 of FIG. 8, refers to 4 (record with ID=4) of main table A 0802. “Changing reference destination information” of this record is “main table B” and “change to record=1”. And, a reference destination should be set to record with ID=1 of main table B 0803, and value of “term n” 0804 of a record with ID=d in sub table is rewritten.

Although FIG. 8 shows both references destination changes to same table or to other tables for explanation, most of current RDBs have restriction that only one table is referred by a term of sub table. Therefore, it is practical to set restriction that RBD software refers only new main table of after conversion and that the former main table should be accessed by a program base on the present invention.

Example 4 Logic of Changing Reference Destination

When changing reference destination information is “another record of the same table”+“logic of changing reference destination=Z” (Z is a temporary label of logic for explanation), or when changing reference destination information is “record of another table”+“logic of changing reference destination=Z”, changing logic of reference destination is the following. When this record of the main table is referred from a sub table, invoke logic specified by Z, and by the result change reference destination of the referring record.

Record with ID=e of a sub table of FIG. 9 refers to the record with ID=11 of main table A at the beginning. “Changing reference destination information” of this record is “another record of the same table” and “Changing logic of reference destination=Z”. Thus logic Z is invoked.

FIG. 9 shows an example of logic Z as follows. First, fetch 0901a label of the original reference destination record, that is “Head office building” in this example. Next, check 0902 whether character string, specified beforehand, for example, the “head office”, is contained or not. If contained 0903, change 0904 reference of record with ID=e of sub table into reference to a record of ID=13 of main table A. Record of ID=f of sub table is referring to a record of ID=12 of main table A at the beginning, it is changed into reference to a record of ID=13 of main table A. Thus, all references to records of different expressions such as “head office building”, “management department in head office” and “head office” of same concept, are unified to references to a record of “Head Office”.

Example 5 Reference Destination Change Using Changing Tree

When “changing reference destination information” is “node=V of a changing tree” (V is explanatory label of node), reference destination is changes into a record specified to node V. If no record is specified with node V as new changing reference destination, search higher nodes of V in order, detect first new destination record, and set it as new destination.

At the beginning, record with ID=h of sub table of FIG. 10 refers to the record with ID=21 of main table A. “Changing reference destination information” of this record is “node=P of changing tree”. And, fetch 1004 node P 1001 and check 1005 that table and record are specified at this node. Since “ID=32 of main table B” is specified, it is set 1006 as new reference destination of the referencing record. At the beginning, record of ID=i of sub table refers to record of ID=22 of main table A. “Changing reference destination information” of this record is “node=Q of changing tree”. And, fetch 1004 node Q 1003 and check 1005 that table and record are specified at this node. Since node Q has no specification, find 1007 higher node, that is node R 1002, and check 1005 that table and record are specified at this node. Since there is “ID=31 of main table B”, it is set as reference destination of referencing record and write down it to the referencing record.

It is good idea not to show the record with “changing reference destination information”, for avoiding setting reference to this record. In FIG. 10, main table A is not displayed but only main table B which is the new main table is displayed. Therefore, an operator cannot choose a record of main table A as a reference destination. In FIG. 9, records with ID=11 and 12 are not displayed (display=False) but only a record with ID=13 is displayed. That is, only “Head office” can be set as new reference destination.”

Records with “changing reference destination information” and have property “display=false” will be shown for operators who manipulate or modify them, of course.

Process of reference destination change can be done when performing reference from sub table, that is, information on a reference destination is accessed by a program, or can be done collectively when no higher priority processes are running.

Example 6 Version Management of DB

It is necessary to manage versions of the original DB, and base versions of reproduction DBs, to implement the method setting priority to editorial contents on the latest information, of the present invention. FIG. 11 explains this structure.

Original DB 1104 is placed on server 1101. Computer A 1102 has reproduced DB 1105, and computer B 1103 has reproduced DB 1106. Version of original DB 1104 is 0 at the beginning, and base version of reproduced DBs are also 0. As already explained for claim 4, record versions are recorded to each record of the original DB and reproduced DBs. Record version is a record of base version when the record is created newly or when corrected at least some part of it. “0” is the initial value of record version of the original and reproduced record X.

Computer A creates reproduced DB at the first synchronization 1110, and computer B creates reproduced DB at the first synchronization 1111. These base versions are 0. After that, version of original DB is updated from “0” to “6,” this is the result of sending up to server from computers other than computers A and B. In FIG. 11, “computer A” 1102 performs synchronization 1112 once again, and version of reproduced DB becomes 1.

Now, suppose that “computer A” edits 1113 reproduced record X 1108 in reproduced DB 1105. Since a base version of reproduced DB is 1 at this time, record version of reproduced 1108 of record X is set to 1. This edited record and base version of reproduced DB 1105 are sent 1114 up to server. If said editorial contents are judged as valid at server, the original DB 1104 will be updated and version of the original DB will be 7. The original of record X is also updated 1115 to the contents of that edited by “computer A”. After “computer A” receives notification that the editorial contents become valid 1116 from server, synchronize 1116 is performed, and base version of reproduced DB of “computer A” becomes 7.

When program treat a record, program also checks reference destination record of the record. If there is “changing reference destination information”, reference destination of the record is changed. Since some contents of the record are changed by changing this reference destination, record version is set to the base version of that time. Changing reference destination information, specified by earlier versions, that are earlier than the version recorded on this record, has been already confirmed. When changing reference destination by changing reference destination information, changing reference destination information that are set after record version recorded are used, in order from the older one.

Thereby, change of reference destination is made without inconsistency.

On the other hand, computer B performs synchronization 1117 at the time of version 6 of the original DB 1104, and a version of reproduction DB 1106 is set to 6. Next, (reproduced) record X 1109 will be edited 1118. At this time, record version is set to 6 and is sent 1119 up to server. And collision of editing works to record X is found by inspection by serve, because editorial contents (to record X) by “computer A” is sent up after the synchronization 1117 of computer B just before the editing work.

Base version of editing contents that is sent-up by “computer A” is 1 (record version of the original of record X is 1), and base version of editing contents that is sent-up by computer B is 6 (record version of a reproduced record X edited by computer B is 6). Therefore, editing work by computer B is adopted and the original of record X is changed 1119 to the editorial contents made by computer B. At this time, version of original DB changes to 8. Receiving confirmation that “the editorial contents become valid” 1121 from server, computer B synchronize, and base version of reproduced DB of computer B becomes 8.

And, suppose that computer A performs synchronization 1120 with the original DB.

At this time, contents of record X, edited by computer B and becomes valid, propagate to the reproduced DB of “computer A”. That is, the previous edit by computer A becomes invalid at reproduced DB of “computer A” (at this time). Furthermore, additional mechanism is required in order to tell an operator that former edit became invalid.

INDUSTRIAL APPLICABILITY

Not only editing process of DB becomes high-speed, the present invention makes possible parallel DB, that is, plural computers make copies of the original DB, edit on them and reflect them to the original DB. This means that continuation of a process is possible, where connection with server is impossible. It is applicable to mobile DB access and mission critical business. It also meets a demand reducing time, effort and expense to connect with a communications network. Almost on-line or almost off-line operations can be chosen depending on each contents of process of any computer. Furthermore, big flexibility is given to DB operation, since computers of almost on-line or almost off-line can work together via a server.

Claims

1. (canceled)

2. A method to change a reference among records of a database, comprising;

(B) a process to change a “reference of a referring record to a currently referenced record”, when accessing said referring record, based on a “information that specifies a new record referenced to” recorded to said currently referenced record.

3. (canceled)

4. A method to change a reference among records of a database, comprising;

(D) a process, if “delete make” corresponding to a referenced record is found when accessing referencing record that refers said referenced record, to remove said “delete mark”.

5. (canceled)

6. A database management method editing reproduced database that is a copy of whole or some part of original database and updating the original database by results of said editorial contents,

(E) a process to set a version of the original database to a version of reproduced database when the contents of the reproduced databases are coincided with contents of the original database,
(F) a process to set said version of said reproduced database to an edited record when editing said record.

7. A method to manage database, according to claim 6, comprising;

(A1) a process to edit of recording “information that specifies a new record referenced to” corresponding to a currently referenced record, and to set said editorial contents invalid if it is impossible to confirm that said edit becomes valid at the original database,
(B1) a process to change a “reference of a referring record to a currently referenced record”, when accessing said referring record, based on valid “information that specifies a new record referenced to” recorded to said currently referenced record.

8. A method to manage database, according to claim 6, comprising;

(A1) a process to edit of recording “information that specifies a new record referenced to” corresponding to a currently referenced record, and to set said editorial contents invalid if it cannot confirm that said edit becomes valid at the original database,
(B2) a process to change a “reference of a referring record to a currently referenced record”, when accessing said referring record, based on valid “information that specifies a new record referenced to” recorded to said currently referenced record. And at that time, record version of reproduced DB to said record.

9. A method to manage database, according to claim 8, comprising;

(B3) a process to confirming that there is no change by a “reference of a referring record to said currently referenced record” and set version of reproduced database at said confirming time as version of said referencing record, when accessing said referring record, based on valid “information that specifies a new record referenced to” recorded to said currently referenced record.

10. A method to manage database, according to claim 6, comprising;

(H) a process to set an identification to a newly created record, according to “record keeping identifications for newly created singular or plural number of records”, and
(I) a process to do edit that assign new identifications to said “record keeping identifications for newly created singular or plural number of records”, and to set said edit invalid if it is impossible to confirm that said edit becomes valid at the original database.
Patent History
Publication number: 20100198789
Type: Application
Filed: Jun 4, 2008
Publication Date: Aug 5, 2010
Inventor: Kunio Kamimura (Tokyo)
Application Number: 12/601,005