Data model management method, apparatus and system, electronic device and storage medium

Abstract

Provided are a data model management method, apparatus and system, an electronic device, and a storage medium. The data model management method comprises: receiving a data access request from a first micro-service in a micro-service architecture; searching a first database for a data model indicated by a second identifier, and acquiring attribute information of the data model and an association relationship thereof; when a data operation indicated by data operation information needs to write data, on the basis of the attribute information of the data model and a first identifier, determining whether the first micro-service has ownership of the data model, if the first micro-service has the ownership of the data model, calling the data model and the association relationship thereof to execute the data operation to update a data record, and if the first micro-service does not have the ownership of the data model, refusing the data access request; and when the data operation indicated by the data operation information only needs to read the data, directly calling the data model and the association relationship thereof to execute the data operation to query the data record.

Description

Data model management method, device, system, electronic device and storage medium Technical Field

[0001] The present application relates to a data model management method, device, system, electronic device and storage medium. Background Art

[0002] Various application scenarios, such as factory manufacturing operations management, can be automated and intelligentized by deploying a microservices architecture. In the current microservices architecture, each microservice uses an independent database to manage its own data model, thereby ensuring the independence of each microservice through physical isolation.

[0003] However, due to the rapid iteration of business and the continuous updating of business needs, the data models in microservices are often changed at any time, resulting in inconsistent data for the same thing in different microservices, which in turn affects the establishment of effective data assets.

[0004] Therefore, it is necessary to provide a data model management solution suitable for microservice architecture.

[0005] Summary of the Invention

[0006] In view of this, the data model management method, device, system, electronic device and storage medium provided in this application can achieve data consistency between different microservices in a microservice architecture.

[0007] According to a first aspect of an embodiment of the present application, a data model management method is provided, the method comprising:

[0008] Receive a data access request from a first microservice in a microservice architecture, the data access request carrying a first identifier, a second identifier, data operation information, and data record information, wherein the first identifier is used to identify the first microservice, the second identifier is used to indicate a required data model, the data operation information is used to indicate a data operation to be performed, and the data record information is used to indicate a data record to be accessed;

[0009] Searching a first database for the data model indicated by the second identifier and obtaining attribute information and association relationships of the data model, wherein the first database is used to store data models of all microservices in the microservice architecture, attribute information of the data models, and association relationships between the data models;

[0010] When the data operation indicated by the data operation information requires writing data, determining whether the first microservice owns the data model based on the attribute information of the data model and the first identifier; if the first microservice owns the data model, invoking the data model and its associated relationships to perform the data operation to update the data record; and if the first microservice does not own the data model, rejecting the data access request;

[0011] When the data operation indicated by the data operation information only requires reading data, the data model and its associated relationship are directly called to perform the data operation to query the data record.

[0012] According to a second aspect of an embodiment of the present application, a data model management device is provided, including:

[0013] a receiving unit, configured to receive a data access request from a first microservice in a microservice architecture, the data access request carrying a first identifier, a second identifier, data operation information, and data record information, wherein the first identifier is used to identify the first microservice, the second identifier is used to indicate a required data model, the data operation information is used to indicate a data operation to be performed, and the data record information is used to indicate a data record to be accessed;

[0014] a query unit, configured to search a first database for the data model indicated by the second identifier and obtain attribute information and association relationships of the data model, wherein the first database is configured to store data models of all microservices in the microservice architecture, attribute information of the data models, and association relationships between the data models;

[0015] an ownership verification unit, configured to determine whether the first microservice owns the data model based on the attribute information of the data model and the first identifier;

[0016] an operation execution unit, configured to, when the data operation indicated by the data operation information requires writing data, invoke the data model and its associated relationships to perform the data operation to update the data record if the first microservice owns the data model; and to reject the data access request if the first microservice does not own the data model; and, when the data operation indicated by the data operation information requires only reading data, directly invoke the data model and its associated relationships to perform the data operation to query the data record.

[0017] According to a third aspect of an embodiment of the present application, there is provided a microservice system, comprising: two or more microservices, a first database, and the data model management device of the second aspect above;

[0018] A first database is used to store data models of all microservices in the microservice architecture, attribute information of the data models, and associations between data models;

[0019] The microservice is used to send a data access request to the data model management device.

[0020] According to the fourth aspect of the embodiment of the present application, an electronic device is provided, comprising: a processor, a memory, a communication interface and a bus, wherein the processor, the memory and the communication interface communicate with each other through the bus; the memory is used to store at least one executable instruction, and the executable instruction enables the processor to perform operations corresponding to the data model management method described in the first aspect above.

[0021] According to the fifth aspect of the embodiment of the present application, a computer-readable storage medium is provided, on which computer instructions are stored. When the computer instructions are executed by a processor, the processor executes the data model management method as described in the first aspect above.

[0022] According to the sixth aspect of an embodiment of the present application, a computer program product is provided, which is tangibly stored on a computer-readable medium and includes computer-executable instructions, which, when executed, enable at least one processor to execute the data model management method described in the first aspect above.

[0023] According to the above technical solution, after receiving a data access request, the attribute information of the data model is queried from the first database. If the data operation of the data access request involves writing data, the microservice is determined to have ownership of the data model based on the attribute information of the data model and the first identifier of the microservice before executing the data operation. If the data operation of the data access request only involves reading data, there is no need to judge the ownership relationship between the microservice and the data model and the data model is directly called to execute the data operation. As a result, only the microservice that owns the data model can call the data model to execute the update of the data record, while other microservices that do not have the data model can directly call the data model to query the data record. Thus, the read and write logic separation of the data model is achieved through the ownership relationship between the microservice and the data model, that is, the logical isolation between the microservices can not only ensure that each microservice is independent of each other and does not interfere with each other, but also ensure the security of the data and provide convenience for data query. In addition, by storing the data models of all microservices, the attribute information of the data models, and the association relationship between the data models in the first database, the unified management of the data model metadata in the microservice architecture can be achieved, thereby ensuring the consistency of the metadata before and after the data model update. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 is a schematic diagram of a microservice data model and its data records;

[0025] Figure 2 is a diagram of the data model of another microservice and its data records;

[0026] FIG3 is a schematic diagram of the data model shown in FIG1 after being modified;

[0027] FIG4 is a flow chart of a data model management method according to an embodiment of the present application;

[0028] FIG5 is a schematic diagram of a microservice architecture according to an embodiment of the present application;

[0029] FIG6 is a schematic diagram of a microservice architecture for factory manufacturing operations management according to an embodiment of the present application;

[0030] FIG7 is a schematic diagram of the data models and their relationships of all microservices in the microservice architecture for factory manufacturing operations management according to one embodiment of the present application;

[0031] FIG8 is a flowchart of an inventory management microservice updating a bill of materials record according to an embodiment of the present application;

[0032] FIG9 is a flowchart of an inventory management microservice updating a bill of materials record according to an embodiment of the present application;

[0033] FIG10 is a schematic diagram of a data model management device according to an embodiment of the present application;

[0034] FIG11 is a schematic diagram of a microservice system according to an embodiment of the present application;

[0035] FIG12 is a schematic diagram of an electronic device according to an embodiment of the present application.

[0036] List of reference numerals:

[0037] 401: Receives a data access request from the first microservice in the microservice architecture

[0038] 402: Search the first database for the data model indicated by the second identifier and obtain the attribute information and associated relationships of the data model.

[0039] 403: When the data operation indicated by the data operation information requires writing data, the first microservice is determined to have ownership of the data model based on the attribute information of the data model and the first identifier. If the first microservice has ownership of the data model, the data model and its associated relationships are called to perform the data operation to update the data record. If the first microservice does not have ownership of the data model, the data access request is rejected.

[0040] 404: When the data operation indicated by the data operation information only requires reading data, the data model and its associated relationships are directly called to perform the data operation to query the data record.

[0041] 801: The Inventory Management microservice sends a data access request to the Data Model Management Service to update the BOM record through the data access interface provided by the Data Model Management Service.

[0042] 802: After receiving the data access request, the data model management service queries the first database for the attribute information of the bill of materials model 021. Based on the attribute information of the bill of materials model and the first identifier carried in the data access request, it determines whether the inventory management microservice has ownership of the bill of materials model.

[0043] 803: If the Inventory Management microservice owns the BOM model, it calls the BOM model and its associated relationships to update the BOM record and returns a success message to the Inventory Management microservice through the data access interface.

[0044] 804: If the Inventory Management microservice does not own the BOM model, the data access request is rejected and a failure message is returned to the Inventory Management microservice through the data access interface.

[0045] 901: The system configuration personnel submits a configuration request for the inventory management microservice to the data model management service through the human-computer interaction interface provided by the data model management service. The data model management service receives the configuration request and assigns an access identity to the inventory management microservice.

[0046] 902: The data model management service queries the first database for data models and their relationships

[0047] 903: Add or modify the bill of materials model for the inventory management microservice

[0048] 904: Add the access identity of the inventory management microservice to the attribute information of the bill of materials model

[0049] 905: forming a new data model map in the first database

[0050] 101: Data Model of Microservice 1 201: Data Model of Microservice 2 400: Data Model Management Method

[0051] 500: Microservice Architecture 501: Microservices 502: Data Model Management Service

[0052] 5021: Data access interface of data model management service 5022: Human-computer interaction interface of data model management service

[0053] 503: First Database 600: Microservice Architecture for Factory Manufacturing Operations Management

[0054] 601: Production Planning Management Microservice 602: Quality Control Management Microservice 603: Inventory Management Microservice

[0055] 604: Energy Management Microservice 605: Equipment Management Microservice 606: Production Data Analysis Microservice

[0056] 607: Data Model Management Service 608: First Database

[0057] 701: The device management microservice has an ownership data model and its associated relationships

[0058] 702: The inventory management microservice has a data model with ownership and its associated relationships

[0059] 1000: Data model management device 1001: Receiving unit 1002: Query unit

[0060] 1003: Ownership verification unit 1004: Operation execution unit 1100: Microservice system

[0061] 1101: Microservice 1102: First database 1200: Electronic device

[0062] 1202: Processor 1204: Communication interface 1206: Memory

[0063] 1208: Bus 1210: Program DETAILED DESCRIPTION

[0064] As mentioned earlier, in current microservice architectures, each microservice uses a separate database to manage its own data model, ensuring the independence of each microservice through physical isolation. However, due to rapid business iterations and evolving business requirements, the data models within microservices are often subject to change. This leads to inconsistent data for the same object across different microservices, hindering the establishment of effective data assets.

[0065] Figure 1 shows an example diagram of data model 101 in microservice 1, and Figure 2 shows an example diagram of data model 201 in microservice 2. In the initial stages of building the microservice architecture, the field definitions and attributes in the data models for the person "Li Jiao" in microservice 1 and microservice 2 are consistent. Therefore, the data for the person "Li Jiao" generated by microservice 1 using data model A is consistent with the data record for object O generated by microservice 2 using data model B.

[0066] However, due to changes in business requirements, the data model 101 in microservice 1 was changed to the form shown in Figure 3. The "Name" in data model 101 adopted the English standard, that is, the first name first and the last name last. After that, the data record of the person "Li Jiao" generated using data model A in microservice 1 and the data record of the person "Li Jiao" generated using data model 201 in microservice 2 had obvious deviations.

[0067] Obviously, arbitrary changes to the data model within a microservice will lead to significant inconsistencies in the data generated by different microservices for the same transaction. It should be noted that the examples in Figures 1 to 3 above are merely intended to clearly illustrate the data inconsistency issues caused by data model updates. However, in the field of intelligent manufacturing, data models are complex and diverse, and data sources are vast and complex. Changes to data models and the resulting data inconsistencies will have a greater impact on the cleanliness and effectiveness of data assets in this field.

[0068] In an embodiment of the present application, after receiving a data access request, the attribute information of the data model is queried from the first database. If the data operation of the data access request involves writing data, the data operation is performed after the microservice has ownership of the data model based on the attribute information of the data model and the first identifier of the microservice. If the data operation of the data access request only involves reading data, there is no need to judge the ownership relationship between the microservice and the data model and the data model is directly called to perform the data operation. Only the microservice that owns the data model can call the data model to perform the update of the data record, while other microservices that do not have the data model can directly call the data model to query the data record. Then, the read and write logic separation of the data model is realized through the ownership relationship between the microservice and the data model. The read and write logic separation can not only ensure that each microservice is independent of each other and does not interfere with each other, but also ensure the security of the data, while providing convenience for data query. It can be seen that the embodiment of the present application can ensure the independence of microservices and realize the unified management of data models through logical isolation, and realize the data consistency between different microservices in the microservice architecture.

[0069] The data model management method, device, system, electronic device and storage medium provided in the embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0070] Data model management methods

[0071] FIG4 is a flow chart of a data model management method according to an embodiment of the present application. As shown in FIG4 , the data model management method 400 may include the following steps:

[0072] Step 401: Receive a data access request from a first microservice in a microservice architecture, where the data access request carries a first identifier, a second identifier, data operation information, and data record information.

[0073] In the embodiment of the present application, the first microservice refers to any microservice in the microservice architecture.

[0074] The first identifier may indicate the first microservice. The first identifier may be used to uniquely identify the first microservice and indicate the first microservice's ownership of the data model, or may be used solely to indicate the first microservice's ownership of the data model. In one example, the first identifier may be an access identity (Client ID) assigned to the first microservice by the data service management service.

[0075] The second identifier may indicate the required data model. That is, the second identifier may include identification information of all data models required for the current data access request. Each data access request may need to call one or more data models. If the current data access request needs to call multiple data models, the second identifier may include identification information of the multiple data models. If the current data access request only needs to call one data model, the second identifier may only include identification information of the data model. In one example, the identification information of the data model may be, but is not limited to, the name of the data model, the name of the entity corresponding to the data model, the ID of the data model, or other information that can uniquely identify a data model.

[0076] Data operation information is used to indicate the data operation to be performed. In one example, the data operation information can be represented as the name, code, or identifier of the data operation. For example, if the data operation is "add", the data operation information can be represented as "Add". For another example, if the data operation is "modify", the data operation information can be represented as "Modify". For another example, if the data operation is "delete", the data operation information can be represented as "Delete". For another example, if the data operation is "query", the data operation information can be represented as "Query".

[0077] The data record information is used to indicate the data record to be accessed. In one example, the data record information can be represented by the name, number, or identifier of the data record. For example, if the data record is a personal information record of a production staff member, the corresponding data record information can be represented as "production staff information."

[0078] In one possible implementation, a data access request may also include a key. The data model management service verifies the key in the data access request and determines that the data access request is valid before querying the data model and its related information. This inclusion of a key further enhances data access security. Details such as the encryption method for the key are not limited in this embodiment of the application.

[0079] Step 402: Search the first database for the data model indicated by the second identifier and obtain attribute information and association relationships of the data model.

[0080] Step 403: When the data operation indicated by the data operation information requires writing data, determine whether the first microservice owns the data model based on the attribute information of the data model and the first identifier. If the first microservice owns the data model, call the data model and its associated relationships to perform the data operation to update the data record. If the first microservice does not own the data model, reject the data access request.

[0081] If the data operation indicated by the data operation information belongs to one of the following, it is confirmed that the data operation requires writing data: adding a new data record, modifying a data record, or deleting a data record.

[0082] There are various ways to determine whether the first microservice owns the data model based on the data model's attribute information and the first identifier. In one example, the first identifier can be searched for in the data model's attribute information. If the first identifier is found in the data model's attribute information, it is determined that the first microservice owns the data model. If the first identifier is not found in the data model's attribute information, it is determined that the first microservice does not own the data model.

[0083] After rejecting the data access request, a failure message can be returned to the first microservice. This failure message can include a permission-less prompt, indicating that the first microservice does not own the data model. This allows business personnel to understand the reason for the data access failure, making it easier for them to adjust the microservice's ownership of the data model based on business needs.

[0084] In one example, the permission-less notification message can include identification information for data models that the first microservice does not own. If the current data access requires multiple data models, and the first microservice does not own some or all of these data models, the permission-less notification message can include the identification information of these data models. This allows business personnel to clearly understand the reason for the data access failure and adjust the first microservice's ownership of these data models based on business needs and the identification information of the data models included in the permission-less notification message.

[0085] After executing the data operation, a success message can also be returned to the first microservice so that business personnel can learn the execution status of the data access request through the success message.

[0086] Step 404: When the data operation indicated by the data operation information only requires reading data, the data model and its associated relationships are directly called to perform the data operation to query the data records.

[0087] In a possible implementation, if the data operation indicated by the data operation information belongs to a "query operation", it is confirmed that the data operation only requires reading data.

[0088] After directly calling the data model and its associated relationships to perform data operations, a success message can also be returned to the first microservice so that business personnel can learn about the execution status of the data access request through the success message.

[0089] The data model management method of the embodiment of the present application, after receiving a data access request, queries the attribute information of the data model from the first database. If the data operation of the data access request involves writing data, the data operation is performed after determining that the microservice has ownership of the data model based on the attribute information of the data model and the first identifier of the microservice. If the data operation of the data access request only involves reading data, there is no need to judge the ownership relationship between the microservice and the data model and the data model can be directly called to perform the data operation. Only the microservice that owns the data model can call the data model to execute the update of data records, while other microservices that do not have the data model can directly call the data model to query data records. Therefore, the read and write logic separation of the data model is realized through the ownership relationship between the microservice and the data model. The read and write logic separation can not only ensure that each microservice is independent of each other and does not interfere with each other, but also ensure the security of the data, while providing convenience for data query.

[0090] In addition, the data model management method of the embodiment of the present application uses a first database to store the data models of all microservices, the attribute information of the data models, and the association relationships between the data models, rather than each microservice storing its data model and its related data separately. This facilitates the unified management of data model metadata in the microservice architecture and can achieve metadata consistency before and after data model updates.

[0091] The microservice architecture can be constructed based on business needs. Figure 5 shows a schematic diagram of the structure of the microservice architecture 500 of an embodiment of the present application. Referring to Figure 5, a single microservice architecture 500 may include two or two microservices 501, a data model management service 502 and a first database 503. Each microservice 501 can be used to implement the function of a certain aspect or a certain project in the business. Different microservices 501 are independent of each other and do not interfere with each other. The data model management service 502 can be used to implement the management of the data model in the microservice architecture 500. The first database 503 can be used to store the data models of all microservices 501 in the data microservice architecture 500, the attribute information of the data model, and the relationship between the data models. Thus, the comprehensive intelligent management of the business of smart manufacturing entities such as factories can be achieved through the microservice architecture 500.

[0092] The data model of a microservices architecture can be created based on business requirements. The data model's data specifications, data types, and data structures can all be defined at creation time. Microservices can invoke one or more data models to process corresponding data types in the source data, generating data records that conform to the corresponding data specifications and are represented in the corresponding data structures.

[0093] In one possible implementation, referring to FIG5 , the data model management service 502 may provide a data access interface 5021, which is used to implement communication between the data model management service 502 and each microservice 501. Thus, the microservice 501 may send a data access request to the data model management service 502 via the data access interface 5021, and the data model management service 502 may return a success message or a failure message carrying an indication of lack of permission to the microservice via the data access interface 5021.

[0094] In one possible implementation, the data model management service 502 can provide a data access interface 5021 to facilitate communication between itself and different microservices 501. In addition, after the data model is updated, the data model management service 502 can also publish notification messages to all microservices through the data access interface 5021, so that each microservice is informed of the data model update status and the latest version number and other information.

[0095] In one possible implementation, referring to FIG5 , the data model management service 502 may also be used to provide a human-computer interaction interface 5022, which may be used to implement human-computer interaction operations related to data model management. For example, a developer or business person may submit a data model update request to the data model management service 502 through the human-computer interaction interface 5022 to modify an existing data model or add a new data model. For another example, a developer may submit a data model ownership change request to the data model management service 502 through the human-computer interaction interface 5022 to update the microservice's ownership of the data model. In one example, the human-computer interaction interface 5022 may be, but is not limited to, an application programming interface (API).

[0096] The data models of all microservices can be uniformly stored in the first database 503 to achieve unified management of the data models. Storing all data models and their related information in the same database not only makes it easier to achieve data consistency between different microservices, but also supports unified management of microservice architecture metadata, facilitating metadata consistency.

[0097] The first database 503 can store data models themselves, their attribute information, and the relationships between data models. Data model attribute information may include, but is not limited to, the data model's name, its version number, and the first identifier of the microservice that owns the data model. Additionally, data model attribute information may include information such as the data model's description, definition, size, type, and application scenario. The data model name can be the same as or related to the entity name to which it corresponds.

[0098] The first database 503 may serve as an external database of the data model management service 502 , or may be set in the data model management service 502 , or the data model management service 502 may be set on the first database 503 .

[0099] The first database 503 can be any type of database. In one example, the first database can be a graph database. A graph database can store data models, their attribute information, and the relationships between data models in the form of data model views, facilitating quick search of data models. It can also facilitate developers and users to preview data models and their relationships, enabling information sharing and reducing human communication costs.

[0100] It is understandable that the first database may also adopt any other applicable database type, and the embodiment of the present application does not limit the specific type of the first database and its storage method.

[0101] For example, the microservice architecture 500 of the embodiment of the present application can be implemented by a software system, the various microservices 501 in the microservice architecture 500 can be implemented as independent subsystems of the software system, and the data model management service 502 can be implemented as the main system of the software system. The data model management method of the embodiment of the present application can be executed by the data model management service 502 in the microservice architecture 500, and the various microservices 501 in the microservice architecture 500 can communicate with the data model management service 502 through the data access interface 5021 provided by the data model management service 502. The user can adjust the data model in the first database 503 and the ownership of the data model by the microservice through the human-computer interaction interface 5022 provided by the data model management service 502.

[0102] A microservice's ownership of a data model means that the microservice has the right to call the data model to update data records. If a microservice owns a data model, the microservice has the right to call the data model from the first database to perform an update operation on the data records corresponding to the data model. If a microservice does not own a data model, the microservice can only call the data model to query the corresponding data records and does not have the right to perform an update operation on these data records. In one example, a data record update operation refers to an operation involving writing data. For example, a data record update operation can include, but is not limited to, adding a new data record, modifying a data record, and / or deleting a data record.

[0103] Ownership of each data model can be assigned to one or more microservices, and each microservice can own one or more data models. If a data model is shared across a microservices architecture, multiple microservices in the architecture will own it. If a data model is unique to a microservice in the architecture, only that microservice will own it.

[0104] Microservices can manage data model ownership using various applicable methods. In one possible implementation, taking a first microservice as an example, a first identifier can be assigned to the first microservice. This identifier is then written into the attribute information of a specified data model in a first database, granting the first microservice ownership of the specified data model. This configuration of data model ownership is accomplished by writing the microservice's first identifier into the data model's attribute information, making it easy to implement, efficient, and convenient.

[0105] In one example, an encoding rule for the first identifier may be configured in a data service management service, and the first identifier may be generated and allocated for the first microservice during the process of building a microservice architecture.

[0106] A microservice's ownership of a data model can be changed. For example, business personnel can initiate a data model ownership change request to the data model management service through the human-computer interaction interface provided by the data model management service, ensuring that the ownership relationship between the microservice and the data model meets current business needs. Developers can also initiate a data model ownership change request to the data model management service through the human-computer interaction interface provided by the data model management service, allowing ownership of the data model to be transferred between different microservices, revoking ownership of a specific data model from some microservices, or opening ownership of a specific data model to certain microservices, thereby meeting development needs or the requirements of data asset owners.

[0107] The ownership of the data model by the microservice can be changed in various applicable ways. In one possible implementation, a data model ownership change request is received, and the data model ownership change request can carry the identification information of the data model, the first identification of the microservice, and the change operation information, and the change operation information indicates the change operation that needs to be performed. The data model is found from the first database based on the identification information of the data model, and the first identification of the microservice is used to perform a change operation on the attribute information of the data model. In one example, the change operation of the attribute information of the data model can be, but is not limited to: deleting the first identification of the microservice from the attribute information of the data model, and adding the first identification of the microservice to the attribute information of the data model. Thus, by deleting the first identification in the attribute information of the data model or adding the first identification of the microservice to the attribute information of the data model, the change of the ownership of the data model by the microservice can be achieved, which is simple, efficient, and easy to implement.

[0108] Data models can be modified. For example, business personnel can initiate data model update requests to the data model management service through the human-computer interaction interface provided by the data model management service to ensure that the data model meets current business needs. For example, developers can initiate data model update requests through the human-computer interaction interface provided by the data model management service to modify the data model to meet development needs or the specific requirements of the data asset owner.

[0109] Updates to the data model may include, but are not limited to, changes to the data specifications, data types, and / or data structures within the data model, additions to the data model, and / or deletions from the data model. In one example, if the data structure of the data model needs to be modified, this can be achieved by providing field information of the data model. It should be noted that the data specifications in the embodiments of this application refer to data specifications defined in standard protocols in the field of intelligent manufacturing.

[0110] In one possible implementation, a data model update request may carry identification information of the data model, information to be changed, and change operation information. Upon receiving the data model change request, the data model management service may search for the data model in the first database based on the identification information of the data model, and perform the change operation indicated by the change operation information on the corresponding information of the data model according to the information to be changed, thereby completing the change of the data model. In one example, the change operation of the data model may include, but is not limited to: modifying data specifications, adjusting data types, and changing fields in a data structure. The information to be changed of the data model may include, but is not limited to: information on the modified data specification, information on data types to be added, information on data types to be deleted, information on data types to be modified, information on fields to be modified in the data structure, information on fields to be deleted in the data structure, information on fields to be added in the data structure, and information on fields to be added in the data structure.

[0111] After the data model is updated, the data model version number can be updated based on pre-configured version rules so that microservices can call the required data model by version number. For example, version rules can be pre-configured in the data model management service, and a new version number can be generated for the data model based on these version rules after the data model is updated. In one example, after performing the change operation indicated by the change operation information on the corresponding information of the data model according to the information to be changed, a new version number of the data model can be generated based on the pre-configured version rules and written into the data model's attribute information.

[0112] In one possible implementation, after the data model and its version number are updated, the data model and its version number before the update may be retained in the first database so that each microservice can call a different version of the data model as needed.

[0113] After updating the data model and its version number, the data model management service can use a notification mechanism to notify each microservice. In one example, after generating a new version number for the data model, a data model update event can be published to each microservice in the current microservice architecture. This data model update event can carry the new version number of the data model, so that each microservice can be aware of the data model update and its new version number, and can use the new version number to call the updated data model.

[0114] The following uses the manufacturing operations management of a factory as an example to explain microservice architecture and microservices.

[0115] FIG6 shows a schematic structural diagram of a microservice architecture 600 for factory manufacturing operation management. 6 , the microservice architecture 600 responsible for factory manufacturing operation management may include: a production planning management microservice 601, a quality control management microservice 602, an inventory management microservice 603, an energy management microservice 604, an equipment management microservice 605, a production data analysis microservice 606, a data model management service 607 responsible for managing the data models of the above microservices, and a first database 608. The first database 608 is set in the data model management service 607. The production planning management microservice 601, the quality control management microservice 602, the inventory management microservice 603, the factory energy management microservice 604, the equipment management microservice 605, and the production data analysis microservice 606 can communicate with the data model management service 607 through the data access interface provided by the data model management service 607.

[0116] Through the data model management service 607, access identifiers are assigned to the production planning management microservice 601, the quality control management microservice 602, the inventory management microservice 603, the energy management microservice 604, the equipment management microservice 605, and the production data analysis microservice 606, and the data model is configured. Then, the access identity of the microservice that owns the data model is set to configure the ownership relationship of each microservice to its data model.

[0117] Figure 7 is a schematic diagram illustrating the data models and relationships of all microservices in the microservice architecture 600 for factory manufacturing operations management. In Figure 7 , circles represent data models or their corresponding entities, and the lines connecting the circles represent the relationships between the data models. The data model enclosed by the dashed box 701 is owned by the equipment management microservice 605, while the data model enclosed by the dashed box 702 is owned by the inventory management microservice 603.

[0118] In an example, see Figure 7, the inventory management microservice can process the material-related data in the factory's source data by calling the material classification model 023, the bill of materials model 021, the material outbound list model 027, and the material inbound list model 026 to generate material classification records, bill of materials records, material outbound list records, and material inbound list records, and display these records in the form of corresponding knowledge graphs. The nodes in the knowledge graph represent the entities corresponding to the data model, and the lines between the nodes in the knowledge graph represent the association relationship between data records.

[0119] In one example, the inventory management microservice 603 in the microservice architecture 600 shown in FIG6 can update the bill of materials record through the process of FIG8. Referring to FIG8, the process 800 of the inventory management microservice updating the bill of materials record may include the following steps:

[0120] Step 801: The inventory management microservice sends a data access request for updating the bill of materials record to the data model management service through the data access interface provided by the data model management service.

[0121] Step 802: After receiving the data access request, the data model management service queries the first database for attribute information of the bill of materials model and determines whether the inventory management microservice owns the bill of materials model based on the attribute information of the bill of materials model and the first identifier carried in the data access request.

[0122] Step 803: If the inventory management microservice owns the bill of materials model, the bill of materials model and its associated relationships are called to update the bill of materials record, and a success message is returned to the inventory management microservice through the data access interface.

[0123] Step 804: If the inventory management microservice does not own the bill of materials model, the data access request is rejected and a failure message is returned to the inventory management microservice through the data access interface.

[0124] The failure message may carry unauthorized information, which may indicate that the inventory management microservice does not own the bill of materials model. The unauthorized information may include identification information such as the name of the bill of materials model, so that the inventory management microservice can request ownership based on the identification information such as the name of the bill of materials model when necessary.

[0125] In one example, the ownership configuration of the inventory management microservice to the bill of materials model 021 in the microservice architecture 600 shown in FIG6 can be implemented through the process of FIG9. Referring to FIG9, the process 900 of the inventory management microservice updating the bill of materials record may include the following steps:

[0126] Step 901: The system configuration personnel submits a configuration request for the inventory management microservice to the data model management service through the human-computer interaction interface provided by the data model management service. The data model management service receives the configuration request and assigns an access identity (ClientID) to the inventory management microservice.

[0127] Step 902: The data model management service queries the first database for data models and their relationships.

[0128] Step 903: Add or modify the bill of materials model for the inventory management microservice;

[0129] Step 904: Add the access identity of the inventory management microservice to the attribute information of the bill of materials model;

[0130] Step 905: A new data model map is formed in the first database so that system configuration personnel can preview all the data models and their relationships in the updated first database.

[0131] It should be noted that FIG. 6 to FIG. 9 are merely exemplary implementations of the embodiments of the present application and are not intended to limit the scope of the embodiments of the present application.

[0132] Data model management device

[0133] Corresponding to the above method embodiment, FIG10 shows a schematic diagram of a data model management device 1000 according to an embodiment of the present application. As shown in FIG10 , the data model management device 1000 includes:

[0134] Receiving unit 1001 is configured to receive a data access request from a first microservice in a microservice architecture, the data access request carrying a first identifier, a second identifier, data operation information, and data record information, wherein the first identifier is used to identify the first microservice, the second identifier is used to indicate a required data model, the data operation information is used to indicate a data operation to be performed, and the data record information is used to indicate a data record to be accessed;

[0135] A query unit 1002 is configured to search a first database for a data model indicated by a second identifier and obtain attribute information of the data model and its associations. The first database is configured to store data models of all microservices in the microservice architecture, attribute information of the data models, and associations between the data models.

[0136] The ownership verification unit 1003 is used to determine whether the first microservice has ownership of the data model based on the attribute information of the data model and the first identifier;

[0137] Operation execution unit 1004 is configured to, when the data operation indicated by the data operation information requires writing data, invoke the data model and its associated relationships to perform the data operation to update the data record if the first microservice owns the data model; and to reject the data access request if the first microservice does not own the data model; and, when the data operation indicated by the data operation information requires only reading data, directly invoke the data model and its associated relationships to perform the data operation to query the data record.

[0138] In an embodiment of the present application, the receiving unit 1001 can be used to execute step 401 in the aforementioned method embodiment, the query unit 1002 can be used to execute step 402 in the aforementioned method embodiment, and the ownership verification unit 1003 and the operation execution unit 1004 can be used to execute steps 403 and 404 in the aforementioned method embodiment.

[0139] It should be noted that the information interaction, execution process, etc. between the various units in the above-mentioned data model management device are based on the same concept as the above-mentioned data model management method embodiment. The specific content can be found in the description of the above-mentioned method embodiment and will not be repeated here.

[0140] Microservice system

[0141] Figure 11 shows a schematic diagram of a microservice system 1100 according to one embodiment of the present application. As shown in Figure 11, microservice system 1100 includes two or more microservices 1001, a first database 1002, and the data model management device 1000 according to the above-described embodiment. First database 1102 is used to store the data models, attribute information, and relationships between data models for all microservices in the microservice architecture. Microservice 1101 is used to send data access requests to data model management device 1000.

[0142] In one example, the microservice 1101 may send a data access request to the data model management apparatus 1000 in response to an operation by a business person. The operation by the business person may be implemented through a human-computer interaction interface provided by the microservice 1101.

[0143] In an example, microservice 1001 can be microservice 501 in the microservice architecture shown in Figure 5, the first database 1002 can be the first database 503 in the microservice architecture shown in Figure 5, and the data model management device 1000 can be the data model management service in the microservice architecture shown in Figure 5.

[0144] It should be noted that the above-mentioned microservice system is based on the same concept as the above-mentioned data model management method and device embodiments. The specific content can be found in the description of the above-mentioned method and device embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0145] electronic devices

[0146] FIG12 is a schematic diagram of an electronic device provided in Example 4 of the present application. The specific embodiments of the present application do not limit the specific implementation of the electronic device. Referring to FIG12 , the electronic device 1200 provided in the embodiment of the present application includes: a processor 1202, a communications interface 1204, a memory 1206, and a bus 1208. Among them:

[0147] The processor 1202 , the communication interface 1204 , and the memory 1206 communicate with each other via a bus 1208 .

[0148] The communication interface 1204 is used to communicate with other electronic devices or servers.

[0149] The processor 1202 is used to execute the program 1210, and specifically can execute the relevant steps in the above-mentioned data model management method embodiment.

[0150] Specifically, the program 1210 may include program codes, which include computer operation instructions.

[0151] Processor 1202 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application. The one or more processors included in the smart device may be processors of the same type, such as one or more CPUs, or may be processors of different types, such as one or more CPUs and one or more ASICs.

[0152] The memory 1206 is used to store the program 1210. The memory 1206 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.

[0153] The program 1210 can be specifically used to enable the processor 1202 to execute the data model management method in any of the aforementioned embodiments.

[0154] The specific implementation of each step in program 1210 can be found in the corresponding descriptions of the corresponding steps and units in the above-mentioned data model management method embodiment, and will not be repeated here. Those skilled in the art will clearly understand that for the convenience and brevity of description, the specific working processes of the above-described devices and modules can refer to the corresponding process descriptions in the above-mentioned method embodiment, and will not be repeated here.

[0155] The electronic device of this embodiment, after receiving a data access request, queries the attribute information of the data model from the first database. If the data operation of the data access request involves writing data, the data operation is performed after determining that the microservice has ownership of the data model based on the attribute information of the data model and the first identifier of the microservice. If the data operation of the data access request only involves reading data, there is no need to determine the ownership relationship between the microservice and the data model and the data model is directly called to perform the data operation. Only the microservice that owns the data model can call the data model to perform data record updates, while other microservices that do not own the data model can directly call the data model to query data records. Thus, the read and write logic separation of the data model is achieved through the ownership relationship between the microservice and the data model. The read and write logic separation not only ensures that each microservice is independent of each other and does not interfere with each other, but also ensures data security and provides convenience for data query. In addition, by using the first database to store the data models of all microservices, the attribute information of the data models, and the association relationship between the data models, unified management of data model metadata in the microservice architecture can be achieved, thereby ensuring metadata consistency before and after the data model is updated.

[0156] Computer-readable storage medium

[0157] The present application also provides a computer-readable storage medium storing instructions for causing a machine to execute the data model management method as described herein. Specifically, a system or device equipped with a storage medium can be provided, on which software program code implementing the functions of any of the above-described embodiments is stored, and a computer (or CPU or MPU) of the system or device can be caused to read and execute the program code stored in the storage medium.

[0158] In this case, the program code read from the storage medium itself can realize the function of any one of the above embodiments, so the program code and the storage medium storing the program code constitute part of this application.

[0159] Examples of storage media for providing program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, the program code can be downloaded from a server computer via a communication network.

[0160] In addition, it should be clear that the functions of any of the above embodiments can be achieved not only by executing the program code read by the computer, but also by enabling the operating system operating on the computer to complete part or all of the actual operations based on the instructions of the program code.

[0161] In addition, it can be understood that the program code read from the storage medium is written into a memory provided in an expansion board inserted into the computer or into a memory provided in an expansion module connected to the computer, and then based on the instructions of the program code, a CPU installed on the expansion board or expansion module is enabled to perform part or all of the actual operations, thereby realizing the functions of any of the above embodiments.

[0162] Computer program product

[0163] The present application also provides a computer program product tangibly stored on a computer-readable medium and comprising computer-executable instructions. When executed, the computer-executable instructions cause at least one processor to perform the data model management methods provided in the aforementioned embodiments. It should be understood that each solution in this embodiment has the corresponding technical effects of the aforementioned method embodiments and will not be further elaborated here.

[0164] It should be noted that not all steps and modules in the above-mentioned processes and device structure diagrams are required, and certain steps or modules can be omitted according to actual needs. The execution order of each step is not fixed and can be adjusted as needed. The system structure described in the above-mentioned embodiments can be a physical structure or a logical structure, that is, some modules may be implemented by the same physical entity, or some modules may be implemented by multiple physical entities, or may be implemented by certain components in multiple independent devices.

[0165] Nouns and pronouns referring to persons in this patent application are not limited to a specific gender.

[0166] In the above embodiments, the hardware module can be implemented mechanically or electrically. For example, a hardware module can include a permanent dedicated circuit or logic (such as a dedicated processor, FPGA or ASIC) to complete the corresponding operation. The hardware module can also include programmable logic or circuits (such as a general-purpose processor or other programmable processors), which can be temporarily set by software to complete the corresponding operation. The specific implementation method (mechanical method, or dedicated permanent circuit, or temporarily set circuit) can be determined based on cost and time considerations.

[0167] The present application has been presented and described in detail above through the accompanying drawings and preferred embodiments. However, the present application is not limited to these disclosed embodiments. Based on the above multiple embodiments, those skilled in the art can know that the code review methods in the above different embodiments can be combined to obtain more embodiments of the present application, and these embodiments are also within the scope of protection of the present application.

Claims

1. A data model management method (400), the method comprising: Receive a data access request from a first microservice in a microservice architecture, the data access request carrying a first identifier, a second identifier, data operation information, and data record information, the first identifier being used to indicate the first microservice, the second identifier being used to indicate a required data model, the data operation information being used to indicate a data operation to be performed, and the data record information being used to indicate a data record to be accessed; Searching a first database for a data model indicated by the second identifier and obtaining attribute information and association relationships of the data model, wherein the first database is used to store data models of all microservices in the microservice architecture, attribute information of the data models, and association relationships between the data models; When the data operation indicated by the data operation information requires writing data, determining whether the first microservice has ownership of the data model according to the attribute information of the data model and the first identifier, if the first microservice has ownership of the data model, calling the data model and its associated relationship to perform the data operation to update the data record, and if the first microservice does not have ownership of the data model, rejecting the data access request; When the data operation indicated by the data operation information only requires reading data, the data model and its associated relationship are directly called to perform the data operation to query the data record.

2. The method according to claim 1, further comprising: After rejecting the data access request, a failure message is returned to the first microservice, where the failure message carries no-authorization prompt information, and the no-authorization prompt information is used to indicate that the first microservice does not have ownership of the data model.

3. The method according to claim 2, wherein: The unauthorized prompt information includes identification information of a data model that the first microservice does not own.

4. The method according to claim 1 or 2, further comprising: A data access interface is provided, wherein the data access interface is used to communicate with each microservice in the microservice architecture to receive data access requests from each microservice.

5. The method according to claim 1, wherein: The first database is a graph database.

6. The method according to claim 1, wherein: The determining, according to the attribute information of the data model and the first identifier, whether the first microservice has ownership of the data model includes: searching the first identifier in the attribute information of the data model; and, If the first identifier can be found in the attribute information of the data model, it is determined that the first microservice has ownership of the data model; If the first identifier cannot be found in the attribute information of the data model, it is determined that the first microservice does not have ownership of the data model.

7. The method according to claim 1, before receiving a data access request from a first microservice in a microservice architecture, the method further comprises: Allocating the first identifier to the first microservice; as well as, The first identifier is written into the attribute information of the specified data model in the first database, so that the first microservice has ownership of the specified data model.

8. The method according to claim 1, further comprising: Receive a data model ownership change request, the data model ownership change request carrying identification information of the data model, a first identification of the microservice, and change operation information, the change operation information indicating a change operation to be performed; The data model is found from the first database according to the identification information of the data model, and a change operation is performed on the attribute information of the data model based on the first identification of the microservice.

9. The method according to claim 1, further comprising: Receive a data model update request, the data model update request carrying identification information of the data model, information to be changed, and change operation information, the change operation information being used to indicate a change operation to be performed on the data model; The data model is found in the first database according to the identification information of the data model, and the change operation indicated by the change operation information is performed on the corresponding information of the data model according to the information to be changed.

10. The method according to claim 8 or 9, further comprising: A human-computer interaction interface is provided, wherein the human-computer interaction interface is used to receive the data model ownership change request and / or the data model update request.

11. The method according to claim 9, further comprising: After performing the change operation indicated by the change operation information on the corresponding information of the data model according to the information to be changed, a new version number of the data model is generated based on a pre-configured version rule and written into the attribute information of the data model.

12. The method according to claim 11, further comprising: After the new version number of the data model is generated, a data model update event is published to each microservice in the current microservice architecture. The data model update event carries the new version number of the data model so that each microservice can call the updated data model according to the new version number.

13. A data model management device (1000), comprising: A receiving unit (1001) is used to receive a data access request from a first microservice in a microservice architecture, wherein the data access request carries a first identifier, a second identifier, data operation information, and data record information, wherein the first identifier is used to indicate the first microservice, the second identifier is used to indicate a required data model, the data operation information is used to indicate a data operation to be performed, and the data record information is used to indicate a data record to be accessed; A query unit (1002) is used to search a first database for a data model indicated by the second identifier and obtain attribute information of the data model and an association relationship thereof, wherein the first database is used to store data models of all microservices in the microservice architecture, attribute information of the data models, and association relationships between the data models; An ownership verification unit (1003), configured to determine whether the first microservice has ownership of the data model according to the attribute information of the data model and the first identifier; an operation execution unit (1004), configured to, when the data operation indicated by the data operation information requires writing data, call the data model and its associated relationship to execute the data operation to update the data record if the first microservice has ownership of the data model, and reject the data access request if the first microservice does not have ownership of the data model; And, when the data operation indicated by the data operation information only needs to read data, directly calling the data model and its associated relationship to perform the data operation to query the data record.

14. A microservice system (1100), comprising: Two or more microservices (1101), a first database (1102), and a data model management device (1000) according to claim 13; A first database (1102), used to store data models of all microservices in the microservice architecture, attribute information of the data models, and associations between the data models; The microservice (1101) is used to send a data access request to the data model management device (1000).

15. An electronic device (1200), comprising: A processor (1202), a communication interface (1204), a memory (1206) and a bus (1208), wherein the processor (1202), the communication interface (1204) and the memory (1206) communicate with each other via the bus (1208); The memory (1206) is used to store at least one executable instruction, wherein the executable instruction enables the processor (1202) Execute operations corresponding to the method as described in any one of claims 1 to 12.

16. A computer-readable storage medium having computer instructions stored thereon, wherein when the computer instructions are executed by a processor, the processor is caused to execute the method according to any one of claims 1 to 12.

17. A computer program product tangibly stored on a computer readable medium and comprising computer executable instructions which, when executed, cause at least one processor to perform the method according to any one of claims 1-12.

Images