JP7740367B2 - Database management device, database management method and database management program - Google Patents

Description

The present invention relates to a database management device, a database management method, and a database management program.

In the development of information systems, it is necessary for applications to quickly access databases and respond to data tampering. In recent years, in addition to traditional relational databases (RDBs), graph databases (graph DBs), which can more quickly obtain interconnections between data, have been attracting attention as a data reference source (see Patent Document 1 and Non-Patent Document 1). However, because graph DBs are specialized for graphical display, they are not a substitute for RDBs. In other words, RDBs and graph DBs are different types of databases and will coexist.

Japanese Patent Application Laid-Open No. 2014-229276

Masashi Sugimoto and three others, "Proposal of a Real-Time Synchronization Method for Relational Databases and Graph Databases," IEICE Technical Report, ICM2020-78, Institute of Electronics, Information and Communication Engineers, March 18, 2021, pp. 104-109

However, with conventional technology, an environment in which databases with different characteristics, such as RDBs and graph DBs, coexisted hindered application development. For example, when an RDB and a graph DB coexisted, the database data layout was disorganized and not necessarily organized, depending on whether the data attributes were read-only or updated. This resulted in complex schemas and hindered application development.

The present invention has been made in consideration of the above, and aims to realize a database that can improve the efficiency of application development in an environment where databases with different characteristics coexist.

In order to solve the above-mentioned problems and achieve the objectives, the database management device of the present invention is characterized by having an acquisition unit that acquires data, a separation unit that separates each area of a database with different storage characteristics into an area that allows data to be referenced and an area that allows data to be updated, and a classification unit that classifies and stores the acquired data in the separated areas according to the attributes of the data.

According to the present invention, it is possible to realize a database that can improve the efficiency of application development in an environment where databases with different characteristics coexist.

FIG. 1 is a diagram for explaining an overview of a database management device. FIG. 2 is a schematic diagram illustrating the general configuration of a database management device. FIG. 3 is a diagram for explaining the processing of the unit. FIG. 4 is a flowchart showing the procedure of the database management process. FIG. 5 is a diagram illustrating a computer that executes a database management program.

One embodiment of the present invention will be described in detail below with reference to the drawings. Note that the present invention is not limited to this embodiment. In addition, in the drawings, identical parts are designated by the same reference numerals.

[Database Management Device Overview]
1 is a diagram for explaining an overview of a database management device. As shown in Fig. 1, in an environment where different types of databases with different database characteristics, such as an RDB and a graph DB, coexist, the database management device of this embodiment separates the areas of each database into a reference system and an update system.

Here, the reference system is an area that stores data referenced by an application. The update system is an area that stores data that allows applications to update data. In the example shown in Figure 1, the RDB is separated into an RDB reference system 14a and an RDB update system 14b, and the graph DB is separated into a graph DB reference system 14c and a graph DB update system 14d.

In this way, a multi-layer database with reference and update systems is configured within the database. This allows application developers to easily understand the internal structure of the database, improving development efficiency and shortening development time.

In addition, by placing data in the graph DB reference system and the graph DB update system, it is possible to speed up processing specialized for graphic display.

In addition, NoSQL databases, including graph DBs, generally have insufficient transaction management implementation due to the emphasis on performance, but the transaction management of the graph DB is complemented by the transaction management of the coexisting RDB, thereby strengthening data reliability.

In addition, by only targeting the updated system when backing up the configured database, backup and recovery times can be shortened.

[Configuration of database management device]
2 is a schematic diagram illustrating the overall configuration of a database management device 10. As illustrated in FIG. 2, the database management device 10 is realized by a general-purpose computer such as a personal computer, and includes an input unit 11, an output unit 12, a communication control unit 13, a storage unit 14, and a control unit 15.

The input unit 11 is realized using input devices such as a keyboard and a mouse, and inputs various instruction information, such as starting processing, to the control unit 15 in response to input operations by the operator. The output unit 12 is realized by a display device such as an LCD display, a printing device such as a printer, etc.

The communication control unit 13 is realized by a NIC (Network Interface Card) or the like, and controls communication between the control unit 15 and external devices such as servers via a network. For example, the communication control unit 13 controls communication between the control unit 15 and database devices of other systems that manage data used in the database management processing described below, or user terminals on which applications are installed.

The memory unit 14 is realized by a semiconductor memory element such as RAM (Random Access Memory) or flash memory, or a storage device such as a hard disk or optical disk. The memory unit 14 pre-stores the processing programs that operate the database management device 10 and data used during execution of the processing programs, or temporarily stores them each time processing is performed. The memory unit 14 may also be configured to communicate with the control unit 15 via the communication control unit 13.

In this embodiment, the memory unit 14 stores an RDB reference system 14a, an RDB update system 14b, a graph DB reference system 14c, and a graph DB update system 14d, which are generated in the database management process described below, and are used by applications as databases.

The control unit 15 is implemented using a CPU (Central Processing Unit) or the like, and executes processing programs stored in memory. As a result, the control unit 15 functions as an acquisition unit 15a, a separation unit 15b, and a classification unit 15c, as illustrated in FIG. 2. Note that each or some of these functional units may be implemented in different hardware. For example, the separation unit 15b may be implemented in a device separate from the other functional units. The control unit 15 may also include other functional units.

The acquisition unit 15a acquires data. For example, the acquisition unit 15a acquires data used in the database management process described below from the database of another system via the input unit 11 or the communication control unit 13. Specifically, the acquisition unit 15a replicates the database of the other system using a snapshot. The acquisition unit 15a may also store the acquired data in the memory unit 14 as master data or initial data. The acquisition unit 15a may also transfer this data to the classification unit 15c described below without storing it in the memory unit 14.

The separation unit 15b separates each area of databases with different characteristics in the storage unit 14 into a reference system area that references data and an update system area that allows data updates. Specifically, the separation unit 15b separates each of the RDB and graph DB areas in the storage unit 14 into a reference system area that references data and an update system area that allows data updates. As a result, the separation unit 15b generates areas in the storage unit 14, for example, an RDB reference system 14a, an RDB update system 14b, a graph DB reference system 14c, and a graph DB update system 14d.

The classification unit 15c classifies and stores the acquired data in separate areas according to the attributes of the data. Here, the attributes of the data include, for example, whether the data is to be referenced or updated. The classification unit 15c then stores the acquired data in one of the RDB reference system 14a, RDB update system 14b, graph DB reference system 14c, and graph DB update system 14d according to the attributes of each data.

For example, the classification unit 15c stores the acquired data, which is represented as nodes and relationships between nodes, in either the graph DB reference system 14c or the graph DB update system 14d, which are separated within the graph DB area.

Here, Figure 3 is a diagram for explaining the processing of the classification unit. As shown in Figure 3, the classification unit 15c classifies and stores data acquired from the databases of other systems into an RDB reference system 14a, an RDB update system 14b, a graph DB reference system 14c, and a graph DB update system 14d according to the attributes of each data.

Specifically, the classification unit 15c replicates the data acquired by the acquisition unit 15a from the other system DB as a snapshot (Figure 3(1)) and first stores it in the RDB reference system 14a. Next, the classification unit 15c moves independently managed data, such as key values to be updated, from the RDB reference system 14a to the RDB update system 14b (Figure 3(2)), excluding data to be stored in the graph DB, such as data represented by the relationships between nodes.

The classification unit 15c also classifies data stored in the graph DB, such as data expressed as relationships between nodes, into either the graph DB reference system 14c or the graph DB update system 14d. Data expressed as relationships between nodes is data that can be illustrated in a line diagram or network form, such as the coordinates of point facilities such as manholes and utility poles, and the span lengths between point facilities such as conduits, pipelines, and cables.

The classification unit 15c moves the data to be referenced, among the data stored in the graph DB, from the RDB reference system 14a to the graph DB reference system 14c (Figure 3 (3)). Furthermore, the classification unit 15c moves the data to be updated, among the data stored in the graph DB, from the RDB reference system 14a to the graph DB update system 14d (Figure 3 (5)). For example, the graph DB update system 14d stores attribute values such as material and construction year for point equipment and spans, as well as service-related key values.

Furthermore, if there is data in the RDB update system 14b that is expressed as relationships between nodes and has an attribute value to be updated, the classification unit 15c moves it from the RDB update system 14b to the graph DB update system 14d (Figure 3 (6)).Furthermore, if there is an attribute value to be updated in the data in the graph DB reference system 14c, the classification unit 15c moves it from the graph DB reference system 14c to the graph DB update system 14d (Figure 3 (4)).

In this way, multiple layers of reference and update systems are configured within the RDB and graph DB, respectively (see Figure 3 (2) and (4)). This improves the efficiency of application development. Furthermore, by separating data from the RDB and storing it in the graph DB reference system 14c and graph DB update system 14d (see Figure 3 (3), (5), and (6)), it becomes possible to speed up processing specialized for graphic display.

Furthermore, with the memory unit 14 configured in this manner as a database, for example, an application that displays graphs can access the graph DB reference system 14c and the graph DB update system 14d (Figures 3 (7) and (8)). Furthermore, an application that displays data can access the RDB reference system 14a and the RDB update system 14b (Figures 3 (9) and (10)).

In this way, by using the storage unit 14 as a database, the areas to be processed by applications that access the database are clearly defined, making application development easier and shortening development time. Furthermore, by limiting backup operations during database operation to the update system only, it is possible to shorten the time required for backup and restoration operations.

[Database management process]
Next, the database management process performed by the database management device 10 according to this embodiment will be described with reference to Fig. 4. Fig. 4 is a flowchart showing the procedure of the database management process. The flowchart of Fig. 4 starts, for example, when an operation input is made to instruct the start of the database management process.

First, the acquisition unit 15a acquires data from a database of another system, etc. (step S1).

Next, the separation unit 15b separates each area of the database with different characteristics in the memory unit 14 into a reference-system area that allows data to be referenced and an update-system area that allows data to be updated (step S2).

Specifically, the separation unit 15b separates the RDB and graph DB areas of the storage unit 14 into a reference system area that allows data to be referenced and an update system area that allows data updates. As a result, the separation unit 15b generates areas in the storage unit 14, for example, an RDB reference system 14a, an RDB update system 14b, a graph DB reference system 14c, and a graph DB update system 14d.

The classification unit 15c then classifies and stores the acquired data in separate areas according to attributes such as the data's reference target/update target (step S3). For example, the classification unit 15c stores the acquired data in one of the RDB reference system 14a, the RDB update system 14b, the graph DB reference system 14c, and the graph DB update system 14d.

For example, the classification unit 15c stores the acquired data, which is represented by nodes and their relationships, in either the graph DB reference system 14c or the graph DB update system 14d, which are separated within the graph DB area. This completes the series of database management processes.

[effect]
As described above, in the database management device 10, the acquisition unit 15a acquires data. The separation unit 15b separates each area of the database with different characteristics in the storage unit 14 into a reference-system area that allows data to be referenced and an update-system area that allows data to be updated. The classification unit 15c classifies and stores the acquired data in the separated areas according to the attributes of the data.

This allows the database management device 10 to configure multiple layers of reference and update systems within the database. This allows application developers to easily understand the internal structure of the database, improving development efficiency and shortening development time. In this way, it is possible to create a database that can improve the efficiency of application development in an environment where heterogeneous databases such as RDBs and graph DBs coexist.

Specifically, the separation unit 15b separates the RDB and graph DB areas of the storage unit 14 into a reference area that allows data to be referenced and an update area that allows data updates. While NoSQL databases, including graph DBs, generally have insufficient transaction management due to their emphasis on performance, this arrangement strengthens data reliability by complementing the transaction management of the graph DB with the transaction management of the coexisting RDB.

The classification unit 15c also stores the acquired data, which is expressed as relationships between nodes, in either the graph DB reference system 14c or the graph DB update system 14d, which are separated from the RDB. By separating the data from the RDB and storing it in the graph DB reference system 14c and the graph DB update system 14d, it is possible to speed up processing specialized for graphical display.

[program]
A program written in a computer-executable language may be created to execute the processes executed by the database management device 10 according to the above embodiment. In one embodiment, the database management device 10 can be implemented by installing a database management program that executes the above database management processes as package software or online software on a desired computer. For example, by executing the database management program on an information processing device, the information processing device can function as the database management device 10. Other examples of information processing devices include mobile communication terminals such as smartphones, mobile phones, and PHS (Personal Handyphone Systems), as well as slate terminals such as PDAs (Personal Digital Assistants). The functions of the database management device 10 may also be implemented on a cloud server.

Figure 5 shows an example of a computer that executes a database management program. The computer 1000 has, for example, memory 1010, a CPU 1020, a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These components are connected by a bus 1080.

The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012. The ROM 1011 stores a boot program such as a BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to a hard disk drive 1031. The disk drive interface 1040 is connected to a disk drive 1041. A removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1041. The serial port interface 1050 is connected to, for example, a mouse 1051 and a keyboard 1052. The video adapter 1060 is connected to, for example, a display 1061.

Here, the hard disk drive 1031 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. Each piece of information described in the above embodiment is stored, for example, in the hard disk drive 1031 or memory 1010.

The database management program is stored on the hard disk drive 1031, for example, as a program module 1093 that describes instructions to be executed by the computer 1000. Specifically, the program module 1093 that describes each process executed by the database management device 10 described in the above embodiment is stored on the hard disk drive 1031.

In addition, data used for information processing by the database management program is stored, for example, on the hard disk drive 1031 as program data 1094. The CPU 1020 then reads the program module 1093 and program data 1094 stored on the hard disk drive 1031 into the RAM 1012 as needed, and executes each of the procedures described above.

The program module 1093 and program data 1094 related to the database management program are not limited to being stored on the hard disk drive 1031, but may be stored, for example, on a removable storage medium and read by the CPU 1020 via the disk drive 1041, etc. Alternatively, the program module 1093 and program data 1094 related to the database management program may be stored in another computer connected via a network such as a LAN (Local Area Network) or WAN (Wide Area Network), and read by the CPU 1020 via the network interface 1070.

The above describes an embodiment of the invention made by the inventor, but the present invention is not limited to the descriptions and drawings that form part of the disclosure of the present invention according to this embodiment. In other words, all other embodiments, examples, operational techniques, etc. made by those skilled in the art based on this embodiment are included in the scope of the present invention.

REFERENCE SIGNS LIST 10 Database management device 11 Input unit 12 Output unit 13 Communication control unit 14 Storage unit 14a RDB reference system 14b RDB update system 14c Graph DB reference system 14d Graph DB update system 15 Control unit 15a Acquisition unit 15b Separation unit 15c Classification unit

Claims (4)

an acquisition unit for acquiring data;
a separation unit that separates each of the areas of the relational database and the graph database in the storage unit into an area that allows data to be referenced and an area that allows data to be updated;
a classification unit that classifies and stores the acquired data into the separated areas according to the attributes of the data. The database management device according to claim 1, characterized in that the classification unit stores, of the acquired data, data represented by nodes and relationships between the nodes in one of the separated areas of the graph database. A database management method executed by a database management device having a storage unit, comprising:
an acquisition step of acquiring data;
a separation step of separating each of the areas of the relational database and the graph database in the storage unit into an area for referencing data and an area for allowing data updates;
a classification step of classifying and storing the acquired data into the separated areas according to the attributes of the data;
A database management method comprising: an acquisition step for acquiring data;
a separation step of separating each of the areas of the relational database and the graph database in the storage unit into an area for referencing data and an area for allowing data updates;
a classification step of classifying and storing the acquired data into the separated areas according to attributes of the data;
A database management program that allows a computer to execute the above.