sql範式

❶ sql server第一、第二、第三範式

所謂範式就是符合某一種級別的關系模式的集合。通過分解把屬於低級範式的關系模式轉換為幾個屬於高級範式的關系模式的集合。這一過程稱為規范化。
1、
第一範式（1NF）：一個關系模式R的所有屬性都是不可分的基本數據項。
2、
第二範式（2NF）：關系模式R屬於第一範式，且每個非主屬性都完全函數依賴於鍵碼。
3、
第三範式（3NF）：關系模式R屬於第一範式，且每個非主屬性都不偉遞領帶於鍵碼。
4、
BC範式（BCNF）：關系模式R屬於第一範式，且每個屬性都不傳遞依賴於鍵碼。
不到第一範式:
create
學生(姓名,性別年齡)
----(因為性別年齡列包括了兩個屬性)
第一範式不到第二範式:
create
學生(姓名,性別,年齡,語文老師名)
--(因為老師列不是完全函數依賴於鍵碼)
第二範式不到第三範式
create
學生(姓名,性別,年齡,語文老師id,數學老師id)
create
老師(老師id,老師名,老師年齡)
第三範式不到第四範式
create
學生(學生id,姓名,性別,年齡,籍貫)
create
關系表(學生id,老師id)
create
老師(老師id,老師名,老師年齡,籍貫)
第四範式
create
學生(學生id,姓名,性別,年齡,籍貫id)
create
關系表(學生id,老師id)
create
老師(老師id,老師名,老師年齡,籍貫id)
cteate
籍貫表(id,籍貫)

❷ SQL範式舉例

一、範式例子

定義：
=====
第一範式：（1NF）
如果關系模式，它的每一分量是不可分的數據項，則此關系模式為第一範式
第二範式：（2NF）
若關系模式R屬於1NF，且每個非主屬性完全依賴於碼，則R為2NF
第三範式：（3NF）
若關系模式R屬於2NF，不存在非主屬性對碼的傳遞依賴，則稱R為3NF
傳遞依賴：當屬性間存在X->Y,Y-\->X,Y->Z,稱z傳遞依賴與X

舉例：
=====
將有關學生簡歷、選課等數據設計成一關系模式student
表示為：
student(sno,sname,age,sex,class,department,cno,cname,score,grade)
-----------------------------------------------------------------
該關系模式的每一屬性對應的域為簡單域，符合第一範式
該關系模式滿足函數依賴集
F={sno->sname,sno->age,sno->sex,sno->class,sno->department
class->departmet (班級決定系)
cno->cname,cno->score(課程號決定課程名、學分)
sno,cno->grade(學號和課程號決定成績）
}
下面將低級範式的關系模式轉換成若干個高一級範式的關系模式集合
student1(sno,sname,age,sex,class,department)
--------------------------------------------
course(cno,cname,score)
-------------------------
sc(sno,cno,grade)
-----------------
非主屬性對碼完全依賴，均為2NF

分析模式student1,存在sno->class ,class-\->sno,class->department
所以存在department(系)對sno(學號)傳遞依賴，所以關系模式student1不是第三範式
student1分解為:
student2(sno,sname,age,sex,class)
---------------------------------
class(class,department)
-----------------------
所以關系模式student 可分解成 4個3NF的關系模式student2 ,class ,course,sc

❸ SQL第一範式要求資料庫不包括復合鍵

第一範式要求關系表定義中不包含復合列，或者說每個列必須是不可分割的原子列。而復合鍵是指由多個已知的列組合而成的鍵，所以這個問題的答案是false。

❹ SQL Server 資料庫 範式問題

第一範式（1NF）無重復的列
第二範式（2NF）屬性
完全依賴於主鍵[消除非主屬性對主碼的部分函數依賴]
第三範式（3NF）屬性
不依賴於其它非主屬性[消除傳遞依賴]

兩個屬性組成的關系必為2NF，因為兩個屬性組成 的關系的碼只有三種情況：全碼；兩個分別為碼； 的關系的碼只有三種情況：全碼；兩個分別為碼； 其中一個是碼 關系模式R<U,F> 關系模式R<U,F> 其中：U={A,B,C,D}，分別討論關系模式R 其中：U={A,B,C,D}，分別討論關系模式R是否滿足 2NF。 2NF。
1)F={A→B,B→C,C→D,D→A} 2NF,因為沒有非主屬性 因為沒有非主屬性；
R是2NF,因為沒有非主屬性；
2)F=Φ 2)F=Φ 2NF,因為沒有非主屬性 因為沒有非主屬性；
R是2NF,因為沒有非主屬性； 
5.2.4 2NF 3)F={A→B,B→A,A→C} 候選碼為(A,D),(B,D) 因為存在非主屬性C (A,D),(B,D)。 候選碼為(A,D),(B,D)。
因為存在非主屬性C對碼 A,D)的部分函數依賴 所以R不是2NF 的部分函數依賴， 2NF。
（A,D)的部分函數依賴，所以R不是2NF。
規范化：由於A→C造成R不是2NF 所以分解為： A→C造成 2NF， 規范化：由於A→C造成R不是2NF，所以分解為： R1（A,C)和R2(A,B,D)均為 均為2NF. R1（A,C)和R2(A,B,D)均為2NF.
4)F={(A,B)→C,D→A} 候選碼為(B,D), 因為存在非主屬性A對碼（ 候選碼為(B,D), 因為存在非主屬性A對碼（B,D) 的部分函數依賴,所以R不是2NF
2NF的部分函數依賴,所以R不是2NF；
規范化：由於D→A造成R不是2NF 所以分解為： D→A造成 2NF， 規范化：由於D→A造成R不是2NF，所以分解為： R1（A,D)和R2(B,C,D)均為 均為2NF. R1（A,D)和R2(B,C,D)均為2NF.
另解： (A,B,C),R (A,B,D)進一步 分解為 (A,B,C),R』』(A,B,D)進一步R 另解：R』(A,B,C),R (A,B,D)進一步R』』分解為 R1」(A,D),R2 (A,D),R2」(B,D) R1 (A,D),R2 (B,D) 5.2.4 2NF 5)F={(A,B)→C,C→A} 候選碼為(A,B,D) (B,C,D),因為沒有非主 (A,B,D)和 候選碼為(A,B,D)和(B,C,D),因為沒有非主 屬性, 所以， 2NF。
屬性, 所以，R是2NF。 結論： 結論： 單個屬性組成候選碼的關系一定是2NF; 單個屬性組成候選碼的關系一定是2NF; 兩個屬性組成的關系一定是2NF;

沒有非主屬性的關系一定是2NF; 沒有非主屬性的關系一定是2NF; All-Key的關系一定是 的關系一定是2NF. All-Key的關系一定是2NF. 5.2.5 3NF 定義5.7 關系模式R U,F〉中若不存在這樣的碼X, 定義5.7 關系模式R〈U,F〉中若不存在這樣的碼X, 屬性組Y及非主屬性Z(Z Y)使得X→Y,（Y→X） Z(Z? 使得X→Y, 屬性組Y及非主屬性Z(Z?Y)使得X→Y,（Y→X） Y→Z,成立 則稱R 成立, ∈3NF。

Y→Z,成立,則稱R〈U，F〉∈3NF。 由定義5.7可以證明, R∈3NF， 5.7可以證明 由定義5.7可以證明,若R∈3NF，則每一個非主屬 性既不部分依賴函數於碼也不傳遞函數依賴於碼。
性既不部分依賴函數於碼也不傳遞函數依賴於碼 等價定義：關系模式R U,F〉∈2NF， 等價定義：關系模式R〈U,F〉∈2NF，且每一個非 主屬性都不傳遞函數依賴於碼，則稱R 主屬性都不傳遞函數依賴於碼，則稱R〈U，F〉 ∈3NF。 ∈3NF。

判斷3NF的方法是先判斷2NF,然後檢查有無非主屬 3NF的方法是先判斷2NF, 判斷3NF的方法是先判斷2NF,然後檢查有無非主屬 性對碼的傳遞函數依賴 5.2.5 3NF 關系模式SC(SNO,CNO,G) (SNO,CNO)→G沒 關系模式SC(SNO,CNO,G) (SNO,CNO)→G沒 有非主屬性對碼的傳遞依賴， SC∈3NF； 有非主屬性對碼的傳遞依賴，故SC∈3NF；

❺ SQL資料庫三大範式

c

資料庫範式1NF 2NF 3NF BCNF(實例）

設計範式（範式,資料庫設計範式,資料庫的設計範式）是符合某一種級別的關系模式的集合。構造資料庫必須遵循一定的規則。在關系資料庫中，這種規則就是範式。關系資料庫中的關系必須滿足一定的要求，即滿足不同的範式。目前關系資料庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、第四範式（4NF）、第五範式（5NF）和第六範式（6NF）。滿足最低要求的範式是第一範式（1NF）。在第一範式的基礎上進一步滿足更多要求的稱為第二範式（2NF），其餘範式以次類推。一般說來，資料庫只需滿足第三範式（3NF）就行了。下面我們舉例介紹第一範式（1NF）、第二範式（2NF）和第三範式（3NF）。

在創建一個資料庫的過程中，范化是將其轉化為一些表的過程，這種方法可以使從資料庫得到的結果更加明確。這樣可能使資料庫產生重復數據，從而導致創建多餘的表。范化是在識別資料庫中的數據元素、關系，以及定義所需的表和各表中的項目這些初始工作之後的一個細化的過程。
下面是范化的一個例子 Customer Item purchased Purchase price Thomas Shirt $40 Maria
Tennis shoes $35 Evelyn Shirt $40 Pajaro Trousers $25
如果上面這個表用於保存物品的價格，而你想要刪除其中的一個顧客，這時你就必須同時刪除一個價格。范化就是要解決這個問題，你可以將這個表化為兩個表，一個用於存儲每個顧客和他所買物品的信息，另一個用於存儲每件產品和其價格的信息，這樣對其中一個表做添加或刪除操作就不會影響另一個表。
關系資料庫的幾種設計範式介紹
1 第一範式（1NF）

在任何一個關系資料庫中，第一範式（1NF）是對關系模式的基本要求，不滿足第一範式（1NF）的資料庫就不是關系資料庫。

所謂第一範式（1NF）是指資料庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重復的屬性。如果出現重復的屬性，就可能需要定義一個新的實體，新的實體由重復的屬性構成，新實體與原實體之間為一對多關系。在第一範式（1NF）中表的每一行只包含一個實例的信息。例如，對於圖3-2
中的員工信息表，不能將員工信息都放在一列中顯示，也不能將其中的兩列或多列在一列中顯示；員工信息表的每一行只表示一個員工的信息，一個員工的信息在表中只出現一次。簡而言之，第一範式就是無重復的列。
2 第二範式（2NF）

第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的，即滿足第二範式（2NF）必須先滿足第一範式（1NF）。第二範式（2NF）要求資料庫表中的每個實例或行必須可以被惟一地區分。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。如圖3-2
員工信息表中加上了員工編號（emp_id）列，因為每個員工的員工編號是惟一的，因此每個員工可以被惟一區分。這個惟一屬性列被稱為主關鍵字或主鍵、主碼。
第二範式（2NF）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。簡而言之，第二範式就是非主屬性非部分依賴於主關鍵字。
3 第三範式（3NF）

滿足第三範式（3NF）必須先滿足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那麼在圖3-2的員工信息表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三範式（3NF）也應該構建它，否則就會有大量的數據冗餘。簡而言之，第三範式就是屬性不依賴於其它非主屬性。

❻ SQL Server資料庫設計中的三大範式

1，是數據的原子性
2，是確保每列都和主鍵相關，意思是：只做一件事
3，確保每列都和主鍵直接相關，而不是間接相關，意思是不能存在傳遞依賴

❼ sql 範式 1NF=>2NF=>3NF=>BCNF=>4NF=>5NF 問題

1NF：不說實體直接說表。若一個表中的所有列不能再拆分，則滿足1NF。
例：客戶目錄表----客戶編碼、客戶名稱、家庭地址、工作單位、聯系電話... ...非1NF
原因：聯系電話可以分為家庭電話、單位電話、行動電話等等。
2NF：滿足1NF的同時，每個列只能依賴於候選主鍵，不能依賴於不是非候選主鍵的列。
例：銷售明細表----顧客編碼、商品編碼、商品名稱、銷售單價、銷售數量、銷售金額.....非2NF
原因：候選主鍵是顧客編碼+商品編碼，所有其它列都依賴於候選主鍵，但商品名稱又依賴於
商品編碼，因此此表不是2NF
3NF：滿足2NF的同時，不能存在傳遞依賴。
傳遞依賴---A依賴於B，B又依賴候選主鍵，A傳遞依賴候選主鍵
例：銷售明細表----顧客編碼、商品編碼、銷售單價、銷售數量、銷售金額.....非3NF
（這里設銷售單價不依賴商品編碼，可以降價、打折等）
原因：候選主鍵是顧客編碼+商品編碼，所有其它列都依賴於候選主鍵，但銷售金額又依賴於
銷售單價+銷售數量，形成了銷售金額-->銷售單價+銷售數量-->候選主鍵，成了傳遞依
賴關系。因此，此表不滿足3NF。去掉銷售金額就是3NF了。
至於BCNF以上基本就不適用了。NF太高需要大量連接查詢，資料庫的性能急劇下降，不可取。

❽ 請求sql範式問題

既然你這樣說了··
那就說說我的理解吧··
第一範式：就是確保每列的原子性即屬性不能再分就屬性為最小的單元··比如說人的姓名就不可以再分了·
第二範式：就是把每個對象里的冗餘再拆分·分為對個對象··就多個表··一表一對象
第三範式：就是建關系·將第二範式中拆分的表建好關系·就OK
其他範式可以不用再理解了·
主要看客戶的要求·

❾ 有沒有用同一個表來介紹SQL的三大範式的例子

首先就得知道什麼是sql的三大範式

1.什麼是資料庫三範式？分別是哪三範式？各有什麼優缺點？
所謂第一範式（1NF）是指資料庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重復的屬性。如果出現重復的屬性，就可能需要定義一個新的實體，新的實體由重復的屬性構成，新實體與原實體之間為一對多關系。在第一範式（1NF）中表的每一行只包含一個實例的信息。簡而言之，第一範式就是無重復的列。說明：在任何一個關系資料庫中，第一範式（1NF）是對關系模式的基本要求，不滿足第一範式（1NF）的資料庫就不是關系資料庫。
第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的，即滿足第二範式（2NF）必須先滿足第一範式（1NF）。第二範式（2NF）要求資料庫表中的每個實例或行必須可以被惟一地區分。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。例如員工信息表中加上了員工編號（emp_id）列，因為每個員工的員工編號是惟一的，因此每個員工可以被惟一區分。這個惟一屬性列被稱為主關鍵字或主鍵、主碼。
第二範式（2NF）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。簡而言之，第二範式就是屬性完全依賴於主鍵。
滿足第三範式（3NF）必須先滿足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那麼在的員工信息表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三範式（3NF）也應該構建它，否則就會有大量的數據冗餘。簡而言之，第三範式就是屬性不依賴於其它非主屬性。
問題分析
因此不滿足第二範式的要求，會產生如下問題
數據冗餘： 同一門課程由n個學生選修，"學分"就重復n-1次；同一個學生選修了m門課程，姓名和年齡就重復了m-1次。
更新異常：
1)若調整了某門課程的學分，數據表中所有行的"學分"值都要更新，否則會出現同一門課程學分不同的情況。
2)假設要開設一門新的課程，暫時還沒有人選修。這樣，由於還沒有"學號"關鍵字，課程名稱和學分也無法記錄入資料庫。
刪除異常 ： 假設一批學生已經完成課程的選修，這些選修記錄就應該從資料庫表中刪除。但是，與此同時，課程名稱和學分信息也被刪除了。很顯然，這也會導致插入異常。2.1.2 解決方案
把選課關系表SelectCourse改為如下三個表：學生：Student(學號，姓名, 年齡，性別，系別，系辦地址、系辦電話)；課程：Course(課程名稱, 學分)；選課關系：SelectCourse(學號, 課程名稱, 成績)。2.2 第三範式（3NF）實例分析
接著看上面的學生表Student(學號，姓名, 年齡，性別，系別，系辦地址、系辦電話)，關鍵字為單一關鍵字"學號"，因為存在如下決定關系：
（學號）→ (姓名, 年齡，性別，系別，系辦地址、系辦電話)
但是還存在下面的決定關系
(學號) → (所在學院)→(學院地點, 學院電話)
即存在非關鍵欄位"學院地點"、"學院電話"對關鍵欄位"學號"的傳遞函數依賴。
它也會存在數據冗餘、更新異常、插入異常和刪除異常的情況。 (數據的更新，刪除異常這里就不分析了，可以參照2.1.1進行分析)
根據第三範式把學生關系表分為如下兩個表就可以滿足第三範式了：
學生：(學號, 姓名, 年齡, 性別，系別)；
系別：(系別, 系辦地址、系辦電話)。
總結
上面的資料庫表就是符合I,II,III範式的，消除了數據冗餘、更新異常、插入異常和刪除異常。

希望對你有幫助哈