woaidongmao

第一范式：

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

（第一范式是通過(guò)把重復(fù)的組放到每個(gè)獨(dú)立的表中，把這些表通過(guò)一對(duì)多關(guān)聯(lián)聯(lián)系起來(lái)這種方式來(lái)消除重復(fù)組的。）

第二范式：

第二范式要求非主鍵列是主鍵的子集，非主鍵列活動(dòng)必須完全依賴整個(gè)主鍵。主鍵必須有唯一性的元素,一個(gè)主鍵可以由一個(gè)或更多的組成唯一值的列組成。一旦創(chuàng)建，主鍵無(wú)法改變，外鍵關(guān)聯(lián)一個(gè)表的主鍵。主外鍵關(guān)聯(lián)意味著一對(duì)多的關(guān)系.

（第二范式處理冗余數(shù)據(jù)的刪除問(wèn)題。當(dāng)某張表中的信息依賴于該表中其它的不是主鍵部分的列的時(shí)候，通常會(huì)違反第二范式。）

第三范式：

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

（第三范式規(guī)則查找以消除沒(méi)有直接依賴于第一范式和第二范式形成的表的主鍵的屬性。我們?yōu)闆](méi)有與表的主鍵關(guān)聯(lián)的所有信息建立了一張新表。每張新表保存了來(lái)自源表的信息和它們所依賴的主鍵。）

第四范式：

第四范式禁止主鍵列和非主鍵列一對(duì)多關(guān)系不受約束

（）

第五范式：

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

在數(shù)據(jù)庫(kù)設(shè)計(jì)時(shí)，大家應(yīng)該時(shí)刻的注意到這幾個(gè)范式。 其中第五范式是最難實(shí)現(xiàn)的。但是，還是需要盡量的去實(shí)現(xiàn)這些功能。

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

 

發(fā)表評(píng)論

  回復(fù)  引用  查看    

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

理想和現(xiàn)實(shí)總是有差距的，有時(shí)為了節(jié)約成本或加快速度，我們不得不違反這些理想的東西~~~

  回復(fù)  引用  查看    

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

這個(gè)是當(dāng)然的，成本與最好效果本來(lái)就是相互矛盾的。

  回復(fù)  引用  查看    

#3樓 2005-05-02 17:22 | 聽(tīng)棠.NET     

我的數(shù)據(jù)庫(kù)設(shè)計(jì)一般都會(huì)考慮到第三范式的，但有一個(gè)很現(xiàn)實(shí)的違反第三范式的例子，這可能是其他的朋友要注意的。
在進(jìn)銷存系統(tǒng)中，訂單信息中關(guān)聯(lián)到好多其他的基本信息，比如：客戶，付款方式，貨運(yùn)方式等，這些信息是有專門表進(jìn)行維護(hù)的，在下訂單時(shí)也是用下拉框選擇的，但在保存訂單信息時(shí)，不能只記錄所謂的外鍵ID，而是應(yīng)該同時(shí)記錄名稱等其他的信息。
這是因?yàn)橛唵尾荒芤驗(yàn)闆](méi)有了客戶ID或是付款方式ID而不知道客戶與付款方式了。對(duì)于訂單這種客觀存在的事物，是具有一定的歷史性質(zhì)的，因此在設(shè)計(jì)時(shí)應(yīng)該與其他的關(guān)聯(lián)信息可以“斷開”，這也就是保證了訂單的獨(dú)立性。
但比如訂單類型就可以直接關(guān)聯(lián)ID，因?yàn)樗桥c訂單這個(gè)事物時(shí)時(shí)關(guān)聯(lián)的，里面的奧妙，大家要在日常的設(shè)計(jì)中去體會(huì)。

  回復(fù)  引用  查看    

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

對(duì)于,聽(tīng)棠.NET先生說(shuō)的問(wèn)題,一般能通過(guò)制度來(lái)完善,而不是由電腦本身進(jìn)行完善.

對(duì)于很多的管理軟件,制度是很重要的. 不然就沒(méi)有"實(shí)施"概念了. 大家以為呢?

同時(shí),歡迎你來(lái)看我的作品. 謝謝

  回復(fù)  引用  查看    

#5樓 2005-05-08 13:00 | 聽(tīng)棠.NET     

@tongtkk :
制度？？聽(tīng)你說(shuō)到這個(gè)所謂的“制度”，那我就明白你是反對(duì)我的意見(jiàn)的，你可能還是在設(shè)想著用所謂的“制度”來(lái)控制這種問(wèn)題，但比如貨運(yùn)地址吧，你是不是認(rèn)為在刪除時(shí)要進(jìn)行一下判斷，也就是在訂單中使用過(guò)的就不能刪除？？
那么這批訂單由于時(shí)間問(wèn)題，要移出數(shù)據(jù)庫(kù)進(jìn)行備份了，結(jié)果在這時(shí)可以刪除貨運(yùn)地址，然后有一天客戶想看以前移出的備份數(shù)據(jù)了，導(dǎo)回來(lái)后發(fā)現(xiàn)貨運(yùn)地址沒(méi)有了。。。一片驚嘆。。。
我的思想很簡(jiǎn)單，要是在實(shí)際的業(yè)務(wù)中，是以實(shí)物型式存在的，那么這類東西應(yīng)該具有一定的“獨(dú)立性”，這個(gè)“獨(dú)立性”就跟現(xiàn)實(shí)中的單據(jù)一樣，不會(huì)因?yàn)槠渌緮?shù)據(jù)的丟失而無(wú)效，真是由于這種實(shí)物存在，也就是具有了一定的“歷史性”，因此違反所謂的“第三范式”也是理所應(yīng)當(dāng)?shù)摹?/span>

  回復(fù)  引用  查看    

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

對(duì)于你說(shuō)的備份問(wèn)題，我表示不能理解，因?yàn)閿?shù)據(jù)庫(kù)備份不可能只是備份某一個(gè)表的數(shù)據(jù)，而是需要備份很多表的。當(dāng)然，如果你只是想把這些備份數(shù)據(jù)存儲(chǔ)在別的地方時(shí)，你也可能把備份表里的數(shù)據(jù)去掉第三范式。（這里特殊情況，因?yàn)檫@樣設(shè)計(jì)的目的是為了程序服務(wù)，而對(duì)于程序沒(méi)有太大關(guān)系的數(shù)據(jù)，你可以保留自己的想法）。

  回復(fù)  引用  查看    

#7樓 2005-05-08 16:28 | 聽(tīng)棠.NET     

哎，怎么說(shuō)你呢：“別把無(wú)知當(dāng)個(gè)性”，沒(méi)有貶義，你挺愛(ài)思考的，這一點(diǎn)我很欣賞你。
數(shù)據(jù)庫(kù)設(shè)計(jì)之“有時(shí)不得不違背的第三范式”

 

  回復(fù)  引用  查看    

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

對(duì)于貴作的《數(shù)據(jù)庫(kù)設(shè)計(jì)之“有時(shí)不得不違背的第三范式”》
中寫的很多東西，這本身不存在著違反第三范式的問(wèn)題，但是你在這里一定要把它拉進(jìn)來(lái)。

比如客戶，付款條款，貨運(yùn)方式等中，其中客戶是比較重要的角色，當(dāng)然需要進(jìn)行分表表達(dá)。而付款條款等，只有有一定的條件的情況下，才有可能出現(xiàn)分表的問(wèn)題。而貨運(yùn)方式就沒(méi)有必要。因?yàn)閿?shù)據(jù)與分表基本起不了太多的作用。

第三范式要理解為：訂單與付款方式有一定的關(guān)系嗎？　訂單與貨運(yùn)方式有一定的關(guān)系嗎？　如果沒(méi)有，就不會(huì)違反第三范式。

對(duì)于你在上文中不禮貌的寫法，表示強(qiáng)烈反對(duì)。如果下次再出現(xiàn)，將刪除你在我這里發(fā)表的資料。請(qǐng)注意用詞！

  回復(fù)  引用  查看    

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

實(shí)際上聽(tīng)棠.NET先生把數(shù)據(jù)錄入和數(shù)據(jù)存儲(chǔ)搞混淆了。
當(dāng)下訂單出現(xiàn)不存在的客戶，付款方式，貨運(yùn)方式時(shí)，程序應(yīng)自動(dòng)提供統(tǒng)一的界面供新增客戶，付款方式，貨運(yùn)方式等內(nèi)容，注意這只是界面的統(tǒng)一（訂單數(shù)據(jù)和客戶，付款方式，貨運(yùn)方式在一個(gè)界面上），但是寄存儲(chǔ)時(shí)應(yīng)將客戶，付款方式，貨運(yùn)方式等內(nèi)容存到各自的表中（客戶表，付款方式表，貨運(yùn)方式表）。訂單標(biāo)僅保存新增的客戶id，付款方式id，貨運(yùn)方式id。所以并不違反第三范式。

  回復(fù)  引用  查看    

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

表是否可從1 NF范式直接導(dǎo)出3 NF范式

  回復(fù)  引用  查看    

#11樓 2005-06-10 18:34 | 簡(jiǎn)單生活     

大家可能誤解聽(tīng)棠描述的應(yīng)用情況了。

實(shí)際上聽(tīng)棠說(shuō)的違反第三范式的情況是必須存在的。

以訂單中引用客戶的送貨地址為例，一年前客戶的訂單上的送貨地址就應(yīng)該是客戶一年前的送貨地址，不能因?yàn)榭蛻衄F(xiàn)在搬家了，送貨地址改變。然后連一年前的訂單上的送貨地址都變成最新地址，這顯然是不合理的。

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

  回復(fù)  引用  查看    

#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

  回復(fù)  引用  查看    

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

范式主要的目的是為了使數(shù)據(jù)庫(kù)更加合理化，而不是給數(shù)據(jù)庫(kù)或者業(yè)務(wù)的一個(gè)桎郜。即它是要我們注意方面的事情，而不是因?yàn)檫@個(gè)而把業(yè)務(wù)實(shí)現(xiàn)變更了。因此，希望大家注意。 一個(gè)東西決對(duì)的合適與不合適，只要合業(yè)務(wù)流程，讓軟件做的更加合理，這就是最好的。

  回復(fù)  引用  查看    

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

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

  回復(fù)  引用    

#15樓 2005-07-15 16:01 | 評(píng) [未注冊(cè)用戶]

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

  回復(fù)  引用    

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

在討論這個(gè)問(wèn)題時(shí)，首先要弄清應(yīng)用范式的目標(biāo)，再考慮為了這些目標(biāo)應(yīng)該怎樣使用范式。

范式目標(biāo)之一：邏輯正確。例如，經(jīng)理管理部門信息，人事管理員工。如果采用范式分成“部門”“員工”主子2表，人事管理員工時(shí)，只能為員工指定現(xiàn)在存在的合法部門ID。如果不采用范式，部門和員工的信息在一個(gè)表中，管理員工時(shí)，就可能因?yàn)槿耸率韬?、或程序不完善為員工指定了一個(gè)錯(cuò)誤、不存在的部門名稱?；蛘咄粋€(gè)部門，在不同的記錄中，簡(jiǎn)稱一樣，名稱卻不一樣等等。這樣，公司的部門就被搞亂套了。范式化的數(shù)據(jù)模型具有健壯性，能夠抵御一定程度的人為和程序的疏忽，保證數(shù)據(jù)的完整性。

在實(shí)際業(yè)務(wù)邏輯中，會(huì)遇到前面幾位提到的例子，是否需要保存冗余的歷史信息，也就是范式中最關(guān)鍵的詞匯“依賴”是否在發(fā)生變動(dòng)時(shí)永遠(yuǎn)都能夠成立。否則，就不是“依賴”，不用范式。就這個(gè)送貨地址變更例子而言，怎樣看待這個(gè)“依賴”成立，可以站在不同的角度上，短時(shí)間段內(nèi)，還是系統(tǒng)的全壽命內(nèi)，得出的結(jié)論自然不同，每個(gè)人的不同觀點(diǎn)在自己的角度上看都是對(duì)的，但是最終還是要看業(yè)務(wù)規(guī)則是否要這個(gè)“依賴”。

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

另外一個(gè)考慮因素是后來(lái)引出來(lái)的。原來(lái)的系統(tǒng)多是OLTP，面向交易處理，插入、刪除、修改操作占多。有實(shí)踐工作經(jīng)驗(yàn)的人都知道，在這樣的范式系統(tǒng)中，要做靈活復(fù)雜的報(bào)表有多么痛苦，就算是有各種智能輔助報(bào)表工具也是令人遺憾。而現(xiàn)在的系統(tǒng)，決策、分析占了很重要的角色，如果要問(wèn)數(shù)據(jù)庫(kù)倉(cāng)庫(kù)的分析工具為什么能夠快速做出各種復(fù)雜的分析？關(guān)鍵就是非范式化。但是我們?cè)O(shè)計(jì)的每個(gè)系統(tǒng)都能夠使用OLTP加一個(gè)數(shù)據(jù)庫(kù)倉(cāng)庫(kù)這種配置嗎？顯然不現(xiàn)實(shí)，在系統(tǒng)中實(shí)現(xiàn)一定的非范式化，可以簡(jiǎn)化查詢、報(bào)表的工作，豐富其功能。

非范式系統(tǒng)的最大的問(wèn)題是數(shù)據(jù)的一致性，DBMS的KEY & FKEY幫不上忙了，就需要額外的機(jī)制來(lái)保證。怎樣權(quán)衡，還需要實(shí)踐，就不是一次能夠講清楚的了。

  回復(fù)  引用    

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

初學(xué)范式，看了各位大俠的討論，我想請(qǐng)教一個(gè)小小的問(wèn)題
，不知對(duì)否？


有一道題目：
班號(hào) 學(xué)號(hào) 姓名 性別 課號(hào) 課名 學(xué)時(shí) 成績(jī) 考試時(shí)間
2 93 zhang 女 01 英語(yǔ) 23 98 12。23
2 94 liu 男 04 物理 34 70 12。30

逐步滿足各個(gè)范式：

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

第一范式：（滿足原子性）
學(xué)號(hào)（key） 班號(hào) 姓名 性別 課號(hào) 課名 學(xué)時(shí) 成績(jī) 考試時(shí)間

第二范式（非主屬性完全依賴候選關(guān)鍵字）
學(xué)員信息表：學(xué)號(hào)(key) 班號(hào) 姓名 性別
課程信息表：課號(hào)(key) 課名 學(xué)時(shí)
成績(jī)表： 課號(hào)(key) 成績(jī) 考試時(shí)間

  回復(fù)  引用    

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

上面的關(guān)系來(lái)看，第三范式已經(jīng)能實(shí)現(xiàn)了。因?yàn)槿齻€(gè)表的各自沒(méi)有相互關(guān)系。第四范式也實(shí)現(xiàn)了。因?yàn)橹麈I與非主鍵一對(duì)多關(guān)系受到約束?；緵](méi)有問(wèn)題。而第五范式可以實(shí)現(xiàn)，已經(jīng)分解到最低層了。

  回復(fù)  引用    

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

違反范式是否可以簡(jiǎn)化查詢？如：訂單系統(tǒng)：為統(tǒng)計(jì)某城市某客戶定貨的某產(chǎn)品總量，設(shè)有以下表：
〔客戶〕－－客戶名稱，客戶id，所在城市
〔訂單〕－－客戶id，訂單號(hào)碼
〔訂單明細(xì)〕－－訂單號(hào)碼，產(chǎn)品id，定貨數(shù)量
請(qǐng)問(wèn)是否在〔訂單明細(xì)〕中加入（所在城市）字段，統(tǒng)計(jì)全部定貨數(shù)量是否更方便？

  回復(fù)  引用  查看    

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

@聽(tīng)棠.NET
你說(shuō)的那種情況并不是必須違反3nf。關(guān)鍵在于，你沒(méi)有抽象出歷史版本的概念。只要在訂單中引用客戶資料的歷史版本，就不存在什么必須違反3nf的問(wèn)題。
我認(rèn)為這個(gè)問(wèn)題在于設(shè)計(jì)時(shí)對(duì)業(yè)務(wù)概念理解不清。
你需要引用的是客戶資料的歷史信息，而不是客戶現(xiàn)在的信息。

  回復(fù)  引用  查看    

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

@zxprzxpr
還是不夠好，主鍵應(yīng)該用無(wú)意義的字段。比如用sql server的自動(dòng)生成的主鍵。

  回復(fù)  引用  查看    

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

@月色瘋狂
說(shuō)得對(duì)。

  回復(fù)  引用    

#23樓 2007-10-08 16:06 | 聽(tīng)棠.NET@SB [未注冊(cè)用戶]

聽(tīng)棠.NET 簡(jiǎn)直就是個(gè)白吃,居然還裝高人,SB

  回復(fù)  引用    

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

哎，怎么說(shuō)你呢：“別把無(wú)知當(dāng)個(gè)性”，沒(méi)有貶義，你挺愛(ài)思考的，這一點(diǎn)我很欣賞你。對(duì)于聽(tīng)棠.NET的這句回復(fù)我真是莫名其妙，世上沒(méi)有絕對(duì)正確的東西，殺豬還各有殺法呢！寫了幾篇文章就覺(jué)得了不起了呀，要在公司里我早就讓這種人走人了！

  回復(fù)  引用  查看    

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

追求的就是第五范式

  回復(fù)  引用    

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

我完全明白聽(tīng)棠是指什么。
其實(shí)只要把貨運(yùn)之類的信息獨(dú)立成單獨(dú)的表，由人員和訂單分別引用就完全不會(huì)出現(xiàn)聽(tīng)棠所說(shuō)的問(wèn)題

  回復(fù)  引用    

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

哈哈，討論的結(jié)果，大家終于明白了，3nf是否可以完全遵守。
其實(shí)沒(méi)遵守3nf的原因是設(shè)計(jì)者不想或自認(rèn)為沒(méi)辦法遵守或系統(tǒng)其它要求(非業(yè)務(wù)的，如性能)，才放棄3nf。

對(duì)于第5范式去應(yīng)用那些存儲(chǔ)這10億、100億行數(shù)據(jù)的表應(yīng)該比較合適，不只大家是否認(rèn)同

  回復(fù)  引用  查看    

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

我也認(rèn)為有時(shí)候設(shè)計(jì)的稍微冗余一些能夠極大的提高性能。
但冗余的代價(jià)往往是需要程序去保證數(shù)據(jù)的一致性，需要空間去保存冗余的數(shù)據(jù)。
這個(gè)需要平衡一下。
討論歸討論，不必大動(dòng)肝火，傷了和氣……

  回復(fù)  引用    

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

我比較同意16樓的觀點(diǎn)，其實(shí)做表的連接是非常消耗系統(tǒng)資源的，所以有時(shí)必要的數(shù)據(jù)冗余是需要存在的。