JP6633009B2 - Table data analysis program - Google Patents

Description

  The present invention relates to a table data analysis program.

  In the past, when developing a new system without an existing system, there was a technology that shared the specifications of the system among stakeholders as a unified notation using a conceptual data model, and gradually clarified it (for example, Patent Document 1).

  These technologies use a conceptual data model to perform a logical design first, then a physical design, and finally describe as a detailed design document and implement it according to a top-down flow. It is.

  On the other hand, when developing a new system by modifying the existing system that is already in operation, it is necessary to understand the specifications (structure, structure) of the current system in a bottom-up flow.

JP 2011-154653 A

  However, in the conventional method as described above, in order to understand the specifications of the current system (hereinafter, referred to as “current specifications”) in a bottom-up flow, the current specifications are automatically converted and represented as conceptual data models as they are. It was difficult.

  As a method to understand the current specifications, read existing documents (for example, system specifications, system design documents, user use manuals, maintenance and operation manuals), hear from system users, and read the system program source code. There is a way to understand the specification by analyzing it.

  However, such a method requires a comprehensive judgment by looking at a wide variety of information obtained, and is a difficult task unless a veteran skilled technician possessing various past knowledge. Further, since such a method requires a large amount of work, a technique capable of lowering the technical level threshold so that many developers can work and reducing the amount of work is desired.

  If documents such as specifications have been lost, or if the current system has been operated for a long period of time, the document may have been modified and reworked many times. In some cases, it is difficult to extract specifications from documents in such cases.

  Also, even with the method of hearing with the system user, the information obtained is limited to what the system user knows.

  Furthermore, even with the method of analyzing the program source code, it is possible to analyze the business rules expressed in the source code, but to detect local rules (minor rules that are easy to overlook) that only the business staff using the system knows. It is difficult.

  The present invention has been made in view of the above points, and has as its object to support the understanding of computer system specifications.

Therefore, in order to solve the above problem, the table data analysis program classifies columns including a plurality of types of values among columns in the first table data into columns for each type, and divides each row of the first table data into columns. a classification unit for classifying according to the type of value that each row comprises a processing unit for generating a second table data by processing the first table data based on the classification result by the classifying unit, wherein In the first table data, the unit of the pattern of the repetition of the type in the column including the values of the plurality of types is analyzed, and the line including the head type in the unit and the line including the type other than the head in the unit are distinguished. A computer functions as an analysis unit that adds information to the second table data .

  It can assist in understanding computer system specifications.

FIG. 2 is a diagram illustrating an example of a hardware configuration of an analyzer 10 according to the first embodiment. FIG. 2 is a diagram illustrating an example of a functional configuration of an analyzer 10 according to the first embodiment. 5 is a flowchart for explaining an example of a processing procedure executed by the analyzer 10 according to the first embodiment. FIG. 4 is a diagram illustrating an example of table data. FIG. 11 is a diagram illustrating an example of table data to which labels are added by eliminating mixing. It is a figure showing the example of functional composition of analyzer 10 in a 2nd embodiment. 9 is a flowchart for explaining an example of a processing procedure executed by the analyzer 10 according to the second embodiment. FIG. 14 is a diagram illustrating an example of table data according to the second embodiment. FIG. 14 is a diagram illustrating an example of table data after correction in the second embodiment. FIG. 14 is a diagram illustrating an example of manual correction of table data according to the second embodiment. FIG. 13 is a diagram illustrating an example of a functional configuration of an analyzer 10 according to a third embodiment. 15 is a flowchart for explaining an example of a processing procedure executed by the analyzer 10 according to the third embodiment. FIG. 4 is a diagram illustrating an example of a row or a column corresponding to noise. It is a figure showing the example of functional composition of analyzer 10 in a 4th embodiment. 15 is a flowchart for explaining an example of a processing procedure executed by the analyzer 10 according to the fourth embodiment. FIG. 9 is a first diagram for explaining an analysis of a unit of a multi-layout structure. FIG. 9 is a second diagram for explaining the analysis of the unit of the multi-layout structure. FIG. 14 is a third diagram for describing the analysis of the unit of the multi-layout structure. FIG. 4 is a diagram illustrating an example of table data in which units of a multi-layout structure are analyzed. It is a figure showing the example of functional composition of analyzer 10 in a 5th embodiment. 15 is a flowchart illustrating an example of a processing procedure executed by an analyzer 10 according to a fifth embodiment. It is a figure showing the 1st example of detection of a singular point. It is a figure showing the 2nd example of detection of a singular point. It is a figure showing the 3rd example of detection of a singular point. It is a figure showing the example of functional composition of analyzer 10 in a 6th embodiment. 15 is a flowchart for explaining an example of a processing procedure executed by the analyzer 10 according to the sixth embodiment. FIG. 24 is a diagram illustrating an example of a plurality of table data input in the sixth embodiment. FIG. 21 is a diagram illustrating an example of a plurality of table data for which a relational structure is estimated in the sixth embodiment. It is a figure showing the example of functional composition of analyzer 10 in a 7th embodiment. It is a figure showing the 1st example of a conceptual data model diagram. It is a figure showing the 2nd example of a conceptual data model figure. FIG. 9 is a diagram illustrating an example of table data in which a column is added for each singular point. It is a figure showing the 3rd example of a conceptual data model figure.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a diagram illustrating an example of a hardware configuration of an analyzer 10 according to the first embodiment. 1 includes a drive device 100, an auxiliary storage device 102, a memory device 103, a CPU 104, an interface device 105, a display device 106, an input device 107, and the like, which are mutually connected by a bus B.

  A program for realizing the processing in the analyzer 10 is provided by a recording medium 101 such as a CD-ROM. When the recording medium 101 storing the program is set in the drive device 100, the program is installed from the recording medium 101 to the auxiliary storage device 102 via the drive device 100. However, the program need not always be installed from the recording medium 101, and may be downloaded from another computer via a network. The auxiliary storage device 102 stores installed programs and also stores necessary files and data.

  The memory device 103 reads out the program from the auxiliary storage device 102 and stores it when there is an instruction to start the program. The CPU 104 implements functions related to the analyzer 10 according to a program stored in the memory device 103. The interface device 105 is used as an interface for connecting to a network. The display device 106 displays a GUI (Graphical User Interface) based on a program. The input device 107 includes a keyboard, a mouse, and the like, and is used to input various operation instructions.

  FIG. 2 is a diagram illustrating an example of a functional configuration of the analyzer 10 according to the first embodiment. 2, the analyzer 10 has an input unit 11, a classification unit 12, a processing unit 13, and the like. Each of these units is realized by a process of causing the CPU 104 to execute one or more programs installed in the analyzer 10.

  The input unit 11 stores data (hereinafter, referred to as “table data”) obtained by converting data of a database of a computer system (hereinafter, referred to as “DB store data”), which is a specification analysis target, into a text format. (Hereinafter, referred to as “table data file”). DB store data is data having a tabular structure.

  The classification unit 12 classifies a column including a plurality of types of values among columns in the table data into columns for each type, and classifies each row of the table data according to the type of the value included in each row.

  The processing unit 13 processes the input table data based on the classification result by the classification unit 12 to generate table data in which the classification result is reflected.

  Hereinafter, a processing procedure executed by the analyzer 10 will be described. FIG. 3 is a flowchart illustrating an example of a processing procedure executed by the analyzer 10 according to the first embodiment.

  In step S100, the input unit 11 reads table data stored in a table data file specified by the user.

  FIG. 4 is a diagram illustrating an example of the table data. As shown in FIG. 4, the table data has a tabular structure.

  Subsequently, the classification unit 12 determines whether different types of data are mixed in the column direction or the row direction in the table data (S110). Specifically, the classification unit 12 first determines, for each column, the type of each value included in the column. For the determination of the type of the value, for example, a “classification filter using a regular expression” can be used. The classification filter is prepared for each type, and the type of each value can be determined by applying each classification filter to each value. For example, the type of the value that matches the classification filter expressing “telephone number” is determined to be “telephone number”. By doing so, a column including a plurality of types of values is determined to be a column in which data of different types are mixed.

  In the example of FIG. 4, it is determined that two types of data of “address” and “alphanumeric” are mixed in the second column. That is, in the first row, the value in the second column is an address, but the values in the second and fourth rows are alphanumeric. On the other hand, the first, third, fourth, and fifth columns are columns of a single type of “name”, “mail address”, “date”, and “number”, respectively. Is determined.

  Further, regarding the row direction, after the determination in the column direction is performed, the difference in the type of each row is determined based on the difference in the combination of the types of the columns constituting each row.

  In a database such as an RDB (Relational Database), it is unlikely that a table including columns or rows in which two or more types of data are mixed is low as shown in FIG. For example, in a mainframe system such as that described above, there is a case where table information in a format as shown in FIG. 4 exists for the purpose of reducing storage capacity and the like.

  When a plurality of types are mixed in the column direction or the row direction (Yes in S110), the processing unit 13 classifies a column in which a plurality of types are mixed for each type, and eliminates the mixed types ( S111). That is, the processing unit 13 processes the table data by classifying (dividing) a column in which a plurality of types are mixed into columns for each type.

  Subsequently, the processing unit 13 assigns a label to each of the classified columns and rows (S130).

  FIG. 5 is a diagram illustrating an example of table data to which labels have been added by eliminating the mixture. In FIG. 5, the type determined for the column (“name”, “address”, “alphanumeric character”, “mail address”, “date”, “numerical value”) is assigned to each column as a label. Have been. In the initial state of FIG. 4, "address" and "alphanumeric" belong to the same column, but in FIG. 5, they are classified (divided) into different columns by the operation of step S111.

  In FIG. 5, “★” or “○” is given as a label to each line. That is, “★” is a label assigned to a line including “name”, “address”, “mail address”, “date”, and “number”. “○” is a label given to a line including “alphanumeric characters” and “numeric characters”. Note that a common label may be given to rows of the same type, and a symbol or character string other than “★” and “O” may be used as a label.

  Note that the processing unit 13 may display the table data with the label on the display device 106, for example, in a table format as shown in FIG.

  As described above, according to the first embodiment, table data including columns in which different types of data are mixed can be converted into table data in which columns are classified by type. As a result, it is possible to improve the clarity of the meaning of the invisible table data structure. That is, it is possible to support understanding of the specifications of the computer system such as the current system. For example, it is possible to reduce the design burden of new system design and the like, and to eliminate the need for highly skilled persons for data analysis and the like.

  Next, a second embodiment will be described. In the second embodiment, points different from the first embodiment will be described. Points that are not particularly mentioned in the second embodiment may be the same as those in the first embodiment.

  FIG. 6 is a diagram illustrating an example of a functional configuration of the analyzer 10 according to the second embodiment. 6, the same components as those in FIG. 2 are denoted by the same reference numerals, and description thereof will be omitted. 6, the analyzer 10 further includes a classification support unit 14. The classification support unit 14 is realized by a process of causing the CPU 104 to execute one or more programs installed in the analyzer 10.

  The classification support unit 14 supports further classification of the table data that has been automatically processed (elimination of mixing and labeling) as illustrated in FIG.

  FIG. 7 is a flowchart illustrating an example of a processing procedure executed by the analyzer 10 according to the second embodiment. 7, the same steps as those in FIG. 3 are denoted by the same step numbers, and a description thereof will be omitted.

  Subsequent to step S130, the classification support unit 14 determines whether or not the current table data needs to be corrected (S140). The current table data refers to the table data after execution of step S111 when step S111 is executed, and the table data in the state input at step S100 when step S111 is not executed. Say. The determination of the necessity of the correction may be performed based on the presence or absence of the input by the user. For example, the user may input whether or not the table data displayed by the processing unit 13 needs to be corrected.

  Subsequently, the classification support unit 14 determines whether a new classification filter has been input to correct the table data (S141). Here, it is assumed that the table data displayed by executing steps up to step S130 is as shown in FIG.

  FIG. 8 is a diagram illustrating an example of table data according to the second embodiment. In FIG. 8, the value of the “address” of the row whose “name” is “Makoto Sato” is “Osaka Prefectural Arts and Cultural Management Foundation”. That is, FIG. 8 shows an example in which the “Osaka Prefectural Arts and Cultural Management Foundation” is incorrectly classified as an “address”.

  In this case, for example, the user can define a classification filter for classifying a character string ending in “Foundation” into a company name and add it as one of the filter groups used in step S111. Note that the newly added classification filter may correspond to an existing type, or may correspond to a new type.

  When a new classification filter is input (Yes in S140), the processing from step S100 is repeated using the classification filter and the existing classification filter. As a result, the table data in FIG. 8 is modified as shown in FIG.

  FIG. 9 is a diagram illustrating an example of table data after correction in the second embodiment. In FIG. 9, a column of "company name" is added to the right of the column of "address", and "Osaka Prefectural Arts and Cultural Management Foundation" is moved to the column of "company name".

  By adopting such a method, for example, when a mixture of types that cannot be classified by the assumed classification filter is found, correct classification can be performed by further adding a classification filter.

  On the other hand, when the classification cannot be performed by the classification filter (No in S141), the classification support unit 14 receives a direct correction instruction from the user for eliminating the mixture by the user's manual correction. For example, addition of a new column and values classified into the column are selected by the user. In this case, the classification support unit 14 adds a new column to the table data and moves the selected value to the column (S141).

  FIG. 10 is a diagram illustrating an example of manual correction of table data according to the second embodiment. In (1) of FIG. 10, a certain column of the table data is extracted with a classification filter capable of extracting a name, and as a result, the “director” and the “room manager” are erroneously selected as the data of the “name”. An example is shown in which “Principal Investigator”, “Principal Investigator”, “Manager in Charge”, “Chief Investigator”, and the like have been selected as data other than “Name”. It should be noted that the data other than “name” refers to data not selected as “name”, and is not intended to include the type “other than name”. The data shown in FIG. 10 is different from the data shown in FIG. 4 for convenience.

  In this case, as shown in (2), the user adds a new column labeled “Position” to the table data, and adds “New director”, “Office director”, “Chief researcher”, “Chief researcher”. "," Director in charge "," Chief investigator ", etc., and input an instruction to move a value corresponding to the position to the column.

  By doing so, for example, when the user notices that there is an error in the result of the automatic classification by the classification filter, it is possible to lead to a correct classification result by manual correction.

  Next, a third embodiment will be described. In the third embodiment, points different from the second embodiment will be described. What is not particularly mentioned in the third embodiment may be the same as in the second embodiment.

  FIG. 11 is a diagram illustrating an example of a functional configuration of the analyzer 10 according to the third embodiment. 11, the same parts as those of FIG. 6 are denoted by the same reference numerals, and the description thereof will be omitted. In FIG. 11, the analyzer 10 further includes a noise removing unit 15. The noise removing unit 15 is realized by a process of causing the CPU 104 to execute one or more programs installed in the analyzer 10.

  The noise elimination unit 15 deletes (removes) the row or the column when the data considered to be noise (data not used in actual operation such as test data) is detected in the row or the column in the table data. I do.

  FIG. 12 is a flowchart illustrating an example of a processing procedure executed by the analyzer 10 according to the third embodiment. 12, the same steps as those in FIG. 7 are denoted by the same step numbers, and a description thereof will be omitted.

  Subsequent to step S110 or step S111, the noise removing unit 15 determines whether there is a row or a column corresponding to noise in the table data (S120). Whether it corresponds to noise may be determined based on, for example, whether any of the keywords stored in the auxiliary storage device 102 in advance is included. When any one of the keywords is included, it may be determined to correspond to the noise, or when a certain keyword is included in a predetermined ratio or more, it may be determined to correspond to the noise. In this case, the predetermined ratio together with the keyword may be stored in the auxiliary storage device 102 as a rule (rule) for specifying the noise target.

  FIG. 13 is a diagram illustrating an example of a row or a column corresponding to noise. For example, when there is a rule in which a column including 80% or more of all data including characters matching the keyword “test” is a noise target, the column c1 in FIG. 13 corresponds to noise. This is because column c1 includes “test” in 16 rows out of 20 rows.

  If there is a rule that includes a line that includes at least one “Travel Expense Taro” as a noise target, a line surrounded by a rectangle r1 corresponds to the noise.

  It should be noted that even if there is a rule in which a column in which data including characters matching the keyword "Travel expense" matches 80% or more of all data is a noise target, the column c2 does not correspond to noise. This is because, in column c2, the ratio of “Travel expenses Taro” is 50%.

  When there is a row or a column corresponding to the noise (Yes in S120), the noise removing unit 15 deletes the row or the column (S121).

  As described above, according to the third embodiment, the processing after step S130 can be executed in a state where the row or column corresponding to noise has been deleted. Therefore, the accuracy of the processing after step S130 can be improved, and the processing can be made more efficient.

  Next, a fourth embodiment will be described. In the fourth embodiment, the points that are different from the third embodiment will be described. What is not particularly mentioned in the fourth embodiment may be the same as in the third embodiment.

  FIG. 14 is a diagram illustrating an example of a functional configuration of the analyzer 10 according to the fourth embodiment. 14, the same parts as those of FIG. 11 are denoted by the same reference numerals, and the description thereof will be omitted. In FIG. 14, the analysis device 10 further has a multi-layout analysis unit 16. The multi-layout analysis unit 16 is realized by a process of causing the CPU 104 to execute one or more programs installed in the analysis device 10.

  The multi-layout analysis unit 16 detects the presence of a multi-layout structure in the table data and analyzes a unit of the multi-layout structure. As shown in FIG. 4, the multi-layout structure refers to a structure that includes columns in which a plurality of types are mixed in one table data. The “unit of the multi-layout structure” refers to a unit of a pattern of repeating a type in a column including values of a plurality of types.

  The detection of multi-layout structures is usually performed by manual analysis and detection by highly-skilled people with specialized knowledge, but it can be detected only by a limited number of specific people, and the method must be widely used. Can not. In addition, since it is left to the manual work of a highly skilled person, the cost is high and dissemination is hindered. Thus, in the present embodiment, the multi-layout analysis unit 16 automatically detects a multi-layout structure.

  FIG. 15 is a flowchart illustrating an example of a processing procedure executed by the analyzer 10 according to the fourth embodiment. 15, the same steps as those of FIG. 12 are denoted by the same step numbers, and a description thereof will be omitted.

  Subsequent to step S140 or step S142, the multi-layout analysis unit 16 determines whether a multi-layout structure exists in the table data (S150). If a multi-layout structure exists (Yes in S150), the multi-layout analysis unit 16 analyzes a unit of the multi-layout structure (S151).

  FIG. 16 is a first diagram illustrating the analysis of the unit of the multi-layout structure. FIG. 16A shows an example in which an address and a name appear alternately in column # 1, and the other type is single. That is, in the table data of (1), the repetition pattern of the address and the name is every two lines, and has a periodicity of two lines. Strictly, at the time of step S151, column # 1 is classified into two columns by the operation of step S111. Therefore, in step S151, analysis is performed for each set of columns that were initially the same column. Note that columns # 1 to # 4 are symbols that abstractly indicate the labels of each column.

  The analysis result in this case is as shown in (2). That is, the multi-layout analysis unit 16 determines two rows as a unit of the multi-layout structure. Further, the multi-layout analysis unit 16 determines that the first row (the row including the “address”) of the two rows is the “head structure (head row)” (main information structure) of the multi-layout structure, The other rows (rows including “name”) are determined to be the “body structure (body row)” (auxiliary information structure) of the multi-layout structure.

  That is, when the multi-layout structure has regular periodicity, the period is determined as a unit of the multi-layout structure.

  FIG. 17 is a second diagram illustrating the analysis of the unit of the multi-layout structure. FIG. 17A shows an example in which not only column # 1 but also column # 3 (strictly, a set of columns classified from column # 3) has periodicity. However, the unit of periodicity of column # 1 is 2, whereas the unit of periodicity of column # 3 is 4.

  The analysis result in this case is as shown in (2). That is, the multi-layout analysis unit 16 regards 4 which is the least common multiple of the periodicity (2 and 4 in this example) of each column as the periodicity of the entire row, and determines this as the unit of the multi-layout structure. In addition, the multi-layout analysis unit 16 determines, for each unit of the multi-layout structure, the first row as a head row and the other rows (the second to third rows in FIG. 17) as body rows.

  FIG. 18 is a third diagram for explaining the analysis of the unit of the multi-layout structure. FIG. 18A shows an example in which types (type A and type B) are mixed only in column # 1, and types are not mixed in other columns. However, the column # 1 has a structure in which the type A and the type B repeatedly appear, although the period is not constant.

  The analysis result in this case is as shown in (2). That is, the multi-layout analysis unit 16 determines each of the first to third rows and the fourth to eighth rows as a unit of the multi-layout structure. In addition, the multi-layout analysis unit 16 determines, for each unit of the multi-layout structure, the first row as a head row and the other rows as body rows.

  In the detection of the multi-layout structure and the analysis of the unit of the multi-layout structure, for example, a set of types of each column in each row is set as a vector, and the existence of a vector pattern is detected (for example, a vector A and a vector B). , A pattern in which a plurality of occurrences of the vector A and a plurality of occurrences of the vector B are repeated is determined, and the unit of these repetitions is determined as a unit of the multi-layout structure.

  Note that the multi-layout analysis unit 16 may reflect the analysis result of the unit of the multi-layout structure in, for example, table data as shown in FIG.

  FIG. 19 is a diagram illustrating an example of table data in which units of the multi-layout structure are analyzed. The table data shown in FIG. 19 includes a column of “multi-layout flag”. Further, the labels of the respective columns are classified into “in the case of HEAD” and “in the case of BODY”. The table data in FIG. 19 is different from the table data in FIG. 4 for convenience.

  The column of “multi-layout flag” is a column indicating whether each row is a head row or a body row. That is, the value of the column in the head row is “HEAD”, and the value of the column in the body row is “BODY”.

  Also, the row of “in the case of HEAD” indicates the label of each column in the head row, and the row of “in the case of BODY” indicates the label of each column in the body row.

  As described above, according to the fourth embodiment, it is possible to automatically detect a multi-layout structure in table data, which is common in an old current system, and determine (estimate) a unit of the multi-layout structure. can do. As a result, the clarity of the table structure can be improved.

  Note that the fourth embodiment may be combined with only the first embodiment or only with the second embodiment.

  Next, a fifth embodiment will be described. In the fifth embodiment, points different from the fourth embodiment will be described. What is not particularly mentioned in the fifth embodiment may be the same as the fourth embodiment.

  When migrating an existing system to a new system, the detection of important business rules existing in the current system (and the business using it) is omitted, and problems occur in the downstream process (mainly the test process) of the development of the new system. It has been a problem that it was discovered and reworked the development. In order to solve this problem, it is necessary to thoroughly detect the business rules (especially important rules) possessed by the current system. Reading and understanding, hearing from the person in charge of the operation of the current system, and analyzing the source code of the current system as a last resort, etc., are detected, and it takes a lot of trouble and operation, and instead it is omission Has also occurred.

  Therefore, in the fifth embodiment, in order to easily detect important business rules of the current system, anyone focuses on the DB store data held by the current system, and uses only the DB store data as input information. An example of finding a business rule will be described.

  FIG. 20 is a diagram illustrating a functional configuration example of the analyzer 10 according to the fifth embodiment. 20, the same parts as those of FIG. 14 are denoted by the same reference numerals, and the description thereof will be omitted. In FIG. 20, the analyzer 10 further includes a singular point detection unit 17. The singularity detection unit 17 is realized by a process of causing the CPU 104 to execute one or more programs installed in the analyzer 10.

  The singularity detection unit 17 detects an outlier (singularity) for each numeral string based on the relational structure in the table data that has been clarified (estimated) up to step S151. The number sequence refers to a sequence including only numbers as values (that is, a sequence having numerical values). By detecting the singularity, the singularity detecting unit 17 finds signs of minor work hidden in major work in work belonging to the same genre, and estimates minor work rules therefrom. Contribute. The tasks belonging to the same genre are considered to correspond to one row in one table, and a sign of a minor rule is detected by detecting a value that is a singular point in the row.

  FIG. 21 is a flowchart illustrating an example of a processing procedure performed by the analyzer 10 according to the fifth embodiment. In FIG. 21, the same steps as those in FIG. 15 are denoted by the same step numbers, and a description thereof will be omitted.

  Subsequent to step S150 or step S151, the singularity detection unit 17 determines whether there is one or more numeric strings in the table data (S160). The determination of the numeric string is performed, for example, by checking the value included in each column. In the case of the table data shown in FIG. 19, the column of “date” of the head row and the body row, the column of “product number” of the body row, the column of “number” of the body row, and the “telephone number” of the head row Column corresponds to a numeric string.

  When there is one or more number strings (Yes in S160), the singularity detection unit 17 attempts to detect a singularity for each number string (S161). For example, the singularity detection unit 17 obtains, for each unit of the multi-layout structure, the minimum value, the maximum value, and the average value of the numerical values indicated by the numbers, and calculates the minimum value, the maximum value, or the average value. If there is a value (singular point) showing a tendency different from the value in the majority unit of, this value is detected.

  FIG. 22 is a diagram illustrating a first detection example of a singular point. In FIG. 22, in the table data shown in FIG. 19, the minimum value (oldest date) and the minimum value (oldest date) of the column of “date” and the column of “number” of the body row are set for each unit of the multi-layout structure. An example in which the maximum value (latest date) and the average value (average date) are calculated is shown.

  In the example of FIG. 22, the oldest date (“10000101”) of the unit of the first multi-layout structure in the column of “date” is the oldest date of the unit of the other multi-layout structure in the same column. It can be seen that it deviates from. In this case, the singularity detecting unit 17 detects the oldest date (“10000101”) of the unit of the first multi-layout structure in the column of “date” as a singularity, and determines that the oldest date is Outputs the location information of the stored cell.

  The user investigates why the value of this singularity is different from the majority of the values, and interviews the business rules that cause the problem with business operations staff who seem to know the meaning of the singularity. Discover by etc. As a result, for example, according to the example of FIG. 22, the user has determined that the value of January 1, 1000 is a local rule that the return processing was performed differently from other dates (shipping completion dates). , You can discover business rules that are easy to overlook.

  Alternatively, the detection of a singular point may be performed as follows. FIG. 23 is a diagram illustrating a second example of detecting a singular point. In FIG. 23, the value of the column of “year, month, day” is the date of integration from the reference date, with the oldest date in the column (the date of the first row in FIG. 23) as the reference date. Has been converted to a numeric column. In this case, the singular point detection unit 17 detects a value that is far from the others in the numerical value sequence. In the example of FIG. 23, it is detected that only 0 is significantly different from the others. As a result, it is possible to support the discovery of the local rule as described above.

  The detection of a singular point may be performed as follows. FIG. 24 is a diagram illustrating a third detection example of a singular point. In FIG. 24, it is assumed that columns # 1 and # 3 are numeric strings.

  The singular point detection unit 17 calculates a variance value for each number string (1). In FIG. 24, it is assumed that the variance value for column # 1 is 0.1 and the variance value for column # 3 is 0.001. In this case, since the variance of column # 1 is the largest, the singularity detection unit 17 estimates that there will be a singularity in column # 1 (2), and classifies the value of column # 1 by the clustering method. (3). As the clustering method, for example, a known method such as the K-means method may be used. As a result of the clustering, the singularity detecting unit 17 detects a value belonging to a cluster having a relatively small number of elements as a singularity (4).

  The user can find a local rule as described above based on the singularity.

  As described above, according to the fifth embodiment, it is possible to detect a singular point from DB store data (table data) and notify the user of the singular point. The user can find a business rule by investigating the cause of the singularity. In other words, conventional methods such as source code analysis can extract only the rules implemented in them, so it is not possible to detect business rules for minor operations that are often overlooked, such as those known only by business site staff. It was difficult. According to the present embodiment, since a business rule or the like is extracted from the DB store data holding the current work result, such a minor business rule can also be detected. Therefore, it is possible to discover important business rules without requiring advanced skills.

  Note that the fifth embodiment may be combined only with each embodiment other than the fourth embodiment.

  Next, a sixth embodiment will be described. In the sixth embodiment, points different from the fifth embodiment will be described. What is not particularly mentioned in the sixth embodiment may be the same as the fifth embodiment.

  FIG. 25 is a diagram illustrating an example of a functional configuration of the analyzer 10 according to the sixth embodiment. 25, those parts that are the same as those corresponding parts in FIG. 20 are designated by the same reference numerals, and a description thereof will be omitted. In FIG. 25, the analyzer 10 further includes a relationship estimating unit 18. The relationship estimating unit 18 is realized by a process of causing the CPU 104 to execute one or more programs installed in the analyzer 10.

  When a plurality of table data (a plurality of tables) are input, the relationship estimating unit 18 estimates the relationship (reference relationship) between the tables.

  FIG. 26 is a flowchart illustrating an example of a processing procedure performed by the analyzer 10 according to the sixth embodiment. 26, those steps which are the same as those corresponding steps in FIG. 21 are designated by the same step numbers, and a description thereof will be omitted.

  In the sixth embodiment, steps S100 to S160 or S161 are executed for a plurality of table data.

  FIG. 27 is a diagram illustrating an example of a plurality of table data input in the sixth embodiment. FIG. 27 shows three table data T1 to T3.

  When steps S100 to S160 or S161 are executed for each of the table data T1 to T3, each table data is in a state shown in FIG. 28, for example.

  FIG. 28 is a diagram illustrating an example of a plurality of table data for which a relational structure has been estimated in the sixth embodiment. In FIG. 28, each column of the table data T1 to T3 is classified into columns 1 to 7, columns 11 to 13, or columns 21 to 23. In particular, regarding the table data T1, the second column in FIG. 27 is classified into a column 2-1 and a column 2-2. Note that labels for each column and labels for each row are omitted.

  Subsequently, the relationship estimating unit 18 estimates the relationship between the respective table data (S170). For example, the relationship between table data is determined by, for example, whether all values included in any column of one table data are included in any column of the other table data. You. When all the values included in any one column of one table data are included in any column of the other table data, between all the two table data (strictly speaking, Is determined to have a reference relationship. In this case, of the two columns determined to be in the reference relationship, the direction from the column having the overlapping value to the column having no overlapping value may be the reference direction. This is because it is estimated that a column having no value duplication may be a column storing a key value in the table data including the column.

  For example, all values in column 2-2 of table data T1 are included in table data T2 column 11. Further, while there is a value overlap in the column 2-2 of the table data T1, there is no value overlap in the column 11 of the table data T2. Therefore, it is determined that the column 2-2 of the table data T1 refers to the table data T2 column 11. All the values in column 7 of table data T1 are included in column 21 of table data T3. Further, while there is a value overlap in column 7 of table data T1, there is no value overlap in column 21 of table data T3. Therefore, it is determined that the column 7 of the table data T1 refers to the column 21 of the table data T3.

  The relationship estimating unit 18 may display information indicating the determination result on the display device 106.

  As described above, according to the sixth embodiment, the relationship structure between table data can be clarified. By clarifying the relational structure between the tables, it is possible to expect easier discovery of unknown system specifications and business rules.

  Note that the sixth embodiment may be combined only with each embodiment other than the fifth embodiment.

  Next, a seventh embodiment will be described. In the seventh embodiment, points different from the sixth embodiment will be described. What is not particularly mentioned in the seventh embodiment may be the same as in the sixth embodiment.

  FIG. 29 is a diagram illustrating a functional configuration example of the analyzer 10 according to the seventh embodiment. 29, those parts that are the same as those corresponding parts in FIG. 25 are designated by the same reference numerals, and a description thereof will be omitted. In FIG. 29, the analysis device 10 further has a model generation unit 19. The model generation unit 19 is realized by a process of causing the CPU 104 to execute one or more programs installed in the analysis device 10.

  The model generation unit 19 generates a concept data model for the processing result before step S161. The DB store data in the current system has a large data amount and a large number of table data as the system becomes complicated and large-scale. In this case, it is difficult to understand the relationship between the table data as a structure. Therefore, the model generation unit 19 sets one table data as one concept, generates a concept data model diagram (class diagram) using the label of each column in the one table data as an attribute of the concept, and generates a data structure diagram that is difficult to understand. Contribute to better understanding. Note that the model generation unit 19 may execute processing in parallel with other units.

  For example, when the three types of table data shown in FIG. 27 are input, the model generation unit 19 expresses each table data in the input state as one box (concept or class), and A conceptual data model diagram obtained by automatically converting a column (column structure) as a class attribute is displayed on the display device 106.

  FIG. 30 is a diagram illustrating a first example of a conceptual data model diagram. In FIG. 30, class 1 is a class based on the table data T1 in FIG. Class 2 is a class based on the table data T2. Class 3 is a class based on the table data T3. Each class has attributes corresponding to the columns of the corresponding table data.

  In addition, at the time when the steps up to step S170 are executed for each table data, the model generating unit 19 may update the conceptual data model diagram as shown in FIG.

  FIG. 31 is a diagram illustrating a second example of the conceptual data model diagram. FIG. 31 shows that class 1 aggregates class 1H and class 1B. The class 1H is a class corresponding to the head row having the multi-layout structure, which is analyzed by performing the step S151 on the table T1. That is, the class 1H is a class corresponding to a row including values in column 1, column 2-1, column 3, column 4, column 5, column 6, and column 7 in the table T1 of FIG. On the other hand, the class 1B is a class corresponding to a body row having a multi-layout structure, which is analyzed by executing step S151 in FIG. 26 for the table T1. That is, the class 1B is a class corresponding to a row including values in the columns 2-2, 4 and 5 in the table T1 of FIG. Class 1 includes a plurality of units of a multi-layout structure. Therefore, the multiplicity between class 1 and class 1H is one-to-many, and the multiplicity is assigned to the relationship line between class 1 and class 1H. Similarly, the multiplicity between the class 1 and the class 1B is one-to-many, and the multiplicity is given to the relationship line between the class 1 and the class 1B.

  Since the head row and the body row of the multi-layout structure are displayed separately on the conceptual data model, it is possible to easily grasp the multi-layout structure.

  In FIG. 31, the class 1H and the class 3 are connected by a relation line, and the class 1B and the class 2 are connected by a relation line. The direction of the arrow of the relation line follows the reference direction between the classes related to the relation line. This is based on the execution result of step S170 in FIG. 26 for the table data T1 to T3. That is, in step S170, it is estimated that the column related to column 7 of the table data T1 refers to the column related to column 1 of the table data 3. In addition, it is estimated that the column related to column 2-2 of the table data T1 refers to the column related to column 1 of the table data T2. FIG. 31 shows that the original concept of the arrow refers to the concept ahead of the arrow. As shown in FIG. 31, each relationship line may be additionally provided with a label of a column having a reference relationship.

  Furthermore, the execution result of step S161 in FIG. 26 may be reflected in the conceptual data model diagram. In this case, in step S161, the singularity detection unit 17 adds a row for each detected singularity to the table data, and moves the singularity with respect to the row. As a result, if it is the table data T1 in FIG. 28, for example, it is updated as shown in FIG.

  FIG. 32 is a diagram illustrating an example of table data in which a column is added for each singular point. In FIG. 32, the column 4 of the table data T1 is classified into columns 4-1, 4-2, and 4-3. Column 4-2 is a destination column of the singular point “10000101” included in column 4. Column 4-3 is a destination column of the singular point “999999999” included in column 4.

  The model generation unit 19 may generate a conceptual data model diagram as shown in FIG. 33 for such table data T1.

  FIG. 33 is a diagram illustrating a third example of the conceptual data model diagram. In FIG. 33, the columns (columns 4-2 and 4-3) corresponding to the singular points are also clearly shown as attributes of class 1H. By doing so, the information of the singular point (the existence of the singular point) can be shown in an easily understandable manner using the conceptual data model structure.

  As described above, according to the seventh embodiment, the result of clarifying the structure in the table data and between the table data is automatically converted and expressed by using the conceptual data model, so that the structure of the table data can be understood. Can be facilitated.

  Note that the seventh embodiment may be combined with only the respective embodiments other than the sixth embodiment.

  Further, according to each of the above-described embodiments, by using the DB store data as the input information, it is possible to eliminate the need for the skill of comprehensively determining various input information.

  Further, according to each of the above-described embodiments, the present invention extracts information on the specifications of the current system from the DB store data, so that only the DB store data can be obtained without performing various documents, hearings, and program analysis. The only way to analyze is to allow non-experts to estimate the specifications of the current system. Further, by expressing the structure of the system using the conceptual data model, a person who estimates the specifications of the current system can understand the system easily.

  In each of the above embodiments, the concept of columns and rows may be interchanged. That is, a column may be grasped as a row, or a row may be grasped as a column.

  In each of the above embodiments, the program installed in the analyzer 10 is an example of a table data analysis program. Table data is an example of table data. The classification support unit 14 is an example of a reception unit. The multi-layout analysis unit 16 is an example of an analysis unit. The singular point detection unit 17 is an example of a detection unit. The model generation unit 19 is an example of a generation unit. The noise removing unit 15 is an example of a deleting unit.

  As mentioned above, although the Example of this invention was described in full detail, this invention is not limited to such a specific embodiment, A various deformation | transformation is carried out within the range of the gist of this invention described in the claim.・ Change is possible.

Reference Signs List 10 analysis device 11 input unit 12 classification unit 13 processing unit 14 classification support unit 15 noise removal unit 16 multi-layout analysis unit 17 singular point detection unit 18 relationship estimation unit 19 model generation unit 100 drive device 101 recording medium 102 auxiliary storage device 103 Memory device 104 CPU
105 interface device 106 display device 107 input device B bus

Claims (6)

Among the columns in the first table data, columns including a plurality of types of values are classified into columns for each type, and each row of the first table data is classified according to the type of the value included in each row. A classifier,
A processing unit that processes the first table data based on a classification result by the classification unit to generate second table data;
Analyzing the unit of the pattern repetition of the type in the column including a plurality of types of values in the first table data, and distinguishing between the row including the head type in the unit and the row including the type other than the head in the unit An analyzing unit for adding information to be performed to the second table data;
A table data analysis program for causing a computer to function as a computer. The classification unit, the type based on the classification information for determining determines the type of each value in the first table data, the necessity of the classification result in which the second table data to the pair to correct Is determined, if further classification information is added when it is determined that correction is necessary, a column including a plurality of types of values is classified into columns for each type based on the classification information.
2. The table data analysis program according to claim 1, wherein: Causing a computer to function as a receiving unit that receives correction by the user for the classification result,
3. The table data analysis program according to claim 1, wherein: Causing the computer to function as a deletion unit that deletes a column or a row that meets a predetermined rule among the columns and rows in the second table data;
The table data analysis program according to any one of claims 1 to 3, wherein: For a column related to a numerical value in the second table data, in a set of numerical values included in the column, cause the computer to function as a detecting unit that detects a numerical value indicating a tendency different from other numerical values,
The table data analysis program according to any one of claims 1 to 4, wherein: Causing the computer to function as a generation unit that generates a conceptual data model diagram in which the second table data is a class and the columns of the second table data are attributes;
The table data analysis program according to any one of claims 1 to 5, wherein:

Images