Execution of user defined ADT function implemented by embedded module in a database management method5930800Abstract A user defined ADT function (to be implemented by an embedded module assigned to the function) is executed with module calling triggers other than the execution of the ADT function described in an SQL statement in a database management method which allows the user to define a data type. By creating a proper execution procedure command package, an embedded module implementing an ADT function can be executed even if the function is defined in a format to return execution results as a set. The database processing method includes an ADT function analysis for selecting a procedural model for creating a proper execution procedure command package in accordance with an evaluation style and a non-ADT function called embedded module analysis for adding information on embedded modules called on module calling triggers other than execution of ADT functions. Examples of module calling triggers other than execution of ADT functions include module calling triggers specified by embedded module defining information which includes the evaluation style of the embedded module in addition to the module calling triggers. Claims We claim: Description FIELD OF THE INVENTION
______________________________________
adtmodule text {
ADT name : TEXT,
.sub.-- p.sub.-- text.sub.-- contains {
embedded module type : ADT.sub.-- function.sub.-- called,
ADT function name : CONTAINS,
evaluation style : set.sub.-- evaluation,
embedded module calling trigger : AS.sub.-- FUNCTION
.sub.-- p.sub.-- text.sub.-- at.sub.-- insert {
embedded module type :
non.sub.-- ADT.sub.-- function.sub.-- called,
embedded module calling trigger : AS.sub.-- INSERT.sub.-- TRIGGER
}
.sub.-- p.sub.-- text.sub.-- at.sub.-- delete {
embedded module type :
non.sub.-- ADT.sub.-- function.sub.-- called,
embedded module calling trigger : AS.sub.-- DELETE
TRIGGER
}
}
______________________________________
In the example of the embedded module defining information shown in FIG. 2, the embedded module with the embedded module name ".sub.-- p.sub.-- text.sub.-- contains" is called to implement an ADT function with the name "contains" and returns evaluation results as a set. The embedded module with the embedded module name ".sub.-- p.sub.-- text.sub.-- at.sub.-- insert" is called at an insertion time of text data. The module calling trigger "AS.sub.-- INSERT.sub.-- TRIGGER" means that the text insertion is the occasion of a module calling trigger. On the other hand, the embedded module with the embedded module name ".sub.-- p.sub.-- text.sub.-- at.sub.-- delete" is called at a deletion time of a line including text data. The module calling trigger "AS.sub.-- DELETE.sub.-- TRIGGER" means that the deletion of the line including the text data is the occasion of a module calling trigger. The following is a list of module calling triggers which includes module calling triggers other than "AS.sub.-- FUNCTION", "AS.sub.-- INSERT.sub.-- TRIGGER" and "AS.sub.-- DELETE.sub.-- TRIGGER". (1) AS.sub.-- FUNCTION: At invocation of an ADT function (2) AS.sub.-- INSERT.sub.-- TRIGGER: At insertion of ADT data (3) AS.sub.-- DELETE.sub.-- TRIGGER: At deletion of ADT data (4) AS.sub.-- UPDATE.sub.-- TRIGGER: At updating of ADT data (5) AS.sub.-- DROP.sub.-- TABLE.sub.-- TRIGGER: At deletion of a table (6) AS.sub.-- BEGIN.sub.-- TRANSACTION: At the start of a transaction (7) AS.sub.-- PREPARE.sub.-- COMMIT: At preparation of a commit (8) AS.sub.-- COMMIT: At a commit (9) AS.sub.-- START.sub.-- ROLLBACK.sub.-- TRIGGER: At the start of a transaction rollback processing (10) AS.sub.-- TERMINATE.sub.-- ROLLBACK.sub.-- TRIGGER: At the completion of a transaction rollback processing (11) AS.sub.-- START.sub.-- SYSTEM.sub.-- TRIGGER: At the start of the system (12) AS.sub.-- TERMINATE.sub.-- SYSTEM.sub.-- TRIGGER: At the end of the system (13) AS.sub.-- START.sub.-- RECOVERY.sub.-- TRIGGER: At the start of a recovery (14) AS.sub.-- TERMINATE.sub.-- RECOVERY.sub.-- TRIGGER: At the end of a recovery (15) AS.sub.-- START.sub.-- PROCESS.sub.-- TRIGGER: At the start of a process (16) AS.sub.-- TERMINATE.sub.-- PROCESS.sub.-- TRIGGER: At the end of a process (17) AS.sub.-- BEGIN .sub.-- SESSION .sub.-- TRIGGER: At the start of a session (18) AS.sub.-- CLOSE.sub.-- SESSION.sub.-- TRIGGER: At the end of a session (19) AS.sub.-- CURSOR.sub.-- OPEN.sub.-- TRIGGER: At the time the cursor is opened (20) AS.sub.-- CURSOR.sub.-- CLOSE.sub.-- TRIGGER: At the time the cursor is closed FIG. 3 is a diagram showing a flowchart of a typical analysis processing carried out in the ADT function analysis 120 for an ADT function described after the WHERE clause. To be more specific, the figure shows an analysis of an ADT function (after the WHERE clause), and partial processing carried out in an ADT function sub-analysis 121 of the ADT function analysis 120 wherein a procedural model of an execution procedure command package after the WHERE clause is selected in accordance with the evaluation style 26 specified in the embedded module defining information 20. There are two procedural models which can be selected. One of the procedural models provides a procedure for taking results of execution of an embedded module one after another and carrying out data manipulation thereon through one time calling of an embedded module. According to a procedure provided by the other procedural model, on the other hand, the pieces of data are fetched one after another and an embedded module is executed for each of the pieces of data. As shown in the figure, the flowchart begins with step 122 to acquire the embedded module defining information 20 for an ADT function appearing after the WHERE clause of the user inquiry which was obtained as a result of the processing carried out in the user inquiry analysis 110 shown in FIG. 1. The calling ADT function names 25 of the embedded module defining information 20 are searched for an entry 21 that matches the ADT function described in the user inquiry 2, that is, by using the ADT function described on the user inquiry 2 as a key. The flow then goes on to step 123 at which the evaluation style in the embedded module defining information is identified. If the evaluation style is found to be a set evaluation, that is, if the outcome of step 123 is YES, the flow proceeds to step 124 to select a procedural model "Manipulation of each piece of data after set acquisition." This procedural model provides a procedure for fetching evaluation results of an embedded module obtained as a set, one after another, and carrying out data evaluation described after the SELECT clause on each of the results. If the evaluation style is found to be a sequential evaluation, that is, if the outcome of step 123 is NO, on the other hand, the flow proceeds to step 125 to select a procedural model "Manipulation of data after sequential acquisition of one line data." This procedural model provides a procedure for applying evaluation to one piece of line data obtained by sequentially accessing table data or accessing index data such as B-tree index information through the calling of an embedded module. According to the conventional method, step 125 is always taken, that is, the procedural model "Manipulation of data after sequential acquisition of one line data" is the only one available. In the method provided by the present invention, on the other hand, a set evaluation embedded module for step 124 may be used depending upon the evaluation style. The flow then continues from step 124 or 125 to step 126 at which embedded module calling information to be added to execution procedure command package in the creation process is stored in a memory. FIG. 4 is a diagram showing a flowchart of typical processing carried out in the non-ADT function called embedded module analysis 130. In the non-ADT function called embedded module analysis 130, information for calling an embedded module at a module calling trigger other than the execution of an ADT function is stored in a memory. The information for calling the embedded module is based on information on a module calling trigger described in the embedded module defining information 20 by the user inquiry 2. As shown in the figure, the flowchart begins with step 131 to form a judgment as to whether or not the user inquiry 2 is a request for an operation to update data. If the user inquiry 2 is not a request for an operation to update data, that is, if the outcome of the judgment formed at step 131 is NO, the flow goes on to step 135 to form a judgment as to whether or not an embedded module to be called at a module calling trigger described in the user inquiry 2 exists. In other words, the embedded module defining information is searched for the module calling trigger. If the embedded module to be called does not exist, that is, if the outcome of the judgment formed at step 135 is No, the flow goes on to step 136 at which the processing is ended. If the embedded module to be called exists, that is, if the outcome of the judgment formed at step 135 is YES, on the other hand, the flow goes on to step 134 at which information for calling an embedded module is stored in a memory. The information for calling the embedded module is based on pieces of data of the embedded module defining information searched for at step 135. If the user inquiry 2 is found to be a request for an operation to update data at step 131, that is, if the outcome of the judgment formed at step 131 is YES, on the other hand, the flow goes on to step 132 to form a judgment as to whether or not the data to be manipulated is ADT data. If the data to be manipulated is not ADT data, that is, if the outcome of the judgment formed at step 132 is NO, the flow goes on to step 136 at which the processing is ended. If the data to be manipulated is ADT data, that is, if the outcome of the judgment formed at step 132 is YES, on the other hand, the flow goes on to step 133 at which the embedded module defining information is searched for a module calling trigger for the operation to update the data and the ADT name. The flow then goes on to step 134 at which pieces of data of the embedded module defining information searched for at step 133 are stored in a memory as information for calling the embedded module. The flow then goes on to step 136 at which the processing is ended. FIG. 5 is a diagram showing a flowchart of typical processing carried out in the execution procedure command package creating process 140. As shown in the figure, the flowchart begins with step 141 at which the selected procedural model is prepared. The flow then goes on to step 142 at which execution procedure commands are created from a result of analyzing the user inquiry with the procedural model used as a base. The flow then proceeds to step 143 at which the ADT function analysis 121 for analyzing the ADT function after the WHERE clause and the non-ADT function called embedded module analysis 130 are carried out to create embedded module calling information. The creation of the embedded module calling information is based on the information for calling a module stored in the memory earlier. The flow then continues to step 144 at which the embedded module calling information is added to the execution procedure commands created at step 142. FIG. 6 is a diagram showing an example of the execution procedure command package and the embedded module calling information added thereto. In the user inquiry execution processing 11 shown in FIG. 1, processings 312 identified by processing numbers 311 in the execution procedure command package are executed sequentially one after another. Each of the processings is executed by the DB access function 70 shown in FIG. 1 for the processing. The additional embedded module calling information 313 is information on processing objects or the like of the processing 312. The embedded module calling information 313 includes information pointing to relevant embedded module calling information, a table of access objects and information on columns. The relevant embedded module calling information is denoted by reference numeral 1 in the example shown in FIG. 6. It is needless to say that the execution procedure command package shown in FIG. 6 is no more than an example. Instead of a table structure as is the case with this example, the execution procedure command package can also have a binary format having typically a tree structure. In addition, the expression of the relation with the module information is not limited to the additional embedded module calling information 313. FIG. 7 is a diagram showing a flowchart of typical processing carried out in the embedded module calling process 80. When a relation to the module information is encountered in the additional embedded module calling information 313 of the execution procedure command package shown FIG. 6 by the user inquiry execution processing 11, or when the DB access function 70 reaches a calling window 60, processing is carried out in the embedded module calling process 80 as follows. As shown in the figure, the processing begins with step 800 to form a judgment as to whether or not the processing is a data manipulation processing such as an insert, delete or update operation. If the processing is found to be a data manipulation processing, that is, if the outcome of the judgment formed at step 800 is YES, the flow goes on to step 810 at which the ADT name of the object to be manipulated is acquired. The flow then proceeds to step 811 to form a judgment as to whether or not an ADT is included in the data to be manipulated. If an ADT is not included in the data to be manipulated, that is if the outcome of the judgment formed at step 811 is NO, the flow continues to step 820 at which the processing is ended. In this case, no embedded module is called. If an ADT is found included in the data to be manipulated at step 811, that is, if the outcome of the judgment formed at step 811 is YES, on the other hand, the flow continues to step 812 at which one of the ADT names is fetched. This is because a plurality of ADTs may be included in the data to be manipulated. The flow then goes on to step 813 at which the embedded module calling information 40 added to the execution procedure command package 30 is retrieved by using a module calling trigger of the processing currently being carried out and the fetched ADT name. The flow then proceeds to step 814 to form a judgment as to whether or not relevant embedded module calling information 40 exists. If the relevant embedded module calling information 40 exists, that is, if the outcome of the judgment formed at step 814 is YES, the flow continues to step 815 at which an embedded module is called in accordance with the relevant embedded module calling information 40. If the relevant embedded module calling information 40 does not exist, that is, if the outcome of the judgment formed at step 814 is NO, on the other hand, the flow returns to step 811 to form a judgment as to whether or not another ADT is included in the data to be manipulated. If the processing is not a data manipulation processing, that is, if the outcome of the judgment formed at step 800 is NO, on the other hand, the flow goes on to step 816 at which embedded module calling information 40 is acquired by using a module calling trigger in the current processing as a key. A plurality of pieces of embedded module calling information 40 may be acquired. In this case, an embedded module associated with each piece of embedded module calling information 40 is called. To put it in more detail, first of all, the flow goes on to step 817 of the flowchart to form a judgment as to whether or not a piece of embedded module calling information 40 exists. If no piece of embedded module calling information 40 exists, that is, if the outcome of the judgment formed at step 817 is NO, the flow goes on to step 820 at which the processing is ended. If a piece of embedded module calling information 40 exists, that is, if the outcome of the judgment formed at step 817 is YES, on the other hand, the flow proceeds to step 818 at which one piece of embedded module calling information is fetched. The flow then goes on to step 819 at which the embedded module associated with the embedded module calling information 40 fetched at step 818 is called. The flow then goes on to step 817 to form a judgment as to whether or not a piece of embedded module calling information 40 is left to determine if another embedded module remains to be called. In the method described above, with the embedded module calling information 40 used as a base, by using relevant module calling triggers and ADTs, an embedded module not related to an ADT function, that is, a non-ADT function called embedded module, is also called as well. Next, the embodiment described by referring to FIG. 1 is used as a base for explaining in detail a user embedded module through actual commands with reference to FIGS. 8 to 11. FIG. 8 is an explanatory diagram used for describing typical processing of a search operation. As a user inquiry 2, an SQL statement "SELECT C1 FROM T1 WHERE CONTAINS (TEXT.sub.-- C, "OLYMPIC")" is used as a request to fetch values of a C1 column of lines including a character string "OLYMPIC" in the data of a TEXT.sub.-- C column from a table T. Sentences are stored as values of text type data and the text type of the data is an ADT. CONTAINS is an ADT function of the text type data. The operation of CONTAINS is to evaluate whether or not a specified character string (that is, "OLYMPIC" in the above SQL statement) is included in the data of the specified text type column (that is, TEXT.sub.-- C in the above SQL statement). It is obvious from the embedded module defining information 20 shown in the figure that the name of an embedded module for implementing the ADT function is .sub.-- p.sub.-- text.sub.-- contains, the evaluation result of which is to be returned as a set as indicated by "set evaluation" specified as the evaluation style thereof. The .sub.-- p.sub.-- text.sub.-- contains embedded module executes the above function by accessing a dedicated sentence index data 5 defined in the specified TEXT.sub.-- C column. Since the evaluation style of the embedded module defining information 20 is "set evaluation", in the preprocess processing 10, "Manipulation of each piece of data after set acquisition" is selected as a procedural model which corresponds to step 124 shown in FIG. 3. In this case, execution procedure command package 30 and the embedded module defining information 40 like the ones shown in the figure are created. Arrows 7 shown in the figure each point to a location to which the contents of the embedded module defining information are related. Then, in the execution control 50, the user inquiry is processed as follows. The execution control flow begins with step 511 at which the .sub.-- p.sub.-- text.sub.-- contains embedded module 90 is called in accordance with a command "(1) Call an embedded module" of the execution procedure command package 30 and the related embedded module calling information 40. The .sub.-- p.sub.-- text.sub.-- contains embedded module 90 accesses the sentence index data 5 defined in the TEXT.sub.-- C column, returning information on lines (or line descriptors) as evaluation results in a set format. In FIG. 8, the evaluation result set is denoted by reference numeral 91. The execution control flow then goes on to step 512 to form a judgment as to whether or not an evaluation result exists. If an evaluation result is not empty, that is, if the outcome of the judgment formed at step 512 is YES, the execution control flow proceeds to step 513 at which a line descriptor is fetched in accordance with a command "(2) Fetch an evaluation result" of the execution procedure command package 30. The execution control flow then goes on to step 514 at which the value of the specified data (of the column C1) is fetched by using the line descriptor in accordance with a command "(3) Fetch the column value" of the execution procedure command package 30. The value of the specified data (of the column C1) is fetched by accessing table data 4 by using the DB access function 70. In the figure, the "sentence m" 71 is the fetched value. The execution control flow then proceeds to step 515 at which the fetched value of the specified data (of the column C1) is displayed to the user. The execution control flow then returns to step 512 at which similar processing is carried out for another evaluation result. When the evaluation result is found to be empty at step 512, that is, if the outcome of the judgment formed at step 512 is NO, the execution control flow proceeds to step 516 at which the execution control processing is ended. Finally, results 6 are output to the user. As described above, an embedded module which returns evaluation results as a set can also be used for implementing an ADT function. By creating an appropriate execution procedure command package, such an embedded module can be executed for implementing an ADT function. FIG. 9 is an explanatory diagram used for describing another search operation. As a user inquiry 2, an SQL statement "SELECT C1 FROM T1 WHERE WCG (TEXT.sub.-- C, 1000)" is used as a request to fetch values on a C1 column of lines with a number of words in the data of a TEXT.sub.-- C column exceeding 1,000 from a table T. The TEXT.sub.-- C column is a data type similar to that of the example and defined as a text type (which is an ADT type). WCG is an ADT function of the text type data. The operation of WCG is to evaluate whether or not the number of words in the data of the specified text type column (that is, TEXT.sub.-- C in the above SQL statement) exceeds the specified number which is 1,000 in this example. It is obvious from the embedded module defining information 20 shown in the figure that the name of an embedded module for implementing the ADT function is .sub.-- p.sub.-- text.sub.-- wordcount.sub.-- greater, the object to be processed of which is a piece of ADT data as indicated by "sequential evaluation" specified as the evaluation style thereof. The .sub.-- p.sub.-- text.sub.-- wordcount.sub.-- greater embedded module executes the above function by reading in the TEXT type data and counting the number of words included in the data. Since the evaluation style of the embedded module defining information 20 is "sequential evaluation", in the preprocess processing 10, "Manipulation of data after sequential acquisition of one line data" is selected as a procedural model which corresponds to step 125 shown in FIG. 3. In this case, execution procedure command package 30 and embedded module defining information 40 like the ones shown in the figure are created. Arrows 7 shown in the figure each point to a location to which the contents of the embedded module defining information are related. Then, in the execution control 50, the user inquiry is processed as follows. The execution control flow begins with step 521 to form a judgment as to whether or not lines to be fetched remain. Initially, a line or lines remain to be fetched, that is, the outcome of the first judgment formed at step 521 is YES. In this case, the execution control flow goes on to step 522 at which a line to be evaluated is fetched in accordance with a command "(1) Fetch a line" of the execution procedure command package 30. The execution control flow then goes on to step 523 at which the .sub.-- p.sub.-- text.sub.-- wordcount.sub.-- greater embedded module 90 is called in accordance with a command "(2) Call an embedded module" of the execution procedure command package 30 and the relevant embedded module calling information. The .sub.-- p.sub.-- text.sub.-- wordcount.sub.-- greater embedded module evaluates the data of the specified ADT column of a line and returns TRUE or FALSE as an evaluation result. The execution control flow then goes on to step 524 to find out whether or not the evaluation result is TRUE or FALSE. If the evaluation result is found FALSE, the execution control flow returns to step 521 to evaluate the next unevaluated line. If the evaluation result is found TRUE, on the other hand, the execution control flow proceeds to step 525 at which the value of the specified data (of the C1 column) is fetched in accordance with a command "(3) Fetch a column value" of the execution procedure command package 30. The specified data is fetched by accessing the table data 4 using the DB access function 70 as is the case with the example shown in FIG. 8. In FIG. 9, the "sentence m" 71 is the fetched value. The execution control flow then goes on to step 526 at which the data of the C1 column is displayed to the user as an output result 6. As described above, an embedded module which evaluates data piece by piece can also be used. By creating an appropriate execution procedure command package, such an embedded module can be executed for implementing an ADT function. FIG. 10 is an explanatory diagram used for describing an insert operation. As a user inquiry 2, an SQL statement "INSERT INTO T1 WHERE VALUES(100, TEXT("- - -"))" is used as a request to catalog (insert) new data into a table T1. The ADT function TEXT is a constructor function of text type data for generating a text instance (a data value). It is obvious from the embedded module defining information 20 that, the calling of the .sub.-- p.sub.-- text.sub.-- at.sub.-- insert embedded module 90 is triggered by the insertion of a line containing a text type column as indicated by AS INSERT TRIGGER specified as a module calling trigger. In the preprocess processing 10, the execution procedure command package 30 and embedded module defining information 40 like the ones shown in the figure are created. Arrows 7 shown in the figure each point to a location to which the contents of the embedded module defining information are related. Then, in the execution control 50, the user inquiry is processed as follows. The execution control flow begins with step 531 at which a line of table data is inserted in accordance with a command "(1) Insert a line" of the execution procedure command package 30. The line is inserted by the DB access function 70, strictly speaking, by a table data (line) inserting function. The DB access function 70 is used for adding data to the table data 4. At the embedded module calling window 60 of the data insertion, the .sub.-- p.sub.-- text.sub.-- at.sub.-- insert embedded module 90 is called in accordance with the embedded module calling information 40. The .sub.-- p.sub.-- text.sub.-- at.sub.-- insert embedded module 90 adds information on data of the added sentence to a sentence index data 5 for the text type column. By maintenance of the sentence index data information by using the .sub.-- p.sub.-- text.sub.-- at.sub.-- insert embedded module 90, that is, by addition and deletion of information to the sentence index data, the function of the CONTAINS function which has been explained by referring to FIG. 7 can be implemented. FIG. 11 is an explanatory diagram used for describing typical commit processing. The SQL statement "COMMIT" used as a user inquiry 2 is a request for a commitment of transactions made so far. It is obvious from the embedded module defining information 20 that the .sub.-- p.sub.-- text.sub.-- at.sub.-- commit embedded module 90 is called at a commit module calling trigger as indicated by the specification of AS.sub.-- COMMIT as a module calling trigger. In the preprocess processing 10, the execution procedure command package 30 and embedded module defining information 40 like the ones shown in the figure are created. Arrows 7 shown in the figure each point to a location to which the contents of the embedded module defining information are related. Then, in the execution control 50, the user inquiry is processed as follows. The execution control flow begins with step 541 at which commit processing is carried out in accordance with a command "(1) Execute commit processing" of the execution procedure command package 30. The commit processing is implemented in transaction processing 70. At the embedded module calling window 60 of the transaction processing 70, the .sub.-- p.sub.-- text.sub.-- at.sub.-- commit embedded module 90 is called in accordance with the embedded module calling information 40. In this case, the .sub.-- p.sub.-- text.sub.-- at.sub.-- commit embedded module 90 terminates the exclusive control of the sentence index data 5 for the text type column and carries out other processing. It is needless to say that the termination of the exclusive control of the sentence index data 5 is no more than an example and does not prescribe or define the function of the embedded module 90. From the function point of view, it is desirable to call an embedded module having a function for maintaining information such as special index data (for example, sentence index data) and a data resource for supporting an operation of a relevant ADT function on a module calling trigger other than AS.sub.-- FUNCTION such as the commit module calling trigger. The function of an embedded module 90, module calling triggers and other attributes are entrusted to the user who defines the ADT. As described above, according to the present invention, by cataloging the evaluation style of an embedded module in advance in a database system and selecting a procedural model according to the cataloged evaluation style at a time of the creation of an execution procedure command package, an embedded module which returns results of evaluation as a set can be executed by properly creating the execution procedure command package. In addition, by cataloging module calling triggers of an embedded module in a database management system in advance and adding module information regarding module calling triggers to an execution procedure command package, the embedded module can be called even on module calling triggers other than the calling of the associated ADT function. Furthermore, with the capabilities described above, it is possible to define an ADT function that treats dedicated index data or other information as an implementation means. These all imply that it is possible to provide a database management system which allows an ADT with a greater variety of functions than the conventional ADT to be defined. Although the present invention has been described above along with the preferred embodiments disclosed, one of ordinary skill in the art would be enabled by this disclosure to make various modifications to the preferred embodiments and still be within the scope and spirit of the present invention as recited in the appended claims.
|
Same subclass Same class Consider this |
||||||||||