Data processing method and related device
By using a common API in the graph database and adopting a combined storage pattern of basic nodes and attribute nodes, the problem of complex data model updates in existing technologies is solved, enabling flexible and rapid data storage and updates, and improving the business efficiency of industrial software applications.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HUAWEI CLOUD COMPUTING TECHNOLOGIES CO LTD
- Filing Date
- 2024-04-30
- Publication Date
- 2026-05-19
AI Technical Summary
In existing cloud-based industrial software applications, updating and changing data models is complex and time-consuming, especially when integrating multiple applications and customers. It is difficult to flexibly and quickly adjust data storage modes, which affects business efficiency.
It adopts a flexible data storage model, uses a graph database and introduces a general application programming interface (API) to support any type of data model. Through the combination of basic nodes and attribute nodes, it realizes the storage and updating of data objects, avoiding frequent changes to the data storage model.
It reduced the time required for data model changes, improved business efficiency, simplified the complexity of software code for developers, reduced the workload of code migration, and enabled flexible and rapid data model changes.
Smart Images

Figure CN122070533A_ABST
Abstract
Description
[0001] Cross-references to related applications
[0002] This application claims priority to International Application No. PCT / RU2023 / 000328, filed on October 26, 2023. The disclosure of the aforementioned patent application is incorporated herein by reference in its entirety. Technical Field
[0003] This disclosure relates to the field of database technology, and in particular to data processing methods and related apparatus. Background Technology
[0004] Many leading industries, including automotive, aerospace and defense (A&D), electronic and semiconductor (E&S), and energy and utilities (E&U), use specialized industrial software applications to automate internal business processes and improve product development efficiency and quality. A common trend in industrial software automation is the migration to the cloud and the use of cloud-based solutions and platforms.
[0005] The purpose of providing this background information is to illustrate information that the applicant believes may be relevant to this disclosure. It is neither necessary to acknowledge nor should it be interpreted that any of the foregoing information constitutes prior art relative to this disclosure. Summary of the Invention
[0006] In a first aspect, embodiments of this disclosure provide a data processing method, wherein the method includes:
[0007] Retrieve the object information of the data object, where the object information includes the basic attributes of the data object;
[0008] Object information is stored in a data structure, wherein the data structure includes a first node, the basic attributes of the data object are stored in the first node, the first node can be connected to at least one second node, and each of the at least one second node is used to store additional attributes of the data object.
[0009] The aforementioned data structure, as an implementation of a data storage model, can support any type of source system data model. It acts as a universal container, capable of storing and updating any data model. Data objects can have their own basic attributes (e.g., name), which can be stored in their corresponding first nodes. They can have different numbers of additional attributes, which can be stored in different numbers of second nodes. They can also have different relationships describing the relationship between the second nodes and the first nodes. However, for all these data objects, the data storage model is the same: regardless of what data objects are added to the data model, they can be stored in the data structure. This data structure includes first nodes for storing general attributes (the basic attributes of the data objects) and one or more second nodes for storing other attributes (if any), thereby improving the storage efficiency of data objects. Compared to existing solutions, for example, when adding a new data object with a new class, the proposed solution does not require changing the data storage model. The new class will be treated as one or more new attributes of the data object, and only one or more new second nodes need to be created. In this way, the time required to implement data model changes can be reduced, and business efficiency can be improved due to the ability to implement flexible and rapid data model changes.
[0010] In one possible implementation of the first aspect, the object information also includes at least one additional attribute of the data object;
[0011] The data structure also includes at least one second node, which is connected to the first node through at least one correspondence, and each of the at least one additional attributes is stored in the at least one second node.
[0012] Therefore, adding attributes will be achieved by adding a second node, eliminating the need to update attributes listed in the data storage schema. This reduces the time required to change the data model and improves business efficiency due to the flexible and rapid implementation of data model changes. Furthermore, the data structure implementing the data storage schema is flexible; the data storage schema uses only two types of nodes (first node and second node) to support the storage of data objects from any data model. The data structure, as the implementation method of the data storage schema, can be updated without changing the database's data storage schema. Updating the data structure excludes the database from the update chain, and the data storage schema is created only once when the data structure is created and will not change again. This further reduces the time required to change the data model and improves business efficiency due to the flexible and rapid implementation of data model changes. The data storage schema can support any type of data model.
[0013] In one possible implementation of the first aspect, for each of the at least one attribute, the additional attribute includes a name of the additional attribute and a value of the additional attribute, and for a second node storing the additional attribute, the second node is associated with a node identifier for identifying the second node, an attribute name for indicating the name of the additional attribute stored in the second node, and an attribute value for indicating the value of the additional attribute.
[0014] Since each additional attribute has its own second node, operations such as creating, updating, deleting, and editing attributes can be efficiently performed by manipulating the second node corresponding to the additional attribute.
[0015] In one possible implementation of the first aspect, for each of at least one second node, the second node is also associated with at least one of the following:
[0016] The creator of the second node, the creation date of the second node, the modification date indicating the time when the information associated with the second node was last modified, or the modifier identifier indicating the modifier who last modified the information associated with the second node.
[0017] Based on the above, users can quickly and comprehensively understand information related to the second node based on the data structure.
[0018] In one possible implementation of the first aspect, for each of at least one second node, the relationship between the second node and the first node is characterized by a relationship identifier for identifying the relationship, an identifier for indicating the starting node of the relationship, an identifier for indicating the target node of the relationship, and a relationship type for identifying the type of the relationship.
[0019] Based on the above information related to relationships, users can quickly and comprehensively understand the nodes related to those relationships.
[0020] In one possible implementation of the first aspect, the relation is further characterized by at least one of the following:
[0021] The creator of the relationship, the creation date of the relationship, the modification date indicating when the relationship was last modified, or the modifier identifier indicating the modifier who modified the relationship.
[0022] Based on the above relationship-related identifiers, users can quickly and comprehensively learn about relationship-related information.
[0023] In one possible implementation of the first aspect, storing object information based on a data structure includes:
[0024] Call the general application programming interface (API) to:
[0025] Create the first node to store the basic properties of the data object;
[0026] Create at least one second node to store at least one additional attribute;
[0027] For each of at least one second node, create a relationship between the first node and the second node.
[0028] The general API supports the above data storage modes and is introduced only once. It does not need to be updated when any data model changes, thus simplifying the way databases are handled, reducing the complexity of software code for developers, reducing "template code", and eliminating the need to create CRUD + compare for each data model object. Due to the limited number of methods used, code simplification and reduced code migration workload are achieved.
[0029] In one possible implementation of the first aspect, the method further includes:
[0030] In response to a second node deletion request, invoke the general API to delete at least one target second node that has the node identifier indicated in the second node deletion request.
[0031] In one possible implementation of the first aspect, the method further includes:
[0032] In response to a first relationship deletion request, the general API is invoked to delete the relationship between the first node indicated in the first relationship deletion request and the target second node in at least one second node, as well as the target second node.
[0033] In one possible implementation of the first aspect, the method further includes:
[0034] In response to a second relationship deletion request, invoke the general API to delete the relationship between the first node indicated in the second relationship deletion request and another first node.
[0035] In one possible implementation of the first aspect, the method further includes:
[0036] In response to a relationship edit request, invoke the general API to update the relationship indicated in the relationship edit request.
[0037] The creation, deletion, and editing of the aforementioned relationships can all be implemented through a general API. The general API only needs to be imported once and does not need to be updated when the data model changes, thereby reducing the time required to implement data model changes and improving business efficiency due to the ability to make flexible and rapid data model changes.
[0038] In one possible implementation of the first aspect, the method further includes:
[0039] In response to a second node search request, a general API is invoked to return all second nodes in at least one second node that are connected to the first node, wherein the second node search request indicates the node identifier of the first node.
[0040] In one possible implementation of the first aspect, the method further includes:
[0041] In response to the first relation search request, the general API is invoked to return information about the target second node in at least one second node that is connected to the first node by the relation indicated in the first relation search request.
[0042] In one possible implementation of the first aspect, the method further includes:
[0043] In response to the second relation search request, the general API is invoked to return information about another first node that is connected to the first node through the relation indicated in the second relation search request.
[0044] In one possible implementation of the first aspect, the method further includes:
[0045] In response to an attribute search request, the general API is invoked to return information about the nodes storing the attribute indicated in the attribute search request in the first node and at least one second node.
[0046] In one possible implementation of the first aspect, the method further includes:
[0047] In response to a node search request, the general API is invoked to return information about the first node and at least one second node identified by the node identifier indicated in the node search request.
[0048] All of the above operations can be implemented through a general API. The general API only needs to be imported once and does not need to be updated when the data model changes, thereby reducing the time required to implement data model changes and improving business efficiency due to the ability to make flexible and rapid data model changes.
[0049] In one possible implementation of the first aspect, the type of the first node is indicated by object information and stored in a node type indicator associated with the first node.
[0050] In one possible implementation of the first aspect, the first node is associated with a node identifier used to identify the first node.
[0051] In one possible implementation of the first aspect, the basic attribute is the name of the data object, and the first node is also associated with a node name, which is used to indicate the name of the first node corresponding to the name of the data object.
[0052] In one possible implementation of the first aspect, the first node is also associated with at least one of the following:
[0053] The creator of the first node, the creation date of the first node, the update status of the first node, the source address of the object information, the modification date indicating the time when the information associated with the first node was last modified, or the modifier identifier indicating the modifier who last modified the information associated with the first node.
[0054] Based on the above, object information of data objects can be stored in data structures, and object information can be checked quickly.
[0055] In one possible implementation of the first aspect, the method further includes:
[0056] In response to a type add request, the general API is invoked to add the type to be added as indicated in the type add request as an available type for the data structure.
[0057] The above method eliminates the need to create new node types in the data storage model, thereby reducing the time required to change the data model and improving business efficiency by enabling flexible and rapid data model changes.
[0058] In one possible implementation of the first aspect, the method further includes:
[0059] In response to an additional attribute add request, the general API is invoked to create another second node to store the additional attributes indicated in the additional attribute add request.
[0060] In one possible implementation of the first aspect, the method further includes:
[0061] In response to a first node deletion request, the general API is invoked to delete the first node, where the first node deletion request indicates the node identifier of the first node.
[0062] In one possible implementation of the first aspect, the method further includes:
[0063] In response to a node edit request, invoke the general API to update the node indicated by the node identifier in the node edit request with the attribute values indicated in the node edit request.
[0064] The creation, deletion, and editing operations of the first node mentioned above can all be implemented through the general API. The general API only needs to be imported once and does not need to be updated when the data model changes, thereby reducing the time required to implement data model changes and improving business efficiency due to the flexible and rapid implementation of data model changes.
[0065] In a second aspect, embodiments of this disclosure provide a data processing apparatus, wherein the apparatus includes:
[0066] The acquisition module is used to acquire object information of data objects, including the basic attributes of the data objects.
[0067] A storage module is used to store object information in a data structure, wherein the data structure includes a first node, the basic attributes of the data object are stored in the first node, the first node can be connected to at least one second node, and each of the at least one second node is used to store additional attributes of the data object.
[0068] In one possible implementation of the second aspect, the object information also includes at least one additional attribute of the data object;
[0069] The data structure also includes at least one second node, which is connected to the first node through at least one correspondence, and each of the at least one additional attributes is stored in the at least one second node.
[0070] In one possible implementation of the second aspect, for each of the at least one attribute, the additional attribute includes a name of the additional attribute and a value of the additional attribute, and for a second node storing the additional attribute, the second node is associated with a node identifier for identifying the second node, an attribute name for indicating the name of the additional attribute stored in the second node, and an attribute value for indicating the value of the additional attribute.
[0071] In one possible implementation of the second aspect, for each of at least one second node, the second node is also associated with at least one of the following:
[0072] The creator of the second node, the creation date of the second node, the modification date indicating the time when the information associated with the second node was last modified, or the modifier identifier indicating the modifier who last modified the information associated with the second node.
[0073] In one possible implementation of the second aspect, for each of the at least one second node, the relationship between the second node and the first node is characterized by a relationship identifier for identifying the relationship, an identifier for indicating the starting node of the relationship, an identifier for indicating the target node of the relationship, and a relationship type for identifying the type of the relationship.
[0074] In one possible implementation of the second aspect, the relation is further characterized by at least one of the following:
[0075] The creator of the relationship, the creation date of the relationship, the modification date indicating when the relationship was last modified, or the modifier identifier indicating the modifier who modified the relationship.
[0076] In one possible implementation of the second aspect, the device further includes:
[0077] The calling module is used to invoke the common application programming interface (API) to:
[0078] Create the first node to store the basic properties of the data object;
[0079] Create at least one second node to store at least one attribute;
[0080] For each of at least one second node, create a relationship between the first node and the second node.
[0081] In one possible implementation of the second aspect, the device further includes a calling module for:
[0082] In response to a second node deletion request, invoke the general API to delete at least one target second node that has the node identifier indicated in the second node deletion request.
[0083] In one possible implementation of the second aspect, the device further includes a calling module for:
[0084] In response to a first relationship deletion request, the general API is invoked to delete the relationship between the first node indicated in the first relationship deletion request and the target second node in at least one second node, as well as the target second node.
[0085] In one possible implementation of the second aspect, the device further includes a calling module for:
[0086] In response to a second relationship deletion request, invoke the general API to delete the relationship between the first node indicated in the second relationship deletion request and another first node.
[0087] In one possible implementation of the second aspect, the device further includes a calling module for:
[0088] In response to a relationship edit request, invoke the general API to update the relationship indicated in the relationship edit request.
[0089] In one possible implementation of the second aspect, the device further includes a calling module for:
[0090] In response to a second node search request, a general API is invoked to return all second nodes in at least one second node that are connected to the first node, wherein the second node search request indicates the node identifier of the first node.
[0091] In one possible implementation of the second aspect, the device further includes a calling module for:
[0092] In response to the first relation search request, the general API is invoked to return information about the target second node in at least one second node that is connected to the first node by the relation indicated in the first relation search request.
[0093] In one possible implementation of the second aspect, the device further includes a calling module for:
[0094] In response to the second relation search request, the general API is invoked to return information about another first node that is connected to the first node through the relation indicated in the second relation search request.
[0095] In one possible implementation of the second aspect, the device further includes a calling module for:
[0096] In response to an attribute search request, the general API is invoked to return information about the nodes storing the attribute indicated in the attribute search request in the first node and at least one second node.
[0097] In one possible implementation of the second aspect, the device further includes a calling module for:
[0098] In response to a node search request, the general API is invoked to return information about the first node and at least one second node identified by the node identifier indicated in the node search request.
[0099] In one possible implementation of the second aspect, the type of the first node is indicated by object information and stored in a node type indicator associated with the first node.
[0100] In one possible implementation of the second aspect, the first node is associated with a node identifier used to identify the first node.
[0101] In one possible implementation of the second aspect, the basic attribute is the name of the data object, and the first node is also associated with a node name, which is used to indicate the name of the first node corresponding to the name of the data object.
[0102] In one possible implementation of the second aspect, the first node is also associated with at least one of the following:
[0103] The creator of the first node, the creation date of the first node, the update status of the first node, the source address of the object information, the modification date indicating the time when the information associated with the first node was last modified, or the modifier identifier indicating the modifier who last modified the information associated with the first node.
[0104] In one possible implementation of the second aspect, the device further includes a calling module for:
[0105] In response to a type add request, the general API is invoked to add the type to be added as indicated in the type add request as an available type for the data structure.
[0106] In one possible implementation of the second aspect, the device further includes a calling module for:
[0107] In response to an additional attribute add request, the general API is invoked to create another second node to store the additional attributes indicated in the additional attribute add request.
[0108] In one possible implementation of the second aspect, the device further includes a calling module for:
[0109] In response to a first node deletion request, the general API is invoked to delete the first node, where the first node deletion request indicates the node identifier of the first node.
[0110] In one possible implementation of the second aspect, the device further includes a calling module for:
[0111] In response to a node edit request, invoke the general API to update the node indicated by the node identifier in the node edit request with the attribute values indicated in the node edit request.
[0112] In a third aspect, embodiments of this disclosure provide a computing device cluster including processing circuitry for performing a data processing method according to the first aspect or any possible implementation thereof.
[0113] In a fourth aspect, embodiments of this disclosure provide a computer program product including program code for performing a data processing method according to the first aspect or any possible implementation thereof.
[0114] In a fifth aspect, embodiments of this disclosure provide an electronic device including processing circuitry for performing a data processing method according to the first aspect or any possible implementation thereof.
[0115] In a sixth aspect, embodiments of this disclosure provide a chip including an input / output (I / O) interface and a processor for calling and running a computer program stored in a memory, enabling a device equipped with the chip to perform a method according to the first aspect or any possible implementation thereof.
[0116] In a seventh aspect, embodiments of this disclosure provide a computer-readable medium storing computer-executable instructions that, when executed by a processor, cause the processor to perform a data processing method according to the first aspect or any possible implementation thereof.
[0117] In an eighth aspect, embodiments of this disclosure provide a computer program including computer execution instructions that, when executed by a processor, cause the processor to perform a data processing method according to the first aspect or any possible implementation thereof. Attached Figure Description
[0118] Figure 1 This is a typical diagram of the product lifecycle automation process.
[0119] Figure 2A and Figure 2B This is a diagram illustrating examples of different data model definitions.
[0120] Figure 3 This is a schematic diagram of the data model content.
[0121] Figure 4 This is a schematic diagram of an exemplary architecture for standalone industrial software applications.
[0122] Figure 5 This is a schematic diagram of an exemplary architecture for developing industrial software applications based on a cloud platform.
[0123] Figure 6 This is a schematic diagram of an exemplary architecture for developing industrial software applications based on a cloud platform.
[0124] Figure 7 This is a schematic flowchart illustrating the change chain of a data model for an independent application according to one or more embodiments of this disclosure.
[0125] Figure 8 This is a schematic flowchart illustrating the change chain of a data model for a cloud-based application according to one or more embodiments of this disclosure.
[0126] Figure 9 This is a schematic diagram of an exemplary data storage pattern according to one or more embodiments of the present disclosure.
[0127] Figure 10 This is a schematic diagram of an exemplary data model according to one or more embodiments of this disclosure.
[0128] Figure 11 The attributes of basic nodes and attribute nodes according to one or more embodiments of this disclosure are illustrated by way of example.
[0129] Figure 12A and Figure 12B Examples of basic node instances and attribute node instances in a database according to one or more embodiments of this disclosure are shown respectively.
[0130] Figures 13A to 13D Different services of the data model according to one or more embodiments of this disclosure are shown respectively.
[0131] Figure 14 This is a schematic flowchart of a data processing method according to one or more embodiments of the present disclosure.
[0132] Figure 15 A schematic structural diagram of a data processing apparatus according to one or more embodiments of the present disclosure is shown. Detailed Implementation
[0133] To more clearly describe the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings required in the description of the embodiments or the prior art will be briefly introduced below.
[0134] In the following description, reference is made to the accompanying drawings, which form part of this disclosure, which illustrate by way of description specific aspects of embodiments of this disclosure or aspects that may be used with embodiments of this disclosure. It will be understood that embodiments of this disclosure may be used in other aspects and include structural or logical variations not shown in the drawings. Therefore, the following detailed description is not intended to be limiting, and the scope of this disclosure is defined by the appended claims.
[0135] Before describing the details of this disclosure, the following terms will be explained.
[0136] An API – Application Programming Interface – is a collection of predefined functionalities for a software application. Software systems encapsulate their own service capabilities into APIs and provide them to applications for invocation. Developers can directly call APIs without needing to consider the underlying source code or understand its internal workings.
[0137] Template code – sections of code that are repeated in multiple places with little or no variation.
[0138] Cloud providers – Companies or organizations that provide different types of services to customers and / or third-party application developers.
[0139] Cloud core applications – one or more software applications provided by a cloud provider to third-party application developers as the basis for their development activities.
[0140] CRUD – CRUD is an acronym for CREATE, READ, UPDATE, and DELETE. They are commonly used for database operations, namely adding, deleting, modifying, and querying data.
[0141] Customers – Companies or organizations that use software applications to automate their own business tasks.
[0142] A data model is a set of data objects, attributes, and relationships used to describe information business objects (such as documents, drawings, and models) used by customers in their daily business operations within an IT system. A data model is a graphical modeling of application execution by software designers, including data entities, relational entities, and interface models.
[0143] Data modelers are specialized software tools used to describe data models. They can be described using text, visuals, or specific formats.
[0144] Data storage scheme / schema – A set of predefined tables with columns and rows in a relational database (RDB). A set of predefined node and edge types with attributes in a graph database.
[0145] Edges are the basic unit of graph databases, used to store relationships between data entities.
[0146] A node is the basic unit of a graph database, used to store information about data entities.
[0147] The Industrial Digital Model Engine (IDME) is an exemplary industrial software development and operation platform developed based on digital transformation and data management practices. It establishes a common foundation based on "model + data-driven" principles. It provides fundamental technical services for collaboratively building a new generation of fully-stack, independently controllable industrial software systems, helping to quickly build and operate cloud-based SaaS chemical industry software, aggregating enterprise-level full-scenario data, constructing enterprise-level data graphs, and providing tens of thousands of interconnected data indexes, traceability, and interactive services.
[0148] Industrial software – a set of software tools that automate different business tasks throughout the product lifecycle of an engineering product.
[0149] Product Lifecycle Management (PLM) refers to the entire lifecycle of a product, from the initial demand to its eventual termination. PLM is an advanced concept in enterprise information management, aiming to increase revenue and reduce costs through the most effective means.
[0150] There are some necessary steps in automating the industrial product lifecycle using industrial software. Figure 1 This is a typical diagram illustrating the automated process of the product lifecycle. For example... Figure 1 As shown, the steps include: investigating customer business processes; defining a set of automated software; defining a data model; performing user training and adoption; configuring and customizing the software. This disclosure focuses primarily on the data model definition phase.
[0151] As mentioned above, a data model is a set of data objects, attributes, and relationships used to describe information business objects (such as documents, drawings, and models) used by customers in their daily business operations. Depending on the complexity of the business, the number of data model entities (or data model instances, which are representations of data objects in the data model) varies greatly, but typically includes hundreds of data entities, relation entities, and attribute entities, which represent the data objects, attributes, and relationships in the data model, respectively. Figure 2A and Figure 2B Two different data model definition examples are shown.
[0152] Data models for individual customers and businesses may differ. For example... Figure 3 As shown, an example of the data model content is presented, which consists of three main parts:
[0153] Basic data blocks, applicable to all customers (approximately 60% of data objects).
[0154] Industry-specific data blocks (approximately 20%).
[0155] Customer-specific data blocks (approximately 20%).
[0156] Different clients (such as companies) use different data models. While the basic data blocks within these models are the same, the industry-specific data blocks are also identical when clients belong to the same industry. However, the client-specific data blocks within each client's data model are different. For example, two companies in the automotive industry might have approximately 80% identical data models and 20% different data models; that is, the basic data blocks and industry-specific data blocks are the same in both models.
[0157] It requires creating a unique data model for each customer to achieve customer satisfaction and automation acceptance.
[0158] Traditionally, industry-specific data blocks are frozen after initial definition, but still require periodic updates due to business and IT changes. Businesses introduce new object types and relationships throughout the product lifecycle as it automates new processes or enhances the maturity of existing ones. IT introduces new software tools for the business, updating or replacing existing ones. All these changes necessitate regular updates to the data model within authoring tools, especially in integrated applications that use data authoring tools for data extraction and further processing.
[0159] The need for regular updates to data models and the use of cloud-based industrial software present the following business and technical challenges:
[0160] (1) Customers generally require software administrators to be able to make regular changes to the data model (without involving the IT department and without interrupting business).
[0161] (2) Cloud-based software requires the greatest flexibility in terms of data model changes because it integrates different applications, companies, and customers on the same cloud platform.
[0162] (3) Cloud-based applications typically cannot access databases and store data through applications owned by cloud providers, so application developers need to find a way to update database schemas / schemas;
[0163] (4) The unified data model for managing integrated software is particularly complex, as it combines data from different industrial software source systems. It requires frequent data model updates and periodic changes because the data from the source systems is highly heterogeneous.
[0164] These challenges necessitate a change in how data model definitions are defined. The following principles need to be considered:
[0165] (a) A data model may not be frozen after its initial definition; a non-frozen data model means that updates to any one or more of the names of data objects, attributes of data objects, and relations in the data model are possible;
[0166] (b) The data model can be easily configured and changed by the software administrator without requiring special IT knowledge;
[0167] (c) The data model can be updated without shutting down the database and stopping business operations;
[0168] (d) The data model for the cloud solution can be updated with minimal involvement from the cloud platform team;
[0169] (e) Cloud-based data storage solutions can provide maximum flexibility to support any type of data model and common data model changes.
[0170] Technically, a data model is represented in a database through a data storage schema. Depending on the database type, data storage schemes typically include:
[0171] A set of predefined tables with columns and rows in an RDB;
[0172] A set of predefined node and edge types with attributes in a graph database.
[0173] Traditional RDBs have predefined schemas. A common scenario is that when the data model changes, it's necessary to shut down the business logic and database software, and appropriately modify the database data storage schema. In other words, when the data model or its corresponding data storage schema changes, the data storage schema needs to be reread, and the business logic and database software restarted for the updated data storage schema to take effect.
[0174] Graph databases offer greater flexibility in changing data storage schemas. There are two types of graph databases: those with flexible schemas (such as Neo4J) and those with strictly predefined schemas (such as Nebula). Database administrators can change the data storage schema in such databases without shutting down the database.
[0175] Figure 4 This illustrates the traditional architecture of standalone industrial software applications, such as Figure 4 As shown, this illustrates the data model change cycle for standalone industrial software applications.
[0176] The data model change cycle in this architecture is as follows:
[0177] (1) Data model changes are initiated in the data modeler application.
[0178] (2) Changes are propagated to the database. Based on the changes in the data model, the data storage schema in the database is updated.
[0179] (3) The backend code has also been changed to represent updates in the data model and data storage schema – new methods for creating, reading, updating and deleting data objects have been introduced, etc.
[0180] (4) Finally, the changes to the data model are implemented in the front-end code.
[0181] For example, in the aforementioned standalone application, if it is necessary to add a data object to the data model—for instance, a new data object provided with a new class compared to one or more existing stored data objects—this addition is only at the logical level. To implement this addition, the data storage mode corresponding to the data model can be changed accordingly, then the backend code can be updated to represent the newly added data object, and finally, the frontend displays this newly added data object. For example, there exists a data model representing telephone contacts, where the data objects include their own personal information, including name, phone number, marital status, and number of children. According to the GDB data storage schema, each data object can be stored as a node associated with an item in the personnel information (e.g., a data structure with four members, recording name, phone number, marital status, and number of children). All data objects in the data model are stored using the same node type. Now, if a new data object with personnel and company information (company address and company name) needs to be added to the data model, using the existing node type is no longer feasible. This existing node type could be a four-member data structure; instead, a new node type needs to be created (e.g., a new data structure with six members) to store the personnel and company information of the new data object. Therefore, the data storage schema needs to be changed to create a new node type for the newly added data object. The data model and the corresponding data storage schema have changed.
[0182] Cloud-based industrial software applications have more complex architectures. They can be built on one or more cloud platform tools that manage databases and data models in the cloud. Figure 5 An example of an industrial software application built on a cloud platform is shown.
[0183] exist Figure 5 In the scenario shown, the development team for Application 1 uses cloud services provided by the cloud core application and does not directly access database management. Application 1 collaborates with the cloud core application via API. The cloud core application hosts more than one possible graph database. The cloud core application is managed by a separate cloud core team. Therefore, the development team for Application 1 needs to request a change in data storage schema from the cloud core team whenever the data model changes.
[0184] The above scenario can be extended to numerous applications created on the same cloud platform, such as... Figure 6 As shown.
[0185] exist Figure 6 In the case shown:
[0186] (a) Different applications from different vendors and different customers (e.g., customer 1, customer 2 and customer 4) use the same cloud core applications and databases from the cloud provider;
[0187] (b) Cloud core applications are supported and developed by the cloud core team;
[0188] (c) Applications have their own data modelers, front-ends, and back-ends;
[0189] (d) These applications are developed by different development teams, often partners – third-party teams;
[0190] (e) The developed applications are used by different customers and have different data models;
[0191] (f) After the application is implemented on the client side, the application's data model is managed by the client application administrator.
[0192] In this scenario, the application development team and application administrator need to contact the cloud core team to implement the data model change. The cloud core team needs to update the data storage schema and appropriate APIs in the database.
[0193] like Figure 6 As shown, data models 1, 2, 3, and 4 may need to be changed. Taking the update of data model 1 as an example, the development team or application administrator of the application corresponding to data model 1 should contact the cloud core team to update the data model and the corresponding data storage mode (shown as...). Figure 6 (The cloud core team then provides a new API for the updated data model, following the change request in the cloud).
[0194] The disadvantages of the above technical solutions ( Figure 5 and Figure 6 The effects described herein will impact the cloud provider's core team (also known as the cloud core team), application development teams, and application administrators.
[0195] (1) The main drawback is the complexity and time required to implement changes to the data model. Since application administrators and developers do not have direct access to the cloud database, they must contact the cloud core team when changes occur. This takes time, and can be lengthy if the teams are geographically separated.
[0196] (2) The cloud core team must introduce a mechanism to collect change requests and assign appropriate personnel (or teams) to implement data model change requests.
[0197] (3) The cloud core team needs to use a unified data scheme to store different data models, which makes this unified scheme complex, and the entities of data objects, relationships and attributes may be duplicated.
[0198] (4) The cloud core team needs to update the cloud core application API regularly to keep it in sync with the updated data storage model.
[0199] (5) The application development team lost flexibility in the process of change, became associated with the cloud core team, and became inefficient in the software (SW) development cycle.
[0200] All the drawbacks mentioned above become even more critical when developing cloud-based data integration applications. These applications connect data objects from different source systems with their own data models. Therefore, the integration of cloud applications should be open to new source system connections and should allow application administrators to dynamically change the unified integrated data model.
[0201] for Figure 4 The standalone application architecture shown has the same drawback: changing the data storage model requires additional time and IT resources.
[0202] In view of the above-mentioned technical problems, this disclosure proposes a data storage mode that is applicable to:
[0203] (1) Standalone data integration applications that use graph databases for data storage (also known as standalone industrial software applications).
[0204] (2) Cloud-based software applications that use cloud-based graph databases for data storage;
[0205] (3) Other industrial software applications use graph databases for data storage and require regular dynamic data model updates.
[0206] As described below, this disclosure introduces a flexible data storage model that supports any type of data model and a common API for exchanging data with cloud core applications (DBs) to allow database-level data transfer from... Figure 4 Excluded from the data model change chain of the independent application shown, and from the cloud core platform level... Figure 5 The data model change chain for cloud-based software applications shown is excluded. Figure 7 This is a schematic flowchart illustrating a change chain of a data model for an independent application according to one or more embodiments of this disclosure. Figure 8 This is a schematic flowchart illustrating the change chain of a data model for a cloud-based application according to one or more embodiments of this disclosure. Figure 8In the illustrated embodiment, application administrators are allowed to update the data model without changing the GDB data storage schema. In effect, it excludes the database from the update chain. The general database schema should be created once in the cloud core application and remain unchanged. In this way, developers of cloud-based applications (on the application side) are independent of developers of the cloud core infrastructure (also referred to above as the cloud core application), thereby reducing the IT workload for supporting DB schema updates: eliminating a task for the DB support team; and reducing the workload for the cloud provider: no need to support data model changes and updates.
[0207] This disclosure is applicable to any type of data stored in graph databases, primarily for heterogeneous graphs with complex logic (such as engineering diagrams). This disclosure can serve as a general method for representing heterogeneous graph information using homogeneous graphs. This disclosure allows users to reduce graph complexity and represent complex graphs in a "binary view" based on only two node types. It is useful for software development companies dealing with complex graphs. It can also be used by companies attempting to manage information in graph databases rather than traditional RDB databases and to leverage the advantages of homogeneous graph processing.
[0208] The principle of data storage mode will refer to Figure 9 To explain, the data storage model for any type of data model entity storage only has two types of nodes: basic nodes and attribute nodes. Basic nodes and attribute nodes can be connected through relationships, for example, the relationship _HAS_ATTRIBUTE.
[0209] Data storage uses an "atomic model," where "BaseNode" represents the "atomic nucleus," and all "AttributeNodes" represent "electrons." It should be noted that... Figure 9 The single attribute node shown is for illustrative purposes only; there can be more than one attribute node, and this application does not limit this. Any attribute on the atomic nucleus other than general attributes is based on its own node and connected through relationships. This provides absolute freedom in creating unique types of nodes and attributes and allows us to implement any data model the client desires. Figure 10 As shown in the example of the data model for storing data objects implemented in the above storage mode, the data model includes a basic node and nine attribute nodes, and each of the nine attribute nodes is connected by a relation (_HAS_ATTRIBUTE).
[0210] It should be noted that, Figure 10 The expressions “descripti…” and “paramet…” in the text indicate “description” and “parameter”, respectively.
[0211] It uses only two types of nodes to store information about all types of data objects, instead of the special node types and edges used in traditional data modeling methods.
[0212] (1) Basic nodes describe all types of data model entities (instances) and include a set of common attributes applicable to all types of data model objects;
[0213] (2) Attribute nodes describe industry- and customer-specific attributes. It includes a limited set of properties that apply to all types of attributes. The most important properties include: name (attribute name) and value (attribute value).
[0214] You can specify a list of common attributes for the basic node in Table 1. All of the following attributes can be of type string.
[0215] Table 1
[0216]
[0217] The value of the attribute name "type" depends on the client's application.
[0218] Table 2 allows you to specify a list of common attributes for each attribute node in the attribute node used to store the corresponding attributes. All of the following attributes can be of type string.
[0219] Table 2
[0220]
[0221] Figure 11 The properties of basic nodes and attribute nodes are shown as examples.
[0222] A general list of attributes relating each attribute node in the basic node and attribute nodes can be specified in Table 3. All of the following attributes can be of type string.
[0223] Table 3
[0224]
[0225] In Table 3, the attribute name "type" of the relation corresponds to the attribute name "type" of the basic node related to the relation in Table 1.
[0226] If a new type of data object is added to the data model, that type is defined in the data modeler and written using the generic API in the BaseNode "type" property. It is not necessary to create a new node type in the data storage schema. Figure 12AAs shown, new types of data objects can be extended by adding a list of values to the "type" field in Table 1 without needing to create new types of data objects in the database.
[0227] If you add a new type of attribute to a data object in the data model, that attribute type is defined in the data modeler and represented as a new attribute node linked to the base node. There is no need to update the attribute list in the data storage schema. For example... Figure 12B As shown, new types of properties can be added to the user interface, and the new properties are represented as new property nodes linked to the base node in the database, without needing to update the property list of the base node.
[0228] It should be noted that, Figure 12A and Figure 12B The “descripti…” and “paramet…” in the text indicate “description” and “parameter”, respectively.
[0229] Therefore, any complex data model can be described using this universal data storage pattern.
[0230] It should be noted that all entries shown in Tables 1 to 3 are for illustrative purposes only, and not all entries are necessary to represent the related basic nodes, attribute nodes, or relationships, such as createDate, owningUser, modifyDate, suspicious, dataSourceURL, lasModUser, description, eTag, etc.
[0231] In one possible implementation of this disclosure, the relationship can be a relationship between two first nodes. The general properties of this relationship are similar to those of the relationship between the first node (basic node) and the second node (attribute node) described above, and will not be repeated here.
[0232] The data storage pattern described above is a general scheme for any data model in a graph database. The application backend can implement several common services (e.g., create service, update service, compare service, delete service) to support all necessary graph database operations, as follows: Figures 13A to 13D As shown.
[0233] (1) Create a service
[0234] The service retrieves JSON (JavaScript Object Notation) from the request and creates a base node with a "basic" attribute. All other attributes are created as separate nodes (attribute nodes) and linked to the base node via the relation "_HAS_ATTRIBUTE". Attribute nodes cannot exist without a base node. Specifically, when the base node is created, the "basic" attribute is populated into the base node's field, and then all remaining attributes (all other attributes) after the base node is created will have their own attribute nodes. A code example for creating a base node is shown below.
[0235] {
[0236] "body": {
[0237] "uid": "99999999",
[0238] "name": "new document",
[0239] "createDate": "2023-04-06T16:21:28.9336134",
[0240] "owningUser": "user 1",
[0241] "modifyDate": "2023-04-06T16:21:28.9336134",
[0242] "suspicious": false,
[0243] "type": "document",
[0244] "dataSourceURL": "http: / / localhost",
[0245] "lastModUser": "user 1",
[0246] "description": "new document desc",
[0247] "eTag": "eTag value",
[0248] "extra_param1": "extra_param1_value",
[0249] "extra_param2": "extra_param2_value",
[0250] "extra_param3": "extra_param3_value",
[0251] "extra_param4": "extra_param4_value"
[0252] }
[0253] }
[0254] For extra_param1 / 2 / 3 / 4 in the code above, four new attribute nodes will be created respectively, and each of the four attribute nodes will be connected to the base node through a relationship.
[0255] (2) Update service
[0256] The service receives update requests, which may carry information about all fields of the base node and one or more attribute nodes of the data model to be updated. The update service calls the comparison service and, based on the call result, performs updates to existing attributes, creates new attributes, or deletes irrelevant attributes.
[0257] (3) Comparison services
[0258] Because nodes in the data storage schema have only two classes (types), it's possible to compare sorted lists of basic nodes and attribute nodes and determine whether they are equal based on the comparison results. This helps in understanding whether an entity needs to be updated, whether they are equal, or whether a new copy with a "SUSPICIOUS" relationship needs to be created.
[0259] (4) Delete service
[0260] A deletion request for the base node "uid" has been received. Attribute nodes cannot exist without a base node; therefore, all relationships with the specified base node and all related attribute nodes should be deleted.
[0261] The data model implemented based on the proposed data storage pattern has been described above. The data processing methods applying this data model will be described below. (References) Figure 14 The data processing method may include the following steps:
[0262] S1201, retrieve object information of the data object.
[0263] Specifically, the object information includes the basic attributes of the data object. In one possible implementation, the data object can be input by a client user; for example, it can be input by the development team of the application corresponding to the data model described above.
[0264] In one possible implementation, for example, the basic attribute of a data object could be its name. Taking the data model representing a telephone contact as an example, the data object could be a person whose personal information is used as its attributes; for instance, this personal information could include their name as a basic attribute in the object's information.
[0265] In one possible implementation, the basic attribute of the data object, i.e. the name of the data object, is used to indicate the name of the node (i.e., the first node mentioned below) used to store the basic attribute of the data object.
[0266] S1202, store object information in a data structure.
[0267] Specifically, to store object information of a data object in a data structure, a first node can be created in the data model as a data storage schema. That is, the data structure includes a first node, where the basic attributes of the data object are stored. The first node can be connected to at least one second node, where each of the at least one second node stores additional attributes of the data object. As previously described, in the example where the data object is a person as a telephone contact, in addition to the basic attributes of the data object, the data object may also have attributes (e.g., his / her phone number, marital status, and number of children). Therefore, these additional / specific attributes will not be stored in the first node but will be stored in the second nodes connected to the first node. More or less information may also be included, which is not limited in this disclosure embodiment. Furthermore, the number of second nodes can be equal to the number of additional attributes of the data object. That is, all these additional attributes are related to the same data object, and the names stored in the first node are general / common attributes shared by all these additional attributes. Therefore, these additional attributes are each stored in the second nodes, while the common attributes are stored in the first node.
[0268] In one possible implementation, the above data structure can be implemented as a combination of Figure 9 The proposed data storage model allows the first and second nodes to be the basic node and attribute node mentioned above, respectively. The name of the data object can be stored in the "name" field of the basic node shown in Table 1. The attributes of the data object can include those shown in Table 2.
[0269] The aforementioned data structure, as an implementation of a data storage model, can support any type of source system data model. It acts as a universal container, capable of storing and updating any data model. Data objects can have their own basic attributes (e.g., name), which can be stored in their corresponding first nodes. They can have different numbers of additional attributes, which can be stored in different numbers of second nodes. They can also have different relationships describing the relationship between the second nodes and the first nodes. However, for all these data objects, the data storage model is the same: regardless of what data object is added to the data model, it can be stored in the data structure. This data structure includes a first node for storing general attributes (the name of the data object) and one or more second nodes for storing other attributes (if any), thereby improving the storage efficiency of data objects. Compared to existing solutions, for example, when adding a new data object with a new class, the proposed solution does not require changing the data storage model. The new class will be treated as one or more new attributes of the data object, and only one or more new second nodes need to be created. In this way, the implementation time for data model changes can be reduced, and business efficiency can be improved by enabling flexible and rapid data model changes.
[0270] In one possible implementation of this disclosure, the type of the first node is indicated by object information and stored in a node type indicator associated with the first node. In another possible implementation, the type of the first node is used to indicate the type of the data object indicated by the object information. Different data objects correspond to different node types, including but not limited to: "part," "document," "function," and so on. Different types can have different numbers of attributes and relationships associated with the first node. For example, the "document" type has 20 additional attributes and 5 relationships, while the "part" type has 14 attributes and 8 relationships. Values for each type can be stored, for example, in the corresponding node type indicator indicated by the "type" field of the basic node shown in Table 1 above. After obtaining the object information, the type of the first object can be determined, for example, based on the number of additional attributes and relationships indicated in the object information.
[0271] In one possible implementation of this disclosure, the first node is associated with a node identifier used to identify the first node. In one possible implementation, the node identifier can be automatically assigned when the first node is created, for example, it can be indicated by the "uid" field of the basic node shown in Table 1 above.
[0272] In one possible implementation of this disclosure, the basic attribute is the name of the data object, and the first node is also associated with a node name, which indicates the name of the first node corresponding to the name of the data object. In one possible implementation, the name of the first node can be automatically given when the first node is created, for example, it can be indicated by the "name" field of the basic node shown in Table 1 above.
[0273] In one possible implementation of this disclosure, the first node is also associated with at least one of the following: the creator of the first node, the creation date of the first node, the update status of the first node, the source address of the object information, the modification date indicating the time when the information associated with the first node was last modified, or the modifier identifier indicating the modifier of the information associated with the first node was last modified. In one possible implementation, when creating the first node, the creator, creation date, update status, source address, modification date, and modifier identifier can be filled in, for example, automatically filled in the fields "owningUser", "createDate", "suspicious", "dataSourceURL", "modifyDate", and "lastModUser" as shown in Table 1 above. In one possible implementation, the modifier can be the same as the creator, or the modifier can be a user authorized or designated by the creator, and the modifier identifier can be the username of the user logged into the application; this disclosure does not limit this aspect.
[0274] In one possible implementation, the first node is also associated with at least one of the first node's tag and other information related to the first node, such as filling in the "eTag" and "description" fields of the basic node shown in Table 1. The first node's tag is used to indicate whether the "dataSourceURL" field has changed or is up-to-date.
[0275] Based on the above, object information of data objects can be stored in data structures, and object information can be checked quickly.
[0276] In one possible implementation of this disclosure, the object information further includes at least one additional attribute of the data object; wherein, the data structure further includes at least one second node, the at least one second node being connected to the first node through at least one correspondence, and each of the at least one additional attribute is stored in the at least one second node. In one possible implementation, when the first node is created, the first node carries basic / general / common attributes, all other additional attributes have their own attribute nodes, all other attributes can be at least one attribute of the aforementioned data object, each of the other attributes is stored in its own attribute node and connected to the basic node through its correspondence, wherein the relationships corresponding to different attribute nodes connected to the same basic node can be different, for example, attribute node 1 and attribute node 2 are connected to the basic node, and relationship 1 corresponding to attribute node 1 and relationship 2 corresponding to attribute node 2 have different attributes, such as id and target node as shown in Table 3, for example, id in relationship 1 is R01, and the target node in relationship 1 is attribute node 1, id in relationship 2 is R02, and the target node in relationship 2 is attribute node 2. It should be noted that the value of id is only exemplary, and other values can be set to achieve the functions defined by these fields, and the embodiments of this disclosure do not limit the specific values.
[0277] Based on this, the data structure for implementing the data storage model is flexible, and the data storage model only has two types of nodes (first node and second node) to support the storage of data objects of any data model.
[0278] In one possible implementation of this disclosure, for each of at least one attribute, the additional attribute includes a name and a value. For a second node storing the additional attribute, the second node is associated with a node identifier for identifying the second node, an attribute name for indicating the name of the additional attribute stored in the second node, and an attribute value for indicating the value of the additional attribute. In one possible implementation, the attribute node (second node) storing the additional attribute may have various fields for carrying a node identifier for identifying the attribute node, an attribute name for indicating the name of the additional attribute stored in the attribute node, and an attribute value for indicating the value of the additional attribute, such as the fields "uid", "name", and "value" of the attribute node shown in Table 2. For example, in a data model used to represent telephone contacts, where the data object is a person with personal information (including their name, phone number, marital status, and number of children) as additional attributes, at least one attribute includes the person's name, phone number, marital status, and number of children. Each of these attributes includes a name and a value. When the attribute is a person's phone number, the name and value of the attribute are "telephone number" and "701120", respectively, stored in the "attributename" and "attribute value" fields of the attribute node corresponding to the attribute.
[0279] Since each additional attribute has its own second node, operations such as creating, updating, deleting, and editing attributes can be efficiently performed by manipulating the second node corresponding to the additional attribute.
[0280] In one possible implementation of this disclosure, for each of the at least one second node, the second node is also associated with at least one of the following: the creator of the second node, the creation date of the second node, the modification date indicating the time when the information associated with the second node was last modified, or a modifier identifier indicating the modifier who last modified the information associated with the second node. In one possible implementation, the attribute node (second node) may have fields carrying the creator, creation date, modification date, or modifier identifier, such as the fields "owningUser", "createDate", "modifyDate", and "lastModUser" of the attribute node shown in Table 2. In one possible implementation, the modifier may be the same as the creator, or the modifier may be a user authorized or designated by the creator, and the modifier identifier may be the username of the user logged into the application; this disclosure does not limit this aspect.
[0281] Based on the above, users can quickly and comprehensively understand information related to the second node based on the data structure.
[0282] In one possible implementation, the second node is also associated with other information related to the second node, which can be filled into the “description” field of the attribute node shown in Table 2.
[0283] In one possible implementation of this disclosure, for each of at least one second node, the relationship between the second node and the first node is characterized by a relation identifier for identifying the relationship, an identifier for indicating the starting node of the relationship, an identifier for indicating the target node of the relationship, and a relation type for identifying the type of the relationship. The relation identifier, the identifier for indicating the starting node, and the identifier for indicating the target node can be indicated, for example, in the “id”, “startNode”, and “targetNode” fields shown in Table 3 above. Continuing with the example above, where attribute node 1 and attribute node 2 are connected to the base node, attribute node 1 and the base node are connected via relation 1, and attribute node 2 and the base node are connected via relation 2, relation 1 can be characterized by a relation identifier for identifying relation 1, such as the id “R01” of relation 1. Relation 1 can also be characterized by identifiers for indicating the starting node and target node of relation 1, such as the IDs of the starting node and target node, where the starting node can be the base node and the target node can be attribute node 1. Similarly, relation 2 can be characterized by a relation identifier used to identify relation 2, such as the id "R02" of relation 2. Relation 2 can also be characterized by identifiers used to indicate the starting node and the target node of relation 2, such as the IDs of the starting node and the target node, where the starting node can be a base node and the target node can be attribute node 2.
[0284] Based on the above information related to relationships, users can quickly and comprehensively understand the nodes related to those relationships.
[0285] In one possible implementation of this disclosure, the relationship is further characterized by at least one of the following: the creator of the relationship, the creation date of the relationship, the modification date indicating the time when the relationship was last modified, or the modifier identifier indicating the modifier who modified the relationship. For example, the creator, creation date, modification date, and modifier identifier can be indicated in the "owningUser", "createDate", "modifyDate", and "lastModUser" fields shown in Table 3 above, respectively.
[0286] Based on the above relationship-related identifiers, users can quickly and comprehensively learn about relationship-related information.
[0287] In one possible implementation of this disclosure, step S1202, storing object information based on a data structure, includes:
[0288] Call the general application programming interface (API) to:
[0289] Create the first node to store the basic properties of the data object;
[0290] Create at least one second node to store at least one additional attribute;
[0291] For each of at least one second node, create a relationship between the first node and the second node.
[0292] In one possible implementation, a general-purpose API allows users to change the data model from the application interface via web requests. The general-purpose API supports various operations and has a flexible data storage model, which can be divided into three types: (1) Node API; (2) Relationship API; and (3) Data Retrieval API (hereinafter also referred to as Search API). It should be noted that three APIs are shown here, but they are illustrative and not restrictive. In practical applications, we can use only one API to support all operations, and this disclosure does not limit this approach.
[0293] A first node and at least one second node can be created using the node API, and the relationship between the first node and each of the at least one second node can be created using the relationship API. For example, the relationship could be... Figure 9 The _HAS_ATTRIBUTE relationship is shown below. The syntax for creating the first node (base node) and the second node (attribute node) and the relationship between them are given below.
[0294] POST / createBaseNode
[0295] Description: This is used to create new "basic nodes".
[0296] Return: The output is a single "basic node", which may have the basic attributes created and filled in.
[0297] POST / createAttributeNode
[0298] Description: This is used to create new "attribute nodes".
[0299] Return: The output is a single "attribute node" with the created and populated attributes.
[0300] POST / createRelation
[0301] Description: This is used to create new relationships between base nodes and attribute nodes.
[0302] Return: The output is a single relation with the populated attributes created between the two nodes.
[0303] The general API supports the above data storage modes and is introduced only once. It does not need to be updated when any data model changes, thus simplifying the way databases are handled, reducing the complexity of software code for developers, reducing "template code", and eliminating the need to create CRUD + compare for each data model object. Due to the limited number of methods used, code simplification and reduced code migration workload are achieved.
[0304] In one possible implementation of this disclosure, the method further includes: in response to a type addition request, invoking a generic API to add the type to be added as indicated in the type addition request as an available type of the data structure. In one possible implementation, the type to be added can be defined in the data modeler of the data model and written to the "type" field of the base node shown in Table 1 via the generic API. For example, if the type to be added indicated in the type addition request is a "function" type, then the "function" type is added to the "type" field of the base node.
[0305] The above method eliminates the need to create new node types in the data storage model, thereby reducing the time required to change the data model and improving business efficiency by enabling flexible and rapid data model changes.
[0306] In one possible implementation of this disclosure, the method further includes: in response to an additional attribute addition request, invoking a generic API to create another second node to store the additional attribute indicated in the additional attribute addition request. In one possible implementation, the additional attribute indicated in the additional attribute addition request may be defined in the data modeler of the data model and represented as a new attribute node linked to the base node via invoking the generic API.
[0307] Therefore, adding attributes will be achieved by adding a second node, eliminating the need to update the attributes listed in the data storage model. This reduces the time required to change the data model and improves business efficiency by enabling flexible and rapid data model changes.
[0308] In one possible implementation of this disclosure, the method further includes: in response to a first node deletion request, invoking a general API to delete the first node, wherein the first node deletion request indicates the node identifier of the first node. In one possible implementation, the general API is a node API. When a base node is created, the attributes associated with the base node can only have "base" attributes, or they can have both "base" attributes and other attributes simultaneously, which are stored one by one in the attribute nodes. In the former case, if there are no attribute nodes connected to the base node, in response to the first node deletion request, only the base node is deleted by invoking the general API; in the latter case, if there are one or more attribute nodes connected to the base node, in response to the first node deletion request, the base node and the one or more attribute nodes connected to the base node are deleted by invoking the general API. The syntax for deleting the first node (base node) is as follows:
[0309] POST / deleteBaseNode
[0310] Description: This is used to delete a single "base node" and all associated "attribute nodes" by the "base node's" UID.
[0311] Returns: The output shows the single "base node" deleted from the database and all related "attribute nodes".
[0312] In one possible implementation of this disclosure, the method further includes: in response to a node edit request, invoking a general API to update the node indicated by the node identifier in the node edit request with the attribute value indicated in the node edit request. When the node edit request is a node edit request for editing a first node (in which case, the node edit request will be referred to as a first node edit request), the method includes: in response to the first node edit request, invoking a general API to update the first node having the node identifier indicated in the first node edit request with the attribute value indicated in the first node edit request. In one possible implementation, the general API is a node API, and the first node edit request may carry the attribute value of the attribute to be updated for the first node, i.e., the attribute value of the "basic" attribute (e.g., the name and / or type of the data object), and may carry the node identifier of the first node, such as the id of the first node. The syntax for editing the first node (basic node) is as follows:
[0313] POST / editBaseNode
[0314] Description: This is used to update the properties of the specified "base node".
[0315] Returns: Outputs the updated properties of the single existing "basic node".
[0316] The creation, deletion, and editing operations of the first node mentioned above can all be implemented through the general API. The general API only needs to be imported once and does not need to be updated when the data model changes, thereby reducing the time required to implement data model changes and improving business efficiency due to the flexible and rapid implementation of data model changes.
[0317] In one possible implementation of this disclosure, the creation, editing, and deletion of multiple first nodes are similar to those of a single first node mentioned above, and will not be repeated here. The syntax for creating, deleting, and editing multiple first nodes (basic nodes) is as follows.
[0318] POST / createBaseNodeBulk
[0319] Description: This is used to create a new list of "basic nodes".
[0320] Returns: The output is a list of "basic nodes", which may have the attributes created and filled in.
[0321] POST / deleteBaseNodeBulk
[0322] Description: This is used to delete the "basic node" list and all associated "attribute nodes" by UID.
[0323] Returns: Output is a list of the deleted "base nodes".
[0324] POST / editBaseNodeBulk
[0325] Description: This is used to update the properties of a specified list of "base nodes".
[0326] Returns: The output is the updated properties of the existing "basic nodes".
[0327] In one possible implementation of this disclosure, the method further includes: responding to a second node deletion request, invoking a general API to delete at least one target second node among the second nodes that has a node identifier indicated in the second node deletion request. In one possible implementation, the node identifier indicated in the second node deletion request can be a node identifier of the second node, and the second node to be deleted (the target second node) can be determined based on the deletion request. In one possible implementation, the general API is a node API, and the node identifier indicated in the second node deletion request can include node identifiers of a first node and a second node. First, the first node connected to the second node to be deleted can be determined based on the node identifier of the first node; then, the second node to be deleted can be determined based on the node identifier of the second node. The syntax for deleting a second node (attribute node) is as follows:
[0328] POST / deleteAttributeNode
[0329] Description: This is used to delete an "attribute node" by UID.
[0330] Returns: The output is the single "attribute node" that was deleted.
[0331] In one possible implementation of this disclosure, when the node edit request is for deleting a second node (in this case, the node edit request will be referred to as the second node edit request), the method further includes: in response to the second node edit request, invoking a general API to update at least one second node having a node identifier indicated in the second node edit request with the additional attribute value indicated in the second node edit request. In one possible implementation, the general API is a node API, and the second node edit request may carry the attribute value of the additional attribute of the second node to be updated to update the "attribute value" field of the second node. The syntax for editing the second node (attribute node) is as follows:
[0332] POST / editAttributeNode
[0333] Description: This is used to update the properties of a specified "property node".
[0334] Returns: The output is the updated properties of the existing single "property node".
[0335] The creation, deletion, and editing operations of the second node mentioned above can all be implemented through the general API. The general API only needs to be imported once and does not need to be updated when the data model changes, thereby reducing the time required to implement data model changes and improving business efficiency due to the flexible and rapid implementation of data model changes.
[0336] In one possible implementation of this disclosure, the creation, editing, and deletion of multiple second nodes are similar to those of a single second node mentioned above, and will not be repeated here. The syntax for creating, deleting, and editing multiple second nodes (attribute nodes) is as follows:
[0337] POST / createAttributeNodeBulk
[0338] Description: This is used to create a new list of "attribute nodes".
[0339] Returns: The output is a list of "attribute nodes" containing the created and populated attributes.
[0340] POST / editAttributeNodeBulk
[0341] Description: This is used to update the properties of a specified list of "property nodes".
[0342] Returns: The output is the updated properties of the existing "property nodes".
[0343] POST / deleteAttributeNodeBulk
[0344] Description: This is used to delete the list of "Attribute Nodes" by their UID.
[0345] Returns: The output is a list of the deleted "attribute nodes".
[0346] In one possible implementation of this disclosure, the method further includes: responding to a first relationship deletion request by invoking a general API to delete the relationship between the first node indicated in the first relationship deletion request and a target second node among at least one second node, and the target second node. In one possible implementation, the general API is a relationship API, where the relationship is the relationship between the first node and the second node. The first relationship deletion request may carry at least one of a relationship identifier and a node identifier of the second node associated with the relationship. When the first relationship deletion request carries a relationship identifier (such as the id of the relationship shown in Table 3), the relationship to be deleted can be determined; based on the determined relationship and its attributes (such as the value of the "targetNode" field of the relationship shown in Table 3), the second node associated with the relationship can be determined; then the relationship and the second node associated with the relationship are deleted. When the first relationship deletion request carries a node identifier of the second node associated with the relationship (such as the id of the second node shown in Table 3), the target second node associated with the relationship can be determined. Based on the determined target second node, a relationship whose value of the "targetNode" field is the same as the determined id of the target second node can be determined from the relationships associated with the first node, and then the relationship and the target second node associated with the relationship are deleted.
[0347] In one possible implementation of this disclosure, the method further includes: in response to a second relationship deletion request, invoking a general API to delete the relationship between the first node indicated in the second relationship deletion request and another first node. In one possible implementation, the general API is a relationship API, where the relationship is between two first nodes, and the second relationship deletion request may carry an identifier of the relationship, such as the relationship's id.
[0348] The syntax for deleting a relationship is as follows:
[0349] POST / deleteRelation
[0350] Description: This is used to delete a single relationship between nodes by UID.
[0351] Return: The output is the single relation and associated attitude node that was deleted from the database.
[0352] In one possible implementation of this disclosure, the method further includes: in response to a relationship edit request, invoking a general API to update the relationship indicated in the relationship edit request. In one possible implementation, the general API is a relationship API, and the relationship edit request may carry the relationship's ID to update the relationship's attributes, such as the "targetNode", "modifyDate", "lastModUser", and "description" fields. The syntax for editing relationships is as follows:
[0353] POST / editRelation
[0354] Description: This is used to update the properties of a specified relationship.
[0355] Returns: The output is the updated attributes of a single relationship that exists between the nodes.
[0356] The creation, deletion, and editing of the aforementioned relationships can all be implemented through a general API. The general API only needs to be imported once and does not need to be updated when the data model changes, thereby reducing the time required to implement data model changes and improving business efficiency due to the ability to make flexible and rapid data model changes.
[0357] In one possible implementation of this disclosure, the creation, editing, and deletion of multiple relations are similar to those of a single relation as described above, and will not be repeated here. The syntax for creating, deleting, and editing multiple relations is shown below.
[0358] POST / createRelationBulk
[0359] Description: This is used to create a list of relationships between new nodes.
[0360] Return: The output is a list of relations with the populated attributes created between the nodes.
[0361] POST / deleteRelationBulk
[0362] Description: This is used to delete a list of relationships by UID.
[0363] Returns: Output is a list of the relationships that were deleted.
[0364] POST / editRelationBulk
[0365] Description: This is used to update the properties of a specified list of relationships.
[0366] Return: The output is the updated attributes that have existing relationships.
[0367] In one possible implementation of this disclosure, the method further includes: responding to a second node search request by invoking a general API to return all second nodes connected to the first node from at least one second node, wherein the second node search request indicates the node identifier of the first node. In one possible implementation, the general API is a search API, and the second node search request carries the node identifier of the first node, such as the first node's id. Based on the first node's node identifier, one or more second nodes associated with the first node can be identified, as well as all information associated with one or more second nodes. The syntax for searching one or more second nodes associated with the first node is as follows:
[0368] POST / getAllRelatedNodes
[0369] Description: This is used to retrieve all child nodes that are related to a specified node (first node) by any relationship.
[0370] Returns: The output is a list of the second node, attributes, and relationships.
[0371] In one possible implementation of this disclosure, the method further includes: responding to a first relation search request by invoking a general API to return information about at least one target second node connected to the first node through a relation indicated in the first relation search request. In one possible implementation, the general API is a search API, the relation is the relationship between the first node and the second node, the first relation search request may carry a relation ID, and based on this request, the first node and the target second node associated with the relation can be determined, as well as all information related to the first node and the target second node.
[0372] In one possible implementation of this disclosure, the method further includes: in response to a second relationship search request, invoking a general API to return information about another first node connected to the first node through the relationship indicated in the second relationship search request. In one possible implementation, the general API is a search API, the relationship being between two first nodes, and the second relationship search request may carry a relationship ID. Based on this request, the first node and another first node related through the relationship can be determined, as well as all information related to these two first nodes.
[0373] The syntax for searching all nodes related by this relationship is as follows:
[0374] POST / getRelatedNodesBySpecifiedRelation
[0375] Description: This is used to retrieve all nodes that are related to a specified node through a specified relationship.
[0376] Returns: The output is a list of nodes, attributes, and one or more relationships.
[0377] In one possible implementation of this disclosure, the method further includes: responding to an attribute search request by invoking a general API to return information about nodes storing the attribute indicated in the attribute search request in a first node and at least one second node. In one possible implementation, the general API is a search API, and the attribute search request may carry the attribute name and attribute value. Based on the attribute name and attribute value, nodes possessing the attribute (which has an attribute name and attribute value) can be determined, as well as all information associated with that node. For example, if the attribute search request includes an attribute named "type" and with a value of "requirement," then nodes possessing that attribute can be determined. In one possible implementation, if the attribute indicated in the attribute search request is an attribute of a first node, then the first node and all or more second nodes associated with the first node (if any) are returned; if the attribute indicated in the attribute search request is an attribute of a second node, then only the second node is returned.
[0378] The syntax for searching all nodes related by this relationship is as follows:
[0379] POST / findNodeBySpecifiedAttribute
[0380] Description: This is used to find nodes by any specified attribute.
[0381] Returns: The output is a list of nodes, attributes, and relationships.
[0382] In one possible implementation of this disclosure, the method further includes: in response to a node search request, invoking a general API to return information about nodes identified by node identifiers indicated in the node search request, from a first node and at least one second node. In one possible implementation, the general API is a search API, the node search request may carry a node ID, and the node may be either a first node or a second node. Based on this request, the node can be determined, as well as all information associated with the node. The syntax for searching for nodes associated with node identifiers is as follows:
[0383] POST / findNodeByUID
[0384] Description: This is used to find nodes by UID.
[0385] Returns: The output is a list of nodes, attributes, and relationships.
[0386] In one possible implementation of this disclosure, the method further includes: responding to an attribute value search request by invoking a general API to return information about nodes in a first node and at least one second node, wherein the attribute value of the node's attribute is the same as the attribute value indicated in the attribute value search request. In one possible implementation, the general API is a search API that, based on the request, can determine a node and all information associated with that node. For example, if the attribute value search request includes an attribute with a value of "requirement", then nodes with the attribute (whose attribute value is the same as the attribute value) can be determined. The syntax for searching for nodes associated with the attribute value is as follows:
[0387] POST / findNodeGlobally
[0388] Description: This is used to find nodes by the value of any attribute.
[0389] Returns: The output is a list of nodes, attributes, and relationships.
[0390] All of the above operations can be implemented through a general API. The general API only needs to be imported once and does not need to be updated when the data model changes, thereby reducing the time required to implement data model changes and improving business efficiency due to the ability to make flexible and rapid data model changes.
[0391] In view of the above, this disclosure can solve the following technical problems:
[0392] (1) The technical dependencies between the application development team and the cloud core team and database team;
[0393] (2) Lack of the possibility of real-time data model updates;
[0394] (3) Each time the data model is updated, the data storage mode needs to be updated;
[0395] (4) Each data model update requires updating the cloud core API;
[0396] (5) The complexity of unified data model management in cloud applications;
[0397] (6) A large amount of “template code” is used for backend implementation (in the case of complex data models).
[0398] Figure 15 A schematic structural diagram of a data processing apparatus according to an embodiment of the present disclosure is shown. Figure 15 As shown, the data processing device 1500 may include:
[0399] The acquisition module 1501 is used to acquire object information of a data object, wherein the object information includes the basic attributes of the data object;
[0400] Storage module 1502 is used to store object information in a data structure, wherein the data structure includes a first node, the basic attributes of the data object are stored in the first node, the first node can be connected to at least one second node, and each of the at least one second node is used to store additional attributes of the data object.
[0401] In one possible implementation of this disclosure, the object information further includes at least one additional attribute of the data object;
[0402] The data structure also includes at least one second node, which is connected to the first node through at least one correspondence, and each of the at least one additional attributes is stored in the at least one second node.
[0403] In one possible implementation of this disclosure, for each of at least one attribute, the attribute includes a name of an additional attribute and a value of the additional attribute, and for a second node storing the additional attribute, the second node is associated with a node identifier for identifying the second node, an attribute name for indicating the name of the additional attribute stored in the second node, and an attribute value for indicating the value of the additional attribute.
[0404] In one possible implementation of this disclosure, for each of at least one second node, the second node is also associated with at least one of the following:
[0405] The creator of the second node, the creation date of the second node, the modification date indicating the time when the information associated with the second node was last modified, or the modifier identifier indicating the modifier who last modified the information associated with the second node.
[0406] In one possible implementation of this disclosure, for each of at least one second node, the relationship between the second node and the first node is characterized by a relationship identifier for identifying the relationship, an identifier for indicating the starting node of the relationship, an identifier for indicating the target node of the relationship, and a relationship type for identifying the type of the relationship.
[0407] In one possible implementation of this disclosure, the relationship is further characterized by at least one of the following:
[0408] The creator of the relationship, the creation date of the relationship, the modification date indicating when the relationship was last modified, or the modifier identifier indicating the modifier who modified the relationship.
[0409] In one possible implementation of this disclosure, the device further includes:
[0410] The calling module is used to invoke the common application programming interface (API) to:
[0411] Create the first node to store the basic properties of the data object;
[0412] Create at least one second node to store at least one additional attribute;
[0413] For each of the at least one second node, a relationship is created between the first node and the second node.
[0414] In one possible implementation of this disclosure, the apparatus further includes a calling module for:
[0415] In response to a second node deletion request, invoke the general API to delete at least one target second node that has the node identifier indicated in the second node deletion request.
[0416] In one possible implementation of this disclosure, the apparatus further includes a calling module for:
[0417] In response to a second node edit request, a general API is invoked to update at least one second node that has a node identifier indicated in the second node edit request with the additional attribute values indicated in the second node edit request.
[0418] In one possible implementation of this disclosure, the apparatus further includes a calling module for:
[0419] In response to a first relationship deletion request, the general API is invoked to delete the relationship between the first node indicated in the first relationship deletion request and the target second node in at least one second node, as well as the target second node.
[0420] In one possible implementation of this disclosure, the apparatus further includes a calling module for:
[0421] In response to a second relationship deletion request, invoke the general API to delete the relationship between the first node indicated in the second relationship deletion request and another first node.
[0422] In one possible implementation of this disclosure, the apparatus further includes a calling module for:
[0423] In response to a relationship edit request, invoke the general API to update the relationship indicated in the relationship edit request.
[0424] In one possible implementation of this disclosure, the apparatus further includes a calling module for:
[0425] In response to a second node search request, a general API is invoked to return all second nodes in at least one second node that are connected to the first node, wherein the second node search request indicates the node identifier of the first node.
[0426] In one possible implementation of this disclosure, the apparatus further includes a calling module for:
[0427] In response to the first relation search request, the general API is invoked to return information about the target second node in at least one second node that is connected to the first node by the relation indicated in the first relation search request.
[0428] In one possible implementation of this disclosure, the apparatus further includes a calling module for:
[0429] In response to the second relation search request, the general API is invoked to return information about another first node that is connected to the first node through the relation indicated in the second relation search request.
[0430] In one possible implementation of this disclosure, the apparatus further includes a calling module for:
[0431] In response to an attribute search request, the general API is invoked to return information about the nodes storing the attribute indicated in the attribute search request in the first node and at least one second node.
[0432] In one possible implementation of this disclosure, the apparatus further includes a calling module for:
[0433] In response to a node search request, the general API is invoked to return information about the first node and at least one second node identified by the node identifier indicated in the node search request.
[0434] In one possible implementation of this disclosure, the type of the first node is indicated by object information and stored in a node type indicator associated with the first node.
[0435] In one possible implementation of this disclosure, the first node is associated with a node identifier used to identify the first node.
[0436] In one possible implementation of this disclosure, the basic attribute is the name of the data object, and the first node is also associated with a node name, which is used to indicate the name of the first node corresponding to the name of the data object.
[0437] In one possible implementation of this disclosure, the first node is also associated with at least one of the following:
[0438] The creator of the first node, the creation date of the first node, the update status of the first node, the source address of the object information, the modification date indicating the time when the information associated with the first node was last modified, or the modifier identifier indicating the modifier who last modified the information associated with the first node.
[0439] In one possible implementation of this disclosure, the apparatus further includes a calling module for:
[0440] In response to a type add request, the general API is invoked to add the type to be added as indicated in the type add request as an available type for the data structure.
[0441] In one possible implementation of this disclosure, the apparatus further includes a calling module for:
[0442] In response to an additional attribute add request, the general API is invoked to create another second node to store the additional attributes indicated in the additional attribute add request.
[0443] In one possible implementation of this disclosure, the apparatus further includes a calling module for:
[0444] In response to a first node deletion request, the general API is invoked to delete the first node, where the first node deletion request indicates the node identifier of the first node.
[0445] In one possible implementation of this disclosure, the apparatus further includes a calling module for:
[0446] In response to a node edit request, the general API is invoked to update the node indicated by the node identifier in the first node edit request with the attribute values indicated in the first node edit request.
[0447] It should be noted that the technical effect of this data processing device is similar to the data processing method described above, and will not be repeated here.
[0448] This application provides a computing device cluster, including a processing circuit, which is used to execute any of the above-described data processing methods.
[0449] This disclosure provides an electronic device including a processing circuit for performing any of the above-described data processing methods.
[0450] In one possible implementation, the electronic device may include a transceiver, a processor, and a memory. The memory may be used to store code, instructions, etc., executed by the processor.
[0451] It should be understood that the processor can be an integrated circuit chip with data processing capabilities. In implementation, the various steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by software instructions. The processor can be a general-purpose processor, a central processing unit (CPU), a graphics processing unit (GPU), a neural processing unit (NPU), a system-on-chip (SoC), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The processor can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor can be a microprocessor, or it can be any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly executed and completed by a hardware decoding processor, or executed and completed by a combination of hardware and software modules in the decoding processor. The software modules can reside in mature storage media in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with the hardware in the processor, completes the steps of the above methods.
[0452] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or it can include both volatile and non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random-access memory (RAM) used as an external cache. By way of example rather than limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).
[0453] It should be noted that the memory described in this specification includes, but is not limited to, these memories, and may be any other suitable type of memory.
[0454] This disclosure provides a chip including an input / output (I / O) interface and a processor, the processor being used to call and run a computer program stored in a memory, enabling a device equipped with the chip to execute any of the above-described data processing methods.
[0455] This disclosure provides a computer-readable medium storing computer-executable instructions that, when executed by a processor, cause the processor to perform any of the above-described data processing methods. Optionally, the storage medium may specifically be a memory.
[0456] This disclosure provides a computer program product including computer-executable instructions that, when executed by a processor, cause the processor to perform any of the above-described data processing methods.
[0457] This disclosure provides a computer program including computer-executable instructions that, when executed by a processor, cause the processor to perform any of the above-described data processing methods.
[0458] Those skilled in the art will recognize that the various examples, units, and algorithm steps described in conjunction with the embodiments disclosed in this specification can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but should not consider such implementation to be beyond the scope of this application.
[0459] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the described apparatus embodiments are merely examples. For example, the unit division is merely a logical functional division, and in actual implementation, it can be other divisions. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not performed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed can be implemented through some interface. Indirect coupling or communication connection between devices or units can be implemented electronically, mechanically, or otherwise.
[0460] The units described as discrete components may or may not be physically separate. The components shown as units may or may not be physical units, and may be located in one location or distributed across multiple network units. Some or all of the units can be selected based on actual needs to achieve the purpose of this embodiment.
[0461] Furthermore, in the various embodiments of this application, each functional unit can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0462] When these functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, its essential contribution to the prior art, or a portion thereof, can be implemented in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to instruct a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0463] Although this disclosure describes methods and processes by way of steps in a certain order, one or more steps in the methods and processes may be omitted or changed as appropriate. Where appropriate, one or more steps may be performed in an order other than that described.
[0464] It should be noted that the expression "at least one of A or B" as used in this document is interchangeable with the expression "A and / or B". It refers to a list in which A, or B, or both A and B can be selected. Similarly, "at least one of A, B, or C" as used in this document is interchangeable with "A and / or B and / or C" or "A, B, and / or C". It refers to a list in which: A or B or C, or both A and B, or both A and C, or both B and C, or all of A, B, and C can be selected. The same principle applies to longer lists with the same format.
[0465] Although this disclosure describes at least part of the methodological aspects, those skilled in the art will understand that this disclosure also relates to various components, whether hardware components, software, or any combination thereof, for performing at least some aspects and features of the described methods. Accordingly, the technical solutions of this disclosure can be implemented in the form of a software product. Suitable software products may be stored in pre-recorded storage devices or other similar non-volatile or non-transitory computer-readable media, including DVDs, CD-ROMs, USB flash drives, removable hard drives, or other storage media. The software product includes instructions tangibly stored therein that enable a processing device (e.g., a personal computer, server, or network device) to perform the method examples disclosed herein. Machine-executable instructions may be in the form of code sequences, configuration information, or other data, which, when executed, cause a machine (e.g., a processor or other processing device) to perform the steps in the methods according to the examples of this disclosure.
[0466] This disclosure may be implemented in other specific forms without departing from the subject matter of the claims. The exemplary embodiments described are to be regarded in all respects as illustrative rather than restrictive. Features selected from one or more of the foregoing embodiments may be combined to create alternative embodiments not explicitly described, and features suitable for such combinations will be understood within the scope of this disclosure.
Claims
1. A data processing method, characterized in that, include: Obtain object information of a data object, wherein the object information includes the basic attributes of the data object; The object information is stored in a data structure, wherein the data structure includes a first node, the basic attributes of the data object are stored in the first node, the first node can be connected to at least one second node, and each of the at least one second node is used to store additional attributes of the data object.
2. The method according to claim 1, characterized in that, The object information also includes at least one additional attribute of the data object; The data structure further includes at least one second node, which is connected to the first node through at least one correspondence relationship, and each of the at least one additional attributes is stored in the at least one second node.
3. The method according to claim 2, characterized in that, For each of the at least one additional attribute, the additional attribute includes a name of the additional attribute and a value of the additional attribute, and for a second node storing the additional attribute, the second node is associated with a node identifier for identifying the second node, an attribute name for indicating the name of the additional attribute stored in the second node, and an attribute value for indicating the value of the additional attribute.
4. The method according to claim 2 or 3, characterized in that, For each of the at least one second node, the second node is also associated with at least one of the following: The creator of the second node, the creation date of the second node, the modification date indicating the time when the information associated with the second node was last modified, or the modifier identifier indicating the modifier who last modified the information associated with the second node.
5. The method according to any one of claims 2 to 4, characterized in that, For each of the at least one second node, the relationship between the second node and the first node is characterized by a relationship identifier for identifying the relationship, an identifier for indicating the starting node of the relationship, an identifier for indicating the target node of the relationship, and a relationship type for identifying the type of the relationship.
6. The method according to claim 5, characterized in that, The relationship is also characterized by at least one of the following: The creator of the relationship, the creation date of the relationship, the modification date indicating the time when the relationship was last modified, or the modifier identifier indicating the modifier who modified the relationship.
7. The method according to any one of claims 2 to 6, characterized in that, The object information is stored based on a data structure, including: Call the general application programming interface (API) to: Create the first node to store the basic attributes of the data object; Create the at least one second node to store the at least one additional attribute one by one; For each of the at least one second node, a relationship is created between the first node and the second node.
8. The method according to any one of claims 2 to 7, characterized in that, Also includes: In response to a second node deletion request, a general API is invoked to delete the target second node among the at least one second node that has the node identifier indicated in the second node deletion request.
9. The method according to any one of claims 2 to 8, characterized in that, Also includes: In response to a first relationship deletion request, a general API is invoked to delete the relationship between the first node indicated in the first relationship deletion request and a target second node among the at least one second node, as well as the target second node.
10. The method according to any one of claims 2 to 9, characterized in that, Also includes: In response to a second relationship deletion request, a general API is invoked to delete the relationship between the first node and another first node as indicated in the second relationship deletion request.
11. The method according to any one of claims 2 to 10, characterized in that, Also includes: In response to a relationship edit request, a general API is invoked to update the relationship indicated in the relationship edit request.
12. The method according to any one of claims 2 to 11, characterized in that, Also includes: In response to a second node search request, a general API is invoked to return all second nodes of the at least one second node connected to the first node, wherein the second node search request indicates the node identifier of the first node.
13. The method according to any one of claims 2 to 12, characterized in that, Also includes: In response to the first relation search request, a general API is invoked to return information about the target second node in the at least one second node that is connected to the first node by the relation indicated in the first relation search request.
14. The method according to any one of claims 2 to 13, characterized in that, Also includes: In response to the second relation search request, the general API is invoked to return information about another first node connected to the first node through the relation indicated in the second relation search request.
15. The method according to any one of claims 2 to 14, characterized in that, Also includes: In response to an attribute search request, a general API is invoked to return information about the nodes in the first node and the at least one second node that store the attribute indicated in the attribute search request.
16. The method according to any one of claims 2 to 15, characterized in that, Also includes: In response to a node search request, a general API is invoked to return information about the node identified by the node identifier indicated in the node search request among the first node and the at least one second node.
17. The method according to any one of claims 1 to 16, characterized in that, Also includes: In response to an additional attribute addition request, a general API is invoked to create another second node to store the additional attribute indicated in the additional attribute addition request.
18. The method according to any one of claims 1 to 17, characterized in that, The type of the first node is indicated by the object information and stored in the node type indicator associated with the first node.
19. The method according to any one of claims 1 to 18, characterized in that, The basic attribute is the name of the data object, and the first node is also associated with a node name, which is used to indicate the name of the first node corresponding to the name of the data object.
20. The method according to any one of claims 1 to 19, characterized in that, The first node is also associated with at least one of the following: The creator of the first node, the creation date of the first node, the update status of the first node, the source address of the object information, the modification date indicating the time when the information associated with the first node was last modified, or the modifier identifier indicating the modifier who last modified the information associated with the first node.
21. The method according to any one of claims 1 to 20, characterized in that, Also includes: In response to a type addition request, a general API is invoked to add the type to be added as indicated in the type addition request as an available type of the data structure.
22. The method according to any one of claims 1 to 21, characterized in that, Also includes: In response to a first node deletion request, a general API is invoked to delete the first node, wherein the first node deletion request indicates the node identifier of the first node.
23. The method according to any one of claims 1 to 22, characterized in that, Also includes: In response to a node edit request, a general API is invoked to update the node indicated by the node identifier in the node edit request with the attribute value indicated in the node edit request.
24. A data processing apparatus, characterized in that, include: The acquisition module is used to acquire object information of a data object, wherein the object information includes the basic attributes of the data object; A storage module is used to store the object information in a data structure, wherein the data structure includes a first node, the basic attributes of the data object are stored in the first node, the first node can be connected to at least one second node, and each of the at least one second node is used to store additional attributes of the data object.
25. The apparatus according to claim 24, characterized in that, The object information also includes at least one additional attribute of the data object; The data structure further includes at least one second node, which is connected to the first node through at least one correspondence relationship, and each of the at least one additional attributes is stored in the at least one second node.
26. The apparatus according to claim 25, characterized in that, For each of the at least one attribute, the attribute includes the name of the additional attribute and the value of the additional attribute, and for a second node storing the additional attribute, the second node is associated with a node identifier for identifying the second node, an attribute name for indicating the name of the additional attribute stored in the second node, and an attribute value for indicating the value of the additional attribute.
27. The apparatus according to claim 25 or 26, characterized in that, For each of the at least one second node, the second node is also associated with at least one of the following: The creator of the second node, the creation date of the second node, the modification date indicating the time when the information associated with the second node was last modified, or the modifier identifier indicating the modifier who last modified the information associated with the second node.
28. The apparatus according to any one of claims 25 to 27, characterized in that, For each of the at least one second node, the relationship between the second node and the first node is characterized by a relationship identifier for identifying the relationship, an identifier for indicating the starting node of the relationship, an identifier for indicating the target node of the relationship, and a relationship type for identifying the type of the relationship.
29. The apparatus according to claim 28, characterized in that, The relationship is also characterized by at least one of the following: The creator of the relationship, the creation date of the relationship, the modification date indicating the time when the relationship was last modified, or the modifier identifier indicating the modifier who modified the relationship.
30. The apparatus according to any one of claims 25 to 29, characterized in that, The device further includes: The calling module is used to invoke the common application programming interface (API) to: Create the first node to store the basic attributes of the data object; Create the at least one second node to store the at least one additional attribute one by one; For each of the at least one second node, a relationship is created between the first node and the second node.
31. The apparatus according to any one of claims 25 to 30, characterized in that, It also includes calling modules for: In response to a second node deletion request, a general API is invoked to delete the target second node among the at least one second node that has the node identifier indicated in the second node deletion request.
32. The apparatus according to any one of claims 25 to 31, characterized in that, It also includes calling modules for: In response to a first relationship deletion request, a general API is invoked to delete the relationship between the first node indicated in the first relationship deletion request and a target second node among the at least one second node, as well as the target second node.
33. The apparatus according to any one of claims 25 to 32, characterized in that, It also includes calling modules for: In response to a second relationship deletion request, a general API is invoked to delete the relationship between the first node and another first node as indicated in the second relationship deletion request.
34. The apparatus according to any one of claims 25 to 33, characterized in that, It also includes calling modules for: In response to a relationship edit request, a general API is invoked to update the relationship indicated in the relationship edit request.
35. The apparatus according to any one of claims 25 to 34, characterized in that, It also includes calling modules for: In response to a second node search request, a general API is invoked to return all second nodes among the at least one second node that are connected to the first node, wherein the second node search request indicates the node identifier of the first node.
36. The apparatus according to any one of claims 25 to 35, characterized in that, It also includes calling modules for: In response to the first relation search request, a general API is invoked to return information about the target second node in the at least one second node that is connected to the first node by the relation indicated in the first relation search request.
37. The apparatus according to any one of claims 25 to 36, characterized in that, It also includes calling modules for: In response to the second relation search request, the general API is invoked to return information about another first node connected to the first node through the relation indicated in the second relation search request.
38. The apparatus according to any one of claims 25 to 37, characterized in that, It also includes calling modules for: In response to an attribute search request, a general API is invoked to return information about the nodes in the first node and the at least one second node that store the attribute indicated in the attribute search request.
39. The apparatus according to any one of claims 25 to 38, characterized in that, It also includes calling modules for: In response to a node search request, a general API is invoked to return information about the node identified by the node identifier indicated in the node search request among the first node and the at least one second node.
40. The apparatus according to any one of claims 24 to 39, characterized in that, It also includes calling modules for: In response to an additional attribute addition request, a general API is invoked to create another second node to store the additional attribute indicated in the additional attribute addition request.
41. The apparatus according to any one of claims 24 to 40, characterized in that, The type of the first node is indicated by the object information and stored in the node type indicator associated with the first node.
42. The apparatus according to any one of claims 24 to 41, characterized in that, The basic attribute is the name of the data object, and the first node is also associated with a node name, which is used to indicate the name of the first node corresponding to the name of the data object.
43. The apparatus according to any one of claims 24 to 42, characterized in that, The first node is also associated with at least one of the following: The creator of the first node, the creation date of the first node, the update status of the first node, the source address of the object information, the modification date indicating the time when the information associated with the first node was last modified, or the modifier identifier indicating the modifier who last modified the information associated with the first node.
44. The apparatus according to any one of claims 24 to 43, characterized in that, It also includes calling modules for: In response to a type addition request, a general API is invoked to add the type to be added as indicated in the type addition request as an available type of the data structure.
45. The apparatus according to any one of claims 24 to 44, characterized in that, It also includes calling modules for: In response to a first node deletion request, a general API is invoked to delete the first node, wherein the first node deletion request indicates the node identifier of the first node.
46. The apparatus according to any one of claims 24 to 45, characterized in that, It also includes calling modules for: In response to a node edit request, a general API is invoked to update the node indicated by the node identifier in the node edit request with the attribute value indicated in the node edit request.
47. A computing device cluster, characterized in that, It includes a processing circuit for performing the method according to any one of claims 1 to 23.
48. A computer program product, characterized in that, Includes program code for performing the method according to any one of claims 1 to 23.
49. A computer-readable medium, characterized in that, The computer executes instructions, which, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 23.