JPH07182222A - Device for managing objective-oriented data base - Google Patents

Abstract

PURPOSE:To provide an objective-oriented data base managing device capable of improving access efficiency by extracting logical relation among plural classes expressed by objective orientation and clustering the classes in accordance with the extracted result. CONSTITUTION:An inter-object logical relation analyzing part 30 extracts logical relation among objects (classes) based on a compiled result of a source code 50 including plural classes expressed by objective orientation and defined by a user. A data arrangement control part 41 determined the stored positions of respective classed in a practical secondary storage 60. When a certain class has only one sub-class, the class concerned and the sub-class are adjacently arranged. When a certain class has plural sub-classes, the class concerned is arranged in the vicinity of an object having high probability of being stored in a main storage such as a data dictionary.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an object-oriented database management device for clustering objects representing information of a plurality of defined classes.

[0002]

2. Description of the Related Art Conventionally, not only in an object-oriented database management system but also in a general database management system, a technique called clustering for physically arranging logically related objects or records is improved. It is widely known that it is important for. In this case, the user (database creator or the like) explicitly describes the logical relationship between the objects, so that the objects are arranged physically close to each other. As a result, when an object is accessed, the objects logically related to the object can be simultaneously read into the main memory or the cache memory, so that the hit rate of the cashier can be improved.

A technique for improving the cache hit rate is disclosed in, for example, Japanese Patent Laid-Open No. 56-1625.
Those described in JP-A No. 7 and JP-A No. 60-163146 are known.

Japanese Unexamined Patent Publication No. 56-16257 discloses a method of reading all data of a track including a record into a cache memory when the record is accessed.

Japanese Unexamined Patent Publication (Kokai) No. 60-163146 discloses information about logical connection between data in table data of a relational database and a cache control method using the information.

[0006]

However, in the conventional clustering method described above, when constructing a database, it is necessary to clearly indicate the logical relationship between objects or records that are logically related to each other. For this reason,
Since the user needs to describe the logical relationship, the database cannot be constructed quickly. Moreover, there is a possibility that an incorrect logical relationship will be described,
In this case, it is extremely difficult to improve the cache hit rate by clustering as described above.

In the above-mentioned Japanese Patent Laid-Open No. 56-16257, there is no description or suggestion of how to include data logically related to the record in the track. Absent. In addition, JP-A-60-
In the 163146 publication, no consideration is given to arranging related relations in physical proximity. Further, since the publications of these publications do not incorporate the concept peculiar to object orientation, it is not possible to efficiently extract the logical relationship between objects in the object oriented database management system.

According to the present invention, an object-oriented database management device capable of improving access efficiency by extracting a logical relationship between a plurality of classes expressed by object orientation and clustering according to the extraction result. The purpose is to provide.

[0009]

A first invention is an object-oriented database management device for clustering objects representing information of a plurality of defined classes, and interprets parent-child relationships and attributes of each class. Interpreting means (30 in FIG. 1), counting means (41 in FIG. 1) for counting the number of subclasses of each class based on the interpretation result by the interpreting means, and based on the counting result by the counting means, Arrangement means (41 in FIG. 1) for arranging the objects expressing the information of each class on the secondary storage.

A second aspect of the present invention further comprises an embedding means (41 in FIG. 1) for embedding definition information in a class having an attribute defined as a class based on the interpretation result by the interpretation means. It has.

[0011]

In the first invention, the interpreting means interprets the parent-child relationship and attributes of each class at the time of compiling the source code including a plurality of defined classes, and the counting means based on the interpretation result, An object that counts the number of subclasses of each class and that is arranged by the arranging means can access the main memory on the secondary memory for objects that represent information of a class having a plurality of subclasses. Place it near a highly objective object. Therefore, when a subclass is accessed, its parent class is also accessed on the main memory.
It is possible to perform efficient object clustering according to a logical relationship between objects (classes).

In the second invention, the embedding means embeds the definition information in the class having the attribute defined as the class based on the interpretation result by the interpreting means. Since definition information exists for other included classes, it is possible to reduce access to other classes.

[0013]

Embodiments of the present invention will be described below with reference to the accompanying drawings.

FIG. 1 is a functional block diagram showing the configuration of an embodiment of an object-oriented database management system to which the object-oriented database management device according to the present invention is applied.

In FIG. 1, the system comprises a lexical analysis unit 1.
0, syntax analysis unit 20, inter-object logical relationship analysis unit 3
0 and a data input / output unit 40, and these function units compile a source code (that is, a source file) 50 including a plurality of classes described by a user to generate an object expressing information of each class. Clustering is performed on the next storage device 60.

The source code 50 is lexically analyzed by the lexical analysis unit 10 and further parsed by the syntax analysis unit 20. Ie compiled.

The inter-object logical relationship analysis unit 30 extracts a logical relationship between objects based on the compilation result of the source code 50. As a typical one of the logical relationship (logical relationship) handled by object-oriented,
There are generalization relationships or inheritance relationships called "is-a relationships", and aggregate relationships called "part-of relationships".

According to the present invention, the logical relationship as described above is used to arrange data that are likely to be simultaneously accessed in a physical vicinity. For example,
Consider a case where information of a plurality of user-defined classes is stored in a database (hereinafter, an object having class information is referred to as a class object).

The input / output unit 40 stores the logical relationship information of the class objects (which means the arrangement information of the objects) extracted by the inter-object logical relationship analysis unit 30.
Passed to.

In the data input / output unit 40, the data arrangement control unit 41 determines the storage position of each class object on the actual secondary storage based on the passed logical relationship information.

Next, user-defined classes (that is, class definitions) used in this embodiment are shown below.

Here, an example of a class (class definition) defined by the description in "C ++ language" will be described. Prior to that, an expression format of the type of the class in "C ++ language" is shown below. The description in "" is the expression format.

Next, the class definition is shown below. “Class String {char * data;};” ... Class definition 1 Here, in the class definition 1, the description in “” is an example (the same applies in the following description).
“Class” is a class, and “String” represents a class name and a string type. That is, "Strin
It means that the class "g" (hereinafter, "String" class) is a string type. "Char * data;
"Is an attribute," char * "is an attribute type, and" dat
"a" is the type name.

“Class Person {String name;};” Class Definition 2 Here, “class” is a class and “Person” is a class name. "String name" is an attribute and "String
"g" is the attribute type and "name" is the type name. In this class definition 2, the attribute type (Stri
ng) is a part of a class called "Person" (hereinafter referred to as "Person" class).

“Class Employee: public Person {int salary; int emp-no;};” Class Definition 3 Here, “class” is a class and “Employee” is a class name. ":" (Colon) represents an inheritance relationship. “Public” represents a public declaration. By using this declaration, the "publ" of the "Person" class
You can directly refer to and call member variables / member functions declared as "ic". From the above, class definition 3
Shows that the "Person" class is a parent, and the child of the parent class is a class "Employee" (hereinafter referred to as "Employee" class). That is, "Employee" means that the information of the class "Person" class is inherited. “Int salary” is the first attribute, “int” is an attribute type (that is, an integer type, the same applies in the following description), and “salary” is a type name. "Int emp-no" is the second attribute,
"Int" is an attribute type and "emp-no" is a type name.

[Class Student: public Person {int stu-no;};] Class definition 4 Here, “class” is a class, “Student” is a class name, and “public” is a public declaration. ,
"Person" is the class name. Also, ":" (colon) represents an inheritance relationship. From the above, class definition 4
Then, like the class definition 3, the class "Student" (hereinafter referred to as the "Student" class) is the parent "Pe
It is shown that it inherits the information of the "rson" class. "Int stu-no" is an attribute, "int" is an attribute type, and "stu-no" is a type name.

The class definition 1 and the class definition 2 are in the above-mentioned "part-of relationship", and the class definition 2, the class definition 3 and the class definition 4 are in the "is-a relationship".

In this embodiment, the source code 50 includes the contents of the class definitions 1 to 4 described above.

Next, the inter-object logical relationship analysis unit 30
The analysis processing of the logical relationship according to will be described with reference to the flowchart of FIG.

The inter-object logical relationship analysis unit 41 manages information of the analysis target class based on the compilation result of the source code 50 analyzed by the lexical analysis unit 10 and the syntax analysis unit 20 (especially the information of the class object). A temporary class information management object for doing so is generated (step 110).

After that, the following analysis processing is performed for one class definition to be analyzed.

The inter-object logical relationship analysis unit 41 determines whether or not the class to be analyzed has a parent class (step 120). If the parent class exists, the existence of the parent class is checked as the analysis target class. Registered as class information in the class information management object (step 13)
0). After completing step 130, the process proceeds to step 120. If the parent class does not exist in step 120 or the class information about all parent classes is registered in the class information management object, it is determined whether or not the class to be analyzed has attributes (step 140), and the attributes are determined. If there is no attribute, the processing is terminated. On the other hand, if there is an attribute, one of the attribute information is read (step 150), and the attribute information is associated with the class information already registered in the class information management object. Register (step 160). After this step 160 is completed, the routine proceeds to step 140.

By performing the above processing, class information management objects are generated for all classes and class information is registered.

Next, FIG. 3 shows an example of the class information management object corresponding to each class of the above class definitions 1 to 4.

In FIG. 3, (a) is a class information management object corresponding to the class definition 1, and (b) is a class information management object corresponding to the class definition 2 in FIG. (C) is a class information management object corresponding to the class definition 3, and (d) in the figure is a class information management object corresponding to the class definition 4. Further, a more specific description will be given with reference to the flowchart of FIG.

In the class definition 1, since there is no parent class in the "String" class, step 140 and subsequent steps are executed after step 120. As a result,
In (a), the attribute information of the “String” class, that is, the attribute type (char *) is registered as the class information corresponding to “String” as the information indicating the “String” class.

In the class definition 2, since there is no parent class in the "Person" class, step 140 and subsequent steps are executed in the same manner as above. Here, the attribute information of the "Person" class, that is, the attribute type (Strin
Since g) means the "String" class of the above class definition 1, in this case, (String) as the attribute information of the "Person" class is not registered, but actually,
As shown in FIG. 3B, the attribute information of the “String” class, that is, the attribute type (char *) is “Person” as the class information.
It is registered in correspondence with "Person" as information indicating a class.

In the class definition 3, since the "Employee" class has the "Person" class as the parent class, the step 130 is executed through the step 120. As a result, as shown in FIG. 3C, information indicating that the "Person" class is a parent class, for example, "Person required" corresponds to the class information, and corresponds to "Employee" as the information indicating the "Employee" class. Will be registered. Further, since there are two attributes in the "Employee" class, step 120 and subsequent steps are executed through step 120. Then, as in the case of the class definition 1 above, the attribute type (that is, int) of the “Employee” class is registered as class information.

In the class definition 4, as in the case of the class definition 3, class information is registered as shown in FIG.

Then, the inter-object logical relationship analysis unit 3
When creating the class information management objects for each of the above class definitions, 0 passes the class information management objects to the data arrangement control unit 41 and instructs the data arrangement control unit 41 to execute the object arrangement. .

Next, the object arrangement processing by the data arrangement control unit 41 will be described with reference to the flowchart of FIG.

The data arrangement control unit 41 manages the subclasses of all the classes based on the class information management object passed from the inter-object logical relationship analysis unit 30, and has a variable length composed of a class name and the number of subclasses. (Hereinafter referred to as a subclass management table) is created (step 310), and it is determined whether or not there is an unchecked class information management object among the class information management objects passed from the inter-object logical relationship analysis unit 30. (Step 320).

If there are unchecked ones,
The class information management object is read (step 330), it is determined whether or not the attribute information is registered therein (step 340), and if it is registered, the attribute information is read (step 350). It is determined whether the attribute is a class attribute (Class attribute), that is, whether it is a (part-of relationship) (step 360).

If it is not a class attribute, the process proceeds to step 340. On the other hand, if it is a class attribute (part)
-Of relation) reads the information of the class,
This information is embedded at the position of the read attribute information (step 370).

After that, it is judged whether or not the read class has a parent class, that is, (is-a relation) (step 380). , If it has a parent class (is-a relationship), the value of the number of subclasses of the parent class in the subclass management table is incremented by 1 (step 39).
0). After finishing this step 390, step 38
Move to 0.

If the attribute information does not exist in step 340, the process proceeds to step 380.

If all the class information management objects are checked in step 320, the process is terminated. Now we have the number of subclasses for all classes.

FIG. 5 shows the contents of the subclass management table in which the number of subclasses of the classes for the above class definitions 1 to 4 is obtained by the above-mentioned processing.

In FIG. 5, only the class with the class name “Person” (“Person” class) has two subclasses.
It has become. This is done by changing the "Person" class to "Employ", as is clear from the above class definitions 1 to 4.
Since the "ee" class (see class definition 3) and the "Student" class (see class definition 4) inherit, "Perso"
The number of subclasses of the “n” class is “2”.

When the number of subclasses of all classes is obtained in this way, the data arrangement control unit 41 clusters the class objects based on the subclass management table.

Next, the clustering processing by the data arrangement control unit 41 will be described with reference to the flowchart of FIG.

The data arrangement control unit 41 reads the subclass management table (step 501) and determines whether or not there is an unanalyzed class in the subclass management table (step 502).

If there is an unanalyzed class, the class is managed based on the subclass management table as shown in FIG. 5 and the class information management object already passed from the inter-object logical relationship analysis unit 30. It is determined whether or not the class has a subclass (step 503), and if it does not have the subclass, the process moves to the above step 502. On the other hand, if the class has the subclass, the subclass is unique based on the class information management object. It is judged whether or not it is a subclass (step 504).

Here, in the case of the only subclass, the class and the subclass are arranged adjacent to each other (step 505). Step 5 after completing this step
Move to 02.

If there are a plurality of subclasses in step 504, the class having the largest number of subclasses analyzed so far is compared with the number of subclasses registered in the subclass management table (step 506).
It is determined whether or not the number of subclasses of the subclass is larger (step 507).

If the number is small, the process proceeds to step 502. On the other hand, if the number is large, the class is defined as the class having the largest number of subclasses, and the name of the class and the number of subclasses are temporarily stored (step 508). After completing this step, the process proceeds to step 502.

When all the classes are analyzed in step 502, based on the class name and the number of subclasses temporarily stored in step 508,
It is judged whether or not there is a class having the largest number of subclasses (step 509), and if there is, the class having the largest number of subclasses is determined based on the name of the temporarily stored class, such as in the data dictionary. It is placed in the vicinity (step 510), and the process ends. Step 50
In 9, if there is no class having the largest number of subclasses, the process ends.

With the above processing, the clustering of class objects is completed. In the above-mentioned processing procedure, step 505 and step 510 show the processing in which the class object is actually arranged in the secondary storage.

That is, the process of step 505 means that a certain class has only one subclass and that the class and its subclass are arranged adjacent to each other. As a specific example, now, the above class definitions 1 to 3
If there is only up to, as shown in Figure 7 (a), "Pe
The "rson" class and the "Employee" class are arranged adjacent to each other.

Further, step 510 means that when a certain class has a plurality of subclasses, the class is arranged in the vicinity of an object which is likely to be read in the main memory such as a data dictionary.

The above is the case of "is-a relation",
Next, the clustering result in the case of the “part-of relationship” will be described using the above class definitions 1 to 4. FIG.
It becomes like (b). That is, "Perso of class definition 2
The "String" class of the class definition 1 is embedded as an attribute of the "n" class. As a result, when the "Person" class is loaded into the main memory, the "String" class is also loaded at the same time, so the number of times the class is accessed can be reduced.

In the above embodiment, the "C ++ language" has been described as an example, but the present invention is not limited to this.
Any object-oriented language can be applied. Since this can be easily recognized by those skilled in the art, description in other languages will be omitted.

As described above, in this embodiment,
When storing the "Employee" class and the "Student" class in the database, the information of the parent class "Person" is necessary in addition to the information unique to each class. , The class object of the "Person" class is arranged near the class object of the "Student" class. For this reason,
When the class object of the subclass is loaded into the main memory, the object of its parent class is also loaded into the main memory, so access to the process for the class object and the "Person" class has the "String" class as an attribute. By embedding the class object of “String” class in the class object of “Person” class, it is possible to reduce the number of times of reading the necessary class object.

Finally, the correspondence between the constituent features of the invention of claim 1 and the constituent features of the embodiment of FIG. 1 will be described. The interpreting means corresponds to the inter-object logical relationship analyzing section 30 of FIG. 1, and the counting means and the arranging means are both data arrangement control section 41 of FIG.
Corresponding to.

Correspondence between the constituent features of the invention of claim 2 and the constituent features of the embodiment of FIG. 1 will be described. The embedding means corresponds to the data arrangement control unit 41 in FIG.

[0066]

As described in detail above, according to the first aspect of the present invention, the interpreting means interprets the parent-child relationships and attributes of a plurality of defined classes, and the counting means based on the interpretation result. , The number of subclasses of each class is counted, and the arranging means accesses the main memory on the secondary memory for the object expressing the information of the class having a plurality of subclasses based on the counting result. Since it is arranged near an object that has a high possibility, when a subclass is accessed, its parent class will also be accessed on the main memory. According to this, efficient object clustering can be performed.

According to the second invention, the embedding means embeds the definition information in the class having the attribute defined as the class based on the interpretation result by the interpreting means. When this is done, the information of the class that has that attribute is also accessed, so the number of times the class is read can be reduced.

[Brief description of drawings]

FIG. 1 is a functional block diagram showing the configuration of an embodiment of an object-oriented database management device according to the present invention.

FIG. 2 is a flowchart showing the processing operation of an inter-object logical relationship analysis unit.

FIG. 3 is a diagram showing a class information management object generated by an inter-object logical relationship analysis unit.

FIG. 4 is a flowchart showing a subclass management table creation processing operation of the data arrangement control unit.

FIG. 5 is a diagram showing a subclass management table created by a data placement control unit.

FIG. 6 is a flowchart showing a class object automatic placement processing operation of a data placement control unit.

FIG. 7 is a diagram for explaining a result of automatic arrangement.

[Explanation of symbols]

10 ... Lexical analysis part, 20 ... Syntax analysis part, 30 ... Inter-object logical relationship analysis part, 40 ... Input / output part, 41 ... Data arrangement control part, 50 ... Source code, 60 ... Secondary storage device.

Claims (2)

[Claims] 1. An object-oriented database management device for clustering objects expressing information of a plurality of defined classes, comprising: interpreting means for interpreting parent-child relationships and attributes of each class; and interpreting by the interpreting means. Counting means for counting the number of subclasses of each class based on the result; and arranging means for arranging the objects expressing the information of each class on the secondary storage based on the counting result by the counting means. An object-oriented database management device characterized by being provided. 2. Based on the interpretation result by the interpretation means,
The object-oriented database management device according to claim 1, further comprising an embedding unit that embeds definition information in a class having an attribute defined as a class.