Database processing method, apparatus for carrying out the same and medium storing processing program6427145Abstract A database processing system for analyzing a query issued to a database to generate a corresponding execution procedure for performing database processing in accordance therewith. A plurality of columns for storing data each constituted by a set of instances and conditions concerning the instances constituting the plurality of columns are entered. A query is inputted which contains a predicate for evaluating whether a set of instances which meet the designated conditions and which can be identified with the same subscript exists among the sets of instances stored in the plurality of columns. In response to the query, a decision is made as to whether or not an index has been generated for one or plural columns specified in the query predicate. When the index is generated, the index is accessed to acquire an identifier of table data which is "true" for a predicate. Unless the index is generated, a decision is then made as to whether or not column data acquired by accessing the database meet the conditions specified in the predicate contained in the query. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
CREATE TABLE grade (
Registered-ID-number CHAR(8)
Name MVARCRAR (10),
Department MVARCHAR (10),
E-mail-address VARCHAR (32),
Subject MVARCHAR (16) ARRAY[32],
Mark INTEGER ARRAY[32])
At this juncture, it is to be noted that the repetitive column is designated by a key word "ARRAY". Further, the above statement indicates that the subject column allows the MVARCHAL-type data of a maximum definition length of 16 bytes to be stored or entered for management up to 32 elements at maximum. Similarly, the above statement indicates that the mark column is capable of storing the INTEGER-type data up to 32 elements at maximum. In conjunction with the repetitive column, it should also be mentioned that any one of the elements entered for management in the repetitive column can discriminatively be identified by a value interposed between square brackets "[" and "]" which succeed to the repetitive column name in the query statement. By way of example, the query statement projecting the value of an element identified or determined by "1" among the elements entered in the subject column may be expressed as follows: SELECT subject[1] FROM grade Parenthetically, in most of practical cases, the numeric value "N" placed or interposed between the square brackets "[" and "]" may duly be regarded as designating the N-th element in the subject column. Hereinafter, the value interposed or placed between the square brackets "[" and "]" which succeeds to the repetitive column name in the query statement will be referred to as "subscript" only for convenience of description. For proceeding with the description, it is assumed, only by way of example, that guide information concerning an English conversation course is to be sent by E-mail to the students whose marks for English are not greater than the score "60" and thus the E-mail addresses of these students have to be acquired. In that case, for realization of the query for the student grade list, a query statement 4 mentioned below (also see FIG. 3) may be inputted to the database managing system. SELECT E-mail-address FROM grade WHERE ARRAY (subject, mark) [ANY] (subject=`English` AND mark<=60) In the case of the instant embodiment of the invention, an ARRAY predicate is used for realizing the evaluation that the mark for the subject `English` is not greater than the score "60". With the ARRAY predicate, a plurality of the repetitive columns designated within the parenthesis "()" which succeeds to "ARRAY" in the statement are regarded as repetition of plural items represented, respectively, by sets each of the elements having a same subscript, and if any one of these elements satisfies the conditions given within the parenthesis "()" which succeeds to "[ANY]", truth value "true" is sent back. In the case where one repetitive column is designated within the parenthesis "()" succeeding to "ARRAY" rather than a plurality of repetitive columns, the ARRAY predicate returns truth value "true" when any one element entered in the designated repetitive column meets the conditions designated within the parenthesis "()" which succeeds to "[ANY]". It will now be appreciated that the above-mentioned query statement including the ARRAY predicate is to realize the query for acquiring the E-mail address values of the table rows in each of which the value of the element of the subject column identifies `English` and in each of which the value of the element of the mark column corresponding to the above-mentioned element is not greater than the score "60". Upon reception of the query 4 mentioned above from the user, the database managing system performs evaluation of the subject column and the mark column in the individual rows 301 to 305 of the student grade list in the light of the ARRAY predicate. As a result of the evaluation, the row 302 containing the element for which the marked score of the subject `English` is "52" and the row 303 containing the element for which the marked score of the subject `English` is "59" are selectively determined as the rows which meet the imposed conditions to be sent back or returned to the user as a result of the search (denoted by reference numeral 5 in FIG. 3). As will be appreciated from the above, through the procedure described above, the sets of the instances which have heretofore been realized in terms of the relations between or among a plurality of tables in the case of the conventional relational database model can be stored in a single table as the values of the columns capable of handling the sets according to the teachings of the present invention, whereby the capacity of the database can be reduced to a possible minimum. Besides, by virtue of the capability of evaluating the elements of plural repetitive columns as the sets or combinations, respectively, the search for the columns handling the sets can be realized with a simplified query description or statement. Additionally, because the query statement is destined for the single table mentioned above and thus the access areas can be reduced to a minimum, the processing for executing the query can be realized efficiently and effectively. Further, for realization of the query, the relevant processing(s) can be executed at a further increased speed by adopting or using as key the index indicating the sets or combinations of the elements entered in the plural repetitive columns. Now, description will be directed to a configuration of a structure of the database managing system. FIG. 4 is a block diagram showing a structure of the database managing system according to an embodiment of the invention. As can be seen in FIG. 4, the database managing system 1 according to the instant embodiment of the invention is comprised of a query analyze processing module 10, a database processing execution control module 20, a table data managing module, an index managing module 40, a database area access processing module 50 and a definition processing/dictionary managing module 60. The query analyze processing module 10 is designed to receive the query request 4 issued from the user or an application program for analyzing the query to thereby generate an appropriate or proper execution procedure for allowing the access to the database. Further, the query analyze processing module 10 also serves for a function for sending back to the query source the data acquired as the result of execution of the query request 4 by making access to the database. In case the query request 4 represents a data manipulation processing (DML) request such as storage, deletion, updating or search of data, then the processing control is transferred to the database processing execution control module 20. On the other hand, when the query request 4 indicates a data definition processing (DDL) such as table definition, index definition or the like, the processing control is transferred to the definition processing/dictionary managing module 60. Furthermore, when it is found upon analyzing the query 4 that the query statement contains the ARRAY predicate, then the query analyze processing module 10 performs a processing 11 for determining whether the index for evaluating the ARRAY predicate is available or not. The result of the index availability determination processing is sent to the execution procedure creation processing 12 to be reflected in the execution procedure. The database processing execution control module 20 is designed to control the execution of access to the database in accordance with the execution procedure generated by the query analyze processing module 10 through cooperation with the table data managing module 30 and the index managing module 40. The data acquired as the result of the database access is transferred to the query analyze processing module 10 to be sent back to the query request source denoted by reference numeral 4 in FIG. 4. The table data managing module 30 is designed to manage the table data 21 stored in the database area 2. In more concrete, the table data managing module 30 performs the processings for storage, deletion, updating and search of the data through the medium of the database area access processing module 50. The table data 21 also contains the data concerning the table having the repetitive columns described previously by reference to FIG. 3. The table data managing module 30 is further imparted with a function for performing the ARRAY predicate evaluation processing 31 for the row data of the table when the ARRAY predicate is contained in the query statement and when the execution procedure mentioned previously indicates that no index is used for evaluating the ARRAY predicate. The index managing module 40 is in charge of managing the indexes 22 stored in the database area 2. More specifically, the index managing module 40 is imparted with a function for performing an index update processing 42 in accompany with updating of the table data 21 to thereby update the relevant indexes 22 through the medium of the database area access processing module 50. Additionally, the index managing module 40 is imparted with a function for executing an index search processing 41 for allowing the search to be performed for the table rows which are "true" for the ARRAY predicate at a high speed by making access to the indexes 22. The database area access processing module 50 is designed to make access to the table data 21 or the indexes 22 stored in the database area 2 in accordance with the request issued from the table data managing module 30 or the index managing module 40 as described hereinbefore. The definition processing/dictionary managing module 60 is in charge of managing various definition information such as schema information, table information and the like which are stored in the dictionary 3. The definition information stored in the dictionary 3 also includes index definition information 32 for the indexes 22 which in turn are stored in the database area 2. Further, the definition processing/dictionary managing module 60 is designed to register in the dictionary 3 the definition information resulting from the analysis performed by the query analyze processing module 10 when the query request 4 indicates a data definition processing (DDL). The program or programs for realizing the functions of the query analyze processing module 10, the database processing execution control module 20, the table data managing module 30, the index managing module 40, the database area access processing module 50 and the definition processing/dictionary managing module 60 of the database managing system 1 may be recorded on a recording medium such as a CD-ROM or the like and stored on a magnetic disk or the like to be loaded in a memory for execution as occasion requires. Of course, the medium for recording the program(s) mentioned above is never limited to the CD-ROM. Other appropriate recording medium may be used to this end. Further, the program(s) may be loaded onto the memory for execution thereof by way of another computer system connected to on a network. FIG. 2 is a schematic block diagram showing exemplarily a hardware structure of a computer system according to an embodiment of the present invention. Referring to the figure, the computer system denoted generally by numeral 2000 is comprised of a CPU 2002, a main storage unit 2001, an external storage unit 2003 such as a magnetic disk device or the like and a large number of terminals 2004. The database managing system 1 described hereinbefore by reference to FIG. 4 is installed in the main storage unit 2001, while the database area 2 including the table data 21 and the indexes 22 to be managed by the database managing system 1 is stored in the external storage unit 2003. Further, the dictionary 3 mentioned previously is also stored in the external storage unit 2003. Additionally, the program(s) for realizing the database managing system 1 is stored in the external storage unit 2003 as well. FIG. 5 is a view for illustrating, by way of example only, a storage structure of the individual row data stored as the table data 21. The row data are stored each in the form of a data record 530 in a page 500 which serves as a unit base for the data input/output operation. In this conjunction, it should also be mentioned that the page 500 constitutes a structural unit of the database area 2. A plurality of data records 530 can be stored in one page 500. The store location or position of the data record 530 on the page 500 can be designated with the aid of slots 520. In the slot areas 520, there are stored the locations or positions of the data records 530, respectively, relative to the top of the page 500. Page control information 510 is provided or effecting slot management in view of slot allocation status or the like and area management in view of page occupation status or the like. The data record 530 includes a repetitive column data field 532 in which data of the repetitive column is stored. Further, the data record 530 contains data fields 533 for the other ones than the repetitive column and a record header 531 for managing the data fields in the data record 530. In the repetitive column data fields 532, there are stored in an array structure the elements constituting the repetitive column data. By virtue of this arrangement, access to the element can readily be realized by using the subscript mentioned hereinbefore. In the case of the database managing system now under consideration, the repetitive column data fields 532 are stored directly in the data record 530. However, the repetitive column data fields may be realized as another data record which can logically be pointed from the data record 530. Further, the elements constituting the repetitive column data need not necessarily be implemented in the array structure. What is required is that the store position or location can be determined with the subscript. FIG. 6 is a view for illustrating, by way of example, a structure of the index 22 in the database managing system according to the instant embodiment of the invention. More specifically, a typical structure of the index 22 which is destined to be stored in the database area 2 is illustrated in FIG. 6. As can be seen from this figure, the index 22 is composed of index entries 221. Referring to FIG. 6, each of the index entries 221 is comprised of an index key 222 and a record identifier 223 for making it possible to access the data record 530 (see FIG. 5) which is the entity of the relevant row data. The index key 222 is generated on the basis of the value of the element identified by a given subscript and contained in the repetitive column data having the index defined in the relevant row data. In the case where the index is defined for a plurality of repetitive columns, the index key 222 is generated on the basis of a combination or set of the values of the elements determined by the subscripts contained in the data of the plural repetitive columns, respectively. In the case of the example illustrated in FIG. 6, there is shown the index which is defined for the two repetitive columns (subject and mark) of a student grade list table. In that case, the index key 222 assumes a data structure of "the value of the element of the subject column+value of the element of the mark column". Definition of the index can be realized in the form of a request statement analogous to SQL (Structured Query Language), as exemplified by the undermentioned one. CREATE INDEX ARRAY_IDX1 ON grade (subject, mark) where ARRAY --IDX1 represents an index name affixed to the index defined. Each of the record identifiers 223 is composed of a page identifier 224 for identifying definitely the page 500 in which the data record 530 is stored and a slot ID number 225 identifying the slot 520 for specifying the store position of the data record in the page. The slot ID numbers 225 are assigned sequentially, starting from the one adjacent to the page control information 510 in the page storage structure (see FIG. 5). In the case of the example illustrated in FIG. 6, a structure "page identifier+slot ID number" is adopted. However, no problem will arise in the structure "slot ID number+page identifier". Access to the data record can be realized with the aid of the record identifier 223. More specifically, access to the store page is carried out by using the page identifier 224 constituting a part of the record identifier 223, and then the data record store position entered in the slot corresponding to the slot ID number 225 is acquired for thereby making access to the data record 530. Since the repetitive column of one row data has a plurality of elements, there are available a number of index keys 222 which number is equal to the number of elements, i.e., index entries 221, for the one row data. To say in another way, the same record identifier 223 exists in a plurality of index entries 221, respectively. In the case of the example shown in FIG. 6, the record identifiers {Page 25, 2} exist in the two index entries 221, respectively. Further, the record identifier {Page 30, 4} also exist in the two index entries 221, respectively. At this junction, it should be added that the index may be defined not only for a plurality of repetitive columns but also for the combination of the other column than the repetitive column and the repetitive column. FIGS. 13, 14 and 15 are views showing, by way of example, variations of the index structure. FIG. 13 shows an example of the index entries 221 in the case where the index is defined for one repetitive column. Shown at the right-hand side of a table 1300 are the index entries 221 which correspond to the row data 1301 (having the record identifier of "row 13") of the table 1300 with the index having been defined for the repetitive column C3. The index keys 222 contained in the index entries 221 are generated in dependence on the values of the elements, respectively, of the repetitive column C3. Since the number of the elements stored in the repetitive column C3 is four in the case of the row data 1301, the number of the index entries 221 each having the record identifier "row 13" is four. In this conjunction, it is to be mentioned that when redundancy or overlapping such as duplication occurs in the values of the elements stored in the repetitive column, a number of the record identifiers which correspond to that of overlapping values are stored in one index entry 221 for management. FIG. 14 shows an example of the index entries 221 in the case where the index is defined for two repetitive columns. More specifically, shown at the right-hand side of a table 1400 are the index entries 221 which correspond to row data 1401 (having the record identifier of "row 14") of the table 1400 with the indexes being defined for the repetitive columns C3 and C4, respectively. The index keys 222 contained in the index entries 221 are generated in dependence on the values of the elements, respectively, of the repetitive column C3 and the values of the elements, respectively, of the repetitive column C4 which correspond to the subscripts of the elements, respectively, of the repetitive column C3. FIG. 15 shows an example of the index entries 221 in the case where the index is defined for two repetitive columns and one of the other columns than the repetitive columns. More specifically, there are shown at the right-hand side of the table 1500 the index entries 221 which correspond to row data 1501 (having the record identifier of "row 15") of the table 1500 with the indexes being defined for the repetitive columns C3 and C4 and one other column C2, respectively. The index keys 222 contained in the index entries 221 are generated, respectively, in dependence on three element values, i.e., the values in the column C2, the values of the elements of the repetitive column C3 and the values of the elements of the repetitive column C4 which correspond, respectively, to the subscripts of the elements of the repetitive row C3. The index 22 now under consideration is provided for the purpose of acquiring the record identifier of the data record having the column value which coincides with the conditions designated or specified in the ARRAY predicate. Accordingly, in most of practical applications, the index entries 221 need not be stored in the form of a table structure as described hereinbefore in conjunction with the exemplary embodiment of the invention but may be implemented as a high-speed data access enabling form such as a B-tree (balanced multiway search tree) index, as illustrated in FIG. 7. FIG. 7 is a view for illustrating an exemplary implementation of the data structure of the index 22 as a B-tree index according to another embodiment of the present invention. As can be seen in FIG. 7, the B-tree index 22 is comprised of a root node 701, intermediate nodes 702 and leaves nodes 703. The tree structure is realized with the root node 701 being positioned atop. The index entries 221 are stored for management in the distal leaves nodes 703, respectively, of the tree structure, whereas there are stored in the root node 701 and the intermediate nodes 702, respectively, entries having respective pointers to the nodes of hierarchically lower rank. In many practical applications, the root node 701, the intermediate nodes 702 and the leaves nodes 703 may each be realized by the page which represents a unit for data input/output operation. Through the index search processing 41 described hereinbefore by reference to FIG. 4, the tree structure is traced from the root node or page 701 to the leaf node 703 by way of the intermediate node 702 with the key generated under the conditions designated or specified in the ARRAY predicate. The root node 701 and the intermediate nodes 702 may be resident in a memory. In that case, the input/output frequency can be decreased, whereby a high-speed access can be achieved. FIG. 8 is a flow chart for illustrating a processing procedure carried out by the query analyze processing module 10 in the database managing system according to the instant embodiment of the invention. More specifically, FIG. 8 shows the contents of a processing 11 for making decision as to the use of the index corresponding to the ARRAY predicate, which processing is executed by the query analyze processing module 10 when the ARRAY predicate makes appearance in the query request 4. For analyzing the query request 4 issued by the user, it is decided on the basis of the index definition information 32 registered in the dictionary 3 whether an execution procedure in which the index is used for evaluation with the ARRAY predicate is to be generated or alternatively an execution procedure in which no index is used is to be generated. Referring to FIG. 8, in a step 801, the ARRAY predicate is first analyzed for acquiring the column names designated or specified in the ARRAY predicate. Subsequently, in a step 802, the index definition information relevant to the acquired column names is acquired. The processing for acquiring the index definition information 32 is executed by activating the processing/dictionary managing module 60. When it is decided in a step 803 that the relevant index definition information has been acquired (i.e., when the decision step 803 results in "Yes"), the processing proceeds to a step 804 where generation of the execution procedure in which the index is used for the evaluation with the ARRAY predicate is determined, whereupon the processing comes to an end in a step 806. On the other hand, unless the relevant index definition information is found available in the step 803, decision is then made that the usable index is not defined, which is then followed by a step 805 where generation of the execution procedure is determined such that the repetitive column data is evaluated by accessing the data record without using the index for evaluation of the ARRAY predicate. The processing then comes to an end in a step 806. FIG. 9 is a flow chart for illustrating a processing procedure executed by the index managing module 40 of the database managing system according to the instant embodiment of the invention. More specifically, FIG. 9 illustrates contents of the index search processing 41 which is executed in the case where the ARRAY predicate is contained in the query statement and where the index usable for evaluation with the ARRAY predicate is available with the use of the index being determined by the processing procedure described hereinbefore by reference to FIG. 8. At first, in a step 901, the index search key is generated under the conditions designated or specified in the ARRAY predicate. By way of example, in the case of the query statement described hereinbefore by reference to FIG. 3, "subject=`English`" and "mark<=60" are used for generating the index search key {`English`, 60}. Subsequently, in a step 902, index entry search is performed by using the index search key generated in the step 901. In the case of the example mentioned just above, the index entry or entries which meet the conditions "subject=`English` AND mark<=60" are searched. When the index entry or entries which coincide with the specified conditions are found in a step 903, the processing proceeds to a step 904 where the record identifiers contained in the index entry or entries are acquired, whereon the acquired record identifiers are sent back to the table data managing module 30 in a step 905. The index search processing then comes to an end in a step 907. The record identifiers sent back to the table data managing model are used for accessing the data record which is performed by the table data managing module 30 for thereby carrying out the projection processing or the like. By contrast, unless the index entry or entries which coincide with the specified conditions are found in the step 903, the processing proceeds to a step 906 where the search result that the relevant record identifier is not found is sent back to the table data managing module 2030, whereupon the index search processing is terminated (step 907). FIGS. 10 and 11 are flow charts for illustrating a processing procedure executed by the index managing module 40 of the database managing system according to the instant embodiment of the invention. More specifically, there are illustrated in FIGS. 10 and 11 the contents of the index update processing 42 executed when the table data 21 containing the repetitive columns for which the index is defined is to be updated. Update processing is performed on the index designated as the object to be updated through the execution procedure generated by the query analyze processing module 10. At first, the type of the processing performed on the table data 21 is decided by referencing the execution procedure generated by the query analyze processing module 10 in a step 1001. When the result of this decision shows that the processing performed on the table data is an insert processing, the processing then proceeds to a step 1002. In the step 1002, the column data which constitutes the index to be updated is acquired from the inserted table data. In this conjunction, it is to be mentioned that acquisition of the column data from the inserted table data resident in the memory is preferred because of high efficiency. In the case of the repetitive column, one of the elements is acquired as the inserted data. Subsequently, in a step 1003, the index key is generated by using the data acquired in the step 1002. In a step 1004, search is performed for the whole index for finding the index-entry-updated position by using the index key generated precedingly. In a step 1005, decision is made as to whether or not the index entry corresponding to the concerned index key has been found. When the index entry has been found as being present, the processing then proceeds to a step 1006 where the record identifier is added to the index entry as found. On the other hand, unless the index entry is found in the decision step 1005 (i.e., when the step 1005 results in "No"), a novel index entry is generated and added to the index in a step 1007. After completion of the update processing for one index entry in the steps 1006 and 1007, decision is then made in a step 1008 whether or not any further additional data exists. To say in another way, it is decided in the step 1008 whether or not any further element of the repetitive column exists. When the decision step 1008 results in affirmation "Yes", indicating presence of the additional data, then the step 1002 is resumed for adding the record identifier or the novel index entry, as described hereinbefore. When no additional data is present, this means that the update processing has been executed a number of times which corresponds to the number of elements of the repetitive column. Accordingly, the index update processing comes to an end (step 1026). Turning back to the step 1001, when the decision results in a delete processing, the processing proceeds to a step 1009. In the step 1009, the column data which constitutes the index to be updated is acquired from the table data deleted. In this conjunction, the column data required for updating the index should preferably be stored in the memory upon deletion of the table data. In the case of the repetitive column, one of the elements is acquired as the deleted data. Subsequently, in a step 1010, the index key is generated by using the data acquired in the step 1009. In a step 1011, search is performed for the whole index for thereby finding the index-entry-updated position by using the index key generated in the step 1010, whereon the record identifier is deleted from the index entry (step 1012). When the number of the record identifiers in the index entry becomes zero after deletion, the index entry itself may be deleted. In succession, decision is made in the step 1013 whether or not any further data deleted exist. In other words, it is decided in the step 1013 whether or not any further element of the repetitive column exists. When the decision step 1013 results in affirmation "Yes", indicating presence of the element, the step 1009 is resumed for performing the record identifier deletion processing for the index, as described above. When no data deleted is preset, this means that the update processing has been executed a number of times corresponding to the number of elements of the repetitive column, whereupon the index update processing is terminated (step 1026). Turning back to the step 1001, when the decision in this step 1001 results in an update processing, the processing proceeds from the step 1014 to a step 1015. Steps succeeding to the step 14 are shown in FIG. 11. In the step 1015, pre-update column data (i.e., column data before update processing) which constitutes the index is acquired from the table data updated. Upon updating of the table data, the column data required for updating the index is stored as the pre-update column data in the memory. In the case of the repetitive column, one of the elements is acquired as the pre-update data. Subsequently, in a step 1016, the index key is generated by using the data acquired in the step 1015. In a step 1017, search is performed for the whole index for finding the index-entry-updated position by using the index key generated in the step 1016. In a step 1018, the record identifier is deleted from the index entry. When the number of the record identifiers in the index entry becomes zero due to the deletion, the index entry itself may be deleted. Subsequently, post-update column data (i.e., the column data after update processing) which constitutes the index for the updated table data is acquired in a step 1019. In this conjunction, it is to be mentioned that the column data mentioned above should preferably be acquired from the updated table data resident in the memory because of high efficiency. In the case of the repetitive column, one of the elements is acquired as the post-update data. Subsequently, in a step 1020, the index key is generated by using the data acquired precedingly. In a step 1021, search for the whole index is performed for finding the index-entry-updated position by using the index key generated in the step 1020. In a step 1022, decision is made as to whether or not the index entry corresponding to the index key has been found. When the index entry has been found as being present, the processing then proceeds to a step 1023 where the record identifier is added to the index entry as found. By contrast, unless the index entry is found in the step 1022 (i.e., when the decision step 1022 results in "No"), a novel index entry is generated to be added to the index in a step 1024. After completion of the update processing of one index entry in the steps 1023 and 1024, decision is then made in a step 1025 whether or not any further data updated exists. To say in another way, it is decided in the step 1025 whether or not any further element of the repetitive column exists. When the decision step 1025 results in affirmation "Yes", indicating the presence of the updated data, the step 1015 is resumed. When the data updated is absent, this means that the update processing has been carried out a number of times corresponding to the number of elements of the repetitive column. Accordingly, the index update processing comes to an end in the step 1026. FIG. 12 is a flow chart for illustrating a processing procedure executed by the table data managing module 30 of the database managing system according to the instant embodiment of the invention. More specifically, this figure illustrates the contents of the processing executed by the table data managing module 30 for the row data of the table on the presumption that the ARRAY predicate is contained in the query statement and that nonuse of the index for evaluation of the ARRAY predicate is specified by the execution procedure. By accessing the data record with the record identifier for the ARRAY evaluation as acquired by using the index or the like, the designated column data is evaluated in the light of the ARRAY predicate. At first, in a step 1201 shown in FIG. 12, a record identifier for the row representing the search result candidate screened out by using the index or the like is acquired, whereon access is made to the page storing the data record with the page identifier contained in the record identifier in a step 1202. Further, access is made to the data record with the slot ID number contained in the record identifier in a step 1203, which is then followed by a step 1204 where access is made to the repetitive column data field. In a step 1205, one element data is extracted from the repetitive column, whereon decision is performed for the element data as to whether the conditions stipulated in the ARRAY predicate applies valid or not, i.e., "true" or "false", in a step 1206. In case the decision step 1206 results in being "true", the ARRAY predicate evaluation processing is terminated in a step 1208. In that case, further processing for extracting projected column data or the like may be performed. On the other hand, in case the decision as to whether or not the conditions prescribed in the ARRAY predicate are met by the element data results in being "false" in a step 1208, then the processing proceeds to a step 1207 for making decision as to whether or not a succeeding element exists for thereby evaluating whether the conditions specified in the ARRAY predicate is met by the succeeding element data. When the succeeding element exists, the step 1205 is resumed. On the other hand, unless any further element data is present, the ARRAY predicate evaluation processing is terminated by issuing the final decision result of being "false". In this case, the ARRAY predicate evaluation processing may be performed for the succeeding data record. The processings described above by reference to the flow charts are implemented in the form of program or programs which can be executed by the computer system illustrated, by way of example, in FIG. 4. In this conjunction, it should be noted that the programs mentioned above are never restricted to those stored in the external storage unit which is physically connected directly to the computer system such as illustrated in FIG. 2. The program(s) may be stored in a recording medium such as a hard disk device, a floppy disk or the like which can be accessed by a computer for read/write operations. Further, the program(s) may be stored in an external storage unit connected to another computer system which is provided separately from the computer system shown in FIG. 2. In the database managing system described above, the function for evaluating the repetitive column is realized with the ARRAY predicate. It should however be understood that the present invention is n ever restricted to the ARRAY predicate. Other types of predicates or functions may be resorted to for substantially same effects. Furthermore, although the foregoing description has been made on the presumption that in conjunction with the function for realizing the ARRAY predicate, the values of elements of plural repetitive columns are handled in terms of a set or combination, the present invention is not always restricted to the function of the ARRAY predicate. By way of example, the present invention may be implemented by applied to the system in which a table definition statement "CREATE TABLE" with options being designated is adopted. As is apparent from the foregoing, in the database managing system according to the illustrated embodiment of the invention, the set of the instances of a same data type can be stored in a single management table as the data of the column referred to as the repetitive column, whereby the database capacity for the table can be suppressed to a possible minimum. Besides, by virtue of capability of evaluating the elements of plural repetitive columns as a set or combination, search for the column handling the set can be performed at a high speed with a simplified query description or statement. According to the teachings of the present invention disclosed herein, the access to the database can be realized very advantageously by managing the set of instances susceptible to mutual comparison as the column data referred to as the repetitive column.
|
Same subclass Same class Consider this |
||||||||||