在許多領域，尤其是心理學，
為了檢驗壹個假設，發現壹些有趣的現象。實驗者將設計具有驗證目的的實驗。
有些實驗是經典的，被後人以相同或相似的目的多次使用，從而形成了實驗範式。
實驗範式包括實驗的目的、具體過程和手段，以及是否是被試內部或被試之間或混合實驗設計。
壹句話:
實驗範式可以作為具體實驗的模板，並根據其新的要求進行修改。
比如在決策心理學中，經典的實驗範式有:愛荷華遊戲任務、劍橋遊戲任務等。
設計範式(範式、數據庫設計範式、數據庫設計範式)是符合壹定層次的關系模式的集合。數據庫的建設必須遵循壹定的規則。在關系數據庫中，這條規則是壹個範例。關系數據庫中的關系必須滿足壹定的要求，即滿足不同的範式。目前關系數據庫有六種範式:第壹範式(1NF)、第二範式(2NF)、第三範式(3NF)、第四範式(4NF)、第五範式(5NF)、第六範式(6NF)。滿足最低要求的範式是第壹範式(1NF)。在第壹範式的基礎上，進壹步滿足更多要求的稱為第二範式(2NF)，其他範式以此類推。壹般來說，壹個數據庫只需要滿足第三範式(3NF)。下面用例子介紹壹下第壹範式(1NF)、第二範式(2NF)、第三範式(3NF)。
在創建數據庫的過程中，規範化就是將數據庫轉換成壹些表的過程。這種方法可以使從數據庫中得到的結果更加清晰。這可能會導致數據庫中出現重復數據，從而導致創建冗余表。規範化是在確定數據庫中的數據元素和關系，並定義所需的表和每個表中的項目之後的詳細過程。
下面是壹個正常化的例子:客戶項目購買購買價格托馬斯襯衫$40瑪麗亞tennisshoes $35伊芙琳襯衫$40帕哈羅褲子$25。
如果上表用於保存商品的價格，並且您想刪除其中壹個客戶，那麽您還必須刪除壹個價格。常態化就是為了解決這個問題。可以把這個表變成兩個表，壹個存儲每個客戶的信息和他買的物品，另壹個存儲每個產品的信息和它的價格，這樣添加或刪除壹個表都不會影響另壹個表。
幾種關系數據庫設計範式介紹
1第壹範式(1NF)
在任何關系數據庫中，第壹範式(1NF)是對關系模式的基本要求，不滿足第壹範式(1NF)的數據庫不是關系數據庫。
第壹範式(1NF)是指數據庫表的每壹列都是不可分割的基本數據項，同壹列不能有多個值，即實體中的壹個屬性不能有多個值或重復屬性。如果有重復的屬性，您可能需要定義壹個新的實體。新實體由重復的屬性組成，新實體與原始實體之間是壹對多的關系。在第壹範式(1NF)中，表的每壹行只包含壹個信息實例。例如，對於圖3-2中的員工信息表，不能在壹列中顯示所有的員工信息，也不能在壹列中顯示兩列或多列；員工信息表的每壹行只代表壹個員工的信息，壹個員工的信息在表中只出現壹次。簡而言之，第壹範式是非重復列。
2第二範式(2NF)
第二範式(2NF)是在第壹範式(1NF)的基礎上建立的，即要滿足第二範式(2NF)，必須先滿足第壹範式(1NF)。第二範式(2NF)要求數據庫表中的每個實例或行必須是唯壹可區分的。為了區分，通常需要在表中添加壹列來存儲每個實例的唯壹標識。如圖3-2所示，雇員編號(emp_id)列被添加到雇員信息表中。因為每個員工的員工號都是唯壹的，所以每個員工都可以被唯壹地區分。這個唯壹的屬性列稱為主鍵或主鍵和主代碼。
第二範式(2NF)要求實體的屬性完全依賴於primary關鍵字。所謂完全依賴，就是不能有壹個屬性只依賴於main關鍵字的壹部分。如果有，那麽這個屬性和main關鍵字的這壹部分要分開，形成壹個新的實體，新實體和原實體的關系是壹對多的。為了區分，通常需要在表中添加壹列來存儲每個實例的唯壹標識。簡而言之，第二種範式是非主屬性不部分依賴於主關鍵字。
3第三範式(3NF)
要滿足第三範式(3NF)，首先要滿足第二範式(2NF)。簡而言之，第三範式(3NF)要求數據庫表不包含已經包含在其他表中的非主關鍵字信息。例如，有壹個部門信息表，其中每個部門都有部門編號(dept_id)、部門名稱、部門檔案等信息。那麽在圖3-2的員工信息表中列出部門編號後，部門名稱、部門檔案等部門相關信息就不能再添加到員工信息表中了。如果沒有部門信息表，就要按照第三範式(3NF)來構造，否則會有很多數據冗余。簡而言之，第三種範式是屬性不依賴於其他非主屬性。
數據庫設計三種範式的應用實例分析
數據庫的設計範式是數據庫設計需要滿足的規範。符合這些規範的數據庫結構簡潔明了，同時也不會出現插入、刪除、更新等異常操作。反之，就是亂七八糟，不僅給數據庫程序員制造麻煩，而且看起來很惡心，可能會存儲很多不必要的冗余信息。
設計範式很難理解嗎？不，我們在大學課本裏被給了壹堆數學公式。當然，我們無法理解它們，也無法記住它們。所以我們中的許多人根本沒有按照範例來設計數據庫。
從本質上來說，設計範式可以用非常生動簡潔的語言清晰地表述和理解。本文將以通俗的方式解釋範式，並以作者設計的壹個簡單論壇的數據庫為例，說明如何將這些範式應用到實際項目中。
範式解釋
第壹範式(1NF):數據庫表中的字段都是單壹屬性，不能再細分。這個單壹屬性由基本類型組成，包括整數、實數、字符、邏輯、日期等等。
例如，以下數據庫表符合第壹範式:
字段1字段2字段3字段4
並且這樣的數據庫表不符合第壹範式:
字段1字段2字段3字段4
字段3.1字段3.2
顯然，在任何當前的關系數據庫管理系統(DBMS)中，傻瓜都不可能做出不符合第壹範式的數據庫，因為這些DBMS不允許將數據庫表的壹列分成兩列或更多列。因此，您不可能在現有的DBMS中設計不符合第壹範式的數據庫。
第二範式(2NF):非關鍵字段對數據庫表中任何候選關鍵字段都不存在部分函數依賴(部分函數依賴是指組合關鍵字中的某些字段決定非關鍵字段的情況)，即所有非關鍵字段完全依賴於任何壹組候選關鍵。
假設選課關系表為SelectCourse(學號，姓名，年齡，課程名稱，成績，學分)，關鍵字為組合關鍵字(學號，課程名稱)，因為有以下決定關系:
(學號，課程名稱)→(姓名，年齡，成績，學分)
這個數據庫表不滿足第二範式，因為存在以下決定性關系:
(課程名稱)→(學分)
(學號)→(姓名，年齡)
也就是說，存在組合關鍵字中的字段確定非關鍵字的情況。
因為不符合2NF，所以這個選課關系表會存在以下問題:
(1)數據冗余:
同壹門課被n個學生選擇，“學分”重復n-1次；同壹個學生上了M門課，名字和年齡重復了m-1次。
(2)更新異常:
如果調整了某門課程的學分，數據表中所有行的“學分”值都要更新，否則會出現同壹門課程的不同學分。
(3)插入例外:
假設要開壹門新課程，還沒有人學過。這樣，由於沒有“學號”關鍵字，數據庫中無法記錄課程名稱和學分。
(4)刪除例外:
假設壹組學生已經完成了選修課，這些選修記錄應該從數據庫表中刪除。但同時，課程名稱和學分信息也被刪除。顯然，這也會導致插入異常。
將選課關系表更改為以下三個表:
學生:學生(學號、姓名、年齡)；
課程:課程(課程名稱、學分)；
選課關系:SelectCourse(學號，課程名稱，年級)。
這樣的數據庫表符合第二範式，消除數據冗余，更新異常，插入異常，刪除異常。
此外，所有單個關鍵字數據庫表都符合第二範式，因為不可能有組合關鍵字。
第三範式(3NF):在第二範式的基礎上，如果非關鍵字段對任何候選關鍵字段不存在傳遞函數依賴，則數據表符合第三範式。所謂傳遞函數依賴，是指如果存在“A → B → C”的決定性關系，則C的傳遞函數依賴於A..因此，滿足第三範式的數據庫表不應具有以下依賴關系:
關鍵字段→非關鍵字段x →非關鍵字段Y
假設學生關系表是學生(學號、姓名、年齡、學院、學院地點、學院電話)，關鍵字是單個關鍵字“學號”，因為有以下決定關系:
(學號)→(姓名、年齡、學院、學院地點、學院電話)
該數據庫符合2NF，但不符合3NF，因為存在以下決定性關系:
(學號)→(學院)→(學院地點，學院電話)
即非關鍵字段“學院位置”和“學院電話”依賴於關鍵字段“學號”的傳遞函數。
它還會有數據冗余、更新異常、插入異常和刪除異常，讀者可以自行分析。
將學生關系表分為以下兩個表:
學生:(學號，姓名，年齡，學院)；
學院:(學院，地點，電話)。
這樣的數據庫表符合第三範式，消除數據冗余，更新異常，插入異常，刪除異常。
Bowes-Cod範式(BCNF):在第三範式的基礎上，如果任何字段對任何候選關鍵字段不存在傳遞函數依賴，則數據庫表符合第三範式。
假設倉庫管理關系表是StorehouseManage(倉庫ID，存儲物品ID，管理員ID，數量)，有壹個管理員只在壹個倉庫工作；倉庫可以儲存各種物品。該數據庫表中有以下決定性關系:
(倉庫ID，存儲項目ID) →(管理員ID，數量)
(管理員ID，存儲項目ID) →(倉庫ID，數量)
因此，(倉庫ID，存儲項ID)和(管理員ID，存儲項ID)是StorehouseManage的候選鍵，表中唯壹的非鍵字段是quantity，符合第三範式。然而，由於以下決定性的關系:
(倉庫ID) →(管理員ID)
(管理員ID) →(倉庫ID)
即存在關鍵字段決定關鍵字段的情況，所以不符合BCNF範式。它會出現以下異常情況:
(1)刪除異常:
當倉庫被清空時，所有的“存儲項目ID”和“數量”信息被刪除，同時，“倉庫ID”和“管理員ID”信息也被刪除。
(2)插入例外:
當倉庫不存儲任何東西時，您不能向倉庫分配管理員。
(3)更新異常:
如果倉庫有了新的管理員，表中所有行的管理員ID都將被修改。
倉庫管理關系表被分解成兩個關系表:
倉庫管理:StorehouseManage(倉庫ID，管理員ID)；
倉庫:倉庫(倉庫標識、存儲項目標識、數量)。
這樣的數據庫表符合BCNF範式，消除了刪除異常、插入異常和更新異常。
範例應用
讓我們壹步壹步地獲得壹個論壇數據庫，包含以下信息:
(1)用戶:用戶名、電子郵件、主頁、電話號碼和聯系地址。
(2)帖子:帖子標題、帖子內容、回復標題、回復內容。
我們第壹次將數據庫設計為只有表:
用戶名，郵箱主頁，電話聯系地址，帖子標題，帖子內容，回復標題，回復內容。
該數據庫表符合第壹範式，但沒有壹組候選關鍵字可以確定數據庫表的整行，唯壹關鍵字字段用戶名不能完全確定整個元組。我們需要添加“發布ID”和“回復ID”字段，也就是說，將表修改為:
用戶名電子郵件主頁電話聯系地址發帖ID發帖標題發帖內容回復ID回復標題回復內容
這樣，數據表中的關鍵字(用戶名、發帖ID、回復ID)就可以確定整行:
(用戶名、發帖ID、回復ID) →(郵箱、主頁、電話號碼、聯系地址、發帖標題、發帖內容、回復標題、回復內容)
然而，這樣的設計並不符合第二範式，因為存在以下決定性關系:
(用戶名)→(電子郵件、主頁、電話號碼、聯系地址)
(發帖ID) →(發帖標題，發帖內容)
(回復ID) →(回復標題，回復內容)
也就是說，非關鍵字段的某些功能依賴於候選關鍵字段。顯然，這種設計會導致大量的數據冗余和操作異常。
我們將數據庫表分解為(帶下劃線的關鍵字):
(1)用戶信息:用戶名、郵箱、主頁、電話、聯系地址。
(2)帖子信息:帖子ID、標題、內容。
(3)回復信息:回復ID、標題、內容。
(4)發布:用戶名，發布ID
(5)回復:發帖ID，回復ID
這種設計符合1，2，3範式和BCNF範式的要求，但這種設計是最好的嗎？
不壹定。
觀察發現，第4項中“用戶名”和“發帖ID”的關系是1: n，所以我們可以將“發帖”合並到第2項“發帖信息”中；第5項“回復”中“發帖ID”和“回復ID”的關系也是1: n，所以我們可以將“回復”合並到第3項“回復信息”中。這可以在壹定程度上減少數據冗余，新的設計是:
(1)用戶信息:用戶名、郵箱、主頁、電話、聯系地址。
(2)帖子信息:用戶名、帖子ID、標題、內容。
(3)回復信息:發帖ID、回復ID、標題、內容。
數據庫表1顯然滿足所有範式的要求；
數據庫表2中的關鍵字段“發文ID”存在壹些非關鍵字段“標題”和“內容”的函數依賴，不符合第二範式的要求，但這種設計不會導致數據冗余和操作異常。
在數據庫表3中，還存在壹些非關鍵字段“title”和“content”對關鍵字段“reply ID”的函數依賴，不符合第二範式的要求，但類似於數據庫表2，這種設計不會導致數據冗余和操作異常。
可見不壹定要符合正規形式的要求。對於1: n的關系，當1的壹邊與N的另壹邊合並時，N的另壹邊不再滿足第二範式，但這個設計更好！
對於M: N的關系，M的壹邊或N的壹邊不能合並到另壹邊，會導致不符合範式的要求，以及操作異常和數據冗余。
對於1: 1的關系，我們可以把左邊的1或者右邊的1合並到另壹邊。設計不會滿足範式的要求，但不會導致異常操作和數據冗余。
結論
符合範式要求的數據庫設計結構清晰，同時可以避免數據冗余和異常操作。這並不意味著不符合範式要求的設計壹定是錯誤的。在數據庫表中存在1: 1或1: n關系的特殊情況下，合並不符合範式的要求是合理的。
當我們設計數據庫時，我們必須始終考慮範式的需求。