JP3630697B2 - Data management system and method - Google Patents

Description

[0001]
[Industrial application fields]
The present invention relates to a method for managing a database application that uses data having a complicated structure.
[0002]
In particular, the present invention relates to a method for sharing data without contradiction in an application in which persistent data existing in a database and temporary data existing only in an application are intertwined with each other in a complicated relationship, such as multimedia data processing. .
[0003]
[Prior art]
In general, in a database application, a persistent object (hereinafter referred to as a persistent object) that is placed on the database and shared by multiple applications, and a temporary object that exists only during the execution of the application and disappears with the application process ( Hereinafter, volatile objects) are mixed.
[0004]
Here, the “object” refers to all data structures that can be handled as a single unit having a single meaning, including conventional record data or a tuple of a relational database.
[0005]
In general, when creating an application that uses a database, persistent objects and volatile objects are mixed in the application. In particular, a situation occurs where a persistent object points to a volatile object by means such as a link. In such a situation, the volatile object disappears with the termination of the application process, and a permanent data structure including the volatile object can be lost, so that the meaning of the entire data structure is lost. For example, when drawing a figure using a bitmap display and a mouse, in the example of managing database of drawing data created thereby, communication information with a window server for displaying the drawing data is: It is a volatile object, and color information and font information are lost when the application ends. Therefore, the meaning as drawing data is lost.
[0006]
Conventionally, in order to avoid this problem caused by the mixture of objects, persistent objects stored using a database system on a computer do not describe the relationship with volatile objects, but with the relationship with the data stored in the database. Have only saved. In other words, the explicit or implicit reference relationship of data in the database has been closed in the database in this sense. As a result, the consistency of the database was maintained. To maintain this consistency, for example, persistent objects on a typical relational database system are prohibited from storing relationships with volatile objects.
[0007]
For this reason, in an application that needs to describe the relationship with the volatile object, the application programmer has described the process of copying the persistent object to the application memory space and then describing the relationship with the volatile object. .
As an example of such application description, an example of database management of drawing data displayed using an X window system, which is a general window system on a workstation, will be described. In the X window system, the drawing data displayed in the window includes communication information (such as font information and color information resource identifiers) with the window server that is actually displayed. At this time, since a connection with each window server is established for each application process, communication information with the window server differs for each application process. Therefore, this drawing data has a volatile object as its attribute. On the other hand, here, since the drawing data on the window is to be managed by the database, this is a permanent object. Here, in the conventional method, the following procedure is used to prevent the persistent object from being mixed with the volatile object. (1) The data structure stored in the database is separated from the data structure held in the application process. In the database, the drawing figure is unique from the drawing data excluding volatile objects such as communication information with the window server. Only the data part of is stored. (2) When the application process uses drawing data, it secures a data structure of graphic data including communication information, embeds drawing data extracted from the database, and creates a copy of the drawing data. Then, communication information with the window server is established for this copy.
And it was necessary to describe these procedures at the responsibility of the application programmer.
[0008]
[Problems to be solved by the invention]
In the present invention, the application programmer is responsible for the persistent object for each application for the purpose shown in the above conventional example, that is, for the addition of a procedure and the change of the data model which are not necessary for programming without using a database. It is necessary to create a program that handles volatile objects and volatile objects consistently, and solves the problem that productivity of creating applications falls.
[0009]
[Means for Solving the Problems]
In order to solve the above problems, according to the present invention, including a persistent object that is shared by multiple applications, present in the execution of a particular application, an application-specific volatile object disappears at the end of the application in the data management system that handles semi persistent objects, and creating means for each application creates an application specific volatile objects included in the semi-persistent objects about the persistent objects in the database in memory, to the volatile object created pointers, registration means in association with the instance of the semi-persistent object containing an application and the volatile object that created the volatile object is registered in the registration table to be shared by the plurality of applications, each When the application refers to the semi-persistent objects, by referring to the registration table, and identifying means for identifying the application-specific volatile object, when each application updates the semi-persistent object, said registration table see, comprises identification means for identifying other applications sharing the permanent portion of the semi-persistent objects, and notification means for notifying the updating of the semi-persistent objects in other applications identified by the identification means .
According to another aspect of the present invention, the semi-persistent including a persistent object that is shared by multiple applications, present in the execution of a particular application, an application-specific volatile object disappears at the end of the application in the data management method of handling objects, and creating steps each application creates an application specific volatile objects included in the semi-persistent objects about the persistent objects in the database in memory, a pointer to the volatile object created , in association with the instance of the semi-persistent object containing an application and the volatile object that created the volatile object, a registration step of registering the registration table to be shared by the plurality of applications, each application To but when referring to the semi-persistent objects, by referring to the registration table, the identification step of identifying the application-specific volatile object, when each application updates the semi-persistent object, referring to the registration table to comprise the said semi-persistent object persistence partial identification step of identifying the other applications that share, and a notification step of notifying the updating of the semi-persistent objects in other applications identified by the identifying step.
[0010]
【Example】
Examples of this patent will be described below with reference to the drawings. In the present embodiment, an example of managing the drawing information in a database in a drawing application using a window system will be described.
FIG. 1 is a diagram showing a system configuration in the present embodiment. In the figure,
Reference numeral 1 denotes an input device for a user of a drawing application to input commands and data to the drawing application, for example, a keyboard or a mouse.
[0011]
Reference numeral 2 denotes a CPU for performing processing in the present embodiment based on a command input from the input device 1 and executes a program existing in a memory described later.
[0012]
Reference numeral 3 denotes an output device for printing or displaying the processing result of the CPU 2 or a message from the drawing application, for example, a printer or a CRT display.
[0013]
Reference numeral 4 denotes a database for storing and managing drawing data, for example, an object-oriented database.
[0014]
5 is a memory for temporarily storing data, processing programs, programs shown in FIGS. 2, 3, 4, 8, 9, 10, 11 and 12 described later, data required for processing, and the like. Device. Each data included here may be divided into independent storage devices.
[0015]
Reference numeral 6 denotes a computer bus that combines the above components to exchange data, addresses, control data, and the like.
[0016]
FIG. 2 is a diagram showing a definition part of a circle among drawing primitives handled by the drawing application. In the figure,
Reference numeral 1 denotes a class definition that describes the attributes and behaviors of a circle, and includes a description in the range from begin to end. Hereinafter, a class representing a circle is referred to as “Circle”, and an instance having a circle is referred to as “aCircle”. 2 is a definition of the persistence instance attribute of the Circle. The instance of the Dimension class representing coordinates and length x-center, y-center, radius, and the reference color to the persistence instance of the Color class representing color information Composed. All persistent instance attributes of a persistent object are persistent objects. Note that a reference to an instance of the class Color is represented as ^ Color. However, since the color can be regarded as an instance of the ^ Color class, it will be treated as follows.
[0017]
Reference numeral 3 denotes a definition of a volatile instance attribute of a Circle, which includes an instance pen of a Pen class representing a rendering attribute and a reference window to a WindowList representing a window group in which a Circle is rendered. A volatile instance attribute gives a data structure of the same class as two persistent instance attributes, whereas a persistent instance attribute is a persistent object created for each instance instance, whereas A volatile instance attribute is a volatile object created for each application that references a persistent object that contains it.
[0018]
4 is the definition of the persistence class attribute of Circle. A persistent or volatile instance attribute has a unique value for each instance, whereas a class attribute has a common value for all instances. In this embodiment, this represents the number of all instances of Circle.
An instance class num-of-Circles of the Integer class is defined.
[0019]
5 is the definition of the volatile class attribute of Circle. Similar to the volatile instance attribute 3, the volatile class attribute has a value common to instances belonging to a predetermined class for each application. In this embodiment, an instance window-system of the ^ SystemSystem class representing a reference to the control information of the window system is a volatile object that exists only during the operation of the application and is common to all instances of the Circle class. 6 is a declaration of the instance method of Circle, and a series of messages accepted by aCycle and an instance class representing a return value of a method body defined separately are defined. However, when there is no return value, it is expressed as “Void”. In this embodiment, the display method for displaying aCircle, the X coordinate of aCircle is changed to an instance x of the Dimension class, and the set-x method that returns a reference to the changed aCircle as a return value. The set-y, set-r, and set-c methods for changing the coordinates, radius, and color, the changed method for notifying the change of aCycle, and the destroy method for destroying the aCycle are defined.
[0020]
7 is the definition of the Circle class method. Class methods do not operate on specific instances, but are used for instance creation and initialization of class attributes. In the present embodiment, a create method is defined in which an instance of Circle is generated, an instance attribute is set according to arguments x 1, y 2, r 3, and c 2, and then a reference to the generated instance is returned.
In addition, the definition of the persistent attribute and the volatile attribute in FIG. 2 is a method of specifying the instance variables collectively as in the present embodiment, and a method of specifying in a form-qualifying format such as “transient dimension”, for example. These are semantically equivalent. Below, it demonstrates according to the definition of FIG.
FIG. 3 is a flowchart showing a procedure for initializing the class attribute of the Circle class.
As class attributes of the Circle class, there are a persistent class attribute num-of-Circles and a volatile class attribute window-system. First, if the other class fails in the search, the persistent class attribute assumes that the Circle class has never been used by any application, creates a persistent object num-of-Cycles, and sets the value to 0. Initialization is performed (step S2). Next, the volatile class attribute window-system is initialized using a reference to the window system control information obtained as a result of initialization of the window system by a known method (step S3). The above processing is performed only once when the application uses the Circle class for the first time.
[0021]
FIG. 4 is a flowchart showing a procedure for generating an instance aCycle of the Circle class, which is executed by the processing unit CPU. As described above, the instance generation of the Circle class is performed by the create method. First, after securing a storage area for storing aCycle on the database, the persistent instance attribute is initialized using an argument (step S1). Next, a volatile object representing a volatile instance attribute is created (step S2). The creation of the volatile object is created in the virtual space of the application in the embodiment of the present invention. However, the creation of the volatile object is not limited to this, and may be created on the database. After the above process, a volatile instance attribute conversion table is created (step S3), the volatile object is registered in the instance attribute conversion table (step S4), and the process ends.
5 to 7 are diagrams showing the volatile instance attribute conversion tables.
[0022]
There are three types of conversion table construction methods: a method for each instance, a method for each class, and a method for providing one global table as a whole. Furthermore, there are two types of the latter two types: the conversion table is placed on the database or the application virtual space in the storage area of the storage device. Hereinafter, each method will be described.
[0023]
FIG. 5 is a diagram showing a method of providing a conversion table for each instance on the database.
[0024]
The conversion table is configured as a dictionary having application identifiers as keys and volatile object references as values. The application identifier is an identifier provided by the operating system, for example, a set of a host identifier and a process identifier.
[0025]
FIG. 6 is a diagram showing a method for providing a conversion table for each class or globally on a database. The conversion table is configured as a dictionary having application identifiers and object identifiers as keys and volatile object references as values. The application identifier is the same as in FIG. An object identifier is assigned to each volatile instance attribute expressed as a volatile object as a unique number in the same class in the conversion table for each class, or a unique number in the database in the global conversion table. . Since an application generally uses a plurality of instances of a certain class, there are generally a plurality of volatile instance attributes of the same class. Object identifiers are necessary to distinguish them from each other. As the object identifier, an identifier given by the database system may be used, or a number obtained by a numbering mechanism using a known method may be used independently of the database system.
[0026]
FIG. 7 is a diagram showing a method of providing a class-by-class or global conversion table on the virtual space of the application. The conversion table is configured as a dictionary having object identifiers as keys and volatile object references as values. Since the conversion display body is application-specific information, it is not necessary to identify the application in the database, and an application identifier is unnecessary compared to FIG. On the other hand, if there is no application identifier, whether or not information related to reference to the same object by another application is obtained depends on the database system used. When the database system does not provide the reference information, an equivalent function can be provided by providing a conversion table that excludes the column related to the reference of the volatile object from the conversion table of FIG. 5 or FIG.
[0027]
FIG. 8 is a flowchart showing a procedure in which an application searches for an already created aCircle and sets an application-specific volatile instance attribute, and is executed by the processing unit CPU. First, a search is made for a Circle object stored in the database (step S1). If the search is successful, a volatile instance attribute is created (step S2) and registered in the conversion table (step S3). If the search fails, an error is notified (step S4) and the process ends.
[0028]
FIG. 9 is a flowchart showing a procedure for displaying aCycle on a window. First, the instance aCycle is searched (step S1), and if successful, the volatile attributes windows, pen, and window-system are extracted (step S2), and if successful, the acycle is drawn using the volatile attributes (step S3). If any error occurs in the above processing, the error is notified (step S4) and the process ends.
[0029]
FIG. 10 is a flowchart showing a procedure for extracting a volatile attribute in step S2 of FIG. Here, the volatile class attribute is realized as a global variable used in a known programming language, and is treated as such in the embodiment of the present invention. On the other hand, the volatile instance attribute is registered and referred to using any one of the conversion tables shown in FIGS. Hereinafter, a procedure for extracting the volatile instance attribute pen using the conversion table of FIG. 5 will be described.
[0030]
In FIG. 10, first, a conversion table in which the volatile attribute pen is registered is extracted (step S1). If the conversion table has the format shown in FIG. 5 or 6, the retrieval is performed using a known database search technique, and if the conversion table has the format shown in FIG. 7, the retrieval is performed directly from the memory space of the application. If this extraction is successful, the conversion table is searched to extract an item corresponding to the volatile attribute pen (step S2). If this extraction is successful, the volatile object pen is extracted from the above item (step S3). If any error occurs in the above processing, the error is notified (step S4) and the process ends. FIG. 11 is a flowchart showing a means for notifying each application sharing the permanent part of the semi-persistent object when the semi-persistent object is changed. As described above, the change notification of aCycle is performed by the changed method. First, a list of application identifiers that refer to the persistent part of the semi-persistent object aCycle is created (step S1). This can be created from the conversion table shown in FIG. 5 or FIG. 6, or can be created using the function of the database system. Next, if the list is not empty, there are other applications that refer to aCircle, so an application identifier is taken out from the list (step S2). Further, using a known inter-process communication function provided by the operating system or the like, it is checked whether or not communication with the application corresponding to the application identifier is possible. If communication is possible, the change is notified to the application (step S3). ). The above process is repeated until the list becomes empty, and then the process ends. Note that the application on the side that received the change notification redisplays aCycle according to the procedure shown in FIG. 9, for example.
[0031]
FIG. 12 is a flowchart showing a means for notifying each application sharing the permanent part of the semi-persistent object when the semi-persistent object is destroyed. There are two methods of notifying destruction of semi-persistent objects: a method of notifying after destroying and a method of destroying after notifying. The former performs processing according to the procedure shown in FIG. On the other hand, in the latter case, after performing the same processing as FIG. 11 before the destruction (steps 1 to 3), whether or not it has been destroyed by another application and deleted from the database during the destruction notification. If it is not yet destroyed and exists in the database, the destruction process is performed and the process is terminated. In addition, when performing destruction notification between applications, the application that has received the notification activates the change notification by the method shown in FIG. 11, and cooperates with the processing in FIG. 12 to coordinate the destruction processing among a plurality of applications. Can be done automatically. Furthermore, by combining the methods shown in FIG. 11, it is possible to realize not only destruction processing but also arbitrary cooperation processing.
[0032]
【The invention's effect】
As described above, according to the present invention, persistent data shared by a plurality of processes, such as a multimedia database, and a process-specific data that exists during execution of a specific process and disappears when the process ends. In data management handling temporary data, there are the following advantages.
(1) Even if the persistent data includes temporary data, it can be kept intact when used in the application process.
(2) It is possible to maintain the consistency of persistent data shared by a plurality of application processes.
(3) A cooperative operation of a plurality of application processes can be easily realized.
[Brief description of the drawings]
FIG. 1 is a system configuration diagram for explaining an embodiment of the present invention;
FIG. 2 is a class definition diagram for explaining the definition of a semi-persistent object in the embodiment;
FIG. 3 is a flowchart for explaining initialization of a class attribute of a semi-persistent object;
FIG. 4 is a flowchart for explaining a procedure for creating an instance of a semi-persistent object;
FIG. 5 is a diagram for explaining a structure when a conversion table for setting and retrieving a volatile instance attribute of a semi-persistent object is provided on a database for each instance of the semi-persistent object;
FIG. 6 is a diagram for explaining a structure when a conversion table for setting and retrieving a volatile instance attribute of a semi-persistent object is provided on a database for each semi-persistent object class or globally. ,
FIG. 7 illustrates a structure when a conversion table for setting and retrieving a volatile instance attribute of a semi-persistent object is provided in the virtual space of an application for each semi-persistent object class or globally. Illustration for the
FIG. 8 is a flowchart for explaining a procedure for setting a volatile instance attribute of a semi-persistent object;
FIG. 9 is a flowchart for explaining a procedure when processing using a volatile attribute of a semi-persistent object;
FIG. 10 is a flowchart for explaining a procedure for extracting a volatile attribute of a semi-persistent object;
FIG. 11 is a flowchart for explaining a procedure for notifying an application that refers to the semi-persistent object of a change of the semi-persistent object;
FIG. 12 is a flowchart for explaining a procedure for notifying an application that refers to a semi-persistent object before destroying the semi-persistent object.
[Explanation of symbols]
1 Input device 2 CPU
3 Output device 4 Database 5 Storage device

Claims (6)

A persistent object that is shared by multiple applications, present during the execution of a specific application, the data management system that handles semi-persistent object that contains the application-specific volatile object disappears at the end of the application,
And creation means for each application creates an application specific volatile objects included in the semi-persistent objects about the persistent objects in the database in memory,
The pointer to the created the volatile object, in association with the instance of the semi-persistent object containing an application and the volatile object that created the volatile object, and registering means for registering in the registration table to be shared by the plurality of application ,
When each application refers to the semi- persistent object , referring to the registration table, identification means for identifying the application- specific volatile object ;
As each application updates the semi-persistent object, by referring to the registration table, and identifying means for identifying the other applications sharing the permanent portion of the semi-persistent object,
A data management system comprising: notification means for notifying other applications identified by the identification means of the update of the semi- persistent object . The data management system according to claim 1, wherein the registration table is provided for each instance of the semi- persistent object , and the pointer is registered in association with an application identifier. Data management system of claim 1, change of the semi-persistent object is characterized in that it comprises a disruption of the semi-persistent objects. A persistent object that is shared by multiple applications, present during the execution of a specific application, the data management method of handling semi-persistent object that contains the application-specific volatile object disappears at the end of the application,
A creation step of each application creates an application specific volatile objects included in the semi-persistent objects about the persistent objects in the database in memory,
The pointer to the created the volatile object registration process in association with the instance of the semi-persistent object containing an application and the volatile object that created the volatile object is registered in the registration table to be shared by the plurality of application ,
When each application refers to the semi- persistent object , an identification step for identifying a volatile object specific to the application with reference to the registration table;
As each application updates the semi-persistent object, by referring to the registration table, an identification step of identifying the other applications sharing the permanent portion of the semi-persistent object,
And a notification step of notifying the other application identified by the identification step of the update of the semi- persistent object . 5. The data management method according to claim 4 , wherein the registration table is provided for each instance of the semi- persistent object , and the pointer is registered in association with an application identifier. The data management method according to claim 4 which changes the semi-persistent object comprising the destruction of the semi-persistent objects.

Images