Ⅰ 數據結構中的1範式，2範式，3範式，bc範式，4範式，5範式。怎麼理解希望解釋的直白些。
這個不是數據結構的內容，屬於資料庫設計的范疇。規范化設計資料庫可以減少數據冗餘，減少數據插入、更新異常。
1範式，2範式，3範式，bc範式，4範式，5範式是規范化標准。
比如：目前的所有商用資料庫設計出來的表至少必須滿足第一範式（1nf：即滿足表的所有屬性都是不能再分解的原子屬性）。
2範式-5範式這些標准多是根據表的屬性間的不同程度的函數依賴（從1nf到5nf逐步提高標准）來區分的。由資料庫設計者把握設計出來的資料庫規范化到什麼程度。理論上滿足的規范化程度越高，設計出來的資料庫越有效、穩定。但有時候考慮到數據查詢、表連接的頻率問題，不得不反規范化，減低滿足的標准才能提高程序執行效率。
簡單的講可以這樣理解：
第一範式：指表中的屬性都是原子屬性，不能再拆分了。
第二範式：在第一範式的基礎上，要求非主屬性都完全函數依賴於主鍵。
第三範式：在第二範式的基礎上，要求要求沒有非主屬性傳遞依賴於主鍵。
BC範式：在第三範式基礎上，要求所有非主鍵屬性都必須依賴於主鍵。
第四範式：在BC範式基礎上，要求表中存在的多值依賴都必須是對主鍵函數依賴。
第五範式：在第四範式的基礎上，繼續拆分表格，消除多值依賴。
在一個表中：
主屬性：所有包含在候選碼里的屬性。
非主屬性：不包含在候選碼里的屬性。
候選碼：一個或者一組可以唯一標識一條記錄且不含多餘屬性的屬性。
函數依賴：表中屬性X的值可以唯一確定Y的值，則說：X確定Y，或Y依賴於X（記作X->Y）。
傳遞依賴：X->Y，Y->Z。則可以說Z傳遞依賴於X。
多值依賴：一個屬性的值可以確定一組屬性。（函數依賴是一種特殊的多值依賴，依賴的整組屬性只有1個，而不是多個）
（例如假設有一個人事資料的數據表，我們根據表中記錄的一個人的姓名，我們可以查到他的年齡即有： 姓名->年齡。在沒有同名存在的情況下，姓名就是這個表的候選鍵（碼），因為姓名可以唯一確定一條記錄的其他屬性，例如：姓名->(性別、年齡、職位)，同時我們把姓名選為該表的主鍵（含主屬性）。姓名以外的其他屬性即為非主屬性。有時候一個表可以有多個候選鍵，則需要選擇其中一組作為主鍵，所有候選鍵包括的屬性都是主屬性。）
以上內容都是根據自己理解信手敲出。並沒有嚴謹的校對教科書的概念。如有疏漏錯誤實屬正常，如有人補漏改錯不勝榮幸。
Ⅱ 資料庫中第一範式，第二範式，第三範式、、、、是什麼，怎麼區分
第一範式：一言以蔽之：「第一範式的數據表必須是二維數據表」，第一範式是指資料庫的每一列都是不可分割的基本數據項，強調列的原子性，試題中某一屬性不能擁有幾個值。比如資料庫的電話號碼屬性裡面不可以有固定電話和行動電話值。 說明：在任何一個關系資料庫中，第一範式（1NF）是對關系模式的基本要求，不滿足第一範式（1NF）的資料庫就不是關系資料庫。
第二範式建立在第一範式的基礎上，即滿足第二範式一定滿足第一範式，第二範式要求數據表每一個實例或者行必須被唯一標識。除滿足第一範式外還有兩個條件，一是表必須有一個主鍵；二是沒有包含在主鍵中的列必須完全依賴於主鍵，而不能只依賴於主鍵的一部分。每一行的數據只能與其中一列相關，即一行數據只做一件事。只要數據列中出現數據重復，就要把表拆分開來。
第三範式若某一範式是第二範式，且每一個非主屬性都不傳遞依賴於該範式的候選鍵，則稱為第三範式，即不能存在：非主鍵列 A 依賴於非主鍵列 B，非主鍵列 B 依賴於主鍵的情況。
(2)資料庫設計5個範式擴展閱讀：
範式是符合某一種級別的關系模式的集合。關系資料庫中的關系必須滿足一定的要求，滿足不同程度要求的為不同範式。
Ⅲ 簡述資料庫的三大範式和五大約束
範式書上講解太拗口，自己總結一下：
第一範式：數據表中的每一列（每個欄位）必須是不可拆分的最小單元,不允許存在隱藏欄位,屬性保持「原子性」（最大細分的二維表）
第二範式：第一範式基礎上要有主鍵，所有列都必須依賴於主鍵，而不能有任何一列與主鍵沒有關系，也就是說一個表只描述一件事情（相當於這行闡述的是一個人時，你不能加一列說明天氣）
第三範式：滿足第二範式，表中的每一列只與主鍵直接相關而不是間接相關，（表中的每一列只能依賴於主鍵）
正規化範式（BCDF）：所有表中的決定因素必須是一個候選鍵，如果只有一個候選鍵，那麼就和第三範式是一樣的。
有第四第五範式，更高的範式是為了解決數據冗餘問題，但可以通過其他辦法達到。所以一般用不到
五大約束：
1. primary KEY :設置主鍵約束；
2. UNIQUE ：設置唯一性約束，不能有重復值；
3. DEFAULT 默認值約束，height DOUBLE(3,2)DEFAULT 1.2 height不輸入是默認為1,2
4. NOT NULL ：設置非空約束，該欄位不能為空；
5. FOREIGN key :設置外鍵約束。
Ⅳ 資料庫的三大範式
1、第一範式（1NF）
所謂第一範式（1NF）是指在關系模型中，對於添加的一個規范要求，所有的域都應該是原子性的，即資料庫表的每一列都是不可分割的原子數據項，而不能是集合，數組，記錄等非原子數據項。
即實體中的某個屬性有多個值時，必須拆分為不同的屬性。在符合第一範式（1NF）表中的每個域值只能是實體的一個屬性或一個屬性的一部分。簡而言之，第一範式就是無重復的域。
說明：在任何一個關系資料庫中，第一範式（1NF）是對關系模式的設計基本要求，一般設計中都必須滿足第一範式（1NF）。
不過有些關系模型中突破了1NF的限制，這種稱為非1NF的關系模型。換句話說，是否必須滿足1NF的最低要求，主要依賴於所使用的關系模型。
2、第二範式（2NF）
在1NF的基礎上，非碼屬性必須完全依賴於候選碼（在1NF基礎上消除非主屬性對主碼的部分函數依賴）
第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的，即滿足第二範式（2NF）必須先滿足第一範式（1NF）。
第二範式（2NF）要求資料庫表中的每個實例或記錄必須可以被唯一地區分。選取一個能區分每個實體的屬性或屬性組，作為實體的唯一標識。
例如在員工表中的身份證號碼即可實現每個一員工的區分，該身份證號碼即為候選鍵，任何一個候選鍵都可以被選作主鍵。
在找不到候選鍵時，可額外增加屬性以實現區分，如果在員工關系中，沒有對其身份證號進行存儲，而姓名可能會在資料庫運行的某個時間重復。
無法區分出實體時，設計辟如ID等不重復的編號以實現區分，被添加的編號或ID選作主鍵。（該主鍵的添加是在ER設計時添加，不是建庫時隨意添加）
第二範式（2NF）要求實體的屬性完全依賴於主關鍵字。
所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。
為實現區分通常需要為表加上一個列，以存儲各個實例的唯一標識。簡而言之，第二範式就是在第一範式的基礎上屬性完全依賴於主鍵。
3、第三範式（3NF）
在2NF基礎上，任何非主屬性不依賴於其它非主屬性（在2NF基礎上消除傳遞依賴）
第三範式（3NF）是第二範式（2NF）的一個子集，即滿足第三範式（3NF）必須滿足第二範式（2NF）。
簡而言之，第三範式（3NF）要求一個關系中不包含已在其它關系已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。
那麼在員工信息表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。
如果不存在部門信息表，則根據第三範式（3NF）也應該構建它，否則就會有大量的數據冗餘。
簡而言之，第三範式就是屬性不依賴於其它非主屬性，也就是在滿足2NF的基礎上，任何非主屬性不得傳遞依賴於主屬性。
(4)資料庫設計5個範式擴展閱讀
設計關系資料庫時，遵從不同的規范要求，設計出合理的關系型資料庫，這些不同的規范要求被稱為不同的範式，各種範式呈遞次規范，越高的範式資料庫冗餘越小。
目前關系資料庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、巴斯-科德範式（BCNF）、第四範式(4NF）和第五範式（5NF，又稱完美範式）。
滿足最低要求的範式是第一範式（1NF）。在第一範式的基礎上進一步滿足更多規范要求的稱為第二範式（2NF），其餘範式以次類推。一般說來，資料庫只需滿足第三範式(3NF）就行了。
參考資料：網路-資料庫範式
Ⅳ 資料庫有幾種範式
目前關系資料庫有六種範式，即第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、巴斯−科德範式（BCNF）、第四範式（4NF）和第五範式（5NF，又稱完美範式）。滿足最低要求的範式是第一範式（1NF）。在第一範式的基礎上進一步滿足更多規范要求的稱為第二範式（2NF），其餘範式依次類推。一般來說，資料庫只需滿足第三範式（3NF）。
第一範式（1NF）第一範式（1NF）是指在關系模型中，對域添加的一個規范要求，所有的域都應該是原子性的，即資料庫表的每一列都是不可分割的原子數據項，而不是集合、數組、記錄等非原子數據項。即實體中的某個屬性有多個值時，必須拆分為不同的屬性。在符合第一範式（1NF）表中的每個域值只能是實體的一個屬性或一個屬性的一部分。
簡而言之，第一範式（1NF）是最基本的範式，如果資料庫表中的所有欄位值都是不可分解的原子值，就說明該資料庫表滿足第一範式（1NF）。在任何一個關系資料庫中，第一範式（1NF）是對關系模式設計的基本要求，所有設計的數據模型都必須滿足第一範式（1NF）。
從上面的定義描述中，可以歸納出第一範式（1NF）具有如下幾個顯著特點：（（1)資料庫表中的欄位都是單一屬性。
①欄位不可再分。
②同一列中不能有多個值。
（2）單一屬性由基本類型構成。
①整型。
②實數。
③字元型。
④邏輯型。
⑤日期型。
⑥其他類型。
滿足以上兩大特徵的表就是符合第一範式（1NF）的表，不滿足以上任一特徵的表都是不符合第一範式（1NF）的表。
例如，圖欄位可再分的表所示的「電話」欄位可以再拆分成「手機」與「座機」欄位，不滿足「欄位不可再分」的要求，因此不符合第一範式（1NF）要求。
欄位可再分的表
又如，圖欄位可再分的表所示的「姓名」欄位包含「張偉」與「宋鑫」兩個值，不滿足「同一列中不能有多個值」的要求，因此也不符合第一範式（1NF）要求。
同一列中有多個值的表
第二範式（2NF）第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的，即滿足第二範式（2NF）必須先滿足第一範式（1NF）。第二範式（2NF）要求資料庫表中的每個實例或記錄必須可以被唯一地區分。選取一個能區分每個實體的屬性或屬性組，作為實體的唯一標識。例如，員工表中的身份證號碼即可實現每個員工的區分，該身份證號碼即候選鍵，任何一個候選鍵都可以被選作主鍵。在找不到候選鍵時，可額外增加屬性以實現區分。如果在員工關系中沒有對其身份證號碼進行存儲，而姓名可能會在資料庫運行的某個時間重復，無法區分出實體時，設計身份證號碼等不重復的編號以實現區分，被添加的編號選作主鍵。注意：該主鍵的添加是在ER設計時添加，不是在建庫時隨意添加。
第二範式（2NF）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴，是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分，通常需要為表加上一個列，以存儲各個實例的唯一標識。
簡而言之，第二範式（2NF）在第一範式（1NF）的基礎之上更進一層。第二範式（2NF）需要確保資料庫表中的每一列都和主鍵相關，而不能只與主鍵的某一部分相關（主要針對聯合主鍵而言）。也就是說在一個資料庫表中，一個表中只能保存一種數據，不可以把多種數據保存在同一個資料庫表中。
所謂聯合主鍵，是指由兩個或兩個以上的欄位共同組成數據表的主鍵。如圖聯合主鍵表所示，單憑「客戶」欄位無法確定表中唯一的記錄，單憑「開戶銀行」欄位也無法確定表中唯一的與「開戶銀行」一起組成數據表的聯合主鍵。
聯合主鍵表
從上面的定義描述中，可以歸納出第二範式（2NF）具有如下幾個顯著特點：（（1)資料庫表滿足第一範式（1NF）。
（2）資料庫中每個表均有主鍵。
①單欄位主鍵。
②聯合主鍵。即不能存在單個主鍵欄位決定非主鍵欄位的情況。
例如，表中有A、B、C、D、E五個欄位，若A與B為聯合主鍵（A，B），如有A決定C的情況（A→C），則不符合第二範式（2NF）。
滿足以上特徵的表就是符合第二範式（2NF）的表，不滿足以上任何一特徵的表都是不符合第二範式（2NF）的表。
例如，如圖所示，所有欄位均不可再拆分，因而滿足第一範式（1NF）的要求，但表中沒有任何一個欄位可以確定表中的唯一記錄，即表中沒有主鍵，因此其不滿足「資料庫中每張表均有主鍵」的要求，所以不符合第二範式（2NF）要求。
又如，如圖所示，滿足第一範式（1NF）的要求，並且在原來的基礎上增加了「ID」欄位作為表的主鍵，因此其符合第二範式（2NF）要求。
沒有主鍵的數據表
增加了主鍵的數據表
重新分析圖1−3所示的聯合主鍵表，此表符合第一範式（1NF）「欄位不可再拆分」的要求，並且有「客戶」與「開戶銀行」兩個欄位作為表的聯合主鍵（客戶，開戶銀行），但其是否就是一個符合第二範式（2NF）的表呢？
進一步分析，就可以發現：「客戶電話」欄位由「客戶」欄位決定，「開戶行地址」欄位由「開戶銀行」欄位決定；即存在如下依賴關系：客戶→客戶電話，開戶銀行→開戶行地址。
（客戶，開戶銀行）為主鍵欄位，（客戶電話，開戶行地址）為非主鍵欄位，因此，其不符合聯合主鍵中「不能存在單個主鍵欄位決定非主鍵欄位」的情況，所以可以認定其並不是符合第二範式（2NF）的數據表。
例1.1判斷如圖所示的學生信息表是否符合第二範式（2NF）。
圖所示中存在聯合主鍵（學號，課程編號），但存在（學號→姓名）、（課程編號→課程名）的依賴關系，即存在某個主鍵欄位決定非主鍵欄位的情況，因此其不符合第二範式（2NF），不是第二範式（2NF）表。可考慮把此表拆成分數表（見圖）、課程表（見圖）和姓名表（見圖），則此三個表是符合第二範式（2NF）的表。
圖學生信息表
圖分數表
圖課程表
圖姓名表
第三範式（3NF）第三範式（3NF）是第二範式（2NF）的一個子集，即滿足第三範式（3NF）必須滿足第二範式（2NF）。第三範式（3NF）要求一個關系中不包含已在其他關系包含的非主關鍵字信息。
第三範式（3NF）就是任何非主屬性不依賴於其他非主屬性，也就是在滿足第二範式（2NF）的基礎上，任何非主屬性不得傳遞依賴於主屬性。第三範式（3NF）需要確保數據表中的每一列數據都和主鍵直接相關，而不能間接相關。數據不能存在傳遞關系，即每個屬性都跟主鍵有直接關系而不是間接關系。如屬性之間含有A→B→C這樣的關系，是不符合第三範式（3NF）的。
當數據表不符合第三範式（3NF）時，會有大量的冗餘數據，還會存在插入異常、刪除異常、數據冗餘度大、修改復雜等問題。
從上面的定義描述中，可以歸納出第三範式（3NF）具有如下幾個顯著特點：（（1)資料庫表滿足第二範式。
（2）資料庫表的非主鍵欄位不存在傳遞依賴關系（即非主鍵欄位不能決定其他非主鍵欄位）。例如，表中有A、B、C、D、E五個欄位，若A為主鍵，如有C決定D的情況（C→D）則不符合第三範式（3NF）。
滿足以上特徵的表就是符合第三範式（3NF）的表，不滿足以上任何一特徵的表都是不符合第三範式（3NF）的表。
如圖所示，表中有主鍵（工號），因而滿足第二範式（2NF）的要求；但表中非主鍵欄位間存在傳遞依賴關系：非主鍵欄位「部門」決定非主鍵欄位「部門電話」和「部門主管」（部門→部門電話，部門→部門主管），因此不符合第三範式（3NF）的要求。
圖非主鍵欄位存在傳遞依賴關系的表
例1.2判斷圖所示的學生院屬信息表是否符合第三範式（3NF）。
圖學生院屬信息表
圖中有主鍵（學號），則滿足第二範式（2NF）的要求，但存在（所在學院→學院電話）、（所在學院→學院地點），即存在非主鍵欄位決定其他非主鍵欄位的情況，因此其不符合第三範式（3NF）的要求，不是第三範式（3NF）表。可考慮把此表拆成學生表（見圖）和學院表（見圖），則兩個表是符合第三範式（3NF）的表。
圖學生表
圖學院表
Ⅵ 資料庫設計遵守哪些範式
關系資料庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、巴德斯科範式（BCNF）、第四範式（4NF）和第五範式（5NF）。滿足最低要求的範式是第一範式（1NF）。在第一範式的基礎上進一步滿足更多要求的稱為第二範式（2NF），其餘範式以次類推。一般說來，資料庫只需滿足第三範式（3NF）就行了。
第一範式 無重復的列
第二範式 屬性完全依賴於主鍵
第三範式 屬性不能傳遞依賴於主屬性（屬性不依賴於其它非主鍵屬性）
Ⅶ 範式的關系資料庫中的幾種設計範式
1 第一範式（1NF）
在任何一個關系資料庫中，第一範式（1NF）是對關系模式的基本要求，不滿足第一範式（1NF）的資料庫就不是關系資料庫。
所謂第一範式（1NF）是指資料庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重復的屬性。如果出現重復的屬性，就可能需要定義一個新的實體，新的實體由重復的屬性構成，新實體與原實體之間為一對多關系。在第一範式（1NF）中表的每一行只包含一個實例的信息。
簡而言之，第一範式就是無重復的列。
2 第二範式（2NF）
第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的，即滿足第二範式（2NF）必須先滿足第一範式（1NF）。第二範式（2NF）要求資料庫表中的每個實例或行必須可以被唯一地區分。為實現區分通常需要為表加上一個列，以存儲各個實例的唯一標識。這個唯一屬性列被稱為主關鍵字或主鍵、主碼。
第二範式（2NF）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性。如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列，以存儲各個實例的唯一標識。
簡而言之，第二範式就是非主屬性非部分依賴於主關鍵字。
3 第三範式（3NF）
滿足第三範式（3NF）必須先滿足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字信息。
例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那麼在圖3-2的員工信息表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三範式（3NF）也應該構建它，否則就會有大量的數據冗餘。
簡而言之，第三範式就是屬性不依賴於其它非主屬性。
4 BCNF（BC範式）
5 第四範式（4NF）
6第五範式（5NF）
是最終範式，消除了4NF中的連接依賴。
軟道語錄
軟道範式
軟道範式是對資料庫進行優化的原則 。
（歡迎廣大讀者補充更正以上信息）
資料庫設計三大範式應用實例剖析
資料庫的設計範式是資料庫設計所需要滿足的規范，滿足這些規范的資料庫是簡潔的、結構明晰的；同時，不會發生插入（insert）、刪除（delete）和更新（update）操作異常。反之則是亂七八糟，不僅給資料庫的編程人員製造麻煩，而且面目可憎，可能存儲了大量不需要的冗餘信息。
設計範式是不是很難懂呢？非也，大學教材上給我們一堆數學公式我們當然看不懂，也記不住。所以我們很多人就根本不按照範式來設計資料庫。
實質上，設計範式用很形象、很簡潔的話語就能說清楚道明白。本文將對範式進行通俗地說明，並以筆者曾經設計的一個簡單論壇的資料庫為例來講解怎樣將這些範式應用於實際工程。