Device accessing a database using one of old definition information and new definition information based on an access request5881378Abstract A derived database processing system in a database processing device comprises a plurality of independent databases which can provide a plurality of users with a group of data to be shared for a common purpose. The derived database processing system comprises a dictionary for managing database logical definition information and database storage information in a secondary memory, a derived database registering unit for determining a definition frame of a new name without violating a definition frame of a name used in a schema definition which defines data in a database, a dictionary information manipulating means for referring to said dictionary when the manipulation target is a derived database, then selecting necessary components of said database, and a database processing procedure generating unit, in a binding process to optimize access routing in a database. The derived database processing means also comprises a database definition management means which replaces an old version of a database definition information with a new version by utilizing a consistency monitoring means and an integrity monitoring means associated with it. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
______________________________________
›Description format of a databse define statement!
<database definition> :: = CREATE DB <database name>
›FROM <cs designation>!
<database name> :: = "identifier"
<cs designation> :: = <cs name> › ,{< cs NAME> }...!
______________________________________
›Syntax rule! <database name> in the CS definition of each CS designated by <cs name> must match <database name> in <database definition>. ›Semantic Rule! A database comprises CSs designated by <cs names>in <cs designation>. The database is named by <database name>. If <cs designation> is skipped, a CS designating the present <database name> in the database designation in the CS definition will be a component.
______________________________________
›Description format of a derived database define
statement!
<definition of derived database>::=CREATE VDB <derived
database name>
FROM <element DB designation> ›WHERE <replacement
list>!
<derived database name>::=<identifier>
<element DB designation>::=<database name> ›<cs list>!
›{, <database name> ›<cs list> }...!
<CS list>::=(<cs name> ›{, <cs name> }...!)
<replacement list>::=<replacement list>
›{, <replacement element> }...!)
<replacement element>::=<schema name 1> AS <schema
name 2>
ON <database name>
.vertline.<table name 1> AS <table name 2> OA <database
name>
______________________________________
›Syntax rule! 1) A database designated by <database name> in <element DB designation> must be defined in <database definition> or <derived database definition>. 2) Each CS designated in <CS list> must be designated explicitly or implicitly in <database definition> or <derived database definition> of the database designated by <database name> immediately before the <CS list>. 3) A schema or a table designated by <schema name 1>or <table name 1> respectively in <replacement element> must be included in a database designated by <database name>. 4) <schema name 2> or <table name 2> in <replacement element> must be unique in <derived database definition>. ›Semantic rule! 1) A database is generated with a CS designated by <CS name> in <CS list> is extracted from the database designated by <database name> in <element DB designation>. This database is named by <derived database name>. If <CS list> is omitted, it is assumed that all CSs of the designated database have been designated. 2) In the database designated by <database name> in <replacement element>, an identifier of a schema (included in the database) designated by <schema name 1> is replaced with <schema name 2>. Likewise, in the database designated by <database name> in <replacement element>, an identifier of a table (included in the database) designated by <table name 1> is replaced with <table name 2>. 3) With respect to a schema or a table not designated in <replacement list>, an identifier is not replaced at all. By the input of a database define statement 40 or a derived database define statement 41 as described above, the following information is stored in a dictionary 15. (a) Data base information such as a database identifier (b) Information such as a CS identifier for identifying a composite structure (CS) which forms a database (c) Information relating to a derived database identifier and an identifier of a database to be selected (d) Information of the relation between a derived database and a CS to be selected (e) Information of the relation between an original name and its alias of a schema name or a table name when a name is duplicately assigned among databases. Described below is an example of a database define statement, etc., in a commodity analysis derived database generated from a divisional database and a central database. In this example, a database define statement is used for a central database, a manufacturer division database, and a wholesaler division database. The define statement is written as follows: CREATE DB Central DB FROM (manufacturer information CS, manufacturer commodity attribute information CS, etc.) CREATE DB Manufacturer DB FROM (sales amount CS, budget CS, etc.) CREATE DB Wholesaler DB FROM (sales amount CS, etc.) The definition of associated information other than a derived database is as follows: CREATE CS Manufacturer CS TYPE B+TREE FROM <schema table name> ON DB01 ALLOCATE DB DB01 <DB area name> TO Manufacturer information CS <DB area name> TO Manufacturer commodity attribute information CS Likewise, DB02 is allotted to a manufacturer DB and DB03 to a wholesaler DB. As the description of the define statement is similar to that described above, an example is not shown here. A derived database define statement is described, for example, as follows: CREATE VDB Commodity Analysis VDB FROM DB01 (Manufacturer information CS, Manufacturer commodity attribute information CS) DB02 (Sales amount CS, Budget CS) DB03 (Sales amount CS) The configuration example of a database manipulating system is explained as follows in association with FIG. 9A. The input of a bind control unit 50 shown in FIG. 9A is a derived database identifier or a database identifier, and an SQL standard module. A schema name and a table name are given in this module. The schema name and a table name can be an alias designated by a derived database. The input of a bind control unit 50 is, for example, a statement described as follows:
______________________________________
BIND
m <SQL module file name>
n Commodity analysis VDB
______________________________________
The content of <SQL module file name> associated with an SQL statement is described as follows: SELECT * FROM Manufacturer information, Manufacturer commodity attribute information, sales amount, budget, etc. The above described manufacturer information . . . sales amount are table names in a SQL schema. The bind control unit 50 notifies a derived database interpreting unit 14 in a dictionary information manipulating unit 13 of a derived database identifier or a database identifier. The derived database interpreting unit 14 determines elements of a dictionary 15 processed in this binding process. The dictionary elements comprises a sequence of CS identifiers in a generic composite structure, a sequence of schema names of the logical structure definition, a sequence of table names in a schema, original schema names and their aliases and original table names and their aliases. The processes are performed as follows: i) All database identifiers and CS identifiers are obtained from derived database identifiers. ii) A plurality of associated table names are obtained from CS identifiers. Associated schema names are obtained from table names. iii) Aliases are obtained from table names and schema names. An optimizing unit 51 obtains logical information and storage information for optimization by providing a logical information manipulating unit 53 in a dictionary information manipulating unit 13 with schema names and table names as inputs. The logical information manipulating unit 53 outputs a CS identifier and an original name if it is an alias when a schema name and a table name is inputted to a derived database interpreting unit 14. The logical information manipulating unit 53 extracts logical information from table information. If there is a reference restriction defined in an SQL schema among tables, the logical structure information in the table(s) is also extracted. To update a table associated with the reference restriction, the reference restriction must remain unchanged. The logical information manipulating unit 53 extracts meta information including physical information under CS information by providing a storage information manipulating unit 54 with a CS identifier. If another table in a reference relation exists, storage information in the table is also extracted. The storage information manipulating unit 54 comprises a storage structure information manipulating unit 55, a CS space information manipulating unit 56, a CS space/DB area transforming unit 57, and a DB area information management unit 58. A storage structure information manipulating unit 55 manages primitive information of a data organization which is an element of a CS. The elements of a CS comprise basic data organizations such as a heap, B+ tree, a hash. The CS space information manipulating unit 56 manages space information assigned to a CS. The CS space/DB area transforming unit 57 transforms a collection of extent information called CS space and DB area. The DB area information managing unit 58 manages extent information associated with DB areas. The extent information includes volume information in physical media and extent information in a volume. The storage information manipulating unit 54 determines a program for manipulating data organizations associated with a storage structure in a CS. Next, information is taken out of the CS space information manipulating unit 56, a CS space/DB area transforming unit 57, and a DB area information management unit 58 and determines the extent information in a volume to be accessed actually. According to these results, the optimizing unit 51 outputs a database managing procedure 52 where the optimum process cost for a database can be figured out based on logical information and storage information. The following process can be performed: i. The job of a dictionary information manipulating unit 13 can be switched. For example, a derived database interpreting unit 14 can be called by the optimizing unit 51; and derived database identifiers or database identifiers as well as schema names and table names can be inputted when the logical information manipulating unit 53 is called by the optimizing unit 51. ii. A dictionary 15 can be a table of a relational database, or can be a directory comprising a unique control table structure. iii. The derived database information on the dictionary 15 can exist in a database accessible during the binding process. When a system is physically distributed, modification can be made on duplicate arrangement and update based on the distributed database method. iv. A binding process can be performed before or just at the execution of an access to a database. The interpreting unit 14 of a derived database (shown in FIG. 9A) is explained more in detail by referring to FIGS. 9B and 9C. The definition of a derived database is as follows. CREATE VDB Commodity analysis VDB FROM DB01 (Manufacturer information CSx, Manufacturer commodity attribute information CSz) DB02 (Turnover CSy, Budget CSy) DB03 (Sales amount CSz) The above definition includes identifiers of a derived database, database, and a CS. In this supplement, a database described in derived database definition (DB01, DB02, and DB03 in the above example) is referred to as "an element database" of the derived database. In the dictionary, the information relating to the logical structure (schema, table, column, integrity restriction, etc.), and the storage structure (GCS and CS) of each element database is stored as shown in FIG. 9B. The information relating to the above database in a dictionary can be referenced using an identifier of an element database and an identifier of a CS as the keys. Based on this information, the logical structure (schema, table, column, integrity restriction, etc.) selected by a derived database and the storage structure (GCS and CS) can be determined. These structures, like an "element" database, can be referred to as an "element ???" of the derived database. As a result, the relation information between an identifier of a derived database and <an element database, element table, element integrity restriction, element GCS, and element CS> are stored as information in a dictionary (in the format 15). In FIG. 9B above, a table, GCS, and CS in the double line block are the element table, element GCS, and element CS of the derived database. The information of a derived database contains the relation information between an identifier of the derived database and components (an element database, element table, element integrity restriction, element GCS, and element CS), but does not have an entity that an ordinary database has, because these components all belong to an element database. In this respect, it refers to the same relation between a table and a view. However, it appears to an application program as a single database, as shown in FIG. 1C. As a view from an application of a derived database (Commodity analysis VDB in FIG. 2) is the same as an ordinary database, the input of a bind control unit (50) in the explanation of the configuration example of a database manipulation system shown in FIG. 9A can be, for example, described as follows: BIND -m a file name of an SQL module -n commodity analysis VDB In the file designated by the file name of the SQL module, a data manipulation statement (an SQL statement as described below) for commodity analysis VDB is stored.
______________________________________
SELECT * FROM Manufacture information table,
Manufacture commodity attribute information table,
Turnover table, Budget table, and Sales table
WHERE locating condition
______________________________________
The locating condition in the above described data manipulating statement need not be closed within a single element database, but can cover a plurality of element databases. As a derived database refers to a view only, the actual data manipulation is performed to each element database (in the above example, DB01, DB02, and DB03). Therefore, in the optimizing process, the data manipulation to a derived database must be performed by splitting the process into data manipulation closed within each element database and data manipulation covering a plurality of element databases. Accordingly, the information relating to components of a derived database (an element database, element table, element integrity restriction, element GCS, element CS) is required. The information described above can be obtained by accessing a dictionary information manipulating unit (13) shown in FIG. 9A. The components of the dictionary information manipulating unit are described below. 1) A derived database interpreting unit In a derived database interpreting unit (14), the relation information (15) between a derived database in a dictionary and components are detected using an identifier of a derived database as the key. As a result, an identifier of a component of a derived database (an element database, element table, element integrity restriction, element GCS, element CS) can be output. The components identified by these identifiers are considered in the optimizing range. 2) A logical information manipulating unit In a logical information manipulating unit (53), the information of the elements relating to the logical structure (an element table, element integrity restriction) in the components of a derived database is manipulated. The information relating to the elements of the logical structure (for example, definition information of an element table) can be outputted with an identifier of an element relating to the logical structure as the key. 3) A storage information manipulating unit In a storage information manipulating unit (54), the information relating to the storage structure (an element GCS and element CS) in the components of a derived database is manipulated. The information relating to the elements of the storage structure (for example, definition information of an element CS) can be outputted with an identifier of an element relating to the storage structure as the key. FIG. 10 shows an example of a operational configuration being executed and relating to an application program 60 including a database processing procedure 52 generated as described above. For example, an object of an application program 60 written in a host language such as C language and COBOL and a database processing procedure 52 are linked. They can be linked either by a pre-linkage through a linkage editor or a runtime dynamic linkage. A string control unit 61 is used to control linkage of an application program 60 and a database access unit 62. The database access unit 62 performs input and output to a database storage 16 according to the storage structure of data to be accessed which is determined by the database processing procedure 52, and according to the DB space information, etc. The above described process is shown in FIG. 10, and can be configured as in the prior art technology. As described above, the present embodiment permits an application program to access a plurality of independent databases, thus providing flexible services for diversified and high level user requests. As an application program can access a plurality of databases simultaneously, the following effects and advantages can be obtained: 1. Among independently developed databases, cross reference to a table among databases, transmission of data, and update of data can be performed by one application program. 2. Between a divisional database and a central database, it is very difficult to make an adjustment among divisional databases, but an alias assignment function allows an application program to process a plurality of divisional databases simultaneously and to perform data reference between a divisional database and a central database, and perform data transmission simultaneously. 3. Between independently processed databases having the same schema structure, data in tables equally defined and distributed in a plurality of independently processed databases can be processed by an application program. 4. Between a private and shared databases, the private database and the shared databases can be processed simultaneously by an application program. 5. Between test data and a production database, the production database can be used in a test by intermixing the test data as a test database with the production database to be accessed for reference by an application program. Additionally, as any table can be selected among a plurality of databases for use in a derived database, accidental destruction of data can be avoided by accessing only selected tables for the derived database. Even though duplicate names are found between databases, an alias can be assigned by the definition of a derived database, and the range of data to be processed by an application program can be extended easily without modification to existing databases. FIGS. 11A and 11B show an explanatory view of the principle of another embodiment according to the present invention. In FIGS. 11A and 11B, 70 show a database processing device comprising a CPU and a memory; 71 shows a definition modification management unit; 72 shows a database, 73 shows an old version of a database definition; 74 shows a new version of a database definition; 75a-75c, 76a, and 76b show definition elements associated with a logical structure and storage structure of a database, 77 shows an access selecting unit; and 78 shows a definition modification model. A definition modification management unit 71 manages database definition information in each definition element of a before-modification (an old version) database definition 73 and an after-modification (a new version) database definition 74. The definition modification management unit also provides a mechanism for checking the consistency of the definition information of a new version. An access selecting unit 77 selects, in response to an access request for the database 72, an access using a before-modification database definition 73 or an access using an after-modification database definition 74, and then realizes an access according to the selected definition information. A database processing device 70 of the present invention comprises such a definition modification managing unit 71, manages old version definition information, new version definition information, and the relation among them, allows either the old version or the new version definition information to be selected at an access request through an access selecting unit 77, and comprises a mechanism in a database management system for replacing old version information using new version information when a modification of all definition elements that are necessary is confirmed. In the definition modification processing method in the present invention, as shown in FIG. 11B, a definition modification model 78 is provided in the database management system, comprising an application phase for making a new version database definition 74 available in coexistence with an old version database definition 73, a verification phase for verifying during the operation using said old version database definition 73 and by executing a test program to see if said applicable new version database definition 74 meets the purpose of modification, and a confirmation phase for replacing an old version database definition 73 with a verified new version database definition 74, wherein the definition is progressively modified for each definition element in units of definition modification model. Data base definition elements comprise logical structure definition elements such as a schema, table, column, integrity constraint, etc., storage structure definition elements such as generic composite structure relating to data organizations, etc., and physical structure definition elements indicating the location of data in physical media. The definition of a database comprises these definition elements and the relation information among them. The requirements of definition modification are: 1 A definition modification model is required for ensuring consistency of database interpretation after executing the definition modifying operation; and 2 The modified definition must be verified by actual test data, etc. to determine whether the modification meets the original purpose. To meet the above described requirements, the definition must be modified based on the relation among definition elements, and every inconsistency must be corrected by repeating the operation to meet the purpose of the modification. For example, when a table is deleted, the definition element of the storage structure that refers to the table is influenced by the deletion. The overall integrity can be retained by deleting or modifying a definition for each of the definition elements that are influenced by modification. Then, an access module is bound or linked to the adjusted definition element to verify, using actual definition data, that the definition modification meets the original purpose. In the present invention, as an operation model required for definition modification is provided in a database management system, the definition is modified not ad hoc, but using a predetermined plan and procedure based on a definition modification model with little affect on the practical operation of a database. FIG. 12 shows a configuration example of a definition modification management unit 71 shown in FIG. 11. A definition modification management unit 71 comprises, as shown in FIG. 12 for example, a database definition information management mechanism 80, a modification information management mechanism 81, a consistency monitoring mechanism 82, and an integrity monitoring mechanism 90. The database definition information management mechanism 80 adjusts information of database definition elements, and manages them using their identifiers in each level such as a logical, storage, and physical level. The modification information management mechanism 81 manages, for each database definition element, before-modification (old version) and after-modification (new version) including the relation between them. In the example shown in FIG. 12, a definition element 75a is modified to a definition element 76a, and a definition element 75b to a definition element 76b. The information related to the above described modification is managed as follows. The information of a new version database definition 74 does not have to contain all related information in performing the present invention, but has only to contain the difference information associated with the modification that is different after the modification from the old version database definition 73. Copies can be used instead of difference information. The consistency monitoring mechanism 82 monitors, in the applying operation the identification of an applicable range and the the consistency among definition elements in an applicable range, that is, the applicability. FIG. 13 shows a flowchart of the consistency monitoring mechanism 82 to be used in an applying operation. 1 First, an applying operation is accepted, and definition elements to be applied are identified. 2 An application range is identified. In the example shown in FIG. 12, the application range contains a database definition 74 in a new version including a definition element 76a and definition element 76b. 3 The consistency of definition elements to be applied in the application range is checked. If no inconsistency is found, control is transferred to process 4; if inconsistency exists, control is transferred to process 5. 4 If there is no inconsistency, the definition elements to be applied are admitted in the application range. Then, control is transferred to process 6. 5 If there is inconsistency, the applying operation up to this point is judged as invalid and gets to no effect. 6 Determination is made as to whether all necessary applying operation is completed. If not, processes from step 1 must be repeated again. If yes, all definition elements are judged as applicable, and the applying operation is completed successfully. "Consistency" means that there is no inconsistency among the definition elements in a specific application range (usually, a sub-definition of a database definition). As for integrity, it is checked within the range covering a whole database and associated application programs. FIG. 14A shows the position of an integrity monitoring mechanism 90 shown in FIG. 12. The integrity monitoring mechanism 90 monitors the integrity of other objects such as database definition elements affected by definition modification and application programs 92. A check range 91 covers an application program 92, a new version database definition 74, data 93 to be actually accessed, etc. FIG. 14B shows a flowchart of the integrity monitoring mechanism 90 in the confirming operation. 1 First, a confirming operation is accepted, and definition elements to be confirmed are identified. 2 The definition elements to be confirmed are checked whether they conform, with respect to data integrity, to other definition elements and application programs 92. If yes, the confirming operation is completed successfully. 3 If not, an integrity operation must be performed. An integrity monitoring mechanism 90 checks for the integrity. In the practical integrity operation, a user may participate. 4 If the integrity operation is successfully over, it is judged as being over. If the operation fails, the confirming operation is judged as invalid. FIG. 15 shows an explanatory view of an access selecting unit 77. The access selecting unit 77 allows, when definition information is being accessed, either before-modification (old version) definition information or after-modification (new version) definition information to be selected. The access selecting unit 77 cannot be used by an application program which simultaneously accesses to the definition information comprising both new and old version definition information, but can be used for verification of the new version definition information during the operation using the old version definition information. FIG. 15B shows a flowchart of an access selecting unit 77. 1 In response to an access request, it is checked whether it is an access request to an after-modification (new version) definition. 2 If it is an access request to an after-modification definition, a new version database definition 74 is selected. 3 If it is an access request to a before-modification definition, an old version database definition 73 is selected. 4 Now, either the selected database definition 73 or 74 is accessed, thus obtaining necessary definition information. Next, an example of definition information is described in association with FIGS. 16 to 18. As shown in FIG. 16A, a before-modification database (identifier DB) is expressed in a logical structure definition table (identifier T), generic composite structure (identifier S), and a physical structure definition (identifier P). Each mechanism is described as follows, for example by adding a column C to the table T: A new database definition can be generated by performing an applying operation using an input of a definition modification statement. An identifier of a new version database can be expressed implicitly or explicitly by adding a subscript to an identifier of the old version database. In this example, the following table modification statement in an SQL language (for adding a column) is applied as a target of a new database (identifier DBI)
______________________________________
"ALTER TABLE T
ADD COLUMN C description of a column"
______________________________________
The consistency monitoring mechanism 82 shown in FIG. 12 determines whether a new version table definition really contains no inconsistency. In this example, the table definition statement "CREATE TABLE T . . . " is applied to the target database DB1 simultaneously. As a result, the above described table definition statement together with the table modification statement (for adding a column) admits generating a consistent and applicable table definition. An old version database definition is independent of a new version database definition. The relation between the new and old versions can be managed by the database definition information management mechanism 80 and the modification information management mechanism 81. In the verifying process of a new version table, a check is made using actual data and programs to determine whether the modification meets the original purpose. There are two methods available for the check. One method is shown in FIG. 17A, indicating the utilization of a lower layer (storage definition and physical definition) of an old version database. The other method is shown in FIG. 17B, performing an applying operation of definition modification on lower layers of the old version database to ensure the conformity to the new version database for obtaining the integrity of the whole database. In this method, a column is added to the table T; a record length is changed in the storage structure S; and space is extended in the physical structure P. In this phase, as shown in FIG. 14A, the integrity monitoring mechanism 90 checks the integrity of a new version in the whole database, and the integrity to an accessing module (an application program). An access selecting unit 77 shown in FIG. 11, etc. selects either a new or an old version database, permitting an access. However, this does not allow a new version to co-operate with an old version. In this example, the result comes in the following two determinations: (Case 1) If the value in the added column C is determined to be ineffective (null), the generic composite structure and the physical structure definition need not be modified. (Case 2) If it is determined as a result of the addition of a column C that the record length of the generic composite structure should be changed and the space in the physical structure definition should be extended, the generic composite structure and the physical structure definition must be modified. If it is confirmed that the definition modification meets its original purpose as a result of the verification, the confirmation phase can be started for the modification of the table definition. In the confirmation phase, confirmation in upper layers can be completed based on the completion of the confirmation of lower layers. Therefore, if the above (Case 1) is true, only the interpretation of the generic composite structure and the physical structure definition should be modified a little, but the definition itself is not modified at all (referred to as a copy level). If the above (Case 2) is true, the confirmation of the table definition modification is completed based on the completion of the confirmation of the generic structure definition (modification of a record length), and the confirmation of the generic composite structure (modification of a record length) is completed based on the completion of the confirmation of the physical structure definition (extension of the space). Transmission and reorganization of data may be, but does not have to be, interlocked with physical definition layers. FIG. 18A shows the sequence of the complete confirmation where the lower layer definition in an old version database is used. FIG. 18B shows the sequence of the complete confirmation where the lower layer definition of an old version database is modified. Next, a basic model of the operation and the state of definition modification are explained as follows. An ordinary model of definition modification is a transient model to be settled to the final after-modification state by way of the before-modification state and the intermediate state. The intermediate state is a transient state during the definition modification where data in a database cannot be processed, thus halting operation of the database. By contrast, a definition modification model applied in the present invention, as shown in FIG. 11B, considers a new version modified using a new definition an object which is independent of a before-modification definition and co-exists with an old version definition, reducing a disruptive influence on the operation of the database. A new definition modification model 78 shown in FIG. 11B comprises an application phase, a verification phase, and a confirmation phase. A summary of respective phases as follows. (a) In an application phase, a new definition description is applied; definition information of the application state (hereinafter referred to as meta data) is generated; and all definition elements are adjusted until determined to be consistent and practically applicable. (b) In a verification phase, actual data and program are checked to determine whether the meta data in the application state meet the original purpose of the modification. (c) In a confirmation phase, an old version database 1is replaced with a new version database after the determination is made in the verification phase that the meta data in the application state meet the original purpose of the modification. The definition modification model 78 is applied in each abstraction of a logical level, storage level, and physical level. FIG. 19 shows a process flow in a multi-abstraction configuration. Layers of definition elements are not limited only to the logical level, storage level, or physical level. The layers of the present definition modification model 78 is only an example. When the definition modification is reflected in every abstraction, the definition modification is completed. In the modification of the logical structure definition, a new definition is first applied at the logical level, and then verified in the state where it co-exists with an old definition. At the beginning of the confirming operation of the logical structure after the verification, definition modification is induced at the storage level if necessary. Likewise, at the beginning of the confirming operation of the storage structure, definition modification is induced in the physical level. Each of the above described phases are explained as follows. (Application Phase) In the application phase, one or more definition modifications are specified, and then the applying operation is performed. FIG. 20 shows examples of the applying operation and an example of generation of meta data. After performing a basic syntax check for the definition modification specified by the applying operation, a new version definition is generated with the specification fully reflected on it. Then, as shown in FIG. 20, an old version remains as is. Data relating to the old version is not affected by an applying operation. When a new version definition is generated with integrity, the applying operation can be determined as being successfully completed. This state is referred to as an applicable state. If a single applying operation cannot obtain the integrity, a plurality of applying operations are combined and obtain the integrity, that is, the applicable state. An applying operation can replace an existing applying operation, but usually, a plurality of applying operations are processed at the same level, and cannot be assigned priority. A result of an applying operation can be canceled, permitting deletion of a new version which is generated by the corresponding applying operation. (Verification Phase) In the verification phase, a check is made to determine whether the modification meets the original purpose by actually executing a test program on an applicable version (in this case, generating an access module AM using a new version, preparing test data, etc.). FIG. 21 shows a verification example of a new version. As a result of the verification, (1) a new version is accepted as is; (2) definition modification is continued to meet the original purpose; or (3) the modification is rejected. In case (3), a new version definition is deleted by canceling the applying operation of the corresponding definition modification. (Confirmation Phase) If a new version is determined to be accepted by the verification, the confirmation phase is started. FIG. 22 shows an example of a confirming process using a single definition layer. In the confirmation phase, a new version is replaced with an old version. The replacement depends on the verification result (1) or (2). That is, if the result is (1) above (accepted as is), the confirmation phase is completed using a single definition layer. If the result is (2), the confirmation phase is completed using a plurality of definition layers. If the confirmation phase is completed using a plurality of definition layers, it may result in lower level definition modification, or in modification of the interpretation of definition elements. (1) When the confirmation phase results in lower level definition modification The procedure for the definition modification is performed according to the definition modification standard in a multi-abstraction configuration as described above by referring to FIG. 19. The definition modification may be a secondary lower level definition modification (for example, a modification of a record length in a generic composite structure). That is, the confirmation phase of a lower level definition modification must be completed as a condition of the completion of a higher level confirmation. (2) When the interpretation of the relation among definition elements is to be modified A definition modification (for example, an addition of a column) is re-interpreted concerning the relation among associated definition elements, and a definition modification relating to the associated definition elements may not be performed. For example, an access to an added column is completely ignored. In this case, the confirmation can be completed without a secondary lower level definition modification or completion of its conformation. As the interpretation of the database is modified, of course, all inquiries up to this point cannot be determined as valid. Consistency check shown in steps 2-3 in FIG. 13 is explained in more detail. The explanation is given to show how to check the consistency of the definition elements to be applied in the application range. To give a clearer explanation, a model is limited to be in the logical structure (relational model) and a storage structure (GCS and CS)(Other database models are set based on the same basic system, having different types and names of a definition). The consistency check is made when an applying operation is performed by a consistency monitoring mechanism (82). The check range designation and the checking logic are described below. 1. The consistency check range The consistency check range can be designated. Unless the integrity of definition elements of a database being defined is not recognized in the designated range, the process terminates abnormally. On the other hand, if the integrity of definition elements of a database being defined is recognized in the designated range, the process terminates normally. For example, the consistency check range can be set as a) and b) below: a) Designation by a table is shown in FIG. 23A A table name: The check range refers to the logical structure (column, integrity constraints, etc.) and the definition of the corresponding storage and physical structure (GCS and CS) to a designated table. Overall designation: The check range refers to the logical structure (column, integrity constraints etc.) to all tables in a database being defined and the definition of the storage and physical structure (GCS and CS). b) Designation by the logic, storage, and physical structures is shown in FIGS. 23B Likewise, the consistency check range can be designated respectively in the logical structure and the storage/physical structure. Logical structure: The check range refers to the definition of the logical structure (columns, integrity constraints, etc.) to all tables in a database being defined. Storage/physical structure: The check range refers to the definition of the storage/physical structure (GCS and CS) to all tables in a database being defined. Overall designation: The check range refers to the designation of the logical structure (column, integrity constraints, etc.) to all tables in a database being defined and the storage/physical structure (GCS and CS). 2. Consistency check logic The consistency check monitoring mechanism checks the consistency in the logical structure definition, generic composite structure, and physical structure definition within the range designated in 1, above with the resource utilization state taken into account. The consistency check monitoring mechanism is used to ensure the consistency with necessary definitions established for the following optimizing operation and data accesses. Definition elements to be checked: Logical structure . . . table, view, integrity costraints, and column Storage structure . . . storage definition part of GCS and CS Physical structure . . . space definition part of CS Relation to be checked (a) Upper/lower relation "include" relation in the description "semantic dependence" relation in the concept (conditions for existence, etc.) "referencer/referencee" relation (b) Resource use relation Explanation of symbols (a) Definition elements and their upper/lower relation are shown by an arrow. The direction pointed by an arrow shows an upper element. Each block shows one definition element. Generally, a plurality of lower elements correspond to a single upper element. For example, the relation between a table and a column is shown in FIG. 24A. (b) Definition elements and their resource use relation are shown by an arrow. The direction pointed by an arrow shows a resource-providing element. Each block shows one definition element. A real line block indicates a resource-providing element, and a broken line block indicates a resource-provided element. For example, a table definition T provided from a database DBxx to a database DByy is shown in FIG. 24B. 1) Consistency check (1) The consistency of database definition of a new version is checked by a consistency monitoring mechanism based on the following logic: a) Relation where one table is fixed (=relation without a view definition and referential constraint) (1) The validity of arrows for the definition elements in FIG. 25A is checked. However, if either of the associated element is the resource-provided element, or both of them are the resource-provided elements from another database, the validity check is performed with the resource use relation taken into account. (2) The opposite relation of the relation 1 to 6 is determined in the above illustrated relations. For example, the check of the opposite relation of 5 above is performed by checking the definition of a GCS to a table. However, if either of the associated elements is the resource-provided element, or both of them are the resource-provided elements from another database, the validity check is performed with the resource use relation taken into account (refer to the consistency check (2)). b) Relation of referential constraint (relation between two tabled) Among the definition elements in a new version database definition, the consistency of the definition elements associated with reference restriction is checked based on the following logic: (1) The validity of 8 in the following definition elements shown in FIG. 25B is checked. However, if either of the associated elements of the relation 8, or both of them are provided from another database, the validity check is performed with the resource use recation taken into account. c) Relation of view definition (relation among a plurality of tables) Among the definition elements in a new version, the consistency of the definition elements relating to a view is checked based on the following logic: (1) The validity of 9 in the following definition elements shown in FIG. 25C is checked. However, if either of the associated elements of the relation 9, or both of them are provided from another database, the validity check is performed with the resource use relation taken into account. 2) Consistency check (2) . . . Consistency check on the resource use relation A consistency monitoring mechanism performs the following check relating to the resource use relation in new version database definition. This ensures that, among the definition elements having an entity (defined object), an upper definition element entity (defined object) exists in the environment of the same new version. a) If a lower definition element is provided by an older version database definition, the entity of the upper definition element can exist in a new version database definition or can be provided by an old version database definition, as shown in FIG. 26A. b) When an entity of the lower definition element exists in the new version database definition, the entity of the upper definition element also must exist in the database definition, as shown in FIG. 26B. c) Generally, when an upper definition element has a plurality of lower definition elements, the resource use relation in each of lower definition elements can be different from one another as long as the restriction a)-b) is satisfied. This means that all the lower definition elements of a definition element having an entity (defined object) in a database definition need not have an entity (defined object) in the database definition, thus ensuring the reduction of the redundancy database definition information, as shown in FIG. 26C. FIG. 27 shows a detailed flowchart corresponding to steps 2 and 3 in FIG. 13. Step 2 identifies the application range corresponding to the definition elements to be applied. The application range comprises a whole database, a designation range of table, a range of the logical structure and a range of the storage/physical structure. Step 3 checks the definition element to be applied within the application range as follows. As to validity of the definition elements of a table, it is determined whether an upper or lower definition element is used (i.e. borrowed). If NO, dependence relation check relating to a forward or backward relation is performed. If YES, resource use relation check and dependence relation check relating to a forward or backward relation is performed. As to a validity of the referential constraint, it is determined whether an upper or lower definition element is used (i.e. borrowed). If NO, a dependence relation check is performed. If YES, a resource use relation check and a dependence relation check are performed. As to a validity of a view, it is determined whether an upper or lower definition element is used. If NO, dependence relation check is performed. If YES, a resource use relation check and dependence relation check are performed. As described above, the definition modification of a database applied in the present invention comprises an application phase, verification phase, and confirmation phase, each of these phases being formatted and standardized to establish a common model of definition modification. Thus, an ordinary user-specified procedure and restriction management can be adopted in a database management system. A progressive database re-organizing process in definition modification can be realized in a process model.
|
Same subclass Same class Consider this |
||||||||||