所謂第一範式(1NF)是指數據庫表的每一列都是不可分割的基本數據項,同一列中不能同時有多個值,即實體中的某個屬性不能有多個值或者不能有重複的屬性。若是出現重複的屬性,就可能須要定義一個新的實體,新的實體由重複的屬性構成,新實體與原實體之間爲一對多關係。在第一範式(1NF)中表的每一行只包含一個實例的信息。簡而言之,第一範式就是無重複的列。數據庫
在任何一個關係數據庫中,第一範式(1NF)是對關係模式的基本要求,不知足第一範式(1NF)的數據庫就不是關係數據庫。在當前的任何關係數據庫管理系統(DBMS)中,不可能作出不符合第一範式的數據庫,由於這些DBMS不容許你把數據庫表的一列再分紅二列或多列。所以,你想在現有的DBMS中設計出不符合第一範式的數據庫都是不可能的。cors
第二範式(2NF)是在第一範式(1NF)的基礎上創建起來的,即知足第二範式(2NF)必須先知足第一範式(1NF)。第二範式(2NF)要求數據庫表中的每一個實例或行必須能夠被惟一地區分。爲實現區分一般須要爲表加上一個列,以存儲各個實例的惟一標識。例如員工信息表中加上了員工編號(emp_id)列,由於每一個員工的員工編號是惟一的,所以每一個員工能夠被惟一區分。這個惟一屬性列被稱爲主關鍵字或主鍵、主碼。函數
第二範式(2NF)要求實體的屬性徹底依賴於主關鍵字。所謂徹底依賴是指不能存在僅依賴主關鍵字一部分的屬性,若是存在,那麼這個屬性和主關鍵字的這一部分應該分離出來造成一個新的實體,新實體與原實體之間是一對多的關係。爲實現區分一般須要爲表加上一個列,以存儲各個實例的惟一標識。簡而言之,第二範式就是屬性徹底依賴於主鍵。性能
這裏說的主關鍵字可能不僅有一個,有些狀況下是存在聯合主鍵的,就是主鍵有多個屬性。spa
舉例:設計
以學生選課爲例,每一個學生均可以選課,而且有這一門課程的成績,那麼若是將這些信息都放在一張表StuGrade(stuNo,stuName,age,sex,courseNo,courseName,credit,score)。3d
若是不仔細看,咱們會覺得這張表的主鍵是stuNo,可是當咱們看到最後一個score屬性之後,在想一想若是沒有課程信息,那麼哪裏有學生成績信息呢。因此這張表的主鍵是一個聯合主鍵(stuNo,corseNo),這個聯合屬性可以惟一肯定score屬性。那麼再看其餘信息,好比stuName只須要stuNo就可以惟一肯定,courseName只須要courseNo就可以惟一肯定,所以這樣就存在了部分依賴,不符合第二範式。若是要讓學生課程成績信息知足第二範式,那麼久須要將這張表拆分紅多張表,一張學生表Studnet(stuNo,stuName,age,sex),一張課程表Course(courseNo,courseName,credit),還有最後一張學生課程成績表StuGrade(stuNo,courseNo,score)。code
這樣就符合第二範式了。blog
知足第三範式(3NF)必須先知足第二範式(2NF)。簡而言之,第三範式(3NF)要求一個數據庫表中不包含已在其它表中已包含的非主關鍵字信息。開發
舉例:
每個員工都有一個所屬部門,假若有一個員工信息表Employee(emp_id,emp_name,emp_age,dept_id,dept_name,dept_info)。
這張員工信息表的主鍵是emp_id,由於這個屬性可以惟一肯定其餘全部屬性,好比知道員工編號emp_id之後,確定可以知道員工姓名,所屬部門編號,部門名稱和部門介紹。因此這裏dept_id不是主屬性,而是非主屬性。可是,咱們又能夠發現dept_name,dept_info這兩個屬性也能夠由dept_id這個非主屬性決定,即dept_name依賴dept_id,而dept_id依賴emp_id,這樣就存在了傳遞依賴。並且咱們能夠看出傳遞依賴的一個明顯缺點就是數據冗餘很是嚴重。
那麼如何解決傳遞依賴問題,其實很是簡單,咱們只須要將dept_name,dept_info這連個屬性刪除就能夠了,即Employee(emp_id,emp_name,emp_age,dept_id),而後再建立一個部門表Dept(dept_id,dept_name,dept_info)。
這樣若是要搜索某一個員工的部門信息dept_info,能夠經過數據庫鏈接來實現,查詢語句以下:
select e.emp_id,e.emp_name,d.dept_name from Employee e,Dept d where e.dept_id=d.dept_id
注意點: