Data expression method, device, equipment and storage medium

Abstract

Embodiments of this specification provide a data expression method, apparatus, device, and medium. The method includes: pre-storing common data for all transactions in a common data storage space; upon receiving a transaction expression request for a particular transaction, directly retrieving the common data for that transaction from the common data storage space based on the common intermediate fields of the transaction; and simultaneously retrieving the individual data for that transaction from pre-acquired source transaction data based on the individual intermediate fields of the transaction. Data processing is performed on the common data and individual data to obtain transaction data, and the transaction data is encapsulated using a transaction expression method to obtain the expression data for that transaction.

Description

Technical Field

[0001] This specification relates to the field of data application, and more specifically, to a data expression method, apparatus, device, and storage medium in the field of data application. Background Art

[0002] In the field of data applications, source data is expressed through multiple transactions. However, since each transaction has different transaction expression requirements and focuses on different data expression, in order to meet the transaction expression requirements of each transaction, the source data needs to be processed accordingly. However, since the transaction expression requirements of all transactions may contain a lot of cross-reuse intermediate logic, when processing the source data, the same data processing is often performed multiple times for a specific requirement indicator. This method lacks sustainability, increases the computational complexity of data processing, and reduces data expression efficiency. Summary of the Invention

[0003] This specification provides a data expression method, apparatus, device and storage medium, which can pre-store the common data of all transactions in a common data storage space, separate data processing from data expression, achieve sustainability of data processing, reduce the computational complexity of data processing, and improve data expression efficiency.

[0004] In a first aspect, an embodiment of this specification provides a data expression method, the method comprising:

[0005] In response to a transaction expression request of a first transaction, determining a common middle field and a unique middle field of the first transaction, where the common middle field is determined based on matching a first requirement field of the first transaction with a second requirement field of a second transaction, and the second transaction is a transaction other than the first transaction in the transaction system;

[0006] Acquire common data corresponding to the first transaction in a common data storage space based on the common intermediate field, where the common data storage space is used to store common data corresponding to the common intermediate field between the first transaction and the second transaction;

[0007] Obtaining, based on the individual middle field, individual data corresponding to the first transaction from the pre-acquired source transaction data;

[0008] Performing data processing on the common data and the individual data based on the transaction expression requirement of the first transaction to obtain transaction data of the first transaction;

[0009] The transaction data is encapsulated based on the transaction expression mode of the first transaction to obtain the expression data of the first transaction.

[0010] In a second aspect, an embodiment of this specification provides a data presentation device, the device comprising:

[0011] an intermediate field determination unit, configured to determine, in response to a transaction expression request of a first transaction, a common intermediate field and a unique intermediate field of the first transaction, wherein the common intermediate field is determined based on matching a first requirement field of the first transaction with a second requirement field of a second transaction, and the second transaction is a transaction other than the first transaction in the transaction system;

[0012] A common data acquisition unit, configured to acquire common data corresponding to the first transaction from a common data storage space based on the common intermediate field, the common data storage space being configured to store common data corresponding to the common intermediate field between the first transaction and the second transaction;

[0013] A personality data acquisition unit, configured to acquire personality data corresponding to the first transaction from pre-acquired source transaction data based on the personality intermediate field;

[0014] a transaction data acquisition unit, configured to process the common data and the individual data based on the transaction expression requirement of the first transaction to obtain transaction data of the first transaction;

[0015] The data expression unit is used to encapsulate the transaction data based on the transaction expression method of the first transaction to obtain the expression data of the first transaction.

[0016] In a third aspect, an embodiment of this specification provides a computer device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program implements the steps of the above method when executed by the processor.

[0017] In a fourth aspect, an embodiment of this specification provides a storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of the above method are implemented.

[0018] In a fifth aspect, an embodiment of this specification provides a computer program product, comprising: a computer program, which, when executed by a processor of a computer device, enables the processor to at least implement the method of the first aspect.

[0019] In an embodiment of the present specification, the common data of all transactions are stored in a common data storage space in advance. When a transaction expression request for a certain transaction is received, the common data of the transaction is directly obtained from the common data storage space according to the common intermediate fields of the transaction. At the same time, the individual data of the transaction is obtained from the pre-acquired source transaction data according to the individual intermediate fields of the transaction. Data processing is performed on the common data and the individual data to obtain transaction data, and the transaction data is encapsulated through a transaction expression method to obtain the expression data of the transaction. This method stores the common data of all transactions in a common data storage space in advance. When expressing data for the transaction, data processing is separated from data expression, so that some processed data can be continuously used by multiple transactions, thereby achieving sustainability of data processing, reducing the computational load of data processing, and improving data expression efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0021] Figure 1 This is a flowchart of a data expression method in a related technology provided by an embodiment of this specification;

[0022] Figure 2 This is a system architecture diagram of a data expression method provided in an embodiment of the present application;

[0023] Figure 3 This is a flow chart of a data expression method provided in an embodiment of this specification;

[0024] Figure 4 This is a flowchart of a common data acquisition method provided in an embodiment of this specification;

[0025] Figure 5 This is a flowchart of a method for obtaining personality data provided by an embodiment of this specification;

[0026] Figure 6 This is a schematic diagram of the structure of a data expression device provided in an embodiment of this specification;

[0027] Figure 7 This is a structural diagram of a computer device provided in an embodiment of this specification. DETAILED DESCRIPTION

[0028] The following will be combined with the drawings in the embodiments of this specification to clearly and completely describe the technical solutions in the embodiments of this specification. Obviously, the embodiments described are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without making any creative efforts are within the scope of protection of this specification.

[0029] The data expression method provided in the embodiments of this specification is applicable to data application scenarios. Data application aims to realize the conversion of data into transactions. Its core application scenarios include financial technology, e-commerce, medical health, logistics supply chain, education technology, media entertainment and other industry scenarios.

[0030] See Figure 1 , Figure 1 This is a flow chart of a data expression method in a related technology provided by an embodiment of this specification. Figure 1 As shown, in the related technology, the data application scenario includes multiple transactions, such as transaction 1, transaction 2, ... transaction n. When expressing data for each transaction, it is necessary to obtain the source transaction data of each transaction separately, that is, the unprocessed original data generated by each transaction, such as user identification (ID), transaction time, account login location, and other data. According to the transaction expression requirements of each transaction, the corresponding source transaction data is processed to obtain the intermediate data required to obtain its transaction data. The intermediate data is then processed to obtain the transaction data corresponding to each transaction, and the transaction data is expressed for each transaction. Among them, the transaction data is determined according to the transaction expression requirements of each transaction, directly serving the front-end application, decision support and transaction operations, and has a high degree of customization and scenario-based characteristics. Therefore, the transaction data of each transaction is differentiated data.

[0031] However, since there may be a lot of cross-reuse intermediate logic in the transaction expression requirements of each transaction, when processing the source transaction data, the same data processing is often performed multiple times for a certain requirement indicator. Therefore, the intermediate data of each transaction may contain data that it shares with at least one other transaction, that is, the intermediate data includes both individual data unique to each transaction and common data shared with at least one other transaction. Based on this, the transaction expression method in the related art lacks sustainability when obtaining intermediate data, increases the computational complexity of data processing, and reduces the efficiency of data expression.

[0032] Based on the above problems, this specification provides a data expression method. Figure 2 , Figure 2 This is a system architecture diagram of a data expression method provided by the embodiment of this specification. Figure 2As shown, the embodiment of this specification implements the data expression of each transaction in the data application scenario through a three-layer data model according to the data processing flow in the data expression method and the hierarchical architecture of the basic layer-middle layer-polymorphic layer.

[0033] The foundation layer is used to collect and store source transaction data for the transaction system consisting of all transactions in the data application scenario. Based on the mapping relationships between source transaction data, the foundation layer stores source transaction data in the form of source data tables. It is understood that due to the diversity of transactions, each transaction generates at least one source data table, and the foundation layer will store multiple source data tables.

[0034] The middle layer is used to close the similar caliber of each transaction. After determining the common data in the intermediate data required by each transaction in the data application scenario, the data processing logic performed by each transaction to obtain the common data is unified. The middle layer calls the source transaction data required for each common data from the basic layer according to the unified data processing logic, performs corresponding data processing on the called source transaction data, obtains each common data and saves each common data.

[0035] The polymorphic layer is used to express transaction data and perform visual interaction. Since the transaction data of each transaction is differentiated data, when obtaining transaction data, the polymorphic layer calls the common data required by each transaction from the middle layer and the individual data required by each transaction from the basic layer, and processes the common data and individual data to obtain differentiated transaction data. In order to maximize the value of transactions, the transaction characteristics, user needs, cost-effectiveness, and system capabilities of each transaction are comprehensively considered to determine the transaction expression method that matches each transaction. This allows the polymorphic layer to express transaction data based on the transaction expression method and transaction data corresponding to each transaction. Among them, the transaction expression method is a method of providing visual interaction for each transaction, including data integration report (DI) reports, data display views, broadcasts, user unified interaction platforms, external interfaces, and other methods.

[0036] For example, let's take an e-commerce scenario as an example. Assuming that the e-commerce scenario includes security risk control transactions, business indicator transactions, and R&D transactions, the source transaction data generated by security risk control transactions, business indicator transactions, and R&D transactions is stored in the base layer in the form of source data tables. The base layer stores multiple source data tables, each of which includes mutually mapped data, named fields in the code, data types, and data values. Source data tables in e-commerce scenarios include, but are not limited to, user behavior log tables, transaction flow tables, order details tables, and system log tables. The user behavior log table is used to record the user's full-link behavior (login, payment, browsing), and construct risk characteristics through dimensions such as device fingerprint, IP, and geographic location, including data such as user ID, event type, device ID, event occurrence time, operation IP address, and account login location; the transaction flow table is used to associate user behavior with transaction data, including data such as user ID, merchant ID, order ID, transaction amount, transaction time, payment method, and whether a refund is required; the order details table is used to split the order and product dimensions and support the calculation of operating indicators, including order ID, product ID, purchase quantity, product unit price, discount amount, order creation time, order status (pending payment, completed, refunded, etc.); the system log table is used to collect full-link service logs and support system fault location and performance analysis, including log ID, service name, log level, log content, log time, server IP, and other data. Taking the user behavior log table as an example, please refer to Table 1, which is an example schematic diagram of a source data table in a base layer provided in an embodiment of the present application.

[0037] Table 1

[0038]

[0039] If at least two of the following transactions—security risk control transactions, operational indicator transactions, and R&D transactions—share common intermediate data, then this common intermediate data is common data in e-commerce scenarios. Taking security risk control transactions and operational indicator transactions as examples, the transaction expression requirements for security risk control transactions are to ensure transaction security, user privacy, and compliance on e-commerce platforms, and to prevent risks such as fraud and data leakage. Based on an analysis of the transaction expression requirements for security risk control transactions, the transaction data ultimately expressed by security risk control transactions includes data such as risky user IDs and the number of risky transaction interceptions. The intermediate data required to obtain transaction data for security risk control transactions includes data such as account login location, account transaction frequency, transaction amount, and user profile tags. The transaction expression requirements for operational indicator transactions are to optimize operational efficiency, user experience, and profitability. Based on an analysis of the transaction expression requirements for operational indicator transactions, the transaction data ultimately expressed by operational indicator transactions includes data such as product profit, conversion rate, user repurchase rate, and marketing return rate. The intermediate data required to obtain transaction data for operational indicator transactions includes data such as user behavior data, user profile tags, account transaction frequency, and transaction amount. User profile tags categorize users based on their spending levels and habits, and then assign tags based on these categorizations, such as high-spending users, low-spending users, and electronics enthusiasts. Account transaction frequencies include high, medium, and low frequencies, determined by the number of transactions a user makes in a given day, week, month, or year. The transaction amount is the amount of each order in a user's account. Therefore, security risk control transactions share common data with operational indicator transactions. The data stored in the middle layer includes, but is not limited to, user profile tags, account transaction frequency, and transaction amount.

[0040] In an embodiment of the present specification, the common data of all transactions are stored in a common data storage space in advance. When a transaction expression request for a certain transaction is received, the common data of the transaction is directly obtained from the common data storage space according to the common intermediate fields of the transaction. At the same time, the individual data of the transaction is obtained from the pre-acquired source transaction data according to the individual intermediate fields of the transaction. Data processing is performed on the common data and the individual data to obtain transaction data, and the transaction data is encapsulated through a transaction expression method to obtain the expression data of the transaction. This method stores the common data of all transactions in a common data storage space in advance. When expressing data for the transaction, data processing is separated from data expression, so that some processed data can be continuously used by multiple transactions, thereby achieving sustainability of data processing, reducing the computational load of data processing, and improving data expression efficiency.

[0041] based on Figure 2 The system architecture diagram shown below will be combined with Figure 3-Figure 5 , the data expression method provided in the embodiments of this application is introduced in detail.

[0042] See Figure 3 , Figure 3 This is a flow chart of a data expression method provided in the embodiment of this specification. Figure 3 As shown, the method of the embodiment of this specification may include the following steps S102 to S110.

[0043] S102, in response to a transaction expression request of a first transaction, determining a common middle field and a unique middle field of the first transaction;

[0044] Specifically, when a transaction expression request for a first transaction is received, the common intermediate fields and individual intermediate fields of the first transaction are determined in response to the transaction expression request of the first transaction. The transaction expression request is used to determine the transaction that currently requires data expression. The common intermediate fields are determined based on matching the first requirement field of the first transaction with the second requirement field of the second transaction, the individual intermediate fields are the remaining intermediate fields in the first requirement field except the common intermediate fields, and the second transaction is the remaining transaction in the transaction system except the first transaction. As can be seen from the above, the common intermediate fields and individual intermediate fields are determined before the data expression of the transaction is performed. Therefore, when the transaction expression request for the first transaction is received, the common intermediate fields and individual intermediate fields of the first transaction are directly determined.

[0045] Here, "field" refers to the name of the data in the code. For example, if the data is a user ID, its field can be "user-id." The "requirement field" includes the transaction data field of the transaction data ultimately expressed by the transaction, as well as the intermediate data fields obtained by tracing the data lineage of the transaction data field. After obtaining the intermediate data fields, data dictionary technology is used to clarify the meaning of each intermediate data field. The meanings of the intermediate data fields of all transactions are matched, and intermediate data fields with the same meaning are identified as common intermediate fields. The requirement field is obtained based on the transaction expression requirements of the transaction, which are the goals of each transaction. Intermediate data refers to the data required before the transaction data is obtained. Intermediate data includes common data and individual data. The intermediate data field refers to the name of the intermediate data in the code, and the common intermediate field refers to the name of the common data in the code. The common intermediate fields and individual intermediate fields of a transaction together constitute the intermediate data fields of that transaction. It should be noted that if the intermediate data of a first transaction matches the intermediate data of at least one transaction in a second transaction, the intermediate data is identified as common intermediate data.

[0046] For example, assume that the application scenario of the embodiment of this specification is e-commerce, the first transaction is a security risk control transaction in e-commerce, and the second transaction is an operating indicator transaction and R&D transaction in e-commerce. Security risk control transactions and operating indicator transactions have common data, which includes but is not limited to user portrait tags, account transaction frequency, transaction amount and other data. The common intermediate fields are the names of user portrait tags, account transaction frequency and transaction amount in the code, such as user-data. The personalized intermediate data of security risk control transactions include but are not limited to the account login location. The personalized intermediate fields are the names of the account login location in the code, such as login_location.

[0047] S104, acquiring common data corresponding to the first transaction in the common data storage space based on the common intermediate field;

[0048] Specifically, based on the common intermediate fields of the first transaction, common data corresponding to the common intermediate fields is retrieved from the common data storage space, and the common data is determined as the common data of the first transaction. The common data storage space is used to store the common data corresponding to the common intermediate fields between the first transaction and the second transaction. The common data is the common intermediate data required to obtain the transaction data of the first transaction.

[0049] It should be noted that common data includes static data and dynamic data. Static data is data that remains unchanged during the lifecycle of a transaction, such as user IDs and product categories. Dynamic data is data that changes in real time with user behavior, transaction status, or the external environment, such as user account balances, order status, product inventory, and user profile tags. The common data stored in the common data storage space includes not only static data but also dynamic data that is collected, processed, and synchronized at a high frequency. This allows common data to be quickly retrieved from the common data storage space when a transaction expression request is received, improving data expression efficiency.

[0050] S106, obtaining the personality data corresponding to the first transaction from the pre-acquired source transaction data based on the personality middle field;

[0051] Specifically, based on the personalized intermediate field, the personalized data corresponding to the personalized intermediate field is obtained from the pre-acquired source transaction data, and the personalized data is determined as the personalized data of the first transaction. The personalized data is the personalized intermediate data required to obtain the transaction data of the first transaction. The pre-acquired source transaction data refers to the unprocessed raw data generated by all transactions of the transaction system obtained through cross-domain collaboration capabilities before obtaining common data and personalized data, which is used to directly reflect the events that occurred in the transaction, such as user ID, account login time, account login location, order transaction time, order transaction location, etc. The raw data directly obtained. Similar to common data, personalized data also includes static data that does not change for a long time and dynamic data that changes in real time.

[0052] Optionally, embodiments of this specification may provide a personalized data storage space that stores static data within the personalized data and simultaneously acquires dynamic data within the personalized data in real time based on continuously updated source transaction data. This allows for rapid acquisition of the personalized data from the personalized data storage space upon receipt of a transaction expression request. Embodiments of this specification may also acquire the personalized data from the source transaction data after receiving a transaction expression request.

[0053] S108, performing data processing on the common data and the individual data based on the transaction expression requirement of the first transaction to obtain transaction data of the first transaction;

[0054] Specifically, the polymorphic layer calls the common data of the first transaction from the common data storage space, obtains the personalized data of the first transaction from the source transaction data, or calls the personalized data of the first transaction from the personalized data storage space. Based on the transaction expression requirements of the first transaction, the common data and personalized data are processed to obtain the transaction data of the first transaction. The polymorphic layer is used to express transaction data. The personalized data and common data together constitute the intermediate data of the first transaction. By processing the intermediate data, the final transaction data is obtained. The intermediate data of the transaction can be data directly obtained from the source transaction data, such as user ID, transaction time, account login location, etc., or it can be data obtained by processing the data in the source transaction data.

[0055] For example, in a security risk control transaction, a user account is risk-scored based on the account login location, account transaction frequency, transaction amount, and user profile tag, and the risky user ID is determined and displayed. The user profile tag, account transaction frequency, and transaction amount are common data in the intermediate data of the security risk control transaction. The user profile tag is data that categorizes users based on their consumption behavior, such as their consumption level and consumption habits, in the source transaction data. Account transaction frequency includes high frequency, medium frequency, and low frequency, and is determined based on the number of transactions a user performs in a day / week / month / year. The transaction amount can be directly obtained from the source transaction data. The account login location is individual data in the intermediate data of the security risk control transaction and can be directly obtained from the source transaction data. Identifying a risky account requires meeting multiple conditions. Taking user A's account as an example, after obtaining user A's account login location, account transaction frequency, transaction amount, and user portrait label, user A's current data is compared with historical data to determine that user A's account login location is a high-risk area, and user A's account transaction frequency suddenly changes from low frequency to high frequency. At the same time, user A's user portrait label indicates that user A is a low-spending user, but user A's transaction amount does not conform to the consumption habits of low-spending users. In this case, user A's account can be determined to be a risky account.

[0056] S110 , encapsulating transaction data based on the transaction expression method of the first transaction to obtain expression data of the first transaction.

[0057] Specifically, the polymorphic layer encapsulates transaction data based on the first transaction's transaction expression method to obtain the first transaction's expression data. Data representation of the first transaction is then performed based on this expression data to display the transaction status to users or staff. Transaction expression methods provide visual interaction for each transaction, including DI reports, data display views, broadcasts, a unified user interaction platform, and external interfaces. Each transaction can correspond to at least one transaction expression method.

[0058] Among them, DI reports are standardized transaction reports generated by integrating multiple transaction data, used to display transaction indicators such as product sales and user repurchase rates. They include various types such as reporting status reports, inspection status reports, and operation and maintenance status reports. Among them, reporting status reports can be used as a transaction expression method for operating indicator transactions, and are used to present key transaction indicators such as profit margins and user growth to management. Reporting status reports can be generated on a daily, monthly, or quarterly basis; inspection status reports can be used as a transaction expression method for security risk control transactions, and are used to detect transaction process compliance and risk points; operation and maintenance status reports can be used as a transaction expression method for R&D transactions, and are used to detect the system stability of e-commerce platforms. The data display view can dynamically present transaction data, and can be used to display dynamically changing data such as risk event trends and real-time interception statistics for security risk control transactions. Reports include both online and offline. Offline reports are typically periodic reports generated based on historical data or batch processing, used to aggregate and analyze non-real-time transaction data. They can be used for weekly / monthly sales summary reports within operational metrics. Online reports are typically push reports generated based on real-time data streams. They are typically used to detect and respond to immediate transactions, such as real-time interception statistics within security risk control. A unified user interaction platform integrates user services, user interfaces, and data analysis capabilities, such as a customer service system, a user personal center, or a self-service portal. This platform provides data display for users of the e-commerce platform and facilitates user management. Users can view data such as their order status through the unified user interaction platform. External interfaces are external data service interfaces for third-party applications or partners to call. These third-party applications or partners can be platforms such as payment platforms or logistics platforms that interact with the e-commerce platform.

[0059] It should be noted that the information (including but not limited to user device information, user personal information, user behavior information, etc.) and data (including but not limited to data used for analysis, storage, and display, etc.) involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the order information, interaction information, and user information mentioned in this specification are all obtained with full authorization.

[0060] In an embodiment of the present specification, the common data of all transactions are stored in a common data storage space in advance. When a transaction expression request for a certain transaction is received, the common data of the transaction is directly obtained from the common data storage space according to the common intermediate fields of the transaction. At the same time, the individual data of the transaction is obtained from the pre-acquired source transaction data according to the individual intermediate fields of the transaction. Data processing is performed on the common data and the individual data to obtain transaction data, and the transaction data is encapsulated through a transaction expression method to obtain the expression data of the transaction. This method stores the common data of all transactions in a common data storage space in advance. When expressing data for the transaction, data processing is separated from data expression, so that some processed data can be continuously used by multiple transactions, thereby achieving sustainability of data processing, reducing the computational load of data processing, and improving data expression efficiency.

[0061] See Figure 4 , Figure 4 This is a flow chart of a common data acquisition method provided in the embodiment of this specification. Figure 4 As shown, the method of the embodiment of this specification may include the following steps S202 to S214.

[0062] S202, determining a first requirement field of the first transaction based on the transaction expression requirement of the first transaction;

[0063] Specifically, the first requirement field of the first transaction is determined based on the transaction expression requirement of the first transaction. The transaction system in the current application scenario includes multiple transactions, and the requirement fields of each transaction can be determined based on the transaction expression requirement of each transaction. The transaction expression requirement is the transaction's goal and is used to determine the transaction data that the transaction ultimately needs to express, thereby determining the transaction's requirement fields. A field is the name of data in the code. For example, if the data is a user identifier (ID), the field can be user-id. Requirement fields include the transaction data field of the transaction data ultimately expressed by the transaction, as well as intermediate data fields obtained by data lineage tracing of the transaction data field. Intermediate data is data required before obtaining the transaction data. Intermediate data fields are the names of intermediate data in the code. Data lineage tracing refers to tracking the entire lifecycle of data from its source to its final consumption, including its origin, processing, transformation logic, and usage. Its core purpose is to record and display the data flow path and dependencies across different transactions and processes to enhance data transparency, ensure data quality, and support compliance audits and troubleshooting.

[0064] For example, assuming that the application scenario of the embodiments of this specification is e-commerce, the first transaction is a security risk control transaction in e-commerce, and the transaction expression requirements of the security risk control transaction are to ensure the transaction security, user privacy and compliance of the e-commerce platform, and to prevent risks such as fraud and data leakage. Based on the analysis of the transaction expression requirements of the security risk control transaction, the transaction data ultimately expressed by the security risk control transaction is data such as the risk user ID and the number of risky transaction interceptions. Then, the transaction data fields in the first requirement field of the security risk control transaction include but are not limited to the names of the risk user ID and the number of risky transaction interceptions in the code, such as risky_account_id. Taking the risky user ID as an example, the lineage is traced to obtain the intermediate data required to obtain the risky user ID, including the account login location, account transaction frequency, transaction amount, user profile label, and other data. Then, the intermediate data fields in the first requirement field include but are not limited to the names of the account login location, account transaction frequency, transaction amount, user profile label, and other data in the code, such as login_location, transaction_frequency, single_transaction_amount, and user-data.

[0065] S204, cross-comparing the first requirement field with the second requirement field of the second transaction to determine a common intermediate field between the first requirement field and the second requirement field, and a unique intermediate field in the first requirement field;

[0066] Specifically, the first requirement field of a first transaction is cross-compared with the second requirement field of a second transaction to identify common intermediate fields in the first and second requirement fields, as well as unique intermediate fields in the first requirement field. The second transaction refers to the transactions in the transaction system other than the first transaction. Common intermediate fields are determined by matching the first requirement field of the first transaction with the second requirement field of the second transaction. Unique intermediate fields are intermediate fields in the first requirement field other than the common intermediate fields. It should be noted that common intermediate fields can be common to at least one of the first and second transactions. Cross-comparison is a technique for identifying common fields in a set of requirement fields across different transactions. Technologies related to cross-comparison include metadata management, data mapping and matching, and visual analysis. The specific process of cross-comparison involves aggregating the requirement fields of all transactions using a metadata management platform. During this aggregation process, data dictionary technology is used to clarify the meaning and data processing logic of each requirement field in each transaction. Data mapping and matching is then performed using pattern matching algorithms or semantic analysis algorithms. All requirement fields themselves or the meaning of all requirement fields across all transactions are compared and analyzed to identify common intermediate fields. Finally, all common intermediate fields are displayed using visual analysis tools. It should be noted that after the common intermediate fields are determined, they are unified, that is, the naming of the common data is unified.

[0067] For example, in an e-commerce scenario, the first transaction is a security risk control transaction, and the second transaction is an operating indicator transaction and an R&D transaction. The transaction expression requirements of the operating indicator transaction are to optimize operational efficiency, user experience, and profitability. Based on the analysis of the transaction expression requirements of the operating indicator transaction, the transaction data ultimately expressed by the operating indicator transaction is obtained as data such as product profit, conversion rate, user repurchase rate, and marketing return rate. The transaction data fields in the second requirement field of the operating indicator transaction include, but are not limited to, the naming of data such as product profit, conversion rate, user repurchase rate, and marketing return rate in the code. The transaction data of the operating indicator transaction is traced by data lineage, and the intermediate data required for the transaction data of the operating indicator transaction includes user behavior data, user profile tags, account transaction frequency, transaction amount, and other data. The intermediate data fields in the second requirement field of the operating indicator transaction include, but are not limited to, the naming of data such as user behavior data, user profile tags, account transaction frequency, and transaction amount in the code, such as user_behavior_log, user_profile_tags, purchase_frequency, and single_tx_amount.

[0068] A cross-comparison is performed on the intermediate data fields of security risk control transactions and the intermediate data fields of business indicator transactions. Since the field naming methods of the two transactions are different, data dictionary technology, pattern matching algorithm and semantic analysis algorithm are combined. Based on the meaning of the intermediate data fields of the two transactions, the intermediate data fields are matched. The common data of the two transactions are account transaction frequency, transaction amount and user portrait label. The naming of the common data in the code is unified to obtain the common intermediate fields. In the intermediate data of security risk control transactions, except for the common data, the rest of the data is personalized data, that is, the account login location is the personalized data of the security risk control transaction, and the personalized intermediate field can be login_location.

[0069] S206, obtaining common source fields corresponding to the common intermediate fields, and common processing logic corresponding to the common source fields;

[0070] Specifically, data lineage tracing is performed on common intermediate fields to obtain the source fields corresponding to the common intermediate fields and the initial processing logic corresponding to the source fields. The source fields and initial processing logic are then unified to obtain the common source fields corresponding to the source fields and the common processing logic corresponding to the initial processing logic. It should be noted that intermediate data can be data directly obtained from the source transaction data, such as user ID, transaction time, account login location, etc., or it can be data obtained by data processing data in the source transaction data.

[0071] The source fields are the fields corresponding to all source data required to obtain the common data corresponding to the common intermediate fields, and the initial processing logic is the data processing logic from the source data to the common intermediate data. Because the source fields and initial processing logic vary in different transactions, the embodiments of this specification unify the source fields and initial processing logic after obtaining them.

[0072] Exemplarily, the common data obtained in step S204, such as account transaction frequency, transaction amount, and user profile tags, is traced for lineage to obtain source data. Account transaction frequency includes daily / weekly / monthly / yearly transaction frequency, which is determined based on the number of transactions performed by the user in that day / week / month / year. Therefore, the source data corresponding to the account transaction frequency is the number of transactions performed by the user in that day / week / month / year, and the source fields are daily_transaction_count, weekly_transaction_count, monthly_transaction_count, and yearly_transaction_count. Combined with the naming of the source fields in the second transaction, the source fields are unified to obtain the common source fields. The account transaction frequency is divided into high frequency, medium frequency and low frequency according to the number of transactions. Taking the daily transaction number as an example, its initial processing logic is "After each natural day, obtain the total number of transactions of the user in the past preset number of days, calculate the user's daily average transaction number based on the total number of transactions and the preset number of days, and determine the daily average transaction number as the user's daily transaction number. If the daily transaction number is greater than or equal to 30 times, the user's account transaction frequency is determined to be high frequency; if the daily transaction number is greater than or equal to 10 times and less than 30 times, the user's account transaction frequency is determined to be medium frequency; if the daily transaction number is less than 10 times, the user's account transaction frequency is determined to be low frequency." If the transaction number thresholds set for high frequency, medium frequency and low frequency in the second transaction are different, the first transaction and the second transaction can be combined to determine a unique transaction number threshold for dividing high frequency, medium frequency and low frequency. The initial processing logic for determining the account transaction frequency based on the daily transaction number in the first transaction and the second transaction can be unified according to the unique transaction number threshold to obtain a common processing logic.

[0073] S208, obtaining source transaction data generated by the transaction system;

[0074] Specifically, the basic data required for transaction data expression comes from the source transaction data generated by the transaction system. Therefore, before obtaining common data and individual data, the source transaction data generated by the transaction system is pre-acquired and stored in the base layer data model. By integrating all transactions into the transaction system through cross-transaction collaboration capabilities, data silos can be eliminated, facilitating the centralized integration of source transaction data for different transactions, reducing blind spots from a single transaction perspective, and improving data accuracy. Source transaction data is the unprocessed raw data generated by all transactions, such as user ID, account login time, account login location, transaction time, transaction location, and other directly acquired raw data.

[0075] S210, determining common data corresponding to common intermediate fields based on common source data corresponding to common source fields and common processing logic;

[0076] Specifically, based on the common source fields, common source data corresponding to the common source fields is obtained from the source transaction data. The common source data is then processed based on the common processing logic to obtain common data corresponding to the common intermediate fields. The common source fields include all source data fields before the common data corresponding to the common intermediate fields is obtained.

[0077] After obtaining the common data, the common data is stored in the common data storage space so that it can be called by the polymorphic layer. The common data storage space is used to store the common data corresponding to the common intermediate fields between the first transaction and the second transaction. It should be noted that the common data stored in the common data storage space includes static data and dynamic data. Static data is data that remains unchanged during the life cycle of the transaction, such as user ID, product category and other data; dynamic data is data that changes in real time with user behavior, transaction status or external environment, such as user account balance, order status, product inventory, user portrait label and other data. The common data stored in the common data storage space includes not only static data, but also dynamic data that is collected, processed and synchronized at a high frequency, so that when a transaction expression request is received, the common data can be quickly obtained from the common data storage space to improve data expression efficiency.

[0078] Optionally, the common data storage space can be a funnel model, and the common data is stored in layers based on the funnel model. The specific process is to determine the first layer where the common source field is located and the second layer where the common intermediate field is located based on the common processing logic; the common source data corresponding to the common source field is stored in the first layer, and the common data corresponding to the common intermediate field is stored in the second layer. Among them, the first layer includes at least one layer. Taking the common data of account transaction frequency in security risk control transactions as an example, first obtain the user ID and transaction records from the source transaction data. The transaction records include original data such as transaction time, transaction amount, and transaction status, and save the user ID and transaction records in the basic data layer in the first layer. Aggregate the user ID and transaction time in the transaction record, count the number of transactions of the user per day, and save the user ID, date, and the number of transactions corresponding to each date in the daily transaction aggregation layer in the first layer. Each natural day, the user ID, the dates of the past preset number of days, and the number of transactions corresponding to each date are aggregated to count the total number of transactions of the user in the past preset number of days. The daily average number of transactions is calculated based on the preset number of days and the total number of transactions. The user ID, total number of transactions, and daily average number of transactions are stored in the total transaction aggregation layer in the first level. Based on the daily average number of transactions, the user's account transaction frequency is determined, and the user ID and account transaction frequency are stored in the frequency classification layer in the first level. The user's account transaction frequency is updated regularly, and the user ID, account transaction frequency, historical transaction frequency, and update time are stored in the second level. The historical transaction frequency is the transaction frequency of the user's current account transaction frequency before it was updated.

[0079] S212 , in response to the transaction expression request of the first transaction, determining the common middle fields and the individual middle fields of the first transaction based on the transaction expression requirement of the first transaction;

[0080] S214 : Acquire common data corresponding to the first transaction in the common data storage space based on the common intermediate field.

[0081] Specifically, the common data of the first transaction is obtained in advance and stored in the common data storage space. When the transaction expression request of the first transaction is received, the common data corresponding to the first transaction can be directly called from the common data storage space based on the common intermediate field of the first transaction to obtain the transaction data of the first transaction finally expressed according to the common data.

[0082] It should be noted that the information (including but not limited to user device information, user personal information, user behavior information, etc.) and data (including but not limited to data used for analysis, storage, and display, etc.) involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the order information, interaction information, and user information mentioned in this specification are all obtained with full authorization.

[0083] In an embodiment of the present specification, the requirement fields of each transaction are determined by expressing the requirement through transactions, and the requirement fields of all transactions are cross-compared to determine the common intermediate fields between at least two transactions in all transactions. By tracing the data lineage of the common intermediate fields, the common source fields and the common processing logic corresponding to the common source fields are obtained, and then the common source data can be obtained from the pre-acquired source transaction data through the common source fields. The common source data is processed based on the common processing logic to obtain the common data of each transaction and at least one of the remaining transactions, and the common data is stored in the common data storage space. When the transaction is expressed, the common data corresponding to the transaction is directly obtained from the common data storage space. The embodiment of the present specification predetermines the common intermediate fields of all transactions, and then uniformly processes the data to obtain the common data of each transaction and at least one of the remaining transactions. There is no need to calculate the common data of each transaction and at least one of the remaining transactions multiple times. The common source fields and common processing logic processed in a unified manner can achieve sustainable use of the common data, reducing the computational complexity of data processing. Common data is stored in a separate common data storage space. When expressing data for a transaction, the common data of the transaction is directly called from the common data storage space, which improves the efficiency of data expression. At the same time, the common data storage space clarifies the responsibility boundaries in the data expression system, ensures the independence and low coupling of the code, and improves the maintainability and reusability of the entire system.

[0084] See Figure 5 , Figure 5 This is a flow chart of a method for obtaining personality data provided by an embodiment of this specification. Figure 5 As shown, the method of the embodiment of this specification may include the following steps S302 to S314.

[0085] S302, determining a first requirement field of the first transaction based on the transaction expression requirement of the first transaction;

[0086] Please refer to step S202 for the specific process, which will not be described again here.

[0087] S304, cross-comparing the first requirement field with the second requirement field of the second transaction to determine a common intermediate field between the first requirement field and the second requirement field, and a unique intermediate field in the first requirement field;

[0088] Please refer to step S204 for the specific process, which will not be described again here.

[0089] S306, obtaining the personality source field corresponding to the personality intermediate field and the personality processing logic corresponding to the personality source field;

[0090] Specifically, the data lineage of the personalized intermediate fields is traced to obtain the personalized source fields corresponding to the personalized intermediate fields, as well as the personalized processing logic corresponding to the personalized source fields. The personalized source fields are the fields corresponding to all the personalized source data required to obtain the personalized data corresponding to the personalized intermediate fields, and the personalized processing logic is the data processing logic from the personalized source data to the personalized intermediate data. It should be noted that the intermediate data can be data directly obtained from the source transaction data, such as user ID, transaction time, account login location, etc., or it can be data obtained by processing the data in the source transaction data.

[0091] For example, in an e-commerce scenario, the intermediate data of security risk control transactions includes, but is not limited to, account login location, account transaction frequency, transaction amount, user profile tags, and other data. Account transaction frequency, transaction amount, and user profile tags are common data, while account login location is personalized data. Data lineage tracing of the account login location reveals that the account login location is data that can be directly obtained from the source transaction data. Therefore, the personalized source data of security risk control transactions includes, but is not limited to, the account login location. Personalized source fields include, but are not limited to, the naming of the account login location in the code, such as login_location. Its personalized processing logic can be data cleaning and other data processing methods.

[0092] S308, obtaining source transaction data generated by the transaction system;

[0093] Please refer to step S208 for the specific process, which will not be described again here.

[0094] S310 , in response to a transaction expression request of a first transaction, determining a common intermediate field and a unique intermediate field of the first transaction based on a transaction expression requirement of the first transaction;

[0095] S312, based on the personalized source field corresponding to the personalized intermediate field, obtaining personalized source data corresponding to the personalized source field from the pre-acquired source transaction data;

[0096] S314: Process the personalized source data based on the personalized processing logic to obtain personalized data corresponding to the first transaction.

[0097] Specifically, based on the personalized source field, personalized source data corresponding to the personalized source field is obtained from the source transaction data, and the personalized source data is processed based on the personalized processing logic to obtain personalized data corresponding to the first transaction. The personalized source field includes all source data fields before the personalized data corresponding to the personalized intermediate field is obtained.

[0098] It should be noted that the information (including but not limited to user device information, user personal information, user behavior information, etc.) and data (including but not limited to data used for analysis, storage, and display, etc.) involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the order information, interaction information, and user information mentioned in this specification are all obtained with full authorization.

[0099] In the embodiments of this specification, the requirement fields of each transaction are determined by expressing the transaction requirements, and the requirement fields of all transactions are cross-compared to determine the individual intermediate fields of each transaction. By tracing the data lineage of the individual intermediate fields, the individual source fields and the individual processing logic corresponding to the individual source fields are obtained. When a transaction expression request is received, the individual source data corresponding to the individual source fields is obtained from the pre-acquired source transaction data, and the individual source data is processed based on the individual processing logic to obtain the individual data. The individual data is directly obtained from the source transaction data, and the acquisition channel of the individual data is separated from the acquisition channel of the common data, thereby improving the flexibility of data processing.

[0100] based on Figure 2 The system architecture diagram will be combined with Figure 6 , the content display device provided by the embodiment of this specification is introduced in detail. It should be noted that, Figure 6 The data expression device in the present application is used to execute Figure 3-Figure 5 For the convenience of explanation, only the part related to the embodiment of this specification is shown. For the specific technical details not disclosed, please refer to the application. Figure 3-Figure 5 The embodiment shown.

[0101] See Figure 6 , Figure 6 This is a structural diagram of a data expression device provided in the embodiment of this specification. Figure 6 As shown, the data expression device 1 of the embodiment of this specification may include: an intermediate field determination unit 11, a common data acquisition unit 12, a personalized data acquisition unit 13, a transaction data acquisition unit 14 and a data expression unit 15.

[0102] An intermediate field determination unit 11 is configured to determine, in response to a transaction expression request of a first transaction, common intermediate fields and individual intermediate fields of the first transaction, wherein the common intermediate fields are determined based on matching a first requirement field of the first transaction with a second requirement field of a second transaction, where the second transaction is a transaction other than the first transaction in the transaction system;

[0103] A common data acquisition unit 12 is configured to acquire common data corresponding to the first transaction from a common data storage space based on the common intermediate field, where the common data storage space is configured to store common data corresponding to the common intermediate field between the first transaction and the second transaction;

[0104] The personality data acquisition unit 13 is configured to acquire personality data corresponding to the first transaction from the pre-acquired source transaction data based on the personality intermediate field;

[0105] The transaction data acquisition unit 14 is configured to process the common data and the individual data based on the transaction expression requirements of the first transaction to obtain transaction data of the first transaction;

[0106] The data expression unit 15 is configured to encapsulate the transaction data based on the transaction expression mode of the first transaction to obtain the expression data of the first transaction.

[0107] Optionally, the data expression device 1 is specifically configured to determine a first requirement field of the first transaction based on the transaction expression requirement of the first transaction;

[0108] Cross-comparing the first requirement field with the second requirement field of the second transaction to determine a common intermediate field between the first requirement field and the second requirement field, and a unique intermediate field in the first requirement field;

[0109] Obtain the common source fields corresponding to the common intermediate fields, as well as the common processing logic corresponding to the common source fields;

[0110] Based on the common source data corresponding to the common source fields and the common processing logic, the common data corresponding to the common intermediate fields are determined.

[0111] Optionally, the data expression device 1 is specifically used to perform data lineage tracing on the common intermediate fields, to obtain the source fields corresponding to the common intermediate fields, and the initial processing logic corresponding to the source fields;

[0112] The source fields and the initial processing logic are unified respectively to obtain the common source fields corresponding to the source fields and the common processing logic corresponding to the initial processing logic.

[0113] Optionally, the data expression device 1 is specifically used to obtain source transaction data generated by the transaction system.

[0114] Optionally, the data expression device 1 is specifically configured to obtain common source data corresponding to the common source fields in the source transaction data based on the common source fields;

[0115] The common source data is processed based on the common processing logic to obtain the common data corresponding to the common intermediate fields.

[0116] Optionally, the data expression device 1 is specifically configured to determine the first level at which the common source fields are located and the second level at which the common intermediate fields are located based on the common processing logic;

[0117] The common source data corresponding to the common source fields are stored in the first level, and the common data corresponding to the common intermediate fields are stored in the second level.

[0118] Optionally, the data expression device 1 is specifically used to obtain the personalized source field corresponding to the personalized intermediate field, and the personalized processing logic corresponding to the personalized source field.

[0119] Optionally, the personality data acquisition unit 13 is specifically configured to acquire personality source data corresponding to the personality source field in the pre-acquired source transaction data based on the personality source field corresponding to the personality intermediate field;

[0120] The personalized source data is processed based on the personalized processing logic to obtain personalized data corresponding to the first transaction.

[0121] In the embodiments of the present specification, the common intermediate fields of all transactions are predetermined, and then the data processing is performed uniformly to obtain the common data of each transaction and at least one of the other transactions. There is no need to calculate the common data of each transaction and at least one of the other transactions multiple times. The common source fields and common processing logic processed in a unified manner are used to achieve sustainable use of the common data, thereby reducing the computational complexity of data processing. The common data is stored in a separate common data storage space. When expressing data for a transaction, the common data of the transaction is directly called from the common data storage space. The data processing is separated from the data expression, so that some processed data can be continuously used by multiple transactions, thereby achieving sustainability of data processing, reducing the computational complexity of data processing, and improving data expression efficiency. Personalized data is obtained from the source transaction data, and the acquisition channels of personalized data are separated from the acquisition channels of common data, thereby improving the flexibility of data processing. At the same time, the responsibility boundaries in the data expression system are clarified through the basic layer data model, the common data storage space, and the polymorphic layer, ensuring the independence and low coupling of the code, and improving the maintainability and reusability of the entire system.

[0122] It should be noted that the data expression device provided in the above embodiment, when executing the data expression method, only uses the division of the above functional modules as an example. In actual application, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the data expression device provided in the above embodiment and the data expression method embodiment are based on the same concept. The implementation process is detailed in the method embodiment and will not be repeated here.

[0123] The serial numbers of the embodiments in this specification are for descriptive purposes only and do not represent the merits of the embodiments. In some cases, the actions or steps recited in the claims may be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0124] See Figure 7 , Figure 7 This is a structural diagram of a computer device provided in an embodiment of this specification.

[0125] For example, Figure 7 As shown, the computer device 700 includes: a processor 701 and a memory 702, wherein the processor 701 is electrically connected to the memory 702.

[0126] Processor 701 is the control center of computer device 700 and may include one or more processing cores. Using various interfaces and circuits, processor 701 connects the various components of the computer device. By running or invoking computer programs stored in memory 702 and accessing data stored in memory 702, it executes various computer device functions and processes data, thereby providing overall control over computer device 700. Optionally, processor 701 may be implemented as at least one of the following hardware forms: a digital signal processing (DSP), a field programmable gate array (FPGA), or a programmable logic array (PLA). Processor 701 may integrate one or a combination of a CPU, a graphics processing unit (GPU), and a modem. The CPU primarily processes the operating system, user interfaces, and applications; the GPU is responsible for rendering and drawing display content; and the modem handles wireless communications. It is understood that the modem may also be implemented independently of the processor 701 and implemented as a separate communications chip.

[0127] The memory 702 can be used to store software programs and modules. The processor 701 executes various functional applications and data processing by running the computer programs and modules stored in the memory 702. The memory 702 may mainly include a program storage area and a data storage area. The program storage area may store an operating system, computer programs required for at least one function, etc.; the data storage area may store data generated based on the use of the computer device 700.

[0128] In addition, the memory 702 may include a high-speed random access memory and a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage device. Accordingly, the memory 702 may also include a memory controller to provide the processor 701 with access to the memory 702.

[0129] In a first feasible implementation of the embodiments of this specification, the processor 701 in the computer device 700 loads instructions corresponding to one or more computer program processes into the memory 702 according to the following steps, and the processor 701 runs the computer program stored in the memory 702 to implement various functions as follows:

[0130] In response to a transaction expression request of a first transaction, determining a common middle field and a unique middle field of the first transaction, where the common middle field is determined based on matching a first requirement field of the first transaction with a second requirement field of a second transaction, and the second transaction is a transaction other than the first transaction in the transaction system;

[0131] Acquire common data corresponding to the first transaction in a common data storage space based on the common intermediate field, where the common data storage space is used to store common data corresponding to the common intermediate field between the first transaction and the second transaction;

[0132] Obtaining, based on the individual middle field, individual data corresponding to the first transaction from the pre-acquired source transaction data;

[0133] Performing data processing on the common data and the individual data based on the transaction expression requirement of the first transaction to obtain transaction data of the first transaction;

[0134] The transaction data is encapsulated based on the transaction expression mode of the first transaction to obtain the expression data of the first transaction.

[0135] Optionally, before executing the transaction expression request in response to the first transaction and determining the common middle field and the individual middle field of the first transaction, the processor 701 further executes:

[0136] determining a first requirement field of the first transaction based on the transaction expression requirement of the first transaction;

[0137] Cross-comparing the first requirement field with the second requirement field of the second transaction to determine a common intermediate field between the first requirement field and the second requirement field, and a unique intermediate field in the first requirement field;

[0138] Obtain the common source fields corresponding to the common intermediate fields, as well as the common processing logic corresponding to the common source fields;

[0139] Based on the common source data corresponding to the common source fields and the common processing logic, the common data corresponding to the common intermediate fields are determined.

[0140] Optionally, when executing the process of obtaining the common source fields corresponding to the common intermediate fields and the common processing logic corresponding to the common source fields, the processor 701 specifically performs:

[0141] Conduct data lineage tracing for common intermediate fields to obtain the source fields corresponding to the common intermediate fields and the initial processing logic corresponding to the source fields;

[0142] The source fields and the initial processing logic are unified respectively to obtain the common source fields corresponding to the source fields and the common processing logic corresponding to the initial processing logic.

[0143] Optionally, after performing a cross comparison between the first requirement field and the second requirement field of the second transaction and determining a common middle field between the first requirement field and the second requirement field, and a unique middle field in the first requirement field, the processor 701 further performs:

[0144] Get the source transaction data generated by the transaction system.

[0145] Optionally, when the processor 701 determines the common data corresponding to the common intermediate field based on the common source data corresponding to the common source field and the common processing logic, it specifically performs:

[0146] Obtaining common source data corresponding to the common source fields in the source transaction data based on the common source fields;

[0147] The common source data is processed based on the common processing logic to obtain the common data corresponding to the common intermediate fields.

[0148] Optionally, the processor 701 further executes:

[0149] Determine, based on the common processing logic, the first level at which the common source fields are located and the second level at which the common intermediate fields are located;

[0150] The common source data corresponding to the common source fields are stored in the first level, and the common data corresponding to the common intermediate fields are stored in the second level.

[0151] Optionally, after performing a cross comparison between the first requirement field and the second requirement field of the second transaction and determining a common middle field between the first requirement field and the second requirement field, and a unique middle field in the first requirement field, the processor 701 further performs:

[0152] Get the personality source field corresponding to the personality intermediate field, as well as the personality processing logic corresponding to the personality source field.

[0153] Optionally, when the processor 701 acquires the personality data corresponding to the first transaction from the pre-acquired source transaction data based on the personality middle field, it specifically performs:

[0154] Based on the personalized source field corresponding to the personalized intermediate field, the personalized source data corresponding to the personalized source field is obtained from the pre-acquired source transaction data;

[0155] The personalized source data is processed based on the personalized processing logic to obtain personalized data corresponding to the first transaction.

[0156] In the embodiments of the present specification, the common intermediate fields of all transactions are predetermined, and then the data processing is performed uniformly to obtain the common data of each transaction and at least one of the other transactions. There is no need to calculate the common data of each transaction and at least one of the other transactions multiple times. The common source fields and common processing logic processed in a unified manner are used to achieve sustainable use of the common data, thereby reducing the computational complexity of data processing. The common data is stored in a separate common data storage space. When expressing data for a transaction, the common data of the transaction is directly called from the common data storage space. The data processing is separated from the data expression, so that some processed data can be continuously used by multiple transactions, thereby achieving sustainability of data processing, reducing the computational complexity of data processing, and improving data expression efficiency. Personalized data is obtained from the source transaction data, and the acquisition channels of personalized data are separated from the acquisition channels of common data, thereby improving the flexibility of data processing. At the same time, the responsibility boundaries in the data expression system are clarified through the basic layer data model, the common data storage space, and the polymorphic layer, ensuring the independence and low coupling of the code, and improving the maintainability and reusability of the entire system.

[0157] It should be understood that the device provided in the embodiments of this specification is used to execute the above-mentioned data expression method, and thus can achieve the same effect as the above-mentioned implementation method.

[0158] In the case of an integrated unit, the device may include a processing module and a storage module. When the device is applied to a computer device, the processing module may be used to control and manage the operation of the computer device. The storage module may be used to support the computer device in executing relevant program codes, etc.

[0159] The processing module may be a processor or controller that implements or executes the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a digital signal processing (DSP) and a microprocessor, and the storage module may be a memory.

[0160] In addition, the device provided in the embodiments of this specification may specifically be a chip, component or module, and the chip may include a connected processor and memory; wherein the memory is used to store instructions, and when the processor calls and executes the instructions, the chip can execute a data expression method provided in the above embodiments.

[0161] An embodiment of this specification also provides a computer-readable storage medium, which stores computer program code. When the computer program code runs on a computer, the computer executes the above-mentioned related method steps to implement a data expression method provided by the above-mentioned embodiment.

[0162] This embodiment also provides a computer program product. When the computer program product runs on a computer, it enables the computer to execute the above-mentioned related steps to implement a data expression method provided by the above embodiment.

[0163] Among them, the device, computer-readable storage medium, computer program product or chip provided in this embodiment are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0164] Through the description of the above implementation methods, technical personnel in the relevant field can understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0165] In the embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0166] The above content is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A data expression method, comprising: In response to a transaction expression request of a first transaction, determining a common middle field and a unique middle field of the first transaction, wherein the common middle field is determined based on matching a first requirement field of the first transaction with a second requirement field of a second transaction, where the second transaction is a transaction other than the first transaction in the transaction system; acquiring, based on the common intermediate field, common data corresponding to the first transaction in a common data storage space, the common data storage space being used to store common data corresponding to the common intermediate field between the first transaction and the second transaction; Acquire, based on the individual middle field, individual data corresponding to the first transaction from the pre-acquired source transaction data; performing data processing on the common data and the individual data based on the transaction expression requirement of the first transaction to obtain transaction data of the first transaction; The transaction data is encapsulated based on the transaction expression mode of the first transaction to obtain the expression data of the first transaction.

2. The method according to claim 1, before determining the common middle field and the individual middle field of the first transaction in response to the transaction expression request of the first transaction, further comprising: determining a first requirement field of the first transaction based on the transaction expression requirement of the first transaction; Cross-comparing the first requirement field with the second requirement field of the second transaction to determine a common intermediate field between the first requirement field and the second requirement field, and a unique intermediate field in the first requirement field; Obtaining the common source fields corresponding to the common intermediate fields and the common processing logic corresponding to the common source fields; Based on the common source data corresponding to the common source fields and the common processing logic, the common data corresponding to the common intermediate fields are determined.

3. The method according to claim 2, wherein obtaining the common source fields corresponding to the common intermediate fields and the common processing logic corresponding to the common source fields comprises: Performing data lineage tracing on the common intermediate fields to obtain source fields corresponding to the common intermediate fields and initial processing logic corresponding to the source fields; The source fields and the initial processing logic are respectively unified to obtain common source fields corresponding to the source fields and common processing logic corresponding to the initial processing logic.

4. The method according to claim 2, further comprising: after cross-comparing the first requirement field with the second requirement field of the second transaction and determining a common intermediate field between the first requirement field and the second requirement field, and a unique intermediate field in the first requirement field: Get the source transaction data generated by the transaction system.

5. The method according to claim 4, wherein determining the common data corresponding to the common intermediate fields based on the common source data corresponding to the common source fields and the common processing logic comprises: Acquiring common source data corresponding to the common source field in the source transaction data based on the common source field; The common source data is processed based on the common processing logic to obtain common data corresponding to the common intermediate fields.

6. The method according to claim 2, further comprising: Determining, based on the common processing logic, a first level at which the common source fields are located and a second level at which the common intermediate fields are located; The common source data corresponding to the common source fields are stored in the first level, and the common data corresponding to the common intermediate fields are stored in the second level.

7. The method according to claim 2, further comprising: after cross-comparing the first requirement field with the second requirement field of the second transaction and determining a common intermediate field between the first requirement field and the second requirement field, and a unique intermediate field in the first requirement field: Obtain the personality source field corresponding to the personality intermediate field and the personality processing logic corresponding to the personality source field.

8. The method according to claim 7, wherein obtaining the personality data corresponding to the first transaction from the pre-acquired source transaction data based on the personality intermediate field comprises: Based on the personalized source field corresponding to the personalized intermediate field, obtaining personalized source data corresponding to the personalized source field from the pre-acquired source transaction data; The personalized source data is processed based on the personalized processing logic to obtain personalized data corresponding to the first transaction.

9. A data presentation device, comprising: an intermediate field determining unit, configured to determine, in response to a transaction expression request of a first transaction, a common intermediate field and a unique intermediate field of the first transaction, wherein the common intermediate field is determined based on matching a first requirement field of the first transaction with a second requirement field of a second transaction, the second transaction being a transaction other than the first transaction in the transaction system; a common data acquisition unit, configured to acquire, based on the common intermediate field, common data corresponding to the first transaction from a common data storage space, wherein the common data storage space is configured to store common data corresponding to the common intermediate field between the first transaction and the second transaction; a personality data acquisition unit, configured to acquire personality data corresponding to the first transaction from pre-acquired source transaction data based on the personality middle field; a transaction data acquisition unit, configured to process the common data and the individual data based on a transaction expression requirement of the first transaction to obtain transaction data of the first transaction; A data expression unit is used to encapsulate the transaction data based on the transaction expression method of the first transaction to obtain the expression data of the first transaction.

10. A computer device comprising: processor and memory; The memory stores a computer program, which is suitable for being loaded by the processor and executing the steps of the method according to any one of claims 1 to 8.

11. A storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the method according to any one of claims 1 to 8.

12. A computer program product comprising: A computer program, when executed by a processor of a computer device, causes the processor to perform the steps of the method according to any one of claims 1 to 8.

Images