WO2014041699A1 - データ分析方法、データ分析装置及びその処理プログラムを格納した記憶媒体 - Google Patents

データ分析方法、データ分析装置及びその処理プログラムを格納した記憶媒体 Download PDF

Info

Publication number
WO2014041699A1
WO2014041699A1 PCT/JP2012/073734 JP2012073734W WO2014041699A1 WO 2014041699 A1 WO2014041699 A1 WO 2014041699A1 JP 2012073734 W JP2012073734 W JP 2012073734W WO 2014041699 A1 WO2014041699 A1 WO 2014041699A1
Authority
WO
WIPO (PCT)
Prior art keywords
dimension
data analysis
query
identifier
data
Prior art date
Application number
PCT/JP2012/073734
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 US14/402,838 priority Critical patent/US9892187B2/en
Priority to JP2014535341A priority patent/JP5784239B2/ja
Priority to PCT/JP2012/073734 priority patent/WO2014041699A1/ja
Publication of WO2014041699A1 publication Critical patent/WO2014041699A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/283—Multi-dimensional databases or data warehouses, e.g. MOLAP or ROLAP

Definitions

  • the present invention relates to a technique for analyzing data stored in a database.
  • OLAP On-line Analytical Processing
  • Patent Documents 1, 2, and 3 In database analysis, it is required to aim for business added value by predicting human consumption behavior (for example, Patent Documents 1, 2, and 3).
  • a graph database consisting of nodes and edges is also known for RDB.
  • data for expressing a complicated relationship such as a person-to-person relation and a distribution situation in a distribution network is stored as it is, and a schema definition is not required in advance like an RDB.
  • the purpose of graph analysis in which analysis is performed using this graph database is to precisely determine people, things, and contents based on data clustering and distance approximation.
  • OLAP data analysis a query is processed for a star schema composed of a dimension table and a history table to obtain a query result, but the query target is narrowed by a range search to the dimension table. .
  • the means for narrowing down the data analysis target has been difficult to realize only by a range search to the dimension table.
  • an object of the present invention is to realize precise data analysis by combining RDB data analysis and graph analysis without using a plurality of applications.
  • the present invention is a data analysis method for analyzing data in a data analysis apparatus including a storage device, wherein the data analysis apparatus corresponds to a first identifier for identifying data to be analyzed, and the first identifier A first step of setting a plurality of dimension tables including attributes to be performed, and the data analysis apparatus includes second identifiers respectively associated with the first identifiers of the plurality of dimension tables.
  • the dimension table includes a third step including a first dimension table associated with the relation table via an attribute associated with the first identifier and the second identifier, and the data analysis device includes the dimension table.
  • the data capacity can be reduced, and as a result of the graph analysis and the OLAP analysis, the number of data of the dimension tables is reduced, and further, the product calculation and the graph processing are performed. The amount of data processing is reduced.
  • FIG. 1 is a block diagram showing an example of the graph data analysis apparatus according to the first embodiment of the present invention.
  • the graph data analysis apparatus 1 is a computer that performs analysis according to an accepted query on the data of PD1 to PD4 stored in the database 10 and outputs an analysis result.
  • the graph data analysis apparatus 1 includes a CPU 8 that performs calculations, a main storage device 2 that stores data and programs, an auxiliary storage device 4 that stores a database 10 and programs, and a network interface 5 that communicates with a network (not shown). And an auxiliary storage device interface 3 that reads from and writes to the auxiliary storage device 4, an input device 6 that includes a keyboard and a mouse, and an output device 7 that includes a display, a speaker, and the like.
  • the main storage device 2 is loaded with an operating system (OS) 20 and executed by the CPU 8.
  • OS operating system
  • a graph data analysis unit 30 that receives an inquiry and analyzes data operates.
  • the graph data analysis unit 30 includes a table definition processing unit 310, a data load processing unit 320, and an inquiry processing unit 330 as processing units.
  • the graph data analysis unit 30 includes a star schema 400 and a relation table 500 as data to be processed and a data structure.
  • the table definition processing unit 310, the data load processing unit 320, and the inquiry processing unit 330, which are processing units, are executed by the CPU 8 after being loaded into the main storage device 2.
  • the CPU 8 operates as a functional unit that realizes a predetermined function by operating according to the program of each functional unit.
  • the CPU 8 functions as the table definition processing unit 310 by operating according to the table definition program. The same applies to other programs.
  • the CPU 8 also operates as a functional unit that realizes each of a plurality of processes executed by each program.
  • a computer and a computer system are an apparatus and a system including these functional units.
  • Information such as programs, data or data structures for realizing each function of the graph data analysis unit 30 is stored in an auxiliary storage device 4, a nonvolatile semiconductor memory, a hard disk drive, a storage device such as an SSD (Solid State Drive), or an IC card. It can be stored in a computer-readable non-transitory data storage medium such as an SD card or a DVD.
  • the auxiliary storage device 4 stores the database 10 that is the source of the data to be analyzed, the dictionary 11 that stores definitions of the structure of the database 10, the structure of the star schema 400, and the fact table 410 of the star schema 400.
  • the history information 12 to be stored is stored.
  • the programs of the OS 20 and the graph data analysis unit 30 can be stored in the auxiliary storage device 4. 1 shows an example in which the star schema 400 is held in the main storage device 2, but when the capacity of the star schema 400 is large, a part of the star schema 400 is held in the main storage device 2 and the others. May be held in the auxiliary storage device 4.
  • the database 10 shows an example in which PD1 to PD4 configured by RDB are stored.
  • these databases 10 are original data to be analyzed, and are duplicates of external databases or portions thereof. Etc. can be configured.
  • the history information 12 is data obtained by extracting data to be analyzed in time series from the data in the database 10, and is used as the fact table 410 of the star schema 400.
  • the dictionary 11 stores the definition of the history information 12, the definition of the star schema 400, and the definition of the relation table 500.
  • FIG. 2 is a block diagram showing an example of the relationship of data used in the present invention.
  • the cube 700 to be operated by OLAP is a result of the OLAP operation performed on the star schema 400.
  • the table group in which the star schema 400 is defined includes a fact table 410 including the substance of data extracted from the history information 12 having the database 10 as original data, and a plurality of dimension tables 420a to 420d defining data to be analyzed or aggregated. Consists of In the following, the generic name of the dimension table is indicated by 420.
  • the fact table 410 and the dimension table 420 are related by a primary key.
  • the database PD1 is a sales database, and as the history information 12, a customer sales history table (see FIGS. 7A and 8) is provided.
  • the database PD2 is a call database, and a call history table (see FIG. 4) is provided as the history information 12.
  • FIG. 2 shows an example in which the structure of the star schema 400 is composed of a dimension table 420 of products, customers, periods, and regions with respect to the fact table 410.
  • the graph structure shows the relationship between people (customers). An example of attention is shown.
  • the dimension table 420a is a product dimension table related to product names (see FIG. 7A)
  • the dimension table 420b is a period dimension table related to periods (see FIG. 7A)
  • the dimension table 420c is a customer related to customer identifiers. It is a source table (see FIG. 7A)
  • a dimension table 420d is a region dimension table related to region names (see FIG. 7A).
  • the graph structure 600 shows an example of paying attention to the relationship between people, and is composed of a human identifier and a relationship between people.
  • the graph structure 600 is composed of edges indicating relationships between nodes, and each node has a primary key.
  • the customer dimension table 420c of the star schema 400 and the graph structure 600 focused on the person are the same data
  • the customer dimension table 420c of the star schema 400 and the graph as shown in FIG. It can be the same as 500 ′ included in structure 600.
  • one of the dimension tables 420 of the star schema 400 is used as a node, and the graph data itself only needs to hold an edge. Therefore, by combining the dimension table 420 and the node including the same data, the node data is duplicated. You can avoid holding. As a result, the data amount of the dimension table 420 of the star schema 400 and the graph structure 600 can be reduced.
  • the data of the target dimension table is narrowed down by the graph data analysis based on the graph structure 600. Until now, narrowing down was done only by range search to the dimension table.
  • the data of the customer dimension table 420c can be reduced by narrowing down the target number of customers to 1 / n by graph data analysis.
  • the dimension table 420 to be narrowed down on the fact table 410 can be expressed by the graph structure 600, the dimension table 420 can be narrowed down by the graph data analysis. Is greatly reduced and the time required for analysis can be shortened.
  • FIG. 3A is a diagram showing the relationship between the star schema 400 and the cube 700. It is assumed that the number of primary key values in each dimension table 420a to 420d of the star schema 400 is w, x, y, z.
  • the cube 700 requires a calculation amount of O (a ⁇ b ⁇ c ⁇ d) in order to calculate an aggregate value for each cell in the space forming the cube. For example, the number of products ⁇ the number of customers ⁇ the number of periods ⁇ the number of regions.
  • FIG. 3B is a diagram illustrating an example of a graph structure and a graph expression.
  • the graph structure 600 is composed of nodes and edges (representing the relationship between the nodes), and the nodes have primary keys. For example, if the relationship between people is expressed in the graph structure 600, the node has a human identifier as a primary key.
  • the relationship table 500 corresponding to the graph structure is generated from the history information 12. Then, graph data analysis is performed on the dimension table 420 that is the same table as the relationship table 500, thereby narrowing down the operation target data of OLAP.
  • FIG. 4 shows an example of the relation of data for generating the relation table 500.
  • FIG. 4 shows an example in which a customer relationship table 500A is generated as a relationship table 500 indicating the relationship between customers using the call history table 120, the telephone management table 121, and the customer table 122 from the call database of the database PD2. Show. This processing is performed by the table definition processing unit 310 of the graph data analysis unit 30 shown in FIG.
  • the call history table 120 includes a call identifier 1201 for identifying a call, a phone from 1202 for storing a caller telephone number, a phone to 1203 for storing a callee telephone number, a call time 1204, a time 1205, and the like.
  • a record (or row) is constructed.
  • Time 1205 is a preset time such as a call start time or completion time.
  • the telephone management table 121 includes one record (or row) including a telephone number 1210 and a customer identifier 1211 indicating the user of the telephone.
  • the customer table 122 includes a customer identifier 1220 and a customer name 1221 to form one record (or row).
  • a graph structure 600 corresponding to an edge between customers is acquired as a customer relationship table 500A from a customer identifier, a caller (phone from 1202), and a callee (phone to1203).
  • the call charge can be calculated from the call history table 120, the telephone management table 121, and the customer table 122 from the total call time for each customer name.
  • the table definition processing unit 310 obtains a caller customer identifier and a callee customer identifier from the telephone management table 121 using the telephone from 1202 and the telephone to 1203 of the call history table 120 as keys. Further, the customer name 1221 corresponding to each customer identifier is acquired from the customer table 122.
  • the table definition processing unit 310 stores a customer from 501 that uses the telephone from 1202 of the call history table 120 as the customer identifier of the caller, a customer to502 that uses the telephone to1203 as the customer identifier of the callee, and a time 503 for storing the time 1204. Then, the customer relationship table 500A constituting one record (or row) is generated from the time 504 at which the time 1205 is stored.
  • the table definition processing unit 310 sets a definition 510 in which the customer identifiers of the customer from 501 and the customer to 502 correspond to the customer dimension table 420c for the generated customer relationship table 500A.
  • FIGS. 5A and 5B an example of the relation of data for generating the star schema 400 is shown in FIGS. 5A and 5B.
  • FIG. 5A is a diagram illustrating a data relationship when a star schema is generated.
  • FIG. 5B is a diagram illustrating an example of a star schema definition.
  • FIG. 5A shows an example of generating the dimension table 420 and the fact table 410 shown in FIG. 2 from the sales database of the database PD1. This processing is performed by the table definition processing unit 310 of the graph data analysis unit 30 shown in FIG. In this embodiment, an example in which a customer sales history table 410a is generated as the fact table 410 is shown.
  • the table definition processing unit 310 generates a customer sales history table 410a from the sales database of the database PD1.
  • the customer sales history table 410a includes a sold product identifier 411, a customer identifier 412 that purchased the product, a region code 413 that the product was sold, and a period code 414 that stores the time when the product was sold.
  • Each record (or row) includes the selling price 415 for storing the sold price and the sold quantity 416.
  • the product identifier 411, the customer identifier 412, the region code 413, and the period code 414 of the customer sales history table 410a are treated as a plurality of identifiers, and the selling price 415 and the number 416 are treated as attributes.
  • the table definition processing unit 310 generates a product dimension table 420a having the product identifier 411 of the customer sales history table 410a as a main key from the sales database.
  • the merchandise dimension table 420a includes a merchandise identifier 421 and a merchandise name 422, which are primary keys, and constitutes one record (or row).
  • the product identifier 421 is treated as an identifier associated with the product identifier 411 of the customer sales history table 410a
  • the product name 422 is treated as an attribute.
  • the table definition processing unit 310 generates a customer dimension table 420b having the customer identifier 412 of the customer sales history table 410a as a main key from the sales database.
  • the customer dimension table 420c includes a customer identifier 425 and a customer name 426, which are primary keys, and constitutes one record (or row).
  • the customer identifier 425 is treated as an identifier associated with the customer identifier 412 of the customer sales history table 410a
  • the customer name 426 is treated as an attribute.
  • the table definition processing unit 310 generates an area dimension table 420d having the area code 413 of the customer sales history table 410a as a main key from the sales database.
  • the region dimension table 420d includes one region (or row) including a region code 427 and a region name 428 as primary keys.
  • the region code 427 is treated as an identifier associated with the region code 413 of the customer sales history table 410a
  • the region name 428 is treated as an attribute.
  • the table definition processing unit 310 generates a period dimension table 420b having the period code 414 of the customer sales history table 410a as a main key from the sales database.
  • the period dimension table 420b includes a period code 423 serving as a primary key and a period name 424 as an attribute to form one record (or row).
  • the period code 423 is treated as an identifier associated with the period code 414 of the customer sales history table 410a
  • the period name 424 is treated as an attribute.
  • FIG. 5B is an example of the definition 520 of the star schema 400.
  • the table definition processing unit 310 reads the definition 520 in FIG. 5B and generates a fact table 410 (customer sales history table 410a) and a dimension table 420 shown in FIG. 5A.
  • FIG. 6 shows a state in which the table definition processing unit 310 generates the star schema 400 shown in FIG. 5A and takes in the sales database data of the database PD1.
  • the customer dimension table 420c has the customer identifier 425 as a primary key, it can be understood that the customer dimension table 420c can be composed of the same data as the nodes of the graph structure 600 shown in FIG.
  • the customer relationship table 500A shown in FIG. 4 the directionality of a call between customer identifiers (customer from 501 and customer to 502) can be treated as an edge indicating the correlation between customers.
  • the customer identifier 425 of the customer dimension table 420c is used as a node, and the customer from 501 and the customer to 502 of the customer relationship table 500A indicating the correlation of call history between customers are used as edges as shown in FIG.
  • the customer dimension table 420c of the star schema 400 and the customer relationship table 500A are combined to be handled as a graph structure 600.
  • FIG. 7A is a diagram showing a combination of data when the combination of the customer dimension table 420c and the customer relationship table 500A is handled as the graph structure 600.
  • the customer identifier 425 of the customer dimension table 420c of the star schema 400 connected by a thick line is a node, and the customer from 501 and the customer to 502 of the customer relationship table 500A are edge From and To.
  • the graph structure 600 ′ can be configured with the customer dimension table 420 c of the star schema 400 as a node and the customer relationship table 500 A as an edge.
  • the relationship table 500 does not have a graph data node, and it is only necessary to hold an edge. Therefore, the data amount when the star schema 400 and the graph structure 600 are combined can be reduced.
  • graph data analysis is performed on the graph structure 600 ′ of FIG. 7A, and the amount of data in the customer sales history table 410a, which is the fact table 410 to be operated, is narrowed down, so that OLAP can be performed at high speed. Data analysis can be realized.
  • FIG. 7B is a diagram showing an example of the definition 530 when the graph structure 600 is handled from the combination of the customer dimension table 420c and the customer relationship table 500A.
  • the definition 530 is an example of defining a customer dimension table 420c as a node and further defining a customer relationship table 500A as an edge.
  • FIG. 8 shows actual data taken from the databases PD1 and PD2 into the star schema 400 and the customer relationship table 500A shown in FIG. 7A.
  • the graph data analysis unit 30 Upon receipt of the inquiry, the graph data analysis unit 30 performs analysis after narrowing down the customers using the graph structure 600 ′ from the dimension table 420, the customer sales history table 410a, and the customer relationship table 500A of the star schema 400. Can do.
  • FIG. 9 is a flowchart illustrating an example of processing performed by the table definition processing unit 310. This process is executed when the graph data analysis apparatus 1 receives an inquiry.
  • a database to be analyzed is defined by a query. That is, the table definition processing unit 310 stores the relationship table 500 that stores the relationship between matters and objects, the dimension table 420 that can describe the meaning of real world data, and the real world data as unified time series data. The relationship between the history table, the relationship table 500, and the dimension table 420 is defined.
  • the table definition processing unit 310 defines a plurality of dimension tables 420 having a primary key for identifying an analysis target designated by the query and one or more attributes related to the key as columns (S1). This processing corresponds to “CREATE TABLE-dimension table” in FIG. 5B.
  • the table definition processing unit 310 forms a primary key with a plurality of columns referring to the primary keys of the plurality of dimension tables 420, and defines a history table having one or more attributes related to these primary keys as columns. (S2). This processing corresponds to the “CREATE TABLE customer sales history table” in FIG. 5B.
  • the table definition processing unit 310 includes a first column and a second column that refer to the primary key of the dimension table 420, and one or more attributes related to the first column and the second column as columns.
  • the relationship table to be defined is defined (S3). This process corresponds to the “CREATE TABLE customer relationship table” in FIG. 7B and the definition 510 in FIG. 4 (S3).
  • the table definition processing unit 310 performs a definition for associating the first column and the second column of the relationship table 500 that refer to the primary key of the dimension table 420 with the primary key of the relationship table 500.
  • This process corresponds to the “CREATE TABLE customer dimension table” and “CREATE TABLE customer relationship table” in FIG. 7B (S3).
  • the graph structure 600 'of FIG. 8 is set.
  • FIG. 10 is a flowchart illustrating an example of processing performed by the data load processing unit 320 of the graph data analysis apparatus 1. This process is executed after the process of FIG. 9 is completed. Alternatively, it is performed when an administrator or the like instructs execution from the input device 6.
  • the data load processing unit 320 loads data from the database 10 to each dimension table 420 to be analyzed generated by the table definition processing unit 310 (S11).
  • the data load processing unit 320 loads data from the database 10 into the analysis target customer sales history table 410a (fact table 410) generated by the table definition processing unit 310 (S12).
  • the data load processing unit 320 loads data from the database 10 into the analysis target customer sales history table 410a (fact table 410) generated by the table definition processing unit 310 (S12).
  • the data load processing unit 320 loads the column information referring to the primary key of the dimension table 420 and the attributes related to these columns from the history information 12 into the relation table 500 as rows (S13).
  • the data of the database 10 is taken into the dimension table 420, the fact table 410 of the star schema 400, and the relation table 500 referring to the dimension table 420.
  • data is stored in the star schema 400 and the relationship table 500 as shown in FIG.
  • FIG. 11 is a diagram illustrating an example of an integrated analysis inquiry process regarding products and customers. This processing is executed when the graph data analysis apparatus 1 receives an inquiry from the network interface 5 or the input device 6.
  • the customer dimension table 420c (first dimension table) includes data with customer identifiers 425 of “A” to “U”, and constitutes a node of the graph structure 600 '.
  • the customer relationship table 500A also includes data having customer identifiers “A” to “U” in customer from 501 and customer to.
  • the inquiry processing unit 330 uses the customer dimension table 420c 'in which the customer identifier 425 is narrowed down to "A" to "D" as the second dimension table for the subsequent analysis processing. That is, in the subsequent analysis of the star schema 400, the customer dimension table 420c ′, which is the second dimension table obtained by narrowing down the first dimension table to the product dimension table 420a, the period dimension table 420b, and the region dimension table 420d, is converted into customer sales. A query is executed in association with the history table 410a (fact table 410).
  • the OLAP operation or the like can be performed after narrowing down the data amount of the dimension table 420C '(second dimension table) corresponding to the graph structure 600', and the processing can be realized at high speed with a small amount of data.
  • FIG. 12 is a diagram showing an example of recursive query processing in the graph data analysis of the query processing unit 330.
  • Q1 in FIG. 12 shows a process in which the inquiry processing unit 330 calculates the route and distance from a specific node to all nodes for the customer from 501 and the customer to 502 in the customer relationship table 500A. That is, the distance dist between the customer from 501 and the customer to 502 in the customer relationship table 500A of FIG. 4 is calculated.
  • the distance dist between the customer from 501 and the customer to 502 is obtained from the integrated value of the call time 503 or the time zone during which the call is made, and the distance dist as the closeness increases. Is a close value.
  • a well-known or publicly known method may be used in addition to the above familiarity.
  • the inquiry processing unit 330 obtains the shortest path (minPath) from a specific node to all nodes in the customer relationship table 500A.
  • the shortest route is extracted from routes to other nodes related to a certain node.
  • the inquiry processing unit 330 calculates the total distance of the shortest route and calculates the reciprocal of the total distance.
  • the inquiry processing unit 330 determines the node (for example, “A”) having the maximum reciprocal of the distance of the shortest path as the proximity centrality.
  • the inquiry processing unit 330 obtains a node adjacent to the node having the maximum reciprocal of the shortest path distance. As a result, a graph representation 600B as shown in FIG. 3B is obtained.
  • FIG. 13A, 13B, and 13C show an example of the star schema 400 query process.
  • an analysis result is obtained from the Cartesian product set of the dimension tables 420b, 420c, and 420d of the star schema 400 by the query Q02.
  • the area name 428 is Tokyo
  • the period name is the second quarter of 2012
  • the total sales price 415 is obtained for each customer name 426
  • the area code 427 AAA and for each period code and customer identifier 425
  • the total selling price of the product purchased by the customer is obtained.
  • the result of this query Q02 is output as the query result A02 of FIG. 13B.
  • FIG. 14 is a flowchart illustrating an example of processing performed by the inquiry processing unit 330.
  • a second dimension table is created from a recursive query of the cluster property and distance approximation property from the dimension table 420 and the customer relationship table 500A, and a plurality of dimension tables 420 and fact tables including the created second dimension table are created.
  • 410 is an example in which a result is obtained from a query of join and aggregation.
  • the query processing unit 330 performs a recursive query as shown in FIG. 12 on the dimension table 420 and the relation table 500, and the second dimension table (for example, the customer dimension table 420c ′ in FIG. 11) as an intermediate result. Is created (S21).
  • the inquiry processing unit 330 executes a join / aggregation inquiry on the plurality of dimension tables 420 including the intermediate result dimension table and the customer sales history table 410a (S22). Then, the execution result is output (S23).
  • step S21 the proximity centrality (centrality analysis) shown in FIG. 12 is recursively queried from the customer dimension table 420c and the customer relationship table 500A that can form the graph structure 600 ′.
  • the second dimension table (customer dimension table) 420c ′ corresponding to the graph representation 600B is calculated as a customer with high centrality.
  • the inquiry processing unit 330 calculates a second dimension table 420c ′ from the received inquiry from the customer dimension table 420c including a certain customer group and the customer relation table 500A, and the centrality within the customer group is calculated.
  • the centrality within the customer group is calculated.
  • new products can be introduced and advertised efficiently. For example, by introducing a product at the customer “A”, it is possible to convey the introduction of a new product to the customers “B” to “D” who are close to the customer “A” by word of mouth or the like.
  • FIG. 15 shows an example in which the graph data analysis apparatus 1 is adopted for a central data warehouse (CDWH).
  • CDWH central data warehouse
  • the configuration of the graph data analysis apparatus 1 is the same as that shown in FIG.
  • the graph data analysis apparatus 1 acquires the databases PD1 to PD4 by using an ETL (Extract, Trasform, Load) tool.
  • the query is executed to output CUBE 700 and graph data (such as a partial graph).
  • An example in which the analysis by the OLAP or the graph data analysis is performed on the output of the graph data analysis apparatus 1 is shown.
  • the ETL tool may be executed by an external computer, but may be executed by the graph data analysis apparatus 1.
  • the first embodiment by making a part of the dimension table a part of the graph structure 600 ′, it is possible to prevent the data from being held redundantly and to reduce the data amount. . Further, as a result of the graph data analysis, the number of data in the dimension table is reduced, and further, the data processing amount of the direct product calculation and the graph processing is also reduced.
  • the dimension table 420 for narrowing down the fact table 410 can be expressed by the graph structure 600 ′
  • the dimension table 420 can be quickly narrowed down by the graph data analysis. This greatly reduces the amount of data, and shortens the time required for analysis.
  • the dimension table 420 for narrowing down the fact table 410 can be expressed by the graph structure 600 ′, the fact table 410 can be quickly narrowed down by the graph data analysis. This greatly reduces the amount of data, and shortens the time required for analysis.
  • 16 to 19B show a second embodiment, in which a second dimension table is generated from a star schema 400 having a table structure, and graph data is output from the second dimension table. Is the same as in the first embodiment.
  • the second dimension table (customer dimension table 420c ') is generated from the plurality of dimension tables 420 and the fact table 410 (customer sales history table 410a) by OLAP analysis or the like. Then, graph data is output from the second dimension table (customer dimension table 420c ').
  • FIG. 16 is a diagram illustrating a data relationship when a second dimension table (customer dimension table 420c ′) is generated from the star schema 400 and then a graph representation 600B is output.
  • FIG. 17 is a diagram illustrating a data relationship when the second dimension table is generated from the star schema 400.
  • FIG. 18 is a diagram illustrating an example of a query for generating the second dimension table from the star schema 400.
  • FIG. 19A is a diagram illustrating an example of a query when the graph representation 600B is generated from the second dimension table (customer dimension table 420c ′).
  • FIG. 19B is a diagram showing a relation of data when the graph representation 600B is generated from the second dimension table (customer dimension table 420c ′).
  • the data amount of the node that generates the graph data in the second dimension table can be reduced.
  • the data amount of the node that generates the graph data in the second dimension table can be reduced.
  • the number of data of the dimension table is reduced, and further the data amount of the graph data processing is reduced.
  • each processing unit, processing means, and the like may be partially or entirely realized by dedicated hardware.
  • the various software exemplified in the present embodiment can be stored in various recording media (for example, non-transitory storage media) such as electromagnetic, electronic, and optical, and through a communication network such as the Internet. It can be downloaded to a computer.
  • recording media for example, non-transitory storage media
  • a communication network such as the Internet. It can be downloaded to a computer.
  • the present invention is not limited to the above-described embodiments, and includes various modifications.
  • the above-described embodiments have been described in detail for easy understanding of the present invention, and are not necessarily limited to those having all the configurations described.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

　記憶装置を備えたデータ分析装置でデータを分析するデータ分析方法であって、前記データ分析装置が、分析対象のデータを識別する第１の識別子と、当該第１の識別子に対応する属性を含む次元表を複数設定する第１のステップと、前記データ分析装置が、前記複数の次元表の第１の識別子にそれぞれ対応付けられた第２の識別子を有し、これら第２の識別子に対応する属性を含む履歴表を設定する第２のステップと、前記データ分析装置が、前記第１の識別子と第２の識別子に関連する属性を格納する関係表を設定する第３のステップと、前記データ分析装置が、前記次元表の第１の識別子を参照する前記第１の識別子と第２の識別子に関連する属性を関連付ける第４のステップと、前記データ分析装置が、前記関係表と前記第１の次元表を組み合わせて問合せを行い、当該問合せの結果、第２の次元表を生成する第５のステップと、を含む。

Description

データ分析方法、データ分析装置及びその処理プログラムを格納した記憶媒体
　本発明は、データベースに蓄積されたデータを分析する技術に関する。
　企業などでは、一般的な業務システムとしてはＲＤＢ（Relational Data Base）のデータベースを使用し、膨大なデータを蓄積している。企業では、蓄積した顧客データや販売データを、多次元的に解析して、視覚化することでビジネスの課題を解決するために利用することが検討されている。この種のデータの多次元的な解析手法としては、ＯＬＡＰ（On-line Analytical Processing）が知られており、多次元のデータを操作して、複雑な分析を行うものである。例えば、顧客の商品購入の履歴を解析し、地域別の売上や製品別の売上や、既設単位の売上など、多様な次元から高速に分析を実行する。
　データベースの解析では、人の消費行動の予測を行うことで、ビジネス的な付加価値を狙うことが求められている（例えば、特許文献１、２、３）。
　一方、ＲＤＢに対して、ノードとエッジからなるグラフ型データベースも知られている。グラフ型データベースでは、人と人の関係や、物流網における配送状況など複雑な関係を表現するためのデータを、そのままの形で格納し、ＲＤＢのように事前にスキーマ定義を必要としない。このグラフ型データベースを用いて分析を行うグラフ分析では、データのクラスタ性や、距離近似性で、人、モノ、コンテンツを精緻に判断することを目的としている。
特表２００６－５１３４６２号 特開平１０－１１６１９０号 特開２０１１－２９１１号
　しかしながら、上記従来のＯＬＡＰによるＲＤＢのデータ分析では、基本的にデータの集約であり、精緻なデータ分析がなされていなかった。一方、グラフ分析では、データのクラスタ性や、距離近似性で、人やモノ、コンテンツを精緻に判断することを狙っている。
　そこで、グラフ分析でデータのクラスタ性や、距離近似性で、人やモノ、コンテンツ間の関係性を解析する。そして、グラフ分析の結果から、データの全体像、相互関係、潜在的な構造を探るため、ＯＬＡＰ及び統計解析などのデータ分析を組み合わせることは、個別のシステムとして実現されている。このため、膨大なデータから精緻な分析を行うためには、複数のアプリケーションアプリを使い分けることで対処することしかできない、という問題があった。
　また、ＯＬＡＰのデータ分析では、次元表及び履歴表によって構成されるスタースキーマに対して問合せが処理されて問合せ結果が得られるが、次元表への範囲検索によって問合せ対象を絞り込むことがなされていた。即ち、データ分析対象を絞り込む手段は、次元表への範囲検索でしか実現が困難であった。
　そこで本発明は、複数のアプリケーションを用いることなく、ＲＤＢのデータ分析と、グラフ分析を組み合わせて、精緻なデータ分析を実現することを目的とする。
　本発明は、記憶装置を備えたデータ分析装置におけるデータを分析するデータ分析方法であって、前記データ分析装置が、分析対象のデータを識別する第１の識別子と、当該第１の識別子に対応する属性を含む次元表を複数設定する第１のステップと、前記データ分析装置が、前記複数の次元表の第１の識別子にそれぞれ対応付けられた第２の識別子を有し、これら第２の識別子に対応する属性を含む履歴表を設定する第２のステップと、前記データ分析装置が、前記第１の識別子と第２の識別子に関連する属性を格納する関係表を設定し、前記複数の次元表は、前記第１の識別子と第２の識別子に関連する属性を介して前記関係表に関連付けられた第１の次元表を含む第３のステップと、前記データ分析装置が、前記次元表の第１の識別子を参照する前記第１の識別子と第２の識別子に関連する属性を関連付ける第４のステップと、前記データ分析装置が、前記関係表と前記第１の次元表について問合せ処理を行い、当該問合せ処理の結果、第２の次元表を生成する第５のステップと、を含む。
　本発明によれば、次元表を重複して保持しないので、データ容量を削減することができ、また、グラフ分析及びＯＬＡＰ分析した結果、次元表のデータ件数が削減され、さらに直積計算及びグラフ処理のデータ処理量も削減される。
本発明の第１の実施例を示し、グラフデータ分析装置の一例を示すブロック図である。 第１の実施例を示し、データの関連の一例を示すブロック図である。 第１の実施例を示し、スタースキーマとキューブの関係を示すブロック図である。 第１の実施例を示し、グラフ構造とグラフ表現の一例を示す図である。 第１の実施例を示し、関係表を生成する際のデータの関係を示す図である。 第１の実施例を示し、スタースキーマを生成する際のデータの関係を示す図である。 第１の実施例を示し、スタースキーマの定義の一例を示す図である。 第１の実施例を示し、スタースキーマに販売データベースのデータを取り込んだ状態を示す図である。 第１の実施例を示し、顧客次元表と顧客関係表の組み合わせをグラフ構造として扱う場合のデータの組み合わせを示す図である。 第１の実施例を示し、顧客次元表と顧客関係表の組み合わせをグラフ構造として扱う場合のデータの組み合わせを示す図である。 第１の実施例を示し、スタースキーマに販売データベースのデータを取り込み、顧客関係表に通話データベースのデータを取り込んだ状態を示す図である。 第１の実施例を示し、表定義処理部で行われる処理の一例を示すフローチャートである。 第１の実施例を示し、データロード処理部で行われる処理の一例を示すフローチャートである。 第１の実施例を示し、商品と顧客に関する統合分析の問合せ処理の一例を示す図である。 第１の実施例を示し、再帰的問合せの一例を示す図である。 第１の実施例を示し、スタースキーマの問合せ処理の一例を示す図である。 第１の実施例を示し、スタースキーマの問合せ結果の一例を示す次元表の図である。 第１の実施例を示し、スタースキーマの問合せ処理の一例を示す次元表の図である。 第１の実施例を示し、問合せ処理部で行われる処理の一例を示すフローチャートである。 第１の実施例を示し、グラフデータ分析装置をセントラルデータウェアハウスに適用した例を示す。 本発明の第２の実施例を示し、スタースキーマから第２の次元表を生成し、その後、グラフデータを出力する際のデータの関係を示す図である。 第２の実施例を示し、スタースキーマから第２の次元表を生成する際のデータの関係を示す図である。 第２の実施例を示し、スタースキーマから第２の次元表を生成する際の問合せの一例を示す図である。 第２の実施例を示し、第２の次元表からグラフデータを生成する際の問合せの一例を示す図である。 第２の実施例を示し、第２の次元表からグラフデータを生成する際のデータの関連を示す図である。
　以下、本発明の一実施形態について添付図面を用いて説明する。
　図１は、本発明の第１の実施例のグラフデータ分析装置の一例を示すブロック図である。グラフデータ分析装置１は、データベース１０に格納したＰＤ１～ＰＤ４のデータに対して、受け付けた問合せに応じた分析を実行し、分析結果を出力する計算機である。
　グラフデータ分析装置１は、演算を行うＣＰＵ８と、データやプログラムを保持する主記憶装置２と、データベース１０やプログラムを格納する補助記憶装置４と、ネットワーク（図示省略）と通信を行うネットワークインタフェース５と、補助記憶装置４に読み書き行う補助記憶装置インターフェース３と、キーボードやマウスで構成された入力装置６と、ディスプレイやスピーカ等で構成された出力装置７と、から構成される計算機である。
　主記憶装置２には、オペレーティングシステム（ＯＳ）２０がロードされＣＰＵ８によって実行される。そして、ＯＳ２０上では、問合せを受け付けてデータの分析を行うグラフデータ分析部３０が稼働する。グラフデータ分析部３０は、処理ユニットとして表定義処理部３１０と、データロード処理部３２０と、問合せ処理部３３０とを有する。グラフデータ分析部３０は、処理対象データ及びデータ構造としてスタースキーマ４００と関係表５００を有する。処理ユニットである表定義処理部３１０、データロード処理部３２０並びに問合せ処理部３３０は、主記憶装置２にロードされてからＣＰＵ８によって実行される。
　ＣＰＵ８は、各機能部のプログラムに従って動作することによって、所定の機能を実現する機能部として動作する。例えば、ＣＰＵ８は、表定義プログラムに従って動作することで表定義処理部３１０として機能する。他のプログラムについても同様である。さらに、ＣＰＵ８は、各プログラムが実行する複数の処理のそれぞれを実現する機能部としても動作する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。
　グラフデータ分析部３０の各機能を実現するプログラム、データまたはデータ構造等の情報は、補助記憶装置４や不揮発性半導体メモリ、ハードディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）等の記憶デバイス、または、ＩＣカード、ＳＤカード、ＤＶＤ等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。
　補助記憶装置４には、解析するデータの元となるデータベース１０と、データベース１０の構造や、スタースキーマ４００の構造などの定義を格納した辞書１１と、スタースキーマ４００のファクト表４１０のデータを格納する履歴情報１２が格納される。なお、図示はしないが、上述したように、ＯＳ２０やグラフデータ分析部３０のプログラムを補助記憶装置４に格納することができる。また、図１では、スタースキーマ４００が主記憶装置２に保持される例を示すが、スタースキーマ４００の容量が大きい場合には、スタースキーマ４００の一部を主記憶装置２に保持し、その他を、補助記憶装置４に保持するようにしてもよい。
　なお、図１において、データベース１０にはＲＤＢで構成されたＰＤ１～ＰＤ４が格納されている例を示すが、これらのデータベース１０は、分析対象の元のデータであり、外部のデータベースの複製や部分などで構成することができる。
　そして、履歴情報１２は、データベース１０のデータのうち、分析対象のデータを時系列的に抽出したデータであり、スタースキーマ４００のファクト表４１０として用いられるものである。辞書１１には、履歴情報１２の定義や、スタースキーマ４００の定義や関係表５００の定義が格納される。
　＜データ分析の概要＞
　本発明のグラフデータ分析装置１では、ＯＬＡＰ（On-line Analytical Processing）を用いてＲＤＢを多次元データとして分析を行う際に、履歴情報１２の中のグラフ構造を抽出し、ＯＬＡＰの操作対象となるデータ量を絞り込む点を特徴とする。
　図２は、本発明で用いるデータの関連の一例を示すブロック図である。本発明では、ＯＬＡＰの操作対象となるキューブ７００は、スタースキーマ４００に対してＯＬＡＰ操作された処理結果である。スタースキーマ４００の定義されたテーブル群は、データベース１０を元データとする履歴情報１２から抽出したデータの実体を備えるファクト表４１０と、分析または集計するデータを定義した複数の次元表４２０ａ～４２０ｄとから構成される。なお、以下では、次元表の総称を４２０で示す。ファクト表４１０と次元表４２０は、主キーで関連付けられる。
　図２の例では、データベースＰＤ１が販売データベースで、履歴情報１２としては顧客売上履歴表（図７Ａ、図８参照）を提供する。データベースＰＤ２が通話データベースで、履歴情報１２としては通話履歴表（図４参照）を提供する。
　そして、図２では、スタースキーマ４００の構造が、ファクト表４１０に対して商品、顧客、期間、地域の次元表４２０から構成される例を示し、グラフ構造として人（顧客）同士の関係性に着目する例を示している。
　このため、次元表４２０ａは、商品名に関する商品次元表であり（図７Ａ参照）、次元表４２０ｂは、期間に関する期間次元表であり（図７Ａ参照）、次元表４２０ｃは、顧客の識別子に関する顧客元表であり（図７Ａ参照）、次元表４２０ｄは、地域名に関する地域次元表である（図７Ａ参照）。
　また、グラフ構造６００は人の関係性に着目する例を示し、人の識別子と、人同士の関係性で構成される。グラフ構造６００は、ノードとノード間の関係性を示すエッジから構成され、ノードが主キーを持つ。
　ここで、スタースキーマ４００の顧客次元表４２０ｃと、人に着目するグラフ構造６００が、同じデータを対象とすることになれば、図３で示すように、スタースキーマ４００の顧客次元表４２０ｃとグラフ構造６００に含まれる５００’と同じものとすることが可能となる。
　つまり、スタースキーマ４００の次元表４２０のひとつをノードとし、グラフデータ自体はエッジのみを保持すれば良いので、同じデータを含む次元表４２０とノードを結合することで、ノードのデータを重複して保持するのを回避できる。これにより、スタースキーマ４００の次元表４２０と、グラフ構造６００のデータ量を削減することが可能となる。
　そして、問合せの処理の際には、人に関連したファクト表４１０のＯＬＡＰ分析を行う場合、まず、グラフ構造６００によるグラフデータ分析で、対象の次元表のデータを絞り込む。従来までは、次元表への範囲検索でだけ絞り込みがなされていた。
　すなわち、グラフデータ分析によって、対象の顧客数を１／ｎに絞り込むことで顧客次元表４２０ｃのデータを削減できる。
　したがって、ファクト表４１０を絞り込む対象の次元表４２０が、グラフ構造６００で表現可能な場合には、グラフデータ分析によって次元表４２０を絞り込むことが可能となるので、後のＯＬＡＰの操作対象のデータ量が大幅に削減され、分析に要する時間を短縮できるのである。
　図３Ａは、スタースキーマ４００とキューブ７００の関係を示す図である。スタースキーマ４００の各次元表４２０ａ～４２０ｄの主キーの値数をｗ、ｘ、ｙ、ｚとする。キューブ７００は、キューブをなす空間の各セル毎の集約値を算出するために、Ｏ（ａ×ｂ×ｃ×ｄ）の計算量が必要である。例えば、商品数×顧客数×期間数×地域数となる。
　図３Ｂは、グラフ構造とグラフ表現の一例を示す図である。グラフ構造６００は、ノードと（ノード間の関係を表現する）エッジからなり、ノードは主キーを持つ。例えば、グラフ構造６００で人の関係性を表現すると、ノードは人の識別子を主キーとして持つ。
　図中、グラフ表現６００Ａから、グラフデータ分析（パス解析、中心性解析）した結果、特定の人を含む周辺の人（図では１ホップ内）を算出すると、グラフ表現６００Ｂのように、Ａ～Ｄの４人のグラフとなる。この結果、ＯＬＡＰの操作対象の人数は１／ｎとなる。
　ここで、本発明では、履歴情報１２からグラフ構造に対応する関係表５００を生成する。そして、関係表５００と同じ表とされた次元表４２０についてグラフデータ分析を実施することで、ＯＬＡＰの操作対象のデータを絞り込むのである。
　＜関係表の生成＞
　次に、関係表５００を生成するデータの関連の一例を図４に示す。図４はデータベースＰＤ２の通話データベースから、通話履歴表１２０と、電話管理表１２１と、顧客表１２２を用いて、顧客間の関連性を示す関係表５００として、顧客関係表５００Ａを生成する例を示す。この処理は、図１に示したグラフデータ分析部３０の、表定義処理部３１０で行われる。
　通話履歴表１２０は、通話を識別する通話識別子１２０１と、発信元の電話番号を格納する電話ｆｒｏｍ１２０２と、着信先の電話番号を格納する電話ｔｏ１２０３と、通話時間１２０４と、時刻１２０５等からひとつのレコード（または行）が構成される。なお、時刻１２０５は、通話開始時刻または修了時刻など予め設定した時刻である。
　電話管理表１２１は、電話ＮＯと１２１０と、当該電話の使用者を示す顧客識別子１２１１を含んでひとつのレコード（または行）が構成される。
　顧客表１２２は、顧客識別子１２２０と、顧客名１２２１を含んでひとつのレコード（または行）が構成される。
　本実施例では、顧客識別子と、発信元（電話ｆｒｏｍ１２０２）と、着信先（電話ｔｏ１２０３）から顧客間のエッジに相当するグラフ構造６００を顧客関係表５００Ａとして取得する。なお、上記通話データベースの履歴情報１２では、通話履歴表１２０と、電話管理表１２１と、顧客表１２２から顧客名毎の通話時間の総計などから通話料の算出を行うことができる。
　まず、表定義処理部３１０は、通話履歴表１２０の電話ｆｒｏｍ１２０２と電話ｔｏ１２０３の電話ＮＯをキーとして、発信元の顧客識別子と、着信先の顧客識別子を電話管理表１２１から取得する。また、各顧客識別子に対応する顧客名１２２１を顧客表１２２から取得する。
　次に、表定義処理部３１０は、通話履歴表１２０の電話ｆｒｏｍ１２０２を発信元の顧客識別子とした顧客ｆｒｏｍ５０１と、電話ｔｏ１２０３を着信先の顧客識別子とした顧客ｔｏ５０２と、時間１２０４を格納する時間５０３と、時刻１２０５を格納する時刻５０４と、からひとつのレコード（または行）を構成する顧客関係表５００Ａを生成する。
　次に、表定義処理部３１０は、生成した顧客関係表５００Ａについて、顧客ｆｒｏｍ５０１と顧客ｔｏ５０２の顧客識別子が顧客次元表４２０ｃに対応する定義５１０を設定する。
　＜スタースキーマ４００の生成＞
　次に、スタースキーマ４００を生成するデータの関連の一例を図５Ａ、図５Ｂに示す。図５Ａは、スタースキーマを生成する際のデータの関係を示す図である。図５Ｂは、スタースキーマの定義の一例を示す図である。
　図５ＡはデータベースＰＤ１の販売データベースから、図２に示した次元表４２０とファクト表４１０を生成する例を示す。この処理は、図１に示したグラフデータ分析部３０の、表定義処理部３１０で行われる。なお、本実施例では、ファクト表４１０として顧客売上履歴表４１０ａを生成する例を示す。
　表定義処理部３１０は、データベースＰＤ１の販売データベースから顧客売上履歴表４１０ａを生成する。顧客売上履歴表４１０ａは、販売された商品識別子４１１と、当該商品を購入した顧客識別子４１２と、当該商品が販売された地域コード４１３と、当該商品が販売された時期を格納する期間コード４１４と、販売された価格を格納する売価４１５と、販売された個数４１６とを含んでひとつのレコード（または行）が構成される。なお、本実施例では、顧客売上履歴表４１０ａの商品識別子４１１と、顧客識別子４１２と、地域コード４１３と、期間コード４１４とを複数の識別子として扱い、売価４１５と個数４１６を属性として扱う。
　次に、表定義処理部３１０は、顧客売上履歴表４１０ａの商品識別子４１１を主キーとする商品次元表４２０ａを販売データベースから生成する。商品次元表４２０ａは、主キーとなる、商品識別子４２１と商品名４２２を含んでひとつのレコード（または行）が構成される。そして、本実施例では、商品識別子４２１を顧客売上履歴表４１０ａの商品識別子４１１に関連付けられた識別子として扱い、商品名４２２を属性として扱う。
　次に、表定義処理部３１０は、顧客売上履歴表４１０ａの顧客識別子４１２を主キーとする顧客次元表４２０ｂを販売データベースから生成する。顧客次元表４２０ｃは、主キーとなる、顧客識別子４２５と顧客名４２６を含んでひとつのレコード（または行）が構成される。そして、本実施例では、顧客識別子４２５を顧客売上履歴表４１０ａの顧客識別子４１２に関連付けられた識別子として扱い、顧客名４２６を属性として扱う。
　次に、表定義処理部３１０は、顧客売上履歴表４１０ａの地域コード４１３を主キーとする地域次元表４２０ｄを販売データベースから生成する。地域次元表４２０ｄは、主キーとなる地域コード４２７と地域名４２８を含んでひとつのレコード（または行）が構成される。そして、本実施例では、地域コード４２７を顧客売上履歴表４１０ａの地域コード４１３に関連付けられた識別子として扱い、地域名４２８を属性として扱う。
　次に、表定義処理部３１０は、顧客売上履歴表４１０ａの期間コード４１４を主キーとする期間次元表４２０ｂを販売データベースから生成する。期間次元表４２０ｂは、主キーとなる期間コード４２３と属性としての期間名４２４を含んでひとつのレコード（または行）が構成される。そして、本実施例では、期間コード４２３を顧客売上履歴表４１０ａの期間コード４１４に関連付けられた識別子として扱い、期間名４２４を属性として扱う。
　図５Ｂは、スタースキーマ４００の定義５２０の一例である。表定義処理部３１０は、図５Ｂの定義５２０を読み込んで、図５Ａに示した、ファクト表４１０（顧客売上履歴表４１０ａ）と次元表４２０を生成する。
　＜グラフ構造の設定＞
　図６は、表定義処理部３１０が図５Ａに示すスタースキーマ４００を生成し、データベースＰＤ１の販売データベースのデータを取り込んだ状態を示す。
　ここで、顧客次元表４２０ｃは、顧客識別子４２５を主キーとすることから、図２に示したグラフ構造６００のノードと同一のデータで構成できることが分かる。一方、図４で示した顧客関係表５００Ａでは、顧客識別子（顧客ｆｒｏｍ５０１と顧客ｔｏ５０２）間の通話の方向性を顧客間の相関関係を示すエッジとして扱うことができる。
　そこで、本発明では、顧客次元表４２０ｃの顧客識別子４２５をノードとし、図４で示したように顧客間の通話履歴の相関関係を示す顧客関係表５００Ａの顧客ｆｒｏｍ５０１と顧客ｔｏ５０２をエッジとして用いることで、スタースキーマ４００の顧客次元表４２０ｃと顧客関係表５００Ａを組み合わせることで、グラフ構造６００として扱う。
　図７Ａは、顧客次元表４２０ｃと顧客関係表５００Ａの組み合わせをグラフ構造６００として扱う場合のデータの組み合わせを示す図である。図中太線で接続したスタースキーマ４００の顧客次元表４２０ｃの顧客識別子４２５をノードとし、顧客関係表５００Ａの顧客ｆｒｏｍ５０１と顧客ｔｏ５０２をエッジのＦｒｏｍ及びＴｏとする。
　これにより、スタースキーマ４００の顧客次元表４２０ｃをノードとし、顧客関係表５００Ａをエッジとしてグラフ構造６００’を構成することができる。これにより、関係表５００はグラフデータのノードを有すること無く、エッジのみを保持すれば良いので、スタースキーマ４００とグラフ構造６００を合わせたときのデータ量を削減できる、という効果がある。
　さらに、後述する問合せ処理では、図７Ａのグラフ構造６００’に対してグラフデータ分析を実施し、操作対象のファクト表４１０である顧客売上履歴表４１０ａのデータ量を絞り込むことで、高速にＯＬＡＰによるデータ分析を実現できる。
　図７Ｂは、顧客次元表４２０ｃと顧客関係表５００Ａの組み合せからグラフ構造６００をとして扱う場合の定義５３０の一例を示す図である。定義５３０は、ノードとなる顧客次元表４２０ｃを定義し、さらに、エッジとなる顧客関係表５００Ａを定義する例である。
　図８は、図７Ａのスタースキーマ４００と顧客関係表５００Ａに実際のデータをデータベースＰＤ１、ＰＤ２から取り込んだものである。グラフデータ分析部３０は、問合せを受け付けると、スタースキーマ４００の次元表４２０と顧客売上履歴表４１０ａと顧客関係表５００Ａから、顧客についてグラフ構造６００’を用いて絞り込みを行ってから分析を行うことができる。
　＜表定義処理部＞
　図９は、表定義処理部３１０で行われる処理の一例を示すフローチャートである。この処理は、グラフデータ分析装置１が問合せを受け付けたときに実行される。この表定義処理部３１０では、問合せで分析対象となるデータベースを定義する。つまり、表定義処理部３１０は、事柄や物の関係性を格納する関係表５００と、実世界のデータの意味を記述得る次元表４２０と、実世界のデータを一元的な時系列データとして格納する履歴表と、関係表５００と次元表４２０の関連を定義する。
　表定義処理部３１０は、問合せで指定された分析対象を識別する主キーと、当該キーに関連する１以上の属性を列とする複数の次元表４２０を定義する（Ｓ１）。この処理は、図５Ｂの「ＣＲＥＡＴＥ　ＴＡＢＬＥ　～次元表」に対応する。
　次に、表定義処理部３１０は、複数の次元表４２０の主キーを参照する複数の列で主キーを構成し、これら主キーに関連する１以上の属性を列とする履歴表を定義する（Ｓ２）。この処理は、図５Ｂの「ＣＲＥＡＴＥ　ＴＡＢＬＥ　顧客売上履歴表」に対応する。
　次に、表定義処理部３１０は、次元表４２０の主キーを参照する第１の列及び第２の列と、当該第１の列及び第２の列に関連する１以上の属性を列とする関係表を定義する（Ｓ３）。この処理は、図７Ｂの「ＣＲＥＡＴＥ　ＴＡＢＬＥ　顧客関係表」及び図４の定義５１０に対応する（Ｓ３）。
　次に、表定義処理部３１０は、次元表４２０の主キーを参照する関係表５００の第１の列及び第２の列と、関係表５００の主キーを関連付ける定義を行う。この処理は、図７Ｂの「ＣＲＥＡＴＥ　ＴＡＢＬＥ　顧客次元表」及び「ＣＲＥＡＴＥ　ＴＡＢＬＥ　顧客関係表」に対応する（Ｓ３）。この処理によって、図８のグラフ構造６００’が設定される。
　以上の処理によって、図７Ａに示したように、スタースキーマ４００と関係表５００及びグラフ構造６００’が定義される。
　＜データロード処理部＞
　図１０は、グラフデータ分析装置１のデータロード処理部３２０で行われる処理の一例を示すフローチャートである。この処理は、図９の処理が完了した後に実行される。あるいは、管理者などが入力装置６から実行を指示したときに行われる。
　データロード処理部３２０は、表定義処理部３１０が生成した分析対象の各次元表４２０にデータベース１０からデータをロードする（Ｓ１１）。
　次に、データロード処理部３２０は、表定義処理部３１０が生成した分析対象の顧客売上履歴表４１０ａ（ファクト表４１０）にデータベース１０からデータをロードする（Ｓ１２）。
　次に、データロード処理部３２０は、表定義処理部３１０が生成した分析対象の顧客売上履歴表４１０ａ（ファクト表４１０）にデータベース１０からデータをロードする（Ｓ１２）。
　データロード処理部３２０は、履歴情報１２から、次元表４２０の主キーを参照する列情報と、それらの列に関連する属性を、行として関係表５００にロードする（Ｓ１３）。
　以上の処理により、スタースキーマ４００の次元表４２０、ファクト表４１０と、次元表４２０を参照する関係表５００にデータベース１０のデータが取り込まれる。この結果、例えば、図８で示すようにスタースキーマ４００と関係表５００にデータが格納される。
　＜問合せ処理部＞
　次に、グラフデータ分析装置１の問合せ処理部３３０で行われる処理の一例を示す。図１１は、商品と顧客に関する統合分析の問合せ処理の一例を示す図である。この処理は、グラフデータ分析装置１がネットワークインタフェース５または入力装置６から問合せを受け付けたときに実行される。
　図１１の例では、顧客次元表４２０ｃ（第１の次元表）に顧客識別子４２５が「Ａ」～「Ｕ」のデータが含まれ、グラフ構造６００’のノードを構成する。顧客関係表５００Ａも顧客ｆｒｏｍ５０１と顧客ｔｏに顧客識別子が「Ａ」～「Ｕ」のデータが含まれている。
　問合せ処理部３３０では、問い合わせの内容に応じて、顧客識別子（または顧客名）による絞り込みを行う。例えば、地域コード４１３＝ｘ、期間コード４１４＝ｙで売価４１５の合計が１位の顧客に関係する顧客について分析を行う例を示す。
　まず、問合せ処理部３３０は、地域コード４１３、期間コード４１４が問合せの条件を満たす顧客識別子４１２毎に売価４１５の合計を算出し、この合計が最大の顧客識別子＝「Ａ」を抽出する。
　次に、問合せ処理部３３０は、顧客識別子４２５＝「Ａ」に関係する顧客識別子を、図１２で後述するように、グラフデータ分析によってグラフ構造６００’から抽出する。この結果、顧客識別子＝「Ａ」～「Ｄ」の顧客が抽出され、これらの顧客の相関関係が図３Ｂのグラフ表現６００Ｂで示すことが出力される（図中（１））。
　ここで問合せ処理部３３０は、顧客識別子４２５を「Ａ」～「Ｄ」に絞り込んだ顧客次元表４２０ｃ’を第２の次元表として以降の分析処理に用いる。すなわち、以降のスタースキーマ４００の分析では、商品次元表４２０ａ、期間次元表４２０ｂ、地域次元表４２０ｄに、第１の次元表を絞り込んだ第２の次元表である顧客次元表４２０ｃ’を顧客売上履歴表４１０ａ（ファクト表４１０）に関連付けて問合せを実行する。
　これにより、グラフ構造６００’に対応する次元表４２０Ｃ’（第２の次元表）のデータ量を絞り込んでからＯＬＡＰの操作などを行うことができ、少ないデータ量で高速に処理を実現できる。
　図１２は、問合せ処理部３３０のグラフデータ分析で再帰的な問合せ処理の一例を示す図である。この処理は、近接中心性（中心性解析）を再帰問合せで求める例で、図３Ｂのグラフ表現６００Ａの状態から、顧客識別子＝「Ａ」に関係する顧客を、グラフ表現６００Ｂとして抽出する再帰処理を示す。つまり、図１１の第１の次元表４２０ｃと顧客関係表５００Ａのグラフ構造６００’から第２の次元表４２０ｃ’の顧客識別子４２５をグラフデータ分析で抽出する処理の一例を示す。
　まず、図１２のＱ１では、問合せ処理部３３０が、顧客関係表５００Ａの顧客ｆｒｏｍ５０１、顧客ｔｏ５０２について、特定のノードから全ノードへの経路と距離を算出する処理を示す。つまり、図４の顧客関係表５００Ａの顧客ｆｒｏｍ５０１と、顧客ｔｏ５０２の距離ｄｉｓｔをそれぞれ算出する。ここで、顧客ｆｒｏｍ５０１と、顧客ｔｏ５０２の距離ｄｉｓｔは、図４で示したように、通話の時間５０３の積算値や通話を行った時間帯などから親密度を求め、親密度が高いほど距離ｄｉｓｔは近い値となる。なお、人間の距離については、上述の親密度の他、周知ないし公知の手法を利用すれば良い。
　図１２のＱ２では、問合せ処理部３３０が、顧客関係表５００Ａで特定のノードから全ノードへの最短経路（ｍｉｎＰａｔｈ）を求める処理である。この処理では、あるノードが関係する他のノードまでの経路のうち最短の経路を抽出する。
　次に、Ｑ３では、問合せ処理部３３０が、最短経路の距離の合計を計算し、距離の合計の逆数を計算する。次に、Ｑ４では、問合せ処理部３３０が、最短経路の距離の合計の逆数が最大のノード（例えば「Ａ」）を近接中心性と判定する。
　次に、図１２のＱ５では、問合せ処理部３３０が、最短経路の距離の合計の逆数が最大となるノードに隣接するノードを求める。この結果、図３Ｂで示すようなグラフ表現６００Ｂが得られる。
　以上より、問合せ処理部３３０は、図３Ｂのグラフ表現６００Ｂで示すように、グラフ表現６００Ｂの中心となる顧客識別子＝「Ａ」から所定の範囲の顧客識別子＝「Ｂ」～「Ｄ」をグラフデータ分析によって抽出することができる。
　図１３Ａ、図１３Ｂ、図１３Ｃは、スタースキーマ４００の問合せ処理の一例を示す。図１３Ａは、地域名４２８＝東京で、顧客名４２６及び期間名４２４毎の売上総計（売価×個数）を求める例である。
　この例では、問合せＱ０２で、スタースキーマ４００の次元表４２０ｂ、４２０ｃ、４２０ｄの直積集合から分析結果が得られる。この例では、地域名４２８が東京で、期間名が１２年第２四半期で、売価４１５の合計を顧客名４２６毎に求める場合、地域コード４２７＝ＡＡＡで、期間コードと顧客識別子４２５毎に、顧客が購入した商品の売価の合計が得られる。この問合せＱ０２の結果が、図１３Ｂの問合せ結果Ａ０２として出力される。
　図１４は、問合せ処理部３３０で行われる処理の一例を示すフローチャートである。この処理では、次元表４２０及び顧客関係表５００Ａからクラスタ性と、距離近似性の再帰問合せから第２の次元表を作成し、作成した第２の次元表を含む複数の次元表４２０及びファクト表４１０とを関連付けジョイン及び集約の問合せから結果を得る例である。
　まず、問合せ処理部３３０は、次元表４２０及び関係表５００に、図１２で示したような再帰問合せを実行し、中間結果として第２の次元表（例えば、図１１の顧客次元表４２０ｃ’）を作成する（Ｓ２１）。
　次に、問合せ処理部３３０は、中間結果の次元表を含む複数の次元表４２０及び顧客売上履歴表４１０ａにジョイン及び集約の問合せを実行する（Ｓ２２）。そして、実行結果を出力する（Ｓ２３）。
　例えば、ステップＳ２１では、図１１で示したように、グラフ構造６００’を構成可能な顧客次元表４２０ｃと顧客関係表５００Ａから、図１２に示した近接中心性（中心性解析）を再帰問合せによって算出し、中心性の高い顧客としてグラフ表現６００Ｂに対応する第２の次元表（顧客次元表）４２０ｃ’を算出する。
　この結果、図１１の第２の次元表４２０ｃ’では、顧客識別子＝Ａを中心として、顧客識別子＝Ａと距離の近い顧客識別子＝Ｂ～Ｄが抽出される。
　次に、ステップＳ２２では、例えば、図１３Ａで示したように、第２の次元表４２０ｃ’の顧客名毎の売価の合計を期間名毎に求めると、ステップＳ２３で、顧客識別子＝Ａ～Ｄの顧客名毎の売価の合計が出力される。
　この例では、問合せ処理部３３０は、受け付けた問合せから、ある顧客の集団を含む顧客次元表４２０ｃと顧客関係表５００Ａから第２の次元表４２０ｃ’を算出し、顧客の集団内で中心性の高い顧客「Ａ」と、顧客「Ａ」と距離の近い顧客「Ｂ」～「Ｄ」について、顧客売上履歴表４１０ａから商品の購入状況や購入動向を迅速に抽出することが可能となる。上記問合せの出力より、商品を購入した顧客の集団から中心性の高い顧客を抽出することで、新たな商品の紹介や広告を効率よく行うことができる。例えば、顧客「Ａ」にある商品の紹介を行うことで、顧客「Ａ」と距離の近い顧客「Ｂ」～「Ｄ」に口コミなどで新たな商品の紹介を伝えることが可能となる。
　図１５は、グラフデータ分析装置１をセントラルデータウェアハウス（ＣＤＷＨ）に採用した例を示す。グラフデータ分析装置１の構成は、上記図１と同様である。この例では、グラフデータ分析装置１はＥＴＬ（Ｅxtract、Ｔransform、Ｌoad）ツールでデータベースＰＤ１～ＰＤ４を取得する。そして、問合せを実行してＣＵＢＥ７００やグラフデータ（部分グラフなど）を出力する。グラフデータ分析装置１の出力について、ＯＬＡＰによる分析やグラフデータ分析を行う例を示している。なお、ＥＴＬツールは、外部の計算機で実行すれば良いが、グラフデータ分析装置１で実行しても良い。
　以上のように、第１の実施例では、次元表の一部をグラフ構造６００’の一部とすることで、データを重複して保持するのを防いで、データ量を削減することができる。また、グラフデータ分析した結果、次元表のデータ件数が削減され、さらに直積計算及びグラフ処理のデータ処理量も削減される。
　特に、ファクト表４１０を絞り込む対象の次元表４２０が、グラフ構造６００’で表現可能な場合には、グラフデータ分析によって迅速に次元表４２０を絞り込むことが可能となるので、後のＯＬＡＰの操作対象のデータ量が大幅に削減され、分析に要する時間を短縮できるのである。
　したがって、ファクト表４１０を絞り込む対象の次元表４２０が、グラフ構造６００’で表現可能な場合には、グラフデータ分析によって迅速にファクト表４１０を絞り込むことが可能となるので、後のＯＬＡＰの操作対象のデータ量が大幅に削減され、分析に要する時間を短縮できるのである。
　図１６～図１９Ｂは第２の実施例を示し、第２の次元表を表構造のスタースキーマ４００から生成し、第２の次元表からグラフデータを出力するようにしたもので、その他の構成は前記第１の実施例と同様である。
　第２の実施例では、複数の次元表４２０とファクト表４１０（顧客売上履歴表４１０ａ）からＯＬＡＰ分析などにより、第２の次元表（顧客次元表４２０ｃ’）を生成する。そして、第２の次元表（顧客次元表４２０ｃ’）からグラフデータを出力する。
　図１６は、スタースキーマ４００から第２の次元表（顧客次元表４２０ｃ’）を生成し、その後、グラフ表現６００Ｂを出力する際のデータの関係を示す図である。
　第２の実施例では、図１６で示すように、地域名４２８＝東京で、売上総計（売価４１５×個数４１６）が最大の顧客識別子４１２を求める（１）。そして、当該顧客識別子４１２に関係する顧客のグラフ表現（部分グラフ）６００Ｂを、顧客関係表５００Ａを用いて抽出する（２）。
　図１７は、スタースキーマ４００から第２の次元表を生成する際のデータの関係を示す図である。グラフデータ分析装置１の問合せ処理部３３０は、地域名４２８＝東京で、売上総計（売価４１５×個数４１６）が最大の顧客識別子４１２＝「Ａ」を顧客売上履歴表４１０ａと各次元表４２０から算出する。この結果、第２の次元表である顧客次元表４２０ｃ’は、顧客識別子４２５＝「Ａ」のみの表が生成される。
　図１８は、スタースキーマ４００から第２の次元表を生成する際の問合せの一例を示す図である。
　上述のように、問合せ処理部３３０は、問合せＱ０３を読み込んで、地域名４２８＝東京で、売上総計（売価４１５×個数４１６）が最大の顧客識別子４１２＝「Ａ」を顧客売上履歴表４１０ａと各次元表４２０から算出し、上述のように第２の次元表である顧客次元表４２０ｃ’を生成する。
　図１９Ａは、第２の次元表（顧客次元表４２０ｃ’）からグラフ表現６００Ｂを生成する際の問合せの一例を示す図である。図１９Ｂは、第２の次元表（顧客次元表４２０ｃ’）からグラフ表現６００Ｂを生成する際のデータの関連を示す図である。
　問合せ処理部３３０は、図１９Ａの問合せＱ０４を読み込んで、第２の次元表（顧客次元表４２０ｃ’）に関係する顧客ｔｏ５０２を顧客関係表５００Ａから抽出する。第２の次元表４２０ｃ’の顧客識別子４２５＝「Ａ」に対応する顧客関係表５００Ａの顧客ｔｏ５０２は、「Ｂ」、「Ｃ」、「Ｄ」であるので、グラフ表現６００Ｂが出力される。
　以上のように、第２の実施例においても、第２の次元表でグラフデータを生成するノードのデータ量を削減できる。そして、第１の実施例と同様に、次元表の一部をグラフ構造の一部とすることで、データを重複して保持するのを防いで、データ量を削減することができる。また、表構造のデータを分析した結果、次元表のデータ件数が削減され、さらにグラフデータ処理のデータ量も削減される。
　なお、本発明において説明したグラフデータ分析装置１等の構成、各処理部及び処理手段等は、それらの一部又は全部を、専用のハードウェアによって実現してもよい。
　また、本実施例で例示した種々のソフトウェアは、電磁的、電子的及び光学式等の種々の記録媒体（例えば、非一時的な記憶媒体）に格納可能であり、インターネット等の通信網を通じて、コンピュータにダウンロード可能である。
　また、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明をわかりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。

Claims (20)

  1. 　記憶装置を備えたデータ分析装置におけるデータを分析するデータ分析方法であって、
    　前記データ分析装置が、分析対象のデータを識別する第１の識別子と、当該第１の識別子に対応する属性を含む次元表を複数設定する第１のステップと、
    　前記データ分析装置が、前記複数の次元表の第１の識別子にそれぞれ対応付けられた第２の識別子を有し、これら第２の識別子に対応する属性を含む履歴表を設定する第２のステップと、
    　前記データ分析装置が、前記第１の識別子と第２の識別子に関連する属性を格納する関係表を設定し、前記複数の次元表は、前記第１の識別子と第２の識別子に関連する属性を介して前記関係表に関連付けられた第１の次元表を含む第３のステップと、
    　前記データ分析装置が、前記次元表の第１の識別子を参照する前記第１の識別子と第２の識別子に関連する属性を関連付ける第４のステップと、
    　前記データ分析装置が、前記関係表と前記第１の次元表についての問合せの処理を行い、当該問合せの処理の結果、第２の次元表を生成する第５のステップと、
    を含むことを特徴とするデータ分析方法。
  2. 　請求項１に記載のデータ分析方法であって、
    　前記データ分析装置が、前記生成された第２の次元表と前記複数の次元表と関連する履歴表とが関連付けられた問合せを実行する第６のステップを含むことを特徴とするデータ分析方法。
  3. 　請求項１に記載のデータ分析方法であって、
    　前記第５のステップは、
    　前記データ分析装置が、前記複数の次元表と関連する前記履歴表とが関連付けられた問合せを実行し、当該問合せの実行の結果、第２の次元表を生成し、前記生成された第２の次元表と前記関係表を関連付けられた問合せを実行する第７のステップを含むことを特徴とするデータ分析方法。
  4. 　請求項１に記載のデータ分析方法であって、
    　前記第５のステップは、
    　前記関係表と前記第１の次元表とが組み合わせられた問合せは、前記関係表と前記第１の次元表で構成されるグラフ構造から特定された属性を指定することを特徴とするデータ分析方法。
  5. 　請求項２に記載のデータ分析方法であって、
    　前記第６のステップは
    　前記第２の次元表と前記関係表とが関連付けられた問合せは、前記第２の次元表の属性を指定することを特徴とするデータ分析方法。
  6. 　請求項２に記載のデータ分析方法であって、
    　前記第６のステップは、
    　前記第２の次元表と前記複数の次元表と関連する履歴表とが関連付けられた問合せを、前記属性と複数の属性値の範囲を指定することを特徴とするデータ分析方法。
  7. 　請求項３に記載のデータ分析方法であって、
    　前記第７のステップは、
    　前記第２の次元表と前記関係表とが関連付けられた問合せは、前記第２の次元表の属性を指定することを特徴とするデータ分析方法。
  8. 　請求項３に記載のデータ分析方法であって、
    　前記第７のステップは、
    　前記第２の次元表と前記複数の次元表と関連する履歴表とが関連付けられた問合せを、前記属性と複数の属性値の範囲を指定することを特徴とするデータ分析方法。
  9. 　プロセッサと記憶装置を備えて、データを分析するデータ分析装置であって、
    　分析対象のデータを識別する第１の識別子と、当該第１の識別子に対応する属性を含む次元表を複数設定し、前記複数の次元表の第１の識別子にそれぞれ対応付けられた第２の識別子を有し、これら第２の識別子に対応する属性を含む履歴表を設定し、前記第１の識別子と第２の識別子に関連する属性を格納する関係表を設定し、前記複数の次元表は、前記第１の識別子と第２の識別子に関連する属性を介して前記関係表に関連付けられた第１の次元表を含み、前記次元表の第１の識別子を参照する前記第１の識別子と第２の識別子に関連する属性を関連付ける表定義処理部と、
    　前記複数の次元表と、前記履歴表及び前記関係表にそれぞれデータを取り込むデータロード部と、
    　問合せを受け付けて、前記次元表と履歴表及び関係表について問合せを実行し、当該問合せの実行の結果、第２の次元表を生成する問合せ処理部と、
    を備えたことを特徴とするデータ分析装置。
  10. 　請求項９に記載のデータ分析装置であって、
    　前記問合せ処理部は、
    　前記生成された第２の次元表と前記複数の次元表と関連する履歴表とが関連付けられた問合せを実行することを特徴とするデータ分析装置。
  11. 　請求項９に記載のデータ分析装置であって、
    　前記問合せ処理部は、
    　前記複数の次元表と関連する前記履歴表とが関連付けられた問合せを実行し、当該問合せの実行の結果、第２の次元表を生成し、前記生成された第２の次元表と前記関係表を関連付けた問合せを実行することを特徴とするデータ分析装置。
  12. 　請求項９に記載のデータ分析装置であって、
    　前記問合せ処理部は、
    　前記関係表と前記第１の次元表とが組み合わせられた問合せは、前記関係表と前記第１の次元表で構成されるグラフ構造から特定された属性を指定することを特徴とするデータ分析装置。
  13. 　請求項１０に記載のデータ分析装置であって、
    　前記問合せ処理部は、
    　前記第２の次元表と前記関係表とが関連付けられた問合せは、前記第２の次元表の属性を指定することを特徴とするデータ分析装置。
  14. 　請求項１０に記載のデータ分析装置であって、
    　前記問合せ処理部は、
    　前記第２の次元表と前記複数の次元表と関連する履歴表を関連付けた問合せを、前記属性と複数の属性値の範囲を指定することを特徴とするデータ分析装置。
  15. 　プロセッサと記憶装置を備えた計算機でデータを分析する処理プログラムを格納した非一時的な記憶媒体であって、
    　分析対象のデータを識別する第１の識別子と、当該第１の識別子に対応する属性を含む次元表を複数設定する第１の手順と、
    　前記複数の次元表の第１の識別子にそれぞれ対応付けられた第２の識別子を有し、これら第２の識別子に対応する属性を含む履歴表を設定する第２の手順と、
    　前記第１の識別子と第２の識別子に関連する属性を格納する関係表を設定し、前記複数の次元表は、前記第１の識別子と第２の識別子に関連する属性を介して前記関係表に関連付けられた第１の次元表を含む第３の手順と、
    　前記次元表の第１の識別子を参照する前記第１の識別子と第２の識別子に関連する属性を関連付ける第４の手順と、
    　前記関係表と前記第１の次元表についての問合せに基づいた処理を行い、当該問合せの処理の結果、第２の次元表を生成する第５の手順と、
    を前記計算機に実行させることを特徴とする処理プログラムを格納した非一時的な記憶媒体。
  16. 　請求項１５に記載の処理プログラムを格納した非一時的な記憶媒体であって、
    　前記生成された第２の次元表と前記複数の次元表と関連する履歴表を関連付けた問合せを実行する第６の手順を含むことを特徴とする処理プログラムを格納した非一時的な記憶媒体。
  17. 　請求項１５に記載の処理プログラムを格納した非一時的な記憶媒体であって、
    　前記第５の手順は、
    　前記複数の次元表と関連する前記履歴表とが関連付けられた問合せを実行し、当該問合せの結果、第２の次元表を生成し、前記生成された第２の次元表と前記関係表を関連付けた問合せを実行する第７の手順を含むことを特徴とする処理プログラムを格納した非一時的な記憶媒体。
  18. 　請求項１５に記載の処理プログラムを格納した非一時的な記憶媒体であって、
    　前記第５の手順は、
    　前記関係表と前記第１の次元表とが組み合わせられた問合せは、前記関係表と前記第１の次元表で構成されるグラフ構造から特定された属性を指定することを特徴とする処理プログラムを格納した非一時的な記憶媒体。
  19. 　請求項１６に記載の処理プログラムを格納した非一時的な記憶媒体であって、
    　前記第６の手順は
    　前記第２の次元表と前記関係表を関連付けられた問合せは、前記第２の次元表の属性を指定することを特徴とする処理プログラムを格納した非一時的な記憶媒体。
  20. 　請求項１６に記載の処理プログラムを格納した非一時的な記憶媒体であって、
    　前記第６の手順は、
    　前記第２の次元表と前記複数の次元表と関連する履歴表を関連付けられた問合せを、前記属性と複数の属性値の範囲を指定することを特徴とする処理プログラムを格納した非一時的な記憶媒体。
PCT/JP2012/073734 2012-09-14 2012-09-14 データ分析方法、データ分析装置及びその処理プログラムを格納した記憶媒体 WO2014041699A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US14/402,838 US9892187B2 (en) 2012-09-14 2012-09-14 Data analysis method, data analysis device, and storage medium storing processing program for same
JP2014535341A JP5784239B2 (ja) 2012-09-14 2012-09-14 データ分析方法、データ分析装置及びその処理プログラムを格納した記憶媒体
PCT/JP2012/073734 WO2014041699A1 (ja) 2012-09-14 2012-09-14 データ分析方法、データ分析装置及びその処理プログラムを格納した記憶媒体

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2012/073734 WO2014041699A1 (ja) 2012-09-14 2012-09-14 データ分析方法、データ分析装置及びその処理プログラムを格納した記憶媒体

Publications (1)

Publication Number Publication Date
WO2014041699A1 true WO2014041699A1 (ja) 2014-03-20

Family

ID=50277851

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/073734 WO2014041699A1 (ja) 2012-09-14 2012-09-14 データ分析方法、データ分析装置及びその処理プログラムを格納した記憶媒体

Country Status (3)

Country Link
US (1) US9892187B2 (ja)
JP (1) JP5784239B2 (ja)
WO (1) WO2014041699A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018536909A (ja) * 2015-10-23 2018-12-13 オラクル・インターナショナル・コーポレイション 表形式データから、多次元データベース環境に使用されるキューブスキーマを自動的に推論するためのシステムおよび方法
JP2021099545A (ja) * 2019-12-19 2021-07-01 エヌ・ティ・ティ・コムウェア株式会社 情報検索装置、情報検索方法、およびプログラム
JP7460363B2 (ja) 2019-12-19 2024-04-02 エヌ・ティ・ティ・コムウェア株式会社 情報検索装置、情報検索方法、およびプログラム

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150046203A1 (en) * 2013-08-06 2015-02-12 International Business Machines Corporation Determining Recommendations In Data Analysis
US10521455B2 (en) * 2014-03-18 2019-12-31 Nanobi Data And Analytics Private Limited System and method for a neural metadata framework
US10733155B2 (en) 2015-10-23 2020-08-04 Oracle International Corporation System and method for extracting a star schema from tabular data for use in a multidimensional database environment
US10121000B1 (en) * 2016-06-28 2018-11-06 Fireeye, Inc. System and method to detect premium attacks on electronic networks and electronic devices
JP6736450B2 (ja) * 2016-10-25 2020-08-05 株式会社日立製作所 データ分析支援装置及びデータ分析支援システム
US11630815B2 (en) * 2017-03-21 2023-04-18 Choral Systems, Llc Data analysis and visualization using structured data tables and nodal networks
US11328213B2 (en) 2017-03-21 2022-05-10 Choral Systems, Llc Data analysis and visualization using structured data tables and nodal networks
US11334802B2 (en) 2017-03-21 2022-05-17 Choral Systems, Llc Data analysis and visualization using structured data tables and nodal networks
US11657028B2 (en) 2017-03-21 2023-05-23 Choral Systems, Llc Data analysis and visualization using structured data tables and nodal networks
CN110413708B (zh) * 2019-07-23 2022-06-21 杭州城市大数据运营有限公司 一种面向业务术语的数据分析系统
CN111291024B (zh) * 2020-02-19 2023-11-24 京东方科技集团股份有限公司 数据处理方法、装置、电子设备及存储介质
US11269912B2 (en) 2020-07-14 2022-03-08 Sap Se Parallel load operations for ETL with unified post-processing
CN112069021B (zh) * 2020-08-21 2024-02-20 北京五八信息技术有限公司 流量数据的存储方法、装置、电子设备和存储介质
CN113782162A (zh) * 2021-03-26 2021-12-10 北京京东拓先科技有限公司 一种问诊费配置的方法、装置、设备及存储介质
CN114840583B (zh) * 2022-06-24 2022-09-20 国网浙江省电力有限公司杭州供电公司 基于块数据构建的全景指标数据分析处理方法及系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006513474A (ja) * 2003-01-13 2006-04-20 インターナショナル・ビジネス・マシーンズ・コーポレーション リレーショナルｏｌａｐエンジンのための多次元計算を記述する方法、システム、およびプログラム
JP2008544382A (ja) * 2005-06-24 2008-12-04 オービタル・テクノロジーズ・インコーポレーテッド 関係データベースクエリと多次元データベースクエリとを変換するシステムおよび方法

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6115712A (en) 1996-07-12 2000-09-05 International Business Machines Corporation Mechanism for combining data analysis algorithms with databases on the internet
US6377943B1 (en) * 1999-01-20 2002-04-23 Oracle Corp. Initial ordering of tables for database queries
US20020029207A1 (en) * 2000-02-28 2002-03-07 Hyperroll, Inc. Data aggregation server for managing a multi-dimensional database and database management system having data aggregation server integrated therein
US6976015B2 (en) * 2001-11-07 2005-12-13 Hyperion Solutions Corporation Method for extracting data from a relational database using a reduced query
WO2003081376A2 (en) 2002-03-20 2003-10-02 Catalina Marketing International Inc. Targeted incentives based upon predicted behavior
US9218409B2 (en) * 2002-06-04 2015-12-22 Sap Se Method for generating and using a reusable custom-defined nestable compound data type as database qualifiers
US7287022B2 (en) * 2002-07-19 2007-10-23 Microsoft Corporation System and method for analytically modeling data organized according to related attributes
US8543566B2 (en) * 2003-09-23 2013-09-24 Salesforce.Com, Inc. System and methods of improving a multi-tenant database query using contextual knowledge about non-homogeneously distributed tenant data
US8224872B2 (en) * 2004-06-25 2012-07-17 International Business Machines Corporation Automated data model extension through data crawler approach
US7949628B1 (en) * 2005-12-29 2011-05-24 United Services Automobile Association (Usaa) Information technology configuration management
US7856431B2 (en) * 2006-10-24 2010-12-21 Merced Systems, Inc. Reporting on facts relative to a specified dimensional coordinate constraint
US8655918B2 (en) * 2007-10-26 2014-02-18 International Business Machines Corporation System and method of transforming data for use in data analysis tools
JP4980395B2 (ja) 2009-06-16 2012-07-18 株式会社日立製作所 データ分析システム及び方法
CN102207940B (zh) * 2010-03-31 2014-11-05 国际商业机器公司 用于验证数据的方法和系统
US8856085B2 (en) * 2011-07-19 2014-10-07 International Business Machines Corporation Automatic consistent sampling for data analysis

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006513474A (ja) * 2003-01-13 2006-04-20 インターナショナル・ビジネス・マシーンズ・コーポレーション リレーショナルｏｌａｐエンジンのための多次元計算を記述する方法、システム、およびプログラム
JP2008544382A (ja) * 2005-06-24 2008-12-04 オービタル・テクノロジーズ・インコーポレーテッド 関係データベースクエリと多次元データベースクエリとを変換するシステムおよび方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KAZUYA SHIMIZU: "Creating data warehouses based on multidimensional models", PROVISION, vol. 8, no. 4, 29 October 2001 (2001-10-29), pages 74 - 83 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018536909A (ja) * 2015-10-23 2018-12-13 オラクル・インターナショナル・コーポレイション 表形式データから、多次元データベース環境に使用されるキューブスキーマを自動的に推論するためのシステムおよび方法
JP2021099545A (ja) * 2019-12-19 2021-07-01 エヌ・ティ・ティ・コムウェア株式会社 情報検索装置、情報検索方法、およびプログラム
JP7460363B2 (ja) 2019-12-19 2024-04-02 エヌ・ティ・ティ・コムウェア株式会社 情報検索装置、情報検索方法、およびプログラム

Also Published As

Publication number Publication date
JPWO2014041699A1 (ja) 2016-08-12
JP5784239B2 (ja) 2015-09-24
US9892187B2 (en) 2018-02-13
US20150100543A1 (en) 2015-04-09

Similar Documents

Publication Publication Date Title
JP5784239B2 (ja) データ分析方法、データ分析装置及びその処理プログラムを格納した記憶媒体
JP6744854B2 (ja) データ記憶方法、データ照会方法、およびそれらの装置
Abelló et al. YAM2: a multidimensional conceptual model extending UML
US8019783B2 (en) Search interface for finding data items of interest from a database system
US9965531B2 (en) Data storage extract, transform and load operations for entity and time-based record generation
US20160173122A1 (en) System That Reconfigures Usage of a Storage Device and Method Thereof
US20080222634A1 (en) Parallel processing for etl processes
US10878476B2 (en) Assortment optimization
US10579589B2 (en) Data filtering
US20110208691A1 (en) Accessing Large Collection Object Tables in a Database
JP2015528593A (ja) 電子商取引プラットフォームにおける情報を検索するための方法及び装置
CN110019754A (zh) 一种知识库的建立方法、装置及设备
WO2017203672A1 (ja) アイテム推奨方法、アイテム推奨プログラムおよびアイテム推奨装置
US20120124110A1 (en) Database, management server, and management program
CN113287100A (zh) 用于生成内存表格模型数据库的系统和方法
JP5771476B2 (ja) データ管理システム及びデータ管理方法
US20150302429A1 (en) Report generation system and method
US20190213613A1 (en) Segmenting market data
US20140101154A1 (en) Simplifying grouping of data items stored in a database
JP3922221B2 (ja) 多次元データ集計処理装置及び多次元データ集計処理プログラム
JP6716919B2 (ja) 情報抽出装置、抽出方法、および、抽出プログラム
JP5767177B2 (ja) Ｉｃｔソリューション環境影響評価システムおよび方法
JP5600127B2 (ja) 情報集計システム
JP2019159645A (ja) データ解析支援システムおよび方法
JP7147258B2 (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: 12884634

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2014535341

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 14402838

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12884634

Country of ref document: EP

Kind code of ref document: A1