Order data creation, query and modification method and device

Abstract

The invention relates to the technical field of aviation, in particular to an order data creation, query and modification method and device, and the method comprises the steps: receiving data information of an order created by a passenger for the first time; generating order data in an XML format containing the SPNRID by using the data information of the order created for the first time; the method comprises the following steps: splitting order data in an XML format into a plurality of XML node fragments taking SPNRID as a primary key according to business meanings; each XML node segment with the SPNRID as the primary key is stored in an XML DATA field of a CLOB type of a specified data table, and each data table takes the SPNRID as the primary key. The super passenger reservation record SPNR is created by using a standardized XML format, the SPNR is split and then stored in each database table, a data table does not need to be newly added in a database along with the increase of order types, a field does not need to be independently added for each piece of new order information, the design of the database is simplified, and the efficiency is improved. And the complexity and the coupling degree of the system are greatly reduced, so that the maintenance of the system is simpler and more convenient.

Description

Technical Field

[0001] This disclosure relates to the technical field of aviation, and in particular to a method and apparatus for creating, querying, and modifying order data. Background Technology

[0002] In the aviation industry, with globalization and the rapid development of the tourism industry, airlines are facing unprecedented challenges in storing order data. Every day, millions of passengers purchase tickets globally, and this order data needs to be stored and managed quickly and accurately. In this process, the scale and complexity of the order data place enormous pressure on airlines' order storage systems.

[0003] To adapt to the market shift towards travel retail, airlines' primary task is to identify and acquire passengers' needs for various service products throughout their travel cycle, such as insurance, paid seats, and paid meals. This has led to the creation of multiple order types beyond traditional ticket orders. Each order contains a wealth of details, such as passenger name, flight number, purchase date, fare, payment method, and refund / change information. This detailed information needs to be properly stored and managed. This places higher demands on the order data structure and storage method in the order storage system. A concise, efficient, low-complexity, loosely coupled, and highly maintainable order data structure and storage method must be designed to support the increasingly diverse order types. Therefore, the design of the order data structure and database tables must be specifically optimized to facilitate the storage and flow of order information.

[0004] Before the variety of airline ticket products and services became so extensive, traditional order storage structures were based on product categories, with each product stored in its own independent table, and the tables linked by foreign keys. All information for airline ticket orders or supplementary product / service orders needed to be planned at the top-level during the initial database table design phase, with each piece of information defined as a separate data field in a table of a specified type.

[0005] This structure faces two major problems: First, if changes in demand later necessitate adding new data items to a certain type of order, the corresponding data table will need an additional column (this is highly probable for a single flight ticket or ancillary service product). This has a significant impact on the entire system, including the need to modify and retest the tested SQL statements and handle compatibility issues with old order data. Second, if a passenger books, changes, or cancels an associated ancillary service product related to their flight ticket order, not only must the flight ticket order data table be modified, but the data tables for the associated products or services must also be located and modified to update the passenger's entire order. With the increasing variety of ancillary services offered by flight tickets, this structure constantly increases the system's complexity and coupling, while simultaneously reducing its maintainability. Summary of the Invention

[0006] To address the aforementioned issues, this disclosure provides a method and apparatus for creating, querying, and modifying data, which can minimize modifications to the database structure to meet the needs of frequent changes in order information items.

[0007] Firstly, a method for creating order data is provided, including: Receive data information from passengers' first order creation; Generate order data in XML format, including SPNRID, using the data information from the initial order creation; The XML format order data is split into multiple XML node fragments with SPNRID as the primary key, according to the business meaning; Each XML node fragment with SPNRID as the primary key is stored in the XMLDATA field of type CLOB in the specified data table, where SPNRID is the primary key for each data table.

[0008] Furthermore, it also includes: setting the SPNRID and XML DATA fields in each data table as key fields; and extracting information that can be used as order query conditions from XML node fragments and setting it as a separate field for easy use as query filtering conditions.

[0009] Furthermore, based on the XSD file, order data in XML format containing SPNRID is generated using the data information from the initial order creation; The XSD file defines the type, number, attributes, and relationships of each node in the XML node fragment corresponding to the Super Passenger Reservation Record (SPNR).

[0010] Furthermore, one SPNRID corresponds to three data tables: the UNIQUEITEM table, the ITEM table, and the ORDER table. The UNIQUEITEM table stores information about nodes in the XML representation of the SPNR where the number of nodes is unique and only one row is needed in each SPNR. The ITEM table stores information about nodes in the XML representation of the SPNR where the number of nodes is not unique and there are one or more nodes. The ORDER table stores information about the nodes of the ticket products and their ancillary service products in the SPNR.

[0011] Furthermore, the UNIQUEITEM table stores the POS order generation channel node, the Pricing overall price node, the PaymentDetails payment information node, the Audits operation record node, the Queues processing queue node, and the AssociatedBookings associated order node; The ITEM table stores the Customer passenger information node, the Remarks refund and modification information node, the Warnings warning information node, and the Errors error information node. The ORDER table stores the ModularProduct product module node.

[0012] Secondly, a method for querying order data is provided, including: Determine SPNRID; Using the SPNRID, the XML node fragment of the order is obtained from each data table. Each data table has SPNRID as the primary key, which is responsible for storing the content of different nodes in the Super Passenger Reservation Record SPNR. The node information is stored as a whole through the XML DATA field of type CLOB. The sum of the nodes stored in the CLOB type field of each data table can be assembled into a complete SPNR. All the acquired XML node fragments are combined into a complete, XML-formatted Super Passenger Reservation Record (SPNR) data set. Extract relevant data from the Super Passenger Reservation Record (SPNR) and display it.

[0013] Furthermore, after assembling all the acquired XML node fragments into a complete, XML-formatted Super Passenger Reservation Record (SPNR) data, and before extracting relevant data from the SPNR for display, the method further includes: The structure and content of the Super Passenger Reservation Record (SPNR) are constrained and validated using an XSD file, which defines the type, number, attributes, and relationships of each node in the SPNR.

[0014] Thirdly, a method for modifying order data is provided, including: Receive SPNRID and modified content; Based on SPNRID, retrieve the XML node fragment of the Super Passenger Reservation Record SPNR pointed to by that SPNRID from all data tables; All the acquired XML node fragments are combined into a complete XML structured Super Passenger Reservation Record (SPNR) data. Based on the changes, make targeted modifications to the node content in SPNR; The modified Super Passenger Reservation Record (SPNR) is then broken down into XML node fragments with SPNRID as the primary key, based on its business meaning. Each XML node fragment with SPNRID as the primary key is stored in the XMLDATA field of type CLOB in the specified data table, where SPNRID is the primary key for each data table.

[0015] Fourthly, an order data creation device is provided, comprising: The receiving module is used to receive data information from passengers when they first create an order; The generation module is used to generate order data in XML format, which includes SPNRID, using the data information from the initial order creation. The splitting module is used to split XML format order data into multiple XML node fragments with SPNRID as the primary key, based on business meaning; The storage module is used to store each XML node fragment with SPNRID as the primary key into a CLOB type XML DATA field of a specified data table, where each data table uses SPNRID as the primary key.

[0016] Furthermore, it also includes: The configuration unit is used to set the SPNRID and XML DATA fields in each data table as key fields; and to extract information that can be used as order query conditions from the XML node fragments and set it as a separate field for easy use as query filtering conditions.

[0017] Fifthly, an order data query device is provided, comprising: The determination module is used to determine the SPNRID; The acquisition module is used to retrieve the XML node fragment of the order from each data table using the SPNRID. Each data table has SPNRID as the primary key, which is responsible for storing the content of different nodes in the Super Passenger Reservation Record SPNR. The node information is stored as a whole through the XML DATA field of type CLOB. The sum of the nodes stored in the CLOB type field of each data table can be assembled into a complete SPNR. The combination module is used to combine all the acquired XML node fragments into a complete, XML-formatted Super Passenger Reservation Record (SPNR) data. The display module is used to extract relevant data from the Super Passenger Reservation Record (SPNR) and display it.

[0018] Furthermore, it also includes: The verification module is used to constrain and verify the structure and content of the Super Passenger Reservation Record (SPNR) using an XSD file. The XSD file defines the type, number, attributes, and interrelationships of each node in the Super Passenger Reservation Record (SPNR).

[0019] Sixthly, an order data modification device is provided, comprising: The receiving module is used to receive SPNRID and modified content; The acquisition module is used to retrieve the XML node fragment of the Super Passenger Reservation Record SPNR pointed to by the SPNRID from all data tables based on the SPNRID. The combination module is used to combine all the acquired XML node fragments into a complete XML structured Super Passenger Reservation Record (SPNR) data. The modification module is used to modify the node content in SPNR according to the modification content; The splitting module is used to split the modified Super Passenger Reservation Record (SPNR) into XML node fragments with SPNRID as the primary key, based on the business meaning. The storage module is used to store each XML node fragment with SPNRID as the primary key into a CLOB type XML DATA field of a specified data table, where each data table uses SPNRID as the primary key.

[0020] In a seventh aspect, an electronic device is provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; The processor, when executing a program stored in memory, implements the method described above.

[0021] Eighthly, a computer storage medium is provided, wherein a computer program is stored therein, and the computer program, when executed by a processor, implements the above-described method.

[0022] Compared with the prior art, this disclosure has the following advantages: 1. Consistency: By using a standardized XML format, SPNR ensures consistency and interoperability in data transmission between different microservices. This not only simplifies the development process but also promotes system modularity and componentization.

[0023] 2. Flexibility: SPNR's design allows its internal nodes to be expanded or adjusted according to actual business needs without affecting the overall structure. It abandons the earlier approach of creating a separate data table for each order type and a separate field for each order's information. Instead, it designs a solution that supports continuous expansion of order types while requiring no new data tables or changes to existing data table fields. This reduces system complexity, decoupling, and maintainability. This feature enables the system to quickly respond to market changes and service innovations.

[0024] 3. Constraints and Validation: To ensure data consistency and correctness, SPNR's design incorporates XSD files as constraints on its structure and content. The XSD file defines the type, number, attributes, and relationships of each node in SPNR, ensuring data validity and integrity. Rigorous schema validation allows for timely detection and correction of errors during data flow, improving system reliability and stability.

[0025] Other features and advantages of this disclosure will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the disclosure. The objects and other advantages of this disclosure may be realized and obtained by means of the structures pointed out in the description, claims and drawings. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 A schematic diagram of the SPNR node configuration is shown; Figure 2 A schematic diagram illustrating the creation of order data according to an embodiment of the present disclosure is shown; Figure 3A schematic diagram of an order data query according to an embodiment of the present disclosure is shown; Figure 4 A schematic diagram of a database table storage plan according to an embodiment of the present disclosure is shown; Figure 5 A schematic diagram illustrating a modification of existing order data according to an embodiment of this disclosure is shown. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0029] To address the numerous problems inherent in traditional order storage structures, this disclosure proposes a "unified order" storage solution. This solution aims to revolutionize the design of traditional order management systems by abandoning the old model where each order type operates with an independent data structure, each order type has its own separate database table, and each piece of order information occupies a separate field in the table. This results in a more flexible and efficient order storage system.

[0030] The following section first describes the design and implementation of the order data structure, as well as the design and implementation of the data tables in the database. Then, based on the design principles and implementation of the data structure and tables, the relevant uses are explained, including: order data creation methods, order data query methods, and order data modification methods. Finally, the order data creation device, order data query device, order data modification device, electronic equipment, and storage medium are described.

[0031] I. Design and Implementation of Order Data Structure In an order storage system, the flow of order data is a crucial link in ensuring smooth business processes. To achieve efficient, flexible, and easy-to-maintain data exchange, this disclosure adopts a data structure based on XML (Extensible Markup Language) to represent and transmit order information. This specific XML-formatted order data is named SPNR (SuperPassenger Name Record), designed to provide a unified and comprehensive data structure to carry all relevant information throughout the entire order lifecycle, including order creation, cancellations, and modifications.

[0032] 1. SPNR Design Principles for Order Data Structure Design Consistency: By using a standardized XML format, SPNR ensures consistency and interoperability in data transmission between different microservices. This not only simplifies the development process but also promotes system modularity and componentization.

[0033] Flexibility: SPNR's design allows its internal nodes to be expanded or adjusted according to actual business needs without affecting the overall structure. This feature enables the system to respond quickly to market changes and service innovations.

[0034] Constraints and Validation: To ensure data consistency and correctness, SPNR's design incorporates XSD (XML Schema Definition) files as constraints for its structure and content. The XSD file defines the type, number, attributes, and relationships of each node in SPNR, ensuring data validity and integrity. Rigorous schema validation allows for timely detection and correction of errors during data flow, improving system reliability and stability.

[0035] 2. Key Nodes in the Design of Order Data Structure: SPNR Order generation channel nodes: Record the source channels of orders, such as official website, mobile application, third-party platform, etc., to help track marketing results and optimize sales channels.

[0036] Flight ticket product details: Provide a detailed description of the purchased flight ticket, including flight number, departure point, destination, departure time, arrival time, etc., to ensure that passenger information is accurate.

[0037] Additional service product nodes: These cover optional services such as baggage check-in, paid seating, and paid meals, providing customers with a personalized travel experience.

[0038] Price Node: Includes total order amount and discount information, transparently displaying consumption details.

[0039] Payment node: Records payment methods, transaction status, payment vouchers, etc., to ensure fund security and facilitate subsequent inquiries.

[0040] Order operation log nodes: Track every step of the order processing process, such as order generation, ticketing, synchronization, rescheduling, cancellation, etc., to facilitate auditing and problem tracing.

[0041] Passenger node: Records basic information and contact details of passengers and their contacts.

[0042] Refund and Change Node: Records the flight ticket refund and change review process and detailed amount calculation.

[0043] Queue node: Indicates which stage of processing the current order is currently in.

[0044] Parent-child order node: Records the parent or child order number and main product information of the current order, providing a clear hierarchical relationship for easy management and statistical analysis.

[0045] Warning and Error Nodes: Record problems or anomalies encountered during order processing to assist in problem diagnosis and resolution.

[0046] Through this design, the SPNR is not merely a simple data carrier; it's more like a comprehensive order file, containing almost all the necessary information about the ticket and related ancillary services. This approach not only improves the integration and usability of information but also provides a solid foundation for subsequent business analysis, customer service, and operations management.

[0047] 3. Specific implementation of order data structure To achieve efficient management and flexible expansion of order information, this disclosure uses XML format to design the SPNR. Through this structured approach, the SPNR can not only carry rich order-related information but also ensure data consistency and integrity. The SPNR node in this disclosure is structured as follows: Figure 1 As shown, the details are as follows: (1) POS node 1) Purpose: To store channel information for generating orders, such as official websites, mobile applications, or third-party platforms.

[0048] 2) Constraint: Unique quantity, ensuring that each order can only have one clear source channel.

[0049] 3) Example:

[0050] (2) ModularProduct node 1) Purpose: To record information about airfare products and their ancillary services (such as baggage check-in, priority boarding, etc.).

[0051] 2) Constraints: Since each refund or change of a ticket will generate a new node, and a ticket can have multiple add-on products, there may be multiple instances of this node in SPNR.

[0052] 3) Example:

[0053] (3) Pricing node 1) Purpose: Includes the total amount of the order and details of all fees.

[0054] 2) Constraint: The quantity is unique, ensuring that the price information for each order is singular and clear.

[0055] 3) Example:

[0056] (4) PaymentDetails node 1) Purpose: To record information such as payment method, transaction status and payment voucher.

[0057] 2) Constraints: The number of nodes is unique, and there can be multiple child nodes, each representing a payment information.

[0058] 3) Example:

[0059] (5) Audits node 1) Purpose: To track and record all operations during the order processing process, including order generation, ticketing, refunds and changes, cancellations, etc.

[0060] 2) Constraints: The number of nodes is unique, and each node can have multiple child nodes, each representing an operation record.

[0061] 3) Example:

[0062] (6) Customer node 1) Purpose: To record basic information and contact details of passengers and their contacts.

[0063] 2) Constraints: Since passenger information may change and be updated over time, the number is not unique, and multiple versions are allowed.

[0064] 3) Example:

[0065] (7) Remarks node 1) Purpose: To record order refund and modification requests and their review process, which may involve multiple reviews to form multiple nodes.

[0066] 2) Constraints: The number is not unique and will increase dynamically based on the actual number of refunds and changes.

[0067] 3) Example:

[0068] (8) Queues node 1) Purpose: Indicates which stage of processing the current order is currently in.

[0069] 2) Constraints: The number of nodes is unique, and each node can have multiple child nodes, each representing a specific point in time and belonging to only one queue.

[0070] 3) Example:

[0071] (9) AssociatedBookings node 1) Purpose: To record the parent or child order number and main product information of the current order, providing a clear hierarchical relationship for easy management and statistical analysis.

[0072] 2) Constraints: The quantity is unique, but it can contain references to multiple related orders.

[0073] 3) Example:

[0074] (10) Warnings node and Errors node 1) Purpose: To record problems or abnormal situations encountered during the order process, and to assist in problem diagnosis and resolution.

[0075] 2) Constraints: The number is unique, but each node can contain multiple warning or error records.

[0076] 3) Example:

[0077] II. Design and Implementation of Data Tables in the Order Database 1. Design of data tables in the order database To achieve efficient, flexible, and easy-to-maintain order data management, this disclosure adopts an innovative database design approach, aiming to address the need for frequent changes in order information items by minimizing modifications to the database structure. The core design revolves around three main data tables, each responsible for storing the content of different nodes in the SPNR, and using CLOB (Character Large Object) type XMLDATA fields to store specific node information as a whole. Furthermore, to ensure rapid access and efficient querying of critical business information, each table also includes some important order information as separate fields based on actual needs. The design principles are as follows: Flexibility: By storing the content of different nodes in the SPNR within CLOB type XMLDATA fields, changes in order information items can be easily adapted. When information items in the order details are added or removed, this is reflected in the SPNR as an increase or decrease in the content of a specific node. For the database table, this translates to a change in the content stored in a CLOB type XMLDATA field, without affecting the number of fields in the table. No changes to the database table structure are required. This significantly improves system flexibility, enabling the business logic layer to respond more quickly to new requirements.

[0078] Simplified maintenance: By reducing direct manipulation of database table fields, database maintenance becomes much simpler. Developers no longer need to frequently adjust the database structure, thus reducing maintenance costs and technical risks.

[0079] Performance optimization: While storing large amounts of text data using CLOB fields may be considered performance-impacting, this issue can be effectively mitigated through proper indexing strategies and query optimization. Furthermore, separating frequently queried critical fields into individual columns can significantly improve query speed and response time.

[0080] 2. Specific implementation of data tables in the order database To achieve efficient storage and retrieval of content from different nodes in an XML-formatted SPNR, this disclosure employs an innovative database design. The scheme uses three main data tables to store the content from different SPNR nodes, and these tables are linked using the order number field SPNRID. The following is a detailed description of the database tables: UNIQUEITEM table 1) Purpose: Used to store node information in SPNR that is unique in quantity and requires only one line of record per order, such as POS (order generation channel), Pricing (overall price), PaymentDetails (payment information), Audits (operation records), Queues (processing queue), AssociatedBookings (associated orders), etc.

[0081] 2) Key fields: SPNRID (primary key): Order number, used to link to other tables.

[0082] XMLDATA (CLOB): Stores complete node information specified by SPNR.

[0083] Individual fields: Important information extracted based on business needs, such as TotalAmount and PaymentStatus, for easy and quick querying.

[0084] ITEM table 1) Purpose: Used to store information about nodes in SPNR that are not unique and may be multiple, such as Customer (passenger information), Remarks (refund and modification information), Warnings and Errors (warning and error messages).

[0085] 2) Key fields: SPNRID (primary key): Order number, used to link to other tables.

[0086] XMLDATA (CLOB): Stores complete node information specified by SPNR.

[0087] Individual fields, such as ChangeType and WarningCode, are used to extract key information for quick retrieval.

[0088] ORDER table 1) Purpose: This table is specifically used to store ModularProduct nodes, i.e., individual accounts, with one ModularProduct node corresponding to one row. Since an order may include multiple changes to the ticket and multiple additional services for different passengers, multiple rows of records in this table correspond to one order.

[0089] 2) Key fields: SPNRID (primary key): Order number, used to link to other tables.

[0090] XMLDATA (CLOB): Stores complete information about a ModularProduct node in the SPNR.

[0091] Individual fields: such as FlightNumber, extract key information for quick retrieval.

[0092] By designing the data structure and tables described above, a fixed number of tables are used to record node information for the Super Passenger Reservation Record Order Number (SPNRID). Therefore, it's unnecessary to add new tables to the database as order types increase, nor is it necessary to add separate fields for each new order. This simplifies the database design, significantly reduces system complexity and coupling, and makes system maintenance much easier. Developers can focus more on optimizing and innovating business logic, rather than spending a lot of time on database design adjustments.

[0093] 2. It helps improve the system's scalability and performance. By reducing redundant tables and fields in the database, query and update operations become more efficient, and response time is shortened.

[0094] III. Relevant Usage Methods 1. Order Data Creation Method like Figure 2 As shown, the methods for creating order data include: Step 201: Receive data information from the passenger's first order creation; Step 202: Generate order data in XML format using the data information from the initial order creation; The generated order data includes the Super Passenger Reservation Record Order Number SPNRID.

[0095] To ensure data consistency and accuracy, specific XSD constraints must be met when creating the SPNR data structure for order information. These specific XSD constraints are recorded in the XSD file. Step 202 specifically involves: based on the XSD file, generating order data in XML format containing the SPNRID using the data information from the initial order creation; wherein, the XSD file defines the type, number, attributes, and relationships of each node in the XML node fragment corresponding to the Super Passenger Reservation Record SPNR.

[0096] It should be noted that the order data generated here is the Super Passenger Reservation Record (SPNR), which is an XML data structure conforming to specific XSD constraints. When a passenger creates a new order, the system generates SPNR data in XML format according to the passenger information, selected flight information, selected additional service information, etc., and uses it as the carrier of order information for business flow within the system.

[0097] Step 203: Split the XML format order data into multiple node fragments according to the business meaning; The multiple node fragments here are split into multiple nodes with SPNRID as the primary key and are XML node fragments.

[0098] If the data received in step 201 includes passenger information, selected flight information, and selected additional service information, then according to the business meaning, the order data can be split into passenger information node fragments in XML format with SPNRID as the primary key, ticket product node fragments in XML format with SPNRID as the primary key, and additional service product node fragments in XML format with SPNRID as the primary key.

[0099] Step 204: Store each XML node fragment into a CLOB type field of a specified data table, where each data table uses the order number SPNRID as the primary key.

[0100] A CLOB type field refers to an XML DATA field of type CLOB.

[0101] Each data table here is responsible for storing the content of different nodes in the Super Passenger Reservation Record (SPNR), and the node information is stored as a whole through the XMLDATA field of type CLOB. The sum of the nodes stored in the CLOB type fields of each data table can be assembled into complete SPNR data.

[0102] Furthermore, to improve the efficiency of subsequent retrieval or querying, the SPNRID and XML DATA fields of the Super Passenger Reservation Record in each data table are set as key fields; information that can be used as order query conditions in each data table is also extracted from the XML fragment and set as a separate field for easy use as query filtering conditions.

[0103] Specifically, a Super Passenger Reservation Record (SPNRID) corresponds to three data tables: UNIQUEITEM, ITEM, and ORDER. The UNIQUEITEM table stores node information for unique entries, with each SPNR Super Passenger Reservation Record requiring only one row. The ITEM table stores node information for entries that are not unique or may have multiple entries. The ORDER table stores information about the ticket product and its ancillary services. It should be noted that two or more data tables corresponding to a Super Passenger Reservation Record (SPNRID) can be designed according to actual needs; the data tables disclosed herein are the primary tables.

[0104] Specifically, the UNIQUEITEM table stores the POS order generation channel node, the Pricing overall price node, the PaymentDetails payment information node, the Audits operation record node, the Queues processing queue node, and the AssociatedBookings associated order node; The ITEM table stores the Customer passenger information node, the Remarks refund and modification information node, the Warnings warning information node, and the Errors error information node. The ORDER table stores the ModularProduct product module node.

[0105] 2. Order Data Query Method like Figure 3 As shown, the methods for querying order data include: Step 301: Passengers check their existing order information.

[0106] Here, the existing order information contains the order number SPNRID. The order number can be entered into the front-end machine through scanning or other methods, and then the front-end machine sends it to the back-end.

[0107] Step 302: Based on the order number SPNRID, retrieve the XML node fragment of the order from all data tables; Each data table has SPNRID as the primary key, which is responsible for storing the content of different nodes in the Super Passenger Reservation Record (SPNR). The node information is stored as a whole through the XML DATA field of type CLOB. The sum of the nodes stored in the CLOB field of each data table can be assembled into a complete SPNR. Step 303: Combine all the acquired XML node fragments into a complete, XML-formatted SPNR data; Step 304: Extract relevant data from SPNR and display it to passengers through the front end.

[0108] To ensure data consistency and accuracy, after assembling all acquired XML node fragments into a complete, XML-formatted Super Passenger Reservation Record (SPNR) data set, and before extracting relevant data from the SPNR for display, the method further includes: The structure and content of the Super Passenger Reservation Record (SPNR) are constrained and validated using an XSD file, which defines the type, number, attributes, and relationships of each node in the SPNR.

[0109] Specifically, such as Figure 4 As shown, when determining the order number SPNRID for a Super Passenger Reservation Record, for example, using SPNRID, the XMLDATA (CLOB) field is retrieved from the UNIQUEITEM table to construct the POS (Order Generation Channel), Pricing (Overall Price), PaymentDetails (Payment Information), Audits (Operation Records), Queues (Processing Queues), and AssociatedBookings (Associated Orders) nodes in the SPNR structure. The XMLDATA (CLOB type) field is retrieved from the ITEM table to construct the Customer (Passenger Information), Remarks (Refund and Change Information), Warnings, and Errors nodes in the SPNR structure. The XMLDATA (CLOB type) field is retrieved from the ORDER table to construct the ModularProduct node in the SPNR structure. Thus, the CLOB type data scattered across the three tables forms a complete order SPNR structure.

[0110] 3. A method for modifying order data like Figure 5 As shown, the methods for modifying order data include: Step 501: Passenger modifies existing order information; Here, the existing order information contains the order number SPNRID. The order number SPNRID to be modified and the modification content can be entered into the front-end machine through scanning or other methods, and the front-end machine sends it to the back-end.

[0111] Enter the order number SPNRID to be modified and the content to be modified; Step 502: Based on the order number SPNRID, retrieve the XML node fragment that the order points to from all data tables; Step 503: Assemble all XML node fragments into a complete, XML-structured SPNR data; Step 504: Based on the changes made by the passenger, modify the content of the specified nodes in the SPNR accordingly; Step 505: The modified SPNR is split into multiple node fragments according to its business meaning; Step 506: Store each XML node fragment into a CLOB type field of a specified data table, with SPNRID as the primary key for each data table.

[0112] Each data table uses the Super Passenger Reservation Record Order Number SPNRID as the primary key, which is responsible for storing the content of different nodes in the Super Passenger Reservation Record SPNR. The node information is stored as a whole through the XMLDATA field of type CLOB. The sum of the nodes stored in the CLOB field of each data table can be assembled into complete SPNR data. Furthermore, after step 504 and before step 505, the method further includes: The structure and content of the Super Passenger Reservation Record (SPNR) are constrained and validated using XSD files. The XSD files define the type, number, attributes, and interrelationships of each node in the SPNR. Based on the above database table structure, when querying order details, the system uses the order number SPNRID as the key to retrieve the corresponding CLOB type data from each table and concatenates them into a complete SPNR structure. This process not only ensures data consistency and integrity but also guarantees high query performance. The reassembled SPNR can seamlessly flow between various microservices, supporting subsequent business processing and service calls.

[0113] IV. Related Usage Devices 1. An order details information storage device, comprising: The receiving module is used to receive data information from passengers when they first create an order; The generation module is used to generate order data in XML format, which includes SPNRID, using the data information from the initial order creation. The splitting module is used to split XML format order data into multiple XML node fragments with SPNRID as the primary key, based on business meaning; The storage module is used to store each XML node fragment with SPNRID as the primary key into a CLOB type XML DATA field of a specified data table, where each data table uses SPNRID as the primary key.

[0114] Furthermore, it also includes: The configuration unit is used to set the SPNRID and XML DATA fields in each data table as key fields; and to extract information that can be used as order query conditions from the XML node fragments and set it as a separate field for easy use as query filtering conditions.

[0115] 2. An order data query device, comprising: The determination module is used to determine the SPNRID; The acquisition module is used to retrieve the XML node fragment of the order from each data table using the SPNRID. Each data table has SPNRID as the primary key, which is responsible for storing the content of different nodes in the Super Passenger Reservation Record SPNR. The node information is stored as a whole through the XML DATA field of type CLOB. The sum of the nodes stored in the CLOB type field of each data table can be assembled into a complete SPNR. The combination module is used to combine all the acquired XML node fragments into a complete, XML-formatted Super Passenger Reservation Record (SPNR) data. The display module is used to extract relevant data from the Super Passenger Reservation Record (SPNR) and display it.

[0116] Furthermore, it also includes: The verification module is used to constrain and verify the structure and content of the Super Passenger Reservation Record (SPNR) using an XSD file. The XSD file defines the type, number, attributes, and interrelationships of each node in the Super Passenger Reservation Record (SPNR).

[0117] 3. An order data modification device, comprising: The receiving module is used to receive SPNRID and modified content; The acquisition module is used to retrieve the XML node fragment of the Super Passenger Reservation Record SPNR pointed to by the SPNRID from all data tables based on the SPNRID. The combination module is used to combine all the acquired XML node fragments into a complete XML structured Super Passenger Reservation Record (SPNR) data. The modification module is used to modify the node content in SPNR according to the modification content; The splitting module is used to split the modified Super Passenger Reservation Record (SPNR) into XML node fragments with SPNRID as the primary key, based on the business meaning. The storage module is used to store each XML node fragment with SPNRID as the primary key into a CLOB type XML DATA field of a specified data table, where each data table uses SPNRID as the primary key.

[0118] In this disclosed solution, at the business level, the "Unified Order" solution supports unlimited expansion of order types and order information items. This means that airlines can quickly adjust their product and service mix according to market changes and customer needs without worrying about limitations of the underlying system. New order types or added information items can be easily integrated into the existing system framework without interfering with existing business processes or requiring large-scale system modifications. From a functional implementation perspective, the biggest highlight of this disclosed solution is that it does not require adding new data tables to the database with the increase of order types, nor does it require adding separate fields for each new order information item. This not only simplifies the database design but also greatly reduces the complexity and coupling of the system, making system maintenance easier. Developers can focus more on optimizing and innovating business logic rather than spending a lot of time on database design adjustments. In addition, the "Unified Order" solution also helps improve system scalability and performance. Due to the reduction of redundant tables and fields in the database, query and update operations become more efficient, and response time is shortened.

[0119] Based on the same inventive concept as the above disclosure, this disclosure also provides an electronic device. The electronic device of this disclosure includes at least one processor and at least one memory electrically connected to the processor. The memory is electrically connected to the processor, wherein the memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method described above.

[0120] It should be noted that the electrical connection between the above-mentioned units does not necessarily mean the connection between lines. The indirect connection method can be applied to the embodiments of this disclosure as long as it achieves the purpose of this disclosure.

[0121] Based on the same inventive concept, this disclosure also provides a computer storage medium storing a computer program, which, when executed by a processor, implements the steps of the above method.

[0122] Although the present disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present disclosure.

Claims

1. A method for creating order data, characterized in that, include: Receive data information from passengers' first order creation; Generate order data in XML format, including SPNRID, using the data information from the initial order creation; The XML format order data is split into multiple XML node fragments with SPNRID as the primary key, according to the business meaning; Each XML node fragment with SPNRID as the primary key is stored in a CLOB type XML DATA field of the specified data table, where SPNRID is the primary key for each data table.

2. The method according to claim 1, characterized in that, Also includes: Set the SPNRID and XMLDATA fields in each data table as key fields; and extract information that can be used as order query conditions from the XML node fragments and set it as a separate field for easy use as query filtering conditions.

3. The method according to claim 1, characterized in that, Generate order data in XML format, including SPNRID, using the data information from the initial order creation, including: Based on the XSD file, order data in XML format containing SPNRID is generated using the data information of the first order creation. The XSD file defines the type, number, attributes, and interrelationships of each node in the XML node fragment corresponding to the Super Passenger Reservation Record SPNR.

4. The method according to any one of claims 1-3, characterized in that, One SPNRID corresponds to three data tables: UNIQUEITEM, ITEM, and ORDER. The UNIQUEITEM table stores information about nodes in the XML representation of the SPNR that are unique and require only one row in each SPNR. The ITEM table stores information about nodes in the XML representation of the SPNR that are not unique and have one or more nodes. The ORDER table stores information about the ticket product and its ancillary service product nodes in the SPNR.

5. The method according to claim 4, characterized in that, The UNIQUEITEM table stores the POS order generation channel node, the Pricing overall price node, the PaymentDetails payment information node, the Audits operation record node, the Queues processing queue node, and the AssociatedBookings associated order node; The ITEM table stores the Customer passenger information node, the Remarks refund and modification information node, the Warnings warning information node, and the Errors error information node. The ORDER table stores the ModularProduct product module node.

6. A method for querying order data, characterized in that, include: Determine SPNRID; Using the SPNRID, the XML node fragment of the order is obtained from each data table. Each data table has SPNRID as the primary key, which is responsible for storing the content of different nodes in the Super Passenger Reservation Record SPNR. The node information is stored as a whole through the XMLDATA field of type CLOB. The sum of the nodes stored in the CLOB field of each data table can be assembled into a complete Super Passenger Reservation Record SPNR. All the acquired XML node fragments are combined into a complete, XML-formatted Super Passenger Reservation Record (SPNR) data set. Extract relevant data from the Super Passenger Reservation Record (SPNR) and display it.

7. The method according to claim 6, characterized in that, After assembling all the acquired XML node fragments into a complete, XML-formatted Super Passenger Reservation Record (SPNR) data set, and before extracting relevant data from the SPNR for display, the method further includes: The structure and content of the Super Passenger Reservation Record (SPNR) are constrained and validated using an XSD file, which defines the type, number, attributes, and relationships of each node in the SPNR.

8. A method for modifying order data, characterized in that, include: Receive SPNRID and modified content; Based on SPNRID, retrieve the XML node fragment of the Super Passenger Reservation Record SPNR pointed to by that SPNRID from all data tables; All the acquired XML node fragments are combined into a complete XML structured Super Passenger Reservation Record (SPNR) data. Based on the modifications, the node content in the Super Passenger Reservation Record (SPNR) should be modified accordingly. The modified Super Passenger Reservation Record (SPNR) is then broken down into XML node fragments with SPNRID as the primary key, based on its business meaning. Each XML node fragment with SPNRID as the primary key is stored in a CLOB type XML DATA field of a specified data table, where each data table uses SPNRID as the primary key.

9. An order data creation device, characterized in that, include: The receiving module is used to receive data information from passengers when they first create an order; The generation module is used to generate order data in XML format, which includes SPNRID, using the data information from the initial order creation. The splitting module is used to split XML format order data into multiple XML node fragments with SPNRID as the primary key, based on business meaning; The storage module is used to store each XML node fragment with SPNRID as the primary key into a CLOB type XML DATA field of a specified data table, where each data table uses SPNRID as the primary key.

10. The apparatus according to claim 9, characterized in that, Also includes: The configuration unit is used to set the SPNRID and XML DATA fields in each data table as key fields; Information that can be used as order query conditions is extracted from the XML node fragment and set as a separate field for easy use as query filtering conditions.

11. An order data query device, characterized in that, include: The determination module is used to determine the SPNRID; The acquisition module is used to retrieve the XML node fragment of the order from each data table using the SPNRID. Each data table has SPNRID as the primary key, which is responsible for storing the content of different nodes in the Super Passenger Reservation Record SPNR. The node information is stored as a whole through the XML DATA field of type CLOB. The sum of the nodes stored in the CLOB field of each data table can be assembled into a complete Super Passenger Reservation Record SPNR. The combination module is used to combine all the acquired XML node fragments into a complete, XML-formatted Super Passenger Reservation Record (SPNR) data. The display module is used to extract relevant data from the Super Passenger Reservation Record (SPNR) and display it.

12. The apparatus according to claim 11, characterized in that, Also includes: The verification module is used to constrain and verify the structure and content of the Super Passenger Reservation Record (SPNR) using an XSD file. The XSD file defines the type, number, attributes, and interrelationships of each node in the Super Passenger Reservation Record (SPNR).

13. An order data modification device, characterized in that, include: The receiving module is used to receive SPNRID and modified content; The acquisition module is used to retrieve the XML node fragment of the Super Passenger Reservation Record SPNR pointed to by the SPNRID from all data tables based on the SPNRID. The combination module is used to combine all the acquired XML node fragments into a complete XML structured Super Passenger Reservation Record (SPNR) data. The modification module is used to modify the node content in the Super Passenger Reservation Record (SPNR) according to the modification content. The splitting module is used to split the modified Super Passenger Reservation Record (SPNR) into XML node fragments with SPNRID as the primary key, based on the business meaning. The storage module is used to store each XML node fragment with SPNRID as the primary key into a CLOB type XML DATA field of a specified data table, where each data table uses SPNRID as the primary key.

14. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method described in any one of claims 1-8.

15. A computer storage medium, characterized in that, The computer storage medium stores a computer program, which, when executed by a processor, implements the method described in any one of claims 1-8.

Images