JP2005190212A - Database system, data processing method and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a database system, a data processing method and a program by which conditions for retrieval, totalization, etc. can be stored and reused. <P>SOLUTION: A registration part 30 is a registering means for registering a condition used for a function. A reuse part 40 is a reusing means for reusing a registered condition as a condition for another function by receiving an access and correction in accordance with given operation. For instance, a reusing method in which a common part set in detail is used in its entirety and only data expression such as a table and graph display is changed can be easily performed. Thereby the efficiency of operation such as the specification of a condition can be sharply improved and time required up to the output of a result desired by a user can be effectively shortened. Especially when the system is applied to the development of a software system in which various presentation of information is required, more effects can be expected. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to a database system, a data processing method, and a program that can store and reuse conditions such as search and tabulation.

In recent years, with the development of computer technology, database technology using computers has been applied in various industrial fields. The database is typically managed in units called forms and tables. Predefined data items are called fields, categories, and the like, and a large number of records that are sets of values for each field are recorded. In the search, for example, if a narrowing condition is given such that a certain field is a specified value, the corresponding record is narrowed down and the result can be displayed in a list.
JP2003-30217

  However, in the conventional technique, every time a search is performed in the database, a condition for narrowing down the corresponding item has to be input, and thus there is a problem that takes time and effort. In addition, even if it is desired to change only a part of the stored database and search a new database, there is a problem that it takes time since a new condition must be input from the beginning. Furthermore, there is an inconvenience that the conditions used in the search cannot be reused in the aggregation and analysis.

  In particular, it is often difficult to determine in advance how to process the information accumulated in the past or in the future through aggregation and analysis, etc., and narrowing down every trial and error If the above conditions were input from the beginning as described above, there was a problem of inefficiency, and there was a need for improvement.

  For example, when information on defects in software / system development is accumulated in a database, various different treatments can be considered depending on factors such as differences in the stage of system development and the standpoint of a programmer or system engineer. For example, how to show to users, the range and level of detail of the target information, table, list, graph, etc., whether to view along with the bug convergence curve, as well as system development approaches and individual Requests may vary depending on the team, individual, etc. In order to meet these various demands, inefficiency is a particularly serious problem in the prior art in which conditions are input from scratch.

  Conventionally, there is a server that can only use a search history in a server (see Patent Document 1), but a technique for solving the above problem has not been known.

  The present invention solves the above-described prior art, and an object of the present invention is to provide a database system, a data processing method, and a program capable of storing and reusing conditions such as search and aggregation.

  In order to achieve the above object, in the present invention, in a database system, a data processing method, and a program that realize two or more functions including data search, aggregation, and analysis based on operations and conditions, respectively, The condition used in the function is registered, and the registered condition is reused as a condition of another function by calling and accepting correction according to a given operation. .

  As a result, the stored search conditions can be reused for different information display functions such as data aggregation and analysis. For example, the common part set in detail is used as it is, and the reuse such as changing only the way of viewing data such as a list or a graph display becomes easy. For this reason, operations such as condition specification are greatly improved, and the time until the output of the result desired by the user is effectively shortened. In particular, if applied to the development of software systems that require various ways of showing information, further effects can be expected.

  As described above, according to the present invention, it is possible to provide a database system, a data processing method, and a program that can store and reuse conditions such as search and aggregation.

  The best mode for carrying out the present invention (hereinafter referred to as “embodiment”) will be specifically described with reference to the drawings.

[1. Constitution〕
First, the block diagram of this embodiment is shown in FIG. This embodiment relates to a database system (hereinafter referred to as “the present system”) that realizes each function including data search, aggregation, and analysis based on given operations and conditions according to the use of the user 1. The system is realized by the computer realizing each function of the virtual circuit block as shown in the configuration diagram of FIG. 1 based on control by a predetermined program (for example, an application program such as a workflow system). Since it can be grasped as such a program or data processing method, each part is also expressed as a device in the drawings below.

  In the configuration diagram of FIG. 1, the menu output unit 10, the information search condition input unit 20, the registration unit 30, and the reuse unit 40 are realized by the computer being controlled by a predetermined program. .

  Among these, the user 1 is a person or a system that processes data by each function of search, aggregation, and analysis using an application program. The menu output unit 10 is a part that outputs a menu through a display device such as a liquid crystal and receives an operation on the menu.

  The registration unit 30 is a registration unit that registers the conditions used in the function in the portion indicated by a broken line in FIG. The reuse unit 40 is a part indicated by a two-dot chain line in FIG. 1. The registered condition is reused as a condition for the other function by accepting a call and correction according to a given operation. It is a reuse means to make it.

  The registration unit 30 and the reuse unit 40 have a common component with a unique component. Common components are a display condition creation unit 50, a registration condition DB (database) 53, and a user DB 55. The unique components of the registration unit 30 are the menu creation unit 33 and the form DB 35, and the unique components of the reuse unit 40 are the field definition unit 43, the field DB 45, and the input device component unit 47.

  The menu creation unit 33 is a part that creates menu items. In the description of FIG. 1, for the sake of convenience, the configuration is divided as described above. However, each function is not strictly divided as “0000 copies”. For example, the menu creation unit 33 includes the menu output unit 10. In addition to the information search condition input unit 20, an input / output unit that displays a menu screen and dynamically changes the menu screen by adding a menu item for calling the registered condition or a result using the condition is configured. doing.

  Further, the information search condition input unit 20 receives a service request for a function such as information search / aggregation / analysis from a user or another computer system, and controls the menu creation unit 10 and the reuse unit 40. The display condition creation unit 50 is a part that creates conditions to be displayed to the user from information in various databases.

  The form DB 35 is a database in which data to be searched (aggregated / analyzed) by the workflow system is stored. As a specific example, in the defect information system, data including detailed defect information is included. . The registration condition DB 53 is a database that stores conditions for narrowing down data used when searching (aggregating / analyzing) data. The user DB is a database in which user information is stored, and is used to change the conditions to be displayed for each user (by login).

  The field definition unit 43 is a part that defines field information. Field information is information for categorizing data from various viewpoints, and is typically a data item constituting each record of a database. The field DB 45 is a database in which such field information is stored.

  The input device part unit 47 is a part for storing a part group of screen elements used for data input such as conditions used for functions such as search, totalization, and analysis based on the contents of the field DB 45. For example, a GUI (graphical user interface) component such as a text input field, a selection combo box (drop box), a check field, and a radio button for a web page can be used.

  The registration unit 30 divides the condition into the registration condition DB 53 by dividing the condition into a common condition unit common to the functions and a function specific condition unit specific to any one of the functions. A condition part is configured to be called as the object of reuse.

[2. Action)
The present embodiment as described above operates as follows.
[2-1. Implementation of each function]
First, in this system, saved search conditions can be reused for different information display functions such as information aggregation and analysis. As a precondition, the system displays a list of information search results. Each function such as tabulation, analysis, and graph display of information is realized as follows.

  As an outline, the information is narrowed down based on a narrowing condition regarding a specific unit (field information) input by the user, and all corresponding information is acquired from the form DB. Information processing device that performs various processes such as cumulative calculation of such information, sorting based on specific units, calculation of standard deviation, etc., and displays the processed information in various forms such as list display, table format, graph format, etc. The information display device is realized as software independent from each other, and a plurality of functions are realized by a combination of both.

  FIG. 2 is a conceptual diagram showing the situation, and shows a method for realizing each function that allows a user to view information managed by the system. That is, information from the form DB and the field DB is displayed on the information display device via the information processing device as each function, and a difference in the combination becomes a difference in function. 3 shows an example of field definition in the form DB, and FIG. 4 shows an example of the field DB.

  Based on these, a specific example of a processing procedure for narrowing down information and displaying a list of results at the time of search is shown in the flowchart of FIG. In this procedure, information that has been narrowed down and searched from the form DB based on information input by the user (step 51) (step 52), and if necessary (step 53), sorting is performed on a specific field (step 53). Step 54) A list is displayed (Step 55).

  FIG. 6 is a flowchart illustrating a processing procedure when information is narrowed down and results are displayed in a one-dimensional or two-dimensional table format. In other words, in this procedure, for information searched from the form DB based on information input by the user (step 61) (step 62), depending on one or two designated fields (step 63), Based on one-dimensional or two-dimensional, the cumulative number of corresponding information is calculated (step 64 or 65) and displayed in tabular form (step 66 or 67).

[2-2. (Realization of reuse)
The saved conditions can be reused between the information display functions realized as described above. For example, the information search condition input unit 20 corresponding to functions other than the used information search condition input unit 20 uses the saved narrow-down conditions used in the information search condition input unit 20 corresponding to functions such as search, aggregation, and analysis. But it can be reused. These reuses are realized as follows. As an outline, the used conditions are stored separately in the common condition part and the function specific condition part when registering in the registration condition DB 53. When calling up the stored conditions in a certain information search condition input unit 20, only the common condition part is extracted, and those that can be used in the information search condition input unit 20 on the calling side are specified from the common condition part. .

  The processing procedure of such a call is illustrated in the flowchart of FIG. That is, the information search condition input unit 20 calls the saved condition (step 71) and passes it to the display condition creation unit 50 (step 72). In practice, the condition is divided into a common condition part and a function specific condition part. (Step 73), although the common condition part (Step 74) can be used (Step 75), the condition part is passed to the display condition creation part (Step 76). As a premise now, the saved condition information is divided in advance into a common condition part and a function specific condition part as shown in FIG.

[2-3. Correction of conditions)
The conditions passed to the information search condition input unit 20 are processed according to the following flow, and finally, the information search condition input unit 20 displays the condition units that can be used there. First, the display condition creation unit 50 passes each field condition to the field definition unit 43 together with each field name used in the condition. Next, the field definition unit 43 acquires detailed information regarding the field from the field database 45 based on the field information passed from the display condition creation unit 50. From the detailed information obtained as described above, the field definition unit 43 acquires the parts of the display device (FIG. 2) corresponding to each field from the parts group of the input device part unit 47, and together with the conditions, the information search condition It is passed to the input unit 20. The information search condition input unit 20 provides the user with a screen in which the condition selected by the user is input.

  Through the procedure described above, a screen on which the condition selected by the user is input in advance can be displayed, and a part of the condition can be corrected. Another major feature is that an interface for inputting conditions, such as an appropriate and optimal GUI component, can be provided for each field information related to system information (various aspects when viewing information, category information). .

[2-4. (Reuse for aggregation of search criteria in search)
Next, a processing procedure for reusing the saved refinement condition used in the search function in the aggregation is illustrated in the flowchart of FIG. In this case, if the specific condition extracted from the condition DB is (step 91) the common condition part (step 92) and the field narrowing condition (step 93), information on the field is acquired from the field DB 45 (step 94). A condition input unit using a GUI component suitable for the narrow-down condition is passed to the information search condition input unit 20 together with the input value (step 95).

  If the condition extracted from the condition DB is not a common condition part (step 92), it is a search condition (step 96) and the condition part can be used (step 97). (Step 93), a value is passed to a specific input part of the condition input part (Step 98).

[2-5. Dynamic registration and calling of search conditions)
In addition, if the menu screen is dynamically changed by adding or deleting hyperlinks corresponding to the search conditions in the menu items, the search conditions registered and saved in this way and the results corresponding to them can be directly displayed. Can be called. Such a function is realized as follows.

  First, when the menu output unit 10 receives a user's request for changing a menu item, the menu output unit 10 instructs the menu creation unit 33 to update the menu to the latest information. Then, the menu creation unit 33 instructs the display condition creation unit 50 to select a condition for permitting display to the user. This selection results in, for example, a range of conditions and a display format according to the access authority and menu pattern associated with the user ID and department information recorded in advance in the user DB 55. In response to this, the display condition creating unit 50 acquires information from the target database and selects a condition to be displayed for each user. Then, the menu creation unit 33 creates menu items from the conditions to be displayed for each user and the information in the form DB 35, and the menu items created by the menu creation unit 33 are used by the menu output unit 10. Provide to By the procedure as described above, it is possible to dynamically change the menu item and always display the latest information.

  Here, an example of a processing procedure until the stored condition dynamically appears on the menu screen is illustrated in the flowchart of FIG. That is, the display condition creation unit 50 acquires the latest information on the registration conditions (step 101), and the menu creation unit 33 uses the registration conditions received from the display condition creation unit 50 (step 102) for which function. It is identified (step 103), the conditions registered for each function are classified (step 104), and the latest menu is provided to the user (step 105).

  As a result, the name of the saved condition is displayed for each function in the menu display portion of the screen. Therefore, for the conditions registered when using a certain function, if you want to see the result of the same function with the same refinement condition from the next time on, click the name of the information display device that was used before (Figure 2) That is, the latest result is displayed on the processing result screen. This makes it possible to quickly track information that changes every day.

[2-6. Menu output customization)
In this system, the output to the menu can be customized by applying various constraint conditions to the registered conditions. In other words, as an initial situation, it is assumed that all conditions used in a project using the system are always displayed and available to any user. However, if the system becomes large-scale and the number of users increases, the conditions to be stored may become very large, and the conditions that the user wants to use may differ from person to person.

  Therefore, by using user information such as user IDs and departments recorded in the user DB 55, it is possible to customize and narrow down the conditions displayed on the menu for each user or department. Access to the conditions becomes easier. That is, in such an example, the input / output means identifies the user and selects and narrows down according to the attribute recorded in advance for each individual user or user among the registered conditions. The condition is output as the object of reuse.

  First, an example of user information including the user ID is shown in FIG. Based on such user information, the customization as described above is realized by a processing procedure illustrated in FIG. In addition to the user information, a function for organizing information to be displayed may be added to the system from various viewpoints such as for each usage authority.

  The flowchart in FIG. 12 exemplifies a processing procedure for displaying a menu of conditions narrowed down for each department to which the user belongs. That is, the menu creation unit 33 that has received the latest information on the registration conditions (step 121) from the display condition creation unit 50 (step 122) identifies the function that the registration conditions were used for (step 123). ) Classifying the conditions registered for each function (step 124), providing the latest menu to the user (step 125), and using the user DB, the conditions to be output for each department to which the user belongs Narrow down (step 126).

  This makes it possible to reuse conditions that are narrowed down according to attributes such as individual users, departments, and usage rights. Protected.

[2-7. (Reuse of search conditions between systems)
In addition, when a new system is constructed based on the present invention, search conditions that have been used and stored in other similar systems can be reused. As a typical example, when a system is constructed for each department (organization) and used for many different types of projects implemented in the department, what kind of trouble each department is analyzing in other departments That is, there is a case where it is desired to refer to how the accumulated information is summed up or displayed in a graph for usefulness. Therefore, for example, paying attention to the similarity of the workflow of the system used for defect management, present the analysis status of defects in other departments in charge of projects close to that department in the system of a certain department .

  In such an example, a plurality of database systems as described above are connected in association with data of a predetermined workflow, and the number of stages and the number of activities representing the characteristics of each workflow based on each data. Similarity determination means (not shown) for determining the similarity between the workflows based on the above elements is provided, and the reuse of the condition relating to the registration is performed between the systems having a high similarity as the determination result.

  As a result, based on the similarity of the associated workflow, it is possible to refer to information retrieval, aggregation, analysis, etc. in departments with similar work, so the work efficiency of the departments using each system is effectively improved. Improved.

  Workflows vary in the complexity of the flow for each department depending on the number of users and the influence of the development process. Therefore, as an index indicating the degree of similarity of the workflow, considering the number of workflow stages, the total number of activities, the total number of branch source activities, the total number of branch destination activities, and the total number of activities with “return”, the similarity of workflows Is determined. An explanation of each of these indices is illustrated in FIG. From these indices, for example, the display condition creation unit 50 of each system calculates the similarity of the workflow and presents information on the systems of other departments with which the workflow is similar.

[2-8. Screen example)
Next, a description will be given of a procedure until the used narrowing conditions are saved and the saved narrowing conditions are reused, and an example of a screen in each procedure. This example assumes the following cases. This is a database that handles defect information that represents the contents of bugs (defects) in the development of a software system. Each defect information includes information items called defect numbers and bug ranks such as A, B, and C that indicate the importance of the defects. Is included. In this case, the condition used in the search “search for defect information whose defect number is between 1 and 100 and bug rank A” is registered, the registered condition is reused in the aggregation, and the result is This is the output case.

[2-8-1. (Overview)
In such re-use of conditions, the narrow-down conditions used in search, aggregation, and analysis are registered as shown in FIG. 14, and in subsequent searches, aggregation, and analysis, they are registered as shown in FIG. Select narrow-down conditions and reuse them on the input screen. Hereinafter, description will be made with reference to the drawings of each screen example. In the following description, the reference numerals of the circled numbers are represented as (1) and (2).

[2-8-2. Enter search conditions)
First, FIG. 16 shows a search condition input screen. This search is to display a list of information narrowed down under a specific condition among stored defect information. The common condition part corresponds to part (1) on this screen, and narrows down the stored information using various category information, and is input using a web page input column or a selection box.
In the case of this screen example,
・ Defect number from 1 to 100 ・ Bug rank is A
The condition of displaying a list of defect information corresponding to is specified.

  Further, (2) of the screen example is a part for specifying which items and which items are included in which order in the list display in the specific function condition part of the search function. After specifying these items, a search is executed by the “search execution” button (3) in the screen example.

[2-8-3. (Search results screen under the entered conditions)
As a result of the above button operation, a list is displayed on a search result screen as illustrated in FIG. In this screen, the narrowed down information is displayed in a list according to the common condition part and unique function condition part input in the screen example of FIG. When the “search condition registration” button (1) in the screen example of FIG. 17 is pressed, the conditions used this time, that is, the common condition part and the unique function condition part can be registered with desired names.

  FIG. 18 is a screen showing that the registration for the used search condition is completed with the name “bug rank A bug reference”. The detailed information on the used conditions is displayed again on this screen. In the same procedure, conditions used in the aggregation function and analysis function as well as the search function can be registered.

[2-8-4. (Entering aggregation conditions)
It is assumed that the conditions registered as described above are recalled for reuse by other, for example, a counting function. For example, FIG. 19 shows a condition input screen for counting. Aggregation displays information narrowed down under specific conditions among stored defect information in a table format. In this screen, the common condition part corresponds to the part (1) and narrows down the stored information using search conditions such as various category information. Moreover, (2) in this screen example corresponds to the unique function condition part of the totaling function, and selects vertical and horizontal category information of the table. In order to reuse the previously registered condition from this input screen, the button “3. Registration condition list” is selected.

[2-8-5. (List of filtering conditions)
The screen example of FIG. 20 is displayed when the (3) “Registration condition list” button is pressed on the screen of FIG. This screen is a list of registered narrowing conditions, and all the conditions are listed in common regardless of whether the registration or its call is a search function or an aggregation function. For example, even in the conditions used in the search function before, whether or not it is a target that can be reused in common with each function is automatically judged according to the pattern such as the combination of the fields that are configured. It can also be used for aggregation and analysis functions.

  The common condition part may have very detailed settings depending on how it is used. In particular, in such a case, the same or close common condition part is reused. There are many cases where it is desired to change the type of display or graph display. In such a case, the reuse of such conditions works very effectively. On the screen of FIG. 20, by clicking the “reuse” link of (1) corresponding to the desired condition, the usable part of the specified condition can be reused.

[2-8-6. Example of conditional reuse)
FIG. 21 shows an example of a totaling condition input screen for reusing the condition “bug defect A defect reference” selected for reuse in FIG. 20 as a search condition in the totaling function. That is, in this screen example, the conditions registered in FIG. 17 and FIG. 18, that is, the narrowing-down conditions of defect information with defect numbers 1 to 100 and bug rank A are reused by the aggregation function. In this screen example, the common condition part of the search condition used in the past is called in the common condition part (1). On this screen, by selecting the vertical and horizontal category information to be aggregated and executing the aggregation, the aggregation result can be output.

  The category information is typically a field that is a reference for tabulation. For example, when “discoverer” is specified, the number of hits for each item having the same value of the field “discoverer” becomes the tabulation result. FIG. 22 shows an example of a tabulation result screen when execution of tabulation only in the vertical category is selected in FIG. 21 and “discoverer” is selected as category information. That is, FIG. 22 is an example of a screen that narrows down the conditions specified in FIG. 21 and displays the tabulation results in a table format. The category information of the discoverer is displayed vertically, and the number of defects for each discoverer is displayed.

[3. effect〕
In the present embodiment as described above, the stored search conditions can be reused for different information display functions such as data aggregation and analysis. For example, the common part set in detail is used as it is, and the reuse such as changing only the way of viewing data such as a list or a graph display becomes easy. For this reason, operations such as condition specification are greatly improved, and the time until the output of the result desired by the user is effectively shortened. In particular, if applied to the development of software systems that require various ways of showing information, further effects can be expected.

  In the present embodiment, conditions registered in each process such as search, aggregation, and analysis are dynamically reflected in the menu screen in addition to the menu items as, for example, hyperlinks in the WWW (World Wide Web). (FIG. 23). For example, by clicking the link, you can jump to the screen for confirming, editing, and executing the condition, and meet the selected condition without going through the normal condition input screen for each function. The result is easily obtained, so that the operation is greatly improved.

The functional block diagram which shows the structure of embodiment of this invention. The conceptual diagram which shows an example of a mode that each function is implement | achieved in embodiment of this invention. The figure which shows the example of the field definition in form DB in embodiment of this invention. The figure which shows the example of field DB in embodiment of this invention. The flowchart which illustrates the process sequence of the search of the information in embodiment of this invention The flowchart which illustrates the process sequence of the total of the information in embodiment of this invention. The flowchart which illustrates the process sequence which the information search condition input part calls the conditions preserve | saved in embodiment of this invention. The figure which illustrates the condition information preserve | saved in embodiment of this invention. 6 is a flowchart illustrating a processing procedure for reusing a refinement condition used and stored in a search function according to an embodiment of the present invention. The flowchart which illustrates the process sequence until the preserve | saved conditions appear dynamically on a menu screen in embodiment of this invention. The figure which illustrates user information in the embodiment of the present invention. 6 is a flowchart for displaying a menu of conditions narrowed down for each department to which a user belongs in the embodiment of the present invention. The figure which shows the parameter | index which determines the similarity of a workflow in embodiment of this invention. The conceptual diagram which shows a mode that a condition is registered for reuse from each function, such as a search and a total, in embodiment of this invention. The conceptual diagram which shows a mode that the registered conditions are selectively called and reused in embodiment of this invention. The figure which shows the example of a screen of search condition input in embodiment of this invention. The figure which shows the example of a screen of the search result display on the input conditions in embodiment of this invention. The figure which shows the example of the registration completion screen of the used search conditions in embodiment of this invention. The figure which shows the example of the input screen of total conditions in embodiment of this invention. The figure which shows the example of the list screen of the registered narrowing-down conditions in embodiment of this invention. The figure which shows the example of a screen which shows reuse of the search conditions in the function of a total in embodiment of this invention. The figure which shows the example of a screen of a total result in embodiment of this invention. The figure which shows the search condition designation | designated screen in which the link to the registered conditions was dynamically displayed in embodiment of this invention.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 ... User 10 ... Menu output part 20 ... Information search condition input part 30 ... Registration part 33 ... Dedicated protocol conversion part 35 ... Form DB
40 ... Reuse unit 43 ... Field definition unit 45 ... Field DB
47 ... Input device component part 50 ... Display condition creation part 53 ... Registration condition DB
55 ... User DB

Claims (7)

In a database system that realizes two or more functions including data search, aggregation, and analysis based on operations and conditions, respectively,
Registration means for registering the condition used in the function;
Reuse means for reusing as a condition of the other function by accepting a call and modification according to a given operation for the registered condition;
A database system characterized by realizing a computer. The registration means is configured to divide and register the condition into a common condition part common to the functions and a function specific condition part specific to any of the functions,
The database system according to claim 1, wherein the reuse unit is configured to call the common condition part as the reuse target.   A menu screen for displaying the operation and the condition is displayed, and menu means for dynamically changing the menu screen by adding a menu item for calling the registered condition or a result using the condition is provided. The database system according to claim 1.   The menu means identifies the user, and among the registered conditions, the individual user or the condition selected and narrowed according to the attribute recorded in advance for the user is set as the object of reuse. The database system according to any one of claims 1 to 3, wherein the database system is output.   A plurality of database systems according to any one of claims 1 to 4 are connected in association with data of a predetermined workflow, and the number of stages related to the number of stages and the number of activities representing the characteristics of each workflow based on the data A database system comprising: similarity determination means for determining the similarity between workflows based on the database, and performing the reuse of the conditions relating to the registration between the systems having a high similarity as the determination result . In a data processing method that realizes two or more functions including retrieval, aggregation, and analysis of data based on operations and conditions, respectively,
A process of registering the condition used in the function;
Regarding the registered condition, a process of reusing it as a condition of the other function by accepting a call and correction according to a given operation;
A data processing method characterized in that a computer executes. In a data processing program that realizes two or more functions including data retrieval, aggregation, and analysis by controlling a computer based on operations and conditions, respectively,
The program is stored in the computer,
Register the conditions used in the function,
A data processing program characterized in that the registered condition is reused as a condition of another function by calling and accepting correction according to a given operation.

Images