Patent Application
20100211550
The present invention relates generally to the updating of large databases and more specifically to a method allowing validation in a production database of new entered data prior to their release.
In an increasingly interconnected world all significant providers of goods and services have to set up large and, most often, very-large databases holding the characteristics, specifications and costs of their products, services and global commercial offers. Operated under the control of a database management system (DBMS) contents are made accessible, simultaneously, to many online customers from all over the world, and also to the authorized administrators in charge of keeping database contents updated. In this environment databases must often be operated in real time, in a 24-hour-a-day/7-day-a-week mode.
In the airline industry, examples of such very-large database platforms are the ones that hold the airline fares along with the rules restricting their use. Fare databases are mainly set up by a few worldwide global distribution systems (GDSs) that provide travel services to all the actors of the travel industry and more specifically to traditional travel agencies and also to all sorts of other online travel service providers. For instance, AMADEUS is a world leading GDS.
One large provider of fares is the airline tariff publishing company (ATPCO), an organization owned by a number of domestic and international airlines that collects and distributes the latest airfares of many airlines around the world on a multi-daily basis. Another provider of fares is called SITA, a similar international organization. ATPCO and SITA provide fare data in an electronic form suitable for computer processing including all the rules associated with those fares. Fares and rules provided by airlines and coded by ATPCO and SITA are electronically transmitted to the GDSs mentioned above for being incorporated into their fare databases.
ATPCO and SITA are not however the only sources of fares for the GDS fare databases. A GDS like AMADEUS also provides software tools that let third-party fare providers file fares directly into its fare and pricing database platform. Indeed, a good deal of fares created on a daily basis by airline companies, and travel service companies on behalf of airlines, is negotiated fares. Contrary to public fares, negotiated fares are contracted between, e.g., an airline company and a particular travel agency or travel organization for its private use. They are often filed directly into GDS fare database thus bypassing ATPCO and SITA.
However, direct filing of fares does not go without posing its own set of problems. The fare and pricing database platform is a complex and very-large database which is continuously in use and must sustain real-time commercial transactions while being updated. Especially, filing of new fares along with the associated data such as the rules that restrict their use and the available routes requires that many transactions all complete successfully before actually getting a consistent set of updated data tables that can translate into new useable fares.
It is thus the object of the invention to describe a technique to update a large database, such as a GDS fare database, without disturbing its normal operation while its updating (i.e., entry of new fares) is in progress. It is a specific object of the invention to allow a validation of the new fares before they become visible and can be actually used by the end-users of the database.
Further objects, features and advantages of the present invention will become apparent to the ones skilled in the art upon examination of the following description in reference to the accompanying drawings. It is intended that any additional advantages be incorporated herein.
The invention describes a method of insuring the integrity of a plurality of updates brought in real-time to a production database concurrently used by one or more software applications. The production database includes a plurality of products participating to the definition of objects. The method first comprises the step of requesting the issuance of a unique filing number associated to a draft state version of the plurality of updates while keeping them invisible to the end-users of the production database. Then, a set of product items identified as a whole by the unique filing number are created or copied from the production database and gathered under the form of a meta-product on which the plurality of updates is applied. When updating is complete, the meta-product is successively set into a customizable flow of one or more validation states in order to perform a cross-validation of the plurality of updates. Finally, when validation is complete, the meta-product is set into a production state where the uniquely identified meta-product becomes immediately visible and useable by the end-users of the one or more software applications.
The invention may also comprise optionally one of the following features:
The invention also concerns a computer program product stored on a computer readable storage medium, comprising computer readable code means for causing at least one computer to operate the above method.
The invention further concerns a server side or a client side of a computer program product stored on a computer readable storage medium, comprising computer readable code means for causing at least one computer to operate the above method.
The following detailed description of the invention refers to the accompanying drawings. While the description includes exemplary embodiments, other embodiments are possible, and changes may be made to the embodiments described without departing from the spirit and scope of the invention.
The database (110) of this example used to illustrate the invention is a fare database of the kind set up by GDSs from their large computing and storing resources (150) to allow pricing of travel solutions. This example is chosen to enhance the understanding of the invention and does not limit the invention to fare databases or to commercial offers. GDS resources are made available online through any combination of networks including the Internet (160) and the use of the corresponding standard protocols. The pricing requests are received (120), e.g., from the traditional travel agencies affiliated to the GDS to complete travel commercial transactions on behalf of the travelers, clients of the travel agencies. Pricing requests are also received from numerous online travel sites in order to price the travel solutions selected by end-users of the sites. Whichever the source of the pricing request, a pricing engine application (130) operated by the GDS uses the fare database to establish the cost of the travel solutions. Pricing requests are issued by agents of travel agencies from their computer terminals and by end-users typically accessing various online travel sites from their personal computers through a standard client application, i.e.: a web browser or a navigator (135).
As mentioned in the background section new fares are created on a daily basis. Direct filing of fares is achieved through a dedicated software platform (140) running from GDS computing resources in a standard client/server mode. Then, the direct filing software platform let fare providers manually file negotiated fares from the corresponding client applications (145) through a graphic user interface (GUI). Negotiated fares are fares that result of agreements and contracts signed between, e.g., airlines and travel agencies and, generally, between any fare providers and any travel service providers that do not use the services provided by ATPCO or SITA.
The introduction of new fares must be done in real-time however without disturbing the regular operation of the database which remains continuously interrogated through the pricing engine (130) in order to answer the commercial requests (120) issued from the here above mentioned travel agencies and online travel sites, i.e., by travel agents and individual end-users of the sites (122). The fare database is comprised of several elements, hereafter referred to as products. Said products participate to the definition of objects which are for instance global commercial offers in the described example. The products must be consistently updated to eventually get a valid fare that becomes commercially useable. The products are updated through independent dedicated transactions (144) with the database. Transactions are issued by those in charge of entering, updating or deleting fares through the direct filing software platform (140) provided by the GDS. They are broadly referred to as the filing team (142) in the following. Creation, update or deletion of data are performed manually. The products include the rules (112) that translate the terms and conditions of the negotiated contract in the form of restrictions that apply when buying the new fare. The routes on which the new fare applies are defined in a second product (114) while the individual fare amounts are in a third product (116). There are at least as many transactions to issue as products to update. Then, the main problem lies in the fact that all product modifications are becoming immediately visible to the pricing engine (130) while a new fare is being created. This may cause incoherencies as long as not all the transactions have actually completed so that all products are updated in a coherent way for the new fare and also made compatible with all the already existing fares.
Another problem tied to the fact that all modifications are immediately visible is that no validation of the new fares is in practice possible. Air fares are particularly complex and subject to the application of many rules. The parties involved in a negotiated fare (e.g., an airline and a travel agency) cannot however conveniently preview how a contract translates into a new fare unless it is actually also made immediately available for the regular commercial transactions. A new fare cannot be built and tested in advance by the filing team, i.e., before the date it is scheduled to be released and put in production mode.
The coherence of the updates on several products part of a global commercial offer is achieved through the use of a filing number (210). The filing number is made unique and its validity is linked, as further discussed, to the filing cycle flow (220) to which it belongs. It is attached to any update done on any of the products defined in the database. A filing number thus uniquely identifies a particular update among a set of updates. Hence, all the data tagged with a same filing number form a meta-product (230) which is managed as a unique entity by the system. The filing team is responsible of the identification of the set of updates and of its functional coherence.
A filing cycle flow (220) is made of states and transitions:
Based on the above concepts of states and transitions a filing cycle flow can thus be customized to fit the needs of a particular filing team and way of working of their organization. This customizable flow of validation states is further discussed in
To guarantee the coherence of the system some restrictions apply through:
On an implementation point of view, a state (240) is a field stored in a database table. It qualifies a set of data identified by a unique filing number. The association filing number-state is stored in a separate table. Each time the state is modified for a given filing number a new association is created and kept in the filing cycle flow (220). The filing number is attributed at the beginning of the filing cycle and used by the filing team to identify a set of updates concerning several products in the database. The last attributed filing number is stored in a dedicated table.
On the product side, a new version is created for each Mkey (270) at the beginning of the filing cycle flow: it is either a brand new Mkey, when the data do not already exist in the master file, or it is a copy of the existing data in production. During the whole filing cycle flow, only the last update of the data is kept in the database. For a given filing number, there is only one version of an Mkey. However, several Mkey's of a product can be identified by the same filing number.
As further discussed in
This way of filing has many advantages. The database needs not to be duplicated. Only the products being updated exist in two versions. Indeed, a possible solution to the problem solved by the invention would be to have a standby duplicated database in which all updates would be done and checked before the standby database is put in turn in production replacing the active database at scheduled times. This way of doing presents drawbacks in comparison with the invention. Indeed, such solution requires to manage and store two large and complex databases. Also, contrary to what is feasible with the filing system of the invention, an update could not be put in production as soon as it has been thoroughly checked since it would have to wait the next scheduled swapping to become visible by the end-users of the database.
Also, the filing team does not need to create a version for all products defined in the database but only for the ones that must be modified. Even though products are not all modified the validation of the updates can be conducted normally. In this case, the filing system of the invention just retrieves the non-updated products necessary to perform the validation. Necessary non-updated products and updated products are thus merged to permit the validation of the updated products.
With the example used to illustrate the invention, if only the rule product (232) and the fare product (236) need to be modified; then, the non-updated other product of this example, i.e., the routing product (234), needs not actually to be included (as shown in
The defined states are as follows:
The above exemplary filing cycle can be adapted to any organization's needs. The number of states is not limited. New requirements may be considered and new states added to the flow if necessary. A state defines the actions allowed on the data so that they can be updated, deleted, processed or just only read. Also the permitted transitions to and from the states are part of the definition of the filing cycle. The definition of a new state must be coherent with the existing flow and it can imply the development of new actions.
The exemplary filing cycle of
Hence, the foregoing described database filing system retains from legacy systems the ability, for the filing teams and their organizations, to react in real time to the competition because the database updates can still be made instantaneous (360).
Yet, the filing of new contracts may also include optional preparation and validation phases that can be tailored to fit any organization management needs:
The scope of this invention also extends to hotel industry and the data to be updated may correspond to hotel fares/rates. Although the invention is described above in connection with an example involving fares and commercial offers, its scope extends to all kind of data for which it is advantageous to insure integrity of updates brought in real-time to a production database. For instance, the production database can include products participating to the definition of an industrial manufacturing process. In this case end-users may be industrial machines or technicians.
| Number | Date | Country | Kind |
|---|---|---|---|
| 09305151.4 | Feb 2009 | EP | regional |
