Unified business and technology data language construction methodology and data automation services

Abstract

A method for constructing a unified business and technology data language includes the following steps: Step 1, specifying independent variables based on the business model and the indicator meta-model; Step 2, performing the specified independent variables as follows to ensure they conform to the domain language model of the asset management data domain: whether the independent variable corresponds to a concept or class in the asset management domain and whether it corresponds to metadata, whether the independent variable forms parent and child nodes and thus performs association calculations; Step 3, determining whether to use the independent variable or return to Step 1.

Description

Technical Field

[0001] This invention relates to the field of database design, particularly to a method for constructing a unified data language for business and technology, and a data automation service. Background Technology

[0002] In the asset management business data domain, an automated and intelligent data service layer method is constructed by establishing an indicator metadata domain language to bridge the gap between business and DBMS data models.

[0003] Every enterprise and organization has a large amount of data accumulated. The vast majority of subsequent data query and browsing services are completed through BI report development or manual data extraction. In a few scenarios, dimensional models are built in combination with BI tools to support self-service browsing and analysis of limited content (which accounts for a small part of the enterprise's data content).

[0004] How to open up data content so that business users can freely extract, browse, and analyze data has always been a problem in the data field, mainly because:

[0005] ER models lack accurate, consistent, and complete descriptions of data: In data system practice, developers often have too much freedom in designing and implementing ER models, leading to a lack of consistent, accurate, and complete descriptions. Common issues include: a table lacking accurate business primary key settings, redundant fields or transitive dependencies, and a field having different meanings at different times. All of these cause a loss of connection between the table's related fields and the essential entity described by the data, making subsequent data use impossible to automate.

[0006] The ER model is far removed from the data business model, necessitating a new descriptive language to fill this gap: the ER model used by DBMS is expressed in a technical language that is difficult for business personnel to accurately understand. Furthermore, because the ER model is fundamentally different from business principles, a significant amount of business knowledge remains undigitized within the system during system design and development. During manual data extraction or dataset creation (such as developing reports), much of the know-how resides in the minds of developers; the DBMS system fails to digitize this relevant business knowledge, hindering the automation of data services.

[0007] In the existing data service model, business users and data engineers need to engage in extensive point-to-point communication. Data engineers then develop, encapsulate, and test the data based on their understanding of the requirements, before delivering it to business users for testing and confirmation. This process results in low communication efficiency, repetitive work (including duplicate code scripts), and unstructured knowledge accumulation due to the lack of a unified data domain language. The consequences include:

[0008] 1) There is a lack of a unified formal language between business and data engineers, resulting in inefficient and low-quality communication;

[0009] 2) Business requirement datasets require data engineers to manually develop them, resulting in many service process nodes and long time, making it impossible to escape the human resource trap of data services and failing to meet the business's need for rapid data acquisition and verification;

[0010] 3) The knowledge gained during the data service process cannot be effectively accumulated and lacks unified management, which is detrimental to the digital transformation of enterprises;

[0011] 4) The data service layer lacks a unified interface for external exposure, resulting in severe entropy increase in the data access layer of the participating companies' information systems. Summary of the Invention

[0012] A method for constructing a unified business and technology data language includes the following steps:

[0013] Step 1: Specify the independent variables based on the business model and the indicator meta-model;

[0014] Step 2, perform the following operations on the specified independent variables to ensure compliance with the domain language model of the asset management data domain:

[0015] The independent variable is checked to determine whether it corresponds to a concept or class in the asset management domain and whether it corresponds to metadata.

[0016] Whether the independent variable forms a parent node and a child node and is therefore used for association calculation;

[0017] Step 3: Decide whether to use the independent variable or return to Step 1.

[0018] According to a preferred embodiment of the present invention, the metadata in step 2 includes: indicator identifier, name-related elements such as full name and abbreviation in Chinese and English, indicator DAG information, data type, update frequency of the data service itself, indicator data format enum: [Scalar, Tuple, Data Frame], whether it is reference data, reference data value range space, unit, currency, whether it is master data, data precision, explanation of business meaning, calculation formula, R&D status, accountability status, accountability stakeholder information, etc.

[0019] According to a preferred embodiment of the present invention, the parent node includes an asset management domain concept system, and the child nodes corresponding to the parent node include securities, parties, regions, customers, dates, channels, products and services, and industries. Each of the child nodes also serves as a new parent node, including other child nodes.

[0020] According to a preferred embodiment of the present invention, step 4 is further included, forming a table T based on the identified independent variables, the table T comprising: )and ,in,

[0021] R represents a relation, F represents a function, C represents an independent variable, subscripts 1-n correspond to the number of independent variables and the distinct independent variables, and 1-m represent the business primary key of the table.

[0022] This invention also proposes a data automation service, namely the above-mentioned unified business and technology data language construction method.

[0023] According to a preferred embodiment of the present invention, the method further includes step I: describing the requirements, i.e., the expression based on the domain language model, through a human-computer interface or by writing a DSL script, and sending it to the server; step II: after receiving the requirements, the server performs lexical and semantic analysis on them.

[0024] According to a preferred embodiment of the present invention, step II includes: a) obtaining, through lexical analysis, a list of indicators for the demand request and parameter settings for the demand request; b) obtaining the parameter settings for each indicator based on the input parameters of the dataset and the parameter mapping rules of the domain model; c) generating an orchestrated and optimized data retrieval demand expression through semantic analysis; d) executing the data request and performing automated data assembly; e) analyzing the actual data situation in terms of concepts, relationships, and instances based on the data results, and providing an intelligent data layout scheme, which can also support users to define the data layout scheme by submitting specified settings to determine the final returned dataset structure; f) returning the final dataset to the requester through the API.

[0025] According to a preferred embodiment of the present invention, the method further includes g) an automatic display step: performing a corresponding layout based on the characteristics of the independent variable, the characteristics including: order and transpose.

[0026] According to a preferred embodiment of the present invention, the method further includes step h): controlling specific parameters for each independent variable, wherein the parameters include: single_col: whether to occupy a column independently; Flat2indicator: whether to flatten the component into the index; if true, the component will no longer occupy a column independently; only one of this parameter and single_col needs to be set; treeHeader: whether the row and column index names of the dataset should use a tree structure; layerLevel: if it is a tree structure index name structure, this parameter specifies the height of the component in the tree hierarchy.

[0027] According to a preferred embodiment of the present invention, a unified and consistent data service API is included, defined as: Query(Indicator_Identifier=I1, Parameters= This query interface requires two parameters: Indicator_Identifier and Parameters.

[0028] Thus, the technical solution of this invention achieves the following: designing a domain language model for the asset management data domain, bridging the gap between the ER model and business operations, and becoming a unified and standard communication language between asset management business personnel and data engineers. This expression model needs to fully standardize business information to ensure that data services can be automated based on it; based on this domain language model, realizing the automated assembly and intelligent layout of data requirement datasets; solving the parameter mapping problem between the input parameters of the requirement dataset and the domain language model; and providing a unified and consistent data service API based on the domain language model. Attached Figure Description

[0029] Figure 1 Example diagram of the concept tree of the asset management domain;

[0030] Figure 2 System schematic logic diagram;

[0031] Figure 3 Schematic diagram of indicator metadata model;

[0032] Figure 4 Automated data assembly and intelligent layout are achieved based on indicator metadata.

[0033] Figure 5 Data requirement: mapping management between dataset input parameters and indicator parameters. Detailed Implementation

[0034] A method for constructing a unified business and technology data language includes the following steps:

[0035] Step 1: Specify the independent variables based on the business model and the indicator meta-model;

[0036] Step 2, perform the following operations on the specified independent variables to ensure compliance with the domain language model of the asset management data domain:

[0037] The independent variable is checked to determine whether it corresponds to a concept or class in the asset management domain and whether it corresponds to metadata.

[0038] Whether the independent variable forms a parent node and a child node and is therefore used for association calculation;

[0039] Step 3: Decide whether to use the independent variable or return to Step 1.

[0040] According to a preferred embodiment of the present invention, the metadata in step 2 includes: indicator identifier, name-related elements such as full name and abbreviation in Chinese and English, indicator DAG information, data type, update frequency of the data service itself, indicator data format enum: [Scalar, Tuple, Data Frame], whether it is reference data, reference data value range space, unit, currency, whether it is master data, data precision, explanation of business meaning, calculation formula, R&D status, accountability status, and accountability stakeholder information.

[0041] exist Figure 3 As can be seen, a logical diagram is laid out in an orderly manner around the indicator metadata.

[0042] like Figure 1 As shown, according to a preferred embodiment of the present invention, the parent node includes an asset management domain concept system, and the child nodes corresponding to the parent node include securities, parties, regions, customers, dates, channels, products and services, and industries. Each of the child nodes also serves as a new parent node, including other child nodes. Figure 1 As shown.

[0043] According to a preferred embodiment of the present invention, step 4 is further included, forming a table T based on the identified independent variables, the table T comprising: )and ,in

[0044] R represents a relation, F represents a function, C represents an independent variable, subscripts 1-n correspond to the number of independent variables and the distinct independent variables, and 1-m represent the business primary key of the table.

[0045] like Figure 2 As shown, this invention also proposes a data automation service, including the aforementioned method for constructing a unified business and technology data language. Figure 4 The flowchart shows the process from requirement submission to delivery. First, the data requirement is formally expressed and submitted using data language. Then, the independent variables of the indicators are standardized and calculated to obtain the standard concept in the asset management domain concept space as the independent variable, denoted as B_Key(indicator_i). Then, Union(B_Key(indicator_i)) is formed, where i is all the requirement indicators involved in the requirement. Next, the indicator data is extracted and the default layout is performed according to Union(B_Key(indicator_i). If the user has layout requirements, the API delivery data is formed according to their requirements, or the API delivery data is formed directly according to the recommended layout.

[0046] Figure 5This demonstrates the mapping management between input parameters and indicator parameters of the data requirement dataset. First, the values ​​of the independent variables in the requirement dataset are defined, for example, D1:p1, D2:p2', ..., Dn:pn. Then, a tool is used to list the requirement indicators and their independent variables. A commonly used function mapping template library is called to define the mapping for each independent variable component of the indicator, represented as a function mapping of the basic requirement dataset independent variables, denoted as Func-mapping(D1:p1, D2:p2', ..., Dn:pn). Next, testing and verification are performed, and finally, the configuration is completed to provide API services.

[0047] According to a preferred embodiment of the present invention, the method further includes step I: describing the requirements, i.e., the expression based on the domain language model, through a human-computer interface or by writing a DSL script, and sending it to the server; step II: after receiving the requirements, the server performs lexical and semantic analysis on them.

[0048] According to a preferred embodiment of the present invention, step II includes: a) obtaining, through lexical analysis, a list of indicators for the demand request and parameter settings for the demand request; b) obtaining the parameter settings for each indicator based on the input parameters of the dataset and the parameter mapping rules of the domain model; c) generating an orchestrated and optimized data retrieval demand expression through semantic analysis; d) executing the data request and performing automated data assembly; e) analyzing the actual data situation in terms of concepts, relationships, and instances based on the data results, and providing an intelligent data layout scheme, which can also support users to define the data layout scheme by submitting specified settings to determine the final returned dataset structure; f) returning the final dataset to the requester through the API.

[0049] According to a preferred embodiment of the present invention, the method further includes g) an automatic display step: performing a corresponding layout based on the characteristics of the independent variable, the characteristics including: order and transpose.

[0050] According to a preferred embodiment of the present invention, the method further includes step h): controlling specific parameters for each independent variable, wherein the parameters include: single_col: whether to occupy a column independently; Flat2indicator: whether to flatten the component into the index; if true, the component will no longer occupy a column independently; only one of this parameter and single_col needs to be set; treeHeader: whether the row and column index names of the dataset should use a tree structure; layerLevel: if it is a tree structure index name structure, this parameter specifies the height of the component in the tree hierarchy.

[0051] According to a preferred embodiment of the present invention, a unified and consistent data service API is included, defined as: Query(Indicator_Identifier=I1, Parameters= This query interface requires two parameters: Indicator_Identifier and Parameters.

[0052] The method of the present invention achieves the following technical effects:

[0053] Business and data engineers communicate using domain-specific languages ​​to improve communication efficiency.

[0054] The domain model of metrics fills the gap in expressive capabilities between business logic and DBMS, and can support the automation of data services.

[0055] This democratizes data services within enterprises or organizations, promotes digital transformation, improves the efficiency and breadth of data resource utilization, and ultimately empowers business operations. Furthermore, domain-based indicator models can effectively support fine-grained (cell-level) data access control.

[0056] The following explains the terms and mathematical formulas involved: Definitions of terms,

[0057] Concept: Also often called a class, it refers to anything we care about or observe. It is a collection of all objects within a domain, that is, a space composed of all things and objects. In the asset management field, the set of things we care about and want to observe is the asset management domain concept set, denoted as C: {C1, C2, C3, ..., Cn};

[0058] Relationship: The interaction between concepts in a domain; all objects described by observed data in relational model data tables. Formally, the value space of a relation is a Cartesian product of multiple concepts, i.e., R: C1×C2×...×C_n, such as the relation "securities code×date", "stock code×date×closing price", etc.

[0059] A function is a special type of relation, such as relation R: C1×C2×...×C_n. From a function perspective, it can be understood as a mapping from C1×C2×...×C_(n-1) to C_n. It can be converted into a many-to-one or one-to-one mapping in the number field, which can be expressed as: C_n = F(C1,C2,...,C_(n-1)), representing the mapping from relation C1×C2×...×C_(n-1) to relation C_n.

[0060] Instance: refers to the instantiated element of a concept in the real world, that is, a specific instance of a thing. The value space of a concept is composed of all possible instances, and the value set of a concept in reality is composed of the actual instances that appear.

[0061] Indicator: A certain measure of the object described by the data to be observed. The space of all indicators in the asset management domain is denoted as I. An indicator Indicator in this space can be represented as Indicator = F(C1,C2,...,C_n), R: C1×C2×...×C_n is the object to be observed by the indicator. Let B_Key(Indicator) = (C1,C2,...,C_n).

[0062] Indicator Metadata Model: The indicator space of the asset management domain is denoted as I. Within this space, an indicator Indicator = F(C1,C2,...,C_n), where C1×C2×...×C_n represents the relationship measured by the indicator, i.e., the object described by the indicator observation data, which is precisely the relationship formed by the Cartesian product of a series of concepts. From a functional perspective, (C1,C2,...,C_n) is the vector of independent variables for the indicator, where each component is a concept or class within the asset management domain.

[0063] The following describes and defines the indicator metamodel from multiple aspects: The metadata items of the indicator include, but are not limited to, the following: indicator identifier, name-type elements, such as full name and abbreviation in Chinese and English, indicator DAG information, data type, update frequency of the data business itself, indicator data format, enum: [Scalar, Tuple, Data Frame], whether it is reference data, reference data value range space, unit, currency, whether it is master data, data precision, explanation of business meaning, calculation formula, R&D status, accountability status, and accountability stakeholder information.

[0064] The standardized definition of the asset management domain concept system is C_Std : {C1_Std, C2_Std, C3_Std, ..., Cn_Std}. Based on the asset management domain business system, a unified standard definition is established for related concept systems, forming a tree-structured concept system. For example... Figure 1 The example shown is as follows: The node space of this tree is C_std. For any node C_(i_std) in the space, its parent node concept can be obtained: C_(j_std) = parent(C_(i_std)). Semantically, different indicators can be calculated by the JOIN operator if the components in the independent variable vector belong to the same concept.

[0065] Determining the composition of independent variables for metrics based on the essence of the business: This is the data standard definition process, which requires manual intervention. By analyzing and defining data business processes, and structuring them using a domain-specific language model, the essence of the data metrics can be expressed.

[0066] Typically, business personnel can specify independent variables based on their understanding of the indicator meta-model and the business aspects of the indicator. When necessary, data engineers need to participate in the communication to ensure that they have a precise understanding of the connotation of the indicator and the conceptual system in the domain model, so as to ensure that the business model can be accurately mapped to the indicator meta-model.

[0067] Metadata definition for indicator management: such as the department and personnel responsible for indicator business standards, the department and personnel responsible for indicator development, the department and personnel responsible for indicator quality management standards, etc.

[0068] like Figure 2 The data retrieval devices for the indicators and data storage system shown here, after defining the asset management domain indicator space under the domain language model, need to be implemented. This section uses RDBMS as an example to explain the technical implementation of the data retrieval device.

[0069] Suppose an RDBMS has a table T1, which can be formally defined as: T : (R∶ C1×C2×...×C_n). Assuming that 〖C_1~C_m〗 is the business primary key of this table, it can be further refined formally as: T: F(R∶C1,C2,...,C_m)→(C_(m+1),...,C_n), i.e.: (C_(m+1),...,C_n) = F(C1,C2,...,C_m). For a certain indicator, assuming it is a component in the returned results, it is denoted as: Indicator = C_i = F(C1,C2,...,C_m). Through the above transformation, indicator data retrieval is achieved at the theoretical level of the model. However, in actual engineering, many problems need to be solved. Common issues include: the business primary keys in the DBMS tables may be unclear or inaccurate. This needs to be analyzed and handled properly in the data retrieval device to ensure that the transformation strictly follows the domain model specifications. The primary keys of tables in the DBMS have inconsistent and non-standard naming issues, which need to be mapped to the standardized definition of the asset management domain concept system. Indicator = C_i = F(C1,C2,...,C_m)= C_(i_std) = Func_mapping( F(C1,C2,...,C_m) )= F(C_(1_std),C_(2_std),...,C_(m_std)).

[0070] If the table structure does not meet the requirements of the third normal form (3NF), an analysis and judgment should be made according to the specification of the indicator domain model. Some attribute columns with primary key dependencies or transitive dependencies should be excluded, and the remaining columns that meet the requirements of the third normal form should be included in the indicator domain model. For redundant columns or columns with transitive dependencies, the correct and three-normal-form relationships of the attribute column should be found, and the data retrieval device should be designed based on these relationships.

[0071] Attribute columns may lack consistency and uniformity in their definitions. For example, the definition of a behavior in an attribute column may be A before a certain historical point in time, but it may be changed to B later. According to the definition of the indicator domain model, A and B are two indicators. The data retrieval device should be set based on this to ensure the consistency and accuracy of the indicator domain language model.

[0072] In extreme cases, where the data model design in the storage system is poor, it is recommended to redefine the dataset model and then map it to the metric domain language model, i.e., configure the data retrieval device. Essentially, this involves fixing the flaws in the storage model design.

[0073] Data service automation: The automated assembly and intelligent layout of data demand datasets, based on data storage models completed by data retrieval devices, is standardized into indicator domain models. Then, Union Operator operations are performed: Given a standard indicator Indicator = F(C1,C2,...,C_n), where (C1,C2,...,C_n) is the indicator's independent variable vector, each component being a concept or class in the asset management domain. A dataset is a collection of indicators; when different indicators share the same independent variable vector, i.e., act on the same concept or class, they can be represented as a dataset.

[0074] How do we determine whether different indicators have the same independent variable vector? Through the standardized model, we can obtain Indicator = F(C_(1_std),C_(2_std),...,C_(m_std)).

[0075] Assuming Indicator1 = F(C_(1_std),C_(2_std),...,C_(m_std))=F(B_Key(Indicator1) ) , Indicator2 = F(C_(1_std),C_(2_std),...,C_(n_std)) = F(B_Key(Indicator2) ), and (C_(1_std),C_(2_std),...,C_(m_std)) intersects with (C_(1_std),C_(2_std),...,C_(n_std)) (i.e., the intersection is not empty), then Indicator1 and Indicator2 can be applied to the same concept or class and displayed as a dataset through a Join operation. Similarly, multiple indicators that satisfy the above conditions can be displayed as a dataset.

[0076] When requesting indicator data, the independent variable vector of the indicator needs to be specified, that is, the instance space of the indicator observation object needs to be determined, and the value space mapped to the value range space is obtained accordingly: Single indicator data request: Indicator_dataset = F(c1,c2,...,c_n) = {Indicator:paras}, c_i is a subset of the instance value space of C_i, paras =(c1,c2,...,c_n).

[0077] Multi-indicator dataset request: Indicators_dataset = {Indicator1: paras1, Indicator2: paras2, …, Indicatorn: parasn}, Paras = Paras_customize(B_Key(Indicatori)), that is, the parameter settings of indicator Indicatori are formed by setting the parameters of the indicator B_key vector one by one.

[0078] Based on the aforementioned calculation logic: B_Key(Indicators_dataset) = U(B_Key(Indicator1), B_Key(Indicator2), B_Key(Indicator3), ... , B_Key(Indicatorn) ), the solution yields the independent variable vector of the series of indicator demand datasets, denoted as (C_(1_std),C_(2_std),...,C_(m_std)).

[0079] Once the dataset's independent variables (C_(1_std), C_(2_std), ..., C_(m_std)) are determined and data extraction is performed, the dataset can be automatically laid out based on the characteristics of each component, i.e., intelligent layout: for example, dates can be arranged sequentially, and conversions between different year, month, and day formats can be performed. If a component has transpose properties, the dataset can also be transposed according to that component to meet different user needs for dataset display.

[0080] Users can also specify layout requirements and control the data layout definition by setting parameters. In terms of form, it is: Indicators_dataset_layout_customize_paras = {C_(1_std) ∶ (single_col=,flat2Indicator=,treeHeader=,layerLevel = ),C_(2_std),...,C_(m_std)}.

[0081] Each component has the same parameter controlling the attribute; for simplicity, only one is written above.

[0082] Parameter explanations: single_col: whether to occupy a separate column; Flat2indicator: whether to flatten the component into the indicator. If true, the component will no longer occupy a separate column. Only one of this parameter and single_col needs to be set; treeHeader: whether to use a tree structure for the row and column index names of the dataset; layerLevel: if it is a tree structure index name structure, this parameter specifies the height of the component in the tree.

[0083] A unified and consistent data service API is defined based on the API specification of the indicator domain model: Given a standard indicator Indicator = F(C1,C2,...,C_n), where (C1,C2,...,C_n) is the indicator's independent variable vector, each component being a concept or class in the asset management domain. The parameters required to query an indicator are then the indicator's independent variable vector. The unified interface for querying indicators can be defined as Query(Indicator_Identifier=I1, Parameters= (C1=A,C2=B,...,C_n=X)). It is clear that the query interface requires two parameters: the indicator identifier (Indicator_Identifier) ​​and the indicator parameters (Parameters). The indicator identifier is clearly defined in the standardized domain model; it belongs to the indicator's metadata information and can uniquely identify an indicator, i.e., it is the primary key of the indicator's metadata. The indicator parameters are the indicator's independent variable vector; the values ​​of the independent variables determine the indicator value. Therefore, by inputting the indicator identifier and the independent variable vector values, the query interface can return one or more indicator values. In the indicator parameters, the values ​​of the independent variables can be either scalars or vectors. When all component values ​​are scalars, a unique indicator value is returned, with the data type being the indicator data format in the indicator metadata. The returned indicator value data is uniformly returned in array format, where each element contains an independent variable vector and an indicator, i.e., (C1, C2, ..., C_n, Indicator). All element values ​​are returned in scalar or tuple form. If some indicators return as Data Frames, they are represented in a nested structure, similar to drill-down detail data. The parameter mapping management and maintenance mechanism for the requirement dataset input parameters and the domain model is as follows: Assume the request API specification of the requirement dataset Req_dataset is: Req_dataset(dst_identifier, Paras_dst), Paras_dst = [p_1,p_2,...,p_n], which corresponds to the independent variable vector (D1,D2,...,D_n) of the requirement dataset, i.e., Req_dataset_result = F(D1:p_1,D2:p_2,...,D_n:p_n). This is because the final data acquisition of Req_dataset needs to be converted to: {Indicator1: paras1, Indicator2: paras2, …, Indicatorn: parasn}, Paras = Paras_customize(B_Key(Indicatori)).Therefore, it is necessary to maintain the mapping rules between the input variables of the dataset and the parameters of the list of indicators involved in the dataset. That is, for any i: Parasi = Func_mapping(D1:p_1,D2:p_2,...,D_n:p_n), in the asset management domain space, common Func_mapping methods include: Equal, adding or subtracting constants based on the (D1,D2,...,D_n) parameters, setting a fixed value for a certain component of the indicator key, completing the mapping through a custom function UDF, and converting the global parameters of the dataset into the parameters of each queryable indicator through the function mapping between the dataset parameters and the domain model parameters, and returning the dataset through the indicator assembly service to realize the query of the dataset containing parameters.

[0084] The automated data service process includes: users describing their needs (i.e., expressions based on the domain language model) through a human-computer interface or by writing DSL scripts and sending them to the server; upon receiving the needs, the server performs lexical and semantic analysis: lexical analysis yields a list of requested metrics and parameter settings; parameter settings for each metric are calculated based on the dataset input parameters and the parameter mapping rules of the domain model; semantic analysis generates an orchestrated and optimized data retrieval requirement expression; the data request is executed and automated data assembly is performed; based on the data results analysis of the actual data situation in terms of concepts, relationships, and instances, an intelligent data layout scheme is provided, or users can define the data layout scheme by submitting specified settings to determine the final returned dataset structure; the final dataset is returned to the requester via API.

[0085] The present invention has been described exemplarily above with reference to the accompanying drawings. However, any technical solution formed by changes, combinations and additions of features under the guidance of the concept of the present invention shall fall within the protection scope of the present invention without departing from the protection scope of the claims.

Claims

1. A method for constructing a unified business and technology data language for the financial asset management field, to build a domain language model for defining and calculating financial data indicators, comprising the following steps: Step 1: Specify the independent variables based on the financial asset management business model and the indicator meta-model; Step 2, perform the following operations on the specified independent variables to ensure that they conform to the domain language model of the financial asset management data domain: whether the independent variable corresponds to a concept or class in the financial asset management data domain and detect whether it corresponds to metadata; whether the independent variable forms parent and child nodes and therefore performs association calculations. Step 3: Determine whether to use the independent variable or return to Step 1; The metadata in step 2 includes: The indicator includes the Identifier, name-related elements, indicator DAG information, data type, update frequency of the data business itself, indicator data format (enum: [Scalar, Tuple, Data Frame]), whether it is reference data, reference data value range, units, currency, whether it is master data, data precision, business meaning description, calculation formula, R&D status, accountability status, and accountability stakeholder information; the name-related elements include the full name and abbreviation in Chinese and English. The parent node represents the financial asset management data domain concept system. The child nodes corresponding to this parent node include securities, parties involved, regions, customers, dates, channels, products and services, and industries. Each child node can also serve as a new parent node, including other child nodes. Also included is step 4, forming a table T from the identified independent variables, the table T comprising: and ; Where R represents a relation, F represents a function, C represents an independent variable, subscripts 1 to n correspond to the number of independent variables and the distinct independent variables, and subscripts 1 to m represent the business primary key of the table.

2. A data automation service method, characterized by, include: Step 1: Describe the requirements through a human-computer interface or by writing a DSL script, i.e., an expression based on a domain language model, and send it to the server. The domain language model is obtained by the data language construction method for unified business and technology in the field of financial asset management as described in claim 1. Step II: After receiving the request, the server performs lexical and semantic analysis on it.

3. The data automation service method of claim 2, wherein, Step II includes: a) Lexical analysis yielded: a list of metrics for the demand request and parameter settings for the demand request; b) Calculate the parameter settings for each metric based on the input parameters of the dataset and the parameter mapping rules of the domain model; c) Generate an optimized data retrieval requirement expression through semantic analysis; d) Execute data requests and perform automated data assembly; e) Based on the data results analysis, the actual data situation in terms of concepts, relationships, and instances is analyzed, and an intelligent data layout scheme is given. Users can also define the data layout scheme by submitting a specified setting scheme to determine the final returned dataset structure. f) Return the final dataset to the requester via API.

4. The data automation service method of claim 3, wherein, It also includes g) an automatic display step: performing a corresponding layout based on the characteristics of the independent variable, the characteristics of which include: order and transpose.

5. The data automation service method according to claim 4, characterized in that, It also includes step h): controlling specific parameters for each independent variable. These parameters include: single_col: whether to occupy a separate column; Flat2indicator: whether to flatten the component into the indicator. If true, the component will no longer occupy a separate column. Only one of this parameter and single_col needs to be set; treeHeader: whether to use a tree structure for the row and column index names of the dataset; layerLevel: if it is a tree structure index name structure, this parameter specifies the height of the component in the tree.

6. The data automation service method according to claim 2, characterized in that, This includes a unified and consistent data service API, defined as follows: You need to pass in the indicator identifier name Indicator_Identifier and the indicator parameters Parameters.

Images