產(chǎn)品數(shù)據(jù)管理(Product Data Management,PDM)是管理所有與產(chǎn)品相關的信息和過程的技術,其主要功能包括產(chǎn)品文檔管理、產(chǎn)品結(jié)構(gòu)管理和工作流管理等。PDM能使產(chǎn)品數(shù)據(jù)在其生命周期內(nèi)保持一致、最新和安全,能夠縮短產(chǎn)品研發(fā)周期、降低成本、提高質(zhì)量,并為企業(yè)贏得競爭等優(yōu)勢。PDM為機械制造企業(yè)數(shù)據(jù)管理系統(tǒng)的核心系統(tǒng)之一,也是數(shù)字化制造的實現(xiàn)奠定基本物質(zhì)基礎之一,但現(xiàn)代PDM也面臨著挑戰(zhàn),如PDM一般采用關系型數(shù)據(jù)庫,而傳統(tǒng)關系型數(shù)據(jù)庫很難克服數(shù)據(jù)庫高并發(fā)讀寫、海量數(shù)據(jù)的高效率存儲和訪問、數(shù)據(jù)庫的高可擴展性和高可用性的問題。說明隨著MBE全三維信息化技術逐步成熟,裝備制造業(yè)PDM系統(tǒng)中數(shù)據(jù)的結(jié)構(gòu)化特點越來越弱——企業(yè)能夠不需要數(shù)據(jù)轉(zhuǎn)換而充分使用三維模型,則企業(yè)獲得的數(shù)據(jù)將是原始CAD數(shù)據(jù)。
關系型數(shù)據(jù)庫中的數(shù)據(jù)往往需要極高的精確度,一般須遵守ACID特征,非關系型數(shù)據(jù)庫NoSQL則打破了長久以來關系型數(shù)據(jù)庫與ACID理論大一統(tǒng)的局面。相對于傳統(tǒng)的關系型數(shù)據(jù)庫系統(tǒng),NoSQL數(shù)據(jù)管理系統(tǒng)有很多優(yōu)勢特征:高擴展性、高容錯性、高性價比等,這些特性使得NoSQL數(shù)據(jù)管理系統(tǒng)更利于管理大規(guī)模海量數(shù)據(jù),且能有效地處理非結(jié)構(gòu)化數(shù)據(jù),例如文件、電子郵件、多媒體和社會媒體。
產(chǎn)品結(jié)構(gòu)與配置管理作為PDM的核心內(nèi)容之一,它以創(chuàng)建產(chǎn)品結(jié)構(gòu)樹為中心,從PDM集成應用系統(tǒng)中自動捕捉產(chǎn)品結(jié)構(gòu)信息建立產(chǎn)品結(jié)構(gòu)樹;诖,本文著重研究以非關系型數(shù)據(jù)庫NoSQL來存儲產(chǎn)品結(jié)構(gòu)信息,以產(chǎn)品結(jié)構(gòu)樹形式展示給用戶的問題。
1 產(chǎn)品結(jié)構(gòu)樹
產(chǎn)品結(jié)構(gòu)樹用于對產(chǎn)品進行逐層分解,第一層將產(chǎn)品分解成多個部件(在樹中,零件為葉子結(jié)點,部件為非葉子結(jié)點),而部件則再進一步分解成子部件和零件,此過程以此類推,直到將此產(chǎn)品的全部組成成分分解成零件為止,由此形成的分層的樹狀結(jié)構(gòu)便是產(chǎn)品結(jié)構(gòu)樹,故產(chǎn)品結(jié)構(gòu)樹反映了產(chǎn)品與零部件之間的層次關系。產(chǎn)品A的分解過程如圖1所示:
圖1 產(chǎn)品分解過程示例圖
如圖1所示的產(chǎn)品A是由多個零部件組成,其中部件又由多個零件或子部件組成。由圖1可知,產(chǎn)品結(jié)構(gòu)樹為多叉樹,而多叉樹中非葉子結(jié)點的子結(jié)點數(shù)是沒有限制的,且產(chǎn)品結(jié)構(gòu)樹中的零部件可能會被多個部件重復使用(如圖2所示),樹中每個部件都有,n(n>=0)個子部件和零件組成,每個零件又被n(n>=0)部件使用,則樹的內(nèi)部為多對多的關系。
圖2 產(chǎn)品結(jié)構(gòu)樹中零部件被重用示例圖
則由圖1和圖2可知,產(chǎn)品結(jié)構(gòu)樹主要有兩個特點:樹中非葉子結(jié)點的子結(jié)點數(shù)不固定;樹內(nèi)部結(jié)點之間為多對多關系。產(chǎn)品結(jié)構(gòu)樹的存儲結(jié)構(gòu)主要有兩種:雙親表示法和孩子表示法。由于RDB(關系型數(shù)據(jù)庫)的表中的列數(shù)是固定的,不允許列數(shù)動態(tài)地變化,因而在基于RDB的傳統(tǒng)PDM系統(tǒng)產(chǎn)品的數(shù)據(jù)存儲結(jié)構(gòu)中,主要建有基本信息表:產(chǎn)品、部件及零件表,和一個關系表以記錄產(chǎn)品的配置關系,在關系表中以一條記錄來記錄一對直系的父子關系,即將多對多的關系拆分成多個一對一的關系,并且基于此關系表記錄產(chǎn)品的更新信息。對于成型產(chǎn)品,其配置結(jié)構(gòu)是固定的,故可在基本信息中直接記錄其結(jié)構(gòu)關系,結(jié)合產(chǎn)品結(jié)構(gòu)樹及RDB的特點,本文以文檔型NoSQL數(shù)據(jù)庫(MongoDB)作為其底層數(shù)據(jù)支撐環(huán)境來研究產(chǎn)品結(jié)構(gòu)樹的數(shù)據(jù)組織,由于NoSQL具有嵌入文檔、模式自由等特點,因而較RDB能更好地記錄產(chǎn)品的基本屬性與配置關系信息。
2 基于NoSQL的PDM數(shù)據(jù)存儲結(jié)構(gòu)及產(chǎn)品結(jié)構(gòu)樹生成算法
根據(jù)產(chǎn)品結(jié)構(gòu)樹創(chuàng)建原理,利用NoSQL數(shù)據(jù)庫的特點,摒棄PDM系統(tǒng)中數(shù)據(jù)在關系型數(shù)據(jù)庫中的存儲結(jié)構(gòu)的傳統(tǒng)模式,以更靈活的方式構(gòu)建PDM的數(shù)據(jù)存儲結(jié)構(gòu),便于用戶更好地理解和操作。
2.1 基于NoSQL的PDM基本信息的數(shù)據(jù)存儲結(jié)構(gòu)
NoSQL打破RDB的一行只記錄一對關系規(guī)則,利用NoSQL的數(shù)組和內(nèi)嵌文檔功能,一條記錄便可以記錄多組關系對的功能,且關系對的數(shù)目無限制,故可在產(chǎn)品基本信息的集合中設定一個Children[]數(shù)組字段,即將產(chǎn)品結(jié)構(gòu)樹中的多對多關系拆分成一對多的關系,且在Children[]數(shù)組字段中記錄該產(chǎn)品(或部件)的所有直系孩子結(jié)點的編碼_id,并在Children[]字段中再插入一個num字段以記錄被包含的相應孩子結(jié)點的數(shù)量,而在零件集合中則沒有Children[]數(shù)組字段。
在NoSQL中,PDM基本信息主要由產(chǎn)品product集合、部件component集合、零件parts集合組成,產(chǎn)品product的屬性主要有產(chǎn)品編碼Product_id、產(chǎn)品名稱Name、類型Type、子結(jié)點Children[]、自制/外購Make/Buy、凈重Weight、創(chuàng)建者Creator、設計者Designer和創(chuàng)建日期CreateDate,字段子結(jié)點Children[]是一個數(shù)組,在Children[]中設有_id字段、Type字段和num字段,分別記錄此產(chǎn)品的所有直系孩子結(jié)點的編碼、相應結(jié)點的類型及此結(jié)點被包含的數(shù)量。該結(jié)構(gòu)相較于傳統(tǒng)RDB需要多條行記錄才能完成的存儲方式而言,更便于數(shù)據(jù)庫管理員直觀地看到某父結(jié)點的直系子結(jié)點。產(chǎn)品product集合在數(shù)據(jù)庫中的存儲結(jié)構(gòu)如下所示。
部件component集合中的主要屬性為部件編碼Component_id、部件名稱Name、類型Type、子結(jié)點Children[]、自制/外購Make/Buy、凈重Weight、創(chuàng)建者Creator、設計者Designer和創(chuàng)建日期CreateDate,部件component集合在數(shù)據(jù)庫中的存儲結(jié)構(gòu)如下所示:
零件parts集合的主要屬性為Parts_id、部件名稱Name、類型Type、材質(zhì)Material、圖紙Picture、自制/外購Make/Buy、凈重Weight、數(shù)量quantity、創(chuàng)建者Creator、設計者Designer和創(chuàng)建日期CreateDate,零件已是最小的產(chǎn)品單位,它在產(chǎn)品結(jié)構(gòu)樹中處于最底層的,故其零件parts集合在數(shù)據(jù)庫中的存儲結(jié)構(gòu)如下所示:
2.2 產(chǎn)品結(jié)構(gòu)樹生成算法
基于上述存儲結(jié)構(gòu),采用層次遍歷方法生成產(chǎn)品結(jié)構(gòu)樹,算法如下:
(1)以某一產(chǎn)品為根結(jié)點,即為樹的第一層結(jié)點;
(2)在產(chǎn)品集合中查找此產(chǎn)品記錄中的Children[]字段,記下其所有的孩子結(jié)點以及它們的類型Type,即為樹的第二層結(jié)點;
(3)第二層的所有結(jié)點中,若有類型為零件的直接定為葉子結(jié)點,若為部件類型則定為非葉子結(jié)點并查找其在部件集合記錄中的Children[]字段中的所有孩子結(jié)點的編碼及類型,這些孩子結(jié)點組成了樹的第三層;
(4)對第三層的結(jié)點的處理方法同第三步對第二層結(jié)點所做的處理,以此類推,直到樹的最底層中的各個結(jié)點均為零件類型為止。
若產(chǎn)品A的結(jié)構(gòu)為(A(B1(B3(a5,a6),a2),B2(B4(a7,a8,a9),a3,a4),al))以大寫字母代表產(chǎn)品(A、A1、…)和(子)部件(B、B1、…),以及小寫字母代表零件(a、a1…),采用Tree Tag技術在Jsp頁面上顯示,如圖3所示:
圖3 產(chǎn)品A結(jié)構(gòu)樹示例圖
3 基于NoSQL的PDM系統(tǒng)產(chǎn)品結(jié)構(gòu)樹的維護
隨著產(chǎn)品信息多樣性的發(fā)展、產(chǎn)品升級,以及客戶對產(chǎn)品性能、結(jié)構(gòu)、特征等需求的變化,產(chǎn)品結(jié)構(gòu)樹的結(jié)構(gòu)也必然隨之發(fā)生變化,其中,增加、刪除零部件操作,即對產(chǎn)品結(jié)構(gòu)樹做增加、刪除結(jié)點(根結(jié)點除外)操作最為關鍵。
3.1 產(chǎn)品結(jié)構(gòu)樹的結(jié)構(gòu)關系地整理
PDM的基本信息集合中產(chǎn)品product、部件component和零件parts集合皆用于存放某個(某類)產(chǎn)品的全部信息,而配置關系僅表示相鄰兩層之間的直系父子關系,不能全面、直觀地表達整棵樹中結(jié)點之間的(被)包含關系,因而在基于RDB的PDM系統(tǒng)中,查找某結(jié)點的祖先或后代時需要多次連接操作才能完成。
在關系型數(shù)據(jù)庫中,通常用閉包表(如表1所示)來存儲整棵樹的結(jié)構(gòu),用祖先(ancestor)和后代(descendant)兩個字段將樹中任意結(jié)點的祖先一后代關系對存儲于此閉包表中。因而在查找某結(jié)點X的祖先(后代)時,只需要在閉包表中搜索后代(祖先)是X的所有行的祖先(后代)字段對應的結(jié)點即可。
表1 閉包表
在NoSQL(以MongoDB為例)亦可采用閉包結(jié)構(gòu)形式的集合來存儲產(chǎn)品結(jié)構(gòu)樹中的結(jié)構(gòu)關系。設集合RelationComplete用來存儲產(chǎn)品的結(jié)構(gòu)關系,并且對它只做添加新記錄的操作。RelationComplete主要設有六個字段:編碼_id、參考referenceID、所屬產(chǎn)品ofProduct、后代descendant[]、祖先ancestor[]和類型Type。其中referenceID和ofProduct字段是內(nèi)嵌文檔,包括相應參考結(jié)點編碼_id和名稱name兩個列;后代descendant[]字段是一個嵌入文檔的數(shù)組,包括后代的編碼descendantld、名稱name、類型type、層次pathLevel四列。字段層次pathlevel能更加清晰地記錄此后代結(jié)點與參考的祖先結(jié)點之間的間隔層數(shù),其中,一個結(jié)點的直接子結(jié)點的pathLevel為1,再下一層為2,以此類推。集合RelationComplete結(jié)構(gòu)如下所示:
在集合RelationComplete中,由于只有類型type為產(chǎn)品和部件的參考結(jié)點才可能有后代descendant[]字段,因而用戶在查找某產(chǎn)品中結(jié)點的祖先時,首先在所屬產(chǎn)品的記錄中后代descendant[]數(shù)組字段中查找此結(jié)點,然后將相應的參考結(jié)點按照此后代結(jié)點的pathLevel值進行排序;而在查找非葉子結(jié)點的后代時,直接查找其后代descendant[]數(shù)組字段中的所有記錄即可,故可一次地查出此結(jié)點在樹中的所有后代,較傳統(tǒng)RDB需多次查找的模式更為靈活。
3.2 產(chǎn)品結(jié)構(gòu)樹的維護
產(chǎn)品結(jié)構(gòu)樹的維護亦采用閉包結(jié)構(gòu)來管理,更新時,只需更新變動的樹枝上的祖先一后代關系即可。產(chǎn)品結(jié)構(gòu)樹的維護過程如圖4所示。
圖4 產(chǎn)品結(jié)構(gòu)樹的維護過程
如圖4所示,在更新樹中結(jié)點X1的基本四種情況中,只需更新變動樹枝上X與T的后代信息,這里只考慮了更新樹中底層的情況,其它情況可基于此四種情況推演得出。
具體實現(xiàn)時,首先創(chuàng)建集合RelationChange用以保存結(jié)構(gòu)樹更新時的臨時關系,其結(jié)構(gòu)與RelationComplete相同,設有四個字段編碼_id、祖先(ancestor)、后代(descendant[])和類型Type,而后代數(shù)組字段記錄則相應地包含后代的編碼childld、名稱name、類型type。
3.2.1 插入節(jié)點
結(jié)點的更新必須同時更新其祖先及后代信息,如在樹Ax中添加一個葉子結(jié)點,則該結(jié)點祖先與后代的關系都需要更新,其過程如圖5所示。
圖5 添加葉子結(jié)點過程
如圖5所示,向樹Ax的非葉子結(jié)點Bx中添加一個葉子結(jié)點b,則零件a4、a5與b組成新部件Bx1,即其原父部件由Bx變成新部件Bx1,產(chǎn)品Ax則變成新產(chǎn)品Ax1。而在集合RelationChange中,第一步將集合RelationComplete中產(chǎn)品Ax內(nèi)部祖先與后代的關系對復制到集合中,則集合RelationChange如下所示:
由于添加結(jié)點b時,a4、a5與b組成新結(jié)點Bx1,第二步則在集合RelationChange中插入一條關于Bx1的祖先與后代關系記錄,Bx1記錄如下所示:
第三步:在字段后代descendant[]中查找含有a5結(jié)點的記錄,插入Bx2以及Bx2的(除結(jié)點a4、a5以外)后代的信息。
第四步:將集合中信息中含有Bx的記錄刪除。
當添加一棵子樹(部件)時,首先將這棵樹內(nèi)部的祖先與后代關系對從RelationComplete復制到集合RelationChange中,然后再將沿著此子樹所在產(chǎn)品結(jié)構(gòu)樹中的位置向上遍歷的結(jié)點與子樹中的所有結(jié)點設置為祖先與后代的關系對,并插入到相應的集合中。
3.2.2 刪除節(jié)點
刪除葉子結(jié)點的過程如圖6所示,若刪除Ax中的結(jié)點a3,則其父結(jié)點B1變成B11(只有a1和a2兩個孩子結(jié)點),首先刪除集合中祖先結(jié)點為B1的記錄,并添加B11記錄;然后在集合的后代信息查找B1以及a3記錄,插入B11記錄,并刪除B1和a3記錄。
圖6 刪除一個葉子結(jié)點
刪除一棵完整的子樹X時,首先在集合后代descendant[]數(shù)組字段中刪除所有以X為后代的記錄,然后在集合中刪除樹X的記錄。在集合RelationChange中完成更新操作后,將更新信息添加到基本信息集合中,然后刪除集合RelationChange。當再次更新產(chǎn)品結(jié)構(gòu)樹時,再創(chuàng)建集合RelationChange,如是在此集合中存儲的是正在更新的樹的相關信息。
4 結(jié)束語
本文以產(chǎn)品結(jié)構(gòu)樹來描述產(chǎn)品的配置關系,分析了產(chǎn)品結(jié)構(gòu)樹的結(jié)構(gòu)特點,以及基于RDB的傳統(tǒng)PDM產(chǎn)品信息數(shù)據(jù)存儲結(jié)構(gòu),提出了利用NoSQL-MongoDB嵌入文檔的數(shù)組產(chǎn)品信息的新存儲結(jié)構(gòu)模式,以及在運行時動態(tài)創(chuàng)建產(chǎn)品結(jié)構(gòu)樹的新思路,較關系型數(shù)據(jù)庫建表的傳統(tǒng)模式更加便于管理產(chǎn)品的結(jié)構(gòu)關系,且更利于產(chǎn)品結(jié)構(gòu)樹的維護,為企業(yè)產(chǎn)品數(shù)據(jù)管理探索出一條更為廣闊的新視野。
核心關注:拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務領域、行業(yè)應用,蘊涵了豐富的ERP管理思想,集成了ERP軟件業(yè)務管理理念,功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領域的管理,全面涵蓋了企業(yè)關注ERP管理系統(tǒng)的核心領域,是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處:拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標題:基于NoSQL的PDM產(chǎn)品結(jié)構(gòu)數(shù)據(jù)組織
本文網(wǎng)址:http://www.ezxoed.cn/html/solutions/14019311706.html