[go: up one dir, main page]

WO2005086003A1 - データベース・システム - Google Patents

データベース・システム Download PDF

Info

Publication number
WO2005086003A1
WO2005086003A1 PCT/JP2005/003914 JP2005003914W WO2005086003A1 WO 2005086003 A1 WO2005086003 A1 WO 2005086003A1 JP 2005003914 W JP2005003914 W JP 2005003914W WO 2005086003 A1 WO2005086003 A1 WO 2005086003A1
Authority
WO
WIPO (PCT)
Prior art keywords
database
record
column
block
location
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2005/003914
Other languages
English (en)
French (fr)
Inventor
Masaharu Tamatsu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Annex Systems Inc
Original Assignee
Annex Systems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Annex Systems Inc filed Critical Annex Systems Inc
Priority to JP2006510776A priority Critical patent/JPWO2005086003A1/ja
Publication of WO2005086003A1 publication Critical patent/WO2005086003A1/ja
Priority to US11/530,342 priority patent/US20070078909A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/221—Column-oriented storage; Management thereof

Definitions

  • the present invention relates to a database 'system for storing and retrieving data in a computer.
  • indexes have a hierarchical structure, so if index updates are performed by data insertion or deletion, the exclusion range is changed because the upper indexes may be changed. There was a disadvantage such as widening and causing a deadlock.
  • This database 'system had the following problems.
  • data item changes and additional 'deletion' changes may occur.
  • the operation of the database system is stopped, the definition of the database is changed, the data is changed, and then the database system is operated. This kind of work is long time said several hours In the meantime, shutting down the database is a major limitation for systems that require continuous operation!
  • the embodiments of the present invention can solve the following problems.
  • the conventional database can not handle the latest record format. These records are stored in multiple formats and can be searched, added, updated, and deleted from those records, so that there is historical data storage management that has never been done before.
  • the present invention in a database 'system for storing and retrieving data, records defined by a database definition of one purgeon into records defined by a database definition of another version.
  • records defined by a database definition of one purgeon are recorded into records defined by a database definition of another version.
  • a database system equipped with In a database system equipped with.
  • FIG. 1 is a format of a database described in the specification.
  • FIG. 2 illustrates the reorganization for the primary 'block and overflow' blocks.
  • FIG. 3 is a database for performing column tracking. Here, the alternative key is omitted.
  • Figure 5 is a diagram of the column addition: past retrospective type 'child database method, and progressed to the middle of the case of adding column b. In this figure, it indicates that the column addition up to record 2 is finished ing.
  • FIG. 6 is a diagram of database definition and definition cross. Reference. Table in the case of adding column b in column addition: past retrospective type 'child database method.
  • the database definition shows VI and V2.
  • VI is a database definition before adding a column
  • V2 is a database definition after adding a column.
  • Figure 7 shows the database in the state where the addition of column b is completed in the column addition: past retrospective type 'child database method.
  • Figure 8 shows the state in which the record tracking is performed after the addition of the column b is completed in the column addition: past retrospective type 'child database method.
  • ⁇ 9] is a diagram of the column addition: past retrospective type ⁇ In the case of adding column b by the direct addition method, it has advanced to the middle of the process. This figure shows the state where reorganization has been completed up to record 3.
  • FIG. 10 is a diagram of database definition and definition cross 'reference' table when adding a column in the column addition: past retrospective type ⁇ direct addition method.
  • VI be the database shown in the database in Figure 3 and the database definition in Figure 4, and let V2 be the database definition after adding a column.
  • Figure 11 shows the state where the addition of a column is completed when adding a column by the column addition: past retrospective type ⁇ direct addition method.
  • Figure 12 shows the database definition with the column addition completed when adding a column by the column addition: past retrospective type ⁇ direct addition method.
  • Figure 13 is a diagram of a database where column addition: past non-recursive type ⁇ column addition by child database method is performed.
  • Figure 14 is a diagram of the time when preparation work is completed when adding a column: past non-recursive type ⁇ adding a column by a child database method.
  • FIG. 15 is a diagram at the time when a record with added columns is stored in the database by the column addition: past non- retroactive type 'child database method.
  • Figure 16 is a diagram of column definition: database definition body and definition body cross reference 'table when performing column addition in the past not retrospective type / child database method.
  • Figure 17 shows the version of the database definition that created the record in the record It is a figure in the case of holding.
  • FIG. 18 is a diagram in the case of holding the version of the database definition which created the record in the block in the block.
  • Figure 19 is a diagram of column addition: past non-recursive type ⁇ database definition body and definition body of direct addition method cross ⁇ reference ⁇ reference ⁇ tape nore.
  • Figure 20 is a diagram in which the records where column addition has been performed by column addition: past non-forward type ⁇ direct addition method are stored on the database.
  • FIG. 21 is a diagram of a database definition and a definition cross 'reference' table when combining a child database created by the column addition: child database method into a parent database.
  • FIG. 22 is a diagram in which the summary up to record 3 has been completed when putting together the child database created by the column addition: child database method into the parent database.
  • Figure 23 is a diagram in which the summary is complete when putting together the child database created by the column addition: child database method into the parent database.
  • Figure 24 is a diagram of the database definition body and the logical structure conversion table at the time of completion when the child databases created by the column addition: child database method are put together in the parent database.
  • Figure 25 is a diagram of column deletion: definition deletion method.
  • FIG. 26 is a diagram of the database definition and the logical structure conversion tape in the case of the column deletion: definition deletion method.
  • Figure 27 is a diagram of column deletion: past holding ⁇ database to which child database method is applied.
  • Figure 28 is a diagram of the database when column deletion: past retention 'child database method is applied and preparation work is completed.
  • Figure 29 is a diagram of the database definition body and the logical structure conversion table when the column deletion: past retention 'child database method is applied and preparation is completed.
  • FIG. 30 is a diagram of the database at the end of the processing up to record 3 applying the column deletion: past retention 'child database method.
  • Figure 31 is a diagram of the database when processing is completed with column deletion: past retention, child database method applied.
  • FIG. 32 is a figure at the time when processing up to re Cord 3 is completed by applying the column deletion: past non-holding type 'direct column deletion method.
  • FIG. 33 is a diagram of a database definition and a logical structure conversion table when column deletion: past non-holding type ⁇ direct column deletion method is applied.
  • ⁇ 34] is a diagram of a database definition and a logical structure conversion table after column deletion when column deletion: past non-holding type 'direct column deletion method is applied.
  • ⁇ 35] is a diagram of the database when column deletion is completed when column deletion: past non-holding type ⁇ direct column deletion method is applied.
  • FIG. 36 is a diagram showing an overflow block management table.
  • Figure 37 is a diagram in the case where a database with an overflow block management table is applied to the child database method.
  • Figure 38 shows the case where the database using overflow 'block management table is applied to the column addition: direct addition method.
  • FIG. 39 is an example of performing some reorganization at high speed by applying the method of reducing the initial capacity of the new location 'table at the time of reorganization.
  • FIG. 40 is a diagram showing the principle of an accelerator system.
  • FIG. 41 shows an overflow block management table for the accelerator system.
  • Figure 44 is a diagram of how multiple columns become one alternative key when applied to XML.
  • FIG. 45 is a diagram of alternate key entry in the case of making multiple columns into one alternate key.
  • FIG. 46 is a diagram for processing a record read request in the case of the past non retrospective type.
  • FIG. 47 is a diagram for processing a record update request in the case of the past non retrospective type.
  • FIG. 48 is a diagram for processing a record deletion request in the case of the past non retrospective type.
  • FIG. 49 is a diagram for processing a record addition request in the case of the past non retrospective type.
  • FIG. 50 is a diagram for processing a record read request in the case of the retrospective type.
  • FIG. 51 is a diagram for processing a record update request in the case of the retrospective type.
  • FIG. 52 is a diagram for processing a record deletion request in the case of the retrospective type.
  • FIG. 53 is a diagram for processing a record addition request in the case of the retrospective type.
  • FIG. 54 is an example of a logical structure conversion table.
  • FIG. 55 is an example of performing logic structure conversion with logic.
  • Figure 56 is an example of creating a new database definition from an arbitrary database definition.
  • FIG. 57 is an example of a parent database and a child database.
  • a record always has one unique primary key and zero or more non-unique keys (alternative keys, which may result in uniqueness).
  • an item (row) that is not a key.
  • the primary key is a code that can identify an employee, such as an employee code
  • the alternative key is a name or date of birth, etc.
  • serial numbers etc. in storage order and use them as primary keys.
  • An item (column) is a unit of information and there are items that can be key and items that can not be key. One or more exist in the record.
  • the columns may be of fixed-length or variable-length format.
  • variable-length format it is possible to make variable length for each column, and it is also possible to recognize a column without column information as a column.
  • Records can be viewed as a logical collection.
  • a set of items subordinate to a primary key can be defined as a broad logical record. However, not all items subordinate to the primary key are always one logical record. For example, according to employee code When considering the items to which it belongs, there are information such as name, date of birth, date of joining affiliation, e-mail address, extension number and so on. In addition, there is information such as address, school of origin and family. Besides, there is also information on salary and bonus. In addition, there is also evaluation result information.
  • employee master should have a name, date of birth, date of joining, affiliation, e-mail address, and extension number.
  • employee personal file include the address, school from which you are from, and your family.
  • the employee salary file contains salary and bonus information.
  • the employee evaluation file contains the evaluation results. In this way, a logical record subordinate to the employee code is created. Also, these logical records can consist of multiple physical records. Take, for example, an employee evaluation file. In the past, it was assumed that the superior had adopted a method in which the superior scored the evaluation item. On the other hand, it is assumed that the evaluation of subordinates will be added.
  • a database definition is used to define a database in a general database system.
  • the database definition holds a wide range of information such as physical structure, logical structure, storage structure, index configuration information, and attributes regarding the database, it shall have at least RAID configuration information.
  • Record configuration information is information including physical structure, logical structure, and attribute information.
  • the term database definition is used to explain, but the contents relate to record configuration information. That is, the record configuration information in the database definition is called a database definition.
  • adding, deleting, or changing columns in the same table changes the logical structure or physical structure of the record, but the database is newly created according to the change. Let the definition be the database definition of the new version.
  • a table means a file (for example, an employee master, a customer master, a goods master, an accounts receivable file, etc.) which is generally used in a database and has row and column powers, which will be described later. It is different from 'tape alternate key / location' table, logical structure conversion table, etc.
  • the various tables used in this specification are called by the names of location 'table, alternative key' location 'table, logical structure conversion table, etc., and they are simply not called tables!
  • FIG. 46 shows the case of accessing the database from multiple versions of application programs. This figure illustrates READ processing (read processing is often SELECT in SQL).
  • the application 'request source such as program 30 directs a READ command to the database system. In the database system, request reception processing 31 is performed, and then index search processing 32 is performed.
  • the record is read from the block etc. where the record is stored (the database ⁇ names differ according to the system). It then converts the read records into the logical structure of that version. Then, using the logical structure conversion unit, conversion is performed to the version of the database definition of the application program.
  • the logical structure conversion unit converts a record defined by a database definition of one version into a record defined by a database definition of another version, for example, a logical structure conversion table or a logical structure conversion. Program 'logic' etc can be used. Pass the converted records to the application 'program.
  • the column addition can be roughly divided into two methods, the retroactive type and the retroactive type. Each type is further divided into a child database addition method and a direct addition method. There are four possible implementations.
  • a database storing columns to be added is defined as another new database (child database) separately from the existing database to which column addition is performed, and the primary key of the existing database and the addition are added.
  • a set of columns (items) are paired to form a record (child record), and the primary key of the new database is a method of setting the primary key of the existing database and creating a child record in the new database.
  • the direct column addition method is a method of directly adding columns to an existing database. This is implemented by applying the method described in "Database Reorganization System”. Column addition is performed for each record, but the unit of processing is a block. For the current location 'table, prepare a new location' table so that the block for which the row tracking is performed is managed by the new location 'table. Read the records sequentially, add columns to the existing database, and store the records in the block again. Write the address of the block to the new location 'table. In this method, the record with the new column added is stored in the existing database, and the block added with the record added is mixed with the block stored in the existing database. , Use column manipulation pointers to separate them.
  • column operation completion pointer is used to determine the completion point of column addition.
  • column operation pointer 1 points to the next address of the entry 1 pointing to the last block in which the column addition of each location.table is completed.
  • Column Manipulation Pointers are for existing and new locations Hold the table one by one.
  • the database is divided into two, the advantage is that the load on creation is light. Because the database is divided into two, the added database must also have a location table and a primary key. The database should be larger by that amount. In addition, it is necessary to access two databases to retrieve one record, and the load on the system increases accordingly. However, if there are a lot of accesses that specify items with less access to the entire record, and there are few applications that use the added items, it may be efficient. It is necessary to use properly according to the situation.
  • deletion of a column can be roughly divided into two types: past-held and past-non-held.
  • the past retention type is further divided into a definition deletion method and a child database method.
  • the past non-holding type is only the direct column deletion method.
  • the definition deletion method is a method of deleting a column to be deleted on the definition and leaving the actual deletion unnecessary. With this method, deletion is only required to change the definition of the database, so work is completed in a very short time. Reading records is performed with the record length actually written on the database, but when passing a record to the application program, the deleted column will be deleted and passed from the record. On the other hand, when passing a record to an application program using an old database definition, it is possible to make the record contain the deleted column.
  • the child database method is implemented using a method similar to the method of performing reorganization using the “database reorganization system”, but deleting a column from the record and deleting the record after the column deletion is performed. Write back. Furthermore, the deleted item and the primary key of the original database are combined to create a new record, and the record is written to the child database. Since this method creates a new database at the time of column deletion, there is a disadvantage that it takes extra time for column deletion. It is possible to avoid the situation that the program can not be run if it exists. In the case of the child database method as well as the definition deletion method, an application using an old database definition 'when passing a record to a program, it is possible to use a record that contains deleted columns. It becomes.
  • the past non-holding type is a method of deleting the deletion target column from the record before deletion and writing the shortened record after deletion back to the database.
  • This method can be realized by using a method similar to the method of reorganization using the “database reorganization system”.
  • the new location 'table is used for the current location table, and the address of the block storing the record after column deletion is held by the new location' table.
  • Column changes are about attributes and lengths. If this is classified, if there is no change in length due to a change in the attribute of the column, if there is no change in the attribute of the column and the length changes, then both the attribute and the length of the column change. There will be three.
  • An attribute is a type of information stored in the column, and has attributes such as numeric values, characters, and dates.
  • the retrospective type is a method of changing the length of the change column of the existing record to the length of the new database definition.
  • changes to existing records are similar to the method described in the column addition: retrospective type.
  • the past non-retroactive type no change is made to the existing record, and the length of the change column of the record created using the latest database definition is changed in the newly created record. It will be done.
  • the database definition is as follows.
  • the first database definition is manually created by the system administrator. Let this be version 1 (VI).
  • V2 be the database definition after the addition. This V2 provides the system administrator with the power to add which column to which position of VI, and the method to follow as a child database method or a direct addition method.
  • V2 creates a definition of a new VI.
  • the physical structure has changed, for example, when the database becomes a single database due to reorganization with force V2, which was a form of a child database method in VI, but the logical structure does not change. .
  • a logical structure conversion table of VI and V2 is created. This shows how each column of VI and each column of V2 correspond to each other.
  • the logical structure conversion table is a table in which the logical structure of the database definition of each purgeon is extracted and arranged in rows. This logical structure conversion table enables conversion of logical structures between versions.
  • FIG. 54 shows an example of the logical structure conversion table.
  • FIG. 46 is a diagram related to the past non- retroactive type READ processing.
  • FIG. 50 is a diagram related to the retrospective type of READ processing.
  • the past non retrospective type is a type that does not reflect (does not retroactively reflect) a newly added column to a record that has already been created. In other words, past records remain in the form in which they were created. Newly created records, applications using database definitions that have been followed by columns As for the force, a record including an additional column is added, and from the previous version of the application 'program, a record in a format not including the additional column is added. In other words, different types of records are mixed.
  • Database The term 'sub-schema' and 'schema' are generally used in the 'system'. In this specification, the term database will be used without any particular term.
  • expressions such as "column addition to database” and "access to database” represent operations on a specific type of database 'file (for example, employee file), and are stored in database' system ". The database is not for the entire file. Also, if a certain type of database 'file strength multiple database' file strength is also configured, for example, in the employee master, the birthplace of the newly added column is stored in another database 'file If it is treated as one set as a record, it is also used for each database file, using database and expression. [Past past type]
  • Figure 46 illustrates past non- retroactive READ processing (read processing: often SQL in SQL).
  • the application program 30 directs the READ instruction to the database system.
  • request reception processing 31 is performed.
  • Analysis of SQL type of database (which database 'file access force to file, application' confirmation of database definition of the program and its version, access type (in this case, READ processing), key type (primary key or alternative key strength, In the case of an alternative key, it is a confirmation of whether the key value (target key value) or key condition (equal to, greater than or less than the target key value, etc.) is wrong.
  • Process 32 is performed to detect the position where the target record is stored, which is the same as the conventional database system up to this point.
  • the record is stored based on the physical structure, etc. (the name differs depending on the database system), the record Read out.
  • the record may be distributed to multiple databases. In this case, read the required multiple databases.
  • the read record is converted into the logical structure of that version.
  • conversion is performed to the database definition version of the application program. Pass the converted records to the application program.
  • the stored records It becomes possible to read records that are unrelated to the version of the database definition for which the document was created and the version information of the database definition used by the application's program that is reading.
  • each database definition has a logical structure conversion table.
  • the database definition in FIG. 46 is illustrated as including logic for converting the physical structure and the logical structure of a record. As described above, it is possible to configure the database definition to include logic for logical structure conversion, and the database definition describes only pure definition and the logic for performing logical structure conversion is the database. It is also possible to construct as a separate entity from the definition body. This explanation is the same as in the explanation of FIGS. 46 to 53.
  • REWITE is the process of adding and updating the read record.
  • Application program 30 issues REW ITE request to database 'system 2'.
  • database 'system execute request acceptance process 31.
  • SQL analysis, database type, application 'program's confirmation of database definition version, access type (here REWRITE), and confirmation whether record information is correct are performed.
  • the distribution process 37 is performed according to the database definition version of the application program. If the database definition of application 'program is VI, assign record information to the database definition of VI. In database definition, convert from record to physical structure.
  • storage position setting is performed. This record is read by the READ process, and if there is an exclusion at that time, there is no change in the storage position, so the storage position at the time of READ is set. If the READ power S is not exclusive, the storage location may be changed before performing REWRITE, so the storage location is searched. Second, in the block that contains the record, the record that was previously occupied by the record Move subsequent records within the block if the space required differs from the space required. Further, version information is set to the stored record (38). After that, save the record. Next, if there is a change in the alternative key, make a change in the alternative key.
  • Figure 48 shows the past non retrospective type DELETE processing. Similar to REWRITE. Also in the case of DELETE processing, it is common to read the record and delete it, but it is also possible to delete it by giving a key value suddenly.
  • Request processing acceptance 31, type of database, distribution of application's database definition by program version 37, physical structure conversion by database definition of each version is the same as REWRITE process.
  • storage position setting or storage position search is performed. This is also similar to REWRITE processing.
  • record deletion the space occupied by the record becomes free, and it is necessary to move the record after that record. Then, delete the record. Next, if there is an alternate key, delete the alternate key 'entry for that record.
  • Figure 49 shows the past non retrospective type INSERT (record addition) processing.
  • request acceptance processing is performed.
  • record information is required. Information about the key is not necessary because it is included in the record. Sort by database definition version. After that, conversion of logical structure and physical structure is performed by database definition. Next, the storage location is searched, and in the block where the record is stored, the record after the record is moved and the record is stored. In addition, follow the alternate key 'entry.
  • FIG. 54 shows an example of a logical structure conversion table.
  • This logical structure conversion table is set so that logical structure conversion can be performed for database definition VI to V4.
  • Column name is on the left side It is.
  • To the right the logical structure of the Database Definition VI is described.
  • Column a is offset 0 to 8 bytes of record
  • column b is absent
  • column c is offset of record 8 to 12 bytes
  • column d is offset of record 20 to 14 bytes
  • column e is , Record offset 34 to 16 bytes
  • ⁇ Uf is record offset 50 to 18 bytes.
  • V2 V3
  • V4 Column History is a deletion This indicates that column deletion was done in this version. Also, the offset and the length are expressed in parentheses. This does not exist in the V4 logical record, but indicates that the value of column e is saved as past data! I'm sorry! Used to pass the value of column e to the application program when the record is created in V4 and the application program is other than V4. If a V4 application program is a request source, it is natural to pass a record that does not contain the column e .
  • Column history is history information on whether the column was created or deleted in the database definition version. The leftmost column of this logical structure conversion table is held by each of a plurality of database definitions for the database, and the column is extracted by the “OR” condition.
  • Column c is the offset 8 to 12 bytes of the read record, and it is set to the offset 18 to 12 bytes of the record for V3.
  • Column d is the offset 20 bytes to 14 bytes of the read record, and it is set to the offset 30 bytes to 14 bytes of the record for V3. The following sets the columns e and f. Now that the record for V3 is complete, the application 'program' that record give.
  • the columns are passed from V4 to V2 of the logical structure conversion table.
  • Column a is the offset 0 to 8 bytes of the read record, and it is set to the offset 0 to 8 bytes of the record for V2.
  • Column b sets the offset 8 power and 10 noise of the read record to the offset 8 bytes to 10 bytes of the record for V2.
  • Column c is the offset 18 to 12 bytes of the read record, which is set to the offset 18 to 12 bytes of the record for V2.
  • Column d is an offset of 30 to 14 bytes of the read record, which is set to an offset of 30 to 14 bytes of the record for V2.
  • logical conversion between database definitions is not performed because a logical structure conversion table is not used. It only converts logical and physical structures within a single version. This logical structure conversion table is updated when creating a new version of the database definition. Updates can be made automatically by the database 'system.
  • a record is a unit of data stored in a database and is a series of one or more items (columns). In this specification, in addition to that, it shall include version information of the database definition when the record is created.
  • a logical structure is a structure of records consisting of a series of one or more columns. It includes information such as column order, column start position, length, column attributes, column history, etc., but at a minimum, it shall include column start position and length information.
  • the physical structure indicates how the record is stored. Also, of the information stored in the record, the version information of the database definition is the application 'program It is not necessary to pass it to the ram and is managed by the database 'system.
  • the logical structure conversion table is used to explain the conversion of the logical structure.
  • the first method is to keep logical conversion between versions as program 'logic'.
  • the example is illustrated in Figure 55.
  • the number of logical structure conversion formulas increases geometrically if there are many versions. is there. It is possible to reduce the number of logical structure return expressions by converting it into an intermediate form and then converting it to the target form.
  • the second method is to move the same column by comparing the logical structures in the database definition of each purgeon. Because column attributes and lengths may have changed, it may be necessary to change attributes or change lengths simply by moving the column. This description applies to the entire description of the logical structure conversion table below.
  • the past retrospective type prepares the value of a new column to be added to the already created record and applies it to the existing record to make the record including the additional column. Also, newly created records are only records that include additional columns.
  • FIG. 50 illustrates a retrospective type of READ processing.
  • Application 'Program 30 Force Read command to database system.
  • request processing 31 is performed.
  • index search processing 32 is performed to detect the position where the target record is stored. Up to this point, it is similar to the conventional database system and past non-recursive READ. Find the desired record from the part 33 where the data (record) is stored.
  • V4 latest version of the database definition of the record exists, it is not necessary to store the version information of the database definition in the record.
  • Read-out record Since the version information is V4, the record is sent to the database definition of V4. Here, based on the physical structure, the record is read from the block etc.
  • the record is stored (the name differs depending on the database 'system).
  • a single record may be distributed to multiple databases.
  • the necessary multiple databases are read.
  • the read record is converted to the logical structure of that version.
  • conversion is performed to the database definition version of the application program. Pass the converted record to the application program. In this way, it is possible to read a record that is unrelated to the version of the database definition for which the stored record was created and the version information of the database definition used by the reading application's program. Become.
  • Application 'program 30 issues REWITE request to database system 2.
  • the request acceptance process 31 is executed.
  • the logical structure conversion table 36 is used to perform the logical structure conversion of the database definition version of the application program.
  • the logical structure of the conversion destination is only the latest V4.
  • the V4 database definition 35 converts logical structure to physical structure.
  • storage position setting is performed. This record is read by READ processing, and if there is force exclusion at that time, there is no change in the storage position, so the storage position at READ time is set. If READ is not exclusive, the storage location may be changed before executing REWRITTE, so the storage location is searched.
  • the record to store is previously occupied Move the subsequent record in the block if the space used is different from the space required newly. Further, version information setting 38 is performed on the record to be stored. Then store the records. Next, if there is a change in the alternative key, change 39 on the alternative key.
  • Figure 52 shows a retrospective type of DELETE processing. Similar to REWRITE. Also in the case of DELETE processing, it is common to read the record and delete it, but it is also possible to delete it by giving a key value suddenly.
  • Request processing Acceptance 31 The logical structure conversion table 36 converts the logical structure from each version to V4, and performs physical structure conversion based on the database definition of V4. These are similar to REWRITE processing. Next, storage position setting or storage position search is performed. This is also similar to RE WRITE processing. In the case of deleting a record, the space occupied by that record becomes empty, so it is necessary to move the record after that record. Then, delete the record. Next, if there is an alternate key, delete the alternate key entry for that record.
  • Figure 53 shows the retrospective type INSERT (record addition) processing.
  • INSERT retrospective type
  • record information is required. Information about the key is not necessary because it is included in the record. Sort by database definition version. After that, conversion of logical structure and physical structure is performed by database definition. Next, the storage location is searched, and in the block where the record is stored, the record after the record is moved and the record is stored. In addition, follow the alternate key 'entry.
  • the scheme for structural transformation is similar to the past non-recursive type.
  • Axcellarator function of the database (hereinafter referred to as” Axcellarator function ". Patent application PCTZJP03Z13443)"
  • the system of the axcellarator1 system holds a copy of the location.table and the alternative key.location 'table. It is invented that access can be processed in parallel by using the accelerator's 'system location' table or alternative key 'location' table when searching.
  • linking from the primary “1 block” to the overflow “1 block” and “o flow 1 block” “block flow 1 block” block is performed using the uno flow 1 block management table.
  • the scheme In the "Overflow One Block Management Table", alternate key ⁇ ⁇ ⁇ block and alternate key ⁇ ⁇ ⁇ overflow ⁇ ⁇ ⁇ ⁇ block concatenation, alternate key ⁇ overflow ⁇ block and alternate key overflow ⁇ block concatenation as well
  • the alternative key overflow method is a method using a block management table.
  • the primary 'system 1' is one of the major systems to which the 'data storage search method' is applied.
  • Data 'records are stored in block 11 in order of primary key.
  • Block 11 is primary ⁇ ⁇ ⁇ block and overflow ⁇ ⁇ ⁇ block In the case of Figure 1, only the primary block is shown.
  • When adding a data record to its primary one block if the primary 'block is full, concatenate an overflow' block to its primary one block and store a data 'record. It is possible to connect an overflow ⁇ ⁇ block to the overflow ⁇ ⁇ block.
  • Location 'Table LC has a location table 'record (or location' table one entry) containing the address of each primary block in a continuous area.
  • Location 'Table LC is secured in advance in a continuous area.
  • the continuous area is a logical order, and may be separated in the physical area. In such a case, it can be treated as logically continuous using an address conversion table. The same applies to the following description.
  • the last pointer 101 is used to indicate the end of the used area of the location 'table.
  • the term "concatenation" means that physical connection is not made in the primary-block but the first overflow ⁇ ⁇ ⁇ block holds the address of the first overflow.
  • Such a representation is used because the state in which the block holds the address of the second overflow block can be treated as if the force is physically connected to the block (see below). , And so on). Because it stores in this way, location 'table' entries are arranged in order of primary key.
  • the primary key search finds blocks by performing a binary search between location 'table LC's first address and final pointer 101! /, Location' table entries. Find the desired record in the block. ⁇ If an overflow * ⁇ block is linked to the block, the overflow 'block is also searched.
  • the same logic can be used to update, add, and delete the power described in the search.
  • the substitute key is a non-unique key in the database, such as the name and date of birth in the employee database.
  • Alternate keys are used to There may be none or more than one database.
  • FIG. 1 an example in which there are three alternative keys is illustrated.
  • Alternate key records consisting of alternate key values and primary key values are stored in the alternate key value block (22A, 22B, 22C) in the order of alternate key values.
  • Alternative key 'overflow ⁇ ⁇ ⁇ block it is possible to further connect alternative key ⁇ ⁇ ⁇ overflow ⁇ ⁇ ⁇ block.
  • the alternative key 'overflow one' block is omitted.
  • An alternative key "location. Table” having a sequence of alternate key “location” table “records (or alternative key 'location' table ⁇ entries) in which addresses of each alternative key 'block are described in a continuous area. (AALC, ABLC, ACLC).
  • the alternative key location table is secured in advance in a continuous area.
  • Alternate key 'location' Use the alternate key final pointer (29A, 29B, 29C) to indicate the end of the used area of the table.
  • an alternative key with an alternative key value greater than the alternative key value of an existing alternative key' entry is stored in the last alternative key block, and the alternative key in its block If it can not be stored, a new alternative key block is created and the record is stored in the alternative key 'block.
  • a combination of the alternative key location and the alternative key block is called an alternative key table (20A, 20B, 20C).
  • the method of searching for records having a certain alternative key is the first entry in the alternative key location table and the alternative key 'location' table pointed to by the alternative key last pointer (29A, 29B, 29C). Search 'between entries for binary search, find the desired alternative key block, search in the alternative key block, and find the alternative key entry with the desired alternative key'.
  • the alternate key 'overlapping key' overflow block is linked to the alternate key 'procedure'
  • the alternate key 'one block' block is also the target of the search.
  • a binary search is performed on the location 'tape nore LC' to find the target block, and the target record is found in the block. If an overflow block is linked to the block, the overflow block is also the target of the search.
  • the alternative key since the alternative key is non-unique, there may be a plurality of records having the same alternative key value. In this case, if the next alternate key in the alternate key 'block' has the same alternate key value, the same operation as described above is repeated.
  • the same logic can be used to update, add, and delete the power described in the search. Also, if there are multiple types of alternate keys, as many alternate key tables as alternate key types will be created and used.
  • the “Database Reorganization System” proposes a mechanism proposed for “Data storage and retrieval method” to perform reorganization without stopping the database using points with a simple structure.
  • This "database reorganization system” will be briefly described.
  • Reorganization involves three steps: elimination of overflow blocks, securing of a proper initial storage rate, and elimination of fragmentation.
  • the elimination of the overflow block is as follows. When a large number of overflow one blocks are linked to the primary one block, when trying to insert a record into these blocks, the record is a primary key across the primary one block and the overflow one block. Since the values must be arranged in order, the number of records to be moved increases. Even when searching for records, efficiency must be lowered because the search must be performed across multiple blocks. In order to avoid such a thing, we eliminate the overflow block and make it a primary block.
  • Ensuring an appropriate initial storage rate is as follows. If an appropriate percentage of free space is provided in the block in advance, even if the record insertion occurs, the record insertion can be performed immediately without adding an overflow block. However, if the record insertion is repeated many times, the empty space will be out of the proper initial storage capacity. This is to restore the initial state. Defragmentation is similar to securing a proper initial storage rate. It is necessary to eliminate unnecessary primary and overflow blocks, or consolidate blocks with low storage rate. It is to keep the block used uniformly. Here, the primary one block and the overflow one block As mentioned above, the same applies to alternate key blocks and alternate key overflow blocks.
  • location' table is prepared for two working LC and new LN.
  • a reorganization pointer to indicate how far the reorganization has finished, one for the current location' table and one for the new location 'table Set up one RPLN.
  • FIG. 2 illustrates the elimination of the overflow block.
  • the block 11 pointed to by the current location 'table LC' consists of a primary 'block 12 and an overflow block 13, 14 forces. Since the first block of the current location 'table LC' consists of only the primary 'block 0', the new location 'table' is transferred to the first location 'table' entry.
  • the overflow 1-blocks 1-2 and 1-3 are linked.
  • the primary one 'block 1' is transferred to the location 'table' entry 1 of the new entry 'table LN.
  • the overflow ⁇ ⁇ ⁇ block 1-3 also writes the overflow ⁇ ⁇ ⁇ block 1-3 address in the new location 'entry 1 in table LN, making it a primary ⁇ ⁇ block.
  • search is performed to determine whether the primary key value of the record stored in the block pointed to by the entry pointed to by the reorganization pointer RPLC is greater or less than the desired primary key value. If it is smaller, the target record is retrieved by performing a binary search by using the new location 'table LN while the head and reorganization pointer RPLN are pointing. If it is greater than or equal to the current location 'table V, then the reorganization pointer RPLC and the last pointer FP point to the target while searching for the target record by performing a binary search. Do. Although the case of search has been described here, update, addition, and deletion can be performed in the same manner.
  • FIG. 3 is a prototype of the database used in the present embodiment.
  • primary 'block and uno flow block, uno flow block and uno flow block concatenation, and alternate key' block and alternate key 'overflow' block, alternate key 'overflow ⁇ ⁇ blocks and alternate key for ⁇ ⁇ - overflow ⁇ ⁇ block connection a description of the case where by the method shown in the "data storage and retrieval method".
  • the location 'table 10 and block 11 are shown.
  • seven records from record O to record 6 are stored. Each record has five items (columns) a, c, d, e and f.
  • the method described in "Data storage search method” is used as a method of storing and searching this record.
  • FIG. 4 is a database definition of the prototype database shown in FIG.
  • the database definition includes various information such as physical configuration information of the database, block size, proper initial storage rate, data type, etc. In this figure, it is necessary for the present invention. Information is focused on A database definition is a data definition of database definition information.
  • the method described here is a method of creating a column to be added as a child database. This method is called retroactive type 'child database method'.
  • the system administrator instructs the database system to add column b immediately after column a in a retrospective type 'child database method'.
  • the preferred method is to use a screen to perform interactively.
  • create a database definition V 2 (D2 and D21 in FIG. 6) after the column b is added.
  • FIG. 6 the definition body cross' reference. Table X6 1S is described together. We will explain later about how to create database definition V2 and definition cross 'reference' table.
  • DB—A1 is added as another database to DB—A.
  • DB—A is a parent database and DB—A1 is a child database.
  • Fig. 6, VI is also described.
  • the database definition of the previous version is not necessary.
  • the child block 16 for DB-A1 may be secured each time a record is stored, but a necessary number of blocks may be secured in advance.
  • column b has the actual meaning, but it can not be searched or updated only in column b, so it is combined with the primary key column a of DB-A and is used as a record and stored in 16 blocks. Do.
  • FIG. 7 shows the state in which the addition of the column b is performed until the record 6 in this manner, and the column addition is completed. Completion of column addition is when the end of the data for the additional column is detected.
  • the column operation pointer 1 is not necessary because it points to the final pointer 101 and Cf position. Therefore, it is not shown in FIG.
  • FIG. 8 is used to explain the case of adding a record after column addition is completed. It is preferable that records created retrospectively in the past are only records that include additional columns. In the case of the retroactive type, applications using the previous version of the database definition 'Additional records in the program do not have information on the additional columns, so the values for the columns are added. Is preferably set to an initial value force null value, or a sequence without information. Or, an application that uses a database definition other than the latest 'Do not run one of the programs that adds records! /, And so on!
  • FIG. 8 is a diagram when the addition of record 7 is completed.
  • the retroactive type there is a method of not running application programs that do not use the latest version of the database definition, but this method is not new because it is a conventional method.
  • FIG. 53 is a diagram in which the database definition is up to V4.
  • the logical structure conversion table 36 in this figure is two of VI and V2, and the latest database definition 35 is for V2. Let's say. Application If the program uses V2 database definition, conversion of the logical structure is unnecessary, so it is the same as normal record addition. We will explain the case where the 'application' program uses the database definition of VI. First, application request processing is performed from the application's program. Next, the logical structure conversion table 36 is used to convert the logical structure of the VI into the logical structure of V2. The specific format of the logical structure conversion table 35 is shown in X6 of FIG. Ru. Set column a of VI (offset 0 to 8 bytes) to offset 0 to 8 bytes of V2.
  • the application 'program is using which version of the database definition Must be specified in the application program. This is the simplest way of coding in an application 'program. In this case, when changing the version of the database definition to be used, it is necessary to change the application program. As another method, the version of the database definition is given to the application as an external information (for example, a parameter etc.) to the application program, so that the application change due to the version change can be changed. It is also possible to reduce. This is common to other column additions, column deletions, and column updates. Alternatively, it is possible to determine the version of the database definition used automatically by the database 'system by looking at the application' program creation date '. In this case, it can be easily determined by comparing the creation date of each version of the database definition with the application creation date.
  • the column status column of the database definition will be described using V2 (D2 and D21) of the database definition in FIG.
  • the column status column is for showing the history of the column and the status at that time.
  • the column status column of column b is described as "concatenate with DB_A1.” This indicates that column b is logically a column in DB_A. Physically, column b does not exist immediately after column a, and it is logically connected.
  • the column status column of the column b of the database definition D21 of the DB2 of DB2 to A2 is “connected from“ DB_A ””. This indicates that the entity in column b exists in DB_A1, but logically exists as part of DB-A.
  • the use of the column status column will be described in more detail in different sections of the following specification that it can be used in various ways.
  • the database to which the column is being added can be accessed using FIG.
  • the request source is an application 'program'.
  • access is to the primary key and its primary key value is al.
  • index search processing is performed.
  • the application program uses a database definition VI, use the logical structure conversion table to convert V2's logical form to VI's logical form.
  • the method of structural conversion is as described with reference to FIG. Pass the converted record to the requester. If the request source uses database definition V2, conversion of the logical structure is not necessary, so the records created by the database definition are passed to the request source.
  • the access is a primary key and the primary key value is a3 will be described.
  • a binary ⁇ ⁇ ⁇ search is performed on the DB's location 'table to find record 3 in block 111. If the column operation pointer 102 is used, the target primary key value is larger than the block pointed to by the column operation pointer, so column addition is complete and access to the block must be completed. As you can see, there is no need to access DB—A1. If the column operation pointer is not used, a binary search is performed on the table of “DB—child location of table A1”, and since record 31 does not exist, it is determined that the column b has not been added yet. it can. In this way, access during column tracking can be efficiently performed using the column operation pointer.
  • Access with the alternative key performs a binary one's search of the alternative key 'location' table according to the desired alternative key value, and the alternative key 'block or alternative key' overflow 'block force, It is sufficient to look up an alternate key 'entry having a desired alternate key value, and use the primary key value of the alternate key' entry to perform a binary 'search by primary key against the location' table to search for a desired record.
  • alternative keys there may be multiple records with the same key value, in which case the above operation is repeated.
  • the record can be updated, deleted, or added.
  • An overflow block management table 14 is provided in the parent database (2: DB_A). Further, an overflow 'block management table' pointer 141 is provided for the overflow 'block management table 14'. Similarly, the overflow database management table 19 is provided in the child database (3: DB-A1). Furthermore, an overflow ⁇ ⁇ ⁇ block management table 'pointer 191 is provided for the overflow ⁇ ⁇ block management table 19. In the case of FIG. 37, since no overflow block has occurred, the overflow block is omitted in the figure. Also, both overflow block management tables are unused. The usage of these overflow block management tables and access when using them use the method described in “Overflow 'block management table”.
  • a new database definition V2 (D210 in FIG. 10) is created with the column b added.
  • column b is added to DB-A so that the number of columns of records is 5 to 6.
  • the “column status column” in column b of V2 (D210 in FIG. 10) indicates the “adding” power. This indicates that the column is being traced, and the column It will be blank if the addition is complete.
  • one column operation pointer (103 and 83) is provided for the current location 'table 10 and column additional location' table 8. Furthermore, a row operation complete pointer (104 in FIG. 9) having the same value as the final pointer (101 in FIG. 9) immediately before starting the row tracking is provided.
  • the purpose of the column operation complete pointer is to add a new record while the direct addition method is used, and the position pointed to by the final pointer (101 in Figure 9) is shifted backward, This is to avoid that it becomes impossible to determine the force required to add a column to the record of.
  • the column operation completion pointer does not change its pointing position until column addition is completed. Also, when column addition is completed, it becomes unnecessary.
  • FIG. 9 shows the state in which the addition of the column b is performed up to record 3 in this manner.
  • recordl is that much You only need to move to the right.
  • the overflow 'block is excluded from the description, but in the case where an overflow block is present, it is preferable to simultaneously eliminate the overflow block.
  • the power described as the long record fits into the previous block If the record does not fit into the previous block, the following occurs.
  • To target one or more blocks check the number of records in the block and the record length, and store records that became long after the column for those records at the appropriate initial storage rate Calculate the number of blocks N required for.
  • the access is a primary key and the primary key value (target 'key value) is al will be described.
  • the access is a primary key and the primary key value (target 'key value) is al will be described.
  • it performs request reception processing and checks which version of the database definition the request source uses.
  • it is checked whether the entry pointed to by the target 'key value power column operation pointer 103 is smaller than the primary key value of the record of the block being managed. In this case it can be seen that it is small. If it is smaller, perform a 'Nounary' search for the new entry 'table 8'.
  • Binary 'search is new Performed on the location 'table' entry, which is at the beginning of the table and between the point at which the column operation pointer 83 points. It searches for block 0 (110) and finds recordl among them.
  • application 'program power using old version of database definition may generate new record, so do not run such application' program, It is preferable to use, but when operating Is set in the database system as the value of column b, either as an initial or null value, or as a column with no information.
  • FIG. 11 shows the state in which column addition is completed.
  • the database definition is as shown in Fig.12.
  • the database definition in Fig. 12 is basically the same as Fig. 10, but since column addition has been completed, the column status column in column b of V2 (D210) is blank.
  • the former current location 'table 10 is illustrated by a dotted line, but this is because it is actually unnecessary.
  • New location 'Table 8 will be the current location' table. In order to emphasize that it is in a state where the line addition in the direct addition method has been completed, it will be described here using the name of the new location 'table.
  • the request acceptance process is performed first.
  • a narrowly search is performed to find recordl in block 0. Since this record is added column by retroactive type 'direct addition method', it is understood that the record format is V2. Also, as described in the child database method, if the version of the database definition body for which the record is created is included in the record, the determination can be made more easily and more easily.
  • the physical structure and the logical structure are converted using the database definition body of V2.
  • the request source uses the database definition VI to determine whether it is V2 or not. If you are using a request source, pass the converted record to the request source.
  • the request source force SV1 convert the logical structure using the logical structure conversion table and pass the record to the request source.
  • Access from the alternate key is performed after accessing the alternate key table. Search the primary key from the table and search for the target record.
  • An overflow block management table 14 is provided for the current location 'table 10'. Also, in order to identify the last entry of the overflow block management table, an overflow 'block last pointer 141 is provided. So far, it will be necessary regardless of the column addition. Create a new location 'table 8' for direct column addition. Also, a new overflow 'block management table 84 and a new overflow' block end pointer 841 for the new location 'table 8 are created. In FIG. 38, since the overflow block is not generated, the overflow block is omitted in the figure. Also, both overflow block management tables are not in use. The usage of these overflow block management tables and access when using them use the method described in “Overflow block management table”.
  • the past non-retrospective type ⁇ child database method is basically the same power as the retrospective type ⁇ child database method
  • the addition of values to records created in the past for newly added columns It is a method to add an additional column from the record created after the change of the database definition without changing the database definition. Also, records created after changing the database definition can be only those with added columns. It is also possible to mix records created with previous versions of the database definition. Since adding a single version of the record is included in adding multiple versions of the record, we will focus on the case where multiple versions of the record are added.
  • FIG. 13 is a database that is going to perform column addition of column b by the past non-forward type child database method.
  • seven records from record dO to record 6 have already been created .
  • the database definition V2 (D2 and D21 in FIG. 16) is created after the column b is added.
  • the logical structure conversion tape X6 is also described. The method of creating the database definition V2 and the logical structure conversion table will be described later.
  • DB— A1 is added to DB— A as another database.
  • DB—A is the parent database
  • DB—A1 is the child database.
  • the record for DB-A (record7) will be stored at the last position by comparison with the final pointer. In this case, block 3 (113).
  • the record for DB—A1 (recrd 71) is stored in block 0 (160 in FIG. 15) of DB—A1.
  • FIG. 15 further shows a state in which the record 91 is written from the application program using V2. This completes the description of writing records from an application program using multiple versions of database definitions.
  • the powers described in relation to the two versions operate in the state where there are a plurality of versions.
  • the version information of the database definition in this record is such that the version information of the database definition used when creating the record is stored at a specific position of the record, as shown in FIG. 17, for example. It is.
  • the record length in Figure 17 is the length of the record in the case of variable-length records, as used by the force VSAM, the position of the record at a particular location in the block that is not in the record. It is possible to go out by storing in conjunction with etc. It is also possible to store the version of the database definition for which the record was created. Figure 18 shows this.
  • FIG. 15 shows an application 'program using database definition body VI and a record written out from the application' program using V2 in a mixed manner, which will be explained using FIG. 15 and FIG. Also, Figures 46 to 49 are helpful for understanding.
  • the request source is an application program.
  • request acceptance processing is performed, in which it is determined whether the request source uses force V2 using the database definition VI.
  • a binary ⁇ ⁇ ⁇ search is performed for the location of DB-A's table 10 to find recordl in block 0.
  • the requester uses the database definition VI, the version of the requester is the same as the version of the created database definition, so the read record is passed as it is to the requester.
  • the request source uses database definition V2, refer to VI and V2 in the logical structure conversion table (X6 in Figure 16).
  • V2 the columns of the record consist of the columns a, b, c, d, e, f.
  • Column b is "DB-Al" in the source column of V2 and "consolidated from DB_A" in the column status column. Because of this, column b will be present in DB_A1, but the actual record is created in database definition VI, so column b I do not have.
  • the row b is a sequence of the columns a, b, c, d, e, f as records passed to the force request source existing in the child database.
  • VI determines which version of the database definition the request source uses.
  • VI Perform the logical structure conversion from V2 to VI using the logical structure conversion table X6 shown in Figure 16.
  • the records read from DB-A are in the format of the recipient. In this case, it can be seen that, in fact, access to DB-A1 is unnecessary. In order to reduce excess access, it is effective to determine the necessity of access to the child database by determining the version of the request source.
  • the access with the alternative key is performed by searching the alternative key 'location' table binary according to the desired alternative key value, and the alternative key 'block or alternative key' overflow 'block force, It is sufficient to look up an alternate key 'entry having a desired alternate key value, and use the primary key value of the alternate key' entry to perform a binary 'search by primary key against the location' table to search for a desired record.
  • the processing for the target record is as described above.
  • the alternate key may have multiple records with the same key value, in which case the above operation is repeated.
  • Logical structure conversion table is a method to convert to the latest version logical structure.
  • the application using the old version does not have a value for the added column, so a null value or information for the added column is Set the initial value or the missing column.
  • the other is to stop the operation of the application program using an older version of the database definition.
  • FIG. 13, FIG. 19, and FIG. Figure 13 shows the situation just before adding a column, although it was also used in the past non- retroactive type 'child database method. Also, it is assumed that the version of the database definition corresponding to this state is VI. Here, seven records from recordO to record 6 have already been created. At this point, it is decided to carry out the follow-up of the column b in the past not retroactively, and instruct the database system. The database system creates a corresponding database definition V2 (D210 in FIG. 19) and a logical structure conversion table (X6 in FIG. 19). This completes the column addition of the past non- retroactive 'direct addition method'. The reason is that the past data is not changed.
  • V2 database definition
  • X6 logical structure conversion table
  • FIG. 19 shows a state in which three records such as record 7, 8 and 9 are added.
  • record tracking from an application program (request source) using database definition V2 (D210 in FIG. 19) will be described.
  • Figure 49 is helpful.
  • Application The 'program creates a record consisting of the columns a, b, c, d, e, f and passes it to the database' system.
  • the database 'system performs request acceptance processing. Allocates records to database definition V2 and converts logical structure and physical structure. After that, the storage location of the record is searched if necessary, the record in the block is moved, and the record is stored. After that, add an alternative key.
  • the conversion by the logical structure conversion table is not necessary, as the record power to be accessed is created by the database definition VI. If you are using demand force, use the logical structure conversion table to convert VI to V2. In this case, the column b does not exist in the record of VI, so it is preferable to set a null value or a column without information or an initial value.
  • the request source uses the database definition V2 if the record is created with the record strength database definition V2 to be accessed, the structure conversion by the logical structure conversion table is not performed. It is unnecessary. If you are using a demand source, use the logical structure conversion table to convert V2 to VI. In this case, delete column b, because column b does not exist in the record of the VI. In practice, it is possible to set column c or less immediately after column a.
  • Overflow ⁇ Storage and access using the block management table are the same as the method described in the past retroactive type ⁇ direct sequence addition method, so details are omitted here.
  • This command instructs the database system to start reorganization, and to bring two databases into one in reorganization.
  • This command can be determined automatically by a program incorporated in the "Database Reorganization System", or can be activated by a system administrator.
  • V2 the database definition immediately before reorganization
  • V3 the database definition during reorganization or after reorganization
  • the database definition V2 consists of two databases, DB_A (2) and DB_A1 (3), and these two appear as if they were one database.
  • DB-A is only one and column b is included in the record.
  • create database definition after completion of reorganization This is FIG.
  • the logical structure conversion table X25 is also shown in FIG.
  • the method of performing reorganization is as follows. First, prepare a new location 'table 9 for the current location' table 10 of DB-A (2). DB-A1's current location 'The new location' table is not necessary for the table. A reorganization pointer (102) for the current location 'table 10 and a reorganization pointer (92) for the new location' table 9 are provided. New location 'Reorganization pointer for a table may be substituted with an end pointer. This is the preparation work. Here, for the current location 'table 10 of DB_A (2), it is assumed that a new location' table 9 is provided.
  • the current location 'table 15 for new location' table 15 of DB A1 (3) It is also possible to set a bull and do not set a new location 'table for the current location' table 10 of DB-A '. This is to integrate the parent database with the child database. New location 'Integrates the other database to the database to which the table is assigned. In this case, access to the database will be done using the location table of DB-A1.
  • DB-A excludes the first entry of the current location 'table 10 and the first block.
  • Read recordO then read recordlO of DB—A1 (3).
  • this method is the method described in the retrospective and direct addition methods in the past. Furthermore, by integrating the records, Because the code length becomes long, if you rewrite records sequentially from the top of the block of DB-A, it is necessary to shift the position of the record behind each time, but this is also a retroactive type 'direct addition method' As mentioned above, it is possible to minimize overhead by performing update on a block basis.
  • the current location 'reorganization pointer 102 for table' points to the third entry of the current location 'table and the third entry of the new location' table 9. Also, with regard to DB-A1, since it is integrated with DB-A, it is not a direct target of reorganization, so there is no need to provide a reorganization pointer.
  • FIG. 23 shows the state where the above reorganization has been executed until the last record, and the reorganization is completed. In this case, it is preferable to delete the current location 'table 10' indicated by dotted lines without actually needing to delete the current location 'table. Also, the new location 'table 9 is actually the current location' table.
  • FIG. 24 shows the database definitions VI (Dl), V2 (D225) and V3 (D325) with the reorganization completed. DB-A1 has become unnecessary due to consolidation by reorganization.
  • the database definition V2 (D2 25) is equal to V3. This indicates that the logical form of V2 has been changed to match V3 and is now the same as V3. Of course, create the same definition as database definition V3 (D325)! Even, good!
  • DB's current location 'table 10 or new location' table 9 is greater than the primary key value of the location 'table.entry' entry pointed to by the primary key value reorganization pointer of the target record , Depending on whether it is less than that. This is the method described in "Database Reorganization System".
  • the primary key value of the destination record Force Use the current location 'table 10 if it is greater than the primary key value of the location' table 'entry pointed to by the reorganization pointer, use the new location' table 9 if it is Do.
  • New location of DB 'A table 9 If using table 9, location table between location' table 'entry pointed to by start address of new location' table 9 and reorganization pointer 92 'table Perform a 'one binary search' on the entry to search for blocks and find records. New location 'The records in the block managed by the table have been reorganized, so the records have been consolidated and column b has been added to the records. That is, the records are created by database definition V3. Therefore, the database definition uses that after the completion of reorganization in FIG. It converts physical structure and logical structure according to V3 database definition. Next, it is determined which version of the database definition is used by the request source, and the logical structure is converted by the logical structure conversion table X25. If the version of the record and the database definition of the request source are the same, conversion by the logical structure conversion table is not necessary.
  • the location 'table or new location' table power may also be searched by the primary key to retrieve the desired record.
  • the record update can be performed by updating the record found in the search, and the deletion is found in the search You just delete it.
  • the application 'program' does not work because it writes a record without column b.
  • the initial value or null is used. It is preferable to create an entity database by filling in a matrix without values or information. The update, deletion and addition of records are as described in Figure 47 to Figure 49.
  • the state in which the reorganization has been completed is shown in FIG.
  • the current location 'table 10 is indicated by a dotted line, and is no longer necessary because the force reorganization has been completed.
  • the new location 'table 9 actually functions as a working location table, and will be described here as the new location' table 9.
  • the database definition and the logical structure conversion table are shown in FIG. This is as explained in the reorganization during reorganization. Access after completion of reorganization is the same as the access to the new location 'table described in Access during reorganization. The slight difference is that the reorganization is complete, so use the reorganization pointer to not decide whether to use the working location 'table power' new location 'table.
  • the target of the binary search is that it is for a location 'table' entry from the beginning of the new location table to the point where the final pointer is pointing.
  • the location 'table or new location' table power may also be searched by the primary key to retrieve the desired record.
  • the power described in the case of integrating two databases into one can be realized by integrating three or more databases by using the method described above. For example, in the case where there are two child databases, it is possible to combine three databases into two and further to one, or simultaneously to combine three databases into one.
  • the reorganization method described in “Data storage and retrieval system” can be applied to reorganization when using overflow and block management tables.
  • For record addition and access during reorganization use the method described in the child database method for records before reorganization, and use the method described for direct column addition method for records after reorganization. Since it is sufficient, detailed explanation is omitted here. In either case, access to the database being reorganized is possible.
  • DB—A is the parent database
  • DB—A1 is the child database.
  • the frequency of reference and update for each item may change due to the addition of the application system and the change in the use status. If this is the case, it is possible to replace the items using the reorganization mechanism described above. For example, referring to FIG. 57, if the reference to item c or the frequency of updating decreases, the column c is deleted from DB ⁇ A, and the column c is added to DB ⁇ A1. It is possible for the parent database to always keep items (columns) that are frequently updated. Similarly, referring to the item (column) d in the child database, if the update frequency increases, delete the column d from DB-A1 and add the column d to DB-A. Needless to say, addition and deletion of these columns can be performed automatically by the function of this database.
  • the "Database Reorganization System” is capable of storing a location 'table' entry larger than the number of primary 1 'blocks after reorganization with respect to the size of the new location.table. However, this method will always require space for a new location 'table, which is about the same size as the current location' table for reorganization.
  • the current location' table becomes the new location 'table.
  • the reorganization of the primary one block 5 (here mainly elimination of the overflow one block) is performed.
  • the first entry in the new location 'table' is 5 and points to the primary 'block 5'.
  • the second entry in the new location 'table is 6 and points to an overflow block 5-1.
  • the fact that it is managed by the new location 'table' means that the overflow ⁇ ⁇ block became a primary ⁇ ⁇ block.
  • the reorganization is performed to the overflow ⁇ ⁇ block 5-3, and further to the reorganization from the primary ⁇ ⁇ block 6 to the overflow ⁇ ⁇ ⁇ block 6-5.
  • the new location 'table entry 1 will be used up to 14.
  • the primary 'blocks 7 and 8 are not reorganized, and the old 7 of the current location' table entry is replaced with the entry 15 of the new entry.
  • replace the old 8 of the current location table table entry with the entry 16 entry. This will complete the reorganization.
  • Past-held There are three ways to delete a column. There are two types: past-held and past-unheld.
  • the past retention type is further divided into a definition deletion method and a child database method.
  • the past non-holding type is only the direct column deletion method.
  • Past retention type ⁇ Definition deletion method is a method of deleting a column only on the database definition without deleting the column from the entity of the database. This method has the advantage that the time associated with the deletion is instantaneous. Although there is no column deletion as a matter of fact, the database area remains large. When reading records, the length of the record is long, the column deletion and transfer to the request source, and processing time Has the disadvantage of taking a long time. In this method, it is possible to actually delete the deletion target column at the time of reorganization.
  • Column deletion The past non-retention type is similar to the column addition: past retrospective type, and deletes the deletion column from the existing record by going back to the past. Access to this type is the same as described in Figures 50-53. The database definition holds only the latest one.
  • column deletion The past retention type is similar to column addition: past non retrospective type. For existing records, it will remain created. Access to this direction will be the same as described in Figure 46 to Figure 49. The database definition holds the version of each.
  • a new child database is created for column deletion, and the parent database stores records excluding the column to be deleted from the original record, and the child database contains the records. Create a king record in which the deleted column and the primary key are paired, and store it.
  • the direct column deletion method directly deletes the record to be deleted from the records stored in the block, and stores the record without the deletion column as a new record.
  • the program may terminate abnormally, because the deleted column value can not be returned. This point is the same as in the direct column deletion method. Therefore, when using this method, it is necessary to implement carefully. If you adopt the method of creating deleted columns as a new separate database in reorganization, the time required for reorganization will be long and an area for creating a new database will be needed. On the other hand, using the database definition before deleting a column, it can be handled without problems even with the demand for program power. And requests from programs that use the new version of the database definition are faster than before the reorganization.
  • FIG. 25 is a diagram when the column e is deleted by the past retention type and definition deletion method.
  • the force of shading column e is described in more detail in the following description.
  • the database definition and the logical structure conversion table X27 are described in FIG.
  • the database definition for the state immediately before deleting the column e is V3, and the database definition after deleting the column e is V4.
  • the database definitions VI, V2, V3 are the same as those described in FIG. Also, Figures 46 to 49 are for reference.
  • the database is instructed to delete the column e by the definition deletion method.
  • the database system performs preparation work.
  • the V4 database definition (D4) and the logical structure conversion table X27 are created.
  • VI database definition
  • V2 V2
  • V3 V3
  • column e will be deleted from the six-column record from column a to column f.
  • the status of “deletion of definition” is set in the column status column of the column e of V4.
  • the offset of the column e of the logical position of the database definition V4 (X27) and the column e of the V4 logical position of the logical structure conversion table (X27) is "(64)", and the length is "(16)" .
  • This expression makes it possible to identify that the column e is deleted as an entity, but is by definition deleted, and that the record created in the database definition V4 can be identified in another version.
  • the value of column e is to be passed.
  • the V4 record itself does not hold the column e. Needed as a temporary column to convert to another version.
  • the preparation work is finished above.
  • the shaded column e in Fig. 25 indicates that this is a deletion by definition. Since there is no need to make any changes to the database as an entity, the work involved in deletion is complete.
  • This parenthesis is used to mean that it is a field that is not included in the original logical record but is required for logical conversion. This is done using the same expression in! / ⁇ in V4 column e of the logical structure conversion table. Offset of logical record of V4 16 bytes from 64 bytes store the value of column e. In other words, when converting to another version when converting the logical structure of V4, it means that the value of column e is set and the value is passed to other versions. This is something that can be done by adopting the past retention type.
  • FIG. 27 shows a database for column deletion.
  • seven records from recordO to record6 are stored.
  • Each record has columns a, b, c, d, e
  • FIG. 30 is a diagram at the time when column deletion by the past hold type 'child database method' has progressed to the middle.
  • entry 0 and block 0 110 in FIG. 29
  • entry 0 in the new location 'table 9 in FIG. 30) in DB—A (2 in FIG. 30) in the current location' table (10 in FIG. 30)
  • entry 0 and child block 0 160 in Fig. 30
  • the record consisting of rows a, b, c, d, f is written back to block 0 (110 in FIG. 30).
  • the primary key column a and the deleted column e are combined to form a child record recordOl, which is stored in block 0 (160 in FIG. 30) of DB_A1 (3 in FIG. 30).
  • Child location of DB_A1. Exclude the first entry in the table, create a child block o (160 in Figure 30), and store it in it.
  • the primary key column a and the deleted column e are combined into a child record recordl and stored in block 0 (160 in FIG. 30) of DB-1 A1 (3 in FIG. 30).
  • the number of records stored in the block of DB-A does not change, but if the number of records actually changes, multiple points may be stored at one point in time. Exclusion is performed on blocks, and column deletion operations are performed on the records of those blocks so that the records are stored in each block at an appropriate initial storage rate. At this time, if there is an overflow block, it is regarded as a primary block, and if an appropriate initial storage rate is set, if an excess block occurs, it is regarded as an unused block.
  • FIG. 31 shows the state in which row deletion is performed in this way and record 6 is completed.
  • FIG. 30 corresponds to the column addition of FIG. 5: the retrospective type child database method of FIG. Past retrospective type ⁇ Direct addition method has been combined, and even if column deletion is performed, access can be performed without any problem.
  • Figures 46 to 49 apply as a schematic.
  • the conversion of V4 to other versions is similar to the logical position and length of the column e, as described in the past holding type definition deletion method. With special meaning, it enables logical structure conversion.
  • the past non-holding type 'direct column deletion method will be described.
  • This method is a method to write back only the record which deleted the deletion column from the existing record as a new record in a block.
  • This method has many similarities to the direct row addition method in row tracking.
  • This method will be described using FIG.
  • First prepare a new location table 9 for the current location 'table 10.
  • the column manipulation pointer one initially points to the first entry of each location table. Further, a final operation pointer 101 of the current location table is pointed to! /, A location 'tape nore entry' A column operation completion pointer 104 is provided to point to the same location as one. The value of the column operation complete pointer does not change until the column deletion is complete.
  • FIG. 35 is a diagram when deletion of column e is completed.
  • the location 'table 10 has been deleted as a column, and at the moment it is prepared as a new location' table
  • the past non-retention type is a type that deletes deleted columns that exist in already written records!
  • the record format is only the latest one generation. However, if you look at VI, column b does not exist.
  • the first method is to keep past versions of database definitions. In this case, if you leave it as it is, it will be inconsistent with the record format, so create a new database definition with the format of column e removed. In addition, when this method is adopted, the record format is different before and after the column deletion, so while the column deletion is performed, the old format database definition body and the new format database definition are used. Hold both sides of the body.
  • Figure 33 shows the database definition and the logical structure conversion table in this case.
  • the second method is a method of giving a null value or a column having no information or an initial value to the column b of the record created by the VI to make the same record format.
  • Figure 34 shows the database definition and the logical structure conversion table in this case.
  • “DUMMY” and “!” Are inserted in the column history of the column b of the VI of the logical structure conversion table to express that the information is not regular information.
  • reorganization can be performed in three ways, depending on how column e is handled at the time of subsequent reorganization.
  • the second method is a method in which the force sequence e is deleted as a child database.
  • the child database has been described with regard to the child database method by adding columns, but it is the same as the explanation.
  • the new database is stored as a king record consisting of column e and column a which is the main key.
  • the merits of this method are that it can guarantee the operation of the program that was using column e, and that the access from the program using database definition V4 will be faster.
  • creating a new database at the time of reorganization has the disadvantage of increasing the time required for reorganization and an additional space for a new database.
  • Implementation method applies the method explained in the past holding type ⁇ child database method.
  • the third method is that the entity database also deletes the column e.
  • This method is exactly the same as the column deletion and direct deletion method. It requires the least amount of database space.
  • Column changes are about attributes and lengths. If this is classified, if there is no change in length due to a change in the attribute of the column, if there is no change in the attribute of the column and the length changes, then both the attribute and the length of the column change. There will be three.
  • An attribute is a type of information stored in the column, and has attributes such as numeric values, characters, and dates.
  • the change in column length will be described.
  • the retrospective type is a method of changing the length of the change column of the existing record to the length of the new database definition.
  • changes to existing records are similar to the method described in the column addition: retrospective type.
  • past retroactive type no change is made to existing records, and newly created records are created using the latest database definition. Change column length will change.
  • the principle of the accelerator system is as follows. Location Perform a binary search on the 'table or alternative key' table and find the desired record. When you do a binary 'search on a location' table, you will find the split points again and again, which is typically more than the number of times to find a record in a block. . Also, the possibility of requesting records in the same block from multiple processes at the same time is quite low. Therefore, if multiple copies of the location 'table and alternative key' location 'table are held and binary' search 'can be performed on each in parallel, it is possible to execute many access requests for records. .
  • FIG. 40 shows the case where there is only one accelerator system.
  • the location 'table (fland' location 'table), alternative key' location 'table (fland ⁇ alternative key' location 'table) is held! /, 1S primary' block, overflow ' Blocks, alternate keys 'blocks, alternate keys' overflow ⁇ ⁇ ⁇ blocks are possessed, ⁇ ,.
  • the system's Fland ⁇ mouth Case 'table is functionally equivalent to the primary' system location 'table.
  • the A-Kellerator.System's Fland.Alternate Key Location 'table is functionally equivalent to the Primary'A'-Alternate Key' Location 'table.
  • Each record of “Flander location 'tape nore' in the accelerator system 1” points to the same block as each location 'table' record in the primary system ⁇ .
  • the accelerator system has one location 'table and three alternative key locations' tables, and has the same number as the primary system. This is called “symmetric system" in "A-Kellerator". On the other hand, for example, it is assumed that only two types of location 'table and alternative key' location 'table are held! /, Such as an accelerator system, location' table only, alternative key. Location It is possible to create an accelerator system such as 'table only'. This is called an asymmetric system. With regard to the accelerator system, the same applies to primary 'block and overflow' blocks, alternative key 'block and alternative key' overflow. Blocks.
  • the primary 'system' has a location 'table 10, an alternative key' location 'table ALA 0, an alternative key' location 'table ALBO, an alternative key' location 'table ALC 0 ,. In addition, it has a final pointer (101, 10A1, 10B1, 10C1).
  • Overflow 'block management table 20 alternate key' overflow 'block if the database is in the form of an overflow table and block management table It has a management table 20A, an alternative key-overflow-block control table 20B, an alternative key-overflow-block-block management table 20C.
  • an overflow “block management table” pointer 201 is set in the overflow management block “ ⁇ block management table,” and an alternative key “overflow management” block management table 20 -Bar flow 1 block management table pointer 20A1 is provided, and similarly, an alternative key flow 1 block management table 'pointers 20B and 20C are provided.
  • the accelerator system 1 'system 3 has a' land 'location' tape nore 16 ', an ALA 1 and ALB 1 and an ALC 1's and' land 'table for each of the' land 'and a final pointer (16 1, 16A1, 16B1, 16C1) ing. If the database is a database format using an overflow block management table, Fland. Overflow
  • the change part is changed.
  • the overflow one block management table 20 when the database uses the overflow one block management table, the overflow one block management table 20, the overflow ⁇ ⁇ block management in the primary one system Table 'pointer 201, alternative key ⁇ ⁇ ⁇ overflow 1) If there is a change in the block management table (20A, 20B, 20C), or the alternative key 'overflow' block management table.
  • Pointer (20A1, 20B1, 20C1) Informing the change, in the accelerator system, the land 'overflow' block management table 21, the land final pointer 161, the land overflow 'block management table pointer 211, the land substitute key' one.
  • the corresponding part is changed to any of the bar-flow one block management table (21A, 21B, 21C) and the Fland alternative key overflow one-block management table 'pointers (21A1, 21B1, 21C1).
  • Pointer 211 Holland Alternate Key 'Location' Table (21 ⁇ , 21 B, 21 C), Holland Alternate Key ' Location 'the last pointer of table (21A1, 21B 1, 21C1), Fland alternative key' overflow one 'block management table (21 ⁇ , 21 ⁇ , 21C), Fland alternative key' overflow one 'block management table' pointer ( 21A1, 21B1, 21C1) are kept equal to the primary 'system
  • the accelerator 'system sends a change completion notice to the primary system when the change is completed. In the primary 'system, until the notification of completion of change from all the' accelerator 'systems arrives, the part waits for exclusion.
  • the 'new overflow' block management table and new overflow 'block management table' pointer are added to the table. If there is a change in the above elements in the primary 'system, notify the changer system of the change, and in the' accellarator 'system, change the relevant point.
  • Accelerator ⁇ ⁇ ⁇ Access in the system will only change access to the block to the primary ⁇ ⁇ ⁇ system, the others will be described in the column add 'deleted' change described above and in the accelerator system It can be realized by combining the described methods.
  • tags have the same attribute but have the same attribute as the "raw material” of the XML sample in Fig. 42, or they have no attributes such as the "author” of the XML sample in Fig. 43 The same tag is to appear.
  • RDB normalization issues are also involved, making it difficult with conventional databases. Met.
  • the raw material in Figure 42 although it is possible to regard it as separate items depending on the number of “ ⁇ ”, it is difficult in the conventional type when examining whether or not the power used in a certain raw material is used. It was work.
  • each of the columns cl, c2 and c3 is a separate column, in the case of a conventional alternative key, the force used to create three alternative keys. Registered as key C).
  • the alternate key shown in "Data storage search method" is registered in the alternate key 'table as a substitute key' entry 1 of the record combining the alternate key value and the primary key value. For this reason, even if they are separate columns, they can be used as the same key if the information content and attributes are the same. Using this method is very effective when searching for which book a particular author wrote.
  • Figure 99 shows how an alternative key 'entry is created when the XML author in Figure 43 is the alternative key C.
  • These alternative key 'entries' are stored in the same alternative key' table (alternate key C).
  • the "raw material" of Fig. 42 can be one key. Of course, it can also be treated as a separate line according to the attributes of the raw material. It is effective to divide and store "Product” in FIG. 42 and "Book” in FIG. 43 as a record for each "Product” and "Book". In this case, it is preferable to load the suffix into the primary key, have the same primary key, and indicate that the record is divided. By storing attribute information in the logical structure of the database definition column, it is possible to convert database records to XML.
  • information can be nested, and it is possible to have a hierarchical structure such as upper information and lower information. To cope with such a structure, it is possible to use COBOL's DATA DIVISION. This can be handled by describing the level number in the logical structure of the database definition column.
  • XML can be stored in the databases indicated by "data storage search method” and “data storage search system”.
  • conversion between XML format and record format is equivalent to the accelerator system, if one is adopted. By doing this, it is possible to reduce the load on the primary 'system.
  • V2 a column f is added to the record stored in DB—A.
  • column addition 'child database method power system administrator power is notified. Based on this
  • the added column f is not a primary key item, so it can be determined that the column f alone can not constitute a database. From this, it can be determined that the new database DB-A1 is configured by a record combining the column a and the column f of DB-A. Also, it can be determined that the conventional DB-A itself is not subject to any change. In this way, V2 database definitions can be created.
  • V3 Since two V2 databases are reorganized into one, it is possible to immediately determine that a database definition change is required. Let this be V3. In V3, two databases become one. Dynamically, it does not change to V2. The logical structure takes over V2 as it is. Physically, the fact that column b was out is included in the new record. There is no need for a child database, and one physical record.
  • each version of the database definition can be logically created.
  • the creation of a new version applies the database definition of the previous version and the information provided by the system administrator to create a new version, that is, change information (difference information).
  • change information difference information
  • the method of modifying the previous version can be implemented by reflecting the difference between the new version and the previous version in each previous database definition.
  • a column status column is provided to hold version-specific history and configuration change information, and the previous version of the database definition is modified and held, and the latest version is provided. Created in the form of, the database can be searched with the previous database definition, update, addition, deletion, deletion.
  • a column to be converted is determined.
  • the latest logical structure conversion table is symmetrical to the database definition V4, and the case of creating the database definition V5 will be described as an example.
  • the logical structure conversion table needs to hold only one generation, but for convenience of explanation, the logical structure conversion table up to the database definition V4 is symmetrical with V4 and the database definition V5 is symmetrical.
  • V5 be the structure conversion table.
  • the logic of database definition V5 Add the structure part to the right side (on the drawing) of the logical structure conversion table V5.
  • FIG. 56 shows that V5 and V6 are created based on V3. This is effective, for example, when it is necessary to add specific information regarding a specific customer when basic items are defined and operated in EDI (Electronic Commerce) and the like. To change all the records and programs to correspond to their specific information requires waste of storage space and time for changing the application program.
  • EDI Electronic Commerce
  • V3 format basic trading partners
  • V4 format specific trading partners X
  • V5 format By using (specific supplier Y), V6 format (specific supplier Z), etc., it is possible to minimize the storage area and to minimize changes in the application program.
  • Each database definition has an area that can store information such as the number of times of use, date of creation, date of last change, date of last use, etc., so that each usage status can be viewed statistically. It is preferable that these items be maintained by the database system. Furthermore, it is more preferable to keep the name of the program using each database definition, the date of use, etc. This function makes it possible to determine the power of using or not using the old version of the database definition, and the version of the database definition that has not been used for a certain period of time or more and its database. It becomes possible to delete the data held by the definition body. (Effect of the invention)

Landscapes

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

Abstract

【目的】データベースを無停止で運用したまま、列の追加等を可能とし、古いデータベース定義体を使用しているプログラムの稼動が保証でき、データベース定義体の作成・変更を自動的に行うことを目的とする。 【構成】データを格納し、検索するデータベース・システムにおいて、或るバージョンのデータベース定義体により定義されたレコードを、別のバージョンのデータベース定義体により定義されたレコードに変換する論理構造変換部と、或る１種類のテーブルのレコードに対して複数のバージョンのデータベース定義体と、そのデータベース定義体により定義された複数のバージョンのレコードを格納するデータ格納部と、を備えたデータベース・システム。

Description

明 細 書
データベース ·システム 技術分野
[0001] 本発明は、コンピューターにおけるデータを格納し、検索するデータベース 'システ ムに関するものである。
背景技術
[0002] 従来のコンピューターによるデータベース格納検索方式は、「Jeflfrey D.Ullman著、国 井他 1名訳、 "データベース 'システムの原理" ,第 1版， 日本コンピューター協会， 1985年 5月 25日」、 rsamuel Leffler他著/中村明他訳， "UNIX4.3BSDの設計と実装"， 丸善株式会社， 1991年 6月 30日」など多数の書籍に記載されている。
このような従来のデータベース格納検索方式によれば、（1)インデックスの創生や維 持に負荷がかかること、（2)最終的に使用されると想定される最大のブロックを予め 生成しておかなければならないこと、（3)インデックスが階層構造をとつているため、 データの挿入や削除によってインデックスの更新が行われる場合に、上位インデック スまで変更される場合が発生するために排他範囲が広くなり、デッドロックを引き起こ しゃすいこと、などの不都合があった。
[0003] このような従来のデータベース格納検索方式の不都合を解消するため、本発明者 は、従来の階層型インデックスに代えてロケーション'テーブルと代替キー ·テーブル という概念を導入し、インデックスの処理に伴う複雑な処理を簡素化し、テーブル自 体の検索をバイナリー 'サーチなどの手法を用いることにより、高速化と、メンテナンス の容易性を確保できるようにしたデータ格納検索方式を提案した（日本国特許第 33 45628、米国特許第 6654868号参照）」。
[0004] このデータベース 'システムには、次のような問題があった。実際にデータベース'シ ステムを運用していく場合に、データ項目の変更や追加 '削除'変更が発生すること がある。このデータベースでは、データ項目を追加する場合に、データベース 'システ ムの運用を止めて、データベースの定義変更を行い、データの変更を行った後、デ ータベース ·システムを稼動させることになる。このような作業は、数時間と言った長時 間を必要とするものであり、その間、データベースを停止させることは、連続稼動を要 求されるシステムにお 、ては、大きな制約となって!/、た。
[0005] また、それ以上に、データベースを使用しているアプリケーション ·プログラムを調査し 、矛盾が発生しないように修正する手間は、膨大な時間を必要とするものであった。 このように、アプリケーション 'プログラムの変更を行わなければならな ヽと 、うことは、 列の追加'変更 '削除が必要になっても、これらを決断するには大きな理由が必要で めつに。
[0006] 本発明に関連する既存の発明として、「データベースの再編成システム、並びに、デ ータベース（以下、「データベース再編成システム」と呼ぶ。特許出願 PCTZJP03/ 11592)」、「データベースのァクセラレーター機能（以下、「ァクセラレーター機能」と 呼ぶ。 PCTZJP03Z13443)」、「データ格納検索システム（特願 2004— 020006)」 が挙げられる。
発明の開示
発明が解決しょうとする課題
[0007] 従来のデータベース 'システムでは、データベースに列の追加 '削除'変更を行うこと は、長時間、データベースの稼動を止める方法しか存在していな力つた。また、デー タベースの列を追加'削除 ·変更することは、データベースの定義を変更することであ る力 定義を変更した場合、古い定義で稼動していたアプリケーション 'プログラムを 新しいデータベース定義で稼動させることは不可能で、必要なアプリケーション 'プロ グラムを修正したり、再コンパイルする必要があった。このため、列の追加 '削除'変 更を簡単に実行することは不可能であった。
[0008] 本発明の実施の形態は、次の課題を解決することができるものである。
1.データベース ·システムの性能を向上することにある。
2.データベース 'システムの列の追加、削除、又は変更を容易に行えるようにするこ とにある。
3.列の追加、削除、又は変更を行う場合にデータベースの稼動を止めることなぐ運 用しながら実行できるようにする。
4.列の追加、削除、又は変更を行った場合でも、アプリケーション 'プログラムを変更 することなく稼動すること〖こある。
5.同一のテーブルのレコードに関して、列の追加、削除、変更が行われると、新たな レコード形式となる力 従来のデータベースでは最新のレコード形式のものし力扱え なかった。それらの複数の形式のレコードを格納し、それらのレコードに対して、検索 、追加、更新、削除が行えるので、これまでに無かった履歴型のデータ格納管理を行 つことにある。
課題を解決する為の手段
[0009] 本発明は、データを格納し、検索するデータベース 'システムにおいて、或るパージ ヨンのデータベース定義体により定義されたレコードを、別のバージョンのデータべ一 ス定義体により定義されたレコードに変換する構造変換部と、或る 1種類のテーブル のレコードに対して複数のバージョンのデータベース定義体と、そのデータベース定 義体により定義された複数のバージョンのレコードを格納するデータ格納部と、を備 えたデータベース ·システムにある。
[0010] 本発明は、データを格納し、検索するデータベース 'システムにおいて、或るパージ ヨンのデータベース定義体により定義されたレコードを、別のバージョンのデータべ一 ス定義体により定義されたレコードに変換する構造変換部と、或る 1種類のテーブル のレコードに対して単一のバージョンのデータベース定義体と、そのデータベース定 義体により定義された単一のバージョンのレコードを格納するデータ格納部と、を備 えたデータベース ·システムにある。
図面の簡単な説明
[0011] [図 1]は、明細書で説明するデータベースの形式である。
[図 2]は、プライマリー 'ブロックとオーバーフロー 'ブロックに対する再編成を図示した ものである。
[図 3]は、列追カ卩を行うとするデータベースである。ここでは、代替キーについては省 略している。
[図 4]は、図 3のデータベースのデータベース定義体である。
[図 5]は、列追加:過去遡及型'子データベース方式で、列 bを追加する場合の途中 まで進行した図である。この図では、 record2までの列追加が終了していることを示し ている。
[図 6]は、列追加:過去遡及型'子データベース方式で、列 bを追加する場合の、デー タベース定義体と定義体クロス.リファレンス.テーブルの図である。データベース定 義体は VIと V2を示している。 VIは、列追加前のデータベース定義体、 V2は列追 加後のデータベース定義体である。
[図 7]は、列追加:過去遡及型'子データベース方式で、列 bの追加が完了した状態 のデータベースを示して 、る。
[図 8]は、列追加:過去遡及型'子データベース方式で、列 bの追加が完了した後に、 レコードの追カ卩が行われた状態を示して 、る。
圆 9]は、列追加:過去遡及型 ·直接追加方式で列 bを追加する場合の途中まで進行 した図である。この図では、 record3まで再編成が終了している状態を示している。
[図 10]は、列追加:過去遡及型 ·直接追加方式で列を追加する場合の、データべ一 ス定義体と定義体クロス'リファレンス 'テーブルの図である。この場合は、図 3のデー タベースおよび図 4のデータベース定義体に示されたデータベースを VIとし、列を 追加後のデータベース定義体を V2として 、る。
[図 11]は、列追加:過去遡及型 ·直接追加方式によって列を追加する場合、列の追 加が完了した状態を示している。
[図 12]は、列追加:過去遡及型 ·直接追加方式によって列を追加する場合、列の追 加が完了した状態での、データベース定義体を示している。
[図 13]は、列追加：過去非遡及型 ·子データベース方式による列追加を行うとするデ ータベースの図である。
[図 14]は、列追加:過去非遡及型 ·子データベース方式による列追加を行う際の、準 備作業が終了した時点の図である。
[図 15]は、列追加:過去非遡及型'子データベース方式により、列追加がされたレコ ードがデータベース上に格納された時点の図である。
[図 16]は、列追加:過去非遡及型 ·子データベース方式による列追加を行う際の、デ ータベース定義体と定義体クロス ·リファレンス 'テーブルの図である。
[図 17]は、レコード中にそのレコードを作製したデータベース定義体のバージョンを 保持する場合の図である。
[図 18]は、ブロック中に、そのブロック中のレコードを作成したデータベース定義体の バージョンを保持する場合の図である。
[図 19]は、列追加：過去非遡及型 ·直接追加方式のデータベース定義体と定義体ク ロス ·リファレンス ·テープノレの図である。
[図 20]は、列追加:過去非遡及型 ·直接追加方式で列追加を行ったレコードが、デー タベース上に格納された図である。
[図 21]は、列追加：子データベース方式で作成された子データベースを親データべ ースにまとめる際の、データベース定義体と定義体クロス'リファレンス 'テーブルの図 である。
[図 22]は、列追加：子データベース方式で作成された子データベースを親データべ ースにまとめる際、 record3までのまとめが終了した図である。
[図 23]は、列追加：子データベース方式で作成された子データベースを親データべ ースにまとめる際、まとめが完了した図である。
[図 24]は、列追加：子データベース方式で作成された子データベースを親データべ ースにまとめる際、まとめが完了した時点のデータベース定義体と論理構造変換テ ーブノレの図である。
[図 25]は、列削除:定義削除方式の図である。
[図 26]は、列削除:定義削除方式を行った場合のデータベース定義体と論理構造変 換テープノレの図である。
[図 27]は、列削除：過去保持 ·子データベース方式を適用するデータベースの図であ る。
[図 28]は、列削除:過去保持 '子データベース方式を適用し、準備作業が終了した時 点のデータベースの図である。
[図 29]は、列削除:過去保持 '子データベース方式を適用し、準備作業が終了した時 点のデータベース定義体と論理構造変換テーブルの図である。
[図 30]は、列削除:過去保持'子データベース方式を適用し、 record3までの処理が 終了した時点のデータベースの図である。 [図 31]は、列削除:過去保持，子データベース方式を適用し、処理が完了した時点の データベースの図である。
[図 32]は、列削除:過去非保持型'直接列削除方式を適用し、 reCord3までの処理が 終了した時点の図である。
[図 33]は、列削除:過去非保持型 ·直接列削除方式を適用した場合の、データべ一 ス定義体と論理構造変換テーブルの図である。
圆 34]は、列削除:過去非保持型'直接列削除方式を適用した場合の、列削除後の データベース定義体と論理構造変換テーブルの図である。 圆 35]は、列削除:過去非保持型 ·直接列削除方式を適用した場合の、列削除が完 了した時点のデータベースの図である。
[図 36]は、オーバーフロ一'ブロック管理テーブルを示した図である。
[図 37]は、列追力!] :子データベース方式に、オーバーフロ一'ブロック管理テーブルを 用 、たデータベースを適用した場合の図である。
[図 38]は、列追加：直接追加方式に、オーバーフロー 'ブロック管理テーブルを用い たデータベースを適用した場合の図である。
[図 39]は、再編成時に、新規ロケーション 'テーブルの初期容量を小さくする手法を 応用して、一部の再編成を高速に行う場合の例である。
[図 40]は、ァクセラレータ一 ·システムの原理を示した図である。
[図 41]は、ァクセラレータ一'システムに、オーバーフロ一.ブロック管理テーブルを用
V、たデータベースを適用した場合の図である。
[図 42]は、 XMLの例である
[図 43]は、 XMLの例である
[図 44]は、 XMLに適用した場合に、複数の列を 1つの代替キーにする方法の図であ る。
[図 45]は、複数の列を 1つの代替キーにする方法の場合の、代替キーエントリーの図 である。
[図 46]は、過去非遡及型の場合の、レコード読み取り要求を処理する図である。
[図 47]は、過去非遡及型の場合の、レコード更新要求を処理する図である。 [図 48]は、過去非遡及型の場合の、レコード削除要求を処理する図である。
[図 49]は、過去非遡及型の場合の、レコード追加要求を処理する図である。
[図 50]は、過去遡及型の場合の、レコード読み取り要求を処理する図である。
[図 51]は、過去遡及型の場合の、レコード更新要求を処理する図である。
[図 52]は、過去遡及型の場合の、レコード削除要求を処理する図である。
[図 53]は、過去遡及型の場合の、レコード追加要求を処理する図である。
[図 54]は、論理構造変換テーブルの例である。
[図 55]は、論理構造変換をロジックで行う場合の例である。
[図 56]は、任意のデータベース定義体から、新たなデータベース定義体を作成する 場合の例である。
[図 57]は、親データベースと子データベースの例である。
発明を実施するための最良の形態
[0012] 本明細書では、方法の説明が多くなる力 ここで述べる方法を用いてシステムを構築 することが可能である。
[0013] [レコード]
レコードとは、必ず 1つのユニークな主キーとゼロ個若しくは 1個以上のノンユニーク なキー（代替キー。結果的にユニークであっても問題はない）を持つ。この他に、キー とはならない項目（列）を持つことができる。主キーは、例えば従業員データベースの 場合、従業員コードなど従業員を識別できるコードであり、代替キーは、氏名や生年 月日などであり、データベースによっては、無くても良いし、複数あっても構わない。 また、意味を持った主キーとなるべき項目存在しないレコードに関しては、格納順の 連番などを付与して、それを主キーとしても良い。項目（列）は、情報の単位であり、キ 一となるものとキーとならないものがある。レコード中に 1つ以上存在する。列は、固定 長形式でも良いが、可変長形式とすることも可能である。可変長形式の場合は、列毎 に可変長とすることが可能であり、列情報が存在しない列も、列として認識することが 可能である。レコードは論理的な集合体として捉えることができる。主キーに従属する 項目の集合を広義の論理レコードと定義できる。しかしながら、常に主キーに従属す る項目すベてを 1つの論理レコードとするわけではない。例えば、従業員コードに従 属する項目を考えた場合に、氏名や生年月日、所属入社年月日、電子メールァドレ ス、内線電話番号などの情報がある。更に、住所や出身学校、家族といった情報もあ る。その他に、給与や賞与の情報もある。また、更に評価結果情報もある。
[0014] これらの情報は、扱うことが多い単位毎にまとめたり、セキュリティの関係から、一部を 別のレコードにしたりする。例えば、上記の場合であれば、従業員マスターには、氏 名、生年月日、入社年月日、所属、電子メールアドレス、内線電話番号を入れる。従 業員個人ファイルには、住所、出身学校、家族を入れる。従業員給与ファイルには、 給与や賞与の情報を入れる。従業員評価ファイルには、評価結果を入れる。このよう にして、従業員コードに従属する論理レコード力 つ作成される。また、それらの論理 レコードは、複数の物理レコードから構成することが可能である。例えば、従業員評 価ファイルを例に取る。評価項目として、従来は評価項目を挙げて、上司がスコアリン グする方式を採用していたとする。それに対して、部下の評価を付け加えることにな つたとする。そのような場合、上司の評価と部下の評価をまとめて、新たに 1つの物理 レコード =論理レコードとすることが可能である。一方、それまでの上司の評価を格納 してあるレコードはそのままとして、新たに部下の評価を入れた物理レコードを作製し 、両者を併せて新たな論理レコードとすることが可能である。また、この場合、上司の 評価ファイルと部下の評価ファイルを、各々、独立した論理レコードとして扱うことも可 能である。これを、更に細分化すると、項目毎に主キーと組み合わせて、別々の物理 レコードとすることも可能である。本明細書では、特に断りの無い限り、論理的なレコ ードを対象とした説明を行う。
[0015] この広義のレコードは、実体として存在させる 1つ目の方法として、主キーに従属する 項目をすベて並べて、 1つの連なりとすることができる。これが、一般的なレコードの 概念である。実体として存在させる二つ目の方法として、主キーとその主キーに従属 する項目の 2つ力 なるレコード、つまり、狭義のレコードとして格納することが可能で ある。主キーに従属する項目毎に狭義のレコードを作製するという方法である。この 狭義のレコードの集合体が広義のレコードとなる。実体として存在させる 3つ目の方 法としては、 1つ目の方法と二つ目の方法の折衷案的な方法で、主キーに従属する 1 つ以上の項目力 なる狭義のレコードを複数作製し、その狭義のレコードの集合を広 義のレコードとするものである。本明細書では、特に断りの無い限り、広義のレコード を使用する力 子データベース方式は、第 3の方法を用いたものである。
[0016] データベース定義体とは、一般的なデータベース 'システムでデータベースを定義す るために用いられている。データベース定義体は、データベースに関する物理構造、 論理構造、格納構造、インデックス構成情報、属性など幅広い情報を保有しているが 、少なくともレードの構成情報を持つものとする。レコードの構成情報とは、物理構造 、論理構造、属性情報を含む情報のことである。本明細書では、データベース定義 体という用語を用いて説明を行うが、その内容は、レコード構成情報に関するもので ある。つまり、データベース定義体におけるレコード構成情報を、データベース定義 体と呼ぶということである。データベース定義体のバージョンとは、同一のテーブルに 対して、列の追加や削除、変更を行うことにより、レコードの論理構造や物理構造が 変更されるが、その変更に伴って新たに作成するデータベース定義体を新しいバー ジョンのデータベース定義体とする。ここで、テーブルとは、データベースで一般的に 用いられる、行と列力もなる或るファイル (例えば従業員マスター、得意先マスター、 商品マスター、売掛金ファイルなど）のことを意味し、後述する、ロケーション'テープ ルゃ代替キー ·ロケーション 'テーブル、論理構造変換テーブルなどとは異なるもの である。本明細書で使用している、各種のテーブルは、ロケーション 'テーブルや代 替キー'ロケーション 'テーブル、論理構造変換テーブルなどとの名称で呼び、単に テーブルと呼ぶことは無!、。
[0017] まず、列の追加'変更 ·削除を行う際に、アプリケーション 'プログラムの変更を要しな いことについて述べる。従来の方法は、データベースをー且停止し、その後に列の追 カロ '削除'変更を行い、データベースの再稼動を行っていた。このため、データべ一 スに格納されているレコードの形式は最新の一世代のみに限られていた。この情報 はデータベース定義体に格納されている。アプリケーション.プログラムも、データべ ースの最新の世代に合致するように修正されたものを用いて 、た。
[0018] 本発明では、データベースに格納されているテーブル内のレコードに対して、そのレ コードが作成されたデータベース定義体のバージョン情報を保持すること、複数世代 のデータベース定義体を保有すること、各バージョンの論理構造を変換すること、ァ プリケーシヨン'プログラムがどのバージョンのデータベース定義体を使用しているか の情報 (アプリケーション 'プログラムのバージョン情報)を保有すること、および、複数 のバージョンの振り分けを行うことにより、実現するものである。図 46は、複数のバー ジョンのアプリケーション.プログラムから、データベースにアクセスする場合の図であ る。この図では、 READ処理（読み出し処理は、 SQLでは、多くの場合 SELECTで ある。）を図示している。アプリケーション 'プログラムなどの要求元 30から READ命令 をデータベース.システムに指示する。データベース.システムでは、リクエスト受付処 理 31を行い、その後、インデックス検索処理 32を行う。ここまでは、従来のデータべ 一ス'システムと同様である。データが格納されているデータ格納部 33から目的のレ コードを見つける。そのレコード内またはレコード外の特定の場所に、そのレコードが 作成された時のデータベース定義体のバージョン情報（レコード 'バージョン情報）を 予め格納しておくものとする。このレコード 'バージョン情報は、そのレコードを作製' 変更する都度、格納するものとする。
[0019] 読み出したレコード 'バージョン情報に合致するバージョンのデータベース定義体に 、レコードを送る。ここで物理構造に基づいて、レコードが格納されているブロック等（ データベース ·システムによって名称が異なる）から、レコードを読み出す。そして、読 み出したレコードを、そのバージョンの論理構造に変換する。その後、論理構造変換 部を用いて、アプリケーション 'プログラムのデータベース定義体のバージョンに変換 を行う。論路構造変換部は、或るバージョンのデータベース定義体により定義された レコードを、別のバージョンのデータベース定義体により定義されたレコードに変換 するものであり、例えば、論理構造変換テーブルや論理構造変換プログラム 'ロジック などが使用できる。変換されたレコードをアプリケーション 'プログラムに渡す。このよう に、格納されているレコードが作成されたデータベース定義体のバージョンと、読み 出す側のアプリケーション 'プログラムが使用しているデータベース定義体のバージョ ン情報に関係なぐレコードを読むことが可能となる。 READ処理と同様に、レコード の更新、追加、削除も可能である。
[0020] 列の追加は、大別すると過去遡及型と過去非遡及型の 2つの方法となる。各々の型 は更に、子データベース追加方式と、直接追加方式の 2つに分かれるため、全体とし て 4つの実現方式が存在する。
過去遡及型は、列の追加を行う際に、それまでに作成されたレコードに対して、追カロ する列の値を予め用意し、それらの値を既存のレコードに追カ卩していくものである。こ のようにすることによって、既存のレコードも追加列の値を保有することになる方式で ある。過去非遡及型は、列の追加を行う際に、それまで作成されたレコードに対して、 追加する列の値を用意せず、新たに作成されるレコードに関しては追加列の値を持 つ力 列追加を行う以前に作成されたレコードに関しては、追加列に値を持たない方 式である。追加列に値が無いレコードの追加列の値は、初期値やヌル値、または情 報を持たない列としてアプリケーション 'プログラムに渡す。また、特定のリターンコー ドを渡すことも可能である。これは、以下の説明でも同様である。
[0021] 子データベース方式とは、既存の列追加が行われるデータベースとは別に、追加す る列を格納するデータベースを別の新規データベース (子データベース）として定義 し、既存のデータベースの主キーと追加する列（項目）を組としてレコードの形式にし (子レコード）、新規データベースの主キーは、既存のデータベースの主キーを設定 し、新規データベースに子レコードを作成する方法である。
[0022] 直接列追加方式とは、既存のデータベースに対して、直接的に列を追加する方法で ある。これは、「データベース再編成システム」で示された方法を応用して実施する。 列の追加はレコード毎に行うが、処理の単位はブロックである。現用のロケーション' テーブルに対して、新規のロケーション 'テーブルを用意し、列の追カ卩が行われたブ ロックは新規のロケーション 'テーブルによって管理されるようにする。既存のデータ ベースに対して、順次、レコードを読み出し、列の追加を行った後、そのレコードを再 度ブロックに格納する。そのブロックのアドレスを新規ロケーション 'テーブルに書く。 この方法の場合、既存のデータベース上で、新たな列が追加されたレコードが格納さ れて 、るブロックと、追加されて 、な 、レコードが格納されて 、るブロックが混在する ことになるため、それらを分離するために、列操作ポインターを使用する。更に、列操 作完了ポインターを用いて、列追加の完了点を定める。また、列操作ポインタ一は、 各ロケーション.テーブルの列追加が終了している最終ブロックを指しているエントリ 一の次のアドレスを指すようにする。列操作ポインタ一は、既存と新規の各ロケーショ ン.テーブルに対して、一つづつ保持する。
[0023] 上記の子データベース方式を使用した場合には、「データベース再編成システム」を 使用して再編成を行うときに、別々に分かれている 2つのデータベースを一つにまと めることが可能である。データベースが 2つに分かれている場合は、作成時の負荷が 軽いと言う利点がある力 データベースが 2つに分かれているため、追加されたデー タベースにも、ロケーション ·テーブルや主キーを持たなければならず、その分だけデ ータベースが大きくなる。また、一つのレコードを検索するために 2つのデータベース をアクセスする必要があり、その分だけ、システムの負荷が増加する。し力しながら、 レコード全体を対象にするアクセスが少なぐ項目を指定したアクセスが多くて、尚且 つ、追加した項目を使用するアプリケーションが少ない場合には、効率的な場合もあ るので、使用状況に応じた使い分けが必要である。
[0024] 列の削除も、列の追加と同様に、大きく分けると、過去保持型と過去非保持型の 2つ になる。過去保持型は、更に、定義削除方式と子データベース方式に分かれる。過 去非保持型は直接列削除方式のみである。定義削除方式は、削除する列を定義上 で削除し、実際の削除は行わずにおく方法である。この方法を用いると、削除はデー タベースの定義変更だけで済むので、極短時間で作業が完了する。レコードの読み 出しは、実際にデータベース上に書かれているレコード長で行うが、アプリケーション •プログラムにレコードを渡す際に、削除されている列をレコードから削除して渡すこと になる。一方、古いデータベース定義体を使用しているアプリケーション 'プログラム にレコードを渡す場合には、削除された列を含んだレコードとすることが可能となる。
[0025] 列の追加'削除以外に、列の変更がある。列変更は列追加と同様に、過去遡及型と 過去非遡及型となる。
[0026] 子データベース方式は、「データベース再編成システム」を使用して再編成を行う方 法と同様の方法を用いて実施するが、レコードから列を削除して、列削除後のレコー ドを書き戻す。更に、削除項目と元のデータベースの主キーとを組み合わせて、新し いレコードを作製し、そのレコードを子データベースに書き込む方法である。この方 法は、列削除時に新たなデータベースを作成するため、列削除の時間が余分に掛か るというデメリットがある力 万一、削除項目を使用しているアプリケーション 'プロダラ ムが存在した場合に、そのプログラムの稼動ができなくなる、という事態を回避するこ とができる。子データベース方式の場合も定義削除方式と同様に、古いデータべ一 ス定義体を使用しているアプリケーション 'プログラムにレコードを渡す場合には、削 除された列を含んだレコードとすることが可能となる。
[0027] 過去非保持型は、削除前のレコードから、削除対象列を削除して、短くなつた削除後 のレコードを、データベースに書き戻す方法である。この方法は、「データベース再編 成システム」を使用して再編成を行う方法と同様の方法を用いることにより、実現可能 となる。現用のロケーション ·テーブルに対して新規ロケーション'テーブルを使用し、 列削除後のレコードが格納されているブロックのアドレスは、新規ロケーション'テー ブルによって保持される。どのレコードまで、列削除を行つたかを区分するために、現 用と新規のロケーション 'テーブルに対して、 1つづつ、列操作ポインターを使用する 。この方式の場合は、削除された項目を使用しているアプリケーション 'プログラムが あると、そのアプリケーション 'プログラムに問題が発生する可能性があるため、注意 が必要である。
[0028] 次に、列の変更の場合に関して述べる。列の変更は、属性と長さに関するものである 。これを分類すると、その列の属性の変更で長さの変更が無い場合、列の属性の変 更が無く長さが変更になる場合、列の属性と長さの両方が変更になる場合の 3つに なる。属性とは、その列に格納されている情報の型のことで、数値であるとか、文字、 日付などと ヽつた属'性がある。
[0029] まず、列の属性の変更に関して説明する。何れも、列追加：直接追加方式と同様の 方法を用いる。また、列の属性変更を既存のレコードにまで適用するの力否かで方 法が分かれる。既存のレコードの変更列の属性を変更する場合には、列追加の過去 遡及型と同じように、既存のレコードの変更列の属性を変更する。これを、列変更:過 去遡及型と呼ぶ。これに対して既存のレコードの変更列の属性は以前のままとし、新 たなデータベース定義体を用いて作成するレコードの変更列の属性を変更する方法 を、列変更:過去非遡及型と呼ぶ。
[0030] 列変更:過去遡及型の場合は、現用ロケーション 'テーブルに対して、新規ロケーショ ン 'テーブルを設け、再編成を実施しながら、既存のレコードの変更列を変更していく 。列変更:過去遡及型の場合は、列追加:過去遡及型と同様に、レコードの形式は最 新のデータベース定義体バージョンのみとすることが好ましい。この場合は、データ ベース定義体は最新のバージョンのみを保有することになる。一方で、古いデータべ ース定義体を使用したアプリケーション 'プログラムにレコードを渡すために、論理構 造変換テーブルを使用する。
[0031] 列変更:過去非遡及型の場合は、既存のレコードに対する変更を行わないので、既 存のレコードに対する操作は不要である。新たに作成されるレコードは、最新パージ ヨンのデータベース定義体を用いたものだけでなぐ既存の古!、データベース定義体 バージョンを用いたレコードも追加される。また、既存のレコードは、作成された時点 の形式のままであるので、データベース定義体は各バージョンを保有することになる 。この場合も、論理構造変換テーブルを使用する。
[0032] 次に列の長さの変更に関して説明する。列の長さを変更する方法も、過去遡及型と 過去非遡及型を選択する事が可能である。過去遡及型とは、既存のレコードの変更 列の長さを新しいデータベース定義体の長さに合わせるように変更する方法である。 この場合の、既存のレコードに対する変更は、列追加:過去遡及型で述べた方法と 同様である。過去非遡及型の場合には、既存のレコードに対しては変更を行わず、 新たに作成されるレコードで、最新のデータベース定義体を用いて作成されるレコー ドの変更列の長さが変更されることになる。
[0033] この場合も、論理構造変換テーブルを用いることで、レコードのバージョンとアプリケ ーシヨン'プログラムのバージョンが異なっても、レコードの受け渡しが可能であるが、 列の長さを変更した場合、情報の桁あふれや切り捨ての可能性があるため、適用す る場合には、運用上の問題が発生しないことを確認することが必要である。
[0034] データベース定義体に関しては、次の様になる。最初のデータベース定義体は、シ ステム管理者が人手で作成する。これをバージョン 1 (VI)とする。これに対して、例え ば、列の追加を行う場合に、追加後のデータベース定義体を V2とする。この V2は、 VIに対して、どの列をどの位置に追加する力、また、追カ卩の方法は、子データべ一 ス方式か、直接追加方式か、といったことを、システム管理者が、データベース 'シス テムに対して指定する。この指定に基づき、データベース 'システムでは、 VIの情報 と合成することにより、 V2を作成する。各バージョンのデータベース定義体とは、その バージョンの物理情報と論理情報を組み合わせたものである。
[0035] その後、 V2の定義を元に、必要があれば新 VIの定義を作成する。必要になる場合 は、例えば、 VIで子データベース方式の形式であったもの力 V2で再編成により一 つのデータベースになった場合など、物理構造が変化したが、論理構造は変わらな い場合である。
[0036] 次に、 VIと V2の論理構造変換テーブルを作成する。これは、 VIの各列と V2の各列 力 Sどのように対応しているかを示すものである。論理構造変換テーブルは、各パージ ヨンのデータベース定義体の論理構造を抜き出し、列が横に並ぶようにしたものであ る。この論理構造変換テーブルによって、各バージョン間の論理構造の変換が行え る。図 54が論理構造変換テーブルの例である。
実施例
[0037] 列の追加 '削除'変更により、データベースの或るテーブルのレコードの物理構造や 論理構造が変更された場合に、旧来のバージョンのデータベース定義体を用いて稼 動していたアプリケーション 'プログラムを、変更することなく利用することが可能であ ることに関して説明を行う。ここでは、データベース定義体のバージョン力 VI、 V2、 V3、 V4の 4つの場合を例にとって説明する力 バージョンの数が幾つであっても実 施可能である。本明細書では、方法についての説明が多くなる力 この方法を用いて システムを構築することにより、データベース 'システムとすることができる。本明細書 と図面では、多くの個所で、列の属性に関しての説明を省略している。これは、列の 属性変更以外ではあまり意味を持たな 、からである。
[0038] [複数バージョンのアプリケーション 'プログラムからのアクセス]
図 46は、過去非遡及型の READ処理に関する図である。また、図 50は過去遡及型 の READ処理に関する図である。ここでは、列追カ卩の場合を例にとって、過去遡及 型と過去非遡及型の説明を行う。過去非遡及型とは、既に作成されたレコードに対し て、新たに追加する列を反映させない (遡及させない)ものである。つまり、過去のレ コードは、そのレコードが作成された形式のままである。新たに作成されるレコードは 、列の追カ卩を行ったデータベース定義体を使用しているアプリケーション 'プログラム 力 は、追加列を含んだ レコードが追加され、以前のバージョンのアプリケー シヨン 'プログラムからは、追加列を含まない形式のレコードが追加されることになる。 つまり、異なる形式のレコードが混在することになる。
[0039] これに対して、過去遡及型とは、既に作成されたレコードに対して、新たに追加する 列の値を用意し、それを既存のレコードに適用して、データベース上のすべてのレコ ードが追加列を含んだ形式のレコードとする。また、新たに作成されるレコードは、追 加列が含まれた形式のレコードのみとする。過去遡及型の場合には、以前のパージ ヨンのデータベース定義体を使用しているアプリケーション 'プログラムの内、レコード を追加するものは、追加列に関する情報を持っていないため、その列の値に関して は初期値かヌル値、または情報を持たない列をセットすることが好ましい。または、最 新以外のデータベース定義体を使用して 、るアプリケーション'プログラムの内、レコ ードを追加するものを稼動させな 、ようにするとしてもよ 、。
[0040] 本発明では、データベースに格納されているレコードに、そのレコードが作成された データベース定義体のバージョン情報を保持すること、複数バージョンのデータべ一 ス定義体を保有すること、各バージョンの論理構造を変換すること、アプリケーションプログラムにどのバージョンのデータベース定義体を使用して 、るかの情報（アプリケ ーシヨン'プログラムのバージョン情報）を保有すること、および、複数のバージョンの 振分けを行うことにより、実現できるものである。
[0041] データベース 'システムでは、一般的にサブスキーマとスキーマという表現が用いられ る力 本明細書では、特にそのような用語を用いずにデータベースという用語を用い て説明を行う。本明細書の説明で「データベースに対する列追加」や「データベース に対するアクセス」というような表現は、特定の種類のデータベース 'ファイル (例えば 、従業員ファイル）に対する操作を表しており、データベース 'システムに格納されて いるデータベース 'ファイル全体に対するものでは無い。また、特定の種類のデータ ベース'ファイル力 複数のデータベース 'ファイル力も構成されている場合、例えば 、従業員マスターで、新たに追加された列の出身地が別のデータベース 'ファイルに 格納されている力 レコードとしては一つのセットとして扱われる場合、には、各々の データベース ·ファイルに対してもデータベースと 、う表現を使用して 、る。 [0042] [過去非遡及型]
[過去非遡及型: READ]
図 46では、過去非遡及型の READ処理 (読み出し処理: SQLでは、多くの場合 S ELECT)を図示している。アプリケーション.プログラム 30から READ命令をデータ ベース'システムに指示する。データベース 'システムでは、リクエスト受け処理 31を 行う。 SQLの解析、データベースの種別（どのデータベース 'ファイルに対するァクセ ス力 、アプリケーション 'プログラムのデータベース定義体とそのバージョンの確認、 アクセス種別（この場合は READ処理）、キー種別（主キーか代替キー力、代替キー の場合はどの代替キーか）、そのキー値 (ターゲット ·キー値）、キー条件 (ターゲット · キー値と等しい、大きい、小さいなど）が間違いないかの確認である。その後、インデ ックス検索処理 32を行い、 目的のレコードが格納されている位置を検出する。ここま では、従来のデータベース 'システムと同様である。データ（レコード）が格納されてい る部分 (データ格納部） 33から目的のレコードを見つける。そのレコード内またはレコ ード外の特定の場所には、そのレコードが作成された時のデータベース定義体のバ 一ジョン情報（レコード 'バージョン情報）を予め格納しておくものとする。このレコード 'バージョン情報は、データベースを作成する時点で行い、その後、アプリケーション •プログラム力もレコードを追加 ·変更する都度、格納するものとする。図 17が、レコー ド形式の例である。ここでは、レコード長、データベース定義体バージョン情報の他に 、列の値が並んでいる。図 18は、レコード外の特定の場所にデータベース定義体バ 一ジョン情報を持つ場合の例である。
[0043] 読み出したレコードのデータベース定義体のバージョン情報に合致するバージョンの データベース定義体 物理構造に基づ 、て、レコードが格納されて 、るブロック等 ( データベース ·システムによって名称が異なる）から、レコードを読み出す。物理構造 によっては、複数のデータベースに 1つの レコードが分散している場合もある力 その場合は、必要な複数のデータベースを読む。そして、読み出したレコードを、そ のバージョンの論理構造に変換する。その後、論理構造変換テーブルを用いて、ァ プリケーシヨン'プログラムのデータベース定義体のバージョンに変換を行う。変換さ れたレコードをアプリケーション.プログラムに渡す。このように、格納されているレコー ドが作成されたデータベース定義体のバージョンと、読み出す側のアプリケーション' プログラムが使用しているデータベース定義体のバージョン情報に関係なぐレコー ドを読むことが可能となる。図 46では、データベース定義体と論理構造変換テープ ルを分離して表現して 、るが、各データベース定義体に論理構造変換テーブルを持 たせるような形式を採っても、同様に実現可能である。これは、以下の説明でも同様 である。図 46のデータベース定義体は、レコードの物理構造と論理構造の変換を行 うロジックを含むように図示してある。このようにデータベース定義体の内部に、論理 構造変換用のロジックを含むような構成とすることも可能であるし、データベース定義 体は純粋な定義のみを記述し、論理構造変換を行うロジックはデータベース定義体 とは別な物として構成することも可能である。この説明は、図 46から図 53までに関す る説明にお 、ても同様である。
[過去非遡及型： REWRITE]
次に図 47に関して説明する。これは、過去非遡及型の REWRITE (更新処理。多く の SQLでは、 UPDATE)に関して図示したものである。 REWITEとは、ー且読込ん だレコードに対し、更新を加えて書き戻す処理である。この図では、既にレコードの読 込みと更新処理が終了しているものとする。アプリケーション ·プログラム 30から REW ITEの要求をデータベース 'システム 2に対して行う。データベース 'システムでは、リ タエスト受付処理 31を実行する。ここでは、 SQL解析、データベースの種別、アプリ ケーシヨン'プログラムのデータベース定義体バージョンの確認、アクセス種別（ここで は REWRITE)、レコード情報が間違いないかの確認を行う。次に、アプリケーション 'プログラムのデータベース定義体バージョンによる振分け処理 37を行う。アプリケー シヨン 'プログラムのデータベース定義体が VIであれば、 VIのデータベース定義体 にレコード情報を割振る。データベース定義体では、レコードから、物理構造に変換 する。次に、格納位置設定を行う。このレコードは READ処理によって読込まれてお り、その時点カゝら排他が行われていれば格納位置に変化が無いので、 READ時の 格納位置を設定する。 READ力 S排他されていない場合には、 REWRITEを行うまで の間に、格納位置が変化している可能性があるため、格納位置の検索を行う。次に、 そのレコードを格納するブロック内で、格納するレコードが以前に占めていたスぺー スと新たに必要となるスペースが異なる場合に、ブロック内で後続のレコードを移動す る。更に、格納するレコードにバージョン情報設定を行う（38)。その後、レコードの格 納を行う。次に、代替キーに関して変更が生じた場合は、当該代替キーに関する変 更を行う。
[0045] [過去非遡及型： DELETE]
図 48は、過去非遡及型の DELETE処理を示したものである。 REWRITEと似てい る。 DELETE処理の場合も、ー且、レコードを読込んだ上で DELETEすることが一 般的であるが、いきなりキー値を与えて DELETEすることも可能である。リクエスト処 理受付 31、データベースの種別、アプリケーション 'プログラムのデータベース定義 体バージョンによる振分け 37、各バージョンのデータベース定義体による物理構造 変換は、 REWRITE処理と同様である。次に、格納位置設定または格納位置検索を 行う。これも、 REWRITE処理と同様である。レコード削除の場合は、そのレコードが 占めていたスペースが空くため、当該レコード以降のレコードの移動が必要となる。 そして、レコードの削除を実施する。次に、代替キーがあれば、そのレコードに関する 代替キー'エントリーの削除を行う。
[0046] [過去非遡及型: INSERT]
図 49は、過去非遡及型の INSERT (レコードの追加）処理である。上記例と同様に、 リクエスト受付処理を行う。 INSERTの場合は、レコード情報が必要となる。キーに関 する情報はレコードに含まれるので、必要ない。データベース定義体バージョンによ る振分けを行う。その後、データベース定義体により、論理構造と物理構造の変換を 行う。次に格納位置を検索した上、当該レコードが格納されるブロックで、そのレコー ド以降のレコードを移動し、レコードの格納を行う。更に、代替キー'エントリーを追カロ する。
[0047] [論理構造変換部]
次に、論理構造を変換することに関して説明を行う。まず、論理構造変換部の一例と して論理構造変換テーブルに関して説明を行う。図 54は、論理構造変換テーブルの 例である。この論理構造変換テーブルでは、データベース定義の VIから V4までに 関して、論理構造の変換を行えるように設定されている。一番左側にあるのが列名称 である。その右に、データベース定義 VIの論理構造が記述されている。列 aは、レコ ードのオフセット 0バイトから 8バイト、列 bは存在せず、列 cは、レコードのオフセット 8 バイトから 12バイト、列 dはレコードのオフセット 20バイトから 14バイト、列 eは、レコー ドのオフセット 34バイトから 16バイト、歹 Ufは、レコードのオフセット 50バイトから 18バイ ト、となっている。同様に、 V2、 V3、 V4の論理構造が記述されている。 V4の列 eは列 履歴が削除となっている力 これは、列削除がこのバージョンで行われたことを示して いる。また、オフセットと長さが括弧付きで表現されている力 これは、 V4の論理レコ ード中には存在しな 、が、列 eの値が過去データとして保存されて!、ることを表して!/ヽ る。レコードが V4で作成され、アプリケーション ·プログラムが V4以外である場合に、 アプリケーション ·プログラムに列 eの値を渡すために使用される。 V4のアプリケーショ ン.プログラムが要求元である場合には列 eを含まないレコードを渡すことは当然のこ とである。列履歴は、その列が、そのデータベース定義体バージョンで作成されたり、 削除されたりしたかの履歴情報となって 、る。この論理構造変換テーブルの一番左 にある列は、そのデータベースに対する複数のデータベース定義体の各々が保有し て 、る列を「OR」条件で抜き出したものとなる。
この論理構造変換テーブルを用いて、論理構造の変換を行う例を説明する。まず、 R EAD処理の場合に関して説明する。読込んだレコードのデータベース定義体バー ジョンが VIであったとする。また、アプリケーション 'プログラム（要求元）のデータべ ース定義体バージョンが V3であったとする。この場合には、論理構造変換テーブル の VIから V3に列を渡していくことになる。列 aは、読込んだレコードのオフセット 0バ イトから 8バイトであり、それを、 V3用のレコードの、オフセット 0バイトから 8バイトにセ ットする。列 bは、読込んだレコードには存在しないことが分かるので、 V3用のレコー ドの列 b (オフセット 8バイトから 10バイト）には、列 bの初期値かヌル値、または情報を 持たない列をセットする。列 cは、読込んだレコードのオフセット 8バイトから 12バイトで あり、それを、 V3用のレコードの、オフセット 18バイトから 12バイトにセットする。列 d は、読込んだレコードのオフセット 20バイトから 14バイトであり、それを、 V3用のレコ ードの、オフセット 30バイトから 14バイトにセットする。以下、列 e, fのセットを行う。こ れで、 V3用のレコードが完成するので、アプリケーション 'プログラムにそのレコード を渡す。
[0049] 次に、読込んだレコードのデータベース定義体バージョンが V4であったとする。また 、アプリケーション 'プログラムのデータベース定義体バージョンが V2であったとする 。この場合には、論理構造変換テーブルの V4から V2に列を渡していくことになる。 列 aは、読込んだレコードのオフセット 0バイトから 8バイトであり、それを、 V2用のレコ ードの、オフセット 0バイトから 8バイトにセットする。列 bは、読込んだレコードのオフセ ット 8力ら 10ノイトを、 V2用のレコードの、オフセット 8バイトから 10バイトにセットする 。列 cは、読込んだレコードのオフセット 18バイトから 12バイトであり、それを、 V2用の レコードの、オフセット 18バイトから 12バイトにセットする。列 dは、読込んだレコードの オフセット 30バイトから 14バイトであり、それを、 V2用のレコードの、オフセット 30バイ トから 14バイトにセットする。列 eは、 V4の論理レコード上のオフセット 64バイトから 16 ノイトを、 V2用のレコードの、オフセット 44バイトから 16バイトにセットする。列 fは、読 込んだレコードのオフセット 44バイトから 20バイトを、 V2用のレコードの、オフセット 6 0バイトから 20バイトにセットする。これで、 V2用のレコードが完成するので、アプリケ ーシヨン'プログラムにそのレコードを渡す。
[0050] 次に、 REWRITE, DELETE, INSERTの場合は、論理構造変換テーブルを使用 していないので、データベース定義体間の論理変換は行わない。単一のバージョン 内で、論理構造と物理構造の変換を行うのみである。この論理構造変換テーブルは 、新しいバージョンのデータベース定義体を作成する時に更新する。更新は、データ ベース'システムが自動的に行うことが可能である。
[0051] ここで、レコード、物理構造、論理構造に関して定義を行っておく。レコードとは、デ ータベースに格納するデータの単位で、 1つ以上の項目（列）の連なりである。本明 細書では、それに加えて、そのレコードが作成'変更された時のデータベース定義体 のバージョン情報を含むものとする。論理構造とは、 1つ以上の列の連なりからなるレ コードの構造である。列の順序、列の先頭位置、長さ、列の属性、列の履歴などの情 報を含むが、最低限、列の先頭位置と長さ情報を含むものとする。物理構造とは、そ のレコードがどのように格納されているかを示すものである。また、レコードに格納され ている情報の内、データベース定義体のバージョン情報は、アプリケーション 'プログ ラムに渡す必要の無いものであり、データベース 'システムによって管理される。
[0052] [論理構造変換部:別の方式]
上記では、論理構造変換テーブルを用いて論理構造の変換を行うことにつ ヽて説明 を行った。しかしながら、論理構造を変換するには、このような論理構造変換テープ ルを用いずに行うことも可能である。一つ目の方法は、バージョン間の論理変換を、 プログラム 'ロジックとして保持する方法である。図 55にその事例を図示する。この場 合には、各バージョン間の論理構造変換をすベて 1対 1で記述すると、バージョンが 多くなつた場合には、その論理構造変換式の数が幾何級数的に多くなるので問題が ある。中間的な形式に一旦変換して、その後、目的の形式に変換する方式とすること で、論理構造返還式の数を少なくすることが可能となる。二つ目の方法は、各パージ ヨンのデータベース定義体にある論理構造同士を比較して、同じ列同士を移動する 方法である。列の属性や長さが変更されている可能性もあるため、単純に列を移動 するだけでなぐ属性変更や長さの変更を行うことも必要な場合がある。この説明は、 以降の論理構造変換テーブルに関する説明全体に適用するものである。
[0053] [過去遡及型]
次に過去遡及型に関して説明する。過去遡及型は、既に作成されたレコードに対し て、新たに追加する列の値を用意し、それを既存のレコードに適用して、追加列が含 まれたレコードとする。また、新たに作成されるレコードは、追加列が含まれたレコード のみとする。
[0054] [過去遡及型： READ]
図 50は、過去遡及型の READ処理を図示している。アプリケーション 'プログラム 30 力 READ命令をデータベース ·システムに指示する。データベース ·システムでは、 リクエスト受け処理 31を行う。その後、インデックス検索処理 32を行い、目的のレコー ドが格納されている位置を検出する。ここまでは、従来のデータベース 'システムや過 去非遡及型の READと同様である。データ（レコード）が格納されている部分 33から 目的のレコードを見つける。過去遡及型では、レコードのデータベース定義体のバー ジョン情報は最新のもの（この場合は V4)のみしか存在しないので、レコード内にデ ータベース定義体のバージョン情報を格納しておく必要は無い。 [0055] 読み出したレコード 'バージョン情報は V4なので、 V4のデータベース定義体に、レコ ードを送る。ここで物理構造に基づいて、レコードが格納されているブロック等 (デー タベース'システムによって名称が異なる）から、レコードを読み出す。物理構造によ つては、複数のデータベースに 1つのレコードが分散している場合もある力 その場 合は、必要な複数のデータベースを読む。そして、読み出したレコードを、そのバー ジョンの論理構造に変換する。その後、論理構造変換テーブルを用いて、アプリケー シヨン'プログラムのデータベース定義体のバージョンに変換を行う。変換されたレコ ードをアプリケーション.プログラムに渡す。このように、格納されているレコードが作 成されたデータベース定義体のバージョンと、読み出す側のアプリケーション 'プログ ラムが使用しているデータベース定義体のバージョン情報に関係なぐレコードを読 むことが可能となる。
[0056] 新たに追加された列力 他のテーブルとジョインしている場合、従来のデータベース では、必ずジョインが行われる力 上記で説明したデータベースでは、列追加が行わ れる前のアプリケーション 'プログラムからアクセスした場合、その列をアプリケーショ ン ·プログラムには渡さな 、ので、その追加された列に対応する値が存在しな 、場合 であっても、アプリケーション 'プログラムに悪影響が無い。
[0057] [過去遡及型： REWRITE]
次に図 51に関して説明する。これは、過去遡及型の REWRITEに関して図示したも のである。アプリケーション'プログラム 30から REWITEの要求をデータベース ·シス テム 2に対して行う。データベース 'システムでは、リクエスト受付処理 31を実行する。 次に、論理構造変換テーブル 36を用いて、アプリケーション 'プログラムのデータべ ース定義体バージョンの論理構造変換を行う。この場合、変換先の論理構造は最新 の V4のみである。次に、 V4のデータベース定義体 35により、論理構造から物理構 造への変換を行う。次に、格納位置設定を行う。このレコードは READ処理によって 読込まれており、その時点力 排他が行われていれば格納位置に変化が無いので、 READ時の格納位置を設定する。 READが排他されていない場合には、 REWRIT Eを行うまでの間に、格納位置が変化している可能性があるため、格納位置の検索を 行う。次に、そのレコードを格納するブロック内で、格納するレコードが以前に占めて いたスペースと新たに必要となるスペースが異なる場合に、ブロック内で後続のレコ ードを移動する。更に、格納するレコードにバージョン情報設定 38を行う。その後、レ コードの格納を行う。次に、代替キーに関して変更が生じた場合は、当該代替キーに 関する変更 39を行う。
[0058] [過去遡及型： DELETE]
図 52は、過去遡及型の DELETE処理を示したものである。 REWRITEと似ている。 DELETE処理の場合も、ー且、レコードを読込んだ上で DELETEすることが一般 的であるが、いきなりキー値を与えて DELETEすることも可能である。リクエスト処理 受付 31、論理構造変換テーブル 36による、各バージョンから V4への論理構造の変 換を行い、 V4のデータベース定義体による物理構造変換を行う。これらは、 REWRI TE処理と同様である。次に、格納位置設定または格納位置検索を行う。これも、 RE WRITE処理と同様である。レコード削除の場合は、そのレコードが占めていたスぺ ースが空くため、当該レコード以降のレコードの移動が必要となる。そして、レコード の削除を実施する。次に、代替キーがあれば、そのレコードに関する代替キー 'ェント リーの削除を行う。
[0059] [過去遡及型： INSERT]
図 53は、過去遡及型の INSERT (レコードの追加）処理である。上記例と同様に、リ タエスト受付処理を行う。 INSERTの場合は、レコード情報が必要となる。キーに関 する情報はレコードに含まれるので、必要ない。データベース定義体バージョンによ る振分けを行う。その後、データベース定義体により、論理構造と物理構造の変換を 行う。次に格納位置を検索した上、当該レコードが格納されるブロックで、そのレコー ド以降のレコードを移動し、レコードの格納を行う。更に、代替キー'エントリーを追カロ する。構造変換に関する方式は、過去非遡及型と同様である。
[0060] [特別なデータベース構造]
ところで、殆どのデータベース 'システムでは、既存のレコードに列を追加するには、 ー且、データベースを停止させないと実施できない。本発明者が発明した、「データ ベース検索格納方式（日本国特許第 3345628、米国特許第 6654868号参照）」、 または、「データベース格納検索システム」にて発明されたデータベースを用いること で、データベースを停止させることなく稼動させたままで、既存のレコードに対して列 の追カ卩を行うことが可能である。
[0061] 本発明者は、従来の階層型インデックスに代えてロケーション 'テーブルと代替キー' テーブルという概念を導入し、インデックスの処理に伴う複雑な処理を簡素化し、テー ブル自体の検索をバイナリー 'サーチなどの手法を用いることにより、高速化と、メン テナンスの容易性を確保できるようにした「データ格納検索方式」を発明した。更に、 「データベースの再編成システム、並びに、データベース（以下、「データベース再編 成システム」と呼ぶ)特許出願 PCTZJP03Z11592」では、「データ検索格納方式」 で提案したデータベースに対して、データベースを稼動させながら再編成が行える 仕組を提案した。更に、代替キー'テーブルに対して代替キー'ロケーション'テープ ルを付加することにより、効率的な再編成が可能となることを発明している。
また、「データベースのァクセラレーター機能（以下、「ァクセラレーター機能」と呼ぶ。 特許出願 PCTZJP03Z13443)」では、ロケーション.テーブルや代替キ一.ロケ一 シヨン'テーブルのコピーをァクセラレータ一'システムが保持し、レコードを検索する 際に、ァクセラレータ一'システムのロケーション 'テーブルや代替キ一'ロケーション' テーブルを使用することで、アクセスが並行処理できることを発明している。
また、「データ格納検索システム」では、プライマリ一'ブロックからオーバーフロ一'ブ ロック、ォーノ一フロー'ブロック力らォーノ ーフロー'ブロックへの連結を、ォーノ 一 フロ一.ブロック管理テーブルを用いて行う方式を発明している。「オーバーフロ一'ブ ロック管理テーブル」では、代替キ^ ~ ·ブロックと代替キ^ ~ ·オーバーフロ^ ~ ·ブロック の連結、代替キー ·オーバーフロー ·ブロックと代替キー ·オーバーフロー ·ブロックの 連結も同様に、代替キー ·オーバーフロー ·ブロック管理テーブルを用いて行う方式 である。
[0062] [データ格納検索方式]
ここで、本発明者が提案した「データ格納検索方式」の内容について、図 1を用いて 簡単に説明しておくことにする。プライマリー 'システム 1は、「データ格納検索方式」 を適用するシステムのうち、主となるものである。データ'レコードは、ブロック 11に主 キーの順に格納する。ブロック 11は、プライマリ^ ~ ·ブロックとオーバーフロ^ ~ ·ブロッ クとカもなるが、図 1では、プライマリー ·ブロックのみを図示してある。そのプライマリ 一 ·ブロックにデータ ·レコードを追加する場合に、プライマリー'ブロックが満杯である 場合に、オーバーフロ一'ブロックを、そのプライマリ一'ブロックに連結して、データ' レコードを格納する。オーバーフロ^ ~ ·ブロックに、更にオーバーフロ^ ~ ·ブロックを連 結することが可能である。各プライマリー ·ブロックのアドレスが記載されたロケーショ ン ·テーブル 'レコード（または、ロケーション'テーブル ·エントリ一）を連続領域に有 するロケーション.テーブル LCを有する。ロケーション 'テーブル LCは連続した領域 に予め確保する。ここで連続した領域とは、論理的な順序であり、物理的な領域では 、離れていても良い。このような場合には、アドレス変換テーブルを用いて、論理的に 連続していると扱うことができる。これは、以下の説明でも同様である。ロケーション' テーブルの使用領域の最後を示すために、最終ポインター 101を用いる。
[0063] 最後のプライマリー 'ブロックにレコードが追加できない場合は、その後にプライマリ 一 ·ブロックを追加して、レコードの格納を行う。その追加したプライマリ一'ブロックの アドレスを、ロケーション 'テーブル LCに書き、最終ポインターの位置を 1つ後方に動 かす。
[0064] ここで、連結とは、物理的に連結されていることを意味するのではなぐプライマリー- ブロックが一番目のオーバーフロ^ ~ ·ブロックのアドレスを保持し、 1番目のオーバー フロ一.ブロックが 2番目のオーバーフロ一'ブロックのアドレスを保持している状態が 、あた力も物理的にブロックが繋がれているように扱えることから、そのような表現を使 用している（以下、同様である）。このように格納するので、ロケーション 'テーブル 'ェ ントリーは、主キーの順番に並んでいる。主キーによる検索は、ロケーション'テープ ル LCの最初のアドレスと最終ポインター 101が指して!/、るロケーション'テーブル ·ェ ントリーの間に対して、バイナリ一'サーチを行うことにより、ブロックを見つけ、そのブ ロック内で目的のレコードを見つける。当該ブロックにオーバーフロ^ ~ ·ブロックが連 結されている場合は、オーバーフロー 'ブロックも検索の対象となる。ここでは、検索 に関して述べている力 レコードの更新、追加、削除も同様のロジックで実現できる。
[0065] 代替キーは、データベースにおけるノンユニークなキーのことで、例えば、従業員デ ータベースにおける、氏名や生年月日などのことである。代替キーは、或る種類のデ ータベースに対して、無くても良いし、複数あっても構わない。図 1では、代替キーが 3つ存在する場合の例を図示して 、る。代替キー値と主キー値からなる代替キー ·レ コード (または代替キー 'エントリー）は、代替キー 'ブロック（22A、 22B、 22C)に代 替キー値の順番に格納する。その代替キー 'ブロックに代替キー 'エントリーを追加す る場合に、その代替キー'ブロックが満杯である場合に、代替キー'オーバーフロー' ブロックを代替キー 'ブロックに連結して、代替キー 'エントリーを格納する。代替キー 'オーバーフロ^ ~ ·ブロックに、更に代替キ^ ~ ·オーバーフロ^ ~ ·ブロックを連結するこ とが可能である。図 1では、代替キ一'オーバーフロ一'ブロックは省略してある。
[0066] 各代替キ一'ブロックのアドレスが記載された代替キ一'ロケーション'テーブル'レコ ード (または、代替キー'ロケーション 'テーブル ·エントリー）を連続領域に有する代替 キ一.ロケーション.テーブル (AALC、 ABLC、 ACLC)を有する。代替キ一'ロケ一 シヨン'テーブルは連続した領域に予め確保する。代替キー'ロケーション 'テーブル の使用領域の最後を示すために、代替キー最終ポインター（29A、 29B、 29C)を用 いる。代替キー'エントリーの追加で、既存の代替キー'エントリーの代替キー値より大 き 、代替キー値を持つ代替キー ·エントリ一は、最後の代替キー ·ブロックに格納し、 その代替キー ·ブロックに格納できな 、場合には新たに代替キー ·ブロックを作成し、 その代替キー'ブロックに当該レコードを格納する。
[0067] 代替キ一.ロケーション.テーブルと代替キ一.ブロックを組にして、代替キ一.テープ ル（20A、 20B、 20C)と呼ぶ。或る代替キーを持ったレコードを検索する方法は、代 替キ一.ロケーション.テーブルの最初のエントリーと、代替キー最終ポインター（29A 、 29B、 29C)が指している代替キ一'ロケーション'テーブル'エントリーの間をバイナ リ一.サーチし、 目的の代替キ一.ブロックを見つけ、その代替キ一 ·ブロックの中を検 索して、 目的の代替キーを持つ代替キー'エントリーを見つける。その代替キー 'プロ ックに代替キー'オーバーフロー ·ブロックが連結されて 、る場合には、代替キー'ォ 一バーフロ一.ブロックも検索の対象となる。次に、その代替キ一'エントリーの主キー によって、ロケーション'テープノレ LCをバイナリ一'サーチし、 目的のブロックを見つけ 、そのブロック内から目的のレコードを見つけ出す。当該ブロックにオーバーフロ一' ブロックが連結されて 、る場合は、オーバーフロー .ブロックも検索の対象となる。 [0068] 尚、代替キーはノンユニークであるので、同一の代替キー値を持ったレコードが複数 存在する可能性がある。この場合は、代替キー 'ブロック中の次の代替キー'レコード が同一の代替キー値である場合には、上記と同様な動作を繰り返す。ここでは、検索 に関して述べている力 レコードの更新、追加、削除も同様のロジックで実現できる。 また、複数種類の代替キーが存在する場合には、代替キーの種類と同じ数の代替キ 一 ·テーブルを作成し、使用することになる。
[0069] [データベース再編成システム]
次に、「データベース再編成システム」に関して、図 2を用いて説明する。「データべ ース再編成システム」は、「データ格納検索方式」で提案された、構造がシンプルな 点を利用して、データベースを停止することなぐ再編成を行う仕組を提案している。 この「データベース再編成システム」について簡単に説明をする。再編成とは、ォー バーフロ一.ブロックの解消、適正な初期格納率の確保、フラグメンテーションの解消 の 3つを行うことである。オーバーフロ一'ブロックの解消とは、次のようなことである。 プライマリ一'ブロックにオーバーフロ一'ブロックが多数連結されると、それらのブロッ クに対してレコードを挿入しょうとしたときに、プライマリ一'ブロックとオーバーフロ一' ブロックにまたがってレコードが主キー値の順に並んでいなければならないので、移 動すべきレコードの数が多くなつてしまう。レコードの検索をする場合でも、複数のブ ロックにまたがって検索を行わなければならないので、効率が低下してしまう。このよう なことを避けるために、オーバーフロ一'ブロックを無くして、プライマリ一'ブロックに する。
[0070] 適正な初期格納率の確保とは次のようなことである。ブロック内に予め適当な割合の 空き空間を設けておくと、レコードの挿入が発生した場合でも、直ちにオーバーフロ 一.ブロックを追加することなくレコードの挿入が行える。ところがレコードの挿入が幾 度も繰り返されると適正な初期格納率力 外れた空き空間になってしまう。これを初 期の状態に戻すものである。フラグメンテーションの解消は、適正な初期格納率の確 保と似ている力 不要になったプライマリ一'ブロックやオーバーフロ一'ブロックを削 つたり、格納率が少ないブロックは、統合するなどして、ブロックが均一に使用された 状態にすることである。ここでは、プライマリ一'ブロックとオーバーフロ一'ブロックに 関して述べたが、代替キー ·ブロックと代替キー ·オーバーフロー ·ブロックに関しても 全く同様である。
[0071] ロケーション 'テーブルとブロックの再編成においては、ロケーション 'テーブルを現用 LCと新規 LNの 2つ用意する。更に、各々のロケーション 'テーブルに対して、再編成 がどこまで終了して 、るかを示すための再編成ポインターを、現用ロケーション'テー ブルに対して 1つ RPLCと、新規ロケーション 'テーブルに対して 1つ RPLNを設ける 。図 2では、オーバーフロ一'ブロックの解消に関して図示している。現用ロケーション 'テーブル LCが指しているブロック 11は、プライマリ一'ブロック 12と、オーバーフロ 一.ブロック 13、 14力らなる。現用ロケーション 'テーブル LCの最初のブロックは、プ ライマリ一'ブロック 0のみからなるので、新規ロケーション 'テーブルの最初のロケ一 シヨン 'テーブル'エントリーに書き移す。次に、プライマリー 'ブロック 1を見ると、ォー バーフロ一.ブロック 1—2、 1—3が連結されている。プライマリ一'ブロック 1を、新規口 ケーシヨン'テーブル LNのロケーション'テーブル'エントリー 1に書き移す。次に、ォ 一バーフロ^ ~ .ブロック 1—2の連結を切り離し、新規ロケーション 'テーブル LNのェン トリー 2にオーバーフロ^ ~ ·ブロック 1—2のアドレスを書き、プライマリ^ ~ ·ブロックとする 。同様に、オーバーフロ^ ~ ·ブロック 1—3も、新規ロケーション 'テーブル LNのエントリ 一 3にオーバーフロ^ ~ ·ブロック 1—3のアドレスを書き、プライマリ^ ~ ·ブロックとする。
[0072] 同様に、次々とオーバーフロ一'ブロックの切り離しを行い、現用ロケーション'テープ ル LCのエントリー 3が管理していたブロック 3までのオーバーフロ^ ~ ·ブロック解消が 終了した時点を、図 2は示している。現用ロケーション 'テーブルの再編成ポインター RPLCは、現用ロケーション 'テーブル LCのエントリー 3の次のアドレスを指している。 また、新規ロケーション 'テーブルの再編成ポインター RPLNは、新規ロケーション' テーブルのエントリー 6の次のアドレスを指している。
[0073] 次に適正な初期格納率の確保と、フラグメンテーションの解消は、一時点で複数のブ ロックを対象にし、それらのプライマリ一'ブロック、オーバーフロ一'ブロック間で、適 正な初期格納率になって 、な 、ブロック間でレコードの移動を行 、、ブロック内に適 正にレコードが格納されるようにするもので、状況によって、ブロックを削除したり、追 加したりする。ここでは、プライマリ一'ブロックとオーバーフロ一'ブロックに関して述 ベたが、代替キー ·ブロックと代替キー ·オーバーフロー ·ブロックに関しても全く同様 である。
[0074] 再編成中にデータベースをアクセスすることか可能である。まず検索に関して述べる 。検索は、再編成ポインター RPLCが指しているエントリーが指しているブロックに格 納されているレコードの主キー値が、 目的の主キー値より大きいか小さいかの判定を 行う。小さい場合には、新規のロケーション 'テーブル LNを用いて、先頭と再編成ポ インター RPLNが指している間に対してバイナリー 'サーチを行うことにより、 目的のレ コードの検索を行う。大きいか等しい場合は、現用のロケーション 'テーブル LCを用 V、て、再編成ポインター RPLCと最終ポインター FPが指して 、る間に対してバイナリ 一.サーチを行うことにより、 目的のレコードの検索を行う。ここでは検索の場合を説 明したが、更新、追加、削除も同様に行える。
[0075] 代替キ一'テーブルにおける再編成やアクセスも、ロケーション 'テーブルとブロックの 場合と、ほぼ同様な方式で実行可能である。また、代替キー ·テーブルに関して、代 替キー'ロケーション 'テーブルを保持する形式を新たに発明している。以上で、「デ ータベース再編成システム」の説明を終了する。
[0076] [オーバーフロ一 ·ブロック管理テーブルを用いた形式]
上記では、プライマリー 'ブロックとオーバーフロー 'ブロック、オーバーフロー'ブロッ クとオーバーフロ一'ブロックの連結は、当該ブロックの直前のブロックが、当該ブロッ クのアドレスを保持するという形式であった。これに対して、「データ格納検索システム 」では、プライマリー 'ブロックとオーバーフロー 'ブロック、オーバーフロー 'ブロックと オーバーフロ一'ブロックの連結に関して、図 36にあるように、オーバーフロ一'ブロッ ク管理テーブルを用いて行うものである。図 36の場合、ロケーション'テーブル'ェン トリー 4が指しているプライマリ一'ブロックには、 3つのオーバーフロ一'ブロックが連 結されている。これらのアドレスをオーバーフロ^ ~ ·ブロック管理テーブルのエントリー 1, 2, 4が保持している。このような形式を採った場合、ブロックやオーバーフロ一'ブ ロックがロケーション ·テーブルに比較して低速な記憶装置に格納されている場合に 、オーバーフロ一'ブロックを次々に読んでいく必要が無いため高速なアクセスが可 能となる。 [0077] 以上力 本発明に関連する、本発明者による既存の発明の概要である。「データ格 納検索方式」または、「データ格納検索システム」を用いたデータベースに対して、列 の追加 '削除'変更をデータベースを停止せずに適用する場合の事例を説明する。 特に、列追加:過去遡及型、列削除:過去非保持型を使用する場合に、データべ一 スの稼動を «I続したままで、既存のレコードに対する列追加、削除が可能であること、 また、子データベース方式を用いた列追加を行った場合に、その後の再編成で、デ ータベースを稼動させながら、複数のデータベースに分かれているレコードを一つに まとめることが可能であること、列削除でも削除列を子データベースとすることが可能 であることなどを説明する。
[0078] 図 3は、本実施例で使用するデータベースの原型である。ここでは、プライマリー 'ブ ロックとォーノ一フロー ·ブロック、ォーノ一フロー ·ブロックとォーノ一フロー ·ブロッ クの連結、及び、代替キー'ブロックと代替キー'オーバーフロー 'ブロック、代替キー 'オーバーフロ^ ~·ブロックと代替キ^ ~·オーバーフロ^ ~·ブロックの連結に関しては、「 データ格納検索方式」で示された方法によっている場合の説明とする。ここでは、ロケ ーシヨン'テーブル 10とブロック 11を示している。ブロック中には、レコードが recordO から record6までの 7つのレコードが格納されている。各レコードは、 a, c, d, e, fの 5 つの項目（列）を持っている。このレコードを格納'検索する方法としては、「データ格 納検索方式」で述べて 、る方式によるものである。ここでは代替キー'テーブルは省 略してある。図 4は、図 3に示した原型データベースのデータベース定義体である。 データベース定義体には、データベースの物理的な構成情報、ブロックの大きさ、適 正な初期格納率、データの型などの様々な情報が付属することになるが、本図では、 本発明に必要な情報に絞って記載している。データベース定義体とは、データべ一 ス定義情報をデータ化したものである。
[0079] 列の追カ卩に関して説明を行う。列の追加は、大別すると過去遡及型と過去非遡及型 の 2つの方法となる。また、各々の型は、子データベース追加方式と直接追加方式の
2つに分かれるため、全体として 4つの実現方式が存在する。
[0080] [列の追加]
[過去遡及型] 過去遡及型は、列の追加を行う際に、既に作成されたレコードに対して、追加する列 の値を予め用意し、それらの値を既存のレコードに追カ卩していくものである。このよう にすることによって、既存のレコードも追加列の値を保有することになる方式である。
[0081] [列の追加：過去遡及型 ·子（Subsidary)データベース方式]
図 5、図 6を用いて、図 3のデータベースに、新たに列（項目） bを追加する場合を説 明する。ここで説明する方式は、追加する列を子データベースとして作成する方法で ある。この方式を、過去遡及型'子データベース方式と呼ぶ。まず、過去遡及型'子 データベース方式で列 bを、列 aの直後に追加することを、システム管理者がデータ ベース'システムに指令する。指令する方法は、画面を用いて対話型に行う方法が好 ましい。データベース 'システムでは、列 bが追加された後のデータベースの定義体 V 2 (図 6の D2と D21)を作成する。図 6では、定義体クロス'リファレンス.テーブル X6 1S 併せて記述してある。データベース定義体 V2と定義体クロス'リファレンス'テー ブルの作成方法に関しては後ほど説明する。図 6の D21では DB— Aに対して、 DB —A1が別のデータベースとして追加されている。 DB— Aを親データベース、 DB— A1を子データベースとする。図 6では、 VIも併せて記載してある力 過去遡及型で は基本的に最新のデータベース定義体のみがあれば、それより前のバージョンのデ ータベース定義体は不要である。次に、 DB—A1用の子ロケーション 'テーブル 15を 作成する。最終ポインター 151を用意し、子ロケーション 'テーブル 15の先頭を指す ようにする。 DB— A1用の子ブロック 16は、レコードを格納する都度確保していっても よいが、予め必要な数のブロックを確保しても良い。以上が準備作業となる。 DB— A 1では、列 bが実際の意味を持っているが、列 bだけでは検索や更新が出来ないので 、 DB— Aの主キーの列 aと組み合わせてレコードとし、ブロック中 16に格納する。
[0082] 次に、列 bの追加を行う。これは過去遡及型であるので、列 bの内容に関するデータ は予め用意し、これらのデータベースの外部にあるとする。まず、 recordOの列 bを追 加する場合について説明する。 recordOを読み、レコードが存在することを確認した ら、 DB—A1の最初の子ロケーション 'テーブル 15のエントリー（子ロケーション'テー ブル.エントリー）を排他し、 recordOの主キーと recordO用の列 b (実際にはデータべ ースの外にあるデータ）とを組み合わせて、子レコード recordO 1を作成し、子ブロック 0 (160)に recordOlを書き込む。次に、 recordlの列 bを追加する場合について説 明する。この場合は、 recordOlと同じブロックに格納するとする。同様に、 recordlを 読み込み、 recordlの主キーと recordlの列 bとを組み合わせて、子レコード record 11を作成し、 DB—A1の子ブロック 0 (160)に格納する。同様に record21を DB— A1の子ブロック 0 (160)に格納する。ここで、ブロック 0の適正な初期格納率になった ので、ロケーション 'テーブルのエントリー 0の排他を解除する。上記の説明では DB — Aのレコードを読み込むことになつている力 これは列追加時に、 DB— A上で、当 該レコードが既に削除されていないかを確認するためである。
[0083] DB— Aと DB— A1の双方のロケーション 'テーブルに FPと記した矢印が 1つずつあ る力 これは、各々のロケーション 'テーブルがどこまで使用されているかを示す、最 終ポインター（101と 1^1)である。最終ポインターの他に、どのレコードまで列 bの追 カロがされているかを示すために、列操作ポインター 102を用いて、列 bが追加されて V、るレコードが格納されて 、るブロックを指し示すようにすると、データ ·アクセスの効 率ィ匕に対して有効である。列操作ポインターを用いる場合には、 DB— Aのブロック単 位に列追加を行うことが好ましい。図 5では、 record2までの列追加が完了しているが 、ブロック単位では、ブロック 0 (110)までなので、列操作ポインター 102はブロック 0 の直後を指している。
しかしながら、列操作ポインターを使用しなくとも、 DB— A1にレコードが存在してい な ヽ場合は、列 bの追加が未完であると判断することも可能である。
[0084] 図 7は、このようにして record6まで、列 bの追加が行われ、列追加が完了した状態を 示している。列追加の完了は、追加列用のデータのエンドを検出した時点とすること 力 最も単純である。列追加が完了すると、列操作ポインタ一は最終ポインター 101 と同 Cf立置を指すことになるので不要となる。よって、図 7では図示していない。
[0085] 以上では、代替キーに関する説明を省略している力 代替キーに関しては、次のよう になる。まず、列 bを追加する以前力 存在した代替キーに関しては、 DB— Aに付帯 するものとして扱う。また、列 bを追加することによって影響を受けないので、操作をす る必要が無い。次に、列 bが代替キーの対象となる場合は、最初の準備段階で、 DB A1に対して列 bが代替キーであることを通知する。次に DB A1で、空の列 b用の 代替キ一'テーブルを作成する。次に、 recordOl, recordl l等を作成するのと並行 して、列 bと列 aからなる代替キー 'エントリーを作成し、代替キー 'ブロックに格納する 。この場合は、列 b用の代替キー'テーブルを、 DB— Aの中に作成することも可能で あるし、 DB_A1の中に作成することも可能である。
[0086] [列追加完了後のレコード追加]
次に、列追加が完了した後で、レコードの追加を行う場合に関して、図 8を用いて説 明する。過去遡及型で新たに作成されるレコードは、追加列が含まれたレコードのみ とすることが好ましい。過去遡及型の場合には、以前のバージョンのデータベース定 義体を使用しているアプリケーション 'プログラムの内、レコードを追加するものは、追 加列に関する情報を持っていないため、その列の値に関しては初期値力ヌル値、ま たは情報を持たない列をセットすることが好ましい。または、最新以外のデータベース 定義体を使用しているアプリケーション 'プログラムの内、レコードを追加するものを稼 動させな!/、ようにするとしてもよ!/、。
[0087] 図 8と図 53を用いて説明する。アプリケーション 'プログラムから、レコードを追加する 場合は、次のようになる。 record7を追加する。図 8は、 record7の追加が終了した時 点の図である。過去遡及型の場合、最新バージョンのデータベース定義体を使用し ていないアプリケーション ·プログラムは稼動させない、という方法があるが、この方法 は、従来力 存在する方法なので目新しいことはない。ここでは、特に最新以外のバ 一ジョンのデータベース定義体を使用しているアプリケーション 'プログラムからのレコ ード追加の場合に関して説明する。
[0088] 図 53は、データベース定義体が V4まである図である力 この図の、論理構造変換テ 一ブル 36力 VIと V2の 2つであり、最新のデータベース定義体 35が V2用であると する。アプリケーション 'プログラムが V2のデータベース定義体を使用したものである 場合には、論理構造の変換は不要であるので、通常のレコード追加と同じである。ァ プリケーシヨン'プログラムが VIのデータベース定義体を使用している場合に関して 説明する。まず、アプリケーション 'プログラムからの処理要求を、リクエスト受付処理 を行う。次に、論理構造変換テーブル 36を使用して、 VIの論理構造を V2の論理構 造に変換する。論理構造変換テーブル 35の具体的な形式は、図 6の X6に示してあ る。 VIの列 a (オフセット 0バイトから 8バイト）は、 V2のオフセット 0バイトから 8バイトに セットする。列 bは、 VIでは保持していないので、 V2の列 b (DB— A1のオフセット 8 バイトから 10バイト）には、列 bの初期値カ ル値、または情報を持たない列をセット する。 VIの列 c (オフセット 8バイトから 12バイト）は、 V2のオフセット 8バイトから 12バ イトにセットする。以下、列 d, e, fも同様にセットする。この後、 V2のデータベース定 義体（図 53の 35)を用いて論理構造を物理構造に変換する。 V2のデータベース定 義体の詳細は、図 6の D2、 D21に図示してある。 V2では、子データベース方式を用 いて列 bの追加を行ったため、 DB— Aと DB— A1を連結している。親データベース は論理構造変換テーブルでセットされたレコードを DB— Aに格納すればょ ヽが、 DB — A1は、 DB— Aの主キー値をオフセット 0バイトから 8バイトにセットしてから格納す る。
[0089] 上記では、データベース定義体のバージョンが 2つの場合に関して説明したが、図 5 3に図示したように、データベース定義体の各バージョン間の論理構造変換を行うこ とにより、バージョンが幾つ存在しても、実施可能である。また、論理構造変換テープ ルを用いずに論理構造の変換を行う方法が別途存在することは、前述したとおりであ る。
[0090] [過去遡及型 ·子データベース方式で列を追加中のデータベースへのアクセス] 次に、このような列追カ卩を行っている最中に、レコードに対するアクセスが可能である ことを説明する。基本的な仕組は、図 50から図 53を用いて複数バージョンのデータ ベース定義体を使用している別々のアプリケーション 'プログラムからのアクセスが可 能である、という説明にあるとおりである。図 5が、列追加の途中の状態を示している ので、この図を用いて説明を行う。併せて、図 6も使用する。最新のデータベース定 義体 V2を使用するアプリケーション ·プログラムが、データベースに対してアクセス可 能であることは勿論、それに加えて、データベース定義体の各バージョンと論理構造 変換テーブルを保持することにより、データベース定義体 VIを使用していたアプリケ ーシヨン ·プログラムと、データベース定義体 V2を使用するアプリケーション'プロダラ ムの双方が、同じデータベースに対して、アクセス可能であることも説明する。
[0091] アプリケーション 'プログラムが、どのバージョンのデータベース定義体を使用してい るかについては、アプリケーション ·プログラムで指定する必要がある。これは、アプリ ケーシヨン'プログラム内にコーディングしておくの力 最も単純な方法である。この場 合には、使用するデータベース定義体のバージョンを変える場合に、アプリケーショ ン.プログラムの変更が必要になる。他の方法としては、データベース定義体のバー ジョンをアプリケーション 'プログラムに対して外部情報 (例えば、ノ ラメーターなど）と して与えるようにすることで、バージョンの変更に伴うアプリケーション 'プログラムの変 更を少なくすることも可能である。これは、他の列追加や列削除、列更新に関する説 明に共通である。この他に、アプリケーション 'プログラムの作成日を見て、データべ ース 'システムが自動的に、どのバージョンのデータベース定義体を使用しているか 判定する方法も可能である。この場合は、各バージョンのデータベース定義体の作 成日とアプリケーション 'プログラム作成日を比較すれば、簡単に判別することが可能 である。
[0092] レコードのアクセスに関する説明を行う前に、データベース定義体の列状況欄に関し ての説明を、図 6のデータベース定義体の V2 (D2と D21)を使用して行う。列状況欄 とは、その列の履歴と、その時点の状況を示すためのものである。列 bの列状況欄は 、「DB_A1と連結」という説明になっている。これは、列 bが、論理的には DB_Aの 中の列となっている力 物理的には列 aの直後に列 bが存在せず、論理的に連結され ていることを示している。また、同様に V2の DB— A1のデータベース定義体 D21の 列 bの列状況欄は、「DB_A」から連結」となっている。これは、列 bの実体は、 DB_ A1に存在するが、論理的には、 DB— Aの一部として存在していることを示している。 列状況欄の使用方法は、これ以下の明細書の別項中で、多様な使用ができることを 、更に詳細に説明する。
[0093] ここから、列を追加中のデータベースに対して、図 5を用いてアクセスが可能であるこ とを説明する。要求元がアプリケーション 'プログラムであるとする。また、アクセスが主 キーに対してであり、その主キー値が alである場合であるとする。まず、リクエスト受 付処理を行う。その間で要求元がデータベース定義の VIを使用している力 V2を使 用しているかの判定を行う。次に、インデックス検索処理を行う。 DB— Aのロケーショ ン.テーブル 10に対して、バイナリ^ ~ ·サーチを行い、ブロック 0の中の recordlを見 つけ出す。データベース定義体の V2を用いて、 recordlの物理構造を V2の論理レ コードに変換する。次に、アプリケーション 'プログラムがデータベース定義体 VIを使 用している場合は、論理構造変換テーブルを用いて V2の論理形式から VIの論理 形式に変換する。構造変換の方法に関しては、図 54を用いて説明したとおりである。 変換後のレコードを要求元に渡す。要求元がデータベース定義体 V2を使用してい る場合は、論理構造の変換が不要であるので、データベース定義体によって作成さ れたレコードを要求元に渡す。
[0094] 次に、アクセスが主キーであり、主キー値が a3である場合に関して述べる。前記例と 同様に、要求元がどのデータベース定義体を使用しているかを判定する。次に、 DB — Aのロケーション 'テーブルに対して、バイナリ^ ~ ·サーチを行い、ブロック 111の中 の record3を見つけ出す。列操作ポインター 102を使用している場合は、列操作ボイ ンターが指しているブロックよりも、 目的の主キー値が大きいので、列追加が終了して Vヽな 、ブロックに対するアクセスであることが分かるので、 DB— A1に対するアクセス を行う必要がない。列操作ポインターを使用していない場合は、 DB— A1の子ロケ一 シヨン'テーブルに対してバイナリ一'サーチを行い、 record31が無いので、まだ、列 bが追加されていないレコードであると判断できる。このように、列操作ポインターを用 いると列追カ卩中のアクセスが効率的に実行できる。
[0095] 要求元がデータベース定義の VIを使用している場合には、主キー値が alの場合と 同様に、論理構造変換テーブルを使用して V2から VIに論理形式の変換を行い、変 換後のレコードを要求元に渡す。要求元がデータベース定義体 V2を使用している 場合は、論理構造の変換が不要であるので、データベース定義体によって作成され たレコードを要求元に渡す。
[0096] 代替キーでのアクセスは、 目的の代替キー値により、代替キ一'ロケーション'テープ ルのバイナリ一'サーチを行い、代替キ一'ブロックまたは代替キ一'オーバーフロ一' ブロック力 、 目的の代替キー値を持つ代替キー'エントリーを搜し、その代替キー' エントリーの主キー値により、ロケーション 'テーブルに対して主キーによるバイナリー 'サーチを行い、 目的のレコードを検索すればよい。代替キーは、同一のキー値を持 つレコードが複数存在する場合があり、その場合には、上記の動作を繰り返す。 [0097] 上記では、 READ処理 (検索）の場合を説明した力 図 51、 66、 67を用いて説明し たように、レコードの更新、削除、追カ卩が可能である。以下の説明でも、アクセスが可 能であるという説明は、検索の場合を用いて説明してあるが、この場合と全く同様に、 レコードの更新、削除、追カ卩が可能である。レコードの更新は、検索で見つかったレ コードを更新すればよいし、削除は検索で見つ力つたレコードを削除すればよい。追 加の場合は、まず、検索でレコードを格納する場所を見つけて、そこにレコードの格 納を行う。必要に応じて、論理構造変換テーブルを用いてレコード形式の変換を行う
[0098] レコードの追加を、データベース定義体 VIを使用したアプリケーション 'プログラムか ら実行することは、過去遡及型を用いている場合には好ましくない。何故ならば、列 追カロが完了した後に、列 bを持たないレコードが発生してしまうからである。し力しなが ら、データベース定義体 VIを使用しているアプリケーション 'プログラムでレコードの 追加を行いたい場合には、アプリケーション 'プログラムからは列 bの無いレコードを 書く形になるため、データベース 'システムでは、列 bに関しては、初期値かヌル値、 または情報を持たな 、列として実体データベースを作成することが好ま U、。
[0099] [子データベース方式で列を追加完了後のデータベースへのアクセス]
上記では、列を追カ卩中のデータベースへのアクセスに関して説明を行った力 前記 の方法を応用すれば、列追加を完了した時点での、データベースへのアクセスが問 題なく行える。列追カ卩中との相違は、列追加完了後のアクセスでは、データベース定 義体 V2からの検索で列 bの追加が完了して 、な 、、 t 、う状態が発生しな 、ことであ る。
[0100] 以上で、列追加'子データベース方式における、列の追加と、追加途中および追カロ 後のレコードの検索に関して述べた。ここでは、既存のデータベースに 1つの列を追 加する場合に関して説明を行った力 上記の方法を用いれば、同時に 2つ以上の列 を追加することや、既存のデータベースに 1つの列を追加した状態で、更に別の列を 1つ以上追加することが可能である。また、本説明では、列 aの直後に列 bを追加する 場合について説明した力 レコードの最後を含んで、レコードの任意の場所に列の追 加が可能である。これによつて、関連性の高い項目を、お互いに近接したレコード内 の個所に配置することが可能となる。また、論理的な位置は挿入として、物理的な位 置はレコードの最後に付けカ卩える、というような方法も可能である。これは、データべ ース定義体の物理構造と論理構造に記述しておけば良い。
[0101] [オーバーフロ一 ·ブロック管理テーブルを用いた場合]
以上の説明では、プライマリ^ ブロックとオーバーフロ^ ~ ·ブロック、オーバーフロ^ ~ · ブロックとオーバーフロ一'ブロックの連結、及び、代替キ一'ブロックと代替キ一'ォ 一ノ ーフロー ·ブロック、代替キー ·ォーノ 一フロー ·ブロックと代替キー ·オーバーフ ロー ·ブロックの連結に関しては、「データ格納検索方式」で示された方法によって!/ヽ た。これを、「データ格納検索システム」で示された、オーバーフロー 'ブロック管理テ 一ブルを用いたデータベースに適用する場合には、次のようになる。
[0102] 図 37を用いて説明する。親データベース（2 : DB_A)に、オーバーフロ一'ブロック 管理テーブル 14を設ける。更に、そのオーバーフロ一'ブロック管理テーブル 14に 対してオーバーフロー 'ブロック管理テーブル 'ポインター 141を設ける。同様に、子 データベース（3 : DB—A1)にも、オーバーフロ一'ブロック管理テーブル 19を設ける 。更に、そのオーバーフロ^ ~ ·ブロック管理テーブル 19に対してオーバーフロ^ ~ ·ブロ ック管理テーブル 'ポインター 191を設ける。図 37の場合は、オーバーフロ一'ブロッ クが発生していないので、オーバーフロ一 ·ブロックは図上で省略してある。また、双 方のオーバーフロ一'ブロック管理テーブルは未使用の状態となっている。これらの オーバーフロ一'ブロック管理テーブルの使用法や、それらを用いた場合のアクセス は、「オーバーフロー 'ブロック管理テーブル」に記述した方法を用いる。
[0103] [列追加:過去遡及型'直接追加方式]
次に、列追加を現用のデータベースに対して、直接的に行う方法に関して述べる。こ こでは、プライマリー 'ブロックとオーバーフロー 'ブロック、オーバーフロー 'ブロックと オーバーフロ^ ~ ·ブロックの連結、及び、代替キ^ ~ ·ブロックと代替キ^ ~ ·オーバーフロ 一 ·ブロック、代替キー ·ォーノ 一フロー ·ブロックと代替キー ·ォーノ 一フロー ·ブロッ クの連結に関しては、「データ格納検索方式」で示された方法に関して述べる。これも 、「データベース再編成システム」の機能を用いて実現する。図 9、図 10を用いて、図 3のデータベースに、新たに列 (項目） bを追加する場合を説明する。ここで説明する 方式は、追加する列を直接、現用のデータベースに追加する方法である。この方式 を、直接追加方式と呼ぶ。まず、子データベース方式と同様に、直接追加方式で列 b を追加することを、データベース 'システムに指令する。データベース 'システムでは、 列 bが追加された新たなデータベースの定義体 V2 (図 10の D210)を作成する。デ ータベース定義体 V2 (図 10の D210)では、 DB— Aに対して、列 bが追加されてレコ 一ドの列数が 5から 6になっている。 V2 (図 10の D210)の列 bの「列状況欄」は、「追 加中」となっている力 これは、列を追カ卩している最中であることを示すもので、列追 加が完了すればブランク状態になる。過去遡及型'子データベース方式と同様に論 理構造変換テーブル を作成する。次に、 DB— A用の列追加ロケーション'テープ ル 8を作成する。更に、現用のロケーション 'テーブル 10と列追加ロケーション'テー ブル 8に対して、列操作ポインター（103と 83)を 1つずつ設ける。更に、列追力卩を開 始する直前の最終ポインター（図 9の 101)と同じ値を持つ、列操作完了ポインター（ 図 9の 104)を設ける。列操作完了ポインターの目的は、直接追加方式による列追カロ を行っている間に、新しいレコードの追加が行われると、最終ポインター（図 9の 101) の指す位置が後方にずれてしまい、どこまでのレコードに対して列追加を行う必要が ある力判別できなくなることを避けるためである。列操作完了ポインタ一は、列追加が 完了するまで、その指している位置は変更されない。また、列追加が完了した場合に は不要となる。直接列追加を行う場合には、列追加を開始した後のレコード追カロは、 列操作完了ポインターが指しているロケーション'テーブル'エントリーの直前のェント リーが指しているブロックには格納せず、列操作完了ポインターが指しているブロック 以降に格納することが好ましい。以上が準備作業となる。
次に、列 bの追カ卩を行う。列 bの内容に関するデータは、これらのデータベースの外部 にあるとする。まず、現用ロケーション'テーブル'エントリー 0、新規ロケーション'テー ブル.エントリー 0、ブロック 0の排他を行う。次に recordOを読み取り、 recordOに列 b を追加する。その後、ブロック 0に列 bを追加した recordOを書き込む。同様に、 recor dlを読み込み、 recordlに列 bを追加する。その後、ブロック 1に列 bを追加した reco rdlを書き込む。ここで、ブロック 0の適正な初期格納率になったので、現用ロケーシ ヨン 'テーブル'エントリー 0、新規ロケーション'テーブル'エントリー 0、ブロック 0の排 他を解除する。列操作ポインタ一は、現用列操作ポインター（103)、新規ロケーショ ン.テーブル列操作ポインター（83)ともに、 2番目のロケーション.テーブル.エントリ 一を指している状態にする。
[0105] 図 9は、このようにして record3まで、列 bの追加が行われた状態を示している。この 説明では、分力りやすくするためにレコードを 1つづつ書き戻すように記述したが、実 際には、 recordOを書き戻す場合に、レコード長が長くなつているので、 recordlをそ の分だけ右側に移動する必要がある。このような、後方のレコードの移動を幾度も行 うことを避けるためには、ブロック内のレコードの長さを計算して、一括して書き戻すな どの方法を採ることが好ましい。本説明では、オーバーフロー 'ブロックに関して説明 から除いているが、オーバーフロ一'ブロックが存在する場合には、オーバーフロ一' ブロックの解消を同時に行うことが好ましい。
[0106] 上記の説明では、従前のブロックに長くなつたレコードが収まることとして説明してい る力 レコードが従前のブロックに収まらない場合には、次のようになる。 1つまたは複 数のブロックを対象とし、そのブロック中のレコード数とレコード長を調べ、それらのレ コードに対して列追カ卩して長くなつたレコードを、適正な初期格納率で収めるために 必要なブロック数 Nを計算する。対象となったブロックの数を Mとする。幾つのブロック を対象とするかは、各々のブロックのレコードの状況による。 M = Nである場合は、ブ ロック数の増減は無い。 M< Nの場合は、その差の数だけブロックを追加する。当然 、新規ロケーション 'テーブル 8のエントリーも、その分、増加する。 M >Nである場合 は、その差の数だけブロックが未使用状態となる。それらのブロック間でレコードの移 動を行い、各々のブロックが、適正な初期格納率となるように調整する。このように、 列追加と再編成を同時に行うことが可能であり、同時に行うことで再編成の回数を削 減することが可能である。これは、過去非遡及型 ·直接追加方式や、列削除'直接削 除方式にも適用される。
[0107] ここでは、既存のデータベースに 1つの列を追加する場合に関して説明を行ったが、 上記の方法を用いれば、同時に 2つ以上の列を追加することや、既存のデータべ一 スに 1つの列を追加した状態で、更に別の列を 1つ以上追加することが可能であるこ とがわかる。 上記のようにして、列の追加を行うが、列追加の完了は、列操作完了ポインターが指 して 、る現用ロケーション'テーブル ·エントリーの直前のブロックに対する列追加が 終了した時点とする。
[0108] 以上では、代替キーに関する説明を省略している力 代替キーに関しては、次のよう になる。まず、列 bを追加する以前力も存在した代替キーに関しては、再編成により、 代替キ一'エントリーが指しているレコードの格納されているブロックのアドレスゃブロ ック番号が変更になる可能性がある。このため、代替キー 'エントリーに、ブロック番号 やブロックのアドレスを保持して ヽる場合には、「データベース再編成システム」で述 ベたように、代替キー 'テーブルの書換えを同時並行して実施する必要がある。一方 、代替キ一 ·エントリーにブロック番号やブロックのアドレスを保持していない場合には 、代替キー 'エントリーに変更が発生しないので、代替キー 'テーブルに対する操作 は不要である。
[0109] 以上の実施例では、既存のレコードの途中に列が追加される例を記述した力 レコー ドの最後に列が追加される場合も、全く同様な方法で実施できることは自明である。
[0110] [過去遡及型 ·直接追加方式での列追カ卩中のアクセス]
次に、このような列追カ卩を行っている最中に、レコードに対するアクセスが可能である ことを説明する。また、過去遡及型'子データベース方式で述べたように、複数のバ 一ジョンのデータベース定義体と論理構造変換テーブルを使用することにより、旧バ 一ジョンの定義体を使用しているアプリケーション 'プログラムからのアクセスが問題な く行えることも同時に説明する。図 9が、列追加の途中の状態を示しているので、この 図を用いて説明を行う。過去遡及型 ·子データベース方式で説明したように、図 50か ら図 53までに記載してある論理は、本方式でも同様である。
[0111] アクセスが主キーであって、その主キー値（ターゲット 'キー値）が alである場合に付 いて説明する。まず、リクエスト受け処理を行い、その中で要求元がデータベース定 義体のどのバージョンを使用しているかを調べる。次に、ターゲット 'キー値力 列操 作ポインター 103が指しているエントリーが管理しているブロックのレコードの主キー 値より小さいか否かを調べる。この場合は小さいことが分かる。小さい場合は、新規口 ケーシヨン'テーブル 8に対してノイナリー'サーチを行う。バイナリー 'サーチは、新 規ロケーション.テーブルの先頭と、列操作ポインター 83が指している間にあるロケ一 シヨン 'テーブル'エントリーに対して実行する。それにより、ブロック 0 (110)を探し、 その中から recordlを見つける。データベース定義体の V2を用いて、 recordlの物 理構造を V2の論理レコードに変換する。次に、アプリケーション 'プログラムがデータ ベース定義体 VIを使用している場合は、論理構造変換テーブルを用いて V2の論 理形式から VIの論理形式に変換する。構造変換の方法に関しては、図 54を用いて 説明したとおりである。変換後のレコードを要求元に渡す。要求元がデータベース定 義体 V2を使用している場合は、論理構造の変換が不要であるので、データベース 定義体によって作成されたレコードを要求元に渡す。
[0112] 次に、アクセスが主キーであって、その主キー値が a5である場合について説明する。
この場合は、ターゲット 'キー値力 列操作ポインターが指しているブロックの主キー 値より大きいか等しい場合に該当する。この場合は、現用ロケーション 'テーブル 10 を使用して、列操作ポインター 103が指しているロケーション'テーブル'エントリーと 、最終ポインター 101が指して!/、る間に存在するロケーション ·テーブル ·エントリーに 対して、バイナリ一'サーチを実行する。ブロック 2 (図 9の 112)の中の record5を見 つけ出す。 record5は、列操作ポインターの情報から、列 bが未追加であることが分 力る。よって、レコードの形式はデータベース定義体 VI (図 10の D10)によって作成 されたものである。また、レコード内またはレコード外の特定の場所に、そのレコード が作成されたデータベース定義体のバージョン情報を格納しておき、それを参照す ることで確実に、そのレコードの形式を判定することが可能である。データベース定義 体 VIを使用して物理構造を論理構造に変換する。要求元がデータベース定義の V 1を使用している場合には、そのままのレコードを要求元に渡す。要求元がデータべ ース定義体 V2を使用している場合は、論理構造変換テーブル（図 10の X6)を使用 して、 V2から VIへの論理構造変換を行う。その後、作成されたレコードを要求元に 渡す。
[0113] 列追カ卩が完了した後に、古いバージョンのデータベース定義体を使用したアプリケー シヨン'プログラム力 新たにレコードを作製する可能性もあるので、そのようなアプリ ケーシヨン'プログラムを稼動させな 、ようにすることが好ま 、が、稼動させる場合に は、データベース 'システムで、列 bの値として、初期値かヌル値、または情報を持た ない列としてセットする。
[0114] [過去遡及型 ·直接追加方式での列追加完了後のアクセス]
列追加が完了した後で、データベース定義体の異なるバージョンを使用しているアブ リケーシヨン'プログラムから、データベースに対するアクセスが可能であることを説明 する。図 11は、列追加が完了した状態を示している。また、データベース定義体は図 12に示すようになる。図 12のデータベース定義体は、基本的には図 10と同じもので あるが、列追加が完了しているので、 V2 (D210)の列 bの列状況欄が空欄となって いる。図 11では、以前の現用ロケーション 'テーブル 10が点線で図示されているが、 実際に不要となっているためである。新規ロケーション 'テーブル 8が現用ロケーショ ン 'テーブルであることになる。し力しながら、直接追加方式での列追カロが完了した状 態であることを強調するために、ここでは新規ロケーション 'テーブルの名称を用いて 説明する。アクセスが主キーに対するものであり、ターゲット 'キー値が alである場合 、まず、リクエスト受付処理を行う。次に、新規ロケーション 'テーブル 8に対して、ノ ィ ナリ^ ~ ·サーチを行い、ブロック 0の中の recordlを見つけ出す。このレコードは過去 遡及型'直接追加方式により列追加がされているので、レコードの形式は V2であるこ とが分かる。また、子データベース方式のところで記述したように、レコード中にそのレ コードが作成されたデータベース定義体のバージョンを入れておけば、より確実に容 易に判別が行える。
[0115] 次に、 V2のデータベース定義体を用いて、物理構造と論理構造の変換を行う。次に 、要求元がデータベース定義体の VIを使用して 、る力 V2を使用して 、るかの判別 を行う。要求元力 を使用している場合には、変換されたレコードを要求元に渡す。 要求元力 SV1を使用している場合には、論理構造変換テーブルを使用して論理構造 の変換を行い、そのレコードを要求元に渡す。
[0116] ここでは、検索に関して述べたが、図 51から図 53の説明で述べたように、レコードの 追加や削除、更新も全く同様に可能である。これらは、子データベース方式で述べた のと同様の方法を用いればよい。
[0117] 代替キーからのアクセスは、代替キ一'テーブルのアクセスを行った後に、ロケーショ ン 'テーブルから主キーによる検索を行い目的のレコードを検索すればよい。
[0118] 以上で、列追加'直接列追加方式における、列の追加と、追加途中および追加後の 列の検索に関して述べた。ここでは、既存のデータベースに 1つの列を追加する場合 に関して説明を行ったが、上記の方法を応用することで、同時に 2つ以上の列を追カロ することや、既存のデータベースに 1つの列を追カ卩した後、更に別の列を 1つ以上追 加することが可能である。直接列追加方式の場合は、現用のデータベースに直接的 に列を追加するので、列追力 II·子データベース方式のように、再編成の際に、 2つの データベースを 1つにする必要は無い。この 2つのデータベースを 1つにする方法は 後述する。
[0119] [オーバーフロ一 ·ブロック管理テーブルを用いた場合]
以上の説明では、プライマリ^ ~ ·ブロックとオーバーフロ^ ~ ·ブロック、オーバーフロ^ ~ · ブロックとオーバーフロ一'ブロックの連結、及び、代替キ一'ブロックと代替キ一'ォ 一ノ ーフロー ·ブロック、代替キー ·ォーノ 一フロー ·ブロックと代替キー ·オーバーフ ロー ·ブロックの連結に関しては、「データ格納検索方式」で示された方法によって!/ヽ た。これを、「データ格納検索システム」で示された、オーバーフロー 'ブロック管理テ 一ブルを用いたデータベースに適用する場合には、次のようになる。
[0120] 図 38を用いて説明する。現用ロケーション 'テーブル 10に対してオーバーフロ一'ブ ロック管理テーブル 14が設けてある。また、オーバーフロ一'ブロック管理テーブルの 最終エントリーを識別するために、オーバーフロー 'ブロック最終ポインターを 141を 設けてある。ここまでは、列追加に関係なく必要になる。直接列追加を行うためには、 新規ロケーション 'テーブル 8を作成する。また、新規ロケーション 'テーブル 8に対す る、新規オーバーフロ一'ブロック管理テーブル 84と新規オーバーフロ一'ブロック最 終ポインター 841を作成する。図 38では、オーバーフロ一'ブロックが発生していな いので、オーバーフロ一'ブロックは図上で省略してある。また、双方のオーバーフロ 一.ブロック管理テーブルは未使用の状態となって 、る。これらのオーバーフロ一'ブ ロック管理テーブルの使用法や、それらを用いた場合のアクセスは、「オーバーフロ 一 ·ブロック管理テーブル」に記述した方法を用いる。
[0121] [列追加:過去非遡及型'子データベース方式] 次に、過去非遡及型 ·子データベース方式による列追加に関して、図 13から図 16を 用いて説明する。過去非遡及型 ·子データベース方式とは、過去遡及型 ·子データ ベース方式と基本的には似ている力 新たに追加する列に関して、過去に作成され たレコードに対して値を追加することをせず、データベース定義体の変更後に作成さ れるレコードから、追加列を追加する方式である。また、データベース定義体の変更 後に作成されるレコードは、列追加されたもののみとすることも可能である力 以前の バージョンのデータベース定義体で作成されたレコードを混在させることも可能であ る。単一のバージョンのレコードのみを追加するのは、複数のバージョンのレコードを 追加することに包含されるので、ここでは、複数のバージョンのレコードが追加される 場合に関して主に説明を行う。
[0122] 図 13は、過去非遡及型 ·子データベース方式による列 bの列追加を行おうとしている データベースである。ここでは、既に recordOから record6までの 7つのレコードが作 成されている。この時点で、列 bを追加することを決め、データベース 'システムに指 令する。データベース 'システムでは指令を受けると、列 bが追加された後のデータべ ースの定義体 V2 (図 16の D2と D21)を作成する。図 16では、論理構造変換テープ ル X6が、併せて記述してある。データベース定義体 V2と論理構造変換テーブルの 作成方法に関しては後ほど説明する。図 16の D21では DB— Aに対して、 DB— A1 が別のデータベースとして追加されている。 DB— Aを親データベース、 DB— A1を 子データベースとする。
[0123] 次に、 DB—A1用の子ロケーション 'テーブル（図 14の 15)を作成する。最終ポインタ 一 151を用意し、子ロケーション 'テーブル 15の先頭を指すようにする。 DB— A1用 の子ブロック 16は、レコードを格納する都度確保していってもよいが、予め必要な数 のブロックを確保しても良い。以上が準備作業となる。 DB— A1では、列 bが実際の 意味を持っている力 列 bだけでは検索や更新が出来ないので、 DB— Aの主キーの 列 aと組み合わせてレコードとし、ブロック中 16に格納することになる。この状態を示し たのが、図 14である。レコードの追加がない場合は、この状態のままである。このデ ータベースに対するアクセスは、 DB— Aのみに対してアクセスすればよいので、特段 の問題は無い。 [0124] 次に、レコードの追カ卩を行う場合に関して説明する。ここでは、図 46から図 49までの 説明が参考となる。アプリケーション 'プログラムから、レコードを追加する場合は、次 のようになる。まず、データベース定義体 V2を使用しているアプリケーション'プログ ラム力も record7を追加する。図 49にあるように、データベース 'システムでは、リクェ スト受付処理を行う。次に、アプリケーション 'プログラムのデータベース定義体のバ 一ジョンの判別を行う。ここでは、 V2であるので、データベース定義体（図 49の 35) の V2を使用して、論理構造と物理構造の変換を行う。ここでは、列 bを除いた列を 1 つのレコードとして、 DB_A上に格納する。列 aを主キーとし、列 aと列 bからなる子レ コードを子データベース（DB—A1)上に格納することになる。 DB— A用のレコード (r ecord7)を、最終ポインターとの比較により、最後の位置に格納することになる。この 場合は、ブロック 3 (113)となる。次に、 DB— A1用のレコード (recrd71)を、 DB— A 1のブロック 0 (図 15の 160)に格納する。
[0125] 次に、データベース定義体 VIを使用したアプリケーション ·プログラムから record8を 書き込むことに関して説明する。リクエスト受付処理と、データベース定義体バージョ ンによる振分けは record7の場合と同様である。 VIのデータベース定義体により、論 理構造と物理構造の変換を行う。変換後のレコードを格納することになる。この場合 には、列 bが含まれないレコードを DB— Aに格納するのみで、 DB— A1に対しては 何も行わない。
[0126] 図 15では、更に、 V2を使用しているアプリケーション 'プログラムから、 record91が 書き込まれた状態を示している。以上が、複数のバージョンのデータベース定義体を 使用したアプリケーション ·プログラムからのレコード書き出しの説明である。ここでは 、 2つのバージョンに関して説明した力 図 46から図 49までの説明で記述したように 、複数のバージョンが存在する状態で稼動する。
[0127] このように、複数のバージョンのデータベース定義体を使用したアプリケーション 'プ ログラムからレコードが書き出されると、そのレコードの形式を判別することが困難に なってしまう。このような状態を避けるためには、過去遡及型の説明中でも述べたが、 レコードの中またはレコード外の特定の場所に、そのレコードが作成されたデータべ ース定義体のバージョン情報を入れておくことにより、確実にレコード形式を判別する ことが可能である。このレコード中の、データベース定義体のバージョン情報は、例え ば図 17のように、レコードの特定の位置に、そのレコードを作成した時に使用したデ ータベース定義体のバージョン情報を格納しておくというものである。図 17での、レコ ード長は、可変長レコードの場合にそのレコードの長さを示すものである力 VSAM で用いられたように、レコード内では無いブロック中の特定の場所にレコードの位置 などと併せて格納することにより、外出しにすることが可能である。そこに、そのレコー ドが作成されたデータベース定義体のバージョンを格納するようにすることも可能で ある。これを示したのが図 18である。
[0128] [過去非遡及型 ·子データベース方式でのデータベースへのアクセス]
次に、この方式を用いた場合のレコードに対するアクセスに関して説明する。図 15が 、データベース定義体 VIを用いたアプリケーション 'プログラムと、 V2を用いたアプリ ケーシヨン'プログラムから書き出されたレコードが混在しているので、この図 15と図 1 6を用いて説明する。また、図 46から図 49が理解の参考となる。要求元がアプリケー シヨン ·プログラムであるとする。また、アクセスが主キーに対してであり、その主キー 値が alである場合とする。まず、リクエスト受付処理を行い、その中で要求元がデー タベース定義の VIを使用している力 V2を使用しているかの判別を行う。次に、 DB — Aのロケーション 'テーブル 10に対して、バイナリ^ ~ ·サーチを行い、ブロック 0の中 の recordlを見つけ出す。次に、このレコードがどのデータベース定義体を使用して 作成されたかを、レコード中のデータベース定義体のバージョン情報により判別する 。この場合は VIを使用して作成されているとする。そのバージョンのデータベース定 義体を使用して、物理構造から論理構造に変換を行う。
[0129] 要求元がデータベース定義体 VIを使用している場合は、作成したデータベース定 義体のバージョンと、要求元のバージョンが同じであるので、読み込んだレコードをそ のまま要求元に渡す。要求元がデータベース定義体 V2を使用している場合は、論 理構造変換テーブル（図 16の X6)の VIと V2を参照する。 V2では、レコードの列は 、列 a, b, c, d, e, fからなつている。列 bは V2のソース欄で「DB— Al」となっており、 列状況欄で「DB_Aから連結」となっている。このため、列 bは DB_A1に存在する ことになるが、実際のレコードはデータベース定義体 VIで作成されているため、列 b を持っていない。論理構造変換テーブル X6の VIの情報を送り側、 V2論理位置の 情報を受け側として、要求元に渡すレコードを作成する。読み込んだレコードのオフ セット 0バイトから 8バイトを渡すレコードのオフセット 0バイトから 8バイトに、読み込ん だレコードのオフセット 8バイトから 12バイトを、渡すレコードのオフセット 18バイトから 12ノイトに、読み込んだレコードのオフセット 20バイトから 14バイトを、渡すレコード のオフセット 30バイトから 14バイトに、以下、列 e, fをセットする。列 bに関しては、読 み込んだレコード中に値が存在しないので、列 bの初期値またはヌル値、または情報 を持たない列をセットすることが好ましい。レコードが完成したら要求元に渡す。
[0130] 次に、要求元からのアクセス力 データベース定義体 V2を使用して作成されたレコ ードに対するものである場合に関して説明する。アクセス力record7に対するもので ある場合、上記と同様に、ロケーション 'テーブル 10にバイナリー 'サーチを行い、ブ ロック 3 (図 15の 113)の中の record7を見つけ出す。このレコードが作成されたデー タベース定義体のバージョンの判別を行うが、この場合は V2であることが分かる。よ つてデータベース定義体 V2 (図 16の D2)を参照すると、列 bは DB— A1に存在する ことがわかる。よって、 DB— A1に対するアクセスを行い、 record71を読んでおく。そ して、データベース定義体 V2を用いて、物理構造と論理構造の変換を行う。この場 合は、列 bが子データベースに存在している力 要求元に渡すレコードとしては、列 a , b, c, d, e, fの並びとする。次に、要求元がデータベース定義体のどのバージョン を使用しているかを判別する。まず、 VIを使用している場合に関して説明する。図 1 6の論理構造変換テーブル X6を使用して、 V2から VIへの論理構造の変換を行う。 V2の情報を送り側、 VIの情報を受け側として、列のセットを行う。ここでは DB— Aか ら読み込んだレコードが、そのまま受け側の形式となっている。この場合には、実際 には、 DB—A1へのアクセスは不要であること分かる。余分なアクセスを軽減するた めに、要求元のバージョンの判定により子データベースへのアクセスの要否を定める ようにすると効果的である。
[0131] 次に、要求元が V2を使用している場合は、データベース定義体 V2の情報により、 D B— Aと DB— A1へのアクセスを行い、物理構造と論理構造の変換を行う。この場合 は、列 bを、レコードの 2番目の位置にセットし、列 c以降をその分だけ後方にずらすこ とである。レコードが作成されたバージョンと、要求元のバージョンが同じなので、論 理構造変換テーブルによる論理構造変換は不要である。ここでは、読込み処理につ いて述べたが、図 47から図 49の方法を用いることで、レコードの更新、削除、追加が 可能である。
[0132] 代替キーでのアクセスは、 目的の代替キー値により、代替キ一'ロケーション'テープ ルのバイナリ一'サーチを行い、代替キ一'ブロックまたは代替キ一'オーバーフロ一' ブロック力 、 目的の代替キー値を持つ代替キー'エントリーを搜し、その代替キー' エントリーの主キー値により、ロケーション 'テーブルに対して主キーによるバイナリー 'サーチを行い、 目的のレコードを検索すればよい。 目的のレコードに対する処理は 前述したとおりである。代替キーは、同一のキー値を持つレコードが複数存在する場 合があり、その場合には、上記の動作を繰り返す。
[0133] [オーバーフロ一 ·ブロック管理テーブルを用いた場合]
オーバーフロ一 ·ブロック管理テーブルを用いた格納やアクセスは、過去遡及型 ·子 データベース方式で述べた方法と同様であるので、ここでは詳し 、説明を省略する。
[0134] [列追加:過去非遡及型'直接追加方式]
次に、過去非遡及型'直接追加方式に関して説明する。この方式は、過去遡及型 · 直接追加方式と似ているが、データベース定義体を変更する以前に作成されたレコ ードに対して、追加する列の値を持たないことである。つまり、過去に作成されたレコ ードは、作成された時点の形式のままであり、新たに作成されるレコードは、列の追加 が行われた形式と列の追加がされる以前の形式と混在することになる。この方式の場 合も、新たなデータベース定義体を作成した後に追加するレコードは、新しい形式の みとすることは可能である力 それは、形式が混合する場合に含まれるので、ここでは 、形式が混合する場合を説明する。
[0135] 新しい形式のレコードのみを追加する場合には、次の 2つの場合がある。 1つは、古 いバージョンを使用したアプリケーション.プログラムからレコードの追加を行う場合に
、論理構造変換テーブルを使用して、最新バージョンの論理構造に変換する方法で ある。この場合、古いバージョンを使用したアプリケーション 'プログラムは、追加され た列に関して値を持っていないため、追加された列に対してはヌル値、または情報を 持たない列か初期値をセットする。もう一つは、古いバージョンのデータベース定義 体を使用しているアプリケーション 'プログラムの稼動を停止することである。
[0136] 図 13と、図 19、図 20を用いて説明を行う。図 13は、過去非遡及型'子データベース 方式でも用いたが、列を追加する直前の状態を示している。また、この状態に対応す るデータベース定義体のバージョンは VIであるとする。ここでは、 recordOから recor d6までの 7つのレコードが既に作成されている。この時点で、過去非遡及型で列 bの 列追カ卩を行うことを決定し、データベース 'システムに指令する。データベース 'システ ムでは、それに対応したデータベース定義体 V2 (図 19の D210)と論理構造変換テ 一ブル（図 19の X6)を作成する。これで、過去非遡及型'直接追加方式の列追加は 完了である。なぜならば、過去のデータの変更を行わないからである。
[0137] データベース定義体 V2 (図 19の D210)の作成を完了した後の、レコードの追加方 法を、図 19と図 20を用!ヽて説明する。図 20は、図 13の状態力ら、 record7, 8, 9の 3つのレコードが追加された状態を示している。まず、データベース定義体 V2 (図 19 の D210)を使用したアプリケーション 'プログラム（要求元）からのレコード追カ卩に関し て説明する。図 49力参考となる。アプリケーション 'プログラムでは、列 a, b, c, d, e, fからなるレコードを作成し、データベース 'システムに渡す。データベース 'システム では、リクエスト受付処理を行う。データベース定義体 V2にレコードを割振り、論理構 造と物理構造の変換を行う。その後、必要に応じてレコードの格納位置を検索し、ブ ロック内のレコードを移動した上で、レコードの格納を行う。その後、代替キ一'ェント リーの追加を行う。
[0138] 次に、アプリケーション 'プログラムが、データベース定義体 VIを使用している場合は 、これも同様に、アプリケーション 'プログラム力も渡されたレコードを、データベース 定義体 VIを使用して、論理構造と物理構造の変換を行い、それを格納する。
[0139] このように、レコードの形式が複数存在するようになる場合は、過去非遡及型'子デー タベース方式のところで説明したように、レコード中またはブロック中にそのレコードを 作製したデータベース定義体のバージョンを入れておくことにより、確実にそのレコー ドの形式を判別することが可能である。
[0140] [過去非遡及型'直接追加方式でのアクセス] 次に、このような状態で、レコードの読み出しや更新に関して説明する。まず、データ ベース定義体 VIを使用した要求元力もの検索の場合を説明する。図 46が参考とな る。まず、リクエスト受付処理を行う。その後、ロケーション 'テーブルのバイナリー 'サ ーチを行い、 目的のレコードを見つける。レコードが作成されたデータベース定義体 のバージョンにより、各バージョンのデータベース定義体に割振る。各データベース 定義体では、物理構造と論理構造の変換を行う。更に、変換されたレコードを、要求 元のデータベース定義体のバージョンに、論理構造変換テーブルを使用して変換す る。
[0141] アクセスの対象となるレコード力 データベース定義体 VIで作成されており、要求元 がデータベース定義体 VIを使用している場合は、論理構造変換テーブルによる変 換は不要である。要求元力 を使用している場合には、論理構造変換テーブルを 使用して VIから V2への変換を行う。この場合、 VIのレコードには列 bが存在してい ないため、ヌル値、または情報を持たない列か初期値をセットすることが好ましい。
[0142] 次に、アクセスの対象となるレコード力 データベース定義体 V2で作成されている場 合に、要求元がデータベース定義体 V2を使用している場合は、論理構造変換テー ブルによる構造変換は不要である。要求元力 を使用している場合には、論理構造 変換テーブルを使用して V2から VIへの変換を行う。この場合、 VIのレコードには列 bが存在していないため、列 bを削除する。実際には、列 aの直後に列 c以下がセットさ れること〖こなる。
[0143] この説明でも検索に関して説明を行ったが、他の方式の場合と同様に、図 47から図 49の説明で示された方法を用いることで、レコードの更新、追加、削除が行える。ま た、代替キーによるアクセスも、他の説明と同様で、まず、代替キーによるアクセスを 行い、その代替キー'エントリーにより、主キーによる検索を行う。
[0144] [オーバーフロ一'ブロック管理テーブルを用いた場合]
オーバーフロー ·ブロック管理テーブルを用いた格納やアクセスは、過去遡及型 ·直 接列追加方式で述べた方法と同様であるので、ここでは詳し 、説明を省略する。
[0145] [再編成：列追カ卩 ·子データベース方式の 2つのデータベースを 1つにする]
次に、列追加 ·過去遡及型 ·子データベース方式または過去非遡及型 ·子データべ ース方式によって作成された子データベースを、「データベース再編成システム」の 手法を応用することによって親データベースに統合することが可能である。この方法 に関して過去遡及型を例にとって説明を行う。図 7が、再編成を行う直前のデータべ ースを示した図である。このデータベースは、過去遡及型'子データベース方式によ つて作成されたものである。図 7の他に、図 21、 23、 24を用いて説明する。ここでは、 親データベースに子データベースを統合することにするが、逆に子データベースに 親データベースを統合することも可能である。
[0146] まず、再編成を開始すること、また再編成で 2つのデータベースを 1つにすることをデ ータベース.システムに指示する。この指令は、「データベース再編成システム」に組 み込んだプログラムによって、自動的に判断することが可能である他、システム管理 者によって起動する方法も可能である。この指令によって、まず、再編成を行うための 準備作業を行う。この場合の再編成は、データベースを 2つから 1つにすることになる ので、データベース定義体の新規作成が必要となる。図 21で、再編成直前のデータ ベース定義体を V2 (D2と D21)として、再編成途中または再編成後のデータベース 定義体を V3 (D3)として示している。データベース定義体 V2は DB_A(2)と DB_ A1 (3)の 2つのデータベースから構成されており、この 2つをあたかも 1つのデータべ ースであるように見せていた。これに対して、 V3では、 DB— Aが 1つだけになつてお り、列 bもレコード中に含まれるようになつている。更に、再編成完了後のデータべ一 ス定義体も作成する。これが図 24である。図 24には、論理構造変換テーブル X25も 記載してある。
[0147] 再編成を行う方法は以下のようになる。まず、 DB— A (2)の現用ロケーション'テープ ル 10に対し、新規ロケーション 'テーブル 9を用意する。 DB— A1の現用ロケーション 'テーブルに対して、新規ロケーション 'テーブルは不要である。現用ロケーション'テ 一ブル 10用の再編成ポインター（102)と、新規ロケーション 'テーブル 9用の再編成 ポインター（92)を設ける。新規ロケーション 'テーブル用の再編成ポインタ一は、最 終ポインターで代用しても良い。ここまでが、準備作業となる。ここでは、 DB_A(2) の現用ロケーション 'テーブル 10に対して、新規ロケーション'テーブル 9を設けるとし た力 DB A1 (3)の現用ロケーション 'テーブル 15に対して新規ロケーション'テー ブルを設け、 DB— Aの現用ロケーション 'テーブル 10に対して、新規ロケーション'テ 一ブルを設けないという方法も採れる。これが、子データベースに親データベースを 統合するということである。新規ロケーション 'テーブルを割り当てたデータベースの 方に、もう一方のデータベースを統合する形となる。この場合は、データベースに対 するアクセスは、 DB—A1のロケーション 'テーブルを使用して行うことになる。
[0148] 次に、 DB— Aで現用ロケーション 'テーブル 10の最初のエントリーと最初のブロック を排他する。 recordOを読み込み、次に DB— A1 (3)の recordlOを読み込む。 reco rdOに対して recordlOの列 bを追加して、新たな recordOとして、ブロック 0中に書込 む。この際に、 recordOのデータベース定義体のバージョン情報を V3に変更する。こ れは、このレコード以降のレコードに関しても同様である。この場合、新たな recordO を格納するために、必要があれば recordlを図中の右側に移動する。
[0149] 次に、上記と同様に recordlと recordl 1を読み込んで、新たな recordlを作成し、 ブロック 0に書込む。次に、ブロック 0のアドレスを新規ロケーション 'テーブル 9に登録 する。これで、ブロック 0に対する再編成が終了したので、ブロック 0の排他を解除す る。次に record2と record3について、同様に、ブロック 1の排他を行い、 DB— Aのレ コードに DB— A1の列 bを追加して、新レコードとしてブロック 1中に格納する。ブロッ ク 1のアドレスを新規ロケーション ·テーブルに登録する。ブロック 1の排他を解除する 。図 22は、ブロック 1まで、再編成が完了した状態を示している。
[0150] この例では、ブロック 0に空きがあって、列 bを追カ卩した場合でも、新たなレコードを格 納できるとしている力 列 bを追加することにより、ブロック 0に格納できない場合は、 新たなブロックを追加して、それを新ブロック 1とする。これは、「データベース再編成 システム」で述べた方法である。このような場合、ブロックを 1つ追加するのみでは、追 カロされたブロックの格納率が適正な初期格納率を下回る可能性があるため、「データ ベース再編成システム」で述べたように、一時点で複数のブロックを対象にして、上記 の再編成を行うことが好ましい。ここでは、説明を簡単にするため、複数ブロックを対 象にした場合とせず、単独のブロックを対象にした説明に止める。再編成に関しては 、「データベース再編成システム」で詳しく説明されている。また、この方法は、過去遡 及型 ·直接追加方式でも述べた方法である。更に、レコードを統合することにより、レ コード長が長くなるため、 DB— Aのブロックの先頭から順次、レコードの書き換えを行 つていくと、後方のレコードの位置をその都度ずらす必要があるが、これも、過去遡及 型'直接追加方式で述べたように、ブロック単位に更新を行うことにより、オーバーへ ッドを最小限にすることが可能となる。
[0151] 現用ロケーション 'テーブル用の再編成ポインター 102は、現用ロケーション'テープ ルの 3番目のエントリーと、新規ロケーション 'テーブル 9の 3番目のエントリーを指して いる。また、 DB— A1に関しては、 DB— Aに統合されるため、再編成の直接的な対 象とならな 、ので、再編成ポインターを設けなくてょ 、。
[0152] 図 23は、以上の再編成を最後のレコードまで実行し、再編成が完了した状態を示し ている。ここでは現用ロケーション 'テーブル 10が点線で表示してある力 現用ロケ一 シヨン'テーブルは実際には必要なく削除するのが好ましい。また、新規ロケーション' テーブル 9が実際には現用ロケーション 'テーブルとなる。図 24は、再編成が完了し た状態でのデータベース定義体 VI (Dl) , V2 (D225)と V3 (D325)を示している。 DB—A1は再編成による統合により不要となっている。データベース定義体 V2 (D2 25)は、 V3とイコールとなっている力 これは、 V2の論理形式に V3がー致するように 変更されたため、 V3と同じになったことを示している。勿論、データベース定義体 V3 (D325)と同じ定義体を作成してお！、ても良!、。
[0153] 上記の説明では、ブロックを 1つづつ対象にして再編成を行う場合を説明したが、実 際には、一時点で複数のブロックを対象にして再編成することが現実的である。また 、オーバーフロー 'ブロックが存在し、それが再編成の対象になることもある。このよう な場合、オーバーフロ一'ブロックをプライマリ一'ブロックにして、そのアドレスをロケ ーシヨン'テーブルに登録する。この方式の詳細は、「データベース再編成システム」 で述べた方法を使用する。以上の実施例では、再編成によって既存のレコードの途 中に列が追加される例を記述したが、レコードの最後に列が追加される場合や、同時 に 2つ以上の子データベースを統合する場合も、全く同様な方法で実施できる。
[0154] 以上では、代替キーに関する説明を省略している力 代替キーに関しては、次のよう になる。再編成により、代替キー'エントリーが指しているレコードの格納されているブ ロックのアドレスやブロック番号が変更になる可能性がある。このため、代替キ一 ·ェ ントリーに、ブロック番号やブロックのアドレスを保持している場合には、「データべ一 ス再編成システム」で述べたように、代替キー'テーブルの書換えを同時平行して実 施する必要がある。一方、代替キ一 ·エントリーにブロック番号やブロックのアドレスを 保持していない場合には、代替キー'エントリーに変更が発生しないので、代替キー' テーブルに対する操作は不要である。
[0155] [再編成中のデータベースに対するアクセス]
再編成中のデータベースに対するアクセスは、列追カ卩中と同様に可能である。 DB— Aの現用ロケーション'テーブル 10と新規ロケーション'テーブル 9の何れを使用する かは、 目的レコードの主キー値力 再編成ポインターが指しているロケーション'テー ブル.エントリーの主キー値より大きいか、それ以下であるかによって使い分ける。こ れは「データベース再編成システム」で述べた方法である。 目的レコードの主キー値 力 再編成ポインターが指しているロケーション'テーブル'エントリーの主キー値より 大きい場合は、現用ロケーション 'テーブル 10を使用し、以下である場合は新規ロケ ーシヨン'テーブル 9を使用する。
[0156] DB— Aの新規ロケーション 'テーブル 9を使用する場合は、新規ロケーション'テープ ル 9の先頭アドレスと、再編成ポインター 92で指している、ロケーション'テーブル'ェ ントリーの間のロケーション'テーブル'エントリーに対してバイナリ一'サーチを行い、 ブロックを探しレコードを見つける。新規ロケーション 'テーブルが管理しているブロッ クにあるレコードは、再編成が終了しているので、レコードが統合されて、列 bがレコ ードに追加されている。つまり、レコードはデータベース定義体の V3によって作成さ れている。よって、データベース定義体は、図 24の再編成完了後のものを使用する。 V3のデータベース定義体により物理構造と論理構造の変換を行う。次に、要求元が どのバージョンのデータベース定義体を使用しているかを判別し、論理構造変換テ 一ブル X25により論理構造の変換を行う。レコードと要求元のデータベース定義体の バージョンが同一である場合は論理構造変換テーブルによる変換は不要である。
[0157] DB— Aの現用ロケーション 'テーブル 10を使用する場合も上記と同様に、現用ロケ ーシヨン'テーブル 10の、再編成ポインター 102で指しているロケーション 'テーブル 'エントリーと最終ポインター 101が指している間のロケーション'テーブル'エントリー に対してバイナリー 'サーチを行い、ブロックを探しレコードを見つける。現用ロケーシ ヨン.テーブル 10を使用している場合は、レコードに対する統合が未了であり、レコー ドはデータベース定義体 V2を使用して作成されたものであることになる。 V2であるの で、子データベース力らも王レコードを読取る。データベース定義体としては、図 21 の再編成中のもの（図 21の D2と D21)を使用する。 V2のデータベース定義体を使 用して物理構造と論理構造の変換を行う。次に、要求元がどのバージョンのデータべ ース定義体を使用しているかを判別し、論理構造変換テーブルにより論理構造の変 換を行う。要求元力 であるときは論理構造の変換は不要である。
[0158] 代替キーからのアクセスは、代替キ一'テーブルのアクセスを行った後に、ロケーショ ン 'テーブルまたは新規ロケーション 'テーブル力も主キーによる検索を行い目的のレ コードを検索すればよい。以上では、検索の場合に関して説明を行ったが、他の方 式の場合と同様、レコードの更新は、検索で見つ力つたレコードを更新すればよいし 、削除は検索で見つ力つたレコードを削除すればよい。レコードの追カ卩を、 VIを使用 したアプリケーション ·プログラムから実行する場合には、アプリケーション 'プログラム 力もは列 bの無いレコードを書く形になるため稼動させないか、列 bに関しては、初期 値またはヌル値、または情報を持たな ヽ列を埋めて実体データベースを作成すること が好ましい。レコードの更新、削除、追加に関しては図 47から図 49で説明したとおり である。
[0159] [再編成完了後のアクセス]
再編成が完了した状態を、図 23に示している。ここでは、現用ロケーション 'テーブル 10を点線で表示してある力 再編成が完了しているため不要となったものである。新 規ロケーション 'テーブル 9は、実際には現用ロケーション ·テーブルとして機能して ヽ る力 ここでは、新規ロケーション 'テーブル 9として説明を行う。また、データベース 定義体と論理構造変換テーブルは、図 24に示してある。これは、再編成中のァクセ スで説明したとおりである。再編成完了後のアクセスは、再編成中のアクセスで説明 を行った、新規ロケーション 'テーブルに対するアクセスと同じである。若干の相違は 、再編成が完了しているので、再編成ポインターを用いて、現用ロケーション'テープ ルを使用するの力 新規ロケーション 'テーブルを使用するかの判別を行わないこと、 バイナリー ·サーチの対象が、新規ロケーション ·テーブルの先頭から、最終ポインタ 一が指している間にある、ロケーション'テーブル'エントリーに対するものであること である。
[0160] 代替キーからのアクセスは、代替キ一'テーブルのアクセスを行った後に、ロケーショ ン 'テーブルまたは新規ロケーション 'テーブル力も主キーによる検索を行い目的のレ コードを検索すればよい。
[0161] 以上では、 2つのデータベースを 1つに統合する場合に関して述べた力 3つ以上の データベースを統合することも、上記の方法を用いることで実現できる。例えば、子デ ータベースが 2つある場合に、 3つのデータベースを 2つにした上で、更に 1つにする ことも可能であるし、同時に 3つを 1つにすることも可能である。
[0162] また、何らかの事情により、再編成時に DB— Aと DB— A1を統合せずに、各々を個 別に再編成することも可能である。この場合は、単なる「データベース再編成システム
」の適用であるので、詳細な説明は省略するが、再編成中のアクセスが可能であるこ とは、「データベース再編成システム」で述べてあるとおりである。
[0163] [オーバーフロ一 ·ブロック管理テーブルを用いた場合]
オーバーフロー.ブロック管理テーブルを用いた場合の再編成に関しては、「データ 格納検索システム」に記載されている再編成の方法を適用すればよい。再編成中の レコード追加やアクセスは、再編成前のレコードに対する場合は、子データベース方 式で述べた方法を使用し、再編成後のレコードに対する場合は、直接列追加方式で 述べた方法を使用すればよいので、ここでは詳しい説明を省略する。何れの方式の 場合でも、再編成中のデータベースへのアクセスは可能である。
[0164] 以上で、子データベースを用いた再編成に関して説明を行った。この再編成を応用 すると、次のような子データベースを採用することが可能となる。一つのレコード中の 項目は、何れもが同程度に参照されたり更新されることはなぐ各項目によって頻度 が異なることが通常である。このような場合に、参照や更新の頻度が高い項目嫌め て、親データベースとし、参照や更新の頻度が低い項目を集めて子データベースと するのである。頻度が高い、低い、というのは相対的な問題であり、閾値を任意に設 定できるようにすることが好ま U、。 [0165] このようにして、親データベースと子データベースを作成し、親データベースは高速 な装置に格納し、子データベースは低速な装置に格納するのである。但し、子デー タベースのロケーション 'テーブルは、高速な装置に格納することが好ましい。一般的 に、高速な装置は高価であり、低速な装置は安価である。このように選択的に格納が 行えると、全体を高価で高速な装置に格納することに比較して、高速性をあまり損な わずに安価な装置を使用して、データベースを構築することが可能となる。このような データベースを図示したのが図 57である。この図では、 DB— Aが親データベースで あり、 DB— A1が子データベースである。
[0166] このようにして、子データベースを作成しても、アプリケーション 'システムの追加や、 利用状況の変化により、各項目毎の参照や更新の頻度が変化することが起こり得る。 このような状況になった場合には、上記で説明した再編成の仕組みを使って、項目を 入れ替えることが可能である。例えば、図 57において、項目 cの参照、更新の頻度が 低下した場合には、 DB— Aから列 cを削除し、 DB— A1に列 cを追加する、という作 業を行うことにより、参照、更新の頻度が高い項目（列)を、常に親データベースが保 持するようにすることが可能である。同様に、子データベース中の項目（列） dの参照 、更新頻度が増加した場合には、 DB— A1から列 dを削除し、 DB— Aに列 dを追カロ する。これらの列の追加削除は、本データベースの機能によって自動的に実施可能 であることは、言うまでも無い。
[0167] また、本データベースの子データベースを使用すると効果がある場合の例として、汎 用パッケージ ·システムへの応用がある。汎用パッケージ ·システムを使用する場合に 、どうしても適用が難しい部分に対して、カスタマイズを行う。その際にデータベース の項目を追カ卩したい場合、従来の方法であると、ノ ッケージ'システムのバージョンァ ップがあっても、実質的に適用できなくなってしまう。これは、パッケージ.システムで データベース項目の追加などがあると、整合性がとれなくなるからである。ところが、 本データベースを使用して、親データベースは汎用パッケージ.システムが使用し、 子データベースをカスタマイズ部分が使用するようにし、両者を物理的に統合しない 環境で使用することにより、ノ ッケージ'システムがデータベース構造を変更しても、 カスタマイズ部分は影響を受けな 、。 [0168] if規ロケーション.テーブルの大きさ]
「データベース再編成システム」では、新規ロケーション.テーブルの大きさに関して、 再編成後のプライマリ一'ブロックの数よりも大きいロケーション'テーブル'エントリー を格納できるものとしている。しかしながら、この方法では、再編成のために現用ロケ ーシヨン'テーブルとほぼ同じ大きさの新規ロケーション 'テーブル用のスペースが常 に必要となることになる。
[0169] このような問題に対して、ロケーション 'テーブルを物理的には分割して取得し、各々 をアドレス変換テーブルなどを用いて連続した領域として扱うことが可能である。この 方法を応用すると、次のように新規ロケーション 'テーブルに必要な領域を少なくする ことが可能である。まず、新規ロケーション 'テーブルを必要な容量の数分の 1から数 十分の 1の容量で作成する。再編成を行っていくに従って現用ロケーション'テープ ルの上位部分は不要となってくる。このため、新規ロケーション 'テーブルのエントリー が満杯になったら、そこでー且、再編成を中断し、現用ロケーション 'テーブルの上位 部分を開放し、そこを改めて新規ロケーション 'テーブルとして取得し、再編成を再開 する。これを、数回力も数十回繰り返すことにより、新規ロケーション 'テーブルに割り 当てる領域を、一時点で小さくすることが可能である。
[0170] 上記で示した、新規ロケーション 'テーブルを小さな領域に分割し、現用ロケーション •テーブルの空いた領域を、新規ロケーション 'テーブル用に使用する、という方法は 、本発明で述べた、直接追加方式や、子データベースを親データベースに統合する 再編成に適用できる他、「データベース再編成システム」にも適用可能である。
[0171] 上記で示した、新規ロケーション 'テーブルを小さな領域に分割し、現用ロケーション •テーブルの空いた領域を、新規ロケーション 'テーブル用に使用する、という方法を 応用すると、次のようなことが可能となる。図 39を用いて説明を行う。図 39では、現要 ロケーション'テーブル LCと新規ロケーション'テーブル LNが示されて!/、る。この図 のデータベースのように、部分的にレコードの挿入が発生して、オーバーフロ一.ブロ ックが発生する場合がある。図 39では、プライマリー ·ブロック 5と 6に集中的にオーバ 一フロー.ブロックが発生している。このような場合に、他の部分の再編成を行わずに
、オーバーフロー ·ブロックが集中的に発生して 、る部分のみの再編成を行うことであ る。図 39では、プライマリー 'ブロック 0, 1, 2, 3, 4に対しては再編成を行わず、プラ ィマリ一'ブロック 5と 6の再編成を行い、プライマリ一'ブロック 7, 8の再編成を行わず に、再編成を完了した時点の図である。
[0172] プライマリ一'ブロック 0から 4までは、再編成を行わないので、現用ロケーション'テー ブルがそのまま新規ロケーション 'テーブルとなる。次に、プライマリ一'ブロック 5の再 編成（ここでは主にオーバーフロ一'ブロックの解消）を行う。新規ロケーション'テー ブルの最初のエントリ一は 5となり、プライマリ一'ブロック 5を指す。新規ロケーション' テーブルの 2番目のエントリ一は 6となり、オーバーフロ一'ブロック 5—1を指す。新規 ロケーション 'テーブルで管理されるということは、オーバーフロ^ ~ ·ブロックがプライマ リ^ ~ ·ブロックになったということである。このようにして、オーバーフロ^ ~ ·ブロック 5—3 までの再編成を行い、更に、プライマリ^ ~ ·ブロック 6からオーバーフロ^ ~ ·ブロック 6— 5までの再編成を行う。新規ロケーション 'テーブルのエントリ一は 14まで使用するこ とになる。その後、プライマリー 'ブロック 7、 8の再編成は行わず、現用ロケーション' テーブル.エントリーの旧 7を新たにエントリーの 15に付け替える。同様に現用ロケ一 シヨン ·テーブル ·エントリーの旧 8をエントリー 16に付け替える。これで再編成が完了 することになる。 S1は、現用ロケーション 'テーブル（=新規ロケーション 'テーブル） のエントリー 4に論理的に接続するのは、新規ロケーション 'テーブルのエントリー 5で あることを示している。
[0173] 図 39では、説明を明らかにするために、新規ロケーション 'テーブルという名称を使 用したが、正確には、再編成が完了しているので、現用ロケーション 'テーブルの一 部である。このように、データベースの一部分に対して高速に再編成を実施すること が可能である。
[0174] [列の削除]
次に、列の削除に関して述べる。列の削除も 3つの方法がある。過去保持型と過去非 保持型の 2つになる。過去保持型は、更に、定義削除方式と子データベース方式に 分かれる。過去非保持型は直接列削除方式のみである。過去保持型 ·定義削除方 式は、データベースの実体からは列の削除を行わず、データベース定義上でのみ列 の削除を行う方法である。この方式は、削除に伴う時間が瞬間的であるという利点が あるが、実体としては列の削除を行わないため、データベースの領域が大きいままで ある、レコードの読み込みに、レコードが長い分と、列の削除をして要求元に転送す る分、処理時間が長く掛かる、という欠点がある。この方式では、再編成の際に、削除 対象の列を実際に削除することが可能である。
[0175] 列削除:過去非保持型は、列追加:過去遡及型と似ており、過去に遡って既存のレコ ードから削除列を削除する。この型に対するアクセスは、図 50から図 53までの説明と 同じになる。データベース定義体は最新のもののみを保持する。これに対し、列削除 ：過去保持型は列追加:過去非遡及型と似ている。既存のレコードに関しては、作成 された状態のままとなる。この方に対するアクセスは、図 46から図 49まで説明と同じ になる。データベース定義体は、各バージョンのものを保持する。
[0176] 子データベース方式は、列削除に当って子データベースを新たに作成し、親データ ベースには、元のレコードから削除する列を除いたレコードを格納し、子データべ一 スには、削除した列と主キーとを組にした王レコードを作成し、それを格納する。
[0177] 直接列削除方式は、ブロック中に格納されているレコードに対して、削除するレコード を直接削除し、削除列のないレコードを新レコードとして格納するものである。
[0178] 過去保持型'定義削除方式のデータベースでは、定義削除方式による列削除を行つ た後で、再編成の仕組を適用することにより実際に列を削除することが可能である。 再編成の際に列を削除する場合、列を削除したレコードのみを新規データベースと して書き戻す方法と、削除した列と主キーとを組み合わせたレコードを新しく子データ ベースとして作成しておく方法がある。再編成で、列を削除したレコードのみを新規 データベースとして書き戻す方法を採用した場合、再編成に要する時間は短くなる 力 列を削除する前のデータベース定義体を使用しているプログラムからの要求では
、削除した列の値を返すことができなくなるので、場合によってはプログラムが異常終 了する可能性がある。この点は、直接列削除方式でも同様である。よって、この方式 を使用する場合は、慎重に実施する必要がある。再編成で、削除した列を新しく別な データベースとして作成しておく方法を採用した場合、再編成に要する時間は長くな る他、データベースを新たに作成する領域も必要となる。一方で、列を削除する前の データベース定義体を使用して 、るプログラム力 の要求でも、問題なく処理できる し、新しいバージョンのデータベース定義体を使用したプログラムからの要求は、再 編成前に比較すると早くなる。
[0179] [列削除:過去保持型'定義削除方式]
図 25は、過去保持型 ·定義削除方式により列 eを削除する場合の図である。図 25で は、列 eに網掛けを施している力 この意味は以下の説明で詳述する。データベース 定義体と論理構造変換テーブル X27は図 26に記述してある。列 eを削除する直前の 状態に対するデータベース定義体を V3とし、列 eを削除した後のデータベース定義 体を V4としている。データベース定義体 VI、 V2、 V3は、図 24に記載したものと同じ である。また、図 46から図 49が参考となる。
[0180] まず、列 eを定義削除方式により削除することをデータベースに指令する。これにより 、データベース.システムでは準備作業を行う。この場合は、 V4のデータベース定義 体 (D4)と、論理構造変換テーブル X27の作成である。データベース定義体 VI (D1 )、 V2 (D225)、 V3 (D325)に関しては変更が無 、ので、そのまま使用する。データ ベース定義体 V4 (X27)では、列 aから列 fまでの 6つの列からなるレコードから、列 e が削除されることになる。し力しながら、実体データベースとしては、列 eを保持したま まであるので、 V4の列 eの列状況欄に「定義削除」というステータスを立てる。データ ベース定義体 V4 (X27)の論理位置の列 eと、論理構造変換テーブル (X27)の V4 論理位置の列 eのオフセットには「（64)」、長さは「（16)」としてある。この表現は、列 e は実体としては削除されて 、な 、が、定義上は削除されて 、ると 、うことを識別可能 とし、更に、データベース定義体 V4で作成されたレコードを他のバージョンの論理構 造に変換する場合に、列 eの値が渡されるようにする為である。 V4のレコード自体に は、列 eは保持していない。他のバージョンに変換するための仮の列として必要にな る。以上で準備作業は終了する。図 25で列 eを網掛けしたのは、定義上の削除であ ることを示したものである。実体としてのデータベースには、何らの変更をする必要が 無いので、削除に伴う作業は以上で完了する。
[0181] [定義削除方式におけるデータベース ·アクセス]
以上のように、定義削除方式による列削除は瞬時に完了するので、列追加の場合の ように、列削除中のアクセスに関する問題は無い。列削除後のアクセスに関して説明 を行う。列削除後の要求元が、どのバージョンのデータベース定義体を使用している かの識別を行う。リクエスト受付処理、インデックス検索を行い、レコードを検出するま では、他の場合と同様である。読み取ったレコードのバージョンの判別を行う。そのバ 一ジョンのデータベース定義体 35により、物理構造と論理構造の変換を行う。更に、 要求元のデータベース定義体のバージョンに対して、論理構造変換テーブルを使用 して論理構造の変換を行い、作成されたレコードを要求元に渡す。他の方式の場合 と同様に、この方法に従って、レコードの更新、追加、削除が行える。代替キーによる アクセスも他の方式と同様に実行できる。
[0182] ここで、データベース定義体 V4から、他のバージョンへの論理構造変換に関して、よ り詳細に説明する。レコードがデータベース定義体 V4で作成されているとする。 V4 では、列 eが削除されているため、データベース定義体 V4を用いて物理構造と論理 構造の変換を行うと、列 eが存在しないレコードが作成されてしまい、それを他のバー ジョンに変換しても、列 eの値がなくなってしまう。このような状態を避けるための方法 力 図 26のデータベース定義体 V4 (D4)と、論理構造変換テーブル X27に示され ている。データベース定義体 V4 (D4)の列 eは、オフセットが「（64)」、長さが「（16)」 として示してある。この括弧は、本来の論理レコードには含まれないが、論理変換の ために必要なフィールドである、という意味として使用している。これは、論理構造変 換テーブルの V4の列 eにお!/ヽても同じ表現を用いて 、る。 V4の論理レコードのオフ セット 64バイトからの 16バイトは列 eの値が格納されている。つまり、 V4の論理構造 変換の際に、他のバージョンに変換する場合には、列 eの値をセットしておき、他のバ 一ジョンへその値を渡すことを意味して 、る。これは過去保持型を採用して 、るから 行えることである。
[0183] [オーバーフロ一'ブロック管理テーブルを用いた形式への適用]
オーバーフロー.ブロック管理テーブルを用いた場合の格納やアクセスに関しては
、データベースの物理構造が変更されていないので、定義削除を行う前と同様に実 施可能である。
[0184] [列削除:過去保持型'子データベース方式]
図 27、 29、 30、 31、 32を用いて、過去保持型'子データベース方式の列削除に関 して説明する。図 27は、列削除を行うとするデータベースである。ここには、 recordO から record6までの 7つのレコードが格納されている。各レコードは、列 a, b, c, d, e
, fからなつている。このレコードに対して列 eの削除を行う。列削除を過去保持型'子 データベース方式で行うことを、データベース.システムに対して指令する。データべ ース 'システムでは、この指令により準備作業を行う。新規ロケーション 'テーブル（図 28の 9)と、新規ロケーション.テーブル用の最終ポインター（図 28の 101)を作成す る。更に、子データベース DB—A1 (図 28の 3)を作成し、子ロケーション 'テーブル（ 図 28の 15)と子ロケーション'テーブル用の最終ポインター（図 28の 151)を作成す る。現用ロケーション 'テーブル用に列操作ポインター（図 30の 102)を作成し、その 中身は現用ロケーション 'テーブルの先頭アドレスとする。新規ロケーション'テープ ル用にも列操作ポインター（図 30の 92)を作成し、その中身は新規ロケーション'テ 一ブルの先頭アドレスとする。新規ロケーション 'テーブルの列操作ポインタ一は最終 ポインターでも代用可能である。現用ロケーション 'テーブルの最終ポインター 101が 指しているエントリーと同じエントリーを指す列操作完了ポインター 104を作成する。 1 更に、データベース定義体 V4 (図 29の D430と D4130)、論理構造変換テーブル（ 図 29の X30)を作成する。データベース定義体 VI (図 29の Dl)、 V2 (図 29の D22 5)、 V3 (図 29の D325)は、図 24のものと同じである。つまり、図 27のデータベース は、図 23のデータベースと同じものである。
図 30は、過去保持型'子データベース方式による列削除が途中まで進行した時点の 図である。最初力も順を追って説明する。まず、 DB— A (図 30の 2)の現用ロケーショ ン'テーブル（図 30の 10)のエントリー 0とブロック 0 (図 29の 110)、新規ロケーション 'テーブル（図 30の 9)のエントリー 0、更に子ロケーション 'テーブル（図 30の 15)の エントリー 0と子ブロック 0 (図 30の 160)を排他し、 recordOを読む。 recordO力ら列 e を削除した後、列 a, b, c, d, fからなるレコードをブロック 0 (図 30の 110)に書き戻す 。次に、主キーである列 aと削除した列 eを組み合わせて子レコード recordOlとし、 D B_A1 (図 30の 3)のブロック 0 (図 30の 160)に格納する。 DB_A1の子ロケーショ ン.テーブルの最初のエントリーを排他し、子ブロック o (図 30の 160)を作成し、その 中に格納する。次に recordlを読み、列 a, b, c, d, fからなるレコードをブロック 0 (図 30の 110)に書き戻す。次に、主キーである列 aと削除した列 eを組み合わせて子レコ ード recordl lとし、 DB一 A1 (図 30の 3)のブロック 0 (図 30の 160)に格納する。
[0186] ここで、 DB— Aのブロック 0 (図 30の 110)が満杯になったので、現用ロケーション'テ 一ブル 10 (図 30の 10)のエントリー 0と、ブロック 0 (図 30の 110)、新規ロケーション' テーブル（図 30の 9)のエントリー 0、子ロケーション'テーブル'エントリー 0と子ブロッ ク 0の排他を解除する。現用ロケーション 'テーブル（図 30の 10)の列操作ポインター は、現用ロケーション'テーブル'エントリー 1の先頭を指すようにする。新規ロケーショ ン.テーブルの列操作ポインター）図 30の 91)は、新規ロケーション'テーブル'ェント リー 1の先頭を指すようにする。子ロケーション ·テーブルの最終ポインター（図 30の 1 51)は、子ロケーション ·テーブル ·エントリー 1の先頭を指すようにする。
[0187] 以下、同様に、 record2を読み列 eを削除した後、列 a, b, c, d, fからなるレコードを ブロック 1 (図 30の 111)に書き戻す。次に、主キーである列 aと削除した列 eを組み合 わせて record21とし、 DB_A1 (図 30の 3)のブロック 0 (図 30の 160)に格納する。 r ecord3も同様に処理する。
[0188] 上記の例では、説明を単純化するために、 DB— Aのブロックに格納するレコード数 が変わらないとしたが、実際にレコード数が変化する場合には、一時点で、複数のブ ロックを対象として排他を行い、それらのブロックのレコードに対して列削除の操作を 行い、各ブロックに適正な初期格納率でレコードが格納されるようにする。この際に、 オーバーフロ一'ブロックがあれば、それをプライマリ一'ブロックとし、適正な初期格 納率とする場合に、余分なブロックが生じた場合には、それを未使用ブロックとする。 図 31は、このようにして列削除を行い、 record6まで完了した状態を示している。
[0189] [列削除を行っている際のデータベースに対するアクセス]
この状態は、列追加'子データベース方式の逆の動作を行っているので、図 30に示 した状態は、図 5の列追加：過去遡及型 ·子データベース方式と図 9の列追カ卩：過去 遡及型 ·直接追加方式を組み合わせたものになっており、列削除を行って 、る状態 であっても、アクセスは問題なく実行できる。図式としては図 46から図 49が適用され る。また、論理構造変換テーブルによる論理構造変換で、 V4力も他のバージョンへ の変換は、過去保持型'定義削除方式で説明したと同様に、列 eの論理位置と長さに 特別の意味を持たせて、論理構造変換を可能としている。
[0190] [オーバーフロ一'ブロック管理テーブルを用いた形式への適用]
オーバーフロ一'ブロック管理テーブルを用いたデータベース形式に対して本方式を 適用する場合の、データの格納やアクセスは、列追加'子データベース方式と同様で あるので、ここでは詳しい説明を省略する。
[0191] [列削除:過去非保持型 ·直接列削除方式]
過去非保持型'直接列削除方式に関して説明する。この方式は、既存のレコードから 削除列を削除したレコードのみを、新たなレコードとして、ブロックに書き戻す方法で ある。この方式は、列追カ卩における直接列追加方式と類似点が多い。この方法を図 3 2を使用して説明する。まず、現用ロケーション 'テーブル 10に対して、新規ロケーシ ヨン.テーブル 9を用意する。次に、現用ロケーション 'テーブルと新規ロケーション'テ 一ブルに対して、列操作ポインターを 1つづつ用意する。列操作ポインタ一は、最初 は各々のロケーション.テーブルの最初のエントリーを指している。更に、現用ロケ一 シヨン ·テーブルの最終ポインター 101が指して!/、るロケーション'テープノレ ·エントリ 一と同一の場所を指す列操作完了ポインター 104を設ける。列操作完了ポインター の値は、列削除が完了するまで変更されない。
[0192] 次に、現用ロケーション'テーブル'エントリー 0、ブロック 0、新規ロケーション'テープ ル.エントリー 0を排他する。次に、 recordOを読み込み、列 eを削除し、ブロック 0に書 き戻す。次に、 record2の処理を同様に行う。ここでブロック 0が適正な初期格納率と なったので、現用ロケーション'テーブル'エントリー 0、ブロック 0、新規ロケーション' テーブル.エントリー 0の排他を解除する。
[0193] 実際には、オーバーフロ一'ブロックが存在したり、ブロック内のレコードが占めるスぺ ースが、適正な初期格納率を下回るなどの可能性があるため、一時点で複数のプロ ックを対象にして、上記の列削除を行うことが好ましい。ここでは、説明を簡単にする ため、複数ブロックを対象にした場合とせず、単独のブロックを対象にした説明に止 める。図 35は列 eの削除が完了した時点の図である。ロケーション 'テーブル 10は、 列削除を行って 、た時点では、新規ロケーション 'テーブルとして用意したものである [0194] 過去非保持型では、既に作成されて!ヽるレコードに存在して ヽる削除列の削除を行 う型であり、レコード形式は最新の 1世代のみとなる。ところが、 VIを見ると、列 bが存 在していない形式となっている。このため、単純に最新の V4のデータベース定義体 のみを保持する方法では矛盾が発生してしまう。この矛盾を回避する方法としては、 以下の 2通りの方法がある。 1つ目は、過去のバージョンのデータベース定義体を残 しておく方法である。この場合、過去の状態のままで残すとレコード形式と矛盾してし まうので、列 eを取り除いた形式として、新たにデータベース定義体を作成しなおす。 また、この方法を採用する場合には、列削除を行う前と後とでレコード形式が異なる ため、列削除を行っている間は、旧形式のデータベース定義体と新形式のデータべ ース定義体の双方を保持する。この場合のデータベース定義体と論理構造変換テー ブルを示したのが、図 33である。
[0195] 2つ目の方法は、 VIで作成されたレコードの列 bに、ヌル値、または情報を持たない 列または初期値を与えて、同一のレコード形式にしてしまう方法である。この場合、デ ータベース定義体は V4のみが存在することになる。この場合の、データベース定義 体と論理構造変換テーブルを示したのが、図 34である。ここでは、論理構造変換テ 一ブルの VIの列 bの列履歴には「DUMMY」と!、う表現を入れて、正規の情報では 無いことを表現している。
[0196] 列削除を行っている間の、データベースに対するアクセスは、列追加'直接列追加方 式と同様であり、検索、追加、削除、更新が行える。
[0197] [オーバーフロ一'ブロック管理テーブルを用いた形式への適用]
オーバーフロ一'ブロック管理テーブルを用いた形式のデータベースに対して本方 式を適用する場合は、列追加:過去遡及型で述べた方法を適用すればよいので、こ こでは詳細な説明は省略する。データの追加や変更 '削除がいつでも可能なのは言 うまでも無い。
[0198] [定義削除方式後の再編成]
次に、列削除を定義削除方式によって実行した場合に、その後の再編成時に列 eを どう扱うかで、再編成は 3通りの方法をとることができる。
[0199] [定義削除方式後の再編成:定義削除列を保持] 一つ目は、列 eをそのまま保持し続ける方式である。この方式のメリットは、再編成に 必要な時間を短縮できる、列 eを使用しているプログラムの稼動を保証できる、という 点にある。一方で、列 eを実体データベースから削除した場合に比較して、レコードの アクセスに時間が掛かる、データベースの格納容量が列 eの分だけ余分に必要となる 、というデメリットがある。
[0200] [定義削除方式後の再編成:定義削除列を子データベースとして追加]
2つ目の方法は、実体データベース力 列 eを削除する力 列 eを子データベースとし て作成しておぐという方式である。子データベースは、列追加で子データベース方 式に関して説明を行ったが、その説明と同じとなる。新規データベースは列 eと主キ 一である列 aからなる王レコードとして格納される。この方式のメリットは、列 eを使用し ていたプログラムの稼動を保証できる、という点と、データベース定義体 V4を使用し ているプログラムからのアクセスが早くなる、という点である。一方で、再編成時に新た にデータベースを作成するので、再編成に力かる時間が増加する、という点と、新規 データベースのための領域が余分に必要である、というデメリットがある。実施方法は 過去保持型 ·子データベース方式で説明した方法を適用する。
[0201] [定義削除方式後の再編成:定義削除列を実体削除]
3つ目の方法は、実体データベース力も列 eを削除してしまう方法である。この方法は 、列削除 ·直接削除方式と方式的には全く同じである。データベース領域が最も少な くて済むことである。一方で、列 eを使用しているプログラムの稼動が保証できない、と Vヽぅデメリットがある。実施方法は過去非保持型 ·直接削除方式で説明した方法を適 用する。
[0202] 以上のように、それぞれの方式にはメリット、デメリットが存在するので、その意味を理 解した上で選択することが必要である。また、再編成中や再編成後のデータベース へのアクセスは、列追加や列追加後の再編成時のアクセスと同様であるので、説明 は省略する力 何の問題も無くアクセスが可能である。
[0203] [オーバーフロ一'ブロック管理テーブルを用いた形式への適用]
オーバーフロ^ ~·ブロック管理テーブルを用いた形式のデータベースに本方式を適 用する場合は、これまで説明してきた方法と変わる所が無いので詳細な説明は省略 する。再編成を行っている間の、データの追加や変更 '削除が可能であるのは言うま でも無い。
[0204] 次に、列の変更の場合に関して述べる。列の変更は、属性と長さに関するものである 。これを分類すると、その列の属性の変更で長さの変更が無い場合、列の属性の変 更が無く長さが変更になる場合、列の属性と長さの両方が変更になる場合の 3つに なる。属性とは、その列に格納されている情報の型のことで、数値であるとか、文字、 日付などと ヽつた属'性がある。
[0205] 列変更:過去遡及型の場合に関して説明を行う。現用ロケーション 'テーブルに対し て、新規ロケーション 'テーブルを設け、再編成を実施しながら、既存のレコードの変 更列を変更して 、く。列操作ポインターを現用ロケーション 'テーブルと新規ロケーシ ヨン.テーブル用に各々 1つづつ設けるのは、列追カ卩の場合と同様である。列変更： 過去遡及型の場合は、列追加:過去遡及型と同様に、レコードの形式は最新のデー タベース定義体バージョンのみとすることが好ましい。この場合は、データベース定義 体は最新のバージョンのみを保有することになる。一方で、古いデータベース定義体 を使用したアプリケーション 'プログラムにレコードを渡すために、論理構造変換テー ブルを使用する。
[0206] 列変更:過去非遡及型の場合は、既存のレコードに対する変更を行わないので、既 存のレコードに対する操作は不要である。新たに作成されるレコードは、最新パージ ヨンのデータベース定義体を用いたものだけでなぐ既存の古!、データベース定義体 バージョンを用いたレコードも追加される。また、既存のレコードは、作成された時点 の形式のままであるので、データベース定義体は各バージョンを保有することになる 。この場合も、論理構造変換テーブルを使用する。
[0207] 次に列の長さの変更に関して説明する。列の長さを変更する方法も、過去遡及型と 過去非遡及型を選択する事が可能である。過去遡及型とは、既存のレコードの変更 列の長さを新しいデータベース定義体の長さに合わせるように変更する方法である。 この場合の、既存のレコードに対する変更は、列追加:過去遡及型で述べた方法と 同様である。過去非遡及型の場合には、既存のレコードに対しては変更を行わず、 新たに作成されるレコードで、最新のデータベース定義体を用いて作成されるレコー ドの変更列の長さが変更されることになる。
[0208] この場合も、論理構造変換テーブルを用いることで、レコードのバージョンとアプリケ ーシヨン'プログラムのバージョンが異なっても、レコードの受け渡しが可能であるが、 列の長さを変更した場合、情報の桁あふれや切り捨ての可能性があるため、適用す る場合には、運用上の問題が発生しないことを確認することが必要である。
[0209] [ァクセラレータ一.システムへの適用]
図 40を用いて、ァクセラレータ一'システムの説明を行う。ァクセラレータ一'システム の原理は次のようなものである。ロケーション 'テーブルや代替キ一'ロケーション'テ 一ブルに対して、バイナリ一'サーチを行って目的のレコードを見つける。ロケーショ ン 'テーブルに対してバイナリー 'サーチを行う際には、二分割点を幾度も探すことに なり、この回数は、ブロック内でレコードを探すための回数よりも多くなることが一般的 である。また、同時に複数のプロセスから、同じブロック内のレコードを要求する可能 性は相当に低いものである。よって、ロケーション 'テーブルと代替キ一'ロケーション 'テーブルのコピーを複数保有し、各々に対して並行してバイナリー 'サーチが行える ようにすれば、レコードに対するアクセス要求を数多く実行することが可能となる。
[0210] 図 40では、ァクセラレータ一'システムが 1つの場合を示している。ァクセラレータ一' システムでは、ロケーション 'テーブル（フランド'ロケーション 'テーブル）、代替キ一' ロケーション'テーブル（フランド ·代替キ一'ロケーション'テーブル）を保有して!/、る 1S プライマリー 'ブロック、オーバーフロー 'ブロック、代替キー'ブロック、代替キー' オーバーフロ^ ~ ·ブロックは保有して ヽな 、。ァクセラレータ^ ~ ·システムのフランド ·口 ケーシヨン'テーブルは、プライマリ一'システムのロケーション 'テーブルと機能的に 同等のものである。同様にァクセラレーター .システムのフランド .代替キー ·ロケーシ ヨン'テーブルは、プライマリ一'システムの代替キ一'ロケーション 'テーブルと機能的 に同等なものである。ァクセラレータ一'システムのフランド ·ロケーション'テープノレの 各レコードは、プライマリ■ ~ ·システムの各ロケーション'テーブル'レコードと同じブロ ックを指している。
[0211] ァクセラレータ一 ·システムでは、アクセス要求があると、主キーの場合はフランド'口 ケーシヨン'テーブルに対してバイナリ一'サーチを行い、 目的のブロックを探し、その ブロック内のレコード検索をプライマリー.システムに依頼する。代替キーの場合は、 フランド'代替キ^ ロケーション 'テーブルのバイナリ^ サーチを行い、 目的のブロ ックを見つけ、プライマリー 'システムが保持している代替キー'ブロックから目的の代 替キ一.レコードを見つけ、その代替キ一'レコードによって、フランド'ロケーション' テーブルのバイナリ一'サーチを行って目的のレコードを見つける。ここでは検索の 方法を述べたが、この方法を適用することで、レコードの更新、追加、削除が行える。 また、代替キーの場合に、代替キー'レコードに基づいてフランド'ロケーション'テー ブルのバイナリ一'サーチを行う、としたが、代替キ一'レコードに、ブロックのアドレス やブロック番号を保持している場合には不要である。このようにして、複数のァクセラ レーター.システムで並行してレコードの検索や更新を行うことにより、処理量を増加 させることが可會 となる。
[0212] 図 40では、ァクセラレータ一'システムはロケーション 'テーブル 1つと代替キ一'ロケ ーシヨン'テーブル 3種を保持しており、プライマリ一'システムと同じ数となっている。 これを、「ァクセラレーター」では対称システムと呼んでいる。これに対して、例えば、 ロケーション'テーブルと代替キ一'ロケーション 'テーブルを 2種類のみ保持して!/、る ようなァクセラレータ一'システムを想定しており、ロケーション 'テーブルのみ、代替キ 一.ロケーション 'テーブルのみ、といったァクセラレータ一'システムを作成することが 可能である。これを非対称システムと呼んでいる。ァクセラレーター 'システムに関して も、プライマリー 'ブロックとオーバーフロー 'ブロック、代替キー'ブロックと代替キー' オーバーフロー.ブロックに関して、ほぼ同様に扱うことができる。
[0213] [ァクセラレータ一.システムへの適用]
次に、「ァクセラレーター機能」を用いたシステムで、プライマリー 'システムとァクセラ レーター ·システムの同期に関して適用に関して図 41を用いて説明する。プライマリ 一'システムでは、ロケーション 'テーブル 10、代替キ一'ロケーション 'テーブル ALA 0、代替キ一'ロケーション 'テーブル ALBO、代替キ一'ロケーション 'テーブル ALC 0、を持っている。更に、最終ポインター（101、 10A1、 10B1、 10C1)を持っている 。データベースがオーバーフロ一.ブロック管理テーブルを用いた形式である場合に は、オーバーフロー 'ブロック管理テーブル 20、代替キー'オーバーフロー 'ブロック 管理テーブル 20A、代替キ一.オーバーフロ一.ブロック管理テーブル 20B、代替キ ~ ·オーバーフロ^ ~ ·ブロック管理テーブル 20C、を持つ。また、オーバーフロ^ ~ ·ブロ ック管理テーブルには、オーバーフロ一'ブロック管理テーブル 'ポインター 201を設 け、代替キ一'オーバーフロ一'ブロック管理テーブル 20Αに対して、代替キ一'ォー バーフロ一.ブロック管理テーブル.ポインター 20A1を設け、同様に、代替キ一'ォ 一バーフロ一.ブロック管理テーブル 'ポインター 20B、 20Cを設けている。
[0214] ァクセラレータ一'システム 3では、フランド'ロケーション'テープノレ 16、 ALA1と ALB 1と ALC1の各フランド代替キ一'ロケーション 'テーブル、更に、最終ポインター（16 1、 16A1、 16B1、 16C1)を持っている。データベースが、オーバーフロ一'ブロック 管理テーブルを用いたデータベース形式である場合には、フランド.オーバーフロー
•ブロック管理テーブル 21、フランド代替キ一'オーバーフロ一'ブロック管理テープ ル 21A、 21B、 21Cを設ける。 21A、 21B、 21Cの各フランド代替キ一'オーバーフロ 一.ブロック管理テーブルに対して、それぞれフランド代替キ一'オーバーフロ一'ブ ロック管理テーブル 'ポインター 21A1、 21B1、 21C1を設ける。
[0215] ァクセラレータ一'システムでは、プライマリ一'システムで、ロケーション'テープノレ または代替キー'ロケーション 'テーブルに変更が発生した場合に、ァクセラレーター 'システムに対して、その変更を通知し、ァクセラレーター 'システムでは、当該フラン ド.ロケーション.テーブルまたはフランド代替キ^ ロケーション ·テーブルの変更を 行うことになつている。プライマリ一'システムで、ロケーション 'テーブル 10、最終ポィ ンター 101、代替キ一'ロケーション 'テーブル、代替キ一'ロケーション 'テーブルの 最終ポインター（10A1、 10B1、 10C1)、の何れかに変更が発生した場合に、その 変更部分をァクセラレータ一'システムに通知する。ァクセラレータ一'システムでは、 その通知に基づいて、当該フランド'ロケーション 'テーブル 16、フランド代替キ一'口 ケーシヨン'テーブル、フランド代替キ一'ロケーション 'テーブルの最終ポインター（2 1A1、 21B1、 21C1)、の何れかに対して、当該変更部分の変更を行う。
[0216] また、データベースがオーバーフロ一'ブロック管理テーブルを用いている場合には 、上記に加えて、プライマリ一'システムで、オーバーフロ一'ブロック管理テーブル 2 0、オーバーフロ^ ~ ·ブロック管理テーブル 'ポインター 201、代替キ^ ~ ·オーバーフロ 一.ブロック管理テーブル（20A、 20B, 20C)、代替キ一'オーバーフロ一'ブロック 管理テーブル.ポインター（20A1、 20B1、 20C1)に変更が発生した場合には、ァク セラレータ一'システムにその変更を通知し、ァクセラレータ一'システムでは、当該フ ランド'オーバーフロ一'ブロック管理テーブル 21、フランド最終ポインター 161、フラ ンド ·オーバーフロ一'ブロック管理テーブル ·ポインター 211、フランド代替キ一'ォ 一バーフロ一.ブロック管理テーブル（21A、 21B、 21C)、フランド代替キ一'オーバ ーフロ一.ブロック管理テーブル 'ポインター（21A1, 21B1, 21C1)の何れかに対し て、当該部分の変更を行う。
[0217] このように、プライマリー 'システム力 変更部分をァクセラレーター 'システムに通知し 、ァクセラレーター 'システムで直ちにその変更を適用することにより、ァクセラレータ ~ ·システムの、フランド'ロケーション'テープノレ 16、フランド 'オーバーフロ^ ~ ·ブロッ ク管理テーブル 21、フランド最終ポインター 161、フランド'オーバーフロ一'ブロック 管理テーブル.ポインター 211、フランド代替キ一'ロケーション 'テーブル（21Α、 21 B、 21C)、フランド代替キ一'ロケーション 'テーブルの最終ポインター（21A1、 21B 1、 21C1)、フランド代替キ一'オーバーフロ一'ブロック管理テーブル（21Α、 21Β、 21C)、フランド代替キ一'オーバーフロ一'ブロック管理テーブル 'ポインター（21A1 , 21B1, 21C1)は、プライマリー 'システムと同等に保たれる。ァクセラレーター 'シス テムでは、当該個所の変更が完了すると、変更完了通知をプライマリー 'システムに 対して送信する。プライマリー 'システムでは、すべてのァクセラレーター 'システムか らの変更完了通知が到着するまで、当該部分の排他待ちを行う。
[0218] 以上で、基本的な場合のァクセラレーター 'システムへの適用に関して説明を行った 力 直接列追加や直接列削除、直接列変更の場合には、それらの操作を行っている 場合には、次の条件が加わる。プライマリー 'システムでは、上記の条件の他に、現 用ロケーション ·テーブル用の列操作ポインター、列操作完了ポインターと、新規ロケ ーシヨン'テーブル、新規列操作ポインターが増加する。これに対応するために、ァク セラレータ一'システムでは、フランド現用ロケーション 'テーブル用の列操作ポインタ 一 (フランド列操作ポインター）、フランド列操作完了ポインター、フランド新規ロケ一 シヨン'テーブル、フランド新規列操作ポインターを追加する。データベース力 ォー バーフロー.ブロック管理テーブルを使用した形式である場合には、新規ロケーション
'テーブルに新規オーバーフロ一'ブロック管理テーブルと、新規オーバーフロ一'ブ ロック管理テーブル 'ポインターが追加される。プライマリー 'システムで上記要素に 変更があった場合には、ァクセラレーター 'システムにその変更を通知し、ァクセラレ 一ター'システムでは、当該個所の変更を行う。
[0219] ァクセラレータ^ ~ ·システムでのアクセスは、ブロックへのアクセスがプライマリ^ ~ ·シス テムに変わるだけで、その他は、前述の列追加 '削除'変更での説明と、ァクセラレー ター ·システムで説明した方法を組み合わせることで実現できる。
[0220] 上記では、ァクセラレーター 'システムの対称システムを想定した説明を行った力 非 対称システムの場合には、プライマリー 'システムで変更があった部分を保持するァク セラレーター ·システムのみ力 その変更を受け取り更新することになる。
[0221] これまで、データベースにおける列の追加 '削除'変更に関して説明を行った。この 列の追加 '削除'変更は、一般的なデータベースに適用できるだけでなぐ XMLを用 いた情報管理にも適用が可能である。 XMLとは、タグによって囲まれた情報の集まり であるが、タグは自由に作成できるため、列の追加'削除 '変更に対して柔軟性があ る一方で、そのような柔軟性があるデータをキチンと整理して格納しておく方法が無 いことが欠点となっていた。
[0222] 特に問題となるのは、図 42の XMLサンプルの「原料」のように、同一で属性を持った タグや、図 43の XMLサンプルの「著者」のように、属性を持たずに同一のタグが出現 することである。特に、図 42の「原料」や、図 43の、「著者」のように同列のタグが複数 個存在する場合を扱うには、 RDBの正規化の問題も絡み、従来型のデータベースで は困難であった。図 42の原料の場合には、「ΝΟ」の数によって、別々の項目ととらえ ることも可能であるが、ある原料が使用されている力否かを調べる場合には、従来型 では困難な作業であった。
[0223] 本明細書で述べた方法を用いたデータベース ·システムを作成すると、 XML情報の 格納が容易に実現できる。 XMLのタグを列の名称としてデータベースを構築する。 タグが増加したときには列の追加とし、タグが減少した場合には列の削除として、デ ータベースの定義を変更していけばよい。同一のタグの場合の解決法を、図 44を用 いて説明する。列 cは、「繰り返し」として 1、 2、 3の 3つが登録されている。これは、図 43の著者名に当る列である。同じタグであるので同一の列名とする力 それを区分 するために「繰り返し」欄を使用している。この場合は、著者名が 3名までの場合に適 用できるが、もっと著者が多い場合には、列 cに対して列追加を行えばよい。
[0224] 列 clと列 c2、列 c3は各々別々の列であるので、従来型の代替キーである場合には、 3つの代替キーを作成していた力 ここでは、 1つの代替キー（代替キー C)として登 録している。「データ格納検索方式」で示した代替キーは、代替キー値と主キー値を 組み合わせたレコードを代替キー 'エントリ一として、代替キー 'テーブルに登録して いる。このため、別々の列であっても、情報の内容や属性が同じであれば、同一のキ 一として使用することが可能である。この方法を用いることにより、特定の著者が書い た本がどれであるかを検索する場合などには、大きな効果を発揮する。図 99は、図 4 3の XMLの著者が代替キー Cであるとする場合に、代替キー'エントリーがどのように 作成されるかを示したものである。これらの代替キー'エントリ一は、同一の代替キー' テーブル (代替キー C)に格納される。
[0225] 図 42の「原料」も同様に、一つのキーとすることが可能である。勿論、原料の属性に 従って個別の列として扱うこともできる。図 42の「製品」や、図 43の「書籍」は、「製品」 や「書籍」ごとにレコードとして分割して格納することが効果的である。この場合には、 主キーにサフィックスを負荷して、同一の主キーを持っており、レコードが分割されて いることを表すのが好ましい。属性情報は、データベース定義体の列の論理構造中 に格納しておくことにより、データベースのレコードを XMLに変換することが可能とな る。
[0226] XMLでは、情報がネスティングされて、上位の情報と下位の情報というように階層構 造を持つことが可能である力 このような構造に対応するには、 COBOLの DATA DIVISIONのように、レベル番号をデータベース定義体の列の論理構造中に記述し ておくことにより対応が可能となる。
[0227] このように XMLを、「データ格納検索方式」および「データ格納検索システム」で示し たデータベースに格納することが可能である。また、 XML形式とレコード形式の変換 は、ァクセラレータ一'システムを採用している場合には、ァクセラレータ一'システム で実行することにより、プライマリー 'システムの負荷を低減することが可能となる。
[0228] [データベース定義の作成変更システム]
列を追加する場合や再編成中のデータベースに対するアクセスの説明で、データべ ース定義体を変更したり、作成したりすることを説明した。このようなデータベース定 義体を人手によって作成したり、変更したりすることは、手間が掛かり、間違いを発生 させる可能性も大きくなるため、好ましくない。本システムによって自動的に作成、変 更されることが好ましいのは当然である。以下では、データベース定義体の作成、変 更を自動的に行う方法について説明する。図 4で示した、 VIに付いては人手で作成 する以外に方法はない。自動的に作成、変更を行うのは、 V2以降を作成する場合や
、新しいバージョンのデータベース定義体を作成する際に、それよりも前のバージョン のデータベース定義体を変更する場合である。まず、列の追加の場合の図 6を例にと つてみる。ここでは、 VIに対して V2では、列 fが追加されている。また、その追加方法 は列追加'子データベース方式によるものである。これらの、列を追加すること、およ び列を追加する方式の決定は、システム管理者が行うべき事項である。列を追加す ること、および列を追加する方式がシステム管理者によって決定されて、データべ一 ス 'システムに通知されると、データベース 'システムでは次のようにして、 V2のデータ ベース定義体の作成と、必要あれば VIの変更を行う。図 6の場合は、 VIの変更は 無い。
[0229] V2では、 DB— Aに格納されているレコードに対して、列 fを追加する。また、列追加' 子データベース方式で行うこと力 システム管理者力 通知されている。これに基づき
、新たにデータベースを作成する必要があることが判定できる。また、追加する列 fは 主キー項目ではな 、ため、列 fのみではデータベースを構成し得な 、ことも判定でき る。ここから、新たなデータベース DB—A1は、 DB— Aの列 aと列 fを組み合わせたレ コードによって構成されることが判定できる。また、従来力 ある DB— A自体は、何ら の変更を受けないことが判定できる。このようにして、 V2のデータベース定義体を作 成することができる。
[0230] 次に、上記の V2のデータベースを、再編成して一つのデータベースにまとめる場合 の定義体の作成方法に関して説明する。これは、図 39、図 41、図 42、図 43が対応 する。再編成を行うことは、条件を予め設定しておくことにより自動的に開始することも 可能であるし、システム管理者の指示によって開始することも可能である。
再編成が開始する前に必要なデータベース定義体を作成する必要がある。この場合 の論理を次に説明する。 V2のデータベース 2つを、再編成を行って 1つにするので あるから、データベース定義体の変更が必要であることはすぐに判定できる。これを V 3とする。 V3では、 2つであったデータベースが 1つになる力 論理的には V2と変わ らない。論理構造は、 V2をそのまま引き継ぐ。物理的には、列 bが外出しになってい たのが、新規レコードには含まれることになる。子データベースは不要となり、物理レ コードも一つとなる。
[0231] 以上のように、データベース定義体の各バージョンは、論理的に作成することが可能 である。新たなバージョンの作成は、その直前のバージョンのデータベース定義体と 、新たなバージョンを作成するためにシステム管理者によって与えられる情報、つまり 変更情報 (差分情報)を適用する。新たなバージョンが作成された後で、それ以前の バージョンを修正する方法は、新たなバージョンと以前のバージョンとの差分を、以前 の各データベース定義体に反映させていくことで実行できる。また、これまでに説明 してきたように、列状況欄を設けて、バージョン毎の履歴と、構成変更の情報を持ち、 以前のデータベース定義体を修正して保有しておく事により、最新のバージョンの形 で作成されて 、るデータベースを、以前のデータベース定義体で検索 ·更新 ·追カロ · 削除が可能である。
[0232] 論理構造変換テーブルの作成方法は、まず、変換対象となる列を定める。最新の論 理構造変換テーブルがデータベース定義体 V4までを対称としたものであり、データ ベース定義体 V5を新たに作成する場合を例にとって説明する。論理構造変換テー ブルは 1つの世代のみを保有すればよいが、説明の都合上、データベース定義体 V 4までを対称とした論理構造変換テーブルを V4、データベース定義体 V5までを対 称とした論理構造変換テーブルを V5とする。この場合には論理構造変換テーブル V 4に対して、データベース定義体 V5で列追加される場合には、その追加列を、論理 構造変換テーブルの列に加える。列が過去非保持型によって削除される場合は、論 理構造変換テーブルの列から削除する。その上で、データベース定義体 V5の論理 構造部分を、論理構造変換テーブル V5の右側（図面上）に加える。
[0233] 上記では、最新のバージョンのデータベース定義体力 新たなデータベース定義体 を作成する方法に関して述べた力 この他に任意のバージョンのデータベース定義 体力 新たなデータベース定義体を作成することが可能である。図 56は、 V3を元に して V5と V6が作成された状態を示している。これは、例えば EDI (電子商取引）など において、基本的な項目を定めて運用している場合に、特定の取引先に関して特定 の情報を追加することが必要になった場合などに有効である。総てのレコードやプロ グラムを、それらの特定の情報に対応するように変更することは、格納領域の無駄や アプリケーション 'プログラムの変更の手間を必要とする。し力しながら、例えば列追 加を過去非遡及型で実施し、取引先に合わせて、 V3の形式 (基本的な取引先）、 V 4の形式 (特定の取引先 X)、 V5の形式 (特定の取引先 Y)、 V6の形式 (特定の取引 先 Z)などとすることにより、格納領域を最小限とし、アプリケーション 'プログラムの変 更も最小限とすることが可能となる。
[0234] 以上では、変更する部分の指示をシステム管理者が行う方法に関して説明した。しか しながら、 XMLのような形式の文書では、システム管理者力 その文書が新しい形式 であるか否かを判定し、新しいバージョンを定めることが困難となる場合も想定される 。このような場合には、データベースへの書き込み時に、リクエスト処理要求受付を行 うが、そのステップ内に、タグ情報の検査を行うステップを挿入し、既存のデータべ一 ス定義体に合致している力、それとも新しいデータベース定義体を必要とする力 を 判定する。この判定に基づき、列が追加されている場合には、新しいデータベース定 義体を作成する。追加列の挿入場所に関しては、そのタグが順序を持っている場合 はそれに従う。
[0235] 以上のように、列の追加'変更を動的に行うことができることを説明した。これを応用 することにより、次のような使用法が可能となる。ロボットのように、所与条件によって 学習を行い、結果をデータとして保存し、次回以降の動作を円滑にするような仕組に おいて、所与条件が増加するとか、学習の結果、項目が増加する、といったことが頻 繁に起こり得る。このような場合に、プログラム自身が、列の追加'削除を自動的に実 施し、データベースを自動的に新しくしていき、データベースの内容を更新していくよ うにすることが可能となる。
[0236] データベース定義体は、各々の使用状況を統計的に見ることが出来るように、各々に 使用回数、作成日、最終変更日、最終使用日などの情報を格納できるようなエリアを 設け、データベース 'システムによって、それらの項目がメンテナンスされることが好ま しい。更には、個々のデータベース定義体を使用しているプログラム名や使用日時な どを保持することは更に好ましい。この機能により、古いバージョンのデータベース定 義体が使用されているのかいないの力、といった判定をすることが可能になり、一定 期間以上使用されていないバージョンのデータベース定義体および、そのデータべ ース定義体によって保持されているデータを削除することが可能となる。 （発明の効 果）
[0237] データベースにおいて、列の追加、削除、変更を行う場合に、データベースを稼動 したままでそれらの作業を行うことが可能となる。また、列の追加、削除、変更を行つ ても、アプリケーション 'プログラムを変更せずに稼動することが可能となる。

Claims

請求の範囲
[1] データを格納し、検索するデータベース 'システムにおいて、
或るバージョンのデータベース定義体により定義されたレコードを、別のバージョンの データベース定義体により定義されたレコードに変換する構造変換部と、 或る 1種類のテーブルのレコードに対して複数のパージヨンのデータベース定義体 と、
そのデータベース定義体により定義された複数のバージョンのレコードを格納する データ格納部と、を備えたデータベース 'システム。
[2] 請求項 1に記載のデータベース 'システムにおいて、
データベース定義体により定義されたレコードを、そのデータベース定義体に振り 分ける手段、を備えたデータベース 'システム。
[3] 請求項 1に記載のデータベース 'システムにおいて、
或るデータベース定義体によって定義されたレコードに対応した要求元力 のァク セス要求に対して、その要求元が要求して 、るデータベース定義体によって定義さ れたレコードに変換する手段、を備えたデータベース ·システム。
[4] データを格納し、検索するデータベース 'システムにおいて、
或るパージヨンのデータベース定義体により定義されたレコードを、別のバージョン のデータベース定義体により定義されたレコードに変換する構造変換部と、 或る 1種類のテーブルのレコードに対して単一のパージヨンのデータベース定義体 と、
そのデータベース定義体により定義された単一のパージヨンのレコードを格納する データ格納部と、を備えたデータベース 'システム。
[5] 請求項 1に記載のデータベース 'システムにおいて、
前記レコードは、主キー項目を含むデータ項目を持ち、
データレコードを主キーの順に格納するプライマリ一'ブロックとオーバーフロ一'ブ ロックと、
プライマリ^ ブロックのアドレスを格納するロケーション 'テーブル 'レコードと、 ロケーション'テーブル ·レコードを主キーの順に格納するロケーション 'テーブルと ロケーション ·テーブルの使用領域の最後を示す最終ポインターと、 追加列と主キーとからなる子レコードを格納する、子プライマリ一'ブロックと子ォー ノ ーフロー'ブロックと、
子プライマリ^ ~ ·ブロックのアドレスを格納する子ロケーション'テーブル'レコードと、 子ロケーション.テーブル ·レコードを主キーの順に格納する子ロケーション'テープ ルと、
子ロケーション ·テーブルの使用領域の最後を示す最終ポインターと、を備えたデ ータベース'システム。
[6] 請求項 4に記載のデータベース 'システムにおいて、
前記レコードは、主キー項目を含むデータ項目を持ち、
データレコードを主キーの順に格納するプライマリー 'ブロックとオーバーフロー 'ブ ロックと、
プライマリ^ ~ ·ブロックのアドレスを格納するロケーション 'テーブル 'レコードと、 ロケーション'テーブル ·レコードを主キーの順に格納するロケーション 'テーブルと ロケーション 'テーブルの使用領域の最後を示す最終ポインターと、
追加列と主キーとからなる子レコードを格納する、子プライマリー 'ブロックと子ォー ノ ーフロー.ブロックと、
子プライマリ一'ブロックのアドレスを格納する子ロケーション'テーブル'レコードと、 子ロケーション.テーブル ·レコードを主キーの順に格納する子ロケーション'テープ ルと、
子ロケーション.テーブルの使用領域の最後を示す最終ポインターと、
列操作ポインターと、を備えたデータベース ·システム。
[7] 請求項 5又は請求項 6に記載のデータベース 'システムにおいて、
オーバーフロー.ブロック管理テーブルと、 オーバーフロ^ ~ ·ブロック管理テーブル ·ポインターと、を備えたデータベース .シス テム。
[8] 請求項 1又は請求項 4に記載のデータベース 'システムにおいて、
主キー項目を含むデータ項目を持つデータレコードと、
データレコードを主キーの順に格納するプライマリ一.ブロックとオーバーフロ一.ブ ロックと、
プライマリ^ ~ ·ブロックのアドレスを格納するロケーション 'テーブル 'レコードと、 ロケーション'テーブル ·レコードを主キーの順に格納するロケーション 'テーブルと ロケーション 'テーブルの使用領域の最後を示す最終ポインターと、
列追加後のレコードが格納されたプライマリー 'ブロックのアドレスを格納する新規口 ケーシヨン 'テープノレ'レコードと、
新規ロケーション'テーブル ·レコードを主キーの順に格納する新規ロケーション'テ 一ブルと、
新規ロケーション 'テーブルの使用領域の最後を示す最終ポインターと、を備えた データベース .システム。
[9] 請求項 8に記載のデータベース ·システムにお ヽて、
現用ロケーション'テーブル用列操作ポインターと、
新規ロケーション'テーブル用列操作ポインターと、
列操作完了ポインターと、を備えたデータベース ·システム。
[10] 請求項 8に記載のデータベース 'システムにおいて、
現用オーバーフロ一'ブロック管理テーブルと、
現用オーバーフロ一'ブロック管理テーブル 'ポインターと、
新規オーバーフロ一.ブロック管理テーブルと、
新規オーバーフロ一'ブロック管理テーブル ·ポインターと、を備えたデータベース · システム。
[11] 請求項 5又は請求項 6に記載のデータベース ·システムにお ヽて、
新規ロケーション'テーブルと、
新規ロケーション 'テーブルの使用領域の最後を示す新規最終ポインターと、 現用ロケーション ·テーブル用の列操作ポインターと、 新規ロケーション'テーブル用の列操作ポインターと、を備えたデータベース ·シス テム。
[12] 請求項 1に記載のデータベース 'システムにおいて、
主キー項目を含むデータ項目を持つデータレコードと、
データレコードを主キーの順に格納するプライマリ一'ブロックとオーバーフロ一'ブ ロックと、
プライマリ^ ~ ·ブロックのアドレスを格納するロケーション 'テーブル 'レコードと、 ロケーション'テーブル ·レコードを主キーの順に格納するロケーション 'テーブルと ロケーション ·テーブルの使用領域の最後を示す最終ポインターと、
削除列と主キーとからなる子レコードを格納する、子プライマリー 'ブロックと子ォー ノ ーフロー'ブロックと、
子プライマリ^ ~ ·ブロックのアドレスを格納する子ロケーション'テーブル'レコードと、 子ロケーション.テーブル ·レコードを主キーの順に格納する子ロケーション'テープ ルと、
子ロケーション ·テーブルの使用領域の最後を示す最終ポインターと、を備えたデ ータベース.システム。
[13] 請求項 12に記載のデータベース 'システムにおいて、
オーバーフロー.ブロック管理テーブルと、 オーバーフロ^ ~ ·ブロック管理テーブル ·ポインターと、を備えたデータベース ·シス テム。
[14] 請求項 1又は請求項 4に記載のデータベース 'システムにおいて、
主キー項目を含むデータ項目を持つデータレコードと、
データレコードを主キーの順に格納するプライマリ一'ブロックとオーバーフロ一.ブ ロックと、
プライマリ^ ~ ·ブロックのアドレスを格納するロケーション 'テーブル 'レコードと、 ロケーション'テーブル ·レコードを主キーの順に格納するロケーション 'テーブルと ロケーション 'テーブルの使用領域の最後を示す最終ポインターと、 列削除後のレコードが格納されたプライマリー 'ブロックのアドレスを格納する新規口 ケーシヨン 'テープノレ'レコードと、
新規ロケーション'テーブル ·レコードを主キーの順に格納する新規ロケーション'テ 一ブルと、
新規ロケーション 'テーブルの使用領域の最後を示す最終ポインターと、を備えた データベース .システム。
[15] 請求項 14に記載のデータベース 'システムにおいて、
現用オーバーフロ一'ブロック管理テーブルと、
現用オーバーフロ一'ブロック管理テーブル 'ポインターと、
新規オーバーフロ一.ブロック管理テーブルと、
新規オーバーフロ一'ブロック管理テーブル ·ポインターと、を備えたデータベース · システム。
[16] 請求項 1又は請求項 4に記載のデータベース ·システムにおいて、
主キー項目を含むデータ項目を持つデータレコードと、
データレコードを主キーの順に格納するプライマリ一.ブロックとオーバーフロ一.ブ ロックと、
プライマリ^ ~ ·ブロックのアドレスを格納するロケーション 'テーブル 'レコードと、 ロケーション'テーブル ·レコードを主キーの順に格納するロケーション 'テーブルと ロケーション 'テーブルの使用領域の最後を示す最終ポインターと、
フランド .ロケーション'テープノレと、
フランド.ロケーション ·テーブルの使用領域の最後を示すフランド最終ポインターと
フランド列操作ポインターと、
フランド列操作完了ポインターと、を備えたデータベース ·システム。
[17] 請求項 1又は請求項 4に記載のデータベース 'システムにおいて、
代替キー値と主キー値力 なる代替キー ·レコードと、 代替キー ·レコードを代替キーの順に格納する代替キー ·ブロックと代替キー 'ォ一 ノ ーフロー.ブロックと、
代替キ一'ブロックのアドレスを格納する代替キ一'ロケーション'テーブル'レコード と、
代替キー ·ロケーション'テーブル'レコードを代替キーの順に格納する代替キー ·口 ケーシヨン 'テープノレと、
代替キー ·ロケーション 'テーブルの使用領域の最後を示す最終ポインターと、 フランド代替キ一'ロケーション 'テーブルと
フランド代替キー'ロケーション 'テーブルの使用領域の最後を示すフランド代替キ 一最終ポインターと、
フランド列操作ポインターと、
フ ランド列操作完了ポインターと、を備えたデータベース 'システム。
[18] 請求項 1又は請求項 4に記載のデータベース ·システムにおいて、
レコードの一部またはレコード外に、そのレコードが作成されたデータベース定義 体のバージョン情報を保持するデータベース .システム。
[19] 請求項 1又は請求項 4に記載のデータベース ·システムにおいて、
任意のバージョンのデータベース定義体に対して変更を加えることにより、新たなバ 一ジョンのデータベース定義体を作成するデータベース ·システム。
PCT/JP2005/003914 2004-03-08 2005-03-07 データベース・システム Ceased WO2005086003A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2006510776A JPWO2005086003A1 (ja) 2004-03-08 2005-03-07 データベース・システム
US11/530,342 US20070078909A1 (en) 2004-03-08 2006-09-08 Database System

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2004-063772 2004-03-08
JP2004063772 2004-03-08

Publications (1)

Publication Number Publication Date
WO2005086003A1 true WO2005086003A1 (ja) 2005-09-15

Family

ID=34918171

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2005/003914 Ceased WO2005086003A1 (ja) 2004-03-08 2005-03-07 データベース・システム

Country Status (3)

Country Link
US (1) US20070078909A1 (ja)
JP (1) JPWO2005086003A1 (ja)
WO (1) WO2005086003A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010211532A (ja) * 2009-03-10 2010-09-24 Canon Inc 情報処理システム、情報処理方法およびプログラム
JP2011150458A (ja) * 2010-01-20 2011-08-04 Internatl Business Mach Corp <Ibm> 情報処理装置、情報処理システム、データ・アーカイブ方法およびデータ削除方法
US8676786B2 (en) 2010-12-17 2014-03-18 Fujitsu Limited Computer product, data conversion apparatus, and conversion method
US9600271B2 (en) 2014-11-19 2017-03-21 Fujitsu Limited System, method, and computer-readable medium

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4854973B2 (ja) * 2005-03-09 2012-01-18 富士通株式会社 記憶制御プログラム、記憶制御方法、記憶制御装置および記憶制御システム
US8713009B2 (en) * 2008-09-25 2014-04-29 Yahoo! Inc. Associating objects in databases by rate-based tagging
US8473515B2 (en) * 2010-05-10 2013-06-25 International Business Machines Corporation Multi-tenancy in database namespace
US20120036166A1 (en) * 2010-08-06 2012-02-09 Oracle International Corporation Effective dating for table or relationship modifications
US10338947B2 (en) * 2011-03-15 2019-07-02 Microsoft Technology Licensing, Llc Extent virtualization
US9171027B2 (en) 2013-05-29 2015-10-27 International Business Machines Corporation Managing a multi-version database
US10114878B2 (en) * 2013-12-16 2018-10-30 International Business Machines Corporation Index utilization in ETL tools
EP3304954A4 (en) * 2015-05-29 2018-08-08 Telefonaktiebolaget LM Ericsson (publ) Method and apparatus for client side encoding in a data processing system
CN106250381B (zh) * 2015-06-04 2020-11-17 微软技术许可有限责任公司 用于确定表格式存储的列布局的系统和方法
EP3633514B1 (en) * 2017-05-24 2022-02-16 Toshin System, Ltd. Data exchange system, data exchange method, and data exchange program
US10628402B2 (en) * 2017-09-27 2020-04-21 International Business Machines Corporation Full data set avoidance
US12008006B1 (en) * 2019-09-04 2024-06-11 Palantir Technologies Inc. Assessments based on data that changes retroactively
JP7798369B2 (ja) * 2020-07-10 2026-01-14 セールスフォース インコーポレイテッド インテリジェントな親和性ベースのフィールド更新の実行
CN114968976B (zh) * 2022-04-14 2025-01-28 上海沄熹科技有限公司 内存数据库存储引擎数据优化方法、电子设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999003039A1 (en) * 1997-07-11 1999-01-21 Annex Systems Incorporated Data storage/retrieval system
WO2004036432A1 (ja) * 2002-10-21 2004-04-29 Annex Systems Incorporated データベースのアクセラレーター

Family Cites Families (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0360387B1 (en) * 1988-09-23 1996-05-08 International Business Machines Corporation Data base management system
US5179701A (en) * 1989-06-15 1993-01-12 Intellution, Incorporation Organizing a process database having different types of data blocks by maintaining separate tables for generic routines and for block-type specific routines
CA2066724C (en) * 1989-09-01 2000-12-05 Helge Knudsen Operating system and data base
US5257365A (en) * 1990-03-16 1993-10-26 Powers Frederick A Database system with multi-dimensional summary search tree nodes for reducing the necessity to access records
JP2503297B2 (ja) * 1990-08-31 1996-06-05 富士通株式会社 デ―タベ―ス処理装置および定義変更処理方法
JPH04243437A (ja) * 1991-01-18 1992-08-31 Nec Corp データベース移行方式
US5263160A (en) * 1991-01-31 1993-11-16 Digital Equipment Corporation Augmented doubly-linked list search and management method for a system having data stored in a list of data elements in memory
US5204958A (en) * 1991-06-27 1993-04-20 Digital Equipment Corporation System and method for efficiently indexing and storing a large database with high data insertion frequency
JPH05233720A (ja) * 1992-02-20 1993-09-10 Fujitsu Ltd Ｄｂにおけるデータベースアシスト方法
US5555388A (en) * 1992-08-20 1996-09-10 Borland International, Inc. Multi-user system and methods providing improved file management by reading
US5446881A (en) * 1992-09-25 1995-08-29 At&T Corp. Database storage and retrieval method using a declining stage size and repetitive searches
JPH06175897A (ja) * 1992-12-02 1994-06-24 Fujitsu Ltd データベース
US5794229A (en) * 1993-04-16 1998-08-11 Sybase, Inc. Database system with methodology for storing a database table by vertically partitioning all columns of the table
US5615367A (en) * 1993-05-25 1997-03-25 Borland International, Inc. System and methods including automatic linking of tables for improved relational database modeling with interface
CA2117846C (en) * 1993-10-20 2001-02-20 Allen Reiter Computer method and storage structure for storing and accessing multidimensional data
US5499358A (en) * 1993-12-10 1996-03-12 Novell, Inc. Method for storing a database in extended attributes of a file system
US5499359A (en) * 1994-01-18 1996-03-12 Borland International, Inc. Methods for improved referential integrity in a relational database management system
JPH07210435A (ja) * 1994-01-26 1995-08-11 Fuji Xerox Co Ltd データベース管理装置
US5666524A (en) * 1994-08-31 1997-09-09 Price Waterhouse Llp Parallel processing system for traversing a transactional database
US5611076A (en) * 1994-09-21 1997-03-11 Micro Data Base Systems, Inc. Multi-model database management system engine for databases having complex data models
CA2167790A1 (en) * 1995-01-23 1996-07-24 Donald S. Maier Relational database system and method with high data availability during table data restructuring
JPH0916607A (ja) * 1995-06-26 1997-01-17 Hitachi Ltd データベース管理システムにおけるインデクス管理方法
US5644763A (en) * 1995-06-28 1997-07-01 Sybase, Inc. Database system with improved methods for B-tree maintenance
US5842196A (en) * 1996-04-03 1998-11-24 Sybase, Inc. Database system with improved methods for updating records
US5933820A (en) * 1996-05-20 1999-08-03 International Business Machines Corporation System, method, and program for using direct and indirect pointers to logically related data and targets of indexes
US5881379A (en) * 1996-05-20 1999-03-09 International Business Machines Corporation System, method, and program for using duplicated direct pointer sets in keyed database records to enhance data recoverability without logging
US5870747A (en) * 1996-07-09 1999-02-09 Informix Software, Inc. Generalized key indexes
US6175835B1 (en) * 1996-07-26 2001-01-16 Ori Software Development, Ltd. Layered index with a basic unbalanced partitioned index that allows a balanced structure of blocks
US6208993B1 (en) * 1996-07-26 2001-03-27 Ori Software Development Ltd. Method for organizing directories
US6321234B1 (en) * 1996-09-18 2001-11-20 Sybase, Inc. Database server system with improved methods for logging transactions
US5852822A (en) * 1996-12-09 1998-12-22 Oracle Corporation Index-only tables with nested group keys
US5893120A (en) * 1997-01-02 1999-04-06 Nemes; Richard Michael Methods and apparatus for information storage and retrieval using a hashing technique with external chaining and on-the-fly removal of expired data
JPH10333953A (ja) * 1997-04-01 1998-12-18 Kokusai Zunou Sangyo Kk 統合データベースシステムおよびそのデータベース構造を管理するプログラムを記録したコンピュータ読み取り可能な記録媒体
JP3734334B2 (ja) * 1997-05-07 2006-01-11 富士通株式会社 データ移行システム、データ移行用プログラムを格納したコンピュータ読み取り可能な記録媒体、及びデータ移行方法
US5974407A (en) * 1997-09-29 1999-10-26 Sacks; Jerome E. Method and apparatus for implementing a hierarchical database management system (HDBMS) using a relational database management system (RDBMS) as the implementing apparatus
US6018742A (en) * 1998-07-07 2000-01-25 Perigis Corporation Constructing a bifurcated database of context-dependent and context-independent data items
US6457021B1 (en) * 1998-08-18 2002-09-24 Microsoft Corporation In-memory database system
US6438652B1 (en) * 1998-10-09 2002-08-20 International Business Machines Corporation Load balancing cooperating cache servers by shifting forwarded request
US6886012B1 (en) * 1998-11-18 2005-04-26 International Business Machines Corporation Providing traditional update semantics when updates change the location of data records
US6279004B1 (en) * 1998-12-22 2001-08-21 International Business Machines Corporation Database index key versioning
US6381605B1 (en) * 1999-05-29 2002-04-30 Oracle Corporation Heirarchical indexing of multi-attribute data by sorting, dividing and storing subsets
US6301646B1 (en) * 1999-07-30 2001-10-09 Curl Corporation Pointer verification system and method
US6470354B1 (en) * 1999-08-05 2002-10-22 International Business Machines Corporation Implementing persistent object services (POS) on top of a relational database
US6418448B1 (en) * 1999-12-06 2002-07-09 Shyam Sundar Sarkar Method and apparatus for processing markup language specifications for data and metadata used inside multiple related internet documents to navigate, query and manipulate information from a plurality of object relational databases over the web
US20020013779A1 (en) * 2000-03-20 2002-01-31 Sridhar Mandayam Andampillai Reverse foreign key techniques in website development
JP2001356945A (ja) * 2000-04-12 2001-12-26 Anetsukusu Syst Kk データバックアップ・リカバリー方式
US6694325B2 (en) * 2000-10-16 2004-02-17 Frank Jas Database method implementing attribute refinement model
JP2002268930A (ja) * 2001-03-08 2002-09-20 Ricoh Co Ltd データベース構成変更装置、方法及び記録媒体
EP1248206A1 (en) * 2001-04-05 2002-10-09 Sun Microsystems, Inc. Method and apparatus for database table definition
US20030229610A1 (en) * 2002-06-07 2003-12-11 Van Treeck George Michael Simpler and more concise interface to relational databases
JP4467257B2 (ja) * 2002-06-28 2010-05-26 株式会社日立製作所 データベース管理方法および装置並びにその処理プログラム
WO2004025475A1 (ja) * 2002-09-10 2004-03-25 Annex Systems Incorporated データベースの再編成システム、並びに、データベース
US20040163041A1 (en) * 2003-02-13 2004-08-19 Paterra, Inc. Relational database structures for structured documents
US7386563B1 (en) * 2003-12-11 2008-06-10 Unisys Corporation Method for using deferred column retrieval to improve row retrieval and query performance of OLE DB applications
US20070005612A1 (en) * 2005-06-29 2007-01-04 International Business Machines Corporation Methods and systems for optimizing searches within relational databases having hierarchical data

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999003039A1 (en) * 1997-07-11 1999-01-21 Annex Systems Incorporated Data storage/retrieval system
WO2004036432A1 (ja) * 2002-10-21 2004-04-29 Annex Systems Incorporated データベースのアクセラレーター

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
UEDA K. ET AL: "Object Shiko Database System ni Okeru Schema no Version Kanri.", INFORMATION PROCESSING SOCIETY OF JAPAN KANKYU HOKOKU., vol. 92, no. 23, 16 March 1992 (1992-03-16), pages 67 - 75, XP002992888 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010211532A (ja) * 2009-03-10 2010-09-24 Canon Inc 情報処理システム、情報処理方法およびプログラム
JP2011150458A (ja) * 2010-01-20 2011-08-04 Internatl Business Mach Corp <Ibm> 情報処理装置、情報処理システム、データ・アーカイブ方法およびデータ削除方法
US8745009B2 (en) 2010-01-20 2014-06-03 International Business Machines Corporation Information processor, information processing system, data archiving method, and data deletion method
US8849766B2 (en) 2010-01-20 2014-09-30 International Business Machines Corporation Information processor, information processing system, data archiving method, and data deletion method
US8676786B2 (en) 2010-12-17 2014-03-18 Fujitsu Limited Computer product, data conversion apparatus, and conversion method
US9600271B2 (en) 2014-11-19 2017-03-21 Fujitsu Limited System, method, and computer-readable medium

Also Published As

Publication number Publication date
JPWO2005086003A1 (ja) 2008-01-24
US20070078909A1 (en) 2007-04-05

Similar Documents

Publication Publication Date Title
US11080277B2 (en) Data set compression within a database system
WO2005086003A1 (ja) データベース・システム
Lomet et al. Access methods for multiversion data
US9058351B2 (en) Apparatus and method for read optimized bulk data storage
CN1264107C (zh) 集成具有不同块大小的表空间
CN116569161B (zh) 受版本控制的关系数据集管理
US11461304B2 (en) Signature-based cache optimization for data preparation
Petrov Database Internals: A deep dive into how distributed data systems work
US8108431B1 (en) Two-dimensional data storage system
US20100114843A1 (en) Index Compression In Databases
US7418544B2 (en) Method and system for log structured relational database objects
WO2009140350A1 (en) Managing storage of individually accessible data units
US10289709B2 (en) Interleaved storage of dictionary blocks in a page chain
US20230281191A1 (en) Projections for big database systems
US8682872B2 (en) Index page split avoidance with mass insert processing
KR20070003577A (ko) 역 계층적 구조를 갖고 있는 파일 시스템
JP6598997B2 (ja) データ準備のためのキャッシュ最適化
KR20030094328A (ko) 저장된 데이터를 재편성하는 시스템 및 방법
JP6432893B1 (ja) データベース処理装置、グループマップファイル生産方法及びプログラム
Graefe More modern b-tree techniques
JP2010026884A (ja) データ圧縮処理を伴うデータ管理方法
US12353386B2 (en) Method of building and appending data structures in a multi-host environment
JPH0212464A (ja) データベース・システム
US20220335030A1 (en) Cache optimization for data preparation
CN117131012A (zh) 一种可持久化和可扩展的轻量级多版本有序键值存储系统

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2006510776

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase