在許多領域,尤其是心理學,
為了檢驗壹個假設,發現壹些有趣的現象。實驗者將設計具有驗證目的的實驗。
有些實驗是經典的,被後人以相同或相似的目的多次使用,從而形成了實驗範式。
實驗範式包括實驗的目的、具體過程和手段,以及是否是被試內部或被試之間或混合實驗設計。
壹句話:
實驗範式可以作為具體實驗的模板,並根據其新的要求進行修改。
比如在決策心理學中,經典的實驗範式有:愛荷華遊戲任務、劍橋遊戲任務等。
設計範式(範式、數據庫設計範式、數據庫設計範式)是符合壹定層次的關系模式的集合。數據庫的建設必須遵循壹定的規則。在關系數據庫中,這條規則是壹個範例。關系數據庫中的關系必須滿足壹定的要求,即滿足不同的範式。目前關系數據庫有六種範式:第壹範式(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關系的特殊情況下,合並不符合範式的要求是合理的。
當我們設計數據庫時,我們必須始終考慮範式的需求。