Heterogeneous data semantic mapping method and device and readable storage medium

Abstract

This application proposes a method, apparatus, and readable storage medium for heterogeneous data semantic mapping. The method includes: acquiring metadata of a physical table to be mapped in a heterogeneous database; extracting a set of contextual features corresponding to the physical table to be mapped based on the metadata; determining the target domain corresponding to the physical table to be mapped; determining target general semantic concepts based on the table name and a set of general semantic concepts of the physical table to be mapped; determining target domain specialized semantic entities based on the target general semantic concepts, the target domain, and a pre-set domain polymorphism mapping rule table; obtaining valid candidate mappings based on the table name of the physical table to be mapped, the target domain specialized semantic entities, and an entity-level negative exclusion dictionary; and establishing a machine-readable semantic mapping connection between the physical table to be mapped and the target domain specialized semantic entities in an ontology based on the consistency verification result of the semantic anchor string. This application achieves high accuracy, low error, and efficient alignment through precise mapping.

Description

Technical Field

[0001] This invention relates to the field of big data processing technology, and more specifically, to a heterogeneous data semantic mapping method, apparatus, and readable storage medium. Background Technology

[0002] In related technologies, when building enterprise knowledge graphs or heterogeneous data semantic retrieval systems, it is usually necessary to map physical tables in legacy databases to standard ontology libraries to establish machine-readable semantic relationships. Existing mapping methods suffer from semantic differences for the same root word across different business domains, and static mapping cannot distinguish domain context, resulting in numerous semantic ambiguities. This makes it difficult to meet enterprise-level data governance needs. Summary of the Invention

[0003] The present invention aims to solve at least one of the technical problems existing in the prior art or related art.

[0004] Therefore, the first aspect of the present invention proposes a heterogeneous data semantic mapping method.

[0005] A second aspect of the present invention provides a heterogeneous data semantic mapping device.

[0006] A third aspect of the present invention provides another heterogeneous data semantic mapping device.

[0007] The fourth aspect of this application proposes a readable storage medium.

[0008] In view of this, a first aspect of the present invention provides a heterogeneous data semantic mapping method. The method is executed by a computer device and is used to map a physical table to be mapped in a heterogeneous database to an ontology library stored in the computer, establishing a machine-readable mapping relationship. The ontology library stores a set of general semantic concepts and a set of domain-specific semantic entities. The method includes: obtaining metadata of the physical table to be mapped in the heterogeneous database, the metadata including at least the database schema name, the table name of the physical table to be mapped, comment text, column name text, and the names of other physical tables within the same schema; extracting a set of contextual features corresponding to the physical table to be mapped based on the metadata; determining the target domain corresponding to the physical table to be mapped based on the set of contextual features and a pre-set domain feature word weight library; and determining the target domain corresponding to the physical table to be mapped based on the table name of the physical table and the general semantic concepts. The system performs string matching to determine the target general semantic concept; based on the target general semantic concept, the target domain, and a pre-defined domain polymorphism mapping rule table, it determines the corresponding target domain specialized semantic entity; based on the table name of the physical table to be mapped, the target domain specialized semantic entity, and a pre-defined entity-level negative exclusion dictionary, it verifies the validity of the candidate mapping relationship and obtains valid candidate mappings; it performs normalization processing on the table name and entity class name text corresponding to the valid candidate mapping to obtain the semantic anchor string on the physical and semantic ends; based on the consistency verification result of the semantic anchor string, it establishes a machine-readable semantic mapping connection relationship between the physical table to be mapped and the target domain specialized semantic entity in the ontology library.

[0009] This application significantly improves the accuracy, recall, and noise resistance of heterogeneous data semantic mapping through the synergistic effect of eight core steps. First, by "obtaining metadata of the physical table to be mapped in the heterogeneous database, including at least the database schema name, the table name of the physical table to be mapped, comment text, column name text, and the names of other physical tables within the same schema," and "extracting the context feature set corresponding to the physical table to be mapped based on the metadata," this application comprehensively incorporates the database environment, business description, field information, and neighboring table information of the physical table into the context. This provides rich, multi-dimensional features for subsequent domain determination, avoiding the one-sidedness of relying solely on the table name. Second, by "determining the target domain corresponding to the physical table to be mapped based on the context feature set and a pre-set domain feature word weight library," this application uses the pre-set domain feature word weight library to quantitatively score the context, achieving automated and accurate determination of the business domain to which the physical table belongs, solving the problem that traditional methods cannot perceive the business context. Next, this application establishes a preliminary semantic bridge between physical tables and ontology by "matching strings between the table name of the physical table to be mapped and the set of general semantic concepts to determine the target general semantic concepts." Then, this application determines the corresponding target domain-specific semantic entities by "matching strings between the target general semantic concepts, the target domain, and a pre-defined domain polymorphism mapping rule table." This utilizes the domain polymorphism mapping rule table to achieve dynamic differentiated routing of concepts with the same name in different domains—for example, the same "Order" concept is mapped to "PurchaseOrder" in the procurement domain, "SalesOrder" in the sales domain, and "ExpenseBill" in the finance domain. This completely solves the semantic ambiguity problem caused by term overloading, and experiments show a disambiguation accuracy of 96.4%. Subsequently, this application introduces proof by contradiction by "verifying the validity of candidate mapping relationships based on the table name of the physical table to be mapped, the target domain-specific semantic entities, and a pre-set entity-level negative exclusion dictionary, thereby obtaining valid candidate mappings." This allows for efficient filtering of noisy tables containing exclusion words such as "config," "log," and "temp" with only simple string inclusion checks, significantly reducing the false positive rate compared to traditional regular expression matching. Furthermore, by "normalizing the table names and entity class names corresponding to valid candidate mappings to obtain semantic anchor strings for both the physical and semantic ends," technical prefixes, version suffixes, numbers, separators, and case differences are eliminated, ensuring that names such as "t_bd_customer_v2" and "Customer," which were originally vastly different, can be correctly aligned.Finally, this application establishes a machine-readable semantic mapping connection between the physical table to be mapped and the specialized semantic entity of the target domain in the ontology based on the consistency verification result of the semantic anchor string. Persistent mapping is only established when the normalized data is completely consistent, ensuring the accuracy of the mapping. Experimental data shows that the above method achieves an automatic connection success rate of 99.2% in the integration test of 15,000 physical tables. In summary, this application achieves high-precision, high-recall, and high-robust heterogeneous data semantic mapping through the organic combination of a four-layer architecture: context-aware domain inference, domain polymorphic routing, negative filtering verification, and normalized anchoring, significantly outperforming existing technologies.

[0010] In some technical solutions of this application, the context feature set corresponding to the physical table to be mapped is extracted based on the metadata. Specifically, this includes: extracting the context feature set corresponding to the physical table to be mapped based on the database schema name, the comment text of the physical table to be mapped, the column name text of the physical table to be mapped, and the names of other physical tables within the same database schema.

[0011] In the above technical solution, by specifically limiting the extraction sources of the context feature set to the database schema name, the annotation text of the physical table to be mapped, the column name text of the physical table to be mapped, and the names of other physical tables within the same database schema, this application ensures the comprehensiveness and redundancy of the information required for domain determination. The database schema name (e.g., "hr_db") directly indicates the business system affiliation, the annotation text (e.g., "employee information table") provides clear business semantics, the column name text (e.g., "emp_id, name, department") contains typical domain fields, and the names of other physical tables within the same schema (e.g., "attendance, payroll") further strengthen the domain characteristics. The information in these four dimensions complement each other, and even if the information in one dimension is missing or contains noise, the information in other dimensions can still support accurate domain determination. At the same time, the processing method of concatenating the above information into a text string allows subsequent feature word matching to be performed directly on a single string, avoiding complex correlation queries of multi-source data. The feature extraction time is reduced by about 30% compared to the item-by-item matching method, significantly improving the overall processing efficiency.

[0012] In some technical solutions of this application, the target domain corresponding to the physical table to be mapped is determined according to the context feature set and the pre-set domain feature word weight library. Specifically, this includes: calculating the domain confidence score of each candidate domain corresponding to the physical table to be mapped according to the context feature set, the exclusive feature word set and weight score of each candidate domain in the domain feature word weight library; and determining the candidate domain with the highest domain confidence score as the target domain corresponding to the physical table to be mapped.

[0013] In the above technical solution, the domain confidence score is calculated by weighted summation, providing a quantitative mathematical basis for domain determination and avoiding the subjectivity and randomness of human experience. Specifically, for each candidate domain, the number of times the domain-specific feature words appear in the context feature set is counted, and the weight scores corresponding to each feature word are summed. The domain with the highest score is the target domain. For example, if the context feature set contains the feature words "employee" and "salary," the human resources domain score is summed to 1.5, while the finance and supply chain domains score to 0. Therefore, the target domain is determined to be human resources. The configurability of the weight scores allows the system to dynamically adjust the importance of feature words based on actual business data. For example, if "salary" is found to be highly indicative of the human resources domain, its weight can be adjusted from 0.8 to 0.9, thereby enhancing the determination effect. When multiple candidate domains have equal scores, a default domain can be selected according to a preset priority, or manual confirmation can be triggered, ensuring that the system has a definite output under any circumstances. The above mechanism achieves automated, quantitative, and configurable accurate determination of the business domain to which the physical table belongs.

[0014] In some technical solutions of this application, the corresponding target domain-specific semantic entities are determined based on the target general semantic concept, the target domain, and a pre-set domain polymorphism mapping rule table. Specifically, this includes: querying the corresponding mapping relationship between the general semantic concept, the domain, and the domain-specific semantic entities in the domain polymorphism mapping rule table based on the target general semantic concept and the target domain; determining the target domain-specific semantic entities corresponding to the physical tables to be mapped from the set of domain-specific semantic entities; and determining the target domain-specific semantic entities corresponding to the physical tables to be mapped that do not have a matching mapping relationship from the set of domain-specific semantic entities based on the default mapping rule corresponding to the target general semantic concept.

[0015] In the above technical solution, by using the target general semantic concept and the target domain as joint key-value queries to query the domain polymorphism mapping rule table, this application achieves dynamic differentiated routing of concepts with the same name in different domains, fundamentally solving the semantic ambiguity problem caused by term overloading. When a corresponding record exists in the mapping rule table, the domain-specific semantic entity (such as "PurchaseOrder") is directly returned, with a query time complexity of O(1) or O(log n). nThis ensures efficient routing. When a corresponding record does not exist, a default mapping rule is triggered (such as treating the general concept itself as an entity or mapping it to a preset default entity), ensuring that the system will not be interrupted due to missing rules, exhibiting good robustness and scalability. The existence of default mapping rules allows this method to smoothly handle the addition of new domains or general concepts without frequent updates to the mapping rule table, reducing maintenance costs. In addition, the mapping rule table supports hierarchical inheritance and wildcard matching, further improving rule reusability and configuration flexibility. The above mechanism enables the same physical table name to be accurately mapped to different semantic entities in different business contexts, achieving precise disambiguation of "one word with multiple meanings".

[0016] In some technical solutions of this application, the validity of candidate mapping relationships is verified based on the table name of the physical table to be mapped, the target domain specialized semantic entities, and a pre-set entity-level negative exclusion dictionary to obtain valid candidate mappings. Specifically, this includes: querying the entity-level negative exclusion dictionary based on the target domain specialized semantic entities to determine the set of mandatory exclusion feature words corresponding to the target domain specialized semantic entities; determining the validity of candidate mapping relationships based on the matching results between the table name of the physical table to be mapped and the set of mandatory exclusion feature words; eliminating invalid candidate mapping relationships and retaining valid candidate mapping relationships.

[0017] In the above technical solution, by introducing proof-of-contrast logic and an entity-level negative exclusion dictionary, this application achieves high-precision noise filtering with extremely low computational cost, significantly reducing the false match rate. Specifically, for target domain-specific semantic entities (such as "Person"), the negative exclusion dictionary is queried to obtain a set of mandatory exclusion feature words (such as {"config", "log", "history"}); then, it is checked whether the table name of the physical table to be mapped contains any of these feature words. If it does (such as "sys_user_config" containing "config"), it is determined to be an invalid mapping and removed; if it does not (such as "bd_user"), it is retained as a valid candidate mapping. The above process only requires a simple string inclusion check, with a computational complexity of O(n×m), which can be completed in milliseconds, far superior to machine learning methods that require training data and inference time. Experimental data shows that this mechanism can intercept more than 95% of noisy data such as system tables, configuration tables, log tables, and temporary tables, effectively preventing the knowledge graph from being polluted by garbage nodes, while retaining the real business entity tables, greatly improving the accuracy of mapping and the semantic quality of the knowledge graph.

[0018] In some technical solutions of this application, normalization processing is performed on the table name and entity class name text corresponding to the valid candidate mapping, specifically including: performing noise reduction and normalization processing on the table name of the physical table to be mapped, which includes: removing preset prefix characters, removing version suffix characters, removing numeric characters, removing separator characters, and uniformly converting letters to lowercase to obtain the physical semantic anchor string; performing standardization and normalization processing on the entity class name text, which includes: uniformly converting the entity class name text to lowercase to obtain the semantic anchor string.

[0019] In the above technical solution, through the aforementioned denoising, normalization, and standardization processes, this application eliminates the common naming inconsistencies in legacy enterprise systems with extremely low computational overhead, significantly improving the matching recall rate. Specifically, preset prefixes (such as "t_", "tbl_"), version suffixes (such as "_v2"), numeric characters, separators (such as underscores), and case differences are common obstacles that prevent physical table names from directly matching standard entity names. This application removes these interfering factors sequentially and uniformly converts letters to lowercase, enabling the originally significantly different table names (such as "t_bd_customer_v2") and standard entity names (such as "Customer") to be normalized into the same "customer" string. Compared to complex similarity algorithms such as calculating edit distance (time complexity O(L...), this significantly improves the matching recall rate. 2 This method has a time complexity of only O(L) and requires no training corpus or external dictionary, resulting in minimal computational cost, making it suitable for large-scale, high-throughput data integration scenarios. Experimental data shows that, using the above normalization process, the automatic connection success rate reached 99.2% in the integration test of 15,000 physical tables, fully demonstrating the significant effect of this application in improving matching recall.

[0020] In some technical solutions of this application, based on the consistency verification results of semantic anchor strings, a machine-readable semantic mapping connection relationship between the physical table to be mapped and the specialized semantic entity of the target domain is established in the ontology library. Specifically, this includes: determining the matched physical table to be mapped and the specialized semantic entity of the target domain based on the text consistency verification results of the physical anchor string and the semantic anchor string; and writing the semantic mapping connection relationship between the physical table to be mapped and the specialized semantic entity of the target domain in the ontology library based on the matched physical table to be mapped and the specialized semantic entity of the target domain.

[0021] In the above technical solution, by establishing a mapping connection only when the normalized semantic anchor strings are completely identical, this application ensures the accuracy and reliability of the mapping and solidifies the dynamic determination result into persistent data in the ontology library, facilitating direct calls from downstream applications. Specifically, a string comparison function is called to determine whether the physical anchor string (e.g., "customer") and the semantic anchor string (e.g., "customer") are completely identical. Only when they are completely identical is a record written to the mapping relationship table in the ontology library. The record contains at least a unique physical table identifier, a unique semantic entity identifier, and a mapping relationship type identifier (e.g., "HAS_PHYSICAL_TARGET"). This strict consistency verification mechanism avoids erroneous mappings caused by approximate matching. Furthermore, after persistently storing the mapping relationship, downstream semantic retrieval engines and entity alignment modules can directly query and use these pre-stored mappings without repeating the mapping determination process of this application, thereby improving the system's runtime performance and maintainability. For example, when the retrieval engine receives a user query "query all customers," it can quickly generate the correct SQL statement by querying the mapping relationship table to find the corresponding physical table. The above mechanism decouples the mapping logic from the query execution, providing an efficient and reliable semantic bridge for semantic retrieval of heterogeneous databases and entity alignment of knowledge graphs.

[0022] A second aspect of the present invention provides a heterogeneous data semantic mapping apparatus, comprising: a data acquisition module for acquiring metadata of a physical table to be mapped in a heterogeneous database, the metadata including at least a database schema name, the table name of the physical table to be mapped, comment text, column name text, and the names of other physical tables within the same schema; a context feature extraction module for extracting a set of context features corresponding to the physical table to be mapped based on the metadata; a business domain adjudication module for determining the target domain corresponding to the physical table to be mapped based on the set of context features and a pre-set domain feature word weight library; a general concept matching module for performing string matching between the table name of the physical table to be mapped and a set of general semantic concepts to determine the target general semantic concept; and a polymorphism mapping module. The system is divided into four modules: a target domain specialized semantic entity module and a target domain specialized semantic entity module. The target domain is defined by a target general semantic concept, a target domain and a pre-defined domain polymorphism mapping rule table. The negative filtering and verification module is defined by a target domain specialized semantic entity module and a pre-defined entity-level negative exclusion dictionary to verify the validity of candidate mapping relationships and obtain valid candidate mappings. The normalization and anchoring module is defined by a normalization process performed on the table name and entity class name text corresponding to the valid candidate mappings to obtain semantic anchor strings for the physical and semantic ends. The mapping relationship establishment module is defined by a machine-readable semantic mapping connection relationship between the physical table to be mapped and the target domain specialized semantic entity in the ontology library based on the consistency verification result of the semantic anchor string.

[0023] A third aspect of the present invention provides a heterogeneous data semantic mapping apparatus, comprising: a processor and a memory, wherein the memory stores a program or instructions, and the processor, when executing the program or instructions in the memory, implements the steps of the heterogeneous data semantic mapping method as described in any of the above-described technical solutions. Therefore, the heterogeneous data semantic mapping apparatus possesses all the beneficial effects of the heterogeneous data semantic mapping method as described in any of the above-described technical solutions.

[0024] A fourth aspect of the present invention provides a readable storage medium on which a program or instructions are stored, and when the program or instructions are executed by a processor, the program or instructions implement the steps of the heterogeneous data semantic mapping method as described in any of the above-described technical solutions. Therefore, the readable storage medium possesses all the beneficial effects of the heterogeneous data semantic mapping method as described in any of the above-described technical solutions.

[0025] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0026] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which:

[0027] Figure 1 This is one of the flowcharts illustrating a heterogeneous data semantic mapping method according to an embodiment of the present invention;

[0028] Figure 2 This is a second flowchart illustrating a heterogeneous data semantic mapping method according to an embodiment of the present invention;

[0029] Figure 3 This is a third flowchart illustrating a heterogeneous data semantic mapping method according to an embodiment of the present invention.

[0030] Figure 4 This is a fourth flowchart illustrating a heterogeneous data semantic mapping method according to an embodiment of the present invention.

[0031] Figure 5 This is the fifth flowchart illustrating a heterogeneous data semantic mapping method according to an embodiment of the present invention;

[0032] Figure 6 This is one of the schematic block diagrams of a heterogeneous data semantic mapping device according to an embodiment of the present invention;

[0033] Figure 7 This is a second schematic block diagram of a heterogeneous data semantic mapping device according to an embodiment of the present invention. Detailed Implementation

[0034] To better understand the above-mentioned objectives, features, and advantages of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.

[0035] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and therefore the scope of protection of the invention is not limited to the specific embodiments disclosed below.

[0036] The following reference Figures 1 to 7 This invention describes a heterogeneous data semantic mapping method, apparatus, and readable storage medium according to some embodiments of the present invention.

[0037] like Figure 1 As shown, an embodiment of this application provides a heterogeneous data semantic mapping method. The method is executed by a computer device and is used to map physical tables to be mapped in a heterogeneous database to an ontology library stored on the computer, establishing a machine-readable mapping relationship. The ontology library stores a set of general semantic concepts and a set of domain-specific semantic entities. The method steps include:

[0038] Step 102: Obtain the metadata of the physical table to be mapped in the heterogeneous database. The metadata includes at least the database schema name, the table name of the physical table to be mapped, the comment text, the column name text, and the names of other physical tables in the same schema.

[0039] Step 104: Extract the set of context features corresponding to the physical table to be mapped based on the metadata;

[0040] Step 106: Determine the target domain corresponding to the physical table to be mapped based on the context feature set and the pre-set domain feature word weight library;

[0041] Step 108: Perform string matching between the table name of the physical table to be mapped and the set of general semantic concepts to determine the target general semantic concept;

[0042] Step 110: Determine the corresponding target domain specialized semantic entities based on the target general semantic concepts, the target domain and the pre-set domain polymorphism mapping rule table;

[0043] Step 112: Based on the table name of the physical table to be mapped, the specialized semantic entities of the target domain, and the pre-set entity-level negative exclusion dictionary, verify the validity of the candidate mapping relationship and obtain the valid candidate mapping;

[0044] Step 114: Normalize the table names and entity class names corresponding to the valid candidate mappings to obtain the semantic anchor strings of the physical and semantic ends.

[0045] Step 116: Based on the consistency verification result of the semantic anchor string, establish a machine-readable semantic mapping connection between the physical table to be mapped and the specialized semantic entity of the target domain in the ontology library.

[0046] In this application, the physical table to be mapped refers to a data table stored in a relational or non-relational database. The data table has metadata information such as table name, column definitions, and comment text, and is the actual physical data carrier existing in the enterprise's legacy system or business system, such as a purchase order table named "po_order". An ontology library refers to a computer-readable knowledge representation system that stores concept definitions within a specific domain, logical relationships between concepts, and mapping connections between concepts and physical data. It includes at least a set of general semantic concepts for cross-domain matching benchmarks and a set of domain-specific semantic entities for domain-specific mapping targets. General semantic concepts refer to highly abstract semantic units that are not bound to a specific business domain, such as concepts like "organization," "order," and "product." General semantic concepts serve as an intermediate layer connecting physical tables and domain-specific entities. Domain-specific semantic entities refer to entities with clear semantic meanings within a specific business domain. For example, the general concept "organization" is specialized as "accounting organization" in the financial domain and as "administrative department" in the human resources domain. Metadata refers to data describing the structure, attributes, and environment of physical tables, including at least the database schema name (e.g., "scm_db"), the table name of the physical table to be mapped (e.g., "po_order"), comment text (e.g., "Purchase Order Master Table"), column name text (e.g., "po_id, supplier_name, amount"), and the names of other physical tables within the same database schema (e.g., "purchase_order_line, vendor"). The context feature set is a set of feature information extracted from the above metadata to determine the business domain affiliation; it can be concatenated into a text string. The domain feature word weight library is a pre-built rule library that stores the exclusive feature words and their weight scores corresponding to each candidate business domain. For example, the financial domain includes the feature words "accounting" with a weight of 0.8 and "voucher" with a weight of 0.7. String matching is the operation of comparing two strings to determine their similarity or equality, which can use exact matching or edit distance calculation. The domain polymorphism mapping rule table is a pre-defined mapping table that records the correspondence between general semantic concepts, business domains, and domain-specific semantic entities, such as ("Order", "procurement domain") to "PurchaseOrder". The entity-level negative exclusion dictionary is a pre-defined dictionary that stores a set of forced exclusion features for each target semantic entity; for example, for the "person" entity, it stores {"config", "log", "history"}. Normalization is an operation that standardizes strings, including removing specific characters (such as preset prefixes, version suffixes, numbers, and separators) and unifying case. The semantic anchor string is a standardized string obtained after normalization; its physical origin is the physical table name, and its semantic origin is the entity class name text.Machine-readable semantic mapping connections refer to mapping records stored in an ontology library that can be directly parsed and invoked by computer programs, including at least a physical table unique identifier, a semantic entity unique identifier, and a mapping relationship type identifier.

[0047] This application addresses three major technical challenges in heterogeneous data environments: homonymy, non-standard naming, and noise interference, through the synergistic effect of the aforementioned eight steps. Specifically, by acquiring metadata and extracting contextual feature sets, this application provides multi-dimensional clues for subsequent domain determination, enabling the system to perceive the business environment in which the physical table exists. By matching the contextual feature set with a domain feature word weight library and calculating confidence scores, this application achieves automated quantitative determination of the business domain to which the physical table to be mapped belongs, avoiding the inefficiency and subjectivity of manually specifying the domain. By matching the table name of the physical table to be mapped with a set of general semantic concepts, this application determines the general semantic concepts of the intermediate layer, laying the foundation for subsequent polymorphic routing. By jointly querying the domain polymorphic mapping rule table using the target general semantic concept and the target domain, this application achieves dynamic differentiated routing of homonymous concepts in different domains. For example, when the target general semantic concept is "Order" and the target domain is the purchasing domain, the routing is to "PurchaseOrder"; when the target domain is the sales domain, the routing is to "SalesOrder"; and when the target domain is the finance domain, the routing is to "ExpenseBill". This mechanism completely resolves the semantic ambiguity problem caused by terminology overloading, with experimental data showing a disambiguation accuracy of 96.4%. By utilizing an entity-level negative exclusion dictionary for counter-verification, this application achieves high-precision noise filtering at extremely low computational cost. If a physical table name contains mandatory exclusion words (such as "config" or "log"), the mapping is removed, effectively preventing configuration tables, log tables, and temporary tables from being incorrectly mapped to core business entities, significantly reducing the false positive rate compared to traditional regular expression matching. By performing normalization processing on the table name and entity class name text, this application eliminates the influence of technical prefixes (such as "t_" or "tbl_"), version suffixes (such as "_v2"), numeric characters, separators, and case differences on the matching results, enabling the correct alignment of originally significantly different table names (such as "t_bd_customer_v2") and standard entity names (such as "Customer"). By comparing the consistency of the normalized semantic anchor strings, a machine-readable mapping connection is established in the ontology only when they are completely consistent, ensuring the accuracy of the mapping. Experimental data shows that the automatic connection success rate reached 99.2% in the integration test of 15,000 physical tables. In summary, this application achieves high-precision, high-recall, and high-robustness semantic mapping of heterogeneous data through a four-layer architecture of context-aware domain inference, domain polymorphic routing, negative filtering verification, and normalized anchoring.

[0048] Building upon the entity-level mapping described above, this application further provides an attribute-level specialization scheme. Specifically, after completing the entity-level mapping, the computer device obtains the column name text of the target column in the physical table to be mapped, such as the column name "amount". The computer device queries a pre-defined attribute-level polymorphism mapping table based on the general attribute name corresponding to the target general semantic concept (e.g., "amount") and the target domain (e.g., "human resources domain"). The attribute-level polymorphism mapping table records the correspondence between the general attribute name, the domain, and the domain-specific attribute name, for example, ("amount", "human resources domain") to "salary", ("amount", "supply chain domain") to "unitPrice". The computer device determines the domain-specific attribute name corresponding to the general attribute name based on the query results and establishes a mapping connection between the target column and the domain-specific attribute name in the ontology. Through attribute-level specialization, the same field name "amount" is understood as "salary" in the human resources domain and as "unit price" in the supply chain domain, thus solving the semantic adhesion problem at the attribute level and further improving the semantic quality of the knowledge graph.

[0049] In some embodiments of this application, extracting the context feature set corresponding to the physical table to be mapped based on metadata specifically includes: extracting the context feature set corresponding to the physical table to be mapped based on the database schema name, the comment text of the physical table to be mapped, the column name text of the physical table to be mapped, and the names of other physical tables within the same database schema.

[0050] In the above embodiments, the extraction sources of the context feature set are specifically defined as the database schema name, the annotation text of the physical table to be mapped, the column name text of the physical table to be mapped, and the names of other physical tables within the same database schema. The database schema name, such as "hr_db", directly indicates the human resources context; the annotation text of the physical table to be mapped, such as "Employee Information Table", provides a clear business description; the column name text of the physical table to be mapped, such as "emp_id, name, department, salary", contains typical fields in the human resources field; the names of other physical tables within the same database schema, such as "department, attendance, payroll", further strengthen the characteristics of the human resources field. By extracting context features from the metadata in the above four dimensions, this application ensures the comprehensiveness and redundancy of the information required for domain determination. Even if the information in a certain dimension is missing or noisy, the information in other dimensions can still support accurate determination. A preferred extraction method is to splice the above four pieces of information into a complete text string according to a preset format, such as "hr_db Employee Information Table emp_id name department salary department attendance payroll", and use this string as the context feature set. By using the method of splicing strings, subsequent steps can directly perform feature word matching on this string without maintaining a complex data structure, reducing the computational complexity. Experiments show that using the extraction method defined in this application, the feature extraction time is reduced by about 30% compared with the method of item-by-item matching. At the same time, the extraction operation can also include performing word segmentation on the annotation text and column name text, removing stop words (such as "de", "le", "shi"), and retaining content words as feature words to further improve the accuracy of domain determination.

[0051] In some embodiments of this application, according to the context feature set and the preset domain feature word weight library, the target domain corresponding to the physical table to be mapped is determined, which specifically includes: calculating the domain confidence score of the physical table to be mapped corresponding to each candidate domain according to the context feature set, the exclusive feature word set and weight score corresponding to each candidate domain in the domain feature word weight library; determining the candidate domain with the highest domain confidence score as the target domain corresponding to the physical table to be mapped.

[0052] In the above embodiments, the domain confidence score is a numerical value used to quantify the association strength between the physical table to be mapped and a candidate business domain. The higher the score, the greater the likelihood that the physical table to be mapped belongs to that domain. Specific feature words refer to a predefined set of words with domain-distinguishing capabilities for each candidate business domain. For example, specific feature words for the financial domain may include "accounting," "voucher," "account," and "ledger"; specific feature words for the human resources domain may include "employee," "attendance," "salary," and "recruitment." The weight score is a numerical value associated with each specific feature word, used to represent the importance of that feature word in the domain determination. The higher the weight score, the greater the contribution of the feature word to the domain confidence score when it appears. The value range is typically between 0 and 1. This application calculates the confidence score through a weighted summation method, giving the domain determination a quantitative mathematical basis and avoiding subjective judgment or random selection. The specific calculation process is as follows: for each candidate domain, the number of times the specific feature words of that domain appear in the context feature set is counted, and the weight scores corresponding to each occurrence of the feature word are summed to obtain the domain confidence score of that candidate domain. For example, if the context feature set contains "employee" appearing once (weight 0.7) and "salary" appearing once (weight 0.8), the score for the human resources domain is 1.5; the score for the finance domain is 0 (no match); and the score for the supply chain domain is 0. The scores of all candidate domains are compared, and the candidate domain with the highest score is determined as the target domain corresponding to the physical table to be mapped. When multiple candidate domains have equal scores, a default domain can be selected according to a preset priority order, or a manual confirmation process can be triggered. The configurability of the weight scores allows the system to adjust the importance of feature words based on actual business data. For example, if the term "salary" is found to be highly indicative of the human resources domain in actual application, its weight can be adjusted from 0.8 to 0.9 to enhance the judgment effect. Through the above mechanism, this application achieves automated and accurate determination of the business domain to which the physical table belongs, laying the domain foundation for subsequent polymorphic routing.

[0053] In some embodiments of this application, determining the corresponding target domain-specific semantic entities based on the target general semantic concept, the target domain, and a preset domain polymorphism mapping rule table specifically includes: querying the corresponding mapping relationship between the general semantic concept, the domain, and the domain-specific semantic entities in the domain polymorphism mapping rule table based on the target general semantic concept and the target domain; determining the target domain-specific semantic entities corresponding to the physical tables to be mapped from the set of domain-specific semantic entities; and determining the target domain-specific semantic entities corresponding to the physical tables to be mapped that do not have a matching mapping relationship from the set of domain-specific semantic entities based on the default mapping rule corresponding to the target general semantic concept.

[0054] In the above embodiments, the joint key value is composed of the target general semantic concept and the target domain, such as ("Order", "Purchase Domain"). This application performs a lookup operation in the domain polymorphism mapping rule table using the joint key value. The mapping rule table can be implemented using a hash table (HashMap), with a query time complexity of O(1); or it can be implemented using a relational database table, with a query time complexity of O(log n). If a corresponding record is found, for example, ("Order", "Purchase Domain") to "PurchaseOrder", the computer device determines "PurchaseOrder" as the target domain specialized semantic entity. If no corresponding record is found, for example, the system has not yet configured a mapping rule for "Order" + "Logistics Domain", then the default mapping rule is triggered: the target general semantic concept "Order" itself is used as the domain specialized semantic entity, or it is mapped to a preset default entity such as "BaseOrder". This application combines joint key-value queries and default mapping rules to ensure efficient routing of common mapping relationships (direct hit, no additional calculation required) and robust system performance in unconfigured scenarios (fallback mapping, preventing errors due to missing rules). The existence of default mapping rules allows this method to smoothly handle new domains or common concepts without frequent updates to the mapping rule table, reducing system maintenance costs. In practical enterprise applications, the mapping rule table can also support hierarchical inheritance. For example, if "Sales Order" inherits from "Order," then when querying ("Order," "Sales Domain"), if no direct mapping exists, the mapping rule corresponding to the parent concept can be found upwards along the concept inheritance chain, further improving rule reusability and reducing configuration. Furthermore, the mapping rule table can support wildcard matching; for example, ("Order," "*") represents mapping to "BaseOrder" in any domain, serving as a global default rule. Through the above mechanisms, this application achieves dynamic differentiated routing for concepts with the same name in different domains, fundamentally solving the semantic ambiguity problem caused by terminology overloading.

[0055] In some embodiments of this application, the validity of candidate mapping relationships is verified based on the table name of the physical table to be mapped, the target domain specialized semantic entities, and a preset entity-level negative exclusion dictionary to obtain valid candidate mappings. Specifically, this includes: querying the entity-level negative exclusion dictionary based on the target domain specialized semantic entities to determine the set of mandatory exclusion feature words corresponding to the target domain specialized semantic entities; determining the validity of candidate mapping relationships based on the matching results between the table name of the physical table to be mapped and the set of mandatory exclusion feature words; and eliminating invalid candidate mapping relationships and retaining valid candidate mapping relationships.

[0056] In the above embodiments, the forced exclusion feature word set refers to a set of words associated with a specific target semantic entity. If the table name of the physical table to be mapped contains any of these words, the system forcibly refuses to map the physical table to the semantic entity. For example, for the entity "Person", the forced exclusion feature word set may include "config", "log", "history", "backup", "temp", and "test". This application achieves low-cost, high-precision noise filtering through proof by contradiction logic. The specific implementation process is as follows: First, using the target domain-specific semantic entity as the key (e.g., "Person"), query the entity-level negative exclusion dictionary to obtain the corresponding forced exclusion feature word list ["config", "log", "history", "backup", "temp"]. Second, convert the table name of the physical table to be mapped to a lowercase string, such as "sys_user_config", and then traverse the exclusion word list, checking whether the lowercase string contains each exclusion word. Checking whether it contains "config", the result is yes. Therefore, the current candidate mapping relationship is determined to be invalid. Third, remove the mapping relationship between the physical table to be mapped and the "Person" entity from the candidate mapping set. If the table name of the physical table to be mapped is "bd_user", and no match is found after traversing the exclusion word list, the current candidate mapping relationship is deemed valid and retained as a valid candidate mapping. This application, through the aforementioned proof-of-contrast mechanism, requires only a simple string inclusion check, with a computational complexity of O(n×m) (n is the number of exclusion words, usually less than 10; m is the table name length, usually less than 100), which can be completed in milliseconds. Compared to traditional methods that rely on complex machine learning models to determine table types (requiring training data and inference time, typically taking seconds or even minutes), this application has extremely low computational overhead, making it suitable for large-scale real-time data processing scenarios. Experimental data shows that this mechanism can intercept over 95% of noisy data from system tables, configuration tables, log tables, temporary tables, backup tables, etc., greatly reducing the risk of the knowledge graph being polluted by invalid nodes. In actual deployment, the forced exclusion feature word set can support regular expression matching; for example, the exclusion word ".*_log" represents matching any table name ending with "_log", further enhancing the flexibility of matching. In addition, the negative exclusion dictionary can also support hierarchical inheritance, that is, child entities inherit the exclusion word set of the parent entity. For example, the "Manager" entity inherits the exclusion word set of the "Person" entity without repeated configuration.

[0057] In some embodiments of this application, normalization processing is performed on the table names and entity class names corresponding to valid candidate mappings, specifically including: performing noise reduction and normalization processing on the table names of the physical tables to be mapped, the noise reduction and normalization processing including: removing preset prefix characters, removing version suffix characters, removing numeric characters, removing separator characters, and uniformly converting letters to lowercase to obtain physical semantic anchor strings; performing standardization and normalization processing on the entity class name text, the standardization and normalization processing including: uniformly converting entity class name text to lowercase to obtain semantic anchor strings.

[0058] In the above embodiments, noise reduction and normalization refers to the operation of cleaning and standardizing physical table names. Preset prefix characters include common technical prefixes such as "t_", "tbl_", and "bd_", which are usually introduced by database design specifications or legacy system naming habits and do not carry business semantics. Version suffix characters include version identifiers such as "_v2", "_v3", and "_2024", used to distinguish different versions of the same table. Numeric characters are usually meaningless serial numbers or version numbers. Separator characters include underscores "_", hyphens "-", and periods ".", used to connect words but hindering direct string comparison. A uniform conversion to lowercase is used to eliminate case sensitivity. Standardization and normalization refers to the normalization operation performed on entity class name text, at least including a uniform conversion to lowercase, and optionally also including the removal of namespace prefixes (such as "ent:"). This application, through the above lightweight string transformation operations, unifies the originally vastly different table names and standard entity names into a comparable standardized form. For example, the physical table name "t_bd_customer_v2" undergoes denoising and normalization: removing "t_" yields "bd_customer_v2", removing "bd_" yields "customer_v2", and removing "_v2" yields "customer". It contains no numeric characters or separators and is converted to lowercase to "customer". The entity class name "Customer" is also normalized to "customer". Since they are consistent, a mapping can be established. Conversely, the physical table name "po_order" becomes "poorder" after denoising and normalization, while the entity class name "PurchaseOrder" becomes "purchaseorder" after normalization. Since they are inconsistent, no mapping is established, avoiding incorrect matching. Compared to complex similarity algorithms such as calculating edit distance (time complexity O(L^2)), this method has extremely low computational cost (time complexity O(L), where L is the string length) and does not require training corpora or external dictionaries (such as WordNet), making it suitable for large-scale, high-throughput data integration scenarios. Experimental data shows that, using the normalization processing specified in this application, the automatic connection success rate reached 99.2% in the integration test of 15,000 physical tables. In actual deployment, the preset prefix character set and version suffix pattern can be configured and extended according to the enterprise naming conventions. For example, prefixes such as "tmp_", "bak_", and "_old" can be added, as well as version suffix patterns such as "_v1.0" and "_rev2", so that the normalization processing can adapt to the naming habits of different enterprises.

[0059] In some embodiments of this application, a machine-readable semantic mapping connection relationship between the physical table to be mapped and the specialized semantic entity of the target domain is established in the ontology based on the consistency verification result of the semantic anchor string. Specifically, this includes: determining the matched physical table to be mapped and the specialized semantic entity of the target domain based on the text consistency verification result of the physical anchor string and the semantic anchor string; and writing the semantic mapping connection relationship between the physical table to be mapped and the specialized semantic entity of the target domain into the ontology based on the matched physical table to be mapped and the specialized semantic entity of the target domain.

[0060] In the above embodiments, text consistency verification refers to the operation of determining whether the physical-side semantic anchor string and the semantic-side semantic anchor string are completely identical. This application calls a string comparison function (such as strcmp or equals method) to perform the verification. If the two strings are completely identical, the physical table to be mapped and the target domain specialized semantic entity are determined to be matched. For example, if the physical-side semantic anchor string "customer" is completely identical to the semantic-side semantic anchor string "customer", then the physical table to be mapped "t_bd_customer_v2" and the semantic entity "Customer" are matched. Then, this application writes a mapping relationship record in the mapping relationship table of the ontology library. The mapping relationship record includes at least three fields: a unique identifier of the physical table to be mapped (such as table ID or full table name "scm_db.t_bd_customer_v2"), a unique identifier of the target domain specialized semantic entity (such as entity URI "http: / / example.com / ontology / Customer"), and a mapping relationship type identifier (such as "HAS_PHYSICAL_TARGET"). The mapping relationship type identifier is used to indicate that the physical table to be mapped is the physical implementation source of the target domain-specific semantic entity. This application explicitly writes mapping relationship records, solidifying the results of dynamic determination into persistent data in the ontology library. Downstream applications, such as heterogeneous database semantic retrieval engines or knowledge graph entity alignment modules, can directly utilize these pre-stored mapping relationships without repeatedly executing the mapping determination process of this application. For example, when the retrieval engine receives a user query "query all customers", it queries the mapping relationship table to find that the physical table corresponding to the semantic entity "Customer" is "scm_db.t_bd_customer_v2", thereby generating the correct SQL query statement "SELECT *FROM t_bd_customer_v2". When the knowledge graph entity alignment module needs to align customer instances from external data sources to customer entities in the ontology, the mapping relationship record provides a bridge between physical data and semantic entities. Through the above mechanism, this application decouples the mapping logic from query execution, improving the system's runtime performance and maintainability. Simultaneously, the standardized format of the mapping relationship record (unique identifier + mapping type) facilitates data exchange and integration between different modules. In actual deployments, mapping relationship records can also contain additional information, such as the confidence score of the mapping relationship (e.g., 0.95), creation time, update time, version number, and mapping source (automatic mapping or manual confirmation). This additional information can be used for quality assessment and lifecycle management of mapping relationships.Ontologies can be implemented using graph databases (such as Neo4j) or triple storage (such as RDF Store). Mapping relationship records are stored in the form of graph edges or triples, which facilitates graph traversal and semantic reasoning, further expanding the application capabilities of knowledge graphs.

[0061] like Figures 2 to 5 As shown, attached Figure 2This is a flowchart of a heterogeneous data semantic mapping method, specifically a three-layer core architecture flowchart of a heterogeneous data semantic mapping method based on domain polymorphism and context awareness. The overall process starts from the top input layer, which is a heterogeneous data source. Internally, it contains core input information such as table metadata (Table: t_user_config) and schema (Schema: finance_db). The aforementioned layers pass the input data down to the first-layer context-aware module via a process link marked 210. The first-layer context-aware module includes a feature extraction InferDomain step and a polymorphic mapping rule step, and is also marked with "Solve..." The core function of the polysemous word "Org-FinanceOrg" is to extract contextual features from the input data in the InferDomain step, outputting the context information of "Finance" and passing it to the polymorphic mapping rule step. The polymorphic mapping rule step performs rule matching based on the input context information. When a rule is matched, it outputs the candidate semantic "ent:FinanceOrg"; otherwise, it outputs the candidate semantic "ent:Person". After completing the first layer of processing, the aforementioned module passes the candidate semantic information down to the second layer, the negative dictionary filtering (NegativeFilter) module, through the process link marked 220. The core function of the second-layer negative dictionary filtering module, marked as "resolving false positives (Userconfig!=Person)," is to pre-load a negative dictionary. The contents of this dictionary are input to the "Contains excluded words?" judgment stage. This stage matches the candidate semantics passed from the first layer with the physical table name. If the judgment result is "yes," the operation of "blocking the mapping downgrade to Configuration" is executed; if the judgment result is "no," the operation of "retaining the mapping and confirming it as Person" is executed. After completing the validity verification and filtering, the module passes the valid candidate mapping information down to the third layer of fault-tolerant matching and anchoring (Nu) through the process link marked 230. The clearMatching module; the third-layer fault-tolerant matching and anchoring module sets up two parallel normalization processing paths for physical name and semantic name. The input of the physical name path is t_bd_customer_v2, which is output to the anchor point customer after denoising and normalization. The input of the semantic name path is Customer, which is also output to the anchor point customer after denoising and normalization to complete consistency matching. Finally, based on the anchor point matching result, the operation of "establishing connection HAS_PHYSICAL_TARGET" is executed to complete the entire closed loop of the heterogeneous data semantic mapping. The overall process of the aforementioned layers is completed by labeling 240 to finish the link.

[0062] like Figure 3 and Figure 4As shown, the fault-tolerant matching and anchoring process of heterogeneous physical table sources is presented. That is, the four table names t_sales_order, TBL_SalesOrder, sales_order_2024, and salesorder_v2 in the heterogeneous physical table sources are synchronously input into the normalization processing unit. The four steps of processing are executed in sequence: removing the t_ / tbl_ prefix, removing the number / version number, removing the separator, and uniformly converting to lowercase. A unified salesorder anchor point is generated, which completes the full-database anchor matching with the normalized ontology class ent:SalesOrder in the semantic graph target. Finally, the mapping relationship between MAPPED_TO and HAS_PHYSICAL_TARGET is created. Figure 3 The presentation of the polymorphic disambiguation process in scenario A starts with the input word "Organization" and enters the context detection stage. If the "HR" context is detected, it is mapped to "ent:Department"; if the "Finance" context is detected, it is mapped to "ent:FinanceOrg" and outputs a 96.4% accuracy improvement result. If no specific context is detected, it is mapped to "ent:Organization" according to "Default". This fully reflects the two core technical features of context-aware domain polymorphic disambiguation and normalization-based fault-tolerant anchoring.

[0063] Figure 5 The process begins with the heterogeneous physical table source at the top. This source contains four heterogeneous physical tables with different naming formats: t_sales_order, TBL_SalesOrder, sales_order_2024, and salesorder_v2. The table names from all four tables are simultaneously input into the normalization processing unit below. This unit performs four normalization operations in sequence: first, removing the prefixes 't_' and 'tbl_' from the table names; second, removing numbers and version numbers from the table names; third, removing underscore separators from the table names; and fourth, unifying the letter representation of the table names. After being converted to lowercase and normalized in four steps, the table name data is output to the full database anchor point step below. The core anchor point of the full database anchor point is salesorder. At the same time, the semantic graph target contains the ontology class ent:SalesOrder. After normalization, the aforementioned ontology class also points to the salesorder anchor point of the full database anchor point. After consistency matching of the full database anchor point, it is determined that the match is successful. Finally, the relationship creation operation is performed below to establish the mapping relationship between the ontology and physical table of MAPPED_TO / HAS_PHYSICAL_TARGET, completing the entire fault-tolerant matching and anchoring process.

[0064] Figure 5This is a flowchart of a heterogeneous data semantic mapping method, specifically an execution flowchart of a polymorphic disambiguation scenario for heterogeneous data semantic mapping. The scenario is labeled Scenario A: Polymorphic Disambiguation. The process begins with the input word "Organization" at the top. The input word moves down to the diamond-shaped decision stage of "Detect Context?". The aforementioned decision stage outputs three branch results: HR, Finance, and Default. The HR branch maps down to the ontology entity ent:Department, the Finance branch maps down to the ontology entity ent:FinanceOrg, and the Default branch maps down to the ontology entity ent:Organization. The mapping result of the Finance branch is marked with a dashed line indicating "accuracy improvement," ultimately pointing down to a disambiguation accuracy result of 96.4%. This fully presents the complete execution logic and technical effect of context-aware domain polymorphic disambiguation.

[0065] like Figure 6 As shown, embodiments of this application provide a heterogeneous data semantic mapping device 300, including: a data acquisition module 310, used to acquire metadata of a physical table to be mapped in a heterogeneous database, the metadata including at least the database schema name, the table name of the physical table to be mapped, comment text, column name text, and the names of other physical tables within the same schema; a context feature extraction module 320, used to extract a set of context features corresponding to the physical table to be mapped based on the metadata; a business domain adjudication module 330, used to determine the target domain corresponding to the physical table to be mapped based on the set of context features and a preset domain feature word weight library; a general concept matching module 340, used to perform string matching between the table name of the physical table to be mapped and a set of general semantic concepts to determine the target general semantic concept; and a polymorphic mapping module. The mapping module 350 is used to determine the corresponding target domain specialized semantic entities based on the target general semantic concepts, the target domain, and a pre-set domain polymorphism mapping rule table. The negative filtering and verification module 360 ​​is used to verify the validity of candidate mapping relationships based on the table name of the physical table to be mapped, the target domain specialized semantic entities, and a pre-set entity-level negative exclusion dictionary, and obtain valid candidate mappings. The normalization anchoring module 370 is used to perform normalization processing on the table name and entity class name text corresponding to the valid candidate mappings to obtain semantic anchor strings for the physical end and the semantic end. The mapping relationship establishment module 380 is used to establish a machine-readable semantic mapping connection relationship between the physical table to be mapped and the target domain specialized semantic entities in the ontology library based on the consistency verification result of the semantic anchor strings.

[0066] The heterogeneous data semantic mapping device 300 provided in this application embodiment achieves automated, high-precision, and highly robust semantic mapping of heterogeneous database physical tables through multi-module collaboration, significantly improving mapping efficiency and accuracy, effectively filtering invalid mapping relationships, and providing standardized and reusable semantic connections for the business ontology database.

[0067] like Figure 7 As shown, an embodiment of this application provides a heterogeneous data semantic mapping apparatus 400, including a processor 402 and a memory 404. The memory 404 stores a program or instructions. When the processor 402 executes the program or instructions in the memory 404, it implements the steps of the heterogeneous data semantic mapping method as described in any of the above embodiments. Therefore, the heterogeneous data semantic mapping apparatus 400 possesses all the beneficial effects of the heterogeneous data semantic mapping method as described in any of the above embodiments.

[0068] Embodiments of this application provide a readable storage medium on which a program or instructions are stored. When executed by a processor, the program or instructions implement the steps of the heterogeneous data semantic mapping method as described in any of the above embodiments. Therefore, the readable storage medium possesses all the beneficial effects of the heterogeneous data semantic mapping method as described in any of the above embodiments.

[0069] In the claims, description, and accompanying drawings of this invention, the term "plural" refers to two or more. Unless otherwise explicitly defined, the terms "upper," "lower," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and simplifying the descriptive process, and are not intended to indicate or imply that the device or element referred to must have the described specific orientation, or be constructed and operated in a specific orientation. Therefore, these descriptions should not be construed as limiting the invention. The terms "connected," "installed," "fixed," etc., should be interpreted broadly. For example, "connected" can be a fixed connection between multiple objects, a detachable connection between multiple objects, or an integral connection; it can be a direct connection between multiple objects or an indirect connection between multiple objects through an intermediate medium. For those skilled in the art, the specific meaning of the above terms in this invention can be understood based on the specific circumstances described above.

[0070] In the claims, description, and accompanying drawings of this invention, the terms "one embodiment," "some embodiments," "specific embodiment," etc., refer to a specific feature, structure, material, or characteristic described in connection with that embodiment or example, which is included in at least one embodiment or example of the invention. In the claims, description, and accompanying drawings of this invention, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0071] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A heterogeneous data semantic mapping method, characterized in that, The method, executed by a computer device, is used to map physical tables to be mapped in a heterogeneous database to an ontology library stored on the computer, establishing a machine-readable mapping relationship. The ontology library stores a set of general semantic concepts and a set of domain-specific semantic entities. The method includes: Obtain the metadata of the physical table to be mapped in the heterogeneous database. The metadata includes at least the database schema name, the table name of the physical table to be mapped, the comment text, the column name text, and the names of other physical tables in the same schema. Extract the context feature set corresponding to the physical table to be mapped based on the metadata; Based on the context feature set and the preset domain feature word weight library, the target domain corresponding to the physical table to be mapped is determined; The target general semantic concept is determined by matching the table name of the physical table to be mapped with the set of general semantic concepts. Based on the target general semantic concept, the target domain and the preset domain polymorphism mapping rule table, determine the corresponding target domain specialized semantic entity; Based on the table name of the physical table to be mapped, the specialized semantic entity of the target domain, and the preset entity-level negative exclusion dictionary, the validity of the candidate mapping relationship is verified to obtain the valid candidate mapping; Normalization is performed on the table name and entity class name text corresponding to the valid candidate mapping to obtain the semantic anchor string of the physical end and the semantic end; Based on the consistency verification result of the semantic anchor string, a machine-readable semantic mapping connection relationship is established between the physical table to be mapped and the specialized semantic entity of the target domain in the ontology.

2. The method according to claim 1, characterized in that, The step of extracting the context feature set corresponding to the physical table to be mapped based on the metadata specifically includes: Based on the database schema name, the comment text of the physical table to be mapped, the column name text of the physical table to be mapped, and the names of other physical tables within the same database schema, extract the context feature set corresponding to the physical table to be mapped.

3. The method according to claim 1, characterized in that, The step of determining the target domain corresponding to the physical table to be mapped based on the context feature set and a preset domain feature word weight library specifically includes: Based on the context feature set, the exclusive feature set and weight score of each candidate domain in the domain feature word weight library, calculate the domain confidence score of each candidate domain corresponding to the physical table to be mapped; The candidate domain with the highest domain confidence score is determined as the target domain corresponding to the physical table to be mapped.

4. The method according to claim 1, characterized in that, The step of determining the corresponding target domain-specific semantic entities based on the target general semantic concept, the target domain, and a pre-set domain polymorphism mapping rule table specifically includes: Based on the target general semantic concept and the target domain, query the corresponding mapping relationship between the general semantic concept, domain and domain specialized semantic entity in the domain polymorphism mapping rule table, and determine the target domain specialized semantic entity corresponding to the physical table to be mapped from the domain specialized semantic entity set; Based on the default mapping rules corresponding to the target general semantic concept, the target domain specialized semantic entities corresponding to the physical tables to be mapped that do not have matching mapping relationships are determined from the domain specialized semantic entity set.

5. The method according to claim 1, characterized in that, The step of verifying the validity of candidate mapping relationships and obtaining valid candidate mappings based on the table name of the physical table to be mapped, the target domain specialized semantic entities, and a pre-set entity-level negative exclusion dictionary specifically includes: Based on the target domain specialized semantic entity, query the entity-level negative exclusion dictionary to determine the set of forced exclusion feature words corresponding to the target domain specialized semantic entity; The validity of the candidate mapping relationship is determined based on the matching results between the table name of the physical table to be mapped and the set of forced exclusion features. Eliminate invalid candidate mappings and retain valid candidate mappings.

6. The method according to claim 1, characterized in that, The normalization process performed on the table names and entity class names corresponding to the valid candidate mappings specifically includes: The table name of the physical table to be mapped is subjected to noise reduction and normalization processing. The noise reduction and normalization processing includes: removing the preset prefix characters, removing the version suffix characters, removing the numeric characters, removing the separator characters, and converting all letters to lowercase to obtain the physical semantic anchor string. The entity class name text is standardized and normalized. The standardization and normalization process includes converting the entity class name text to lowercase to obtain the semantic anchor string.

7. The method according to claim 1, characterized in that, The step of establishing a machine-readable semantic mapping connection between the physical table to be mapped and the target domain specialized semantic entity in the ontology based on the consistency verification result of the semantic anchor string specifically includes: Based on the text consistency verification results between the physical end semantic anchor string and the semantic end semantic anchor string, the matching physical table to be mapped and the target domain specialized semantic entity are determined; Based on the matched physical table to be mapped and the target domain specialized semantic entity, the semantic mapping connection relationship between the physical table to be mapped and the target domain specialized semantic entity is written into the ontology library.

8. A heterogeneous data semantic mapping device, characterized in that, include: The data acquisition module is used to acquire the metadata of the physical table to be mapped in the heterogeneous database. The metadata includes at least the database schema name, the table name of the physical table to be mapped, the comment text, the column name text, and the names of other physical tables in the same schema. The context feature extraction module is used to extract the context feature set corresponding to the physical table to be mapped based on the metadata; The business domain adjudication module is used to determine the target domain corresponding to the physical table to be mapped based on the context feature set and the preset domain feature word weight library; The general concept matching module is used to perform string matching between the table name of the physical table to be mapped and the general semantic concept set to determine the target general semantic concept; The polymorphism mapping module is used to determine the corresponding target domain specialized semantic entities based on the target general semantic concept, the target domain, and a preset domain polymorphism mapping rule table. The negative filtering and verification module is used to verify the validity of the candidate mapping relationship and obtain the valid candidate mapping based on the table name of the physical table to be mapped, the target domain specialized semantic entity and the preset entity-level negative exclusion dictionary; The normalization anchoring module is used to perform normalization processing on the table name and entity class name text corresponding to the effective candidate mapping, respectively, to obtain the semantic anchor string of the physical end and the semantic end; The mapping relationship establishment module is used to establish a machine-readable semantic mapping connection between the physical table to be mapped and the target domain specialized semantic entity in the ontology library based on the consistency verification result of the semantic anchor string.

9. A heterogeneous data semantic mapping device, characterized in that, include: processor; A memory storing a program or instructions, wherein the processor, when executing the program or instructions in the memory, implements the steps of the heterogeneous data semantic mapping method as described in any one of claims 1 to 7.

10. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the heterogeneous data semantic mapping method as described in any one of claims 1 to 7.

Images