數據庫系統(tǒng)概論之關系模型

第三章關系模型--本章內容基礎知識回顧關系模型概述關系模型基本概念關系模型的完整性約束關系代數邏輯數據庫設計：ER到關系的轉換關系演算基礎知識識回顧數據庫發(fā)發(fā)展以數據模模型劃分分第一代網狀、層次數據據庫系統(tǒng)統(tǒng)。代表表：1969年年IBM的IMS((informationManagementSystem));美國CODASYL(ConferenceOnDataSystemLanguage))下屬的DBTG（DataBaseTaskGroup）于60年年代末70年代代初提議議的方法法。層次次數據庫庫是數據據庫的先先驅，而而網狀數數據庫是是數據庫庫概念、、方法、、技術的的奠基者者。第二代關系數據據庫系統(tǒng)統(tǒng)。1970年年IBM公司的研研究員E.F..Codd提出了數數據庫的的關系模模型，關關系方法法和關系系數據理理論的研研究。代代表：IBM的SystemR和Berkele大學的INGRES，，成果：奠奠定了關關系模型型的理論論基礎；；研究了了關系數數據庫語語言，有有關系代代數、關關系演算算、SQL語言、QBE等；研制制了大量量的RDBMS的原型，，實現了了查詢優(yōu)優(yōu)化、并并發(fā)控制制、故障障恢復等等關鍵技技術；基礎知識識回顧數據庫發(fā)發(fā)展第三代以面向對對象數據據模型為為主要特特征的數數據庫系系統(tǒng)。模型更加加豐富、、數據管管理功能能功能更更加強大大、能支支持傳統(tǒng)統(tǒng)數據庫庫難以支支持的新新的應用用。特征：支支持數據據管理、、對象管管理和知知識管理理；保持持或者繼繼承第二二代數據據庫的技技術；對對其他系系統(tǒng)開放放（支持持數據庫庫語言標標準和標標準網絡絡協(xié)議））。僅支持面面向對象象數據模模型并不不能稱為為第三代代數據庫庫系統(tǒng)。?；A知識識回顧關系數據據庫系統(tǒng)統(tǒng)關系數據據庫系統(tǒng)統(tǒng)。產品品的發(fā)展展情況：：(1)對對關系模模型的支支持：第一階段段（70年代））：僅支支持關系系數據結結構、基基本的關關系操作作（選擇擇、投影影、連接接）。如如：dBASE第二階段段（80年代))：SQL成為關系系數據庫庫語言的的國際標標準第三階段段（90年代））：加強強了完整整性、安安全性的的支持。。(2)運運行環(huán)境境：第一階段段：在大大、中、、小型機機上的RDBMS，多用戶系系統(tǒng)第二階段段：提高高可移植植性，能能在多種種硬件平平臺、和和操作系系統(tǒng)環(huán)境境下運行行；聯網網，向分分布式發(fā)發(fā)展，支支持多種種協(xié)議。。第三階段段：分分布式數數據庫和和客戶//服務器器結構的的數據庫庫系統(tǒng)的的推出。。追求開開放性（（可移植植性、可可連接性性、可伸伸縮性））。基礎知識識回顧關系數據據庫系統(tǒng)統(tǒng)關系數據據庫系統(tǒng)統(tǒng)。產品品的發(fā)展展情況：：(3)RDBMS系統(tǒng)構成成：第一階段段：早期期的RDBMS產品主要要提供數數據定義義、數據據存取、、數據控控制等基基本操作作和數據據存儲組組織、并并發(fā)控制制、安全全性、完完整性檢檢查、系系統(tǒng)恢復復等RDBMS的核心功功能。第二階段段：以RDBMS基本功能能為核心心，開發(fā)發(fā)外圍軟軟件系統(tǒng)統(tǒng)，如：：FORM報表生成成系統(tǒng)，，REPORT報表系統(tǒng)統(tǒng)、MENU菜單生成成系統(tǒng)、、GRAPHIC圖形軟件件等等。。為用戶戶提供了了良好的的第四代代應用開開發(fā)環(huán)境境。(4)對對應用的的支持：第一階段段：用于于信息管管理、輔輔助決策策等應用用領域。。第二階段段：聯機機事務處處理的應應用領域域，提高高RDBMS事務處理理的能力力。第三階段段：由集集中到分分布，由由局部到到整個企企業(yè)甚至至整個行行業(yè)。支支持整個個企業(yè)的的聯機事事務處理理。關系模型型概述為什么要要學習關關系模型型?關系模型型是目前前廣泛使使用的一一種數據據模型IBMDB2,MiscrosoftSQLServer,,Informix,Oracle,,Sybase,…………………..僅有少量量的遺產產系統(tǒng)使使用舊的的數據模模型IBM的IMS目前仍在在使用目前關系系模型的的競爭者者:面向向對象的的數據模模型Objectstore,Versant,Ontos,,………….對象關系系模型::InformixUniversalServer,UniSQL,,O2,ORACLE,DB2,,…………....關系模型型概述關系數據據模型是是由E.F..Codd于1970年提提出在此之前前大多數數數據庫庫系統(tǒng)是是基于層層次數據據模型和和網狀數數據模型型的關系模型型給數據據庫領域域帶來了了一場革革命，并并取代了了舊的數數據模型型,E.F..Codd并因此于于1983年獲獲得TuringAwards在70年年代中期期，IBM和UC-Berkeley開發(fā)了早早期的關關系型數數據庫管管理系統(tǒng)統(tǒng)關系模型型概述現在的關關系型數數據庫系系統(tǒng)有IBM的DB2InformixOracleSybaseMicrosoft的Access,,SQLServerFox--xParadox關系模型型概述關系模型型是十分分簡單的的關系模型型的數據據結構非非常單一一，實體體、聯系系都表示示成關系系一個關系系是一個個具有行行和列的的二維表表關系模型型給出關關系操作作的能力力，但不不對RDBMS語言給出出具體的的語法要要求查詢操作作：選擇擇、投影影、連接接、除、、并、交交、差等等更新操作作：增加加、刪除除和修改改一次一集集合關系代數數和關系系演算高度非過過程化關系模型型概述關系模型型的三類類完整性性約束系統(tǒng)支持持：實體體完整性性和參照照完整性性用戶定義義：用戶戶定義的的完整性性本章主要要討論以以下問題題關系模型型是如何何表示數數據的關系模型型可以表表示何種種完整性性約束數據是如如何被查查詢的如何將由由ER模型表示示數據庫庫概念模模式轉換換為關系系模式((模式))的視圖(外外模式))問題關系模型型基本概概念關系域：一組組具有相相同數據據類型值值的集合合笛卡爾積積：給定定一組域域D1,D2,…,Dn，它們的笛笛卡爾積積為：D1XD2X…Dn={(d1,d2,…,dn)|di∈Di,i=1,2,,…n))元組：每每一個元元素(d1,d2,…,dn)叫做一個個n元組，或或元組分量：元元素中的的每一個個值di叫做一個個分量基數：若若Di為有限集集，其基基數為mi,則D1XD2X…Dn的基數為為：關系模型型基本概概念例如：給定三個個域D1=MAN=={王兵，李李平，張張英}，，D2=WOMAN={{丁梅，吳吳芳}D3=CHILD={{王一，李李一，李李二}D1XD2XD3={{（王兵，丁丁梅，王王一），，（王兵，丁丁梅，李李一），，（王兵，丁丁梅，李李二），，（王兵，吳吳芳，王王一），，（王兵，吳吳芳，李李一），，…}笛卡爾積積可以表表示為一一個二維維表，表表中的每每一行對對應一個個元組，，每一列列對應一一個域關系模型型基本概概念MANWOMANCHILD王兵丁丁梅王王一一王兵丁丁梅李李一一王兵丁丁梅李李二二王兵吳吳芳王王一一王兵吳吳芳李李一一王兵吳吳芳李李二二李平丁丁梅王王一一李平丁丁梅李李一一李平丁丁梅李李二二李平吳吳芳王王一一李平吳吳芳李李一一李平吳吳芳李李二二MANWOMANCHILD張英丁丁梅王王一一張英丁丁梅李李一一張英丁丁梅李李二二張英吳吳芳王王一一張英吳吳芳李李一一張英吳吳芳李李二二續(xù)左表關系模型型基本概概念關系:D1XD2X…Dn的子集叫叫做在域域D1,D2,…,,Dn上的關系系表示為R(D1,D2,…,,Dn)關系的目目或度：：n單元關系系：n=1二元關系系：n=2關系是一一個二維維表（子子集）例如：假假設王兵兵的妻子子是丁梅梅，他們們的孩子子是王一一，李平平的妻子子是吳芳芳，他們們的孩子子是李一一和李二二，則取取笛卡爾爾積的一一個子集集構造一一個關系系FAMILY關系模型型基本概概念在R(D1,D2,…,,Dn)表示中，，域可以以重名，，給每列列一個名名字，稱稱為屬性性，關系系表示為為：R(A1,A2,…,,An)例如：FAMILY((FATHER,MOTHER,,CHILD)MANWOMANCHILD王兵丁丁梅王王一一李平吳吳芳李李一一李平吳吳芳李李二二FAMILY關系模型型基本概概念候選碼：：能夠唯唯一標識識一個元元組的最最小屬性性組主碼：主屬性：：候選碼碼中的屬屬性非碼屬性性：不包包含在任任何候選選碼中的的屬性關系的性性質：關系模型型要求在在一個關關系中不不能存在在完全相相同的元元組(但但實際商商用關系系數據庫庫系統(tǒng)支支持重復復元組))關系中元元組行的的序并不不重要關系中列列的序并并不重要要（但有些系系統(tǒng)例外外）關系模型型基本概概念分量必須須取原子子值不同的列列可以出出自同一一個域給定域：：person=={王兵，李李平，張張英，丁丁梅，吳吳芳}child={{王義，李李一，李李二}MANWOMANCHILDfirstsecond王兵丁丁梅王王一李平吳吳芳李李一李李二二FAMILYbad關系模型型基本概概念構造FAMILY關系，仍仍然取personXpersonXchild的子集，，表示為為：FAMILY(FATHER,MOTHER,,CHILD)此處dom((FATHER))=dom(MOTHER))=person關系模式式：關系系的描述述形式化表表示：R(U,,D,,dom,F)，簡記為R(U))或R(A1,A2,…,,An)屬性向域域的映象象常常說說明為屬屬性的類類型和長長度關系模式式是型，，關系是是值關系模型型基本概概念在關系模模型中，，實體和和聯系都都是用關關系表示示的例如：左左圖學生(學號，姓名，，性別，，專業(yè)，，年齡))課程(課程號，課程名名，學時時，學分分)選修(學號，課程號，成績))一個關系系數據庫庫是一組組關系的的集合；；關系數數據庫模模式則是是該數據據庫所有有關系模模式的集集合學生課程選修mn關系模型型--關關系的完完整性關系模型型的完整整性是對對關系的的某種約約束實體完整整性：主主碼中的的屬性不不可取空空值(例例子)參照完整整性：例子：對對于關系系模式學生(學號，姓名，，性別，，專業(yè)，，年齡))課程(課程號，課程名名，學時時，學分分)選修(學號，課程號，成績))外碼：設設F是關系R的一個或或一組屬屬性，但但不是關關系R的碼，如如果F與關系S的主碼Ks相對應，，則稱F為關系R的外碼關系模型型--關關系的完完整性參照關系系R，被參照關關系S參照完整整性：F的取值必必須為：：或者取空空值或者等于于S中某個元元組的主主碼值例如：部門(部門號，部門名名，電話話)雇員(雇員號，雇員名名，職稱稱，部門門號)雇員中部部門號的的取值部門雇員擁有1n關系模型型--關關系的完完整性用戶定義義的完整整性：任何關系系數據庫庫系統(tǒng)都都應支持持實體完完整性和和參照完完整性用戶定義義的完整整性定義義某一具具體應用用中所涉涉及的數數據必須須滿足的的語義要要求，例例如年齡齡的取值值關系數據據庫系統(tǒng)統(tǒng)提供定定義和檢檢驗這類類完整性性機制關系模型型--關關系代數數關系代數數運算分分為：傳傳統(tǒng)的集集合運算算和專門門的關系系運算集合運算算前提：關關系R和關系S具有相同同的目，，相應的的屬性取取自同一一個域并：關系系R和關系S的并記作作：RS（下頁）差：關系系R和關系S的差記作作：R-S交：關系系R和關系S的交記作作：RS關系模型型--關關系代數數ABCABCABCa1b1c1a1b2c2a1b1c1a1b2c2a1b3c2a1b2c2a2b2c1a2b2c1a2b2c1a1b3c2ABCABCa1b2c2a1b1c1a2b2c1RSRSRSR-S關系模型型--關關系代數數R×SABCABCABCa1b1c1a1b1c1a1b2c2a1b2c2a1b1c1a1b3c2a2b2c1a1b1c1a2b2c1a1b2c2a1b2c2ABCa1b2c2a1b3c2a1b2c2a1b2c2a2b2c1a1b3c2a2b2c1a1b2c2a2b2c1a2b2c1a1b3c2a2b2c1a2b2c1RS關系模型型--關關系代數數廣義笛卡卡爾積：：兩個分分別為n和m目的關系系R和S的廣義笛笛卡爾積積是一個個n+m列的元組組的集合合。若R有k1個元組，，S有k2個元組，，則廣義義笛卡爾爾積有k1×k2個元組記作：R×S關系的建建立和修修改---SQL--92SQL語言的簡簡單發(fā)展展歷史SQL語言是由由IBM公司在SystemR系統(tǒng)中首首先提出出SQL在1986年被被ANSI采納為標標準，稱稱為SQL--86在1989又對對SQL標準進行行了少量量修改，，稱為SQL--89在1992年ANSI和ISO對SQL標準進行行主要修修改，稱稱之為SQL--92在1999年又又對SQL--92進行大量量修改((面向對對象的特特點)，，稱之為為SQL--3，有時也稱稱為SQL--99關系的建建立和修修改關系表建建立CREATETABLEStudents((sidCHAR((20)),nameCHAR(30),loginCHAR(20),,ageINTEGER,gpaREAL)關系表刪刪除DROPTABLEStudents關系表修修改ALTERTABLEStudentsADDCOLUMNmaiden-nameCHAR((10))關鍵字約約束---實現實實體完整整性通過UNIQUE子句來定定義候選選碼(候選關鍵鍵字)通過PRIMARYKEY子句來定定義主碼碼(主關鍵字字)CREATETABLEStudents((sidCHAR((20)),nameCHAR((30)),loginCHAR(20),ageINTEGER,gpaREAL,UNIQUE((name,,age),,UNIQUE((login)),PRIMARYKEY((sid)))外鍵約束束--實實現參照照完整性性外鍵約束束指的是是兩個關關系之間間的關鍵鍵字約束束關系,,考慮下下列關系系Students(sid,,name,,login,age,,gpa)Enrolled(sid,,cid,grade))從語義上上來講,,在關系系Enrolled中出現的的sid值,在關關系Students中必須存存在,Enrolled中的sid稱為外鍵鍵,引用用關系Students中的主關關鍵字sid外鍵必須須與被引引用關系系中的主主關鍵字字相匹配配可以有不不同的名名字列數要相相同,且且要具有有兼容的的數據類類型外鍵約束束-----示示例外鍵約束束的語義義在被參照照關系中中關鍵字字的值在在參照關關系中不不一定出出現但在參照照關系中中出現的的關鍵字字值在被被參照關關系中必必須要出出現如果我們們向關系系Enrolled中插入元元組<55555,Art104,,A>>,這個操作作將被拒拒絕因為為違反了了外鍵約約束外鍵約束束的語義義對于操作作:將關關系Students中的<53666,Jones,joines@cs,18,3..4>刪除,有有兩種處處理禁止這種種刪除操操作同時刪除除參照關關系中的的相關元元組值得注意意的是外外鍵可能能來自于于同一關關系,也也就是被被參照關關系就是是參照關關系Students(sid,,name,,login,age,,gpa,partner),,partner是對sid的一個外外鍵約束束Courses(cid,name,desc,preq),,preq是對cid的一個外外鍵約束束當一門課課程沒有有前期課課程時,,preq可以為空空,空值值并不違違反外鍵鍵約束外鍵約束束的定義義----SQL--92邏輯數據據庫設計計：ER到關系的的轉換實體集到到表的轉轉換實體集中中的屬性性映射為為表中的的屬性實體集中中的(主主)關鍵鍵字映射射為關系系中的((主)關關鍵字實體集中中屬性的的域映射射為關系系中屬性性的域實體集到到表的轉轉換---示示例多對多聯聯系集到到表的轉轉換多對多聯聯系被映映射為一一個關系系表，包包括屬性性：每個參加加聯系的的實體集集的主關關鍵字屬屬性，作作為外鍵鍵存在所有外鍵鍵構成該該實體集集的主關關鍵字聯系集本本身的屬屬性---一一般屬性性多對多聯聯系集到到表的轉轉換---例1mn多對多聯聯系集到到表的轉轉換---例1多對多聯聯系集到到表的轉轉換---例2mnp多對多聯聯系集到到表的轉轉換---例2CREATETABLEWork3--In((ssnCHAR(11),,didinteger,fromdate,,todate,,PRIMARYKEY(ssn,,did,from,to))FOREIGKEY(ssn))REFERENCESEmployees,ONDELETENOACTION,FOREIGKEY(did))REFERENCESDepartments,,FOREIGNKEY((from)REFERENCEDURATION,FOREIGNKEY((to))REFERENCEDURATION)一對多聯聯系集的的翻譯1n一對多聯聯系集的的翻譯------方法法一將一對多多聯系翻翻譯為一一個獨立立的表一對多聯聯系集的的翻譯------方法法二將Manages和Departments翻譯為一一個關系系關于聯系系集到關關系映射射的思考考題在一對多多聯系中中，Manages和Departments為什么可可以合并并為一個個關系？？對于一對對多聯系系翻譯的的兩種方方法的優(yōu)優(yōu)缺點是是什么？？對于一個個多對多多聯系集集為什么么必須映映射為一一個獨立立的關系系表？一對一聯聯系應如如何翻譯譯？思考題部部分答案案方法一和和方法二二的優(yōu)缺缺點方法一多多產生一一個關系系對于有些些查詢，，方法一一需要兩兩次連接接，而方方法二只只需要一一次連接接即可方法二的的缺點是是浪費空空間，如如果有些些部門沒沒有經理理的話具有參加加約束的的聯系集集的翻譯譯1nnm具有參加加約束的的1:n(1::1)聯系集的的翻譯具有參加加約束的的聯系集集的翻譯譯ssn的非空定定義反映映了參加加約束使用上面面的第一一種方法法也可以以表示Manages和Departments，但使用方方法二比比方法一一好，((why?因為方法法二浪費費空間的的缺點已已不復存存在)弱實體集集的翻譯譯一個弱實實體總是是參加一一個二元元一對多多聯系((?)全參加約約束1m弱實體集集的翻譯譯使用具有有1:n聯系的第第二種翻翻譯方法法（Why??）,但必須考考慮下面面的具體體要求必須考慮慮弱實體體集有一一個部分分關鍵字字當一個Owner實體被刪刪除以后后,弱實實體集中中相應的的實體也也應被刪刪除弱實體集集的翻譯譯類層次的的翻譯類層次的的翻譯---方法一三個實體體集翻譯譯成三個個關系實體集Employees的翻譯比比較簡單單關系Hourly__Emps的屬性包包括:ssn,,hourly_wages,hours__worked,;ssn是主關鍵鍵字;同同時ssn一個外鍵鍵;當當超類中中實體被被刪除時時子類中中的對象象也必須須刪除Contract_Emps的翻譯相相類似思考題：：為什么么在關系系Hourly__Emps的屬性中中不包含含屬性name和lot??體現繼承承性了嗎嗎？類層次的的翻譯---方法一CREATETABLEHourly_Emps((ssnCHAR(20),hourly__wagesREAL,,hours_workedINTEGER,,PRIMARYKEY(ssn),FOREIGKEY(ssn)REFERENCESEmployees,ONDELETECASCADE))類層次的的翻譯---方法二三個實體體集翻譯譯成兩個個關系僅生成兩兩個關系系:Hourly__Emps和Contract_Emps,他們都包包含超類類Employees的屬性,,除了主主關鍵字字約束以以外,不不需要定定義任何何約束當然，對對于overlap約束只能能用通用用約束機機制來實實現對于方法法一來講講，covering約束也只只能用通通用約束束機制來來實現類層次的的翻譯---兩兩種方法法的比較較方法一::當查詢詢涉及到到Employees的屬性和和其它一一些細節(jié)節(jié)屬性時時需要連連接操作作;當查查詢僅涉涉及到Employees的屬性時時則在Employees關系上進進行即可可;另一一個優(yōu)點點是可以以存儲非非Hourly__Emps和Contract_Emps的實體方法二::主要確確定無法法存儲非非Hourly__Emps和Contract_Emps的實體,,且name和lot出現了兩兩次;優(yōu)優(yōu)點是僅僅涉及到到Hourly__Emps或Contract_Emps的查詢僅僅在一個個關系上上進行即即可,不不需要額額外的連連接操作作,但涉涉及到所所有雇員員的查詢詢則需要要在兩個個關系上上進行;;實例分析析一個公司司數據庫庫需要存存儲雇員員、部門門和雇員員小孩的的信息。。雇員工工作在部部門(一一個雇員員只能工工作