不時有那句話嗎:“濃縮的都是精華”!
在后面的文章中,您會陸續看到浩浩蕩蕩的設計實例連篇累牘,卻都是利用這四種基本模式設計出來的。《易傳·系辭》曰:“易有太極,是生兩儀,兩儀生四象,四象生八卦。”老子在《道德經》中也說:“道生一,一生二,二生三,三生萬物。”
設計模式不必多,只要掌握其中關鍵的幾個,再結合實際的業務需求,一個完整的數據庫模型就可以推導出來。
===============================================================================================
下面讓我們來逐一介紹這四種主要設計模式:
(一)主擴展模式
主擴展模式,通常用來將幾個相似的對象的共有屬性抽取出來,形成一個“公共屬性表”;其余屬性則分別形成“專有屬性表”,且“公共屬性表”與“專有屬性表”都是“一對一”的關系。
“專有屬性表”可以看作是對“公共屬性表”的擴展,兩者合在一起就是對一個特定對象的完整描述,故此得名“主擴展模式”。
舉例如下(注:這個例子已經作了相當程度的簡化,僅僅是用來幫助大家理解“主擴展模式”這個概念來使用的,請大家注意)。
假設某公司包括如下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板制作的知識補充等。
*請認真填寫需求信息,我們會在24小時內與您取得聯系。