CN117453980A

CN117453980A - Metadata management, configuration page generation method, server and storage medium

Info

Publication number: CN117453980A
Application number: CN202311335130.6A
Authority: CN
Inventors: 燕为; 罗东富; 田梦垚; 何旭; 潘亚良; 司丰源; 陆建浩; 史梦兰
Original assignee: Hangzhou Shuopan Intelligent Technology Co ltd
Current assignee: Hangzhou Shuopan Intelligent Technology Co ltd
Priority date: 2023-10-13
Filing date: 2023-10-13
Publication date: 2024-01-26

Abstract

The embodiment of the application provides a metadata management and configuration page generation method, a server and a storage medium, wherein metadata consists of logic entities, and the metadata management method comprises the following steps: establishing service objects, wherein one service object corresponds to one service function point of an enterprise; constructing a plurality of logic entities of the service object, wherein the plurality of logic entities are mounted under the service object and are used for realizing service function points corresponding to the service object; and constructing logic model information of the logic entity and logic entity attributes, wherein the logic entity attributes comprise description information corresponding to the logic entity realization service function points. The embodiment of the application can enable the logic entity to be classified by the business function points of the enterprise, enable the purpose of the logic entity to be clear, optimize the management of the logic entity, realize the management of optimized metadata, and provide a foundation for business application of the enterprise.

Description

Metadata management, configuration page generation method, server and storage medium

Technical Field

The embodiment of the application relates to the technical field of data processing, in particular to a metadata management and configuration page generation method, a server and a storage medium.

Background

The digitized transformation of an enterprise relates to management of data assets of the enterprise, wherein the data assets of the enterprise refer to data resources owned or controlled by the enterprise, and the data resources of the enterprise can be understood as data which can bring value to the enterprise.

Metadata is used as data for describing data, metadata management runs through a data asset management flow, and is an important basis for realizing data asset management, so that the metadata management method has important significance for managing metadata of enterprises. In this context, how to provide a technical solution to optimize metadata management becomes a technical problem that needs to be solved by those skilled in the art.

Disclosure of Invention

In view of this, the embodiment of the present application provides a metadata management, configuration page generation method, server and storage medium, and based on a logical entity as a component of metadata, the embodiment of the present application implements optimized metadata management by optimizing logical entity management.

In order to achieve the above purpose, the embodiments of the present application provide the following technical solutions.

In a first aspect, an embodiment of the present application provides a metadata management method, where metadata is composed of logical entities, the method includes:

establishing service objects, wherein one service object corresponds to one service function point of an enterprise;

Constructing a plurality of logic entities of the service object, wherein the plurality of logic entities are mounted under the service object and are used for realizing service function points corresponding to the service object;

and constructing logic model information of the logic entity and logic entity attributes, wherein the logic entity attributes comprise description information corresponding to the logic entity realization service function points.

In a second aspect, an embodiment of the present application provides a configuration page generating method, including:

selecting a logic entity required by a service scene from a plurality of logic entities of the service object to which the service scene belongs; the service scene comprises a service flow, wherein the service flow comprises a plurality of tasks; the business object corresponds to the business function point of the enterprise, and a plurality of logic entities for realizing the corresponding business function point are downloaded and mounted on the business object;

determining a logic entity of a task of the service scene from logic entities required by the service scene;

and generating a configuration page of the task by utilizing a logic entity of the task, wherein the configuration page of the task is used for configuring the task.

In a third aspect, an embodiment of the present application provides a server, including: at least one memory storing one or more computer-executable instructions that are invoked by the at least one processor to perform the metadata management method as set forth in the first aspect above or the configuration page generation method as set forth in the second aspect above.

In a fourth aspect, embodiments of the present application provide a storage medium storing one or more computer-executable instructions that, when executed, implement a metadata management method as described in the first aspect, or a configuration page generation method as described in the second aspect.

According to the metadata management method provided by the embodiment of the application, the metadata management can be optimized by optimizing the management of the logic entity, wherein the metadata consists of the logic entity; in the aspect of optimizing logical entity management, the embodiment of the application can establish a service object, wherein one service object corresponds to one service function point of an enterprise; thus, a plurality of logic entities of the business object are constructed, and are mounted under the business object and are used for realizing the business function points corresponding to the business object; and constructing logic model information and logic entity attributes of the logic entity, wherein the logic entity attributes comprise description information corresponding to the logic entity realization service function points.

Therefore, the embodiment of the application can build the business object for the business function point of the enterprise, and mount a plurality of logic entities for realizing the business function point on the business object, so that the logic entities can be classified by the business function point of the enterprise, and the purpose of the logic entities can be clarified. Meanwhile, the logical entity attribute of the logical entity constructed by the embodiment of the application comprises the description information corresponding to the service function point realized by the logical entity, so that the service function point can be realized through the description information corresponding to the service function point realized by the logical entity later, and a foundation is provided for the service application of enterprises at the service function point. Therefore, the embodiment of the application realizes the optimized metadata management through the optimized logical entity management, provides a foundation for business application of enterprises, and provides a solution way and a solution for optimizing the data asset management of the enterprises.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required to be used in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only embodiments of the present application, and that other drawings may be obtained according to the provided drawings without inventive effort to a person skilled in the art.

Fig. 1 is a flowchart of a metadata management method provided in an embodiment of the present application.

FIG. 2 is an exemplary diagram of multiple levels of partitioning of a data asset space.

Fig. 3 is a flowchart of a method for modifying a logic entity according to an embodiment of the present application.

Fig. 4 is a flowchart of a data processing method according to an embodiment of the present application.

FIG. 5 is an exemplary diagram of a relationship between a data asset space and a configuration page.

Fig. 6 is a flowchart of a page configuration method provided in an embodiment of the present application.

Fig. 7 is an example diagram of a concatenated header row structure between logical entities.

Fig. 8 is an exemplary diagram of a list page.

Fig. 9 is a block diagram of a metadata management apparatus.

Fig. 10 is a block diagram of a configuration page generating apparatus.

Fig. 11 is a block diagram of a server.

Detailed Description

The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.

The data model helps the enterprise understand its data assets, so the enterprise's data asset management involves data modeling; data modeling is the process of finding, analyzing and determining data requirements, represented by the form of a data model. The data model may be a multi-layered model structure, mainly involving a logical model and a physical model.

Wherein, the logic model is also called as a logic entity, and belongs to a component part of metadata; for example, metadata includes a logical entity, a logical entity attribute, ER (Entity Relationship ) relationship, and the like, which is data describing data, the logical entity belongs to a member of the metadata. The physical model mainly refers to a physical table storing data.

It should be noted that, the logical entity is also referred to as a logical table, and stores information (i.e., metadata) describing a physical table and a physical table field, where the physical table is a storage structure that truly stores data in a database. The physical table may be generated by a logical entity (logical table), and the logical entity and the physical table may be in a one-to-one correspondence (i.e., one logical entity corresponds to one physical table); for example, based on information describing the physical table by the logical entity, a corresponding physical table may be generated and data corresponding to the physical table fields described by the logical entity may be stored using the physical table.

It can be seen that optimizing logical entity management can achieve optimized metadata management as part of metadata.

In the process of optimizing the logic entity, the inventor of the application finds that enterprises often have different types of data, the different types of data possibly correspond to different enterprise services, and based on the property that the logic entity can be used for generating a physical table, how to optimize the management scheme of the logic entity is important, so that a foundation is provided for different service applications of the enterprises.

Based on the above, the embodiment of the application provides an improved metadata management scheme, and in the aspect of optimizing management of logical entities, the embodiment of the application enables the logical entities to be classified according to the business function points of the enterprise by constructing the logical entities corresponding to the different business function points of the enterprise, so that the purposes of the logical entities can be clarified, thereby providing a basis for different business applications of the enterprise and providing a solution way and a solution for optimizing management of data assets of the enterprise.

Based on the foregoing considerations, as an optional implementation, fig. 1 illustrates an optional flowchart of a metadata management method provided in an embodiment of the present application, where the method flow may be implemented by a data asset management platform, for example, by a server forming the data asset management platform.

Referring to fig. 1, the method flow may include the following steps.

In step S100, a business object is established, where a business object corresponds to a business function point of the enterprise.

In step S110, a plurality of logical entities of the service object are constructed, and the plurality of logical entities are mounted under the service object, where the plurality of logical entities are used to implement service function points corresponding to the service object.

As an optional implementation, the embodiment of the application may divide the business functions of the enterprise, so as to sort out a plurality of business function points of the enterprise, and further establish corresponding business objects for each business function point of the enterprise. For example, embodiments of the present application may create a plurality of business objects, where one business object corresponds to one business function point of an enterprise.

According to the embodiment of the application, the plurality of logic entities for realizing the service function points can be constructed under the service object, so that the service object downloads and mounts the plurality of logic entities for realizing the service function points, and the logic entities can be classified by the service function points of enterprises, so that the purposes of the logic entities can be clarified.

In one example, taking an order service object corresponding to an order service function point as an example (a service object corresponding to an order service function point is referred to as an order service object), the embodiment of the application may construct a plurality of logical entities of the order service object for implementing the order service function point, and mount the constructed plurality of logical entities under the order service object. For example, taking an example that order basic information and order line information are needed by an order service function point, the embodiment of the application can construct a logic entity of the order basic information and a logic entity of the order line information in an order service object, and mount the logic entity of the order basic information and the logic entity of the order line information in the order service object. It should be noted that, the logical entity of the order service object download is not limited to the logical entity of the order basic information and the logical entity of the order line information, but may be designed according to the actual requirement, and the above description is only an example.

As an optional implementation, at the data asset management level of the enterprise, the embodiments of the present application may classify the data asset space of the enterprise, and establish at least one data asset space of the enterprise; respectively establishing at least one asset catalog under each data asset space, respectively establishing at least one business object under each asset catalog, and enabling one business object to correspond to one business function point of an enterprise; further, under each business object, a plurality of logic entities for realizing corresponding business function points are constructed, so that the logic entities can be subdivided and classified.

For ease of understanding, FIG. 2 illustrates an example diagram of a multi-level division of data asset spaces, which may be considered as a broad class division of logical entities, that may be established by embodiments of the present application. Alternatively, different data asset spaces may correspond to different phases of an enterprise business implementation. In one example, the plurality of data asset spaces may be, for example, a test data asset space for business testing, a technical data asset space for business online implementation, and the like.

As shown in fig. 2, there may be multiple asset directories under one data asset space, alternatively one asset directory may be associated with one business segment of an enterprise; the situation of having an asset directory in a data asset space may depend on the specific situation of the enterprise, and embodiments of the present application are not limited. In one example, the different data asset spaces may have some or all of the same asset directory, e.g., the asset directory of the test data asset space may be some or all of the same as the asset directory of the technical data asset space. Of course, the embodiments of the present application may also support different asset directories of different data asset spaces, and may be determined according to the needs of the enterprise, which are not limited in this application.

One data asset space may have a plurality of business objects under one asset directory, one business object may correspond to one business function point of an enterprise, e.g., the order business function point of the previous example, etc.

After the data asset space, the asset directory under the data asset space and the business object under the asset directory are constructed, and as shown in fig. 2, the embodiment of the application can construct a plurality of logic entities for realizing the business function points under the business object, so that the logic entities can be subdivided and classified.

It should be noted that, fig. 2 is an example of an enterprise having a plurality of data asset spaces, a plurality of asset directories under one data asset space, and a plurality of business objects under one asset directory, and this embodiment of the present application may also support an enterprise having at least one data asset space (one or more data asset spaces), at least one asset directory (one or more asset directories) under one data asset space, and at least one business object (one or more business objects) under one asset directory.

In a further alternative implementation, the asset inventory under the data asset space may be multi-level and there may be containment relationships between the multi-level asset inventory. For example, taking the example of creating a four-level asset directory in the data asset space, the first-level asset directory contains a second-level asset directory, the second-level asset directory contains a third-level asset directory, and the third-level asset directory contains a fourth-level asset directory. Optionally, a service object can be defined under each level of asset directory, and a logic entity can be established under the service object; it is also possible to define business objects under the last level of asset catalogue and build logical entities under the business objects.

After the data asset space is divided into multiple layers, the embodiment of the application can construct a plurality of logic entities for realizing service function points corresponding to the service objects under the service objects of the asset catalogue of the data asset space, so that the logic entities can be classified with different service function points of different asset catalogues under different data asset spaces of enterprises, and the logic entities can be finely distinguished. That is, based on the business object to which the logic entity belongs, the asset directory to which the business object belongs, and the data asset space to which the asset directory belongs, the embodiment of the application can make the purpose of the logic entity clear, and the management of the logic entity can be optimized, so that the enterprise can use the logic entity with the corresponding purpose in different business scenes conveniently, and a foundation is provided for different business applications of the enterprise.

It should be noted that, performing multi-level division on the data asset space, and then building a logic entity under the service object is only an alternative implementation manner, and the embodiment of the application may also directly sort the service function points of the enterprise, and build the logic entity under the service object corresponding to the service function points.

And step S120, constructing logic model information of the logic entity and logic entity attributes, wherein the logic entity attributes comprise description information corresponding to the logic entity realization service function points.

After a plurality of logical entities are built under the business object, the embodiment of the application can build the logical model information and the logical entity attribute for each logical entity. Optionally, the logic model information is used to describe the logic entity, including a logic entity name, a logic entity field (code), classification information of the logic entity, and the like. Optionally, the categorization information of the logical entity may indicate at least a data asset space to which the logical entity belongs; in one example, the data asset space to which the logical entity belongs may be regarded as categorization information of the logical entity; of course, the embodiment of the application may also support setting the asset directory, the business object, and the like to which the logical entity belongs in the classification information of the logical entity.

In the embodiment of the present application, the logic entity is mounted under the service object corresponding to the service function point, so as to facilitate the use of the logic entity in the service function point, for example, in the service scenario of constructing the service function point association, the embodiment of the present application may use part or all of the logic entities under the corresponding service object to construct a configuration page, so that the tasks in the service scenario (one service scenario may include a service flow formed by a plurality of tasks) are configured by using the configuration page. Therefore, when constructing the logical entity attribute of the logical entity, the embodiment of the application needs to bear the description information corresponding to the service function point realized by the logical entity in the logical entity attribute. That is, the logical entity attribute of the logical entity may include description information corresponding to the logical entity implementation service function point.

As an optional implementation, the description information corresponding to the service function point implemented by the logic entity may include: the logic entity generates description information corresponding to the physical table and generates description information corresponding to the page of the service function point. In one example, the logical entity generating the description information corresponding to the physical table may include at least one of: chinese name of the physical table generated by the logical entity, a field (a field may correspond to a column of the physical table), a data type, primary key judgment information (e.g., whether a field of the physical table is a primary key field), unique key judgment information (e.g., whether a field of the physical table is a unique key), and the like. The logic entity generating the description information corresponding to the page of the service function point may include: the front end of the page presents information of the component, etc.

As an alternative implementation, the server of the data asset management platform may implement the flow shown in fig. 1 based on instructions and inputs from a user (e.g., model builder); for example, the user may send instructions and input information to the server of the data asset management platform through the device that the user operates, so that the server of the data asset management platform may perform multi-level division on the data asset space, construct a logical entity under a business object, construct logical model information and logical entity attributes of the logical entity, and the like based on the instructions and input information of the user.

Further, after the data asset management platform classifies the logic entities as business function points of the enterprise, the data asset management platform can serve as a basis for business applications of the enterprise, so that data sources of the business applications of the enterprise come from the data asset management platform. That is, the data of business application of the enterprise comes from a database of the data asset management platform, the data management of the database is realized by a logic entity managed by the data asset management platform, and the logic entity is classified by business function points of the enterprise; therefore, the optimized logical entity management scheme can provide a basis for business applications of enterprises, enables data of the business applications of the enterprises to be managed in a centralized manner on the data asset management platform, and provides a basis for centralized management of data assets of the enterprises.

In a further optional implementation, after the logical entity attribute is constructed, the embodiment of the present application may publish the logical entity; thus, after the logic entity is released (for example, after the logic entity is released successfully), a physical table corresponding to the logic entity can be established in the database. Optionally, in the case of building a data asset space, the embodiment of the present application may build an area corresponding to a summary (schema) of the data asset space in the database, so that after the logical entity is published, the embodiment of the present application may build a physical table of the logical entity in the database corresponding to the schema of the data asset space to which the logical entity belongs. For example, when the embodiment of the application establishes the data asset space, a field (code) and a schema of the data asset space may be defined, so that the embodiment of the application may establish an area corresponding to the schema of the data asset space in the database according to the schema of the data asset space; further, after the logic entity is released, a physical table corresponding to the logic entity can be established in the region corresponding to the schema of the data asset space to which the logic entity belongs in the database; that is, the physical table is built in the database in an area corresponding to the schema.

Further, the embodiment of the application can provide convenience for distinguishing the data asset space used by the synchronous data when the synchronous data is synchronized. For example, the data of the test data asset space is not necessarily used online, and then the physical tables of all logical entities of the test data asset space in the database may be ignored in synchronizing the data based on the test data asset space and the technical data asset space divided by embodiments of the present application.

In a further alternative implementation, embodiments of the present application may add ER relationships between logical entities after the logical entities are published (e.g., after the logical entities are published successfully). For example, determining a logical entity (data reference relationship such as data reference type) in which a data reference relationship exists among a plurality of logical entities on which a business object is downloaded; thereby adding ER relationships to logical entities that have data reference relationships. An example of adding ER relationships to a logical entity may be shown in connection with the example of fig. 2.

It should be noted that, in the past, the relationship between data is developed through external keys or back-end code logic, but in the embodiment of the present application, ER relationships between logic entities are added to express data reference relationships between logic entities, so that when a user implements service function points by using logic entities, the user can clearly understand the reference relationships between the logic entities displayed by the front end, thereby facilitating the user to implement service function points by using the logic entities.

In one example, embodiments of the present application may add reference data types between logical entities (i.e., ER relationships between logical entities) at a data asset management platform; further, ER relationships between logical entities may be parsed into specific display forms such as connection points and connection lines between logical entities, and stored (e.g., stored in an ER relationship table and a graph database); and the user can clearly know the reference relation between the data through specific display forms such as connection points, connection lines and the like among the logic entities displayed at the front end. For example, the embodiment of the application can analyze ER relationships among logic entities into specific display forms such as connection points, connection lines and the like among the logic entities so as to display data reference relationships among the logic entities through the specific display forms among the logic entities.

In a further alternative implementation, there may be a modification situation of the logical entity (modifying the logical entity means modifying metadata), and the modification of the logical entity needs to be approved, so in order to facilitate the displaying of the difference before and after the modification of the logical entity when the modification of the logical entity is approved, the embodiment of the present application further provides a method flow for modifying the logical entity. As an alternative implementation, fig. 3 illustrates a flowchart of a method for modifying a logic entity provided in an embodiment of the present application, and referring to fig. 3, the method flow may include the following steps.

And step S300, in response to the modification application of the logic entity, copying the logic entity and the logic entity attribute stored in the formal table into the backup table, and giving a version number to the backup table.

Optionally, the currently used logical entity and the logical entity attribute are stored in the formal table. In order to avoid modifying the currently used logic entity and the attribute of the logic entity in the formal table directly, thereby influencing the service operation, the backup table can be set in the embodiment of the application; when the user modifies the logic entity, the embodiment of the application can copy the logic entity and the logic entity attribute stored in the formal table into the backup table so that the user modifies the logic entity in the backup table. For example, when a user needs to modify a logical entity, the user may apply for modification of the logical entity to the data asset management platform, so that the data asset management platform may copy the logical entity and the logical entity attribute stored in the formal table to the backup table in response to the modification application. Further, after copying the logical entity and the logical entity attribute stored in the formal table to the backup table, the embodiment of the application may assign a version number to the backup table.

Step S310, based on the modification information of the logic entity, the logic entity and the logic entity attribute stored in the backup table are modified.

When a user modifies a logical entity, modification information of the logical entity can be provided, so that the data asset management platform can modify the logical entity and the logical entity attribute stored in the backup table. That is, the user's modification operation to the logical entity is performed by modifying the logical entity and the logical entity attribute in the backup table, rather than directly modifying in the formal table.

Step S320, responding to the modification approval application of the logic entity, and comparing the corresponding backup table with the logic entity and the logic entity attribute stored in the formal table according to the version number carried in the modification approval application to obtain the difference information.

After the user completes the modification of the logic entity, the modification of the logic entity needs to be approved, so that the user can submit a modification approval application of the logic entity when completing the modification of the logic entity, and the modification approval application carries the version number of the backup table to be approved; the data asset management platform can respond to the modification approval application, based on the version number carried in the modification approval application, the logical entity and the logical entity attribute stored in the backup table corresponding to the version number are compared with the logical entity and the logical entity attribute stored in the formal table, and the difference information of the backup table and the formal table is obtained, so that the modification position of the logical entity is reflected through the difference information. Further, the difference information can be displayed on the terminal equipment of the approver so that the approver can carry out approval. In an alternative implementation, the embodiment of the application may compare the field contents of the backup table and the formal table, so as to obtain the difference information.

As an alternative implementation, a reference data type (when a physical table is generated, the type of the referenced logical entity attribute needs to be searched as the real data type of the physical table) exists in the data types (shaping, character string type, floating point number type and the like) in the logical entity attributes, and the reference data type expresses the logical entity and the logical entity attribute with ER relationship; therefore, the embodiment of the application can embody the difference of ER relation in the backup table and the formal table by comparing the reference data types of the logical entity attributes in the backup table and the formal table (the reference data types are contained in the data types of the logical entity attributes).

Step S330, after the modification approval of the difference information is passed, the logical entity and the logical entity attribute in the backup table are covered into the formal table.

After the modification of the logic entity is approved, the embodiment of the application can cover the modified logic entity and the logic entity attribute in the backup table into the formal table, so that the modified logic entity can be formally used through the formal table.

In a further alternative implementation, after a corresponding physical table is established based on a logical entity, data processing requirements such as adding, deleting, changing, checking and the like on the physical table exist; the embodiment of the application further provides a data processing scheme to improve the efficiency of data processing such as adding, deleting, changing, checking and the like on the physical table. As an alternative implementation, fig. 4 illustrates a flowchart of a data processing method provided in an embodiment of the present application, and referring to fig. 4, the method flowchart may include the following steps.

Step S400, a data processing request transmitted to a target interface of a physical table is acquired, wherein the data processing request carries request content required by the target interface for data processing, and the request content comprises at least one of the following: the identification of the data asset space to which the logical entity of the physical table belongs, the identification of the logical entity, the data processing conditions, and the indication information of the data to be processed.

As an alternative implementation, different interfaces are needed to perform different data processing on the physical table, so when the data processing needs to be performed on the physical table, it is needed to determine that the data processing is on the target interface corresponding to the physical table. In one example, a physical table may have nine sets of interfaces that implement different data processing, respectively: single new, batch new, single update, batch update, conditional update, single delete, conditional delete, single query, conditional query.

Wherein, a single newly added interface for adding data belonging to a physical table is newly added in batches; the manner of adding the single data is different from the manner of adding the data corresponding to the batch of the single data, for example, the single data is added in the physical table, and the batch of the data is added in the physical table in batch.

Single strip update, batch update, interface to update data (update data such as modification data) belonging to a physical table by condition; the single update, the batch update, and the condition-based update are different in the manner of updating the corresponding update data, for example, the single update is to update the single data in the physical table, the batch update is to update the batch data in the physical table, and the condition-based update is to update the data in the physical table according to the condition of one piece.

A single interface for deleting and deleting the deleted data belonging to the physical table according to the condition; the single delete is to delete a single piece of data in the physical table and the conditional delete is to delete data in the physical table according to a condition of one piece, for example, in a different manner of deleting the corresponding piece of data by condition.

An interface for single query and conditional query of query data belonging to a physical table; the single query queries a single piece of data in the physical table in a different manner than the corresponding query data by condition, e.g., the single query queries a single piece of data in the physical table by condition.

After confirming that the data processing is on the target interface corresponding to the physical table, the front end (for example, the terminal device requesting the data processing) may transmit a data processing request to the target interface of the physical table according to the request content required by the data processing performed on the target interface of the physical table. The content of the request required for data processing by the different interfaces is different, so that the front end needs to transmit the data processing request to the target interface based on the content of the request required for data processing by the target interface. In an alternative implementation, the request content carried by the data processing request may include at least one of: the identification of the data asset space to which the logical entity of the physical table belongs, the identification of the logical entity, the data processing conditions, and the indication information of the data to be processed.

Step S410, according to the request content of the data processing request, generating an SQL execution statement corresponding to the target interface, and executing the SQL execution statement to realize data processing on the physical table.

After obtaining the data processing request transmitted to the target interface, the back end (e.g. the server end of the data asset management platform) may generate, according to the request content of the data processing request, an SQL (Structured Query Language ) execution statement corresponding to the target interface, and execute the SQL execution statement, so as to perform data processing on the physical table by calling the target interface.

In one example, different interfaces have different grammatical logic, so according to the grammatical logic of the target interface, the embodiment of the application can generate the SQL execution statement corresponding to the target interface based on the request content of the data processing request. In one example, taking the interface of a batch query as an example, the corresponding SQL execution statement may be, for example: select [ query field ] from [ logical entity identifier ] where [ conditional splice ] orderby [ ordering rule ]. Different data processing requests relate to different data processing operations, so that the grammar of corresponding SQL execution sentences is also different, and the back end can splice parameters of the SQL execution sentences based on the request content of the data processing requests according to the grammar logic of the interface, thereby forming the SQL execution sentences. For another example, the processing of the data addition needs to indicate the data information to be added, taking a single new addition as an example, a single new addition corresponding SQL execution statement may, for example: insert intos [ logical entity identifier ] [ column name corresponding to data 1 to be newly added, column name corresponding to data 2 to be newly added ] [ data 1 to be newly added, data 2 to be newly added ], wherein the column name and the data are expressed through a data structure Map ].

From the front end, when the front end needs to perform data processing such as adding, deleting, changing, checking and the like on the physical table, the front end needs to query information of a logic entity corresponding to the physical table (for example, the identifier of a data asset space to which the logic entity of the physical table belongs, the identifier of the logic entity), so that the identifier of the data asset space, the identifier of the logic entity, the data processing condition and the indication information of the data to be processed are transmitted to the target interface, and then the back end can automatically complete data processing operation on the physical table, thereby improving the efficiency of data processing such as adding, deleting, changing, checking and the like of the physical table.

As an alternative implementation, one example of using a logical entity for a business application may, for example, use the logical entity to form a configuration page for a task, so that the task related to the business scenario is configured through the configuration page for the task. For easy understanding, fig. 5 is an exemplary diagram illustrating a relationship between a data asset space and a configuration page, and in combination with fig. 2 and fig. 5, a service object to which a service scenario belongs may be determined under the multi-level data asset space illustrated in fig. 2, and a logic entity required by the service scenario is selected from a plurality of logic entities mounted on the service object; a plurality of service flows formed by activities are defined in the service scene, and one activity can be regarded as one task in the service scene, namely, the plurality of tasks in the service scene form the service flows of the service scene; furthermore, the logical entity of each task in the service scene is selected from the logical entities required by the service scene, and the configuration page of each task is constructed by utilizing the logical entity of each task, and can be used for configuring the task.

As an optional implementation, fig. 6 illustrates an optional flowchart of a page configuration method provided in an embodiment of the present application. As shown in fig. 6, the method may include the following steps.

Step S600, selecting a logic entity required by a service scene from a plurality of logic entities of the service object of the service scene; wherein the traffic scenario comprises a traffic flow comprising a plurality of tasks.

In an alternative implementation, the data asset management platform stores a full number of logical entities and ER relationships between the logical entities; for example, the data asset management platform stores logical entities under business objects, and relationships between logical entities, in a multi-level manner of data asset space, asset inventory, business objects. On this basis, the embodiment of the application proposes the concept of a scene (i.e. a service scene), wherein the service scene is associated with service function points, for example, the service function points relate to one or more service scenes when applied; there is a traffic flow under one traffic scenario, there are multiple tasks under the traffic flow (that is, the traffic scenario is achieved by multiple tasks under the traffic flow); wherein one task corresponds to one page.

Based on the association of the service scene and the service function point, the embodiment of the application can determine the service object corresponding to the service function point to which the service scene belongs (namely, the service object to which the service scene belongs), and further select the logic entity required by the service scene from a plurality of logic entities of the service object to which the service scene belongs. The logic entity required by the service scene can be part or all of the logic entity downloaded by the service object, and can be specifically selected according to actual conditions, and the embodiment of the application is not limited.

In step S610, the logical entity of the task of the service scenario is determined from the logical entities required by the service scenario.

Step S620, a configuration page of the task is generated by utilizing a logic entity of the task, and the configuration page of the task is used for configuring the task.

After the logic entity required by the service scene is selected, the logic entity can be selected for each task in the service scene from the logic entities required by the service scene. For example, for any task in a business scenario, embodiments of the present application may select a logical entity for the task from among the logical entities required by the business scenario. Further, when a logical entity is selected for a task, a primary logical entity of the task may be defined.

After determining the logic entity of each task in the service scene, for any task in the service scene, the embodiment of the application can generate a configuration page of the task by utilizing the logic entity of the task; and further, the configuration can be carried out for the task through the configuration page of the task. In an optional implementation, for any task of the service scenario, the number of logical entities of the task may be multiple, and in the embodiment of the present application, a reference association between logical entities of the task may be determined through ER relationships between multiple logical entities of the task, so that a configuration page with a cascade of head logical entities and row logical entities is generated based on the reference association between logical entities of the task, where data of the row logical entities refers to data of the head logical entities.

In an alternative implementation, after determining a logical entity for each task of a service scenario, the embodiment of the present application may record a correspondence between the logical entity of each task and a task ID. Furthermore, for each task of the service scene, the embodiment of the application can query the logical entity of the task and the ER relationship between the logical entities based on the task ID of the task; thus, the reference association between the logical entities of the task can be confirmed through the ER relationship between the logical entities of the task. When there is a reference association between the logic entities, the embodiment of the application may use the logic entity referenced by the logic entity as a head logic entity and the logic entity referenced by the head logic entity as a row logic entity, where the reference is a reference of data, that is, the data of the row logic entity references the data of the head logic entity, and the reference association is cascaded in the task, so that the logic entities of the task may form a cascaded head row structure, and further form a configuration page with the cascaded head row structure.

In one example, taking a logical entity of order basic information and a logical entity of order line information as an example, the data of the order line information is obtained by splitting the data of the order basic information (based on a database design concept, the data of the order basic information and the data of the order line information are stored in different physical tables and have a reference relationship of 1:n, for example, the data of the order basic information has data of N order line information), so the data of the order line information refers to the data of the order basic information; thus, for the logical entities of the order base information and the order line information, the logical entity of the order base information is a head logical entity and the logical entity of the order line information is a line logical entity. Further, the order line information may have attachment information, that is, the data of the attachment information refers to the data of the order line information, so that for the logical entities of the order line information and the attachment information, the logical entity of the order line information is a head logical entity, and the logical entity of the attachment information is a line logical entity. Further, the logical entity of the order basic information, the logical entity of the order line information, the logical entity of the attachment information, and the header line structure forming a cascade.

In one example, taking test logical entities testing a four-level inventory of assets under a data asset space as an example, FIG. 7 illustrates an example diagram of a head row structure concatenated between logical entities. As shown in fig. 7, there is a four-level asset directory in the test data asset space, under the business object of the test logical entity of the four-level asset directory, the logical entity for the test can be constructed, and the ER relationship between the logical entities can express the reference association in the form of a header line. For example, the logical entity of the logical deletion header and the logical entity of the logical deletion first layer line are 1: n, the logical entity of logically deleting the first layer row and the logical entity of logically deleting the second layer row are 1: n, and further, the logical entity of the logical deletion header, the logical entity of the logical deletion first layer line and the logical entity of the logical deletion second layer line form a cascade header line structure.

In a further alternative implementation, if a master logical entity of a task is defined when the logical entity is selected for the task, a configuration page based on the master logical entity and having a concatenation of a head logical entity and a row logical entity may be generated based on ER relationships between the master logical entity of the task, the data of the row logical entity referencing the data of the head logical entity.

In generating the configuration page of the task, the configuration page may be in the form of a list page, a creation page, an edit page, and a detail page of the task, that is, the configuration page of the task includes a list page, a creation page, an edit page, and a detail page of the task. Optionally, the list page of the task is used as a parent page, and the creation page, the editing page and the detail page of the task can be triggered to realize the operations of adding, editing, viewing details and the like when the task is configured; further, the list page of tasks may also have an operation that triggers an newly added task. As an example, fig. 8 illustrates an example diagram of a list page, which may be considered as a configuration page corresponding to a master logical entity of a task, may trigger various configuration pages (e.g., create page, edit page, detail page, etc.) having a concatenation of a head logical entity and a row logical entity under the master logical entity.

As shown in fig. 8, the list page presents information of each task in a list form, and for each task, there are operation entries for editing, deleting, and viewing (viewing details), wherein the operation entry for editing is used for triggering an editing page for entering the task, the operation entry for deleting is used for deleting the task, and the operation entry for viewing details is used for triggering a detail page for entering the task; further, the list page also has an added operation entry for triggering the creation page of the incoming task. The operations of editing, checking details, creating new and the like performed on the task can be cascade operations realized based on the head line structure, that is, pages corresponding to the editing, checking details, creating new and the like of the task are pages based on cascade of head logic entities and line logic entities, and the pages can be generated by the cascade head logic entities and line logic entities under the main logic entities of the task.

In one example, upon clicking on the operation entry of the view details of the list page, embodiments of the present application may obtain the task ID of the task and the data primary key value of the head logical entity; thus, according to the task ID of the task, the associated fields of the head logic entity and the row logic entity of the task are inquired, and according to the data primary key value of the head logic entity of the task, the data of the head logic entity are inquired; furthermore, according to the data of the head logic entity of the task, the associated fields of the head logic entity and the row logic entity inquire the data associated with the row logic entity in the physical table, and the data is displayed on the detail page of the task.

In one example, when clicking on a newly added operation entry of the list page, the embodiment of the present application may obtain a task ID of the task; therefore, the universal interface is called, the data of the head logic entity is newly added, and the data primary key value of the head logic entity is obtained, so that the data is newly added in the physical table of the head logic entity; furthermore, the ER relationship of the logical entities of the task is obtained through the task ID, and the data related to the row logical entities in the head logical entity are newly added into the physical table corresponding to the row logical entities according to the ER relationship of the logical entities.

In one example, when clicking the operation entry of the deletion of the list page, the embodiment of the present application may obtain the task ID, the head logical entity, and the data primary key value of the task; according to task ID of the task, querying ER relation of logical entities of the task, and according to ER relation of the logical entities, deleting data of each logical entity of the task based on the head logical entity and the data primary key value in a recursive manner according to the deleting sequence from the data of the head logical entity to the data of the row logical entity (the data of the logical entity is stored in a physical table corresponding to the logical entity).

In a further alternative implementation, the configuration page may further configure information such as whether a field is displayed, whether a field is necessary to be filled, whether a button is displayed, a button display time, a display size, a custom button, etc., where the configuration information may be persisted in the storage according to a task ID of the task.

In one display implementation, a configuration page (a detail page, a new page, etc. of a task) of the task may be divided into a plurality of regions, where one region corresponds to data of one logical entity of the display task, so that the plurality of regions may display data corresponding to each logical entity of the task according to ER relationships between the logical entities. For example, taking data presentation of order basic information and order line information as an example, the interface design of the configuration page of the task may be that the upper half area of the page displays the data information of the order basic information and the lower half area displays the data information of the order line information; that is, the data information of each logical entity of the task may be presented from the top to the bottom of the page in terms of ER relationships between the logical entities.

In one implementation example, taking a configuration page for creating an order as an example, embodiments of the present application may relate to the following implementation procedure.

1. A stage of establishing a logic entity.

Establishing a data asset space (at this time, an area corresponding to the schema of the data asset space can be established in the database according to the schema defined by the establishment of the data asset space); establishing a procurement-managed asset inventory under the data asset space (the asset inventory may be multi-level, e.g., a four-level asset inventory); establishing an order service object under a purchase management asset catalog; a logical entity that establishes order basic information, a logical entity of order line information, etc. in order service objects.

After the logical entities under the order service objects such as the logical entity of the order basic information, the logical entity of the order line information and the like are built, the logical model information and the logical entity attribute are built for each logical entity respectively. For example, the logical model information of the logical entity of the order basic information may be divided into order number, transportation mode, order status, etc.; the logical model information of the logical entity of the order line information may be divided into order line number, order number, consignee name, etc. Meanwhile, in the embodiment of the application, service components (such as corresponding input boxes and the like) can be configured in the logic entity attribute of the logic entity of the order basic information and the logic entity of the order line information.

After the logical entity and the logical entity attribute are established, the logical entity can be released, and then a physical table can be established for each logical entity in the area corresponding to the schema of the data asset space in the database. It should be noted that, after the logic entities issue successfully, ER relationships between the logic entities may be added to represent data reference relationships between the logic entities, for example, in the data reference layer, the order number of the order basic information and the order number of the order line are 1: n.

2. And a stage of establishing a configuration page.

The order service scene belongs to an order service object, and a logic entity required by the order service scene can be selected from logic entities of the order service object; at this time, ER relationships of the selected logical entities may be displayed; further, the embodiment of the application can also support ER relation which is not needed for confirming the order service scene;

for an order registration task of an order service scenario, registering the order registration task (i.e., an order registration activity) in the order service scenario; the order registration task is arranged and configured, and the logic entity of the order registration task can be further selected from logic entities required by an order service scene, for example, the logic entity of order basic information and the logic entity of order line information are selected; the main logic entity is configured for the order registration task, and the information such as the necessary filling items is configured; and further forming a configuration page of the order registration task, which can be used for configuring the order registration task.

The embodiment of the application also provides a metadata management device, and the content described below can be referred to correspondingly with the above description. Fig. 9 illustrates an alternative block diagram of a metadata management apparatus, referring to fig. 9, which may include:

a business object establishment module 910, configured to establish a business object, where a business object corresponds to a business function point of an enterprise;

the logic entity construction module 920 is configured to construct a plurality of logic entities of the service object, where the plurality of logic entities are mounted under the service object, and the plurality of logic entities are configured to implement service function points corresponding to the service object;

the model information and attribute construction module 930 is configured to construct logical model information of a logical entity and a logical entity attribute, where the logical entity attribute includes description information corresponding to a service function point implemented by the logical entity; logical entities constitute metadata.

Optionally, the service object creation module 910 is configured to create a service object, including:

classifying the data asset space of the enterprise, and establishing at least one data asset space of the enterprise;

establishing at least one asset catalogue under each data asset space respectively;

at least one business object is respectively established under each asset directory.

Optionally, the logic model information includes: the name of the logic entity, the field of the logic entity and the classification information of the logic entity; the classification information of the logic entity at least indicates the data asset space to which the logic entity belongs;

the description information corresponding to the service function point implemented by the logic entity comprises: the logic entity generates description information corresponding to the physical table and generates description information corresponding to the page of the service function point.

In a further alternative implementation, the metadata management apparatus may be further configured to:

after the logic entity is released, establishing a physical table of the logic entity in a region corresponding to the digest of the data asset space to which the logic entity belongs in a database, wherein the digest of the data asset space is defined when the data asset space is established, and the region corresponding to the digest of the data asset space is established in the database;

and/or, publishing the logic entities, and adding ER relationships between the logic entities after publishing the logic entities, wherein the ER relationships between the logic entities express data reference relationships between the logic entities;

and/or resolving the ER relationship between the logic entities into a specific presentation form between the logic entities and storing the specific presentation form so as to present the data reference relationship between the logic entities through the specific presentation form between the logic entities.

copying the logic entity and the logic entity attribute stored in the formal table to the backup table in response to the modification application of the logic entity, and giving a version number to the backup table, wherein the logic entity and the logic entity attribute which are currently used are stored in the formal table; modifying the logic entity and the logic entity attribute stored in the backup table based on the modification information of the logic entity; responding to a modification approval application of the logic entity, and comparing the corresponding backup table with the logic entity and the logic entity attribute stored in the formal table according to the version number carried in the modification approval application to obtain difference information; after the modification approval of the difference information is passed, the logic entity and the logic entity attribute in the backup table are covered into the formal table;

and/or, acquiring a data processing request transmitted to a target interface of the physical table, wherein the data processing request carries request content required by the target interface for data processing, and the request content comprises at least one of the following: the identification of the data asset space to which the logical entity of the physical table belongs, the identification of the logical entity, the data processing condition, and the indication information of the data to be processed; and generating an SQL execution statement corresponding to the target interface according to the request content of the data processing request, and executing the SQL execution statement to realize data processing on the physical table.

The embodiment of the application also provides a configuration page generating device, and the content described below can be referred to correspondingly with the above description. Fig. 10 illustrates an alternative block diagram of a configuration page generation apparatus, referring to fig. 10, which may include:

the logic entity selection module 01 is used for selecting a logic entity required by a service scene from a plurality of logic entities of the service object to which the service scene belongs; the service scene comprises a service flow, wherein the service flow comprises a plurality of tasks; the business object corresponds to the business function point of the enterprise, and a plurality of logic entities for realizing the corresponding business function point are downloaded and mounted on the business object; and determining the logic entity of the task of the service scene from the logic entities required by the service scene;

the page generating module 02 is configured to generate a configuration page of the task by using a logical entity of the task, where the configuration page of the task is used for configuring the task.

In a further alternative implementation, the logical entity selection module 01 may be further configured to define a master logical entity of the task when selecting the logical entity for the task.

Optionally, the page generating module 02 is configured to generate, by using a logical entity of the task, a configuration page of the task, including:

Determining reference association between logical entities of the task based on the master logical entity of the task and ER relationship between the logical entities; based on the reference association between the logical entities of the task, a configuration page based on the main logical entity and provided with a cascade of a head logical entity and a row logical entity is generated, wherein the data of the row logical entity refers to the data of the head logical entity.

Optionally, the configuration page of the task comprises a list page, a creation page, an editing page and a detail page of the task; the list page of the task triggers the creation page, the editing page and the detail page of the task, and the task is deleted through the list page of the task.

In a further optional implementation, the configuration page generating device may further be configured to:

when an operation entry for checking details of the list page is clicked, acquiring a task ID of a task and a data primary key value of a head logic entity; inquiring the associated fields of the head logic entity and the row logic entity of the task according to the task ID of the task, and inquiring the data of the head logic entity according to the data primary key value of the head logic entity of the task; according to the data of the head logic entity of the task, the associated fields of the head logic entity and the row logic entity inquire the data associated with the row logic entity in a physical table and display the data on a detail page of the task;

And/or, when the operation entry for deleting the list page is clicked, acquiring a task ID, a head logic entity and a data main key value of the task; according to the task ID of the task, inquiring the ER relation of the logical entity of the task, and according to the ER relation of the logical entity, deleting the data of each logical entity of the task according to the deleting sequence from the data of the head logical entity to the data of the row logical entity, and based on the head logical entity and the data main key value in a recursion mode.

Embodiments of the present application further provide a server, fig. 11 exemplarily illustrates an optional block diagram of the server, and as shown in fig. 11, the server may include: at least one processor 1, at least one communication interface 2, at least one memory 3 and at least one communication bus 4.

In the embodiment of the present application, the number of the processor 1, the communication interface 2, the memory 3, and the communication bus 4 is at least one, and the processor 1, the communication interface 2, and the memory 3 complete communication with each other through the communication bus 4.

Alternatively, the communication interface 2 may be an interface of a communication module for performing network communication.

Alternatively, the processor 1 may be a CPU (central processing unit), GPU (Graphics Processing Unit, graphics processor), NPU (embedded neural network processor), FPGA (FieldProgrammable Gate Array ), TPU (tensor processing unit), AI chip, specific integrated circuit ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement embodiments of the present application, or the like.

The memory 3 may comprise a high-speed RAM memory or may further comprise a non-volatile memory, such as at least one disk memory.

Wherein the memory 3 stores one or more computer-executable instructions that the processor 1 invokes to perform the metadata management method provided in the embodiments of the present application, or to configure the page generation method.

The embodiment of the application also provides a storage medium, which stores one or more computer executable instructions, and when the one or more computer executable instructions are executed, the metadata management method or the configuration page generation method provided by the embodiment of the application is realized.

The foregoing describes a number of embodiments provided by embodiments of the present application, and the various alternatives presented by the various embodiments may be combined, cross-referenced, with each other without conflict, extending beyond what is possible, all of which may be considered embodiments disclosed and disclosed by embodiments of the present application.

Although the embodiments of the present application are disclosed above, the present application is not limited thereto. Various changes and modifications may be made by one skilled in the art without departing from the spirit and scope of the invention, and the scope of the invention shall be defined by the appended claims.

Claims

1. A method of metadata management, wherein metadata is comprised of logical entities, the method comprising:

2. The method of claim 1, wherein the establishing a business object comprises:

3. The method of claim 2, wherein the logic model information comprises: the name of the logic entity, the field of the logic entity and the classification information of the logic entity; the classification information of the logic entity at least indicates the data asset space to which the logic entity belongs;

4. A method according to any one of claims 2-3, further comprising:

5. The method as recited in claim 1, further comprising:

6. A configuration page generation method, comprising:

7. The method of claim 6, wherein the method further comprises: defining a main logic entity of a task when selecting the logic entity for the task;

the task-utilizing logic entity generates a configuration page of a task, including:

determining reference association between logical entities of the task based on the master logical entity of the task and ER relationship between the logical entities; based on the reference association between the logical entities of the task, a configuration page based on the main logical entity and cascaded by the head logical entity and the row logical entity is generated, wherein the data of the row logical entity refers to the data of the head logical entity.

8. The method of claim 7, wherein the configuration page of the task comprises a list page, a creation page, an edit page, and a detail page of the task; the list page of the task triggers the creation page, the editing page and the detail page of the task, and triggers the deletion task through the list page of the task; the method further comprises the steps of:

and/or when the operation entry for deleting the list page is clicked, acquiring a task ID, a head logic entity and a data main key value of the task; according to the task ID of the task, inquiring the ER relation of the logical entity of the task, and according to the ER relation of the logical entity, deleting the data of each logical entity of the task according to the deleting sequence from the data of the head logical entity to the data of the row logical entity, and based on the head logical entity and the data main key value in a recursion mode.

9. A server, comprising: at least one memory storing one or more computer-executable instructions, and at least one processor invoking the one or more computer-executable instructions to perform the metadata management method of any of claims 1-5 or the configuration page generation method of any of claims 6-8.

10. A storage medium storing one or more computer-executable instructions which, when executed, implement the metadata management method of any one of claims 1-5 or the configuration page generation method of any one of claims 6-8.