1、數據庫設計方法與原則數據庫設計方法與原則-周波周波學習目標學習目標5.4.3.2.1.數據庫設計概述數據庫設計概述規范化規范化第一范式第一范式第二范式第二范式第三范式第三范式數據庫設計概述數據庫設計概述v 概述 這里我們思考兩個問題：修建茅屋需要設計嗎？修建大廈需要設計嗎？結論是：當數據庫比較復雜（如數據量大，表較多，業務關系復雜）時，我們需要先設計數據庫。數據庫設計概述數據庫設計概述n良好的數據庫設計能夠：n節省數據的存儲空間。n能夠保證數據的完整性。n方便進行數據庫應用系統的開發。n糟糕的數據庫設計：n數據冗余、存儲空間浪費。n內存空間浪費。n數據更新和插入的異常。數據庫規范化數據庫規范化

2、v規范化 在設計和操作維護數據庫時，關鍵的步驟就是要確保數據正確地分布到數據庫的表中。使用正確的數據結構，不僅便于對數據庫進行相應的存取操作，而且可以極大地簡化應用程序的其他內容（查詢、窗體、報表、代碼等）。正確進行表設計的正式名稱就是“數據庫規范化”。后面我們將通過實例來說明具體的規范化的工程。數據庫規范化數據庫規范化CREATE TABLE Student ( stuid INTEGER NOT NULL, -學生編號 stuname VARCHAR(200), -學生姓名 sclass VARCHAR(200),-班級名稱 coursename VARCHAR(20),-課程名稱 sde

3、gree FLOAT -課程分數 tname VARCHAR(20)-老師名字)請同學們結合表中的數據和結構觀察這張表會存在哪些缺點。數據庫規范化數據庫規范化v缺點：n數據冗余、存儲空間浪費。n內存空間浪費。n數據更新和插入的異常。數據庫規范化數據庫規范化v設計數據庫的一般步驟： 收集信息。 抽取對象。 抽取每個對象的屬性。 考慮對象之間的關系。 繪制E-R圖。 將E-R圖轉換為表格。 最后應用三大范式規范化表格。下面我們以一個BBS簡易論壇的數據庫設計為例來看看設計數據庫的步驟：數據庫規范化數據庫規范化v收集信息（與該系統有關人員進行交流、坐談，充分理解數據庫需要完成的任務） BBS論壇的基

4、本功能： 用戶注冊和登錄，后臺數據庫需要存放用戶的注冊信息和在線狀態信息； 用戶發貼，后臺數據庫需要存放貼子相關信息，如貼子內容、標題等； 論壇版塊管理：后臺數據庫需要存放各個版塊信息，如版主、版塊名稱、貼子數等；數據庫規范化數據庫規范化v標識對象（標識數據庫要管理的關鍵對象或實體） 實體一般是名詞： 用戶：論壇普通用戶、各版塊的版主。 用戶發的主貼。 論用戶發的跟貼（回貼）。數據庫規范化數據庫規范化v標識每個實體的屬性（Attribute）數據庫規范化數據庫規范化v標志對象之間的關系（Attribute） 跟貼和主貼有主從關系：我們需要在跟貼對象中表明它是誰的跟貼。 版塊和用戶有關系：從用戶

5、對象中可以根據版塊對象查出對應的版主用戶的情況。 主貼和版塊有主從關系：需要表明發貼是屬于哪個版塊的。 跟貼和版塊有主從關系：需要表明跟貼是屬于哪個版塊的。數據庫規范化數據庫規范化v繪制ER圖數據庫規范化數據庫規范化v將ER圖裝換為表格 將各實體轉換為對應的表，將各屬性轉換為各表對應的列。 標識每個表的主鍵列，需要注意的是：沒有主鍵的表添加ID編號列，它沒有實際含義，用于做主鍵或外鍵，例如用戶表中的“UID”列，版塊表中添加“SID”列，發貼表和跟貼表中的“TID”列 在表之間建立主外鍵，體現實體之間的映射關系 。數據庫規范化數據庫規范化v將ER圖裝換為表格數據庫規范化數據庫規范化v將ER圖裝

6、換為表格使用范式使用范式v數據庫基本概念回顧： 實體：現實世界中客觀存在并可以被區別的事物。比如“一個學生”、“一本書”、“一門課”等等。它也可以是虛擬的，比如說“老師與學校的關系”。 屬性：實體所具有的某一特性，比如說，“性別”是“人”的一個屬性。在關系數據庫中，屬性又是個物理概念，屬性可以看作是“表的一列”。 使用范式使用范式v數據庫基本概念回顧： 元組：表中的一行就是一個元組。 分量：元組的某個屬性值。在一個關系數據庫中，它是一個操作原子，即關系數據庫在做任何操作的時候，屬性是“不可分的”。否則就不是關系數據庫了。 碼：表中可以唯一確定一個元組的某個屬性（或者屬性組），如果這樣的碼有不止

7、一個，那么大家都叫候選碼，我們從候選碼中挑一個出來做老大，它就叫主碼。 使用范式使用范式v數據庫基本概念回顧： 主屬性：一個屬性只要在任何一個候選碼中出現過，這個屬性就是主屬性。 非主屬性：與上面相反，沒有在任何候選碼中出現過，這個屬性就是非主屬性。 外碼：一個屬性（或屬性組），它不是碼，但是它別的表的碼，它就是外碼。課堂示例一課堂示例一v范式（范式（6個）個）好了，上面已經介紹了我們掌握范式所需要的全部基礎概念，下面我們就來講范式。范式可以理解為一種規范等級，范式的包含關系。一個數據庫設計如果符合第二范式，一定也符合第一范式。如果符合第三范式，一定也符合第二范式第一范式第一范式v第一范式（1

8、NF）：屬性不可分。v第一范式的特點： 有主關鍵字 主鍵不能為空。 主鍵不能重復。 字段不可以再分。v下表是否滿足第一范式?StudyNo|Name | Sex | Contact20040901 john Male Email:,phone:22245620040901 mary Famale Email: phone:123455 違反第一范式的示例違反第一范式的示例以上的表格是否又滿足第一范式呢？課堂示例一課堂示例一注意：這兩種情況都不滿足第一范式。不滿足第一范式的數據庫，不是關系數據庫！所以，我們在任何關系數據庫管理系統中，做不出這樣的“表”來。第二范式第二范式v第二范式（2NF）：非

9、主屬性完全依賴于碼。 定義：如果關系模式R是第一范式的，而且關系中每一個非主屬性不部分依賴于主鍵，稱R是第二范式的。所以第二范式的主要任務就是滿足第一范式的前提下，消除部分函數依賴。 觀察這個表格是否滿足第二范式：StudyNo|Name | Sex | Email|Phone | ClassNo | ClassAddress01 john Male 222456 A樓2單元02 mary Famale 123455 A樓3第二范式的例子第二范式的例子v這個表完全滿足于第一范式主鍵由StudyNo和ClassNo組成，這樣才能定位到指定行，但是,ClassAddress部分依賴于關鍵字(Cla

10、ssNo-ClassAddress),所以要變為兩個表：表一StudyNo|Name | Sex | Email | Phone | ClassNo 01 john Male 222456 200401 02 mary famale 123455 200402 表二ClassNo | ClassAddress200401 A樓2200402 A樓3第二范式的例子第二范式的例子再來看一個例子：違反第二范式的例子違反第二范式的例子分析：一個學生上一門課，一定在特定某個教室。所以有（學生，課程）教室一個學生上一門課，一定是特定某個老師教。所以有（學生，課程）老師一個學生上一門課，他老師的職稱可以確定

11、。所以有（學生，課程）老師稱一個學生上一門課，一定是特定某個教材。所以有（學生，課程）教材一個學生上一門課，一定在特定時間。所以有（學生，課程）上課時間因此（學生，課程）是一個碼。然而，一個課程，一定指定了某個教材，一年級語文肯定用的是小學語文1那么就有課程教材。（學生，課程）是個碼，課程卻決定了教材，這就叫不完全依賴，或者說部分依賴。出現這樣的情況，就不滿足第二范式！思考： 那么，如果我們希望他滿足第二范式，仿照剛才的例子我們應該怎樣做了？違反第二范式的例子違反第二范式的例子解決：1、校長要新增加一門課程叫“微積分”，教材是大學數學，怎么辦？學生還沒選課，而學生又是主屬性，主屬性不能空，課程

12、怎么記錄呢，教材記到哪呢(插入異常)2、下學期沒學生學一年級語文（上）了，學一年級語文（下）去了，那么表中將不存在一年級語文（上），也就沒了小學語文1。這時候，校長問：一年級語文（上）用的什么教材啊？郁悶了吧?(刪除異常)3、校長說：一年級語文（上）換教材，換成大學語文。有10000個學生選了這么課，改動好大啊！改累死了郁悶了吧？（修改異常）那應該怎么解決呢？投影分解，將一個表分解成兩個或若干個表。違反第二范式的例子違反第二范式的例子解決：第三范式第三范式v第三范式（3NF）（不依賴于其它非主屬性消除傳遞依賴 ）。例:StudyNo|Name|Sex| Email|bounsLevel|bouns40901 john M 良 $100040902 mary famale 差 $600這個完全滿足了第二范式,但是bounsLevel和bouns存在傳遞依賴。第三范式第三范式解決：更改為：表一：StudyNo|Name |Sex| Email | bouunsNo20040901 john Male 120040902 mary Famale 2表二：bounsNo | bounsLevel | bouns1 優秀 $10002 良 $600 第三范式第三范式在來看一個