您好,登錄后才能下訂單哦!
1 概述
一般地,在進行數據庫設計時,應遵循三大原則,也就是我們通常說的三大范式,即第一范式要求確保表中每列的原子性,也就是不可拆分;第二范式要求確保表中每列與主鍵相關,而不能只與主鍵的某部分相關(主要針對聯合主鍵),主鍵列與非主鍵列遵循完全函數依賴關系,也就是完全依賴;第三范式確保主鍵列之間沒有傳遞函數依賴關系,也就是消除傳遞依賴。
本文將基于三大范式原則,結合具體的實例做簡要分析,難度系數:基礎。
2 第一范式
2.1 例子引入
根據如下場景設計出兩種數據表,請分析兩種數據表的合理性。
問題:需求描述:數據庫系統中需要一個實體表,該表用來存儲用戶信息,其中“地址”這個屬性,要求查詢到省份、城市和詳細地址。
2
3 具體例子:
4 姓名:張紅欣; 性別:男; 年齡:26歲; 聯系電話:0378-23459876;省份:河南省;城市:開封; 詳細地址:朝陽區新華路23號;
5 姓名:王艷; 性別:女; 年齡:25歲; 聯系電話:021-2348768; 省份:貴州省;城市:貴陽市;詳細地址:南明區南明區獅峰路6號;
6 姓名:汪梅; 性別:女; 年齡:21歲; 聯系電話:0571-3876450; 省份:浙江省;城市:杭州市;詳細地址:濱江區濱康路352號;
第一種表設計
第二種表設計
2.2 分析
第一種表設計不滿足第一范式,為什么不滿足第一范式?因為region列不具有原子性,能拆分成省份、市和具體地址;
3 第二范式
3.1 例子引入
根據如下場景設計出兩種數據表,請分析兩種數據表的合理性。
需求描述:設計一個訂單信息表,訂單有多種商品,將訂單編號和商品編號作為聯合主鍵。
第一種表設計
第二種表設計
3.2 分析
第一種表設計不滿足第二范式,訂單編號和商品編號作為聯合主鍵,由于商品名稱,單位,價格這幾列只與商品編號有關,與訂單編號無關,因此與主鍵(聯合主鍵)無關,違反范式第二原則;
第二種表設計滿足第二范式,把第一種設計表進行拆分,把商品信息分離到另一個表中,把訂單項目表也分離到另一個表中。
4 第三范式
4.1 例子引入
根據如下場景設計出兩種數據表,請分析兩種數據表的合理性。
需要在數據庫中存儲如下信息:
學生編號;學生卡號;用戶ID號;操作員級別;操作日期;操作時間;
第一種表設計
第二種表設計
4.2 分析
第一種表設計不滿足第三范式,在表中,一個UserID能確定一個UserLevel。這樣,UserID依賴于StudentNo和CardNo,而UserLevel又依賴于UserID,這就導致了傳遞依賴,3NF就是消除這種依賴。
第二種表設計滿足第三范式,將第一種表格拆分成成兩個表格。
5 參考文獻
【01】http://www.cnblogs.com/springside-example/archive/2011/10/06/2530207.html
【02】http://www.cnblogs.com/linjiqin/archive/2012/04/01/2428695.html#undefined
6 版權
感謝您的閱讀,若有不足之處,歡迎指教,共同學習、共同進步。博主網址:http://www.cnblogs.com/wangjiming/。極少部分文章利用讀書、參考、引用、抄襲、復制和粘貼等多種方式整合而成的,大部分為原創。如您喜歡,麻煩推薦一下;如您有新想法,歡迎提出,郵箱:2016177728@qq.com。可以轉載該博客,但必須著名博客來源。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。