A method and apparatus for knowledge representation and inference of business logic

Abstract

This application discloses a method and apparatus for knowledge representation and deduction of business logic. The method includes: generating a semantic graph corresponding to the business logic at the concept layer based on a knowledge representation model; wherein the semantic graph includes one or more types of nodes and edges connecting one or more types of nodes, and the nodes include at least nodes of variable type; generating an instance graph based on the semantic graph and the physical table to which the business object is mapped; wherein the instance graph includes nodes and edges in the semantic graph; generating executable code based on the business logic relationships between nodes in the instance graph; determining the data instance corresponding to each node in the instance graph based on the data instance corresponding to the node with an in-degree of 0 and the executable code; wherein the data instance corresponding to the node can be deduced based on the data instance of the preceding branch node to which the node depends.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a method and apparatus for knowledge representation and deduction of business logic. Background Technology

[0002] Currently, much professional knowledge exists in various business areas of enterprises but is not explicitly expressed. During business analysis, users need to externally organize this knowledge into specific business logic and apply it to data to obtain analytical results. Because this business logic is not explicitly represented, the analysis process often requires IT personnel to consult with business personnel to understand their needs, which are then translated into computer code and embedded in the IT system. Only after the dataset is processed by the code can the results be fed back to the business. This leads to several inconveniences: First, the chain from professional knowledge to feedback of calculation results is long, involving multiple stages such as IT's understanding and analysis of business requirements, module design, code development and testing, resulting in a relatively long cycle. Business personnel cannot directly configure knowledge and then use the calculation results to obtain timely feedback. Second, business users cannot see the business logic implemented in the IT system, nor can they intervene in or adjust the logic. This leads to two consequences: first, the results lack interpretability, leaving users confused about how the calculated results were obtained; second, the logic cannot be dynamically adjusted. Business users often have a need to dynamically adjust logic during the inference and analysis process. For example, business logic is based on certain assumptions and estimates, which need to be evaluated based on real-time feedback of calculation results to determine whether they meet expectations and whether dynamic adjustments are necessary. However, traditional inference systems hide business logic in IT code, and any logic adjustment will trigger the system development change process (as described in point 1 above). This means that they cannot support real-time logic adjustments, let alone provide real-time feedback on the results calculated based on the new logic. Third, the conceptual representation layer and instance layer of business knowledge are not decoupled, so the system does not have the function of automated knowledge management and analysis.

[0003] Here, expressions related only to business logic are called conceptual layer representations, while the combination of business logic and data structure, concretized into executable code logic in the actual operating environment, is called instance layer representation. The two are closely linked; the transition from the conceptual layer to the instance layer is an instantiation process, and also a process of business knowledge moving from abstraction to concreteness. Traditional IT system implementations only retain the logic of the instance layer, without explicit expression of the conceptual layer or establishing any connection. This has several limitations: First, because the conceptual layer is not expressed or abstracted, it lacks knowledge management and reasoning capabilities, and cannot perform correlation and impact analysis between logical elements; second, because the instance layer logic fails to establish a connection with data results, it cannot support what-if analysis; third, because the conceptual layer logic and instance layer logic are not connected, automatic code generation after user-entered business logic cannot be achieved.

[0004] Faced with the lack of visibility into the logic of the data analysis process and the inability to interpret the results, the current state of technology in the industry is as follows: Some business logic configuration tools exist, which simply implement the IT implementation program code through configuration. Although the IT logic is visible and the calculation results can be fed back in real time, there is no expression of the business logic concept layer. The results remain inexplicable to the business, and the business cannot dynamically adjust the logic based on the calculation results. There are also some tools and inventions similar to rule engines (such as Drools and Qizheng). Although they store business logic in a rule-based manner, achieving separation of business logic and data, these tools lack sufficient expression of the business logic concept layer. This is reflected in the fact that rule elements are not explicitly expressed, which cannot support subsequent automated knowledge management or perform correlation and influence analysis between elements. Summary of the Invention

[0005] This application provides a method and apparatus for knowledge representation and deduction of business logic.

[0006] In a first aspect, embodiments of this application propose a method for knowledge representation and deduction of business logic, the method comprising:

[0007] Based on the knowledge representation model, a semantic graph corresponding to the business logic of the concept layer is generated; wherein, the semantic graph includes one or more types of nodes and edges connecting the one or more types of nodes, and the nodes include at least variable type nodes;

[0008] An instance graph is generated based on the semantic graph and the physical tables to which the business objects are mapped; wherein, the instance graph includes the nodes and edges in the semantic graph;

[0009] Based on the business logic relationships between the nodes in the example diagram, generate executable code;

[0010] Based on the data instance corresponding to the node with an in-degree of 0 in the instance graph and the executable code, the data instance corresponding to each node in the instance graph is determined; wherein, the data instance corresponding to the node can be deduced based on the data instance of the preceding branch node that the node depends on.

[0011] In one possible implementation, generating a semantic graph corresponding to the business logic of the concept layer based on the knowledge representation model includes:

[0012] Obtain the nodes and edges corresponding to the business logic of the concept layer from the knowledge representation model;

[0013] The semantic graph is generated based on the nodes and edges corresponding to the business logic of the conceptual layer.

[0014] In one possible implementation, the conceptual layer business logic includes: operation rule-based logic, conditional judgment-based logic, and / or complex function / model type logic.

[0015] In one possible implementation, the node further includes: a node of constant type, a node of function type, and / or a node of container type; wherein the node of container type encapsulates a semantic graph including nodes of different types and edges of different types and is called by the semantic graph of the upper layer to construct a multi-level semantic graph.

[0016] In one possible implementation, the edges include: edges of flow control relation type, edges of computation relation type, edges of logical judgment relation type, and / or edges of logical link relation type.

[0017] In one possible implementation, generating executable code based on the business logic relationships between nodes in the instance graph includes:

[0018] Starting with the node with an in-degree of 0 in the instance graph, perform a local breadth-first traversal and generate multiple independent paths that can run in parallel based on the dependencies between nodes in the instance graph.

[0019] During the traversal, sub-paths that match the predefined meta-path features are identified, and executable code is generated based on the type of nodes in the path and the semantic meaning of the edges.

[0020] If a container-type node is found during the traversal, the logic of the lower-level subgraph encapsulated by the container node is opened, the subgraph is traversed according to the same logic, the executable code in the subgraph is generated, and then the upper-level instance graph is returned to continue to complete the subsequent operations.

[0021] In one possible implementation, the method further includes:

[0022] Based on predefined meta-path characteristics, paths containing nodes that do not have data instances in the instance graph are removed.

[0023] In one possible implementation, the method further includes:

[0024] Determine the running status and progress of the executable code in the computing environment.

[0025] In one possible implementation, the method further includes:

[0026] Conflict detection is performed on the semantic graph.

[0027] In one possible implementation, the conflict detection of the semantic graph includes:

[0028] If it is determined that the initially detected node is not in the current set of nodes in the connected graph, then a depth-first traversal is performed starting from the initially detected node.

[0029] For each node encountered, if the node has no access mark, an access mark is added, the node is added to the current node set of the connected graph, and the traversal continues. Otherwise, a directed cycle is found, and the path information consisting of all nodes with access marks is output. If the out-degree of the node is greater than 1 and / or the in-degree is greater than 1, its unvisited preceding branch nodes and / or following branch nodes are stored in a queue.

[0030] If the out-degree of the node is 0, then clear the access flags of all nodes in the current connected graph, and take a new node from the queue of the preceding branch node and / or the following branch node, and repeat the above steps; otherwise, select a node from all nodes in the current connected graph and repeat the above steps.

[0031] In one possible implementation, the method further includes:

[0032] Logical ambiguity detection is performed on the semantic graph.

[0033] In one possible implementation, the logical expression ambiguity detection of the semantic graph includes:

[0034] In the semantic graph, if at least two processing methods occur when the assumptions of the conceptual layer business logic expressed by if-then are true, it is determined that there is a logical expression ambiguity in the semantic graph.

[0035] In one possible implementation, the method further includes:

[0036] An association impact analysis is performed on the dependency relationships between nodes in the instance graph, and a what-if analysis is performed based on the adjusted data instance; wherein, the what-if analysis is used to characterize the impact of the adjusted data instance on subsequent dependent nodes.

[0037] In one possible implementation, the method further includes:

[0038] If the data instance corresponding to the node in the instance graph does not meet the business expectations, then a semantic graph corresponding to the modified concept layer business logic is regenerated based on the knowledge representation model.

[0039] Secondly, embodiments of this application propose a knowledge representation and deduction apparatus for business logic, including at least one processor, the processor being configured to execute a program stored in a memory, wherein when the program is executed, the apparatus performs the following:

[0040] Such as the methods in the first aspect and its various possible implementations.

[0041] Thirdly, embodiments of this application propose a computer program product containing instructions that, when run on a computer, cause the methods described in the first aspect and its various possible implementations to be executed by the computer.

[0042] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, performs methods as described in the first aspect and its various possible implementations. Attached Figure Description

[0043] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0044] Figure 1 A schematic diagram of a system provided in an embodiment of this application;

[0045] Figure 2 A schematic diagram of a semantic graph corresponding to business logic provided in an embodiment of this application;

[0046] Figure 3 A flowchart illustrating a knowledge representation and deduction method for business logic provided in an embodiment of this application;

[0047] Figure 4 A schematic diagram of a semantic graph provided in an embodiment of this application;

[0048] Figure 5 A schematic diagram of the user interface provided in an embodiment of this application;

[0049] Figure 6 This is a schematic diagram illustrating the mapping of business objects and their attributes to physical tables and fields in the physical tables, as provided in the embodiments of this application.

[0050] Figure 7 A schematic diagram of data instances corresponding to each element in the attributes of the business object provided in the embodiments of this application;

[0051] Figure 8 A schematic diagram of an example diagram (showing data instances corresponding to some nodes) provided for an embodiment of this application;

[0052] Figure 9 This is a schematic diagram illustrating the generation of multiple independent, parallel-running paths based on the dependency relationships of nodes in the example diagram, as provided in an embodiment of this application.

[0053] Figure 10 A schematic diagram of the node computation logic dictionary provided in the embodiments of this application;

[0054] Figure 11 A schematic diagram of an example diagram (showing data instances corresponding to all nodes) provided for an embodiment of this application;

[0055] Figure 12 A schematic diagram of a semantic graph showing the existence of loop dependencies provided in an embodiment of this application;

[0056] Figure 13 A schematic diagram of a semantic graph illustrating the existence of logical ambiguity in embodiments of this application;

[0057] Figure 14 This is a schematic diagram illustrating what-if analysis as provided in an embodiment of this application. Detailed Implementation

[0058] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the specific implementation methods of the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0059] It should be noted that the term "and / or" in this application is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. In the embodiments of this application, words such as "exemplary," "for example," or "e.g.," are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary," "for example," or "e.g.," in the embodiments of this application should not be construed as superior to other embodiments or design schemes. Specifically, the use of words such as "exemplary" or "e.g.," is intended to present the relevant concepts in a specific manner. In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0060] In one possible implementation, a business logic code generation method is proposed, the specific process of which is as follows: First, the data source, logical operation, and data output channel are pre-encapsulated into visual data source components, logical operation components, and data output channel components for user selection; then, users can set corresponding component parameters for these data source components, logical operation components, and data output channel components according to the application scenario; second, users drag and drop the above components to complete the connection between components and form a flowchart; third, the system converts the flowchart into its corresponding string; and then parses the string to generate business logic code. The main purpose of the above solution is to improve the efficiency of developers by writing commonly used processing methods in the data preprocessing process into code functions, and then encapsulating them into visual components, providing users with a drag-and-drop interface to achieve visual programming. The above solution shields the underlying technology, simplifies the development process of big data, lowers the development threshold, and makes it easier, more controllable, and more reliable to handle most streaming and real-time big data processing application scenarios. However, since the configurable granularity is still at the relatively large-granular data component level, the flexibility is somewhat reduced. Furthermore, due to its coarse granularity, the influencing factors of its business logic are not explicitly revealed, making it unsuitable for subsequent knowledge analysis and quality management. Additionally, because the conceptual and instance layers of the business logic are not separated, it cannot support configuration by business personnel. The rules are executable, but the dependencies between rules cannot be explicitly expressed, and the results of the logical calculations are uninterpretable.

[0061] In another possible implementation, a business rule processing method, apparatus, device, system, and storage medium are proposed. This method configures multiple business rules based on business objectives. These multiple business rules can form a circular directed graph structure according to the execution order and dependencies configured in the rule configuration information. Each business rule is executed according to its execution order and dependencies. This technical solution can efficiently and flexibly handle business rules for complex businesses, thus supporting application scenarios requiring real-time decision-making, such as distributed and high-concurrency scenarios. However, because the logical management granularity of the business configuration in this technical solution is at the rule level, the dependencies between business logics can only be defined at the rule-level logical unit granularity. In actual business logic, each rule contains multiple rule elements, and a rule can only be executed when all rule elements are complete. Therefore, only by explicitly expressing these element information can the dependencies between rules be intuitively revealed. For example, different rules often share common rule elements, indicating a common dependency between them. Another example: the rule elements that rule B depends on can only be obtained from the output of rule A, thus indicating a dependency between rules A and B. However, neither this invention nor existing rule engines on the market can explicitly express the rule elements in business rules, thus inevitably resulting in the limitations mentioned above.

[0062] Figure 1 This is a schematic diagram of a system applicable to an embodiment of this application. For example... Figure 1 As shown, the entire system comprises three main modules: a business logic configuration module, a heterogeneous graph-based knowledge generation and code translation module, and a knowledge computation module.

[0063] The first module is the business logic configuration module. Users primarily input business logic using a user-friendly interface, such as near-natural language or tables. This includes defining business objects, configuring business logic, and mapping business objects to physical tables. In one example, the business object is defined as the Group Profit and Loss Object. The configured business logic is Profit = Revenue - Cost - Expenses - Other Expenses, and Revenue = Orders * Order-to-Receipt Ratio. The physical table mapped to the business object (Group Profit and Loss Object) is GRP_IS.

[0064] The second module is a knowledge generation and code translation module based on heterogeneous graphs. This application transforms business logic into a form that is easily understood by humans and can be executed by machines. The execution process is visual to support interpretable results, explicitly expressing business elements and supporting the analysis of the relationships and influences between various business elements. This part mainly completes the abstraction of business logic, providing targeted knowledge representation methods so that the knowledge representation space can cover the space of business logic description. The knowledge representation model in this embodiment carries the expression of business logic and completes this function. The semantic graph generation of business logic is mainly based on the knowledge representation model, transforming various different business logics into a unified semantic expression of business logic based on the heterogeneous graph model. The business logic expressed here is still conceptual and has not yet reached a specific level of execution at the data level. The semantic graph to executable code mechanism module mainly completes the automated translation from semantic logic to executable code logic by using a semantic layer of business logic represented by a heterogeneous graph, adding the physical table corresponding to the user-specified business object, specifying a specific execution environment, and using this module. Therefore, this module includes semantic graph generation of business logic, semantic graph and executable code translation mechanism, and construction of a knowledge representation model based on heterogeneous graphs. A semantic graph corresponding to the business logic is generated based on the above knowledge representation model. An instance graph is generated based on the semantic graph and the physical tables mapped to business objects in the business logic. Then, the instance graph is translated into executable code based on the business logic relationships between nodes in the instance graph.

[0065] The third module is the knowledge computing module, which includes knowledge computing and execution status management and knowledge quality management and analysis. Knowledge computing and execution status management ensures that executable code runs in the computing environment and determines its running status and progress. Knowledge quality management and analysis primarily utilizes semantic graphs to check for conflicts and contradictions between business logic representations and supports correlation analysis, specifically including conflict detection and logical ambiguity detection of the semantic graphs.

[0066] In the embodiments of this application, based on business scenario analysis and collection, the following are the main ways of expressing business logic:

[0067] 1) Rule-based logic: There are certain quantitative relationships between business elements, which can be defined by formulas. For example, revenue = orders * order-to-receipt ratio.

[0068] 2) Conditional logic (If…then…): This type of business logic is mainly used in slightly more complex business scenarios where the operational relationships between business elements depend on certain preconditions; or where it is necessary to break down the business scenarios into sub-scenarios based on whether the relationships between business elements are valid or exceed thresholds, and then define the operational relationships between business elements in each sub-scenarios. For example, in the business scenario of determining the deterioration of project revenue and expenditure risks,

[0069] If: Annual forecast - Annual budget < -5M, or Lifetime forecast - Lifetime budget < -5M, where M is Million.

[0070] Therefore: Predicting a worsening of the budgeted tribute level = True

[0071] 3) Complex Function / Model-like Logic: The first two types represent business logic that is easily understood by users, described in a white-box manner. However, in some scenarios, users rely on external functional modules or functions, treating their implementation as a black box and not needing to understand the internal details. In this case, when describing this part of the business logic, we only need to describe the business elements that the black box requires as input, the business functions that the black box can perform, and the business results that the black box outputs.

[0072] For example, customer solvency rating is obtained by feeding a list of customers with transaction history into a machine learning model using complex algorithms. For users, they only need to know the required business elements to obtain the desired customer solvency rating. For instance, Customer Solvency Rating = Customer Solvency Rating Model (Past Year's EBIT, Debt Growth Rate, Liquidity Ratio, Operating Efficiency, ...)

[0073] The aforementioned business logic has its own characteristics. Specifically, it comprises multiple business elements, with numerous quantitative relationships existing between them. This is the primary logical expression method in business analysis and deduction. The quantitative relationships between business elements are not constant and need to be judged within specific scenarios. In more complex scenarios, different quantitative relationships exist under different conditions. While the main body of the business logic is expressed by the business in its own understanding, it also incorporates some external capabilities for assistance. These functions internally provide the business with quantitative data results in a black-box manner. These can be introduced as function nodes in the representation of business knowledge.

[0074] Based on the above characteristics, a business knowledge representation method based on heterogeneous graphs is proposed. The two most basic elements of a heterogeneous graph are nodes and edges. Specifically, nodes represent the business elements contained in the business logic. Based on the different characteristics of the abstracted business elements, nodes can be divided into different types, as shown in Table 1. Edges represent the operational relationships between nodes. Similarly, after abstraction, these relationships are divided into different types based on their differences in characteristics, as shown in Table 2.

[0075] Table 1

[0076]

[0077] Table 2

[0078]

[0079]

[0080] Based on the above heterogeneous graph design, it can support the representation of business logic in data analysis and deduction scenarios. For example, when it is necessary to represent the following business logic in a risk control scenario:

[0081] Logic 1: Risk deterioration value calculation logic. Specifically, when the project risk probe exceeds a certain threshold, risk deterioration is confirmed, and a risk deterioration score is calculated. The business logic can be summarized as follows:

[0082] If: Project risk probe score > Threshold (Equation 1)

[0083] Therefore: Calculate the risk deterioration score

[0084] The project risk probe is related to four key business elements, namely:

[0085] The project is complex (X1), the client interface assumes it did not fall into the tender document (X2), the client interface assumes it did not fall into the contract (X3), and a large proportion of new projects appeared during execution (X4). Each of these four business elements has a quantifiable value. If the sum of these four business element values ​​exceeds a certain threshold, the business assessment indicates a potential risk deterioration in the project. Project Risk Probe Score = X1 + X2 + X3 + X4.

[0086] The magnitude of risk deterioration is quantified by three business factors: project complexity (X1), project change rate (X5), and overdue closure rate (X6). Risk deterioration value = X1 * X5 * X6.

[0087] In this way, business logic elements are represented by nodes of type `variable`, decision logic by nodes of type `Intra_Judge_FUN`, and custom logic by nodes of type `Intra_PreDEF_FUN`. Business logic based on heterogeneous graph representation, i.e.

[0088] If: Project risk assessment logic IF1(x1,x2,x3,x4)

[0089] Therefore: x7 = Project risk deterioration value THEN1(x1,x5,x6)

[0090] If: [(Cost jump judgment logic IF2(x8,x9)and External risk deterioration judgment IF3(x9)]or Project coping deterioration judgment IF4(x7,x8)

[0091] Therefore: x12 = final project risk composite value THEN2(x10, x11)

[0092] like Figure 2 As shown.

[0093] It should be noted that, in this application, the construction of a knowledge representation model for the business logic is the primary problem to be solved. A knowledge representation model is constructed based on the above-mentioned types of business logic. For example, based on the conceptual layer business logic, namely Profit = Revenue - Cost - Expenses - Other Expenses, Revenue = Orders * Order-to-Receipt Ratio, CBG = Honor + Huawei, Global = China + Overseas, the constructed knowledge representation model is {Profit Node, Revenue Node, Cost Node, Expenses Node, Other Expenses Node, Order Node, Order-to-Receipt Ratio Node, CBG Node, Honor Node, Huawei Node, Global Node, China Node, Overseas Node, Edge PartOf, Edge Not_Part Of, Edge FactOf}.

[0094] Figure 3 A flowchart illustrating a knowledge representation and deduction method for business logic proposed in an embodiment of this application is shown, including steps S302-S308.

[0095] The following describes the embodiments provided in this application. Figure 3 This paper provides a detailed introduction to a knowledge representation and deduction method for business logic.

[0096] In one possible implementation, the knowledge representation and deduction method for business logic provided in this application embodiment is achieved through the following steps:

[0097] It should be noted that, in this embodiment, the business object is the group's profit and loss object, and the attributes of the business object are profit and loss indicators, products, and regions. The elements in the profit and loss indicators are profit, revenue, cost, expenses, orders, order-to-receipt ratio, and other expenditures. The elements in the products are CBG, Honor, and Huawei. The elements in the regions are global, China, and overseas. The above-mentioned business object, the attributes of the business object, and the various elements in the attributes of the business object are collectively referred to as business elements. The following uses the conceptual layer business logic of Profit = Revenue - Cost - Expenses - Other Expenses and Revenue = Orders * Order-to-Receipt Ratio as an example to illustrate the knowledge representation and deduction method of the business logic.

[0098] S302, Based on the knowledge representation model, generate a semantic graph corresponding to the business logic of the concept layer; wherein, the semantic graph includes one or more types of nodes and edges connecting the one or more types of nodes, and the nodes include at least variable type nodes.

[0099] In one possible implementation, nodes and edges corresponding to the conceptual layer business logic are obtained from the knowledge representation model. Specifically, users can assemble the business logic by dragging and dropping profit, revenue, cost, expense, other expenditure, order, order-to-receipt ratio, part of, not-part of, and fact of nodes in the aforementioned knowledge representation model, forming a semantic graph corresponding to the conceptual layer business logic: Profit = Revenue - Cost - Expense - Other Expenses, Revenue = Order * Order-to-Receipt Ratio. Alternatively, users can input business logic into the user interface using a similar formalized natural language approach. For example, business element names need to be defined uniformly, and business elements need to be specified using qualifiers <>; scenario judgments should use standardized "if" and "then" keywords. By identifying the business elements and relationships between them in the business logic described in natural language, a semantic graph corresponding to the conceptual layer business logic (Profit = Revenue - Cost - Expense - Other Expenses, Revenue = Order * Order-to-Receipt Ratio) is generated. Inputting business logic includes inputting each business element, defining business objects, configuring business logic, and mapping business objects to physical tables. Furthermore, users can also input information based on a second type of natural language, but instead of directly inputting text strings, a guided input interface is presented, allowing them to input information about various business elements. By identifying the business elements and relationships within the business logic described in the second type of natural language, a semantic graph corresponding to the conceptual layer business logic (i.e., Profit = Revenue - Cost - Expenses - Other Expenses, Revenue = Orders * Order-to-Receipt Ratio) is generated. This semantic graph transforms the business logic into a conceptual level, providing a detailed expression of the business logic, but not yet reaching the level of data-driven execution. The business logic can be visualized in a user-friendly manner. The advantage of visualizing the business logic is that users can directly adjust and configure it. The semantic graph corresponding to the above conceptual layer business logic is shown below. Figure 4 As shown, it can support complex business logic representation; support visual business logic; it can convey business logic in an explicit and easy-to-understand way, facilitating human-computer interaction (here, "human" refers to business personnel); it can sufficiently abstract and structure business logic to support the subsequent automatic conversion of logic into machine-executable code; it clearly expresses the relationships between all elements of business logic, supporting subsequent automated knowledge management and analysis. The above user interface is as follows... Figure 5 As shown.

[0100] S304, Generate an instance graph based on the semantic graph and the physical table to which the business objects are mapped; wherein, the instance graph includes the nodes and edges in the semantic graph.

[0101] See Figure 4 , Figure 4 This is the semantic diagram for the conceptual layer business logic, namely Profit = Revenue - Cost - Expenses - Other Expenses, and Revenue = Orders * Order-to-Receipt Ratio. See also... Figure 6 , Figure 6 The group's profit and loss objects are mapped to the physical table GRP_IS; the attributes (profit and loss indicators) of the group's profit and loss objects are mapped to the field RPT_ITEM; the attributes (products) of the group's profit and loss objects are mapped to the field PROD; and the attributes (regions) of the group's profit and loss objects are mapped to the field REGION. Examples of data corresponding to the elements of ordering, order-to-receipt ratio, cost, expenses, and other expenditures in the attributes (profit and loss indicators) of the group's profit and loss objects are as follows: Figure 7 As shown. According to Figure 4 The semantic graph shown and the corresponding physical table GRP_IS generated as follows Figure 8 The example diagram is shown. See also... Figure 8 ,exist Figure 8 The data displayed includes data instances corresponding to ordering nodes, order-to-receipt ratio nodes, cost nodes, expense nodes, and other expenditure nodes, down to the level of data-level executability.

[0102] It should be noted that if the same business logic needs to be mapped to different physical environments, you only need to change the physical table to which it is mapped.

[0103] S306, Generate executable code based on the business logic relationships between nodes in the example diagram.

[0104] In this embodiment of the application, after generating the instance graph, a local breadth-first traversal is performed, starting with the node with an in-degree of 0 in the instance graph. Multiple independent, parallel-running paths are generated based on the dependencies between nodes in the instance graph, such as... Figure 9 In the example, path1 and path2. Each independent path can be broken down into multiple steps. For example, path1 can be broken down into... Figure 9 As shown, p11, p12, p13, and path2 can be broken down into p21, p22, and p23. Each step uses a dictionary to store the dependencies between nodes, such as... Figure 10As shown, in a certain path of the overall semantic graph, a single step consisting of profit, revenue, cost, expense, and other expenditures is analyzed based on the meta-path features in the single step. The logical relationship between profit and revenue, cost, expense, and other expenditures is parsed: Profit = Revenue - Cost - Expense - Other Expenditure, and then stored in a dictionary data structure. During the traversal, sub-paths matching the predefined meta-path features are identified. Based on the type of nodes and the semantic meaning of the edges in the path, executable code is generated. If a container-type node is found during the traversal, the logic of the lower-level subgraph encapsulated by the container-type node is opened, and the subgraph is traversed according to the same logic to complete the generation of executable code in the subgraph. Then, the upper-level instance graph is returned to continue the subsequent operations. Specifically, through the analysis of predefined meta-path features between nodes in the semantic graph, corresponding to different business logic semantic expressions, such as encountering the following meta-paths: parent <- child node1, with an edge of part of, parent <- child node2, with an edge of part of (here, parent and child are variable types, representing business elements), it is translated as parent = child node1 + child node2, completing the translation into executable code based on the characteristics of semantic graph meta-paths.

[0105] In this embodiment of the application, S306 supports translating business logic into executable code. For example, the business logic, i.e., revenue = order * order-to-receiver ratio, can be translated into SQL as "Select order * ord rev R AS rev from GRP_IS".

[0106] In S304 and S306, business logic and implementation logic are decoupled, and implementation logic can be automatically transformed from business logic. As mentioned earlier, the business logic configured by business personnel supports a visual representation, making it easy to understand. Furthermore, the code logic used for its transformation is completely decoupled. In other words, the business logic describes the essential aspects of the business and is not bound to the backend physical implementation. When the business logic performs an instantiation action, specifying the physical data object to be calculated, it can be automatically transformed into implementation logic—that is, executable code.

[0107] S308, based on the data instance corresponding to the node with an in-degree of 0 in the instance graph and the executable code, determine the data instance corresponding to each node in the instance graph; wherein, the data instance corresponding to the node can be deduced based on the data instance of the preceding branch node to which the node depends.

[0108] In this embodiment, the business logic can be executed in real time after instantiation, providing real-time feedback to the user. Based on the data instances corresponding to the order node and order-to-receipt ratio node being 100 and 0.3 respectively, and the executable SQL code for the business logic revenue = order * order-to-receipt ratio being "Select order * ord rev R AS rev from GRP_IS", the data instance corresponding to the revenue node is 30. Based on the data instances corresponding to the revenue node, cost node, expense node, and other expenditure nodes being 30, 15, 5, and 5 respectively, and the executable code for the business logic profit = revenue - cost - expense - other expenditures, the data instance corresponding to the profit node is 5. The instance diagram after executing the executable code is shown below. Figure 11 As shown in the example diagram, this diagram displays the data instances corresponding to all nodes. That is, the revenue node depends on two preceding branch nodes: the order node and the order-to-receipt ratio node. The data instance corresponding to the revenue node can be deduced from the data instances corresponding to the order node and the order-to-receipt ratio node, and the deduction result is interpretable.

[0109] It should be noted that, in the embodiments of this application, paths containing nodes without data instances in the instance graph can be removed based on predefined meta-path features.

[0110] It should also be noted that this application supports automated knowledge management. After the executable code is generated, knowledge computation and management can be performed, including knowledge computation and execution status management and knowledge quality management and analysis. Specifically, knowledge computation and execution status management ensures the executable code runs in the computing environment and determines its running status and progress. Knowledge quality management and analysis primarily utilizes semantic graphs to check for conflicts and contradictions between business logic representations and supports correlation analysis, specifically including conflict detection and logical ambiguity detection of the semantic graphs.

[0111] Conflict detection on semantic graphs primarily detects cyclic dependencies between business elements. If a cycle exists in the semantic graph, it indicates a circular dependency. Circular dependencies can lead to infinite loops during program scheduling, typically originating from user input errors during business logic configuration. The system searches for errors through cycle detection and then provides feedback to the user for correction. The conflict detection steps are as follows:

[0112] First, if the initially detected node is not in the current set of nodes in the connected graph, then perform a depth-first traversal starting from the initially detected node.

[0113] Then, for each node encountered during traversal, if the node has no visited flag, a visited flag is added, the node is added to the current node set of the connected graph, and the traversal continues; otherwise, a directed cycle is detected. Figure 12As shown, the path information consisting of all nodes with access markers is output; where, if the out-degree of a node is greater than 1 and / or the in-degree is greater than 1, its unvisited preceding branch nodes and / or following branch nodes are stored in a queue.

[0114] Finally, if the out-degree of the node is 0, clear the access flags of all nodes in the current connected graph, and take a new node from the queue of the preceding branch node and / or the following branch node, and repeat the above steps; otherwise, select a node from all nodes in the current connected graph and repeat the above steps.

[0115] Specifically, detecting logical ambiguity in semantic graphs means that if, when the assumptions of the conceptual layer business logic expressed by an if-then statement are true, at least two processing methods exist, then logical ambiguity in the semantic graph is determined. Specifically, it involves checking for logical inconsistencies when expressing business logic using if-then statements. For example... Figure 13 As shown, IF_FUN determines whether the external scenario is satisfied. If both scenarios are satisfied, two processing methods (infer relationship) can be derived and assigned to Y. This leads to the problem of inconsistent logical expression.

[0116] Convenient association impact analysis and what-if analysis. It performs association impact analysis on the dependencies between nodes in the instance graph and conducts what-if analysis based on the adjusted data instances; the what-if analysis characterizes the impact of the adjusted data instances on subsequent dependent nodes. For example, as shown... Figure 14 As shown, the data instances corresponding to the ordering nodes are relatively... Figure 11 If the number of data instances corresponding to the ordering node increases by 50%, then the number of data instances corresponding to the revenue node will be... Figure 11 The number of data instances corresponding to the mid-income node increased by 50%, and the number of data instances corresponding to the profit node increased by [missing information]. Figure 11 The number of data instances corresponding to the mid-profit nodes increased by 300%. As the above analysis shows, the business logic and implementation logic are scalable and reusable. New business requirements can be tracked through the configured business logic, allowing for full utilization of existing implementation logic.

[0117] It should also be noted that this application supports interactive business analysis, allows for dynamic logic adjustment, generates results in near real-time, and provides interpretable results. If the data instance corresponding to the node identified in S208 does not meet business expectations, it can return results such as... Figure 5The user interface shown allows modification of business logic or adjustment of parameter variables, followed by re-execution. Based on the knowledge representation model, a semantic graph corresponding to the modified conceptual layer business logic is regenerated. Business knowledge configuration can be divided into two phases, both visualized. For different roles, the first phase configures the business logic layer for business personnel, while the second phase specifies the actual physical data objects mapped to business objects for IT personnel.

[0118] It should also be noted that the nodes in this embodiment include variable type nodes, and may also include constant type nodes, function type nodes, and / or container type nodes. The type of node is not specifically limited in this embodiment. Different businesses have different requirements for the level of detail in their business logic. Based on a heterogeneous graph with detailed rules, different levels of semantic graphs can be constructed through container nodes to provide multi-level business logic expressions to meet the needs of businesses with different perspectives and levels of detail.

[0119] This application provides a knowledge representation and deduction apparatus for business logic, including at least one processor, which executes instructions stored in a memory to enable, as Figure 3 The steps of the knowledge representation and deduction method for the business logic shown are executed.

[0120] This application provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, such as... Figure 3 The steps of the knowledge representation and deduction method for the business logic shown are executed.

[0121] Based on the same concept as the above-described method embodiments, this application also provides a computer program product including instructions, which, when run on a computer, causes the computer to perform the following... Figure 3 The steps of the knowledge representation and deduction method for the business logic shown are illustrated.

[0122] It should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method of knowledge representation and reasoning of business logic, characterized by, The method comprises: According to the knowledge representation model, a semantic graph corresponding to the concept layer business logic is generated; wherein the semantic graph comprises one or more types of nodes and edges connecting the one or more types of nodes, and the nodes at least comprise variable type nodes; According to the semantic graph and the physical table to which the business object is mapped, an instance graph is generated; wherein the instance graph comprises the nodes and edges in the semantic graph; According to the business logic relationship between the nodes in the instance graph, executable code is generated; According to the data instance corresponding to the node with an in-degree of 0 in the instance graph and the executable code, the data instance corresponding to each node in the instance graph is determined; wherein the data instance corresponding to the node can be deduced according to the data instance of the preceding branch node on which the node depends.

2. The method of claim 1, wherein, The method according to the knowledge representation model, a semantic graph corresponding to the concept layer business logic is generated, comprising: Obtaining nodes and edges corresponding to the concept layer business logic from the knowledge representation model; According to the nodes and edges corresponding to the concept layer business logic, the semantic graph is generated.

3. The method of claim 1, wherein, The concept layer business logic comprises: operation rule type logic, condition judgment type logic and / or complex function / model type logic.

4. The method of claim 1, wherein, The nodes further comprise: constant type nodes, function type nodes and / or container type nodes; wherein the container type nodes encapsulate semantic graphs comprising different types of nodes and different types of edges and are called by the upper layer semantic graph for constructing a multi-level semantic graph.

5. The method of claim 1, wherein, The edges comprise: flow control relationship type edges, calculation relationship type edges, logical judgment relationship type edges and / or logical link relationship type edges.

6. The method of claim 2, wherein, The method according to the business logic relationship between the nodes in the instance graph, executable code is generated, comprising: Taking the node with an in-degree of 0 in the instance graph as a starting node, local breadth-first traversal is performed, and multiple independent and parallel executable paths are generated according to the dependency relationship between the nodes in the instance graph; During the traversal process, a sub-path matching a predefined meta-path feature is determined, and executable code is generated according to the types of the nodes in the path and the semantic meanings of the edges; If a container type node is found during the traversal process, the lower layer sub-graph logic encapsulated by the container node is opened, the sub-graph is traversed according to the same logic, the executable code generation in the sub-graph is completed, and then the subsequent operation in the upper layer instance graph is continued.

7. The method of claim 6, wherein, The method further comprises: According to the predefined meta-path feature, the path in which the node without a data instance in the instance graph is removed.

8. The method of claim 1, wherein, The method further comprises: Determining the running state and running progress of the executable code in the computing environment.

9. The method of claim 1, wherein, The method further comprises: Performing conflict detection on the semantic graph.

10. The method of claim 9, wherein, The conflict detection on the semantic graph comprises: If the starting detected node is not in the node set of the current connected graph, depth-first traversal is performed starting from the starting detected node; When each node is traversed, if the node has no access mark, the node is marked with the access mark, the node is added to the node set of the current connected graph, and the traversal continues, otherwise it is determined that a directed ring is found, and path information composed of all nodes with the access mark is output; wherein, if the out-degree of the node is greater than 1 and / or the in-degree of the node is greater than 1, the untraversed pre-branch node and / or post-branch node of the node is stored in the queue; If the out-degree of the node is 0, the access marks of all nodes in the current connected graph are cleared, and a new node is taken out from the queue of pre-branch nodes and / or post-branch nodes, and the above steps are repeated, otherwise a node is selected from all nodes in the current connected graph, and the above steps are repeated.

11. The method of claim 1, wherein, The method further comprises: Performing logical expression ambiguity detection on the semantic graph.

12. The method of claim 11, wherein, The logical expression ambiguity detection on the semantic graph comprises: In the semantic graph, when the hypothesis condition of the concept layer business logic of the if-then expression is true, if at least two processing modes appear, it is determined that the semantic graph has logical expression ambiguity.

13. The method of claim 1, wherein, The method further comprises: Performing correlation impact analysis on the dependency relationship between nodes in the instance graph and performing what-if analysis based on the adjusted data instance; wherein, the what-if analysis is used to represent the impact of the adjusted data instance on subsequent dependent nodes.

14. The method of claim 1, wherein, The method further comprises: If the data instance corresponding to the node in the instance graph does not meet the business expectation, a semantic graph corresponding to the modified concept layer business logic is regenerated according to the knowledge representation model.

15. An apparatus for knowledge representation and inference of business logic, characterized by The computer program product comprises at least one processor configured to execute instructions stored in a memory to cause the method of any one of claims 1-14 to be performed.

16. A computer program product comprising instructions, characterized in that, The computer program product, when running on a computer, causes the method of any one of claims 1-14 to be performed by the computer.

17. A computer-readable storage medium, characterized in that, The computer program is stored on the computer readable storage medium, and when executed by the processor, The method of any one of claims 1-14 is performed.

Images