[發明專利]元數據升級方法和系統

有效

• 申請號: 201010616410.0
• 申請日: 2010-12-30
• 公開（公告）號: CN102054041A
• 公開（公告）日: 2011-05-11
• 發明（設計）人: 李靖和;張鑫;裴旭;李紹文;汪成杰
• 申請（專利權）人: 用友軟件股份有限公司
• 主分類號: G06F17/30
• 分類號: G06F17/30
• 代理公司: 北京友聯知識產權代理事務所(普通合伙) 11343
• 代理人: 尚志峰;汪海屏

技術領域

本發明涉及企業資源管理系統，尤其涉及元數據升級方法和系統。

背景技術

ERP(Enterprise?Resource?Planning，簡稱ERP)系統的研發中涉及到了各種概念，下面進行簡單說明：

元數據：是描述數據的數據，用于實現抽象的持久層和界面表現層，是抽象數據的描述性數據。在通常的管理信息系統中，元數據包含實體元數據、服務(接口)元數據、UI(User?Interface，簡稱UI)元數據等。

元元數據：元數據的數據模型。

元數據包：按組件或應用組織為單位的數據包，該數據包包含元元數據、元數據、資源以及格式描述。升級數據包包含基準數據包和增量數據包。

資源元數據：描述系統中各種名稱、字典、描述性信息以及其他非結構化數據的元數據，用以解決多語種、客戶化等問題。

組件：一種軟件模型管理的粒度，根據功能和數據模型間的耦合性、研發組織的便利性等因素在系統應用架構設計期間進行劃分。

隨著企業規模的擴大以及ERP系統的逐漸發展，系統的功能越來越復雜，數據越來越龐大，用戶的需求也存在著多樣性和不確定性。ERP系統的研發需要快速的響應用戶的需求。元數據升級能夠在快速軟件開發中，起到關鍵性作用。

在通常的軟件建模工具中，模型的發布往往是生成靜態的腳本或者數據文件，有如下缺點

1.模型只能發布到新系統中，無法或很難保留現有數據和配置信息；

2.實體數據模型只能生成建庫的腳本，開發人員需要人工編寫升級腳本或升級程序；

3.用戶環境的個性化信息，比如用戶數據、授權信息、多語信息以及各種定制的UI數據都很難在版本升級時得到繼承。

此外，開發和設計人員針對模型的修改有如下若干種：

1.增加實體或字段，修改屬性類型；

2.UI模型對界面顯示信息或者相關數據的增加、刪除和修改；

3.修改物理模型的字段屬性、默認值、索引等等；

4.實體信息改為多語種。

還有很多對模型的修改場景，在此不一一列舉。

比較常見的設計工具在實現上述模型修改時一般情況下是比較簡單的，但是模型改完之后有一系列問題難以處理：

1.單元測試環境和集成測試環境的驗證環境的升級，而該驗證環境往往有比較復雜的數據作為案例。

2.驗證通過后進行用戶環境的升級，補丁通過驗證環境的驗證后，進行用戶環境的升級，而用戶的數據更加復雜，并且各個用戶的版本不一致，導致升級的困難。

這樣，如果研發人員每次修改模型都要自己編寫升級程序的話，會引起如下問題：

1.升級程序的編寫降低了開發效率，同時提高了對開發人員的要求；

2.升級程序處理多版本時比較困難；

3.在大的團隊開發中，很難對升級程序或腳本進行管理；

顯然這樣的研發過程很難保證高質量和高效率。

因此，需要一種元數據升級方法和系統，可以使用統一工具進行快速安全的升級，能夠保留用戶的個性化信息，提高研發人員的工作效率。

發明內容

有鑒于此，本發明所要解決的技術問題在于，提供一種元數據升級方法和系統，可以使用統一工具進行快速安全的升級，能夠保留用戶的個性化信息，提高研發人員的工作效率。

本發明提供了一種元數據升級方法，包括：步驟102，循環比較新的元數據與原有的元數據之間的差異；步驟104，根據所述差異實現所述原有的元數據的升級。不需要重新構造元數據的模型，通過比較差異的方法來修改原有的元數據，既能保留用戶的個性化信息，又能保證元數據的快速升級。

在上述技術方案中，優選地，在所述步驟104中，根據所述差異判斷需要修改的所述元數據是否為業務主鍵，在判斷結果為是所述業務主鍵的情況下，刪除所述元數據所在的表的所有觸發器，對所述元數據進行修改。這樣，刪除了所述表的觸發器之后，可以對元數據進行增加、刪除和更改。

在上述技術方案中，優選地，在所述步驟104中，在對所述元數據進行修改后，判斷需要修改的所述元數據是否存在索引和約束，在判斷結果為是的情況下，則刪除所述索引和所述約束，對所述元數據的所述表的結構進行修改。除了刪除觸發器之后，還要刪除元數據的索引和約束，這樣才能繼續修改元數據的表結構。

在上述技術方案中，優選地，修改完所述元數據的所述表的結構之后，重新建立所述索引和所述約束。在有必要的情況下，重新建立元數據的索引和約束關系。