⑴ 理解資料庫中的第一第二第三範式有什麼用誰能告訴我
比如你是班主任，要統計成績了。有以下幾項，考號，姓名，科目號，科目，成績。如果沒有理解第一範式，你就只能這么記錄了：考號2010005001是張三，語文考了80分。但是理解了就不一樣了，你就學會把這條信息抽象為5個屬性了，可以用excel表格統計了！
你在錄入成績的過程中會發現，語文，數學之類的字粘貼了好多遍啊，能不能單獨拿出來啊。當然可以。因為科目名只依賴於科目號，於是你可以把上述信息分成三個表：
考生表：考號（PK） + 姓名
科目表：科目號（PK） + 科目名
成績表：考號（PK） + 科目號（PK） + 成績
簡單的說，第二範式消除了非主屬性對主鍵的部分依賴。
第三範式的話，其實上面這么做就已經是第三範式了。為了便於理解，我們加一列 等級吧。比如60分以下C，60到80是B，80以上是A。
那麼成績表現在是這樣：
成績表：考號（PK） + 科目號（PK） + 成績 + 等級
其實等級成績有關，跟主鍵只有間接的決定關系，主鍵決定成績，成績決定等級，我們需要把它獨立出來。
考生表：考號（PK） + 姓名
科目表：科目號（PK） + 科目名
成績表：考號（PK） + 科目號（PK） + 成績
等級表：等級（PK） + 成績
簡單的說，第三範式消除了非主屬性對主鍵的傳遞依賴。
說了這么多，總結起來一句話：沒啥鳥用。沒上過學的，出來設計的表估計也是滿足第三範式的。
⑵ 第二範式名詞解釋
第二範式(Second Normal Form,2nd NF)是指每個表必須有主關鍵字(Primary key),其他數據元素與主關鍵字一一對應。通常稱這種關系為函數依賴(Functional dependence)關系，即表中其他數據元素都依賴於主關鍵字,或稱該數據元素惟一地被主關鍵字所標識。第二範式是資料庫規范化中所使用的一種正規形式。它的規則是要求數據表裡的所有非主屬性都要和該數據表的主鍵有完全依賴關系；如果有哪些非主屬性只和主鍵的一部份有關的話，它就不符合第二範式。同時可以得出：如果一個數據表的主鍵只有單一一個欄位的話，它就一定符合第二範式(前提是該數據表符合第一範式)
⑶ 資料庫第二範式
第二範式（2NF）和第三範式（3NF）的概念很容易混淆，區分它們的關鍵點在於，2NF：非主鍵列是否完全依賴於主鍵，還是依賴於主鍵的一部分；3NF：非主鍵列是直接依賴於主鍵，還是直接依賴於非主鍵列。
第二範式（2NF）：首先是 1NF，另外包含兩部分內容，一是表必須有一個主鍵；二是沒有包含在主鍵中的列必須完全依賴於主鍵，而不能只依賴於主鍵的一部分。考慮一個訂單明細表OrderDetail其屬性如下： （OrderID，ProctID，UnitPrice，Discount，Quantity，ProctName）。
因為我們知道在一個訂單中可以訂購多種產品，所以單單一個OrderID 是不足以成為主鍵的，主鍵應該是（OrderID，ProctID）。顯而易見 Discount（折扣），Quantity（數量）完全依賴（取決）於主鍵（OderID，ProctID），而 UnitPrice，ProctName 只依賴於 ProctID。所以 OrderDetail 表不符合 2NF。不符合 2NF的設計容易產生冗餘數據。
可以把OrderDetail表拆分為：
OrderDetail（OrderID，ProctID，Discount，Quantity）
Proct （ProctID，UnitPrice，ProctName）
來消除原訂單表中UnitPrice，ProctName多次重復的情況。
第三範式（3NF）：首先是 2NF，另外非主鍵列必須直接依賴於主鍵，不能存在傳遞依賴。即不能存在：非主鍵列 A 依賴於非主鍵列 B，非主鍵列 B 依賴於主鍵的情況。考慮一個訂單表Order： （OrderID，OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity）主鍵是（OrderID）。
其中OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity
等非主鍵列都完全依賴於主鍵（OrderID），所以符合 2NF。
不過問題是CustomerName，CustomerAddr，CustomerCity 直接依賴的是
CustomerID（非主鍵列），而不是直接依賴於主鍵，它是通過傳遞才依賴於主鍵，所以不符合 3NF。
通過拆分Order為Order（OrderID，OrderDate，CustomerID）和Customer（CustomerID，CustomerName，CustomerAddr，CustomerCity）從而達到 3NF。
⑷ 資料庫三大範式通俗理解是什麼
1、第一範式（1NF）：
所謂第一範式（1NF）是指在關系模型中，對於添加的一個規范要求，所有的域都應該是原子性的，即資料庫表的每一列都是不可分割的原子數據項，而不能是集合，數組，記錄等非原子數據項。
即實體中的某個屬性有多個值時，必須拆分為不同的屬性。在符合第一範式（1NF）表中的每個域值只能是實體的一個屬性或一個屬性的一部分。簡而言之，第一範式就是無重復的域。
2、第二範式（2NF）
在1NF的基礎上，非碼屬性必須完全依賴於候選碼（在1NF基礎上消除非主屬性對主碼的部分函數依賴）
第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的，即滿足第二範式（2NF）必須先滿足第一範式（1NF）。第二範式（2NF）要求資料庫表中的每個實例或記錄必須可以被唯一地區分。選取一個能區分每個實體的屬性或屬性組，作為實體的唯一標識。
3、第三範式（3NF）
在2NF基礎上，任何非主屬性不依賴於其它非主屬性（在2NF基礎上消除傳遞依賴）第三範式（3NF）是第二範式（2NF）的一個子集，即滿足第三範式（3NF）必須滿足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個關系中不包含已在其它關系已包含的非主關鍵字信息。
關系模型結構
1、單一的數據結構——關系（表文件）。關系資料庫的表採用二維表格來存儲數據，是一種按行與列排列的具有相關信息的邏輯組，它類似於Excel工作表。一個資料庫可以包含任意多個數據表。在用戶看來，一個關系模型的邏輯結構是一張二維表，由行和列組成。這個二維表就叫關系，通俗地說，一個關系對應一張表。
2、元組（記錄）。表中的一行即為一個元組，或稱為一條記錄。
3、屬性（欄位）。數據表中的每一列稱為一個欄位，表是由其包含的各種欄位定義的，每個欄位描述了它所含有的數據的意義，數據表的設計實際上就是對欄位的設計。創建數據表時，為每個欄位分配一個數據類型，定義它們的數據長度和其他屬性。欄位可以包含各種字元、數字、甚至圖形。
以上內容參考網路——資料庫範式、網路——關系資料庫
⑸ 舉例說明一下怎麼算是第一範式、第二範式、第三範式
1.第一範式：存在非主屬性對碼的部分依賴關系 R(A,B,C) AB是碼 C是非主屬性 B-->C B決定C C部分依賴於B。如果關系R 中所有屬性的值域都是單純域，那麼關系模式R是第一範式的。
那麼符合第一模式的特點就有：有主關鍵字、主鍵不能為空、主鍵不能重復,、欄位不可以再分。例如：
StudyNo | Name | Sex | Contact
20040901 john Male Email:[email protected],phone:222456
20040901 mary famale email:[email protected] phone:123455
以上的表就不符合，第一範式：主鍵重復(實際中資料庫不允許重復的)，而且Contact欄位可以再分
所以變更為正確的是：
StudyNo | Name | Sex | Email | Phone
20040901 john [email protected] 222456
20040902 mary [email protected] 123455
2.第二範式：存在非主屬性對碼的傳遞性依賴 R(A,B,C) A是碼 A -->B ,B-->C。如果關系模式R是第一範式的，而且關系中每一個非主屬性不部分依賴於主鍵，稱R是第二範式的。所以第二範式的主要任務就是：滿足第一範式的前提下，消除部分函數依賴。
StudyNo | Name | Sex | Email | Phone | ClassNo | ClassAddress
01 john [email protected] 222456 200401 A樓2
01 mary [email protected] 123455 200402 A樓3
這個表完全滿足於第一範式,主鍵由StudyNo和ClassNo組成，這樣才能定位到指定行。但是,ClassAddress部分依賴於關鍵字(ClassNo-〉ClassAddress，所以要變為兩個表：
表一
StudyNo | Name | Sex | Email | Phone | ClassNo
01 john [email protected] 222456 200401
01 mary [email protected] 123455 200402
表二
ClassNo | ClassAddress
200401 A樓2
200402 A樓3
3.第三範式
不存在非主屬性對碼的傳遞性依賴以及部分性依賴 ，
StudyNo | Name | Sex | Email | bounsLevel | bouns
20040901 john [email protected] 優秀 $1000
20040902 mary [email protected] 良 $600
這個完全滿足了第二範式,但是bounsLevel和bouns存在傳遞依賴，更改為：
StudyNo | Name | Sex | Email | bouunsNo
20040901 john [email protected] 1
20040902 mary [email protected] 2
bounsNo | bounsLevel | bouns
1 優秀 $1000
2 良 $600
這里可以用bounsNo作為主鍵，基於兩個原因
（1）不要用字元作為主鍵。可能有人說：如果我的等級一開始就用數值就代替呢？
（2）但是如果等級名稱更改了，不叫 1，2 ，3或優、良，這樣就可以方便更改，所以一般優先使用與業務無關的欄位作為關鍵字。
一般滿足前三個範式就可以避免數據冗餘。
(5)對資料庫第二範式理解擴展閱讀：
設計關系資料庫時，遵從不同的規范要求，設計出合理的關系型資料庫，這些不同的規范要求被稱為不同的範式，各種範式呈遞次規范，越高的範式資料庫冗餘越小。
目前關系資料庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、巴斯-科德範式（BCNF）、第四範式(4NF）和第五範式（5NF，又稱完美範式）。
設計關系資料庫時，遵從不同的規范要求，設計出合理的關系型資料庫，這些不同的規范要求被稱為不同的範式，各種範式呈遞次規范，越高的範式資料庫冗餘越小。
目前關系資料庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、巴斯-科德範式（BCNF）、第四範式(4NF）和第五範式（5NF，又稱完美範式）。滿足最低要求的範式是第一範式（1NF）。在第一範式的基礎上進一步滿足更多規范要求的稱為第二範式（2NF），其餘範式以次類推。一般說來，資料庫只需滿足第三範式(3NF）就行了。
參考鏈接：
網路-資料庫範式