Ofbiz數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計

1、目錄Ofbiz數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計21.ofbiz數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計 - PARTY22.ofbiz數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計 - CONTACT_MECH43.Ofbiz數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計 - 訂單ORDER84.ofbiz數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計 - 訂單支付ORDER_PAYMENT_PREFERENCE105.ofbiz數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計 - 庫存INVENTORY126.ofbiz數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計 Payment & Invoice13Ofbiz數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計轉(zhuǎn)載：1. ofbiz數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計 - PARTYofbiz的精華就在于其數(shù)據(jù)結(jié)構(gòu)（表結(jié)構(gòu)）的設(shè)計。數(shù)據(jù)結(jié)構(gòu)的通用性也決定了ofbiz幾乎可

2、以適用任何企業(yè)應(yīng)用。我們首先來看看PARTY相關(guān)的表結(jié)構(gòu)設(shè)計。在ofbiz中，PARTY是個抽象概念，它可以是一個人（用戶、員工、家人等等），也可以是個組織（公司、部門、項目組、供應(yīng)商、集團客戶等等）。然而畢竟個人和組織的許多屬性是不同的，比如姓名就只有個人有，組織只有組織名稱等等，因此，在PARTY基礎(chǔ)上派生出兩個對象（兩張表），PERSON帶表個人，PARTY_GROUP代表組織。我們注意到在PERSON和PARTY_GROUP兩張表里，有PARTY_ID作為外鍵指向PARTY表的PARTY_ID主鍵，而PARTY_ID在PERSON和PARTY_GROUP里同時也扮演著主鍵的角色。這種設(shè)

3、計模式大大簡化了程序開發(fā)的復(fù)雜度。 下面再來看看PARTY的角色。ofbiz中并沒有一個我們習(xí)慣的ROLE表，而只有一個ROLE_TYPE表。其實這個ROLE_TYPE就是我們習(xí)慣的ROLE，可能是ofbiz覺得現(xiàn)實中分不清什么是ROLE，什么是ROLE_TYPE，取而代之的是ROLE_TYPE里有個PARENT_ROLE_TYPE_ID指向自己，用此方式來表示一個ROLE_TYPE（角色）的層級結(jié)構(gòu)。PARTY_ROLE是PARTY和ROLE_TYPE的多對多關(guān)系表，我們當然能夠理解，一個PARTY通常會有多個角色。ofbiz的角色相關(guān)的設(shè)計中，最精妙的是PARTY_RELATIO

4、NSHIP。PARTY_RELATIONSHIP的幾個主要字段是PARTY_ID_FROM、PARTY_ID_TO、ROLE_TYPE_ID_FROM、ROLE_TYPE_ID_TO、PARTY_RELATIOSHIP_TYPE_ID。現(xiàn)實社會中，每個人都有不同的角色，每個人與其他人或組織也有不同的關(guān)系，PARTY_RELATIONSHIP就是為了這些復(fù)雜的人以及組織之間的關(guān)系而設(shè)計的。比如，某個人P是某個公司O的雇員，那么在PARTY_RELATIONSHIP表中，PARTY_ID_FROM指向PARTY表中的P這條數(shù)據(jù)，PARTY_ID_TO指向PARTY表中的O這條數(shù)據(jù)，ROLE_TYP

5、E_ID_FROM指向ROLE_TYPE表中的EMPLOYEE（ofbiz的初始數(shù)據(jù)中有），ROLE_TYPE_ID_TO指向ROLE_TYPE表中的ORGANIZATION_UNIT（ofbiz的初始數(shù)據(jù)中有），PARTY_RELATIONSHIP_TYPE_ID指向PARTY_RELATIONSHIP_TYPE表中的EMPLOYMENT（ofbiz的初始數(shù)據(jù)中有）。用這種方式，我們可以表示出社會上幾乎所有的人、組織之間的關(guān)系。在PARTY_RELATIONSHIP中，我們還發(fā)現(xiàn)有兩個屬性，F(xiàn)ROM_DATE和THRU_DATE，表明，這個relationship只在FROM_DATE和TH

6、RU_DATE之間的日期有效，過期無效。這種設(shè)計廣泛存在于ofibz的其它對象中，通常當某個對象的內(nèi)容更新了，ofbiz不會去更新原有的記錄，而是將原先的記錄的THRU_DATE設(shè)為當天（即到今天為止就過期了），另外再新增加一條記錄，F(xiàn)ROM_DATE設(shè)為第二天（即從明天開始有效）。 在應(yīng)用中，我們經(jīng)常會給人或組織進行分類。如按照公司雇員人數(shù)進行分類，按照公司所屬行業(yè)進行分類，按照用戶的年齡進行分類，按照用戶的積分進行分類等等。為了能夠?qū)崿F(xiàn)這種靈活的分類方法，ofbiz使用了三張表，PARTY_CLASSIFICATION、PARTY_CLASSIFICATION_GROUP、PAR

7、TY_CLASSIFICATION_TYPE。其關(guān)系如下圖：PARTY_CLASSIFICATION_TYPE是分類的方法，如：ANNUAL_REVENUE表示按年收入分類、INDUSTRY_CLASSIFICAT表示按行業(yè)分類等等。PARTY_CLASSIFICATION_GROUP表示了在某種分類方式下的分類級別，PARTY_CLASSIFICATION則是PARTY和PARTY_CLASSIFICATION_GROUP的多對多關(guān)系表，即明確該PARTY屬于哪個分類方式下的哪個級別。舉個例子，很多零售企業(yè)會根據(jù)客戶的購買金額把客戶分為金牌用戶、銀牌用戶等等，這時，我們需要在PARTY_CL

8、ASSIFICATION_GROUP里增加幾條記錄（如：PARTY_CLASSIFICATION_TYPE_ID=VALUE_RATING，DESCRIPTION=金牌用戶）來代表金牌用戶、銀牌用戶等等，然后通過PARTY_CLSSIFICATION將用戶與PARTY_CLASSIFICATIO_GROUP進行關(guān)聯(lián)。同樣，我們可以定義不同的PARTY_CLASSIFICATIO_GROUP來代表不同其它分類的級別，并將用戶（PARTY）進行關(guān)聯(lián)。2. ofbiz數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計 - CONTACT_MECHofbiz中，party的電話、地址等聯(lián)系方式設(shè)計得非常巧妙，讓我們來仔細分析一下。有一

9、個叫做CONTACT_MECH的表，這張表我們把它稱作聯(lián)系方式表，一個電話號碼、一個通訊地址、一個電子郵件，都分別會在這張表里找到對應(yīng)的一條 記錄。然后通過PARTY_CONTACT_MECH表與PARTY進行多對多關(guān)聯(lián)，也就是一個PARTY可以對應(yīng)多個聯(lián)系方式，同樣一個聯(lián)系方式也可以 對應(yīng)多個PARTY（比如家庭成員共用一個電話號碼）。在PARTY_CONTACT_MECH里，我們又發(fā)現(xiàn)了FROM_DATE和THRU_DATE兩個字段。我們當然可以理解，每個聯(lián)系方式都會有有效期 間（從FROM_DATE到THRU_DATE），這樣的設(shè)計使得我們不必為PARTY的聯(lián)系方式煩惱了。比如，某個用戶

10、的電話號碼改變了，我們只需在原 先的PARTY_CONTACT_MECH記錄里的THRU_DATE設(shè)為今天，然后新增一條記錄代表用戶新的電話號碼。這樣的設(shè)計，保留了老的電話號 碼，使得系統(tǒng)運維人員總是能夠找到歷史的記錄。在CONTACT_MECH表里，有兩個字段：CONTACT_MECH_TYPE_ID和INFO_STRING。我們先來看 CONTACT_MECH_TYPE_ID，該字段是個外鍵指向CONTACT_MECH_TYPE。如果我們在初始化ofbiz的時候?qū)肓顺跏紨?shù)據(jù)， 就會發(fā)現(xiàn)CONTACT_MECH_TYPE里存放的是“EMAIL_ADDRESS”、“POSTAL_ADDRES

11、S”、“TELECOM_NUMBER”等聯(lián)系方式的類型。這里有人會問，怎么沒有MOBILE_NUMBER（手機號碼）？在ofbiz中，手機的聯(lián)系方式類 型也是“TELECOM_NUMBER”。那如何表達手機呢？這時需要引入另外一張表，CONTACT_MECH_PURPOSE_TYPE。在初始化數(shù) 據(jù)里，我們發(fā)現(xiàn)許多例如“PHONE_HOME”、“SHIPPING_LOCATION”、“PHONE_MOBILE”等代表聯(lián)系目的的數(shù)據(jù)。手機是作為一種聯(lián)系目的在CONTACT_MECH_PURPOSE_TYPE表中定義了（也就是“PHONE_MOBILE”這條數(shù)據(jù)），并通過 CONTACT_MECH

12、_TYPE_PURPOSE表（注意不是CONTACT_MECH_PURPOSE_TYPE）與 CONTACT_MECH_TYPE_ID進行了多對多的關(guān)聯(lián)。CONTACT_MECH_TYPE_PURPOSE也就定義了哪些聯(lián)系方式的類型可以有 哪些聯(lián)系目的。在CONTACT_MECH里，有個字段叫INFO_STRING，如果這個CONTACT_MECH代表的是email，則INFO_STRING里的 內(nèi)容就是email。不過如果這個CONTACT_MECH代表的是電話號碼或地址，那哪里存放區(qū)號、城市、郵編等內(nèi)容呢？顯然，ofbiz是不會把這些信息一股腦兒都弄成字符串存放到INFO_STRING里，

13、這樣的話，就必須有另外兩張表：TELECOM_NUMBER（存放電話號碼）和 POSTAL_ADDRESS（存放地址），這兩張表各有外鍵指向CONTACT_MECH。到這里，我們已經(jīng)把有關(guān)PARTY的聯(lián)系方式介紹得差不多了，基本概念都已經(jīng)在了。但是還有一張表，或許是最為關(guān)鍵的一張表，PARTY_CONTACT_MECH_PURPOSE。這張表里有主要是三個字段，都是外鍵：PARTY_ID（指向PARTY的外鍵）、CONTACT_MECH_ID（指向CONTACT_MECH的外鍵）、CONTACT_MECH_PURPOSE_TYPE_ID（指向 CONTACT_MECH_PURPOSE_TYPE

14、的外鍵）。這三個外鍵的組合，唯一指明了某個PARTY的某個聯(lián)系方式（CONTACT_MECH） 是做什么用的（CONTACT_MECH_PURPOSE_TYPE）。不過這個PARTY_CONTACT_MECH_PURPOSE和PARTY_CONTACT_MECH感覺上是重合的，PARTY_CONTACT_MECH_PURPOSE已經(jīng)包含了PARTY_CONTACT_MECH的所有信息。之所以還要有 PARTY_CONTACT_MECH，可能也是為了概念上以及使用上的方便，不過這個也增加了維護方面的成本。3. Ofbiz數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計 - 訂單ORDER對于訂單來說，主要的表就是ORDER_H

15、EADER和ORDER_ITEM。ORDER_HEADER就是所謂的訂單頭，一條記錄代表一條訂單。ORDER_PAYMENT_PREFERENCE是訂單的支付，它有三個主要外鍵，ORDER_ID代表是哪個訂單，PAYMENT_METHOD_ID代表是哪種具體付款方法，PAYMENT_METHOD_TYPE_ID代表哪種付款類型。 ORDER_HEADER中的字段：ORDER_TYPE_ID是外鍵指向ORDER_TYPE表，用來表示該訂單是個采購訂單還是銷售訂單。EXTERNAL_ID是代表了外部訂單號，比如說拿ofbiz作為ERP來處理淘寶上的訂單，那EXTERNAL_ID就可以用來

16、存儲淘寶上的訂單號。STATUS_ID是該訂單的狀態(tài)，是外鍵指向STATUS_ITEM表，STATUS_ITEM表中STATUS_TYPE_ID為"ORDER_STATUS"的數(shù)據(jù)是ORDER_HEADER中STATUS_ID字段 的可選項。這里要注意，ofbiz中訂單的狀態(tài)和貨運（SHIPMENT）狀態(tài)以及支付（PAYMENT）狀態(tài)是三個分開的對象的狀態(tài)，象淘寶上“等待支 付”以及“等待賣家發(fā)貨”這種訂單狀態(tài)，在ofbiz中是PAYMENT對象以及SHIPMENT對象的狀態(tài)。PRODUCT_STORE_ID是用來表示該銷售訂單是在哪個店賣出去的。REMAINING_SUB

17、_TOTAL可以看作是除了運費之外的所有費用總和（包括商品的費用，其它各種費用，還要減去各種促銷費用）。GRAND_TOTAL可以看作是包括了運費之后的費用，也就是客戶需要總共支付的費用。ORDER_ITEM中的字段：ORDER_ID外鍵為對應(yīng)的訂單。ORDER_ITEM_SEQ_ID只是一個序列號，在一個訂單中，總是以00001開始。PRODUCT_ID代表了這個訂單項所對應(yīng)的產(chǎn)品。QUANTITY是訂單中這個商品的數(shù)量。CANCEL_QUANTITY是訂單中這個商品取消的數(shù)量，如果QUANTITY是4，CANCEL_QUANTITY是4，則代表用戶買了這個商品4件，但是又取消了4件，當然，

18、最后結(jié)果就是1件也沒買。UNIT_PRICE在這個訂單中這個商品的單價。UNIT_LIST_PRICE這個商品的吊牌價。UNIT_AVERAGE_COST在這個訂單中這個商品的平均成本，但是根據(jù)我們的檢查，似乎ofbiz從來都沒有用到這個字段，在系統(tǒng)中，這個字段的值永遠是NULL。所以我們認為，開發(fā)者可以在自己開發(fā)的程序中，把這個值填充上去，為報表做準備。4. ofbiz數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計 - 訂單支付ORDER_PAYMENT_PREFERENCE訂單的支付主要集中在ORDER_PAYMENT_PREFERENCE，PAYMENT_METHOD_TYPE，PAYMENT_METHOD和PAYM

19、ENT。它們的關(guān)系相對比較復(fù)雜，具體見下圖：ORDER_PAYMENT_PREFERENCE存儲了一個訂單的支付信息，當然，一個訂單可以有多個支付，比如一個100元的訂單，其中20元客戶用 現(xiàn)金支付，30元用銀行卡支付，剩下50元用信用卡支付（現(xiàn)實生活中這種情況不太可能發(fā)生，但是ofbiz支持這種情況）。PAYMENT_METHOD_TYPE是支付類型，比如信用卡支付、現(xiàn)金支付、支票支付等。PAYMENT_METHOD支付方法，這個對象很多開發(fā)人員將它與PAYMENT_METHOD_TYPE搞混。PAYMENT_METHOD是 PAYMENT_METHOD_TYPE的具體形式?？醋侄?，其中PA

20、RTY_ID代表支付的人（或公司），GL_ACCOUNT_ID代表該支付方法對應(yīng)COMPANY（在ofbiz中COMPANY指的就是擁有這個ofbiz的企業(yè)）的財務(wù)哪個科目，F(xiàn)IN_ACCOUNT_ID代表具體的財務(wù)賬戶（如某個銀行的賬戶）。PAYMENT支付指的是具體的一次支付行為。再看一下這些對象之間的聯(lián)系。ORDER_PAYMENT_PREFERENCE有兩個外鍵分別指向PAYMENT_METHOD_TYPE和 PAYMENT_METHOD。而我們已經(jīng)看到，PAYMENT_METHOD已經(jīng)有外鍵指向PAYMENT_METHOD_TYPE了，那 ORDER_PAYMENT_PREFEREN

21、CE為什么還要同時指向PAYMENT_METHOD和PAYMENT_METHOD_TYPE？原因是，對于一次訂單的支付，最理想情況是，我們知道支付的具體信息（知道支付者的銀行信息等），這樣我們就能夠設(shè)置 ORDER_PAYMENT_PREFERENCE里的PAYMENT_METHOD_ID了。但是在某些零售情況下，我們對客戶的支付具體信息是不知道 的，比如對方用現(xiàn)金支付，或者是通過其它第三方支付，我們不知道具體的支付信息，這樣，在ORDER_PAYMENT_PREFERENCE里，我們就得 依賴PAYMENT_METHOD_TYPE_ID這個字段了。也許有人問，如果在ORDER_PAYMENT

22、_PREFERENCE 里，PAYMENT_METHOD_TYPE_ID指向的信息和PAYMENT_METHOD_ID指向的信息矛盾怎么辦？這點我也不清楚，讓我們盡量避免這種麻煩吧。PAYMENT這個對象同時有三個外鍵指向ORDER_PAYMENT_PREFERENCE、PAYMENT_METHOD_TYPE和 PAYMENT_METHOD。在ofbiz中，PAYMENT代表了一次支付行為，所以，可以是一次訂單的支付（所以要有外鍵指向 ORDER_PAYMENT_PREFERENCE），也可能是其它的支付，所以，它也需要有外鍵指向PAYMENT_METHOD_TYPE和 PAYMENT_MET

23、HOD。5. ofbiz數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計 - 庫存INVENTORY庫存是ERP里的核心模塊之一。ofbiz的庫存管理，主要集中在INVENTORY_ITEM和INVENTORY_DETAIL中。 ofbiz的庫存是按照批次進行管理的。批次的概念是，某個商品每進一次貨，單獨會對這次進貨的商品進行管理。所以，同一個商品，每一個批次，就會生成一條INVENTORY_ITEM數(shù)據(jù)。批次的管理，在藥品食品中就很重要，因為同樣的藥，每個批次的保質(zhì)期會不一樣，所以要分開管理。還有，同樣的商品，不同批次進貨，可能進貨價格不一樣，也就是成本會不一樣，也需要分開管理，財務(wù)方面會有計算成本的需求。INV

24、ENTORY_DETAIL則是針對每個INVENTORY_ITEM，記錄下所有的進出貨記錄。所以，當某個商品新進一批貨的時候，會產(chǎn)生一條 INVENTORY_ITEM，同時也會產(chǎn)生一條INVENTORY_ITEM_DETAIL（外鍵指向先前的INVENTORY_ITEM）。同樣的商品，再進一批貨的時候，會再產(chǎn)生一條INVENTORY_ITEM，同時還會產(chǎn)生一條INVENTORY_ITEM_DETAIL（外鍵指向剛剛生成的 INVENTORY_ITEM）。接下來，當該商品產(chǎn)生一次銷售的時候，會在最先生成的INVENTORY_ITEM（根據(jù)先進先出的原則）里扣除該次銷售的商品數(shù)量，并且生成一條新的

25、INVENTORY_ITEM_DETAIL數(shù)據(jù)記錄。在ofbiz中，有三個庫存概念，一個是實際庫存（QUANTITY_ON_HAND），一個是可用庫存（AVAILABLE_TO_PROMISE）和 一個財務(wù)庫存（ACCOUNTING_QUANTITY）。實際庫存代表該批次實際有的商品數(shù)量，可用庫存代表該批次可以銷售的商品數(shù)量（可能用戶已經(jīng)買 了，但是還沒發(fā)貨，會導(dǎo)致可用庫存小于實際庫存），財務(wù)庫存代表了庫存資產(chǎn)。在INVENTORY_ITEM中，實際庫存存在QUANTITY_ON_HAND_TOTAL中，QUANTITY_ON_HAND沒有用，可用庫存存在AVAILABLE_TO_PROMIS

26、E_TOTAL中，AVAILABLE_TO_PROMISE沒有用，財務(wù)庫存存在 ACCOUNTING_QUANTITY_TOTAL中，ACCOUNTING_QUANTITY沒有用。在INVENTORY_ITEM_DETAIL中，QUANTITY_ON_HAND_DIFF保存的是某次進出貨記錄實際庫存的差額（正數(shù)代表加庫存，負數(shù)代表減庫存），AVAILABLE_TO_PROMISE_DIFF是可用庫存的差額，ACCOUNTING_QUANTITY_DIFF代表財務(wù)庫 存的差額。很多時候，當我們生成一條銷售訂單的時候，我們會發(fā)現(xiàn)某個INVENTORY_ITEM關(guān)聯(lián)的INVENTORY_ITEM_D

27、ETAIL會產(chǎn)生三條記錄。一條是減去可用庫存，一條是減去實際庫存，一條是減去財務(wù)庫存。我們很容易想到，在電子商務(wù)里，當用戶下了一條訂單，我們首先生成一條 INVENTORY_ITEM_DETAIL記錄，減去可用庫存，這時導(dǎo)致了這個批次的庫存中，可用庫存少于實際庫存，當我們發(fā)貨的時候，再生成一條 INVENTORY_ITEM_DETAIL記錄，減去實際庫存，這時，這個批次的庫存中，實際庫存又跟可用庫存相等了。當財務(wù)把這次交易記上賬后，再生成一條記錄，減去財務(wù)庫存。稍微復(fù)雜一點的情況，當用戶下了單，生成了減去可用庫存的記錄后，用戶又不想要了。這時，系統(tǒng)不會把剛生成的那條 INVENTORY_ITEM_DETAIL記錄給刪除，或把AVAILABLE_