專利名稱：允許在新鍵入的數據發布之前驗證新鍵入的數據的大型生產數據庫中的大量更新的方法
技術領域：
本發明一般涉及大型數據庫的更新，特別是，涉及一種允許在新鍵入的數據發布之前在新鍵入的數據的生產數據庫(productiondatabase)中進行驗證的方法。
背景技術：
在日益互連的世界中，所有的商品和服務的重要提供商必須建立保存他們的產品的特性、規格和成本、服務和全球商業報價的大型(最經常的是巨大型)數據庫。在數據庫管理系統(DBMS)的控制下操作，使得全世界的許多在線客戶，還有負責保持數據庫內容更新的授權管理員可同時訪問內容。在這種環境下，數據庫通常必須在一天M小時/ 一星期 7天模式下被實時操作。在航空業中，這樣的巨大型數據庫平臺的例子是將飛機票價與限制它們的使用的規則一起保存的數據庫平臺。票價數據庫主要由幾個世界范圍的全球分銷系統(GDS)建立，GDS向旅游業的所有執行者(更具體地向傳統旅行社)，還向各種各樣的其它在線旅游服務提供商提供旅游服務。例如，AMADEUS是世界領先的GDS。一個大的票價提供商是航空運價出版公司(ATPCO)，ATPCO是許多國內和國際航空公司所擁有的組織，該組織在多日的基礎上收集和分銷全世界的許多航空公司的最近飛機票價。另一個票價提供商被稱為SITA，SITA是類似的國際組織。ATPCO和SITA提供適合于計算機處理的電子形式的票價數據，包括所有的與這些票價相關聯的規則。由航空公司提供并由ATPCO和SITA編碼的票價和規則被電子發送到以上提及的GDS，以被并入它們的票價數據庫中。然而，ATPCO和SITA不是⑶S票價數據庫的唯一票價來源。像AMADEUS的GDS還提供讓第三方票價提供商將票價直接提交到其票價和定價數據庫平臺中的軟件工具。事實上，由航空公司和代表航空公司的旅游服務公司每日創建的大量票價是議定票價。與公開票價相反，議定票價在比如航空公司和其私用的旅游組織或特定旅行社之間訂立。它們經常被直接提交到⑶S票價數據庫，從而繞過ATPCO和SITA。然而，直接提交票價并不是沒有提出其自己的一系列問題。票價和定價數據庫平臺是被連續使用的并且在被更新的同時必須持續進行實時的商業交易的復雜的巨大型數據庫。尤其是，與相關聯的數據一起提交新票價要求在實際得到一組一致的可被轉化為新的可用票價的更新數據表之前許多交易全部成功地完成，所述相關聯的數據為例如限制所述新票價的使用的規則和可到達路線。因此，本發明的目的是描述這樣一種技術，該技術更新大型數據庫，例如GDS票價數據庫，并且在該大型數據庫的更新(即，輸入新票價)正在進行的同時，不干擾該大型數據庫的正常操作。本發明的特定目的是使得可在新票價變為可見并且可被數據庫的終端用戶實際使用之前對新票價進行驗證。因此，本發明特別解決了更新大型數據庫中的大量數據的問題。在本發明中，大型數據庫或大型生產數據庫指定占用多于1太字節(10 千兆字節)或者包含多于十億行的數據庫。在本發明中，大量更新是指每天多于500000次更新和/或每天幾百萬次讀取訪問的流量。當研究以下參照附圖的描述時，本發明的進一步的目的、特征和優點對于本領域技術人員將變得顯然。意圖在于任何另外的優點并入本文中。
發明內容
本發明描述了一種確保實時引入到被一個或多個軟件應用共同使用的大型生產數據庫中的大量更新的完整性的方法。生產數據庫包括參與對象定義的多個產品 (product)。生產數據庫與微處理器耦合，所述微處理器被布置為使得所述方法執行以下步驟。所述方法首先包括在使多個更新對于生產數據庫的終端用戶保持不可見的同時請求發放與多個更新的草案(draft)狀態版本相關聯的唯一提交號的步驟。然后，從生產數據庫創建或拷貝用唯一提交號標識為一個整體的一組產品項，將該組產品項記錄在生產數據庫中，并聚集在對其應用多個更新的元產品(meta-product)的形式下。拷貝限于必須通過驗證進行更新的一組數據。當更新完成時，為了執行所述多個更新的交叉驗證，連續地將元產品設置到可定制的一種或多種驗證狀態的流程中。交叉驗證是指可執行的多個驗證。所述多個驗證可由相同的或不同的實體或團隊執行。所述多個驗證可包括相同的或不同的驗證步驟。交叉驗證還可關系到多個產品，從而使得能夠修改參與價格計算的許多不同產品和一次驗證所有的更新。交叉驗證可使得能夠對所有執行的更新的組合進行驗證。最后，當驗證完成時，將元產品設置到生產狀態中，在生產狀態下，唯一標識的元產品變得可被一個或多個軟件應用的終端用戶立即看見和使用。本發明還可以可選地包括以下特征之一-大型生產數據庫占用多于1太字節(10M千兆字節)或者包含多于十億行。-大型生產數據庫每天可接收多于500000百萬次更新，更優選地，多于2百萬次更新。-大型生產數據庫每天可接收多于五百萬次讀取訪問，優選地，每天多于一千五百萬次讀取訪問。-可定制的一種或多種驗證狀態的流程包括手動驗證狀態，所述手動驗證狀態不允許更新元產品。-可定制的一種或多種驗證狀態的流程包括適用驗證狀態，所述適用驗證狀態允許對元產品模擬一個或多個軟件應用。-元產品與對元產品模擬一個或多個軟件應用所需的無論哪個非更新生產產品合并。-適用驗證狀態允許從元產品更新和刪除數據。-適用驗證狀態允許一個或多個應用程序如同元產品是生產產品那樣顯示元產品。
-如果多個更新的交叉驗證失敗，則可定制的一種或多種驗證狀態的流程允許將元產品返回到草案狀態。-可定制的一種或多種驗證狀態的流程允許將元產品設置到生產狀態中。
-生產狀態僅允許專家團隊更新元產品。-生產狀態允許更新任何產品。-可定制的一種或多種驗證狀態的流程僅包括手動驗證狀態。-生產數據庫是票價數據庫，并且一個或多個軟件應用包括定價引擎。本發明還涉及存儲在計算機可讀存儲介質上的計算機程序產品，該計算機程序產品包括用于使至少一個計算機操作以上方法的計算機可讀代碼裝置。因此，為了向定價交易提供與驗證上下文對應的所有數據，S卩，在驗證上下文中更新的數據和生產數據，本發明在數據庫引擎與定價交易之間添加“層”。本發明不需要數據庫的任何復制。本發明不需要另外的數據庫。它使得在單個數據庫被連續地且同時地用于答復終端用戶查詢的同時在該數據庫中進行大量更新。數據的拷貝限于在驗證上下文中正將被更新的一組數據。這旨在在不增加系統的復雜性的情況下使用戶更容易進行更新。本發明的另一個目的是包括至少存儲生產數據庫的一個或多個數據存儲裝置的系統。所述系統還包括與數據存儲裝置耦合且被布置為用于執行上述方法的微處理器。本發明還涉及存儲在計算機可讀存儲介質上的計算機程序產品的服務器端或客戶端，服務器端或客戶端包括被布置為用于使至少一個計算機操作以上方法的計算機可讀代碼裝置和微處理器。
圖1示出了本發明的更新技術最佳地應用于大型連續操作數據庫的例子。圖2描述了本發明用于在提交循環流程期間更新連續操作數據庫的產品的裝置， 所述提交循環流程控制更新的可見性，直到它們被投入生產為止。圖3是包括多達具有相應過渡的四種狀態的更新循環流程的例子。
具體實施例方式本發明的以下詳細描述參照附圖。盡管描述包括示例性實施例，但是其它實施例也是可以的，并且可在不脫離本發明的精神和范圍的情況下，對所描述的實施例進行改變。圖1示出了本發明的更新技術最佳應用于大型連續操作數據庫的例子。用于示出本發明的該例子的數據庫(110)是由GDS從它們的大量計算和存儲資源 (150)建立的、允許對旅游解決方案進行定價的類型的票價數據庫。選擇該例子是為了增加對本發明的理解，該例子不將本發明限于票價數據庫或者商業報價。通過任意組合包括互聯網的網絡(160)和使用對應的標準協議來使得可在線獲得GDS資源。比如從隸屬于GDS的傳統旅行社接收定價請求(120)，以代表旅游者(旅行社的客戶)完成旅游商業交易。為了對網站的終端用戶所選擇的旅游解決方案進行定價，還從許多在線旅游網站接收定價請求。無論定價請求的來源是哪個，由GDS操作的定價引擎應用(130)都使用票價數據庫來建立旅游解決方案的成本。定價請求由旅行社的代理從他們的計算機終端和由終端用戶通常通過標準客戶機應用(即，web瀏覽器或導航器)從他們的個人計算機(13 訪問各種在線旅游網站而發出。因此，在本發明的上下文中，“商業報價”包括由產業(例如航空業)提供給他們的分銷網絡(像web網站)、旅行社或公司等的所有類型的定價。該商業報價由GDS通過廣范圍的定價交易分銷，所述定價交易也被稱為商業交易，其答復各種客戶的需要，提供就結果的數字或內容(像關于旅程的X最低可適用價格或X最低可獲得價格)而言不同類型的結^ ο如在背景部分中所提及的，每日創建新票價。票價的直接提交通過在標準客戶機/ 服務器模式下從GDS計算資源運行的專用軟件平臺(140)來實現。然后，直接提交軟件平臺讓票價提供商通過圖形用戶界面(GUI)從對應的客戶機應用(145)手動提交議定票價。議定票價是作為在比如航空公司與旅行社之間并且通常在任何票價提供商與不使用由ATPCO 或SITA提供的服務的任何旅游服務提供商之間簽署的協議和合同的結果的票價。然而，為了答復從這里以上提及的旅行社和在線旅游網站(S卩，由旅行社和網站的各個終端用戶(122))發出的商業請求(120)，必須在不干擾數據庫的常規操作的情況下實時引入新票價，所述數據庫通過定價引擎(130)保持連續詢問。票價數據庫包括幾個元素，以下將元素稱為產品。所述產品參與對象的定義，所述對象例如在所述例子中是全球商業報價。產品必須被一致地更新，以最終得到變為商業可用的有效票價。產品借助數據庫通過獨立的專用交易(144)被更新。交易由那些負責通過由GDS提供的直接提交軟件平臺 (140)鍵入、更新或刪除票價的人發出。以下，將他們寬泛地稱為提交團隊(142)。手動執行數據的創建、更新或刪除。產品包括規則(112)，規則(112)轉化在購買新票價時應用的限制形式的議定合同的條款和條件。在第二產品(114)中定義應用新票價的路線，同時各個票價量在第三產品(116)中。至少發出如更新的產品那么多的交易。那么，主要問題在于下述事實，即，在正創建新票價的同時，所有的產品修改正變得對于定價引擎(130)立即可見。只要不是所有的交易實際上都已完成，這就可引起不一致性，使得對于新票價，以一致的方式更新所有的產品，并且還使得所有的產品與所有的已經存在的票價兼容。與所有的修改立即可見的事實相聯系的另一個問題是在實踐上可能不對新票價進行驗證。飛機票價特別復雜，并且受制于許多規則的應用。然而，議定票價中所涉及的當事方(比如，航空公司和旅行社)不能方便地預覽合同如何轉化為新票價，除非實際上也使得它對于常規的商業交易可立即獲得。新票價不能由提交團隊預先(即，在該新票價被安排發布并被投入生產模式之前)構建和測試。圖2描述了本發明用于在提交循環流程期間更新連續操作數據庫的產品的裝置， 所述提交循環流程控制更新的可見性，直到它們被投入生產為止。全球商業報價的幾個產品部分上的更新的一致性通過使用提交號(210)來實現。使提交號是唯一的，并且如進一步所論述的，將其有效性鏈接至它所屬的提交循環流程 (220) 0將它附加到對數據庫中定義的任何產品進行的任何更新。提交號因而唯一地標識一組更新之中的特定更新。因此，用相同的提交號標記的所有數據形成元產品030)，系統將元產品(230)作為獨一實體進行管理。提交團隊負責標識一組更新及其功能一致性。提交循環流程Q20)由狀態和轉移(transition)構成-狀態(MO)與提交號(210)相關聯。它確定可在用提交號標識的一組數據(230) 上進行的動作。當更新被投入生產時，提交循環流程的最后狀態對應于數據的出版060)。 當到達這種狀態時，提交號變為作廢。如果必須處理更多的更新，則將需要新的唯一提交號。
-轉移(250)是將一組數據的狀態變為另一種狀態的動作。如以下進一步論述的， 為了可在更新最后被投入生產之前到達另一種中間狀態，向提交團隊提議從狀態的幾種轉移。總是可從任何狀態出版投入生產的數據，并且如果必須取消更新會話，則還可刪除對應的整組數據。由于已經投入生產的數據(200460)可能已經被用于對票進行定價和銷售， 所以僅這些數據不能從系統移除。基于以上狀態和轉移概念，可如此定制提交循環流程，以適應特定提交團隊的需要和他們的組織的工作方式。這是為何流程被命名為可定制流程的原因。在圖3中對該可定制的驗證狀態的流程進行進一步論述。為了保證系統的一致性，一些限制始終應用-通過稱為MKeH270)的一組標識字段來確定每個主文件(專用于產品的一組數據庫表)中的更新的粒度。只有一個提交號(210)被允許與MKey相關聯，以使得可以對給定的一組數據(230)僅存在一個更新循環有效。-如果有現存數據Q00)的話，則任何新的提交必須總是從現存數據O00)開始。 在當前的提交循環流程結束時，新數據與舊數據合并。必須保持它們一致。在實現觀點上，狀態(MO)是存儲在數據庫表中的字段。它授權給用唯一提交號標識的一組數據。關聯提交號狀態被存儲在分離的表中。每次對給定的提交號修改狀態時，創建新的關聯，并在提交循環流程O20)中保持該新的關聯。在提交循環開始時歸屬 (attribute)提交號，提交團隊使用該提交號來識別關于數據庫中的幾個產品的一組更新。 最后歸屬的提交號被存儲在專用的表中。在產品方面，在提交循環流程開始時對每個MKeH270)創建新版本或者它是當數據已經不存在于主文件中時的全新的MKey，或者它是投入生產的現存數據的拷貝。在整個提交循環流程期間，只有數據的最后更新被保留在數據庫中。對于給定的提交號，僅存在 MKey的一個版本。然而，一個產品的幾個MKey可用相同的提交號標識。如圖3中進一步論述的，本發明的提交系統如此開放和靈活，足以讓負責為組織創建新票價的提交團隊通過具有在新票價被發布和被用于生產中之前的適當數量的中間驗證狀態來針對它們的組織的需要定制提交循環流程020)。在生產數據庫中直接管理提交行為。對于給定的一組數據，兩個版本可一起存在于數據庫中一個對應于生產行為，一個對應于提交行為。一旦驗證中的版本被提升，它就變為被定價引擎作為目標的新版本。這種提交方式具有許多優點。不必復制數據庫。僅正被更新的產品存在兩個版本。事實上，本發明所解決的問題的可能的解決方案將是具有備用的復制數據庫，在所述備用的復制數據庫中，在備用數據庫被轉而投入生產并在安排的時間替換工作的數據庫之前，將完成并檢查所有的更新。與本發明相比，這種處理方式存在缺點。事實上，這樣的解決方案需要管理和存儲兩個大型的復雜數據庫。此外，與本發明的提交系統可實行的相反， 更新不能在它被徹底檢查后立即被投入生產，這是由于它將必須等待下一次安排的對換， 以變為被數據庫的終端用戶可見。此外，提交團隊不必對數據庫中定義的所有產品創建版本，而是僅需對必須被修改的產品創建版本。即使產品不是全部被修改，也可正常進行更新的驗證。在這種情況下， 本發明的提交系統僅僅檢索執行驗證所需的非更新產品。所需的非更新產品和更新產品因而被合并，以允許對更新產品進行驗證。
8
關于用于表明本發明的例子，如果只有規則產品(232)和票價產品(236)需要被修改，則該例子的非更新的其它產品(即，路線安排產品034))實際上不必(如圖2所示那樣)包括在用唯一提交號(210)標識的元產品中。在這種情況下，為了執行更新驗證，本發明的提交系統而是默認地僅選取非更新產品的生產版本004)。這避免創建數據庫中的無用數據，即，復制沒有修改的生產版本。圖3是包括多達具有對應轉移的四種狀態的提交循環流程的例子。定義的狀態如下
權利要求
1.一種確保實時引入到被一個或多個軟件應用(130)共同使用的大型生產數據庫 (110)中的多個更新的完整性的方法，所述大型生產數據庫包括參與商業報價的定義的多個產品(112，114，116)，所述方法包括以下步驟在保持所述多個更新對于所述大型生產數據庫的終端用戶(12 不可見的同時，請求發放與所述多個更新的草案狀態版本(310)相關聯的唯一提交號；在所述大型生產數據庫中，從所述大型生產數據庫創建或拷貝將被更新和驗證的一組產品項030)，該組產品項(230)用所述唯一提交號(210)標識為一個整體，并被聚集在對其應用多個更新的元產品形式下；當所述元產品的更新完成時，為了至少執行所述多個更新的驗證，連續地將所述元產品設置到一種或多種驗證狀態 (320,330)的流程中；當所述元產品的驗證完成時，將所述唯一標識的元產品設置到生產狀態(340)中，所述唯一標識的元產品變為可被所述一個或多個軟件應用(130)的終端用戶(122)立即看見和使用。
2.根據權利要求1所述的方法，其中，所述一種或多種驗證狀態的流程包括手動驗證狀態(320)，所述手動驗證狀態(320)不允許更新所述元產品。
3.根據權利要求1或2所述的方法，其中，所述一種或多種驗證狀態的流程包括適用驗證狀態(330)，所述適用驗證狀態(330)允許對所述元產品模擬所述一個或多個軟件應用。
4.根據權利要求3所述的方法，其中，所述元產品與對所述元產品模擬所述一個或多個軟件應用所需的無論哪個非更新生產產品合并。
5.根據權利要求3所述的方法，其中，所述適用驗證狀態允許從元產品更新和刪除數據(334)。
6.根據權利要求3所述的方法，其中，所述適用驗證狀態允許所述一個或多個應用如同元產品是生產產品那樣顯示元產品。
7.根據前面的權利要求中的任何一個所述的方法，其中，如果所述多個更新的驗證失敗，則所述一種或多種驗證狀態的流程允許使元產品返回到草案狀態(324，336)。
8.根據前面的權利要求中的任何一個所述的方法，其中，所述一種或多種驗證狀態的流程允許將元產品設置到生產狀態中(3 ，338)。
9.根據前面的權利要求中的任何一個所述的方法，其中，所述生產狀態僅允許專家團隊更新元產品(342)。
10.根據權利要求9所述的方法，其中，所述生產狀態允許更新任何產品(342)。
11.根據前面的權利要求中的任何一個所述的方法，其中，所述一種或多種驗證狀態的流程僅包括手動驗證狀態(350)。
12.根據前面的權利要求中的任何一個所述的方法，其中，所述大型生產數據庫為票價數據庫(110)，所述一個或多個軟件應用包括定價引擎(130)。
13.根據前面的權利要求中的任何一個所述的方法，其中，所述流程是可定制的。
14.根據前面的權利要求中的任何一個所述的方法，其中，所述大型生產數據庫占用多于1太字節或者包含多于十億行。
15.根據前面的權利要求中的任何一個所述的方法，其中，存儲在計算機可讀存儲介質(150)上的計算機程序產品(140)包括用于使至少一個計算機操作根據權利要求1-14中的任何一個所述的方法的計算機可讀代碼裝置。
全文摘要
描述了確保實時引入到被一個或多個軟件應用共同使用的大型生產數據庫中的多個更新的完整性的方法。大型生產數據庫包括參與對象的定義的多個產品。所述方法首先包括在使多個更新保持對大型生產數據庫的終端用戶不可見的同時請求發放與所述多個更新的草案狀態版本相關聯的唯一提交號的步驟。然后，在大型生產數據庫中創建或拷貝用唯一提交號標識為一個整體并且在其上應用更新的一組產品項，并將該組產品項聚集在元產品形式下，所述多個更新應用在所述元產品上。當更新完成時，為了執行多個更新的交叉驗證，連續地將元產品設置到可定制的一種或多種驗證狀態的流程中。最后，當驗證完成時，將元產品設置到生產狀態中，在生產狀態下，唯一標識的元產品變為可被所述一個或多個軟件應用的終端用戶立即看見和使用。
文檔編號G06F17/30GK102388384SQ201080007819
公開日2012年3月21日 申請日期2010年2月16日 優先權日2009年2月17日
發明者B·拉斯卡, B·雅南, R·朱立恩, R·達尼埃羅, S·德斯蒙塞奧 申請人:阿瑪得斯兩合公司