核心思想
1.第一范式 要求消除拆分欄位至原子欄位，即不可再拆分；
2.第二范式 要求消除部分函式依賴，實作完全函式依賴;
3.第三范式 要求消除傳遞函式依賴;
函式依賴: A列屬性跟主鍵有關系
部分函式依賴: A列屬性只跟主鍵的部分屬性有關系
完全函式依賴: A列屬性跟主鍵的全部屬性有關系
傳遞函式依賴: A列屬性跟B列屬性有關系,B列屬性跟主鍵有關系
舉個栗子
栗子
除開道德問題,圖上資料庫表設計存在多少中設計缺陷
Q1:
’人物特色(渣男)'列還可以再拆分,解耦,能更適合變化(違背第一范式原則)
其實渣男型別還可以有很多的組合
Q2:
嚴重的傳遞依賴,(違背第三范式原則)
-----‘女友姓名’,‘學歷資訊(女友)’,'年齡’等等 都跟渣男沒有關系,不是渣男的本身屬性
如: 年齡→女友名→男友姓名
這會衍生出二個問題
Q2-1:
如果這系統突然進入了一個’萌新妹子’,她的資料錄入不合法,(她需要先遇到一個渣男)
這也太不公平,太扯了…也許她只是想認識博主這種 母胎單身,風度翩翩,才華橫溢的好人
Q2-2:
如果’趙六’這人,突然分手了,不渣了,洗掉這條記錄,那么’小紫’這個人,也被洗掉了,該系統查不到她資訊了
這也太扯了,其實她還可以…
改進2.0版
經過了第一范式,第三范式后,依然存在著問題
Q3:
在’渣男渣女關系表’中 —‘渣男編號’'渣女編號’組成復合主鍵
’年齡’屬性只與’渣女編號’有關(違背了第二范式),同理’醫院到訪次數’的設計正確
第二范式知識點
物體表中一般不會出現違反第二范式的情況，因為都是“一個”主鍵列，而關系表是兩個以上列的“復合”主鍵，故而關系表容易出現違反 第二范式 的情況，
主要是該關系表非主鍵外的屬性，本該屬于相關的某個物體表的，卻放到了該關系表中，這使得該屬性不能通過該關系表的復合主鍵唯一確定，DML操作會發生錯誤；
改進3.0
一潭訓麗的分割線,三大范式講完,現在難度升級
難度升級
現在我們添加了一些表,
上面的圖表都滿足三大范式,都已經不可拆分,都跟主鍵完全依賴,也沒有傳遞依賴
但在使用體驗上還是有設計問題
Q4:
’寶寶表’中 名字為AA的寶寶他媽媽是誰?
查詢順序是: 寶寶表→接生記錄表→住院記錄表→渣女表
這也太難受了,就像物理學的’功’一樣,萬事萬物皆在做’功’,需要消耗能量;
在IT界也一樣,這太消耗資源跟性能,太慢了.
反范式冗余欄位
我們為什么不冗余呢,讓寶寶編號或姓名(看需求),冗余到渣女表
衡量的度
- 當SQL關連查詢涉及到4張表時可考慮采用冗余欄位
- 一般的，每間隔一級增加一個冗余外鍵
衍生一個問題
如何保證冗余欄位資料的正確性（一致性）是反范式化的關鍵
- 如果在程式開發前設計的冗余欄位，可以在正常的業務邏輯程式中一并處理
- 如果是程式完成之后增加的冗余欄位，可以使用觸發器維護
- 對于OLAP中大量存在冗余欄位，可能需要使用單獨的處理任務進行維護
OLTP/OLAP科普
OLTP—On-Line Transaction Processing聯機事務處理程序（OLTP），也稱為面向交易的處理程序，
OLAP—軟體技術,使分析人員能夠從多方面角度觀察資訊，深入理解資料，
- OLTP系統的模型，需滿足第二范式（2NF）要求，設計上不追求滿足第三范式（3NF）
- OLTP系統中在完成范式化作業之后，對某些表，可以適當反范式化增加冗余欄位以提高資料訪問性能；在OLAP中采用的是面向問題的設計思想，應該大量使用反范式化冗余資訊
宣告
本文僅娛樂,不涉及任何種族歧視,性別歧視;
不代表博主價值觀,愛情觀
把我錄入改系統也只能填 編號,姓名,迷惑點
作業
4.0版本依然不完美,你們知道如果想知道孩子的父親是誰,應該怎么改嗎?
原文出處:https://www.chrisyoung777.com/blog/index.php/archives/16/
原創不易,未經博主允許，禁止轉載
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/15461.html
標籤：其他