第一范式：

對于表中的每一行，必須且僅僅有唯一的行值.在一行中的每一列僅有唯一的值并且具有原子性.

（第一范式是通過把重復的組放到每個獨立的表中，把這些表通過一對多關聯聯系起來這種方式來消除重復組的。）

第二范式：

第二范式要求非主鍵列是主鍵的子集，非主鍵列活動必須完全依賴整個主鍵。主鍵必須有唯一性的元素,一個主鍵可以由一個或更多的組成唯一值的列組成。一旦創建，主鍵無法改變，外鍵關聯一個表的主鍵。主外鍵關聯意味著一對多的關系.

（第二范式處理冗余數據的刪除問題。當某張表中的信息依賴于該表中其它的不是主鍵部分的列的時候，通常會違反第二范式。）

第三范式：

第三范式要求非主鍵列互不依賴.

（第三范式規則查找以消除沒有直接依賴于第一范式和第二范式形成的表的主鍵的屬性。我們為沒有與表的主鍵關聯的所有信息建立了一張新表。每張新表保存了來自源表的信息和它們所依賴的主鍵。）

第四范式：

第四范式禁止主鍵列和非主鍵列一對多關系不受約束

（）

第五范式：

第五范式將表分割成盡可能小的塊，為了排除在表中所有的冗余.
（）

在數據庫設計時，大家應該時刻的注意到這幾個范式。 其中第五范式是最難實現的。但是，還是需要盡量的去實現這些功能。

posted @ 2005-04-30 14:07 空中的風月 閱讀(12126) 評論(29)  編輯 收藏 網摘

 

發表評論

  回復  引用  查看    

#1樓 2005-04-30 16:29 | mikespook     

理想和現實總是有差距的，有時為了節約成本或加快速度，我們不得不違反這些理想的東西~~~

  回復  引用  查看    

#2樓 [樓主]2005-04-30 16:57 | Jackie     

這個是當然的，成本與最好效果本來就是相互矛盾的。

  回復  引用  查看    

#3樓 2005-05-02 17:22 | 聽棠.NET     

我的數據庫設計一般都會考慮到第三范式的，但有一個很現實的違反第三范式的例子，這可能是其他的朋友要注意的。
在進銷存系統中，訂單信息中關聯到好多其他的基本信息，比如：客戶，付款方式，貨運方式等，這些信息是有專門表進行維護的，在下訂單時也是用下拉框選擇的，但在保存訂單信息時，不能只記錄所謂的外鍵ID，而是應該同時記錄名稱等其他的信息。
這是因為訂單不能因為沒有了客戶ID或是付款方式ID而不知道客戶與付款方式了。對于訂單這種客觀存在的事物，是具有一定的歷史性質的，因此在設計時應該與其他的關聯信息可以“斷開”，這也就是保證了訂單的獨立性。
但比如訂單類型就可以直接關聯ID，因為它是與訂單這個事物時時關聯的，里面的奧妙，大家要在日常的設計中去體會。

  回復  引用  查看    

#4樓 2005-05-03 16:55 | tongtkk     

對于,聽棠.NET先生說的問題,一般能通過制度來完善,而不是由電腦本身進行完善.

對于很多的管理軟件,制度是很重要的. 不然就沒有"實施"概念了. 大家以為呢?

同時,歡迎你來看我的作品. 謝謝

  回復  引用  查看    

#5樓 2005-05-08 13:00 | 聽棠.NET     

@tongtkk :
制度？？聽你說到這個所謂的“制度”，那我就明白你是反對我的意見的，你可能還是在設想著用所謂的“制度”來控制這種問題，但比如貨運地址吧，你是不是認為在刪除時要進行一下判斷，也就是在訂單中使用過的就不能刪除？？
那么這批訂單由于時間問題，要移出數據庫進行備份了，結果在這時可以刪除貨運地址，然后有一天客戶想看以前移出的備份數據了，導回來后發現貨運地址沒有了。。。一片驚嘆。。。
我的思想很簡單，要是在實際的業務中，是以實物型式存在的，那么這類東西應該具有一定的“獨立性”，這個“獨立性”就跟現實中的單據一樣，不會因為其他基本數據的丟失而無效，真是由于這種實物存在，也就是具有了一定的“歷史性”，因此違反所謂的“第三范式”也是理所應當的。

  回復  引用  查看    

#6樓 2005-05-08 13:37 | tongtkk     

對于你說的備份問題，我表示不能理解，因為數據庫備份不可能只是備份某一個表的數據，而是需要備份很多表的。當然，如果你只是想把這些備份數據存儲在別的地方時，你也可能把備份表里的數據去掉第三范式。（這里特殊情況，因為這樣設計的目的是為了程序服務，而對于程序沒有太大關系的數據，你可以保留自己的想法）。

  回復  引用  查看    

#7樓 2005-05-08 16:28 | 聽棠.NET     

哎，怎么說你呢：“別把無知當個性”，沒有貶義，你挺愛思考的，這一點我很欣賞你。
數據庫設計之“有時不得不違背的第三范式”

 

  回復  引用  查看    

#8樓 [樓主]2005-05-08 17:18 | Jackie     

對于貴作的《數據庫設計之“有時不得不違背的第三范式”》
中寫的很多東西，這本身不存在著違反第三范式的問題，但是你在這里一定要把它拉進來。

比如客戶，付款條款，貨運方式等中，其中客戶是比較重要的角色，當然需要進行分表表達。而付款條款等，只有有一定的條件的情況下，才有可能出現分表的問題。而貨運方式就沒有必要。因為數據與分表基本起不了太多的作用。

第三范式要理解為：訂單與付款方式有一定的關系嗎？　訂單與貨運方式有一定的關系嗎？　如果沒有，就不會違反第三范式。

對于你在上文中不禮貌的寫法，表示強烈反對。如果下次再出現，將刪除你在我這里發表的資料。請注意用詞！

  回復  引用  查看    

#9樓 2005-06-01 17:02 | 漁家傲     

實際上聽棠.NET先生把數據錄入和數據存儲搞混淆了。
當下訂單出現不存在的客戶，付款方式，貨運方式時，程序應自動提供統一的界面供新增客戶，付款方式，貨運方式等內容，注意這只是界面的統一（訂單數據和客戶，付款方式，貨運方式在一個界面上），但是寄存儲時應將客戶，付款方式，貨運方式等內容存到各自的表中（客戶表，付款方式表，貨運方式表）。訂單標僅保存新增的客戶id，付款方式id，貨運方式id。所以并不違反第三范式。

  回復  引用  查看    

#10樓 2005-06-09 20:28 | chen     

表是否可從1 NF范式直接導出3 NF范式

  回復  引用  查看    

#11樓 2005-06-10 18:34 | 簡單生活     

大家可能誤解聽棠描述的應用情況了。

實際上聽棠說的違反第三范式的情況是必須存在的。

以訂單中引用客戶的送貨地址為例，一年前客戶的訂單上的送貨地址就應該是客戶一年前的送貨地址，不能因為客戶現在搬家了，送貨地址改變。然后連一年前的訂單上的送貨地址都變成最新地址，這顯然是不合理的。

所以說，類似于象送貨地址這樣的應用很多，是不是違反三范我不清楚，反正應用上就得這么做。

  回復  引用  查看    

#12樓 2005-06-19 00:17 | peter     

If you put delivery address to order table, and you never update it with customer's new address, on the surface, you achieve what you want in your sample, but this will cause another problem sometimes. Give you another example: the customer ordered last week and the delivery is ready to go, but the customer told us yesterday his address is changed. Do you still need the addess? I am sure you will. If you do, then this means you have another rule to decide when to update customer's address, if update, how many addresses in orders table you need to update?

In real applications, there are many ways to deal this. One way is to store "the address" in order table, this address means "the address at the time order placing". Over the time, a customer may have many addresses, but in your system, you can decide how you store these addresses. The solution you provide above is to store "address history" in your order table. It all depends on the system, sometimes, it's cost effective doing this way, but sometimes other systems cannot do this way.

Third Normal Form is a guideline to help developers to reduce redundancy. If you say your system is against third normal form, then I am sure this redundancy comes with a cost.

Peter

  回復  引用  查看    

#13樓 2005-06-21 09:23 | tongtkk     

范式主要的目的是為了使數據庫更加合理化，而不是給數據庫或者業務的一個桎郜。即它是要我們注意方面的事情，而不是因為這個而把業務實現變更了。因此，希望大家注意。 一個東西決對的合適與不合適，只要合業務流程，讓軟件做的更加合理，這就是最好的。

  回復  引用  查看    

#14樓 2005-06-24 08:49 | JOAN     

R(A,B,C,D,E)中，FD=（A—>B,A->C,(C,D)->E）。
問此關系符合第幾范式，請分解。

  回復  引用    

#15樓 2005-07-15 16:01 | 評 [未注冊用戶]

廣東話來講，那個鬼佬說的很有道理，真不知道他看得懂中文，為什么就寫E文呢。聽棠的說法反映的是一種情況，但是他對于3NF的理解本身就變形了，頂！

  回復  引用    

#16樓 2005-08-24 14:23 | 尹青山 [未注冊用戶]

在討論這個問題時，首先要弄清應用范式的目標，再考慮為了這些目標應該怎樣使用范式。

范式目標之一：邏輯正確。例如，經理管理部門信息，人事管理員工。如果采用范式分成“部門”“員工”主子2表，人事管理員工時，只能為員工指定現在存在的合法部門ID。如果不采用范式，部門和員工的信息在一個表中，管理員工時，就可能因為人事疏忽、或程序不完善為員工指定了一個錯誤、不存在的部門名稱。或者同一個部門，在不同的記錄中，簡稱一樣，名稱卻不一樣等等。這樣，公司的部門就被搞亂套了。范式化的數據模型具有健壯性，能夠抵御一定程度的人為和程序的疏忽，保證數據的完整性。

在實際業務邏輯中，會遇到前面幾位提到的例子，是否需要保存冗余的歷史信息，也就是范式中最關鍵的詞匯“依賴”是否在發生變動時永遠都能夠成立。否則，就不是“依賴”，不用范式。就這個送貨地址變更例子而言，怎樣看待這個“依賴”成立，可以站在不同的角度上，短時間段內，還是系統的全壽命內，得出的結論自然不同，每個人的不同觀點在自己的角度上看都是對的，但是最終還是要看業務規則是否要這個“依賴”。

范式目標之二：成本、代價、"cost"。當初制定范式時的代價和現在的代價含義已經大不相同。那時存儲是稀缺資源，需要各種手段節約存儲（Y2K問題就是一個佐證）。但是現在，存儲是極廉價的（無論大機還是微機，擴內存和硬盤的代價遠低于升級CPU或升主頻），而時間和程序員是稀缺資源。采用范式最大的好處是節約存儲，但壞處是做某些復雜查詢時，需要高級的程序員寫出極復雜的多級關聯查詢語句。我曾經為一個范式系統寫過一條select查詢語句，僅一句（含多次關聯、集合等操作）就有近2000字長，如果在DOS下整個一屏幕都顯示不下，天哪！這種典型的范式系統浪費了最稀缺的資源：技術員、開發時間、運行時的等候時間，而且這樣的程序的維護性幾乎是0。

另外一個考慮因素是后來引出來的。原來的系統多是OLTP，面向交易處理，插入、刪除、修改操作占多。有實踐工作經驗的人都知道，在這樣的范式系統中，要做靈活復雜的報表有多么痛苦，就算是有各種智能輔助報表工具也是令人遺憾。而現在的系統，決策、分析占了很重要的角色，如果要問數據庫倉庫的分析工具為什么能夠快速做出各種復雜的分析？關鍵就是非范式化。但是我們設計的每個系統都能夠使用OLTP加一個數據庫倉庫這種配置嗎？顯然不現實，在系統中實現一定的非范式化，可以簡化查詢、報表的工作，豐富其功能。

非范式系統的最大的問題是數據的一致性，DBMS的KEY & FKEY幫不上忙了，就需要額外的機制來保證。怎樣權衡，還需要實踐，就不是一次能夠講清楚的了。

  回復  引用    

#17樓 2005-11-20 20:12 | zxprzxpr [未注冊用戶]

初學范式，看了各位大俠的討論，我想請教一個小小的問題
，不知對否？


有一道題目：
班號 學號 姓名 性別 課號 課名 學時 成績 考試時間
2 93 zhang 女 01 英語 23 98 12。23
2 94 liu 男 04 物理 34 70 12。30

逐步滿足各個范式：

我是這樣寫的，不知道有問題嗎？好像第二范式也同時滿足了第三范式？？？

第一范式：（滿足原子性）
學號（key） 班號 姓名 性別 課號 課名 學時 成績 考試時間

第二范式（非主屬性完全依賴候選關鍵字）
學員信息表：學號(key) 班號 姓名 性別
課程信息表：課號(key) 課名 學時
成績表： 課號(key) 成績 考試時間

  回復  引用    

#18樓 2005-11-25 00:13 | tongtkk [未注冊用戶]

上面的關系來看，第三范式已經能實現了。因為三個表的各自沒有相互關系。第四范式也實現了。因為主鍵與非主鍵一對多關系受到約束。基本沒有問題。而第五范式可以實現，已經分解到最低層了。

  回復  引用    

#19樓 2005-12-21 11:08 | cai8845218 [未注冊用戶]

違反范式是否可以簡化查詢？如：訂單系統：為統計某城市某客戶定貨的某產品總量，設有以下表：
〔客戶〕－－客戶名稱，客戶id，所在城市
〔訂單〕－－客戶id，訂單號碼
〔訂單明細〕－－訂單號碼，產品id，定貨數量
請問是否在〔訂單明細〕中加入（所在城市）字段，統計全部定貨數量是否更方便？

  回復  引用  查看    

#20樓 2006-05-07 17:44 | 月色瘋狂     

@聽棠.NET
你說的那種情況并不是必須違反3nf。關鍵在于，你沒有抽象出歷史版本的概念。只要在訂單中引用客戶資料的歷史版本，就不存在什么必須違反3nf的問題。
我認為這個問題在于設計時對業務概念理解不清。
你需要引用的是客戶資料的歷史信息，而不是客戶現在的信息。

  回復  引用  查看    

#21樓 2006-05-07 17:45 | 月色瘋狂     

@zxprzxpr
還是不夠好，主鍵應該用無意義的字段。比如用sql server的自動生成的主鍵。

  回復  引用  查看    

#22樓 2007-04-09 13:57 | yunhuasheng     

@月色瘋狂
說得對。

  回復  引用    

#23樓 2007-10-08 16:06 | 聽棠.NET@SB [未注冊用戶]

聽棠.NET 簡直就是個白吃,居然還裝高人,SB

  回復  引用    

#24樓 2007-10-19 09:24 | abcd [未注冊用戶]

哎，怎么說你呢：“別把無知當個性”，沒有貶義，你挺愛思考的，這一點我很欣賞你。對于聽棠.NET的這句回復我真是莫名其妙，世上沒有絕對正確的東西，殺豬還各有殺法呢！寫了幾篇文章就覺得了不起了呀，要在公司里我早就讓這種人走人了！

  回復  引用  查看    

#25樓 2008-07-15 20:26 | OK_008     

追求的就是第五范式

  回復  引用    

#26樓 2008-08-05 14:17 | YYX [未注冊用戶]

我完全明白聽棠是指什么。
其實只要把貨運之類的信息獨立成單獨的表，由人員和訂單分別引用就完全不會出現聽棠所說的問題

  回復  引用    

#27樓 2008-08-24 13:55 | MarsGe [未注冊用戶]

哈哈，討論的結果，大家終于明白了，3nf是否可以完全遵守。
其實沒遵守3nf的原因是設計者不想或自認為沒辦法遵守或系統其它要求(非業務的，如性能)，才放棄3nf。

對于第5范式去應用那些存儲這10億、100億行數據的表應該比較合適，不只大家是否認同

  回復  引用  查看    

#28樓 2008-10-06 17:35 | RandomLife     

我也認為有時候設計的稍微冗余一些能夠極大的提高性能。
但冗余的代價往往是需要程序去保證數據的一致性，需要空間去保存冗余的數據。
這個需要平衡一下。
討論歸討論，不必大動肝火，傷了和氣……

  回復  引用    

#29樓 2008-10-30 09:44 | 海浪0924 [未注冊用戶]

我比較同意16樓的觀點，其實做表的連接是非常消耗系統資源的，所以有時必要的數據冗余是需要存在的。