數(shù)據(jù)庫表的結(jié)構(gòu)設(shè)計(jì)可謂是ofbiz除技術(shù)框架之外，另一個(gè)非常值得學(xué)習(xí)的方向。這篇文章我們來談?wù)刼fbiz對(duì)電子商務(wù)會(huì)員表的設(shè)計(jì)。

PARTY

ofbiz對(duì)人、團(tuán)體進(jìn)行了抽象，稱之為party，翻譯為中文稱之為“會(huì)員”（但我覺得拋開領(lǐng)域，如果你也有相關(guān)的設(shè)計(jì)需求，在其他領(lǐng)域可能稱之為團(tuán)體更合適）。會(huì)員在ofbiz被設(shè)計(jì)為一個(gè)抽象的概念（對(duì)應(yīng)到面向?qū)ο笤O(shè)計(jì)中，你可以稱其為一個(gè)基類），它有兩個(gè)具體的延伸（繼承者）：分別是PERSON以及PARTY_GROUP。數(shù)據(jù)庫的E-R圖：

這里PERSON，PARTY_GROUP分別表示“個(gè)人會(huì)員”、“組織會(huì)員”。Party只是一種抽象，它定義了可以被抽象為“會(huì)員”的對(duì)象所具有的基本特征。但 “個(gè)人”以及“組織”會(huì)員卻具備比 “基本會(huì)員”更多的特征，所以此處從Party延伸出兩張表來存儲(chǔ)這些額外的特征信息它們的主鍵都是PARTY表的PARTY_ID。

PARTY_TYPE

partyType定義了party的類型約束。E-R圖如下：

可以看到，PARTY_TYPE是擁有層級(jí)關(guān)系的（它的一個(gè)屬性PARENT_TYPE_ID自關(guān)聯(lián)了PARTY_TYPE的主鍵：PARTY_TYPE_ID，下面如果看到E-R圖上有自關(guān)聯(lián)到本身的，都表示這種關(guān)系，不再敖述）。

ofbiz提供的初始數(shù)據(jù)中有如下幾種party type：

構(gòu)建成層級(jí)關(guān)系如下圖所示：

上面展示的兩張表：PERSON、PARTY_GROUP也是其中的兩個(gè)partyType，并且這些partyType都可以獨(dú)立擴(kuò)展的，PERSON、PARTY_GROUP也是僅有的兩個(gè)擴(kuò)展。這也是上面表結(jié)構(gòu)中這兩個(gè)記錄的HAS_TABLE值為Y的原因。

PARTY_ROLE

就跟社會(huì)的“角色分工”一樣，一個(gè)會(huì)員在系統(tǒng)中也必定會(huì)擁有屬于自己的角色。而PARTY_ROLE表就是用于關(guān)聯(lián)會(huì)員與角色類型的關(guān)系表，很明顯會(huì)員與角色類型是多對(duì)多的關(guān)系（這里需要提及的是：ofbiz中只有角色類型，沒有角色，或者更準(zhǔn)確點(diǎn)說，角色類型包含了角色）。

PARTY_RELATIONSHIP

上面我們看到的會(huì)員是一類“抽象”的實(shí)體。不管它表示的是個(gè)人，還是組織，它總是會(huì)跟其他會(huì)員發(fā)生關(guān)系，就好像一個(gè)人不可能脫離社會(huì)而孤立得存在著，他必然有自己的社會(huì)角色，并跟社會(huì)的其他“團(tuán)體”產(chǎn)生聯(lián)系。這在ofbiz中被抽象為“partyRelationship”。我們來看它是如果表達(dá)“關(guān)系”這個(gè)語義的：

當(dāng)你把這些所有的字段連起來，它幾乎能涵蓋所有的“會(huì)員關(guān)系”（要知道，有時(shí)會(huì)員關(guān)系會(huì)非常復(fù)雜，一個(gè)會(huì)員有時(shí)會(huì)存在于多個(gè)系統(tǒng)中）。

我們?cè)倩剡^頭來，看PARTY_RELATIONSHIP的表結(jié)構(gòu)設(shè)計(jì)：

可以看到前五個(gè)鍵形成了聯(lián)合主鍵，其中前四個(gè)都是形如XXX_FROM，XXX_TO的ID標(biāo)識(shí)。表示從“FROM”方往“TO”方建立關(guān)系。其中PARTY_ID_FROM與ROLE_TYPE_ID_FROM是“源”方；PARTY_ID_TO與ROLE_TYPE_ID_TO是“目標(biāo)”方。

從上面圖中也可以看到，每個(gè)關(guān)系都帶有兩個(gè)DATETIME字段，分別表示：開始日期，截止日期。這說明關(guān)系是有“時(shí)段”這個(gè)屬性的。當(dāng)然，如果沒有截止日期，可以看做是“永久”的。因此為了防止關(guān)系過了生效時(shí)段無法再次建立關(guān)系（因?yàn)橹麈I不允許重復(fù)），所以選擇了聯(lián)合“FROM_DATE”作為聯(lián)合主鍵（后面如果再次建立相同的關(guān)系時(shí)，只要FROM_DATE不一樣，就視為一條新記錄）。

這里有必要說明一下，在ofbiz的數(shù)據(jù)庫設(shè)計(jì)中，大量采用了“時(shí)段”這個(gè)屬性來標(biāo)識(shí)記錄的有效性。這樣的設(shè)計(jì)與邏輯刪除相比的好處是：它除了減少了刪除時(shí)因?yàn)橥怄I約束等連帶關(guān)系導(dǎo)致的錯(cuò)誤，還可以直接充當(dāng)“歷史記錄”的作用，省去了對(duì)歷史表的維護(hù)，當(dāng)然它的缺點(diǎn)就是：表中的記錄會(huì)比其他的設(shè)計(jì)多得多。

當(dāng)然，From跟To只是為了標(biāo)識(shí)兩者建立了關(guān)系，卻并未說明它們到底存在怎樣的關(guān)系，就好像——我跟你是朋友。這句話可以拆分為三部分：FROM方：我，TO方：你，關(guān)系是：朋友。上表中用一個(gè)字段表示了關(guān)系：PARTY_RELATIONSHIP_TYPE_ID（這只是一個(gè)外鍵，關(guān)聯(lián)著表PARTY_RELATIONSHIP_TYPE）。

在界面上新建一個(gè)關(guān)系（此處是從外部到自己的一個(gè)關(guān)系）：

PARTY_RELATIONSHIP_TYPE

該表約束了關(guān)系的類型。比如：雇傭者、朋友、父、子、管理者，E-R圖：

從圖中可以看出，會(huì)員關(guān)系類型也擁有層次關(guān)系。表中還有兩個(gè)特別的字段：

• ROLE_TYPE_ID_VALID_FROM
• ROLE_TYPE_ID_VALID_TO
  

它們用于約束這個(gè)關(guān)系的建立雙方的角色。也就是說，不是任意的兩個(gè)角色之間一定可以建立起某個(gè)特定的會(huì)員關(guān)系。當(dāng)然這兩個(gè)字段通常都為空，表示不對(duì)此加以限制。
對(duì)每個(gè)關(guān)系類型，都可以擴(kuò)展以獨(dú)立實(shí)現(xiàn)關(guān)系（被擴(kuò)展后關(guān)系類型記錄的字段HAS_TABLE被標(biāo)識(shí)為Y，否則默認(rèn)為N），在ofbiz的初始化數(shù)據(jù)中，唯一被擴(kuò)展的關(guān)系類型是：EMPLOYMENT。我們來看看EMPLOYMENT關(guān)系表的實(shí)現(xiàn)：

可以看到，它跟之前的PARTY_RELATIONSHIP的主鍵實(shí)現(xiàn)方式一樣。因此可以把它看做是：PARTY_RELATIONSHIP_TYPE_ID為EMPLOYMENT的PARTY_RELATIONSHIP的特殊實(shí)現(xiàn)。
在界面上建立一個(gè)關(guān)系類型：

PARTY_CLASSIFICATION_TYPE

為了便于管理，ofbiz對(duì)會(huì)員按各種維度進(jìn)行分類，常見的分類的類型有：年收入、價(jià)值等級(jí)、產(chǎn)業(yè)、雇員數(shù)量等；

PARTY_CLASSIFICATION_GROUP

會(huì)員并不會(huì)直接跟分類的類型產(chǎn)生關(guān)系，而是跟一個(gè)或多個(gè)分類組產(chǎn)生關(guān)聯(lián)關(guān)系。而分類組受分類類型約束。
新建一個(gè)分類組：

PARTY_CLASSIFICATION

會(huì)員的分類相關(guān)表的關(guān)系圖：

從表的關(guān)聯(lián)關(guān)系可以看出，會(huì)員分類跟分類組是多對(duì)多的關(guān)系，并且分類具有時(shí)效性。因此聯(lián)合FROM_DATE作外鍵。
將會(huì)員劃歸入一個(gè)會(huì)員分類：

CONTENT_MECH

從這張表開始，我們來看會(huì)員的聯(lián)系方式相關(guān)的表結(jié)構(gòu)設(shè)計(jì)，這也是一部分非常棒的設(shè)計(jì)。
這張表存儲(chǔ)了聯(lián)系方式基本信息。它引用了另一張表：CONTENT_MECH_TYPE作為外鍵，來表示該聯(lián)系方式的類型（通常的聯(lián)系方式類型有電話、郵箱、網(wǎng)址等）。

CONTENT_MECH_TYPE

可以看到聯(lián)系方式類型，也是具有層級(jí)結(jié)構(gòu)（父子關(guān)系）的。
當(dāng)我們想新建一個(gè)聯(lián)系方式時(shí)，首先必須先指定想創(chuàng)建的聯(lián)系方式的類型：

PARTY_CONTACT_MECH

毫無疑問，地址信息只有跟會(huì)員聯(lián)系起來，才能表示會(huì)員的地址。而會(huì)員跟地址是多對(duì)多的關(guān)系，理解這個(gè)關(guān)系時(shí)需要注意的是會(huì)員可以是任何團(tuán)體、組織或者個(gè)人。那這里可能就會(huì)存在兩個(gè)不同的會(huì)員擁有同一個(gè)聯(lián)系方式的可能，比如：一個(gè)員工會(huì)員與一個(gè)該員工所屬的公司會(huì)員，它們可以都存在同一個(gè)聯(lián)系方式：公司的通訊地址。當(dāng)然一個(gè)會(huì)員擁有多個(gè)聯(lián)系方式，這是很容易理解的。所以會(huì)員標(biāo)識(shí)跟聯(lián)系方式標(biāo)識(shí)之間是多對(duì)多的關(guān)系，并且跟前面的設(shè)計(jì)模式相似——聯(lián)系方式也有時(shí)效性，比如換電話號(hào)碼，換工作導(dǎo)致聯(lián)系方式變化等，所以聯(lián)合FROM_DATE作為聯(lián)合主鍵：

當(dāng)我們選擇聯(lián)系方式類型為電話號(hào)碼時(shí)，會(huì)出現(xiàn)如下的表單填寫：

如果你新建一個(gè)聯(lián)系方式的類型為電話號(hào)碼，那么電話號(hào)碼存儲(chǔ)在何處？此處又跟前面談到的HAS_TABLE字段有關(guān)(CONTACT_MECH_TYPE中也存在這個(gè)字段)。正常情況下，聯(lián)系方式關(guān)聯(lián)著聯(lián)系方式類型，普通的聯(lián)系方式的具體信息存儲(chǔ)在CONTACT_MECH的INFO_STRING屬性中。但有些聯(lián)系信息不是單純的像郵箱這樣只是一個(gè)字符串，比如像電話號(hào)碼、郵政編碼…它們都有具體的格式表示。所以這些特例用INFO_STRING這一個(gè)屬性存儲(chǔ)也不方便，因此可以獨(dú)立擴(kuò)展該CONTACT_MECH_TYPE(將其HAS_TABLE字段設(shè)置為Y，這樣查詢?cè)揅ONTACT_MECH信息的時(shí)候，就不采用INFO_STRING字段，而是采用擴(kuò)展表中格式化的聯(lián)系方式)。

CONTACT_MECH_PURPOSE_TYPE

當(dāng)我們點(diǎn)擊上面界面的保存按鈕之后，會(huì)更進(jìn)一步得擴(kuò)充聯(lián)系信息：

在ofbiz中還存在一個(gè)稱之為“聯(lián)系目的”的東西，它是什么意思？

看到選項(xiàng)我們就會(huì)明白，說白了一個(gè)人的地址簿或者電話簿中的聯(lián)系方式可能有很多。它們沒有主次之分，只有目的不同。

PARTY_CONTACT_MECH_PURPOSE

上面談到了聯(lián)系目的，那么很自然它需要跟會(huì)員具體的某條聯(lián)系信息關(guān)聯(lián)起來才能稱之為：某個(gè)會(huì)員為了某種聯(lián)系目的存儲(chǔ)了一個(gè)“聯(lián)系方式”記錄。

這里需要注意的是，它并沒有跟PARTY_CONTACT_MECH產(chǎn)生直接關(guān)聯(lián)（沒有外鍵關(guān)系），而是把PARTY_CONTACT_MECH的三個(gè)主鍵照搬過來，聯(lián)合CONTACT_MECH_PURPOSE_TYPE_ID形成四個(gè)組合主鍵，這是因?yàn)镻ARTY_CONTACT_MECH的聯(lián)合主鍵機(jī)制無法被其他表當(dāng)做外鍵引用。因此，可以將PARTY_CONTACT_MECH_PURPOSE看作聯(lián)系信息模塊的聚合。這個(gè)怎么來理解？其實(shí)一個(gè)地址可以看成：某個(gè)會(huì)員（PARTY_ID），出于某種目的（CONTACT_MECH_PURPOSE_TYPE_ID）,在某段時(shí)間內(nèi)（FROM_DATE），保存了某個(gè)聯(lián)系方式（CONTACT_MECH_ID）。這種聯(lián)系方式的設(shè)計(jì)非常有彈性，因此在大部分情況下，這種抽象性能夠涵蓋大部分應(yīng)用場景。

CONTENT_TYPE

會(huì)員內(nèi)容的設(shè)計(jì)跟聯(lián)系方式類似。會(huì)員可以有一個(gè)類似文件空間在服務(wù)器上，可以供其保存文檔、圖片之類的東西。CONTENT_TYPE限定了會(huì)員可以存儲(chǔ)的內(nèi)容類型：

CONTENT

該表是它的具體存儲(chǔ)內(nèi)容的地方，當(dāng)然并不是唯一的，如果CONTENT_TYPE有一條記錄的HAS_TABLE值為Y，則那個(gè)記錄對(duì)應(yīng)的表也用于存儲(chǔ)內(nèi)容。內(nèi)容表里的字段非常多，就不截圖了。
跟之前的聯(lián)系信息類似，會(huì)員可以有多個(gè)內(nèi)容，一個(gè)內(nèi)容也可能從屬于多個(gè)會(huì)員。因?yàn)闀?huì)員是個(gè)抽象的概念，對(duì)應(yīng)到實(shí)體上可能會(huì)有重合，所以需要一個(gè)“目的”來修飾會(huì)員內(nèi)容，它就是——PARTY_CONTENT_TYPE。

PARTY_CONTENT_TYPE

用于修飾會(huì)員內(nèi)容的用途，當(dāng)然這里它的表名叫type，事實(shí)上從數(shù)據(jù)記錄來看，來時(shí)充當(dāng)了目的的作用。

內(nèi)容還跟其他一些表有關(guān)聯(lián)（主要是被引用關(guān)系，比如：CONTENT_ROLE等），此處因?yàn)楦疚闹黝}沒太大關(guān)系，所以不再敖述。

總結(jié)

更高的抽象級(jí)別

ofbiz party模塊的設(shè)計(jì)，正如它所應(yīng)用的場景：非常適用于電子商務(wù)系統(tǒng)會(huì)員信息相關(guān)的設(shè)計(jì)。當(dāng)然ofbiz中其他相關(guān)的多個(gè)系統(tǒng)也同樣應(yīng)用了這些表結(jié)構(gòu)，這也意味著它有適用于一般行業(yè)、系統(tǒng)的通用性，這得益于這種設(shè)計(jì)的抽象級(jí)別比較高。它可以描述任何的組織、個(gè)體、他們的地址信息、他們之間的關(guān)系。特別是對(duì)會(huì)員“relationship”表的設(shè)計(jì)非常類似于《分析模式》中談到的責(zé)任模式：

因此，如果你面臨組織結(jié)構(gòu)比較復(fù)雜的業(yè)務(wù)場景時(shí)，比如群組、聯(lián)系人、個(gè)人、公司都可以成為系統(tǒng)的用戶，又或者一個(gè)非常大的跨國公司，擁有：總部、區(qū)域銷售辦公室、辦事處、分公司等各種組織形式時(shí)，這種設(shè)計(jì)就會(huì)派上用場。

數(shù)據(jù)庫表的繼承關(guān)系

從PARTY、PARTY_TYPE、PARTY_GROUP、PERSON這幾張表我們可以學(xué)習(xí)到數(shù)據(jù)庫表的“繼承”設(shè)計(jì)。

時(shí)效性設(shè)計(jì)

不是真刪除、也不是邏輯刪除、而是失效（FROM_DATE, THUR_DATE）。這種方式可以代替“操作-操作歷史”的多表設(shè)計(jì)，轉(zhuǎn)而合并為獨(dú)立的一張表。

原文發(fā)布時(shí)間為：2014-12-07
本文作者：vinoYang
本文來自云棲社區(qū)合作伙伴CSDN博客，了解相關(guān)信息可以關(guān)注CSDN博客。

總結(jié)

以上是生活随笔為你收集整理的谈Apache OFbiz 会员模块表结构设计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。