JP5108637B2 - Data update method and data update system - Google Patents

Description

The present invention relates to a data updating method, and relates to a data updating system.

  Updating data in a database (hereinafter abbreviated as DB (Database) as appropriate) requires resources (computer resources) such as a CPU (Central Processing Unit) and memory. The process of updating a large amount of data with respect to a database on a terminal such as an embedded system that has limited resources is a burden.

  Until now, the database in the embedded system is not managed by middleware like a database management system, but a method in which an application in the embedded system creates its own processing has been used.

  However, due to recent advances in storage technology and higher functionality of embedded systems, the volume of data handled and the diversification have advanced, and in application-specific data management in embedded systems, higher performance and higher performance required for embedded systems are required. It is becoming difficult to meet reliability. In addition, the speed of product development is becoming more important due to intensifying competition in the embedded system market.

  In such a situation, the database on the terminal is not implemented in an application in the embedded system, but a high-performance RDB (Relational Database) that operates on a computer with abundant resources such as a center is applied. As such, there is a growing awareness of separating application and data management and increasing software development productivity.

Here, it is necessary to reduce processing in order to operate a high-performance RDB in an embedded system having a lower performance than the center. As an example of a method for reducing processing, there is a method of using log data of update instructions. For example, in Patent Document 1, when an update to the own station is performed, the update instruction is recorded as a log, and the log is also used when an update to another station is performed.
JP 2004-145827 A

  However, in the conventional technique, the processing has not been sufficiently reduced to operate the RDB in the embedded system.

  For example, in Patent Document 1, a log is reused by a plurality of devices, but an update command written in SQL (Structured Query Language) or the like (hereinafter abbreviated as an SQL update command) is applied to apply the log. This process is required for each device individually. The reason why the processing related to the update instruction is heavy is that the operation target of the update instruction is a logical structure called an RDB table.

  In other words, each device needs to assemble a table as a logical structure from a file as a physical structure stored in the device itself, but this processing becomes a heavy load.

  Therefore, the present invention solves the above-described problems and reduces the load of database processing on a computer having a lower performance than the center in a system in which a high performance computer and a computer having a lower performance than the center cooperate. The main purpose.

In order to solve the above-described problem, the present invention provides a table as a logical structure of an RDB (Relational Database) composed of a two-dimensional table as a page as a physical structure stored in a file of a disk device for each version. A DBMS (Data Base Management System) to be managed is executed by a database system that starts operation with the same version in one high-performance center and one or more terminals that have lower performance than the center. A data update method,
The center is
Store the result of applying the inputted center side acceptance instruction to the table in a page in the DB area of the file,
For the page in the DB area, when the update difference file indicating the difference page in which the data change from the pre-update version to the post-update version by the center side reception instruction is created , the center apparatus side reception instruction is applied and updated. When applied to a page in the DB area of the previous version, an update flag indicating that the page has been updated is set as updated for the location corresponding to the updated page of the update flag array corresponding to the page array Then, referring to the update flag array in order, the page where the update flag has been updated is extracted as a difference page,
Each said terminal
Store the result of applying the received terminal-side acceptance command to the table in a page in the DB area of the file;
For the page in the DB area, for the page in which the data change from the pre-update version to the post-update version by the terminal side acceptance instruction, the pre-update version page is saved in a backup file as a backup page,
When the center side acceptance command is issued, the terminal side acceptance command is applied by overwriting the backup page for the page whose data has been changed to the updated version by the terminal side acceptance command. Write back to the pre-update version,
Updating the updated difference file of the updated difference file notified from the center to the updated version after the application of the center-side acceptance command by overwriting the page in the DB area of the terminal. It is characterized by.
Other means will be described later.

  According to the present invention, in a system in which a high-performance center and a terminal having a lower performance than the center cooperate, it is possible to reduce the load of database processing on a computer having a lower performance than the center.

  Hereinafter, an embodiment of a database system to which the present invention is applied will be described in detail with reference to the drawings.

  FIG. 1 is an explanatory diagram showing an overview of the entire database system of this embodiment. In this system, one center and one or more terminals are connected via a network. Each of the center and the terminal has a DB in which a predetermined version of data is stored. Hereinafter, the DB possessed by the center is referred to as the center DB, and the DB possessed by the terminal is referred to as the terminal DB.

  The center and the terminal are each realized as a computer including a storage unit that stores a DB and a CPU that executes control processing and the like.

  In FIG. 1, the version of the data in the DB possessed by each computer is represented by a numerical value in the ellipse. For example, the center and all terminals on the left side (before update) of FIG. 1A have version “1.0” data. That is, the same content data is stored in each computer.

  Next, two types of update (center side received update and terminal side received update) focusing on the influence range of the update will be described.

  FIG. 1A is an explanatory diagram showing terminal-side received update. Unlike the large amount of data updates targeted by the center-side received update shown in FIG. 1B, the terminal-side received update mainly targets updates that can be executed sufficiently even on an embedded system and do not have a large load. .

  The center DB and the terminal DB hold the same version “1.0” in the initial state. Of the three terminals, one terminal A accepts an input of an SQL update command. Then, the terminal A reflects the SQL update command on the terminal DB of its own device. This update command reflection processing is executed by the DB management unit 21 (FIG. 8) of the terminal A. As a result, the version of the terminal DB of terminal A is updated from “1.0” to “1.1”.

  The update to the version “1.1” is an update that is closed to the terminal A (in other words, local) without being reflected to other terminals and centers. Independent update is performed in each DB by terminal side received update. Therefore, even when there are a plurality of terminals, the terminal DBs of the terminals are operated independently and do not affect each other. In the present embodiment, the terminal-side received update is expressed by increasing the decimal value of the version number.

  FIG.1 (b) is explanatory drawing which shows center side reception update. If only the terminal side received update of FIG. 1A is performed individually, the resources of the terminal are compressed. Therefore, the center side received update reduces the burden on the terminal by performing an update common to all the terminals on behalf of the resource-rich center.

  The center DB and the terminal DB hold the same version “1.0” in the initial state. A center that manages three terminals accepts an input of an SQL update command. Then, the center reflects the SQL update command on the center DB of its own device. The update command reflection process is executed by the DB management unit 11 (FIG. 8) of the center. As a result, the version of the center DB of the center is updated from “1.0” to “2.0”.

  This update to version “2.0” is reflected in all terminals managed by the center. In other words, the update is reflected in all terminals (in other words, global). In this specification, the center side received update is expressed by increasing the integer value of the version number.

  Here, the case where the center side reception update is performed after the terminal side reception update is performed will be described. As a result of the terminal-side received update in FIG. 1A, the version “1.1” of the terminal DB of the terminal A and the version “1.0” of the terminal DB of the terminals B and C are mixed. In the center side received update, it is necessary to reflect the update of the center DB version “1.0” → “2.0” to all terminals.

  First, in the terminals B and C, the version before the update is “1.0”, which is the same as that of the center. Therefore, the process equivalent to the center update is also performed in the terminal, so that the version “2.0” can be obtained without any problem. Updated.

  On the other hand, in the terminal A, the version before update is “1.1” unlike the center. Therefore, even if processing equivalent to center update is performed, the terminal DB cannot be updated to version “2.0” because the data before update is different. That is, it becomes a problem when two types of updates (terminal side received update and center side received update) are used together.

  FIG.1 (c) is explanatory drawing which shows the coping method to the problem when using two types of update together. This figure is a state transition diagram focusing on the version of the terminal DB of the terminal A, and the numerical value described in the ellipse indicates the version number.

  First, state transition from version “1.0” to “1.1” will be described. The terminal DB performs terminal side received update shown in FIG. This terminal-side received update is executed by the DB management unit 21 (FIG. 8) of the terminal A. At this time, if a page for rewriting data is specified, the page before the actual rewriting is saved as a backup file. The backup file saving (storing) process is executed by the backup file creation unit 23 (FIG. 8). Note that when a terminal-side received update is performed a plurality of times on the same page, the backup file may be saved only once for each page.

  Next, state transition from version “1.1” to “1.0” will be described. This state transition is a preparation for reflecting the center side received update of version “1.0” → “2.0” shown in FIG. When this center side received update is reflected on the terminal A, the terminal DB version “1.1” of the terminal A and the update source version “1.0” of the center DB need to be the same version.

  Therefore, the version of the terminal DB of terminal A is written back from “1.1” to “1.0”. This write-back process is executed by the page write-back unit 25 (FIG. 8) of the terminal A. Specifically, it is realized by overwriting the backup file of version “1.0” on the page of “1.1” at the time of state transition from version “1.0” to “1.1”. The

  The state transition from version “1.0” to “2.0” will be described. This state transition is processing for reflecting on the terminal A the center side received update of version “1.0” → “2.0” shown in FIG. The center creates difference data of version “1.0” → “2.0”, and inputs the difference data to the terminal A.

  Specifically, the center compares the database of the initial state “1.0” prepared in advance with the updated database of “2.0” for each page, and among the pages with different pages, Store the updated database page in a file. This file becomes the difference data. This difference data storage processing is executed by the center update difference file creation unit 13 (FIG. 8). The process of updating the center database from “1.0” to “2.0” is executed by the DB management unit 11 (FIG. 8).

  The terminal A to which the difference data from the center is input updates the version DB to “2.0” by applying the difference data to the terminal DB of the version “1.0”. This update process is executed by the page update unit 26 of the terminal A (FIG. 8). Thereby, the center side received update is reflected on the terminal A.

  Further, state transition from version “2.0” to “2.1” will be described. This state transition is a process of setting the version “2.1” by applying the contents of the terminal side received update of version “1.0” → “1.1” to the version “2.0”.

  Specifically, the terminal A stores the SQL update instruction at the time of the terminal-side received update from “1.0” to “1.1” that has already been performed, and the SQL update instruction is stored in the version “ By applying to "2.0", the version is "2.1". As a result, since one SQL update command is reused in two terminal-side received updates, the trouble of inputting the SQL update command to the terminal A can be saved. The process for storing the SQL update command is executed by the update command history management unit 27 (FIG. 8).

  That is, by setting the version “2.1”, it is possible to recover the contents of the terminal-side received update lost when writing back to the version “1.0” after executing the center-side received update process. it can.

  The update contents that can be recovered here are limited to a part. For example, if a predetermined page is rewritten by terminal-side reception update, if the predetermined page has been deleted as a result of the center-side reception update process, the predetermined page disappears, so such terminal-side reception Updates cannot be recovered with version “2.1”.

  On the other hand, if a specific page targeted for a terminal-side received update is not affected by the logical structure by the physical center-side received update process, that is, if no change is made to any row in the table, The contents of the terminal side received update can be recovered with version “2.1”.

表１は、ＳＱＬ更新命令の更新命令履歴ファイルの一例である。更新命令履歴ファイルには、更新の順序を識別するための更新ＩＤと、指定されたＳＱＬ文と、ＳＱＬ文の入力パラメータ値とを対応づけて格納する。更新ＩＤは、例えば、ＳＱＬ更新命令の発行時の時間を識別するように作成される。例えば、第１列の更新ＩＤ「2006-1223-0123」は、2006年12月23日01時23分という発行時の時間をもとに作成されたものである。更新ＩＤによって順序を一意に規定することにより、その順序でＳＱＬ文を適用することができる。

Table 1 is an example of an update command history file of SQL update commands. In the update command history file, the update ID for identifying the update order, the designated SQL statement, and the input parameter value of the SQL statement are stored in association with each other. The update ID is created, for example, so as to identify the time when the SQL update command is issued. For example, the update ID “2006-1223-0123” in the first column is created based on the issuance time of 01:23 on December 23, 2006. By uniquely defining the order by the update ID, SQL statements can be applied in that order.

  FIG. 2 is an explanatory diagram showing a relationship between a logical structure table in RDB and a physical structure page.

  RDB is the most common database used in information systems today. In RDB, the logical structure of a database is represented in a two-dimensional table format. The horizontal direction of the table is called a row (record), and the vertical direction is called a column (field). A row is a unit for manipulating a table and is composed of one or more columns. Data of the same format is stored in the same column of each row.

  In RDB, data operations are performed by specifying a table and a row to be operated using a language called SQL. In order to manipulate the data in the database, the RDB operator need only be aware of the logical structure such as the rows and columns of the table shown in two dimensions.

  That is, it is not necessary to be aware of the physical structure where and in what form the file is stored in the physical structure file storing the table. The correspondence between the logical structure and the physical structure is performed by a database management system that is middleware.

  Data to be accessed by the database is expressed as a logical structure table. The DB area storing this table is composed of one or more files stored in the physical area when viewed from the operation system.

  In the case where the DB area is composed of a plurality of files, an operation such as updating performed on the DB area may be performed on each of the plurality of files constituting the DB area. Files are separated in units of pages with a fixed size (also called segments). Data operations on the physical structure are performed for each page.

  FIG. 2A shows a table before update. The table is expressed in a two-dimensional table format with rows and columns as axes. An update instruction described in the SQL format can be applied to this table. In FIG. 2A, description will be given focusing on a part of one table, but the DB area may store a plurality of tables.

  FIG. 2B is the same data as the table of FIG. 2A, and is a page when stored in the DB area. The page stores, for example, data constituting the table in order. The update command described in the SQL format is not applicable to this page. In FIG. 2B, one page is extracted and described. However, one table may be stored across a plurality of continuous pages.

  FIG. 2C shows an updated table that is a result of applying the SQL update instruction to FIG. The SQL update instruction “SQL update instruction“ selects the record in which the first column is 11 and changes the second column of the record to 999-999 ”, thereby changing the value of the second column of each row to“ 999-999 ”. Has been updated.

  When updating the data, upon receiving the SQL update command, the database management system identifies the corresponding page and identifies the corresponding part in the page. First, the identification of the corresponding page is to identify the corresponding page in which the table specified by the SQL update instruction is stored, in other words, to convert from the logical structure to the physical structure.

  Next, the identification of the corresponding part in the corresponding page is, for example, confirming that the value of the first column of each row in the corresponding page is “11”, and finding the row whose value is “11”. , Rewriting the area in which the value of the second column of the row is stored to the value “999-999”. As described above, the RDB update process has an overhead of specifying a corresponding page and a corresponding portion in the page.

  FIG. 2D is the same data as the table of FIG. 2C, and is a page when stored in the DB area. Compared with FIG. 2B, the portion corresponding to the data in the second column is rewritten as “999-999”.

  Here, a feature of this specification is that the logical update is performed first time, and the physical update is performed using the result of the logical update after the second time.

  First, logical update refers to converting a page into a table (solid line arrow in the figure, figure when updating from the page before update in FIG. 2B to the page after update in FIG. 2D). 2 (b) → shown in FIG. 2 (a), and an SQL update instruction is applied to the converted table (solid arrow in the figure, shown in FIG. 2 (a) → FIG. 2 (c)) and applied The converted table is converted into a page (shown by solid arrows in the figure, FIG. 2 (c) → FIG. 2 (d)). In other words, this is an update method using a table having a logical structure, and is called logical update.

  On the other hand, physical update refers to the DB area in which the page before update is stored when updating from the page before update in FIG. 2B to the page after update in FIG. This is a process of copying (overwriting) the updated page. In other words, the update method uses the physical structure page as it is without using the logical structure table, and is called physical update.

  The physical update includes a page update that is updated (upgraded) after the update before the update, and a page write-back that is rewritten before the update after the update. In any physical update, since the computer processing is merely data copying to the storage device without interpreting SQL, high-speed processing is possible. That is, there is no overhead due to conversion from the logical structure to the physical structure that has occurred in the update process by SQL, and the time required for the update can be estimated as the disk input / output time.

  Conventionally, all logical updates have been applied to data updates for terminals with lower performance than the center such as embedded systems. At that time, it is difficult to finish the update processing for a large amount of data within a time acceptable for the system. This is because an RDB data update causes an overhead for conversion from a logical structure to a physical structure.

  In an embedded system, especially an embedded system for consumers, due to factors such as cost and power consumption, resources such as CPUs and storage devices that can be used are limited compared to enterprise servers, etc. It has a big influence.

  By the way, in the method for coping with the problem when the two types of updates shown in FIG. 1C are used together, the logical update and the physical update shown in FIG. Can be realized. Details of the speed-up process will be described below.

  First, logical update is applied to terminal side received update from version “1.0” to “1.1”. This is because this is the first time to interpret the input SQL update instruction.

  Next, to write back the terminal-side received update from version “1.1” to “1.0”, the page write-back of the physical update is applied with the backup file as the update source page. Since it is a physical update, high-speed processing is possible.

  Then, in the center side received update from version “1.0” to “2.0”, the center applies a logical update, and each terminal applies a physical update. Since the center side is the first time to interpret the SQL update command input to its own device, logical update is performed. Each terminal then performs a physical update page update using the result of the first logical update. Since it is a physical update, high-speed processing is possible.

  Further, logical update is applied to the terminal side received update from version “2.0” to “2.1”. This is because physical update cannot be applied to interpret the input SQL update instruction.

  As described above, since the physical update can be applied when the center-side received update is reflected on each terminal, high-speed processing is possible. In addition, when configuring a terminal with specifications that do not have terminal-side received updates, it is not possible to have a function for interpreting SQL update instructions, and all updates can be done with physical updates, resulting in smaller and faster equipment. Can be realized.

  FIG. 3 is an explanatory diagram in which two types of updates are used together. FIG. 3A shows eight pages before update. FIG. 3B shows the page after the terminal-side received update for pages C and D is performed with respect to FIG. The version numbers of the updated pages C and D are “1.1”.

  FIG. 3C shows a state in which the center side received update “pages B, D, G, H” is applied without executing the page write-back as the preprocessing in the state of FIG. Although the pages B, D, G, and H are updated to the version “2.0”, the page C remains the version “1.1” because it is not an object of the center side received update. However, page C in the center DB is version “1.0” because no terminal-side received update is performed, and data inconsistency with the terminal DB in FIG. 3C occurs.

  FIG. 3D shows a state in which the center side received update “pages B, D, G, H” is applied after executing the page write-back as the preprocessing in the state of FIG. Page C returns to version “1.0” by the page write-back process. Therefore, the data content is the same as page C of the center DB, and the inconsistency is eliminated.

  FIG. 4 illustrates a backup file used for terminal side received update (version “1.0” → “1.1”) and write back (version “1.1” → “1.0”). It is explanatory drawing to do.

  The backup file 24 is a file that saves the page before the update of the page to be updated when the terminal side received update is performed. However, the page before update is saved only once for each page, and is performed only when the page is updated for the first time.

  FIG. 4A shows that when a terminal-side received update instruction is received, it is saved in the backup file 24 in order to update the page. It is assumed that an SQL update command affected by two pages (page C and page D) out of eight pages (page A to page H) is received. The two pages to be updated are saved by copying them as the backup file 24 before updating.

  FIG. 4B shows a page after the terminal side received update instruction is executed and the page is updated. Of the eight pages (page A to page H), two pages (page C and page D) are changed.

  FIG. 4C shows that the page is written back as a preparation when a center side received update instruction is received. By overwriting the two backup files 24 (pages C and D) saved in FIG. 4A in the corresponding portions, high-speed page write-back is realized.

  FIG. 5 is an explanatory diagram of an update difference file. This update difference file 14 is a page rewrite (page addition, page deletion, and page content change) as a result of performing update processing from before update to after update for each page in the DB area. The page is extracted as a difference.

  The update difference file 14 is notified to each terminal from the center that has executed the center side received update. In this notification, the amount of data can be reduced as compared with a method in which all pages including a page that is not updated are notified collectively.

  It is assumed that 4 pages (pages B, D, G, and H) among 8 pages shown in FIG. 5A are changed and 2 pages (pages I and J) are added. An update difference file shown in FIG. 5B is notified from the center to each terminal, and each terminal reflects the notified update difference file in its own terminal DB. Thereby, the terminal DB is updated as shown in FIG.

  FIG. 6 is an explanatory diagram showing the synthesis process of the update difference file. The plurality of update difference files 14 can be combined into one update difference file 14 according to the version number. For example, the update difference file 14X is for updating version “7.0” → “8.0”, and the update difference file 14Y is updated for version “8.0” → “9.0”. Is for. Since the updated version “8.0” of the update difference file 14X matches the version “8.0” before the update of the update difference file 14Y, both can be combined.

  The update difference file 14X has a page 01a and a page 06 as difference pages. The update difference file 14Y has page 01b, page 07, and page 08 as difference pages. The page 01a and the page 01b are data stored at the same page 01 position.

  The update difference file 14Z has a set of pages (pages 06, 07, 08) in one of the update difference file 14X and the update difference file 14Y. Furthermore, for pages (page 01a, page 01b) that are in the same position in both the update difference file 14X and the update difference file 14Y, the page 01b of the update difference file 14Y with the new (large) version number becomes the update difference file 14Z. included.

  By combining the update difference file 14, it is not necessary to hold all versions of the DB area on the center, and the disk size can be saved. Regarding the newly created update difference file 14Y, the latest version of the update difference file 14 that has already been created (for example, "8.0" of the update difference file 14X) is newly created. The version before update. As a result, since the difference amount is small, the update difference file 14Z can be created at high speed.

  For example, if an update difference file 14 for updating a DB area whose version number is two or more versions away is required, such as an update from version “7.0” to version “9.0”, version “7. The update difference file 14Z of “0” → “8.0” and “8.0” → “9.0” may be synthesized.

  When the update source versions of the terminals are not unified, the center synthesizes the update difference file 14 for each update source version. As a method for the center to acquire the update source version, there are a method for holding the update source version of each terminal on the center side or a method for notifying the update source version from each terminal.

  FIG. 7 is a configuration diagram showing computer hardware for configuring the center and the terminal. The computer includes a CPU 107a, a NIC (Network Interface Card) 107b, a main storage device 107c such as a RAM (Random Access Memory), and an auxiliary storage device 107g such as an HDD (Hard Disk Drive).

  The CPU 107a realizes a DBMS (Data Base Management System) 107d by executing an OS (Operating System) 107f and an application program on the main storage device 107c. The DBMS 107d performs data communication with other apparatuses via the NIC 107b by using the communication management unit 107e.

  As for data exchange between the center and the terminal, as shown in FIG. 7, a storage medium may be used instead of realizing the communication processing utilizing the data communication network of the network via the NIC. For example, when the data output from the center (update difference file or the like) is written in a storage medium such as a DVD-ROM (Digital Versatile Disc-Read Only Memory) and the storage medium is inserted into the terminal, the terminal Data is input by reading the data.

  FIG. 8 is a configuration diagram focusing on the functional units of the computer for configuring the center 1 and the terminal 2 respectively. Each of these functional units is mounted inside or outside the DBMS 107d of the main storage device 107c in FIG.

  The center 1 includes a DB management unit 11, a DB area 12, an update difference file creation unit 13, and an update difference file 14. The terminal 2 includes a DB management unit 21, a DB area 22, a backup file creation unit 23, a backup file 24, a page write-back unit 25, a page update unit 26, an update command history management unit 27, and an update command history file 28. .

  The DB management units 11 and 21 installed in the DBMS receive SQL processing requests to the DB areas 12 and 22 and perform data operation processing corresponding to the requests on the DB areas. The SQL processing request has a format for designating a table having a logical structure and a row therein. Here, the DB management unit 11 of the center 1 processes center side received update, and the DB management unit 21 of the terminal 2 processes terminal side received update.

  The DB areas 12 and 22 are storage areas for storing pages as shown in FIG. As shown in FIG. 2, the DB management units 11 and 21 convert data into operations on pages that are physical structures in the DB areas 12 and 22 when performing data operation processing on tables that are logical structures. Execute.

  The update difference file creation unit 13 creates the update difference file 14 shown in FIG. The backup file creation unit 23 creates the backup file 24 shown in FIG. The page write-back unit 25 and the page update unit 26 perform the physical update described with reference to FIGS.

  The update command history management unit 27 records the SQL update command of the (1) terminal side received update request in FIG. 1C in the update command history file 28 and then notifies the DB management unit 21 of the request. Further, when the (4) terminal side received update request in FIG. 1C is executed again, the SQL update command is read from the update command history file 28 and the request is notified to the DB management unit 21.

  FIG. 9 is an explanatory diagram showing the data structure of the DB area in a tree format. The root direction of the tree is arranged on the left side. A multiplicity is set between the nodes. For example, one DB area 12 includes one page management information and one or more page individual information.

  The page management information indicates information related to one table. As described above, one table is stored in one or more pages. This page management information indicates information common to each page. The number of pages is the number of pages constituting the table. The page size indicates the capacity when stored in a fixed-length page disk. The deletion page number indicates a page number of a page from which deletion is started for deleting pages after a certain page number in the DB area before update. The update flag array will be described later.

  The page individual information indicates information related to one page. The page number indicates the position of the page in the DB area.

  One update flag sets whether the DB area 12 of the center 1 has been updated (value “1”) or not (value “0”). The update flag array is an array of update flags. Since the update flags for the number of pages and one update flag array indicate the same contents, either one may be configured as described later. The page data indicates the data content of the page. The value of the update flag array or the update flag is referred to when the update difference file 14 is created. After the update difference file 14 is created, the value is cleared to “0”.

  The difference between the DB area 12 and the DB area 22 is that the update flag in the DB area 12 is changed to a backup flag in the DB area 22. The backup flag sets whether the page is saved in the backup file 24 (value “1”) or not (value “0”) when the page is updated.

  In the first update process, the backup flag corresponding to the page to be backed up is changed from the value “0 (not backed up)” to the value “1 (backed up)”. In the second and subsequent times, the backup flag corresponding to the page to be backed up is referred to, and if the value is “1”, the backup process is omitted. When the backup file 24 is used for the write-back process, the value may be returned to the value “0” and the backup file 24 that is no longer needed after use may be deleted.

  FIG. 10 is an explanatory diagram of the update flag and the update flag array described in FIG. It is assumed that six updates (pages B, D, G, H, I, and J) have been performed on the eight pages shown in FIG. FIG. 10 (b) summarizes the presence / absence of those updates as an update flag array, and FIG. 10 (c) shows the presence / absence of those updates individually stored as update flags in the upper left of each page. is there.

  FIG. 11A shows a data structure for storing the update difference file 14 shown in FIG. One update difference file 14 includes one version information, one page management information, and one or more difference pages.

  The version information is composed of a set of a pre-update version and a post-update version. The version information is composed of information such as a version number and a creation date.

  The page management information is information common to the difference pages stored in the update difference file 14. The page management information includes the number of pages stored in the update difference file 14, the page size of the stored pages, and the first page number of the page to be deleted from the target DB area during the physical center side received update process. It is configured.

  The difference page is a page in the DB area and is an updated page. The difference pages are in page number order. If the difference pages are sequentially copied to the update destination DB area, the movement amount of the disk header can be minimized and the performance of the update process can be further improved. In addition, each difference page is associated with a page number indicating a corresponding portion to be arranged. Therefore, the update process of the DB area on the terminal only needs to copy the update page to the location specified by the page number.

  FIG. 11B shows a data structure for storing the backup file 24 shown in FIG. One backup file 24 includes one backup management information and one or more backup pages. The backup page indicates the page contents before update saved from the DB area.

  The backup management information includes free capacity, page size, number of pages, and new page allocation information. The free space is an area for storing the free space of the backup file 24.

  The page size is an area that stores the size (page size) of the backup page stored in the backup file 24. The number of pages is an area for storing the number of backup pages in the backup file.

  The new page allocation information is an area for storing information when the DB area is expanded and a new page is added and allocated in the process of updating the DB area. The allocation flag is a flag indicating whether a new page is added (value “1”) or not (value “0”). The start position is a page number indicating the start position of the added new page. The number of pages is the number of added new pages.

  FIG. 12 is an explanatory diagram showing the operations of the center 1 and the terminal 2 when the “(3) center side received update” of FIG. In this figure, the case where the terminal-side received update is not performed and the version before update is the same in the center 1 and the terminal 2 will be described. For example, the terminals B and C in FIG.

  The DB area 22 of the terminal 2 makes the contents the same as the DB area 12 of the center 1 every time a certain period or more passes. The terminal 2 creates a DB area 22 that is a copy of the DB area 12 at a timing such as factory shipment. The state of the database at this time is assumed to be version “1.0”.

  The DB management unit 11 of the center 1 repeats the center-side received update for the DB area 12 and temporarily freezes the update at an appropriate stage. The DB area 12 at that time is assumed to be version “2.0”. Then, the update difference data creation unit 13 of the center 1 extracts the update difference file 14 between the version “1.0” and the version “2.0”.

  For example, the difference data creation unit 13 compares the version “1.0” saved in advance with the latest version “2.0” for each page, and the version “2.0” of the page with the difference is displayed. In the update difference file 14.

  When the page update unit 26 of the terminal 2 receives the update difference file 14 from the center 1, it overwrites the page in the update difference file on the corresponding page in the DB area 22. By this processing, the versions of the center 1 and the terminal 2 become the same “2.0”.

  FIG. 13 is an explanatory diagram showing the operations of the center 1 and the terminal 2 in order from “(1) terminal side received update” to “(4) terminal side received update again” in FIG. is there. In this figure, a case where the pre-update version does not match between the center 1 and the terminal 2 by performing terminal side received update will be described. For example, the terminal A in FIG. 1A corresponds to the description of this figure.

  First, as described with reference to FIG. 12, the DB area 12 of the center 1 and the DB area 22 of the terminal 2 are set to version “1.0”.

  The DB management unit 21 of the terminal 2 performs “(1) terminal side received update”. Specifically, when an SQL update command is received, a data operation based on the command is performed on the DB area 22 to update the version to “1.1”. Here, the backup file creation unit 23 saves the page of the version “1.0” in the backup file 24 before executing the update to the version “1.1”. Note that the page with the backup flag “1” has already been backed up, so there is no need to make a duplicate backup.

  The page write-back unit 25 of the terminal 2 performs “(2) terminal-side received update write-back”. Specifically, the backup file 24 of the version “1.0” is overwritten on the DB area 22 updated to the version “1.1”, thereby writing back to the version “1.0”. Thereby, the version before update becomes the same in the center 1 and the terminal 2.

  The center 1 performs “(3) Center side received update” as described in FIG. As a result, the DB area 22 is updated from version “1.0” to version “2.0”.

  The update command history management unit 27 of the terminal 2 records the SQL update command at the time of “(1) terminal side received update” in the update command history file 28, and the update command history file 28 is again stored in the DB management unit 21. To execute “(4) Re-execute terminal side received update”. As a result, the DB area 22 is updated from version “2.0” to version “2.1”.

  FIG. 14 illustrates three methods for realizing the process in which the update difference data creation unit 13 of the center 1 creates the update difference file 14. By applying any one of the three methods, the update difference file 14 is created.

  FIG. 14A shows a full text comparison without using an update flag.

  The update difference data creation unit 13 saves all data in the DB area before update (version “1.0”), and does nothing particularly when applying the SQL update instruction. When creating the update difference file 14, the update difference data creation unit 13 compares all the data before and after the update to extract pages that do not match, and creates the update difference file 14.

  According to this method, no processing occurs when applying the SQL update instruction, so that the throughput of the SQL update instruction can be improved. Further, since there is no need to use an update flag, a simple data structure is sufficient, and the influence of expansion to an existing system can be reduced.

  FIG. 14B shows a method for setting the update flag outside the page of the DB area. When applying the SQL update instruction, the update difference data creation unit 13 sets the update flag corresponding to the updated page in the update flag array outside the page (see FIG. 10B). When creating the update difference file 14, the update difference data creation unit 13 extracts the updated page in which the update flag is set, and creates the update difference file 14.

  By this method, the update flag array is read to identify the page to be updated, so that it is not necessary to access the data content of the page, and the high-speed update difference file 14 can be created. Since the update flag array is gathered in one place, disk access becomes faster. Furthermore, since it is not necessary to save all data in the DB area before update (version “1.0”), the disk capacity can be saved.

  FIG. 14C shows a method for setting the update flag in the page of the DB area. The difference from FIG. 14B is that an update flag (see FIG. 10C) set in the page is used instead of using the update flag array.

  By this method, in addition to the effect of saving the disk capacity described with reference to FIG. 14B, the update flag is embedded as page unit information, and it is not necessary to create another data unlike the update flag array. The amount of change from the existing system can be reduced and the development cost can be reduced.

  FIG. 15 is a flowchart showing terminal-side received update processing executed by the DB management unit 21 of the terminal 2.

  First, an SQL update command is received and a page to be updated is specified from the DB area (S101). Next, it is determined whether or not the backup flag of the specified page is “1” (S102). If Yes in S102, the process proceeds to S108, and if No, the process proceeds to S103.

  Then, it is determined whether the new page allocation flag in the backup file is “1” and the start position of the new page allocation information in the backup file is smaller than the page number of the specified page (S103). If Yes in S103, the process proceeds to S107, and if No, the process proceeds to S104.

  Further, it is determined whether there is sufficient free space in the backup file (S104). If Yes in S104, the process proceeds to S106, and if No, the process proceeds to S105. Then, the update process is interrupted as an error state (S105), and the process ends.

  If Yes in S104, a copy of the identified page is stored in the backup page in the backup file (S106). Then, the backup flag of the specified page is set to “1” (S107). Then, the contents of the specified page are updated (S108).

  Here, it is determined whether or not the free area of the DB area is small (S109). If Yes in S109, the process proceeds to S110, and if No, the process ends. If YES in S109, a new page is allocated to the DB area (S110), the new page allocation information is updated (S111), and the process is terminated.

  FIG. 16A is a flowchart showing backup file update processing executed by the backup file creation unit.

  First, it is determined whether or not the allocation flag of the new page allocation information in the backup file is “1” (S201). If Yes in S201, the process proceeds to S203, and if No, the process proceeds to S202. Next, the start position is set for the new page allocation information in the backup file, and the allocation flag is set to “1” (S202). Then, for the new page allocation information in the backup file, the number of pages allocated this time is added to the value of the number of pages (S203).

  FIG. 16B is a flowchart showing page write-back processing using a backup file executed by the page write-back unit.

  First, backup pages are selected from the backup file in order of page number (S301). Next, the selected backup page is overwritten and copied to a page having the same page number in the DB area (S302).

  Here, it is determined whether or not there is an unselected backup page in the backup file (S303). If Yes in S303, the process proceeds to S301, and if No, the process proceeds to S304. Also, it is determined whether the allocation flag in the backup file is “1” (S304). If Yes in S304, the process proceeds to S305, and if No, the process proceeds to S306.

  Then, all pages on the DB area having page numbers after the page number at the start position in the backup file are deleted (S305). Further, the backup file is cleared, that is, the free space is cleared to the file size, the number of pages is set to “0”, and the new page allocation information is cleared to 0 (S306).

  FIG. 17 is a flowchart illustrating a method (see FIG. 14A) of full-text comparison without using an update flag in the update difference file creation processing executed by the update difference file creation unit.

  First, it is determined whether or not an unselected page exists in the updated DB area (S401). If Yes in S401, the process proceeds to S402, and if No, the process proceeds to S407. Next, an unselected page is selected from the updated DB area (S402). Then, it is determined whether a page with the same page number as the selected updated page exists in the DB area before update (S403). If Yes in S403, the process proceeds to S404, and if No, the process proceeds to S406.

  Then, a page with the same page number is selected from the DB area before update (S404). Here, it is determined whether or not the contents of the selected pre-update and post-update pages match each other (S405). If Yes in S405, the process proceeds to S401, and if No, the process proceeds to S406. Further, the page selected from the updated DB area is stored as a difference page in the update difference file (S406), and the process returns to S401.

  By the way, if No in S401, it is determined whether or not an unselected page exists in the DB area before update (S407). If Yes in S407, the first page of the unselected pages is set as the deletion start page ( S408).

  FIG. 18A shows an update flag setting executed by the DB management unit at the time of update for executing the method of setting the update flag outside the page (see FIG. 14B) in the update difference file creation process. It is a flowchart which shows a process.

  First, an update page is specified (S501), and the specified page is rewritten (S502). Next, the bit corresponding to the page number of the specified page is changed to “1” in the update flag array located outside the page (S503). When there is another page to be updated (S504, Yes), the process returns to S501 for the page to be updated.

  FIG. 18B is a flowchart showing the update difference file creation process executed by the update difference file creation unit based on the update flag set in FIG. 18A in the update difference file creation process. is there.

  First, when there is no bit having a value of “1” in the update flag array (S511, No), the process is terminated. Next, the corresponding page number is obtained from the bit arrangement position where the value in the update flag arrangement is “1” (S512). Then, the rewritten page having the obtained page number is taken out from the DB area, the page is added to the difference page of the update difference file (S513), and the process returns to S511.

  FIG. 19A shows an update flag setting executed by the DB management unit at the time of update for executing a method of setting an update flag in a page (see FIG. 14C) in the update difference file creation process. It is a flowchart which shows a process.

  First, an update page is specified (S601), and the specified page is rewritten (S602). Next, the update flag of the page individual information corresponding to the specified page is changed to the value “1” (S603). If there is another page to be updated (S604, Yes), the process returns to S601 for the page to be updated.

  FIG. 19B is a flowchart showing the update difference file creation process executed by the update difference file creation unit based on the update flag set in FIG. 16A in the update difference file creation process. is there.

  First, one page in the DB area is selected in order from the top (S611). Next, it is determined whether or not the update flag of the page individual information corresponding to the selected page is “1” (S612). If Yes in S612, the process proceeds to S613, and if No, the process proceeds to S615.

  Then, a copy of the selected page is taken out from the DB area, and the page is added to the difference page of the update difference file (S613). Further, the update flag of the selected page is returned to “0” (S614). Here, it is determined whether there is an unselected page (S615). If Yes in S615, the process proceeds to S611. If No, the process ends.

  FIG. 20 is a flowchart showing the page update process of the center side received update process executed by the page update unit.

  First, difference pages are selected from the update difference file in the order of page numbers (S701). Next, the selected difference page is overwritten on the page having the same page number in the DB area (S702). Here, when there is an unselected difference page (S703, Yes), the process returns to S701, and when there is no difference page (S703, No), the process ends.

  FIG. 21 shows a configuration of a computer that realizes each of the center and the terminal in this embodiment. The computer includes a CPU 107a, a NIC (Network Interface Card) 107b, a main storage device 107c such as a RAM (Random Access Memory), and an auxiliary storage device 107g such as an HDD (Hard Disk Drive).

The CPU 107a realizes a DBMS (Data Base Management System) 107d by executing an OS (Operating System) 107f and an application program on the main storage device 107c. The DBMS 107d performs data communication with other apparatuses via the NIC 107b by using the communication management unit 107e.
The DBMS 107d corresponds to a database management unit. The database management unit executes data access to the logical structure data of the database. The logical structure data may be in a table format as shown in FIG. 2, for example, or may be in other formats such as tree structure data suitable for storing XML (Extensible Markup Language) data.

  As for data exchange between the center and the terminal, a storage medium may be used instead of realizing communication processing utilizing a data communication network of a network via NIC. For example, when the data output from the center (update difference file or the like) is written in a storage medium such as a DVD-ROM (Digital Versatile Disc-Read Only Memory) and the storage medium is inserted into the terminal, the terminal Data is input by reading the data.

  The center 1 has a DB management unit 11 and an update difference file creation unit 13 as a configuration of the DBMS 107d, and has a DB area 12 and an update difference file 14 as a configuration of the auxiliary storage device 107g. In this embodiment, the DB management unit 11 and the update difference file creation unit 13 are shown as an example realized by a program, but may be realized by an object and hardware having the function.

  The terminal 2 includes a DB management unit 21, a backup file creation unit 23, a page write-back unit 25, a page update unit 26, and an update command history management unit 27 as a configuration of the DBMS 107d, and a DB as a configuration of the auxiliary storage device 107g. It has an area 22, a backup file 24, and an update command history file 28. In this embodiment, the DB management unit 21, the backup file creation unit 23, the page write-back unit 25, the page update unit 26, and the update command history management unit 27 show an example realized by a program. You may implement | achieve with the hardware which has. These programs may be stored in a storage medium such as a CD-ROM or DVD-ROM and installed in the storage device before the system is operated.

  The DB management units 11 and 21 installed in the DBMS receive SQL processing requests to the DB areas 12 and 22 and perform data operation processing corresponding to the requests on the DB areas. The SQL processing request has a format for designating a table having a logical structure and a row therein. Here, the DB management unit 11 of the center 1 processes the center side received update.

  The DB management unit 21 in the terminal 2 processes terminal side received update.

  The DB areas 12 and 22 are storage areas for storing pages as shown in FIG. As shown in FIG. 2, the DB management units 11 and 21 convert data into operations on pages that are physical structures in the DB areas 12 and 22 when performing data operation processing on tables that are logical structures. Execute.

  The update difference file creation unit 13 creates the update difference file 14 shown in FIG. The backup file creation unit 23 creates the backup file 24 shown in FIG. The page write-back unit 25 and the page update unit 26 perform the physical update described with reference to FIGS.

The update command history management unit 27 records the SQL update command of (1) “terminal side received update request” in FIG. 1C in the update command history file 28 and then notifies the DB management unit 21 of the request. When the (4) “terminal side received update request” in FIG. 1C is executed again, the SQL update command is read from the update command history file 28 and the request is notified to the DB management unit 21.
Note that the operating subject that executes (4) “terminal side received update request” in FIG. 1C again may be the terminal 2 or the center 1. When the center 1 causes the terminal 2 to execute the “terminal side received update request” again, a control command indicating that is transmitted to the terminal 2. The terminal 2 waits for the reception of the control command, and then reapplies the “terminal side received update request” received by the terminal 2 in the past.

It is explanatory drawing which shows the outline | summary of the whole database system regarding this embodiment. It is explanatory drawing which shows the relationship between the table of the logical structure in RDB regarding this embodiment, and the page of a physical structure. It is explanatory drawing which shows that two types of update regarding this embodiment are used together. It is explanatory drawing which shows the backup file regarding this embodiment. It is explanatory drawing which shows the update difference file regarding this embodiment. It is explanatory drawing which shows the synthetic | combination process of the update difference file regarding this embodiment. It is a block diagram which shows the hardware constitutions of the center and terminal regarding this embodiment. It is a block diagram which shows the function structure of the center and terminal regarding this embodiment. It is explanatory drawing which shows the data structure of DB area | region regarding this embodiment. It is explanatory drawing which shows the update flag and update flag arrangement | sequence regarding this embodiment. It is explanatory drawing which shows the data structure of the update difference file and backup file regarding this embodiment. It is explanatory drawing which shows the operation | movement of the center side reception update regarding this embodiment. It is explanatory drawing which shows operation | movement when it implements in order from terminal side reception update regarding this embodiment to terminal side reception update again. It is explanatory drawing which shows three methods which produce the update difference file regarding this embodiment. It is a flowchart which shows the terminal side reception update process regarding this embodiment. It is a flowchart which shows the update process of the backup file regarding this embodiment, and the page write-back process using the backup file. It is a flowchart which shows the system which compares the whole sentence without using an update flag among the preparation processes of the update difference file regarding this embodiment. It is a flowchart which shows the system which sets an update flag outside a page among the production processes of the update difference file regarding this embodiment. It is a flowchart which shows the system which sets an update flag in a page among the preparation processes of the update difference file regarding this embodiment. It is a flowchart which shows the page update process of the center side reception update process regarding this embodiment. It is a block diagram which shows the structure of the computer of the center and terminal regarding this embodiment.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Center 11 DB management part 12 DB area 13 Update difference file creation part 14 Update difference file 2 Terminal 21 DB management part 22 DB area 23 Backup file creation part 24 Backup file 25 Page write-back part 26 Page update part 27 Update command history management Part 28 Update command history file

Claims (4)

A database system that has database management units for managing versions of logical structure data of a database as a physical structure page stored in a file of a disk device for each version, and operates the same version. A data update method executed by
The center device is
In response to an input of a center device side acceptance command that the center device representatively accepts the update content common to each terminal, the result applied to the logical structure data is stored in a page in the DB area of the file,
For the page in the DB area, the center device side acceptance command is applied when creating an update difference file indicating a difference page in which the data change from the pre-update version to the post-update version by the center device side acceptance command is made. When applying to the page in the DB area of the version before update, the update flag indicating that the page has been updated is updated for the location corresponding to the updated page of the update flag array corresponding to the page array. Set, refer to the update flag array in order, extract the page where the update flag has been updated as a difference page,
The terminal
Update the updated difference file of the updated difference file notified from the center apparatus to the updated version after the application instruction for the center apparatus is applied by overwriting the page in the DB area of the terminal. A data update method characterized by: The terminal
In response to an input of a terminal-side acceptance instruction indicating update contents applied to the terminal, the result applied to the logical structure data is stored in a page in the DB area of the file,
About the page in the DB area, for the page in which the data change from the pre-update version to the post-update version by the terminal side acceptance instruction, the pre-update version page is stored in the backup file as a backup page,
Before the data update using the update difference file, for the page where the data change to the updated version by the terminal-side acceptance instruction, the backup page is overwritten,
In response to the input of the terminal side reception instruction, in the step of applying to the logical structure data, further, the input terminal side reception instructions are ordered and recorded in the update instruction history file,
After the step of overwriting the difference page on the page in the DB area of the terminal, the terminal-side acceptance command read from the update command history file for the logical structure data composed of the updated version of the page The data update method according to claim 1, wherein the data update methods are applied in order. The terminal
In response to the input of the terminal side reception instruction, the result applied to the logical structure data is stored in a page in the DB area of the file,
About the page in the DB area, for the page in which the data change from the pre-update version to the post-update version by the terminal side acceptance instruction, the pre-update version page is stored in the backup file as a backup page,
Before the data update using the update difference file, for the page where the data change to the updated version by the terminal-side acceptance instruction, the backup page is overwritten,
The process of storing in the backup file is
When the page to be updated is stored as the backup page by the terminal-side acceptance instruction this time, the backup flag of the page to be updated indicating that it has been stored is set to stored,
2. The data update method according to claim 1, wherein when the backup flag is already updated by the terminal-side reception instruction after the next time, the storage process of the backup page for the page is omitted. . A database system that has database management units for managing versions of logical structure data of a database as a physical structure page stored in a file of a disk device for each version, and operates the same version. Because
The center device is
In response to an input of a center device side acceptance command that the center device representatively accepts the update content common to each terminal, the result applied to the logical structure data is stored in a page in the DB area of the file,
For the page in the DB area, the center device side acceptance command is applied when creating an update difference file indicating a difference page in which the data change from the pre-update version to the post-update version by the center device side acceptance command is made. When applying to the page in the DB area of the version before update, the update flag indicating that the page has been updated is updated for the location corresponding to the updated page of the update flag array corresponding to the page array. Set, refer to the update flag array in order, extract the page where the update flag has been updated as a difference page,
The terminal
Update the updated difference file of the updated difference file notified from the center apparatus to the updated version after the application instruction for the center apparatus is applied by overwriting the page in the DB area of the terminal. A database system characterized by

Images