WO2013038508A1 - 計算機、計算機システム及びデータベースの構築支援方法 - Google Patents

計算機、計算機システム及びデータベースの構築支援方法 Download PDF

Info

Publication number
WO2013038508A1
WO2013038508A1 PCT/JP2011/070882 JP2011070882W WO2013038508A1 WO 2013038508 A1 WO2013038508 A1 WO 2013038508A1 JP 2011070882 W JP2011070882 W JP 2011070882W WO 2013038508 A1 WO2013038508 A1 WO 2013038508A1
Authority
WO
WIPO (PCT)
Prior art keywords
input data
data
web
schema
operation history
Prior art date
Application number
PCT/JP2011/070882
Other languages
English (en)
French (fr)
Inventor
平塚　幸恵
一智 牛嶋
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to JP2013533387A priority Critical patent/JP5775594B2/ja
Priority to PCT/JP2011/070882 priority patent/WO2013038508A1/ja
Publication of WO2013038508A1 publication Critical patent/WO2013038508A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking

Definitions

  • the present invention relates to a computer, and more particularly to a technique for supporting database construction based on an operation history of a Web application.
  • Non-Patent Documents 1 to 3 In recent years, there has been an increasing need to extract data useful for improving services by analyzing the operation history of Web applications (Web operation history) (see Non-Patent Documents 1 to 3).
  • the web operation history has a role as evidence, and therefore all kinds of data related to the web operation are recorded. Therefore, in order to extract and analyze useful data from the Web operation history, it is necessary to process the data.
  • DB database
  • the DB builder selects necessary items from the history, defines the schema based on those items, and develops a program etc., and operates according to the defined schema. There is a method of extracting necessary data from a history and constructing a DB.
  • Patent Document 1 When manual operations such as data item selection, schema definition, data extraction / processing according to the defined schema are performed manually, it takes time and effort. there were.
  • the method disclosed in Patent Document 1 has a problem that the load when recording history data is high, and a problem that a search conditioned by data in the Web operation screen cannot be processed at high speed. This is because, in order to save the input data together with the Web screen display file, it is necessary to search the Web screen display file for recording the input data and embed the input data in the file. The latter is because the data in the Web operation screen is not tabulated. Further, since input data is recorded as a set together with a Web screen display file (the file includes data necessary for Web screen display such as tabs), there is a problem that the capacity of the operation history increases.
  • the present invention takes the above-described problems into consideration, and is troublesome in constructing a DB for analyzing the operation history of a Web application (such as creation of schema data and load data to be created in accordance with the schema definition). It is an object of the present invention to provide a computer, a computer system, and a database construction support method capable of reducing time.
  • a typical example of the invention disclosed in the present application is as follows. That is, a computer including a processor that executes a program and a memory that stores a program executed by the processor, and the processor selects a data item of a database in units of forms that are constituent units of a Web operation screen. And a function for defining a schema based on input data items included in the form for each form selected by a user of the computer and recording it in the memory.
  • FIG. 1 is a diagram illustrating a configuration example of a computer system 1 according to the embodiment of this invention.
  • the computer system 1 includes a Web client (client device) 2 and a Web server (computer) 3 connected via a network 4 such as a LAN (Local Area Network).
  • a network 4 such as a LAN (Local Area Network).
  • the Web client 2 is a computer that uses functions and data provided by the Web server 3.
  • the web client 2 is a general computer device that includes a CPU (Central Processing Unit), a memory, an interface (not shown), and the like.
  • the Web client 2 includes a Web operation screen display unit 21, a data input unit 22, and a data transmission unit 23.
  • the web operation screen display unit 21 displays a web operation screen on the display device 24 based on resources sent as a response from the web server 3 in response to a request from the web client 2.
  • the data input unit 22 also assigns user operation information (input data) on the Web operation screen displayed based on the resource sent as a response from the Web server 3 to each input element on the Web operation screen. Enter in the variable.
  • the data transmission unit 23 transmits the input data input to the variable of each input element on the Web operation screen to the Web server 3.
  • the Web server 3 is a computer that provides Web application resources and data to the Web client 2 in response to a request from the Web client 2.
  • the Web server 3 includes a DB construction support unit 30.
  • the DB construction support unit 30 includes a real-time data analysis unit 31, a past data analysis unit 32, and a DB construction unit 33.
  • the DB construction support unit 30 supports DB construction based on input data received from the Web client 2 or operation history data stored in the Web operation history 51.
  • the real time data analysis unit 31 analyzes input data received from the Web client 2 in real time.
  • the past data analysis unit 32 analyzes the operation history data received in the past from the Web client 2 and accumulated in the Web operation history 51.
  • the real-time data analysis unit 31 and the past data analysis unit 32 generate a schema definition 71 and DB input data 72 as analysis results.
  • the DB construction unit 33 constructs a Web analysis DB 61 based on the generated schema definition 71 and DB input data 72.
  • the real-time data analysis unit 31 includes an analysis data selection unit 34, a schema definition unit 35, a schema update unit 36, a data filter unit 37, and an input data generation unit 38.
  • the past data analysis unit 32 includes an analysis data selection unit 34, a schema definition unit 35, a schema update unit 36, a history configuration analysis unit 39, and a data extraction / generation unit 40.
  • the real-time data analysis unit 31 and the past data analysis unit 32 share the analysis data selection unit 34, the schema definition unit 35, and the schema update unit 36.
  • the analysis data selection unit 34 is based on the screen configuration of the Web operation screen that presents data items to be analyzed to the client 2 in the input data received from the Web client 2 or the operation history data stored in the Web operation history 51. Select. Details of the analysis data selection unit 34 will be described later with reference to FIG.
  • the schema definition unit 35 defines a schema based on the data selected by the analysis data selection unit 34, and outputs the defined schema (schema definition 71).
  • the schema describes the data structure of the DB to be created (table structure in the embodiment of the present invention), and the schema definition describes the data structure of the DB (table structure in the embodiment of the present invention). . Details of the schema definition unit 35 will be described later with reference to FIG.
  • the schema defined by the schema definition unit 35 can be updated (corrected or changed) by the schema update unit 36.
  • the schema update unit 36 updates the schema defined by the schema definition unit 35 in accordance with an instruction from a DB builder or a web operation history analyst (hereinafter referred to as “user of the web server 3” for convenience of explanation).
  • the data filter unit 37 generates a data filtering program for filtering input data received from the Web client 2 in accordance with the schema defined by the schema definition unit 35. Further, the input data is filtered according to the generated data filtering program. Details of the data filter unit 37 will be described later with reference to FIG.
  • the input data generation unit 38 generates DB input data 72 based on the data filtered by the data filter unit 37.
  • the DB input data 72 is data that is described in a predetermined format such as a CSV format based on the schema definition and can be loaded into the Web analysis DB 61. Details of the input data generation unit 38 will be described later with reference to FIGS. 12 and 14.
  • the history configuration analysis unit 39 analyzes the configuration of operation history data stored in the Web operation history 51. Details of the history configuration analysis unit 39 will be described later with reference to FIGS. 18, 29A, and 29B.
  • the data extraction / generation unit 40 extracts data from the operation history data stored in the Web operation history 51 in accordance with the schema definition 71, and generates DB input data 72 based on the extracted data. Details of the data extraction / generation unit 40 will be described later with reference to FIG.
  • the web operation history 51 is a file for accumulating user operation history data received from the web client 2.
  • the operation history data here includes data that is not directly related to data input by the user, such as protocol headers and tags.
  • the Web analysis DB 61 is a database constructed by the DB construction unit 33 based on the schema definition 71 and the DB input data 72.
  • the computer system 1 allows the DB construction support unit 30 to construct a DB based on the input data received from the Web client 2 or the operation history data stored in the Web operation history 51. Support.
  • FIG. 2 is a diagram illustrating a configuration example of the Web server 3 according to the embodiment of this invention.
  • ⁇ 2 includes a CPU 310, a north bridge 320, a south bridge 330, an SDRAM (Synchronous Dynamic Random Access Memory) 340, and a storage device 350.
  • the CPU 310 is an arithmetic processing device that executes various programs stored in the storage device 350.
  • the north bridge 320 is connected to a LAN slot (not shown) for connecting the LAN card 360 and a SAS slot (not shown) for connecting the SAS cards 370A and 370B via the PCIe (PCI express) bus.
  • the SDRAM 340 is, for example, a DDR2 (Double Data Rate 2) standard SDRAM.
  • the south bridge 330 is connected to a VGA slot (not shown) for connecting a VGA (Video Graphics Array) card 380 via a PCIe bus. Further, it is connected to a USB port (not shown) via a USB bus. In addition, it is connected to a storage device 350 of SATA (Serial Advanced Technology Attachment) standard.
  • VGA Video Graphics Array
  • USB port not shown
  • SATA Serial Advanced Technology Attachment
  • the storage device 350 stores an OS (Operating System) 351, a Web application 352, a DB construction support program 353, a schema definition 71, DB input data 72, and a DBMS (Data Base Management System) 354.
  • the DB construction support program 353 is a program that implements each function of the DB construction support unit 30 (see FIG. 1).
  • the Web server 3 is connected to the network device 81 via the LAN card 360. Further, the storage devices 50 and 60 are connected via the SAS cards 370A and 370B.
  • the storage device 50 stores a web operation history 51.
  • the storage device 60 stores a Web analysis DB 61.
  • the Web server 3 is connected to an output device 82 such as a display via a VGA card 380. Further, it is connected to an input device 83 such as a keyboard and a mouse via a USB port.
  • the web operation history 51 and the web analysis DB 61 are stored in separate storage devices 50 and 60, respectively, but this is not a limitation. For example, they may be stored in the same storage device.
  • the DB construction support program 353, the schema definition 71, and the DB input data 72 are also stored in the storage device 350, but this is not a limitation. For example, it may be stored in the storage devices 50 and 60.
  • FIG. 3 is a diagram showing an example of the analysis data selection screen 301 according to the embodiment of the present invention.
  • the analysis data selection screen 301 shown in FIG. 3 is displayed on the output device 82 by executing the program of the analysis data selection unit 34.
  • the user of the Web server 3 uses the input device 83 to input information necessary for DB construction on the analysis data selection screen 301.
  • the analysis data selection screen 301 includes a selection screen 302 for the user of the Web server 3 to select a data range to be analyzed, and a Web operation screen 303 displayed on the display device 24 of the Web client 2.
  • the web operation screen 303 is composed of one or a plurality of forms.
  • a form is a structural unit of an input screen for inputting data by a user of the Web client 2 (hereinafter referred to as “Web user”).
  • Web user a form 1 for executing a search (search form), a form 2 for executing a search result narrowing (refining form), and a form 3 for ordering a search result (ordering form) It consists of three forms.
  • the user of the Web server 3 selects the data range to be analyzed in form units. Specifically, the analysis target form is selected and checked, and the decision button is pressed. Then, the analysis data selection unit 34 selects the checked form data as an analysis target.
  • the data range to be analyzed is selected in units of forms. However, the present invention is not limited to this case.
  • the data range to be analyzed may be selected in other structural units.
  • FIG. 4 is a diagram illustrating a relationship between the configuration of the table 400 defined by the schema definition unit 35 and the form according to the embodiment of this invention.
  • a table 400 illustrated in FIG. 4 is a table defined based on information on the form 1 (409) when the form 1 (409) is selected as an analysis target.
  • the table definition describes the data items that make up the table and their type information.
  • the table defined on the basis of the form information includes items related to input data entry fields (elements such as text boxes) in the form (hereinafter referred to as “input data items 410”), and individual input data generated in units of forms. It consists of a data set ID for identifying a set, a sequence ID for identifying a series of input data processing to be processed on the Web server 3 side, and a session ID for identifying a series of Web operations on the Web client 2 side.
  • the input data item 410 has name and type information. Therefore, the table is described by extracting the name and type information of each data input item.
  • Keyword String 403
  • Shohin_cd String 404
  • Kakaku Number 405.
  • the name and type information of the input data items in the form are window.document.form [i] .element [j] .name, window It is indicated by .document.form [i] .element [j] .type.
  • the analysis data selection unit 34 first converts the number of the form selected as the analysis target into the form number i in the HTML, and each element (input data entry field) j included in the converted form number i. Extract name and type information. Thereafter, the schema definition unit 35 defines a table based on the extracted name and type information of each element j.
  • the data set in the table can be uniquely identified by the data set ID 406.
  • the session ID 408 can identify a set of input data processed in the same session.
  • sequence ID 407 the order in which the data sets in the same session (even if there are multiple data sets input from different types of forms in the same session, and therefore data sets between different tables) is input ( ).
  • a time stamp can be used for the sequence ID 407. Note that data is inserted into the data set ID 406, the sequence ID 407, and the session ID 408 by the Web server 3.
  • FIG. 5 is a flowchart showing the control logic of the analysis data selection unit 34 according to the embodiment of the present invention.
  • the analysis data selection unit 34 executes the control logic shown below.
  • the analysis data selection unit 34 presents an analysis data selection screen 301 as shown in FIG. 3 (S501).
  • the form number of the selected form is acquired (S502). Specifically, the number on the user interface of the selected form is converted into a number on a program describing a Web operation screen.
  • step 503 the analysis data selection unit 34 selects one of the form numbers acquired in step 502 (S503). Thereafter, in step 504, the form number and form name selected in step 503 are recorded (S504). Here, for example, it is recorded in the storage device 350 (see FIG. 2) (hereinafter the same).
  • step 505 the analysis data selection unit 34 selects one of the element numbers included in the form having the form number selected in step 503 (S505). Thereafter, in step 506 and step 507, the name and type information of the element selected in step 505 are acquired and recorded (S506, S507).
  • the analysis data selection unit 34 extracts information related to elements (input data items) in the form for each analysis target form selected on the analysis data selection screen 301. Note that all or part of the control logic described above may be executed by the schema definition unit 35.
  • FIG. 6 is a diagram illustrating a specific example of input data items in each form extracted by the analysis data selection unit 34 according to the embodiment of this invention.
  • FIG. 6 when all the forms 1, 2, and 3 on the analysis data selection screen 301 (see FIG. 3) are selected, information on input data items in each form extracted by the control logic shown in FIG. Is shown.
  • the information extracted when Form 1 is selected is (# 1, kensaku, keyword: string, shohin_cd: string, kakaku: number).
  • # 1 is an identifier (ID) for uniquely identifying the form 1.
  • kensaku is the name of Form 1. Note that the name of the form is used as the name of the table generated based on the form.
  • keyword: string indicates that the name and type information of the first element included in the form 1 are a keyword and a String type, respectively.
  • “shohin_cd: string” indicates that the name and type information of the second element included in the form 1 are shohin_cd and String types, respectively.
  • “kakaku: number” indicates that the name and type information of the third element included in Form 1 are kakaku and Number types, respectively. Description of the forms 2 and 3 is omitted here.
  • FIG. 7 is a flowchart illustrating the control logic of the schema definition unit 35 according to the embodiment of this invention.
  • the schema definition unit 35 executes the control logic shown below to define a schema (here, a table) corresponding to each form.
  • step 701 the schema definition unit 35 sets the name of one of the names of each form selected as an analysis target as a table name (S701). For example, since the form name of form 1 is “kensaku”, the name of the table generated corresponding to form 1 is “Kensaku_Table”.
  • step 702 the schema definition unit 35 generates a table based on each input data item (including type information) extracted corresponding to the name of the form (S702). For example, each input data item extracted corresponding to the form name “kensaku” of form 1 is “keyword: string, shohin_cd: string, kakaku: number”. Therefore, the input data item 410 of the table 400 as shown in FIG. 4 is inserted based on this data set.
  • step 703 the schema definition unit 35 inserts a data set ID (including type information) into the table generated in step 702 (S703).
  • a data set ID including type information
  • the data set ID 406 and its attributes are inserted into the table 400.
  • the schema definition unit 35 acquires information on the session ID (S704).
  • the session ID information is information unique to the Web application executed on the Web server 3.
  • the session ID is not limited.
  • step 705 the schema definition unit 35 inserts a session ID (including type information) into the table generated in step 702 (S705).
  • a session ID including type information
  • the session ID 408 and its attributes are inserted into the table 400.
  • step 706 the schema definition unit 35 inserts a sequence ID (including type information) into the table generated in step 702 (S706).
  • sequence ID 407 and its attributes are inserted into the table 400.
  • the processing in steps 702 to 706 is repeated for all the forms selected as analysis targets in the processing in step 707.
  • the schema definition part 35 can define a table automatically for every form selected as analysis object. In other words, the time and labor involved in defining the schema can be reduced.
  • FIG. 8 is a diagram illustrating a specific example of the table 800 generated by the schema definition unit 35 according to the embodiment of this invention.
  • FIG. 9 is a flowchart showing the control logic of the data filter unit 37 according to the embodiment of the present invention.
  • FIG. 10 is a diagram illustrating an example of the data filtering program 1000 generated by the data filter unit 37 according to the embodiment of this invention.
  • the data filter unit 37 automatically generates a data filtering program 1000 as shown in FIG. 10 by executing the control logic shown below.
  • step 901 the data filter unit 37 selects a set number of data items to be filtered (S901). Here, it is assumed that the number “# 1” is selected.
  • step 902 the data filter unit 37 defines a filtering function for executing data filtering (S902).
  • a filtering function filtering_kensaku 1003 is defined.
  • step 903 the data filter unit 37 generates a code for filtering the data set to be filtered in the filtering function defined in step 902 (S903).
  • a code 1004 is generated.
  • a code 1004 is a code for storing the value of each input data item “keyword, shohin_cd, kakaku” in a global variable.
  • step 904 the data filter unit 37 generates a code for calling the filtering function defined in step 902 when input data is received from the Web client 2 (S904).
  • the code 1002 is generated in the function input_kensaku 1001.
  • a code 1002 is a code for calling the filtering function filtering_kensaku 1003.
  • a function input_kensaku 1001 is a function called when receiving input data from the Web client 2.
  • step 905 the processing in steps 901 to 904 is repeated for all data set numbers.
  • the data filter unit 37 automatically generates a data filtering program according to the table defined by the schema definition unit 35.
  • FIG. 11 is a diagram illustrating an example of a request 1100 transmitted from the data transmission unit 23 to the data filter unit 37 according to the embodiment of this invention.
  • the request 1100 shown in FIG. 11 data input to the form 1 (search form) on the Web operation screen 303 is described.
  • the request 1100 describes a method name (GET method or POST method. In the example shown in FIG. 11, GET method).
  • a URL Uniform Resource Locator
  • the URL 1101 may be an absolute path or a relative path.
  • a parameter name (the name of an element in the form) and a value set are described by concatenating them with “&”.
  • a set of a parameter keyword and its value XXXX, a parameter shohin_cd and its value YYYYY, a parameter kakaku and its value UUUUU is described.
  • the request 1100 includes header information of Date 1103, Referer 1104, and Cookie 1105.
  • Date 1103 describes the time when the request 1100 is issued.
  • Referer 1104 the URL of the link source of the resource specified by the GET method is described.
  • Cookie 1105 describes the ID of a session related to transmission / reception of request 1100 between Web client 2 and Web server 3.
  • FIG. 12 is a sequence diagram showing a control logic of operations of the Web client 2 and the Web server 3 according to the embodiment of this invention.
  • the Web client 2 transmits a data set value corresponding to this event to the Web server 3 by an HTTP request in response to an input data confirmation event by the Web user (S1201).
  • the input data confirmation event here is an event that occurs when the user of the Web client 2 presses the execution button in the form.
  • the confirmation event is generated, for example, when a user on the Web client 2 side inputs a search keyword in the form and then presses a search execution button on the search form on the Web operation screen 303.
  • step 1201 when an event for confirming input data occurs on the Web operation screen 303, the Web client 2 transmits the value of the data set in the form that generated the event to the Web server 3 by an HTTP request.
  • the following operation of the Web server 3 starts when the user of the Web client 2 logs into the Web application provided by the Web server 3 to the Web client 2 and ends when the user logs out.
  • step 1202 the Web server 3 acquires the value of the data set from the HTTP request transmitted by the Web client 2 in step 1201 (S1202).
  • step 1203 the Web server 3 executes the data filtering program to filter and temporarily record the value of the data set acquired in step 1202 (S1203).
  • the data filtering program is executed by calling it in a program (a program in the Web server 3 in this embodiment) called by the HTTP request transmitted by the Web client 2 in Step 1201.
  • the filtering program described in FIG. 10 is an example when the user on the Web client 2 side calls the kensaku.php program as a resource to be called when an execution button named “search” is pressed.
  • a function filtering_kensaku 1002 for filtering the element value (data set value) in the form transmitted by the HTTP request transmitted from the Web client 2 is called.
  • the Web server 3 acquires the name of the request transmission source form based on the URL of the resource specified in the HTTP request transmitted from the Web client 2 and the Referer information (S1204). Specifically, the HTML file describing the information about the form is checked based on the Referer information. Further, the form in which the URL is described in the action information when the execution button in the form is pressed is checked in the form information in the HTML file, and the name of the corresponding form is acquired.
  • step 1205 the Web server 3 generates a data set ID for identifying the filtered data set and records it in the file having the name acquired in step 1204 (S1205).
  • the file is, for example, a CSV format file. Details of the file will be described later with reference to FIG.
  • the Web server 3 records the sequence ID, the session ID, and the value of the data set filtered in step 1203 in the file having the name acquired in step 1205 (S1206 to S1208).
  • the Web server 3 checks the HTML file describing the form information based on the URL of the calling resource described in the HTTP request and the Referer information, and sets the name of the request source form. Although acquired, it is not limited to this case. For example, as shown in FIG. 13, a table 1300 in which a filtering function and a form name are associated with each other may be created in advance, and the form name associated with the called filtering function may be acquired.
  • the Web client 2 transmits a request to the Web server 3.
  • the Web server 3 automatically executes real-time filtering and DB input data generation processing based on the received request. As a result, it is possible to reduce labor and time required for generating DB input data.
  • FIG. 13 is a diagram illustrating an example of the table 1300 in which the filtering function and the form name according to the embodiment of the present invention are associated with each other.
  • the table 1300 illustrated in FIG. 13 is generated when the data filter unit 37 generates a data filtering program.
  • the table 1300 stores the filtering function 1301, the URL 1302 of the HTML file to which the form belongs, and the form name 1303 in association with each other.
  • the URL 1302 is optional information. However, by associating the URL 1302, even if there is a form with the same name belonging to different HTML files and a filtering function name uniquely determined from the form name is automatically generated, The corresponding form name can be specified by the URL to which the form to be filtered belongs.
  • FIG. 14 is a diagram illustrating a specific example of the DB input data 72 according to the embodiment of this invention.
  • the DB input data 72 shown in FIG. 14 includes DB input data 721 to 723.
  • Each DB input data 721 to 723 is a CSV format data file generated for each table defined by the schema definition unit 35, that is, for each form.
  • the file name is the form name concatenated with the extension “_log”.
  • DB input data 721 is a data file generated based on a table defined corresponding to form 1 (form name kensaku).
  • DB input data 722 and 723 are data files generated based on tables defined corresponding to forms 2 and 3 (form names are shiborikomi and hattyuu, respectively).
  • Each entry of the DB input data 721 to 723 is connected with a data set ID, a sequence ID, a session ID, and each input data item by “,”.
  • each DB input data 721 to 723 can be easily stored in the corresponding table.
  • FIG. 15 is a diagram illustrating data that can be acquired from the form according to the embodiment of this invention.
  • data that the Web server 3 can acquire from a form selected as an analysis target will be described.
  • the Web server 3 can acquire information A and information B related to the form selected on the analysis data selection screen 301 (see FIG. 3).
  • Information A is an HTML URL describing the selected form.
  • Information B is information on the selected form. That is, the information B includes a form number, form action information, a form name, and an element name (input data item name) in the form.
  • the form action information is a path of a resource for processing data in the form.
  • the Web server 3 can confirm the presence / absence of information related to the form selected as the analysis target based on the information A and information B acquired from the operation history data stored in the Web operation history 51.
  • FIG. 16 is a diagram showing an example of the operation history data 1600 stored in the Web operation history 51 according to the embodiment of this invention.
  • the operation history data 1600 shown in FIG. 16 is an HTTP request in which data input to the form 1 (search form) on the Web operation screen 303 is stored.
  • the operation history data 1600 describes a method name (GET method or POST method. In the example shown in FIG. 16, GET method).
  • the URL 1601 of the resource to be called and the query character string 1602 are connected and described by the symbol “?”.
  • the URL 1601 may be an absolute path or a relative path.
  • the query character string 1602 describes parameter names (names of elements in the form) 1603 to 1605 and a set of values concatenated with “&”.
  • a set of a parameter keyword and its value XXXX, a parameter shohin_cd and its value YYYYY, a parameter kakaku and its value UUUUU is described. That is, information B obtainable from the form is recorded in the URL 1601 and the query character string 1602.
  • the operation history data 1600 includes header information of Date 1606, Referer 1607, and Cookie 1608.
  • Date 1606 the time when the operation history data 1600 is issued is described.
  • the Referrer 1607 describes the URL of the link source of the resource specified by the GET method. That is, information A that can be acquired from the form is recorded.
  • Cookie 1608 an ID of a session related to transmission / reception of operation history data 1600 between the Web client 2 and the Web server 3 is described.
  • the Web server 3 determines whether or not there is information regarding the form selected as the analysis target based on the correspondence between the URL extracted from the Referer 1607 in the operation history data 1600 and the action information described in the URL 1601. Can be confirmed. In addition, when there is information regarding the form selected as the analysis target, it is possible to extract the value of the variable of each data input item (keyword, shohin_cd, kakaku in the example shown in FIG. 16) in the form.
  • the Web server 3 can generate a sequence ID and a session ID based on the information of Date 1606 and Cookie 1608, respectively.
  • FIG. 17 is a flowchart illustrating the control logic of the data extraction / generation unit 40 according to the embodiment of this invention.
  • the data extraction / generation unit 40 extracts data corresponding to the schema defined by the schema definition unit 35 by analyzing the operation history data stored in the Web operation history 51. Further, DB input data 72 is generated based on the extracted data.
  • the data extraction / generation unit 40 refers to the Referer information of the operation history data (HTTP request) stored in the Web operation history 51, and matches the URL of the HTML file to which the form selected as the analysis target belongs.
  • the operation history data describing the URL to be searched is searched (S1701).
  • step 1702 the data extraction / generation unit 40 determines whether the URL of the resource related to the operation history data extracted as a result of the search in step 1701 indicates action information of the form selected as the analysis target. Confirmation is made (S1702).
  • step 1703 if YES in step 1702, the data extraction / generation unit 40 extracts and records the name and value of the data set from the operation history data extracted in step 1701 (S1703).
  • step 1704 the data extraction / generation unit 40 extracts and records the session ID from the cookie information in the operation history data extracted in step 1701 (S1704).
  • step 1705 the data extraction / generation unit 40 records the Date information in the operation history data extracted in step 1701 as a sequence ID (S1705).
  • step 1706 the data extraction / generation unit 40 generates a data set ID for uniquely identifying the operation history data extracted in step 1701 (S1706).
  • step 1707 the data extraction / generation unit 40 then selects the form selected as the analysis target based on the data set, the session ID, the sequence ID recorded in steps 1703 to 1705, and the data set ID generated in step 1706.
  • DB input data of the table corresponding to is generated (S1707). Specifically, DB input data 72 as shown in FIG. 14 is generated.
  • the data extraction / generation unit 40 analyzes the operation history data stored in the Web operation history 51 to extract data corresponding to the schema defined by the schema definition unit 35. Further, DB input data 72 is generated based on the extracted data.
  • FIG. 18 is a flowchart illustrating the control logic of the history configuration analysis unit 39 according to the embodiment of this invention.
  • the history configuration analysis unit 39 acquires information on the form existing in the web operation history 51 based on each operation history data (HTTP request) stored in the web operation history 51.
  • Step 1801 the history configuration analysis unit 39 acquires and records the URL described in the Referer information of any operation history data (HTTP request) in the Web operation history 51 (S1801).
  • step 1802 the history configuration analysis unit 39 acquires and records the URL information of the resource of the operation history data to be processed (S1802).
  • step 1803 the history structure analysis unit 39 searches the HTML file of the URL acquired in step 1801 for a form in which the URL of the resource acquired in step 1802 is specified as action information (S1803).
  • step 1804 the history structure analysis unit 39 acquires and records the form number extracted as a result of the search in step 1803 (S1804).
  • step 1805 the history configuration analysis unit 39 determines whether or not the form information acquired in step 1803 is registered in the form information table (S1805).
  • the form information table is a table in which information related to forms existing in the web operation history 51 is recorded. Details of the form information table will be described later with reference to FIG.
  • step S1805 If registered (YES in step S1805), the process advances to step 1807. On the other hand, if not registered (NO in step S1805), in step 1806, the history configuration analysis unit 39 registers the form information acquired in step 1803 in the form information table (S1806).
  • the history configuration analysis unit 39 repeats the processing in steps 1801 to 1806 for all the operation history data existing in the web operation history 51.
  • the history configuration analysis unit 39 acquires information about the form existing in the Web operation history 51 based on each operation history data (HTTP request) stored in the Web operation history 51, and the form information Register in the table.
  • FIG. 19 is a diagram showing an example of the form information table 1900 according to the embodiment of this invention.
  • the form information table 1900 shown in FIG. 19 is generated by the control logic shown in FIG.
  • the URL 1901 specified by the Referer information the URL 1901 specified by the Referer information, the resource URL 1902, and the form number 1903 are registered in association with each other.
  • the form can be uniquely identified by the URL 1901 and the form number 1903.
  • FIG. 20 is a diagram showing a first example of the web operation history analysis data selection screen 2001 according to the embodiment of this invention.
  • the analysis data selection screen 2001 shown in FIG. 20 is displayed on the output device 82 by executing the program of the analysis data selection unit 34.
  • the user of the Web server 3 inputs information on the analysis data selection screen 2001 using the input device 83.
  • the analysis data selection screen 2001 includes a selection screen 2002 for the user of the Web server 3 to select a data range to be analyzed, and a Web operation screen 303 displayed on the display device 24 of the Web client 2.
  • the history logic analyzing unit 39 can extract a form that exists in the web operation history 51, that is, a form that can be analyzed by the control logic shown in FIG. Therefore, when analyzing the Web operation history 51, the analysis data selection unit 34 presents only the forms registered in the form information table 1900 shown in FIG. Thereby, a form that cannot be analyzed, that is, a form from which data is not extracted even if analyzed, can be excluded from the analysis target in advance.
  • FIG. 21 is a diagram showing a second example of the web operation history analysis data selection screen 2101 according to the embodiment of this invention.
  • the analysis data selection screen 2101 shown in FIG. 21 is displayed on the output device 82 by executing the program of the analysis data selection unit 34.
  • the user of the Web server 3 inputs information on the analysis data selection screen 2101 using the input device 83.
  • the analysis data selection screen 2101 includes a selection screen 2102 for the user of the Web server 3 to select a data range to be analyzed, and a Web operation screen 303 displayed on the display device 24 of the Web client 2.
  • the user of the Web server 3 selects the data range to be analyzed in form units. Furthermore, when previewing the analysis result of the form selected as the analysis target, the check box for preview is checked and the decision button is pressed. Then, the Web server 3 analyzes the checked form and displays the analysis result.
  • FIG. 22 is a flowchart showing control logic of preview analysis according to the embodiment of the present invention.
  • the Web server 3 enables the preview of the analysis result of the form selected as the analysis target by executing the following control logic.
  • the Web server 3 acquires the form number of the selected form (S2201). Specifically, the number on the user interface of the selected form is converted into a number on a program describing a Web operation screen.
  • the Web server 3 refers to the Referer information of any operation history data (HTTP request) stored in the Web operation history 51, and the URL of the HTML file to which the form selected as the analysis target belongs.
  • the operation history data in which the matching URL is described is searched (S2202).
  • step 2203 the Web server 3 checks whether or not the resource URL related to the operation history data extracted as a result of the search in step 2202 indicates action information of the form selected as the analysis target (S2203). ). Note that the form selected as the analysis target is identified by the form number.
  • the process returns to step 2202, and the process is repeated for another operation history data.
  • the Web server 3 records the number of the form extracted in step 2202 (S2205). ).
  • the Web server 3 repeats the processing in steps 2202 to 2205 for all the operation history data existing in the Web operation history 51.
  • step 2207 the Web server 3 searches for a form that does not exist in the Web operation history 51 based on the form number recorded in step 2205 (S2207).
  • step 2209 the Web server 3 displays the corresponding form, that is, a form that does not exist in the Web operation history 51 (S2209). Specifically, a form number that does not exist in the web operation history 51 is acquired, and the acquired form number is converted into a user interface number and displayed in a pop-up window. An example of the display screen displayed in step 2209 will be described later with reference to FIG.
  • step 2210 the Web server 3 displays in a pop-up window that the data of all the forms selected as analysis targets exist in the Web operation history 51 ( S2210).
  • FIG. 23 is a diagram showing a first specific example of the preview analysis result display screen 2300 according to the embodiment of the present invention.
  • a display screen 2300 shown in FIG. 23 is a pop-up window displayed when a form selected as an analysis target (here, form 2) does not exist in the Web operation history 51.
  • the user of the Web server 3 obtains data of a form that does not exist in the Web operation history 51 (here, form 2) and generates DB input data 72 in real time. Confirmation can be instructed as to whether or not the setting is to be performed.
  • the Web server 3 When confirming the setting, the user of the Web server 3 uses the input device 83 to press the “confirm setting” button. Then, the Web server 3 executes a control logic shown in FIG. 27 to be described later, and displays a setting confirmation result. On the other hand, to end the preview, press the “End Preview” button. Then, the Web server 3 ends the preview.
  • FIG. 24 is a diagram showing a second specific example of the preview analysis result display screen 2400 according to the embodiment of the present invention.
  • a display screen 2400 shown in FIG. 24 is a pop-up window that is displayed when a “confirm setting” button is pressed on the display screen 2300 of FIG.
  • the user of the Web server 3 obtains data of a form that does not exist in the Web operation history 51 (here, form 2) and generates DB input data 72 in real time. If it is not “setting to be performed”, a setting change can be instructed.
  • the user of the Web server 3 uses the input device 83 to press the “Change setting and end preview” button. Then, the Web server 3 executes control logic shown in FIG. 28 to be described later and changes the setting. Then, the preview ends. On the other hand, if you do not want to change the settings, press the "End preview without changing settings” button. Then, the Web server 3 ends the preview.
  • FIG. 25 is a flowchart showing a control logic for registering a current setting related to real-time data analysis according to the embodiment of the present invention.
  • the form currently set to generate the DB input data 72 in real time is registered.
  • step 2501 the Web server 3 acquires the URL of the HTML file to which one of the forms selected as the analysis target by the user of the Web server 3 belongs (S2501).
  • step 2502 the Web server 3 acquires the number of the form to be processed (S2502).
  • the Web server 3 records the URL acquired in step 2501 and the form number acquired in step 2502 in association with the processing target form in the setting table (S2503).
  • the setting table is a table that stores information on the form that is currently set to generate the DB input data 72 in real time. Details of the setting table will be described later with reference to FIG.
  • the Web server 3 repeats the processing in steps 2501 to 2503 for all the forms selected as analysis targets.
  • the Web server 3 registers, in the setting table 2600, information related to the form that is currently set so as to generate the DB input data 72 in real time among the forms selected as analysis targets.
  • FIG. 26 is a diagram showing an example of the setting table 2600 according to the embodiment of this invention.
  • the setting table 2600 stores information related to the form that is currently set to generate the DB input data 72 in real time.
  • the Web server 3 can refer to the setting table 2600 to check whether the form that does not exist in the Web operation history 51 is a form that is currently set to generate the DB input data 72 in real time.
  • FIG. 27 is a flowchart showing a control logic for confirming a current setting related to real-time data analysis according to the embodiment of the present invention.
  • step 2701 the Web server 3 sets information related to the form determined not to exist in the Web operation history 51. It is searched whether it is registered in the table 2600 (S2701).
  • the setting table 2600 is referenced to search whether the URL of the HTML file to which the form determined not to exist in the Web operation history 51 belongs and the form number are registered in association with each other.
  • the Web server 3 returns information on the corresponding form (S2703).
  • the corresponding form is a form that is not registered in the setting table 2600 among the forms determined not to exist in the Web operation history 51.
  • the form information includes the URL of the HTML file to which the form belongs and the form number.
  • it returns that there is no corresponding form (S2704).
  • step 2705 the Web server 3 converts the form number (number on the program) in the form information returned in step 2703 into a number on the user interface (S2705).
  • the Web server 3 displays the converted form number in a message box (S2706).
  • the message box here is a message box as shown on the display screen 2400 in FIG.
  • step 2706 the Web server 3 determines that there is no corresponding form, that is, all the forms determined not to exist in the web operation history 51 are DB input data in real time. 72 may be displayed to indicate that it is currently set to generate 72.
  • the Web server 3 confirms the current setting related to the real-time data analysis based on the setting confirmation instruction by the user, and displays the confirmation result.
  • FIG. 28 is a flowchart showing a control logic for changing a setting related to real-time data analysis according to the embodiment of the present invention.
  • the Web server 3 converts the input data of the form to be changed to the Web It records in the operation history 51 (S2801).
  • step 2802 the Web server 3 newly defines a schema (table) corresponding to the setting change target form, and inputs the DB in real time based on the input data (HTTP request) of the setting change target form.
  • the business data 72 is generated (S2802).
  • the Web server 3 changes the setting so that the input data of the form determined not to exist in the Web operation history 51 is recorded in the Web operation history 51. Further, a schema corresponding to a form determined not to exist in the Web operation history 51 is newly defined, and DB input data 72 is generated in real time by filtering input data of the form.
  • 29A and 29B are flowcharts showing a modification of the control logic of the history configuration analysis unit 39 according to the embodiment of this invention.
  • the history configuration analysis unit 39 acquires information on the form existing in the Web operation history 51 based on each operation history data (HTTP request) stored in the Web operation history 51.
  • information relating to the recording period of the operation history data is also acquired for each form existing in the Web operation history 51.
  • symbol is attached
  • step 2901 the history configuration analysis unit 39 registers the Date information of the operation history data (HTTP request) to be processed as the latest data (S2901). Specifically, it is registered in Date information 3004 and 3005 of the form information table 3000 as shown in FIG.
  • step 2902 the history configuration analysis unit 39 registers the period information of the operation history data to be processed (S2902).
  • the history structure analysis unit 39 determines whether or not the Date information of the operation history data to be processed is the latest (S2903). Specifically, the determination is made based on a comparison between the Date information of the operation history data to be processed and the Date information stored in the Date information 3004 of the form information table 3000.
  • the history configuration analysis unit 39 registers this Date information as the newest Date information (S2904).
  • the history configuration analysis unit 39 determines whether the Date information of the operation history data to be processed is the oldest (S2905). . Specifically, the determination is made based on a comparison between the Date information of the operation history data to be processed and the Date information stored in the Date information 3005 of the form information table 3000.
  • the history configuration analysis unit 39 registers this Date information as the oldest Date information (S2906).
  • the history configuration analysis unit 39 ends the process of Step 2902.
  • the history configuration analysis unit 39 acquires information on the form existing in the web operation history 51 based on each operation history data (HTTP request) stored in the web operation history 51.
  • information relating to the recording period of the operation history data is also acquired for each form existing in the Web operation history 51. Thereby, the period which can be analyzed for every form can be investigated.
  • FIG. 30 is a diagram showing a modification of the form information table 3000 according to the embodiment of this invention.
  • the form information table 3000 shown in FIG. 30 is generated by the control logic shown in FIGS. 29A and 29B.
  • a URL 3001 a resource URL 3002, a form number 3003, date information 3004 of the newest data, and date information 3005 of the oldest data are registered in association with each other.
  • the form can be uniquely identified by the URL 3001 and the form number 3003. Further, the data information period in each form can be recorded by the Date information 3004 and 3005.
  • FIG. 31 is a diagram showing an example of an analyzable data presentation screen 3100 according to the embodiment of this invention.
  • the analysis possible data presentation screen 3100 shown in FIG. 31 is displayed on the output device 82 by executing the program of the analysis data selection unit 34.
  • data presence / absence information indicating whether or not data exists in the Web operation history 51, and the Web operation history 51 are displayed.
  • period information indicating a range (date and time) that can be analyzed is displayed.
  • the history configuration analysis unit 39 can extract period information that can be analyzed for each form existing in the Web operation history 51 by the control logic shown in FIGS. 29A and 29B described above. Therefore, when analyzing the Web operation history 51, the analysis data selection unit 34 presents an analyzable form and an analyzable period information based on the form information table 3000 shown in FIG.
  • FIG. 32 is a diagram showing a modification of the analysis data selection screen 3201 for the web operation history according to the embodiment of this invention.
  • the analysis data selection screen 3201 shown in FIG. 32 is displayed on the output device 82 by executing the program of the analysis data selection unit 34.
  • the user of the Web server 3 inputs information on the analysis data selection screen 3201 using the input device 83.
  • the analysis data selection screen 3201 includes a selection screen 3202 for the user of the Web server 3 to select a data range to be analyzed, and an analysis period setting menu for setting an analysis period for the form selected on the selection screen 3202 3203 and a Web operation screen 303 displayed on the display device 24 of the Web client 2.
  • selection screen 3202 shown in FIG. 32 is the same as the selection screen 2102 shown in FIG.
  • the history configuration analysis unit 39 can extract period information that can be analyzed for each form existing in the Web operation history 51 by the control logic shown in FIGS. 29A and 29B described above. Therefore, when the analysis period setting menu 3203 is selected, the analysis data selection unit 34 presents a screen for setting the analysis period of the selected form based on the form information table 3000. Details of the analysis period setting screen will be described later with reference to FIG.
  • FIG. 33 is a diagram illustrating a specific example of the analysis period setting screen 3301 according to the embodiment of this invention.
  • the analysis period setting screen 3301 shown in FIG. 33 is a screen that prompts the user to set the analysis period of the selected form (forms 1 and 3 in FIG. 32) when the analysis period setting menu 3203 is selected.
  • the user of the Web server 3 uses the input device 83 to set the start date and time and end date and time of the analysis target period on the analysis period setting screen 3301. Thereby, the analysis period of the operation history data in the Web operation history 51 can be set for each form.
  • FIG. 34 is a diagram showing an example of the session table 3400 according to the embodiment of this invention.
  • the session table 3400 is a table for managing session information.
  • the session information includes user information specified by the session ID, time information related to the session, regional information, and the like.
  • the session table 3400 and each table defined by the schema definition unit 35 can be associated with each other via a session ID.
  • the data inserted into each table defined by the schema definition unit 35 can be analyzed in a multifaceted manner using the session information managed by the session table 3400. Further, it is possible to analyze the relationship of data that is a component of each table via the session ID.

Abstract

　プログラムを実行するプロセッサと、前記プロセッサによって実行されるプログラムを格納するメモリとを備える計算機であって、前記プロセッサは、Ｗｅｂ操作画面の構成単位であるフォーム単位で、データベースのデータ項目を選定させる画面を表示する機能と、当該計算機のユーザにより選定されたフォーム毎に、当該フォームに含まれる入力データ項目に基づいてスキーマを定義し、前記メモリに記録する機能を持つことを特徴とする計算機。

Description

計算機、計算機システム及びデータベースの構築支援方法
　本発明は、計算機に関し、特に、Ｗｅｂアプリケーションの操作履歴に基づいてデータベースの構築を支援する技術に関する。
　近年、Ｗｅｂアプリケーションの操作履歴（Ｗｅｂ操作履歴）を解析することによって、サービス向上に有用なデータを抽出するニーズが高まっている（非特許文献１～３参照）。
　Ｗｅｂ操作履歴には、エビデンスとしての役割があるためＷｅｂ操作にかかわるあらゆる種類のデータが記録されている。そのため、Ｗｅｂ操作履歴から、有用なデータを抽出し、解析するためにはデータの加工が必要である。
　特に大容量の履歴データを多面的な視点で効率よく解析するためには、あらかじめ履歴データをデータベース（以下、「ＤＢ」という。）化しておく必要がある。
　ＤＢ化の方法には、ＤＢ構築者が履歴の中から必要な項目を選定し、それらの項目に基づいてスキーマを定義し、さらにプログラムなどを開発するなどして、定義したスキーマに合わせて操作履歴から必要なデータを抽出しＤＢを構築する方法がある。
　また、操作履歴が視覚的にわかりやすいかたちで検索できるように、Ｗｅｂ画面単位（ファイル単位）で操作履歴を記録し、Ｗｅｂ画面単位でＤＢ化する方法がある。このような方法は特許文献１に開示されている。
特開２００９－５３７４０号公報
Jansen,J.B.,Spink,A.and Taksa,I."Handbook of Research on Web Log Analysis",IGI Global(2008). Lecturer,V.C.and Davamani, A.S."A survey on preprocessing methods for web usage data",International Journal of Computer Science and Information Security,Vol.7,No.3,pp.78-83(2010). Ratnakumar, A.J."An Implementation of web personalization using web mining techniques", Journal of Theoretical and Applied Information Technology,Vol.18,No.1,pp.67-73(2010).
　Ｗｅｂ操作履歴解析用ＤＢの構築にかかわるデータ項目の選定、スキーマの定義、定義したスキーマに合わせたデータの抽出・加工などの作業を主に人手で実施した場合、手間と時間がかかるという問題があった。また、特許文献１に開示された方法においては、履歴データを記録する際の負荷が高いという問題とＷｅｂ操作画面内のデータで条件付けられる検索が高速に処理できないという問題があった。前者は入力データをＷｅｂ画面表示用ファイルと合わせて保存するために、入力データを記録するＷｅｂ画面表示用ファイルの検索及びそのファイルへの入力データの埋め込みが必要となるためである。後者は、Ｗｅｂ操作画面内のデータがテーブル化されていないためである。また、入力データをＷｅｂ画面表示用ファイル（ファイルには、タブなどのＷｅｂ画面表示に必要なデータも含まれる）とセットで記録するため、操作履歴の容量が大きくなるという問題があった。
　本発明は、上述した課題を考慮したものであって、Ｗｅｂアプリケーションの操作履歴を解析するためのＤＢを構築する際の手間（スキーマの定義やスキーマ定義に合わせて作成するロード用データの作成など）と時間を低減することができる計算機、計算機システム及びデータベースの構築支援方法を提供することを目的とする。
　本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、プログラムを実行するプロセッサと、前記プロセッサによって実行されるプログラムを格納するメモリとを備える計算機であって、前記プロセッサは、Ｗｅｂ操作画面の構成単位であるフォーム単位で、データベースのデータ項目を選定させる画面を表示する機能と、当該計算機のユーザにより選定されたフォーム毎に、当該フォームに含まれる入力データ項目に基づいてスキーマを定義し、前記メモリに記録する機能を持つことを特徴とする。
　本発明によれば、Ｗｅｂアプリケーションの操作履歴をＤＢに記録する際の手間と時間を低減することができる。
本発明の実施形態の計算機システムの構成例を示す図である。 本発明の実施形態のＷｅｂサーバの構成例を示す図である。 本発明の実施形態の解析データ選定画面の一例を示す図である。 本発明の実施形態のスキーマ定義部によって定義されるテーブルの構成とフォームとの関係を示す図である。 本発明の実施形態の解析データ選定部の制御ロジックを示すフローチャートである。 本発明の実施形態の解析データ選定部によって抽出される各フォーム内の入力データ項目の具体例を説明する図である。 本発明の実施形態のスキーマ定義部の制御ロジックを示すフローチャートである。 本発明の実施形態のスキーマ定義部によって生成されるテーブルの具体例を示す図である。 本発明の実施形態のデータフィルタ部の制御ロジックを示すフローチャートである。 本発明の実施形態のデータフィルタ部によって生成されるデータフィルタリングプログラムの一例を示す図である。 本発明の実施形態のデータ送信部がデータフィルタ部に送信するリクエストの一例を示す図である。 本発明の実施形態のＷｅｂクライアント及びＷｅｂサーバの動作の制御ロジックを示すシーケンス図である。 本発明の実施形態のフィルタリング関数とフォーム名とを対応付けたテーブルの一例を示す図である。 本発明の実施形態のＤＢ入力用データの具体例を示す図である。 本発明の実施形態のフォームから取得可能なデータを説明する図である。 本発明の実施形態のＷｅｂ操作履歴に格納されたデータの一例を示す図である。 本発明の実施形態のデータ抽出・生成部の制御ロジックを示すフローチャートである。 本発明の実施形態の履歴構成解析部の制御ロジックを示すフローチャートである。 本発明の実施形態のフォーム情報テーブルの一例を示す図である。 本発明の実施形態のＷｅｂ操作履歴の解析データ選定画面の第一の例を示す図である。 本発明の実施形態のＷｅｂ操作履歴の解析データ選定画面の第二の例を示す図である。 本発明の実施形態のプレビュー解析の制御ロジックを示すフローチャートである。 本発明の実施形態のプレビュー解析結果の表示内容の第一の具体例を示す図である。 本発明の実施形態のプレビュー解析結果の表示内容の第二の具体例を示す図である。 本発明の実施形態のリアルタイムデータ解析に係る現在の設定を登録する制御ロジックを示すフローチャートである。 本発明の実施形態の設定テーブルの一例を示す図である。 本発明の実施形態のリアルタイムデータ解析に係る現在の設定を確認する制御ロジックを示すフローチャートである 本発明の実施形態のリアルタイムデータ解析に係る設定を変更する制御ロジックを示すフローチャートである。 本発明の実施形態の履歴構成解析部の制御ロジックの変形例を示すフローチャートである。 本発明の実施形態の履歴構成解析部の制御ロジックの変形例を示すフローチャートである。 本発明の実施形態のフォーム情報テーブルの変形例を示す図である。 本発明の実施形態の解析可能データ提示画面の一例を示す図である。 本発明の実施形態のＷｅｂ操作履歴の解析データ選定画面の変形例を示す図である。 本発明の実施形態の解析期間設定画面の具体例を示す図である。 本発明の実施形態のセッションテーブルの一例を示す図である。
　以下、本発明を実施するための形態について図面を参照して説明する。
　図１は、本発明の実施形態の計算機システム１の構成例を示す図である。計算機システム１は、ＬＡＮ（Local Area Network）等のネットワーク４を介して接続されたＷｅｂクライアント（クライアント装置）２と、Ｗｅｂサーバ（計算機）３とを備える。
　Ｗｅｂクライアント２は、Ｗｅｂサーバ３によって提供される機能やデータを利用する計算機である。Ｗｅｂクライアント２は、ＣＰＵ（Central Processing Unit）、メモリ、インタフェース（不図示）等を備えた一般的なコンピュータ装置である。このＷｅｂクライアント２は、Ｗｅｂ操作画面表示部２１、データ入力部２２及びデータ送信部２３を備える。
　Ｗｅｂ操作画面表示部２１は、Ｗｅｂクライアント２からのリクエストに応じて、Ｗｅｂサーバ３からレスポンスとして送られてくるリソースに基づいて、表示装置２４上にＷｅｂ操作画面を表示する。データ入力部２２も、Ｗｅｂサーバ３からレスポンスとして送られてくるリソースに基づいて表示されたＷｅｂ操作画面上におけるユーザの操作情報（入力データ）を、Ｗｅｂ操作画面上の各入力用エレメントに割り当てた変数に入力する。データ送信部２３は、Ｗｅｂ操作画面上の各入力用エレメントの変数に入力された入力データをＷｅｂサーバ３に送信する。
　Ｗｅｂサーバ３は、Ｗｅｂクライアント２からのリクエストに応じて、Ｗｅｂクライアント２にＷｅｂアプリケーションのリソースやデータを提供する計算機である。このＷｅｂサーバ３は、ＤＢ構築支援部３０を備える。
　ＤＢ構築支援部３０は、リアルタイムデータ解析部３１、過去データ解析部３２及びＤＢ構築部３３を含む。このＤＢ構築支援部３０は、Ｗｅｂクライアント２から受信した入力データ又はＷｅｂ操作履歴５１に格納された操作履歴データに基づくＤＢ構築を支援する。
　リアルタイムデータ解析部３１は、Ｗｅｂクライアント２からリアルタイムに受信した入力データを解析する。一方、過去データ解析部３２は、Ｗｅｂクライアント２から過去に受信し、Ｗｅｂ操作履歴５１に蓄積された操作履歴データを解析する。これらリアルタイムデータ解析部３１及び過去データ解析部３２は、解析結果としてスキーマ定義７１及びＤＢ入力用データ７２を生成する。ＤＢ構築部３３は、生成されたスキーマ定義７１及びＤＢ入力用データ７２に基づいて、Ｗｅｂ解析用ＤＢ６１を構築する。
　リアルタイムデータ解析部３１は、解析データ選定部３４、スキーマ定義部３５、スキーマ更新部３６、データフィルタ部３７及び入力データ生成部３８を含む。
　過去データ解析部３２は、解析データ選定部３４、スキーマ定義部３５、スキーマ更新部３６、履歴構成解析部３９及びデータ抽出・生成部４０を含む。
　すなわちリアルタイムデータ解析部３１及び過去データ解析部３２は、解析データ選定部３４、スキーマ定義部３５及びスキーマ更新部３６を共有する。
　解析データ選定部３４は、Ｗｅｂクライアント２から受信する入力データ又はＷｅｂ操作履歴５１に格納された操作履歴データにおいて、解析すべきデータの項目を、クライント２に提示するＷｅｂ操作画面の画面構成に基づいて選定する。解析データ選定部３４の詳細については、図５を用いて後述する。
　スキーマ定義部３５は、解析データ選定部３４によって選定されたデータに基づいてスキーマを定義し、定義されたスキーマ（スキーマ定義７１）を出力する。スキーマとは、作成すべきＤＢのデータ構成（本発明の実施形態ではテーブルの構成）を記述したものであり、スキーマ定義では、ＤＢのデータ構成（本発明の実施形態ではテーブル構成）を記述する。なお、スキーマ定義部３５の詳細については、図７を用いて後述する。スキーマ定義部３５によって定義されたスキーマは、スキーマ更新部３６によって更新（修正、変更）可能である。
　スキーマ更新部３６は、ＤＢ構築者又はＷｅｂ操作履歴解析者（以下、説明の便宜上「Ｗｅｂサーバ３のユーザ」という。）による指示に従って、スキーマ定義部３５によって定義されたスキーマを更新する。
　データフィルタ部３７は、スキーマ定義部３５によって定義されたスキーマに従って、Ｗｅｂクライアント２から受信した入力データをフィルタリングするデータフィルタリングプログラムを生成する。また、生成されたデータフィルタリングプログラムに従って、入力データをフィルタリングする。データフィルタ部３７の詳細については、図９を用いて後述する。
　入力データ生成部３８は、データフィルタ部３７によってフィルタリングされたデータに基づいて、ＤＢ入力用データ７２を生成する。ＤＢ入力用データ７２とは、スキーマ定義に基づいてＣＳＶ形式等の所定の形式で記述され、Ｗｅｂ解析用ＤＢ６１にロード可能なデータである。入力データ生成部３８の詳細については、図１２及び図１４を用いて後述する。
　履歴構成解析部３９は、Ｗｅｂ操作履歴５１に格納された操作履歴データの構成を解析する。履歴構成解析部３９の詳細については、図１８、図２９Ａ及び図２９Ｂを用いて後述する。
　データ抽出・生成部４０は、スキーマ定義７１に従って、Ｗｅｂ操作履歴５１に格納された操作履歴データからデータを抽出し、抽出されたデータに基づいてＤＢ入力用データ７２を生成する。データ抽出・生成部４０の詳細については、図１７を用いて後述する。
　Ｗｅｂ操作履歴５１は、Ｗｅｂクライアント２から受信したユーザの操作履歴データを蓄積するファイルである。ここでいう操作履歴データとは、プロトコルのヘッダや、タグ等のユーザによって入力されたデータとは直接関係のないデータも含む。
　Ｗｅｂ解析用ＤＢ６１は、ＤＢ構築部３３によってスキーマ定義７１及びＤＢ入力用データ７２に基づいて構築されるデータベースである。
　以上に示す構成により、本発明の実施形態の計算機システム１は、ＤＢ構築支援部３０が、Ｗｅｂクライアント２から受信する入力データ又はＷｅｂ操作履歴５１に格納された操作履歴データに基づくＤＢの構築を支援する。
　図２は、本発明の実施形態のＷｅｂサーバ３の構成例を示す図である。
　図２に示すＷｅｂサーバ３は、ＣＰＵ３１０、ノースブリッジ３２０、サウスブリッジ３３０、ＳＤＲＡＭ（Synchronous Dynamic Random Access Memory）３４０及び記憶装置３５０を備える。
　ＣＰＵ３１０は、記憶装置３５０に記憶された各種プログラムを実行する演算処理装置である。ノースブリッジ３２０は、ＰＣＩｅ（PCI express）バスを介して、ＬＡＮカード３６０を接続するためのＬＡＮスロット（不図示）、ＳＡＳカード３７０Ａ、３７０Ｂを接続するためのＳＡＳスロット（不図示）に接続される。ＳＤＲＡＭ３４０は、例えばＤＤＲ２（Double Data Rate 2）規格のＳＤＲＡＭである。
　サウスブリッジ３３０は、ＰＣＩｅバスを介して、ＶＧＡ（Video Graphics Array）カード３８０を接続するためのＶＧＡスロット（不図示）に接続される。また、ＵＳＢバスを介してＵＳＢポート（不図示）に接続される。また、ＳＡＴＡ（Serial Advanced Technology Attachment）規格の記憶装置３５０に接続される。
　記憶装置３５０には、ＯＳ（Operating System）３５１、Ｗｅｂアプリケーション３５２、ＤＢ構築支援プログラム３５３、スキーマ定義７１、ＤＢ入力用データ７２、ＤＢＭＳ（Data Base Management System）３５４が格納される。ＤＢ構築支援プログラム３５３は、ＤＢ構築支援部３０（図１参照）の各機能を実現するプログラムである。
　このＷｅｂサーバ３は、ＬＡＮカード３６０を介してネットワーク機器８１に接続される。また、ＳＡＳカード３７０Ａ、３７０Ｂを介して記憶装置５０、６０に接続される。記憶装置５０は、Ｗｅｂ操作履歴５１を記憶する。記憶装置６０は、Ｗｅｂ解析用ＤＢ６１を記憶する。
　このＷｅｂサーバ３は、ＶＧＡカード３８０を介してディスプレイ等の出力装置８２に接続される。さらに、ＵＳＢポートを介してキーボード、マウス等の入力装置８３に接続される。
　以上に示す構成において、Ｗｅｂ操作履歴５１及びＷｅｂ解析用ＤＢ６１は、それぞれ別の記憶装置５０、６０に記憶されているが、この場合に限らない。例えば同じ記憶装置に記憶されてもよい。同様に、ＤＢ構築支援プログラム３５３、スキーマ定義７１及びＤＢ入力用データ７２も記憶装置３５０に記憶されているが、この場合に限らない。例えば記憶装置５０、６０に記憶されてもよい。
　図３は、本発明の実施形態の解析データ選定画面３０１の一例を示す図である。図３に示す解析データ選定画面３０１は、解析データ選定部３４のプログラムを実行することによって出力装置８２に表示される。Ｗｅｂサーバ３のユーザは入力装置８３を用いて、解析データ選定画面３０１上でＤＢ構築に必要な情報を入力する。
　解析データ選定画面３０１は、Ｗｅｂサーバ３のユーザが解析対象のデータ範囲を選定するための選定画面３０２と、Ｗｅｂクライアント２の表示装置２４上に表示されるＷｅｂ操作画面３０３とを含む。
　Ｗｅｂ操作画面３０３は、１又は複数のフォームからなる。フォームとは、Ｗｅｂクライアント２のユーザ（以下、「Ｗｅｂユーザ」という。）がデータを入力する入力画面の構成単位である。図３に示す例では、検索を実行するためのフォーム１（検索フォーム）、検索結果に対する絞り込みを実行するためのフォーム２（絞り込みフォーム）、絞り込み結果を発注するためのフォーム３（発注フォーム）の３つのフォームからなる。
　選定画面３０２において、Ｗｅｂサーバ３のユーザは、解析対象のデータ範囲をフォーム単位で選定する。具体的には、解析対象のフォームを選択してチェックし、決定ボタンを押下する。そうすると、解析データ選定部３４は、チェックされたフォームのデータを解析対象として選定する。
　なお、以下、フォーム単位で解析対象のデータ範囲を選定する場合について説明するが、この場合には限らない。その他の構成単位で解析対象のデータ範囲を選定してもよい。
　図４は、本発明の実施形態のスキーマ定義部３５によって定義されるテーブル４００の構成とフォームとの関係を示す図である。図４に示すテーブル４００は、フォーム１（４０９）が解析対象として選定された場合に、フォーム１（４０９）の情報に基づいて定義されるテーブルである。
　テーブルの定義では、テーブルを構成するデータ項目とその型情報を記述する。フォーム情報に基づいて定義されるテーブルは、フォーム内の入力データ記入欄（テキストボックスなどのエレメント）に関する項目（以下、「入力データ項目４１０」という。）、フォーム単位で生成される個々の入力データセットを識別するためのデータセットＩＤ、Ｗｅｂサーバ３側で処理する一連の入力データ処理を識別するためのシーケンスＩＤ、Ｗｅｂクライアント２側の一連のＷｅｂ操作を識別するためのセッションＩＤから成る。
　入力データ項目４１０は、名前と型情報を持つ。そのため各データ入力項目の名前と型の情報を抽出してテーブルを記述する。図４の例では、Keyword:String４０３、Shohin_cd:String４０４、Kakaku: Number４０５となっている。
　なお、Ｗｅｂ操作画面３０３がＨＴＭＬ（HyperText Markup Language）によって記述される場合、フォーム内の入力データ項目の名前及び型情報は、それぞれwindow.document.form[i].element[j].name、window.document.form[i].element[j].typeで示される。
　そこで、解析データ選定部３４は、まず解析対象として選定されたフォームの番号を、ＨＴＭＬ内のフォーム番号iに変換し、変換されたフォーム番号iに含まれる各エレメント（入力データの記入欄）jの名前及び型情報を抽出する。その後、スキーマ定義部３５は、抽出された各エレメントjの名前及び型情報に基づいて、テーブルを定義する。
　データセットＩＤ４０６により、テーブル内のデータセットを一意に識別できる。セッションＩＤ４０８により、同一セッション内に処理された入力データのセットを識別できる。シーケンスＩＤ４０７により、同一セッション内のデータセット（同一セッション内に異なる種類のフォームから入力されたデータセットが複数ある場合においても、従って異なるテーブル間のデータセットであっても）が入力された順番（の前後関係）を明確にすることができる。シーケンスＩＤ４０７には、例えばタイムスタンプを使用することができる。なお、データセットＩＤ４０６、シーケンスＩＤ４０７及びセッションＩＤ４０８には、Ｗｅｂサーバ３によってデータが挿入される。
　図５は、本発明の実施形態の解析データ選定部３４の制御ロジックを示すフローチャートである。解析データ選定部３４は以下に示す制御ロジックを実行する。
　まずステップ５０１において、解析データ選定部３４は、図３に示すような解析データ選定画面３０１を提示する（Ｓ５０１）。Ｗｅｂサーバ３のユーザによって、解析データ選定画面３０１上で解析対象のフォームが選定されると、選定されたフォームのフォーム番号を取得する（Ｓ５０２）。具体的には、選定されたフォームのユーザインタフェース上の番号を、Ｗｅｂ操作画面を記述するプログラム上の番号に変換する。
　その後ステップ５０３において、解析データ選定部３４は、ステップ５０２で取得されたフォーム番号のうち、いずれかのフォーム番号を選択する（Ｓ５０３）。その後ステップ５０４において、ステップ５０３で選択されたフォーム番号及びフォームの名前を記録する（Ｓ５０４）。ここでは、例えば記憶装置３５０（図２参照）に記録する（以下、同様）。
　その後ステップ５０５において、解析データ選定部３４は、ステップ５０３で選択されたフォーム番号のフォームに含まれるエレメント番号のうち、いずれかのエレメント番号を選択する（Ｓ５０５）。その後ステップ５０６及びステップ５０７において、ステップ５０５で選択されたエレメントの名前及び型情報をそれぞれ取得し、記録する（Ｓ５０６、Ｓ５０７）。
　その後ステップ５０８及び５０９の処理により、全てのフォーム番号及び全てのエレメント番号に対して、一連の処理を繰り返す。
　以上に示す処理により、解析データ選定部３４は、解析データ選定画面３０１上で選定された解析対象の各フォームについて、フォーム内のエレメント（入力データ項目）に関する情報を抽出する。なお、以上に示す制御ロジックの全部又は一部は、スキーマ定義部３５によって実行されてもよい。
　図６は、本発明の実施形態の解析データ選定部３４によって抽出される各フォーム内の入力データ項目の具体例を説明する図である。図６では、解析データ選定画面３０１（図３参照）上の全てのフォーム１、２、３が選定された場合に、図５に示す制御ロジックによって抽出される各フォーム内の入力データ項目に関する情報を示している。
　フォーム１が選定された場合に抽出される情報は、（#1, kensaku, keyword:string, shohin_cd:string, kakaku:number）である。"#1"は、フォーム１を一意に識別するための識別子（ＩＤ）である。"kensaku"は、フォーム１の名前である。なお、フォームの名前は、当該フォームに基づいて生成されるテーブルの名前に使用される。"keyword:string"は、フォーム１に含まれる１番目のエレメントの名前及び型情報が、それぞれkeyword、String型であることを示す。"shohin_cd:string"は、フォーム１に含まれる２番目のエレメントの名前及び型情報が、それぞれshohin_cd、String型であることを示す。"kakaku:number"は、フォーム１に含まれる３番目のエレメントの名前及び型情報が、それぞれkakaku、Number型であることを示す。フォーム２、３については、ここでは説明を省略する。
　図７は、本発明の実施形態のスキーマ定義部３５の制御ロジックを示すフローチャートである。スキーマ定義部３５は、以下に示す制御ロジックを実行することによって、各フォームに対応するスキーマ（ここではテーブル）を定義する。
　まずステップ７０１において、スキーマ定義部３５は、解析対象として選定された各フフォームの名前のうち、いずれかのフォームの名前をテーブル名として設定する（Ｓ７０１）。例えばフォーム１のフォーム名は"kensaku"であるので、フォーム１に対応して生成されるテーブルの名前を"Kensaku_Table"とする。
　次にステップ７０２において、スキーマ定義部３５は、フォームの名前に対応して抽出された各入力データ項目（型情報を含む）に基づいて、テーブルを生成する（Ｓ７０２）。例えばフォーム１のフォーム名"kensaku"に対応して抽出される各入力データ項目は、"keyword:string、shohin_cd:string、kakaku:number"である。そのため、このデータセットに基づいて、図４に示すようなテーブル４００の入力データ項目４１０を挿入する。
　その後ステップ７０３において、スキーマ定義部３５は、ステップ７０２で生成されたテーブルに、データセットＩＤ（型情報を含む）を挿入する（Ｓ７０３）。図４に示す例では、テーブル４００にデータセットＩＤ４０６とその属性を挿入する。
　その後ステップ７０４において、スキーマ定義部３５は、セッションＩＤの情報を取得する（Ｓ７０４）。セッションＩＤの情報とは、Ｗｅｂサーバ３上で実行されるＷｅｂアプリケーションに固有の情報である。なお、セッションＩＤに限定されるものではない。
　その後ステップ７０５において、スキーマ定義部３５は、ステップ７０２で生成されたテーブルに、セッションＩＤ（型情報を含む）を挿入する（Ｓ７０５）。図４に示す例では、テーブル４００にセッションＩＤ４０８とその属性を挿入する。
　その後ステップ７０６において、スキーマ定義部３５は、ステップ７０２で生成されたテーブルに、シーケンスＩＤ（型情報を含む）を挿入する（Ｓ７０６）。図４に示す例では、テーブル４００にシーケンスＩＤ４０７とその属性を挿入する。
　その後ステップ７０７の処理により、解析対象として選定された全てのフォームについてステップ７０２～７０６の処理を繰り返す。これにより、スキーマ定義部３５は、解析対象として選定されたフォーム毎にテーブルを自動的に定義することができる。言い換えると、スキーマの定義に係る時間と手間を低減することができる。
　図８は、本発明の実施形態のスキーマ定義部３５によって生成されるテーブル８００の具体例を示す図である。
　図８に示すテーブル８０１、８０２及び８０３は、それぞれフォーム１、２、３から抽出されるデータセットに基づいて定義されたテーブルである。これらテーブル８０１、８０２及び８０３では、データセットＩＤ、シーケンスＩＤ及びセッションＩＤも定義される。
　図９は、本発明の実施形態のデータフィルタ部３７の制御ロジックを示すフローチャートである。図１０は、本発明の実施形態のデータフィルタ部３７によって生成されるデータフィルタリングプログラム１０００の一例を示す図である。
　スキーマ定義部３５によるスキーマ定義が終了すると、データフィルタ部３７は、以下に示す制御ロジックを実行することによって、図１０に示すようなデータフィルタリングプログラム１０００を自動的に生成する。
　まずステップ９０１において、データフィルタ部３７は、フィルタリングすべきデータ項目のセットの番号を選択する（Ｓ９０１）。ここでは、番号"#1"が選択されるものとする。
　次にステップ９０２において、データフィルタ部３７は、データフィルタリングを実行するためのフィルタリング関数を定義する（Ｓ９０２）。図１０に示す例では、フィルタリング関数filtering_kensaku１００３が定義される。
　その後ステップ９０３において、データフィルタ部３７は、ステップ９０２で定義されたフィルタリング関数内に、フィルタリングすべきデータセットをフィルタリングするためのコードを生成する（Ｓ９０３）。図１０に示す例では、コード１００４が生成される。コード１００４は、各入力データ項目"keyword、shohin_cd、kakaku"の値をグローバル変数に保存するためのコードである。
　その後ステップ９０４において、データフィルタ部３７は、Ｗｅｂクライアント２からの入力データ受信時にステップ９０２で定義されたフィルタリング関数を呼び出すコードを生成する（Ｓ９０４）。図１０に示す例では、コード１００２が関数input_kensaku１００１内に生成される。コード１００２は、フィルタリング関数filtering_kensaku１００３を呼び出すコードである。関数input_kensaku１００１は、Ｗｅｂクライアント２からの入力データ受信時に呼び出される関数である。
　ステップ９０５の処理により、全てのデータセットの番号についてステップ９０１～９０４の処理を繰り返す。
　以上に示す処理により、データフィルタ部３７は、スキーマ定義部３５によって定義されたテーブルに従って、データフィルタリングプログラムを自動的に生成する。
　図１１は、本発明の実施形態のデータ送信部２３がデータフィルタ部３７に送信するリクエスト１１００の一例を示す図である。
　図１１に示すリクエスト１１００には、Ｗｅｂ操作画面３０３上のフォーム１（検索フォーム）に入力されたデータが記述されている。リクエスト１１００には、メソッド名（ＧＥＴメソッド又はＰＯＳＴメソッド。図１１に示す例では、ＧＥＴメソッド。）が記述されている。
　ＧＥＴメソッドのリクエストラインには、呼び出し対象のリソースのＵＲＬ（Uniform Resource Locator）１１０１と、クエリ文字列１１０２とが記号"?"によって連結されて記述される。なお、ＵＲＬ１１０１は、絶対パスでも相対パスでもよい。クエリ文字列１１０２には、パラメータ名（フォーム内のエレメントの名前）と値のセットが"&"で連結されて記述される。図１１に示すクエリ文字列１１０２の例では、パラメータkeywordとその値XXXX、パラメータshohin_cdとその値YYYYY、パラメータkakakuとその値UUUUUのセットが記述されている。
　またリクエスト１１００は、Ｄａｔｅ１１０３、Ｒｅｆｅｒｅｒ１１０４及びＣｏｏｋｉｅ１１０５のヘッダ情報を含む。Ｄａｔｅ１１０３には、リクエスト１１００が発行された時間が記述される。Ｒｅｆｅｒｅｒ１１０４には、ＧＥＴメソッドによって指定されたリソースのリンク元のＵＲＬが記述される。Ｃｏｏｋｉｅ１１０５には、Ｗｅｂクライアント２とＷｅｂサーバ３との間のリクエスト１１００の送受信に係わるセッションのＩＤが記述される。
　図１２は、本発明の実施形態のＷｅｂクライアント２及びＷｅｂサーバ３の動作の制御ロジックを示すシーケンス図である。ここでは、Ｗｅｂクライアント２がＷｅｂサーバ３にリクエストを送信する動作と、Ｗｅｂサーバ３が、受信したリクエストに基づいてクライントから送信されたデータをリアルタイムにフィルタリングし、ＤＢ入力用データ生成処理を実行する動作とを説明する。
　まずＷｅｂクライアント２の動作について説明する。
　まずステップ１２０１において、Ｗｅｂクライアント２は、Ｗｅｂユーザによる入力データ確定イベントを契機に、このイベントに対応するデータセットの値をＨＴＴＰのリクエストによりＷｅｂサーバ３に送信する（Ｓ１２０１）。ここでいう入力データ確定イベントとは、Ｗｅｂクライアント２のユーザがフォーム内の実行ボタンを押した際に発生するイベントである。確定イベントは、例えばＷｅｂ操作画面３０３上の検索フォームで、Ｗｅｂクライント２側のユーザがフォーム内に検索キーワードを入力した後、検索という実行ボタンを押下した時に発生する。
　すなわちステップ１２０１では、Ｗｅｂクライアント２は、Ｗｅｂ操作画面３０３上で入力データの確定イベントが発生すると、イベントを発生したフォーム内のデータセットの値をＨＴＴＰのリクエストによりＷｅｂサーバ３に送信する。
　なお、Ｗｅｂ操作画面３０３がＨＴＭＬによって記述される場合、Ｗｅｂ操作画面３０３の情報を記述したＨＴＭＬファイルにおいて実行ボタンが押下された時に送信されるリクエストの種類及びそのリクエストにより呼び出されるリソースのＵＲＬ（本実施例では、Ｗｅｂサーバ３上のリソース）が記述されている。これらの情報を利用して、フォーム内のデータセットの値を送信するＨＴＴＰのリクエストを作成し、Ｗｅｂサーバ３に送信する。その後処理を終了する。
　次にＷｅｂサーバ３の動作について説明する。
　以下に示すＷｅｂサーバ３の動作は、Ｗｅｂサーバ３がＷｅｂクライアント２に提供しているＷｅｂアプリケーションへのＷｅｂクライアント２のユーザのログインによって開始し、ログアウトによって終了する。
　まずステップ１２０２において、Ｗｅｂサーバ３は、ステップ１２０１でＷｅｂクライアント２によって送信されたＨＴＴＰリクエストより、データセットの値を取得する（Ｓ１２０２）。
　次にステップ１２０３において、Ｗｅｂサーバ３は、データフィルタリングプログラムを実行することにより、ステップ１２０２で取得されたデータセットの値をフィルタリングし、一時記録する（Ｓ１２０３）。データフィルタリングプログラムは、ステップ１２０１でＷｅｂクライアント２が送信したＨＴＴＰリクエストにより呼び出したプログラム（本実施例ではＷｅｂサーバ３内のプログラム）内で呼び出すことにより実行される。
　図１０で説明したフィルタリングプログラムは、Ｗｅｂクライアント２側のユーザにより、検索という名前の実行ボタンが押下された時に呼び出されるリソースとしてkensaku.phpプログラムを呼び出した場合の例である。このプログラムの中で、Ｗｅｂクライアント２より送信されたＨＴＴＰリクエストで送信されたフォーム内のエレメントの値（データセットの値）をフィルタするための関数filtering_kensaku１００２を呼び出している。
　次に、Ｗｅｂサーバ３は、Ｗｅｂクライアント２から送信されたＨＴＴＰリクエスト内で指定されたリソースのＵＲＬと、Ｒｅｆｅｒｅｒ情報とに基づいて、リクエスト送信元のフォームの名前を取得する（Ｓ１２０４）。具体的には、Ｒｅｆｅｒｅｒ情報により、フォームに関する情報を記述しているＨＴＭＬファイルを調べる。さらに該ＨＴＭＬファイル内のフォームの情報にフォーム内の実行ボタンが押下された時のアクション情報に該ＵＲＬが記述されているフォームを調べ、該当フォームの名前を取得する。
　その後ステップ１２０５において、Ｗｅｂサーバ３は、フィルタリングされたデータセットを識別するためのデータセットＩＤを生成し、ステップ１２０４で取得された名前のファイルに記録する（Ｓ１２０５）。ファイルとは、例えばＣＳＶ形式のファイルである。ファイルの詳細については、図１４を用いて後述する。
　その後ステップ１２０６～１２０８において、Ｗｅｂサーバ３は、シーケンスＩＤ、セッションＩＤ及びステップ１２０３でフィルタリングされたデータセットの値を、ステップ１２０５で取得された名前のファイルに記録する（Ｓ１２０６～Ｓ１２０８）。
　なお、ステップ１２０４において、Ｗｅｂサーバ３は、ＨＴＴＰリクエスト内に記述された呼び出しリソースのＵＲＬと、Ｒｅｆｅｒｅｒ情報とに基づいて、フォームの情報を記述したＨＴＭＬファイルを調べ、リクエスト送信元のフォームの名前を取得したが、この場合には限らない。例えば、図１３に示すような、フィルタリング関数とフォームの名前とが対応付けられたテーブル１３００を予め作成し、呼び出されたフィルタリング関数に対応付けられたフォーム名を取得してもよい。
　以上に示す処理により、Ｗｅｂクライアント２は、Ｗｅｂサーバ３にリクエストを送信する。一方、Ｗｅｂサーバ３は、受信したリクエストに基づいてリアルタイムフィルタリング及びＤＢ入力用データ生成処理を自動的に実行する。これにより、ＤＢ入力用データの生成にかかる手間と時間を低減することができる。
　図１３は、本発明の実施形態のフィルタリング関数とフォーム名とを対応付けたテーブル１３００の一例を示す図である。図１３に示すテーブル１３００は、データフィルタ部３７がデータフィルタリングプログラムを生成する場合に併せて生成する。
　テーブル１３００は、フィルタリング関数１３０１と、フォームが属するＨＴＭＬファイルのＵＲＬ１３０２と、フォーム名１３０３とを対応付けて格納する。なお、ＵＲＬ１３０２はオプショナルな情報である。但し、ＵＲＬ１３０２も対応付けることにより、異なるＨＴＭＬファイルに属する同じ名前のフォームが存在する場合でかつ、フォーム名から一意に定まるフィルタリング関数名を自動的に生成する場合であっても、フィルタリング関数名と、フィルタリングの対象となるフォームが属するＵＲＬにより、対応するフォーム名を特定することができる。
　図１４は、本発明の実施形態のＤＢ入力用データ７２の具体例を示す図である。
　図１４に示すＤＢ入力用データ７２は、ＤＢ入力用データ７２１～７２３を含む。各ＤＢ入力用データ７２１～７２３は、スキーマ定義部３５によって定義されたテーブル毎、つまりフォーム毎に生成されるＣＳＶ形式のデータファイルである。ファイル名は、フォーム名に拡張子"_log"を連結したものである。
　ＤＢ入力用データ７２１は、フォーム１（フォーム名kensaku）に対応して定義されたテーブルに基づいて生成されたデータファイルである。同様に、ＤＢ入力用データ７２２、７２３は、それぞれフォーム２、３(フォーム名はそれぞれshiborikomi、hattyuu)に対応して定義されたテーブルに基づいて生成されたデータファイルである。
　各ＤＢ入力用データ７２１～７２３の各エントリは、データセットＩＤ、シーケンスＩＤ、セッションＩＤ、各入力データ項目が","によって連結されている。これにより、各ＤＢ入力用データ７２１～７２３を、それぞれの対応するテーブルに容易に格納することができる。
　図１５は、本発明の実施形態のフォームから取得可能なデータを説明する図である。ここでは、Ｗｅｂサーバ３が、解析対象として選定されたフォームから取得可能なデータについて説明する。
　Ｗｅｂサーバ３は、解析データ選定画面３０１（図３参照）上で選定されたフォームに関する情報Ａ及び情報Ｂを取得することができる。
　情報Ａは、選定されたフォームが記述されたＨＴＭＬのＵＲＬである。情報Ｂは、選定されたフォームの情報である。すなわち情報Ｂは、フォームの番号、フォームのアクション情報、フォームの名前及びフォーム内のエレメント名（入力データ項目名）を含む。フォームのアクション情報とは、フォーム内のデータを処理するリソースのパスである。
　Ｗｅｂサーバ３は、Ｗｅｂ操作履歴５１に格納された操作履歴データから取得される情報Ａ及び情報Ｂに基づいて、解析対象として選定されたフォームに関する情報の有無を確認することができる。
　図１６は、本発明の実施形態のＷｅｂ操作履歴５１に格納された操作履歴データ１６００の一例を示す図である。
　図１６に示す操作履歴データ１６００は、Ｗｅｂ操作画面３０３上のフォーム１（検索フォーム）に入力されたデータが格納されたＨＴＴＰリクエストである。操作履歴データ１６００には、メソッド名（ＧＥＴメソッド又はＰＯＳＴメソッド。図１６に示す例では、ＧＥＴメソッド。）が記述されている。
　ＧＥＴメソッドのリクエストラインには、呼び出し対象のリソースのＵＲＬ１６０１と、クエリ文字列１６０２とが記号"?"によって連結されて記述される。なお、ＵＲＬ１６０１は、絶対パスでも相対パスでもよい。クエリ文字列１６０２には、パラメータ名（フォーム内のエレメントの名前）１６０３～１６０５と値のセットが"&"で連結されて記述される。図１６に示すクエリ文字列１６０２の例では、パラメータkeywordとその値XXXX、パラメータshohin_cdとその値YYYYY、パラメータkakakuとその値UUUUUのセットが記述されている。すなわち、ＵＲＬ１６０１及びクエリ文字列１６０２にはフォームから取得可能な情報Ｂが記録されている。
　また操作履歴データ１６００は、Ｄａｔｅ１６０６、Ｒｅｆｅｒｅｒ１６０７及びＣｏｏｋｉｅ１６０８のヘッダ情報を含む。Ｄａｔｅ１６０６には、操作履歴データ１６００が発行された時間が記述される。Ｒｅｆｅｒｅｒ１６０７には、ＧＥＴメソッドによって指定されたリソースのリンク元のＵＲＬが記述される。すなわち、フォームから取得可能な情報Ａが記録される。Ｃｏｏｋｉｅ１６０８には、Ｗｅｂクライアント２とＷｅｂサーバ３との間での操作履歴データ１６００の送受信に係わるセッションのＩＤが記述される。
　Ｗｅｂサーバ３は、操作履歴データ１６００内のＲｅｆｅｒｅｒ１６０７から抽出されるＵＲＬと、ＵＲＬ１６０１に記述されたアクション情報との対応関係に基づいて、解析対象として選定されたフォームに関する情報が存在するか否かを確認することができる。また、解析対象として選定されたフォームに関する情報が存在する場合には、フォーム内の各データ入力項目（図１６に示す例では、keyword、shohin_cd、kakaku）の変数の値を抽出することができる。
　さらに、Ｗｅｂサーバ３は、Ｄａｔｅ１６０６、Ｃｏｏｋｉｅ１６０８の情報に基づいて、それぞれシーケンスＩＤ、セッションＩＤを生成することができる。
　図１７は、本発明の実施形態のデータ抽出・生成部４０の制御ロジックを示すフローチャートである。データ抽出・生成部４０は、Ｗｅｂ操作履歴５１に格納された操作履歴データを解析することにより、スキーマ定義部３５によって定義されたスキーマに対応するデータを抽出する。また、抽出されたデータに基づいて、ＤＢ入力用データ７２を生成する。
　まずステップ１７０１において、データ抽出・生成部４０は、Ｗｅｂ操作履歴５１に格納された操作履歴データ（ＨＴＴＰリクエスト）のＲｅｆｅｒｅｒ情報を参照し、解析対象として選定されたフォームが属するＨＴＭＬファイルのＵＲＬと一致するＵＲＬが記述された操作履歴データを検索する（Ｓ１７０１）。
　次にステップ１７０２において、データ抽出・生成部４０は、ステップ１７０１による検索の結果として抽出された操作履歴データに係るリソースのＵＲＬが、解析対象として選定されたフォームのアクション情報を示すものか否か確認する（Ｓ１７０２）。
　その後ステップ１７０３において、データ抽出・生成部４０は、ステップ１７０２においてＹＥＳの場合、ステップ１７０１で抽出された操作履歴データから、データセットの名前及び値を抽出し記録する（Ｓ１７０３）。
　その後ステップ１７０４において、データ抽出・生成部４０は、ステップ１７０１で抽出された操作履歴データ内のＣｏｏｋｉｅ情報から、セッションＩＤを抽出し記録する（Ｓ１７０４）。
　その後ステップ１７０５において、データ抽出・生成部４０は、ステップ１７０１で抽出された操作履歴データ内のＤａｔｅ情報を、シーケンスＩＤとして記録する（Ｓ１７０５）。
　その後ステップ１７０６において、データ抽出・生成部４０は、ステップ１７０１で抽出された操作履歴データを一意に識別するデータセットＩＤを生成する（Ｓ１７０６）。
　その後ステップ１７０７において、データ抽出・生成部４０は、ステップ１７０３～１７０５で記録されたデータセット、セッションＩＤ、シーケンスＩＤ及びステップ１７０６で生成されたデータセットＩＤに基づいて、解析対象として選定されたフォームに対応するテーブルのＤＢ入力用データを生成する（Ｓ１７０７）。具体的には、図１４に示すようなＤＢ入力用データ７２を生成する。
　以上に示す処理により、データ抽出・生成部４０は、Ｗｅｂ操作履歴５１に格納された操作履歴データを解析することにより、スキーマ定義部３５によって定義されたスキーマに対応するデータを抽出する。また、抽出されたデータに基づいて、ＤＢ入力用データ７２を生成する。
　図１８は、本発明の実施形態の履歴構成解析部３９の制御ロジックを示すフローチャートである。履歴構成解析部３９は、Ｗｅｂ操作履歴５１に格納された各操作履歴データ（ＨＴＴＰリクエスト）に基づいて、Ｗｅｂ操作履歴５１内に存在するフォームに関する情報を取得する。
　まずステップ１８０１において、履歴構成解析部３９は、Ｗｅｂ操作履歴５１内のいずれかの操作履歴データ（ＨＴＴＰリクエスト）のＲｅｆｅｒｅｒ情報に記述されたＵＲＬを取得し記録する（Ｓ１８０１）。
　次にステップ１８０２において、履歴構成解析部３９は、処理対象の操作履歴データのリソースのＵＲＬ情報を取得し記録する（Ｓ１８０２）。
　その後ステップ１８０３において、履歴構成解析部３９は、ステップ１８０１で取得されたＵＲＬのＨＴＭＬファイル内において、ステップ１８０２で取得されたリソースのＵＲＬがアクション情報として指定されたフォームを検索する（Ｓ１８０３）。
　その後ステップ１８０４において、履歴構成解析部３９は、ステップ１８０３による検索の結果として抽出されたフォームの番号を取得し記録する（Ｓ１８０４）。
　その後ステップ１８０５において、履歴構成解析部３９は、ステップ１８０３で取得されたフォームの情報が、フォーム情報テーブルに登録されているか否かを判定する（Ｓ１８０５）。なお、フォーム情報テーブルとは、Ｗｅｂ操作履歴５１内に存在するフォームに関する情報が記録されたテーブルである。フォーム情報テーブルの詳細については、図１９を用いて後述する。
　登録されている場合（Ｓ１８０５でＹＥＳ）、ステップ１８０７に進む。一方、登録されていない場合（Ｓ１８０５でＮＯ）、ステップ１８０６において、履歴構成解析部３９は、ステップ１８０３で取得されたフォームの情報を、フォーム情報テーブルに登録する（Ｓ１８０６）。
　その後ステップ１８０７の処理により、履歴構成解析部３９は、Ｗｅｂ操作履歴５１内に存在する全ての操作履歴データについて、ステップ１８０１～１８０６の処理を繰り返す。
　以上に示す処理により、履歴構成解析部３９は、Ｗｅｂ操作履歴５１に格納された各操作履歴データ（ＨＴＴＰリクエスト）に基づいて、Ｗｅｂ操作履歴５１内に存在するフォームに関する情報を取得し、フォーム情報テーブルに登録する。
　図１９は、本発明の実施形態のフォーム情報テーブル１９００の一例を示す図である。図１９に示すフォーム情報テーブル１９００は、図１８に示す制御ロジックによって生成される。
　フォーム情報テーブル１９００では、Ｒｅｆｅｒｅｒ情報で指定されるＵＲＬ１９０１、リソースのＵＲＬ１９０２及びフォーム番号１９０３が対応付けられて登録される。なお、ＵＲＬ１９０１及びフォーム番号１９０３によって、フォームを一意に識別することができる。
　図２０は、本発明の実施形態のＷｅｂ操作履歴の解析データ選定画面２００１の第一の例を示す図である。図２０に示す解析データ選定画面２００１は、解析データ選定部３４のプログラムを実行することによって出力装置８２に表示される。Ｗｅｂサーバ３のユーザは入力装置８３を用いて、解析データ選定画面２００１上で情報を入力する。
　解析データ選定画面２００１は、Ｗｅｂサーバ３のユーザが解析対象のデータ範囲を選定するための選定画面２００２と、Ｗｅｂクライアント２の表示装置２４上に表示されるＷｅｂ操作画面３０３とを含む。
　なお、図２０に示す選定画面２００２では、図３に示す選定画面３０２と異なり、一部のフォーム（ここではフォーム２）が選択不能に表示される。
　前述の図１８に示す制御ロジックにより、履歴構成解析部３９は、Ｗｅｂ操作履歴５１内に存在するフォーム、すなわち解析可能なフォームを抽出することができる。そこで、解析データ選定部３４は、Ｗｅｂ操作履歴５１を解析する場合には、図１９に示すフォーム情報テーブル１９００に登録されているフォーム、すなわち解析可能なフォームのみを選定可能に提示する。これにより、解析不能なフォーム、すなわち解析してもデータが抽出されないフォームを予め解析対象から除外することができる。
　図２１は、本発明の実施形態のＷｅｂ操作履歴の解析データ選定画面２１０１の第二の例を示す図である。図２１に示す解析データ選定画面２１０１は、解析データ選定部３４のプログラムを実行することによって出力装置８２に表示される。Ｗｅｂサーバ３のユーザは入力装置８３を用いて、解析データ選定画面２１０１上で情報を入力する。
　解析データ選定画面２１０１は、Ｗｅｂサーバ３のユーザが解析対象のデータ範囲を選定するための選定画面２１０２と、Ｗｅｂクライアント２の表示装置２４上に表示されるＷｅｂ操作画面３０３とを含む。
　なお、図２１に示す選定画面２１０２では、図２０に示す選定画面２００２と異なり、選定されたフォームの解析結果をプレビュー（事前確認）するためのチェックボックスが設けられる。
　選定画面２１０２において、Ｗｅｂサーバ３のユーザは、解析対象のデータ範囲をフォーム単位で選定する。さらに、解析対象として選定されたフォームの解析結果をプレビューする場合には、プレビュー用のチェックボックスをチェックし、決定ボタンを押下する。そうすると、Ｗｅｂサーバ３は、チェックされたフォームを解析し、解析結果を表示する。
　図２２は、本発明の実施形態のプレビュー解析の制御ロジックを示すフローチャートである。Ｗｅｂサーバ３は、以下に示す制御ロジックを実行することによって、解析対象として選定されたフォームの解析結果をプレビュー可能にする。
　まずＷｅｂサーバ３のユーザによって、解析データ選定画面２１０１上で解析対象のフォームが選定されると、ステップ２２０１において、Ｗｅｂサーバ３は、選定されたフォームのフォーム番号を取得する（Ｓ２２０１）。具体的には、選定されたフォームのユーザインタフェース上の番号を、Ｗｅｂ操作画面を記述するプログラム上の番号に変換する。
　次にステップ２２０２において、Ｗｅｂサーバ３は、Ｗｅｂ操作履歴５１に格納されたいずれかの操作履歴データ（ＨＴＴＰリクエスト）のＲｅｆｅｒｅｒ情報を参照し、解析対象として選定されたフォームが属するＨＴＭＬファイルのＵＲＬと一致するＵＲＬが記述された操作履歴データを検索する（Ｓ２２０２）。
　その後ステップ２２０３において、Ｗｅｂサーバ３は、ステップ２２０２による検索の結果として抽出された操作履歴データに係るリソースのＵＲＬが、解析対象として選定されたフォームのアクション情報を示すものか否か確認する（Ｓ２２０３）。なお、解析対象として選定されたフォームは、フォーム番号によって識別される。
　抽出された操作履歴データに係るリソースのＵＲＬが、選定されたフォームのアクション情報を示さない場合（Ｓ２２０４でＮＯ）、ステップ２２０２に戻って別の操作履歴データについて処理を繰り返す。
　一方、抽出された操作履歴データに係るリソースのＵＲＬが、選定されたフォームのアクション情報を示す場合（Ｓ２２０４でＹＥＳ）、Ｗｅｂサーバ３は、ステップ２２０２で抽出されたフォームの番号を記録する（Ｓ２２０５）。
　その後ステップ２２０６の処理により、Ｗｅｂサーバ３は、Ｗｅｂ操作履歴５１内に存在する全ての操作履歴データについて、ステップ２２０２～２２０５の処理を繰り返す。
　その後ステップ２２０７において、Ｗｅｂサーバ３は、ステップ２２０５で記録されたフォームの番号に基づいて、Ｗｅｂ操作履歴５１内に存在しないフォームを検索する（Ｓ２２０７）。
　該当フォームがある場合（Ｓ２２０８でＹＥＳ）、ステップ２２０９において、Ｗｅｂサーバ３は、該当フォーム、すなわちＷｅｂ操作履歴５１内に存在しないフォームを表示する（Ｓ２２０９）。具体的には、Ｗｅｂ操作履歴５１内に存在しないフォームの番号を取得し、取得されたフォームの番号をユーザインタフェースの番号に変換し、ポップアップウィンドウに表示する。ステップ２２０９で表示される表示画面の例については、図２３を用いて後述する。
　一方、該当フォームがない場合（Ｓ２２０８でＮＯ）、ステップ２２１０において、Ｗｅｂサーバ３は、解析対象として選定された全てのフォームのデータがＷｅｂ操作履歴５１に存在する旨を、ポップアップウィンドウに表示する（Ｓ２２１０）。
　図２３は、本発明の実施形態のプレビュー解析結果の表示画面２３００の第一の具体例を示す図である。図２３に示す表示画面２３００は、解析対象として選定されたフォーム（ここではフォーム２）がＷｅｂ操作履歴５１内に存在しない場合に表示されるポップアップウィンドウである。
　この表示画面２３００によれば、Ｗｅｂサーバ３のユーザは、現在の設定が「Ｗｅｂ操作履歴５１内に存在しないフォーム（ここではフォーム２）のデータを取得し、リアルタイムにＤＢ入力用データ７２を生成する設定」であるかの確認を指示することができる。
　設定を確認する場合、Ｗｅｂサーバ３のユーザは入力装置８３を用いて"設定を確認する"ボタンを押下する。そうすると、Ｗｅｂサーバ３は後述する図２７に示す制御ロジックを実行し、設定の確認結果を表示する。一方、プレビューを終了する場合、"プレビューを終了する"ボタンを押下する。そうすると、Ｗｅｂサーバ３はプレビューを終了する。
　図２４は、本発明の実施形態のプレビュー解析結果の表示画面２４００の第二の具体例を示す図である。図２４に示す表示画面２４００は、図２３の表示画面２３００上で"設定を確認する"ボタンが押下された場合に表示されるポップアップウィンドウである。
　この表示画面２４００によれば、Ｗｅｂサーバ３のユーザは、現在の設定が「Ｗｅｂ操作履歴５１内に存在しないフォーム（ここではフォーム２）のデータを取得し、リアルタイムにＤＢ入力用データ７２を生成する設定」ではない場合に、設定変更を指示することができる。
　設定を変更する場合、Ｗｅｂサーバ３のユーザは入力装置８３を用いて"設定を変更し、プレビューを終了する"ボタンを押下する。そうすると、Ｗｅｂサーバ３は後述する図２８に示す制御ロジックを実行し、設定を変更する。その後プレビューを終了する。一方、設定を変更しない場合、"設定を変更せずにプレビューを終了する"ボタンを押下する。そうすると、Ｗｅｂサーバ３はプレビューを終了する。
　図２５は、本発明の実施形態のリアルタイムデータ解析に係る現在の設定を登録する制御ロジックを示すフローチャートである。ここでは、解析対象として選定されたフォームのうち、リアルタイムにＤＢ入力用データ７２を生成するよう現在設定されているフォームを登録する。
　まずステップ２５０１において、Ｗｅｂサーバ３は、Ｗｅｂサーバ３のユーザによって解析対象として選定されたフォームのうち、いずれかのフォームが属するＨＴＭＬファイルのＵＲＬを取得する（Ｓ２５０１）。
　次にステップ２５０２において、Ｗｅｂサーバ３は、処理対象のフォームの番号を取得する（Ｓ２５０２）。
　その後ステップ２５０３において、Ｗｅｂサーバ３は、処理対象のフォームについて、ステップ２５０１で取得されたＵＲＬと、ステップ２５０２で取得されたフォームの番号とを対応付けて設定テーブルに記録する（Ｓ２５０３）。
　ここでいう設定テーブルとは、リアルタイムにＤＢ入力用データ７２を生成するよう現在設定されているフォームに関する情報を格納するテーブルである。設定テーブルの詳細については、図２６を用いて後述する。
　ステップ２５０４の処理により、Ｗｅｂサーバ３は、解析対象として選定された全てのフォームについて、ステップ２５０１～２５０３の処理を繰り返す。
　以上に示す処理により、Ｗｅｂサーバ３は、解析対象として選定されたフォームのうち、リアルタイムにＤＢ入力用データ７２を生成するよう現在設定されているフォームに関する情報を、設定テーブル２６００に登録する。
　図２６は、本発明の実施形態の設定テーブル２６００の一例を示す図である。設定テーブル２６００は、リアルタイムにＤＢ入力用データ７２を生成するよう現在設定されているフォームに関する情報を格納する。
　設定テーブル２６００では、ＨＴＭＬファイルのＵＲＬ２６０１と、フォーム番号２６０２とが対応付けて格納される。Ｗｅｂサーバ３は設定テーブル２６００を参照し、Ｗｅｂ操作履歴５１に存在しないフォームが、リアルタイムにＤＢ入力用データ７２を生成するよう現在設定されているフォームであるか否かを確認することができる。
　図２７は、本発明の実施形態のリアルタイムデータ解析に係る現在の設定を確認する制御ロジックを示すフローチャートである。
　図２３に示すような表示画面２３００上で"設定を確認する"ボタンが押下されると、まずステップ２７０１において、Ｗｅｂサーバ３は、Ｗｅｂ操作履歴５１に存在しないと判定されたフォームに関する情報が設定テーブル２６００に登録されているか検索する（Ｓ２７０１）。
　具体的には、設定テーブル２６００を参照し、Ｗｅｂ操作履歴５１に存在しないと判定されたフォームが所属するＨＴＭＬファイルのＵＲＬと、フォームの番号とが対応付けて登録されているか検索する。
　登録されていない場合（Ｓ２７０２でＮＯ）、ステップ２７０３において、Ｗｅｂサーバ３は、該当フォームの情報を返す（Ｓ２７０３）。該当フォームとは、Ｗｅｂ操作履歴５１に存在しないと判定されたフォームのうち、設定テーブル２６００に登録されていないフォームである。またフォームの情報とは、フォームの属するＨＴＭＬファイルのＵＲＬと、フォームの番号とを含む。一方、登録されている場合（Ｓ２７０２でＹＥＳ）、該当フォームがない旨を返す（Ｓ２７０４）。
　その後ステップ２７０５において、Ｗｅｂサーバ３は、ステップ２７０３で返されたフォームの情報のうちのフォームの番号（プログラム上の番号）を、ユーザインタフェース上の番号に変換する（Ｓ２７０５）。
　その後ステップ２７０６において、Ｗｅｂサーバ３は、変換後のフォームの番号をメッセージボックスで表示する（Ｓ２７０６）。ここでいうメッセージボックスとは、図２４の表示画面２４００に示すようなメッセージボックスである。
　なお、ステップ２７０２からステップ２７０４に進んだ場合、ステップ２７０６では、Ｗｅｂサーバ３は、該当フォームがない旨、すなわちＷｅｂ操作履歴５１に存在しないと判定されたフォームの全てが、リアルタイムにＤＢ入力用データ７２を生成するよう現在設定されている旨を表示してもよい。
　以上に示す処理により、Ｗｅｂサーバ３は、ユーザによる設定確認指示に基づいて、リアルタイムデータ解析に係る現在の設定を確認し、確認結果を表示する。
　図２８は、本発明の実施形態のリアルタイムデータ解析に係る設定を変更する制御ロジックを示すフローチャートである。
　図２４に示すような表示画面２４００上で"設定を変更し、プレビューを終了する"ボタンが押下されると、まずステップ２８０１において、Ｗｅｂサーバ３は、設定変更対象のフォームの入力データを、Ｗｅｂ操作履歴５１に記録する（Ｓ２８０１）。
　次にステップ２８０２において、Ｗｅｂサーバ３は、設定変更対象のフォームに対応するスキーマ（テーブル）を新たに定義し、設定変更対象のフォームの入力データ（ＨＴＴＰのリクエスト）に基づいて、リアルタイムにＤＢ入力用データ７２を生成する（Ｓ２８０２）。
　以上に示す処理により、Ｗｅｂサーバ３は、Ｗｅｂ操作履歴５１に存在しないと判定されたフォームの入力データを、Ｗｅｂ操作履歴５１に記録するよう設定変更する。また、Ｗｅｂ操作履歴５１に存在しないと判定されたフォームに対応するスキーマを新たに定義し、このフォームの入力データをフィルタリングすることによって、リアルタイムにＤＢ入力用データ７２を生成する。
　図２９Ａ及び図２９Ｂは、本発明の実施形態の履歴構成解析部３９の制御ロジックの変形例を示すフローチャートである。
　ここでは、履歴構成解析部３９は、Ｗｅｂ操作履歴５１に格納された各操作履歴データ（ＨＴＴＰリクエスト）に基づいて、Ｗｅｂ操作履歴５１内に存在するフォームに関する情報を取得する。本変形例では、Ｗｅｂ操作履歴５１内に存在するフォーム毎に、操作履歴データの記録期間に関する情報も併せて取得する。なお、前述の図１８と同様の処理については、同一の符号を付して重複する説明を適宜省略する。
　ステップ２９０１において、履歴構成解析部３９は、処理対象の操作履歴データ（ＨＴＴＰリクエスト）のＤａｔｅ情報を、最新データとして登録する（Ｓ２９０１）。具体的には、図３０に示すようなフォーム情報テーブル３０００のＤａｔｅ情報３００４、３００５に登録する。
　ステップ２９０２において、履歴構成解析部３９は、処理対象の操作履歴データの期間情報を登録する（Ｓ２９０２）。
　すなわちステップ２９０３において、履歴構成解析部３９は、処理対象の操作履歴データのＤａｔｅ情報が最も新しいか否か判定する（Ｓ２９０３）。具体的には、処理対象の操作履歴データのＤａｔｅ情報と、フォーム情報テーブル３０００のＤａｔｅ情報３００４に格納されたＤａｔｅ情報との比較に基づいて判定する。
　処理対象の操作履歴データのＤａｔｅ情報が最も新しい場合（Ｓ２９０３でＹＥＳ）、履歴構成解析部３９は、このＤａｔｅ情報を最も新しいＤａｔｅ情報として登録する（Ｓ２９０４）。
　一方、処理対象の操作履歴データのＤａｔｅ情報が最も新しくはない場合（Ｓ２９０３でＮＯ）、履歴構成解析部３９は、処理対象の操作履歴データのＤａｔｅ情報が最も古いか否か判定する（Ｓ２９０５）。具体的には、処理対象の操作履歴データのＤａｔｅ情報と、フォーム情報テーブル３０００のＤａｔｅ情報３００５に格納されたＤａｔｅ情報との比較に基づいて判定する。
　処理対象の操作履歴データのＤａｔｅ情報が最も古い場合（Ｓ２９０５でＹＥＳ）、履歴構成解析部３９は、このＤａｔｅ情報を最も古いＤａｔｅ情報として登録する（Ｓ２９０６）。一方、処理対象のデータのＤａｔｅ情報が最も古くはない場合（Ｓ２９０５でＮＯ）、履歴構成解析部３９は、ステップ２９０２の処理を終了する。
　以上に示す処理により、履歴構成解析部３９は、Ｗｅｂ操作履歴５１に格納された各操作履歴データ（ＨＴＴＰリクエスト）に基づいて、Ｗｅｂ操作履歴５１内に存在するフォームに関する情報を取得する。本変形例では、Ｗｅｂ操作履歴５１内に存在するフォーム毎に、操作履歴データの記録期間に関する情報も併せて取得する。これにより、フォーム毎に解析可能な期間を調べることができる。
　図３０は、本発明の実施形態のフォーム情報テーブル３０００の変形例を示す図である。図３０に示すフォーム情報テーブル３０００は、図２９Ａ及び図２９Ｂに示す制御ロジックによって生成される。
　フォーム情報テーブル３０００では、Ｒｅｆｅｒｅｒ情報で指定されるＵＲＬ３００１、リソースのＵＲＬ３００２、フォーム番号３００３、最も新しいデータのＤａｔｅ情報３００４及び最も古いデータのＤａｔｅ情報３００５が対応付けられて登録される。
　なお、ＵＲＬ３００１及びフォーム番号３００３によって、フォームを一意に識別することができる。また、Ｄａｔｅ情報３００４、３００５によって、各フォームにおけるデータの存在期間を記録することができる。
　図３１は、本発明の実施形態の解析可能データ提示画面３１００の一例を示す図である。図３１に示す解析可能データ提示画面３１００は、解析データ選定部３４のプログラムを実行することによって出力装置８２に表示される。
　解析可能データ提示画面３１００では、Ｗｅｂサーバ３のユーザによって選定された解析対象のフォーム毎に、Ｗｅｂ操作履歴５１内にデータが存在するか否かを示すデータの有無情報、及び、Ｗｅｂ操作履歴５１内にデータが存在する場合には解析可能な範囲（日時）を示す期間情報が示される。
　前述の図２９Ａ及び２９Ｂに示す制御ロジックにより、履歴構成解析部３９は、Ｗｅｂ操作履歴５１内に存在する各フォームの解析可能な期間情報を抽出することができる。そこで、解析データ選定部３４は、Ｗｅｂ操作履歴５１を解析する場合には、図３０に示すフォーム情報テーブル３０００に基づいて、解析可能なフォーム及び解析可能な期間情報を提示する。
　図３２は、本発明の実施形態のＷｅｂ操作履歴の解析データ選定画面３２０１の変形例を示す図である。図３２に示す解析データ選定画面３２０１は、解析データ選定部３４のプログラムを実行することによって出力装置８２に表示される。Ｗｅｂサーバ３のユーザは入力装置８３を用いて、解析データ選定画面３２０１上で情報を入力する。
　解析データ選定画面３２０１は、Ｗｅｂサーバ３のユーザが解析対象のデータ範囲を選定するための選定画面３２０２と、選定画面３２０２上で選定されたフォームについての解析期間を設定するための解析期間設定メニュー３２０３と、Ｗｅｂクライアント２の表示装置２４上に表示されるＷｅｂ操作画面３０３とを含む。
　なお、図３２に示す選定画面３２０２は、図２１に示す選定画面２１０２と同様である。
　前述の図２９Ａ及び２９Ｂに示す制御ロジックにより、履歴構成解析部３９は、Ｗｅｂ操作履歴５１内に存在する各フォームの解析可能な期間情報を抽出することができる。そこで、解析データ選定部３４は、解析期間設定メニュー３２０３が選択された場合には、フォーム情報テーブル３０００に基づいて、選定されたフォームの解析期間の設定画面を提示する。解析期間の設定画面の詳細については、図３３を用いて後述する。
　図３３は、本発明の実施形態の解析期間設定画面３３０１の具体例を示す図である。図３３に示す解析期間設定画面３３０１は、解析期間設定メニュー３２０３が選択された場合には、選定されたフォーム（図３２ではフォーム１、３）の解析期間の設定を促す画面である。
　Ｗｅｂサーバ３のユーザは入力装置８３を用いて、解析期間設定画面３３０１上で解析対象期間の開始日時と終了日時を設定する。これにより、フォーム毎にＷｅｂ操作履歴５１内の操作履歴データの解析期間を設定することができる。
　図３４は、本発明の実施形態のセッションテーブル３４００の一例を示す図である。
　セッションテーブル３４００は、セッション情報を管理するためのテーブルである。セッション情報とは、セッションＩＤによって特定されるユーザ情報、セッションに係る時間情報及び地域情報等を含む。
　このセッションテーブル３４００と、スキーマ定義部３５によって定義される各テーブルとは、セッションＩＤを介して相互に関連付けることができる。これにより、スキーマ定義部３５によって定義される各テーブルに挿入されたデータを、セッションテーブル３４００によって管理されるセッション情報を用いて多面的に解析することができる。また、セッションＩＤを介して各テーブルの構成要素であるデータの関係を分析することができる。
　以上、本発明を添付の図面を参照して詳細に説明したが、本発明はこのような具体的構成に限定されるものではなく、添付した請求の範囲の趣旨内における様々な変更及び同等の構成を含むものである。

Claims (16)

  1. 　プログラムを実行するプロセッサと、前記プロセッサによって実行されるプログラムを格納するメモリとを備える計算機であって、
    　前記プロセッサは、
    　Ｗｅｂ操作画面の構成単位であるフォーム単位で、データベースのデータ項目を選定させる画面を表示する機能と、
    　当該計算機のユーザにより選定されたフォーム毎に、当該フォームに含まれる入力データ項目に基づいてスキーマを定義し、前記メモリに記録する機能を持つことを特徴とする計算機。
  2. 　前記Ｗｅｂ操作画面における入力データの履歴を記憶するＷｅｂ操作履歴記憶部に接続され、
    　前記プロセッサは、前記Ｗｅｂ操作履歴記憶部に記憶された入力データの履歴を解析することにより、前記Ｗｅｂ操作履歴記憶部に存在するフォームの情報を抽出し、抽出されたフォームの情報に基づいて操作履歴の解析対象となるデータを選定可能にするためのデータ及び操作画面を作成する機能を持つことを特徴とする請求項１に記載の計算機。
  3. 　前記プロセッサは、選定されたフォーム毎に、当該フォームに対応して定義された前記スキーマと、前記Ｗｅｂ操作履歴記憶部に記憶された入力データの履歴のうちの当該フォームに対応する入力データとに基づいて、前記データベースに格納すべき入力データを抽出する機能を持つことを特徴とする請求項２に記載の計算機。
  4. 　前記プロセッサは、前記Ｗｅｂ操作履歴データベースに記憶された入力データの履歴を解析する場合に、前記スキーマが定義されているフォームに対応する入力データの有無を判定する機能を持つことを特徴とする請求項２に記載の計算機。
  5. 　前記プロセッサは、前記スキーマが定義されていないフォームに対応する入力データが前記Ｗｅｂ操作履歴記憶部に存在する場合、当該フォームに含まれる入力データ項目に基づいてスキーマを新たに定義可能な機能を持つことを特徴とする請求項４に記載の計算機。
  6. 　クライアント装置上で表示させたＷｅｂ操作画面における入力データを受信する計算機であって、
    　前記プロセッサは、前記メモリに記憶されたスキーマに従って、前記クライアント装置から送られてくるリクエストから、前記スキーマに対応するフォームの入力データをフィルタリングする機能を持つことを特徴とする請求項１に記載の計算機。
  7. 　前記プロセッサは、フィルタリングされた前記入力データに基づいて、前記データベースに格納するための入力用データを生成する機能を持つことを特徴とする請求項６に記載の計算機。
  8. 　Ｗｅｂ操作画面を表示させるクライアント装置と、前記Ｗｅｂ操作画面における入力データを前記クライアント装置から受信するサーバ装置を備える計算機システムであって、
    　前記サーバ装置は、
    　前記Ｗｅｂ操作画面の構成単位であるフォーム単位で、データベースに格納すべき入力データ項目を選定させる操作画面を表示し、
    　選定されたフォーム毎に、当該フォームに含まれる入力データ項目に基づいてスキーマを定義し、
    　該定義されたスキーマを該サーバ装置が備えるメモリに記録することを特徴とする計算機システム。
  9. 　前記サーバ装置は、クライアント装置上で表示させたＷｅｂ操作画面における入力データを受信し、前記受信した入力データを、所定の形式で記録し保存する操作履歴保存機能及びその操作履歴記憶部を備えることを特徴とする請求項８に記載の計算機システム。
  10. 　前記サーバ装置は、前記操作履歴記憶部に記憶された入力データの履歴を解析することによって、前記操作履歴記憶部に存在するフォームの情報を抽出し、抽出されたフォームの情報に基づいて操作履歴の解析対象となるデータを選定可能にするためのデータ及び操作画面を作成する機能を持つことを特徴とする請求項９に記載の計算機システム。
  11. 　前記サーバ装置は、選定されたフォーム毎に、当該フォームに対応して定義された前記スキーマと、前記操作履歴記憶部に記憶された入力データの履歴のうちの当該フォームに対応する入力データとに基づいて、前記操作履歴記憶部に格納すべき入力データを抽出することを特徴とする請求項１０に記載の計算機システム。
  12. 　前記サーバ装置は、前記操作履歴記憶部に記憶された入力データの履歴を解析する場合に、前記スキーマが定義されているフォームに対応する入力データの有無を判定することを特徴とする請求項１０に記載の計算機システム。
  13. 　前記サーバ装置は、前記スキーマが定義されていないフォームに対応する入力データが前記操作履歴記憶部に存在する場合、当該フォームに含まれる入力データ項目に基づいてスキーマを新たに定義可能であることを特徴とする請求項１２に記載の計算機システム。
  14. 　前記サーバ装置は、前記メモリに記憶されたスキーマに従って、前記クライアント装置から送られてくるリクエストから、前記スキーマに対応するフォームの入力データをフィルタリングすることを特徴とする請求項９に記載の計算機システム。
  15. 　前記サーバ装置は、フィルタリングされた前記入力データに基づいて、前記データベースに格納するための入力用データを生成することを特徴とする請求項１４に記載の計算機システム。
  16. 　プログラムを実行するプロセッサと、前記プロセッサによって実行されるプログラムを格納するメモリとを備える計算機におけるデータベースの構築支援方法であって、
    　前記プロセッサが、
    　Ｗｅｂ操作画面の構成単位であるフォーム単位で、データベースのデータ項目を選定させる画面を表示する手順と、
    　前記データベースのデータ項目を選定させる画面で選定されたフォーム毎に、当該フォームに含まれる入力データ項目に基づいてスキーマを定義する手順と、
    　該定義されたスキーマを当該計算機が備えるメモリに記録する手順と、
    　を含むことを特徴とするデータベースの構築支援方法。
PCT/JP2011/070882 2011-09-13 2011-09-13 計算機、計算機システム及びデータベースの構築支援方法 WO2013038508A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2013533387A JP5775594B2 (ja) 2011-09-13 2011-09-13 計算機、計算機システム及びデータベースの構築支援方法
PCT/JP2011/070882 WO2013038508A1 (ja) 2011-09-13 2011-09-13 計算機、計算機システム及びデータベースの構築支援方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2011/070882 WO2013038508A1 (ja) 2011-09-13 2011-09-13 計算機、計算機システム及びデータベースの構築支援方法

Publications (1)

Publication Number Publication Date
WO2013038508A1 true WO2013038508A1 (ja) 2013-03-21

Family

ID=47882770

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/070882 WO2013038508A1 (ja) 2011-09-13 2011-09-13 計算機、計算機システム及びデータベースの構築支援方法

Country Status (2)

Country Link
JP (1) JP5775594B2 (ja)
WO (1) WO2013038508A1 (ja)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06149894A (ja) * 1992-11-09 1994-05-31 Nippon Telegr & Teleph Corp <Ntt> スキーマ定義情報作成方法
JPH08147321A (ja) * 1994-11-22 1996-06-07 Fuji Xerox Co Ltd データベース装置
JPH09305454A (ja) * 1996-05-20 1997-11-28 Nec Corp データベース構築装置
JP2001307002A (ja) * 2000-04-20 2001-11-02 Fuji Xerox Co Ltd データ入力フォーム生成システム、データ入力フォーム生成方法、及び、コンピュータ読み取り可能な記録媒体
JP2003271579A (ja) * 2002-03-12 2003-09-26 Seiko Epson Corp 報告書作成システムと報告書作成方法と報告書作成プログラム
JP2005056255A (ja) * 2003-08-06 2005-03-03 Fuji Xerox Co Ltd フォーム生成集計装置及び記録媒体

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06149894A (ja) * 1992-11-09 1994-05-31 Nippon Telegr & Teleph Corp <Ntt> スキーマ定義情報作成方法
JPH08147321A (ja) * 1994-11-22 1996-06-07 Fuji Xerox Co Ltd データベース装置
JPH09305454A (ja) * 1996-05-20 1997-11-28 Nec Corp データベース構築装置
JP2001307002A (ja) * 2000-04-20 2001-11-02 Fuji Xerox Co Ltd データ入力フォーム生成システム、データ入力フォーム生成方法、及び、コンピュータ読み取り可能な記録媒体
JP2003271579A (ja) * 2002-03-12 2003-09-26 Seiko Epson Corp 報告書作成システムと報告書作成方法と報告書作成プログラム
JP2005056255A (ja) * 2003-08-06 2005-03-03 Fuji Xerox Co Ltd フォーム生成集計装置及び記録媒体

Also Published As

Publication number Publication date
JPWO2013038508A1 (ja) 2015-03-23
JP5775594B2 (ja) 2015-09-09

Similar Documents

Publication Publication Date Title
Diouf et al. Web scraping: state-of-the-art and areas of application
Das et al. Creating meaningful data from web logs for improving the impressiveness of a website by using path analysis method
US10078843B2 (en) Systems and methods for analyzing consumer sentiment with social perspective insight
CN102073726B (zh) 搜索引擎系统的结构化数据的引入方法和装置
US20070294230A1 (en) Dynamic content analysis of collected online discussions
CN108090104B (zh) 用于获取网页信息的方法和装置
CN111708774B (zh) 一种基于大数据的产业分析系统
CN110489653A (zh) 舆情信息查询方法和装置、系统、电子设备、存储介质
US11461333B2 (en) Vertical union of feature-based datasets
WO2016075829A1 (ja) データ取得プログラム、データ取得方法及びデータ取得装置
CN103198078A (zh) 一种互联网新闻事件报道趋势分析方法及系统
KR102025813B1 (ko) 사건 흐름 정보를 제공하기 위한 연대순 정보 기반 큐레이션 장치 및 그것의 제어방법
JP2003281149A (ja) アクセス権限設定方法および構造化文書管理システム
JP5775594B2 (ja) 計算機、計算機システム及びデータベースの構築支援方法
US8856152B2 (en) Apparatus and method for visualizing data
CN113407678B (zh) 知识图谱构建方法、装置和设备
CN109213909A (zh) 一种融合搜索与计算的大数据分析系统及其分析方法
CN113515715B (zh) 埋点事件编码的生成方法、处理方法及相关设备
JP2005189942A (ja) Ｗｅｂサイトアクセス状況の集計方法、そのシステム、およびプログラム
CN109408704B (zh) 基金数据关联方法、系统、计算机设备和存储介质
US9582782B2 (en) Discovering a reporting model from an existing reporting environment
Li et al. Research of network data mining based on reliability source under big data environment
CN113190753B (zh) 数据采集方法和装置、电子设备、计算机可读介质
JP7098122B1 (ja) 記事監視システム、注目情報が記述された記事の監視方法、コンピュータプログラム
Hadi et al. Resource Description Framework Representation for Transaction Log File

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11872480

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2013533387

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11872480

Country of ref document: EP

Kind code of ref document: A1