KR100426620B1 - Method of an class instance updating with OID in the main memory resident, object-relational DBMS - Google Patents

Abstract

The present invention relates to a method of changing a class instance including a set of object identifiers and a computer-readable recording medium recording a program for realizing the method. The relationship between classes is stored as a set of object identifiers (OIDs). In the case of changing instances between classes, the client may provide a method of changing a class instance including a set of object identifiers to ensure database consistency, and a computer-readable recording medium recording a program for implementing the method. A first step of analyzing the requested query and confirming whether the query is an instance update query; A second step of obtaining mutual exclusion locks on a class and a subclass inherited from the class of the change query analyzed according to the change query; And a third step of changing an instance according to a result obtained by the mutual exclusion lock, changing the instance, and storing the changed result to the client, the main memory resident object relational database management system (DBMS). Used for server.

Description

Method of an class instance updating with OID in the main memory resident, object-relational DBMS}

The present invention relates to a class instance change technique including a set of object identifiers (OIDs), which is one of the fields of query processing in a main memory resident object relational database management system (DBMS). When changing instances between classes that have ever (1: 1, 1: N ;, N: M) interrelationships, and how to change the class instance with a set of object identifiers to ensure database consistency The present invention relates to a computer-readable recording medium having recorded thereon a program.

Existing object-relational databases refer to a set of objects stored in multiple databases, and associate an object identifier that can uniquely identify an object in order to associate each object related to tables belonging to multiple databases to those tables. I use it. Therefore, tables have a table identifier so that each table can be uniquely identified, and thus, a table mapping and a reference to an object can be generated to map the table to the corresponding table. This reference contains the object containing the object identifier and the identifier of the table to which the object belongs. That is, objects are located based on table mappings and references to objects.

In other words, in the past, objects which are duplicated in several tables as object identifiers can be used to save data storage and enable efficient object references.However, object identifiers can be used to interact with instances of other classes that are interrelated. There are no registered patents for changing the relationship.

In addition, in the past, a view is created from an object relational database and tables stored in a relational database, and a view for representing and changing data through the view is included in one or more relational tables or object tables. You could define a view based on tables, and read data from multiple tables and represent them as a set of objects. In this case, columns may be defined in tables including values for creating object identifiers, and triggers may be defined in views. A column object is a column of attributes that contains user-defined object types, collection objects (nested tables or arrays of variables), or references to objects.

However, in the related art, the advantages of the object relational database can be obtained by accessing the data through the view to which the object relational characteristics are applied while using the relational database as it is. It does not provide.

The present invention has been proposed to solve the above-mentioned problems, and an object for guaranteeing the consistency of a database when a relationship between classes changes an instance between classes stored as a set of object identifiers (OIDs). It is an object of the present invention to provide a method of changing a class instance including an identifier set and a computer-readable recording medium having recorded thereon a program for realizing the method.

That is, according to the present invention, when a database change command transmitted from a data access application (client) is a change to a class related to another class, the present invention blocks other access to the class itself and all classes inherited therefrom. A set of object identifiers is then used to modify the instance that satisfies the condition, allowing the object identifiers (OID) pointers that represent the relationship within the instance of itself and all classes inherited from it and any other classes that interrelate with them. It is an object of the present invention to provide a computer-readable recording medium that records the included class instance changing method and a program for realizing the method.

1 is a configuration example showing a relationship between a main memory device resident DBMS server and a data access application to which the present invention is applied.

2A and 2B are examples of vertical interrelationships between classes defined in a data access application program according to the present invention.

3A to 3C are exemplary views illustrating horizontal interrelationships between classes defined in a data access application program according to the present invention.

4 is a flowchart illustrating a method for changing a class instance including an object identifier set according to the present invention.

FIG. 5 is a flow diagram of an embodiment of the getLock () function call process of FIG.

6A through 6D are flowcharts of an embodiment of a process of calling the update () function of FIG. 4.

* Explanation of symbols for the main parts of the drawings

10: data access application 20: main memory resident DBMS server

30: object relational DBMS server 31: query parsing module

32: Query Execution Module 33: System Catalog Access Module

40: Main memory database

In order to achieve the above object, the present invention provides a method for changing a class instance including an object identifier (OID) set applied to a main memory resident object relational database management system (DBMS) server. A first step of confirming whether the query is an update; A second step of obtaining mutual exclusion locks on a class and a subclass inherited from the class of the changed query analyzed according to the change query; And a third step of changing an instance by finding an instance meeting a condition according to a result of the mutual exclusion lock, and storing and transmitting the changed result to the client. The present invention may further include a fourth step of repeating the third step with respect to subclasses inherited from the own class.

The present invention also relates to a main memory resident object relational database management system (DBMS) server having a processor, comprising: a first function of analyzing a query requested from a client and checking whether the query is an instance update query; A second function of obtaining a mutual exclusion lock on a class and a subclass inherited from the class in response to the change query analyzed according to the change query; And a computer-readable recording medium having recorded thereon a program for realizing a third function of changing an instance according to a result obtained by the mutual exclusion lock, changing the instance, and storing and transmitting the changed result to the client. to provide. The present invention also provides a computer-readable recording medium having recorded thereon a program for further realizing a fourth function of repeatedly performing the third function on subclasses inherited from the own class. To provide.

In the present invention, when a class instance change request is made from a data access application (client) to a main memory resident object relational DBMS server, a mutual exclusive lock is applied to the requested class, and an instance satisfying the condition is searched. If there is an object identifier (OID) pointer in the instance that is associated with another class in all of its instances, access the instance of the relevant relative class and find the inverse OID pointer that points to the class. In order to repeat the process of modifying OID pointers (OID instances) to the inherited classes after locking the mutual exclusion lock, it is necessary to correctly change the data between the interrelated classes to ensure database consistency. Characterized in that.

The above objects, features and advantages will become more apparent from the following detailed description taken in conjunction with the accompanying drawings. Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is an exemplary configuration diagram showing a relationship between a main memory resident object relational DBMS server and a data access application to which the present invention is applied, and includes a data access application 10 and a main memory resident DBMS server 20. The main memory resident DBMS server 20 includes an object relational DBMS server 30 and a main memory database 40.

As shown in FIG. 1, an object-relational DBMS server 30 is a module related to a part related to the present invention, and includes a query parsing module 31 and a query execution module 32. According to the access request of the main memory database 40 generated by the reference to the System Catalog Access Module (System Catalog Access Module) (33) performs a database search, change, or deletion.

2A and 2B are examples of vertical correlations between classes defined in a data access application program according to the present invention.

First, FIG. 2A illustrates a vertical relationship (inheritance) between classes as a diagram, and defines a vertical correlation (inheritance) between the object relational DBMS server 30 and a class as follows.

Any class can be inherited from only one class. In other words, the name and type of the attribute defined in the parent class can be inherited without changing, and it can have its own unique attribute. Multiple inheritance that inherits from multiple superclasses and creates subclasses is not possible.

Thus, class B 202 inherits from class A 201 and class C 203 inherits from class B 202.

In fact, referring to the class definition statement of FIG. 2B, class B includes an attribute (A_att1) 204 inherited from class A and an attribute (B_att1) 205 which is its class. In addition, class C includes an attribute (A_att1) 204 inherited from class A, an attribute (B_att1) 205 inherited from class B, and an attribute (C_att1) 206 defined in its class.

Therefore, a change query that modifies the value of attribute (A_att1) 204 in the top class A also applies to the attributes (A_att1) 204 of class B and class C.

3A to 3C illustrate an example of horizontal interrelationships between classes defined in a data access application program according to the present invention. In the object relational DBMS server of the present invention, three relationships are described as follows. Defined as

First, FIG. 3A illustrates a 1: 1 relationship between classes. Class A 301 and class W 302 have a 1: 1 relationship, and in class A 301, a class A_att2 303 is provided. Only one instance of W 302 is accessible, and in class W 302, only one instance of class A 301, pointing to its instance, is provided via an attribute called W_att2 304. That is, the attribute A_att2 303 of class A 301 has an object identifier (OID) 305 of one instance of class W 302, which serves to indicate that, and in class W 302, W_att2 An attribute named 304 has an object identifier (OID) 306 of only one instance of class A 301 that points to its instance and thus serves to point to it.

Therefore, when changing an instance of class A 301, the following Structured Query Language (SQL) supported by the object relational DBMS of the present invention is used.

exec sql update A set A_att2 = (OID of class W) where ...;

The query only assigns an object identifier (OID) of class W described in the 'set' clause to A_att2, and an object identifier (OID) of an instance of class A being changed is inserted into W_att2 of an instance of class W associated with it. Correlation is automatically maintained.

Second, FIG. 3B illustrates a 1: N relationship between classes. Class A 311 and class W 312 have a 1: N relationship, and in class A 311, a class A_att2 (313) is provided through an attribute. Multiple instances of W 312 can be accessed, and class W 312 can only access one instance of class A 311 that points to its instance through an attribute called W_att2 314. That is, an attribute named A_att2 313 of class A 311 has an object identifier (OID) 315 of several instances of class W 312, which serves to point to them, and W_att2 in class W 312. The attribute (314) has an object identifier (OID) 316 of only one instance of class A 311 that points to its instance and thus serves to point to it.

Therefore, when changing an instance of class A 311, the following Structured Query Language (SQL) supported by the object relational DBMS of the present invention is used.

exec sql update A set A_att2 = (OID of class W) where ...;

The query deletes all existing object identifier (OID) values of A_att2, assigns the object identifier (OID) of class W 312 described in the 'set' clause, and changes W_att2 of the instance of the assigned class W. The object identifier (OID) of the instance of class A being assigned is assigned and the correlation is automatically maintained.

exec sql update A set A_att2 + = (OID of class W) where ...;

The query adds the object identifier (OID) of class W described in the 'set' clause to the existing object identifier (OID) values of A_att2, and the instance of class A being changed in W_att2 of the added instance of class W. Object identifiers (OIDs) are assigned to maintain correlations automatically.

exec sql update set A_att2- = (OID of class W) where ...;

The query deletes the object identifier (OID) of class W described in the 'set' clause from the existing object identifier (OID) values of A_att2, and changes the instance of class A that is being changed to W_att2 of the deleted instance of class W. The object identifier (OID) is deleted so that the correlation is automatically maintained.

Third, FIG. 3C illustrates the M: N relationship between classes. Class A 321 and class W 322 have an M: N relationship. In class A 321, an A_att2 323 attribute is used to define a class. Multiple instances of W 322 can be accessed, and class W 322 can be accessed from multiple instances of class A 321 pointing to its own instance through an attribute called W_att2 324. That is, an attribute called A_att2 323 of class A 321 has an object identifier (OID) 325 of several instances of class W 322, which serves to point to them. In class W 322, W_att2 The attribute 324 has an object identifier (OID) 326 of several instances of class A 321 pointing to its instance and thus serves to point to it.

When changing an instance of class A 321, the following Structured Query Language (SQL) supported by the object relational DBMS of the present invention is used.

exec sql update A set A_att2 = (OID of class W) where ...;

The query deletes all existing OID values of A_att2, assigns the OID of class W described in the 'set' clause, and assigns the OID of the instance of class A being changed to W_att2 of the assigned instance of class W. Correlation is automatically maintained.

exec sql update A set A_att2 + = (OID of class W) where ...;

The query adds the OID of class W described in the 'set' section to the existing OID values of A_att2, and adds the OID of the instance of class A that is being changed to W_att2 of the added instance of class W. Is maintained.

exec sql update set A_att2- = (OID of class W) where ...;

The query deletes the OID of class W described in the 'set' clause from the existing O_values of A_att2 and deletes the OID of the instance of class A being changed in W_att2 of the deleted class W instance. Is maintained.

FIG. 4 is a flowchart illustrating a method of changing a class instance including a set of object identifiers according to the present invention, and is a process of processing in a DBMS server when an instance change query is requested from a data access application.

As shown in FIG. 4, when an instance change request is received from a data access application (401), the query is analyzed to store query information (402), and it is checked whether it is an update query (403). .

As a result of the check (403), the getLock () function is called (404) to request the mutual lock of the interrogation class. Subsequently, it is checked whether a mutual exclusion lock is obtained for the requested class (405), and if so, an instance matching the condition described in the query is searched for its own class and subclasses. Repeat the following operation (406). In other words, if you look at the repetitive task that works while the instance exists, the update () function is called with an instance OID that satisfies the condition (407) and the result is checked (408). Increments 1 by 409; if unsuccessful, withdraws the change query and exits the process of step 406. The result of the successful change for all instances satisfying the condition is stored (411), and if the mutual exclusion lock of the class is not obtained in step (404), the transaction is withdrawn (413). In operation 412, the process 412 transmits the stored data to the application program.

On the other hand, the result of checking whether the update (update) query (403), if the query is not a change query (414) after storing the result (411) and proceeds to the step (412) to send to the application program. .

FIG. 5 is a flowchart illustrating an example of a process of calling the getLock () function of FIG. 4, in which an input parameter (class A) is a class for which a mutual exclusion lock is to be obtained.

As shown in FIG. 5, when the function is started, a request for a lock on a class (501) is performed to check whether a lock is obtained (502), and when a lock is obtained, a subclass of the class is found (503). If the existence of the subclass exists, a mutual exclusion lock is requested to the subclass (505). If a lock is acquired (506), the next subclass is found (507), and the process of checking whether a subclass exists is repeated (504), and the lock is not obtained (502). If a lock is not obtained (506), the result is stored as a failure (508).

On the other hand, when both the input parameter class and its subclasses acquire the mutual exclusion lock and only do not exist, the result is stored as success (509) and returned to the called function.

6A through 6D are flowcharts of an embodiment of a process of calling the update () function of FIG. 4.

Here, the input parameter is the OID of the class instance to be changed, and this function is a function that actually changes the database contents by performing an update query.

As shown in Figs. 6A to 6D, when a function starts, iteratively 601 change clause information for all attributes having primitive data types that do not indicate a relation among attributes to be changed described in the change query. (Attribute name, type, operator, value, etc.) (602).

Subsequently, if there was no error in constructing change clause information for an attribute having a primitive data type, the content thereof was applied to the database (603), and then the data type representing the relation (1: 1 type and 1: N for the OID set). For all attributes of type), the operation is repeatedly performed as follows (604).

That is, the process of checking the attribute type (605) and dividing the attribute type into a 1: 1 relationship 606 and a 1: N relationship 607 is repeatedly performed.

As shown in FIG. 6B, if the attribute type is a 1: 1 relationship (606) The existing instance OID of the partner class currently pointed to by the instance OID of the class to be updated. (608) request a mutual exclusion lock for this (609). Subsequently, it is checked whether a lock is acquired (610). If the lock is not obtained, the result is stored as a failure (611). in Check the type of back pointer (OID instance) to (your class) (612).

If the test result 612, the type is 1: 1 Assigns "NULL_OID" to the inverse pointer of (613), and 1: N Of the set of inverse pointers Delete only (own class instance) (614).

after, The new OID described in the 'set' clause in the corresponding attribute of your own class instance (615). next, in To make an inverse pointer to Request a mutual exclusion lock from the server (616), Check if a lock has been acquired for (617), and if the lock is not obtained, store the result as a failure (618); in Check the pointer type in reverse (619).

Inspection result (619), If the inverse pointer type to 1: 1 is 1: 1 in To the station pointer of (620), and 1: N in During the set of inverse pointers to Add (621).

Since, successfully Wow If the pointer of is set, the result is stored as success (622) and the stored result is returned to the calling function (649).

As shown in FIG. 6C, if the attribute type is 1: N relationship (607), the operator of the 'set' clause is checked (623). First, if the operator is '=' which means the assignment, it means to replace the existing OIDs with the new OIDs described in the 'set' clause of the change query.If the operator is '+ =' which means the union, It means to add the OID described in the 'set' clause to the existing OID set. If the operator is '-=' which means the difference, only the OID described in the 'set' clause in the existing OID set. It means to delete.

Therefore, if the operator is '=' (allocation), it is necessary to find an existing OID, delete all, and allocate a new OID set. That is Set of all instance OIDs of the relative class pointed to by the class instance OID After saving to (624), The next operation is repeated as many times as the number of OIDs stored at 625.

That is, a set Apply for mutual exclusion lock for deletion by one element (OID) in (626), check if the lock is obtained (627), if the lock is not obtained, save the result as failure (628), if the lock is obtained in If the type is 1: 1 Assigns "NULL_OID" (an OID with a null value) to the inverse pointer of (630), and if the type is 1: N Of the set of inverse pointers Only delete (631). After successfully completing step 625, All in The pointer to the row is deleted (632).

Then, if you delete all existing OIDs for the '=' (assignment) operator, or if the operator is '+ =' (set) or '-=' (difference), the instance OIDs described in the 'set' clause Set Saved as (633) Repeat the following process (634) for all OIDs stored in the.

As shown in FIG. 6D, a set Looking closely at the process of repeating the number of OIDs stored in the (634), first check the operator of the 'set' clause (635), if the operator is '=' (assignment) or '+ =' (set) A new OID in the corresponding attribute OID set of Is assigned (636), and the operator is '-=' (difference) OID from the corresponding attribute OID set in It is deleted (637).

after, in In order to change the reverse pointer to the lo, a mutually exclusive lock is applied (638) to check if a lock has been acquired (639), and if the lock is not obtained, the result is stored as a failure (640), and if the lock is obtained in The type is checked to set an inverse pointer to the path (641).

Check result (641), if the type is 1: 1, check the operator in the 'set' clause (642) .If the operator is '=' (assignment) or '+ =' (set), On the station pointer Is assigned (643), and the operator is '-=' (difference) It allocates "NULL_OID" to the inverse pointer of 644.

On the other hand, if the result of the check 641, the type is 1: N, the operator of the 'set' clause is examined (645), if the operator is '=' (assignment) or '+ =' (set) On the station pointer (646), and if the operator is '-=' (difference) Among the inverse pointers of Delete (647).

Then, the same set as above After successfully completing the process of repeating the number of OIDs stored in step 634, the result is stored (648) and returned to the calling function (649).

The method of the present invention as described above may be implemented as a program and stored in a computer-readable recording medium (CD-ROM, RAM, ROM, floppy disk, hard disk, magneto-optical disk, etc.).

The present invention described above is not limited to the above-described embodiments and the accompanying drawings, and various substitutions, modifications, and changes are possible in the art without departing from the technical spirit of the present invention. It will be clear to those of ordinary knowledge.

As described above, the present invention applies to not only its own class but also subordinate classes inherited from itself when changing instances of the interrelationship between classes in the main memory-resident object relational DBMS. It also has the effect of ensuring database consistency by changing the relationship with instances of the class.

Claims (9)

delete delete delete delete A method of changing a class instance including a set of object identifiers (OIDs) applied to a main memory resident object relational database management system (DBMS) server, Analyzing a query requested from a client to determine whether the query is an instance update query; A second step of obtaining mutual exclusion locks on a class and a subclass inherited from the class of the change query analyzed according to the change query; A third step of changing an instance by searching for an instance meeting a condition according to a result of obtaining the mutual exclusion lock, and storing and transmitting the changed result to the client; And A fourth step of repeating the third step with respect to subclasses inherited from the own class; Including, The third step, A fifth step of repeatedly configuring change clause information for an attribute to be changed in order to search for an instance satisfying a condition for the own class and all subclasses thereof; A sixth step of storing the changed information about the attribute in a database, and A seventh step of changing instances of a class that has a correlation with its own class with respect to an instance satisfying the condition, in order to distinguish an attribute type representing a relationship among the attributes to be changed; Including, The change clause information, Method of changing class instance in main memory resident object relational DBMS characterized by attribute change information (name, type, operator, value) shown in set clause. The method of claim 5, wherein The seventh step, When the correlation between the classes is 1: 1, an assignment ("=") operation is performed to execute the own class instance ( An instance of a relative class that points to Delete its own class instance pointer, and add a new instance pointer ( Your own instance pointer () An eighth step of allocating; And When the interrelationship between the classes is 1: N, an assignment ("="), union ("+ ="), or difference ("-=") operation is performed to change the pointer according to the operator of the set clause. 9th Step A method of changing a class instance in a main memory resident object relational DBMS including a. The method of claim 6, The ninth step, If the operator of the set clause is an assignment ("="), then its class instance ( An existing set of instances of the other classes ( ) Deletes all pointers to the class instance of its own, and sets a new instance pointer ( ) And a new set of instances ( Above your own instance pointer ( A tenth step of allocating; If the operator of the set clause is a union ("+ ="), the class instance of its own ( Set of new instance pointers () ), And add a new set of instances ( Above your own instance pointer ( An eleventh step of allocating; And If the operator of the set clause is a difference ("-="), the class instance ( Set of existing instance pointers () ) And the instance set ( Above your own instance pointer ( 12th step to delete) A method of changing a class instance in a main memory resident object relational DBMS including a. delete delete