Abstract:
To provide a database, which is robust against variation of application programs and environments. 
     A database system, which updates data by an application program, includes data storage means for storing a master data and a shared memory area. The shared memory area includes: a first area, which loads the master data and to which an application program is allowed only to refer; and a second area, which stores a difference data generated when the application program updates the master data in the first area, and which the application program is allowed to refer to and update.

Description:
TECHNICAL FIELD 
       [0001]    The present invention relates to a database, in which a user application program updates a data area placed on a shared memory, a database system, a database update method and a database update program. 
       BACKGROUND ART 
       [0002]      FIG. 13  shows a memory database system, in which a user application program directly updates a data area placed on a shared memory. In this database system, in the case where there is a defect in the user application program, there is a problem that, when the user application program updates data, the data area on the shared memory might be destroyed. 
         [0003]      FIG. 14  shows a journal file system for the memory database system. In this system, when data destruction occurs, data is restored according to the following procedure. That is, (1) eliminating the destroyed data on the memory, (2) reloading the master data from the disk apparatus, and (3) roll forwarding an update data from the journal file, which holds and manages the metadata. 
         [0004]    However, the procedures (2) and (3) require reading data from the disk apparatus. Usually, time necessary for reading and writing, when accessing the disk apparatus, is large compared with the case when accessing a memory, then, when the memory destruction occurs, services are suspended for a long time. Also, the cost required for recovery is large. 
         [0005]    As a system, equipped with a function to prevent the data destruction caused by the user application program, there is a memory database system of a client/server method. A system of the client/server method, as shown in  FIG. 15 , includes a server daemon. Access from the user application program to the data is inevitably performed through the server daemon. Only the server daemon accesses the shared memory, and the user application program does not directly access the shared memory. As a result, the user application program does not destroy data on the shared memory. 
         [0006]    As another method, a method used for CVS (Concurrent Versions System) is known. The CVS is a version management system, by which a plurality of people handle a file simultaneously. A configuration of the CVS is shown in  FIG. 16 . When a user updates a master data (a master file, in this case), first, (4) copying whole of the master file from an area, called a repository, into a local area, and next, (5) updating the copied master file. 
         [0007]    After that, (6) the contents of the update are reflected to the master file in a lump. The user himself/herself cannot update directly the master file. As a result, the user does not destroy the master file. 
         [0008]      FIG. 17  shows a data update method disclosed by patent document 1. From an application process, the shared memory of the database system is read-only. A memory for update is provided in block units (64 KB) or page units (4 to 8 KB) for each application process. When updating the data, first, (7) a relevant block of the shared memory is copied to the memory for update, (8) the data on the memory for update is updated, and then, (9) a manager process copies contents on the memory for update into the shared memory. (10) The application process does not directly access the master data. As a result, the user does not destroy the master file. 
         [0009]    Patent document 1: Japanese Patent Application Laid-Open No. 1998-031604 
       DISCLOSURE OF INVENTION 
       [0010]    Technical Problem 
         [0011]    A subject of the present invention is to provide a database, which is robust against variation of application programs and environments. 
         [0012]    In the client/server method, when the user application program accesses data, interprocess communication between the user application program and the server daemon is always necessary. For this reason, due to degradation of data update performance caused by overhead of the interprocess communication, data access cost becomes higher compared with the case of directly accessing the shared memory, and thus, transaction performance is deteriorated. 
         [0013]    This point becomes a serious problem in the memory database, for which high transaction performance is required. 
         [0014]    In addition, in the CVS method, the master data needs to be entirely copied, before starting the data update processing. Further, in the method shown in patent document 1, a part of the master data needs to be copied into the other area, in a block unit or in a page unit. 
         [0015]    The processing for copying data between the memories consumes a CPU resource in proportion to a size of copying. For this reason, in these methods for copying the master data at each time of stating the data update processing, there is a problem that the CPU resource is deprived by the copy processing, and thus, the transaction performance is aggravated. 
         [0016]    Also, in these methods, copies of the master data by the number of the processes, in which the data is updated, is generated. For this reason, there is also a problem that a memory resource necessary for the system increases, too. 
         [0017]    An object of the present invention is to provide a memory database, a memory database system and an update method of a memory database, which solve the problem mentioned above. An object of the present invention is to provide a memory database, which can prevent data destruction by a user, and minimizes degradation of data access performance and consumption of a CPU resource and of a memory resource. 
       SOLUTION TO PROBLEM 
       [0018]    A database system of the present invention is a database system for updating data by an application program, including: data storage means for storing a master data; and a shared memory area. The share memory area includes: a first area, in which the master data is loaded, and to which the application program is allowed only to refer; and a second area, which stores a difference data generated when the application program updates the master data in the first area, and which the application program is allowed to refer to and update. 
         [0019]    A database update method of the present invention is a database update method for updating data by an application program, including: a step for updating a master data loaded in a first area, to which the application program is allowed only to refer, by the application program and for generating a difference data; a step for storing the difference data, which is generated when the application program updates the master data, in a second area, which the application program is allowed to refer to and update; a step for reflecting the difference data into the master data; and a step for eliminating the difference data. 
         [0020]    A database of the present invention is a database for updating data by an application program, including: a first area, in which a master data is loaded, and to which the application program is allowed only to refer; and a second area, which stores a difference data generated when the application program updates the master data in the first area, and which the application program is allowed to refer to and update. 
         [0021]    A database update program of the present invention is a database update program for updating data loaded in a database, which makes the database execute: a step for updating a master data loaded in a first area, to which the program is allowed only to referred, and for generating a difference; a step for storing the generated difference data in a second area, which the program is allowed to refer to and update; a step for reflecting the difference data into the master data; and a step for eliminating the difference data. 
       ADVANTAGEOUS EFFECTS OF INVENTION 
       [0022]    According to the present invention, because a user application program cannot access an area for reference, which stores a master data, even when there is a defect in the user application program, the master data is not destroyed. 
     
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         [0023]      FIG. 1  A system configuration diagram showing one exemplary embodiment of a memory database system according to the present invention; 
           [0024]      FIG. 2  A configuration diagram of a shared memory at the time of creating the shared memory according to this exemplary embodiment; 
           [0025]      FIG. 3  A configuration diagram of a memory database system according to this exemplary embodiment at the time of loading a master data; 
           [0026]      FIG. 4  A configuration diagram of the memory database system according to this exemplary embodiment at the time of configuring an index in an area for update; 
           [0027]      FIG. 5  A configuration diagram of the memory database system according to this exemplary embodiment in an early stage of generating difference data of the master data; 
           [0028]      FIG. 6  A configuration diagram of the memory database system according to this exemplary embodiment in a latter stage of generating the difference data of the master data; 
           [0029]      FIG. 7  A configuration diagram of the memory database system according to this exemplary embodiment in an early stage of updating the master data by the difference data; 
           [0030]      FIG. 8  A configuration diagram of the memory database system according to this exemplary embodiment in a latter stage of updating the master data by the difference data; 
           [0031]      FIG. 9  A configuration diagram of the memory database system according to this exemplary embodiment in an early stage of generating a difference data of the master data by another user; 
           [0032]      FIG. 10  A configuration diagram of the memory database system according to this exemplary embodiment in a latter stage of generating the difference data of the master data by the another user; 
           [0033]      FIG. 11  A configuration diagram of the memory database system according to this exemplary embodiment at the time of referring to an area for reference during generating a difference data of the master data; 
           [0034]      FIG. 12  A configuration diagram of a memory database system according to this exemplary embodiment at the time of data restoration; 
           [0035]      FIG. 13  A configuration diagram of a memory database system at the time of data destruction in the related art; 
           [0036]      FIG. 14  A configuration diagram of a journal file system at the time of data restoration in the related art; 
           [0037]      FIG. 15  A configuration diagram of a memory database system of a client/server method in the related art; 
           [0038]      FIG. 16  A configuration diagram of a memory database system of CVS method in the related art; 
           [0039]      FIG. 17  A configuration diagram of a memory database system in patent document 1; 
           [0040]      FIG. 18  A flow chart showing a processing at the time of start-up of the memory database system according to this exemplary embodiment; 
           [0041]      FIG. 19  A flow chart showing an update processing for data in the memory database according to this exemplary embodiment; 
           [0042]      FIG. 20  A flow chart showing an update processing for data, when other application program issues an update request, in the memory database according to this exemplary embodiment; and 
           [0043]      FIG. 21  A flow chart showing a data restoration processing in the memory database according to this exemplary embodiment. 
       
    
    
     DESCRIPTION OF EMBODIMENTS 
       [0044]    Hereinafter, the preferred embodiment according to the present invention will be described with reference to the drawings. 
         [0045]    Meanwhile, individual processing or operation in a memory database of this exemplary embodiment shown below is realized by a processing, means and a function, which are executed in a computer by instructions of a program (software). The program sends an instruction to each component of the computer and makes them perform a predetermined processing and a function described below. That is, individual processing and means in the memory database of this exemplary embodiment are realized by concrete means, in which the program and the computer cooperate with each other. 
         [0046]    Meanwhile, all or a part of the program is provided, for example, by a magnetic disk, an optical disc, a semiconductor memory or any other computer-readable recording medium. The program read from the recording medium is installed in the computer and then executed. 
         [0047]    Also, the program may be carried out after being loaded into the computer via a communication line not through the recording medium. Further, a program may be executed directly through the communication line. 
         [0048]      FIG. 1  is a block diagram showing an exemplary embodiment of a configuration of a memory database system according to the present invention. The memory database system  1  of this exemplary embodiment includes an information processing apparatus such as a personal computer and a workstation. Specifically, the memory database system  1  of this exemplary embodiment includes a shared memory  100 , which stores data of a database, a user application program  200 , which a user prepared originally, a commit execution daemon  300  and a disk apparatus  400 , which stores a master data. The commit execution daemon  300  may start on a daemon server, which is not illustrated, to carry out the processing described below. 
         [0049]    The shared memory  100  is divided into an area for reference  110  as a first area and an area for update  120  as a second area. 
         [0050]    In the area for reference  110 , the master data  111  is stored. 
         [0051]    The master data  111  is read from the disk apparatus  400  at the time of start-up of the operation of the memory database system  1 . 
         [0052]    The master data  111  includes a record  112  as a main data and an index tree  113  as an index for reference. 
         [0053]    The index tree  113  has a tree structure, which is used in order to rapidly search for record. The index tree  113  has a pointer-for-reference storage area  114  in a leaf portion corresponding to the tail end. 
         [0054]    The pointer-for-reference storage area  114  stores numerical values of a pointer for reference  115 , which points to the respective corresponding records  112 . As an index for update corresponding to the pointer-for-reference storage area  114 , a pointer-for-update storage area  124  is provided in an area for update  120 . The pointer-for-reference storage area  114  stores a link to the pointer-for-update storage area  124 . 
         [0055]    The following access restriction is set to the area for reference  110 . That is, from the user application program  200 , only a reference is possible, but an update is not allowed. Furthermore, from the commit execution daemon  300 , the reference and the update are possible. 
         [0056]    Update information  121  is stored in the area for update  120 . 
         [0057]    At a timing when the user application program  200  tries to update the master data  111 , the update information  121  is created. 
         [0058]    The update information  121  includes a difference record  122  of difference between before and after the update, and the pointer-for-update storage area  124  that stores the index for update. 
         [0059]    At a timing when the master data  111  is read into the area for reference  110 , a content of the pointer-for-reference storage area  114  is automatically copied into the pointer-for-update storage area  124 , and a link from the pointer-for-reference storage area  114  is provided. 
         [0060]    Accordingly, in the initial state, the pointer-for-update storage area  124  stores a numerical value of a pointer for update  125 , which points to the corresponding record  112  on the master data  111 . 
         [0061]    After that, when the user application program  200  tries to update the master data  111  and the difference record  122  is created, the numerical value of the pointer-for-update storage area  124  is updated, so that the pointer for update  125  points to the difference record  122 . 
         [0062]    An access restriction is set for the area for update  120 , and from the user application program  200  and from the commit execution daemon  300 , the reference and the update is possible. 
         [0063]    The user application program  200  is prepared originally by a user who uses the memory database system  1 . The user application program  200  has a function to refer to the master data  111  placed in the area for reference  110 . Furthermore, the user application program  200  has a function to create the difference record  122  when updating the master data  111 , to exclude the area for update  120 , after that, to store the created difference record  122  in the area for update  120 , and to change the pointer for update  125 , so that the difference record  122  is pointed to. 
         [0064]    Furthermore, the user application program  200  has a function to carry out a commit processing by transmitting a commit request to the commit execution daemon  300  after the update of the data. 
         [0065]    The commit execution daemon  300  operates in the memory database system  1 . When the commit request from the user application program  200  is received, the commit execution daemon  300  excludes the area for reference  110  and the area for update  120 . After that, the commit execution daemon  300  has a function to reflect the difference record  122 , stored in the area for update  120 , in the master data  111 , stored in the area for reference  110 , and to change the pointer for update  125  so as all to point to the records  112  of the master data  111 . 
         [0066]    Next, operation of the above-mentioned memory database system  1  will be described with reference to  FIGS. 2 to 12  and  FIGS. 18 to 21 . 
         [0067]    Referring to  FIG. 18 , the shared memory  100  of the memory database system  1  is created according to the following procedure. 
         [0068]    First, as shown in  FIG. 2 , the memory database system  1  creates an area for reference  110  and an area for update  120  on the shared memory  100  at the time of start-up (Step S 101 ). 
         [0069]    Next, as shown in  FIG. 3 , the memory database system  1  loads the master data  111  read from the disk apparatus  400  onto the area for reference  110  (Step S 102 ). The master data  111  includes the records  112  as the main data and the index tree  113  as the index for reference. The index tree  113  has the pointer-for-reference storage area  114  in the leaf portion. 
         [0070]    Next, as shown in  FIG. 4 , the memory database system  1  copies the pointer-for-reference storage area  114  onto the area for update  120 , and generates the pointer-for-update storage area  124  (Step S 103 ). 
         [0071]    The pointer-for-reference storage area  114  stores numerical values of the pointer for reference  115 , which points to the corresponding records  112 , and also stores a link to the pointer-for-update storage area  124  as an index for update provided in the area for update  120  (Step S 104 ). 
         [0072]    The pointer-for-update storage area  124  stores numerical values of the pointer for update  125 , which points to the difference record  122  ( FIG. 1 ). 
         [0073]    However, in the initial state, the pointer for update  125  points to the same record as the pointer for reference  115  on the master data  111 , as shown in  FIG. 4 . 
         [0074]    Next, processing, in which the user application program  200  updates the master data  111  placed on the shared memory  100  will be described with reference to  FIG. 19 . 
         [0075]    In  FIG. 5  and  FIG. 19 , when the user application program  200  tries to update the records  112  of the master data  111 , the user application program  200  excludes the area for update  120  (Step S 201 ). As a result, other user application program or the commit execution daemon  300  cannot refer to the area for update  120 . Next, by referring to the pointer for update  125  from the index tree  113 , the user application program  200  identifies a position of a record image to be updated. In  FIG. 5 , a black-painted part of the records  112  indicates the position of the identified record image. 
         [0076]    After that, the user application program  200  generates a difference record image  122 , which is obtained from the record image before update, a position of which has been identified as above, and from the record image after update (Step S 202 ), and stores it in the area for update  120 , as shown in  FIG. 6  (Step S 203 ). Then, the user application program  200  rewrites the pointer-for-update storage area  124 , so that the pointer for update  125  points to the difference record image  122 . 
         [0077]    After whole of the processing ends, the user application program  200  cancels the exclusion for the area for update  120  (Step S 204 ). 
         [0078]    After the update by the user application program  200  by the specified number of times (the number may be one or may be plural) ends, the update information  121  accumulated in the area for update  120  is reflected to the master data  111 . That is, as shown in  FIG. 7 , the user application program  200  transmits a commit request to the commit execution daemon  300  using an interprocess communication (Step S 205 ). 
         [0079]    When a commit request is received, the commit execution daemon  300  first excludes the area for reference  110  and the area for update  120  (Step S 206 ). 
         [0080]    Next, the difference record  122  accumulated in the area for update  120  is reflected into the master data  111  of the area for reference  110  at the same time (Step S 207 ). 
         [0081]    After rewriting the master data  111  with the difference record  122 , as shown in  FIG. 8 , the difference record  122  is eliminated (Step S 208 ), and the pointer-for-update storage area  124  is rewritten, so that the pointer for update  125 , which pointed to the difference record  122 , points to the corresponding record  112  on the master data  111 . 
         [0082]    After whole of the processing ends, the exclusion for the area for reference  110  and for the area for update  120  is cancelled (Step S 209 ). 
         [0083]    Next, a method, by which a record updated by the user application program  200  is further updated by another user application program, will be described with reference to  FIG. 20 . 
         [0084]    As shown in  FIG. 6 , it is assumed in the state that, by the user application program  200 , the master data  111  is updated, the difference record  122  is stored in the area for update  120 , and the pointer-for-update storage area  124  is rewritten so that the pointer for update  125  points to the difference record  122 , and the exclusion for the area for update  120  has been cancelled (Steps S 201  to S 204 ). 
         [0085]    In this state, when a different user application program  210  tries to update the records  112  anew and requests an update of data, as shown in  FIG. 9  (step S 210 : Yes), the area for update  120  is first excluded, so as not to be referred by the other user application program or the commit execution daemon  300 , as shown in  FIG. 9  (Step S 211 ). 
         [0086]    Next, a record to be updated is identified by referring to the pointer for update  125 . In this case, the pointer for update  125  points inside the difference record  122 , and it is determined that a present real object for update is the record after update  128 . After that, as shown in  FIG. 10 , the different user application program  210  generates a difference record including this record after update  128  ( FIG. 9 ) and also the record after the update of this time (Step S 212 ), and appends it to the area for update  120  (Step S 213 ). Then, the pointer for update  125  is changed, so that the pointer for update  125  points to the generated difference record. After all of the processing ends, exclusion for the area for update  120  is cancelled (Step S 214 ). 
         [0087]    Because the reflection processing to the master data  111  by the commit execution daemon  300 , after the update by the different user application program  210  ends (step S 210 : No), is quite similar to the above, description will be omitted. 
         [0088]    That is, the commit execution daemon  300 , which has received a commit request from the different user application program  210 , excludes the area for reference  110  and the area for update  120 , reflects the difference record  122  accumulated in the area for update  120  into the master data  111  of the area for reference  110  at the same time, rewrites the master data  111  with the difference record  122 , and then eliminates the difference record  122 , rewrites the pointer-for-update storage area  124 , and then cancels the exclusion for the area for reference  110  and the area for update  120 . 
         [0089]    When all of the updates for the database are finished, the master data III of the area for reference  110  is written into the disk apparatus  400 . The master data  111  may be overwritten or may be appended to the master data of the disk apparatus  400 . After that, the area for reference  110  and the area for update  120  are deallocated from the shared memory  100 , and the processing ends. 
         [0090]    Next, a processing, in the case that while the user application program  200  tries to update the master data  111 , the different user application program  210  refers to the master data  111  , will be described. 
         [0091]    While the user application program  200  tries to update the master data  111 , the area for update  120  is excluded, as shown in  FIG. 11 , and thus other user application programs or the commit execution daemon  300  cannot refer to the area for update. However, because data has not been updated in the area for reference  110  and exclusion is not necessary, other user application program can always refer to the area for reference  110 . 
         [0092]    In this regard, however, both of the area for reference  110  and the area for update  120  are excluded while the commit execution daemon  300  reflects the update information  121  in the master data  111  after the update processing of the user application program  200  completes and a commit request is issued to the commit execution daemon  300 . For this reason, any user application program cannot refer to the master data  111 . 
         [0093]    Of course, it is needless to say that, when no user application program has updated the master data  111 , any user application program can refer to the master data  111 . 
         [0094]    In the database system according to this exemplary embodiment, a function that “same” data can be read and write “simultaneously” and “consistently” is secured for the plurality of user application programs. 
         [0095]    A function to protect data from a failure is also required for the database system. 
         [0096]    Referring to  FIG. 12  and  FIG. 21 , a processing for restoring data on the shared memory  100 , in case that a memory destruction occurs due to a defect of the user application program  200 , will be described. 
         [0097]    In the case that the memory destruction occurs due to the defect of the user application program  200 , a memory area, which would be destroyed, is restricted to a memory, which the user application program itself has (referred to as a local memory), and to the area for update  120  within the shared memory  100  on the memory database system  1 . The user application program  200  has an authority for updating the area for update  120 . The area for reference  110 , for which the user application program  200  does not have the update authority, is not destroyed. 
         [0098]    When it is detected that the update information  121  on the area for update  120  was destroyed (step S 301 : Yes), (1) the area for update  120  is excluded (Step S 302 ), as shown in  FIG. 12 , (2) all of the difference records  122  are discarded (Step S 303 ), (3) the contents of the pointer-for-reference storage area  114  are copied again in the area for update  120  (Step S 304 ), and the exclusion for the area for update  120  is cancelled (Step S 305 ). By the above, it is possible to return to the latest committed data status promptly. 
         [0099]    During this period, because the area for reference  110  is neither updated nor excluded, any user application program can refer to the master data  111 . 
         [0100]    As a method for detecting that the update information was destroyed, there is a method, in which a checksum of update information is calculated at the time of generating the update information and the calculated numerical value is stored, and next, when the update information is referred to, the check-sum is calculated again to be compared with the stored numerical value. 
         [0101]    The process for detecting destruction may be performed by the user application program  200  or by the commit execution daemon  300 , or a process for detecting data destruction may be prepared newly. 
         [0102]    Thus, according to the memory database system  1  of this exemplary embodiment, the shared memory  100 , in which data is arranged, is divided into the area for reference  110 , which the user application program  200  is allowed only to refer to, and the area for update  120 , which the program is allowed to refer to and update. As a result, even if there exists a defect, which destroys the memory in the user application program, it is possible to localize an influence of the data destruction only into the update information  121  on the area for update  120 , for which the user application program  200  has an update authority. 
         [0103]    Even if the memory destruction occurs, the master data  111  is preserved in the area for reference  110 . For this reason, only by discarding all of the update information  121  on the area for update  120  and by rewriting a reference destination of the pointer for update  124 , it is possible to recover to the latest committed data state. 
         [0104]    As a result, compared with the restoration procedure in the related technology, i.e. (1) cancelling data on a memory, (2) reloading data from a disk apparatus and (3) roll forwarding from a journal file, a procedure for the disk access becomes unnecessary in this exemplary embodiment. For this reason, a time required for data recovery is reduced substantially. 
         [0105]    According to this exemplary embodiment, although the memory destruction is assumed to be localized as mentioned above, an interprocess communication, which causes overhead, is limited to a commit request from the user application program  200  to the commit execution daemon  300 . Because, in the other communications, the user application program  200  directly accesses the shared memory  100 , degradation in the data access performance is minimized, and the transaction performance improves. 
         [0106]    Copying master data to a memory at every data update, such as in the related art, is not performed. As only generation of difference data is performed, consumption of the CPU resource and the memory resource is minimized. 
         [0107]    In the related art, data cannot be referred to during the data being updated by a user application program. However, according to this exemplary embodiment, the area for reference  110  is excluded only during the commit processing being executed by the commit execution daemon  300 . As the area for reference  110  is not excluded during the data update, a period, where the data reference is impossible, is restricted. 
         [0108]    By the above, a possibility for the user application program performing data reference to wastefully consume processing time due to waiting for exclusion, is reduced, and an efficiency for processing data improves. 
         [0109]    As it has been described above, according to a memory database according to this exemplary embodiment, the area for reference (a first area), to which a user application program can only refer, and an area for update (the second area), which the user application program can refer to and update, are provided in a shared memory area. If a master data is stored in the area for reference, the user application program cannot access the area for reference, which stores the master data. As a result, the master data is not destroyed by a defect of the user application program. 
         [0110]    Furthermore, a memory database according to this exemplary embodiment includes a commit execution daemon capable of referring to and of updating both of the area for reference and the area for update. The memory database stores a master data in the area for reference, and stores a difference data, which has updated the master data, in the area for update, wherein the commit execution daemon updates the master data with the difference data. Because a user application program cannot access the area for reference, which stores master data, the master data is not destroyed due to a defect in the user application program. 
         [0111]    Moreover, as the user application program can access a shared memory area, degradation of data update performance by an overhead of interprocess communication is prevented. Furthermore, consumption of a CPU resource and a memory resource by the processing of copying the master data itself is suppressed. 
         [0112]    The memory database according to the present invention is not limited to the above-mentioned exemplary embodiment. For example, in the above-mentioned exemplary embodiment, a record is exemplified as the main data of the master data, but it may be other concept, to compose a database. 
         [0113]    This application claims priority based on Japanese application Japanese Patent Application No. 2008-097870, filed on Apr. 4, 2008, the disclosure of which is incorporated herein in its entirety. 
       INDUSTRIAL APPLICABILITY 
       [0114]    A memory database of the present invention is used for the field for performing a data analysis for, such a massive amounts of customer data or of statistical data.