JPH047671A - Data base retrieval processing system - Google Patents

Abstract

PURPOSE:To reduce the burden of user and processing time by retrieving instances (group) having a specified connection with an instance designated by means of a condition and processing the instances(group) as a retrieval result. CONSTITUTION:When a retrieval request is received from the user, an object direction data base control system (00DBMS) 50 analyzes the retrieval request, retrieves 53 the instance of a class designated as the object of retrieval from a data base 40, evaluates the condition designated as the retrieval condition and selects the instance satisfying the condition as the retrieval result. Even if the class to which the instance being the object of operation belongs is not clear in DBMS 50 but if connection with the known instance is designated as the condition, 00DBMS 50 recognizes the connection and the instance being the object of operation can be specified. Thus, the burden of the user for designating data being the object of operation can considerably be reduced and a user interface with satisfactory operability can be obtained in the data base 40 in which data having complicated structure is set to be the object.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to a database search processing method in an object-oriented database management system.

[Conventional technology]

In recent years, the field of application of database processing technology has shifted from the traditional business field to the field of computer intelligence (CIM).
OA
(Office Automation) and other new fields are being expanded. In applications to such new fields, the structure of data managed in databases is more complex, and it is necessary to manage real-world data faithfully to that structure.

Against this background, object-oriented database management systems (hereinafter referred to as OO) have been attracting attention recently.
DBMS: 0bject-Oriented Da
ta BaseManage++ent System
). The data entity targeted by the database is called an instance, and a collection of instances with the same attributes is called a class.

000BMS treats each piece of data as one object, and classifies the relationship between objects.
ssification), aggregation
It is expressed through abstractions such as generalization and generalization.

"Classing" groups objects that have common properties; for example, an employee class is a grouping of employee objects. A class is also considered an object, and the class and the objects within the class are called objects and instance objects, respectively. In the following, each will be simply referred to as a class or an instance. "Aggregation" abstracts the inclusion relationship between instances, and corresponds to, for example, the relationship between an assembly component instance and a child component instance in a hierarchical relationship of components.

In particular, a group of instances forming a hierarchical structure with a certain instance as the root is collectively called a composite object. "Streaming" is a relationship between classes, and abstracts a categorical inclusion relationship such as a car class and a vehicle class, for example. This relationship is used to provide inheritance functionality for class definitions. Further, it is sometimes called "specialization" in the sense of a relation in the opposite direction to the generalization relation.

OODBMS attempts to express complex relationships between data in the real world as faithfully as possible through these abstractions.

When a user using 00DBMS constructs a database, he or she first defines classes and related definitions for storing instances. Then register the instance,
Register the instance relationships according to the definition. When accessing the registered instance, use the access interface provided by the OODBMS.

The present invention relates to a search processing method in an OODBMS. Here, paper J is used as a known example 1.

Banerjee et al., “Quaries in Object-Oriented Databases” (Que
ries in 0bject-Oriented D
IEEE Data Eng.
ineering 1988, p 31-38). The above-mentioned known example proposes a curia specification when a user issues a search request to an OODBMS. Examples of cure are shown in FIGS. 8(a) and 8(b).

The cure example in Figure 8 is based on the class hierarchy in Figure 9, and Figure 9 is a vehicle! 101
, Manufacturer (Company) 902, Vehicle body (Auto
body) 903, engine department (Autodriver)
ain) 904, Division (Division) 905
, Employee 906. FIG. 8(a) shows the rFord Motor
Search for all blue cars manufactured by the Company"
This shows an example of the expression format of a search request when searching. Names with colons (:) are variables, indicating that conditions are applied to each car instance existing in the car class. Manufacturer Name Requirements Related Manufacturer
Specified through.

FIG. 8(b) shows the case of ``searching for a manufacturer that has at least one research department,'' and the determination is made based on whether the purpose of any department in the manufacturer is "Re5search."

Basically, a search request to a database is made by specifying a class in which a search target exists and specifying search conditions for instances existing in that class, as in conventional database searches. Also, in searches using aggregated relationships, the path to follow the relationships (path:
It is necessary to specify a related name to clearly specify the path).

[Problem to be solved by the invention]

In the case of document management systems such as OA systems and CAD systems, data is frequently reused. For example, a diagram from a certain document may be attached to a document, or internal materials used in another product may be used in the next product. Such relationships are expressed on the database by associating instances corresponding to diagrams and internal materials with instances of materials and products in an aggregation relationship.

For example, assume that papers 11 and books 12 are managed in a hierarchical relationship as shown in FIG. In this example, the header section 13, the main text 14, and the reference document 15 are shared. In a system having such a hierarchical relationship, for example, even if an attempt is made to search for a document containing a certain diagram or a certain graph, it may not be possible to determine whether this document is a paper or a book. In current OODBMS, as in conventional DBMS, when making a search request, it is necessary to specify the class in which the instance to be searched exists;
It was also necessary to specify the path that follows the class hierarchy.

The inventors of the present application believe that specifying association groups requires the user to be aware of the relationships between classes, which increases the burden on the user. Patent application Hei 1-1 for a search method to trace
No. 35861 [Database search processing method] (hereinafter referred to as
(referred to as a first-filed invention).

Although the burden associated with specifying the path specification described above can be solved by adopting the method of the invention of the earlier application, the problem of burden due to class specification has not been solved.

Therefore, the user had to issue a search request for each class, such as the paper class and the book class. This results in an increased burden on the user and increased processing time.

In view of the above problems, an object of the present invention is to manage relationships between data in an OODBMS, accept a request from a user to search for an instance of any class related to a specified instance (group), and manage relationships between instances. The objective is to provide a user-friendly interface for data retrieval by searching for instances of all classes that are related to each other.

[Means to solve the problem]

In order to achieve the above object, the present invention maintains relationships between user-defined classes and instances as class definition information and instance-related definition information, and allows user searches and
In an object-oriented database management system that searches a database in response to a request while referring to the class definition information and instance-related definition information to find instances (groups) of a class specified by the user that satisfy conditions specified by the user. , when a search request is received from a user to search for all instances related to the instance specified as one condition, with the class of the instance to be searched being undefined, the above condition is met based on the instance related definition information. The present invention is characterized in that instances (groups) having a certain specific relationship with a specified instance are searched for, and these instances (groups) are processed as search results. Incidentally, as the above-mentioned "certain specific" relation, a relation constituting a composite object may be used. Further, when a plurality of instances are specified as a condition, the instance group held as a component of the instance group entry composite object may be used as the search result.

[Effect]

In the present invention, before making a database operation request, a user using an object-oriented database management system (OODBMS) defines attributes of instances targeted for the database and relationship definition information between instances to the OODBMS in advance. I'll keep it. The relationship definition information between instances includes a relationship identifier for identifying a relationship between instances, a type identifier of the relationship, and a class identifier to which a related target instance of the relationship belongs. OOD
Upon acquiring the related definition information, the BMS registers it in the database. Furthermore, when a user registers an instance in the database, the OODBMS simultaneously extracts the relationship between the instances and registers it in the database as related entity information. Associations between instances, as well as values for other attributes, are provided by the user. Furthermore, when the user changes the relationship between instances, the related entity information is maintained.

A database search request given from the user to the 000BMS has the format shown in FIGS. 9(a) and 9(b), for example. O
When an ODBMS receives a search request from a user, it analyzes the search request, searches the database for instances of the class specified as the search target, evaluates the conditions specified in the search conditions, and finds those that satisfy the conditions. Select as search result.

In the present invention, when performing a search using the relationship between instances, the following specification is made, for example.

(any 5elect : V (: V 1ncl
(ude instance specification)) Here, any indicates a search request for an instance of any class.

1nclude is a condition that uses an aggregation relationship to search for a composite object that holds all instances specified in the instance specification as constituent elements. This function is detailed in the specification of the above-mentioned prior invention. In the instance specification, specify something that identifies the instance. The instance can be identified by an object identifier assigned by the system or by a curie. Further, an example of specifying a condition using the relationship when looking at the aggregation relationship in the opposite direction is as follows.

(any 5elect : V (: V 1ncl
udedJy instance specification)) The includeJby condition searches for constituent objects that all composite objects specified in the instance specification hold as constituent elements. Regarding this condition as well,
This is shown in the specification of the prior invention.

When the 000BMS receives the above search request, it first checks the class group to which the instance group given in the instance specification belongs and sets it as the start class group.

Next, in the case of the 1include condition, the aggregation related definition information between classes is examined, and all classes of the composite object that hold all the start class groups as component classes are extracted in the class hierarchy that constitutes the composite object. do. These are set in the termination class, and all paths from each start class to each termination class are extracted. After that, for each path determined here, from the related entity information, the related entities are sequentially traced starting from the instance given in the instance specification,
Finally, select an instance of the terminator class. For a certain termination class, a group of instances of that termination class are selected for each instance specified in the instance specification. An instance that exists in common in each selected instance group becomes an instance of the desired composite object in the termination class. The set of instances found for each termination class is the final result.

On the other hand, in the case of the 1includedJy condition, the aggregation relation definition information between classes is examined, and in the class hierarchy that constitutes the composite object, all classes in which the composite objects of the start class group can have a common element instance are extracted. These are set as termination classes, and all paths from each start class to each termination class are determined. For a certain termination class, a group of instances of that termination class are selected for each instance specified in the instance specification. An instance that exists in common in each selected instance group becomes an instance of the desired element instance in the termination class. The final result is a set of element instances found for each termination class.

As described above, when the operation target data is given as a condition for the relationship (given in the relationship type specification part) with known data (given in the related instance specification part), and when the search target class is undefined, Also, the relevant information is used to identify the data to be manipulated.

〔Example〕

An embodiment of the present invention will be described below with reference to the drawings.

FIG. 2 is a diagram showing the minimum equipment configuration for implementing the present invention. 0008MS50 described later, user program 3
0. and the terminal interface 20 run on the computer 60. The secondary storage devices 61A and 61B store data and files used by the database 40 and each program. The terminal 10 is used when a terminal user uses the 000BMS 50 or starts the user program 30 via the terminal interface 2o.

FIG. 1 is a functional configuration diagram of an object-oriented database management system according to the present invention. The user uses terminal 10
and requests the 000BMS 50 to process via the terminal interface 20 or the user program 30. 0
When the 00BMS 50 receives a database operation request from a user, the request control unit 55 distributes processing depending on the content of the request. In the case of instance operations such as searching and updating instances, the request is passed to the operation request processing unit 52. In the case of class operations such as class definition and definition change, a request is passed to the definition management section 51. When the operation request processing unit 52 receives an instance operation request from a user, it analyzes the request and issues a search request to the operation target search unit 53 for a group of instances to be operated. The operation target search unit 53 is
The search request is analyzed, and a group of operation target instances that satisfy the conditions specified in the search request are searched from the database 40, loaded into the main memory of the computer 60, and passed to the operation request processing section 52. The operation request processing unit 52 performs the operation (search) requested for the operation target instance.

(update, etc.), control is passed to the operation processing execution unit 54. The operation processing execution unit 54 performs the requested operation on the loaded instance group, and reflects the operation result in the database 40 if necessary.

In general, a user who uses 00DBMS 50 defines the attributes of the target instance of the database in advance for 0008MS 50 before making a database operation request. The same applies to relation definition information between instances.

FIG. 3 illustrates an example of a class hierarchy expressed by relationship definitions between instances.

Ellipses 70A to 70Y in the figure represent classes. Labels A to Y within the ellipse indicate class identification names. The arrow from ellipse to ellipse indicates the relationship held by the instance of the class at the start point of the arrow, and indicates that the instance of the class at the end point of the arrow is the target of the relationship. Different line types of arrows indicate different types of relationships. Labels rreQ-iJ beside the arrows are associated identification names of the respective relationships.

FIG. 4 shows a definition statement 80 of relation definition information between instances.
An example of this is shown for class X in FIG. The related definition information 80 includes a class name 81 and a class part (c
lass part) 82, and instance part (jn
(stance part) 83.

Each row ((1) to (4)) of the relation term in the 1stance part corresponds to each arrow starting from class X in FIG. 6, and defines an individual relation.

Each relationship is defined by a relationship identification name 83A, a relationship type identification name 83B, and a class identification name 83C of the target instance of the relationship. Since the definitions for other classes are similar, they are omitted here.

The type of relationship is 00DBM along with the associated functions.
Provided by S50. Users use different relationships depending on their functions.

In this embodiment, the association of the association identifier "has-parts" which defines an aggregate relationship between instances, and the association of the association identifier "reference" which defines a general reference relationship between instances are provided. .

In addition to these associations, the 00DBMS 50 may provide any association that is meaningful to the user.

Furthermore, a plurality of these relationships (the types of relationships may be the same or different) can be defined between arbitrary classes including the class itself.

When the definition management unit 51 in FIG. 1 receives the definition sentence 80 of related definition information as shown in FIG. and registers it in the database 40 as related definition information. An example of the related definition information holding table 85 is shown in FIG.

86 is the class identification name, 87A-87C is 83A-83C
It is an identification name corresponding to .

The operation processing execution unit 54 stores the instance in the database 4.
0, the relationships between instances are extracted and registered in the database 40 as related entity information. Relationships between instances, like the values of other attributes defined for instances, are created or updated when an instance is created or updated.
given by the user.

FIG. 6 is a diagram showing specific contents of related entity information. In this example, the related entity information is composed of an instance table 90 that manages instances and their belonging classes, and an instance related table 91 that manages relationships held by instances for each related identifier. Each row of the instance relationship table 91 represents the entity of the relationship between the - group of instances.

In this embodiment, data is stored in a table format like a relational database for ease of understanding. These data may be stored in a network by linking them with pointers. In that case, it would be possible to save resources and search processing time.

However, the overhead of update processing time increases.

Next, the processing procedure of the operation target search unit 53 when a search request using the aggregation relationship between instances realized by the present invention is received will be shown using FIG. As an example, assume the following two search requests Ql and Q2.

(X 5elect : V(: V 1include
s objj)) -Q 1(any 5elec
t: V(: V 1includes objj))
-Q 2 Both are search requests for a complex object that has instance objj as an element instance, but search request Q1 clearly specifies class X of the complex object sought as before. On the other hand, for search request Q2,
The arbitrary class specification any is specified.

The operation target search unit 53 processes these search requests in the following procedure.

(1) Check the class to which the instance specified in the instance specification belongs and set it as the start class (step 121). In this example, objj belongs to class Y
becomes the starting class.

If multiple instances are specified, the class to which each instance belongs becomes the start class.

(2) Different processes are performed depending on whether a termination class is specified (step 122).

(2,1) In the case where the termination class is specified (for example, in the case of Ql): In this case, the following ■
～■Proceed according to the procedure.

■ The class designated as the search target is set as the terminating class (step 128). In the case of Q1 above, set X.

■ Search all paths from the start class to the end class (step 129). For this search, an association matrix such as that shown in the prior invention may be used, or the class hierarchy may be simply traced using the association definition information shown in FIG. In the case of Ql, the start class is class Y, the end class is class X, and two paths are found: path 1: class Y → class C → class path 2: class Y → class D → class.

■ Search for an instance of the terminator class via the searched path for each specified instance (step 130).

In the case of Ql, the general form of the path from the start class Y to the end class X is Y-)C1→C2→...→C
n→X.

(C1, C2, . . . represent arbitrary class identification names.

) From the instance association table of the related entity information, extract the set 51 (Sl:sll, s12.-) of instances of class C1 that are related to the given related instance objj, and further extract this instance S11゜s12. A set 52 (S2:s21.s22...) of instances of class C2 that has a relationship with... is extracted. In this way, the instances snl, sn2 . A set XI (Xi
: xll, x12...) is determined. Similarly,
For other paths as well, sets (X2), (X3), . . . (Xm) consisting of instances of termination class X are obtained. Finally, the instance that satisfies the given condition is obtained by (XI)n (X2)1''l=n (Xm).The instance that satisfies the condition that is actually obtained according to the above is objj. be.

■ Take the logical product of the search instance group for each specified instance (step 131).

If a plurality of instances are specified in the instance specification, the desired instance group can be obtained by carrying out the above process (1) for each instance and then taking the AND of each search instance group.

(2°2) When no termination class is specified (for example, in the case of Q2): This is a newly added procedure in the present invention, and the following steps 1 to 2 are executed.

■ Searching for and setting a termination class (step 123). Searching for a termination class may also be performed using the association matrix as shown in the prior invention, or simply using the association definition information shown in FIG. You can also use to trace the class hierarchy. All classes located above the class hierarchy become terminating classes. For example Q1, o
Upper class of class Y to which bjj belongs, X, A, C, D
are all terminal classes. Note that when multiple instances are specified in the instance specification, the portion shared by each class hierarchy in the class hierarchy of the class to which each instance belongs becomes the terminating class. For example, in the class hierarchy shown in FIG. 5, if instances of class C and class D are specified, X and A become the terminating classes.

■ For each termination class, search all paths from the start class to the termination class (step 124).

For each terminator class, the above (2, 1) ■
(Step 124) is performed. In addition, in the above-mentioned process (1) (Step 123), a termination class is searched for while tracing the class hierarchy. This process (step 124) can be omitted by retaining the intermediate progress, that is, the path, while tracing the class hierarchy.

■ Search for instances of the termination class via the searched path for each specified instance of each termination class (step 125). For each specified instance of each terminator class, the above (2, 1
) ■ (Step 130) is performed. Here, the hierarchical relationship of the terminus classes is utilized, and the search results of the lower terminus classes are used to search for the higher terminus classes.

■ Perform the logical product of the search instance group for each designated instance for each terminator class (step 126)
. The process of (2, 1) (step 131) is performed for each termination class.

■ Calculate the logical OR of the instances that have been logically ANDed for each termination class. The instance group obtained as a result of the process (2) above is all the desired results. Therefore, a logical OR is performed on the instance groups resulting from the search for each terminator class.

The above processing procedure is a processing procedure when the 1ncludes condition is specified. Furthermore, when multiple instances are specified, the process assumes the all specification in the prior invention.

In the prior invention, a some specification is provided in order to specify a plurality of instances and search for one that satisfies the condition for any one of the instances. If some is specified,
In the above processing procedure, step 126 and step 13
The process in step 1 is changed to a process of calculating a logical sum instead of a logical product. Also, 1nclude to search for element instances
In the case of the d-by condition, in the above processing procedure, the processing in steps 123 and 124 changes from a search toward the upper level of the aggregation relationship to a search toward the lower level.

As described above, by allowing the user to arbitrarily specify the class to be searched, it is possible to search the database without the user being aware of the class hierarchy.

Note that in the above embodiment, all classes on the class hierarchy are targeted in the arbitrarily specified search.

Therefore, there is a problem that the processing time increases and a large amount of data that is unnecessary for the user is searched.

The following method can be considered to avoid this.

One is to limit the search range of the class hierarchy on the system side. If only one instance is specified, only the classes above and below the class to which the instance belongs are searched. For example, 1nclude
If an instance of class Y in FIG. 3 is specified in the s condition, only class C9D is set as the search range. When multiple instances are specified, once the termination class to which the relevant instance group belongs is found, classes higher and lower than that class are not included in the termination class. For example, under the 1ncludes condition, C2 in Figure 5
If an instance of class D is specified, class A
, Once X is found, the search range is not expanded even if there is a higher class.

〔Effect of the invention〕

As explained above, according to the present invention, in the OODI3MS, even if the class to which the operation target instance belongs is unknown, if a relationship with a known instance is specified as a condition, the OODBMS recognizes the relationship and Since instances can be specified, the burden on users for specifying data to be manipulated can be significantly reduced in databases that target data with complex structures, and an easy-to-use user interface can be provided.

[Brief explanation of the drawing]

Fig. 1 is a diagram showing the functional configuration of an object-oriented database management system according to the present invention, Fig. 2 is a diagram showing the minimum equipment configuration for implementing the present invention, and Fig. 3 is a diagram showing relation definition information between instances in the database. Figure 4 is the third
FIG. 5 is a diagram showing an example of the format for holding the related definition information of the class hierarchy shown in FIG. 3, and FIG. 6 is a diagram showing the related entity. A diagram showing an example of information, FIG. 7, is a flowchart showing the operation of the operation target search unit 53 in the OODBMS 50 of FIG.
a) and (b) are diagrams showing an example of conventional search elements for OODBMS, Figure 9 is a diagram showing an example of the class hierarchy on which the search request example in Figure 8 is based, and Figure 10 is a database FIG. 2 is a diagram for explaining the hierarchical relationship of instances in FIG. DESCRIPTION OF SYMBOLS 10... Terminal used by a terminal user, 20... Interface program for terminal users, 30... User program, 40... Database, 50...00
DBMS, 51, 52, 53, 54, 55... Definition management section, operation request processing section, operation target search section, operation processing execution section, request control diagram, and the ninth port of the diagram order diagram, which respectively constitute the OODBMS 50. Risenka 3 Sen (ku) (su) Tea picture

Claims (1)

[Claims] 1. The relationships between classes and instances defined by the user are held as class definition information and instance-related definition information, and the class definition information and instance-related definition information are stored in response to a user's search request. In an object-oriented database management system that searches a database while referencing and searches for instances (groups) of a class specified by the user that satisfy conditions specified by the user, the class of the instance to be searched is specified by the user as unspecified, and the When a search request to search for all instances related to the specified instance(s) is received, based on the instance-related definition information, the instance(s) specified in the conditions of the search request and a certain A database search processing method characterized by searching for instances (groups) with specific relationships. 2. It is characterized by using an aggregation relationship as the specific relationship used at the time of search, and searching for a composite object that holds all the instances (groups) specified in the conditions of the search request as constituent objects. A database search processing method according to claim 1. 3. As the specific relationship used at the time of search, an aggregation relationship is used to search for configuration objects that are held as configuration objects by all instances (groups) specified in the conditions of the search request. A database search processing method according to claim 1.