1，是數據的原子性
2，是確保每列都和主鍵相關，意思是：只做一件事
3，確保每列都和主鍵直接相關，而不是間接相關，意思是不能存在傳遞依賴
㈡ 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,籍貫)
㈢ 要求設計一個資料庫，達到第三範式 可以用E-R圖表示 ,,sql類
只要第三範式的話,2個表就可以表達了 比如倉庫系統,一個kind表(貨物種類),一個goods表(貨物表)
我用SQLServer來寫:
if exists(select * from sysobjects where name='kind')
drop table kind;
create table kind(
kid int identity(1,1) not null,
kname varchar(20) not null
)
if exists(select * from sysobjects where name='goods')
drop table goods;
create table goods(
gid int identity(1,1) not null,
kid int not null,
gname varchar(20) not null
)
--設置兩個表的主鍵
alter table kind add constraint pk_kind primary key(kid)
alter table goods add constraint pk_goods primary key(gid)
--設置外鍵約束
alter table goods add constraint fk_goods_kind foreign key(kid) references kind(kid)
kind表的kid是goods表的外鍵
一個kind可以對應多個goods,多個goods對應一個kind
㈣ SQL Server資料庫設計中的三大範式
是資料庫設計過程中邏輯設計階段所使用的技術，指關系資料庫中的關系滿足的條件，第一範式是滿足最低的要求，指資料庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重復的屬性。如果出現重復的屬性，就可能需要定義一個新的實體，新的實體由重復的屬性構成，新實體與原實體之間為一對多關系。在第一範式（1NF）中表的每一行只包含一個實例的信息。簡而言之，第一範式就是無重復的列。
在滿足第一範式要求的基礎上，要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列，以存儲各個實例的唯一標識。簡而言之，第二範式就是屬性完全依賴於主鍵。
在滿足第二範式的基礎上，要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那麼在的員工信息表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三範式（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、 第一範式（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中三範式的特點
sql中範式是這樣定義的：
設計範式（範式,資料庫設計範式,資料庫的設計範式）是符合某一種級別的關系模式的集合
範式說明
第一範式（1NF）：資料庫表中的欄位都是單一屬性的，不可再分。這個單一屬性由基本類型構成，包括整型、實數、字元型、邏輯型、日期型等
第二範式（2NF）：資料庫表中不存在非關鍵欄位對任一候選關鍵欄位的部分函數依賴（部分函數依賴指的是存在組合關鍵字中的某些欄位決定非關鍵欄位的情況），也即所有非關鍵欄位都完全依賴於任意一組候選關鍵字。
第三範式（3NF）：在第二範式的基礎上，數據表中如果不存在非關鍵欄位對任一候選關鍵欄位的傳遞函數依賴則符合第三範式。所謂傳遞函數依賴，指的是如果存在"A
→
B
→
C"的決定關系，則C傳遞函數依賴於A。因此，滿足第三範式的資料庫表應該不存在如下依賴關系：
關鍵欄位
→
非關鍵欄位x
→
非關鍵欄位y
滿足範式要求的資料庫設計是結構清晰的，同時可避免數據冗餘和操作異常。這並不意味著不符合範式要求的設計一定是錯誤的，在資料庫表中存在1：1或1：N關系這種較特殊的情況下，合並導致的不符合範式要求反而是合理的。
㈧ sql中三範式的特點
sql中範式是這樣定義的：
設計範式（範式,資料庫設計範式,資料庫的設計範式）是符合某一種級別的關系模式的集合
範式說明
第一範式（1NF）：資料庫表中的欄位都是單一屬性的，不可再分。這個單一屬性由基本類型構成，包括整型、實數、字元型、邏輯型、日期型等
第二範式（2NF）：資料庫表中不存在非關鍵欄位對任一候選關鍵欄位的部分函數依賴（部分函數依賴指的是存在組合關鍵字中的某些欄位決定非關鍵欄位的情況），也即所有非關鍵欄位都完全依賴於任意一組候選關鍵字。
第三範式（3NF）：在第二範式的基礎上，數據表中如果不存在非關鍵欄位對任一候選關鍵欄位的傳遞函數依賴則符合第三範式。所謂傳遞函數依賴，指的是如果存在"A → B → C"的決定關系，則C傳遞函數依賴於A。因此，滿足第三範式的資料庫表應該不存在如下依賴關系： 關鍵欄位 → 非關鍵欄位x → 非關鍵欄位y
滿足範式要求的資料庫設計是結構清晰的，同時可避免數據冗餘和操作異常。這並不意味著不符合範式要求的設計一定是錯誤的，在資料庫表中存在1：1或1：N關系這種較特殊的情況下，合並導致的不符合範式要求反而是合理的。
㈨ 有沒有用同一個表來介紹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範式的，消除了數據冗餘、更新異常、插入異常和刪除異常。
希望對你有幫助哈
㈩ 在商業軟體的開發中,資料庫只需要達到第幾範式就可以啦為什麼
理論上三範式。
但是實際的應用中沒有一個是嚴格按照三範式進行設計的。
這個和具體的業務需求有很大的關系。冗餘是經常發生的。通常會用於常用查詢業務中。
需要在資料庫的設計過程中，提煉常用業務。規劃查詢內容。權衡插入和查詢等等。
具體設計達到幾範式沒有固定的要求。