《數據庫原理及應用》第2版 課件 第10講 范式及反范式設計_第1頁
《數據庫原理及應用》第2版 課件 第10講 范式及反范式設計_第2頁
《數據庫原理及應用》第2版 課件 第10講 范式及反范式設計_第3頁
《數據庫原理及應用》第2版 課件 第10講 范式及反范式設計_第4頁
《數據庫原理及應用》第2版 課件 第10講 范式及反范式設計_第5頁
已閱讀5頁,還剩16頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

《數據庫原理及應用》數據庫虛擬教研室制作數據庫目錄03

范式理論01

規(guī)范化概念02函數依賴第10章范式及反范式設計04

范式設計05

反范式設計規(guī)范化概念【例】設計一個教學管理數據庫,希望從該數據庫中經常得到下面的有關信息:學號、姓名、年齡、性別、系、系主任姓名、課程號、成績等。參考設計的關系模式如下:SCS(sno,sname,cno,cname,term,credit,grade)問題:這是不是一個理想的關系模式呢?規(guī)范化概念規(guī)范化概念關系模式SCS存在的問題是:①冗余大:表中相同信息多次存儲,浪費存儲空間。②插入異常:若沒有招生,課程信息無法插入到數據庫中。③刪除異常:刪除課程就刪除了學生記錄。④更新異常:由于信息存在大量冗余,更新信息時要付出很大的代價。規(guī)范化概念結論:SCS關系模式不是一個理想的模式。原因:由于模式中存在的數據依賴引起的。解決方法:通過分解關系模式來消除其中不合適的數據依賴

數據依賴是各屬性間的關聯,包括函數依賴、多值依賴和連接依賴。這里學習函數依賴。函數依賴定義1:設R(U)是屬性集U上的關系模式。X,Y是U的子集。對于X的每一個具體值,Y都有唯一的值與之對應,則稱“X函數決定Y”或“Y函數依賴于X”,記作X

Y。稱X為決定因子,Y是依賴因子。X

Y為關系模式R(U)的一個函數依賴。如:snosname,(sno,cno)

grade注意:屬性間的函數依賴完全來自于現實世界的語義,而不是憑主

觀臆斷的。函數依賴函數依賴與屬性之間的對應取值有關。在關系模式中,如果屬性X與Y的值有1:1關系時,則存在函數依賴X→Y,Y→X,如當學生不重名時,sno→sname,sname→sno。如果屬性X與Y的值有m:1關系時,則只存在函數依賴X→Y,例如:“sno”與“dept”之間為m:1聯系,所以有sno→dept。如果屬性X與Y的值有m:n關系時,則X與Y之間不存在任何函數依賴關系。如sno和cno之間不存在任何函數依賴關系。函數依賴定義2:在關系模式R(U)中,如果X

Y,并且對于X的任何一個真子集X

都有XY,則稱Y完全函數依賴于X,記作XY。f如果Y部分函數依賴于X,則X必定是組合屬性。若(sno,cno)sname,snosname,則(sno,cno)sname。

p若X

Y,并且對于X的某一個真子集X

(X

X),有XY,則稱Y部分函數依賴于X,記作:XY。p函數依賴定義3:在關系模式R(U)中,如果X

Y,(Y

X),Y

X,Y

Z,則稱Z傳遞函數依賴于X,記作XZ

。t【例10.3】在STD(sno,dept,dname),有sno→dept,dept→dname,且deptsno,則sno→dname。t范式理論定義4:設有關系模式R(U),其所有的屬性都是不可分的基本數據項,則稱R屬于第一范式,簡稱1NF,記作R1NF。在任何一個關系數據庫系統(tǒng)中,第一范式是對關系模式的一個最起碼的要求。不滿足第一范式的數據庫模式不能稱為關系數據庫?!纠筷P系模式SCD(sno,cno,sname,sage,dept,dname,grade)SCD1NF范式理論定義5:設有關系模式R(U)1NF

,如果其所有非主(碼)屬性都完全函數依賴于碼,則稱R屬于第二范式,簡稱2NF,記作R2NF。即關系模式中不存在非主屬性對碼的部分函數依賴問題?!纠繛榱俗岅P系模式SCD(sno,cno,sname,sage,dept,dname,grade)滿足第二范式,

分解SCD為兩個關系模式:

S(sno,sname,sage,dept,dname),S2NFSC(sno,cno,grade),SC2NF范式理論定義6:設有關系模式R(U)2NF,如果其所有非主屬性都不傳遞函數依賴于碼,則稱R屬于第三范式,簡稱3NF,記作R3NF。即關系模式中不存在非主屬性對碼的傳遞函數依賴關系?!纠繛榱俗孲(sno,sname,sage,dept,dname)滿足第三范式,將S分解為兩個關系模式: ST(sno,sname,sage,dept),ST3NF SD(dept,dname),SD3NF范式設計范式設計:一般是將一個符合1NF的關系模式分解為符合3NF的過程。1NF2NF3NF消除非主屬性對碼的部分依賴關系消除非主屬性對碼的傳送依賴關系范式設計【例10.5】:已知關系模式R(A,B,C,D,E),R上存在的函數依賴有F={AB→E,B→C,C→D},求:

①關系模式的碼;

②該關系模式滿足幾范式,為什么?

③將R分解為高一級的范式,并說明理由。范式設計解:①根據函數依賴集F={AB→E,B→C,C→D}由于(A,B)能夠決定所有的屬性集合,且沒有任一真子集能夠決定所有的屬性集合,所以R的碼為(A,B)。③將R分解為R1,R2:

R1(A,B,E),F1={(A,B)→E};

R2(B,C,D),F2={B→C,C→D}。R1中:不存在非主屬性對碼的部分函數依賴,所以R1∈2NF。R2中:碼為B,則非主屬性為C,D,不存在非主屬性對碼的部分函數依賴,所以R2∈2NF。②已知R的碼為(A,B),所以非主屬性為C,D,E?!逨中存在B→C∴存在非主屬性C對碼(A,B)的部分函數依賴,所以R∈1NF。反范式設計問題:傳統(tǒng)的數據庫規(guī)范化設計旨在減少數據冗余,提高數據的一致性和完整性。然而,在某些應用場景下,嚴格的規(guī)范化設計可能會導致查詢效率低下,因為需要頻繁地進行表連接操作。反范式設計(也稱為逆規(guī)范化或去規(guī)范化設計)是一種有意違反數據庫規(guī)范化規(guī)則的設計方法。這種做法通常是為了提高查詢性能而犧牲數據冗余和一致性。在某些情況下,特別是對于讀取密集型的應用程序,反范式設計可以顯著減少查詢復雜性和執(zhí)行時間。反范式設計的主要方法包括:增加冗余:通過復制數據來減少查詢中所需的連接操作數量。匯總數據:預先計算和存儲聚合結果,而不是每次查詢時動態(tài)計算。合并表:將多個表合并為一個大表以減少聯接操作。反范式設計【例10.7】在教學管理系統(tǒng)中,經常用到的一個業(yè)務需求是查詢某學生某門課程的成績,返回的信息包含學號、姓名、課程號、課程名、成績等信息。給出反范式設計的關系模式如下。student(sno,sname,sex,dept,birthday,totalcredit,remarks)

∈3NFcourse(cno,cname,term,ctime,credit)

∈3NFscore(sno,cno,sname,cname,grade)

∈1NF分析:(1)student表中totalcredit的數據可以通過credit和grade兩個字段計算獲得,增加了冗余存儲,而規(guī)范化的目的之一是減少冗余,因此屬于反范式設計;(2)在score表中增加sname,cname兩個字段,增加了冗余存儲,直接降低了范式,屬于反范式設計。反范式設計反范式設計也會帶來更新異常問題:因為course表的cname在score表中被重復存儲,若course表的cname值改變了,則在score表中的cname值也要發(fā)生變化,否則就發(fā)生更新異常。解決方法:在course表中設計一個更新觸發(fā)器來進行級聯更新。反范式設計設計步驟:(1)創(chuàng)建冗余表score1:CREATETABLEscore1ASSELECTs.sno,o,sname,cname,gradeFROMstudentsJOINscorescONs.sno=sc.snoJOINcoursecONo=o;(2)在course上創(chuàng)建更新觸發(fā)器DELIMITER$$CREATETRIGGERtr_course_cnam

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論