Mysql數據庫
?前關系數據庫有六種范式：
第?范式（1NF）、第?范式（2NF）、第三范式（3NF）、巴斯-科德范式
（BCNF）、第四范式(4NF）和第五范式（5NF，?稱完美范式）。滿?最低要求的范式是
第?范式（1NF）。在第?范式的基礎上進?步滿?更多規范要求的稱為第?范式
（2NF），其余范式以次類推。?般說來，數據庫只需滿?第三范式(3NF）就?了。所以
這?就只記錄三范式相關的知識。
? 范式
1NF:字段不可分; 2NF:有主鍵，?主鍵字段依賴主鍵; 3NF:?主鍵字段不能相互依賴;
解釋: 1NF:原?性 字段不可再分,否則就不是關系數據庫; 2NF:唯?性 ?個表只說明?個事
物; 3NF:每列都與主鍵有直接關系，不存在傳遞依賴;
第?范式（1NF）
即表的列的具有原?性,不可再分解，即列的信息，不能分解, 只要數據庫是關系型數
據庫(mysql/oracle/db2/informix/sysbase/sql server)，就?動的滿?1NF。數據庫表的每?
列都是不可分割的原?數據項，?不能是集合，數組，記錄等?原?數據項。如果實體中
的某個屬性有多個值時，必須拆分為不同的屬性 。通俗理解即?個字段只存儲?項信息。
關系型數據庫: mysql/oracle/db2/informix/sysbase/sql server ?關系型數據庫: (特點:
?向對象或者集合) NoSql數據庫: MongoDB/redis(特點是?向?檔)
第?范式（2NF）
第?范式（2NF）是在第?范式（1NF）的基礎上建?起來的，即滿?第?范式
（2NF）必須先滿?第?范式（1NF）。第?范式（2NF）要求數據庫表中的每個實例或?
必須可以被惟?地區分。為實現區分通常需要我們設計?個主鍵來實現(這?的主鍵不包含
業務邏輯)。即滿?第?范式前提，當存在多個主鍵的時候，才會發?不符合第?范式的情況。?如有
兩個主鍵，不能存在這樣的屬性，它只依賴于其中?個主鍵，這就是不符合第?范式。通
俗理解是任意?個字段都只依賴表中的同?個字段。（涉及到表的拆分）
第三范式（3NF）
滿?第三范式（3NF）必須先滿?第?范式（2NF）。簡??之，第三范式（3NF）要
求?個數據庫表中不包含已在其它表中已包含的?主鍵字段。就是說，表的信息，如果能
夠被推導出來，就不應該單獨的設計?個字段來存放(能盡量外鍵join就?外鍵join)。很多
時候，我們為了滿?第三范式往往會把?張表分成多張表。
即滿?第?范式前提，如果某?屬性依賴于其他?主鍵屬性，?其他?主鍵屬性?依賴于
主鍵，那么這個屬性就是間接依賴于主鍵，這被稱作傳遞依賴于主屬性。 通俗解釋就是?
張表最多只存兩層同類型信息。
巴斯-科德范式（BCNF）
Boyce-Codd Normal Form（巴斯-科德范式）
在3NF基礎上，任何?主屬性不能對主鍵?集依賴（在3NF基礎上消除對主碼?集的依賴）
巴斯-科德范式（BCNF）是第三范式（3NF）的?個?集，即滿?巴斯-科德范式（BCNF）
必須滿?第三范式（3NF）。通常情況下，巴斯-科德范式被認為沒有新的設計規范加?，
只是對第?范式與第三范式中設計規范要求更強，因?被認為是修正第三范式，也就是
說，它事實上是對第三范式的修正，使數據庫冗余度更?。這也是BCNF不被稱為第四范式
的原因。某些書上，根據范式要求的遞增性將其稱之為第四范式是不規范，也是更讓?不
容易理解的地?。?真正的第四范式，則是在設計規范中添加了對多值及依賴的要求
第四范式
對于第四范式，從理論層?來講是，關系模式R∈1NF,如果對于R對于R的每個?平凡多值依
賴X→Y(Y不屬于X),X都含有候選碼，則R∈4NF。4NF就是限制關系模式的屬性之間不允許有
?平凡且?函數依賴的多值依賴。顯然?個關系模式是4NF，則必為BCNF。
也就是說，當?個表中的?主屬性互相獨?時（3NF），這些?主屬性不應該有多
值。若有多值就違反了第四范式。
第五范式不得存在不遵循鍵約束的?平凡連接依賴。如果且只有?個表符合4NF，同時其中的每個
連接依賴被候選鍵所包含，此表才符合第五依賴。
? 反三范式
沒有冗余的數據庫未必是最好的數據庫，有時為了提?運?效率，提?讀性能，就必
須降低范式標準，適當保留冗余數據。具體做法是： 在概念數據模型設計時遵守第三范
式，降低范式標準的?作放到物理數據模型設計時考慮。降低范式就是增加字段，減少了
查詢時的關聯，提?查詢效率，因為在數據庫的操作中查詢的?例要遠遠?于DML的?
例。但是反范式化?定要適度，并且在原本已滿?三范式的基礎上再做調整的
