Database management system, database management method, and database management program

A database management system according to one embodiment includes at least one processor configured to control a hierarchical database including a plurality of end databases and a primary database directly or indirectly connected to the plurality of end databases. Each of the plurality of end databases stores sensor data. The primary database provides a virtual data table. The at least one processor transmits, to the end database, a search instruction for obtaining a result set containing a combination of an intermediate result based on the sensor data and a path ID for uniquely identifying a path connecting the primary database and the end database, receives a result set, and represents a search result based on the result set by the virtual data table and outputs the search result.

CROSS REFERENCE TO PRIOR APPLICATION

This application is a National Stage Patent Application of PCT International Patent Application No. PCT/JP2020/010126 (filed on Mar. 9, 2020) under 35 U.S.C. § 371, which claims priority to Japanese Patent Application No. 2019-081074 (filed on Apr. 22, 2019), which are all hereby incorporated by reference in their entirety.

TECHNICAL FIELD

One aspect of the present disclosure relates to a database management system, a database management method, and a database management program.

BACKGROUND ART

A hierarchical database is known that includes a plurality of databases that store data (sensor data) obtained from a sensor. For example, Patent Literature 1 discloses a cognitive communication system using a technique of organizing, into a networked and hierarchical structure, database devices for managing frequency usage situations for a wireless communication system that implements cognitive radio. This cognitive communication system includes a wireless communication system composed of a detection device that detects the usage situation of the ambient radio frequency, and a first database device that stores the frequency usage situation detected by the detection device, and a second database device that integrates one or more first database devices.

CITATION LIST

Patent Literature

SUMMARY OF INVENTION

Technical Problem

There are cases where the number of databases that store sensor data is enormous, and analyzing a massive amount of sensor data causes an excessive increase in load on a database management system. There is thus a demand for a database management system capable of performing efficient operations on sensor data.

Solution to Problem

A database management system according to one aspect of the present disclosure includes at least one processor configured to control a hierarchical database including a plurality of end databases, each connected to a sensor, and a primary database directly or indirectly connected to the plurality of end databases. Each of the plurality of end databases stores sensor data based on a signal from the sensor. The primary database provides a virtual data table representing a search result based on the sensor data. The at least one processor performs: acquiring a query for obtaining the search result; transmitting a search instruction corresponding to the query to at least one end database among the plurality of end databases, the search instruction being an instruction signal for obtaining a result set containing a combination of an intermediate result based on the sensor data and a path ID being an identifier for uniquely identifying a path connecting the primary database and the end database; receiving at least one result set corresponding to the at least one end database; representing the search result based on the at least one result set by the virtual data table; and outputting the search result represented by the virtual data table.

According to this aspect, sensor data corresponding to a query is collected in the primary database together with a path ID indicating a path connecting the primary database and the end database, and a search result based on this collected sensor data is represented by the virtual data table and output. Since actual sensor data is stored only in the end database, and the primary database represents the search result by the virtual data table, a storage area for storing the actual sensor data is reduced as a whole in the hierarchical database. Further, a source of sensor data, i.e., an information source, is identifiable by the path ID. This architecture enables efficient operations on sensor data.

Advantageous Effects of Invention

According to one aspect of the present disclosure, efficient operations on sensor data can be achieved.

DESCRIPTION OF EMBODIMENTS

An embodiment of the present disclosure is described hereinafter with reference to the attached drawings. Note that, in the description of the drawings, the same or similar elements are denoted by the same reference symbols and redundant description thereof is omitted.

Overview of System

A database management system1according to an embodiment is a computer system that controls a hierarchical database. The hierarchical database is a database structure generated by organizing a plurality of databases into a hierarchical tree structure. In this embodiment, the hierarchical database at least includes a plurality of end databases (end DBs), each of which is connected to a sensor, and one primary database (primary DB). The hierarchical database may further include one or more intermediate databases (intermediate DB) located between the primary database and the end database in a tree structure. The primary database is located in the highest layer, the end database is located in the lowest layer, and the intermediate database is located in an intermediate layer.

The database management system1is capable of processing sensor data based on signals from one or more sensors. The sensor is an element or device that detects a phenomenon in the real world and converts the detected phenomenon into a signal that can be processed by a computer. The type of a phenomenon to be detected by a sensor is not particularly limited. For example, the phenomenon may be any natural phenomenon or any phenomenon occurring artificially. Accordingly, the type of the sensor to be managed by the database management system1is not particularly limited. The sensor data is electronic data generated on the basis of signals. Since the type of the sensor is not particularly limited, the details of information indicated by the sensor data are also not particularly limited. The database management system1is able to perform data operations such as search on the sensor data stored in the hierarchical database. Further, the database management system1is able to perform processing for managing the hierarchical database.

Hierarchical Database

FIG. 1is a view showing an example of the structure of a hierarchical database2. In this example, the hierarchical database2includes a part (two-layer part) where a primary database10is connected directly to an end database30and a part (three- or four-layer part) where the primary database10is connected to the end database30through at least one intermediate database20. In this manner, the primary database10may be connected directly to the end database30or may be connected indirectly through one or more intermediate databases20. The number of intermediate databases20interposed between the primary database10and a certain end database30is not limited. In this way, the hierarchy of the hierarchical database2may be set flexibly.

FIG. 2is a view showing another example of the structure of the hierarchical database2. In this example, the primary database10and each of a plurality of end databases30are connected through one intermediate database20, and therefore the whole of the hierarchical database2has a three-level architecture. In this manner, the hierarchy of the hierarchical database2may be fixed.

The number of databases (the intermediate databases20or the end databases30) that are directly connected to the primary database10is not limited regardless of whether the hierarchy of the hierarchical database2is flexible or fixed. The number of databases (the intermediate databases20or the end databases30) in the immediately lower level that are connected to one intermediate database20is also not limited. The number of sensors90that are connected to one end database30is also not limited.

The primary database10is a database that provides a final search result based on sensor data. The intermediate database20is a database that is located on a path connecting the end database30and the primary database10for search. The path is a data path connecting the primary database10and one end database30without loopback. Each path is uniquely identified by an identifier called a path ID. The intermediate database20provides an intermediate result of a search to the primary database10. The end database30is a database that stores sensor data. The end database30is connected to one or more sensors, and permanently stores information provided from sensors as sensor data. Only one type of sensor, or a plurality of types of sensors may be connected to one end database30. None of the primary database10and the intermediate database20permanently stores sensor data.

FIG. 3is a view showing an example of a table structure in the hierarchical database2. Each of the primary database10and the intermediate database20includes at least one common master table40and at least one virtual data table50. The end database30includes at least one common master table40and at least one actual data table60.

The common master table40is a storage area that stores information necessary for control of the hierarchical database2. The details of master data, which is information to be stored in the common master table40, are not limited, and may be set arbitrarily. For example, the master data may indicate information (e.g., identifier, name, manufacturer name etc.) about a sensor, or may indicate a rule for converting a numerical value obtained from a sensor into another numerical value. Each of the common master tables40is identical among all databases in the hierarchical database2. Operations (create new, update, delete, etc.) on the common master table40are performed on the initiative of the primary database10. Each of the common master tables40is implemented in each database in association with a version number indicating the stage of a change in this table.

The virtual data table50is a virtual storage area that represents a search result based on sensor data. The virtual data table50does not store actual data, and it can be regarded as a “view”. The virtual data table50shows a collection of data in one or more databases located in the immediately lower level as if it is a single table. The table structure (the structure of records, the data type of each column, the maximum number of records, etc.) of each virtual data table50is identical among all databases in the hierarchical database2. The data structure of the virtual data table50is not limited, and it may be designed arbitrarily. Each record of the virtual data table50may contain a path ID. The path ID may be a column that is recognizable by a user, or a column for internal processing that is not recognized by a user. Operations (create new, update, delete, etc.) on the virtual data table50are performed on the initiative of the primary database10.

The actual data table60is a storage area that permanently stores sensor data. The data structure of the actual data table60is not limited, and it may be designed arbitrarily. The table structure (the structure of records, the data type of each column, the maximum number of records, etc.) of each actual data table60is the same as that of the corresponding virtual data table50. Each record of the actual data table60contains a path ID. The path ID may be recognizable by a user, or may be for internal processing in correspondence with the virtual data table50. Operations (create new, update, delete, etc.) on the actual data table60are performed on the initiative of the primary database10. Sensor data in the actual data table60can be added, updated, or deleted by the end database30.

The virtual data table50and the actual data table60may be a cyclic table. The cyclic table is a table where the number of storable records is predetermined. In the cyclic table, data is managed by a rule such as FIFO (First In, First Out) or LIFO (Last In, First Out). Specifically, when the maximum number of records is exceeded, one specific record is overwritten with a record to be added based on the rule. Columns in the cyclic table may be set to a fixed length. Since columns are set in this way, the total data size of each record is the same, which prevents fragmentation of a memory caused by deviation in memory layout.

The virtual data table50and the actual data table60corresponding to each other can be generated by a common SQL. For example, by the SQL “CREATE CYCLIC TABLE V_TBL value INT LIMIT_RECORDS 1000”, the virtual data table50called “V_TBL”, which is a cyclic table capable of holding 1000 records at maximum, may be generated on the primary database10and the intermediate database20, and the actual data table60having the same table structure may be generated on the end database30. Note that while the actual data table60stores sensor data permanently, the virtual data table50represents sensor data temporarily and does not store sensor data permanently.

FIG. 4is a view showing an example of sensor data. A record of sensor data91contains a record ID, which is an identifier for uniquely identifying a record in a table, time and date when the record is recorded, and one or more values corresponding to one or more sensors (sensor A, sensor B, switch C etc.), A record of sensor data92contains a record ID, a statistical period, and statistical values (maximum value, minimum value, total value, sum of squares, etc.) related to the sensor data91in the statistical period. In the example ofFIG. 4, only columns related to the sensor A are shown for the sensor data92. Assuming that the maximum number of records of each of the sensor data91and92is 6000, and the sensor data91is recorded every one second, the sensor data91shows a history of last 100 minutes. In the case where the history of 100 minutes is statistically processed every 100 minutes by a stored procedure implemented in the end database30, the sensor data92shows statistical values for 400 days or more.

FIG. 5is a view showing an example of a method of constructing the hierarchical database2. In this example, databases are distinguished by alphabetical letters such as (A) and (B) according to need.

First, a primary database (A) is prepared. One intermediate database (B) is connected to this primary database (A), and a database ID “0001” is assigned to this intermediate database (B). The database ID in the present disclosure is an identifier of a database that is assigned to the intermediate database20and the end database30, and it is determined so as to uniquely identify a path from the primary database10to the end database30, A method of setting a specific value of the database ID is not limited, and the database ID may be set by an arbitrary policy. For example, the database ID may be set to a value obtained by representing a 2-byte number by a 4-byte character string in a hexadecimal form. In this case, 65536 (=216) number of databases at maximum can be connected in a level immediately lower than the level of the primary database10or a certain intermediate database20.

Next, an intermediate database (C) is connected to the primary database (A), and a database ID “0002” is assigned to this intermediate database (C). Then, an end database (D) is connected to the primary database (A), and a database ID “0003” is assigned to this end database (D). In this manner, the database IDs may be assigned sequentially without distinguishing between the intermediate database20and the end database30.

When connecting lower-level databases as well, the database IDs are assigned to those databases in the same manner. In the example ofFIG. 5, end databases (E) and (F) are connected to the intermediate database (B), a database ID “0001” is assigned to the end database (E), and a database ID “0002” is assigned to the end database (F). An intermediate database (G) is connected to the intermediate database (C), and a database ID “0001” is assigned to the intermediate database (G). An end database (H) is connected to the intermediate database (G), and a database ID “0001” is assigned to the end database (H).

As shown inFIG. 5, a plurality of databases in the hierarchical database2may have the same database ID unless the database ID does not overlap between one or more databases located in a level immediately lower than the level of a certain higher-level database. In this case also, a path connecting the primary database10and the end database30is uniquely identifiable. Note that a method of assigning the database ID is not limited to the example shown inFIG. 5, and each database ID may be unique in the hierarchical database2, for example.

System Configuration

The database management system1at least includes the primary database10, and may further include at least one of the intermediate database20and the end database30.

FIG. 6is a view showing an example of a typical hardware configuration of a computer100that constitutes the primary database10or the intermediate database20. For example, the computer100includes a processor101, a main storage unit102, an auxiliary storage unit103, a communication control unit104, an input device105, and an output device106. The processor101runs an operating system and an application program. The main storage unit102is ROM and RAM, for example. The auxiliary storage unit103is a hard disk or a flash memory, for example, and it generally stores a larger volume of data than the main storage unit102. The tables are built on the auxiliary storage unit103. The auxiliary storage unit103stores a program causing the computer100to function as the primary database10or the intermediate database20. The communication control unit104is a network card or a wireless communication module, for example, and it is used for data communication with the primary database10, the intermediate database20, or the end database30. The input device105is a keyboard, a mouse, a touch panel or the like, for example. The output device106is a monitor and a speaker, for example.

The functional elements of the primary database10or the intermediate database20are implemented by a program previously stored in the auxiliary storage unit103. To be specific, the functional elements are implemented by loading the program onto the processor101or the main storage device102and running this program on the processor101. The processor101makes the communication control device104, the input device105or the output device106operate in accordance with the program, and reads and writes data to and from the main storage device102or the auxiliary storage device103.

FIG. 7is a view showing an example of a typical hardware configuration of a computer200that constitutes the end database30. For example, the computer200includes a processor201, a main storage unit202, an auxiliary storage unit203, a communication control unit204, and an input interface205. The processor201runs an operating system and an application program. The main storage unit202is ROM and RAM, for example. The auxiliary storage unit203is a hard disk or a flash memory, for example, and it generally stores a larger volume of data than the main storage unit202. The tables are built on the auxiliary storage unit203. The auxiliary storage unit203stores a program causing the computer200to function as the end database30. The communication control unit204is a network card or a wireless communication module, for example, and it is used for data communication with the primary database10or the intermediate database20. The input interface205is an input terminal or a wireless communication module, and it is used for obtaining signals or data from the sensor90.

The functional elements of the end database30are implemented by a program previously stored in the auxiliary storage unit203. To be specific, the functional elements are implemented by loading the program onto the processor201or the main storage device202and running this program on the processor201. The processor201makes the communication control device204or the input interface205operate in accordance with the program, and reads and writes data to and from the main storage device202or the auxiliary storage device203.

The hardware configuration of a computer that constitutes a database is not limited to the above examples. For example, the primary database10, the intermediate database20, and the end database30may have the same hardware configuration or different hardware configurations.

A program causing a computer to function as the primary database10, the intermediate database20, or the end database30may be provided in the form of being recorded in a static manner on a tangible recording medium such as CD-ROM, DVD-ROM or semiconductor memory, for example. Alternatively, the program may be provided as a data signal superimposed onto a carrier wave through a communication network.

Each database may be composed of a single computer100or200or may be composed of a plurality of computers100or200. In the case of using a plurality of computers100or200, those computers100or200are connected through a communication network such as the Internet or an intranet, and thereby one database is logically constructed.

FIG. 8is a view showing an example of the functional structure of each database, Hereinafter, the common master table40and the virtual data table50are denoted by different reference numerals among the primary database10, the intermediate database20, and the end database30as shown inFIG. 8according to need.

The primary database10includes a table management unit11and a search unit12as functional elements. The table management unit11is a functional element that manages a table in the hierarchical database2. The search unit12is a functional element that searches for sensor data according to a query and outputs a search result onto a virtual data table51.

The intermediate database20includes a table management unit21and a data relay unit22. The table management unit21is a functional element that manages a table in the intermediate database20. The data relay unit22is a functional element that acquires data from a database in the immediately lower level for search and outputs the acquired data to a database in the immediately higher level by using a virtual data table52.

The end database30includes a table management unit31and a data extraction unit32. The table management unit31is a functional element that manages a table in the end database30. The data extraction unit32is a functional element that extracts sensor data based on search criteria and outputs the extracted data to a database in the immediately higher level by using the actual data table60.

System Operation

An example of the operation of the database management system1when adding a new database to the hierarchical database2is described hereinafter with reference toFIG. 9.FIG. 9is a sequence chart showing an example of adding a database as a process flow S1. InFIG. 9, a database that is newly added is referred to as a “lower-level database”, and a database that is connected to this lower-level database is referred to as a “higher-level database”. The higher-level database is located in a level immediately higher than the level of the lower-level database. The higher-level database is the primary database10or the intermediate database20. The lower-level database is the intermediate database20or the end database30.

In Step S11, the lower-level database is connected to the higher-level database.

In Step S12, the table management unit of the higher-level database transmits a generation notification to the lower-level database in response to this connection. This table management unit generates a generation notification indicating the database ID to be assigned to the lower-level database and information about all of the common master tables40and all of the virtual data tables50implemented in the higher-level database. The information about the common master table contains a table structure, a version number, and master data. The information about the virtual data table contains a table structure. This table management unit transmits the generation notification to the lower-level database.

In Step S13, the table management unit of the lower-level database sets the database ID to the lower-level database, and generates tables in the lower-level database based on the generation notification. This table management unit generates, in the lower-level database, one or more common master tables which are identical to those of the higher-level database and one or more data tables whose data structure is identical to those of the higher-level database. If the lower-level database is the intermediate database20, the virtual data table50is generated, and if the lower-level database is the end database30, the actual data table60is generated.

A specific example of adding a new database is described hereinafter with reference toFIGS. 10 and 11.FIG. 10is a view showing a specific example of adding a database.FIG. 11is a sequence chart showing an example of the operation of the database management system1corresponding to this addition as a process flow S2. As shown inFIG. 10, in this example, an intermediate database (B) is first connected to a primary database (A), then an end database (C) is connected to the intermediate database (B), and finally an end database (D) is connected to the primary database (A).

The process flow S2corresponding to this series of connections is performed as follows. In Step S21, the process flow S1is performed between the primary database (A) and the intermediate database (B). As a result, the intermediate database (B) includes one or more common master tables40which are identical to those of the primary database (A) and one or more virtual data tables50whose data structure is identical to those of the primary database (A).

In Step S22, the process flow S1is performed between the intermediate database (B) and the end database (C). As a result, the end database (C) includes one or more common master tables40which are identical to those of the intermediate database (B) and one or more actual data tables60whose data structure is identical to those of the intermediate database (B).

In Step S23, the process flow S1is performed between the primary database (A) and the end database (D). As a result, the end database (D) includes one or more common master tables40which are identical to those of the primary database (A) and one or more actual data tables60whose data structure is identical to those of the primary database (A).

As shown in the process flow S2, when a new database (lower-level database) is added to the hierarchical database2, a database (higher-level database) in the immediately higher level transmits a generation notification to the lower-level database in response to this addition. Based on this generation notification, the lower-level database generates the common master table40and the data table (the virtual data table50or the actual data table60) corresponding to that of the higher-level database.

An example of adding a new database may be processing of connecting a database that has previously been an element of the hierarchical database2to the hierarchical database2again. In this case, the table management unit in the higher-level database transmits a generation notification to the added lower-level database in response to this connection. The table management unit in the lower-level database compares the common master table and the data table stored before the connection with the common master table and the data table indicated by the generation notification. Then, the table management unit in the lower-level database regenerates, based on the generation notification, the table whose current structure indicated by the generation notification is different from the structure before the connection, and deletes the table which does not exist in the current structure. This series of process steps allow the lower-level database to function as one functional element of the hierarchical database2again.

An example of a table update process in the database management system1is described hereinafter with reference toFIGS. 12 to 14.FIG. 12is a flowchart showing the operation of the primary database10as a process flow S3.FIG. 13is a flowchart showing the operation of the intermediate database20as a process flow S4.FIG. 14is a flowchart showing the operation of the end database30as a process flow S5.

The operation of the primary database10is as follows. In Step S31, the table management unit11updates at least one table. This processing includes at least one of update of the common master table41and update of the virtual data table51. The update of the common master table is to change at least one of the table structure and the master data. When updating one or more common master tables41, the table management unit11changes the version number of each of the updated common master tables41to a new number that has not been used before. The update of the virtual data table is to change the table structure. In Step S32, the table management unit11transmits an update notification to all databases in the immediately lower level. The table management unit11generates an update notification indicating information about at least one updated table and transmits this update notification. In the case where the common master table41is updated, the update notification contains the table structure, the version number, and the master data of the updated common master table41. In the case where the virtual data table51is updated, the update notification contains the table structure of the updated virtual data table51.

The operation of the intermediate database20is as follows. In Step S41, the table management unit21receives the update notification from a database in the immediately higher level (the primary database10or the intermediate database20). In Step S42, the table management unit21updates at least one table based on this update notification and thereby maintains all of the common master tables42and all of the virtual data tables52in the intermediate database20to be identical to those of the database in the immediately higher level. In Step S43, the table management unit21transmits the update notification to all databases in the immediately lower level. This update notification corresponds to the one received in Step S41, and therefore this transmission can be regarded as the transfer of the update notification.

The operation of the end database30is as follows. In Step S51, the table management unit31receives the update notification from a database in the immediately higher level (the primary database10or the intermediate database20). In Step S52, the table management unit31updates at least one table based on this update notification and thereby maintains all of the common master tables43and all of the actual data tables60in the end database30to be identical to those of the database in the immediately higher level.

A specific example of table update is described hereinafter with reference toFIGS. 10 and 15.FIG. 15is a sequence chart showing a specific example of update of tables in the hierarchical database2composed of four databases shown inFIG. 10, as a process flow S6.

In Step S61, the table management unit11of the primary database (A) updates a table (at least one of the common master table41and the virtual data table51). In Step S62, the table management unit11transmits an update notification to all databases in the immediately lower level, i.e., the intermediate database (B) and the end database (D). The processing in Steps S61and S62corresponds to that in the process flow S3.

In Step S63, the table management unit21of the intermediate database (B) updates one or more tables (at least one of the common master table42and the virtual data table52) based on this update notification. Step S63corresponds to Step S42.

In Step S64, the table management unit31of the end database (D) updates one or more tables (at least one of the common master table43and the actual data table60) based on this update notification. Step S64corresponds to Step S52.

In Step S65, the table management unit21of the intermediate database (B) transmits (transfers) the update notification to the end database (C). Step S65corresponds to Step S43.

In Step S66, the table management unit31of the end database (C) updates one or more tables (at least one of the common master table43and the actual data table60) based on this update notification. Step S66corresponds to Step S52.

As shown in the process flow S6, when at least one table is updated in the primary database10, the update notification is transferred toward each end database30, and this update is reflected in each database. This processing allows each of the common master tables40, the virtual data tables50, and the actual data tables60to be identical in the hierarchical database2.

The deletion of a table can be performed by the same procedure as the update of a table. The table management unit11of the primary database (A) deletes at least one table (at least one of the common master table41and the virtual data table51), and transmits a deletion notification indicating this deletion to the database in the immediately lower level (the lower-level database). When the lower-level database is the intermediate database20, the table management unit21deletes at least one table indicated by this deletion notification, and transmits this deletion notification to the database in the immediately lower level. When the lower-level database is the end database30, the table management unit31deletes at least one table indicated by this deletion notification.

An example of a search process in the database management system1is described hereinafter with reference toFIGS. 16 to 18.FIG. 16is a flowchart showing the operation of the primary database10as a process flow S7.FIG. 17is a flowchart showing the operation of the intermediate database20as a process flow S8.FIG. 18is a flowchart showing the operation of the end database30as a process flow S9.

The operation of the primary database10is as follows. In Step S71, the search unit12acquires a query. The query is a request for data operations on a database, and it is typically represented by a character string in a language such as SQL. It is assumed in this example that the query requests a search for data. A method of acquiring a query is not limited. For example, the search unit12may receive a query that is input by a user, may receive a query from another computer, or may read a query previously stored in a storage unit such as the auxiliary storage unit203.

In Step S72, the search unit12transmits a search instruction to all databases in the immediately lower level. The search instruction is an instruction signal for obtaining a result set containing a combination of an intermediate result based on sensor data and a path ID. The intermediate result is a search result in databases in the immediately lower level. The path ID is represented by using one or more database IDs corresponding to one or more databases on the path.

In Step S73, the search unit12receives a result set from all databases in the immediately lower level. Each database in the immediately lower level sends a result set in response to the search instruction to the primary database10. Thus, the result set is a response signal to the search instruction. When a result set is not received from at least one database in the immediately lower level within a specified period of time after transmission of a search instruction, the search unit12may forcibly quit waiting for reception and perform the subsequent processing, determining that the result set does not exist.

In Step S74, the search unit12represents, by the virtual data table51, a search result on the basis of the received result set. This means that the search result is represented as data in the virtual data table51. When representing the search result, the search unit12may refer to the common master table41and combine the result set and the master data.

In Step S75, the search unit12outputs this search result, i.e., the search result represented by the virtual data table51. A method of outputting the search result is not limited. For example, the search unit12may display the search result on a monitor, transmit it to another computer, store it in a storage device, or use it for the subsequent processing.

The operation of the intermediate database20is as follows. In Step S81, the data relay unit22receives a search instruction from a database in the immediately higher level (the primary database10or the intermediate database20). In Step S82, the data relay unit22transmits this search instruction to all databases in the immediately lower level (the intermediate database20or the end database30). In other words, the data relay unit22transfers the search instruction from the higher-level database to the lower-level database.

In Step S83, the data relay unit22receives a result set from all databases in the immediately lower level. Each database in the immediately lower level sends a result set to the intermediate database20in response to the search instruction. Thus, the result set is a response signal to the search instruction. When a result set is not received from at least one database in the immediately lower level within a specified period of time after transmission of a search instruction, the data relay unit22may forcibly quit waiting for reception and perform the subsequent processing, determining that the result set does not exist.

In Step S84, the data relay unit22edits the path ID of each result set by using the database ID assigned to the intermediate database20. Each path ID is represented by using the database ID of one or more lower-level databases on one path from one end database30to this intermediate database20. In one example, the path ID is represented as a character string generated by joining one or more database IDs according to the sequence of databases on the path. In one example, the data relay unit22joins the assigned database ID with the path ID of the result set and thereby edits this path ID. For example, it is assumed that the database ID of the intermediate database20is “0010”, and the intermediate database20with the database ID “0003” is located in the immediately lower level, and further the end database30with the database ID “0002” is located in the level immediately lower than that level. In this case, the path ID of the result set can be “00030002” or “00020003”. When the path ID is “00030002”, the data relay unit22puts “0010” at the head of this character string and thereby changes the path ID to “001000030002”. When the path ID is “00020003”, the data relay unit22puts “0010” at the end of this character string and thereby changes the path ID to “000200030010”. In this manner, the data relay unit22may join the assigned database ID with the path ID of the result set according to the sequence of databases on the path and thereby edit this path ID.

In Step S85, the data relay unit22integrates one or more result sets, and represents the integrated result set by the virtual data table51. The integration of result sets is processing that generates one result set based on a collection of one or more result sets. The integrated result set is represented as an intermediate result by the virtual data table52. The integrated result set contains the edited path ID. When representing a search result, the data relay unit22may refer to the common master table42and combine the result set and the master data.

In Step S86, the data relay unit22transmits the integrated result set to the database in the immediately higher level. The transmission may be regarded as a response signal to the search instruction received in Step S81.

The operation of the end database30is as follows. In Step S91, the data extraction unit32receives a search instruction from a database in the immediately higher level (the primary database10or the intermediate database20).

In Step S92, the data extraction unit32searches for sensor data based on the search instruction.

In Step S93, the data extraction unit32sets the path ID by using the database ID assigned to the end database30. In one example, data extraction unit32sets the database ID as the path ID.

In Step S94, the data extraction unit32represents, by the actual data table60, the result set containing a combination of the extracted sensor data (i.e., search result) and the path ID. When representing the search result, the data extraction unit32may refer to the common master table43and combine the result set and the master data.

In Step S95, the data extraction unit32transmits the result set to the database in the immediately higher level. This transmission may be regarded as a response signal to the search instruction received in Step S91.

A specific example of a search is described hereinafter with reference toFIG. 19.FIG. 19is a view showing a specific example of a search by the database management system1. In this example, an intermediate database (B), an intermediate database (C), and an end database (D) are connected in a level immediately lower than the level of a primary database (A). An end database (E) and an end database (F) are connected in a level immediately lower than the level of the intermediate database (B). An intermediate database (G) is connected in a level immediately lower than the level of the intermediate database (C). An end database (H) and an end database (I) are connected in a level immediately lower than the level of the intermediate database (G). InFIG. 19, database IDs are shown in parentheses (“(0001)”, “(0002)”, etc.).

It is assumed that the search unit12of the primary database (A) acquires the query “SELECT R_ID, value FROM V_TBL” under circumstances where sensor data is stored in each end database, as shown inFIG. 19. The character string “R_ID” indicates the path ID, and the character string “V_BL” indicates the name of the virtual data table51. In response to this query, a search instruction is passed from the primary database (A) to each end database30along the paths, and a result set is passed from each end database30to the primary database (A). In this example, the intermediate database20puts the assigned database ID at the head of the path ID and thereby edits this path ID. Finally the search unit12represents, by the virtual data table51, a final search result composed of 10 records, and outputs this search result.

Another specific example of a search is described hereinafter with reference toFIG. 20.FIG. 20is a view showing another specific example of a search in the database management system1. The hierarchical structure of the hierarchical database2is the same as that ofFIG. 19. It is assumed that the search unit12of the primary database (A) acquires the query “SELECT R_ID, value FROM V_TBL ORDER BY value DESC LIMIT 2” under circumstances where sensor data is stored in each end database, as shown inFIG. 20, The character string “V_TBL” indicates the name of the virtual data table51. This query means the operation of extracting the top two values when arranged in descending order. In response to this query, a search instruction is passed from the primary database (A) to each end database30along the paths, and a result set is passed from each end database30to the primary database (A). In this example, there is a possibility that the search unit12receives a result set that corresponds only to some of the end databases30from databases in the immediately lower level. A method of editing the path ID is the same as in the example ofFIG. 19. InFIG. 20, records to be passed to databases in the immediately higher level are shown as shaded. The search unit12represents, by the virtual data table51, a final search result composed of two records corresponding to the top two values in the hierarchical database2, and outputs this search result. Since only necessary data is transmitted to the higher-level database, the traffic and processing load in the hierarchical database2are reduced as a whole.

FIGS. 19 and 20both show the search result represented by the virtual data table51of the primary database10, the result set (intermediate result) represented by the virtual data table52of the intermediate database20, and the result set represented by the actual data table60of the end database30. In both examples ofFIGS. 19 and 20, the primary database (A) is able to identify where each record is generated and through what path it has been sent by referring to the path ID. For example, in the example ofFIG. 20, it is identified that the top two values in the hierarchical database2are obtained from the end DB (D) and the end DB (I).

Although each records contains the path ID in the examples ofFIGS. 19 and 20, a method of associating the path ID with a search result or an intermediate result is not limited. Accordingly, the data structure of a result set and a method for representing a result set are not limited. For example, the path ID may be represented by a data structure different from a record of a search result or an intermediate result.

Advantageous Effects

As described above, a database management system according to one aspect of the present disclosure includes at least one processor configured to control a hierarchical database including a plurality of end databases, each connected to a sensor, and a primary database directly or indirectly connected to the plurality of end databases. Each of the plurality of end databases stores sensor data based on a signal from the sensor. The primary database provides a virtual data table representing a search result based on the sensor data. The at least one processor performs: acquiring a query for obtaining the search result; transmitting a search instruction corresponding to the query to at least one end database among the plurality of end databases, the search instruction being an instruction signal for obtaining a result set containing a combination of an intermediate result based on the sensor data and a path ID being an identifier for uniquely identifying a path connecting the primary database and the end database; receiving at least one result set corresponding to the at least one end database; representing the search result based on the at least one result set by the virtual data table; and outputting the search result represented by the virtual data table.

A database management method according to one aspect of the present disclosure is performed by a database management system configured to control a hierarchical database including a plurality of end databases, each connected to a sensor, and a primary database directly or indirectly connected to the plurality of end databases. Each of the plurality of end databases stores sensor data based on a signal from the sensor. The primary database provides a virtual data table representing a search result based on the sensor data. The database management method includes: acquiring a query for obtaining the search result; transmitting a search instruction corresponding to the query to at least one end database among the plurality of end databases, the search instruction being an instruction signal for obtaining a result set containing a combination of an intermediate result based on the sensor data and a path ID being an identifier for uniquely identifying a path connecting the primary database and the end database; receiving at least one result set corresponding to the at least one end database; representing the search result based on the at least one result set by the virtual data table; and outputting the search result represented by the virtual data table.

A database management program according to one aspect of the present disclosure causes a computer to function as a database management system configured to control a hierarchical database including a plurality of end databases, each connected to a sensor, and a primary database directly or indirectly connected to the plurality of end databases. Each of the plurality of end databases stores sensor data based on a signal from the sensor. The primary database provides a virtual data table representing a search result based on the sensor data. The database management program causes the computer to perform: acquiring a query for obtaining the search result; transmitting a search instruction corresponding to the query to at least one end database among the plurality of end databases, the search instruction being an instruction signal for obtaining a result set containing a combination of an intermediate result based on the sensor data and a path ID being an identifier for uniquely identifying a path connecting the primary database and the end database; receiving at least one result set corresponding to the at least one end database; representing the search result based on the at least one result set by the virtual data table; and outputting the search result represented by the virtual data table.

According to this aspect, sensor data corresponding to a query is collected in the primary database together with a path ID indicating a path connecting the primary database and the end database, and a search result based on this collected sensor data is represented by the virtual data table and output. Since actual sensor data is stored only in the end database, and the primary database represents the search result by the virtual data table, a storage area for storing the actual sensor data is reduced as a whole in the hierarchical database. Further, a source of sensor data, i.e., an information source, is identifiable by the path ID. This architecture enables efficient operations on sensor data.

In the database management system according to another aspect, the path ID may be a character string created using a database ID of the at least one end database. Use of an already existing database ID enables easy generation of a unique path ID.

In the database management system according to another aspect, the hierarchical database may further include an intermediate database located on a path from the primary database to the end database. Providing the intermediate database allows flexible construction of the hierarchical database. Further, since processing is distributed between the intermediate database and the primary database, processing load on the primary database is reduced.

In the database management system according to another aspect, when at least one intermediate database is located on the path, the path ID may be a character string created using a database ID of the end database and each database ID of the at least one intermediate database. Use of an already existing database ID enables easy generation of a unique path ID.

In the database management system according to another aspect, the path ID may be a character string generated by joining a database ID of the end database and each database ID of the at least one intermediate database according to sequence of databases on the path. Joining already existing database IDs according to the tree structure of the hierarchical database enables easy generation of a unique path ID.

In the database management system according to another aspect, all of the primary database, the plurality of end databases, and the intermediate database may include a common master table for storing information necessary for control of the hierarchical database. The common master table may be identical among the primary database, the plurality of end databases, and the intermediate database. The common master table may be associated with a version number indicating a stage of a change in table. Associating a version number with the common master table ensures that the common master table is identical in all databases in the hierarchical database.

In the database management system according to another aspect, each of the plurality of end databases may store the sensor data by using a cyclic table. Use of the cyclic table enables efficient storage of data necessary for processing and reduction of storage capacity needed for the end database.

Modified Example

An embodiment of the present disclosure is described in detail above. However, the present disclosure is not limited to the above-described embodiment. Various changes and modifications may be made to the present disclosure without departing from the scope of the disclosure.

In the above-described embodiment, all databases in the hierarchical database2include the common master table40. Note that, however, the common master table is not an essential element and may be omitted.

In the present disclosure, the description “at least one processor performs the first processing, performs the second processing, . . . , and performs the n-th processing” or the description corresponding thereto indicates a concept including the case where an entity (i.e., a processor) of performing n number of process steps from the first processing to the n-th processing changes during the process. Specifically, this description indicates a concept including both of the case where each processing is performed by the same processor during all of n number of process steps and the case where a processor changes by an arbitrary policy during the n number of process steps.

Further, the procedure of a method that is performed by at least one processor is not limited to the example shown in the above-described embodiment. For example, some of the above-described steps may be omitted, or the steps may be carried out in a different order. Further, any two or more steps of the above-described steps may be combined, or some of the steps may be modified or eliminated. Alternatively, another step may be performed in addition to the above-described steps.

In the comparison of two numerical values, any of the two criteria “equal to or more than” and “more than” may be used, and any of the two criteria “equal to or less than” and “less than” may be used. Selection of the criteria would not change the technical significance regarding the processing of comparing two numerical values.

REFERENCE SIGNS LIST