WO2018016001A1 - データモデリングシステム、データモデリング方法 - Google Patents

データモデリングシステム、データモデリング方法 Download PDF

Info

Publication number
WO2018016001A1
WO2018016001A1 PCT/JP2016/071156 JP2016071156W WO2018016001A1 WO 2018016001 A1 WO2018016001 A1 WO 2018016001A1 JP 2016071156 W JP2016071156 W JP 2016071156W WO 2018016001 A1 WO2018016001 A1 WO 2018016001A1
Authority
WO
WIPO (PCT)
Prior art keywords
modeling
column
combined
data
unit
Prior art date
Application number
PCT/JP2016/071156
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 PCT/JP2016/071156 priority Critical patent/WO2018016001A1/ja
Publication of WO2018016001A1 publication Critical patent/WO2018016001A1/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

Definitions

  • the present invention relates to a data modeling system and a data modeling method for performing data modeling when performing data analysis.
  • IT Information Technology
  • Non-patent document 1 In order to expand the scope of business intelligence application, tools that enable self-service business intelligence, such as data modeling by business users themselves, not IT engineers, have been announced for the purpose of analysis and visualization ( Non-patent document 1, Non-patent document 2).
  • Patent Document 1 the consistency between databases is manually interpreted. However, these tasks were carried out by IT technology specialists for a reasonable period of time, but in the process of applying business intelligence to a wider range of work, it is complicated due to human interpretation, The cost is an obstacle.
  • Non-Patent Documents 1 and 2 data modeling is performed by simple user input such as keyword input and axis selection, and visualization and analysis are possible. Even in such a tool, a premise for ensuring consistency between databases serving as inputs is required, and based on this premise, it is possible to perform unique data modeling from user input. However, as in the case of Patent Document 1, since manual interpretation is necessary, the complexity and cost for that is an obstacle.
  • the present invention has been made in view of the above, and provides a data modeling system and a data modeling method capable of reducing manual complexity and interpreting costs when interpreting consistency between databases.
  • the purpose is to do.
  • a data modeling system is a data modeling system that combines a plurality of tables stored in one or a plurality of databases.
  • a column input unit that accepts designation of a column that is an axis to be joined, a column search unit that searches a table including a column similar to the column that is the axis from the one or more databases, and a search
  • a column that is similar to the column that is the axis included in the table is combined by a plurality of methods, and the combined table is output as a modeling candidate, and the combined table candidate is designated next from the input unit.
  • a column extraction unit that extracts similar columns with a certain degree of similarity to the next column and A column selection receiving unit that outputs a next column, receives a column selected by the user from the output next column, narrows down the combined table candidates based on the next column, and newly creates a table including the next column.
  • a table candidate update unit that outputs the combined table as a modeling candidate.
  • the present invention can be grasped as a data modeling method performed by the data modeling system.
  • FIG. 1 shows a configuration example of a data modeling system to which a data modeling system and a data modeling method according to the present invention are applied.
  • a data modeling system and the data modeling method according to the present invention are applied to a system constituted by a plurality of information processing apparatuses such as a general PC (Personal Computer) is described.
  • PC Personal Computer
  • the data modeling system includes a modeling environment 100, a metadata generation environment 130, and a visualization / analysis environment 170. Each environment is connected to be communicable by the networks 160 and 161.
  • the modeling environment 100, the metadata generation environment 130, and the visualization / analysis environment 170 are configured by one or a plurality of computers as hardware.
  • the metadata generation environment 130 includes a CPU 140 and an external storage device 150.
  • the CPU 140 executes a metadata generation unit 141 implemented as software.
  • the external storage device 150 stores a data source storage DB 151 and a metadata storage DB 152, which can be referred to from the modeling environment 100 through the network 160.
  • the modeling environment 100 includes a CPU 110, an external storage device 120, an input device 101, and an output device 102.
  • the CPU 110 executes a modeling engine 111 implemented as software, an uncertainty determination / resolution unit 112, and a UI input unit 113 and a UI output unit 114 that display and accept a user interface such as a GUI.
  • the modeling engine 111 is the core of the modeling apparatus.
  • the external storage device 120 is connected to the CPU 110 and holds a modeling state storage unit 121, a modeling result storage DB 122, and an uncertainty definition list 123.
  • the modeling state storage unit 121 stores a working state including a history in the modeling engine.
  • the modeling result storage DB 122 stores a table that is a result generated by the modeling engine.
  • the uncertainty definition list 123 is prepared together with the modeling engine 111 and the uncertainty determination / resolution unit 112 in advance as software implementation or its external definition. Of these, the modeling state storage unit 121 and the modeling result storage DB 122 are in a state that can be referred to from the visualization / analysis environment via the network 161.
  • the input device 101 is an input device such as a keyboard, a mouse, or a touch panel, for example, and receives information input from the user and delivers it to the UI input unit 113.
  • the output device 102 is an output device such as a display, for example, and has a role of displaying video information generated by the UI output unit 114 to the user.
  • the visualization / analysis environment 170 includes a CPU 180, an input device 171, and an output device 172.
  • the CPU 180 includes a visualization / analysis unit 181, a UI input unit 182, and a UI output unit 183.
  • the visualization / analysis result generated by the visualization / analysis unit 181 is displayed on the user by the output device 172 via the UI output unit 183.
  • the visualization / analysis instruction by the user is sent from the input device 171 to the UI input unit 182 and notified to the visualization / analysis unit 181.
  • Metadata is additional information linked to a database column.
  • the column value and the relationship between values are statistically analyzed. Information obtained.
  • An example of metadata is shown in FIG.
  • the table 601 is an example of a single column metadata table.
  • the data type, the number of digits, the uniqueness, the number of valid elements, and the like are held using columns included in the table group stored in the data source storage DB 151 as keys.
  • the uniqueness is an item indicating whether or not the data is uniquely identified in the table.
  • the valid element is an item indicating the number of data when there is no overlap in the value of each data.
  • the table 601 indicates that the table name is table A, and the column name is a table having two items, column 1 and column 2.
  • the item shown in column 1 is a 9-digit numeric item, which indicates that there are 1101 unique data.
  • the item shown in column 2 is a 6-9-digit character string type item, indicating that there are 22 data including duplicate data.
  • the table 602 is a metadata table for inter-column relationships. The combination of two tables and columns is used as a key, and the number of common elements of the values of both columns is held.
  • the common element is an item indicating the number of data whose values are common between the columns of the table. As shown in the lower part of FIG. 6, the table 602 indicates that there is no common element between the column 1 of the table A and the column 1 of the table C, and the data in the columns of the respective tables do not overlap. Similarly, between column 1 of table A and column 2 of table C, there are 22 common elements, that is, 22 types of data having the same value.
  • Metadata tables 601 and 602 are stored in the metadata storage DB 152 and referred to by the modeling engine 111 at an arbitrary timing.
  • the table and column in the data source storage DB 151 are the search keys.
  • Metadata generation in the metadata generation environment 130 may be performed once when the analysis target table stored in the data source storage unit 151 is updated. Generally, it is assumed that modeling operations using metadata created in the same analysis range are repeatedly performed after the range of analysis is determined by accumulating tables to be analyzed.
  • the metadata storage DB 152 includes analysis auxiliary information prepared in advance as auxiliary information when using metadata. Hold.
  • a business term dictionary corresponds to this, and a synonym relationship and a hierarchical relationship of terms used in business, and expressions that can be stored in a database are held in the dictionary.
  • SALES is used to search for a character string having the same meaning, and it is a numerical type or discrete value. By using the feature that appears as the value of, it is used to assist modeling search.
  • the object of the present invention is to reduce the cost of the preparation stage for the application business, and such auxiliary information is not created specifically for the application business, but is used to some extent for common or business fields. By taking the form that prepares things in advance, it does not affect the cost at the time of introduction to individual work.
  • the processing flow in the modeling engine performed by the modeling engine 111 is shown in FIG. 2, and will be described below in order.
  • step 201 the user accepts designation of an axis of interest for joining tables. Specifically, the user inputs from the input device 101 through the UI input unit 113 using the keyword receiving unit 901 of the modeling engine 111, and the modeling unit 111 receives this as a character string.
  • the column search unit 903 of the modeling engine 111 searches the data source storage DB 151 for the axis of interest input in step 201.
  • the degree of matching and semantic similarity are evaluated for the input keyword, a column in the data source storage DB 151 is searched, and a table having a matched column is acquired as a candidate.
  • statistical analysis information and analysis auxiliary information in the metadata storage DB 152 are used, and for example, blurring of terms used in column names and blurring in character string expression are allowed.
  • a single column that matches one interest axis is not a single column. For example, a column group divided into “year”, “month”, and “day” for a keyword such as “birth date”. Processing that matches is also performed. Such interpretation is supported by the hierarchical relationship of the analysis support information on the metadata storage DB 152.
  • step 203 the modeling unit 904 of the modeling engine 111 searches for the possibility of joining the table group obtained as a result of the search by a plurality of joining methods for the matched columns, and stores the modeling result as a modeling candidate as a modeling candidate. Held in the unit 121.
  • the information in the metadata storage DB 152 is used as an evaluation material when searching for the possibility of connection between tables or columns.
  • the modeling unit 904 presents the table with the current modeling state visualization form stored in the modeling state storage unit 121 to the user as a combination candidate.
  • the combination candidate is presented via the UI output unit 114 and the output device 102.
  • As a presentation method here in addition to the table format, it is also assumed that the output by the visualization / analysis unit 181 can be confirmed.
  • the modeling state in the modeling state storage unit 121 can be referred to by the visualization / analysis unit 181, and can be presented by any visualization means such as a graph through the UI output unit 183 and the output device 172.
  • step 205 an end instruction from the user is accepted. Specifically, input is performed from the input device 101 through the UI input unit 113 using the keyword receiving unit 901 of the modeling engine 111, and the modeling unit 904 receives this as an end instruction.
  • the column can be input by extracting a column that can be a new candidate of interest axis from the current modeling state stored in the modeling state storage unit 121, and presenting and selecting the column.
  • selection candidates are extracted by the column extraction unit 905 of the modeling engine 111, and are displayed as options to the user by the column selection reception unit 902 of the modeling engine 111 to receive user selection.
  • the column that can be a candidate for the new axis of interest is a column other than that input in step 201 as in step 202, for example.
  • Step 207 is a branch depending on whether or not the new axis of interest input in step 206 is included as a column in the target modeling candidate. This determination is common to the extraction processing of the column extraction unit 905 in step 206. If the user selects a method of selecting a column extracted by the column extraction unit 905 in step 206, the branch of step 207 is Move to YES. If an input by a keyword is performed in step 206, the process branches according to this determination.
  • step 207 the table candidate update unit 906 of the modeling engine 111 designates the column as an interest axis in step 208 when a new interest axis is included in the current modeling state candidate (step 207; Yes). Leave the modeling candidate.
  • step 209 the table candidate update unit 906 searches the data source storage DB 151 with the new interest axis. Further, narrow down the tables that can be combined with the target modeling candidates.
  • the table candidate update unit 906 combines the search result table in step 209 with the current modeling state candidate and updates it as a new candidate. In this manner, the table candidate update unit 906 searches for a column that becomes a new axis of interest from the data source storage DB 151 that is a database, and narrows down and narrows the table including the searched column as a table that can be combined with the current modeling candidate. However, a new modeling candidate is output by combining the connectable table with the current modeling candidate.
  • step 211 the modeling unit 904 presents the updated current modeling state to the user in the processing in steps 207 to 210.
  • the processing contents are the same as in step 204.
  • Step 212 accepts the user's work end determination as in step 205. If it is not the end of the work, the interest axis is repeatedly added from step 206.
  • the embodiment of the present invention is realized by the processing flow shown in FIG.
  • step 203 and step 210 a process of storing the possibility of combining the table groups searched according to the interest axis input by the user as a modeling candidate group is performed. This process will be described in detail with reference to FIG.
  • the tables searched in the previous steps are designated as 501 and 502, respectively.
  • the columns that are determined to match the interest axis during the search are denoted by 503 and 504, respectively.
  • joining these tables 501 and 502 There are two options for joining these tables 501 and 502: joining horizontally or vertically. Further, in the case of combining horizontally, since a column different from the column of interest column is aggregated and combined, there is an option of which column to aggregate.
  • the table 511 is one of the possibilities of joining in the horizontal direction.
  • the interest axis columns 503 and 504 in the tables 501 and 502 of the combination source are aggregated for each date and then combined into one table as the columns 513 and 514, respectively.
  • the table 512 is one of the possibilities of joining in the vertical direction.
  • the interesting axis columns 503 and 504 are joined in the vertical direction, and are newly joined as a column 515 to one table.
  • the validity of the join is determined from the similarity of column names and values held as metadata in the metadata storage DB 152, and it is determined whether or not to leave them in the joined table. .
  • the column of interest axis designation that is expected to remain in the table after the combination, these are highly meaningful as candidates for subsequent addition of the interest axis.
  • the modeling state storage unit 121 has a history table 801 that is added each time the user specifies an interest axis as the history. This table is added at the timing of step 203 or step 210 in FIG. Each row of this table indicates a modeling state associated with one procedure of the modeling work. In particular, this last row indicates a current state, and is referred to as a current modeling state in this specification. Further, it is possible to arbitrarily roll back from the current modeling state to each row in the history structure table 801, that is, the modeling state on the history. There are several ways to achieve this, but simply, from the initial state, the user input is replaced with the value stored in the interest axis column from the top of the history table 801, and the flow in FIG. You can create a modeling state with a proven history.
  • the history table 801 holds modeling candidates that can be assumed at that time as each history. Details of the modeling candidates are separately stored in the modeling candidate table 802, and are referred to by the status ID from the history structure table 801.
  • One line of the modeling candidate table 802 represents one modeling candidate, and holds each of the immediately preceding state, the modeling operation performed on the modeling candidate, and the table newly added by the operation. Is expressed.
  • T-01 and T-02 are tables corresponding to, for example, the table 501 and the table 502 shown in FIG. The indeterminate ID in the figure will be described later.
  • the previous state ID refers to the state ID of the modeling candidate table 802 itself.
  • the additional table ID is an identifier uniquely assigned to each table in the data source storage DB 151.
  • each modeling candidate it is possible to derive the table on the data source storage DB 151 used for the modeling candidate and the modeling operation performed between them by sequentially following the previous state. These can be used to build a table represented by modeling candidates.
  • these modeling candidates In order to present these modeling candidates to the user through the UI output unit 114 or to use these modeling candidates from the visualization / analysis unit 181, it is necessary to construct them once in the form of a table.
  • the constructed table itself can be held in the modeling state storage unit 121 in a cache-like form.
  • the modeling unit 904 and the table candidate update unit 906 of the modeling engine 111 form a history relationship as shown by the tree-like relationship 803 as each modeling candidate.
  • This tree-like structure is added with one level of the tree-like structure corresponding to the process of adding the history to the history table 801 in step 203 or 210 with the initial state as the root.
  • the information held in the data structure shown in FIG. 8 can be stored in the modeling result storage DB 122 by the database output unit 907 of the data modeling engine 111.
  • a process for handling the uncertainty associated with modeling in the operation flow is executed.
  • Uncertainty can be caused by differences in criteria when entering between tables to be joined. Such uncertainties can be solved in advance by including it in the work of ensuring consistency between data by hand.
  • the preliminary preparation is limited by statistical analysis or the like for the purpose of reducing the cost of the preparation stage, it is impossible to correct the difference in the criteria at the time of input in advance.
  • a mechanism for handling uncertainties at the time of modeling is introduced, and the uncertainties are dealt with in the operation flow of the user.
  • an embodiment for handling uncertainty is shown.
  • the modeling unit 904 of the modeling engine 111 combines the columns, whether or not the columns to be combined are data input based on the same standard, that is, whether there is data uncertainty or the score at that time. And the determination result is stored in the storage unit as a combined result in association with information (for example, the modeling candidate table shown in FIG. 8) indicating from which data source storage DB 151 the data is combined. Therefore, since information indicating the modeling progress that can be rolled back and information indicating the history remain in the modeling state at the time of the occurrence of any uncertainty, to which table did the modeling operation result in uncertainty? No, if uncertainty occurs, the score value at that time can be grasped.
  • the uncertainty in this embodiment is defined in advance in the uncertainty definition list 123 in FIG.
  • This list is prepared by assuming in advance the uncertainty that may occur when performing a modeling operation.
  • the uncertainty defined here is a list of assumptions that can occur as typical patterns when performing data modeling. As a typical pattern, a method for determining the uncertainty can be defined at the same time.
  • the uncertainty here does not necessarily mean modeling that the user expects or does not want. Therefore, the uncertainty in this embodiment is regarded as a factor that reduces the accuracy of the automatic modeling for the user-specified interest axis, and the uncertainty given to the modeling is expected to be solved by the user at some timing.
  • uncertainty is a list of typical patterns, which means that a typical method can be prepared for the solution at the same time.
  • the uncertainty definition list 123 assumes a table structure 701 as shown in FIG. 7, holds the definition of uncertainty for each row, and shows the identification ID and the reason for determining that there is uncertainty. Has a type and has a reference to the determination method and coping method for uncertainty.
  • the determination method and the coping method indicate the software modules 702 and 703 that are held as module IDs in FIG. 7 and can be executed on the CPU 111. By designating the module ID, it is possible to arbitrarily call the corresponding software module. In the present embodiment, the entities of these software modules reside in the uncertainty determination / resolution unit 112. In FIG.
  • the ID for identifying the uncertainty definition, the uncertainty type identified by the ID, the method for determining the uncertainty of the type, and the case where the uncertainty of the type occurs Corresponding methods are stored in association with each other. For example, when it is determined that the uncertainty of the date range mismatch identified by U-1 has occurred, the module with the module ID 1001 compares the date information included in each table to be combined, and It is determined whether or not the deviation is within an allowable range. If the module determines that the date information of each table is not within the allowable range, for example, the module identified by the module ID 2001 gives priority to the matching date range and combines only the common range. Select as target. The contents of each module is a determination logic as to whether or not the tables and columns to be combined are data input based on the same standard as the determination method, and the coping method is data processing logic for coping with uncertainty.
  • the module of the determination method and coping method of the uncertainty determination / resolution unit 112 referenced from the uncertainty definition list 123 is prepared in advance assuming the uncertainty that may occur during modeling.
  • the processing for handling uncertainty associated with modeling is divided into two.
  • One is a process for determining uncertainty, which is given immediately after step 203 and step 210 in the flow of FIG.
  • the other is a process for dealing with uncertainty, and can be performed immediately after the determination process, for example.
  • step 3 represents a process of detecting uncertainty performed by the modeling engine 111. This process is sequentially performed for all modeling candidates when stored in the modeling state storage unit 121 in step 203 and step 210.
  • step 301 the modeling unit 904 and the table candidate update unit 906 of the modeling engine 111 acquire the definition of uncertainty from the uncertainty definition list 123 as an object of this flow in the order of ID. Uncertainty is handled using a unique identification value (ID) in the table structure 701 in FIG.
  • ID unique identification value
  • step 302 the modeling unit 904 and the table candidate update unit 906 acquire a determination method corresponding to the acquired identification ID of the uncertainty definition.
  • the module ID representing the determination method is acquired from the table structure 701 of the uncertainty definition list in FIG.
  • the modeling unit 904 and the table candidate update unit 906 call and execute a software module executable on the CPU 111 based on the module ID of the uncertainty determination method acquired in step 302.
  • the software module is stored in the external storage device 120, for example.
  • the determination method module 702 is implemented with logic for determining whether or not the uncertainty defined by the uncertainty definition list exists, and the uncertainty table that defines the result table combined in step 203 or step 210 is defined. Judgment from the viewpoint of sex, digitize as modeling accuracy, and return the value. For example, it is conceivable to express a value of 0 to 100 as an accuracy score. It should be noted that the numerical value of the accuracy score is desirably quantified based on a unified standard for all uncertainty definitions appearing in the uncertainty definition list 123 by adjustment at the time of implementation of the determination method module 702.
  • step 304 the modeling unit 904 and the table candidate update unit 906 use the uncertainty definition as a target based on the result in step 303 to determine whether the combination is valid, in other words, the presence of uncertainty. It is determined that there is no room for it to branch. As described above, if the step 303 scores the accuracy as an accuracy of 0 to 100, a branching process such as determining a valid combination when there is an accuracy of a certain threshold, for example, 80 or more.
  • step 304 if the modeling unit 904 or the table candidate update unit 906 determines that there is not sufficient validity, that is, if it is determined that there is uncertainty, the process proceeds to step 305.
  • step 305 the uncertainty candidate ID and the score calculated in step 303 are added to the modeling candidate table 802 in FIG.
  • the modeling unit 904 and the table candidate update unit 906 vertically connect the tables T-01 and T-02, and the uncertainty definition with the identification ID U-2 is determined by the module with the module ID 1002. However, it can be seen that the score was 40.
  • the modeling unit 904 and the table candidate update unit 906 output information stored in the modeling candidate table 802 including the uncertainty ID and the score calculated in step 303 to the output device 102. To display. By confirming the displayed information, the user can easily grasp what kind of uncertainty is caused by the modeling operation for which table and the score at that time can be easily grasped. In addition, since the information stored in the displayed modeling candidate table 802 is displayed in history in order of time series, it is easy to grasp at a glance how the current modeling state was obtained. can do.
  • step 307 the modeling unit 904 and the table candidate update unit 906 confirm whether or not the processing of steps 301 to 305 has been performed for all the uncertainty definitions in the uncertainty definition list 123, and uncertain uncertainty definitions are found. If it remains, return to Step 301. If all the uncertainty definitions in the uncertainty definition list 123 have been implemented, the flow in FIG.
  • the modeling state storage unit 121 is provided with modeling candidates and uncertainty information associated with them (for example, the contents of items included in the history table and the modeling candidate table shown in FIG. 8). Is memorized. In this embodiment, these uncertainties are presented to the user and dealt with.
  • the timing may be the time when the uncertainty is detected, that is, immediately after the processing flow shown in FIG. 3, and the modeling candidate targeted in the flow of FIG. It becomes.
  • the handling of the uncertainty is the modeling candidate held in the current modeling state shown in the last row of the history table 801 among the modeling candidates held in the data structure indicating the modeling state in FIG.
  • historical modeling candidates obtained by following the dendritic relationship 803 can be targeted.
  • the modeling unit 904 and the table candidate update unit 906 present a list of uncertainties from these modeling candidate groups to the user, and activate a flow for dealing with uncertainties at an arbitrary timing. .
  • step 401 the modeling unit 904 of the modeling engine 111 acquires the uncertainty ID in the modeling candidate table 802 from the target modeling candidates.
  • the modeling unit 904 refers to the table structure 701 in the uncertainty definition list 123 based on the uncertainty ID acquired in step 401, identifies the corresponding uncertainty type, and a coping method To get.
  • the coping method is a software module that can be executed by the CPU 110, and is held as a module ID on the table structure 701.
  • the uncertainty determination / resolution unit 112 is inquired based on the module ID. By doing this, it is possible to obtain the entity. Further, a plurality of coping methods can be defined for one uncertainty, and in step 402, all of them are acquired.
  • the software module is stored in, for example, the external storage device 120, similarly to the determination method module.
  • the modeling unit 904 presents the coping method acquired in step 402 as a list of options to the user, and accepts a selection input by the user.
  • options that do not depend on the content of the uncertainty such as approving the uncertainty without taking any action, are also presented.
  • step 404 the modeling unit 904 returns the current modeling state to the modeling state at the time when the uncertainty to be dealt with occurs.
  • Uncertainty in data modeling is linked to the modeling operation included in the modeling candidate table in the modeling operation history, and the modeling unit 904 and the table candidate update unit 906 roll out to the state at the time of the operation to deal with the above. I do. If the timing of dealing with the uncertainty is immediately after the determination, the rollback is targeted only for the modeling operation in which the uncertainty occurs.
  • step 405 the modeling unit 904 executes the software module that is the substance of the coping method selected in step 403.
  • the content depends on the definition of uncertainty, but for example, as a countermeasure against the uncertainty of the date period deviation between tables to be joined as described above, there is an option that only overlapping periods are to be joined. possible.
  • the execution process in the module in that case is such that the tables to be joined are extracted after only overlapping periods and then joined.
  • step 406 the modeling unit 904 re-executes the operation rolled back in step 404.
  • the modeling operation history is sequentially performed.
  • the flow is the same as the processing shown in the flow in FIG. 2 and FIG. 3, but since it is re-execution, the interest axis once input by the user is used as it is stored in the operation history. For this reason, the input reception in step 201 and step 206 does not occur.
  • a countermeasure method is also executed along with the modeling operation. The
  • step 405 since one modeling uncertainty is dealt with in step 405, the modeling state at that time is changed, so the result of the re-execution of the rolled back operation may be different from that before dealing with it. is there.
  • the modeling state at that time is changed, so the result of the re-execution of the rolled back operation may be different from that before dealing with it. is there.
  • the modeling unit 904 determines whether or not the columns to be combined are data of the same date period as the uncertainty criterion.
  • the modeling unit 904 of the modeling engine 111 performs combination along sales proceeds as an axis of interest when combining Table A, Table B, and Table C.
  • a date column exists in common in each of the table A, the table B, and the table C in addition to the sales amount that has become an interest axis.
  • coping method module 703 it is possible to prepare a module that handles only data in the overlapping period that satisfies the AND condition from each of the tables to be joined.
  • all of Table A, Table B, and Table C are combined using only data from April 2014.
  • step 403 of FIG. 4 such a countermeasure is not automatically applied, but prompts the user to make a selection after presenting it. It is expected that the user will select what will ultimately lead to analysis and visualization. Depending on the purpose, in addition to the two options shown here, there is also a choice that the date period is not dealt with and that the combination is performed as it is.
  • the uncertainty definition list 123 and the uncertainty determination / resolution unit 112 are prepared by paying attention to the date period, thereby handling the uncertainty based on the date.
  • the modeling unit 904 determines whether or not the columns to be combined are data of the same unit as a criterion for uncertainty.
  • the modeling unit 904 of the modeling engine 111 performs combination along the interest axis of sales when combining Table A and Table B. At that time, if there is a column corresponding to the sales amount in both the table A and the table B, they are to be combined. In the case of joining in the vertical direction, it is a condition that the modeling operation with high accuracy is that the sales amount column of the table A and the sales amount column of the table B have the same reference sales amount.
  • the uncertainty determination method module 702 it is possible to compare numerical distributions of columns to be joined between tables to be joined and judge whether there is a big difference.
  • the maximum or minimum value, average or median value of the columns to be combined is compared, and the value between these columns is large. Make sure there are no differences. For example, if the area where the two overlap in the numerical distribution is a predetermined ratio or more (for example, when 50% or more of the total area of both does not overlap), the currency units of the two are different. It is determined that
  • the countermeasure module 703 can prepare data processing for performing unit conversion. Since it is difficult to determine the currency unit, it is assumed that an operation for determining the unit and the conversion rate is accompanied with a user input. In addition, in order to deal with the difference due to the handling of the number of digits, such as 1000 times or 10,000 times, in order to match the number of digits of the other sales amount with the number of digits, refer to the number of digits of the other sales amount. You can also prepare data processing that multiplies the value by x and the consistency in the number of digits of both sales. This determination and handling method can be used not only for currency but also for other unit systems.
  • the example 3 and the example 4 show an example in which the uncertainty definition list 123 is prepared by paying attention to the date period and unit.
  • the uncertainty definition list 123 is prepared by paying attention to the date period and unit.
  • this system substitutes metadata obtained by automatic processing such as statistical analysis instead of ensuring consistency between databases manually.
  • metadata is used as a clue
  • data modeling cannot always be uniquely determined from simple user input.
  • this is extracted as uncertainty in data modeling, and a mechanism for handling it in the data modeling operation flow is prepared, and an opportunity for solution is provided to the user. Therefore, when modeling the database, it is possible to reduce the process of preparing in advance when performing data modeling from simple user input.
  • business intelligence is made self-service, it is possible to reduce the necessity of ensuring integrity between databases in advance, and to reduce the cost.
  • the data modeling system is suitable for the purpose of modeling for data analysis and visualization by creating a new table using data from an existing database in combination with an information processing device. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

ユーザから、テーブルを結合するための軸となるカラムの指定を受け付け、軸となるカラムに類似するカラムを含むテーブルを、１または複数のデータベースの中から検索し、検索されたテーブルに含まれる軸となるカラムに類似するカラムを複数の方法で結合し、結合したテーブルをモデリング候補として出力し、結合したテーブルの候補から、入力部から次に指定された次カラムとの類似度が一定以上の類似カラムを抽出し、抽出された次カラムを出力し、出力した次カラムの中からユーザが選択したカラムを受け付け、次カラムに基づいて結合したテーブルの候補を絞り込み、次カラムを含むテーブルを新たな結合したテーブルをモデリング候補として出力する。

Description

データモデリングシステム、データモデリング方法
　本発明は、データ分析を行う際のデータモデリングを行うデータモデリングシステム、データモデリング方法に関する。
　ＩＴ（Information Technology）技術の発展と普及に伴い、非常に広範な業務分野にわたって、その業務効率化などの目的でＩＴ技術に基づく業務システムが導入されている。それらシステムの規模や種別は多様ながら、稼働する業務システムの多くはデータベースを有し、業務データを蓄積している。ひとつの組織内に複数の業務システムが稼働するようなことも一般的であり、異なる業務システムのデータベースに蓄積されたデータ群を横断的に分析することで、有意な情報を抽出し、経営判断につなげていくようなビジネスインテリジェンスの技術の導入が進んでいる。
　反面、各業務システムにおいては、必ずしも他の業務システムとの間でデータベース設計の互換性が保たれてはおらず、異なる業務システムのデータを用いたビジネスインテリジェンス実現には、データベース間の整合性を担保することが必須の手続きとなる。一般的には、業務システム間のデータベース設計が異なっている場合、事前にそのデータの意味を人手によって解釈し、整合性を確保する。場合によっては、これに加え分析の支援情報を与えることもある（特許文献１）。
　ビジネスインテリジェンス適用範囲拡大のため、分析や可視化の目的に沿って、ＩＴ技術者でなく、業務ユーザ自身がデータモデリングを行うような、ビジネスインテリジェンスのセルフサービス化を実現するツールも発表されている（非特許文献１、非特許文献２）。
特開２０１０－２０５２１８号公報
https://aws.amazon.com/jp/quicksight/ http://www.qlikspace.net/qlik-sense/
　上記特許文献１では、データベース間の整合性を人手によって解釈している。しかし、これらの作業はＩＴ技術の専門家によって相応の期間をもって実施されていたが、ビジネスインテリジェンスをより広い範囲の業務に適用していく過程では、人手による解釈のために煩雑さが伴うとともに、そのコストが障害となっている。
　また、上記非特許文献１、２では、キーワード入力や軸選択等の簡易なユーザ入力によって、データモデリングが行われ、可視化や分析を可能とする。こうしたツールにおいても、入力となるデータベース間の整合性を確保する前提は求められ、この前提によりユーザ入力から一意なデータモデリングを行うことが可能となっている。しかしながら、上記特許文献１の場合と同様、人手による解釈が必要であるため、そのための煩雑さやコストが障害となっている。
　本発明は、上記に鑑みてなされたものであって、データベース間の整合性を解釈する際に人手による煩雑さを軽減し、コストを削減することが可能なデータモデリングシステム、データモデリング方法を提供することを目的とする。
　上記課題を解決し、目的を達成するために、本発明にかかるデータモデリングシステムは、１または複数のデータベースに記憶されている複数のテーブルを結合するデータモデリングシステムであって、ユーザから、テーブルを結合するための軸となるカラムの指定を受け付けるカラム入力部と、前記軸となるカラムに類似するカラムを含むテーブルを、前記１または複数のデータベースの中から検索するカラム検索部と、検索されたテーブルに含まれる前記軸となるカラムに類似するカラムを複数の方法で結合し、結合したテーブルをモデリング候補として出力するモデリング部と、前記結合したテーブルの候補から、前記入力部から次に指定された次カラムとの類似度が一定以上の類似カラムを抽出するカラム抽出部と、抽出された前記次カラムを出力し、出力した前記次カラムの中からユーザが選択したカラムを受け付けるカラム選択受付部と、前記次カラムに基づいて前記結合したテーブルの候補を絞り込み、前記次カラムを含むテーブルを新たな前記結合したテーブルをモデリング候補として出力するテーブル候補更新部と、を備えることを特徴とするデータモデリングシステムとして構成される。
　また、本発明は、上記データモデリングシステムで行われるデータモデリング方法としても把握される。
　本発明によれば、データベース間の整合性を解釈する際に人手による煩雑さを軽減し、コストを削減することができる。
データモデリング装置の構成図である。 データモデリングにおける処理フローである。 不確定性を判定する処理フローである。 不確定性の対処を行う処理フローである。 データモデリングにおける結合の可能性探索の例である。 メタデータテーブルの構造例を示す図である。 不確定性定義リストのテーブル構造を示す図である。 データモデリング状態を記憶するデータ構造の例を示す図である。 モデリングエンジンの詳細構成を表す図である。
　本発明の実施形態を図面により詳細に説明する。
　図１に本発明にかかるデータモデリングシステム、データモデリング方法を適用したデータモデリングシステムの構成例を示す。なお、以下では、本発明にかかるデータモデリングシステム、データモデリング方法を、複数の一般的なＰＣ（Personal Computer）等の情報処理装置から構成されるシステムに適用した場合について説明しているが、これらの各機能を、１または複数の情報処理装置で実行する等、実施の態様に応じて、適宜変形して実施することができる。
　図１に示すように、データモデリングシステムは、モデリング環境１００、メタデータ生成環境１３０、可視化／分析環境１７０を備える。各環境は、ネットワーク１６０、１６１によって通信可能な状態に接続されている。モデリング環境１００、メタデータ生成環境１３０、可視化／分析環境１７０は、ハードウェアとしては、１または複数のコンピュータにより構成される。
　メタデータ生成環境１３０は、ＣＰＵ１４０と外部記憶装置１５０を備える。ＣＰＵ１４０では、ソフトウェアとして実装されるメタデータ生成部１４１を実行する。外部記憶装置１５０には、データソース格納ＤＢ１５１とメタデータ格納ＤＢ１５２とが記憶され、これらはネットワーク１６０を通じモデリング環境１００からも参照可能な状態となっている。
　モデリング環境１００は、ＣＰＵ１１０、外部記憶装置１２０、入力装置１０１、出力装置１０２を備える。ＣＰＵ１１０では、ソフトウェアとして実現されるモデリングエンジン１１１、不確定性判定／解決部１１２、またＧＵＩなどのユーザインターフェイスを表示し入力を受け付ける、ＵＩ入力部１１３、ＵＩ出力部１１４を実行させる。このうちモデリングエンジン１１１は本モデリング装置の中核をなし、図９に示すように、キーワード受付部９０１、カラム選択受付部９０２、カラム検索部９０３、モデリング部９０４、カラム抽出部９０５、テーブル候補更新部９０６、データベース出力部９０７を有する。これらの各部の機能については、フローチャートを用いて後述する。
　外部記憶装置１２０は、ＣＰＵ１１０に接続され、モデリング状態記憶部１２１、モデリング結果保存ＤＢ１２２、不確定性定義リスト１２３を保持する。モデリング状態記憶部１２１はモデリングエンジンにおける来歴を含む作業状態を記憶する。モデリング結果保存ＤＢ１２２はモデリングエンジンで生成した結果となるテーブルを格納する。不確定性定義リスト１２３はモデリングエンジン１１１や不確定性判定／解決部１１２と合わせ、ソフトウェアの実装あるいはその外部定義として事前準備される。また、これらのうちモデリング状態記憶部１２１およびモデリング結果保存ＤＢ１２２については、ネットワーク１６１を通じ、可視化／分析環境から参照可能な状態となる。
　入力装置１０１は、例えば、キーボードやマウス、タッチパネル等の入力機器であり、ユーザから情報の入力を受けＵＩ入力部１１３に引き渡す。出力装置１０２は、例えば、ディスプレイ等の出力機器であり、ユーザに対し、ＵＩ出力部１１４で生成した映像情報を表示する役割を持つ。
　可視化／分析環境１７０は、ＣＰＵ１８０と、入力装置１７１、出力装置１７２を備える。ＣＰＵ１８０では可視化／分析部１８１、ＵＩ入力部１８２、ＵＩ出力部１８３を有する。可視化／分析部１８１によって生成した可視化／分析の結果はＵＩ出力部１８３を経て、出力装置１７２によってユーザに表示される。ユーザによる可視化／分析の指示は、入力装置１７１からＵＩ入力部１８２に送られ、可視化／分析部１８１へと通知される。
　図１に示される構成例を用いて、本実施例のデータモデリングの手順を説明する。メタデータ生成環境１３０には、あらかじめ、分析や可視化の対象となるデータベーステーブル群がデータソース格納ＤＢ１５１に集積されている。メタデータ生成部１４１は、データソース格納部１５１に収められたテーブルを統計的に分析し、メタデータを生成、メタデータ格納ＤＢ１５２に格納する。メタデータとは、データベースのカラムに紐付けられた付加情報であり、データベース上のテーブル定義を利用するほか、そのカラムの値やカラムの値と値との間の関係を統計的に分析して得られる情報である。メタデータの例を図６に示す。
　テーブル６０１は、単カラムのメタデータテーブルの例である。データソース格納ＤＢ１５１に格納されるテーブル群に含まれるカラムをキーとしてデータ型、桁数、ユニーク性、有効要素数などを保持している。なお、ユニーク性とは、そのデータがテーブル内で一意に識別されるデータであるか否かを示す項目である。また、有効要素とは、１つ１つのデータの値に重複がないとしたときのデータの数を示す項目である。図６上段に示すように、テーブル６０１は、テーブル名がテーブルＡであり、カラム名がカラム１、カラム２の２つの項目を有したテーブルであることを示している。また、カラム１で示される項目は９桁の数値型の項目であり、１１０１個のユニークなデータがあることを示している。同様に、カラム２で示される項目は６－９桁の文字列型の項目であり、重複するデータを含んで２２個のデータがあることを示している。
　テーブル６０２は、カラム間関係のメタデータテーブルである。２つのテーブルとカラム組合せをキーとし、両カラムの値の共通要素数などを保持している。なお共通要素とは、テーブルのカラム間同士で値が共通するデータの数を示す項目である。図６下段に示すように、テーブル６０２は、テーブルＡのカラム１とテーブルＣのカラム１との間における共通要素がなく、それぞれのテーブルのカラムのデータは重複していないことを示している。同様に、テーブルＡのカラム１とテーブルＣのカラム２との間では、共通要素が２２個、すなわち、同じ値のデータが２２種類存在することを示している。
　これらのメタデータテーブル６０１、６０２はメタデータ格納ＤＢ１５２に格納され、任意のタイミングで、モデリングエンジン１１１から参照される。参照の際は、データソース格納ＤＢ１５１におけるテーブルおよびカラムが、その検索のキーとなる。
　メタデータ生成環境１３０でのメタデータ生成は、データソース格納部１５１に格納する分析対象テーブルを更新した場合に一度実施すれば良い。一般には分析の対象となるテーブルを集積することで分析の範囲を定めた後、同一の分析範囲で作成されたメタデータを用いたモデリング操作が繰り返し行われることが想定される。
　また、メタデータ格納ＤＢ１５２は、以上に述べたデータソース格納部１５１を統計的に分析して得られる情報以外に、メタデータを活用する際の補助情報として、あらかじめ事前準備される分析補助情報を保持する。例えば、業務用語辞書がそれにあたり、業務上用いられる用語の類語関係や階層関係、またそれがデータベース上であり得る表現などを辞書内に保持している。例えば「売上金」という用語に対して、類語「ＳＡＬＥＳ」などは同じ意味を持つ文字列を探索の際に考慮するのに用いられ、またそれが数値型や離散値であることなど、計算機上の値としてあらわれる際の特徴を使うことで、モデリング探索の補助に用いる。ただし、本発明の目的は、適用先業務への準備段階のコストを軽減することであり、こうした補助情報は適用先に特化して作るものではなく、共通的あるいは業務分野ごとにある程度汎用的なものを事前に準備しておく形をとることで、個別業務への導入時のコストに影響を与えることはしない。
　モデリングエンジン１１１によって行われる、モデリングエンジンにおける処理フローを図２に示し、以下に順を追って説明する。
　ステップ２０１では、ユーザにより、テーブルを結合するための興味軸の指定を受け付ける。具体的には、ユーザは入力装置１０１からＵＩ入力部１１３を通じてモデリングエンジン１１１のキーワード受付部９０１を用いて入力し、モデリング部１１１がこれを文字列として受け付ける。
　ステップ２０２において、モデリングエンジン１１１のカラム検索部９０３は、ステップ２０１で入力された興味軸を、データソース格納ＤＢ１５１より探索する。探索は入力されたキーワードに対し、一致度や意味的な類似性を評価して、データソース格納ＤＢ１５１内のカラムを探索し、マッチしたカラムを持つテーブルを候補として取得する。ここでの類似性を判定する上で、メタデータ格納ＤＢ１５２にある統計分析情報や分析補助情報が用いられ、例えばカラム名の使用用語のブレや文字列表現上のブレの許容が行われる。また別の例として、１つの興味軸指定でマッチするカラムは単一とせず、例えば「生年月日」のようなキーワードに対して、「年」「月」「日」に分割されたカラム群をマッチするような処理も行われる。こうした解釈はメタデータ格納ＤＢ１５２上の分析支援情報の階層関係によって支援される。
　ステップ２０３において、モデリングエンジン１１１のモデリング部９０４は、探索の結果得られたテーブル群を、マッチしたカラムについて複数の結合方法により結合する可能性を探索し、結合結果群をモデリング候補としてモデリング状態記憶部１２１に保持する。ステップ２０２同様に、メタデータ格納ＤＢ１５２の情報は、テーブル間やカラム間の結合可能性を探索する際の評価材料として用いられる。
　ステップ２０４では、モデリング部９０４は、モデリング状態記憶部１２１に記憶した、現モデリング状態の可視化形態であるテーブルをユーザに対し結合候補を提示する。結合候補は、ＵＩ出力部１１４、出力装置１０２を経て提示される。現モデリング状態として複数の候補を有する場合、ＧＵＩにより切り替えて表示することも可能とする。ここでの提示方法としては、テーブル形式以外に、可視化／分析部１８１による出力を確認可能とすることも想定される。モデリング状態記憶部１２１にあるモデリング状態は可視化／分析部１８１により参照可能であり、ＵＩ出力部１８３、出力装置１７２を通じて、グラフなどの任意の可視化手段で提示することが可能である。
　ステップ２０５では、ユーザによる終了指示を受け付ける。具体的には、入力装置１０１からＵＩ入力部１１３を通じてモデリングエンジン１１１のキーワード受付部９０１を用いて入力し、モデリング部９０４がこれを終了指示として受け付ける。
　ステップ２０５で作業を終了しない場合、ステップ２０６で再びユーザによる興味軸を受け付ける。ステップ２０１同様のキーワードによる自由入力の他、モデリング状態記憶部１２１に記憶した、現モデリング状態から新たな興味軸候補になり得るカラムを抽出、ユーザに提示し選択させる方法によっても入力可能とする。この処理ではモデリングエンジン１１１のカラム抽出部９０５によって選択候補が抽出され、モデリングエンジン１１１のカラム選択受付部９０２によってユーザに選択肢として表示しユーザ選択を受け付ける。上記新たな興味軸の候補になり得るカラムとは、例えば、ステップ２０２のように、ステップ２０１で入力された以外のカラムである。
　ステップ２０７～２１０の分岐処理ついては、現モデリング状態に保持する候補ごとに行う。
　ステップ２０７は、ステップ２０６で入力された新たな興味軸が対象としているモデリング候補内のカラムとして含まれているかどうかでの分岐となる。この判定はステップ２０６でのカラム抽出部９０５の抽出処理に共通するものであり、ステップ２０６でユーザがカラム抽出部９０５によって抽出されたカラムを選択する方法を選んだ場合は、ステップ２０７の分岐はＹＥＳに移動する。ステップ２０６でキーワードによる入力を行った場合には本判定により分岐することになる。
　ステップ２０７で、モデリングエンジン１１１のテーブル候補更新部９０６は、現モデリング状態の候補に新たな興味軸が含まれていた場合（ステップ２０７；Ｙｅｓ）、ステップ２０８において当該カラムを興味軸として指定し、そのモデリング候補を残す。
　ステップ２０７で、現モデリング状態の候補に新たな興味軸が含まれていない場合（ステップ２０７；Ｎｏ）、ステップ２０９において、テーブル候補更新部９０６は、データソース格納ＤＢ１５１を新たな興味軸によって探索し、さらに対象となるモデリング候補に結合可能であるテーブルを絞り込む。
　ステップ２１０では、テーブル候補更新部９０６は、ステップ２０９での探索結果テーブルを、現モデリング状態の候補に結合し、これを新たな候補として更新する。このように、テーブル候補更新部９０６は、データベースであるデータソース格納ＤＢ１５１から新たな興味軸となるカラムを探索し、探索したそのカラムを含むテーブルを現モデリング候補に結合可能なテーブルとして絞込み、絞り込んだその結合可能なテーブルを現モデリング候補に結合した新たなモデリング候補を出力している。
　ステップ２１１では、モデリング部９０４は、ステップ２０７～２１０での処理において、更新された現モデリング状態をユーザに提示する。ステップ２０４と同等の処理内容となる。
　ステップ２１２は、ステップ２０５と同じくユーザの作業終了判断を受け付ける。作業終了でなかった場合は、ステップ２０６より興味軸の追加を繰り返す形となる。
　以上図２に示した処理フローによって、本発明の１実施形態が実現される。
　なお、ステップ２０３およびステップ２１０においては、ユーザが入力した興味軸に従って探索されたテーブル群を結合する可能性をモデリング候補群として記憶する処理が行われる。この処理を、図５を用いて詳細に説明する。
　各々の前ステップで、探索されたテーブルを５０１、５０２とする。また、探索の際に興味軸にマッチすると判断されたカラムをそれぞれ５０３、５０４とする。
　これらのテーブル５０１、５０２を結合する方法として、横に結合するか、縦に結合するかの２つの選択肢がある。さらに横に結合する場合は、興味軸カラムとは別のカラムについて集約した上で結合するため、どのカラムについて集約するかの選択肢がある。
　図中テーブル５１１は、横方向に結合する可能性の１つである。結合元のテーブル５０１、５０２での興味軸カラム５０３、５０４について、日付ごとの集計を行った上でそれぞれカラム５１３、５１４として、１つのテーブルに結合した例である。同様に日付以外のカラムを用いた集計を行うことも可能である。また興味軸以外のカラムも集計可能であれば、結合後テーブル５１１に残ることになる。
　テーブル５１２は、縦方向に結合する可能性の１つである。興味軸カラム５０３、５０４は縦方向に結合され、新たにカラム５１５として１つのテーブルに結合されている。また興味軸以外のカラムについては、メタデータ格納ＤＢ１５２にメタデータとして保持される、カラム名やその値の類似性などから結合妥当性を判断し、結合後のテーブルに残すかどうかが判定される。ただしこれらは結合後テーブルに必ず残すことが期待される興味軸指定のカラムとは異なり、続く興味軸追加を行う際の候補としての意味が強い。
　以上のようにして探索されたテーブル５０１、５０２の結合の可能性すべてが、ステップ２０３やステップ２１０でモデリング候補として扱われる。図５の例では２つのテーブルを結合する例を示したが、３つ以上のテーブルであっても同様に結合の可能性を探索する。
　次に、図２のフローにおいて利用されるモデリング状態記憶部１２１のデータ構造について図８を用いて、詳細に述べる。
　モデリング状態記憶部１２１は、その来歴として、ユーザにより興味軸指定をするごとに追加される来歴テーブル８０１を持つ。このテーブルは、図２におけるステップ２０３や、ステップ２１０のタイミングで追加される。このテーブルの各行はモデリング作業の１手順に伴うモデリング状態を示しており、特にこの最終行が現在の状態を示し、本明細書では現モデリング状態と呼びわける。また、現モデリング状態から、来歴構造テーブル８０１における各行、すなわち来歴上のモデリング状態へは、任意にロールバックすることを可能としている。その実現方法はいくつかあるが、簡単には初期状態から、来歴テーブル８０１の先頭からユーザ入力を興味軸カラムに記憶された値で代替し、図２のフローを順次やり直していくことで、任意の来歴上のモデリング状態を作ることができる。
　来歴テーブル８０１は、各来歴としてその時点で想定しうる、モデリング候補を保持している。モデリング候補の詳細は、モデリング候補テーブル８０２で別途保持され、来歴構造テーブル８０１からはその状態ＩＤによって参照される形となる。
　モデリング候補テーブル８０２の１行は、１つのモデリング候補を表しており、直前の状態とそこに対して行われたモデリング操作とその操作で新たに追加されたテーブルとをそれぞれ保持することで、これを表現している。図中、Ｔ－０１、Ｔ－０２は、例えば、図５に示したテーブル５０１、テーブル５０２にあたるテーブルである。なお、図中の不確定ＩＤについては後述する。ここで、直前状態ＩＤは、モデリング候補テーブル８０２自身の状態ＩＤを参照する。また、追加テーブルＩＤはデータソース格納ＤＢ１５１内での各テーブルに一意に割り振られた識別子となる。
　各モデリング候補からは、直前の状態を順次たどっていくことで、そのモデリング候補に使われているデータソース格納ＤＢ１５１上のテーブルと、それらの間で行われたモデリング操作とを導出することができ、これらを用いてモデリング候補が表すテーブルを構築することができる。これらのモデリング候補を、ＵＩ出力部１１４を通じてユーザに提示したり、あるいはこれらのモデリング候補を可視化／分析部１８１から利用する場合には、一度テーブルの形で構築する必要がある。実現する上では、構築されたテーブル自体をモデリング状態記憶部１２１にキャッシュのような形で保持することも可能である。
　モデリングエンジン１１１のモデリング部９０４やテーブル候補更新部９０６は、各モデリング候補として、樹状関係８０３に示すような来歴関係を形成する。この樹状構造は、初期状態をルートとして、ステップ２０３やステップ２１０で来歴テーブル８０１に来歴が追加される処理に対応して、樹状構造の１階層を追加する。なお、図８に示すデータ構造に保持する情報は、データモデリングエンジン１１１のデータベース出力部９０７によって、モデリング結果保存ＤＢ１２２に保存可能である。
　本実施例では、モデリングにともなう不確定性を操作フローの中でハンドリングする処理を実行する。不確定性は、結合しようとするテーブル間での入力時の基準の違いによって発生しうる。こうした不確定性は、従来人手によってデータ間の整合性を確保する作業に含めて、事前解決することができた。本実施例ではその準備段階にかかるコストを軽減する目的で、事前準備を統計分析等でとどめていることから、こうした入力時の基準の違いなどを事前に修正しておくことができない。本実施例ではその対策として、モデリングの際に不確定性をハンドリングする仕組みを導入し、ユーザの操作フローの中で、不確定性に対処していく形をとる。図２に示した処理フローに加えて、不確定性をハンドリングする実施例を示す。以下に示すように、モデリングエンジン１１１のモデリング部９０４は、カラムを結合する際に、結合するカラムが同じ基準で入力されたデータか否か、すなわちデータの不確定性の有無やそのときのスコアを判定し、その判定結果を、どのデータソース格納ＤＢ１５１のテーブルから結合されたデータかを示す情報（例えば、図８に示したモデリング候補テーブル）と対応付けて結合結果として記憶部に記憶する。したがって、任意の不確実性発生時のモデリング状態にロールバックできるだけのモデリング経過を示す情報や履歴を示す情報を残しているため、どのテーブルに対してモデリング操作した結果、不確定性が生じたのか否か、不確定性が生じた場合にはそのときのスコアの値を把握することができる。
　本実施例における不確定性は、図１における不確定定義リスト１２３にあらかじめ定義する。このリストは、モデリング操作を行う際に発生しうる不確定性を事前に想定し準備しておくものである。ここで定義する不確定性は、データモデリングを行う際に典型的なパターンとして起きうる想定をリストアップしたものである。典型的なパターンとして、その不確定性を判定する方法も同時に定義できる。また、ここでの不確定性とは、必ずしもユーザが期待する、あるいは逆に望まないモデリングを断定するものではない。従って、本実施例における不確定性はあくまでも、ユーザ指定の興味軸に対する自動モデリングに対する確度を低下させる要因として捉え、モデリングに付与された不確定性は何らかのタイミングでユーザによって解決されることが期待される。その際上述の通り、不確定性は典型的パターンのリストであり、そのことは同時に、その解決策についても典型的な方法を準備できることを意味する。
　不確定性定義リスト１２３は図７に示すようなテーブル構造７０１を想定し、１行ごとに不確定性の定義を保持し、その識別ＩＤ、不確定性ありと判断した理由を示す不確定性種別を持ち、不確定性に対する判定方法および対処方法への参照を持つ。判定方法ならびに対処方法は、図７ではモジュールＩＤとして保持しておりＣＰＵ１１１上で実行可能なソフトウェアモジュール７０２、７０３を指し示す。モジュールＩＤを指定することで、それに対応するソフトウェアモジュールを随意に呼び出すことが可能となっている。本実施形態においてはこれらのソフトウェアモジュールの実体は、不確定性判定／解決部１１２にある。図７では、不確定性定義を識別するためのＩＤと、そのＩＤによって識別される不確定性種別と、その種別の不確定性の判定方法と、その種別の不確定性が生じた場合における対処方法とが対応付けて記憶されている。例えば、Ｕ－１で識別される日付範囲不一致の不確定性が生じたと判定された場合には、モジュールＩＤ１００１のモジュールが、結合しようとするそれぞれのテーブルに含まれる日付情報を比較し、日付のずれが許容範囲内であるか否かを判定する。そして、そのモジュールが、各テーブルの日付情報が上記許容範囲内にないと判定した場合には、例えば、モジュールＩＤ２００１で識別されるモジュールが、一致する日付範囲を優先し、共通する範囲のみを結合対象として選択する。各モジュールの中身は、判定方法としては結合するテーブルやカラムが同じ基準で入力されたデータか否かの判定ロジックであり、対処方法は不確定性に対する対処となるデータ加工ロジックである。
　不確定性定義リスト１２３やそこから参照される不確定性判定／解決部１１２の判定方法および対処方法のモジュールは、モデリングの際に発生しうる不確定性を想定しあらかじめ準備するものである。
　具体的な例としては、２つのテーブルをなんらかの興味軸に沿って結合したとして、両テーブルに日付を表すカラムがあったならば、両テーブルの日付範囲が両テーブルで全く異なっていた場合、結合するにふさわしくない可能性、すなわち不確定性があったものと判断できる。日付範囲が重複なくほぼ連続している場合は、縦方向に結合するにふさわしく、日付で集計して横方向に結合するのにはふさわしくないと行ったモデリングの種別に応じた判定を行う場合もある。また、対処方法の例として、両テーブルで日付期間に重複があっても、ずれがあるような場合には、重なる期間のみを残してデータ結合を行うなどの方法がある。
　上述の通りモデリングに伴う不確定性をハンドリングする処理は２つに分かれる。１つは不確定性を判定する処理であり、図２のフローにおけるステップ２０３およびステップ２１０の直後に付与される。またもう１つは不確定性に対して対処する処理であり、例えば前記判定処理の直後に実施することができる。各々の処理フローについて図を用いて詳細に説明する。
　図３のフローは、モデリングエンジン１１１によって行われる不確定性を検出する処理を表す。この処理は、ステップ２０３およびステップ２１０によってモデリング状態記憶部１２１に記憶した際、すべてのモデリング候補について順次行う。
　ステップ３０１では、モデリングエンジン１１１のモデリング部９０４やテーブル候補更新部９０６は、本フローの対象として、不確定性定義リスト１２３より不確定性の定義をＩＤ順に取得する。不確定性については図７でのテーブル構造７０１における固有の識別値（ＩＤ）を利用してハンドリングする。
　ステップ３０２では、モデリング部９０４やテーブル候補更新部９０６は、取得した不確定性定義の識別ＩＤに対応する判定方法を取得する。本実施形態では、上述の通り図７の不確定性定義リストのテーブル構造７０１より判定方法を表すモジュールＩＤを取得する形となる。
　ステップ３０３では、モデリング部９０４やテーブル候補更新部９０６は、ステップ３０２で取得した、不確定性の判定方法のモジュールＩＤをもとにＣＰＵ１１１上で実行可能なソフトウェアモジュールを呼び出し実行する。ソフトウェアモジュールは、例えば、外部記憶装置１２０に記憶されている。判定方法のモジュール７０２は、不確定性定義リストの定める不確定性が存在するかどうかを判定するロジックが実装されたものであり、ステップ２０３やステップ２１０において結合した結果テーブルを、定義する不確定性の観点から判定し、モデリング確度として数値化し、その値を返却する。数値化は例えば０～１００の値を確度のスコアとして表現することが考えられる。なお確度スコアの数値は、判定方法モジュール７０２の実装時の調整により、不確定性定義リスト１２３にあらわれるすべての不確定性定義について、統一した基準で数値化されることが望まれる。
　ステップ３０４では、モデリング部９０４やテーブル候補更新部９０６は、ステップ３０３での結果をもとに、対象としている不確定性定義を用いて、妥当な結合であるか、言い替えると不確定性の介在する余地はないかを判定し分岐している。上記のようにステップ３０３が確度を０～１００の確度としてスコア付けするのであれば、一定の閾値、例えば８０以上の確度があるときは妥当な結合として判定するなどの分岐処理となる。
　ステップ３０４で、モデリング部９０４やテーブル候補更新部９０６は、十分な妥当性がないと判断した場合、すなわち不確定性があると判断された場合には、ステップ３０５に至る。ステップ３０５では、モデリング状態記憶部１２１に保持される、図８におけるモデリング候補テーブル８０２に対し、モデリング操作情報と合わせて、ステップ３０１以降対象としている不確定性のＩＤとステップ３０３で算出したスコアとを記憶する。例えば、図８の例では、モデリング部９０４やテーブル候補更新部９０６がテーブルＴ－０１とＴ－０２とを縦結合し、識別ＩＤがＵ－２の不確定性定義をモジュールＩＤ１００２のモジュールで判定したが、そのスコアが４０であったことがわかる。
　ステップ３０５で、上記モデリング部９０４やテーブル候補更新部９０６は、上記不確定性のＩＤとステップ３０３で算出したスコアとを含むモデリング候補テーブル８０２に記憶されている情報を、出力装置１０２に出力して表示する。ユーザは、表示されたこれらの情報を確認することにより、どのようなテーブルに対するモデリング操作によりどのような不確定性が生じ、その際のスコアを、一見して容易に把握することができる。また、表示された上記モデリング候補テーブル８０２に記憶されている情報は、時系列に順に履歴で表示されるので、現モデリング状態がどのような経緯で得られたものかを一見して容易に把握することができる。
　ステップ３０７では、モデリング部９０４やテーブル候補更新部９０６は、不確定定義リスト１２３のすべての不確定性定義についてステップ３０１～３０５の処理が実施されたかを確認し、未実施の不確定性定義が残っていればステップ３０１に戻る。不確定定義リスト１２３のすべての不確定性定義について実施済になれば図３のフローは終了となる。
　図３の処理フローで、モデリング状態記憶部１２１には、モデリング候補とともに、それらに紐付く不確定性情報（例えば、図８に示した来歴テーブルやモデリング候補テーブルに含まれる項目の内容）が付与される形で記憶される。本実施例では、これらの不確定性はユーザに提示され対処を行う。そのタイミングとして、その不確定性を検出した時点、すなわち図３で示した処理フローの直後であっても良く、その場合の不確定性対処は図３のフローで対象としたモデリング候補がそのまま対象となる。
　また、任意のタイミングでユーザの対処指示を受け付けるようなことも想定する。その場合、不確定性の対処は、図８のモデリング状態を示すデータ構造内に保持されているモデリング候補のうち、来歴テーブル８０１の最終行に示される、現モデリング状態に保持されるモデリング候補の他、それらから樹状関係８０３をたどって取得される来歴上のモデリング候補が対象となりうる。上記モデリング部９０４やテーブル候補更新部９０６は、これらのモデリング候補群から、不確定性の情報を持つものを一覧としてユーザに提示し、任意のタイミングで、不確定性を対処するフローを起動する。
　上記で対象となるモデリング候補を特定した後、不確定性の対処を行う。不確定性への対処について、図４の処理フローで示す。以下に示すように、モデリング部９０４は、結合するカラムが同じ基準で入力されたデータでないと判定した場合、その判定の理由を示す不確定性種別とその不確定性種別で示される不確定性の判定方法およびその判定方法により判定されたときの対処方法とが対応付けてあらかじめ記憶された対処法テーブル（図７）に基づいて、ユーザが不確定性を判定してその対処方法による対処を実行し、カラムを結合したテーブルをモデリング候補として出力する。したがって、不確定性があると判定された場合であっても、ユーザによりその対処が実行され、対処実行後のモデリング候補が提示されるので、不確定性に対してどのような対処が適切かといった選択肢を人手で考える必要がなくなり、ユーザによる煩雑さを軽減することができる。
　ステップ４０１で、モデリングエンジン１１１のモデリング部９０４は、対象とするモデリング候補から、モデリング候補テーブル８０２における、不確定性のＩＤを取得する。
　ステップ４０２では、モデリング部９０４は、ステップ４０１で取得した不確定性のＩＤをもとに不確定性定義リスト１２３のテーブル構造７０１を参照し、該当する不確定性種別を特定し、その対処方法を取得する。図７に示すように対処方法は、ＣＰＵ１１０で実行可能なソフトウェアモジュールであり、テーブル構造７０１上では、モジュールＩＤとして保持されており、モジュールＩＤをもとに不確定性判定／解決部１１２に問合せを行うことで、その実体を得ることが可能となっている。また、対処方法は、１つの不確定性に対し複数定義が可能であり、ステップ４０２ではそのすべてを取得する。ソフトウェアモジュールは、判定方法のモジュールと同様に、例えば、外部記憶装置１２０に記憶されている。
　ステップ４０３では、モデリング部９０４は、ステップ４０２で取得した対処方法をユーザに選択肢一覧として提示し、ユーザによる選択入力を受け付ける。その際対処しようとしているのがどのような不確定性であるのかといった情報とともに選択肢である対処方法が説明文付きで提示されることが望ましい。また、その際、対処を行わず不確定性を承認するといった、不確定性の内容によらない選択肢も提示される。
　ステップ４０４では、モデリング部９０４は、現モデリング状態を、対処しようとしている不確定性が発生した時点のモデリング状態に戻す。データモデリングにおける不確定性は、モデリングの操作来歴におけるモデリング候補テーブルに含まれるモデリング操作に紐付いており、モデリング部９０４やテーブル候補更新部９０６は、その操作時点の状態にロールバックすることで上記対処を行う。不確定性の対処のタイミングがその判定直後であれば、ロールバックは不確定性の発生したモデリング操作のみが対象となる。
　ステップ４０５では、モデリング部９０４は、ステップ４０３で選択された対処方法の実体であるソフトウェアモジュールを実行する。その内容は、不確定性の定義次第であるが、例えば、前述したような結合ずるテーブル間の日付期間のずれという不確定性に対する対処方法としては、重複期間のみを結合対象とするという選択肢があり得る。その場合のモジュールでの実行処理は、結合対象となるテーブルについてそれぞれあらかじめ重複する期間のみを抽出したのちに結合する、といった内容となる。
　ステップ４０６では、モデリング部９０４は、ステップ４０４でロールバックした操作を再実行する。ステップ４０４で示したように、モデリングの操作来歴を順に行うことになる。その流れは図２および図３でのフローに示した処理と同様だが、再実行であるため、一度ユーザが入力した興味軸は、操作来歴に記憶したものをそのまま利用する形となる。そのためステップ２０１およびステップ２０６での入力受付は発生しない。また、ロールバックした操作の再実行において、不確定性を持つモデリング候補がその過程にあり、その不確定性が対処済みであった場合、そのモデリング操作実行の際に合わせて対処方法も実行される。
　またその際、ステップ４０５で１つの不確定性に対する対処がなされたことで、その時点のモデリング状態が変更されるため、ロールバックした操作の再実行については、対処前とは結果が異なることもある。例えば、モデリング状態のテーブルのカラムやレコードに対処の影響が現れるほか、モデリング状態として保持されるモデリング候補に追加削減があったり、各候補ごとに保持する不確定性にも増減が生じうる。
　以上、図４の処理フローによって、ひとつの不確定性に対し対処が行われる。この処理フローを発生した不確定性に順次適用することで、より確度の高いモデリング結果を得ることができる。
　上記実施例１におけるモデリングの不確定性のハンドリングに際し、日付データの期間の違いに着目する例を示す。以下では、モデリング部９０４は、不確定性の基準として、結合するカラムが同じ日付期間のデータであるか否かを判定している。
　モデリングエンジン１１１のモデリング部９０４は、テーブルＡとテーブルＢとテーブルＣとを結合する際、興味軸として売上金に沿って結合を行うものとする。この場合、興味軸となった売上金以外に、テーブルＡ、テーブルＢ、テーブルＣのそれぞれには日付のカラムが共通して存在しているものとする。
　一般に、売上金について、データ分析や可視化を行う際に、その日付期間が一致していることが前提となる場合が想定できる。しかしながら各テーブルを異なるシステムから、集めてきた場合には、例えば、テーブルＡおよびテーブルＢについては、売上金の集計が２０１２年４月から開始されて現時点まで継続しているのに対し、テーブルＣについては２０１４年４月から開始されて現時点まで継続しているといった形でのデータの日付期間にずれがある場合が想定される。このような場合を想定し、不確定性定義リスト１２３およびそこから参照される不確定性判定／解決部１１２に準備する例を示す。
　不確定性の判定方法モジュール７０２として、結合するテーブル間の日付期間を比較するものを準備する。日付を表すカラムについての最小値を期間の開始日としてみなし、最大値を期間の終了日として見なして、期間を比較する。上記の例では、テーブルＡおよびテーブルＢについては売上金の集計が２０１２年４月から開始されているため、最小値である２０１２年４月が開始日となる。一方、テーブルＡ、テーブルＢ、テーブルＣの売上金の集計がいずれもが現時点まで継続しているため、最大値である現在の日付が終了日となる。なお、カラムに紐付く最小値および最大値については、単カラムメタデータとしてメタデータ格納ＤＢ１５２において図６に示されるテーブル６０１のような形式で保持されている。
　これに対応する対処方法モジュール７０３としては、結合するテーブルのそれぞれからＡＮＤ条件を満たす重複期間のデータのみを扱うというモジュールを準備しておくことができる。上記の例では、テーブルＡ、テーブルＢ、テーブルＣのすべてについて、２０１４年４月からのデータのみを使って結合する形となる。
　それ以外の対処方法として、日付期間の長さを優先し、ＯＲ条件を満たす最大の日付期間が取得できるテーブルの組合せのみを利用する、という方法も準備しておくことができる。上記の例では十分な期間を持たないテーブルＣを無視して、テーブルＡおよびテーブルＢのみを利用し最大の２０１２年４月から現在までの日付期間を使ったデータ結合を行うことになる。
　図４のステップ４０３に示すように、こうした対処方法は自動適用されるものではなく、ユーザに対し提示した上で選択を促すものである。ユーザが最終的に行いたい分析や可視化につながるものを選択することが期待される。目的次第では、ここに示した２つの選択肢以外に、日付期間についてはとくに対処せず、そのまま結合を行うという選択もある。
　以上のように日付期間に着目して、不確定性定義リスト１２３と不確定性判定／解決部１１２とを準備しておくことで、日付に基づく不確定性をハンドリングする。
　上記実施例１におけるモデリングの不確定性のハンドリングに際し、結合するカラム間の種類（以下では種類の違いの一例として単位）の違いに着目する例を示す。以下では、モデリング部９０４は、不確定性の基準として、結合するカラムが同じ単位のデータであるか否かを判定している。
　モデリングエンジン１１１のモデリング部９０４は、テーブルＡとテーブルＢを結合する際、売上金という興味軸に沿って結合を行うものとする。その際、テーブルＡとテーブルＢの双方に売上金に該当するカラムがあった場合、これを結合しようとする。縦方向に結合する場合、テーブルＡの売上金カラムと、テーブルＢの売上金カラムが、同じ基準の売上金であることが、確度の高いモデリング操作であることの条件となる。
　一般に業務システムにおいて、売上金を扱う場合、システム内でその単位がどの通貨で表現するかについては暗黙に定めている場合も多いが、テーブルＡとＢとを異なるシステムから集めてきた場合、両者が同じ通貨を用いていないことも想定される。また、通貨単位の違いのみでなく、仮に同じ日本円であっても、管理方法の違いからＭ￥（１００万円単位）やｋ￥（１０００円単位）など、桁数の扱いが異なる場合も想定される。このような場合を想定し、不確定性定義リスト１２３を準備する例を示す。
　不確定性の判定方法モジュール７０２として、結合するテーブル間の結合するカラムついて、数値分布を比較し、大きな違いがないかを判定することができる。本例では売上金の単位や桁数の数値分布を比較するため、結合対象となるカラム同士の値の最大値または最小値、平均または中央値などを比較し、これらのカラム同士の値に大きな差異がないことを確認する。例えば、上記数値分布として両者が重複する面積が予め定められた割合が一定以上の場合（例えば、両者の総面積に対して５０％以上が重複しない場合）には、両者の通貨単位が異なっていると判定する。
　これに対応する、対処方法モジュール７０３としては、単位変換を行うデータ加工を準備しておくことができる。なお、通貨単位まで確定することは難しいため、ユーザ入力を伴って、単位や変換レートを確定させる操作を伴うことも想定する。また、特に１０００倍や１００００倍などに桁数の扱いによる違いに対してはその対処方法として、一方の売上金の桁数を参照し、他方の売上金の桁数をその桁数に合わせるために倍率を乗算し、両者の売上金の桁数の整合性を取るデータ加工も準備しておくことができる。この判定及び対処の方法については、通貨のみならず、他の単位系についても使用することができる。
　以上のように実施例３と実施例４では日付期間や単位に着目して不確定性定義リスト１２３を準備する例を示した。このように、一般あるいは業務上の通念を元に、モデリングにおいて想定されうる不確定性を事前に準備しておくことで、ハンドリング可能な不確定性を拡充し、モデリングの精度を向上させることにつなげることが可能である。
　上記したように、本システムでは、人手によってデータベース間の整合性を担保するのではなく、統計分析など自動処理によって得られるメタデータによりこれを代替する。この場合、ビジネスインテリジェンスをセルフサービス化する際、メタデータを手がかりとした場合、簡易なユーザ入力からデータモデリングを一意に確定させることができるとは限らない。しかし、上記のような処理を実行することにより、これをデータモデリングにおける不確定性として抽出し、データモデリング操作フローの中でハンドリングする仕組みを準備し、ユーザに解決の機会を提供する。したがって、データベースのモデリングに際し、簡易なユーザ入力からデータモデリングを行う場合の事前準備にあたる工程を軽減することができる。また、例えば、ビジネスインテリジェンスのセルフサービス化にあたって、事前に十全のデータベース間の整合性を担保する必然性を軽減し、そこにかかるコストを削減することができる。
　以上のように、データモデリングシステムでは、情報処理装置を用いて、既存データベースのデータを複合的に用い、新たなテーブルを生成し、データ分析や可視化を行うためのモデリングを行う用途に適している。
１００：　モデリング環境
１０１：　入力装置
１０２：　出力装置
１１０：　ＣＰＵ
１１１：　モデリングエンジン
１１２：　不確定性判定／解決部
１１３：　ＵＩ入力部
１１４：　ＵＩ出力部
１２０：　外部記憶装置
１２１：　モデリング状態記憶部
１２２：　モデリング結果保存ＤＢ
１２３：　不確定性定義リスト
１３０：　メタデータ生成環境
１４０：　ＣＰＵ
１４１：　メタデータ生成部
１５０：　外部記憶装置
１５１：　データソース格納ＤＢ
１５２：　メタデータ格納ＤＢ
１６０：　ネットワーク
１６１：　ネットワーク
１７０：　可視化／分析環境
１７１：　入力装置
１７２：　出力装置
１８０：　ＣＰＵ
１８１：　可視化／分析部
１８２：　ＵＩ入力部
１８３：　ＵＩ出力部

Claims (7)

  1. 　１または複数のデータベースに記憶されている複数のテーブルを結合するデータモデリングシステムであって、
    　ユーザから、テーブルを結合するための軸となるカラムの指定を受け付けるカラム入力部と、
    　前記軸となるカラムに類似するカラムを含むテーブルを、前記１または複数のデータベースの中から検索するカラム検索部と、
    　検索されたテーブルに含まれる前記軸となるカラムに類似するカラムを複数の方法で結合し、結合したテーブルをモデリング候補として出力するモデリング部と、
    　前記結合したテーブルの候補から、前記入力部から次に指定された次カラムとの類似度が一定以上の類似カラムを抽出するカラム抽出部と、
    　抽出された前記次カラムを出力し、出力した前記次カラムの中からユーザが選択したカラムを受け付けるカラム選択受付部と、
    　前記次カラムに基づいて前記結合したテーブルの候補を絞り込み、前記次カラムを含むテーブルを新たな前記結合したテーブルをモデリング候補として出力するテーブル候補更新部と、
    　を備えることを特徴とするデータモデリングシステム。
  2. 　前記テーブル候補更新部は、前記次カラムが前記結合したテーブルに含まれるか否かを判定し、前記次カラムが前記結合したテーブルに含まれないと判定した場合、前記データベースから新たな前記軸となるカラムを探索し、探索した前記カラムを含むテーブルを前記モデリング候補に結合可能なテーブルとして絞込み、絞り込んだ前記結合可能なテーブルを前記モデリング候補に結合した新たなモデリング候補を出力する、
    　ことを特徴とする請求項１に記載のデータモデリングシステム。
  3. 　前記モデリング部は、結合する前記カラムが同じ基準で入力されたデータか否かを判定し、その判定結果を、どの前記データベースのテーブルから結合されたデータかを示す情報と対応付けて結合結果として記憶部に記憶する、
    　ことを特徴とする請求項１に記載のデータモデリングシステム。
  4. 　前記モデリング部は、結合する前記カラムが同じ基準で入力されたデータでないと判定した場合、前記判定の理由を示す不確定性種別と前記不確定性種別で示される不確定性の判定方法および前記判定方法により判定されたときの対処方法とが対応付けてあらかじめ記憶された対処法テーブルに基づいて、前記不確定性を判定して前記対処方法による対処を実行し、前記結合したテーブルをモデリング候補として出力する、
    　ことを特徴とする請求項３に記載のデータモデリングシステム。
  5. 　前記モデリング部は、前記基準として、結合する前記カラムが同じ日付期間のデータであるか否かを判定する、
    　ことを特徴とする請求項３に記載のデータモデリングシステム。
  6. 　前記モデリング部は、前記基準として、結合する前記カラムが同じ単位のデータであるか否かを判定する、
    　ことを特徴とする請求項３に記載のデータモデリングシステム。
  7. 　１または複数のデータベースに記憶されている複数のテーブルを結合するデータモデリング方法であって、
    　ユーザから、テーブルを結合するための軸となるカラムの指定を受け付け、
    　前記軸となるカラムに類似するカラムを含むテーブルを、前記１または複数のデータベースの中から検索し、
    　検索されたテーブルに含まれる前記軸となるカラムに類似するカラムを複数の方法で結合し、結合したテーブルをモデリング候補として出力し、
    　前記結合したテーブルの候補から、前記入力部から次に指定された次カラムとの類似度が一定以上の類似カラムを抽出し、
    　抽出された前記次カラムを出力し、出力した前記次カラムの中からユーザが選択したカラムを受け付け、
    　前記次カラムに基づいて前記結合したテーブルの候補を絞り込み、前記次カラムを含むテーブルを新たな前記結合したテーブルをモデリング候補として出力する、
    　ことを特徴とするデータモデリング方法。
PCT/JP2016/071156 2016-07-19 2016-07-19 データモデリングシステム、データモデリング方法 WO2018016001A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2016/071156 WO2018016001A1 (ja) 2016-07-19 2016-07-19 データモデリングシステム、データモデリング方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2016/071156 WO2018016001A1 (ja) 2016-07-19 2016-07-19 データモデリングシステム、データモデリング方法

Publications (1)

Publication Number Publication Date
WO2018016001A1 true WO2018016001A1 (ja) 2018-01-25

Family

ID=60992372

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/071156 WO2018016001A1 (ja) 2016-07-19 2016-07-19 データモデリングシステム、データモデリング方法

Country Status (1)

Country Link
WO (1) WO2018016001A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020152804A1 (ja) * 2019-01-23 2020-07-30 日本電気株式会社 情報提供システム、方法およびプログラム

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000293414A (ja) * 1999-04-07 2000-10-20 Hitachi Ltd 異種データソース統合方法
JP2002288012A (ja) * 2001-03-23 2002-10-04 Casio Comput Co Ltd ファイル結合装置、及びプログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000293414A (ja) * 1999-04-07 2000-10-20 Hitachi Ltd 異種データソース統合方法
JP2002288012A (ja) * 2001-03-23 2002-10-04 Casio Comput Co Ltd ファイル結合装置、及びプログラム

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020152804A1 (ja) * 2019-01-23 2020-07-30 日本電気株式会社 情報提供システム、方法およびプログラム
JPWO2020152804A1 (ja) * 2019-01-23 2021-12-09 日本電気株式会社 情報提供システム、方法およびプログラム
JP7276355B2 (ja) 2019-01-23 2023-05-18 日本電気株式会社 情報提供システム、方法およびプログラム
US11860910B2 (en) 2019-01-23 2024-01-02 Nec Corporation Information provision system, method, and program

Similar Documents

Publication Publication Date Title
Milo et al. Automating exploratory data analysis via machine learning: An overview
CN110532019B (zh) 一种软件代码片段历史追溯的方法
EP2608074A2 (en) Systems and methods for merging source records in accordance with survivorship rules
JP6028103B2 (ja) データ管理方法、データ管理装置及び記憶媒体
JP6132698B2 (ja) 表形式多次元データ変換方法及び装置
JP2011186729A (ja) データ処理装置
JP6947155B2 (ja) 情報検索システム
US10127292B2 (en) Knowledge catalysts
US20110060712A1 (en) Method and system for design check knowledge construction
JP7375861B2 (ja) 関連スコア算出システム、方法およびプログラム
KR102243794B1 (ko) 데이터 통합 장치 및 데이터 통합 방법
CN103678513B (zh) 一种交互式的检索式生成方法及系统
CN105138643A (zh) 专利检索系统及其检索方法
JP7065718B2 (ja) 判断支援装置および判断支援方法
JP2005149414A (ja) プロジェクトリスクの検索方法、評価システム及び共通データベース活用方法
WO2018016001A1 (ja) データモデリングシステム、データモデリング方法
JP5439235B2 (ja) 文書分類方法、文書分類装置、およびプログラム
JP2008197976A (ja) 連結情報生成プログラム及び連結情報生成方法
US20160147879A1 (en) Fuzzy Search and Highlighting of Existing Data Visualization
WO2019123704A1 (ja) データ分析支援装置、データ分析支援方法およびデータ分析支援プログラム
JP5474871B2 (ja) データ分析のデータ抽出システム、方法、及びプログラム
Vardigan et al. Creating Rich, Structured metadata: lessons learned in the metadata portal project
JP6245571B2 (ja) データ構造、データ生成装置、その方法及びプログラム
JP4568320B2 (ja) 処理手順生成装置及び処理手順生成方法
WO2020070929A1 (ja) プラント機器情報管理システム

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: 16909476

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16909476

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP