--設計正規化指的是可高效的方便擴充資料庫的準則，但實際中也只是作為參考。
實際工作中，設計原則：根據業務盡可能的減少多表查詢。
第一正規化：（單錶）
資料表中的每乙個欄位都不可再分，即都使用標準資料型別，如以下不符合：
create table member(
編號 number,
姓名 varchar2(200),
**** varchar2(200)
);對於****可劃分很多自欄位：如手機，qq,郵箱等，所以不符合第一正規化
可改為：
create table member(
編號 number,
姓名 varchar2(200),
位址 varchar2(200),
郵編 varchar2(20),
手機 varchar2(20),
qq varchar2(20)
);針對第一正規化有兩點**明：
1.如果系統在中國則名字就表示乙個字段，在國外則需要firstname、lastname,不屬於不可再分
2.設計表的時候都使用標準型別（number,varchar2,clob,date）,千萬不要講生日拆分為3個字段
第二正規化：（多對多關係）
資料表中不存在非關鍵字段對任意一后選關鍵字段的部分函式依賴。（說的毛線啊）
個人理解，即：多對多關係
函式關係：總價 = 單價 乘 數量
如：create table orders(
編號 number primary key,
商品名稱 varchar2(200),
單價 number,
數量 number,
總價 number
);依賴關係：
如電影系列，從甲方乙方，到非誠勿擾，到讓子彈飛
從年份、公司、導演，推出電影名稱
從電影、導演 推出唯一的演員，則無法推出
例項：設計乙個學生選課系統，多個學生，多個課程，多對多關係
表設計需要：分為學生表、課程表、選課關係表
第三正規化：（一對多）
資料表之中不存在非關鍵字段對任意一后選關鍵字段的傳遞函式依賴。
sybase powerdesigner
設計階段可以說是以後系統效能的關鍵階段，在這個階段，有乙個關係到以後幾乎所有效能調優的過程—資料庫設計。
在資料庫設計完成後，可以進行初步的索引設計，好的索引設計可以指導編碼階段寫出高效率的**，為整個系統的效能打下良好的基礎。
對於效能要求設計階段，我們需要注意以下幾點：
1、資料庫邏輯設計的規範化
資料庫邏輯設計的規範化就是我們一般所說的正規化，我們可以這樣來簡單理解正規化：
第1規範：沒有重複的組或多值的列，這是資料庫設計的最低要求。
第2規範：每個非關鍵字段必須依賴於主關鍵字，不能依賴於乙個組合式主關鍵字的某些組成部分，消除部分依賴，大部分情況下，資料庫設計都應該達到第二正規化。
第3規範：乙個非關鍵字段不能依賴於另乙個非關鍵字段。消除傳遞依賴，達到第三正規化應該是系統中大部分表的要求，除非一些特殊作用的表。
更高的正規化要求這裡就不再作介紹了，在馬海祥看來，如果全部達到第二正規化，大部分達到第三正規化，系統會產生較少的列和較多的表，因而減少了資料冗餘，也利於效能的提高。
2、合理的冗餘
完全按照規範化設計的系統幾乎是不可能的，除非系統特別的小，在規範化設計後，有計畫地加入冗餘是必要的。
冗餘可以是冗餘資料庫、冗餘表或者冗餘字段，不同粒度的冗餘可以起到不同的作用。
冗餘可以是為了程式設計方便而增加，也可以是為了效能的提高而增加。
從效能角度來說，冗餘資料庫可以分散資料庫壓力，冗餘表可以分散資料量大的表的併發壓力，也可以加快特殊查詢的速度，冗餘字段可以有效減少資料庫表的連線，提高效率。
3、主鍵的設計
主鍵是必要的，sql server的主鍵同時是乙個唯一索引，而且在實際應用中，我們往往選擇最小的鍵組合作為主鍵，所以主鍵往往適合作為表的聚集索引，聚集索引對查詢的影響是比較大的，這個在下面索引的敘述。
在有多個鍵的表，主鍵的選擇也比較重要，一般選擇總的長度小的鍵，小的鍵的比較速度快，同時小的鍵可以使主鍵的b樹結構的層次更少。
主鍵的選擇還要注意組合主鍵的字段次序，對於組合主鍵來說，不同的字段次序的主鍵的效能差別可能會很大，一般應該選擇重複率低、單獨或者組合查詢可能性大的字段放在前面。
4、外來鍵的設計
外來鍵作為資料庫物件，很多人認為麻煩而不用，實際上，外來鍵在大部分情況下是很有用的，理由是：
外來鍵是最高效的一致性維護方法，資料庫的一致性要求，依次可以用外來鍵、check約束、規則約束、觸發器、客戶端程式，一般認為，離資料越近的方法效率越高。
謹慎使用級聯刪除和級聯更新。
這裡說的謹慎，是因為級聯刪除和級聯更新有些突破了傳統的關於外來鍵的定義，功能有點太過強大，使用前必須確定自己已經把握好其功能範圍，否則，級聯刪除和級聯更新可能讓你的資料莫名其妙的被修改或者丟失。
從效能看級聯刪除和級聯更新是比其他方法更高效的方法。
5、欄位的設計
a、資料型別盡量用數字型，數字型的比較比字元型的快很多。
b、資料型別盡量小，這裡的盡量小是指在滿足可以預見的未來需求的前提下的。
c、 盡量不要允許null，除非必要，可以用not null+default代替。
d、少用text和image，二進位製字段的讀寫是比較慢的，而且，讀取的方法也不多，大部分情況下最好不用。
e、自增字段要慎用，不利於資料遷移。
6、資料庫物理儲存和環境的設計
在設計階段，可以對資料庫的物理儲存、作業系統環境、網路環境進行必要的設計，使得我們的系統在將來能適應比較多的使用者併發和比較大的資料量。
這裡需要注意檔案組的作用，適用檔案組可以有效把i/o操作分散到不同的物理硬碟，提高併發能力。
7、系統設計
整個系統的設計特別是系統結構設計對效能是有很大影響的，對於一般的oltp系統，可以選擇c/s結構、三層的c/s結構等，不同的系統結構其效能的關鍵也有所不同。
系統設計階段應該歸納一些業務邏輯放在資料庫程式設計實現，資料庫程式設計包括資料庫儲存過程、觸發器和函式，用資料庫程式設計實現業務邏輯的好處是減少網路流量並可更充分利用資料庫的預編譯和快取功能。
8、索引的設計
在設計階段，可以根據功能和效能的需求進行初步的索引設計，這裡需要根據預計的資料量和查詢來設計索引，可能與將來實際使用的時候會有所區別。
a、根據資料量決定哪些表需要增加索引，資料量小的可以只有主鍵。
b、根據使用頻率決定哪些字段需要建立索引，選擇經常作為連線條件、篩選條件、聚合查詢、排序的字段作為索引的候選字段。
c、把經常一起出現的字段組合在一起，組成組合索引，組合索引的字段順序與主鍵一樣，也需要把最常用的字段放在前面，把重複率低的字段放在前面。
d、乙個表不要加太多索引，因為索引影響插入和更新的速度。
資料庫 資料庫正規化
關聯式資料庫的設計規範。不同的規範要求被稱為不同的正規化，越高的正規化資料庫冗餘越小。減少資料庫中資料冗餘的過程 1 第一正規化 1nf 在關係模式r中，當且僅當所有屬性只包含原子值，即每個分量都是不可再分的資料項，則稱r滿足1nf。例如表所示的教師職稱情況關係就不滿足1nf。原因在於，該關係模式中...
資料庫正規化 三正規化
所謂第一正規化 1nf 是指在關係模型中，對域新增的乙個規範要求，所有的域都應該是原子性的，即資料庫表的每一列都是不可分割的原子資料項，而不能是集合，陣列，記錄等非原子資料項。即實體中的某個屬性有多個值時，必須拆分為不同的屬性。在符合第一正規化 1nf 表中的每個域值只能是實體的乙個屬性或乙個屬性的...
資料庫正規化
注 表在定義中被稱為關係,記作r 欄位在定義中被稱作屬性 模式 資料庫中有三種模式,外模式,內模式,模式 粗體是關鍵字的意思 斜體為外來鍵 以前寫下來的，但是用了多年的帳號已經忘了，唯有把文章轉到這裡來了 真暈哦 http blog.csdn.net fantasylu archive 2004 0...