A method and device for storing and managing three-level structures of over-the-counter derivative contract elements

Abstract

This invention provides a three-level storage management method and apparatus for OTC derivatives contract elements. The method defines a new storage structure for OTC derivatives contract elements, namely, by reclassifying and classifying the contract elements of various types of OTC derivatives contracts according to whether they are common elements and whether they participate in logical control, the method uses a contract model factory to reintegrate the classified contract elements to form a corresponding three-level storage structure. Finally, based on the formed three-level storage structure, the OTC derivatives contract elements are stored and persisted, reducing storage costs while improving R&D efficiency.

Description

Technical Field

[0001] The present invention relates to a method and device for storing and managing a three-level structure of over-the-counter derivative contract elements, and belongs to the field of computer financial technology. Background Art

[0002] In recent years, the development of domestic over-the-counter derivatives has made great progress, business varieties have been continuously enriched, and various over-the-counter derivatives contracts have emerged. Derivative contracts are composed of contract elements. The so-called contract elements refer to the descriptive information of the contract, such as the contract subject, contract quantity, expiration month, exercise price, exercise date, etc. The contract elements contained in different types of contracts have both similarities and differences. Contracts are key elements of the over-the-counter derivatives management system. The quality of the contract element storage management method directly determines the quality of the service system. Therefore, there is a general practical application demand for the optimization of the storage management method of over-the-counter derivatives contract elements.

[0003] Generally speaking, business personnel enter contract elements through the front-end application system, and the back-end service system stores the contract elements and provides the front-end application system with contract element addition, query, modification and deletion services. In the existing technical implementation methods, there are two main methods for the back-end service system to store and manage contract elements:

[0004] The first method is to uniformly store and manage the contract elements of different types of contracts. That is, in the application system, a universal storage structure is designed, which is applicable to the storage of contract elements of all types of contracts. This solution makes the most of the characteristics that different types of contracts have some common elements, and ignores the differences between the contract elements of different types of contracts. This solution can reflect the internal connection between various contracts to the greatest extent. However, due to the differences between different types of contracts, this storage structure will have a large amount of redundant data for each contract stored, resulting in a waste of storage resources. In addition, the universal storage structure has poor readability, which is not conducive to later data maintenance.

[0005] The second method is to independently store and manage the contract elements of different types of contracts. A storage structure is designed for each type of contract to store data. This solution emphasizes the differences between the contract elements of each type of contract and weakens the commonalities between contracts. The storage of each contract element will not produce field redundancy, but it also cuts off the business connection between different types of contracts, increasing the difficulty of system development.

[0006] From the above description, it is not difficult to find that for back-end services, no matter whether a common storage structure or multiple independent storage structures are adopted, it is impossible to take into account the problem that the contract elements between different types of contracts have similarities and differences. At the same time, the rapid development of domestic over-the-counter derivatives business requires the back-end system to respond quickly to market changes, support emerging contracts, and iterate quickly. Therefore, a more suitable storage structure for over-the-counter derivatives contract elements is urgently needed to solve the problem of the coexistence of commonalities and differences in contract elements between different types of contracts, while meeting the demand for rapid iteration of the back-end system. Summary of the invention

[0007] The purpose of the present invention is to overcome the deficiencies in the prior art and to provide a method and device for storage and management of the three-level structure of over-the-counter derivative contract elements, which can improve the information storage and transmission efficiency of the background service system, avoid the presence of a large amount of redundant data in the storage device, and is conducive to improving the utilization rate of the storage space of the background system and the development efficiency, reducing the repetitive coding work of the background developers, and can meet the demand for rapid iteration of the background system and reduce the difficulty of system development.

[0008] To achieve the above object, the present invention is implemented by adopting the following technical solutions:

[0009] In a first aspect, the present invention provides a method for storing and managing a three-level structure of over-the-counter derivative contract elements, comprising the following steps:

[0010] Step 1: Obtain the contract elements of all types of contracts in the backend service system, perform difference analysis on the contract elements, and obtain the common elements and difference elements of the contract elements;

[0011] Step 2: Reanalyze the common elements in various types of contracts and classify them into basic elements of contracts and subject matter elements of contracts according to their business meanings;

[0012] Step 3: Reclassify the basic elements of the contract into business logic control elements and display elements according to whether they participate in logic control;

[0013] Step 4: construct a three-level storage structure model of contract data according to the classification results and the reclassification results; the three-level storage structure model of contract data includes a contract basic element structure, a contract transaction element structure and a contract subject element structure;

[0014] Step 5: configure the contract elements of each level of storage structure and its substructure of the three-level storage structure model;

[0015] Step six: construct database tables based on the constructed three-level storage structure model of contract data; the database tables include a contract basic element table corresponding to the contract basic element structure, a contract transaction element table corresponding to the contract transaction element structure, and a contract transaction element table corresponding to the contract subject element structure.

[0016] Furthermore, the basic elements of the contract include the transaction confirmation number, contract status, review status and liquidity platform status, transaction date, termination date, and position quantity, and the underlying elements of the contract include the underlying code and underlying market information;

[0017] The business logic control elements include transaction confirmation number, contract status, review status and liquidity platform status; the display elements include transaction date, termination date and position quantity.

[0018] Furthermore, the contract basic element structure is used to store common elements in various contracts, with the contract number as its unique primary key;

[0019] The contract transaction element structure is divided into multiple substructures, each substructure is used to store the differential elements of a certain type of contract;

[0020] The contract subject element structure is used to store the contract subject elements, with the transaction ID as its primary key.

[0021] Furthermore, the database table includes a contract basic element table, a contract transaction element table corresponding to a plurality of substructures of the contract transaction element structure, and a contract subject element table;

[0022] The contract basic element table is indexed to the contract transaction element table corresponding to the contract type through the stored contract number and contract type fields, and then associated to the contract subject element table through the secondary stored transaction ID.

[0023] Furthermore, the method for configuring the contract elements of each level of storage structure and its substructure of the three-level storage structure model includes:

[0024] Build a contract model factory. The so-called contract model factory is a maintenance and management module of the three-level storage structure model of over-the-counter derivative contract elements, which is used to configure each level of storage structure and the contract element information contained in its substructure according to the multi-level structure of the three-level storage structure model. The contract model factory is a device, specifically a data organization and management method of the three-level storage structure model of contract elements, which is a concept proposed by the present invention and is part of the content of the invention. There is no product that can be directly used on the market.

[0025] Furthermore, the method further comprises:

[0026] The backend service system encapsulates the interface of the three-level storage structure to provide data services to the foreground application system.

[0027] In a second aspect, the present application provides a three-level structure storage and management device for over-the-counter derivative contract elements, including:

[0028] Difference analysis module: used to obtain the contract elements of all types of contracts in the background service system, perform difference analysis on the contract elements, and obtain the common elements and difference elements of the contract elements;

[0029] Reanalysis module: used to reanalyze the common elements in various types of contracts and classify the common elements into basic elements of the contract and elements of the subject matter of the contract according to their business meanings;

[0030] Classification module: used to reclassify the basic elements of the contract into business logic control elements and display elements according to whether they participate in logic control;

[0031] A three-level storage structure module: used to construct a three-level storage structure model of contract data according to the classification results and the reclassification results; the three-level storage structure model of contract data includes a contract basic element structure, a contract transaction element structure and a contract subject element structure;

[0032] Configuration module: used to configure the contract elements of each level of storage structure and its substructure of the three-level storage structure model;

[0033] Table construction module: used to construct database tables according to the three-level storage structure model of the constructed contract data; the database tables include a contract basic element table corresponding to the contract basic element structure, a contract transaction element table corresponding to the contract transaction element structure, and a contract transaction element table corresponding to the contract subject element structure.

[0034] Furthermore, the contract basic element structure is used to store common elements in various contracts, with the contract number as its unique primary key;

[0035] The contract transaction element structure is divided into multiple substructures, each substructure is used to store the differential elements of a certain type of contract;

[0036] The element structure of the contract subject is used to store the elements of the contract subject, with the transaction ID as its primary key;

[0037] The basic elements of the contract include the transaction confirmation number, contract status, review status and liquidity platform status, transaction date, termination date, and position quantity. The underlying elements of the contract include the underlying code and underlying market information.

[0038] The business logic control elements include transaction confirmation number, contract status, review status and liquidity platform status; the display elements include transaction date, termination date and position quantity.

[0039] Furthermore, the database table includes a contract basic element table, a contract transaction element table corresponding to a plurality of substructures of the contract transaction element structure, and a contract subject element table;

[0040] The contract basic element table is indexed to the contract transaction element table corresponding to the contract type through the stored contract number and contract type fields, and then associated to the contract subject element table through the secondary stored transaction ID.

[0041] In a third aspect, the present invention provides a three-level structure storage and management device for over-the-counter derivatives contract elements, including a processor and a storage medium;

[0042] The storage medium is used to store instructions;

[0043] The processor is configured to operate according to the instructions to execute the steps of the method described in the first aspect.

[0044] Compared with the prior art, the present invention has the following beneficial effects:

[0045] 1. The present invention provides a method for storing and managing a three-level structure of over-the-counter derivative contract elements. By analyzing the contract elements of various types of contracts, the contract elements are classified and organized into a three-level structure, namely, a contract basic element structure, a contract transaction element structure, and an underlying element structure. The contract basic element structure and the underlying element structure are composed of common contract elements of various types of contracts, and the contract transaction element structure is composed of differential elements of the contract. The method for storing and managing the three-level structure of over-the-counter derivative contract elements takes into account both the commonality and the differences of the contract elements in the process of contract element storage, controls and manages the storage of contract elements of various types of contracts, makes the system easy to maintain, has strong readability, and adapts to the demands of the rapid development of over-the-counter derivatives business.

[0046] 2. The present invention solves the problem that a large amount of redundant data will exist for each contract stored in the storage structure, thereby avoiding the waste of storage resources. The universal storage structure has strong readability, which is conducive to later data maintenance. At the same time, the storage structure also saves the business connections between contracts of various types, reducing the difficulty of system development.

[0047] 3. The advantage of the present invention is that by using the three-level structure storage and management method for over-the-counter derivatives contract elements, the hierarchical structure of different types of over-the-counter derivatives contract elements is re-divided. The design of the three-level storage structure not only focuses on the commonalities of contract elements of different types of contracts, but also takes into account their differences. At the same time, in the implementation process of the system, the difference between logical control elements and display elements is highlighted.

[0048] 4. The background service system of the present invention realizes the configurability of the three-level storage management method of contract elements, making the storage structure of contract elements more reasonable and iterative development more convenient. When a new contract type is added, only a set of models corresponding to the contract elements of the new contract type is maintained in the contract model factory to complete most of the basic function development of the contract module, which greatly shortens the development iteration cycle.

[0049] 5. While avoiding the dilemma of adding a new type of contract in the traditional development process, which requires the creation of a new contract storage structure or the existence of a large number of redundant fields, the present invention greatly improves the utilization rate of the storage space of the background system and the development efficiency, reduces the repetitive coding work of the background developers for the common elements of the contract, and significantly improves the quality of function delivery. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1 A schematic diagram of a three-level storage structure in a three-level structure storage management method for over-the-counter derivative contract elements of the present invention;

[0051] Figure 2 A storage structure flow chart is created for a three-level structure storage management method for over-the-counter derivative contract elements of the present invention. DETAILED DESCRIPTION

[0052] The present invention will be further described below in conjunction with the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and cannot be used to limit the protection scope of the present invention.

[0053] Embodiment 1:

[0054] This embodiment provides a three-level structure storage management method for OTC derivative contract elements, and defines a new storage structure for OTC derivative contract elements, that is, by re-dividing and classifying the contract elements of various types of OTC derivative contracts according to whether they are common elements and whether the elements participate in logical control, and using the contract model factory to reintegrate the classified contract elements to form a corresponding three-level storage structure, and finally based on the formed three-level storage structure, the OTC derivative contract elements are stored and persisted, reducing storage costs while improving R&D efficiency. Specifically, the following steps are included:

[0055] Step 1: When users maintain a new type of OTC derivative contract, they need to systematically analyze the contract elements of this type of contract. First, they classify the contract elements according to whether they are common elements, and classify them into two categories: common contract elements and different contract elements. Among them, common contract elements are a collection of public contract elements, and different contract elements are a collection of different contract elements. Common contract elements are further classified according to the different objects they describe, and are divided into two categories: basic contract elements and subject contract elements. Basic contract elements describe the characteristic information of the contract itself, and subject contract elements describe the characteristic information of the contract hook.

[0056] Step 2: According to whether the contract elements participate in business logic control, the basic elements of the contract are split twice into control elements and non-control elements. Non-control elements are also called display elements. Control elements frequently participate in the system's process control and are stored separately. Display elements only participate in the display of contract elements. All display elements are stored in a json string.

[0057] Step 3: Based on the classification results of steps 1 and 2, construct a three-level storage structure model for OTC derivative contract elements. The first level: the contract basic element structure is used to store the basic elements of various types of contracts. The structure is divided into two parts: control elements and display elements. The contract number is its unique primary key and no duplication is allowed. The second level is: the contract transaction element structure. The contract transaction element structure is divided into multiple substructures according to different contract types. Each substructure contains the differential elements of a certain type of contract. The third level: the contract subject element structure stores the subject elements linked to the contract. The transaction ID is its primary key and cannot be repeated, such as Figure 1 shown.

[0058] Step 4: Construct a contract model factory. The so-called contract model factory is a maintenance and management module of the three-level storage structure model of OTC derivative contract elements. The contract model factory configures each level of storage structure and the contract element information contained in its substructure. The contract model factory is a device, specifically a data organization and management method device of the three-level storage structure model of contract elements that applies the management method of the present invention. It is a concept proposed by the present invention and is constructed based on the three-level storage structure model.

[0059] Step 5: The backend service system establishes a corresponding database table structure based on the contract element storage structure model constructed in step 3, including a contract basic element table, multiple contract transaction element tables corresponding to the contract transaction element substructures, and a contract subject element table. That is, the data information of a contract will be split and stored in three database tables. The contract basic element information is stored in the contract basic element table (first-level storage structure), the contract transaction element information is stored in the contract transaction element table (second-level storage structure), and the contract subject element information is stored in the contract subject element table (third-level storage structure). The first-level storage indexes the contract transaction element table (second-level storage structure) corresponding to the contract type through the stored contract number and contract type fields, and then associates it with the contract subject element table (third-level storage structure) through the transaction ID field of the second-level storage.

[0060] Step 6: The backend service system encapsulates the interface of the three-level storage structure and provides data services to the frontend application system.

[0061] Figure 1 A schematic diagram of a three-level storage structure in a three-level structure storage management method for over-the-counter derivative contract elements of the present invention is shown, and the three-level storage structures are respectively a contract basic element structure, a contract transaction element structure and a contract subject element structure, wherein the contract basic element structure is a collection of common elements of various types of contracts, including contract type, contract number, contract status, contract review status, etc.; the contract transaction element structure is divided into multiple substructures, each substructure records the elements that differ between a certain type of contract and other types of contracts; the contract subject element structure records the subject information of the contract, including transaction ID, subject code, subject market and other elements.

[0062] Figure 2 A flowchart of creating a storage structure for a three-level structure storage management method for OTC derivatives contract elements is shown. In actual application, the main steps include:

[0063] Step 1: Obtain the contract elements of all types of contracts in the background service system, conduct difference analysis on the contract elements, and obtain the common elements and difference elements of the contract elements.

[0064] Step 2: Re-analyze the common elements of each type of contract, and divide the common elements into two categories: basic contract elements and contract subject elements according to their business meaning. The basic contract elements include transaction confirmation number, contract status, review status, liquidity platform status, transaction date, termination date, position quantity and other information. The subject elements include subject code, subject market and other information.

[0065] Step 3: Reclassify the basic elements of the contract generated in step 2 according to whether they participate in logic control, and distinguish between business logic control elements and non-business logic control elements (i.e. display elements). Business logic control elements include transaction confirmation number, contract status, review status, and liquidity platform status, etc. Display elements mainly include transaction date, termination date, number of positions, etc.

[0066] Step 4: Construct a three-level storage structure model for contract data based on the classification results. The first-level structure is the contract basic element structure, the second-level structure is the contract transaction element structure, and the third-level structure is the contract subject element structure. The contract basic element structure stores the common elements of various types of contracts. The contract transaction element structure is divided into multiple substructures, each substructure contains the differential elements of a certain type of contract, and the contract subject element structure stores the subject information of the contract.

[0067] Step 5: Configure each level of the three-level storage structure model and its substructures in the contract model factory to contain contract element information.

[0068] Step 6: Based on the constructed three-level storage structure model of contract data, construct corresponding database tables, a contract basic element table, a contract transaction element table corresponding to multiple substructures of the contract transaction element structure, and a contract subject element table.

[0069] The present invention is further described in detail below in conjunction with specific embodiments:

[0070] In the over-the-counter derivatives management system, three types of contracts need to be supported: option contracts, income certificate contracts, and income swap contracts. The contract elements contained in the three contracts are shown in the following table.

[0071]

[0072] First, the contract elements of the three types of contracts are analyzed. All three types of contracts include contract number, contract type, transaction confirmation number, transaction date, termination date, position, contract review status, contract status, liquidity platform status, underlying code, underlying market and other elements. These elements are common elements, and other elements of each type of contract are different elements, such as the barrier status of option contracts, knock-in date, knock-out observation date and barrier observation date. The classification results are shown in the following table.

[0073]

[0074]

[0075] In view of the above classification results, the common elements in the classification results of contract elements are divided into two categories according to their business meanings: basic contract elements and underlying elements. The basic elements of the contract itself described by contract number, contract type, transaction confirmation number, transaction date, termination date, position, contract review status, contract status, and liquidity platform status, the underlying code, and the underlying market describe the information of the contract underlying, as shown in the following table.

[0076]

[0077] According to whether the elements participate in business logic control, the basic elements are further classified into logic control elements and display elements. Contract number, contract type, contract review status, contract status, and liquidity platform status participate in contract business logic control, so they are classified as control elements. Transaction confirmation number, transaction date, termination date, and positions only participate in the display of the contract and are display elements, as shown in the following table.

[0078]

[0079] Finally, based on the classification results of contract elements, a three-level storage structure is constructed: contract basic information structure, contract transaction information structure - options, contract transaction information structure - income certificates, contract transaction information structure - income swaps, and contract subject information structure. Figure 1 As shown, the contract model configuration and maintenance are completed in the contract model factory.

[0080] Through the above implementation process, it is not difficult to find that if the backend application system needs to support a new contract type, in terms of system design: it is only necessary to add a substructure to the contract transaction element structure to record the differences between this type of contract and other types of contracts, and the design of the storage model can be completed, which greatly simplifies the design process; in terms of system implementation, it is only necessary to maintain the newly added contract transaction element substructure to the contract model factory to complete the development, which greatly improves the development efficiency.

[0081] Embodiment 2:

[0082] This embodiment provides a three-level structure storage and management device for over-the-counter derivatives contract elements, including:

[0083] Difference analysis module: used to obtain the contract elements of all types of contracts in the background service system, perform difference analysis on the contract elements, and obtain the common elements and difference elements of the contract elements;

[0084] Reanalysis module: used to reanalyze the common elements in various types of contracts and classify the common elements into basic elements of the contract and elements of the subject matter of the contract according to their business meanings;

[0085] Classification module: used to reclassify the basic elements of the contract into business logic control elements and display elements according to whether they participate in logic control;

[0086] A three-level storage structure module: used to construct a three-level storage structure model of contract data according to the classification results and the reclassification results; the three-level storage structure model of contract data includes a contract basic element structure, a contract transaction element structure and a contract subject element structure;

[0087] Configuration module: used to configure the contract elements of each level of storage structure and its substructure of the three-level storage structure model;

[0088] Table construction module: used to construct database tables according to the three-level storage structure model of the constructed contract data; the database tables include a contract basic element table corresponding to the contract basic element structure, a contract transaction element table corresponding to the contract transaction element structure, and a contract transaction element table corresponding to the contract subject element structure.

[0089] Specifically, the contract basic element structure is used to store common elements in various contracts, with the contract number as its unique primary key;

[0090] The contract transaction element structure is divided into multiple substructures, each substructure is used to store the differential elements of a certain type of contract;

[0091] The element structure of the contract subject is used to store the elements of the contract subject, with the transaction ID as its primary key;

[0092] The basic elements of the contract include the transaction confirmation number, contract status, review status and liquidity platform status, transaction date, termination date, and position quantity. The underlying elements of the contract include the underlying code and underlying market information.

[0093] The business logic control elements include transaction confirmation number, contract status, review status and liquidity platform status; the display elements include transaction date, termination date and position quantity.

[0094] Specifically, the database table includes a contract basic element table, a contract transaction element table corresponding to multiple substructures of the contract transaction element structure, and a contract subject element table;

[0095] The contract basic element table is indexed to the contract transaction element table corresponding to the contract type through the stored contract number and contract type fields, and then associated to the contract subject element table through the secondary stored transaction ID.

[0096] The device of this embodiment can be used to implement the method described in Embodiment 1:

[0097] Step 1: When users maintain a new type of OTC derivative contract, they need to systematically analyze the contract elements of this type of contract. First, they classify the contract elements according to whether they are common elements, and classify them into two categories: common contract elements and different contract elements. Among them, common contract elements are a collection of public contract elements, and different contract elements are a collection of different contract elements. Common contract elements are further classified according to the different objects they describe, and are divided into two categories: basic contract elements and subject contract elements. Basic contract elements describe the characteristic information of the contract itself, and subject contract elements describe the characteristic information of the contract hook.

[0098] Step 2: According to whether the contract elements participate in business logic control, the basic elements of the contract are split twice into control elements and non-control elements. Non-control elements are also called display elements. Control elements frequently participate in the system's process control and are stored separately. Display elements only participate in the display of contract elements. All display elements are stored in a json string.

[0099] Step 3: Based on the classification results of steps 1 and 2, construct a three-level storage structure model for OTC derivative contract elements. The first level: the contract basic element structure is used to store the basic elements of various types of contracts. The structure is divided into two parts: control elements and display elements. The contract number is its unique primary key and no duplication is allowed. The second level is: the contract transaction element structure. The contract transaction element structure is divided into multiple substructures according to different contract types. Each substructure contains the differential elements of a certain type of contract. The third level: the contract subject element structure stores the subject elements linked to the contract. The transaction ID is its primary key and cannot be repeated, such as Figure 1 shown.

[0100] Step 4: Build a contract model factory. The so-called contract model factory is a maintenance and management module for the three-level storage structure model of over-the-counter derivatives contract elements. The contract model factory configures each level of storage structure and the contract element information contained in its substructure.

[0101] Step 5: The backend service system establishes a corresponding database table structure based on the contract element storage structure model constructed in step 3, including a contract basic element table, multiple contract transaction element tables corresponding to the contract transaction element substructures, and a contract subject element table. That is, the data information of a contract will be split and stored in three database tables. The contract basic element information is stored in the contract basic element table (first-level storage structure), the contract transaction element information is stored in the contract transaction element table (second-level storage structure), and the contract subject element information is stored in the contract subject element table (third-level storage structure). The first-level storage indexes the contract transaction element table (second-level storage structure) corresponding to the contract type through the stored contract number and contract type fields, and then associates it with the contract subject element table (third-level storage structure) through the transaction ID field of the second-level storage.

[0102] Step 6: The backend service system encapsulates the interface of the three-level storage structure and provides data services to the frontend application system.

[0103] Embodiment three:

[0104] This embodiment provides a processor and a storage medium;

[0105] The storage medium is used to store instructions;

[0106] The processor is configured to operate according to the instruction to execute the steps described in the first embodiment:

[0107] Step 1: When users maintain a new type of OTC derivative contract, they need to systematically analyze the contract elements of this type of contract. First, they classify the contract elements according to whether they are common elements, and classify them into two categories: common contract elements and different contract elements. Among them, common contract elements are a collection of public contract elements, and different contract elements are a collection of different contract elements. Common contract elements are further classified according to the different objects they describe, and are divided into two categories: basic contract elements and subject contract elements. Basic contract elements describe the characteristic information of the contract itself, and subject contract elements describe the characteristic information of the contract hook.

[0108] Step 2: According to whether the contract elements participate in business logic control, the basic elements of the contract are split twice into control elements and non-control elements. Non-control elements are also called display elements. Control elements frequently participate in the system's process control and are stored separately. Display elements only participate in the display of contract elements. All display elements are stored in a json string.

[0109] Step 3: Based on the classification results of steps 1 and 2, construct a three-level storage structure model for OTC derivative contract elements. The first level: the contract basic element structure is used to store the basic elements of various types of contracts. The structure is divided into two parts: control elements and display elements. The contract number is its unique primary key and no duplication is allowed. The second level is: the contract transaction element structure. The contract transaction element structure is divided into multiple substructures according to different contract types. Each substructure contains the differential elements of a certain type of contract. The third level: the contract subject element structure stores the subject elements linked to the contract. The transaction ID is its primary key and cannot be repeated, such as Figure 1 shown.

[0110] Step 4: Build a contract model factory. The so-called contract model factory is a maintenance and management module for the three-level storage structure model of over-the-counter derivatives contract elements. The contract model factory configures each level of storage structure and the contract element information contained in its substructure.

[0111] Step 5: The backend service system establishes a corresponding database table structure based on the contract element storage structure model constructed in step 3, including a contract basic element table, multiple contract transaction element tables corresponding to the contract transaction element substructures, and a contract subject element table. That is, the data information of a contract will be split and stored in three database tables. The contract basic element information is stored in the contract basic element table (first-level storage structure), the contract transaction element information is stored in the contract transaction element table (second-level storage structure), and the contract subject element information is stored in the contract subject element table (third-level storage structure). The first-level storage indexes the contract transaction element table (second-level storage structure) corresponding to the contract type through the stored contract number and contract type fields, and then associates it with the contract subject element table (third-level storage structure) through the transaction ID field of the second-level storage.

[0112] Step 6: The backend service system encapsulates the interface of the three-level storage structure and provides data services to the frontend application system.

[0113] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0114] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0115] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0116] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0117] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the technical principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A method for storing and managing the three-level structure of over-the-counter derivative contract elements, characterized in that: The following steps are involved: Obtain the contract elements of all types of contracts in the backend service system, perform difference analysis on the contract elements, and obtain the common elements and difference elements of the contract elements; Re-analyze the common elements in various types of contracts and classify them into basic elements of contracts and subject matter elements of contracts according to their business meanings; According to whether they participate in logic control, the basic elements of the contract are reclassified into business logic control elements and display elements; Constructing a three-level storage structure model of contract data according to the classification results and the reclassification results; the three-level storage structure model of contract data includes a contract basic element structure, a contract transaction element structure and a contract subject element structure; Configuring the contract elements of each level of storage structure and its substructure of the three-level storage structure model; According to the constructed three-level storage structure model of the contract data, a database table is constructed; the database table includes a contract basic element table corresponding to the contract basic element structure, a contract transaction element table corresponding to the contract transaction element structure, and a contract transaction element table corresponding to the contract subject element structure; Construct a three-level storage structure model for OTC derivatives contract elements. The first level: the contract basic element structure is used to store the basic elements of various types of contracts. The structure is divided into two parts: control elements and display elements. The contract number is its unique primary key and no duplication is allowed. The second level is: the contract transaction element structure. The contract transaction element structure is divided into multiple substructures according to different contract types. Each substructure contains the differential elements of a certain type of contract. Level 3: The contract subject element structure stores the subject elements linked to the contract. The transaction ID is its primary key and cannot be repeated.

2. The method for storing and managing the three-level structure of OTC derivative contract elements according to claim 1, characterized in that: The basic elements of the contract include the transaction confirmation number, contract status, review status and liquidity platform status, transaction date, termination date, and position quantity. The underlying elements of the contract include the underlying code and underlying market information. The business logic control elements include transaction confirmation number, contract status, review status and liquidity platform status; the display elements include transaction date, termination date and position quantity.

3. The method for storing and managing the three-level structure of OTC derivative contract elements according to claim 2, characterized in that: The contract basic element structure is used to store the common elements in various contracts, with the contract number as its unique primary key; The contract transaction element structure is divided into multiple substructures, each substructure is used to store the differential elements of a certain type of contract; The contract subject element structure is used to store the contract subject elements, with the transaction ID as its primary key.

4. The method for storing and managing the three-level structure of OTC derivative contract elements according to claim 3, characterized in that: The database table includes a contract basic element table, a plurality of contract transaction element tables corresponding to a plurality of substructures of the contract transaction element structure, and a contract subject element table; The contract basic element table is indexed to the contract transaction element table corresponding to the contract type through the stored contract number and contract type fields, and then associated to the contract subject element table through the secondary stored transaction ID.

5. The method for storing and managing the three-level structure of OTC derivative contract elements according to claim 1, characterized in that: The method for configuring the contract elements of each level storage structure and its substructure of the three-level storage structure model includes: According to the multi-level structure of the three-level storage structure model, configure each level of storage structure and the contract element information contained in its substructure.

6. The method for storing and managing the three-level structure of OTC derivative contract elements according to claim 1, characterized in that: The method further comprises: The backend service system encapsulates the interface of the three-level storage structure to provide data services to the foreground application system.

7. A three-level structure storage and management device for over-the-counter derivatives contract elements, characterized in that: include: Difference analysis module: used to obtain the contract elements of all types of contracts in the background service system, perform difference analysis on the contract elements, and obtain the common elements and difference elements of the contract elements; Reanalysis module: used to reanalyze the common elements in various types of contracts and classify the common elements into basic elements of the contract and elements of the subject matter of the contract according to their business meanings; Classification module: used to reclassify the basic elements of the contract into business logic control elements and display elements according to whether they participate in logic control; A three-level storage structure module: used to construct a three-level storage structure model of contract data according to the classification results and the reclassification results; the three-level storage structure model of contract data includes a contract basic element structure, a contract transaction element structure and a contract subject element structure; Configuration module: used to configure the contract elements of each level of storage structure and its substructure of the three-level storage structure model; Table building module: used to build database tables according to the constructed three-level storage structure model of contract data; the database tables include a contract basic element table corresponding to the contract basic element structure, a contract transaction element table corresponding to the contract transaction element structure, and a contract transaction element table corresponding to the contract subject element structure; Construct a three-level storage structure model for OTC derivatives contract elements. The first level: the contract basic element structure is used to store the basic elements of various types of contracts. The structure is divided into two parts: control elements and display elements. The contract number is its unique primary key and no duplication is allowed. The second level is: the contract transaction element structure. The contract transaction element structure is divided into multiple substructures according to different contract types. Each substructure contains the differential elements of a certain type of contract. Level 3: The contract subject element structure stores the subject elements linked to the contract. The transaction ID is its primary key and cannot be repeated.

8. The three-level structure storage and management device for over-the-counter derivative contract elements according to claim 7, characterized in that: The contract basic element structure is used to store the common elements in various contracts, with the contract number as its unique primary key; The contract transaction element structure is divided into multiple substructures, each substructure is used to store the differential elements of a certain type of contract; The contract subject element structure is used to store the contract subject elements, with the transaction ID as its primary key; The basic elements of the contract include the transaction confirmation number, contract status, review status and liquidity platform status, transaction date, termination date, and position quantity. The underlying elements of the contract include the underlying code and underlying market information. The business logic control elements include transaction confirmation number, contract status, review status and liquidity platform status; the display elements include transaction date, termination date and position quantity.

9. The three-level structure storage and management device for over-the-counter derivative contract elements according to claim 8, characterized in that: The database table includes a contract basic element table, a contract transaction element table corresponding to multiple substructures of the contract transaction element structure, and a contract subject element table; The contract basic element table is indexed to the contract transaction element table corresponding to the contract type through the stored contract number and contract type fields, and then associated to the contract subject element table through the secondary stored transaction ID.

10. A three-level structure storage and management device for over-the-counter derivatives contract elements, characterized in that: including processor and storage medium; The storage medium is used to store instructions; The processor is configured to operate according to the instructions to execute the steps of the method according to any one of claims 1 to 6.

Images