不時有那句話嗎：“濃縮的都是精華”！

在后面的文章中，您會陸續看到浩浩蕩蕩的設計實例連篇累牘，卻都是利用這四種基本模式設計出來的。《易傳·系辭》曰：“易有太極，是生兩儀，兩儀生四象，四象生八卦。”老子在《道德經》中也說：“道生一，一生二，二生三，三生萬物。”

設計模式不必多，只要掌握其中關鍵的幾個，再結合實際的業務需求，一個完整的數據庫模型就可以推導出來。

===============================================================================================

下面讓我們來逐一介紹這四種主要設計模式：

（一）主擴展模式

主擴展模式，通常用來將幾個相似的對象的共有屬性抽取出來，形成一個“公共屬性表”；其余屬性則分別形成“專有屬性表”，且“公共屬性表”與“專有屬性表”都是“一對一”的關系。

“專有屬性表”可以看作是對“公共屬性表”的擴展，兩者合在一起就是對一個特定對象的完整描述，故此得名“主擴展模式”。

舉例如下（注：這個例子已經作了相當程度的簡化，僅僅是用來幫助大家理解“主擴展模式”這個概念來使用的，請大家注意）。

假設某公司包括如下6種類型的工作人員：采購員、營銷員、庫房管理員、收銀員、財務人員和咨詢專家，采用主擴展模式進行設計，如下圖所示。

無論哪種類型的工作人員，都要訪問公司的辦公軟件，所以都有“登陸代碼”和“登錄密碼”；并且作為一般屬性，“姓名”、“性別”、“身份證號”、“入職時間”、“離職時間”等屬性，都與個人所從事的工作崗位無關，所以可以抽取出來作為公共屬性，創建“公司員工”表。

很顯然，公司委派員工采購哪些商品是“采購員”的專有屬性，這是由公司的實際業務特點決定的。換句話說，公司不可能把采購任務放到“營銷員”身上，也不可能放到“庫房管理員”身上，“采購商品”屬性就是“采購員”的專用屬性。

“采購員”表的主鍵與“公司員工”表的主鍵是相同的，包括字段名稱和字段的實際取值；“采購員”表的主鍵同時是“公司員工”表主鍵的外鍵。在PDM圖里可以看到“采購員”表中的“員工ID”字段后面有一個“

”標記，這個標記就說明“員工ID”字段既是“采購員”表的主鍵，同時也是該表的外鍵。

“公司員工”表是主表，“采購員”表是擴展表，二者是“一對一”的關系，兩個表的字段合起來就是對“采購員”這個對象的完整說明。同理，“公司員工”表和其他5個表之間也都分別構成了“一對一”的關系。

對于主表來說，從表既可以沒有記錄，也可以有唯一一條記錄來對主表進行擴展說明，這就是“主擴展模式”。

（二）主從模式

主從模式，是數據庫設計模式中最常見、也是大家日常設計工作中用的最多的一種模式，它描述了兩個表之間的主從關系，是典型的“一對多”關系。

舉例如下（注：這個例子已經作了相當程度的簡化，僅僅是用來幫助大家理解“主從模式”這個概念來使用的，請大家注意）。

比如論壇程序。一個論壇通常都會有若干“板塊”，在每個板塊里面，大家可以發布很多的新帖。這時候“板塊”和“發帖”就是主從模式，主表是“板塊”，從表是“發帖”，二者是“一對多”的關系。

多個潛水員也可以對感興趣的同一份發帖進行回復，以表達各自的意見，這時候，一個“發帖”就有了多份“回復”，又構成了一個“主從模式”。

（三）名值模式

名值模式，通常用來描述在系統設計階段不能完全確定屬性的對象，這些對象的屬性在系統運行時會有很大的變更，或者是多個對象之間的屬性存在很大的差異。

舉例如下（注：這個例子已經作了相當程度的簡化，僅僅是用來幫助大家理解“名值模式”這個概念來使用的，請大家注意）。

1. 使用名值模式進行設計時，如果對“其他屬性”僅作瀏覽保存、不作其它任何特殊處理，則通常會設計一個“屬性模板”表，該表的數據記錄在系統運行時動態維護。

系統運行時，如需維護“產品其他屬性”，可先從“屬性模板”中選擇一個屬性名稱，然后填寫“屬性值”保存，系統會將對應的產品ID、屬性模板ID及剛剛填寫的“屬性值”一起保存在“產品其他屬性”里，這樣就完成了相關設置。無論產品的其他屬性需求發生怎樣的變化、怎樣增刪改屬性，都可以在運行時實現，而不必修改數據庫設計和程序代碼。（見下圖）

2. 使用名值模式進行設計時，如果對“其他屬性”有特殊處理，比如統計匯總，那么這個屬性名稱需要在程序代碼中作“硬編碼”，即該屬性名稱需要在程序代碼中有所體現，此時可以在“產品其他屬性”表中直接記錄“屬性名稱”，不再需要“屬性模板”表。

系統運行時，如需維護“產品其他屬性”，程序直接列出“屬性名稱”，然后填寫“屬性值”保存，系統會將對應的產品ID、屬性名稱及剛剛填寫的“屬性值”一起保存在“產品其他屬性”里，這樣就完成了相關設置。以后如果需求發生變更，則只需修改相應的程序代碼即可，不必修改數據庫設計。（見下圖）

（四）多對多模式

多對多模式，也是比較常見的一種數據庫設計模式，它所描述的兩個對象不分主次、地位對等、互為一對多的關系。對于A表來說，一條記錄對應著B表的多條記錄，反過來對于B表來說，一條記錄也對應著A表的多條記錄，這種情況就是“多對多模式”。

“多對多模式”需要在A表和B表之間有一個關聯表，這個關聯表也是“多對多模式”的核心所在。根據關聯表是否有獨立的業務處理需求，可將其劃分為兩種細分情況。

1. 關聯表有獨立的業務處理需求。

舉例如下（注：這個例子已經作了相當程度的簡化，僅僅是用來幫助大家理解“多對多模式”這個概念來使用的，請大家注意）。

比如網上書店，通常都會有“書目信息”和“批發單”。一條“書目信息”面對不同的購買客戶、可以存在多張“批發單”，反過來，一張“批發單”也可以批發多條書目，這就是多對多模式。中間的“批發單明細”表就是兩者的關聯表，具備獨立的業務處理需求，是一個業務實體對象，因此它具備一些特有的屬性，比如針對每一條明細記錄而言的“累計退貨次數”、“累計退貨數量”、“累計結算次數”、“累計結算數量”；由于批發單明細在數據產生后已經打印出紙質清單提供給客戶，因此在“批發單明細”表里對紙質清單中打印的書目信息屬性作了冗余（逆標準化），這樣在將來即使修改了“書目信息”表中的屬性，也不會影響跟客戶核對批發單明細，不會影響未來的財務結算業務。

2. 關聯表沒有獨立的業務處理需求

舉例如下（注：這個例子已經作了相當程度的簡化，僅僅是用來幫助大家理解“多對多模式”這個概念來使用的，請大家注意）。

比如用戶與角色之間的關系，一般系統在做權限控制方面的程序時都會涉及到“系統用戶表”和“系統角色表”。一個用戶可以從屬于多個角色，反過來一個角色里面也可以包含多個用戶，兩者也是典型的“多對多關系”。其中的關聯表“用戶角色關聯表”在絕大多數情況下都是僅僅用作表示用戶與角色之間的關聯關系，本身不具備獨立的業務處理需求，所以也就沒有什么特殊的屬性。

（五）使用上述四種模式的一般原則

1. 什么時候用“主擴展模式”？

對象的個數不多；各個對象之間的屬性有一定差別；各個對象的屬性在數據庫設計階段能夠完全確定；各個擴展對象有獨立的、相對比較復雜的業務處理需求，此時用“主擴展模式”。將各個對象的共有屬性抽取出來設計為“主表”，將各個對象的剩余屬性分別設計為相應的“擴展表”，“主表”與各個“擴展表”分別建立一對一的關系。

2. 什么時候用“主從模式”？

對象的個數較多且不固定；各個對象之間的屬性幾乎沒有差異；對象的屬性在數據庫設計階段能夠完全確定；各個對象沒有獨立的業務處理需求，此時用“主從模式”。將各個對象設計為“從表”的記錄，與“主表”對象建立一對多的關系。

3. 什么時候用“名值模式”？

對象的個數極多；各個對象之間的屬性有較大差異；對象屬性在數據庫設計階段不能確定，或者在系統運行時有較大變更；各個對象沒有相互獨立的業務處理需求，此時用“名值模式”。

4. 什么時候用“多對多模式”？

兩個對象之間互為一對多關系，則使用“多對多模式”。

數據庫物理模型設計的其他模式

除了上面提到的四種主要設計模式，還有一些其他模式，在某些項目中可能會用到，在這里先簡單做個說明，暫不做深入討論，等到以后的項目用到這些模式的時候，再結合實際需求詳細解說。

（一）繼承模式

繼承模式，可以看作是“主從模式”的一種特殊情況（或者說是“變形”），它所代表的兩個對象也是“一對多”的關系。它與“主從模式”的區別是，“繼承模式”中從表的主鍵是復合主鍵，并且復合主鍵中必定包含主表的主鍵列。

根據從表繼承主表的列的數量，繼承模式又分以下兩種情況：

1. 從表繼承主表的全部列

在這種情況下，從表除了代表自身的專用字段以外，還冗余了主表的全部字段。這種設計方式的缺點顯而易見：

數據冗余度大

一致性差

磁盤存儲量大

它的優點也顯而易見：

正因為它的冗余度大、所以它不易丟失數據。假設主表數據丟失、或者被誤操作刪改，也能依據從表數據重新生成主表數據；這種設計方式，可以在發生數據損壞的時候從應用的角度進行一定程度的數據恢復，等于是在SQL Server數據庫級別的數據恢復功能之上又加了一道保險。

正因為它一致性差、主表數據被重復存儲，所以可依據外鍵關系進行數據驗證。將主從表記錄作關聯比較，如果數據不一致，就可以得知數據要么被人為改動，或者要么程序代碼中存在bug。

盡管磁盤存儲量大，但是數據在查詢統計的時候，只需針對從表進行搜索即可，無需關聯操作，可以加快檢索的速度。這就是數據庫模型設計中經常提到的“以空間換時間”。

2. 從表只繼承主表的主鍵列

這種設計方式，從表只繼承了主表的主鍵列，這種方式的優缺點與前面剛好相反。

優點：

數據冗余度小

一致性高

磁盤存儲量小

缺點：

正因為它的冗余度小、所以它易丟失數據。假設主表數據丟失、或者被誤操作刪改，就只能通過SQL Server數據庫級別的數據恢復操作來找回丟失的數據了。

正因為它一致性高，所以無法進行應用程序級的數據驗證。

由于采用了一致性設計，磁盤存儲量較小，但是數據在查詢統計的時候，必須要對兩個表進行內連接（INNER JOIN）操作，才能搜索到相關數據。而內連接操作時需要耗費一定的時間的。這就是數據庫模型設計中經常提到的“以時間換空間”。

當然，在實際的數據庫模型設計過程中，還會有介于上述兩者之間的第3種情況出現，那就是從表繼承了主表的主鍵列以及部分其他列。這就要求我們設計人員要依據實際的業務需求進行綜合分析、權衡、折中，給出最符合業務需求的設計結果。

（二）自聯結模式

自聯結模式，也可以看作是“主從模式”的一種特殊情況（或者說是“變形”），它在一張表內實現了“一對多關系”，并且可以根據業務需要實現“有限層”或者“無限層”的主從嵌套。

這種模式用得最多的情況就是實現“樹形結構”數據的存儲，比如各大網站上常見的細分類別、應用系統的組織結構、Web系統的菜單樹等都能用到這種模式。

自聯結模式有很多變體，且每種變體的優缺點同樣鮮明。由于本連載的重點在于對跨行業通用數據庫模型設計進行分析，所以對每種具體模式的細節方面的設計技巧不能作詳細論述，請大家原諒。這里僅舉兩個例子說明：

1. 簡單自聯結

簡單自聯結，就是在一個表里設置當前類ID、父類ID，同時規定最頂層類的父類ID為一個固定值（比如0），在生成樹的時候使用遞歸算法，記錄的前后順序通過“排序號”字段來確定。

這個表用來存儲菜單樹很方便。首先會有一個主菜單，主菜單下有子菜單，子菜單下面又有孫菜單……菜單的數量不確定、層級不確定，用戶可以在任意菜單下增加新的子菜單，或者刪除某個子菜單及其下的所有孫菜單……這種設計方式很多人都會用到，短小精悍、維護方便、且完全滿足用戶需求，而且樹的層次不限，擴展起來非常容易。這些都是它的優點。

它的缺點就是樹結構的生成由于使用了遞歸算法，必然要對該表進行多次讀取（讀取的次數 = 表內的記錄數 – 最深層級的記錄數），多次讀取就來了比較低的運行效率，當表里的記錄很多的時候，這個缺點可以稱得上是致命的。

于是就有了下面的這種設計模式。

2. 擴展自聯結

擴展自聯結，與簡單自聯結的最大區別就是通過附加冗余字段來避免遞歸運算，所要實現的主要目標就是一次讀取就能生成整個樹，一次提高樹的生成效率。

但是，魚與熊掌不可兼得，凡事都有兩面性。

生成樹的效率提高了，增刪改表內記錄的算法就會相應復雜，并且樹的層數也變為有限的了。

所以在此類設計的時候，大家還是要認真分析業務需求，看看實際業務的重點在什么地方，然后再作具體設計。比如一些門戶網站在首頁顯示產品類別是業務重點，那么我們在設計的時候就要盡可能的提高生成樹的效率，采取擴展自聯結模式；相反，一些基于Web的業務系統，要求對菜單樹的增刪改維護操作盡量簡單，由于菜單的數目不多，所以菜單樹的生成效率不是瓶頸，那么我們設計的時候就可以采取簡單自聯結模式。

關于附加冗余字段實現擴展自聯結的方法很多，網上也有很多這方面的帖子，大家可以到Google上搜一下。

在這里僅舉一個例子如下：

這個設計與前面的設計最大的區別就是排序字段，前面的簡單自聯結用了一個整數型的字段來實現排序，這里用了一個型的字段“層級代碼”來實現大排序。這個字段的取值兩位一組，代表一層，假定最深為5層，初始值為。

按照這樣的設計，表內的數據記錄可能就是這樣的：

ID

1 根類別 0 000000

2 類別1 1 010000

3 類別1.1 2 010100

4 類別1.2 2 010200

5 類別2 1 020000

6 類別2.1 5 020100

7 類別3 1 030000

8 類別3.1 7 030100

9 類別3.2 7 030200

10 類別1.1.1 3 010101

……

現在按字段進行排序，執行如下SQL語句：SELECT * FROM ORDER BY

列出記錄集如下：

ID

1 總類別 0 000000

2 類別1 1 010000

3 類別1.1 2 010100

10 類別1.1.1 3 010101

4 類別1.2 2 010200

5 類別2 1 020000

6 類別2.1 5 020100

7 類別3 1 030000

8 類別3.1 7 030100

9 類別3.2 7 030200

……

在控制顯示類別的層次時，只要對“層級代碼”字段中的數值進行判斷，每2位一組，如大于0則向右移2個空格。

Altium Designer的元件庫

Altium 的元件庫

1、AD自帶的兩個基本庫

原理圖和PCB封裝庫可以合成不可編輯的集成庫

點擊AD軟件界面最右下角的 Panels 按鈕（有的版本是點擊上方windows ），激活和兩個窗口。得到如圖3所示的AD一般窗口布局，最左邊是工程窗口，中間是主窗口，最右邊是元件庫窗口。

圖3 AD一般使用的窗口布局

加載和使用現成元件庫的方法如圖4所示：

（1）點擊1所示的，激活 窗口，通過2所示的Install就可以選擇元件庫文件進行加載，這與通常軟件操作方法無異。

（2）點擊3可以選擇已加載的不同元件庫，同時在下方的搜索欄可以搜索具體元件，可以使用*通配符。

（3）區域4中是元件庫中的元件列表，直接點擊選中具體元件，就可以拖放到主窗口的原理圖或PCB圖窗口使用。

（4）區域5展示是元件的原理圖符號，區域6顯示元件的模型參數，例如三極管bce對應123引腳排列。

（5）區域7中點擊2D/3D按鈕可以切換顯示元件PCB封裝和3D模型

圖4 元件庫窗口的使用方法

如圖5所示為 Devices的195種元件名稱。結合圖4，可以發現以下特點：

（1）涵蓋大部分通用元件，如電阻、電容、二極管、三極管。

（2）集成電路較少。

（3）原理圖符號標準，但對應PCB封裝未必與用戶實際使用一致。

（3）3D模型比較粗糙。

結論：原理圖符號部分可copy，pcb封裝需檢查后進一步加工。

圖5 Devices的195種元件

如圖6所示為 連接器庫的兩類典型元件。

圖6 庫的幾種典型元件

連接器庫中最有用的就是各種標準間距（例如2.54mm/100mil）的排針。如圖7所示，特別注意看清雙列排針的引腳順序以及間距。而非排針的連接器的PCB引腳尺寸大部分與用戶實際使用有差異，難以直接使用。

圖7 不同引腳順序和引腳間距的雙列排針元件

2、AD10配套的集合廠商元件庫

雖然AD自帶的兩個元件庫中幾乎沒有芯片類元件，但是AD公司另外提供了芯片廠商的元件庫供下載，其中最全面的是一個針對AD10發布的，各大元器件廠商的集成庫壓縮包下載。如圖8所示為下載頁面，特別注意紅框中的一句話“frozen ”，這代表這個集成庫壓縮包不會再更新了。

3、AD官網維護的廠商元件庫

如圖10所示，AD的官網也提供實時更新維護的廠商元件庫。

但是，我們只在用到具體器件時，才去查找下載使用。這是因為這個實時元件庫不僅按器件廠商分類，而且同一廠商還細分了產品類別，如圖11所示，難以提前全部下載。

圖11 細分類別的廠商庫文件

4、元件廠商提供的元件模型及轉換方法

如果以上3類庫還不能解決問題，我們還可以從元器件廠商處獲取具體元件的封裝。由于EDA軟件有非常多種，所以元器件廠商通常不會給出所有EDA軟件的庫，而是提供通用的封裝文件。這樣一來就需要格式轉換軟件，下面以BXL格式封裝文件為例，講解如何獲取AD元件庫。

如圖12所示，在TI官網搜索，找到質量與封裝選項。

圖12 的官網資料頁

在圖13所示的芯片的符號和封裝下載頁面，bxl為元件封裝文件，stp為3D模型。stp文件的使用方法我們后面課程會單獨講解。這里先下載bxl文件并安裝讀取器軟件Ultra 。

圖13 芯片的符號和封裝下載頁面

（1）從TI的鏈接中下載免費的Ultra ，并安裝。安裝過程中有勾選項都勾上，如圖14所示。

圖14 Ultra 軟件

（2）如圖15所示，點擊使用免費版本。

圖15 Ultra 軟件安裝選項

使用Ultra 軟件轉換元件模型分三步：

（1）如圖16所示，在Ultra 軟件中點擊Load Data，加載TI網站上下載的元件bxl文件。

圖16 加載bxl文件

（2）參考圖17，勾選目標格式Altium

（3）點擊輸出Export to Tools。

圖17 Ultra 軟件加載和轉換模型

如圖18所示，轉換完成后自動打開一個read.txt說明文檔。在文檔提示的存儲位置（時間文件夾）獲得幾個有用文件。

圖18 Ultra 軟件生成的各種文件

接下來是用AD轉換識別Ultra 軟件生成的腳本。

（1）用AD打開圖18所示的.Prjscr工程文件。然后，雙擊其中的.pas文件，如圖19所示。

圖19 AD打開Ultra 軟件生成的腳本

（2）如圖20所示，運行腳本

圖20 AD運行Ultra 軟件生成的腳本

（3）參考圖21，運行腳本后，選擇日期.txt文件，導入。

圖21 UL Import窗口

（4）得到如圖22所示的AD格式的庫工程文件。

圖22 最終獲得的AD格式的庫文件

接下來可以查看獲得的庫文件。

（1）點擊Panel->SCH Library查看原理圖庫，如圖23所示，原理圖庫里有一個默認待編輯元件，還有一個5部件的28377D的原理圖符號。復雜功能或包含多個相同單元的元件原理圖往往設計成多部件元件。

圖23 原理圖庫中默認的待編輯元件

（2）點擊Panel->PCB Library查看PCB封裝庫，如圖24所示，官方的PCB封裝的焊盤往往會有大中小三種規格供用戶選擇。后綴N普通，M肥大，L細小。

圖24 PCB封裝庫中默認的待編輯元件

5、將外部庫添加進自己的庫

分離的SCH Library和PCB Library直接可編輯，其中的元件都可以很方便的復制粘貼，一般情況下直接使用這兩種庫就可以正常設計電路。而IntLib可以類比是“壓縮文件”，對其操作需要先進行“解壓縮”。

下面舉例說明如何新建庫，并添加已有庫文件元件模型（比如上小節獲得的庫）。

（1）如圖25所示，分別新建集成庫工程、原理圖庫文件、PCB庫文件。

圖25 新建集成庫工程、原理圖庫文件、PCB庫文件

（2）如圖26所示，將新建的SchLib文件和PcbLib文件拖入集成庫工程。并能夠熟練切換工程文件：Panel->Project、Panel->SCH Library、Panel->PCB Library。

圖26 包含原理圖庫和PCB庫的集成庫工程目錄

（3）如圖27所示，原理圖庫和PCB庫都默認有一個待編輯元件

圖27 原理圖庫和PCB庫默認的待編輯元件

（4）如圖28所示，從已有SchLib庫中復制元件（可同時復制多個），此處用的就是上小節原理圖庫。

圖28 復制元件原理圖

（5）如圖29所示，在自建的SchLib庫中粘貼元件。

圖29 粘貼元件原理圖

（6）如圖30所示，從已有PCBLib庫中復制元件（可同時復制多個），此處用的就是上小節的PCB庫。選中多個PCB封裝進行復制。

圖30 復制元件PCB封裝

（7）如圖31所示，在自建庫中粘貼，會有提示是粘貼3個元件。

圖31 粘貼元件PCB封裝

（8）如圖32所示，在合適位置保存集成庫工程及子文件，自行取名，例如mylib。

圖32 保存自建的集成庫

如何復制集成庫中的元件？

（1）先用AD直接打開集成庫文件，得到如圖33所示的提示，按默認選項點OK。

圖33 集成庫extract窗口

（2）將集成庫extract后就可以和前面一樣操作其中的元件，如圖34為AD自帶的連接器 集成庫extract后的文件結構。

圖34 連接器集成庫extract后的文件結構

如何合成集成庫？

（1）一般情況下，分別使用Sch Library和PCB Library即可，兩者都可以直接編輯。有需要，也可將集成庫工程中的兩個文件SchLib和PcbLib合稱為IntLib。

（2）如圖35所示，在集成庫工程文件LibPkg上點擊右鍵菜單，第一個選項就是合成集成庫。

如圖35 合成集成庫的步驟及其輸出位置

推薦瀏覽

我們在畫PCB板子時也會遇到一些基礎硬件知識，除了查看相關數據百度外，我推薦可以去牛客網（點擊可直達）看看，內容很豐富，屬于國內做的很好的了，里面的資源全部免費，有布局布線的知識點補充也有PCB板制作的知識補充等。