A unified data model structure and a method for generating polymorphic relation graphs

Abstract

The first aspect of this invention is the disclosure of a unified data model structure. The second aspect is the disclosure of a method for generating polymorphic relationship graphs. This invention standardizes and unifies graph morphology configuration, relationship description, node information, and interactive behavior. By establishing a universal and unified data model paradigm, it achieves for the first time single-data-model-driven multimodal graph rendering. This is of great practical significance for application in the financial data field, representing relationships between various financial entities (such as equity relationships, beneficiary relationships, and corporate relationships).

Description

Technical Field

[0001] This invention relates to a unified data model structure that can be used to describe various types of relational graphs and a graph generation method based on this data model structure, belonging to the field of data visualization. Background Technology

[0002] The current state of data visualization technology includes the following:

[0003] Independent development of multiple graph types: Mainstream visualization tools in the industry (such as d3.js, ECharts) require defining independent data structures (such as tree structure JSON, force-directed graph node edge list) for each graph type (tree graph / mind map / flowchart, etc.), resulting in high repetitive development. Application limitations: Existing graph generation solutions are mostly limited to a single graph type (such as automatic generation of knowledge graphs), lacking the ability to generate general graphs across different types. At the same time, the generated graphs are mostly static and lack interactive capabilities (scaling, expanding, collapsing, etc.). Lack of ability for non-professional users to customize complex relationship graphs: Each graph requires strongly related data structure configurations, which makes it difficult for users who do not understand graph logic to customize the graphs they want.

[0004] Due to the aforementioned technological status quo, existing map generation methods suffer from the following technical challenges: 1) Redundant data structure: The data structure needs to be redefined for each new map type, and the development cost increases linearly. 2) Lack of configuration standardization: The parameters for generating the map lack a unified description standard, making it impossible to reuse the configuration across different map types. Summary of the Invention

[0005] The purpose of this invention is to express the topological relationships of different graphs through a single data model, thereby enabling a single set of data to generate multiple types of graphs, achieving standardized descriptions of various relationship types (one-to-many, many-to-one, and many-to-many), and driving the flexible presentation and interaction of four core graph forms (Tree, Brain, Dagre, and Force).

[0006] To achieve the above objectives, the first aspect of the technical solution of this invention discloses a unified data model structure, characterized in that it includes a graph morphology configuration set Config, a graph node relationship set relations, and graph node specific information nodeInfo, wherein: The graphical configuration set Config includes: The type field is used to specify the type of the target map morphology. The name field is used to represent the name of the map; The layout field: If the target graph type specified by the type field is tree, then the layout direction of the tree graph is defined by the layout field; The primaryColor field is used to represent the primary color of the graph theme. The `lineConfig` field, used to configure the line style for connections between nodes, further includes: The `type` subfield is used to indicate the line type. The `color` subfield is used to represent the default color of the lines; The showArrow subfield is used to indicate whether an arrow is displayed at the end of the connector line; The `nodeConfig` field is used to implement the node configuration array, and further includes the following subfields: The nodeTypeKey subfield is a unique identifier for the node's shape. The `type` subfield is used to represent the basic form type of a node; The `bg` subfield is used to represent the node's background color. The `color` subfield is used to represent the color of a node; The border subfield is used to indicate the color of the node border; The graph's set of node relationships includes: The fromNodeId field is related to the unique identifier of the starting node, and its value is obtained from the nodeId subfield in the list field of the graph node's specific information nodeInfo. The toNodeId field is a unique identifier for the target node, and its value is obtained from the nodeId subfield within the list field of the graph node's specific information nodeInfo. The lineText field is used to display text on the relationship lines; The color field, used to represent the line color of a specific relationship, can override the value of the color subfield within the lineConfig field of the graph's morphology configuration set Config, if the value of the color field in the graph's relationships set relations can be overridden by the value of the color subfield within the lineConfig field. The line type field is used to represent a specific relationship. The value of the type field in the relationships set of all nodes in the graphic can override the value of the type subfield in the lineConfig field of the graphic shape configuration set Config. The specific information of a graph node, nodeInfo, includes: The StartNodeId field is a unique identifier for the starting node; The EndNodeId field is a unique identifier for the final end node. If the final end node does not exist, the EndNodeId field represents the center node. The list field, used to record detailed information about all nodes, further includes the following subfields: The nodeId subfield is a unique identifier for the node; The nodeName subfield is the node name; The nodeTypeKey subfield, used to represent the current node's form, if the nodeTypeKey subfield in the nodeConfig field of the graphical node's specific information nodeInfo has a value representing the current node's basic form type, then the value of the nodeTypeKey subfield in the nodeConfig field of the graphical node's specific information nodeInfo will be applied to the nodeTypeKey subfield in the list field of the graphical node's specific information nodeInfo. The `property` subfield is an extensible, arbitrary metadata object used to store other node attributes.

[0007] The second aspect of the technical solution of this invention discloses a method for generating a polymorphic relation graph, based on the aforementioned unified data model structure, characterized by comprising the following steps: Step 1: Generate UGM data that conforms to the above unified data model structure based on user needs; Step 2: Parse the UGM data into an internal graph structure G using the parsing adapter; Step 3: The layouter calls the layout algorithm module that matches the type field in the graphical configuration set Config in the UGM data. Taking the internal graph structure G as input, it calculates the geometric coordinates of the nodes on the canvas and the connection paths of the edges to obtain layout data with coordinate and order information. Step 4: The renderer draws the graph onto the screen or canvas based on the layout data output by the layouter and the visual configuration of the graph morphology configuration set Config in the UGM data.

[0008] Preferably, in step 1, after the user inputs their requirements into the large language model using natural language, the large language model generates the UGM data based on the unified data model structure described in claim 1.

[0009] Preferably, step 2 includes the following steps: Step 201: Construct a unified relational semantic graph: Iterate through the list field in the nodeInfo section of the UGM data to generate a node index table NodeMap[nodeId]. Traverse all node relation sets in the UGM data to generate an edge list EdgeList, which fully records the semantics and attributes of each relation; The EdgeList is combined with the NodeMap[nodeId] to form a unified relational semantic graph; Step 202, Node Role Determination: Use the node corresponding to the StartNodeId field in the nodeInfo section of the graph node information, or the node with an in-degree of 0, as the starting node: Use the node corresponding to the EndNodeId field in the nodeInfo information of the graph node, or the node with an out-degree of 0, as the endpoint node; Nodes with both incoming and outgoing edges are designated as intermediate nodes; Step 203, Multi-map mapping mechanism: The internal structure required to generate the target map is generated by calling the corresponding mapping rule based on the value of the type field in the Config set of the graph morphology configuration in the UGM data.

[0010] Preferably, in step 201, the node index table NodeMap[nodeId] is represented as follows: NodeMap[nodeId] = {nodeName, nodeTypeKey, property} Among them, nodeName, nodeTypeKey, and property correspond to the nodeName, nodeTypeKey, and property subfields in the list field of the graph node's specific information nodeInfo, respectively.

[0011] Preferably, in step 201, the edge list EdgeList is represented as: EdgeList = [ { fromNodeId, toNodeId, lineText, color, type } ] Among them, fromNodeId, toNodeId, lineText, color, and type correspond to the fromNodeId, toNodeId, lineText, color, and type fields in the relation set of all nodes in the graph, respectively.

[0012] Preferably, when it is necessary to change the graph, a voice command is sent to the large language model, so that the large language model changes the graph morphology configuration set Config in the UGM data, which contains multiple configurations for graph morphology. Based on the changed UGM data, the graph is changed using steps 2 to 4.

[0013] Preferably, when a new graph needs to be switched, a voice command is sent to the large language model, causing the large language model to change the value of the type field in the graph morphology configuration set Config in the UGM data. The system automatically calls the parsing adapter corresponding to the changed type field, generates the corresponding data structure using step 2, and calls the layouter of the corresponding graph to generate node coordinates using step 3. Finally, the renderer uses step 4 in conjunction with the graph morphology configuration set Config to render the new graph.

[0014] Currently, no publicly available literature or patent descriptions can unify the representation of the four major types of relationship graphs (Tree, Brain, Dagre, and Force) under a single data structure, and seamlessly switch between them using a single field (type). While commonly used graph libraries support multiple graph layouts, they require defining a different data format for each layout. The unified format defined in this invention is not limited to any particular graph feature; it boils down to the node relationship definition of fromId and toNodeId, thus clearly representing the relationships between graph nodes.

[0015] Compared with existing technical solutions, the present invention has the following beneficial effects: (1) This invention creatively defines a single data structure capable of simultaneously describing tree, brain, dagre, and force structures, breaking through the traditional limitation that each graph type requires an independent data model. In the technical solution disclosed in this invention, config.type is used as a key switch to achieve the ability of the same relational data to drive multiple graph forms, which is revolutionary in handling multi-relationship and multi-perspective exploration.

[0016] (2) Decoupling the visual form (config, nodeConfig) from the core relation data (relations, nodeInfo) means that changing the appearance or type of the graph does not require modifying the underlying entity relation data, only the configuration part needs to be adjusted. In addition, in addition to the configuration information mentioned in config, due to the decoupling of the data structure, it is also very convenient to expand more graph configurations in the future.

[0017] (3) The nodeConfig array mechanism allows for easy definition and addition / deletion of different types of node visual styles to adapt to the diverse expression needs of financial entities (enterprises, individuals, assets, accounts, etc.).

[0018] This invention standardizes and unifies graphical configuration, relationship description, node information, and interactive behavior. By establishing a universal and unified data model paradigm, it achieves for the first time single-data-model-driven multimodal graph rendering. This is of great practical significance for application in the field of financial data to describe the relationships between various financial entities (such as equity relationships, beneficiary relationships, and corporate relationships). Attached Figure Description

[0019] Figure 1 This is a flowchart of the present invention. Detailed Implementation

[0020] The present invention will be further illustrated below with reference to specific embodiments. It should be understood that these embodiments are for illustrative purposes only and are not intended to limit the scope of the invention. Furthermore, it should be understood that after reading the teachings of this invention, those skilled in the art can make various alterations or modifications to the invention, and these equivalent forms also fall within the scope defined by the appended claims.

[0021] Graph logic primarily consists of nodes and relationships between them, while graph form mainly comprises basic form, node form, relationship form, and other forms. Specifically: basic form describes the overall display of the graph, adhering to a set of basic display rules (e.g., tree diagrams, brain diagrams, force-guided diagrams, flowcharts); node form describes the morphological characteristics of the nodes that make up the graph, including node display format (e.g., rectangle, circle, single text), node background color, node text, and border color; relationship form describes the connection form between nodes, such as the form of connecting lines (straight lines, dashed lines, broken lines) and the text on the connecting lines, and whether the connecting lines have arrows; other forms describe morphological features beyond the basic characteristics of various graphs, such as whether they are scalable, draggable, clickable, and highlightable. In the financial field, over 90% of financial relationship graphs between entities can be abstracted into the above feature set.

[0022] Based on the above analysis of the logic and form of relational graph display, the first aspect of the present invention is to abstract a set of unified data structures (Unified Graph Model, UGM) that can describe various graph relationships and forms. Based on this data, which contains all the feature sets of the graph to be drawn, various relational graphs can be generated.

[0023] In this embodiment of the invention, the UGM data is organized in JSON format (or other serialization format), mainly including the graph morphology configuration set Config, the graph's total node relationship set relations (array), and the graph node's specific information nodeInfo.

[0024] 1) Graphical Configuration Set (Config) `type`: Required, used to specify the target graph type. In this embodiment, the following are supported: 'tree' (tree diagram), 'brain' (mind map), 'dagre' (flowchart / Dagre layout, suitable for many-to-one bridging logic between nodes), and 'force' (force graph, used for displaying clustered relationships). This field is the core switch that drives different visual forms.

[0025] name: Used to indicate the name of the map.

[0026] `layout`: Applicable to tree-type target graph shapes, used to define the layout direction of the tree diagram. In this embodiment of the invention, the following are supported: 'TB' (Top to Bottom), 'LR' (Left to Right), 'Indent' (Indented, such as an organizational chart), and 'Compact' (Compact Tree).

[0027] primaryColor: Used to represent the theme color of the graph, used to unify the color tone.

[0028] lineConfig: Configures the style of the connecting lines between relational nodes, and further includes the following subfields: 1) type: Used to indicate the line type. In this embodiment of the invention, the following are supported: 'solid' (solid line), 'dotted' (dashed line), and 'polyline' (polyline). 2) color: Used to represent the default line color, which can be overridden by relation-level configuration; 3) showArrow: Used to indicate whether an arrow is displayed at the end of the connecting line.

[0029] `nodeConfig`: An array of node form configurations (highly expandable) used to define the form configurations of common nodes, further including the following subfields: 1) nodeTypeKey: A unique identifier for the node's form; 2) type: Used to represent the basic shape type of the node. In this embodiment of the invention, the following are supported: 'rect' (rectangle), 'circle' (circle), and 'text' (text). 3) bg: Used to represent the background color of a node; 4) color: Used to represent the node color; 5) border: Used to indicate the color of the node border.

[0030] (ii) The set of relationships (array) of all nodes in the graph fromNodeId: Required, related to the unique identifier of the starting node, corresponding to nodeInfo.list.nodeId.

[0031] toNodeId: Required, related to the unique identifier of the target node, corresponding to nodeInfo.list.nodeId.

[0032] lineText: Optional, used to display text (such as equity percentage, amount, relationship description) on the relationship line.

[0033] color: Optional, used to represent the line color for a specific relationship, overriding lineConfig.color; type: Optional, used to represent the line type for a specific relationship, overriding lineConfig.type.

[0034] (iii) Detailed information about the graphical node: nodeInfo StartNodeId: A unique identifier for the starting node.

[0035] EndNodeId: A unique identifier for the final end node. If it does not exist, StartNodeId represents the center node.

[0036] list (array): contains detailed information for all nodes, further including the following subfields: 1) nodeId: A unique identifier for the node; 2) nodeName: The name of the node. 3) nodeTypeKey: Used to represent the current node type (corresponding to nodeConfig.nodeTypeKey). When it exists, the node type characteristic of this type is applied. 4) property: An extensible, arbitrary metadata object used to store other node attributes (such as entity type [company / individual], registered capital, location, risk level, etc.). This data can be used for interactive tooltips, filtering, coloring, or AI processing.

[0037] The unified data model structure provided by this invention is very suitable for expressing polymorphic graphical relationships and describing the relationships between various financial entities in the field of financial data. For example, corporate equity relationships and investment relationships can be displayed using tree diagrams in the model, while deep-level link relationships such as beneficiary and corporate many-to-one contact can be expressed using Dagre flowcharts. Graphical representations of suspected relationships between enterprises can also be well expressed using Force graphs. This allows for the use of a single data structure to express the relationships between various financial entities.

[0038] Furthermore, the data structure provided by this invention is highly structured and semantically clear, offering standardized input / output interfaces for Large Language Models (LLMs) to understand and generate various financial relationship graphs. Because the data structure for various graphs is unified, it naturally possesses the capability for rapid AI integration, enabling rapid conversion from LLM natural language to graphs: users describe their needs in natural language, LLM understands and generates data conforming to this unified data structure, driving the system to render the corresponding graph (such as a Tree graph). In addition, the Graph Format Configuration Set (Config) in the UGM data contains various configurations for graph formats, which greatly facilitates sending graph modification commands to AI, such as changing the theme color or orientation of the displayed graph. AI only needs to modify the `primaryColor` or `layout` field of the Graph Format Configuration Set (Config) in the UGM data.

[0039] Finally, the UGM data provided by this invention only contains config + relations + nodeInfo related fields. Users can draw polymorphic graphs without needing to analyze the characteristics of each graph in detail. Instead, they can fill in a template that meets the data format requirements of the UGM paradigm, supplement the data content they want to display, and quickly build and generate graphs with personal data and personalized style by selecting the graph type and the basic style they want to display in the graph morphology configuration set Config (or leave it blank to use the default style).

[0040] like Figure 1 As shown, the second aspect of this invention is based on the aforementioned unified data structure (i.e., UGM data structure), which implements a relation-driven automatic multi-graph generation mechanism. In this invention, the graph serves only as a visual representation of the relational data; the relational data itself is the core driving force. The entire generation process is implemented through a parsing adapter, a layouter, and a renderer, specifically including the following steps: The first step is to parse the UGM data into an internal graph structure using a parsing adapter, which can then be used for various graph layouts. The main logic is as follows: 1. Construct the Relation-Driven Graph G. Iterate through nodeInfo.list in the UGM data and generate a node index table NodeMap[nodeId]: NodeMap[nodeId] = { nodeName, nodeTypeKey, property} Iterate through the relationships in the UGM data to generate an edge list (EdgeList), which fully records the semantics and attributes of each relationship: EdgeList = [ { fromNodeId, toNodeId, lineText, color, type } ] The edge list EdgeList is combined with the node index table NodeMap[nodeId] to form a unified relational semantic graph G. This unified relational semantic graph G retains all node attributes and relation attributes and is used to drive the generation of different graphs.

[0041] 2. Node Role Determination Start node: Use nodeInfo.StartNodeId or a node with an in-degree of 0; End node: Use nodeInfo.EndNodeId or a node with an out-degree of 0; Intermediate node: has both incoming and outgoing edges; This judgment rule is applicable to all graph types, ensuring that the relational data itself does not depend on the graph structure.

[0042] 3. Multi-graph mapping mechanism (universal generation logic) Based on the config.type in the UGM data, the corresponding mapping rule is invoked to generate the internal structure required for the target map.

[0043] Example (general logic applicable to all graph types): 1) Traverse the EdgeList and construct parent-child or directed relationship chains based on fromNodeId to toNodeId; 2) Line attributes (lineText, color, type) are mapped to the corresponding edges along the relationships; 3) Node attributes (nodeTypeKey, property) are mapped to node styles and interaction information; 4) The positional relationship between the starting point, the ending point, and intermediate nodes serves as a layout constraint.

[0044] This mechanism ensures that the same relational data is used regardless of whether a Tree, Brain, Dagre, or Force graph is generated. The graph topology and layout are automatically derived by the parsing adapter, eliminating the need to reorganize the data.

[0045] The second step involves the layout algorithm module matching the `config.type` value in the UGM data to calculate the geometric coordinates of the nodes on the canvas and the connection paths of the edges. The layout algorithm takes as input the unified relational semantic graph G generated by the parsing adapter and outputs layout data with coordinate and order information.

[0046] In this invention, all layout constraints are derived from relational data, do not rely on manual settings, and are applicable to various graph types, ensuring the principle of relational priority. At the same time, the layout algorithm itself can use existing algorithms without modification.

[0047] The third step involves the renderer drawing the atlas onto the screen or canvas based on the layouter output and the visual configuration in the UGM data, including: 1. Draw edges / relationship lines: 1) Traverse EdgeList; 2) Use lineConfig.type to determine the default line type; 3) Use lineConfig.color as the default line color; 4) If `relations` covers `color` or `type`, then `color` or `type` takes precedence. 5) Draw lineText to display relationship information; 6) The arrow display is determined by config.showArrow.

[0048] 2. Draw nodes: 1) Traverse the NodeMap[nodeId] nodes; 2) Match the config.nodeConfig style based on nodeTypeKey; 3) Type support: 'circle': Draws a circle with a radius based on nodeConfig.size or an estimated value, a fill based on bg, and a stroke based on border; 'rect': Draws a rectangle, with size estimated based on nodeConfig.size or text width, fill based on bg, and stroke based on border; 'text': Directly draw the nodeName text, using color. 'image': Draws the specified imageUrl and scales it to the configured size; 4) Render nodeName or other attribute information on the node; 5) Use primaryColor as the theme color to unify the interface style.

[0049] Compared with existing technical solutions, the advantages of the above-mentioned map generation method are: Relationship-first: The generation of the graph is entirely driven by relational data, and the graphics are only for visualization purposes; Multi-plot compatibility: The same dataset can generate Tree, Brain, Dagre, and Force plots without requiring data modification; Decoupling data and style: Modifying visual effects does not affect relational logic; Supports attribute mapping: Node attributes and relationship attributes can be used for interactive hints, filtering, and dynamic coloring.

[0050] If a person skilled in the art needs to switch from the current graph to a new graph, they only need to change the type field in the graph morphology configuration set Config of the UGM data. The system will then automatically call the parsing adapter corresponding to the new graph type to generate the corresponding data structure. At the same time, it will call the layouter of the corresponding graph to generate node coordinates. Finally, the renderer will combine the style config to render the new graph.

[0051] If those skilled in the art need to change the current drawing style, they only need to change the drawing style configuration set Config in the UGM data, and the renderer will apply the new style during the rendering process.

[0052] It should be noted that this invention does not involve improvements to existing layout algorithms (such as force-directed layout, tree layout) or drawing interfaces (SVG / Canvas), but rather achieves the ability to drive multiple graph forms with the same data through a unified data structure and dynamic mapping mechanism.

Claims

1. A unified data model structure, characterized by, This includes the graph configuration set Config, the graph's relationships set of all nodes, and the graph node information nodeInfo, among which: The graphical configuration set Config includes: The type field is used to specify the type of the target map morphology. The name field is used to represent the name of the map; The layout field: If the target graph type specified by the type field is tree, then the layout direction of the tree graph is defined by the layout field; The primaryColor field is used to represent the primary color of the graph theme. The `lineConfig` field, used to configure the line style for connections between nodes, further includes: The `type` subfield is used to indicate the line type. The `color` subfield is used to represent the default color of the lines; The showArrow subfield is used to indicate whether an arrow is displayed at the end of the connector line; The `nodeConfig` field is used to implement the node configuration array, and further includes the following subfields: The nodeTypeKey subfield is a unique identifier for the node's shape; The `type` subfield is used to represent the basic form type of a node; The `bg` subfield is used to represent the node's background color. The `color` subfield is used to represent the color of a node; The border subfield is used to indicate the color of the node border; The graph's set of node relationships includes: The fromNodeId field is related to the unique identifier of the starting node, and its value is obtained from the nodeId subfield in the list field of the graph node's specific information nodeInfo. The toNodeId field is a unique identifier for the target node, and its value is obtained from the nodeId subfield within the list field of the graph node's specific information nodeInfo. The lineText field is used to display text on the relationship lines; The color field, used to represent the line color of a specific relationship, can override the value of the color subfield within the lineConfig field of the graph's morphology configuration set Config, if the value of the color field in the graph's relationships set relations can be overridden by the value of the color subfield within the lineConfig field. The line type field is used to represent a specific relationship. The value of the type field in the relationships set of all nodes in the graphic can override the value of the type subfield in the lineConfig field of the graphic shape configuration set Config. The specific information of a graph node, nodeInfo, includes: The StartNodeId field is a unique identifier for the starting node; The EndNodeId field is a unique identifier for the final end node. If the final end node does not exist, the EndNodeId field represents the center node. The list field, used to record detailed information about all nodes, further includes the following subfields: The nodeId subfield is a unique identifier for the node; The nodeName subfield is the node name; The nodeTypeKey subfield, used to represent the current node's form, if the nodeTypeKey subfield in the nodeConfig field of the graphical node's specific information nodeInfo has a value representing the current node's basic form type, then the value of the nodeTypeKey subfield in the nodeConfig field of the graphical node's specific information nodeInfo will be applied to the nodeTypeKey subfield in the list field of the graphical node's specific information nodeInfo. The `property` subfield is an extensible, arbitrary metadata object used to store other node attributes.

2. A method for generating a polymorphic relationship map based on the unified data model structure of claim 1, characterized in that, Includes the following steps: Step 1: Generate UGM data that conforms to the unified data model structure described in claim 1 based on user requirements; Step 2: Parse the UGM data into an internal graph structure G using the parsing adapter; Step 3: The layouter calls the layout algorithm module that matches the type field in the graphical configuration set Config in the UGM data. Taking the internal graph structure G as input, it calculates the geometric coordinates of the nodes on the canvas and the connection paths of the edges to obtain layout data with coordinate and order information. Step 4: The renderer draws the graph onto the screen or canvas based on the layout data output by the layouter and the visual configuration of the graph morphology configuration set Config in the UGM data.

3. The method for generating a polymorphic relation graph as described in claim 2, characterized in that, In step 1, after the user inputs their requirements into the large language model using natural language, the large language model generates the UGM data based on the unified data model structure described in claim 1.

4. The method for generating a polymorphic relation graph as described in claim 2, characterized in that, Step 2 includes the following steps: Step 201: Construct a unified relational semantic graph: Iterate through the list field in the nodeInfo section of the UGM data to generate a node index table NodeMap[nodeId]. Traverse all node relation sets in the UGM data to generate an edge list EdgeList, which fully records the semantics and attributes of each relation; The EdgeList is combined with the NodeMap[nodeId] to form a unified relational semantic graph; Step 202, Node Role Determination: Use the node corresponding to the StartNodeId field in the nodeInfo section of the graph node information, or the node with an in-degree of 0, as the starting node: Use the node corresponding to the EndNodeId field in the nodeInfo information of the graph node, or the node with an out-degree of 0, as the endpoint node; Nodes with both incoming and outgoing edges are designated as intermediate nodes; Step 203, Multi-map mapping mechanism: The internal structure required to generate the target map is generated by calling the corresponding mapping rule based on the value of the type field in the Config set of the graph morphology configuration in the UGM data.

5. The method for generating a polymorphic relation graph as described in claim 4, characterized in that, In step 201, the node index table NodeMap[nodeId] is represented as follows: NodeMap[nodeId] = {nodeName, nodeTypeKey, property} Among them, nodeName, nodeTypeKey, and property correspond to the nodeName, nodeTypeKey, and property subfields in the list field of the graph node's specific information nodeInfo, respectively.

6. The method for generating a polymorphic relation graph as described in claim 4, characterized in that, In step 201, the edge list EdgeList is represented as follows: EdgeList = [ { fromNodeId, toNodeId, lineText, color, type } ] Among them, fromNodeId, toNodeId, lineText, color, and type correspond to the fromNodeId, toNodeId, lineText, color, and type fields in the relation set of all nodes in the graph, respectively.

7. The method for generating a polymorphic relation graph as described in claim 3, characterized in that, When the graph needs to be changed, a voice command is sent to the large language model, causing the large language model to change the graph morphology configuration set Config in the UGM data, which contains various configurations for graph morphology. Based on the changed UGM data, the graph is changed using steps 2 to 4.

8. The method for generating a polymorphic relation graph as described in claim 7, characterized in that, When a new graph needs to be switched, a voice command is sent to the large language model, causing the large language model to change the value of the type field in the graph morphology configuration set Config in the UGM data. The system automatically calls the parsing adapter corresponding to the changed type field, generates the corresponding data structure using step 2, and calls the layouter of the corresponding graph to generate node coordinates using step 3. Finally, the renderer uses step 4 in conjunction with the graph morphology configuration set Config to render the new graph.

Images