JP2020112890A - Data processing program, data output device, data integration method, output program, data output method, data processing system - Google Patents

Abstract

To provide a data processing program or the like for extracting useful data items only and storing the extracted data items in an integrated data base for each type of items while integrating the data items for each type.SOLUTION: The data processing program acquires a plurality of types of data including each of a plurality of data items from each of the plurality of data bases, extracts useful data items only previously determined for each of the types, and integrates the extracted data items of respective types to store them in integrated data bases for respective types.SELECTED DRAWING: Figure 12

Description

The present invention relates to a data processing program and the like for performing processing on an integrated database that integrates data.

In data analysis, correct analysis is based on correct data. A data cleansing technique for generating a data-analyzable data set from original data has been proposed (for example, Patent Document 1). Further, in order to obtain correct data, an integrated database in which a plurality of databases that handle the same kind of data are integrated into one is also proposed (for example, Patent Document 2).

JP, 2013-175096, A JP, 2006-18340, A

The conventional data cleansing technology aims to eliminate illegal data. Further, the integrated database increases the number of items (the number of columns) per record by integrating a plurality of databases. The integrated database with data cleansing includes many records of many items.

Therefore, it is difficult to select useful items from all items when performing analysis using the data in the integrated database. The present invention has been made in view of such circumstances. The purpose is to provide a data processing program or the like that extracts only useful data items and stores the extracted data items by integrating them in an integrated database for each type.

A data processing program according to the present invention acquires a plurality of types of data including a plurality of data items from each of a plurality of databases, extracts only useful data items that are predetermined for each type, and extracts the extracted data items as a type. The data is integrated and stored in each integrated database.

According to the present invention, the extracted data items can be integrated and stored in the integrated database for each type.

It is explanatory drawing which shows the structural example of a performance platform. It is a block diagram which shows the hardware structural example of a data provision server. It is explanatory drawing which shows a data integration function. It is explanatory drawing which shows the example of an integrated database. It is explanatory drawing which shows a data provision function. It is explanatory drawing which shows the example of collection system DB. It is explanatory drawing which shows the example of conversion rule DB. It is explanatory drawing which shows the example of calculation formula DB. It is explanatory drawing which shows the example of evaluation rule DB. It is explanatory drawing which shows the example of warning destination DB. It is explanatory drawing which shows the example of provision rule DB. It is a flow chart which shows the example of a procedure of data collection processing. It is a flow chart which shows the example of a procedure of conversion storage processing. It is a flow chart which shows the example of a procedure of data offer processing. It is a flow chart which shows the example of a procedure of evaluation processing. It is a flow chart which shows the example of a procedure of warning processing. It is explanatory drawing which shows the structure of a service provision base. It is a block diagram which shows the hardware structural example of a portal server. It is a block diagram which shows the hardware structural example of a batch server. It is explanatory drawing which shows the example of Robo DB. It is explanatory drawing which shows the example of utilization robot DB. It is explanatory drawing which shows the example of setting DB. It is explanatory drawing which shows the example of a robot list screen. It is explanatory drawing which shows the example of a robo setting screen. It is a flow chart which shows the example of a procedure of Robo setting processing. It is explanatory drawing which shows the example of log DB. It is a flow chart which shows the example of a procedure of evaluation value adjustment processing. It is explanatory drawing which shows the example of report DB. It is a flow chart which shows the example of a procedure of report total processing. It is a block diagram which shows the hardware structural example of an application server. It is explanatory drawing which shows the example of a user different notation DB. It is explanatory drawing which shows the example of conversion DB. It is a flow chart which shows the example of a procedure of search processing. It is a flow chart which shows the example of a procedure of supplier search processing. It is explanatory drawing which shows the example of a supplier search process.

Hereinafter, embodiments will be described with reference to the drawings.

Embodiment 1
FIG. 1 is an explanatory diagram showing a configuration example of an achievement platform. The achievement platform 100 includes a data providing server (data output device) 1, an integrated database 2, a user terminal 3 and various cloud services 4. The data providing server 1, the integrated database 2, the user terminal 3, and the various cloud services 4 are communicably connected to each other via a network N such as the Internet or a telephone public network. The various cloud services 4 include various systems such as a reservation system, POS system, attendance system, accounting system, payroll system, ordering system, anti-company information system, HR system, and credit information system.

The integrated database 2 is a database in which formats and items of data of a plurality of types collected from databases managed by a plurality of systems included in various cloud services 4 are unified and stored for each type. The integrated database 2 stores POS (Point of sale) data, attendance data, reservation data, accounting data, HR (Human Resources) data, anti-social data, and the like. The POS data is sales performance data including a product name, price, quantity, sales date and time collected from a POS register installed at a store or the like. Attendance data includes time and attendance time, attendance time, break time, overtime hours, etc. of each employee. The reservation data includes the number of reservations, the number of reservations, the reservation menu, the estimated sales amount, etc. for each store and each time period. Accounting data includes balance sheets, income statements, cash flow statements, etc. Further, the accounting data includes a sales/accounts receivable table, purchase data, inventory data, cash accounting data, etc., which are necessary when preparing a balance sheet, an income statement, and a cash flow statement. The HR data includes data related to human resources such as salary of each employee, position, assignment, performance for each predetermined period, and personnel evaluation. The anti-social data includes information such as whether the management includes persons related to anti-social forces, whether there is a business relationship with anti-social forces, and whether anti-social activities have been performed in the past. .. The data stored in the integrated database 2 is a data generation source and is associated with the user ID of the user who is the data holder. For example, if ABC Corporation uses the accounting system of Kosha and provides accounting data to the integrated database 2 via the system, the holder of the accounting data is Kosha, and User IDs are associated with each other.

The data stored in the integrated database 2 stores not only the latest data but also past data. For example, the balance sheet included in the accounting data includes data having different update frequencies. That is, it also includes daily data for each day, weekly data for every week, monthly data for every month, and annual data for every year. For example, it includes data that is updated almost in real time, such as POS data, and annual data such as balance sheet, income statement, and cash flow statement that are accounting data created at the time of settlement. Also, items that overlap between different types may be included. For example, the accounting data may include the daily sales amount, and the POS data may include the daily sales amount in which the daily sales amount is aggregated.

FIG. 2 is a block diagram showing a hardware configuration example of the data providing server 1. The data providing server 1 is composed of a server computer or the like. The data providing server 1 includes a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12, a RAM (Random Access Memory) 13, a large-capacity storage unit 14, a communication unit 15, and a reading unit 16. The components are connected by a bus B. The data providing server 1 may be composed of a plurality of computers. Further, the data providing server 1 may be a virtual machine. Furthermore, the function of the data providing server 1 may be provided by a cloud service.

The CPU 11 controls each part of the hardware according to the control program 1P stored in the ROM 12. The RAM 13 is, for example, SRAM (Static RAM), DRAM (Dynamic RAM), or flash memory. The RAM 13 temporarily stores data generated when the CPU 11 executes the program.

The large-capacity storage unit 14 is, for example, a hard disk or an SSD (Solid State Drive). The large-capacity storage unit 14 stores various databases (DB: Data Base). The large-capacity storage unit 14 stores a collection method DB 141, a conversion rule DB 142, a calculation expression DB 143, an evaluation rule DB 144, a warning destination DB 145, and a provision rule DB 146. Further, the control program 1P may be stored in the mass storage unit 14. The collection method DB 141 to the provision rule DB 146 may be stored in other than the data providing server 1. For example, it may be stored in a database server or cloud storage.

The communication unit 15 communicates with the integrated database 2, the user terminal 3, and various cloud services 4 via the network N. Alternatively, the CPU 11 may use the communication unit 15 to download the control program 1P from another computer via the network N or the like and store the control program 1P in the large capacity storage unit 14.

The reading unit 16 reads the portable storage medium 1a including a CD (Compact Disc)-ROM and a DVD (Digital Versatile Disc)-ROM. The CPU 11 may read the control program 1P from the portable storage medium 1a via the reading unit 16 and store it in the large-capacity storage unit 14. Further, the CPU 11 may read the control program 1P from the semiconductor memory 1b.

The functions provided by the achievement platform 100 include a data integration function and a data providing function. The data integration function is a function of collecting data of a plurality of types from a plurality of databases, unifying formats and items, and storing the data in the integrated database 2 for each type. The data providing function is a function of providing the data stored in the integrated database 2.

FIG. 3 is an explanatory diagram showing the data integration function. The data providing server 1 includes a collection unit 111, a conversion unit 112, a calculation unit 113, an evaluation unit 114, a warning unit 115, and a storage unit 116 as functional units that implement the data integration function. The collection unit 111 collects a plurality of types of data from a plurality of databases. In the example shown in FIG. 3, POS data is collected from a database managed by Company A/POS system, Company B/POS system, or the like. Attendance data is collected from a database managed by α company, attendance system, β company, attendance system, etc. Accounting data will be collected from databases managed by Kosha/accounting system, second company/accounting system, etc. Reservation data Yes Collect from the database managed by the company/reservation system and the company/reservation system. HR data is collected from the databases managed by A company/HR system and A company/HR system. Here, company A, company B, company α, company β, company A, company O, company I, company R, company A, and company A are assumed to be service providers. That is, the company A/POS system is used by a plurality of companies as users. The same applies to other systems. Also, the same company may provide multiple types of services. For example, Kosha may provide HR services in addition to accounting services. On the other hand, the same company may use a plurality of services. For example, the same company may use company A/POS system, company β/attendance system, company/reservation system, etc.

The conversion unit 112 converts the format of the data collected by the collection unit 111. Format conversion includes extracting useful items, converting units, and changing the order of data items. The calculation unit 113 obtains new item data from the collected data. For example, the sales per tsubo is calculated from the sales for each store and the number of tsubo. The evaluation unit 114 gives an evaluation value indicating the reliability of each data item. The storage unit 116 associates useful item data, new item data, and evaluation values with each other and stores them in the integrated database 2. In the integrated database 2, data of the same type is stored in the same database. For example, POS data is stored in the same POS-DB for both the data collected from the POS system of Company A and the data collected from the POS system of Company B. Both the data collected from the POS system of Company A and the data collected from the POS system of Company B are stored in the same unit of data item and value. The warning unit 115 gives a warning when there is a data item whose evaluation value is lower than a predetermined threshold value.

FIG. 4 is an explanatory diagram showing an example of the integrated database 2. The integrated database 2 includes a POS-DB 21, attendance DB 22, accounting DB 23, reservation DB 24, HR-DB 25, word-of-mouth DB 26, anti-social information DB 27, and account information DB 28. The POS-DB 21 stores POS data collected from the POS system. The attendance DB 22 stores attendance data collected from the attendance system. The accounting DB 23 stores accounting data collected from the accounting system. The reservation DB 24 stores the reservation data collected from the reservation system. The HR-DB 25 stores the data collected from the HR system. The word-of-mouth DB 26 stores word-of-mouth data collected from the word-of-mouth system. The anti-social information DB 27 stores anti-social data collected from the anti-social information system. The account information DB 28 stores account information (account data) collected from the internet banking system. The account information includes deposit/withdrawal history and balance. As described above, the integrated database 2 stores the data collected from a plurality of POS systems in the same POS-DB 21. As a result, the items included in the POS data and the values for each item are unified. Further, the data collected by the integrated database 2 is provided by the data providing server 1 from various cloud services 4 with the understanding of the user who is the data holder.

FIG. 5 is an explanatory diagram showing the data providing function. The data providing server 1 includes a reception unit 117, an acquisition unit 118, an output conversion unit 119, and a response unit 11A as functional units that realize the data provision function. The accepting unit 117 accepts a data request from various application software (hereinafter, also referred to as “app”) via the communication unit 15. For example, the reception unit 117 provides a Web API (Web Application Programming Interface). The company a application (company a application program), the company b application (company b application program), and the company c application (company c application program) each make a data request to the data providing server 1 by the Web API. The a-company application, the b-company application, and the c-company application have previously acquired the usage right of the Web API, and are assigned with an application ID or the like indicating them. The acquisition unit 118 reads out the data corresponding to the received data request from the integrated database 2. The output conversion unit 119 converts the read data format into an output format as necessary. The response unit 11A generates a response message including the data to be output. The generated response message is returned to the application that requested the data via the communication unit 15.

Next, the database used in the processing for realizing the data integration function and the data providing function will be described. FIG. 6 is an explanatory diagram showing an example of the collection method DB. The collection method DB 141 stores a collection method used when collecting data from databases managed by various cloud services 4. The collection method DB 141 includes a system column, a type column, a type column, and a conversion rule column. The system column stores identification information of a data collection destination, for example, a system name. The type column stores the collection method. For example, file means collection by file inclusion. For example, the various cloud services 4 write files in a network shared folder. The data providing server 1 monitors the network shared folder and fetches the file when it is written. The type column stores the type of data to be collected. For example, type POS, accounting, attendance, reservation, HR, etc. The conversion rule string stores IDs of conversion rules. The ID is an ID that identifies a conversion rule when converting the collected data.

FIG. 7 is an explanatory diagram showing an example of the conversion rule DB. The conversion rule DB 142 stores conversion rules for converting the collected data into a format stored in the integrated database 2. The conversion rule DB 142 includes an ID column, an item number column, an item column, a processing column, and an output item number column. The ID column stores an ID that uniquely identifies the conversion rule. The item number column stores the sequence number of the items included in the collected data. The item string stores item names indicating item contents. The process column stores the process performed for each item. Discard indicates that the item is discarded and is not stored in the integrated database 2. The item number change indicates that the order of items is changed. The calculation indicates that the item is calculated and obtained from a plurality of items. The output item number column indicates the order of arrangement of the items in the output data.

FIG. 8 is an explanatory diagram showing an example of the calculation formula DB. The calculation formula DB 143 stores the calculation formulas for the items calculated and obtained when converting the collected data. The calculation formula DB 143 includes a calculation value sequence and a formula sequence. The calculated value sequence stores information for identifying the item to be calculated, for example, item name. The formula string stores the formula for calculation. The example shown in FIG. 8 indicates that the sales per tsubo is calculated by dividing the sales by the number of tsubo. Since the grammage is static data, sales and grammage may not be included in the same data. In such a case, the basis weight data is acquired from a store master database (not shown) that stores store information.

FIG. 9 is an explanatory diagram showing an example of the evaluation rule DB. The evaluation rule DB 144 stores a rule for obtaining an evaluation value indicating the reliability of a data item. The evaluation rule DB 144 includes a type column, an item column, a default column, an evaluation method column, and a processing column. The type column stores the data type. The data types are POS, attendance, reservation, accounting, HR, etc. The item string stores item names. The default column stores the default evaluation value. The default evaluation value is a value set when reliability evaluation cannot be performed due to the fact that there is no other type data or the like. The evaluation method column stores a method for performing reliability evaluation. The processing column stores the processing for obtaining the evaluation value. The example shown in FIG. 9 shows a method for evaluating the reliability of sales included in accounting data. The evaluation value is 1 to 5, and 5 indicates the highest reliability. The default value for evaluation is 3. The evaluation method is a comparison with POS. Here, it is premised that not only the accounting data but also the POS data of the company to be processed is stored in the POS-DB 21. When the monthly sales included in the accounting data is acquired, the sales data for the period corresponding to the monthly is acquired from the POS data, the acquired sales data is aggregated, and the monthly sales are calculated based on the POS data. .. Then, the deviation rate between the monthly sales included in the accounting data and the monthly sales based on the POS data is obtained. For example, the divergence rate=(difference between two sales)/(accounting data sales)×100. If the deviation rate is less than 5%, the evaluation value is set to 5. If the deviation rate is less than 10%, the evaluation value is set to 4. If the deviation rate is 10% or more, the evaluation value is 2. If the deviation rate is 15% or less, the evaluation value is 1. And give a warning. Here, the evaluation value becomes the default value only when the evaluation cannot be performed, but a deviation rate at which the evaluation value becomes 3 may be defined. Although the default value is 3, it may be changed for each data item. There are data items that are considered to have high reliability and data items that are considered to have low reliability as a general evaluation, depending on the structure of data generation, management method, and whether or not to be audited. Is. The default value may be set in consideration of such general evaluation. Furthermore, the evaluation value may be determined in consideration of the general evaluation.

FIG. 10 is an explanatory diagram showing an example of the warning destination DB. The warning destination DB 145 stores information on a warning destination when a warning is issued. Warnings will be sent by email. The warning destination DB 145 includes a user ID column and a mail address column. The user ID column stores a user ID that uniquely identifies the user. The user mentioned here is a company using various cloud services 4. That is, it is a company in which some data is stored in the integrated database 2. The e-mail address column may store the e-mail address to which the warning is to be sent. The warning may be displayed in a pop-up when the application is started. Alerts may be sent using push notifications. The alert destination may be sent to the administrator of the achievement platform or the administrator of various related cloud services 4 in addition to the user. Alternatively, the information may not be sent to the user, but may be sent to the administrator of the achievement platform or the administrator of various related cloud services 4. For example, if it is determined that the reliability of the sales of accounting data is low due to an abnormal value of POS data due to a system abnormality, the POS system administrator is not notified to the user. This is because it is appropriate to notify. If the cause of the POS data abnormality is not the system abnormality, the POS system administrator may notify the user.

FIG. 11 is an explanatory diagram showing an example of the provision rule DB. The provision rule DB 146 stores the rules defining the provision function of the data stored in the integrated database 2. The provision rule DB 146 includes a function column, a method column, a name column, an argument column, and a return column. The function column stores the names of the provided functions. The method column stores a data providing method. The providing method is API, file, electronic mail, or the like. In the API of the providing method, the user calls a function defined in the providing rule DB 146 and receives data as a return value. For example, the API is a Web API that uses HTTP (Hypertext Transfer Protocol). The file of the providing method is a method in which the file is output to the shared folder and read by the file user. For example, execute a command with a remote shell. In the case of the electronic mail provided, the user sends an electronic mail in which a command designating the data desired to be read is written. The read data is returned as the body of the email or the attached file. In the case of the electronic mail system, the data providing server 1 or another server may send and receive the mail on the achievement platform. The name column stores function names and command names. The argument string stores the arguments of the function or command. The return column stores the content of the returned value. The example of FIG. 11 shows that getAmntOfSalseM is prepared as a function of the API for acquiring the sales amount. The argument of the API function indicates the company code, type, and year/month. The type specifies, for example, a company-wide value or a specific business unit value. The return value of the API function indicates the company code, year/month, sales amount, and evaluation value. The evaluation value is a value indicating the reliability of data. For example, the evaluation value has five levels. If the reliability is higher, the evaluation value is 5. When the reliability is the lowest, the evaluation value is 1.

Next, the data processing performed by the achievement platform 100 will be described using a flowchart.

(Data collection process)
FIG. 12 is a flowchart showing a procedure example of the data collection process. The data collection process is called at a timing suitable for the collection method. Also, when the data collection process is called, information that specifies the collection method shall be passed. The CPU 11 of the data providing server 1 determines whether the collection method is the file method (step S1). CPU11 takes in a file, when it determines with a file system (it is YES at step S1) (step S2). A conversion storage process is performed on the data of the file loaded by the CPU 11 (step S3). The CPU 11 deletes the file that has been converted and stored (step S4). The CPU 11 determines whether there is an unprocessed file (step S5). When the CPU 11 determines that there is an unprocessed file (YES in step S5), the process is returned to step S2, and the process for the unprocessed file is performed. When the CPU 11 determines that there is no unprocessed file (NO in step S5), the process ends. When it is determined that the file method is not the file method (NO in step S1), the CPU 11 determines whether the collection method is the mail method (step S6). When the CPU 11 determines that the collecting method is the mail method (YES in step S6), the CPU 11 fetches the received mail (step S7). The CPU 11 performs a conversion storage process on the received mail data (step S8). The CPU 11 deletes the mail for which the conversion storage process has been completed (step S9). The CPU 11 determines whether there is an unprocessed mail (step S10). When the CPU 11 determines that there is an unprocessed mail (YES in step S10), the process returns to step S7 and the process for the unprocessed mail is performed. When the CPU 11 determines that there is no unprocessed mail (NO in step S10), the process ends. When the CPU 11 determines that the collection method is not the mail method (NO in step S6), it determines whether it is the API calling method (step S11). The API calling method is a method in which the various cloud services 4 on the data collecting side call the API of the data providing server 1 and execute the collecting process when the data is ready. When the CPU 11 determines that the collection method is the API calling method (YES in step S11), it fetches data from the various cloud services 4 (step S12). The data to be captured is stored in the shared folder. Alternatively, it is included in the API argument or the like. The CPU 11 performs conversion storage processing on the captured data (step S13). The CPU 11 returns the completion of conversion (step S14). When the CPU 11 determines that the collection method is not the API calling method (NO in step S11), it executes the API (step S15). The API to execute is passed as an argument. Alternatively, it is stored in the mass storage unit 14. The CPU 11 acquires data as the execution result of the API (step S16). The data is included in the return value. The CPU 11 performs conversion storage processing on the acquired data (step S17). The CPU 11 ends the process. The determination of the collection method may be performed as follows. The argument when starting the data collection process is the system name of the collection destination. The CPU 11 searches the collection method DB 141 using the system name, acquires the collection method stored in the type column, and makes a determination.

FIG. 13 is a flowchart showing a procedure example of the conversion storage process. FIG. 13 shows the details of the processing performed in step S3, step S8, step S13, and step S17 of FIG. The CPU 11 acquires the name of the system that created the data to be processed (step S31). The system name is acquired by a method suitable for the collection method. For example, the system name is included at the beginning or end of the acquired data. Further, the file name at the time of importing the file and the system name are passed as an argument when the API for importing the data is called. The information acquired in S31 is not limited to the name as long as it identifies the system. The ID may be a combination of alphanumeric characters. The CPU 11 acquires the conversion rule corresponding to the acquired system name (step S32). The CPU 11 acquires the ID of the conversion rule from the collection method DB 141 using the system name, and searches the conversion rule DB 142 using the acquired ID to obtain the conversion rule. The CPU 11 performs conversion/calculation (step S33). The CPU 11 converts the format of the acquired data based on the acquired conversion rule. Here, the calculation of the index value obtained from the acquired data is also included. The CPU 11 stores the data for which the format conversion including the calculation of the index value is completed in the integrated database 2 (step S34). The CPU 11 ends the conversion storage process and returns the process to the calling source.

A specific example of the data collection process will be described. Data collection from Company A's POS system is taken as an example. As defined in the collection method DB 141 (FIG. 6), data is collected from the company A/POS system in a file method. The conversion rule is CNV001. The contents of the conversion rule CNV001 are defined in the conversion rule DB 142. Item number 1 of the acquired data collected from Company A's POS system is sales. The sales item is also the output item number 1. Item number 2 of the acquired data is sales discount, which is discarded. Item number 3 is the sales deduction, which is also discarded. Item No. 4 is the cost of sales, and the output item No. is changed to become No. 2. Also, the sales per tsubo is an index value to be calculated, and is the output item number 10. The calculation method of the sales per tsubo is defined in the calculation formula DB 143 (FIG. 8). The unit price per tsubo is the sales divided by the number of tsubo. The grammage is stored in a store DB (not shown). When the processing according to the conversion rule is converted and the calculation is completed, it is stored in the integrated database 2.

(Data provision process)
FIG. 14 is a flowchart showing an example of the procedure of the data providing process. The data providing process is a process activated by a data request from the application software (hereinafter, referred to as “app”) of the user terminal 3. The processing here is data provision using API. The CPU 11 of the data providing server 1 acquires the function name of the function called by the API (step S51). The CPU 11 acquires the provision rule corresponding to the function name from the provision rule DB 146 (step S52). The CPU 11 interprets the argument according to the content of the argument string of the obtained provision rule (step S53). Here, the interpretation is a determination of the requested data content. The CPU 11 acquires data from the integrated database 2 based on the interpretation (step S54). The CPU 11 creates a return value according to the contents of the return column of the provision rule (step S55). The CPU 11 returns the return value (step S56) and ends the process.

Although omitted in the above description, authentication is necessary for the application of the user terminal 3 to request data. The user logs in to the data providing server 1 with the ID and the password, or the application stores the ID and the password and performs the login process when requesting the data. Alternatively, the application may store authentication information given in advance, and the authentication may be obtained by transmitting the authentication information to the data providing server 1. Not limited to these, other authentication mechanisms may be adopted.

A specific example of the data providing process will be described. This is the case where the API function getAmntOfSalseM is called from the user application. This function is a function to get monthly sales. As defined in the provision rule DB 146 (FIG. 11), the company code, type, and year/month are taken as arguments. Based on this, designation of a designated type (designation of the whole company or a specific business office, sales of accounting DB, sales of POS-DB, etc.) of a company designated from the integrated database 2 The sales for the specified year and month are acquired. At that time, an evaluation value indicating the reliability is also acquired. Then, as the return value, a value is generated and returned in the order of the company code, year/month, sales amount, and evaluation value.

(Effects of data collection and provision functions)
The data collection function of the achievement platform 100 collects a plurality of types of data such as attendance data, reservation data, accounting data, HR data, and antisocial data from a plurality of databases. At that time, discard items that are not useful for data analysis. In addition, an index value that is not included in the collected data but can be calculated and is useful for the data is calculated. Therefore, the integrated database 2 of the achievement platform 100 stores a variety of useful data that can be analyzed in various ways. Further, in the data providing function, data can be read from the integrated database 2 by an interface such as API, so that the user can easily develop an application using the data provided by the integrated database 2.

(Evaluation process)
The evaluation process in which the evaluation value is added will be described. The evaluation process is a process of adding an evaluation value indicating reliability to the data stored in the integrated database 2. FIG. 15 is a flowchart showing an example of the procedure of evaluation processing. The CPU 11 of the data providing server 1 acquires the type, item and value of the data to be evaluated (step S71). The CPU 11 searches the evaluation rule DB 144 and determines whether or not there is an evaluation rule for evaluating the evaluation target (step S72). When the CPU 11 determines that there is an evaluation rule (YES in step S72), it attempts to acquire evaluation data for performing evaluation based on the evaluation rule (step S73). The CPU 11 determines whether or not the evaluation data has been acquired (step S74). When determining that the evaluation data has been acquired (YES in step S74), the CPU 11 sets an evaluation value based on the evaluation rule (step S75). The CPU 11 determines whether a warning is necessary (step S76). For example, when the evaluation value is the lowest value, it is determined that a warning is necessary. The criterion for issuing a warning may be defined in the processing sequence of the evaluation rule DB 144. When the CPU 11 determines that a warning is necessary (YES in step S76), it performs warning processing (step S77) and ends the processing. When the CPU 11 determines that the warning is not necessary (NO in step S76), the process ends. When the CPU 11 determines that there is no evaluation rule (NO in step S72) or the CPU 11 determines that the evaluation data cannot be acquired (NO in step S74), the evaluation value is set to a default value (step S78). , The process ends. The default value is, for example, an intermediate value. If it is a 5-level evaluation, it is 3. It is desirable to perform the evaluation process when collecting data. In the conversion/calculation (step S33) of FIG. 13, an evaluation value is given.

(Warning process)
FIG. 16 is a flowchart showing an example of a procedure of warning processing. The CPU 11 creates a message notifying the warning (step S91). For example, the message includes the data type, the data item name, and the evaluation value. The CPU 11 searches the warning destination DB 145 by using the user ID associated with the warning target data as a search key, and acquires the mail address of the user who is the destination of the warning (step S92). The CPU 11 sends a warning message to the acquired mail address (step S93). The warning message may also be sent to the administrator of the performance platform. Instead of sending it directly to the user, the user's e-mail address and a warning message may be sent to the administrator, and the administrator may confirm that the system failure has not occurred before sending the warning message to the user. On the other hand, it is desirable that the department that receives the warning message from the user side includes the department in charge of compliance. This is because there is a possibility that the data has been intentionally tampered with for the purpose of fraud. From this point of view, it is desirable that the achievement platform 100 save the transmission history of the warning message for the predetermined period.

An example of the evaluation process will be described. The evaluation of the sales amount included in the accounting data (first type of data) is taken as an example. Suppose you have collected monthly sales figures for restaurants. In the evaluation rule DB 144 (FIG. 9), there is a record of type=accounting, item=sales. The evaluation method column of the record has POS contrast. That is, the sales amount based on the POS data (second type data) is acquired as the evaluation data. Monthly sales are calculated by adding up the hourly or daily sales in the target month from the POS data of the target restaurant. Then, the evaluation value is determined according to the contents of the processing sequence of the evaluation rule. It is possible to obtain the reliability of the sales amount of the accounting data by checking the data consistency with the sales amount (same data item) included in the POS data.

Since the evaluation value indicating the reliability of the data is given to the data held by the integrated database 2 of the performance platform 100 by the evaluation process, the user can estimate the reliability of the analysis result when performing the data analysis. .. For data with extremely low reliability, alert the administrator and the user of the data source to encourage improvement. Thereby, it is possible to improve the reliability of the integrated database 2 as a whole. Then, the improvement in reliability leads to an increase in the number of users, and the superiority as a database can be enhanced.

(Service provision platform)
As described above, since the achievement platform 100 is a data portal related to management, it is possible to provide various services. Next, a service providing infrastructure utilizing data will be described. FIG. 17 is an explanatory diagram showing the configuration of the service providing infrastructure. The service providing infrastructure includes a portal server 5 and a batch server 6. The portal server 5 may have the function without providing the batch server 6. The plurality of batch servers 6 is assumed when a plurality of different operators provide services.

FIG. 18 is a block diagram showing a hardware configuration example of the portal server. The portal server 5 is composed of a server computer or the like. The portal server 5 includes a CPU 51, a ROM 52, a RAM 53, a large capacity storage unit 54, a communication unit 55, and a reading unit 56. The components are connected by a bus B. In the following, description of the same configuration as the data providing server 1 will be omitted.

FIG. 19 is a block diagram showing a hardware configuration example of a batch server. The batch server 6 is composed of a server computer or the like. The batch server 6 includes a CPU 61, a ROM 62, a RAM 63, a large capacity storage unit 64, a communication unit 65, and a reading unit 66. The components are connected by a bus B. In the following, description of the same configuration as the data providing server 1 will be omitted.

Next, the database used by the service providing infrastructure will be described. FIG. 20 is an explanatory diagram showing an example of the robo DB 541. The robo DB 541 stores information about batch programs that operate on the batch server 6. The robo DB 541 is managed by the portal server 5. For example, the Robo DB 541 is stored in the large capacity storage unit 54. The robo DB 541 includes a robo ID column, a role column, a name column, an icon column, a provision column, an explanation column, an execution frequency column, and a necessary data column. The robo ID column stores a robo ID that can uniquely identify a batch program. The role string stores a character string expressing the function provided by the batch program as a role. The name column stores the name of the batch program. The icon column stores icons of batch programs. The offer column stores the providers of the batch programs. The explanation column stores the explanation sentence about the function of the batch program. The execution frequency column stores the recommended execution frequency of the batch program. The necessary data string stores necessary data when the batch program is executed.

FIG. 21 is an explanatory diagram showing an example of the usage robot DB. The usage robot DB 542 stores information on all batch programs used by the user. The usage robot DB 542 is managed by the portal server 5. For example, the usage robot DB 542 is stored in the large capacity storage unit 54. The usage robot DB 542 includes a user ID column and a robot ID column. The user ID column stores the user ID. The robo ID column stores the robo ID of the batch program used by the user.

FIG. 22 is an explanatory diagram showing an example of the setting DB. The setting DB 641 stores the execution setting of the batch program. The setting DB 641 is managed by the batch server 6 of each company that provides the batch program. The setting DB 641 is stored in, for example, the large capacity storage unit 64 of the batch server 6. The setting DB 641 includes a robot ID column, a user ID column, an execution frequency column, a previous column and a next column. The Robo ID column stores the Robo ID. The user ID column stores the user ID of the user who is using the batch program. The execution frequency column stores the execution frequency set by the user. The last column stores the last execution date. The next column stores the next execution date.

Next, the procedure for using the batch program will be described. The user logs in to the portal server from the user terminal 3. The user selects the robot list on the menu screen displayed after the login is completed. FIG. 23 is an explanatory diagram showing an example of the robo list screen. The robot list screen d01 includes a robot list d011, a selection box d012, an enter button d013, and a cancel button d014. The robot list d011 displays a list of provided batch programs. The selection box d012 is a check box for selecting a batch program to be used. The selection box d012 is displayed corresponding to each batch program. When the enter button d013 is selected, the selection result is transmitted to the portal server 5. When the cancel button d014 is selected, the operation is canceled and the screen returns to the menu screen.

FIG. 24 is an explanatory diagram showing an example of the robo setting screen. The robo setting screen d02 includes a robo display d021, an execution setting d022, a notification destination setting d023, an enter button d024, a cancel button d025, and a customize button d026. The robo display d021 displays the batch program selected on the robo list screen d01. The execution setting d022 sets the execution frequency. In the first menu d0221, select daily, weekly or monthly. The execution date is set in the second menu d0222. It is not necessary to set for daily. If weekly, specify the day of the week. If it is monthly, specify the date. The notification destination setting d023 sets the notification destination from the batch program. The default is a registered email address. If notification to another mail address or SNS is desired, the notification destination type menu d0231 is changed. Then, an e-mail address or SNS account is entered in the notification destination designation box d0232. When the enter button d024 is selected, the setting content is transmitted to the portal server 5. If the cancel button d025 is selected, the operation is canceled and the screen returns to the menu screen. When the customize button d026 is selected, a customize screen is displayed and the operation of the batch program can be customized.

FIG. 25 is a flowchart showing an example of the procedure of the robo setting process. When the user selects the robot list on the menu screen, the user terminal 3 transmits a list request to the portal server 5 (step S111). The CPU 51 of the portal server 5 creates a robot list screen by referring to the robot DB 541 (step S112). The CPU 51 transmits the robo list screen to the user terminal 3 (step S113). The user terminal 3 receives and displays the robot list screen (step S114). The user selects the batch program to use and operates the enter button. The user terminal 3 acquires the selection information (step S115), and transmits the acquired selection information to the portal server 5 (step S116). The CPU 51 of the portal server 5 receives the selection information (step S117). The CPU 51 confirms whether or not there is data necessary for executing the selected batch program (step S118). The CPU 51 acquires the type of the required data stored in the required data string of the robo DB 541 and confirms whether or not the data of the corresponding user is stored in the database corresponding to the type. For example, if POS and attendance are required, it is confirmed whether the data of the user is stored in the POS-DB 21 and attendance DB 22 of the integrated database 2. The CPU 51 determines whether or not the required data is insufficient (step S119). When the CPU 51 determines that the required data is not insufficient (NO in step S119), the process proceeds to step S122. When the CPU 51 determines that the required data is insufficient (YES in step S119), it cancels the selection of the batch program that cannot be executed due to insufficient data (step S120). The CPU 51 generates a message indicating that the selection has been canceled (step S121). The CPU 51 generates a robot setting screen (step S122). If step S121 has been executed, the generated message is included in the robo setting screen. The CPU 51 transmits the generated robot setting screen to the user terminal 3 (step S123). The user terminal 3 receives and displays the robo setting screen (step S124). The user makes settings on the robo setting screen and operates the enter button. The user terminal 3 acquires the setting (step S125) and transmits the setting to the portal server 5 (step S126). The portal server 5 receives the settings, transfers the settings to the corresponding batch server 6 for each batch program (step S127), and ends the process. The batch server 6 to which the settings have been transferred stores the settings in the setting DB 641.

(Example of batch program)
As an example of the batch program, a loan proposal robo will be described. The loan proposal robot is assumed to be a financial institution that provides loans. Loan Proposal Robo extracts promising companies as lenders and makes proposals. The operation of the loan proposing robot when the loan recipient is set as the food and drink business will be described below. The loan proposing robot acquires the sales amount of the latest company, for example, three months, from the POS-DB 21. Also, the confirmed sales amount for this month is acquired from the POS-DB 21. The reservation status is acquired from the reservation DB 24, and an undetermined sales amount of this month and an estimated value of the sales amount of the next month are obtained. Moreover, the account information of the processing target company is acquired from the account information DB 28, and the fund situation of this month is predicted based on the acquired account information. For example, it is predicted whether the working capital will be sufficient until the end of the month (fund prediction). Further, the loan proposing robot acquires the evaluation of the processing target company from the word-of-mouth DB 26. Loan Proposal Robo calculates the creditworthiness of a company based on the latest monthly sales, sales for this month and next month, and word-of-mouth evaluation by a scoring model established by financial institutions. Since the financial institution sets the credit line corresponding to the credit level, the loan proposing robot acquires the credit line (credit line) corresponding to the credit level. It is assumed that the latest monthly sales amount, the sales amount of this month and the next month, the word-of-mouth evaluation, and possible credit lines are stored in advance in the database. Loan Proposal Robo compares loan facility (interest rate 1.2%, maximum amount 3 million yen) and financial situation (expected short of 2.5 million yen), and if it finds a match, proposes to lend to the processing company Notify the financial institution of the message. The financial institution confirms the notice and, if appropriate, offers the loan to the company.

In the service providing platform, various batch programs (robots) can be used to improve the efficiency of various operations.

(Evaluation process by log)
A log (usage history) is taken for the data read from the application provision platform. The evaluation value indicating the reliability is adjusted by the log. FIG. 26 is an explanatory diagram showing an example of the log DB. The log DB 147 is stored in the large capacity storage unit 14 of the data providing server 1, for example. Each log stored in the log DB 147 is generated each time the data stored in the integrated database 2 is read. The log DB 147 includes a date column, a time column, a type column, an item column, a user column, a method column, and a reference user column. The date column stores the date when the data was read. The time column stores the time when the data was read. The type column stores the type of read data. The item string stores the items of the read data. The user column stores the user ID of the user who holds the read data. The method column stores the method of reading the data. The reference user column stores the user ID of the user who has read the data. If the user who has read the data cannot be specified, the robo ID of the batch program that has read the data is stored.

FIG. 27 is a flowchart showing a procedure example of the evaluation value adjustment processing. The evaluation value adjustment process is executed every predetermined period, for example, weekly or monthly. The CPU 11 of the data providing server 1 acquires the logs included in the aggregation period from the log DB 147 (step S131). If the evaluation value adjustment processing is executed weekly, the unprocessed log for the latest one week is acquired. The CPU 11 totals the number of times of reading for each owned user, each data type, and each item (step S132). The CPU 11 ranks by the number of times of reading (step S133). The CPU 11 adjusts the evaluation value according to the ranking (step S134) and ends the process. The evaluation value is adjusted, for example, as follows. The evaluation value of 0.1 is added to the data of the top 5 in the ranking of the number of times of reading, and the evaluation value of 0.1 is subtracted from the data of the bottom 5 of the ranking. Similarly, the evaluation value may be adjusted according to the ranking for each data type and each item.

FIG. 28 is an explanatory diagram showing an example of the notification DB. When the notification DB 148 receives a notification from the user that the data content is in doubt, it records it as a log. The notification DB 148 is stored in the large capacity storage unit 14 of the data providing server 1. The notification DB 148 includes a date column, a time column, a type column, an item column, a user column, and a notification user column. The date column stores the date when the notification was received. The time column records the time when the notification was received. The type column records the type of data for which the notification was received. The item column records the item of data for which the notification was received. The user column stores the user ID of the user who holds the notified data. The report user column stores the user ID of the user who made the report.

FIG. 29 is a flowchart showing an example of the procedure of the report totaling process. The report totaling process is executed every predetermined period, for example, weekly or monthly. The CPU 11 of the data providing server 1 acquires the notification log included in the aggregation period from the notification DB 148 (step S151). If the report totaling process is to be executed weekly, the unprocessed report logs for the latest one week are acquired. The CPU 11 totals the number of notifications for each user owned, each data type, and each item (step S152). The CPU 11 selects one of the aggregated data (step S153). The CPU 11 determines whether or not the number of notifications of the selected data is greater than or equal to the threshold value (step S154). When the CPU 11 determines that the number of notifications of the selected data is equal to or greater than the threshold value (YES in step S154), it updates the evaluation value of the corresponding data (step S155). For example, a value such as 0 or -1 which is not normally given is set. The CPU 11 gives a warning (step S156). The warning process is similar to the warning process shown in FIG. When the CPU 11 determines that the number of notifications of the selected data is less than the threshold value (NO in step S154), the process proceeds to step S157. The CPU 11 determines whether or not there is unprocessed data (step S157). When determining that there is unprocessed data (YES in step S157), the CPU 11 returns the process to step S153, and performs the process on the unprocessed data. When the CPU 11 determines that there is no unprocessed data (NO in step S157), the process ends. In addition, when totaling the number of times of notification, the number of times of notification may be once even if the same notification user has made multiple notifications to the same type and the same item of the same user. This is because the notification from only the same notification user may be low in reliability of the notification itself.

As described above, the reliability is changed according to the number of times of reading each data and the number of times of notification that there is doubt about the content (user evaluation). Thereby, the accuracy of reliability can be improved.

(Interactive provision function)
In the above, the batch program is shown as an example of using the data providing function of the achievement platform 100. The interactive providing function will be exemplified below. The interactive providing function is provided by the application server. FIG. 30 is a block diagram showing a hardware configuration example of the application server. The application server 7 provides an interactive application program. The application server 7 is composed of a server computer or the like. The application server 7 includes a CPU 71, a ROM 72, a RAM 73, a large capacity storage unit 74, a communication unit 75, and a reading unit 76. The components are connected by a bus B. In the following, description of the same configuration as the data providing server 1 will be omitted.

(Search function)
A search function will be described as an example of the interactive providing function. The search function searches the accounting DB 23 stored in the integrated database 2 for a search keyword related to business performance, for example, “A company's 2017 sales amount”, extracts the A company's 2017 sales amount, and returns it as a search result. It is a function.

First, the database used in the search function will be described. FIG. 31 is an explanatory diagram showing an example of the user different notation DB 741. The user different notation DB 741 is stored in the large-capacity storage unit 74 of the application server 7. The different user notation DB 741 stores various notations of the user in association with the user ID. The user different notation DB 741 includes a user ID sequence, a name sequence, an abbreviation/common name sequence, a securities code sequence, and a corporate number sequence. The user ID column stores the user ID. The name column stores the official name of the user. The abbreviation/common name column stores abbreviated names and common names of users. The securities code string stores the securities code of the user. It is blank for users whose securities code is not assigned. The corporation number column stores the corporation number of the user. The corporate number is a number based on the so-called number law and is designated by the Commissioner of the National Tax Agency. In addition to the corporation number, a TSR company code issued by Tokyo Shoko Research or a TDB company code issued by Teikoku Databank may be stored in the user different notation DB 741.

FIG. 32 is an explanatory diagram showing an example of the conversion DB. The conversion DB 742 is stored in the large capacity storage unit 74 of the application server 7. The conversion DB 742 stores a term for converting a search word that is supposed to be used into a notation suitable for a search. The conversion DB 742 includes a search word string, a type string, an item string, and a predetermined period string. The search word string stores search words that are expected to be used. The type column stores the type of data associated with the search term. The item string stores items associated with the search word. The predetermined period column stores a period condition to be supplemented when no period is specified in the search word. By using the conversion DB 742, the input of “Sales of company A” is converted to “accounting sales of company A 2017 fiscal year” (when the current year is 2018).

The search function is provided as follows. The user requests the search function from the user terminal 3 to the application server 7. The application server 7 transmits the search term input screen to the user terminal 3. The user inputs a search word on the input screen and operates a search button or the like. The user terminal 3 transmits the search word to the application server 7. The application server 7 performs a search based on the received search word and sends the search result to the user terminal 3.

FIG. 33 is a flowchart showing an example of the procedure of search processing. The CPU 71 of the application server 7 acquires the search term transmitted from the user terminal 3 (step S171). The CPU 71 converts the acquired search term (step S172). The CPU 71 compares the acquired search word with the search word string in the conversion DB 742, and if there is a match, performs conversion. An example of the conversion is as described above. The CPU 71 determines whether or not the type and item of the search target data have been specified based on the search word (step S173). When the CPU 71 determines that the type and item can be specified (YES in step S173), it searches the integrated database 2 (step S174). The CPU 71 transmits the acquired search result to the user terminal 3 (step S175) and ends the process. When the CPU 71 determines that the type and item are not specified (NO in step S173), it transmits that the search result is 0 to the user terminal 3 (step S176), and ends the process.

As described above, with the search function, various data stored in the integrated database 2 can be extracted by a user interface such as an Internet search engine. The search function can be used only by registered users of the achievement platform, but is not limited thereto. You may make it available to unregistered users with a certain restriction.

In the search function, the numerical value included in the search result may be subjected to arithmetic processing and the result may be output depending on the content of the search word. For example, if "2018 Ebisu Restaurant Gross Margin" is entered as the search condition, the 2018 gross margin for each restaurant in the Ebisu area is acquired and the gross margin of each restaurant is searched. Outputting as a result is a normally conceivable process. Instead, it outputs the average gross profit rate for restaurants in the Ebisu area in 2018. Whether or not the arithmetic processing is performed is determined by, for example, the search target. As in the example here, when the gross profit rate is searched, the value for each company or store is not output, but the average value of the values hit in the search is output.

(Financing support function)
The above-mentioned loan proposing robot proposes an appropriate company as a lender to a financial institution, but the financing support function is a function for a user who wants to receive a loan. As a preliminary step, the lending financial institution registers a scoring model on the performance platform to evaluate its eligibility as a lender. The scoring model including the processing program is stored in the mass storage unit 74 of the application server 7. Further, each financial institution permits the application server 7 to use the evaluation function based on the scoring model.

FIG. 34 is a flowchart showing an example of the procedure of supplier search processing. A user who wants to receive a loan selects the financing support function on the menu screen. The user terminal 3 transmits a function use request to the application server 7 (step S191). The CPU 71 of the application server 7 receives the usage request (step S192). The CPU 71 transmits an input screen for inputting desired loan conditions to the user terminal 3 (step S193). The user terminal 3 receives and displays the input screen (step S194). The user inputs desired loan conditions on the input screen and instructs transmission. The user terminal 3 acquires the input desired condition and transmits it to the application server 7 (step S195). The application server 7 receives the desired conditions (step S196). The CPU 71 of the application server 7 acquires the achievement information of the user from the integrated database 2 (step S197). The CPU 71 selects a financial institution (step S198). The CPU 71 receives the performance information of the user as input, and uses the scoring model of the selected financial institution to score the user (step S199). As a result of scoring, the CPU 71 determines whether or not a loan can be obtained from the financial institution selected by the user (step S200). For example, the CPU 71 determines whether the evaluation score obtained by scoring exceeds a threshold value. When the CPU 71 determines that the user does not receive the loan (NO in step S200), the process proceeds to step S204. When the CPU 71 determines that the user can receive the loan (YES in step S200), the CPU 71 acquires the loan line corresponding to the evaluation point (step S201). This is because the credit line may differ depending on the size of the loan, even if the evaluation score is the loanable score. The CPU 71 determines whether the acquired loan line meets the user's desired conditions (step S202). When the CPU 71 determines that the loan line does not meet the desired conditions (NO in step S202), the process proceeds to step S204. When the CPU 71 determines that the loan line meets the desired condition (YES in step S202), the CPU 71 stores information on the selected financial institution and loan line (step S203). The CPU 71 determines whether there is an unprocessed financial institution (step S204). When the CPU 71 determines that there is an unprocessed financial institution (YES in step S204), the process is returned to step S198, and the process for the unprocessed financial institution is performed. When the CPU 71 determines that there is no unprocessed financial institution (NO in step S204), the result is transmitted to the user terminal 3 (step S205). The user terminal 3 receives and displays the result (step S206).

An example of the supplier search process will be described. FIG. 35 is an explanatory diagram showing an example of the supplier search processing. In FIG. 35, the user who wants a loan is company A. The financial institutions are bank a, bank b and bank c. Company A inputs a desired condition 351 for financing. The application server 7 searches the integrated database 2 and acquires the performance information 352 of the company A necessary for scoring. In the case of information that is a necessary item but is not stored in the integrated database 2, the application server 7 requests the user to input, or obtains it from a plurality of items acquired from the integrated database 2. For example, whether or not the debt balance is within the range of annual sales can be determined by, for example, comparing the debt of the previous year's settlement data with the sales amount. The application server 7 scores the obtained performance information 352 of the company A by the scoring models of the bank a, the bank b, and the bank c. The application server 7 obtains a rating 353 for each item. Then, the application server 7 obtains the evaluation score 3541 based on the evaluation score. The application server 7 determines whether or not the loan can be made 3542 based on the evaluation score 3541. Furthermore, when the loan is available, the application server 7 obtains the loan limit, the user's desired condition and the matching result 3543. The evaluation point 3541, the loan approval/disapproval 3542, and the matching result 3543 are displayed on the user terminal 3 as the determination result 354. Further, the achievement platform has a function that allows the user to apply for a loan, and the application can be made from the display screen of the determination result 354. At that time, the determination result is transmitted to the financial institution.

As described above, the fund-raising support function enables a user who wants to procure funds to collectively check a fund-raising destination to which a loan can be received. Then, when the user applies for a loan, the determination result is sent to the financing source, so that the financing source can make a loan decision without conducting a new examination. Therefore, the user can surely receive the loan quickly.

Although the financing source is a loan from a financial institution, it is not limited thereto. Financing from venture capital is also acceptable. It may also include business plan contests and grant search functionality. In this case, it is determined whether or not the user satisfies the application conditions for the business plan contest and the application conditions for the subsidy.

The technical features (constituent elements) described in each embodiment can be combined with each other, and new technical features can be formed by combining them.
The embodiments disclosed this time are to be considered as illustrative in all points and not restrictive. The scope of the present invention is shown not by the above meaning but by the scope of the claims, and is intended to include meanings equivalent to the scope of the claims and all modifications within the scope.

100 Performance platform 1 Data providing server 11 CPU
111 collection unit 112 conversion unit 113 calculation unit 114 evaluation unit 115 warning unit 116 storage unit 117 reception unit 118 acquisition unit 119 output conversion unit 11A response unit 14 large capacity storage unit 141 collection method DB
142 Conversion Rule DB
143 Calculation formula DB
144 Evaluation Rule DB
145 Warning destination DB
146 Provision rule DB
147 log DB
148 Notification DB
15 communication unit 16 reading unit 1P control program 1a portable storage medium 1b semiconductor memory 2 integrated database 21 POS-DB
22 Attendance DB
23 Accounting DB
24 Reservation DB
25 HR-DB
26 Review DB
27 anti-company information DB
28 Account information DB
3 User terminal 4 Cloud service 5 Portal server 51 CPU
54 Mass Storage 541 Robo DB
542 Use Robo DB
6 Batch server 61 CPU
64 Mass storage 641 Setting DB
7 App server 71 CPU
74 Large-capacity storage unit 741 Different user DB
742 conversion DB
N network

Data processing program according to the present invention acquires data of a plurality types containing each plurality of data items from the plurality of databases, extracts only predetermined data items for each type, the extracted data item type Calculated by calculating the reliability of the data items included in the data of the first type based on the data consistency with the data items of the same type included in the data of the second type The computer is caused to execute a process of associating the reliability with the data item of the first type and storing it in the integrated database.

In the present invention, the extracted data item is integrated and stored in the integrated database for each type , the reliability of the data item is calculated, and the calculated reliability is stored in association with the data item. It becomes possible to estimate the reliability of the analysis result when performing data analysis .

Claims (14)

Obtain multiple types of data including multiple data items from each multiple database,
Extract only useful data items that are predetermined for each type,
A data processing program that integrates and stores the extracted data items in an integrated database for each type. Creating a new data item from the extracted data item,
The data processing program according to claim 1, wherein the generated new item is stored in the integrated database. The reliability of the data items included in the first type of data is calculated based on the data consistency with the same type of data items included in the second type of data,
The data processing program according to claim 1 or 2, wherein the calculated reliability is stored in the integrated database in association with the data item of the first type. The data processing program according to claim 3, wherein the reliability is changed according to a usage history of each data item. Get user ratings for each data,
The data processing program according to claim 3, wherein the reliability is updated based on the acquired user evaluation. The data processing program according to claim 3, wherein when the reliability of each data is below a threshold value, warning information including a data item name, data content, and the reliability is output. Acquire data of multiple types including multiple data items from each of the multiple databases, extract only useful data items that are predetermined for each type, integrate the extracted data items for each type, and store in the integrated database An integration department that
A reception unit that receives request information including the type and the data item,
An output unit that extracts data corresponding to the received request information from the integrated database and outputs the extracted data. The integrated database stores the reliability of each data item or each data,
The data output device according to claim 7, wherein the output unit outputs the reliability for each data item or each data in association with the data to be output. A computer that can access the integrated database
Obtain multiple types of data including multiple data items from each multiple database,
Extract only useful data items that are predetermined for each type,
A data integration method in which the extracted data items are integrated and stored in an integrated database for each type. An integrated database that acquires data of multiple types including multiple data items from each of multiple databases, extracts only useful data items that are predetermined for each type, and integrates and stores the extracted data items for each type. And a reception unit that receives request information including the type and the data item, and an output unit that extracts data corresponding to the received request information from the integrated database and outputs the extracted data. hand,
Send a plurality of the request information set in advance,
Based on the data for each of the request information received from the data output device, calculate an index value,
An output program that outputs the calculated index value. The types include POS data, reservation data regarding products or services, account data including bank accounts, and word-of-mouth data of word-of-mouth sites,
Sending request information including the POS data, the reservation data, the account data, and the word-of-mouth data,
11. The creditworthiness is calculated based on the sales performance calculated from the received POS data, the sales prospect calculated from the reservation data, the fund forecast calculated from the account data, and the evaluation value calculated from the word-of-mouth data. Output program described. Obtaining credit line information associated with the calculated credit level from a database that stores the credit level and credit line information including an interest rate and an upper limit in association with each other,
The output program according to claim 11, which outputs the acquired credit line information. An integrated database that acquires data of multiple types including multiple data items from each of multiple databases, extracts only useful data items that are predetermined for each type, and integrates and stores the extracted data items for each type. And a reception unit that receives request information including the type and the data item, and an output unit that extracts data corresponding to the received request information from the integrated database and outputs the extracted data. A computer that can send and receive data
Send a plurality of the request information set in advance,
Based on the data for each of the request information received from the data output device, calculate an index value,
A data output method characterized by outputting the calculated index value. An integrated database that acquires data of multiple types including multiple data items from each of multiple databases, extracts only useful data items that are predetermined for each type, and integrates and stores the extracted data items for each type. A data output device including: a receiving unit that receives request information including the type and the data item; and an output unit that extracts data corresponding to the received request information from the integrated database and outputs the extracted data, ,
A transmitter for transmitting a plurality of preset request information, a calculator for calculating an index value based on the data for each request information received from the data output device, and an output unit for outputting the calculated index value. A data processing system comprising:

Images