Apparatus and method for semantic integration and virtualization of heterogeneous databases

Abstract

The present invention relates to a semantic integration virtualization device for heterogeneous databases. More specifically, a virtualization device for semantic integration of heterogeneous databases according to the present disclosure comprises: a plurality of source relational databases having different schemas and physically distributed; an ontology for semantically defining and integrating data stored in the plurality of source relational databases; and a semantic-based integration virtualization system located between the source relational databases and the ontology. The semantic-based integration virtualization system comprises: a schema collection unit that collects DB schema information from the source relational databases and collects ontology schema information from the ontology; a schema mapping unit that semantically connects table columns of the collected DB schemas with attributes of the ontology schema; and an SQL query generation unit that generates an SQL query statement for extracting data from the source relational databases when querying the ontology concept based on the mapped relationship. It may include: an OBDA mapping table generation unit that generates an OBDA (Ontology-Based Data Access) mapping table that mutually binds the target and the source by targeting the concept of the above-mentioned ontology and using the above-mentioned generated SQL query statement as a source; a VKG loading unit that loads the above-mentioned ontology schema and the above-mentioned OBDA mapping table into a graph DB (VKG); and a query processing engine that, upon receiving an ontology-based query from a user, retrieves a corresponding SQL query statement by referencing the OBDA mapping table loaded in the graph DB (VKG), transmits the retrieved SQL query statement to the source relational database for execution, and then integrates and returns the results. Other embodiments are also possible.

Description

Technology Field

[0001] The present disclosure relates to a semantic integration virtualization apparatus and method. More specifically, the present disclosure relates to a semantic integration virtualization apparatus and method for heterogeneous databases. Background Technology

[0002] In various industrial sectors, there may be a need to integrate and utilize data stored in multiple heterogeneous databases that are physically distributed and have different schemas. Particularly in the defense sector, integrating and managing METT-TC (Mission, Enemy, Terrain, Friendly, Time, Civilian) data generated in real-time from multiple sources, such as C4I (Command and Control) systems, sensors, GIS (Geographic Information System), and operational reports, can be important for command decision-making.

[0003] Conventional data integration methods utilize a data warehouse (DW) approach, which replicates data through the Extract, Transform, and Load (ETL) process and loads it into a central repository. However, this method had limitations in that changes to the source data were not reflected in real-time and loading delays occurred because data was replicated and loaded in a batch manner. Furthermore, the process of replicating all data to the central repository could cause system overload and I / O bottlenecks, and multidimensional queries triggered large-scale table scans, resulting in response delays.

[0004] Meanwhile, the aforementioned multiple source databases may be designed with different schemas depending on their creator and purpose of use. In cases where schemas differ in this way, schema-level integration was difficult using existing metadata integration methods.

[0005] To address these issues, a virtualization technology utilizing an ontology that semantically links different schemas can be proposed. However, a method that simply directly links (interlocks) actual data from the source database under the ontology presented another problem: query performance was significantly degraded when users queried based on the ontology.

[0006] Therefore, there is a growing need for a new data integration virtualization technology that can guarantee real-time performance and resolve I / O bottlenecks by not replicating source database data, while also enabling semantic integration of heterogeneous databases with different schemas and resolving the performance degradation issues of simple ontology integration methods, thereby providing fast response speeds without modifying or changing the source database. Prior art literature

[0007] Patent Document: Korean Published Patent Application No. 10-2025-0051556 The problem to be solved

[0008] The present disclosure aims to provide a virtualization device that semantically integrates multiple heterogeneous source relational databases, which are physically distributed and have different schemas and are difficult to interoperate with using conventional metadata integration methods, without physical replication or central loading of data.

[0009] In addition, the present disclosure aims to provide a device that solves the I / O bottlenecks caused by data replication and loading and the batch-dependent data loading delay problems associated with conventional data warehouse (DW) methods, ensures real-time performance by directly querying the source database, and distributes the system load through on-demand queries.

[0010] Furthermore, the present disclosure aims to provide a device that provides a response speed equivalent to or faster than directly querying the source relational database by constructing a Virtual Knowledge Graph (VKG) that binds ontology concepts with SQL query statements of the source database to solve the problem of query performance degradation that occurs when actual data is directly linked to an ontology, and by directly executing the user's ontology query as an automatically rewritten SQL statement in the source DB.

[0011] Furthermore, the present disclosure aims to provide a device that semantically connects all data assets and enables consistent access by analyzing and mapping not only the structured relational database but also unstructured text data, such as military manuals, through an LLM agent to convert them into a knowledge graph, and integrating and loading this into an existing virtual knowledge graph (VKG). means of solving the problem

[0012] A virtualization device for semantic integration of heterogeneous databases according to the present disclosure for achieving the aforementioned technical objectives comprises: a plurality of source relational databases having different schemas and being physically distributed; an ontology for semantically defining and integrating data stored in the plurality of source relational databases; and a semantic-based integration virtualization system located between the source relational databases and the ontology; wherein the semantic-based integration virtualization system comprises: a schema collection unit that collects DB schema information from the source relational databases and collects ontology schema information from the ontology; a schema mapping unit that semantically connects the table columns of the collected DB schemas with the attributes of the ontology schema; an SQL query generation unit that generates an SQL query statement for extracting data from the source relational databases when querying the ontology concept based on the mapped relationship; and an OBDA mapping table generation unit that generates an OBDA (Ontology-Based Data Access) mapping table that targets the concept of the ontology and mutually binds the target and the source using the generated SQL query statement as a source. It may include a VKG loading unit that loads the above-mentioned ontology schema and the above-mentioned generated OBDA mapping table into a graph DB (VKG); and a query processing engine that, upon receiving an ontology-based query from a user, retrieves a corresponding SQL query statement by referencing the OBDA mapping table loaded into the graph DB (VKG), transmits the retrieved SQL query statement to the source relational database for execution, and then integrates and returns the results.

[0013] In addition, since the aforementioned multiple source relational databases have different schemas, schema-level integration may not be possible using existing metadata integration methods.

[0014] In addition, the semantic-based integrated virtualization system may use the OBDA mapping table and the query processing engine to solve the problem of reduced query speed that occurs when the actual data of the source relational database is directly connected to the ontology.

[0015] In addition, the above device can be universally applied to all industrial domains that need to integrate the multiple source relational databases.

[0016] Additionally, the above-mentioned industry domain may be a defense command decision system, and the above-mentioned ontology may semantically define METT-TC data of the defense command decision system.

[0017] In addition, the above multiple source relational databases may include C4I, sensor, GIS, and operation reporting databases containing the METT-TC data.

[0018] In addition, the schema collection unit can collect table names, column names, keys, and index information of the C4I, sensor, GIS, and operation report databases, as well as S / P / O (Subject / Predicate / Object) definitions of the METT-TC ontology, to create an inventory and a catalog.

[0019] In addition, the schema mapping unit semantically connects the table columns of the cataloged DB schema with the attributes and relationships of the ontology schema, and can standardize different data units or coordinate systems.

[0020] In addition, the schema mapping unit can set MGRS (Military Grid Reference System) coordinates based on LOD (Level Of Detail) and map LOD representation columns when mapping terrain data of the GIS database.

[0021] In addition, the SQL query generation unit can generate an SQL query statement as an actual extraction logic to be used for ontology concept inquiry based on the mapping relationship including the LOD setting and MGRS coordinate standard.

[0022] In addition, the SQL query generation unit can generate an SQL query statement including a JOIN statement for an on-demand join between the plurality of source relational databases.

[0023] In addition, the above SQL query generation unit can generate an SQL query statement including a geospatial function for spatial querying the above GIS database.

[0024] In addition, the OBDA mapping table generation unit can generate an OBDA mapping rule table that serves as the basis for automatic SQL rewriting of the ontology query by setting targets for each class, attribute, and relationship of the ontology and binding the columns of the generated SQL query statement as sources.

[0025] In addition, the VKG loading unit may not load the actual data of the source relational database by replicating it, but rather load it onto the graph DB (VKG) using Cypher MERGE syntax by combining the ontology schema and the generated OBDA mapping rule table.

[0026] In addition, the above query processing engine can receive a query from a user for the above graph DB (VKG) written in ontology terms in the format of SPARQL, GraphQL, or Cypher.

[0027] In addition, the query processing engine can analyze the received ontology-based query and retrieve one or more stored SQL query statements corresponding to the ontology query by referring to the OBDA mapping rule table loaded in the graph DB (VKG).

[0028] In addition, the above query processing engine can query real-time data stored in the source relational databases, rather than replicated data in the central repository, in a non-replicating manner by transmitting the retrieved SQL query statements to the corresponding source relational databases and executing them directly.

[0029] In addition, the above query processing engine may not modify or change the data of the source relational database through the above non-replication method query.

[0030] In addition, the above query processing engine can resolve I / O bottlenecks caused by central replication and loading in the Data Warehouse (DW) method and distribute the system load through the above non-replicating on-demand query.

[0031] In addition, the above query processing engine can integrate and reassemble different types of data fragments (Instances) returned from the source relational databases based on the ontology schema and return them to the user as a unified response.

[0032] In addition, the above query processing engine can provide a response speed equivalent to or faster than executing SQL queries directly on the source relational database through the virtualized execution of the above ontology-based query.

[0033] Additionally, an LLM agent may be further included, said LLM agent analyzes unstructured text data and maps it to an ontology schema to generate a knowledge graph, and said generated knowledge graph can be integrated and loaded into said graph DB (VKG).

[0034] A method performed by a virtualization device for semantic integration of heterogeneous databases according to the present disclosure for achieving the technical problem described above, wherein the virtualization device comprises: a plurality of source relational databases having different schemas and being physically distributed; an ontology for semantically defining and integrating data stored in the plurality of source relational databases; and a semantic-based integration virtualization system located between the source relational databases and the ontology; wherein a schema collection unit collects DB schema information from the source relational databases and collects ontology schema information from the ontology; a schema mapping unit semantically connects the table columns of the collected DB schemas with the attributes of the ontology schema; and an SQL query generation unit generates an SQL query statement for extracting data from the source relational databases when querying the ontology concept based on the mapped relationship. The method may include the step of an OBDA mapping table generation unit creating an OBDA (Ontology-Based Data Access) mapping table that mutually binds the target and the source by using the concept of the ontology as a target and the generated SQL query as a source; the step of a VKG loading unit loading the ontology schema and the generated OBDA mapping table into a graph DB (VKG); and the step of a query processing engine, upon receiving an ontology-based query from a user, retrieving a corresponding SQL query by referencing the OBDA mapping table loaded in the graph DB (VKG), transmitting the retrieved SQL query to the source relational database for execution, and then integrating and returning the results.

[0035] In addition to this, a computer-readable recording medium for recording a computer program for implementing the present disclosure may be further provided. Effects of the invention

[0036] According to the aforementioned means for solving the problem of the present disclosure, it is possible to provide the effect of achieving successful data integration by semantically connecting multiple heterogeneous source relational databases, which have different schemas and could not be linked using conventional metadata integration methods, using an ontology.

[0037] According to the aforementioned means for solving the problem of the present disclosure, by adopting a non-replicating virtualization method that directly queries the source relational database (DB Call) rather than replicating and loading data into a central repository as in conventional data warehouse (DW) methods, it is possible to resolve the data loading latency problem and provide the effect of always being able to query the latest real-time data.

[0038] According to the aforementioned means for solving the problem of the present disclosure, large-scale input / output (I / O) bottlenecks occurring during the data replication and loading process can be fundamentally eliminated. In addition, by processing user queries on an on-demand basis and distributing SQL queries to each source database, the effect of effectively distributing the system load concentrated on the central server can be provided.

[0039] According to the aforementioned means for solving the problem of the present disclosure, unlike the performance degradation problem of the prior art caused by directly connecting real data to the ontology, by creating an OBDA mapping table that binds the ontology concept and a pre-generated SQL query statement and referencing it, the query processing engine can immediately rewrite and execute the user's ontology query into an SQL statement.

[0040] According to the aforementioned means for solving the problem of the present disclosure, through the automatic rewriting and execution of the SQL query statement, an overwhelmingly faster response speed compared to the conventional direct load method can be provided, as shown in the experimental results. Furthermore, through optimized SQL statement execution, it may be possible to provide a response speed that is equivalent to or faster than executing an SQL query directly on the source relational database.

[0041] According to the aforementioned means for solving the problem of the present disclosure, since only a query is performed without modifying or changing the data of the source relational database, it is possible to provide the effect of guaranteeing the integrity of the original data and not affecting the stability of the existing system.

[0042] According to the aforementioned means for solving the problem of the present disclosure, scalability can be provided that is universally applicable not only to the defense (METT-TC) sector but also to all industrial domains (e.g., medical, finance, manufacturing, etc.) that have a need to integrate multiple databases with different schemas.

[0043] According to the aforementioned means for solving the problem of the present disclosure, by analyzing not only structured relational databases but also unstructured text data such as military manuals through an LLM agent, converting them into knowledge graphs, and loading them into an integrated VKG, it is possible to provide the effect of accessing and utilizing all data assets within an organization from a consistent semantic perspective.

[0044] The effects of the present disclosure are not limited to those mentioned above, and other unmentioned effects will be clearly understood by a person skilled in the art from the description below. Brief explanation of the drawing

[0045] FIG. 1 is a block diagram showing a simplified structure of a semantic integration virtualization device for heterogeneous databases according to an example of the present invention. FIG. 2 is a flowchart illustrating the process of constructing a semantic-based integrated virtualization system according to an embodiment of the present invention. FIG. 3 is a flowchart illustrating a semantic integration virtualization method for heterogeneous databases according to an example of the present invention. FIG. 4 is a flowchart illustrating a defense METT-TC / GIS data retrieval method according to an example of the present invention. FIG. 5 is an exemplary diagram illustrating the execution process of querying METT-TC terrain data according to an example of the present invention. FIG. 6 is a flowchart illustrating an unstructured data LLM agent linkage method according to an example of the present invention. FIG. 7 is an illustrative diagram for explaining the process of converting unstructured text data into a knowledge graph through an LLM agent according to another example of the present invention. FIG. 8 is a graph showing experimental results comparing the performance of a virtualization method (VKG) according to an example of the present invention and a conventional physical loading method (DW). Specific details for implementing the invention

[0046] Throughout this disclosure, the same reference numerals denote the same components. This disclosure does not describe all elements of the embodiments, and general content in the art to which this disclosure pertains or content that overlaps between embodiments is omitted. The terms part, module, component, and block as used in the specification may be implemented in software or hardware, and depending on the embodiments, a plurality of parts, modules, components, and blocks may be implemented as a single component, or a single part, module, component, or block may include a plurality of components.

[0047] Throughout the specification, when a part is described as being "connected" to another part, this includes not only cases where they are directly connected but also cases where they are indirectly connected, and indirect connections include connections made via a wireless communication network.

[0048] Furthermore, when it is stated that a part "includes" a certain component, this means that, unless specifically stated otherwise, it does not exclude other components but may include additional components.

[0049] Throughout the specification, when it is stated that a component is located "on" another component, this includes not only cases where a component is in contact with another component, but also cases where another component exists between the two components.

[0050] The terms first, second, etc. are used to distinguish one component from another, and the components are not limited by the aforementioned terms.

[0051] Singular expressions include plural expressions unless there is an obvious exception in the context.

[0052] In each step, identification codes are used for convenience of explanation and do not describe the order of the steps; the steps may be performed differently from the specified order unless a specific order is clearly indicated in the context.

[0053] The operating principles and embodiments of the present disclosure will be described below with reference to the attached drawings.

[0054] In this specification, the device according to the present disclosure includes all various devices capable of performing computational processing and providing results to a user. For example, the device according to the present disclosure may include all of a computer, a server device, and a portable terminal, or may be in the form of any one of them.

[0055] Here, the computer may include, for example, a notebook, desktop, laptop, tablet PC, slate PC, etc. equipped with a web browser.

[0056] The above server device is a server that processes information by communicating with an external device, and may include an application server, a computing server, a database server, a file server, a game server, a mail server, a proxy server, and a web server.

[0057] The above portable terminal may include, for example, all types of handheld-based wireless communication devices such as PCS (Personal Communication System), GSM (Global System for Mobile communications), PDC (Personal Digital Cellular), PHS (Personal Handyphone System), PDA (Personal Digital Assistant), IMT (International Mobile Telecommunication)-2000, CDMA (Code Division Multiple Access)-2000, W-CDMA (W-Code Division Multiple Access), WiBro (Wireless Broadband Internet) terminals, smartphones, etc., as well as wearable devices such as watches, rings, bracelets, anklets, necklaces, glasses, contact lenses, or head-mounted devices (HMDs).

[0058] FIG. 1 is a block diagram showing a simplified structure of a semantic integration virtualization device (10) for heterogeneous databases according to an example of the present invention.

[0059] Referring to FIG. 1, in one embodiment, a semantic integration virtualization device (10) for heterogeneous databases may include a plurality of source relational databases (200) having different schemas, an ontology (300) semantically defining data of the databases, and a semantic-based integration virtualization system (100) located between the databases (200) and the ontology (300) to virtually link them.

[0060] In one embodiment, the semantic-based integrated virtualization system (100) may function as a control unit that collects schema information from the source relational database (200), maps it to an ontology (300) to generate a virtual integrated knowledge graph (VKG), and responds to user queries. For example, the semantic-based integrated virtualization system (100) may include a schema collection unit (110), a schema mapping unit (120), an SQL query generation unit (130), an OBDA mapping table generation unit (140), a VKG loading unit (150), a query processing engine (160), and an LLM agent (170).

[0061] In one embodiment, the schema collection unit (110) may access each of the plurality of source relational databases (200) and collect DB schema information including table names, column names, keys, index information, etc. Additionally, the schema collection unit (110) may collect ontology schema information, such as S / P / O (Subject / Predicate / Object) definitions, from the ontology (300). The schema collection unit (110) may inventory and catalog the collected DB schema information and ontology schema information and transmit them to the schema mapping unit (120) to be described later.

[0062] In one embodiment, the schema mapping unit (120) can semantically connect (map) a specific table column of the source relational database (200) and a specific attribute or relationship of the ontology (300) based on cataloged information received from the schema collection unit (110). In particular, even when existing metadata integration is impossible because the schemas are different, the schema mapping unit (120) can find and connect semantically identical concepts. Additionally, the schema mapping unit (120) can standardize different data units (e.g., meters and yards) or coordinate systems during the mapping process, and as an example, when mapping a GIS database, it can set MGRS (Military Grid Reference System) coordinates based on LOD (Level Of Detail) and map LOD representation columns.

[0063] In one embodiment, the SQL query generation unit (130) can pre-generate an SQL query statement as an actual extraction logic capable of extracting data from an actual source relational database (200) when a specific concept of the ontology (300) is queried, based on the mapping relationship determined by the schema mapping unit (120). This is a core component of the present invention that stores and executes the SQL statement itself without pre-duplicating data, and the SQL query statement may include a SELECT statement, a JOIN statement for an on-demand join between multiple source relational databases (200), and a geospatial function such as ST_Contains.

[0064] In one embodiment, the OBDA mapping table generation unit (140) may set the concepts (classes, attributes, relationships) of the ontology (300) defined by the schema mapping unit (120) as targets. Additionally, by setting the columns of the SQL query statement generated by the SQL query generation unit (130) as sources, an OBDA (Ontology-Based Data Access) mapping table (or OBDA mapping rule table) that mutually binds the targets and the sources may be generated. The OBDA mapping table generated in this way can be used as a basis for the query processing engine (160), which will be described later, to automatically rewrite the user's ontology query into an SQL statement.

[0065] In one embodiment, the VKG loading unit (150) may not load actual data from the source relational database (200) by replicating it, but may load it onto a graph DB (VKG) by combining the schema (node ​​and edge definitions) of the ontology (300) and the OBDA mapping rule table (reference SQL) generated by the OBDA mapping table generation unit (140). For example, the VKG loading unit (150) may load the schema and mapping rule onto a graph DB (e.g., Neo4j) through Cypher MERGE syntax to establish a virtual integrated knowledge graph (VKG) structure that a user can query.

[0066] In one embodiment, the query processing engine (160) may receive a query written in ontology terms in the form of SPARQL, GraphQL, or Cypher from a user. When the query is received, the query processing engine (160) may retrieve one or more stored SQL query(s) corresponding to the ontology query by referring to an OBDA mapping table loaded in the graph DB (VKG). Then, the query processing engine (160) may transmit the retrieved SQL query(s) to the corresponding source relational databases (200) respectively for direct execution. Through this, the latest real-time data stored in the source relational databases (200), rather than the replicated data in the central repository, can be queried in a non-replicating manner. The different types of data fragments (Instances) returned from the source relational databases (200) respectively may be integrated and reassembled by the query processing engine (160) based on the ontology schema and returned to the user as a unified response such as JSON.

[0067] In one embodiment, an LLM agent (170) may be further included in the semantic-based integrated virtualization system (100) to process not only structured data of the source relational database (200) but also unstructured text data such as military manual PDFs. The LLM agent (170) can analyze the input unstructured text data, map it to a predefined ontology schema, and generate a knowledge graph from the unstructured data through a knowledge graph generation prompt (LLM). The knowledge graph thus generated can be integrated and loaded into the main graph DB (VKG) through the VKG loading unit (150).

[0068] In one embodiment, a plurality of source relational databases (200) may be source repositories of data that are physically distributed and have different schemas, such as C4I, sensors, GIS, and operation report databases, which are difficult to integrate using conventional methods. According to the present invention, the source relational databases (200) may be preserved in their original form without data being duplicated or altered.

[0069] In one embodiment, the ontology (300) may function as a standard language dictionary or conceptual framework for semantically defining and integrating data stored in the plurality of source relational databases (200). For example, in the defense domain, an ontology that semantically defines METT-TC (Mission, Enemy, Terrain, Friendly Forces, Time, Civilian Elements) data may be used as the ontology (300).

[0070] FIG. 2 is a flowchart illustrating the process of constructing a semantic-based integrated virtualization system according to one embodiment of the present invention.

[0071] Referring to FIG. 2, a semantic-based integrated virtualization system (100) can receive multiple source data and ontologies having different schemas and construct a virtual knowledge graph (VKG) that semantically integrates them.

[0072] First, a multi-source METT-TC source relational database (200) and a METT-TC ontology (300) may be prepared as inputs. The multiple source relational databases (200) may include databases that are physically distributed and have different schemas, such as C4I, sensors, GIS, and operation reports.

[0073] The schema collection unit (110) can collect a DB schema including table names, column names, keys, index information, etc. from the input source relational database (200). At the same time, the schema collection unit (110) can collect an ontology schema including S / P / O (Subject / Predicate / Object) definitions from the ontology (300). The collected DB schema information and ontology schema information are inventoryed and cataloged, and can be secured as a baseline for subsequent mapping and query rewriting.

[0074] The schema mapping unit (120) can semantically connect (map) the table columns of the source relational database (200) and the attributes or relationships of the ontology (300) based on the cataloged information. This is intended to solve the problem that conventional metadata integration methods could not combine schemas because they were different, by connecting table identifiers or attributes to ontology concepts, and in this process, different data units or coordinate systems (e.g., MGRS) can be standardized.

[0075] The SQL query generation unit (130) can generate a mapping SQL query statement as a logic for extracting actual data based on the mapping relationship determined by the schema mapping unit (120). This involves pre-defining the SQL query statement itself, which includes SELECT statements, JOIN statements, spatial functions, etc., to be executed when querying the ontology concept, instead of duplicating the actual data or attaching it directly under the ontology. Through this, a real-time queryable state of the VKG virtual layer can be secured.

[0076] The OBDA mapping table generation unit (140) can generate an OBDA mapping table that mutually binds the generated mapping SQL query statement (source) and the concept (target) of the ontology (300). That is, "this concept (Target) By explicitly defining the mapping of this SQL column (Source) and specifying the subject (IRI) template, predicate / object binding, and source SQL, the query processing engine (160) described later can obtain a recipe for automatically rewriting the user's ontology query into an SQL statement.

[0077] The VKG loading unit (150) does not load actual data from the source relational database (200), but can load it onto the graph DB (VKG) by combining the schema (node / edge) of the ontology (300) and the OBDA mapping rule table (reference SQL) generated by the OBDA mapping table generation unit (140). For example, the structure of the virtual knowledge graph to be queried can be established by reflecting the mapping results in the graph DB (e.g., Neo4j) through Cypher MERGE syntax, etc.

[0078] Through the above process, a semantically integrated METT-TC VKG can be finally constructed while ensuring the real-time nature of the source data.

[0079] FIG. 3 is a flowchart illustrating a semantic integration virtualization method for heterogeneous databases according to an example of the present invention.

[0080] Referring to FIG. 3, in one embodiment, in operation 101, the schema collection unit (110) can collect schema information from a plurality of source relational databases (DB) and ontology. For example, the schema collection unit (110) can collect DB schema information including table names, column names, keys, index information, etc. from a plurality of source relational databases including C4I, sensors, GIS, and operation report databases. In addition, the schema collection unit (110) can collect ontology schema information including S / P / O (Subject / Predicate / Object) definitions from METT-TC ontology. The information thus collected can be inventoryed and cataloged, and can be clarified as a baseline for subsequent mapping and query rewriting processes.

[0081] In one embodiment, in operation 102, the schema mapping unit (120) can semantically connect (map) the collected DB schema and the ontology schema. For example, even if integration is impossible using the existing metadata integration method because the schemas are different, the schema mapping unit (120) can semantically connect the table columns of the cataloged DB schema with the properties and relationships of the ontology schema. In this process, the schema mapping unit (120) can standardize different data units or coordinate systems. As a specific example, when mapping terrain data of a GIS database, MGRS (Military Grid Reference System) coordinates can be set based on LOD (Level Of Detail) and LOD representation columns can be mapped. Through this, semantic consistency of multi-source data can be ensured and the interpretability of query results can be improved.

[0082] In one embodiment, in operation 103, the SQL query generation unit (130) can generate an SQL query statement for querying the source DB based on the mapped relationship. For example, the SQL query statement can function as an actual extraction logic for extracting data in real time when the ontology concept is queried, rather than duplicating data in advance. In establishing the reference SQL, the SQL query generation unit (130) may include not only a simple SELECT statement but also a JOIN statement for an on-demand join between multiple source relational databases. Additionally, it can generate an SQL query statement including a geospatial function such as ST_Contains for spatial querying the GIS database, and can secure a real-time queryable state of the VKG virtual layer by designing preprocessing, filters, aggregation conditions, etc.

[0083] In one embodiment, in operation 104, the OBDA mapping table generation unit (140) can generate an OBDA mapping table that mutually binds an ontology concept (target) and a generated SQL query statement (source). For example, the OBDA mapping table generation unit (140) can set targets by class, attribute, and relationship of the ontology and bind columns of the SQL query statement generated in operation 103 as sources. These OBDA mapping rules (OBDA rules) explicitly define the mapping of "this concept - this SQL column" and, by specifying subject (IRI) templates, predicate / object bindings, and source SQL, can secure a basis for automatic SQL rewriting of the ontology query.

[0084] In one embodiment, in operation 105, the VKG loader (150) can load an ontology schema and an OBDA mapping table into a graph DB (VKG). For example, the VKG loader (150) can load the ontology schema (node ​​and edge definitions) and the OBDA mapping rule table (reference SQL) generated in operation 104 onto the graph DB (VKG), rather than duplicating and loading the actual data of the source relational database. In one specific example, the VKG loader (150) can establish a query target structure on the graph DB by reflecting the OBDA mapping results into the graph DB (e.g., Neo4j) through a Cypher MERGE statement.

[0085] In one embodiment, in operation 106, the query processing engine (160) may receive an ontology-based query from a user. For example, the user may send a query written in ontology terms in SPARQL, GraphQL, or Cypher format to the METT-TC integrated VKG.

[0086] In one embodiment, in operation 107, the query processing engine (160) may retrieve a corresponding SQL query statement by referring to an OBDA mapping table loaded in the graph DB (VKG). For example, the query processing engine (160) may analyze the received ontology-based query and refer to an OBDA mapping rule table (e.g., SPARQL / SQL mapping table) generated in operation 104 and loaded in the graph DB (VKG). Through this, one or more stored SQL query statements corresponding to the ontology query may be retrieved to automatically rewrite the query.

[0087] In one embodiment, in operation 108, the query processing engine (160) can transmit and execute the retrieved SQL query statements to the corresponding source relational database. For example, the query processing engine (160) can transmit the retrieved SQL query statements to the corresponding source relational databases (e.g., terrain DB, unit DB, weapon DB) respectively and execute them directly (DB Call). This means querying real-time data stored in the source relational database in a non-replicating manner, rather than the replicated data in the central repository, and may be characterized by not modifying or changing the data in the source relational database during this process.

[0088] In one embodiment, in operation 109, the query processing engine (160) can integrate and reassemble the results returned from the source DB. For example, the query processing engine (160) can integrate and reassemble different types of data fragments (Instances) returned from the source relational databases based on an ontology schema. For example, when querying terrain data, the Instances can be created and integrated based on Level Of Detail (LOD).

[0089] In one embodiment, in operation 110, the query processing engine (160) may return the final integrated result to the user. For example, the final result integrated and reassembled in operation 109 may be returned to the user in a unified response format such as JSON. Through this, the user can simultaneously ensure the real-time nature of the source data and the semantic consistency of the ontology integration, and increase accessibility to the data for command decision.

[0090] FIG. 4 is a flowchart illustrating a defense METT-TC / GIS data lookup method according to an example of the present invention.

[0091] Referring to FIG. 4, in one embodiment, in operation 201, the user may request an ontology query (User Query) containing an operational area (MGRS coordinates). For example, the user may transmit a query written in METT-TC ontology (300) terms to a graph DB (VKG) (e.g., Neo4j) to identify terrain information and enemy status of a specific operational area necessary for command decisions. The query may be a query written in ontology terms in SPARQL, GraphQL, or Cypher format.

[0092] In one embodiment, in operation 202, the semantic-based integrated virtualization system (100) can set Level Of Detail (LOD) based MGRS coordinates. For example, the semantic-based integrated virtualization system (100) can recognize MGRS coordinate parameters corresponding to the operation area from the received User Query. In addition, considering the level of detail requirements of the query and the resolution of different source DBs, MGRS coordinates can be set based on Level Of Detail (LOD), and these can be used as a standard for mapping and query generation described later.

[0093] In one embodiment, in operation 203, the schema mapping unit (120) can verify the LOD representation column mapping of the terrain data. For example, the system (100) can refer to the mapping information established in operation 102 (Fig. 3), that is, the terrain data representation range and LOD representation column mapping information defined by the schema mapping unit (120). This may be a preparatory step for extracting data corresponding to the set LOD (operation 202) from the correct source DB column.

[0094] In one embodiment, in operation 204, the SQL query generation unit (130) can generate an SQL mapping condition including LOD and MGRS coordinate standards. For example, the SQL query generation unit (130) can combine the set LOD and MGRS coordinate standards (operation 202) and the identified LOD column mapping (operation 203). Through this, a condition clause of an SQL query statement including a geospatial function such as ST_Contains can be specified for spatial querying of a GIS database.

[0095] In one embodiment, in operation 205, the query processing engine (160) may refer to an OBDA mapping table (SPARQL / SQL mapping table). For example, the query processing engine (160) may analyze the received ontology-based query (operation 201) and refer to an OBDA mapping rule table (SPARQL / SQL mapping table) loaded in the graph DB (VKG). Through this, one or more stored SQL query statements corresponding to the ontology query can be retrieved, and the user's query can be automatically rewritten into an SQL statement that can be executed in the source DB.

[0096] In one embodiment, in operation 206, the query processing engine (160) can transmit the generated SQL query statement to a source DB, such as a GIS DB or a unit DB (DB Call). For example, the query processing engine (160) can combine the retrieved SQL query statements (operation 205) with the spatial function condition (operation 204) and transmit them to the corresponding source relational databases (e.g., terrain DB, unit DB, weapon DB) respectively for direct execution. This may involve querying real-time data stored in the source relational databases in a non-replicating manner, rather than the replicated data in the central repository.

[0097] In one embodiment, in operation 207, the query processing engine (160) can create an instance by integrating data returned from the source DB based on LOD. For example, the query processing engine (160) can receive different types of data fragments (Instances) returned from the source relational databases. Then, the query processing engine (160) can create a semantically connected instance within the graph DB (VKG) by integrating and reassembling the data fragments based on an ontology schema and based on the set LOD (operation 202).

[0098] In one embodiment, in operation 208, the query processing engine (160) can extract generated Instance data from the graph DB (Neo4j). For example, the query processing engine (160) can extract the integrated Instance data generated in operation 207 from the graph DB (Neo4j) to meet the requirements of the user's initial Cypher query (operation 201).

[0099] In one embodiment, in operation 209, the query processing engine (160) may return the final integration result to the user in JSON format. For example, the query processing engine (160) may return the extracted integration instance data (operation 208) to the user in a unified response format such as JSON. The series of processes (operations 201-209) may provide a response speed equivalent to or faster than executing SQL queries directly on the source relational database through the virtualized execution of ontology-based queries.

[0100] FIG. 5 is an example diagram illustrating the execution process of querying METT-TC terrain data according to an example of the present invention. Referring to FIG. 5, a user can transmit an ontology query (User Query) containing MGRS coordinate (operation area) information to Neo4j, a graph DB (VKG), in order to identify terrain information and enemy status of a specific operation area necessary for command decisions. The ontology query may be a Cypher query written in METT-TC ontology terms.

[0101] The above ontology query (User Query) and MGRS coordinates may also be transmitted to a semantic-based integrated virtualization system (OBDA / VKG System) (100). The semantic-based integrated virtualization system (100) recognizes MGRS coordinate parameters from the received query and, considering the level of detail requirement of the query and the resolution of the source database (200), can perform 1. Level Of Detail-based MGRS coordinate setting.

[0102] Next, the schema mapping unit (120) within the system (100) can perform or verify 2. terrain data representation range LOD representation column mapping by referring to the previously established mapping information.

[0103] Next, the SQL query generation unit (130) within the system (100) can combine the set LOD and MGRS coordinate standards with the confirmed LOD column mapping information. Through this, the 3. SQL mapping condition creation step can be performed to specify the condition clause of an SQL query statement containing a geospatial function such as ST_Contains for spatial querying the GIS database (296). In this process, the system (100) can generate accurate SQL conditions by referencing the METT-TC information table Schema.

[0104] The above-mentioned generated SQL mapping condition (based on LOD setting coordinates) can be passed to and stored in a SPARQL / SQL mapping table, or used as a reference standard for the table.

[0105] The graph DB (Neo4j) (271) can receive a user's Cypher query (272) and prepare an instance data extraction step. According to the rules of the SPARQL / SQL mapping table (291), an LOD-based instance creation step may be performed. This may mean a process in which the query processing engine (160) refers to the mapping table to integrate and reassemble data to be returned from different source DBs based on ontology schema and LOD. As a result of the instance data extraction and LOD-based instance creation (280) steps, the query processing engine (160) may retrieve or generate a final SQL query to be executed in the source database (200).

[0106] The above-mentioned retrieved SQL query can be transmitted to corresponding source relational databases, such as a terrain DB, a unit DB, and a weapon DB, respectively, in the form of a DB Call and executed directly. This may involve querying real-time data in a non-replicating manner, rather than the replicated data in the central repository. The final integrated result returned from the source DBs can be returned to the user in the form of a unified response, such as JSON (298).

[0107] FIG. 6 is a flowchart illustrating a method for linking an unstructured data LLM agent according to an example of the present invention.

[0108] Referring to FIG. 6, in one embodiment, in operation 301, an input unit or user may input unstructured text data. For example, the unstructured text data may be military manual data that serves as a standard for military operations, and may include unstructured documents in the form of PDFs or plain text files. This may be a data source distinct from the structured source relational database (200) processed in operation 101, etc.

[0109] In one embodiment, in operation 302, the LLM agent (170) can analyze unstructured text data. For example, the LLM agent (170) can parse the input unstructured text data (e.g., military manual text) and perform an analysis to identify and extract major entities, relations, properties, etc. present in the text using natural language processing (NLP) techniques.

[0110] In one embodiment, in operation 303, the LLM agent (170) can map the analysis results to a predefined manual ontology schema. For example, the LLM agent (170) can semantically map the results analyzed in operation 302 (extracted entities, relationships, etc.) to a predefined manual ontology schema. For example, the agent can perform the task of connecting an entity named M1A2 tank extracted from text to a weapon class of the ontology schema and mapping an attribute named gun barrel caliber to a specification attribute.

[0111] In one embodiment, in operation 304, the LLM agent (170) may execute a prompt for generating a knowledge graph. For example, the LLM agent (170) may dynamically generate and execute a knowledge graph generation prompt that the large-scale language model (LLM) can understand and execute based on the mapping result of operation 303. The prompt may instruct to generate a knowledge graph structure in the form of an S / P / O triple, such as "The M1A2 tank (Subject) is in an adversarial relationship (Predicate) with the T-14 (Object)."

[0112] In one embodiment, in operation 305, the LLM agent (170) can generate a knowledge graph through the LLM. For example, the LLM agent (170) can generate knowledge graph data (e.g., a list of S / P / O triples) that structures the contents of the unstructured text data to fit an ontology schema by receiving it back from the LLM as a response to the executed prompt (operation 304).

[0113] In one embodiment, in operation 306, the VKG loader (150) can integrate and load the generated knowledge graph into the main graph DB (VKG). For example, the VKG loader (150) can receive knowledge graph data generated by the LLM agent (170) in operation 305. Then, the VKG loader (150) can integrate and load the knowledge graph into the main graph DB (VKG) (e.g., Neo4j) built in operation 105. Through this, the user can consistently query and utilize structured data (source DB) and unstructured data (manual) from the same ontology perspective.

[0114] FIG. 7 is an example diagram illustrating the process of converting unstructured text data into a knowledge graph through an LLM agent according to another example of the present invention.

[0115] Referring to FIG. 7, the semantic-based integrated virtualization device (10) of the present invention can process not only structured source relational databases (200) such as MySQL, MariaDB, PostGIS / PostgreSQL, and Rasdaman, but also unstructured text data such as military manual data as input.

[0116] The above military manual data may include unstructured text, PDF (316) files, and a manual ontology schema design designed to structure the unstructured data. The above military manual data may be input into a Text to Knowledge Graph conversion process.

[0117] The above Text to Knowledge Graph process can be performed by the LLM Agent. The LLM Agent (170) can analyze input unstructured data (operation 302), map it to an ontology schema (operation 303), and execute a knowledge graph generation prompt (LLM) (operation 304) to generate a knowledge graph corresponding to the ontology schema from the unstructured text data (operation 305).

[0118] The knowledge graph generated by the above LLM Agent can be transmitted to the main graph DB (Graph Database With neo4j) of the above semantic-based integrated virtualization system (100) and integratedly loaded (operation 306).

[0119] As illustrated in FIG. 7, the neo4j graph database can function as a final repository in which a virtual knowledge graph (VKG) generated from the source relational database through a Virtual Knowledge Graph design path (e.g., protigii -> ontop -> neo4j) and a knowledge graph generated from the unstructured data through an LLM Agent are integrated. Through this, the user can be provided with the effect of consistently querying and utilizing structured data and unstructured data from the same ontology perspective (Upper Ontology Layer, Domain Ontology Layer, etc.).

[0120] FIG. 8 is a graph showing experimental results comparing the performance of a virtualization method (VKG) according to an example of the present invention and a conventional physical loading method (DW).

[0121] Referring to Fig. 8, the graph on the left may show the processing time (Time (seconds), vertical axis) according to the number of data instances (thousands, horizontal axis) on a logarithmic scale.

[0122] Data processing methods, data freshness, and I / O characteristics can be compared according to the classification items. Regarding data processing methods, conventional DW methods may use ETL, replication, and central storage methods. This may mean a method of replicating data through the ETL process and loading it into a central storage. On the other hand, the VKG method according to the present invention may use non-replication and query federation methods in the virtual layer. This may mean that the query processing engine (160) does not replicate data centrally, does not modify or change data in the source relational database (200) (i.e., non-replication method), and federates queries in the virtual layer by referencing the OBDA mapping table.

[0123] Regarding data recency, conventional DW methods are batch-dependent, so changes to source data may not be reflected in real time and loading delays may occur. On the other hand, the VKG method according to the present invention has the characteristic that real-time performance can be reflected because the query processing engine (160) directly queries (DB Call) the source relational database (200).

[0124] Regarding I / O characteristics, conventional DW methods may experience I / O bottlenecks due to large-scale loading / querying. This may mean that system load and input / output (I / O) bottlenecks occur during the process of replicating all data to a central repository. On the other hand, the VKG method according to the present invention can distribute the load by converting user queries into on-demand queries. This may mean that the query processing engine (160) distributes the retrieved SQL query(s) to the corresponding source relational databases (200), thereby resolving I / O bottlenecks caused by central replication and loading in the DW (Data Warehouse) method and distributing the system load.

[0125] Referring to the graph, the yellow line labeled Direct load (linear, calibrated) may represent the conventional DW method, and the blue line labeled Virtualized load (sublinear, calibrated) may represent the VKG method according to the present invention.

[0126] The conventional DW method (Direct load) takes 3.35 seconds to process 10,000 instances, and as the number of instances increases, the processing time increases linearly or more rapidly, taking 333.0 seconds to process 1 million instances.

[0127] On the other hand, the VKG method (Virtualized load) according to the present invention takes 0.80 seconds to process 10,000 instances, and even if the number of instances increases to 1 million, the processing time is only 2.00 seconds, so it can be confirmed that it shows very low processing time and a sublinear increasing trend.

[0128] This may experimentally demonstrate that the present invention not only solves the problem of reduced query speed associated with conventional ontology linkage methods, but also provides a response speed that is equivalent to or significantly faster than the conventional physical loading (DW) method, which executes SQL queries directly on the source relational database through the virtualized execution of an ontology-based query by the query processing engine (160).

[0129] Meanwhile, the disclosed embodiments may be implemented in the form of a recording medium that stores instructions executable by a computer. The instructions may be stored in the form of program code and, when executed by a processor, may generate a program module to perform the operation of the disclosed embodiments. The recording medium may be implemented as a computer-readable recording medium.

[0130] Computer-readable recording media include all types of recording media that store instructions that can be decoded by a computer. Examples include ROM (Read Only Memory), RAM (Random Access Memory), magnetic tape, magnetic disk, flash memory, optical data storage devices, etc.

[0131] As described above, the disclosed embodiments have been explained with reference to the attached drawings. Those skilled in the art will understand that the present disclosure may be practiced in forms different from the disclosed embodiments without changing the technical spirit or essential features of the present disclosure. The disclosed embodiments are illustrative and should not be interpreted restrictively. Explanation of the symbols

[0132] 10: Semantic Integration Virtualization Device for Heterogeneous Databases 100: Semantic-based integrated virtualization system 110: Schema Collection Section 120: Schema Mapping Section 130: SQL Query Generation Section 140: OBDA Mapping Table Generation Section 150: VKG loading section 160: Query processing engine 170: LLM Agent 200: Multiple source relational databases 300: Ontology

Claims

Claim 1 A virtualization device for semantic integration of heterogeneous databases comprises: a plurality of source relational databases having different schemas and physically distributed; an ontology for semantically defining and integrating data stored in the plurality of source relational databases; and a semantic-based integration virtualization system located between the source relational databases and the ontology; wherein the semantic-based integration virtualization system comprises: a schema collection unit that collects DB schema information from the source relational databases and collects ontology schema information from the ontology; a schema mapping unit that semantically connects table columns of the collected DB schemas with attributes of the ontology schema; an SQL query generation unit that generates an SQL query statement for extracting data from the source relational databases when querying the ontology concept based on the mapped relationship; and an OBDA mapping table generation unit that generates an OBDA (Ontology-Based Data Access) mapping table that targets the concept of the ontology and mutually binds the target and the source using the generated SQL query statement as a source. A semantic integration virtualization device for heterogeneous databases, characterized by comprising: a VKG loading unit that loads the above-mentioned ontology schema and the above-mentioned generated OBDA mapping table into a graph DB (VKG); and a query processing engine that, upon receiving an ontology-based query from a user, retrieves a corresponding SQL query statement by referencing the OBDA mapping table loaded into the graph DB (VKG), transmits the retrieved SQL query statement to the source relational database for execution, and then integrates and returns the results. Claim 2 A semantic integration virtualization device for heterogeneous databases according to claim 1, characterized in that the plurality of source relational databases have different schemas, making schema-level integration impossible using existing metadata integration methods. Claim 3 In paragraph 2, the semantic-based integrated virtualization system is characterized by using the OBDA mapping table and the query processing engine to solve the problem of reduced query speed that occurs when the actual data of the source relational database is directly connected to the ontology. Claim 4 In paragraph 3, the semantic integration virtualization device for heterogeneous databases is characterized in that the industrial domain to which the device is applied is at least one of the medical, financial, manufacturing, and defense sectors. Claim 5 A semantic integration virtualization device for heterogeneous databases, characterized in that, in paragraph 4, the industrial domain is a national defense command decision system, and the ontology is a METT-TC ontology that semantically defines METT-TC data of the national defense command decision system. Claim 6 A semantic integration virtualization device for heterogeneous databases according to claim 5, characterized in that the plurality of source relational databases include C4I, sensor, GIS, and operation report databases containing METT-TC data. Claim 7 In claim 6, the schema collection unit is characterized by collecting table names, column names, keys, and index information of the C4I, sensor, GIS, and operation report databases, and S / P / O (Subject / Predicate / Object) definitions of the METT-TC ontology, and then inventorying and cataloging them, in a semantic integration virtualization device for heterogeneous databases. Claim 8 In claim 7, the schema mapping unit is characterized by semantically connecting the table columns of the cataloged DB schema with the attributes and relationships of the ontology schema, and standardizing different data units or coordinate systems, in a semantic integration virtualization device for heterogeneous databases. Claim 9 In claim 8, the schema mapping unit is characterized by setting MGRS (Military Grid Reference System) coordinates based on LOD (Level Of Detail) and mapping LOD representation columns when mapping terrain data of the GIS database, in a semantic integration virtualization device for heterogeneous databases. Claim 10 A method performed by a virtualization device for semantic integration of heterogeneous databases, wherein the virtualization device comprises: a plurality of source relational databases having different schemas and being physically distributed; an ontology for semantically defining and integrating data stored in the plurality of source relational databases; and a semantic-based integration virtualization system located between the source relational databases and the ontology; wherein a schema collection unit collects DB schema information from the source relational databases and collects ontology schema information from the ontology; a schema mapping unit semantically links the table columns of the collected DB schemas with the attributes of the ontology schema; an SQL query generation unit generates an SQL query statement for extracting data from the source relational databases when querying the ontology concept based on the mapped relationship; and an OBDA mapping table generation unit generates an OBDA (Ontology-Based Data Access) mapping table that targets the concept of the ontology and mutually binds the target and the source using the generated SQL query statement as a source. A method for semantic integration virtualization of heterogeneous databases, characterized by comprising: a step in which a VKG loader loads the ontology schema and the generated OBDA mapping table into a graph DB (VKG); and a step in which, when a query processing engine receives an ontology-based query from a user, it refers to the OBDA mapping table loaded into the graph DB (VKG) to retrieve a corresponding SQL query statement, transmits the retrieved SQL query statement to the source relational database for execution, and then integrates and returns the results.

Images