關系型資料庫範式
㈠ 第一範式第二範式第三範式怎麼區分
滿足第一範式 就是每個屬性都不可在拆分，滿足第二範式，非屬性值要完全依賴主編碼 非碼屬性不相互依賴，滿足第三範式，不存在傳遞依賴。
㈡ 資料庫關系模式有哪些類型
在關系資料庫中有型和值兩種類型結構。關系模式是型，關系是值，關系模式是對關系的描述。
描述一個關系需要從以下兩個方面來定義：第一方面，關系實質上是一個二維表，表的每一行為一個元組，每一列為一個屬性。一個元組就是該關系所涉及的屬性集的笛卡兒積的一個元素。關系是元組的集合，因此關系模式必須指出這個元組集合的結構，即它由哪些屬性構成，這些屬性來自哪些域，以及屬性與域之間的映象關系。
第二方面，一個關系通常是由賦予它的元組語義來確定的。元組語義實質上是一個n目謂詞（n是屬性集中屬性的個數）。凡使該n目謂詞為真的笛卡兒積中的元素（或者說凡符合元組語義的那部分元素）的全體就構成了該關系模式的關系。
1.3.1關系資料庫基本概念關系數據中，關系模式涉及眾多概念、術語，初學者對這方面不容易把握與理解，以下用通俗易懂的語言來對這些概念及術語作簡單的介紹。
1.關系關系（Relation）是指資料庫中實體的信息，也就是資料庫中二維表的數據。一個關系就是一個資料庫表的值，表中的內容是對應關系模式在某個時刻的值，稱為一個關系。例如，關系A表示資料庫有一張名字為A的數據表所記錄的所有數據。關系資料庫中每一個關系都具有以下六方面的性質：（（1)列是同質的。即每一列中的分量為同一類型的數據，來自同一個域。
（2）不同的列可出自同一個域，稱其中的每列為一個屬性，不同的屬性要給予不同的屬性名。
（3）列的順序無所謂。即列的次序可以任意交換。
（4）任意兩個元組不能完全相同。
（5）行的順序無所謂。即行的次序可以任意交換。
（6）分量必須取原子值。即每一個分量都必須是不可分的資料庫屬性。
2.模式模式（Schema）是資料庫中全體數據的邏輯結構和特徵的描述，是所有用戶的公共數據視圖，也稱邏輯模式。有以下幾方面性質：（（1)一個資料庫只有一個模式。
（2）模式是數據在邏輯級上的視圖。
（3）以某一種數據模型為基礎。
定義模式時不僅要定義數據的邏輯結構，包括數據項的構成、名字、類型、取值范圍等，而且要定義與數據有關的安全性、完整性要求，定義這些數據之間的聯系。
3.關系模式關系模式（RelationSchema）描述的是與關系相對應的二維表的表結構，即關系中包含哪些屬性，屬性來自哪些域，以及與域之間的映象關系。
關系模式與關系的區別：（（1)關系模式描述了關系數據結構和語義，是關系的型。而關系是一個數據集合，是關系模式的值，是關系模式的一個實例。
（2）關系實際上就是關系模式在某一時刻的狀態或內容。關系模式是靜態的、穩定的，而關系是動態的、隨時間不斷變化的，因為資料庫操作會不斷地更新資料庫中的數據。
4.元組元組（Tuple）是關系資料庫中的基本概念，一個關系表中的每行就是一個元組。也就是說資料庫表中的每條記錄都是一個元組，表結構的每列就是一個屬性，在二維表裡，元組也稱為記錄。元組可表示一個關系或關系之間的聯系。
一般情況下，一個關系數據表中的每條記錄均有一個唯一的編號（記錄號），這個編號也叫元組號。
5.碼碼（Key）是關系資料庫系統中的基本概念。所謂碼，就是能唯一標識實體的屬性集，是整個屬性集，而不是單個屬性。在關系資料庫中，碼包括多種類型，如超碼、候選碼和主碼。
（（1)超碼（SuperKey）。超碼是一個或多個屬性的集合，這些屬性可以在一個實體集中唯一地標識一個實體。如果K是一個超碼，那麼K的任意超集也是超碼，也就是說如果K是超碼，那麼所有包含K的集合也是超碼。例如，學生是一個實體，則學生的集合是一個實體集，而超碼用來在學生的集合中區分不同的學生。假設學生（實體）具有多個屬性：學號，身份證號，姓名，性別。因為通過學號可以找到唯一一個學生，所以{學號}是一個超碼，同理{學號，身份證號}、{學號，身份證號，姓名}、{學號，身份證號，姓名，性別}、{身份證號}、{身份證號，姓名}、{身份證號，姓名，性別}也是超碼。在這里，因為不同的學生可能擁有相同的姓名，所以姓名不可以區別一個學生，即{姓名}不是一個超碼，{性別}、{姓名，性別}也不是。
（2）候選碼（CandidateKey）。候選碼是可以唯一標識一個元組的最少的屬性集合。候選碼是從超碼中選出的，因此候選碼也是一個或多個屬性的集合。因為超碼的范圍太廣，很多是無用的，所以候選碼是最小超碼，它們的任意真子集都不能成為超碼。例如，如果K是超碼，那麼所有包含K的集合都不能是候選碼；如果K，J都不是超碼，那麼K和J組成的集合{K，J}有可能是候選碼。
雖然超碼可以唯一標識一個實體，但是可能大多數超碼中含有多餘的屬性，所以需要候選碼。
例如學生表，學生（學號，姓名，年齡，性別，專業），其中的學號是可以唯一標識一個元組，所以學號可以作為候選碼。既然學號都可以作候選碼，那麼學號和姓名這兩個屬性的組合就可以唯一區別一個元組。此時的學號可以成為碼，學號和姓名的組合也可以成為碼，但是學號和姓名的組合不能成為候選碼，因為即使去掉姓名屬性，剩下的學號屬性也完全可以唯一地標識一個元組。也就是說，候選碼中的所有屬性都是必需的，缺少任何一個屬性，都不能唯一標識一個元組。
（3）主碼（PrimaryKey）。主碼是從多個候選碼中任意選出一個作為主鍵，這個被選中的候選碼就稱為主碼。如果候選碼只有一個，那麼候選碼就是主碼。雖然說主碼的選擇是比較隨意的，但在實際開發中還是需要一定的經驗，不然開發出來的系統會出現問題。一般來說，主碼都應該選擇那些從不或者極少變化的屬性。
例如，在一個職工實體中，職工（職工號，姓名，入職時間，部門，崗位，工資，職級，工齡，電話），職工號可以用來唯一確定實體中的一個元組，所以職工號是一個候選碼。如果實體屬性——姓名、入職時間、部門三者組合也能唯一地確定一個元組，則（姓名，入職時間，部門）也是一個候選碼。在上述兩個候選碼中任選一個均可作為職工實體的主碼，一般來說直接選擇職工號作為實體的主碼是最為簡單方便的。
1.3.2關系模式的定義關系是資料庫二維表中的數據記錄，關系模式是資料庫二維表的表結構，關系是動態的，關系模式是靜態的。
關系模式可由六個元素來描述，分別是R、U、D、dom、I、F。其中，R為關系的名稱；
U為組成該關系的屬性名的集合；D為U集合中屬性的域集合；dom為屬性集U向域集D的映射；I為完整約束集合；F為屬性間數據的依賴關系集合。
一個關系模式通常表示為R（U，D，dom，I，F），也可以忽略其他元素，直接簡化為R（U）或R（A1，A2，A3，…，An），其中A1，A2，A3，…，An為屬性名。
例如，在一個選課模塊中，包含「學生」「課程」「選修」等關系實體。「學生」實體的屬性有SNO（學號）、SNAME（姓名）、AGE（年齡）、SEX（性別）、SDEPT（系部），其中「學號」為主鍵；「課程」實體的屬性有CNO（課程號）、CNAME（課程名稱）、CDEPT（系部）、TNAME（教師），其中「課程號」為主鍵；「選修」實體的屬性有GRADE（成績）、SNO（學號）、CNO（課程號），其中「學號」和「課程號」為聯合主鍵。學生和課程之間是多對多的關聯關系，即一個學生可以同時選修多門課程，一門課程也可以同時被多個學生選修。這種多對多的關聯關系可以通過「選修」關系實體作為中間橋接實體，變成兩個一對多的實體關聯關系，如圖所示。
圖學生選課實體
從圖的實體關系圖中可以得到選課模塊的實體關系模式集——學生關系、課程關系、選修關系，具體關系模式如下：學生關系模式Student（SNO，SNAME，AGE，SEX，SDEPT）；
課程關系模式Course（CNO，CNAME，CDEPT，TNAME）；
選修關系模式StudentCourse（SNO，CNO，GRADE）。
對以上定義的三個關系模式實例化，插入初始化數據後，可得到學生、課程、選修三個關系的實例，如圖所示。圖中矩形框圈住部分為選課模塊中的關系模式（表結構）；橢圓框圈住部分為選課模塊中的關系（數據）。整個選課模塊的表環境由關系模式與關系兩部分共同組成，缺一不可。關系模式的分解標准關系模式的規范化過程實際上就是關系模式的「分解」過程，即把邏輯上獨立的信息放在獨立的關系模式中。分解是解決數據冗餘的主要方法，也是規范化的一條原則——關系模式有冗餘問題就要分解。
資料庫設計者在進行關系資料庫設計時，應參照模式規范化理論，盡可能使資料庫模式保持高的標准。一般盡量把關系資料庫設計成巴斯−科德範式（BCNF）的模式集，如果設計成巴斯−科德範式（BCNF）模式集時達不到保持函數依賴的標准，那麼只能降低要求，設計成第三範式（3NF）的模式集，以達到保持函數依賴和無損分解的基本要求。
學生、課程、選修三個關系的實例
1.分解的定義一個關系模式可以分解成眾多子關系模式，分解方式不同，得到的子關系模式也不同。
關系模式的分解是指把某一個關系模式按照某一種方式進行分解得到的所有子關系模式。
如關系模式R
函數依賴關系集F=F1∪F2∪…∪Fn，其中F1，F2，…，Fn是F在U1，U2，…，Un上的投影。
2.分解的標准把低級的關系模式分解成高級的關系模式的方法不是唯一的，只要能夠保證分解後的關系模式與原關系模式等價，就是一個完整、標準的分解方法。關系模式的標准分解方法應同時達到以下兩方面的要求：（（1)分解具有無損連接性。
（2）分解要保持函數依賴性。
具有無損連接性的分解保證信息不會丟失，但無損連接不一定能解決插入異常、刪除異常、修改復雜、數據冗餘等問題，如要解決這些問題，則要考慮更高的關系數據範式理論原則。
㈢ 資料庫的三大範式
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的基礎上，任何非主屬性不得傳遞依賴於主屬性。
(3)關系型資料庫範式擴展閱讀
設計關系資料庫時，遵從不同的規范要求，設計出合理的關系型資料庫，這些不同的規范要求被稱為不同的範式，各種範式呈遞次規范，越高的範式資料庫冗餘越小。
目前關系資料庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、巴斯-科德範式（BCNF）、第四範式(4NF）和第五範式（5NF，又稱完美範式）。
滿足最低要求的範式是第一範式（1NF）。在第一範式的基礎上進一步滿足更多規范要求的稱為第二範式（2NF），其餘範式以次類推。一般說來，資料庫只需滿足第三範式(3NF）就行了。
參考資料：網路-資料庫範式
㈣ 求解答資料庫範式
第一範式（1NF）
所謂第一範式（1NF）是指在關系模型中，對於添加的一個規范要求，所有的域都應該是原子性的，即資料庫表的每一列都是不可分割的原子數據項，而不能是集合，數組，記錄等非原子數據項。即實體中的某個屬性有多個值時，必須拆分為不同的屬性。在符合第一範式（1NF）表中的每個域值只能是實體的一個屬性或一個屬性的一部分。簡而言之，第一範式就是無重復的域。
說明：在任何一個關系資料庫中，第一範式（1NF）是對關系模式的設計基本要求，一般設計中都必須滿足第一範式（1NF）。不過有些關系模型中突破了1NF的限制，這種稱為非1NF的關系模型。換句話說，是否必須滿足1NF的最低要求，主要依賴於所使用的關系模型。
第二範式（2NF）
在1NF的基礎上，非碼屬性必須完全依賴於候選碼（在1NF基礎上消除非主屬性對主碼的部分函數依賴）
第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的，即滿足第二範式（2NF）必須先滿足第一範式（1NF）。第二範式（2NF）要求資料庫表中的每個實例或記錄必須可以被唯一地區分。選取一個能區分每個實體的屬性或屬性組，作為實體的唯一標識。例如在員工表中的身份證號碼即可實現每個一員工的區分，該身份證號碼即為候選鍵，任何一個候選鍵都可以被選作主鍵。在找不到候選鍵時，可額外增加屬性以實現區分，如果在員工關系中，沒有對其身份證號進行存儲，而姓名可能會在資料庫運行的某個時間重復，無法區分出實體時，設計辟如ID等不重復的編號以實現區分，被添加的編號或ID選作主鍵。（該主鍵的添加是在ER設計時添加，不是建庫時隨意添加）
第二範式（2NF）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列，以存儲各個實例的唯一標識。簡而言之，第二範式就是在第一範式的基礎上屬性完全依賴於主鍵。
第三範式（3NF）
在2NF基礎上，任何非主屬性不依賴於其它非主屬性（在2NF基礎上消除傳遞依賴）
第三範式（3NF）是第二範式（2NF）的一個子集，即滿足第三範式（3NF）必須滿足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個關系中不包含已在其它關系已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那麼在員工信息表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三範式（3NF）也應該構建它，否則就會有大量的數據冗餘。簡而言之，第三範式就是屬性不依賴於其它非主屬性，也就是在滿足2NF的基礎上，任何非主屬性不得傳遞依賴於主屬性。
巴斯-科德範式（BCNF）
Boyce-Codd Normal Form（巴斯-科德範式）
在3NF基礎上，任何非主屬性不能對主鍵子集依賴（在3NF基礎上消除對主碼子集的依賴）
巴斯-科德範式（BCNF）是第三範式（3NF）的一個子集，即滿足巴斯-科德範式（BCNF）必須滿足第三範式（3NF）。通常情況下，巴斯-科德範式被認為沒有新的設計規范加入，只是對第二範式與第三範式中設計規范要求更強，因而被認為是修正第三範式，也就是說，它事實上是對第三範式的修正，使資料庫冗餘度更小。這也是BCNF不被稱為第四範式的原因。某些書上，根據範式要求的遞增性將其稱之為第四範式是不規范，也是更讓人不容易理解的地方。而真正的第四範式，則是在設計規范中添加了對多值及依賴的要求。
定義：關系模式R<U,F>∈1FNF,若X→Y且Y不是X的子集時X必含有碼，則R<U,F>∈BCNF。也就是說，關系模式R<U,F>中，若每一個決定因素都包含碼，則R<U,F>∈BCNF。
由BCNF的定義可以得到結論，一個滿足BCNF的關系模式有：
-所有非主屬性對每一個碼都是完全函數依賴。
-所有主屬性對每一個不包含它的碼也是完全函數依賴。
-沒有任何屬性完全函數依賴於非碼的任何一組屬性。
若R∈BCNF，按定義排除了任何屬性對碼的傳遞依賴與部分依賴，所以R∈3NF。[1]
一般關系型資料庫設計中，達到BCNF就可以了！
㈤ 什麼是資料庫中的「範式」
設計關系資料庫時，遵從不同的規范要求，設計出合理的關系型資料庫，這些不同的規范要求被稱為不同的範式，各種範式呈遞次規范，越高的範式資料庫冗餘越小。
目前關系資料庫有六種範式，但資料庫必須遵守1、2、3
範式。
第一範式（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)：每一個屬性都是原子項，不可分割
INF中所述的不可分割，是指在可分割的情況下必須分割，這是在應用環境中來判斷的，當屬性是文檔時，雖然文檔有段落標記，但還是不應該分割。
第二範式：每個非主屬性要完全函數依賴於候選鍵，或者是主鍵。
關鍵詞是「完全依賴」，與「部分依賴」或「局部依賴」相對，如果候選鍵或主鍵由兩個屬性組成，非主屬性不能只依賴與其中一個或部分屬性。
比如：股票日行情表由股票代碼、股票名稱、日期、收盤價四個屬性組成，這就違反了2NF，因為「股票名稱」部分依賴於「股票代碼」。
第三範式：所有非主屬性對任何候選關鍵字都不存在傳遞依賴
關鍵詞是「傳遞依賴」，如果非主屬性通過另一個非主屬性依賴主鍵，則是傳遞依賴。
比如：股票基本信息表由股票代碼、股票名稱、企業名稱、所在地區、所在省份組成，其中「所在省份」依賴於所在地區，存在傳遞依賴。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
幾個相關術語：
超鍵（super key）：在關系中能唯一標識元組的屬性集稱為關系模式的超鍵
候選鍵（candidate key）：不含有多餘屬性的超鍵稱為候選鍵
主鍵（primary key）：用戶選作元組標識的一個候選鍵稱為主鍵
主屬性（Prime Attribute）：候選鍵中的屬性稱為主屬性
非主屬性(Non-Key Attribute)：不包含在任何候選鍵中的屬性稱為非主屬性。
㈧ 什麼是資料庫三大範式
什麼是範式：簡言之就是，資料庫設計對數據的存儲性能，還有開發人員對數據的操作都有莫大的關系。所以建立科學的，規范的的資料庫是需要滿足一些
規范的來優化數據數據存儲方式。在關系型資料庫中這些規范就可以稱為範式。
什麼是三大範式：
第一範式：當關系模式R的所有屬性都不能在分解為更基本的數據單位時，稱R是滿足第一範式的，簡記為1NF。滿足第一範式是關系模式規范化的最低要
求，否則，將有很多基本操作在這樣的關系模式中實現不了。
第二範式：如果關系模式R滿足第一範式，並且R得所有非主屬性都完全依賴於R的每一個候選關鍵屬性，稱R滿足第二範式，簡記為2NF。
第三範式：設R是一個滿足第一範式條件的關系模式，X是R的任意屬性集，如果X非傳遞依賴於R的任意一個候選關鍵字，稱R滿足第三範式，簡記為3NF。
㈨ 怎樣區分關系資料庫中的六個範式
這六個範式是逐步加強，資料庫設計時，滿足的範式越高，理論上講，數據冗餘就越少，並且越不容易出問題。。。實際上嘛。。就不說了。。總之，一般設計資料庫時要求滿足第三範式第一範式的意思就是每列都不可再分，且每個表中的每列都是不重復的，只有滿足了第一範式才叫關系型資料庫。先滿足第一範式才能滿足第二範式，第二範式的意思是表中的每行必須唯一，也就是說，要有能唯一標識每行的列（或幾個列也行）滿足第二範式才能滿足第三範式，第三範式是的意思是要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字信息。鮑依斯-科得範式，也就是BC範式，在第三範式的基礎上，消除傳遞依賴（傳遞依賴。。這個還有個定義問題：比如A->B,B->C,則A與C之間的依賴就是傳遞依賴）第四範式，（不廢話了，反正前提是先滿足前一個範式，下面也一樣），消除多值依賴（多值依賴就是存在一對多的關系，間接和直接的都可能有）第五範式，這個就比較扯了，細分成第四範式以後表已經很碎了，第五範式還要求更碎。。。第五範式的目標還是消除多值依賴，不過所消除多值依賴的更難以發現，官方的說法是：保證在第四範式中存在的任何可以分解為實體的三元關系都被分解。 暈不？
㈩ 資料庫範式是什麼
範式是指符合某一種級別的關系模式的集合，關系資料庫中的關系必須滿足一定的要求，滿足不同程度要求的為不同的範式。簡而言之，範式是為了消除重復數據來減少冗餘數據，從而讓資料庫內的數據更好地組織，讓磁碟空間得到更有效利用的一種標准化准則。
資料庫設計對數據的存儲性能，以及開發人員對數據的操作都有很大的關系，所以建立科學的、規范的資料庫必須滿足相關的規范准則是至關重要的。設計關系資料庫時，應遵從不同的規范要求設計出合理的關系型資料庫，這些不同的規范要求被稱為不同的範式。各種範式呈遞次規范，越高等級的範式資料庫冗餘越小，滿足高等級範式的先決條件是先滿足低等級範式。
應用資料庫範式有許多優點，但是主要優點有：（（1)可以減少數據冗餘，這是最重要的優點。
（2）可以消除異常，如插入異常、更新異常、刪除異常等。
（3）可以讓數據組織得更加和諧、合理、高效。
滿足資料庫設計範式規范的資料庫是簡潔的、結構明晰的；同時，不會發生插入（Insert）、刪除（Delete）和更新（Update）操作異常。反之，不僅給資料庫的編程人員帶來麻煩，而且存儲了大量的冗餘信息。