JP7119411B2 - DATABASE DEVICE, DATA MANAGEMENT METHOD AND COMPUTER PROGRAM - Google Patents

Description

The present disclosure relates to a database device and the like.

Data management systems such as databases are used to manage various data. In relation to databases, for example, the following techniques are known.

For example, in Patent Document 1, in a database that includes a plurality of tables, columns are selected from each table to identify column pairs, and one column in the column pair is a foreign key of the other column. A technique for estimating is described. In Patent Document 2, when executing data mining using data accumulated in a database, access processing to the database is analyzed, and a combination of columns related to the same atomic logical work unit is generated as an analysis target. technology is described. Patent Literature 3 describes a technique for identifying useful columns for a preset rule by assigning scores to the positions of appearance of columns in a query statement to a database and statistically processing the scores.

JP 2014-186488 A JP 2013-125429 A Japanese Patent No. 3006525

Various data may be stored in the database, and new knowledge may be obtained by combining the data registered in the database. On the other hand, when a plurality of users store data in the database, it may be difficult for each user to grasp the entirety of the data stored in the database and the structure of the data. In this case, for example, there is a problem that it is not easy for the user to perform data analysis using data registered in the database or a combination thereof.

On the other hand, the techniques described in Patent Literatures 1 and 2 are techniques intended to identify relationships between data by analyzing some program that processes access to a database. It cannot be applied to situations where such a program is not given in advance. In addition, the technology described in Patent Document 3 is a technology intended to identify a column as domain knowledge based on the position of the column included in the query to the database, and is not a technology that can solve the above problem. .

The technology according to the present disclosure has been developed in view of the circumstances as described above. That is, one of the objects of the present disclosure is to provide a technology that enables users to perform data analysis more efficiently.

In order to achieve the above object, a database device according to one aspect of the present disclosure is configured as follows. That is, a database device according to an aspect of the present disclosure includes an inquiry processing unit that receives an inquiry about a data storage unit that has a table that stores data, and a tendency of access to the table related to the inquiry received by the inquiry processing unit. Based on a trend storage unit that stores models, a table related to other queries received by the query processing unit, and models stored in the trend storage unit, an executable operation related to the other query is performed. and a proposing trend determination unit.

A data management method according to another aspect of the present disclosure receives a query about a database having a table that stores data, stores a model representing the trend of access to a table related to the received query, and responds to another query. Suggesting actions that can be performed in relation to the other query based on the relevant tables and the stored model.

In addition, the same object is provided by a database device having the above configuration, a computer program (data management program) for realizing the data management method, etc. by a computer, and a computer-readable recording medium storing the computer program. is also achieved.

That is, a data management program according to still another aspect of the present disclosure stores a query process for receiving a query about a database having a table storing data, and a model representing the tendency of access to the table related to the received query. a computer functioning as a database device, performing storage processing to store data, and trend judgment processing to propose executable operations in relation to other queries based on tables related to other queries and stored models. to execute. Further, the computer program described above may be recorded on a recording medium according to one aspect of the present disclosure.

The present disclosure allows users to perform data analysis more efficiently.

1 is a block diagram illustrating a functional configuration of a database device according to a first embodiment of the present disclosure; FIG. FIG. 2 is a flowchart (Part 1) illustrating the operation of the database device according to the first embodiment of the present disclosure; FIG. 3 is a flowchart (part 2) illustrating the operation of the database device according to the first embodiment of the present disclosure; FIG. 4 is an explanatory diagram (part 1) showing a specific example of the operation of processing an inquiry by the database device according to the first embodiment of the present disclosure; FIG. 5 is an explanatory diagram (part 2) showing a specific example of the operation of processing an inquiry by the database device according to the first embodiment of the present disclosure; FIG. 6 is an explanatory diagram illustrating suggested information presented to a user by the database device according to the first embodiment of the present disclosure. FIG. 7 is a block diagram illustrating the functional configuration of the database system according to the second embodiment of the present disclosure; FIG. 8 is an explanatory diagram illustrating the configuration of a hardware device that can implement each embodiment according to the present disclosure.

<Overview of Embodiment>
Prior to detailed description of each embodiment, technical considerations and the like in the present disclosure will be described.

As symbolized by the term IoT (Internet of Things), many devices have come to be connected to communication networks. Typically, such devices are provided with various sensors (eg, temperature, humidity, vibration, weight, occupancy sensors, etc.) from which data can be collected. These sensors, for example, periodically collect data and send it over a communication network to a data center. In the data center, by storing the collected data in a database, the data is accumulated for later use. A data center is, for example, a system that accumulates and manages various data using a database (or a physical or virtual facility in which such a system operates).

Such devices are expected to increase in the future. As the number of devices increases, it is expected that the amount of collected data will also increase, and the number of representation formats that represent that data will also increase. For example, it is assumed that the temperature expression format (for example, Fahrenheit or Celsius) varies from sensor to sensor depending on the sensor vendor and the purpose of use of the sensor. Similarly, for example, a situation is assumed in which units of kg, units of mg, etc. are used as the expression format for weight. In other words, even sensor data related to the same measurement object may be expressed in different formats.

In addition, when utilizing such sensor data, the sensor data may be combined with other data. As a specific example, a store that sells fresh food can combine temperature sensor data and sales data to analyze top-selling products for each temperature, and purchase based on weather forecasts to reduce sales loss due to shortages. and to minimize excess inventory.

As in the example above, we collect data from various data sources (e.g., information sources such as sensors and existing system data) due to the increase in devices equipped with sensors and the wide range of needs for analysis of collected data. A database (database for analysis) has been constructed as a foundation for analysis based on

With regard to such an analysis database, (i) users of the database may not necessarily understand all the data accumulated, and (ii) the expression format of the data accumulated in the database is unified. There is a tendency not to be

As a specific example of (i) above, for example, multiple users (multiple persons in charge of utilizing and analyzing data) collect data from data sources that are determined to be useful for their own analysis. It may be difficult for each user to grasp the whole picture of the data stored in the database. In such a situation, for example, data with the same content may be collected redundantly under different names.

As a specific example of (ii) above, for example, a situation can be considered in which the temperature expression format differs depending on the sensor that collected the data (for example, one sensor uses “Celsius” and another sensor uses “Fahrenheit”). be done. As another specific example, in a certain database, a column that stores "name" data is a "name" column in one table, a "name" column in another table, and a "name" column in another table. A possible situation is that in a table it is the "NAME" column. The situation (ii) above occurs, for example, when data is collected from various data sources, and the collected data is stored in a database using the expression formats of the data sources as they are.

This situation may make it difficult for users to utilize data. Specifically, for example, the following problems may occur. That is, when performing data analysis using a database, there is a possibility that the user may not be aware of the existence of data useful for the purpose of analysis, even though the data is stored in the database. Moreover, even if the user recognizes useful data, it may be difficult for the user to understand how to combine the data with the data that the user intends to use.

As noted above, useful insights can be obtained by combining data collected from diverse data sources. In a database, such data combination is performed, for example, by an operation called "join". In a join operation, a relationship between two data sources (for example, tables in a relational database) is given as a join condition such as "customer.customer ID=sales.purchaser". This example represents an operation for associating the same value in the "customer ID" column in the customer table (customer table) with the same value in the "purchaser" column in the sales table (sales table).

For example, if the data formats that make up a table (e.g., table and column names) are systematically managed, the database user can, for example, roughly predict the contents of the table and set the conditions for joining the data. can be described. However, in a database with the tendencies described above, even if a user finds useful data (e.g. collected by another user), there may be multiple columns containing data with similar values. Situation is assumed. As a specific example, in a certain table, an identifier that identifies a customer (customer ID (Identifier)) is stored under the name of CID (Customer ID). Suppose you have a column that contains values. In such a case, even if there is data useful for analysis, a situation arises in which the user (analyst) cannot utilize the data.

On the other hand, in the present disclosure, it is possible to support users who do not have sufficient knowledge of the data stored in the target database and the format of the data and are unfamiliar with analysis using the database. technology is provided. A database system in which the technology according to the present disclosure, which will be described below, is implemented can, for example, obtain an analysis processing model (analysis processing flow (process ) to build a model). Such a database system uses this model to propose queries regarding the database to the user.

Specifically, the database system according to the present disclosure may be configured, for example, to store trends in access (queries, etc.) to the database of each user. When a user accesses according to the stored tendency, the database system according to the present disclosure performs the next step (for example, inquiry) for the user according to the stored tendency. It may be configured to suggest. More specifically, the database system may be configured to present the following suggestions to the user, for example. That is, the database system according to the present disclosure may, for example, store the access order of tables within the same session, and propose the next table to be accessed when accesses are made in the same order. For example, the database system according to the present disclosure stores the access order when a certain user accesses tables in the order of table A, table B, table C, and table D. Then, for example, when another user accesses tables A and B in that order, the database system according to the present disclosure proposes table C as the next table to be checked to the user. good too. Thereby, for example, even if another user does not recognize the existence of the data contained in the table C, it is possible to propose the use of the data stored in the table C to the user.

Also, the database system according to the present disclosure may be configured to store relationships between tables and suggest them to other users, for example. For example, in the database system according to the present disclosure, when a user enters "A.CID = B. Customer ID" (the same value in the CID column of Table A and the customer ID column of Table B in Tables A and B) When a join operation is performed under the condition of "associating rows with Then, for example, when another user accesses table A or table B, the database system according to the present disclosure proposes to that user a join with the other table under the above conditions. good. As a result, for example, it is possible to propose a method of combining useful data to another user. By using the database system according to the present disclosure configured as described above, for example, users can efficiently analyze data even in databases in which the users do not have sufficient knowledge. .

The technology according to the present disclosure will be described in more detail below using specific embodiments. Note that the configurations of the following embodiments (and modifications thereof) are one specific example, and the scope of the technology according to the present disclosure is not limited to them. The division of components (for example, division into functional units) in each embodiment shown below is an example of how the embodiment can be implemented. Configurations that can implement each embodiment are not limited to the following examples, and various configurations can be assumed. The constituent elements constituting each embodiment below may be further divided, and one or more constituent elements constituting each embodiment below may be integrated. Where each embodiment exemplified below is implemented using one or more physical devices, virtual devices, and combinations thereof, one or more components may be implemented by one or more devices and a configuration An element may be implemented using multiple devices.

Note that the data management method, which is one aspect of the technology according to the present disclosure, may be implemented as the operation of the database device in each of the following embodiments. Further, the computer program, which is one aspect of the technology according to the present disclosure, may be implemented as a program for executing the data management method, which is one aspect of the technology according to the present disclosure, in the database device according to each of the following embodiments. .

<First Embodiment>
A first embodiment of the technology according to the present disclosure will be described below. In the present embodiment, the technology according to the present disclosure will be specifically described by taking as a specific example a database device that implements the technology according to the present disclosure. Note that the database device in the present disclosure may be implemented as a single device, or may be implemented as a database system using a plurality of devices. A specific hardware configuration that can realize the database device in this embodiment will be described later.

[Constitution]
FIG. 1 is a block diagram illustrating the functional configuration of a database device 100 according to this embodiment. As illustrated in FIG. 1, a database device 100 in this embodiment is communicably connected to a client 200 .

The client 200 is a device by which a user issues a query to the database device 100 (query for data insertion, update, reference, etc. using a query language such as SQL). The client 200 may be configured by, for example, an information processing device such as a computer having a communication function. Queries issued by client 200 are not limited to a specific query language (eg, SQL), and any suitable query language may be used. The communication network that connects the database device 100 and the client 200 is not particularly limited, and appropriate communication methods (wired, wireless, and combinations thereof) can be adopted.

The constituent elements that constitute the database device 100 in this embodiment will be described below. As illustrated in FIG. 1, the database device 100 includes a query processing unit 101, a data storage unit 102, a trend storage unit 103, and a trend determination unit 104. These components constituting the database device 100 may be communicatively connected using an appropriate communication method. Further, each component may be realized, for example, as a software program executed by a hardware device described later, and dedicated hardware (for example, circuit elements capable of executing arithmetic processing, storage processing, communication processing, etc. etc.).

The inquiry processing unit 101 (inquiry processing means) is configured to process an inquiry issued by the client 200 . The query processing unit 101 may, for example, interpret a database query (SQL or the like) issued by the client 200 and execute a database operation command included in the query.

The data storage unit 102 (data storage means) is configured to store data stored in the database device 100 . The format in which the data storage unit 102 stores data is not particularly limited. For example, the data storage unit 102 may store data in a table format as a relational database, or may store data in another format (for example, KVS (Key Value Store), etc.). In the main embodiment, as a specific example, it is assumed that the data storage unit 102 stores data using a table format.

The trend storage unit 103 (tendency storage means) is configured to model and store queries issued by the client 200 . Specifically, the trend storage unit 103 may store a model representing a trend of access to tables included in inquiries received from the client 200 . Detailed operations of the trend storage unit 103 will be described later.

In response to a query issued by the client 200, the trend determination unit 104 (tendency determination means) determines whether or not to propose other executable operations related to the query based on the model stored in the trend storage unit 103. is configured to determine whether The trend determination unit 104 may determine, for example, whether or not the inquiries received from the client 200 include an inquiry similar to the model accumulated in the trend storage unit 103 . If there is a model that matches the query issued by the client 200, the trend determination unit 104 may propose another query to the client 200 based on that model. A specific operation of the trend determination unit 104 will be described later.

[motion]
The operation of the database device 100 configured as described above will be described below. The database device 100 is roughly divided into the following two processes (first process and second process). That is, the database device 100 is configured to model (create a model) an inquiry issued by the client 200 and execute a process (first process) of storing the model. The database device 100 is also configured to execute a process (second process) of proposing an operation to be executed next (for example, a query to be executed next) to the client 200 based on the created model. be done. The database device 100 does not necessarily have to exclusively execute these processes, and may execute both processes in parallel.

The first processing will be described below with reference to the flowchart illustrated in FIG.

The inquiry processing unit 101 receives an inquiry issued by the client 200 and analyzes the inquiry (step S201). In the following, as a specific example, it is assumed that queries issued by the client 200 are described using SQL commonly used in relational databases. Note that the technology according to the present disclosure is not limited to this, and can be applied to other query languages.

The inquiry processing unit 101 reads out the information of the table accessed in the previous inquiry (step S202). For example, the query processing unit 101 may read out from the trend storage unit 103 information of a table stored in step S203 described later when the first process was executed last time. Note that if the inquiry received from the client 200 is the first inquiry in a certain session, the inquiry processing unit 101 does not need to execute step S202. A session may be, for example, a collection of a series of operations (a set of operations) for the database device 100 . For example, one session may be started when a certain user connects to the database device 100 , and the session may end when the user disconnects from the database device 100 . In this case, the session includes operations performed by a certain user after connecting to the database device 100 until being disconnected from the database device 100 .

The inquiry processing unit 101 stores, in the trend storage unit 103, a table to be accessed when processing the inquiry received in step S201 (step S203). Specifically, when the query received from the client 200 is the first query in a certain session, the query processing unit 101 may store in the trend storage unit 103 information representing the tables accessed in the query. If the query received from the client 200 is not the first query in a certain session and the information of the previously accessed table is read in step S202, the query processing unit 101 reads the table accessed in the previous query and the current query. Information indicating the relationship with the table accessed in the inquiry may be stored in the trend storage unit 103 . That is, the query processing unit 101 may store in the trend storage unit 103 information representing the relationship between tables accessed in queries received up to a specific timing. Such specific timing is not particularly limited, and may be, for example, the timing at which the last inquiry was received in a certain session (timing at which the latest inquiry was received), or an appropriate earlier timing. Such timing may be set in the query processing unit 101 in advance as a set value or the like, for example.

As a specific example, it is assumed that the inquiry processing unit 101 receives the following inquiry (SQL) in step S201.

SELECT * FROM t1 WHERE c1 = 42 (inquiry 1).
In the above (query 1), "t1" represents the table accessed in this query (in this case, table "t1" is accessed). At this time, the inquiry processing unit 101 stores information “(t_prv)→t1” in the trend storage unit 103 . "t_prv" temporarily represents the table read in step S202. In actual processing, the table name read in step S202 is set in "t_prc". Also, "→" represents the order (order) in which the tables were accessed. In the above specific example, "→" indicates that table "t1" was accessed after table "t_prv" was accessed in a certain session. Note that the query processing unit 101 is not limited to "→", and may use other appropriate expressions. In this way, the query processing unit 101 stores the access order of the tables included in one or more queries received by a certain specific timing (for example, the timing at which the current query is received) in the trend storage unit 103. can be stored in the trend storage unit 103 as a model representing the trend of accesses.

If the inquiry in step S201 is the first inquiry in a session (step S202 has not been executed), the inquiry processing unit 101 may store the information "t1" in the trend storage unit 103. .

As another specific example, it is assumed that the inquiry processing unit 101 receives the following inquiry (SQL) in step S201.

SELECT * FROM t1, t2 WHERE t1. c1 = t2. c2 (inquiry 2).
In this case, the query processing unit 101 stores information in the format of “(t_prev)→t1, t2” in the trend storage unit 103 . In the above (query 2), a plurality of tables "t1" and "t2" are accessed.

The query processing unit 101 determines whether or not the query received in step S201 includes multiple tables (whether or not multiple tables are accessed in the query) (step S204). Using the above specific example, in the case of (query 1), the number of tables to be accessed is one ("t1"), so the query processing unit 101 determines "No" in step S204. In the case of (query 2) above, since a plurality of tables ("t1", "t2") are accessed, the query processing unit 101 determines "Yes" in step S204.

In the case of Yes in step S204, the inquiry processing unit 101 stores, in the trend storage unit 103, information representing the relationship between tables included in the inquiry received in step S201 (step S205). The query processing unit 101 may store, for example, a join condition for joining tables included in a certain query in the trend storage unit 103 as information representing the relationship between the tables. As a result, the query processing unit 101 can store, in the trend storage unit 103, a join condition that associates a plurality of tables as a model representing trends in access to the tables. In the case of the specific example of (query 2) above, the query processing unit 101 may store, for example, “t1.c1=t2.c2” in the trend storage unit 103 .

Through the processing of steps S203 and S205 described above, the query processing unit 101 can model access to tables stored in the database. More specifically, the query processing unit 101 can model, for example, the order of access to tables stored in the database. In addition, the query processing unit 101 can model relationships between tables stored in the database. More specifically, the query processing unit 101 can model a join relationship between a certain table and another table (a join condition for joining those tables).

The second process will be described below with reference to the flowchart illustrated in FIG.

The inquiry processing unit 101 receives an inquiry from the client 200 and analyzes the inquiry to specify a table related to the inquiry (step S301). For example, when receiving an inquiry such as the above (inquiry 2) from the client 200, the inquiry processing unit 101 identifies tables "t1" and "t2".

The query processing unit 101 repeatedly executes steps S302 to S304 described below for each table identified in step S301 (steps S302 to S305). In the example of (query 2) described above, the processing described in the following steps (steps S302 to S304) is performed for each of table "t1" and table "t2". In the description of the steps below, the table to be processed is indicated as "t" for convenience of description.

The query processing unit 101 reads information related to the table "t" from the trend storage unit 103 (step S302). The query processing unit 101 may provide the read information to the trend determination unit 104 . At this time, the information read out may be, for example, the information stored in the tendency storage unit 103 in steps S203 and S205 described above (for example, the access order of the tables, the connection relationship between the tables, etc.).

The trend determination unit 104 determines whether or not information related to "t" has been obtained in step S302 (step S303). In the case of Yes in step S303, the tendency determination unit 104 proposes information regarding the process to be executed next to the user based on the information related to the table "t" obtained in step S302 (step S304). . The trend determination unit 104 may provide the client 200 with information regarding the process to be executed next, thereby proposing such information to the user. If No in step S303 and if the process in step S304 has been performed, the tendency determination unit 104 checks whether or not the above process has been performed for all the tables identified in step S301 (step S305). In the case of No in step S305, the tendency determination unit 104 may return to step S302 and continue processing. Moreover, in the case of Yes in step S305, the trend determination unit 104 may end the process.

The processing in step S304 will be specifically described below. The trend determination unit 104 may present the user with a table to be accessed next based on the information related to the table “t” obtained in step S302. Further, the tendency determination unit 104 may present to the user another table to be accessed next, the other table, the table "t", and the join condition.

The trend determination unit 104 may present the information on the table “t” acquired from the trend storage unit 103 as it is to the user. In response to the inquiry received in step S301, the trend determination unit 104 selects information that satisfies a specific condition from among the information about the table “t” acquired from the trend storage unit 103, and presents the selected information to the user. good.

Hereinafter, the operation of the database device 100 will be described more specifically using specific examples illustrated in FIGS. 4 and 5. FIG.

FIG. 4 is an explanatory diagram showing a specific example of the first process executed within the same session. In FIG. 4, reference numerals 400a to 400d represent information (models representing queries) stored in the trend storage unit 103. FIG. At reference numerals 400a-400d, the information shown in "( )" represents tables associated with a certain query. For example, for the information represented by reference numeral 400a, the tables associated with the query are "t1", "t2". Also, the information shown in "<>" represents information (for example, join conditions, etc.) representing the relationship between the tables when a query includes a plurality of tables. For example, in the case of information represented by reference numeral 400a, the join condition for tables "t1" and "t2" is "t1.c1=t2.c2". The flow of processing shown in FIG. 4 will be described below.

User 1 sends an inquiry (
"SELECT * FROM t1, t2 WHERE t1.c1=t2.c2"). The query processing unit 101 identifies tables “t1” and “t2” accessed by this query and stores them in the trend storage unit 103 . At this time, the query processing unit 101 may, for example, notify the trend storage unit 103 of an instruction (“append (t1, t2)”) illustrated in S402 of FIG. Also, the query processing unit 101 may store information representing the relationship between the tables “t1” and “t2” (for example, join conditions) in the trend storage unit 103 . As a result, the trend storage unit 103 stores information (model) exemplified by 400a in FIG.

User 1 sends an inquiry (
"SELECT * FROM t3"). The query processing unit 101 identifies the table “t3” accessed by this query and stores it in the trend storage unit 103 . At this time, the inquiry processing unit 101 may, for example, notify the trend storage unit 103 of an instruction (“append (t3)”) illustrated in S404 of FIG. Information exemplified by 400b in FIG. 4 is stored in the trend storage unit 103 . As a result, information (model) representing the access order of the tables in the same session (in this case, the table "t3" is accessed after the tables ("t1", t2")) is stored in the trend storage unit 103. be done.

User 1 sends an inquiry (
"SELECT * FROM t3, t4 WHERE t3.c3=t4.c4"). The query processing unit 101 identifies tables “t3” and “t4” accessed by this query and stores them in the trend storage unit 103 . At this time, the query processing unit 101 may, for example, notify the trend storage unit 103 of an instruction (“append (t3, t4)”) illustrated in S406 of FIG. Also, the query processing unit 101 may store information representing the relationship between the tables “t3” and “t4” (for example, join conditions) in the trend storage unit 103 . The trend storage unit 103 stores information exemplified by 400c in FIG. As a result, information ( model) is stored in the trend storage unit 103 .

User 1 sends an inquiry (
"SELECT * FROM t5"). The query processing unit 101 identifies the table “t5” accessed by this query and stores it in the trend storage unit 103 . At this time, the query processing unit 101 may, for example, notify the trend storage unit 103 of an instruction (“append (t5)”) illustrated in S404 of FIG. The trend storage unit 103 stores information exemplified by 400d in FIG. As a result, the tables are accessed in the same session in the order of access (in this case, table (“t1”, t2”), table “t3”, table (“t3”, “t4”), and table “t5”). ) is stored in the trend storage unit 103 .

FIG. 5 is an explanatory diagram showing a specific example of the second processing. In the processing illustrated in FIG. 5, it is assumed that the processing illustrated in FIG. 4 has been executed in advance and a model representing the information illustrated in 400a-400d in FIG. 4 has been constructed. Note that the user 1 illustrated in FIG. 4 and the user 2 illustrated in FIG. 5 may be different users or the same user.

User 2 executes an inquiry ("SELECT * FROM t3") shown in S501 of FIG. 5 to database device 100 (inquiry processing unit 101).

Upon receiving the inquiry, the inquiry processing unit 101 reads from the trend storage unit 103 information related to the table “t3” that is the object of the inquiry. At this time, the query processing unit 101 may send a command (“get_related(t3)”) as indicated by 502 in FIG. 5 to the tendency storage unit 103, for example.

As described in the specific example shown in FIG. 4, the tendency storage unit 103 stores the following information (model).
"[(t1, t2 <t1.c1 = t2.c2>), (t3), (t3, t4 <t3.c3 = t4.c4>), (t5)]".
In response to a request from the inquiry processing unit 101, the tendency storage unit 103 may return the following information (related information) to the inquiry processing unit 101, for example. That is, since the tendency storage unit 103 stores "(t3, t4)", the query processing unit 101 uses the information representing the table "t4" as the table accessed at the same time as the table "t3" as related information. may be returned to Further, the tendency storage unit 103 may return "t3.c3=t4.c4" as information indicating the relationship between the tables "t3" and "t4" to the query processing unit 101 as related information. This is because "t3.c3=t4.c4" was used as the join condition when the query for accessing the table "(t3, t4)" was executed in S405 of FIG. Further, the tendency storage unit 103 may return information representing the table “t5” as a candidate for the table to be accessed next to the query processing unit 101 as related information. This is because the table "t5" is accessed after the table "t3" in the processing of S403-S408 illustrated in FIG.

The inquiry processing unit 101 sends the information (related information) acquired from the trend storage unit 103 to the trend determination unit 104 . At this time, the query processing unit 101 may send a command (“get_suggestion(t3)”) such as 503 in FIG.

The trend determination unit 104 uses the information received from the inquiry processing unit 101 as candidates for operations to be proposed to the user (suggestion candidates), and determines information to be proposed to the user from the proposal candidates using specific criteria. do.

The trend determination unit 104 may, for example, propose all proposal candidates to the user.

Further, the trend determination unit 104 may determine the information to be proposed to the user, for example, considering conditions regarding inquiries as specific determination criteria. That is, for example, the trend determination unit 104 asks the user ("user 2" in this case) based on whether or not the column referenced in the query received from the user is included in the proposed join condition. Suggested information may be determined. As a specific example, it is assumed that an inquiry with the contents of "SELECT c1 FROM t3" is received from a user. In this case, the column "t3.c3" included in the join condition ("t3.c3=t4.c4") stored in the trend storage unit 103 is the column ("t3.c1") referenced in the query. Not included. Therefore, it is considered that "t3.c3" is out of the user's interest. Therefore, the tendency determination unit 104 sets the table "t4" to the "table "t3" included in the proposal candidates as the condition "t3. c3 = t4. Exclude from the proposal the information that represents "combined by c4". In other words, the tendency determination unit 104 may determine, among the proposal candidates, the join condition including the column referred to in the query as information to be proposed to the user. Note that the trend determination unit 104 is not limited to the above, and may determine information to be proposed to the user using other determination criteria.

The trend determination unit 104 may provide the user (in this case, the user 2) with suggested information (suggestion information), as exemplified in S504 of FIG. Note that the trend determination unit 104 may provide the inquiry processing unit 101 with the proposal information, and the inquiry processing unit 101 may provide the user (user 2 in this case) with the proposal information.

FIG. 6 is an explanatory diagram showing a specific example of a proposal provided from the database device 100 to the user who executed the inquiry illustrated in FIG. 600 shown in FIG. 6 may be provided to the user as part of a display screen displayed on the client 200 or a user interface, for example.

In 601 of FIG. 6, the content of the inquiry executed by the user ("SELECT * FROM t3") is displayed. The user may execute an inquiry to the database device 100 by, for example, inputting an inquiry exemplified by 601 in FIG. 6 into the user interface displayed on the client 200 .

In 602 of FIG. 6, the processing result of the inquiry in 601 is displayed. In this case, the contents of table "t3" are displayed.

In 603 of FIG. 6, proposal information for the user is displayed. At 603 in FIG. 6, "t2", "t3", "t4", "t5", "t6", "t7", "t13", and "t15" represent tables. Arrows connecting the tables represent the order of access. "You are here" represents the table accessed by the user's most recently executed query (table "t3" in this case). Also, "JOIN" represents joining two tables according to a specific join condition. In the specific example shown in FIG. 6, the join condition is displayed as a character string near "JOIN".

As shown in FIG. 6, in response to an inquiry by the user that "SELECT" table "t3", the database device 100 (a) selects table "t3" and table "t4" as the next step, and selects "t3. c3=t4.c4", and (b) referring to table "t5". Also, as a map, the next step is suggested with an arrow.

In the case of the specific example shown in FIG. 6, the database device 100 further refers to the table "t6" or "t7" (connected by an arrow) after referring to the next step (for example, table "t5"). , to join table "t5" and table "t4" under the join condition "t5.c5=t4.c4") can be proposed.

According to the database device 100 configured as described above, the user can more efficiently perform data analysis. The reason is as follows. That is, the database device 100 analyzes a query executed by a certain user and models operations on the database. More specifically, the database device 100 can store the database access order in a session as a model. Therefore, for example, when the user accesses the tables in a certain order, the database apparatus 100 can present candidates for the next table to be accessed. This allows the user to discover, for example, data in the proposed table that the user himself was unaware of, and which other data and data contained in the proposed table. It can be expected that effective data analysis can be performed by combining

Also, the database device 100 can store relationships between tables (for example, join conditions for two certain tables) as a model. Therefore, for example, when a certain user accesses a certain table, the database device 100 can propose a join with another table based on the join condition stored as a model. As a result, for example, even for data that the user has not been able to utilize due to reasons such as unclear connection conditions, the user can discover how to combine the data according to the proposal from the database device 100, making it more effective. It can be expected that it will be possible to perform various data analysis.

[Modification 1 of the first embodiment]
The basic configuration of the database device 100 in this modification may be the same as in the first embodiment. In this modified example, part of the operation of each component constituting the database device 100 is extended from the first embodiment.

Specifically, the database device 100 (query processing unit 101) stores the time when the table was accessed when storing the information related to the table in the trend storage unit 103 in the first process. Then, in the second process, the database device 100 (tendency determination unit 104) determines information to be proposed to the user from the proposal candidates, taking into consideration the time when the table was accessed as a specific criterion.

More specifically, the trend determination unit 104 excludes tables included in the proposal candidates from being proposed to the user if the table was accessed before a specific time (specified time). . In other words, the trend determination unit 104 may propose to the user, among the tables included in the proposal candidates, the tables accessed after a certain specific time (specific time). This is because the trends of access to the table may change over time, and there may be situations where suggesting old information is not useful.

The database device 100 according to this modification configured as described above can propose processing candidates (for example, table access, join, etc.) to the user based on relatively new access trends. can.

[Modification 2 of the first embodiment]
The basic configuration of the database device 100 in this modification may be the same as in the first embodiment. In this modified example, part of the operation of each component constituting the database device 100 is extended from the first embodiment.

In the second process, the database device 100 (tendency determination unit 104) in the present modification considers the access authority of the user who accesses the table as a specific criterion, and considers the information to be proposed to the user from the proposal candidates. to decide.

More specifically, the trend determination unit 104 excludes, for each user, information about tables that the user does not have access rights from among the tables included in the proposal candidates so as not to propose to the user. do. In other words, the tendency determination unit 104 proposes to each user information about a table that the user is authorized to access, among the tables included in the proposal candidates. This is because, if access rights are set for each table according to the user, even if a table without access rights is proposed, the user cannot effectively utilize the information. In addition, this can reduce the possibility of users causing unnecessary confusion. Access rights to the table may be provided via the client 200 when the user uses the database device 100, for example.

[Modification 3 of the first embodiment]
The basic configuration of the database device 100 in this modification may be the same as in the first embodiment. In this modified example, part of the operation of each component constituting the database device 100 is extended from the first embodiment.

Specifically, in the first process, the database device 100 (query processing unit 101) stores the number of times the information is recorded when storing the information related to the table in the trend storage unit 103. . The query processing unit 101 may store, for each table, the number of times queries related to the table have been received in the trend storage unit 103, for example. More specifically, the query processing unit 101 may count the number of accesses to a certain table and store the number of times in the trend storage unit 103 in the first process, for example. For example, the query processing unit 101 may count the number of times the join condition is used for each join condition included in the query, and store the number of times in the trend storage unit 103 .

In the second process, the database device 100 (tendency determination unit 104) determines the information to be proposed to the user from the proposal candidates in consideration of the number of times each proposal candidate is stored as a specific criterion. good. More specifically, the trend determination unit 104 proposes to the user a proposal candidate whose stored number of times exceeds a specific value. This specific value may be settable by the user, for example. The database device 100 in this modified example can prevent the information proposed to the user from becoming excessive in the second process, for example, due to various analytical behaviors of the user. As a specific example, in the first process, 50 queries accessing table "tB" after table "tA" and 10 queries accessing table "tC" next to table "tA" were recorded. assume that. If the specific value is set to "20", then when a query regarding table "tA" is executed in the second process, the database device 100 then proposes table "tB". That is, the database apparatus 100 proposes to the user the table "tB" which is accessed relatively frequently, and excludes the table "tC" which is accessed relatively frequently, so that the information proposed to the user becomes excessive. can prevent it from happening.

<Second embodiment>
A second embodiment of the technology according to the present disclosure will be described below. The second embodiment is an embodiment that implements the database device according to the first embodiment and its modifications as a database system configured by a plurality of separated physical or virtual devices.

FIG. 7 is a block diagram illustrating the functional configuration of the database system 700 in this embodiment. As illustrated in FIG. 7, database system 700 comprises query processing device 701 , data storage device 702 , trend storage device 703 and trend determination device 704 . These components that make up database system 700 may be communicatively coupled using any suitable communication method (eg, wireless communication, wired communication, and combinations thereof). In addition, each component may be realized as a single device using, for example, a general-purpose hardware device and a software program executed by such a device, which will be described later, or dedicated hardware (for example, arithmetic processing, storage processing, communication processing, etc.).

The query processing device 701 accepts queries regarding tables stored in the data storage device, like the query processing unit 101 in the first embodiment and its modification. The query processing device 701 may be configured, for example, to achieve the same function as the query processing unit 101 in the first embodiment and its modification.

The data storage device 702 stores a table storing data, like the data storage unit 102 in the first embodiment and its modification. The data storage device 702 may be configured, for example, to achieve the same function as the data storage unit 102 in the first embodiment and its modification.

The trend storage device 703 stores a model representing the trend of access to the table, like the trend storage unit 103 in the first embodiment and its modification. The trend storage device 703 may be configured, for example, to achieve the same function as the trend storage unit 103 in the first embodiment and its modification.

Similar to the trend determination unit 104 in the first embodiment and its modification, the trend determination device 704 stores data stored in the trend storage device 703 in accordance with tables included in other queries received by the query processing device 701. Based on the model, it provides information that suggests other operations that can be performed in relation to other queries. The trend determination device 704 may be configured to achieve the same function as the trend determination unit 104 in the first embodiment and its modification, for example. According to the database system 700 of this embodiment configured in this manner, the user can more efficiently perform data analysis, as with the database device 100 of the first embodiment.

<Configuration of hardware and software program (computer program)>
A hardware configuration capable of implementing each of the above-described embodiments will be described below. In the following description, each database device 100 described in each of the above embodiments is simply referred to as a database device.

The database device described in each of the above embodiments may be composed of one or more dedicated hardware devices. In that case, each component shown in FIG. 1 above may be implemented as hardware (such as an integrated circuit on which processing logic is implemented) in which a part or all of them are integrated. For example, when the database device is realized by a hardware device, the constituent elements of the database device may be implemented as integrated circuits (for example, SoC (System on a Chip), etc.) capable of providing respective functions. In this case, for example, data possessed by the components of the database device may be stored in a RAM (Random Access Memory) area or flash memory area integrated into the SoC.

In this case, the database device includes, for example, one or more processing circuits capable of realizing the functions of the query processing unit 101, the data storage unit 102, the trend storage unit 103, and the trend determination unit 104, communication circuits, and storage It may be implemented using a circuit or the like. It should be noted that various variations are conceivable in implementing the circuit configuration that realizes the database device. When the database device is composed of a plurality of hardware devices, the respective hardware devices may be communicatively connected by an appropriate communication method (wired, wireless, or a combination thereof).

Moreover, the database device described above may be configured by a general-purpose hardware device 800 as illustrated in FIG. 8 and various software programs (computer programs) executed by the hardware device 800 . In this case, the database device may consist of one or more suitable number of hardware devices 800 and software programs.

A processor 801 in FIG. 8 is, for example, a general-purpose CPU (Central Processing Unit) or a microprocessor. The processor 801 may, for example, read various software programs stored in a non-volatile storage device 803, which will be described later, into the memory 802 and execute processing according to the software programs. In this case, the constituent elements of the database device in each of the above embodiments can be realized as software programs executed by the processor 801, for example.

In this case, the database device in each of the above embodiments may be realized by one or more programs capable of realizing the functions of the query processing unit 101, the data storage unit 102, the trend storage unit 103, and the trend determination unit 104, for example. It should be noted that various variations are conceivable in the implementation of such a program.

The memory 802 is a memory device such as a RAM that can be referred to by the processor 801, and stores software programs, various data, and the like. Note that the memory 802 may be a volatile memory device.

The nonvolatile storage device 803 is a nonvolatile storage device such as a magnetic disk drive or a semiconductor storage device (flash memory, etc.). The nonvolatile storage device 803 can store various software programs, data, and the like. Various tables and models in the database device may be stored in the non-volatile storage device 803, for example.

The reader/writer 804 is, for example, a device that processes data reading and writing to a recording medium 805, which will be described later. The database device may read data recorded on the recording medium 805 via the reader/writer 804, for example.

A recording medium 805 is a recording medium capable of recording data, such as an optical disk, a magneto-optical disk, or a semiconductor flash memory. In the present disclosure, the type of recording medium and recording method (format) are not particularly limited and may be selected as appropriate.

The network interface 806 is an interface device that connects to a communication network, and may employ, for example, a wired or wireless LAN (Local Area Network) connection interface device. A database device may be communicatively coupled to client 200 via network interface 806, for example.

The input/output interface 807 is a device that controls input/output with an external device. The external device may be, for example, an input device (for example, keyboard, mouse, touch panel, etc.) capable of receiving input from the user. Also, the external device may be an output device (for example, a monitor screen, a printer, etc.) capable of presenting various outputs to the user. For example, various data may be output via an input/output interface.

The technology according to the present disclosure may be implemented by the processor 801 executing a software program supplied to the hardware device 800, for example. In this case, an operating system running on the hardware device 800, middleware such as database management software, network software, or the like may execute part of each process.

In each of the above-described embodiments, each part shown in each of the above figures may be realized as a software module, which is a unit of function (processing) of a software program executed by the above-described hardware. For example, when the above units are implemented as software modules, these software modules may be stored in the non-volatile storage device 803 . These software modules may then be read into the memory 802 when the processor 801 executes each process. Also, these software modules may be configured to be able to transmit various data to each other by an appropriate method such as shared memory or inter-process communication.

Furthermore, each of the above software programs may be recorded on the recording medium 805 . In this case, each of the above software programs may be installed into the hardware device 800 using a suitable jig (tool). Also, various software programs may be downloaded from the outside via a communication line such as the Internet. Various common procedures can be employed as a method of providing the software program.

In such a case, the technology according to the present disclosure may be configured by a computer-readable recording medium on which code constituting a software program or code is recorded. In this case, the recording medium may be a non-temporary recording medium independent of the hardware device 800, and may be a recording medium in which a software program transmitted via a LAN, Internet, etc. is downloaded and stored or temporarily stored. may

Further, the above-described database device or components of the database device are a virtual environment obtained by virtualizing the hardware device 800 illustrated in FIG. 8 and a software program (computer program) executed in the virtual environment. may be configured by In this case, the components of the hardware device 800 illustrated in FIG. 8 are provided as virtual devices in the virtual environment.

The present invention has been described above using the above-described embodiments as exemplary examples. However, the invention is not limited to the embodiments described above. That is, within the scope of the present invention, various aspects that can be understood by those skilled in the art can be applied to the present invention, and modifications and combinations of the above embodiments are also included in the technical scope of the present invention. be

REFERENCE SIGNS LIST 100 database device 101 query processing unit 102 data storage unit 103 trend storage unit 104 trend determination unit 700 database system 701 query processing device 702 data storage device 703 trend storage device 704 trend determination device

Claims (10)

query processing means for receiving queries regarding data storage means having tables for storing data;
trend storage means for storing a model representing a trend of access to the table related to queries received by the query processing means;
Based on the table related to the other inquiry received by the inquiry processing means and the model stored in the trend storage means, an operation including the table indicated by the other inquiry among operation candidates is performed. and a trend determination means for determining as a proposed operation ,
The tendency determination means outputs a display screen illustrating the table related to the suggested operation and the suggested operation.
database device. The query processing means stores an access order of the table by one or more queries received by a certain timing as the model in the trend storage means;
The trend determination means accesses one or more of the tables accessible after accessing the tables related to other queries received by the query processing means based on the access order of the tables stored as the model. 2. The database device according to claim 1, wherein operations including access to are selected as proposal candidates that are candidates for operations to be proposed, and one or more operations are proposed from among the proposal candidates. The query processing means stores a join condition for associating the plurality of tables included in the received query as the model in the trend storage means,
The trend judgment means proposes an operation of associating the table included in the other query received by the query processing means with the other table based on one or more of the join conditions stored as the model. 3. The database device according to claim 1, wherein a candidate for an operation to be performed is selected as proposed candidates, and one or more operations are proposed from among the proposed candidates. When the query processing means receives another query, the trend determination means determines, among the join conditions for associating the table included in the other query received by the query processing means, with the other table, the 4. The database device according to claim 3, wherein an operation of associating said tables with said join conditions including columns of said tables referred to in other queries is proposed. When receiving an inquiry, the inquiry processing means stores the time at which the inquiry was accepted in the trend storage means,
When the inquiry processing means receives another inquiry, the trend determination means selects the proposal selected from the proposal candidates based on the model stored in relation to the inquiry received after a certain time. 5. The database device according to any one of claims 2 to 4, wherein one or more operations are proposed from the candidates. The trend determination means selects one or more of the proposal candidates related to the table accessible by the user according to the access right to the table of the user who executed the other query received by the query processing means. 6. The database device according to any one of claims 2 to 5, which proposes the operation of . When the inquiry processing means receives an inquiry,
For the table included in the query, the number of times the query for that table has been executed;
storing in the trend storage means at least one of: when the query includes the join condition that associates the plurality of tables, the number of times the query including the join condition has been executed;
When the query processing means receives another query, the trend determination means proposes an operation including at least one of the table for which queries have been executed at least a specific number of times and the join condition among the proposal candidates. 4. The database device according to claim 3. a query processing device for receiving queries about a data storage device having tables for storing data;
a trend storage device for storing a model representing a trend of access to the table related to queries received by the query processing device;
Based on the table related to the other inquiry received by the inquiry processing device and the model stored in the trend storage device, an operation including the table indicated by the other inquiry among operation candidates is performed. and a trend determination device for determining as a proposed operation,
The trend determination device outputs a display screen illustrating the table related to the suggested operation and the suggested operation,
A database system in which the query processing device, the trend storage device, and the trend determination device are connected to communicate with each other via a communication network. the computer
accepting queries about a database having tables for storing data;
Storing in a storage device a model representing trends in access to the table associated with received queries;
Based on the table related to the other query and the stored model, determining an operation including the table indicated by the other query among operation candidates as an operation to propose ,
outputting a display screen illustrating the table associated with the suggested operation and the suggested operation;
Data management method. a query process that accepts queries about a database having tables that store data;
a storage process for storing, in a storage device, a model representing trends in access to the table associated with received queries;
trend determination processing for determining an operation including the table indicated by the other query among operation candidates as an operation to be proposed, based on the table related to the other query and the stored model ;
A computer program that causes a computer functioning as a database device to execute a process of outputting a display screen showing the table related to the suggested operation and the suggested operation .

Images