① 資料庫三範式具體是
資料庫三範式如下：
第一範式（1NF）：強調的是列的原子性，即資料庫表的每一列都是不可分割的原子數據項。
第二範式（2NF）：要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性。（在1NF基礎上消除非主屬性對主鍵的部分函數依賴）
第三範式（3NF）：任何非主屬性不依賴於其它非主屬性。（在2NF基礎上消除傳遞依賴）
② 資料庫 關系模式 範式問題
1.
f={訂單號
->訂貨日期，訂單號
->客戶號，產品編號
->品名，產品編號
->價格,客戶號->客戶名稱，客戶號->客戶電話}
2.
L類：訂單號，產品編號，客戶號
N類：數量
所以訂單號，產品編號，客戶號，數量一定是R的候選碼成員
由於(訂單號，產品編號，數量)+=訂單號，訂貨日期，客戶號，客戶名稱，客戶電話，產品編號，品名，價格，數量
所以訂單號，產品編號，數量是R的候選碼
3.第一範式，因為R中的非主屬性部分依賴於候選碼
③ 資料庫反範式化表設計和表的垂直和水平拆分什麼意思
1.水平拆分：
是根據主要查詢條件，水平分表。例如，用戶關系表， 根據用戶id：
用戶id為 1， 2， 3， 4，5 的五個用戶，採用取模的方式水平分表。將uid mod 3，取余數
這樣，id為1，4的用戶就在 t_user_1 的表裡， id 為2，5 的用戶在 t_user_2的表裡，id為3的就在t_user_3的表裡。這樣，所有用戶就平均水平分布在三個表裡。
查詢時，根據查詢條件，動態算出，該用戶信息存儲在哪個表裡
2.垂直拆分：
是根據數據量進行分表。例如，網購訂單表：
數據量過大，可能單表幾千萬條數據。那麼，垂直分表， 將id為1-1000000放在第一張表裡。
將id 1000000－2000000的放在第二張表裡。這樣，就實現了垂直分表。
查詢時，根據查詢條件，動態算出，該訂單信息存儲在哪個表裡
同樣可以，水平分庫， 垂直分庫。 也可以兩者相結合，形成資料庫矩陣集群。 數據表的矩陣。
資料庫範式：
目前關系資料庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、巴斯-科德範式（BCNF）、第四範式(4NF）和第五範式（5NF，又稱完美範式）。
具體可查看：http://ke..com/link?url=tUvhPptcmwVSWfG_
為了維持範式，會降低資料庫的查詢性能，大量冗餘信息等。在實際生產環境，很多情況下，不能去實現這種範式，所以要違反範式的定義，就是反範式資料庫設計。
範式只是一個理想化狀態，僅用於關系型資料庫。
④ 資料庫三大範式是什麼
資料庫三大範式是：
第一範式（1NF）：屬性不可分割，即每個屬性都是不可分割的原子項。（實體的屬性即表中的列）
第二範式（2NF）：滿足第一範式；且不存在部分依賴，即非主屬性必須完全依賴於主屬性。（主屬性即主鍵；完全依賴是針對於聯合主鍵的情況，非主鍵列不能只依賴於主鍵的一部分）
第三範式（3NF）：滿足第二範式；且不存在傳遞依賴，即非主屬性不能與非主屬性之間有依賴關系，非主屬性必須直接依賴於主屬性，不能間接依賴主屬性。（A -> B，B ->C，A -> C）
資料庫管理系統是資料庫系統的核心組成部分，主要完成對資料庫的操作與管理功能，實現資料庫對象的創建、資料庫存儲數據的查詢、添加、修改與刪除操作和資料庫的用戶管理、許可權管理等。它的安全直接關繫到整個資料庫系統的安全，其防護手段主要有：
（1）使用正版資料庫管理系統並及時安裝相關補丁。
（2）做好用戶賬戶管理，禁用默認超級管理員賬戶或者為超級管理員賬戶設置復雜密碼；為應用程序分別分配專用賬戶進行訪問；設置用戶登錄時間及登錄失敗次數限制， 防止暴力破解用戶密碼。
（3）分配用戶訪問許可權時，堅持最小許可權分配原則，並限制用戶只能訪問特定資料庫，不能同時訪問其他資料庫。
（4）修改資料庫默認訪問埠，使用防火牆屏蔽掉對 外開放的其他埠，禁止一切外部的埠探測行為。
（5）對資料庫內存儲的重要數據、敏感數據進行加密存儲，防止資料庫備份或數據文件被盜而造成數據泄露。
（6）設置好資料庫的備份策略，保證資料庫被破壞後能迅速恢復。
（7）對資料庫內的系統存儲過程進行合理管理，禁用掉不必要的存儲過程，防止利用存儲過程進行資料庫探測與攻擊。
（8）啟用資料庫審核功能，對資料庫進行全面的事件跟蹤和日誌記錄。
⑤ 數據結構中的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個，而不是多個）
（例如假設有一個人事資料的數據表，我們根據表中記錄的一個人的姓名，我們可以查到他的年齡即有： 姓名->年齡。在沒有同名存在的情況下，姓名就是這個表的候選鍵（碼），因為姓名可以唯一確定一條記錄的其他屬性，例如：姓名->(性別、年齡、職位)，同時我們把姓名選為該表的主鍵（含主屬性）。姓名以外的其他屬性即為非主屬性。有時候一個表可以有多個候選鍵，則需要選擇其中一組作為主鍵，所有候選鍵包括的屬性都是主屬性。）
以上內容都是根據自己理解信手敲出。並沒有嚴謹的校對教科書的概念。如有疏漏錯誤實屬正常，如有人補漏改錯不勝榮幸。
⑥ 資料庫的三大範式
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的基礎上，任何非主屬性不得傳遞依賴於主屬性。
(6)資料庫反第一範式擴展閱讀
設計關系資料庫時，遵從不同的規范要求，設計出合理的關系型資料庫，這些不同的規范要求被稱為不同的範式，各種範式呈遞次規范，越高的範式資料庫冗餘越小。
目前關系資料庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、巴斯-科德範式（BCNF）、第四範式(4NF）和第五範式（5NF，又稱完美範式）。
滿足最低要求的範式是第一範式（1NF）。在第一範式的基礎上進一步滿足更多規范要求的稱為第二範式（2NF），其餘範式以次類推。一般說來，資料庫只需滿足第三範式(3NF）就行了。
參考資料：網路-資料庫範式
⑦ 什麼是反範式
反範式是通過增加冗餘數據或數據分組來提高資料庫讀性能的過程。在某些情況下， 反範式有助於掩蓋關系型資料庫軟體的低效。關系型的範式資料庫即使做過優化， 也常常會帶來沉重的訪問負載。
資料庫的範式設計會存儲不同但相關的信息在不同的邏輯表， 如果這些表的存儲在物理上也是分離的，那麼從幾個表中完成資料庫的查詢可能就會很慢 (比如JOIN操作)。如果JOIN操作的表很多，那麼可能會慢得離譜。 有兩個辦法可以解決這個問題。首選的方法是使邏輯上的設計遵循範式， 但允許資料庫管理系統(DBMS)在磁碟上存儲額外的冗餘信息來加快查詢響應。 在這種情況下，DBMS還要保證冗餘副本與原始數據的一致性。 這種方法通常在SQL中以索引視圖(微軟的SQL Server)或物化視圖(Oracle)實現。 視圖將信息表示為方便查詢的格式，索引確保視圖上的查詢進行了優化。
更常見的做法是對數據做反範式設計。這種方法同樣能提高查詢響應速度， 但此時不再是DBMS而是資料庫設計者去保證數據的一致性。 資料庫設計者們通過在資料庫中創建規則來保證數據的一致性，這些規則叫約束。 這樣一來，資料庫設計的邏輯復雜度就增加了，同時額外約束的復雜度也增加了， 這使該方法變得危險。此外，「約束」在加快讀操作(SELECT)的同時，減慢了寫操作 (INSERT, UPDATE和DELETE)。這意味著一個反範式設計的資料庫， 可能比它的範式版本有著更差的寫性能。
反範式數據模型與沒有範式化的數據模型不同。 只有在範式化已經達到一定的滿意水平並且所需的約束和規則都已經建立起來， 才進行反範式化。例如，所有的關系都屬於第三範式， 連接的關系和多值依賴得到了妥善處理。
⑧ 資料庫中第一範式，第二範式，第三範式、、、、是什麼，怎麼區分
第一範式：一言以蔽之：「第一範式的數據表必須是二維數據表」，第一範式是指資料庫的每一列都是不可分割的基本數據項，強調列的原子性，試題中某一屬性不能擁有幾個值。比如資料庫的電話號碼屬性裡面不可以有固定電話和行動電話值。 說明：在任何一個關系資料庫中，第一範式（1NF）是對關系模式的基本要求，不滿足第一範式（1NF）的資料庫就不是關系資料庫。
第二範式建立在第一範式的基礎上，即滿足第二範式一定滿足第一範式，第二範式要求數據表每一個實例或者行必須被唯一標識。除滿足第一範式外還有兩個條件，一是表必須有一個主鍵；二是沒有包含在主鍵中的列必須完全依賴於主鍵，而不能只依賴於主鍵的一部分。每一行的數據只能與其中一列相關，即一行數據只做一件事。只要數據列中出現數據重復，就要把表拆分開來。
第三範式若某一範式是第二範式，且每一個非主屬性都不傳遞依賴於該範式的候選鍵，則稱為第三範式，即不能存在：非主鍵列 A 依賴於非主鍵列 B，非主鍵列 B 依賴於主鍵的情況。
(8)資料庫反第一範式擴展閱讀：
範式是符合某一種級別的關系模式的集合。關系資料庫中的關系必須滿足一定的要求，滿足不同程度要求的為不同範式。