《數據庫系統(tǒng)與應用技術》課件 第8章 關系規(guī)范化理論_第1頁
《數據庫系統(tǒng)與應用技術》課件 第8章 關系規(guī)范化理論_第2頁
《數據庫系統(tǒng)與應用技術》課件 第8章 關系規(guī)范化理論_第3頁
《數據庫系統(tǒng)與應用技術》課件 第8章 關系規(guī)范化理論_第4頁
《數據庫系統(tǒng)與應用技術》課件 第8章 關系規(guī)范化理論_第5頁
已閱讀5頁,還剩51頁未讀, 繼續(xù)免費閱讀

下載本文檔

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

文檔簡介

第8章關系規(guī)范化理論主講:何廣贏時間:2026/01/01CONTENTS目錄8.1關系規(guī)范化概述理解關系規(guī)范化的必要性,掌握模式分解的核心思想,學習如何通過規(guī)范化解決數據冗余和操作異常問題8.2數據依賴深入理解函數依賴的定義和分類,掌握Armstrong公理系統(tǒng),學習候選碼和最小函數依賴集的求解方法8.3關系模型的范式系統(tǒng)學習1NF、2NF、3NF和BCNF的定義、特點及相互關系,掌握不同范式的規(guī)范化要求和實際應用場景8.4關系模式的分解理解無損連接分解和保持函數依賴分解的原理與方法,學習如何進行既保持無損連接又保持函數依賴的模式分解核心目標:掌握關系規(guī)范化理論,為關系數據庫設計提供理論基礎共4個主要章節(jié)8.1關系規(guī)范化概述018.1.1關系規(guī)范化的必要性關系規(guī)范化的必要性核心問題如果一個關系沒有經過規(guī)范化而隨意進行數據庫的設計,會導致數據冗余和操作異常等嚴重問題,影響數據庫的性能和數據完整性。實例:患者醫(yī)生預約表該關系包含患者、醫(yī)生和預約三類信息,共14個屬性:患者信息:患者號、姓名、出生年月、性別、聯(lián)系方式、住址醫(yī)生信息:醫(yī)生號、姓名、性別、專業(yè)、工作年限預約信息:預約原因、預約日期、預約時間1數據冗余患者和醫(yī)生的基本信息反復出現(xiàn),浪費存儲空間,易造成數據不一致2插入異常新醫(yī)生無患者預約時無法錄入,因缺少患者號(主鍵)導致插入失敗3更新異常修改患者聯(lián)系方式需修改多條記錄,易造成數據不一致性4刪除異常刪除離職醫(yī)生信息時,可能誤刪只預約該醫(yī)生的患者信息關鍵洞察:由于存在以上問題,"患者醫(yī)生預約表"在實際使用中會出現(xiàn)很多問題,它并不是一個規(guī)范的關系。需要通過模式分解使其規(guī)范化。問題一:數據冗余數據冗余:存儲空間的浪費與數據不一致風險定義數據冗余是指在數據庫中的關系存在重復列的情況。在一個關系中引入了兩個或兩個以上的不同實體時,這些實體的基本信息會不斷反復出現(xiàn)。示例分析在"患者醫(yī)生預約表"中,患者和醫(yī)生的基本信息不斷重復:1患者信息重復吳英俊、陳楠楠的基本信息多次出現(xiàn)2醫(yī)生信息重復李明、陳艾明、吳晴晴的基本信息反復出現(xiàn)患者醫(yī)生預約表示例(部分數據)患者號患者姓名聯(lián)系方式醫(yī)生號醫(yī)生姓名專業(yè)4吳英俊135456789335吳晴晴骨科4吳英俊135456789334陳艾明中醫(yī)護理5陳楠楠188456789995吳晴晴骨科5陳楠楠188456789994陳艾明中醫(yī)護理問題:吳英俊和陳楠楠的患者信息完全重復,吳晴晴和陳艾明的醫(yī)生信息也完全重復后果一:浪費存儲空間,冗余數據占用額外磁盤空間后果二:易造成數據不一致,更新時可能漏改部分記錄問題二:插入異常插入異常:主鍵約束導致的數據插入失敗定義插入異常是指插入的數據違反了數據庫對象的規(guī)定,而導致插入不成功的異常結果(例如在約束為非空的列插入空值)。典型場景醫(yī)院引進新醫(yī)生該醫(yī)院新引進了一位醫(yī)生,但還未有患者預約該醫(yī)生主鍵約束沖突該醫(yī)生沒有患者預約,那么他就缺少患者號,而患者號為主鍵不能為空插入失敗因此該醫(yī)生信息不能錄入正常系統(tǒng),導致插入異常嘗試插入新醫(yī)生信息(失敗案例)患者號患者姓名醫(yī)生號醫(yī)生姓名專業(yè)NULLNULL6王強心內科插入失敗原因患者號作為主鍵不能為空(NOTNULL約束),因此無法插入只有醫(yī)生信息的記錄關鍵洞察:插入異常的根本原因是關系模式中混合了多個實體的信息,導致新增一行時必須同時提供多個實體的數據。問題三:更新異常更新異常:復雜更新操作導致的數據不一致定義更新異常是指對數據庫數據進行更新操作后數據不一致、數據不完整等問題。如果一位患者預約了多名醫(yī)生,庫中就會存儲他的多條記錄。典型場景修改患者聯(lián)系方式現(xiàn)實中只需修改一次,而庫中必須將該患者的所有預約記錄中的聯(lián)系方式都修改一遍數據不一致風險這種復雜的更新操作稍有不慎就有可能漏改部分記錄,造成數據不一致性更新操作示例:修改患者聯(lián)系方式場景:患者"吳英俊"的聯(lián)系方式者號患者姓名聯(lián)系方式醫(yī)生姓名操作4吳英晴晴?已更新4吳英艾明?已更新現(xiàn)實操作:只需要修改一次聯(lián)系方式數據庫操作:必須修改該患者的所有預約記錄風險:漏改部分記錄導致數據不一致復雜性:需要找到并更新所有相關記錄破壞:數據完整性被破壞問題四:刪除異常刪除異常:不應該被刪除的數據被錯誤刪除定義刪除異常是指在數據庫操作中,不應該被刪除的數據被錯誤地刪除。當刪除一行時,必須刪除兩個以上實體的數據,可能導致有用信息丟失。典型場景醫(yī)生離職該醫(yī)院某位醫(yī)生離職了,需要刪除他的信息連帶刪除順帶預約該醫(yī)生卻未預約其他醫(yī)生的患者信息也一并被刪除了信息丟失這些患者的其他信息(聯(lián)系方式、住址等)也永久丟失刪除前數據患者號患者姓名醫(yī)生號醫(yī)生姓名預約日期1張文文1李明2024-08-012李思思1李明2024-08-023王明杰1李明2024-08-034吳英俊5吳晴晴2024-08-01操作:刪除醫(yī)生"李明"(醫(yī)生號=1)的信息結果:患者"張文文"、"李思思"、"王明杰"的信息也被刪除,即使他們還有其他預約記錄關鍵洞察:刪除異常的根本原因是關系中表示了多個實體,刪除一行時必須刪除多個實體的數據,導致有用信息被連帶刪除。8.1.2關系規(guī)范化的主要方法模式分解:實現(xiàn)"一物一表"的核心方法核心思想一個關系之所以會出現(xiàn)異常問題,主要原因是數據冗余度高。關系規(guī)范化的主要方法是模式分解,使一個關系表示一個實體。分解原則1一物一表每個關系只表示一個實體或一個聯(lián)系2降低冗余控制數據冗余度,避免信息重復存儲3解決異常消除插入異常、更新異常、刪除異常"患者醫(yī)生預約表"分解為三個關系1患者表屬性:患者號、患者姓名、患者出生年月、患者性別、患者聯(lián)系方式、患者住址主碼:患者號2醫(yī)生表屬性:醫(yī)生號、醫(yī)生姓名、醫(yī)生性別、醫(yī)生專業(yè)、醫(yī)生工作年限主碼:醫(yī)生號3預約表屬性:預約號、患者號、醫(yī)生號、預約原因、預約日期、預約時間主碼:預約號;外碼:患者號、醫(yī)生號新增醫(yī)生:只需插入醫(yī)生表,無需患者信息修改患者信息:只需修改患者表的一條記錄刪除醫(yī)生:只需刪除醫(yī)生表的記錄,患者信息保留模式分解示例患者表:獨立存儲患者基本信息關系結構患者表(Patient)主碼:患者號(PatientID)屬性:?患者號(PatientID)?患者姓名(PatientName)?患者出生年月?患者性別(Gender)?患者聯(lián)系方式?患者住址患者表數據患者號患者姓名出生年月性別聯(lián)系方式住址1張文文1990-01-01設路1號2李思思1992-05-15明路10號3王明杰1994-08-05意路8號4吳英俊1993-08-10年路9號5陳楠楠1992-09-14國路5號無冗余:每個患者信息只存儲一次易更新:修改患者信息只需修改一條記錄獨立管理:患者信息與預約信息分離模式分解示例醫(yī)生表:獨立存儲醫(yī)生基本信息關系結構醫(yī)生表(Doctor)主碼:醫(yī)生號(DoctorID)屬性:?醫(yī)生號(DoctorID)?醫(yī)生姓名(DoctorName)?醫(yī)生性別(Gender)?醫(yī)生專業(yè)(Specialization)?醫(yī)生工作年限(WorkingYears)醫(yī)生表數據醫(yī)生號醫(yī)生姓名性別專業(yè)工作年限1李明M五官科152張浩M兒科203李思美F眼科124陳艾明F中醫(yī)護理105吳晴晴F骨科13無冗余:每個醫(yī)生信息只存儲一次易管理:新增或刪除醫(yī)生獨立操作靈活:醫(yī)生信息變更只需修改一次模式分解示例預約表:存儲患者與醫(yī)生的預約關系關系結構預約表(Appointment)主碼:預約號(AppointmentID)外碼:患者號、醫(yī)生號屬性:?預約號(AppointmentID)?患者號(PatientID)?醫(yī)生號(DoctorID)?預約原因?預約日期?預約時間外鍵約束患者號→患者表.患者號醫(yī)生號→醫(yī)生表.醫(yī)生號預約表數據預約號患者號醫(yī)生號預約原因預約日期預約時間111聽覺受限2024-08-0110:00:00221咽喉腫痛2024-08-0210:00:00331鼻竇炎2024-08-0310:00:00445運動扭傷2024-08-0110:10:10544康復治療2024-08-0410:00:00655運動扭傷2024-08-0111:10:10754康復治療2024-08-0411:00:00關聯(lián)關系:通過外鍵關聯(lián)患者和醫(yī)生靈活操作:刪除醫(yī)生不影響患者信息數據完整:只存儲關聯(lián)信息,無冗余模式分解的權衡模式分解的優(yōu)缺點:空間與效率的權衡優(yōu)勢控制數據冗余分解后的關系所包含的信息量和分解前一樣,但是數據冗余得到了控制,避免了存儲空間的浪費解決操作異常插入異常、更新異常和刪除異常的問題都得到了解決:?插入異常:新來了醫(yī)生只需要更新"醫(yī)生表"?更新異常:修改患者聯(lián)系方式只需要修改"患者表"?刪除異常:醫(yī)生離職只需要刪除"醫(yī)生表"的記錄實現(xiàn)"一物一表"一個規(guī)范化的關系,應該控制好數據冗余度,避免關系后期操作的異常問題,做到"一物一表"代價查詢復雜性增加分解后的關系變多了,之間聯(lián)系也隨之增多,數據的應用會更加復雜需要連接操作例如"預約表"中無法直觀表明患者的姓名和醫(yī)生的姓名,需要通過關系的連接查詢才能實現(xiàn)示例:查詢預約號為7的患者姓名和醫(yī)生姓名,需要連接患者表、醫(yī)生表和預約表性能權衡是否需要分解,分解成多少個關系,是否需要用空間換效率,這些需要從實際需求和應用的角度來考慮設計原則:在規(guī)范化程度與查詢效率之間取得平衡,通常滿足3NF或BCNF即可8.2數據依賴028.2數據依賴數據依賴:屬性之間的相互制約關系定義關系模式中的各屬性之間的相互依賴、相互制約的聯(lián)系稱為數據依賴。一個屬性的取值依賴于另外一個或多個屬性的取值,那么它們之間就存在數據依賴關系。數據依賴類型函數依賴(FD)最重要的一種數據依賴,本書重點討論多值依賴(MVD)4NF中討論,處理多值屬性問題連接依賴5NF中討論,處理連接操作問題數據依賴示例:患者醫(yī)生預約表患者號患者姓名醫(yī)生號醫(yī)生專業(yè)1張文文1五官科2李思思1五官科3王明杰1五官科函數依賴一:患者號→患者姓名若已知患者號,則患者姓名是唯一的。例如患者號=1,則患者姓名一定是"張文文"函數依賴二:醫(yī)生號→醫(yī)生專業(yè)若已知醫(yī)生號,則醫(yī)生專業(yè)是唯一的。例如醫(yī)生號=1,則醫(yī)生專業(yè)一定是"五官科"非函數依賴:醫(yī)生號/→患者號醫(yī)生號=1對應多個患者號(1、2、3),所以醫(yī)生號不能函數決定患者號關鍵洞察:數據依賴是現(xiàn)實世界數據之間內在聯(lián)系的抽象表達,理解數據依賴是進行關系規(guī)范化的基礎8.2.1函數依賴函數依賴的定義與表示定義函數依賴是關系模式中屬性之間的一種邏輯依賴關系,是關系模式中屬性與屬性之間存在的一種重要數據依賴。例如,患者號與患者姓名的關系,若已知患者號,則患者姓名是唯一的,即患者號和患者姓名之間存在函數關系f,患者姓名=f(患者號)。形式化定義設R(U)是屬性集U上的關系模式,X和Y是U的子集。若對于R(U)的任意一個可能的關系r,對于X的每一個具體值,Y都有唯一的具體的值與之對應,則稱:X函數決定Y或Y函數依賴于X記作:X→Y示例:患者醫(yī)生預約表中的函數依賴患者號患者姓名醫(yī)生號醫(yī)生專業(yè)1張文文1五官科2李思思1五官科3王明杰1五官科PatientID→PatientName不可能存在兩個患者,患者號相同而姓名不同,因此我們說患者號函數確定患者姓名DoctorID→Specialization一個醫(yī)生只能從事一個專業(yè),因此醫(yī)生號函數確定醫(yī)生專業(yè)關鍵理解函數依賴強調的是:對于X的每一個具體值,Y都有唯一的具體值與之對應,即Y的值由X唯一確定8.2.1函數依賴函數依賴的術語和記號決定因素與依賴因素定義若X→Y,則稱X為決定因素(Determinant),Y為依賴因素(Dependent)。示例在DoctorID→Specialization中:?決定因素:DoctorID?依賴因素:Specialization相互決定定義若X→Y且Y→X,則稱X與Y相互決定,記作X←→Y。示例當患者無重名時:?PatientID→PatientName?PatientName→PatientID?因此:PatientID←→PatientName不存在函數依賴定義若Y不函數依賴X,則記作X/→Y。示例一個醫(yī)生可以醫(yī)治多名患者:?DoctorID/→PatientID?一個醫(yī)生號對應多個患者號關鍵要點:理解這些術語和記號是后續(xù)學習函數依賴推理和范式判斷的基礎8.2.1函數依賴屬性值聯(lián)系類型與函數依賴:1:1聯(lián)系1:1聯(lián)系若X和Y間的聯(lián)系是1:1(一對一),則X和Y之間可以相互函數決定。函數依賴X→Y且Y→X關鍵特征?X的每個值對應Y的唯一值?Y的每個值對應X的唯一值?X和Y可以相互決定?記作:X←→Y示例:患者號與患者姓名(無重名時)患者號患者姓名說明1張文文患者號1唯一對應張文文2李思思患者號2唯一對應李思思3王明杰患者號3唯一對應王明杰PatientID→PatientName每個患者號對應唯一的患者姓名,因此患者號可以函數決定患者姓名PatientName→PatientID由于無重名,每個患者姓名也對應唯一的患者號,因此患者姓名也可以函數決定患者號PatientID←→PatientName因此患者號和患者姓名相互決定,記作PatientID←→PatientName注意:1:1聯(lián)系的前提是無重名。如果允許患者重名,則PatientName/→PatientID8.2.1函數依賴屬性值聯(lián)系類型與函數依賴:1:M聯(lián)系1:M聯(lián)系若X和Y間的聯(lián)系是1:M(一對多),則Y可以函數決定X,但X不能函數決定Y。函數依賴Y→X但X/→Y關鍵特征?X的每個值對應Y的多個值?Y的每個值對應X的唯一值?只有Y可以決定X?X不能決定Y(一對多)示例:性別與患者號患者號患者姓名性別1張文文F2李思思F3王明杰M4吳英俊M5陳楠楠FPatientID→Gender每個患者號對應唯一的性別,因此患者號可以函數決定性別Gender/→PatientID性別"F"對應多個患者號(1、2、5),因此性別不能函數決定患者號關鍵理解在1:M聯(lián)系中,只有多的一方可以函數決定一的一方,反過來則不行注意:1:M聯(lián)系中,決定因素是多的一方,依賴因素是一的一方8.2.1函數依賴屬性值聯(lián)系類型與函數依賴:M:N聯(lián)系M:N聯(lián)系若X和Y間的聯(lián)系是M:N(多對多),則X和Y之間不存在函數依賴關系。函數依賴X/→Y且Y/→X關鍵特征?X的每個值對應Y的多個值?Y的每個值也對應X的多個值?X不能決定Y?Y也不能決定X示例:醫(yī)生與患者(預約關系)患者號患者姓名醫(yī)生號醫(yī)生姓名1張文文1李明2李思思1李明3王明杰1李明4吳英俊5吳晴晴4吳英俊4陳艾明DoctorID/→PatientID醫(yī)生號=1對應多個患者號(1、2、3),因此醫(yī)生號不能函數決定患者號PatientID/→DoctorID患者號=4對應多個醫(yī)生號(5、4),因此患者號不能函數決定醫(yī)生號關鍵理解M:N聯(lián)系是多對多的,任何一方都不能唯一確定另一方,因此不存在函數依賴關系8.2.1函數依賴函數依賴的重要說明說明一:所有關系實例均要滿足函數依賴不是指關系模式R(U)的某個或某些關系實例滿足的約束條件,而是指R的所有關系實例均要滿足的約束條件。示例PatientID→PatientName不是基于表中現(xiàn)有數據的觀察,而是基于"每個患者號唯一確定一個患者"這一業(yè)務規(guī)則,無論表中有什么數據,這個依賴都必須成立違反函數依賴的情況患者號患者姓名1張文文1李思思患者號相同但姓名不同,違反了PatientID→PatientName說明二:語義范疇的概念函數依賴是語義范疇的概念,只能根據數據的語義來確定函數依賴,而不能僅憑數據值來判斷。語義1:醫(yī)生可以重名DoctorName/→Gender因為同名醫(yī)生可能有不同的性別語義2:醫(yī)生不可以重名DoctorName→Gender因為每個姓名唯一對應一個醫(yī)生,也就唯一對應一個性別語義3:一名醫(yī)生可以從事多個專業(yè)DoctorID/→Specialization因為一個醫(yī)生可能擅長多個專業(yè)領域語義4:一名醫(yī)生只能從事一個專業(yè)DoctorID→Specialization因為一個醫(yī)生號唯一確定一個專業(yè)關鍵洞察:函數依賴的確定依賴于業(yè)務規(guī)則和數據語義,而不是數據本身。相同的數據結構,在不同的業(yè)務規(guī)則下可能有不同的函數依賴8.2.2函數依賴的分類平凡函數依賴與非平凡函數依賴非平凡函數依賴定義若X→Y,但Y?X(Y不是X的子集),則稱X→Y是非平凡函數依賴。示例在關系Doctors(DoctorID,DoctorName,Gender,Specialization,WorkingYears)中:?(DoctorID)→DoctorNameDoctorName不在(DoctorID)中,是非平凡函數依賴重要性:非平凡函數依賴是實際應用中關注的重點,它代表了屬性之間的真實依賴關系平凡函數依賴定義若X→Y,且Y?X(Y是X的子集),則稱X→Y是平凡函數依賴。示例在關系Doctors(DoctorID,DoctorName,Gender,Specialization,WorkingYears)中:?(DoctorID,DoctorName)→DoctorNameDoctorName在(DoctorID,DoctorName)中,是平凡函數依賴?(DoctorID)→DoctorIDDoctorID在(DoctorID)中,是平凡函數依賴說明:對于任意的關系,平凡函數依賴都是必然成立的,無實際意義,因此若無特別聲明,討論的函數依賴均為非平凡函數依賴8.2.2函數依賴的分類完全函數依賴與部分函數依賴完全函數依賴定義設R(U)是屬性集U上的關系模式,X和Y是U的子集。如果X→Y,并且對于X的任何一個真子集Z,Z→Y都不成立,則稱Y完全函數依賴于X。記作:X→Y示例一在Appointments(PatientID,DoctorID,AppointmentDate)中:(PatientID,AppointmentDate)→DoctorID是完全函數依賴因為PatientID/→DoctorID,且AppointmentDate/→DoctorID示例二訂單中:(商品數量,商品單價)→總金額總金額完全依賴于商品數量和商品單價因為單獨的數量或單價都不能確定總金額部分函數依賴定義如果X→Y,并且對于X的某個真子集Z,Z→Y成立,則稱Y部分函數依賴于X。記作:X→Y示例一訂單中:(訂單號,商品編號)→商品數量商品數量部分依賴于(訂單號,商品編號)因為商品數量可以由訂單號單獨確定,也可以由訂單號和商品編號確定關鍵理解部分函數依賴意味著決定因素包含了多余的屬性,Y實際上只依賴于X的一部分,這是導致數據冗余的主要原因之一8.2.2函數依賴的分類傳遞函數依賴定義設R(U)是屬性集U上的關系模式,X、Y、Z是U的子集,且X、Y、Z是不同的屬性集。如果X→Y,Y→X不成立,Y→Z,則稱Z傳遞函數依賴于X。記作:X→ZX決定因素Y中間屬性Z依賴屬性關鍵條件?X→Y:X決定Y?Y→X不成立:Y不能決定X?Y→Z:Y決定Z?結果:Z傳遞依賴于X示例:班級關系中的傳遞函數依賴假設有關系Class(classID,classname,studentID,studentName,major)班級號班級名學號專業(yè)C00124計科1S001計算機科學C00124計科1S002計算機科學C00224軟件1S003軟件工程classID→studentID班級號可以決定該班級的所有學生(通過關系中的記錄)studentID→major學號可以決定該學生的專業(yè)classID→major因此,專業(yè)傳遞函數依賴于班級號:classID→major問題:傳遞函數依賴是導致數據冗余和更新異常的主要原因之一,需要通過規(guī)范化消除8.2.2函數依賴的推理規(guī)則Armstrong公理:自反律(Reflexivity)自反律定義若Y?X?U,則X→Y在R上成立。一組屬性函數決定它的所有子集理解要點?自反律是最基本的推理規(guī)則?任何屬性集都能決定其自身?任何屬性集都能決定其子集?這是函數依賴的固有性質自反律示例假設有關系模式R(U),其中U={A,B,C,D}示例1:屬性集決定自身因為{A,B}?{A,B},所以:{A,B}→{A,B}任何屬性集都能決定自身,這是最直觀的示例2:屬性集決定子集因為{A}?{A,B},所以:{A,B}→{A}屬性集{A,B}可以決定其子集{A}示例3:復雜子集因為{B,C}?{A,B,C,D},所以:{A,B,C,D}→{B,C}全集可以決定任何子集8.2.2函數依賴的推理規(guī)則Armstrong公理:增廣律(Augmentation)增廣律定義若X→Y在R上成立,且Z?U,則XZ→YZ在R上也成立。在函數依賴兩邊同時增加屬性集理解要點?增廣律允許我們在函數依賴兩邊同時增加屬性?增加屬性后,函數依賴仍然成立?這是擴展函數依賴的有力工具?增廣后的依賴仍然保持原有的依賴關系增廣律示例假設已知DoctorID→Specialization,且WorkingYears?U步驟1:已知函數依賴已知:DoctorID→Specialization醫(yī)生號可以決定醫(yī)生專業(yè)步驟2:兩邊增加WorkingYears根據增廣律,兩邊同時增加WorkingYears:(DoctorID,WorkingYears)→(Specialization,WorkingYears)醫(yī)生號和工作年限可以決定醫(yī)生專業(yè)和工作年限步驟3:兩邊增加DoctorName再次應用增廣律,兩邊同時增加DoctorName:(DoctorID,DoctorName,WorkingYears)→(Specialization,DoctorName,WorkingYears)這個依賴仍然成立,但變得更加復雜8.2.2函數依賴的推理規(guī)則Armstrong公理:傳遞律(Transitivity)傳遞律定義若X→Y和Y→Z在R上成立,則X→Z在R上也成立。依賴關系可以傳遞理解要點?傳遞律是邏輯推理的基礎規(guī)則?如果X能決定Y,Y能決定Z?那么X能直接決定Z?這是函數依賴傳遞性的體現(xiàn)傳遞律示例假設在學生關系中有以下函數依賴:步驟1:已知函數依賴學號→班級名班級名→輔導員學號可以決定班級,班級可以決定輔導員步驟2:應用傳遞律根據傳遞律:學號→輔導員因此,學號可以直接決定輔導員,無需通過班級名傳遞過程可視化學號班級名輔導員傳遞律允許我們跳過中間屬性,直接建立依賴關系8.2.2函數依賴的推理規(guī)則Armstrong公理推論:合并規(guī)則合并規(guī)則定義若X→Y和X→Z在R上成立,則X→YZ在R上也成立。將多個依賴合并為一個重要結論如果A?A?…A?是關系模式R的屬性集,那么X→A?A?…A?成立的充分必要條件是X→A?(i=1,2…n)成立。這意味著我們可以將復雜的依賴分解為簡單的依賴,也可以將簡單的依賴合并為復雜的依賴合并規(guī)則示例假設在學生關系中有以下函數依賴:步驟1:已知多個函數依賴已知學號可以決定多個屬性:學號→姓名學號→系名學號→性別學號可以分別決定姓名、系名和性別步驟2:應用合并規(guī)則根據合并規(guī)則,可以將這些依賴合并:學號→(姓名,系名,性別)學號可以同時決定姓名、系名和性別三個屬性逆向應用:分解規(guī)則反過來,如果已知:學號→(姓名,系名,性別)則可以推出:學號→姓名學號→系名學號→性別這表明合并和分解是互逆的操作應用:合并規(guī)則和分解規(guī)則使得函數依賴的表示更加靈活,可以根據需要選擇合適的形式8.2.2函數依賴的推理規(guī)則Armstrong公理推論:分解規(guī)則分解規(guī)則定義若X→Y和Z?Y在R上成立,則X→Z在R上也成立。將復雜依賴分解為簡單依賴重要結論如果A?A?…A?是關系模式R的屬性集,那么X→A?A?…A?成立的充分必要條件是X→A?(i=1,2…n)成立。這意味著我們可以將一個復雜的依賴X→YZ分解為X→Y和X→Z兩個簡單的依賴分解規(guī)則示例假設在學生關系中有以下函數依賴:步驟1:已知復雜函數依賴已知學號可以決定多個屬性:學號→(姓名,系名,性別)學號可以同時決定姓名、系名和性別三個屬性步驟2:應用分解規(guī)則根據分解規(guī)則,可以分解為:學號→姓名學號→系名學號→性別學號可以分別決定姓名、系名和性別步驟3:進一步分解如果已知:(A,B)→(C,D,E)則可以分解為:(A,B)→C(A,B)→D(A,B)→E分解規(guī)則允許我們將復雜依賴細化到單個屬性8.2.2函數依賴的推理規(guī)則偽傳遞規(guī)則與復合規(guī)則偽傳遞規(guī)則定義若X→Y和YW→Z在R上成立,則XW→Z在R上也成立。增強型傳遞律推理過程X→Y已知YW→Z已知XW→Z結論示例已知:學號→班級名,(班級名,課程號)→成績則:(學號,課程號)→成績偽傳遞規(guī)則允許我們在傳遞過程中合并額外的屬性,從而推導出更精確的依賴關系復合規(guī)則定義若X→Y和W→Z在R上成立,則XW→YZ在R上也成立。合并兩個依賴推理過程X→Y已知W→Z已知XW→YZ結論示例已知:學號→姓名,課程號→課程名則:(學號,課程號)→(姓名,課程名)復合規(guī)則允許我們將兩個獨立的依賴合并為一個更大的依賴,這在處理復合屬性時非常有用8.2.3候選碼的求解屬性集閉包:求解候選碼的關鍵概念屬性集閉包在一個關系模式R(U,F)中,U是R的屬性集,F(xiàn)是R的函數依賴集。R中的一個屬性集A,在F的函數依賴關系下,通過直接或間接的依賴關系所能推導出的所有屬性的集合,稱之為A的屬性集閉包。記作:A?或A?F表示在函數依賴集F下,由A能推導出的所有屬性的集合計算方法1.初始:A?=A2.在F中尋找X→Y,其中X?A?3.將Y加入A?4.重復步驟2-3直到A?不再增大屬性集閉包計算示例設有關系模式R(U,F),其中:U={A,B,C,D,E,I}F={A→D,AB→E,BI→E,CD→I,E→C}示例1:計算A?A?={A}A→D?A?={A,D}無法繼續(xù)推導結果:A?={A,D}≠U示例2:計算(AB)?(AB)?={A,B}A→D?(AB)?={A,B,D}AB→E?(AB)?={A,B,D,E}E→C?(AB)?={A,B,D,E,C}CD→I?(AB)?={A,B,D,E,C,I}=U結果:(AB)?=U關鍵應用如果A?=U,則A是候選碼(或包含候選碼)8.2.3候選碼的求解屬性分類:快速識別候選碼元素屬性分類對于給定的關系R(A?…A?)和函數依賴集F,可將其屬性分為L類、R類、N類、LR類:分類標準L類僅出現(xiàn)在函數依賴關系左部的屬性R類僅出現(xiàn)在函數依賴關系右部的屬性N類在函數依賴關系左右兩邊均未出現(xiàn)的屬性LR類在函數依賴關系左右兩邊均出現(xiàn)的屬性屬性分類示例設有關系模式R(U,F),其中:U={A,B,C,D,E,G}F={AB→E,AC→G,AD→B,B→C,C→D}步驟1:分析屬性出現(xiàn)位置左部出現(xiàn):A,B,C,D右部出現(xiàn):B,C,D,E,G未出現(xiàn):無步驟2:分類結果L類(僅左):AR類(僅右):E,GN類(未出現(xiàn)):無LR類(左右):B,C,D分類意義通過分類可以快速判斷哪些屬性可能包含在候選碼中(L類、N類、LR類),哪些屬性不可能包含在候選碼中(R類)8.2.3候選碼的求解候選碼求解的六個推論1推論1:L類屬性必為候選碼元素對于給定的關系模式R及其函數依賴集F,若X是L類屬性,則X必為R中候選碼的元素。2推論2:L類屬性且閉包為全集則為唯一候選碼對于給定的關系模式R及其函數依賴集F,若X是L類屬性且X?包含R的全部屬性,則X為R的唯一候選碼。3推論3:R類屬性不包含在任何候選碼中對于給定的關系模式R及其函數依賴集F,若X是R類屬性,則X不包含在任何候選碼中。4推論4:N類屬性必為候選碼元素對于給定的關系模式R及其函數依賴集F,若X是N類屬性,則X必為R中候選碼的元素。5推論5:N類和L類組成的屬性集且閉包為全集則為唯一候選碼對于給定的關系模式R及其函數依賴集F,若X是N類和L類組成的屬性集,且X?包含R的全部屬性,則X必為R的唯一候選關鍵字。6推論6:LR類屬性可能包含在候選碼中對于給定的關系模式R及其函數依賴集F,若X是LR類屬性,則X可能包含在關系模式R的某個候選碼中。8.2.3候選碼的求解候選碼求解完整示例示例:設有關系模式R(U,F),其中:U={A,B,C,D,E,G}F={AB→E,AC→G,AD→B,B→C,C→D}求R的所有候選碼。求解步驟1判斷屬性類型將屬性分為L、R、N、LR四類2計算屬性集閉包對L類和N類屬性計算閉包3組合LR類屬性與L類或N類屬性組合測試4確定候選碼找出所有閉包為全集的屬性集完整求解過程步驟1:判斷屬性類型?L類(僅左):A?R類(僅右):E,G?N類(未出現(xiàn)):無?LR類(左右):B,C,D根據推論1、3,A必在候選碼中,E、G不在任何候選碼中步驟2:計算A?A?={A}A?≠U,所以A不是唯一候選碼步驟3:組合LR類屬性測試(AB)?={A,B,D,C,E,G}=U?(AC)?={A,C,D,B,E,G}=U?(AD)?={A,D,B,C,E,G}=U?步驟4:確定候選碼關系模式R共有三個候選碼:AB、AC和AD8.2.4最小函數依賴集求解最小函數依賴集:定義與條件函數依賴閉包在關系模式R(U,F)中,為F所邏輯蘊含的函數依賴的全體叫作F的閉包,記為F?,又稱函數依賴閉包。F?={X→Y|F?X→Y}即由F能推導出的所有函數依賴的集合最小函數依賴集對關系模式R(U,F),如果函數依賴集F滿足下列條件,則稱F為一個最小函數依賴集,也被稱為極小依賴集或最小覆蓋。三個條件:1.右部僅含一個屬性2.左部無多余屬性3.無多余函數依賴最小函數依賴集的三個條件1右部僅含一個屬性F中任一函數依賴的右部僅含有一個屬性。示例:A→BC應分解為A→B和A→C2左部無多余屬性F中任一函數依賴的左部不存在多余的屬性。示例:若(AB)→C且A→C,則AB→C左部有冗余,應改為A→C3無多余函數依賴F中不存在多余的函數依賴。示例:若F={A→B,B→C,A→C},則A→C是冗余的,因為可以通過傳遞律推出8.2.4最小函數依賴集求解最小函數依賴集求解算法第一步分解右部為單屬性使F中每個函數依賴的右部都只有一個屬性。方法:若X→Y?Y?…Y?,則替換為:X→Y?X→Y?...X→Y?示例:A→BC替換為A→B和A→C第二步去掉左部多余屬性去掉各函數依賴左部多余的屬性。方法:對X→A,設X=B?B?…B?,若存在X-B?使A∈(X-B?)?,則以(X-B?)取代X示例:若(AB)→C且A→C,則AB→C可簡化為A→C第三步去掉多余函數依賴去掉多余的函數依賴。方法:若存在X→A的真子集G=F-{X→A},若A∈G?,則用F-{X→A}替代F示例:若F={A→B,B→C,A→C},則A→C是冗余的,因為可以通過前兩個依賴傳遞推出8.2.4最小函數依賴集求解最小函數依賴集求解完整示例示例:設有關系模式R(U,F),其中:U={A,B,C}F={A→BC,B→C,AC→B}求F的最小函數依賴集。三步算法第一步:分解右部將右部包含多個屬性的依賴分解第二步:去掉左部多余屬性檢查每個依賴的左部是否有冗余第三步:去掉多余函數依賴檢查是否有可以推導出的冗余依賴完整求解過程第一步:分解F中的函數依賴A→BC?A→B,A→CB→C保持不變AC→B保持不變結果:F={A→B,A→C,B→C,AC→B}第二步:去掉左部多余的屬性對于AC→B,檢查是否可以去掉A或C:?若去掉A:(C)?={C},所以A不能去掉?若去掉C:(A)?={A,B,C},所以可以去掉C結果:F={A→B,A→C,B→C}第三步:去掉多余的函數依賴檢查F={A→B,A→C,B→C}:?若去掉A→B:(A)?={A,C}≠B,所以不能去掉?若去掉A→C:由A→B,B→C可推出(A)?={A,B,C},所以A→C是冗余的?若去掉B→C:(B)?={B}≠C,所以不能去掉最終結果:F={A→B,B→C}8.3關系模型的范式038.3.1范式范式的概念與級別范式的定義范式是關系模式符合某一種級別的規(guī)范。關系數據庫中的關系必須滿足一定的規(guī)范,可有效降低其冗余度。針對同一個數據需求問題,不同設計人員設計出來的關系模式可能不完全相同,用范式來衡量關系模式的規(guī)范化程度。范式級別?1NF:第一范式?2NF:第二范式?3NF:第三范式?BCNF:BC范式?4NF:第四范式?5NF:第五范式(完美范式)范式的包含關系1NF2NF3NFBCNF高階范式一定符合低階范式的要求1NF?2NF?3NF?BCNF?4NF?5NF規(guī)范化如果一個關系模式R為第n范式,可簡記為R∈nNF。一個低一級范式的關系模式,通過模式分解可以轉換為若干個高一級范式的關系模式的集合,這個過程就叫作規(guī)范化。實際應用通常在數據庫應用系統(tǒng)的設計過程中,滿足3NF或BCNF要求即可。因此關于4NF和5NF的定義,本節(jié)不再重點討論。8.3.21NF(第一范式)1NF:屬性是不可分的原子項1NF的定義如果一個關系模式R的所有屬性都是不可分的基本數據項,則R∈1NF。第一范式是關系模式設計的最基本要求。任何關系數據庫中的關系都必須滿足第一范式,這是關系模型的基本約束。1NF的要求?每個屬性都是原子性的?屬性值是不可再分的基本數據項?不允許出現(xiàn)重復組或多值屬性?每個字段只包含單一值非第一范式關系示例患者號患者姓名聯(lián)系方式電話地址p001張文設路1號p002李思明路10號問題分析上表中,"聯(lián)系方式"不是基本數據項,它由兩個其他屬性"電話"和"地址"組成,不符合1NF關于屬性不可再分的要求。這種結構使得數據操作復雜,查詢和更新都不方便。8.3.21NF(第一范式)轉換為1NF的方法轉換方法非第一范式關系轉換為第一范式關系的方法是將所有屬性都分解為基本數據項。轉換為1NF的示例將表8.5的非1NF關系改進為表8.6的1NF關系轉換前(非1NF)患者號患者姓名聯(lián)系方式電話地址p001張文設路1號轉換后(1NF)患者號患者姓名電話地址p001張文設路1號轉換說明將"聯(lián)系方式"這個復合屬性拆分為"電話"和"地址"兩個獨立的原子屬性,使得每個屬性都不可再分。這樣修改后的關系模式滿足1NF的要求,所有屬性都是基本數據項,數據結構更加清晰,操作也更加方便。8.3.32NF(第二范式)2NF:消除非主屬性對碼的部分函數依賴2NF的定義若關系模式R∈1NF,且R中每一個非主屬性都完全函數依賴于碼,則稱R符合第二范式,記作R∈2NF。第一范式是數據庫關系模式中最基本要求,第二范式則能考察關系中主屬性和非主屬性的依賴關系,降低關系的高冗余度。2NF的關鍵點?消除部分函數依賴?非主屬性必須完全依賴于碼?不能有非主屬性部分依賴于碼?每個非主屬性必須由整個碼決定示例:學生關系模式(不滿足2NF)學生(學號,姓名,系名,系負責人,課程名,成績)學號姓名系名系負責人課程名成績001張文文計算機系張小榮C語言91001張文文計算機系張小榮數據庫85002李思思計算機系張小榮C語言78函數依賴分析F={學號→姓名,學號→系名,系名→系負責人,(學號,課程名)→成績}?碼為(學號,課程名)?非主屬性"姓名"和"系名"部分函數依賴于碼?學號→姓名,學號→系名,只依賴于碼的一部分數據冗余:每個系名和系負責人存儲多次插入異常:新系無學生時無法錄入刪除異常:刪除學生可能刪除系信息8.3.32NF(第二范式)學生關系模式的函數依賴分析函數依賴集F={學號→姓名,學號→系名,系名→系負責人,(學號,課程名)→成績}學號→姓名學號決定學生姓名學號→系名學號決定所屬系系名→系負責人系名決定系負責人(學號,課程名)→成績學號和課程名共同決定成績碼的分析碼(候選碼):(學號,課程名)主屬性學號、課程名非主屬性姓名、系名、系負責人、成績部分函數依賴分析姓名對碼的部分依賴姓名→(學號,課程名)是完全函數依賴但學號→姓名,姓名只依賴于碼的一部分"學號",而不是整個碼系名對碼的部分依賴系名→(學號,課程名)是完全函數依賴但學號→系名,系名也只依賴于碼的一部分"學號"8.3.32NF(第二范式)通過模式分解達到2NF分解方法按照2NF的定義分析,發(fā)現(xiàn)產生問題的原因是非主屬性"姓名"和"系名"部分函數依賴于碼。解決辦法是進行模式分解,消除部分函數依賴。分解原則?將部分依賴的屬性分離?保留完全依賴的屬性?確保每個關系表示單一實體分解步驟1識別部分依賴找出非主屬性對碼的部分依賴2分離部分依賴將部分依賴的屬性分離到新關系3保留完全依賴保持完全依賴的屬性在原關系學生關系的分解原關系:學生(學號,姓名,系名,系負責人,課程名,成績)關系1:學生基本信息屬性:學號,姓名,系名,系負責人碼:學號非主屬性"姓名"、"系名"、"系負責人"都完全函數依賴于碼"學號"關系2:學生選課屬性:學號,課程名,成績碼:(學號,課程名)非主屬性"成績"完全函數依賴于碼"(學號,課程名)"結果:在上述兩個關系模式中,非主屬性對碼均為完全函數依賴,都符合2NF8.3.43NF(第三范式)3NF:消除非主屬性對碼的傳遞函數依賴3NF的動機符合2NF的關系模式解決了1NF中存在的一些問題,但在進行數據操作時,仍然存在問題。原因是關系中存在非主屬性對碼的傳遞函數依賴。消除傳遞函數依賴就可以轉換為3NF,進一步減少數據冗余和操作異常。2NF存在的問題數據冗余度高每個系名和系負責人存儲的次數等于該系的學生人數插入異常當一個新系沒有招生時,有關該系的信息無法錄入刪除異常當某系學生全部畢業(yè)且又沒有招生時,刪除學生記錄會刪除該系信息更新異常更新系負責人時需要修改較多的學生記錄示例:學生基本信息關系(不滿足3NF)學生(學號,姓名,系名,系負責人)學號姓名系名系負責人001張文文計算機系張小榮002李思思計算機系張小榮003王明杰計算機系張小榮傳遞函數依賴分析F={學號→姓名,學號→系名,系名→系負責人}?學號→系名?系名→系負責人?因此:學號→系負責人非主屬性"系負責人"對"學號"存在傳遞函數依賴8.3.43NF(第三范式)3NF的定義與模式分解3NF的定義若關系模式R∈2NF,且每一個非主屬性不傳遞函數依賴于碼,則稱R符合第三范式,記作:R∈3NF。通俗地講,3NF要求關系中沒有非主屬性對碼的傳遞依賴,每個非主屬性都直接依賴于碼。3NF的要求?滿足2NF的所有條件?消除傳遞函數依賴?非主屬性直接依賴于碼?不能有間接依賴關系通過分解達到3NF原關系:學生(學號,姓名,系名,系負責人)關系1:學生屬性:學號,姓名,系名碼:學號非主屬性"姓名"、"系名"直接依賴于碼"學號"關系2:系屬性:系名,系負責人碼:系名系負責人直接依賴于碼"系名"結果:這樣分解后的關系模式不再存在傳遞依賴關系,兩個關系均符合3NF8.3.5BCNF(BC范式)BCNF:消除主屬性對碼的依賴BCNF的提出背景關系數據庫設計的目的是消除部分依賴和傳遞依賴,因為這些依賴會導致數據操作異常。到目前為止,所討論的第二范式能消除非主屬性對碼的部分函數依賴,第三范式能消除非主屬性對碼的傳遞函數依賴,但未限制主屬性對碼的部分函數依賴和傳遞函數依賴關系。若發(fā)生這種依賴,仍然可能使關系存在高數據冗余,而導致插入異常、刪除異常、更新異常,因此需要對3NF進一步規(guī)范化,消除主屬性對碼的依賴關系轉換為更高一級的范式,這就Boyce-Codd范式,簡稱BC范式或BCNF。BCNF的特點?比3NF更嚴格的范式?消除主屬性對碼的部分依賴?消除主屬性對碼的傳遞依賴?要求每個決定因子都是碼BCNF的定義形式化定義若關系模式R∈1NF,若X→Y且Y?X時,X必包含碼,則稱R符合BC范式,記作:R∈BCNF。通俗地講:當且僅當關系中的每個函數依賴的決定因子都是碼時,該范式即為BCNFBCNF的三個規(guī)范規(guī)范1所有非主屬性對每一個碼都是完全函數依賴規(guī)范2所有主屬性對每一個不包含它的碼也是完全函數依賴規(guī)范3沒有任何屬性完全函數依賴于非碼的任何一組屬性8.3.5BCNF(BC范式)BCNF的規(guī)范要求詳解規(guī)范1:非主屬性完全依賴所有非主屬性對每一個碼都是完全函數依賴。示例若碼為(學號,課程名),非主屬性為成績,則成績必須完全依賴于(學號,課程名),不能只依賴于學號或課程名規(guī)范2:主屬性完全依賴所有主屬性對每一個不包含它的碼也是完全函數依賴。示例若有兩個碼(學號)和(身份證號),主屬性為學號和身份證號,則學號對(身份證號)必須完全依賴,反之亦然規(guī)范3:無非碼依賴沒有任何屬性完全函數依賴于非碼的任何一組屬性。示例若(系名)不是碼,則不能有任何屬性完全依賴于系名。決定因素必須是碼8.3.5BCNF(BC范式)BCNF示例分析問題描述設有關系模式學生(學號,姓名,課程名,成績),假定學生姓名不重名。函數依賴學號?姓名候選碼(學號,課程名)和(姓名,課程名)3NF分析唯一的非主屬性"成績"對碼不存在部分函數依賴和傳遞函數依賴,所以符合3NF。但是,由于學號?姓名,即決定因素學號或姓名不包含碼,存在主屬性對碼的部分函數依賴,所以不符合BCNF。分解為BCNF將學生關系模式分解為以下兩個關系模式:關系1:學生屬性:學號,姓名候選碼:學號,姓名學號和姓名都是候選碼,無非主屬性,符合BCNF關系2:選修屬性:學號,課程名,成績碼:(學號,課程名)非主屬性成績對碼完全依賴,決定因素是碼,符合BCNF結果:在上述兩個關系模式中,主屬性和非主屬性都不存在對碼的部分依賴和傳遞依賴,均符合BCNF8.4關系模式的分解048.4.1保持無損連接分解無損連接分解的定義與判定定義設ρ={R?,R?,…,R?}是R的一個分解,若R與R?、R?、…、R?自然連接的結果相等,即經過自然連接的元組與分解前的元組沒有增加也沒有減少,則稱關系模式R的這個分解ρ具有無損連接性。等價定義若R=R??R??…?R?,則分解ρ具有無損連接性重要定理當一個關系R分解為R?和R?兩個關系時,分解ρ具有無損連接性的充分必要條件是:U?∩U?→(U?-U?)∈F?或U?∩U?→(U?-U?)∈F?無損連接分解示例設有關系模式R,其中:U={學號,班級名,輔導員}F={學號→班級名,班級名→輔導員}分解方案1:R?(學號),R?(

溫馨提示

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

評論

0/150

提交評論