KR0127101B1 - Object-oriented database system - Google Patents

Abstract

A method for providing an object with persistence in the object-oriented data base system is provided in which a forced inheritance scheme is used to provide an object-oriented language such as C++ with independent persistence together with portability. The method adds forcedly attributes necessary for persisting the object in front of the object, objects other than the class type are capable of inheriting the attributes from the imaginary root class. Thereby permitting the independent persistence to the object without lost of portability, for there is no alteration of the object-oriented language.

Description

How to Provide Persistence to Objects in Object-Oriented Database Systems

1 is a diagram schematically illustrating a system configuration in which a forced inheritance method of the present invention is implemented.

2 is a flowchart illustrating steps according to an exemplary embodiment of the present invention for implementing a forced inheritance method.

3 is a diagram showing the structure of an object to which a header is added.

4 is a diagram showing the structure of an array object with a header added thereto;

* Explanation of symbols for main parts of the drawings

10: Computer 15: CPU

20: Memory 5: Application Resident Area

30: object-oriented database system resident area

35: disk (database)

The present invention relates to an object-oriented database system (L0DBNlS), which combines object-oriented language and database functions. In particular, the present invention relates to persistent C ++ languages that are widely used as object-oriented languages. It is about a method of forced inheitance to provide persistence.

Research on object-oriented database systems has evolved in two different areas of research. One is in the database field and the other in the programming language field. In the database field, research has been successfully conducted to support database support such as persistence, sharing, transaction, and authorization. Traditional database systems, on the other hand, have drawbacks such as weaknesses in the data model and the unnaturalness of the database language and host language combinations.

On the other hand, Smalltalk. Property inheritance in object-oriented languages such as C ++ and Objective-C. Data abstraction. Research into having a meaningful data model such as polymorphism has been successfully conducted. The results of this study can be used to compensate for the shortcomings of traditional database systems. Object-oriented languages, on the other hand, do not have database capabilities, which is a complement to traditional database system research.

The research on object-oriented database systems aims to build a unified database system that combines the object-oriented languages and database functions that have been developed in these two fields with all of their complementary advantages. Therefore, many object-oriented database systems that are currently developed have the form of combining existing object-oriented languages and database functions. Examples of such systems are GemStone, ODE, ObjectStore, VERSANT, ONTOS, and Objectivity / DB. GemStone combines the Smalltalk language and database functionality, while ODE, ObjectStone, VERSANT, ONTOS, and Objectivity / DB combine the C ++ language and database capabilities.

C ++, which is mainly used in the object-oriented data base system, has fundamental types such as int, char, and float, arrays, pointers, and structs. It has a type system in which a new type called class is added to a derived type such as a union. Unlike other types, a class can have not only attributes (or member variables) of objects defined as an instance of the class, but also functions (member functions) that perform operations on objects. You can inherit attributes from the defined class. Like the general programming language, the C ++ language creates objects that are created while the program is running. After the program ends, the storage space is dismantled and the objects do not persist. However, in an object-oriented database system, a function of allowing an object to persist even after the end of a program by automatically storing the object in a database during or after execution of a program written in an object-oriented language is finished.

A method of giving persistence to a language must meet the following requirements. First, you must provide independent persistence or orthogonal persistence. Independent persistence is defined by the nature that all objects can be persisted, regardless of type. In languages with no independent persistence, there are types that can be persisted (persistent types) and types that cannot be persisted (volatile types). Whenever a programmer wants to persist an object of volatile type, the object is persisted. The drawback is that it involves programming overhead as it simulates. Thus, independent persistence is an important property that persistent language must have.

Second, there must be portablity. There may be portability in two aspects. One is that a system that provides persistence as a system's portability should not depend on specific hardware or operating systems. The other is that the portability of programs is that programs written in persistent languages should not rely on specific compilers.

Currently, there are two main ways to combine C ++ with database functionality. One is the Class Library Binding, and the other is the Data Manipulation Language Bibding, each of which adds persistence to C ++ in different ways. Class library binding is a way to use database functionality through a run-time library that contains classes and functions defined in C ++. Class library binding versions of VERSANT, ONTOS, and ObjectStore Objectivity / DB is an example of a system that uses class library bindings. DML binding, on the other hand, is a way to use database functionality through a proprietary language that extends the syntax of C ++ itself. Here, applications are written in an extended language and compiled by their own compilers. The DML binding versions of ODE and ObjectStore are examples of systems that use DML binding.

Currently, most class library bindings take advantage of C ++ 's inheritance of class attributes. In other words, you define a persistent class as the root class and provide persistence only for objects of its subclasses. For example, VERSANT has a persistent root class called 'PObject, and ONTOS is Object. Atwood defined the method of using the root class while belonging to the class library binding as a method of providing persistence from a Virtual Base C1ass (PfVBC). This is referred to simply as the Base Class method.

In general, to give a language persistence, there must be a generic function that stores objects of any persistence type in the database at runtime. Without this, the programmer would have to write code to store the object for each type. This function is defined as a persistence function. In addition, information for storing each object in the persistence function must be provided at run time. This information includes type information and size information. Information about types is needed so that objects can be used as objects of the correct type when they are saved and used again. Information about the size is used to allocate storage space for storing objects.

To give persistence to C ++, you need to keep this information per object at run time. The C ++ compiler preserves information about objects used in a program only at compile time and provides a limited amount at run time. That is, type information is not valid at run time and information about the size of an object is passed as a media parameter to the new operator function, a function that is called when the object is formed in the program. It doesn't work. One way to ensure that this information is provided at run time for each object is to have each object have separate properties for storing them. These attributes are defined as persistence attributes. In summary, the way to give persistence to C ++ is to make sure that all objects you want to persist are passed through persistence properties, and that the persistence function references them.

The base class method uses C ++ 's class attribute inheritance feature to allow objects to have persistent attributes. That is, you define persistent attributes as attributes of the root class (member variables) so that the persistence class inherits them so that the object maintains them at run time. Similarly, you define a persistence function as a member function of the root class so that the persistence class can inherit it and refer to the persistence properties that exist in the object.

Since the base class method does not extend C ++, applications use the normal C ++ language as it is, so they are not dependent on a specific compiler and are portable, but do not provide independent persistence. That is, only objects of class inherit the persistence, so objects of basic or array type that cannot inherit properties cannot be persisted. To have the same effect as persisting this type of object, the programmer must define a persistence class that mimics a volatile type. Element below shows an example of defining an element array that is a persistent class that mimics an array of classes. Here pObject is assumed to be a persistent root class.

1: ch1ss ElementArray: public pObject

2 : {

3: int numelem:

4: public:

5: Element e [1]:

6: ElementArray (int num) {

7: Allocate variable sized storage to hole 'num' elements;

8: for (int i = o; i <num; i ++) construct e [i];

9: numelem = num ,;

10:}

1l:-ElementArray () {

12: for (int i = 0; inumelem; i + +) destruct e [i];

13:}

14:}

Here the programmer must do the following: First, line 1 declares ElementArray as a subclass of pObject. This allows this class to be persistent. Second, declare a variable to store the elements of the array. Since C ++ does not allow the declaration of variable length arrays, set the size of the array to 1 (e [1] on line 5) to make it appear to be a fixed length variable at compile time and to use it as a variable length at run time. This is possible because C ++ doesn't check the area of an array at run time when you use it. Third, you must implement a constructor (lines 6 through 10) that allocates the object's storage space to fit the size and calls the constructor for the elements of the array. If you don't implement this, when you create an object of the ElementArray class, the object's storage is always allocated with a fixed size. For the second element (e [2]) or the third element (e [3]) that are not actually declared in the class, The constructor will not be called and you will not be able to simulate an array of variable length.

Fourth, we need to define a destructor that destroys the elements of the array when the object is destroyed (lines 11 through 13) and a variable that represents the number of elements (numelem in line 3). The destructor must check the number of elements and destroy that many objects. If you don't define them, you won't be called a destructor for elements that aren't declared in the class as before.

As mentioned above, when a programmer simulates a volatile type as a persistent class, there is a lot of work and complexity to do. In addition, if there are multiple volatile types, the programmer must implement a persistence class that mimics each type, resulting in a lot of error and programming overhead.

In addition, there is a performance penalty in referencing array elements of the ElementArray class. To reference an array element, you must index the array. In C ++, indexing an array may require using a pointer to the first element of the array. However, the pointer to the object of the ElementArray class does not point to the first element of the array, e [0], but rather to the first element of the superclass pObject class. 0] adds as much as the offset where the member is located.

In addition to the base class method, the object library binding version of the ObjectStore provides persistence using the virtual memory capabilities of the CPU and operating system. The ObjectStore uses the capabilities of the operating system to adjust the CPU's virtual memory mapping table so that the disk space occupied by the database is considered part of the virtual memory space used by the program. Thus, objects in pages that exist in memory are stored and read in memory. However, this method has the disadvantage of losing portability since it depends on the hardware or the function of the operating system.

Next, the DML binding adds a new keyword to C's syntax, which means that an object is stored in the database regardless of its type. For example, the OML language of the DML-bound version of the ObjectStore has a syntax that adds a new keyword, persistent, corresponding to auto, static, register, etc., which specifies the kind of storage class in C ++. The value of a defined variable is stored in the database regardless of its type. Also, ATT's O ++ language has a new keyword pnew, which is equivalent to the new operator for creating objects in C ++. Objects created using this keyword are stored in the database regardless of their type.

The DML binding method guarantees independent persistence by providing persistence regardless of the type of objects, but extends the C ++ language itself, making applications dependent on their own compilers, making them less portable. In addition, these programs will not be able to use their functions even if a new version of the C ++ compiler is released, which is a hassle to change the compiler as the C ++ compiler is upgraded.

The present invention provides a forced inheritance for granting object persistence to an object-oriented language, in particular C ++, to overcome the shortcomings of the above methods for imparting persistence to an object-oriented language in a database system combining object-oriented language and database functionality. It aims to provide a new way of inheritance.

In the present invention, by adding a header containing an attribute for persisting an object to the object, an object of a type other than a class has an effect such as inheriting such an attribute from a virtual persistent root class.

Hereinafter, the present invention will be described in detail with reference to the accompanying drawings.

1 schematically illustrates a system configuration in which a forced inheritance method of the present invention is implemented.

2 shows the steps of persisting objects created during execution of the application 25 using forced inheritance in one embodiment of the object oriented database system 30 implemented in accordance with the method of the present invention. The procedure is described in detail with reference to FIG. 2 as follows.

First, when the application program 25 is started, it requests the object-oriented database system 30 to open the database in step 100 and then the program is executed in step 110. If there is a request to create an object in step 120 while the application 25 is running, if it is a request to create a persistent object, then the object-oriented database system creates an object that is half the forced inheritance according to steps 140, 150, and 160; Returns a pointer to the object. On the other hand, if this is a request for creation of a generic C ++ object, then according to Danke 170, the object oriented database system creates a generic C ++ object and returns a pointer value to that object. If there is no object creation request in step 120, the process proceeds to step 80.

In more detail with respect to the steps 140, 150 and 160, which are the steps in which the forced inheritance of the present invention is implemented, first, in step 140, as much storage space as the sum of the size of the header including the object and the attributes necessary for the object to persist, It allocates to the memory 20. 3 shows the shape of the object to which the header is added, and the hatched portion represents the header. As shown in FIG. 3, the header may include an object identifier (ID), information about the size and type of the object. The identifier of the object is used as an index to have a storage space in the database 35 in which the object is stored, and the size and type of the object read the object into a storage space in the computer 10, that is, a memory, or a database ( 35) is used for storage. Next, in step 150, the header object of the object is recorded so that the object can be stored later. In step 160, as shown in FIG. Fix it as much as possible and return its value. The application 25 can then do the same as it would for a normal C ++ object when accepting an operation on an object.

Next, if the request for closing the database is made in step 180 before the application 25 terminates, the process proceeds to step 190 where the object-oriented database system references the information recorded in the headers of the persistent objects. The objects are stored in the storage space in (35). If there is no database close request, the process returns to step 110 to continue executing the application program 25.

The application program requires the creation of persistent objects in the object-oriented database system 30 using the following operations.

DB_new (Type)

This operation is provided by the object-oriented database system 30, and creates an object having a type as a type with a header, and returns a memory address of the object like the general new operator. In fact, this operation is defined by a macro as shown below and calls the newly defined new operator function.

#define DB_new (Type) new (ID (Type)) Type

Here, ID (Type) is a macro that returns a type name as a type number.

The newly defined new operator function performs steps 140, 150, and 160 of FIG. 2, which is a part of implementing forced inheritance. For example, the new operator function is source coded as follows.

1: void operator new

2: size _- t size,

3: int type

4 : )

5: {

6: OID id;

7: OBJ _- Header pHead;

8: pHead = Alloc (size + sizeof (OBJ ₋ Header), id);

9: pHead-size = size;

10: pHead-id = id;

11: pHead-type ID = type;

12: return (void) (char) pHead + sizeof (OBJ _- Header);

13:}

In the eighth line of the source code, as much storage space as the sum of the sizes of the object and the header of the object is allocated to the memory and an identifier of the object and a pointer to the allocated memory are returned. In the ninth to the eleventh lines, information for persisting the object is recorded in the attribute of the header. In addition, in the twelfth line, the pointer is adjusted to return the object.

As such, the forced inheritance method of the present invention has various advantages over the conventional method. First, it provides independent persistence. This is because headers can be added not only to objects of the class but also to objects of non-class types, and because the headers are always located at the front of the object, so the persistence function can refer to the heady regardless of the object's type. . Thus, this method has the advantages of both the base class method and the DML binding method. This eliminates the programming overhead incurred by the base class method due to independent persistence, and is portable because it does not extend the language unlike the DM'L binding method.

Next, when you refer to an object in your program, you do not use the address where the object's header is located, but instead use the address where the object is located, as the pointer in Figure 3 points to, so you can make persistence transparent to C ++. have. That is, programmers refer to objects with pointers that point directly to persistent objects, so they can handle persistent objects just like C ++ objects without being aware of the existence of headers.

In addition, when dealing with array objects, there is no waste of storage space and deterioration of indexing performance. Persistence attributes for array objects are not duplicated by the number of elements, but only one at the beginning for the entire array, as shown in Figure 4, saving memory space. When indexing array objects, unlike the base class method, the pointer points directly to the first element of the array, so performance is the same as when indexing regular C ++ arrays.

In the present specification, for convenience, C ++ is described as an example of an object-oriented language, but the present invention is provided by a person having ordinary skill in the art as is or without slight change without departing from the spirit or essential features of the present invention. It may be implemented in other specific forms or applied to other programming languages. Accordingly, the above-described embodiments of the present invention are illustrative in all respects and should not be construed as limiting, the scope of the invention being defined by the appended claims rather than the foregoing description.

Claims (4)

A method for providing persistence for an object defined as a type that inherits attributes or a type that does not inherit attributes in an object-oriented database system, the method enforces one or more selected attributes at the beginning of the object. By adding to the object of the type that can not inherit the attribute to provide a persistence forcibly inherit the attribute so that both types of object can be persisted. The method of claim 1, wherein the attribute includes an identifier of an object, size and type information of the object. A method of providing persistence for an object of a type defined by an object-oriented language in an object-oriented database system, the method comprising: a memory of storage space equal to the size of the object and a header including attributes required for the object to be persisted Assigning to the object, recording upper persistence information for persisting the object in the header of the object, and arranging a pointer to the object to point to an address where the object is located. A method of providing persistence characterized by forcibly inheriting an attribute. 4. The method of claim 3, wherein the attribute includes an identifier of the object, size and type information of the object.