原始單據與實體的關係 可以是一對一、一對多、多對多的關係。在一般情況下，它們是一對一的關係：即一張原始單據對應且只對應一個實體。 在特殊情況下，它們可能是一對多或多對一的關係，即一張原始單證對應多個實體，或多張原始單證對應一個實體。
1. 原始單據與實體之間的關係
可以是一對一、一對多、多對多的關係。在一般情況下，它們是一對一的關係：即一張原始單據對應且只對應一個實體。
在特殊情況下，它們可能是一對多或多對一的關係，即一張原始單證對應多個實體，或多張原始單證對應一個實體。
這裡的實體可以理解為基本表。明確這種對應關係後，對我們設計錄入介面大有好處。
〖例1〗：一份員工履歷資料，在人力資源資訊系統中，就對應三個基本表：員工基本狀況表、社會關係表、工作履歷表。
這就是「一張原始單證對應多個實體」的典型例子。
2. 主鍵與外鍵
一般而言，一個實體不能既無主鍵又無外鍵。在E—R 圖中, 處於葉子部位的實體, 可以定義主鍵，也可以不定義主鍵
(因為它無子孫), 但必須要有外鍵(因為它有父親)。
主鍵與外鍵的設計，在全域資料庫的設計中，佔有重要地位。當全局資料庫的設計完成以後，有個美國資料庫設計專
家說：“鍵，到處都是鍵，除了鍵之外，什麼也沒有”，這就是他的資料庫設計經驗之談，也反映了他對資訊系統核子
心(資料模型)的高度抽象思想。因為：主鍵是實體的高度抽象，主鍵與外鍵的配對，表示實體之間的連結。
3. 基本表的性質
基本表與中間表、臨時表不同，因為它具有以下四個特性：
(1) 原子性。基本表中的欄位是不可再分解的。
(2) 原始性。基本表中的記錄是原始資料（基礎資料）的記錄。
(3) 演繹性。由基本表與程式碼表中的數據，可以衍生出所有的輸出資料。
(4) 穩定性。基本表的結構是相對穩定的，表中的記錄是要長期保存的。
理解基本表的性質後，在設計資料庫時，就能將基本表與中間表、臨時表區分開來。
4. 範式標準
基本表及其欄位之間的關係, 應盡量滿足第三範式。但是，滿足第三範式的資料庫設計，往往不是最好的設計。
為了提高資料庫的運作效率，常常需要降低範式標準：適當增加冗餘，達到以空間換時間的目的。
〖例2〗：有一張存放商品的基本表，如表1所示。 「金額」這個欄位的存在，表示該表的設計不符合第三範式，
因為「金額」可以由「單價」乘以「數量」得到，說明「金額」是冗餘欄位。但是，增加「金額」這個冗餘字段，
可以提高查詢統計的速度，這就是以空間換時間的作法。
在Rose 2002中，規定列有兩種：資料列和計算列。 “金額”這樣的列稱為“計算列”，而“單價”和
“數量”這樣的列被稱為“資料列”。
表1 商品表的表結構
商品名稱商品型號單價數量金額
電視機29吋2,500 40 100,000
5. 通俗地理解範式
##5.
通俗地理解三個範式，對於資料庫設計大有好處。在資料庫設計中，為了更好地應用三個範式，就必須通俗地理解
三個範式(通俗地理解是夠用的理解，並不是最科學最準確的理解)： 第一範式
：1NF是對屬性的原子性約束，要求屬性具有原子性，不可再分解； 第二範式
：2NF是對記錄的惟一性約束，要求記錄有惟一標識，即實體的惟一性；
第三範式：3NF是對字段冗餘性的約束，即任何字段不能由其他字段派生出來，它要求字段沒有冗餘。
沒有冗餘的資料庫設計可以做到。但是，沒有冗餘的資料庫未必是最好的資料庫，有時為了提高運作效率，就必須降
低範式標準，適當保留冗餘資料。具體做法是：在概念資料模型設計時遵守第三範式，降低範式標準的工作放到實體
資料模型設計時考慮。降低範式就是增加字段，允許冗餘。
6. 要善於辨識與正確處理多對多的關係
若兩個實體之間存在多對多的關係，則應消除這種關係。消除的辦法是，在兩者之間增加第三個實體。這樣，原來一 ### 個多對多的關係，現在變成兩個一對多的關係。要將原來兩個實體的屬性合理地分配到三個實體。這裡的第三個
實體，實質上是一個較複雜的關係，它對應一張基本表。一般來講，資料庫設計工具不能辨識多對多的關係，但能處
理多對多的關係。
〖例3〗：在「圖書館資訊系統」中，「圖書」是一個實體，「讀者」也是一個實體。這兩個實體之間的關係，是一
個典型的多對多關係：一本圖書在不同時間可以被多個讀者藉閱，一個讀者又可以藉多本圖書。為此，要在二者之
間增加第三個實體，該實體取名為“借還書”，它的屬性為：借還時間、借還標誌(0表示借書，1表示還書)，另外，
它還應該有兩個外鍵(“圖書”的主鍵，“讀者”的主鍵)，使它能與“圖書”和“讀者”連接。
7. 主鍵PK的取值方法
PK是給程式設計師使用的表間連接工具，可以是一無物理意義的數字字串, 由程式自動加1來實現。也可以是有物理意義
的欄位名稱或欄位名稱的組合。不過前者比後者好。當PK是欄位名稱的組合時，建議欄位的數量不要太多，多了不但索引
佔用空間大，而且速度也慢。
8. 正確認識資料冗餘
主鍵與外鍵在多表中的重複出現, 不屬於資料冗餘，這個概念必須清楚，事實上有許多人還不清楚。非鍵字段的重
復出現, 才是資料冗餘！而且是一種低級冗餘，即重複性的冗餘。高級冗餘不是字段的重複出現，而是字段的派生出現。
〖例4〗：商品中的「單價、數量、金額」三個字段，「金額」就是由「單價」乘以「數量」派生出來的，它就是冗餘，
而且是一種高級冗餘。冗餘的目的是為了提高處理速度。只有低階冗餘才會增加數據的不一致性，因為相同數據，可
能從不同時間、地點、角色上多次輸入。因此，我們提倡高階冗餘(派生性冗餘)，反對低級冗餘(重複性冗餘)。
9. E--R圖沒有標準答案
資訊系統的E--R圖沒有標準答案，因為它的設計與畫法不是惟一的，只要它涵蓋了系統需求的業務範圍和功能內容，
就是可行的。反之要修改E--R圖。儘管它沒有惟一的標準答案，並不代表可以隨意設計。好的E—R 圖的標準是：
結構清晰、關聯簡潔、實體個數適中、屬性分配合理、沒有低級冗餘。
10 . 視圖技術在資料庫設計中很有用
與基本表、程式碼表、中間表不同，視圖是一種虛表，它依賴資料來源的實表而存在。視圖是供程式設計師使用資料庫的
一個窗口，是基表資料綜合的一種形式, 是資料處理的一種方法，是使用者資料保密的一種手段。為了進行複雜處理、
提高運算速度和節省儲存空間, 視圖的定義深度一般不得超過三層。 若三層視圖仍不夠用, 則應在視圖上定義臨時表,
在臨時表上再定義視圖。這樣反覆交迭定義, 視圖的深度就不受限制了。
對於某些與國家政治、經濟、技術、軍事和安全利益有關的資訊系統，視野的作用更為重要。這些系統的基本表完
成物理設計之後，立即在基本表上建立第一層視圖，這層視圖的個數和結構，與基本表的個數和結構是完全相同。
並且規定，所有的程式設計師，一律只准在視圖上操作。只有資料庫管理員，帶著多個人員共同掌握的“安全鑰匙”，
才能直接在基本表上操作。請讀者想想：這是為什麼？
11. 中間表、報表和臨時表
中間表是存放統計資料的表，它是為資料倉儲、輸出報表或查詢結果而設計的，有時它沒有主鍵與外鍵(資料倉
庫除外)。臨時表是程式設計師個人設計的，存放臨時記錄，為個人所用。基底表和中間表由DBA維護，臨時表由程式設計師
自己用程式自動維護。
12. 完整性約束表現在三個面向
域的完整性：用Check來實現約束，在資料庫設計工具中，對欄位的取值範圍進行定義時，有一個Check按鈕，通
過它定義欄位的值城。
參照完整性：用PK、FK、表級觸發器來實現。
使用者定義完整性：它是一些業務規則，用預存程序和觸發器來實現。
13. 防止資料庫設計打補丁的方法是「三少原則」
(1) 一個資料庫中表格的個數越少越好。只有表的個數少了，才能說明系統的E--R圖少而精，去掉了重複的多餘的
實體，形成了對客觀世界的高度抽象，進行了系統的數據集成，防止了打補丁式的設計;
(2) 一個表格中組合主鍵的欄位數量越少越好。因為主鍵的作用，一是建主鍵索引，二是做為子表的外鍵，所以組
合主鍵的字段個數少了，不僅節省了運行時間，而且節省了索引存儲空間；
(3) 一個表格中的欄位個數越少越好。只有字段的個數少了，才能說明在系統中不存在資料重複，且很少有資料冗餘
餘，更重要的是督促讀者學會“列變行”，這樣就防止了將子表中的欄位拉入到主表中去，在主表中留下許
多餘餘餘的欄位。所謂“列變行”，就是將主表中的一部分內容拉出去，另外單獨建造一個子表。這個方法很簡
單，有的人就是不習慣、不採納、不執行。
資料庫設計的實用原則是：在資料冗餘和處理速度之間找到合適的平衡點。 「三少」是一個整體概念，綜合觀點，
不能孤立某一個原則。該原則是相對的，不是絕對的。 「三多」原則肯定是錯的。試想：若覆蓋系統同樣的功
能，一百個實體(共一千個屬性) 的E--R圖，肯定比二百個實體(共二千個屬性) 的E--R圖，好得多。
提倡「三少」原則，是叫讀者學會利用資料庫設計技術進行系統性的資料整合。資料整合的步驟是將檔案系統整合
為應用資料庫，將應用資料庫集成為主題資料庫，將主題資料庫集成為全域綜合資料庫。整合的程度越高，資料
共享性就越強，資訊孤島現象就越少，整個企業資訊系統的全局E—R圖中實體的個數、主鍵的個數、屬性的個數
就會越少。
提倡“三少”原則的目的，是防止讀者利用打補丁技術，不斷地對數據庫進行增刪改，使企業數據庫變成了隨意
設計數據庫表的“垃圾堆”，或數據庫表的“大雜院”，最後造成資料庫中的基本表、代碼表、中間表、臨時表
雜亂無章，不計其數，導致企事業單位的資訊系統無法維護而癱瘓。
「三多」原則任何人都可以做到，該原則是「打補丁方法」設計資料庫的歪理學說。 「三少」原則是少而精的
原則，它要求有較高的資料庫設計技巧與藝術，不是任何人都能做到的，因為該原則是杜絕用「打補丁法」
設計資料庫的理論基礎。
14. 提高資料庫運作效率的方法
在給定的系統硬體和系統軟體條件下，提高資料庫系統的運作效率的方法是：
(1 ) 在資料庫實體設計時，降低範式，增加冗餘, 少用觸發器, 多用預存程序。
(2) 當計算非常複雜、而且記錄條數非常巨大時(例如一千萬條)，複雜計算要先在資料庫外面，以檔案系統方
式用C++語言計算處理完成之後，最後才入庫追加到表中去。這是電信計費系統設計的經驗。
(3) 發現某個表格的記錄太多，例如超過一千萬條，則要對該表進行水平分割。水平分割的做法是，以該表主鍵
PK的某個值為界線，將該表的記錄水平分割為兩個表。若發現某個表格的欄位太多，例如超過八十個，則
垂直分割該表，將原來的一個表分解為兩個表。
(4) 對資料庫管理系統DBMS進行系統最佳化，即最佳化各種系統參數，如緩衝區個數。
(5) 使用資料導向的SQL語言進行程式設計時，盡量採取最佳化演算法。
總之，要提高資料庫的運作效率，必須從資料庫系統層級最佳化、資料庫設計級最佳化、程式實現等級最佳化，這三
個層次同時下功夫。
上述十四個技巧，是許多人在大量的資料庫分析與設計實務中，逐步總結出來的。對於這些經驗的運用，讀者不能生幫硬套，死記硬背，而要消化理解，實事求是，靈活掌握。並逐步做到：在應用中發展，在發展中應用。
下面再來看看其他原則：
1)不應該針對整個系統進行資料庫設計，而應該根據系統架構中的元件劃分，針對每個元件所處理的業務進行元件單元的資料庫設計；不同元件間所對應的資料庫表之間的關聯應盡可能減少，如果不同組件間的表需要外鍵關聯也盡量不要創建外鍵關聯，而只是記錄關聯表的一個主鍵，確保組件對應的表之間的獨立性，為系統或表結構的重構提供可能性。
2)採用領域模型驅動的方式和自頂向下的思路進行資料庫設計，首先分析系統業務，依照職責定義物件。物件要符合封裝的特性，確保與職責相關的資料項被定義在一個物件之內，這些資料項能夠完整描述該職責，不會出現職責描述缺失。且一個物件有且只有一項職責，如果一個物件要負責兩個或兩個以上的職責，應進行分拆。
3)根據建立的領域模型進行資料庫表的映射，此時應參考資料庫設計第二範式：一個表中的所有非關鍵字屬性都依賴整個關鍵字。關鍵字可以是一個屬性，也可以是多個屬性的集合，不論那種方式，都應確保關鍵字能保證唯一性。在確定關鍵字時，應確保關鍵字不會參與業務且不會出現更新異常，這時，最優解決方案為採用一個自增數值型屬性或一個隨機字串作為表的關鍵字。
4)由於第一點所述的領域模型驅動的方式設計資料庫表結構，領域模型中的每一個物件只有一項職責，所以物件中的資料項不存在傳遞依賴，所以，這種想法的資料庫表結構設計從一開始即滿足第三範式：一個表應滿足第二範式，且屬性間不存在傳遞依賴。
5)同樣，由於對象職責的單一性以及對象之間的關係反映的是業務邏輯之間的關係，所以在領域模型中的對象存在主對象和從對象之分，從對象是從1－N或N－N的角度進一步主對象的業務邏輯，所以從對象及對象關係映射為的表及表關聯關係不存在刪除和插入異常。
6)在映射後得出的資料庫表結構中，應再根據第四範式進行進一步修改，確保不存在多值依賴。這時，應根據反向工程的思路回饋給領域模型。如果表結構中存在多值依賴，則證明領域模型中的物件具有至少兩個以上的職責，應根據第一條進行設計修正。第四範式：一個表格如果滿足BCNF，不應存在多值依賴。
7)在經過分析後確認所有的表都滿足二、三、四範式的情況下，表和表之間的關聯盡量採用弱關聯以便於對錶字段和表結構的調整和重構。並且，我認為資料庫中的表是用來持久化一個物件實例在特定時間及特定條件下的狀態的，只是一個儲存介質，所以，表和表之間也不應用強關聯來表述業務（資料間的一致性），此職責應由系統的邏輯層來保證，這種方式也確保了系統對於不正確資料（髒資料）的兼容性。當然，從整個系統的角度來說我們還是要盡最大努力確保系統不會產生髒數據，單從另一個角度來說，髒數據的產生在一定程度上也是不可避免的，我們也要確保系統對這種情況的容錯性。這是一個折衷的方案。
8)應針對所有資料表的主鍵和外鍵建立索引，有針對性的（針對一些大資料量和常用檢索方式）建立組合屬性的索引，提高檢索效率。雖然建立索引會消耗部分系統資源，但比較起在檢索時搜尋整張表中的資料尤其時表中的資料量較大時所帶來的效能影響，以及無索引時的排序操作所帶來的效能影響，這種方式仍然是值得提倡的。
9)盡量少採用預存程序，目前已經有很多技術可以取代預存程序的功能如「物件/關聯映射」等，將資料一致性的保證放在資料庫中，無論對於版本控制、開發和部署、以及資料庫的遷移都會帶來很大的影響。但不可否認，儲存過程具有效能上的優勢，所以，當系統可使用的硬體不會得到提升而效能又是非常重要的品質屬性時，可經過平衡考慮選用預存程序。
10)當處理表間的關聯約束所付出的代價（常常是使用性上的代價）超過了保證不會出現修改、刪除、更改異常所付出的代價，並且資料冗餘也不是主要的問題時，表格設計可以不符合四個範式。四個範式確保了不會出現異常，但也可能由此導致過於純潔的設計，使得表結構難於使用，所以在設計時需要進行綜合判斷，但首先確保符合四個範式，然後再進行精化修正是剛進入資料庫設計領域時可以採用的最好方法。
11)設計出的表格要具有較好的使用性，主要體現在查詢時是否需要關聯多張表格且還需使用複雜的SQL技巧。
12)設計出的表格要盡可能減少資料冗餘，確保資料的準確性，有效的控制冗餘有助於提高資料庫的效能。 (當然有時候必須降低範式)
【相關推薦】
#1. 特別推薦：「php程序員工具箱」V0.1版本下載
3. 資料庫設計那些事
以上是歸納資料庫設計的原則的詳細內容。更多資訊請關注PHP中文網其他相關文章！
