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

第三章關系模型--本章內容基礎知識回顧關系模型概述關系模型基本概念關系模型的完整性約束關系代數邏輯數據庫設計：ER到關系的轉換關系演算第三章關系模型--本章內容基礎知識回顧1基礎知識回顧數據庫發(fā)展以數據模型劃分第一代網狀、層次數據庫系統(tǒng)。代表：1969年IBM的IMS(informationManagementSystem);美國CODASYL(ConferenceOnDataSystemLanguage)下屬的DBTG（DataBaseTaskGroup）于60年代末70年代初提議的方法。層次數據庫是數據庫的先驅，而網狀數據庫是數據庫概念、方法、技術的奠基者。第二代關系數據庫系統(tǒng)。1970年IBM公司的研究員E.F.Codd提出了數據庫的關系模型，關系方法和關系數據理論的研究。代表：IBM的SystemR和Berkele大學的INGRES，成果：奠定了關系模型的理論基礎；研究了關系數據庫語言，有關系代數、關系演算、SQL語言、QBE等；研制了大量的RDBMS的原型，實現了查詢優(yōu)化、并發(fā)控制、故障恢復等關鍵技術；基礎知識回顧數據庫發(fā)展2基礎知識回顧數據庫發(fā)展第三代以面向對象數據模型為主要特征的數據庫系統(tǒng)。模型更加豐富、數據管理功能功能更加強大、能支持傳統(tǒng)數據庫難以支持的新的應用。特征：支持數據管理、對象管理和知識管理；保持或者繼承第二代數據庫的技術；對其他系統(tǒng)開放（支持數據庫語言標準和標準網絡協(xié)議）。僅支持面向對象數據模型并不能稱為第三代數據庫系統(tǒng)?；A知識回顧數據庫發(fā)展3基礎知識回顧關系數據庫系統(tǒng)關系數據庫系統(tǒng)。產品的發(fā)展情況：(1)對關系模型的支持：第一階段（70年代）：僅支持關系數據結構、基本的關系操作（選擇、投影、連接）。如：dBASE第二階段（80年代)：SQL成為關系數據庫語言的國際標準第三階段（90年代）：加強了完整性、安全性的支持。(2)運行環(huán)境：第一階段：在大、中、小型機上的RDBMS，多用戶系統(tǒng)第二階段：提高可移植性，能在多種硬件平臺、和操作系統(tǒng)環(huán)境下運行；聯(lián)網，向分布式發(fā)展，支持多種協(xié)議。第三階段：分布式數據庫和客戶/服務器結構的數據庫系統(tǒng)的推出。追求開放性（可移植性、可連接性、可伸縮性）。基礎知識回顧關系數據庫系統(tǒng)4基礎知識回顧關系數據庫系統(tǒng)關系數據庫系統(tǒng)。產品的發(fā)展情況：(3)RDBMS系統(tǒng)構成：第一階段：早期的RDBMS產品主要提供數據定義、數據存取、數據控制等基本操作和數據存儲組織、并發(fā)控制、安全性、完整性檢查、系統(tǒng)恢復等RDBMS的核心功能。第二階段：以RDBMS基本功能為核心，開發(fā)外圍軟件系統(tǒng)，如：FORM報表生成系統(tǒng)，REPORT報表系統(tǒng)、MENU菜單生成系統(tǒng)、GRAPHIC圖形軟件等等。為用戶提供了良好的第四代應用開發(fā)環(huán)境。(4)對應用的支持：第一階段：用于信息管理、輔助決策等應用領域。第二階段：聯(lián)機事務處理的應用領域，提高RDBMS事務處理的能力。第三階段：由集中到分布，由局部到整個企業(yè)甚至整個行業(yè)。支持整個企業(yè)的聯(lián)機事務處理?；A知識回顧關系數據庫系統(tǒng)5關系模型概述為什么要學習關系模型?關系模型是目前廣泛使用的一種數據模型IBMDB2,MiscrosoftSQLServer,Informix,Oracle,Sybase,…………….僅有少量的遺產系統(tǒng)使用舊的數據模型IBM的IMS目前仍在使用目前關系模型的競爭者:面向對象的數據模型Objectstore,Versant,Ontos,……….對象關系模型:InformixUniversalServer,UniSQL,O2,ORACLE,DB2,………...關系模型概述為什么要學習關系模型?6關系模型概述關系數據模型是由E.F.Codd于1970年提出在此之前大多數數據庫系統(tǒng)是基于層次數據模型和網狀數據模型的關系模型給數據庫領域帶來了一場革命，并取代了舊的數據模型,E.F.Codd并因此于1983年獲得TuringAwards在70年代中期，IBM和UC-Berkeley開發(fā)了早期的關系型數據庫管理系統(tǒng)關系模型概述關系數據模型是由E.F.Codd于1970年提出7關系模型概述現在的關系型數據庫系統(tǒng)有IBM的DB2InformixOracleSybaseMicrosoft的Access,SQLServerFox-xParadox關系模型概述現在的關系型數據庫系統(tǒng)有8關系模型概述關系模型是十分簡單的關系模型的數據結構非常單一，實體、聯(lián)系都表示成關系一個關系是一個具有行和列的二維表關系模型給出關系操作的能力，但不對RDBMS語言給出具體的語法要求查詢操作：選擇、投影、連接、除、并、交、差等更新操作：增加、刪除和修改一次一集合關系代數和關系演算高度非過程化關系模型概述關系模型是十分簡單的9關系模型概述關系模型的三類完整性約束系統(tǒng)支持：實體完整性和參照完整性用戶定義：用戶定義的完整性本章主要討論以下問題關系模型是如何表示數據的關系模型可以表示何種完整性約束數據是如何被查詢的如何將由ER模型表示數據庫概念模式轉換為關系模式(模式)的視圖(外模式)問題關系模型概述關系模型的三類完整性約束10關系模型基本概念關系域：一組具有相同數據類型值的集合笛卡爾積：給定一組域D1,D2,…,Dn，它們的笛卡爾積為：D1XD2X…Dn={(d1,d2,…,dn)|di∈Di,i=1,2,…n)元組：每一個元素(d1,d2,…,dn)叫做一個n元組，或元組分量：元素中的每一個值di叫做一個分量基數：若Di為有限集，其基數為mi,則D1XD2X…Dn的基數為：關系模型基本概念關系11關系模型基本概念例如：給定三個域D1=MAN={王兵，李平，張英}，D2=WOMAN={丁梅，吳芳}D3=CHILD={王一，李一，李二}D1XD2XD3={（王兵，丁梅，王一），（王兵，丁梅，李一），（王兵，丁梅，李二），（王兵，吳芳，王一），（王兵，吳芳，李一），…}笛卡爾積可以表示為一個二維表，表中的每一行對應一個元組，每一列對應一個域關系模型基本概念例如：給定三個域D1=MAN={王兵，李平，12關系模型基本概念MANWOMANCHILD王兵丁梅王一王兵丁梅李一王兵丁梅李二王兵吳芳王一王兵吳芳李一王兵吳芳李二李平丁梅王一李平丁梅李一李平丁梅李二李平吳芳王一李平吳芳李一李平吳芳李二MANWOMANCHILD張英丁梅王一張英丁梅李一張英丁梅李二張英吳芳王一張英吳芳李一張英吳芳李二續(xù)左表關系模型基本概念MANWOMANCHIL13關系模型基本概念關系:D1XD2X…Dn的子集叫做在域D1,D2,…,Dn上的關系表示為R(D1,D2,…,Dn)關系的目或度：n單元關系：n=1二元關系：n=2關系是一個二維表（子集）例如：假設王兵的妻子是丁梅，他們的孩子是王一，李平的妻子是吳芳，他們的孩子是李一和李二，則取笛卡爾積的一個子集構造一個關系FAMILY關系模型基本概念關系:D1XD2X…Dn的子集叫做在域D114關系模型基本概念在R(D1,D2,…,Dn)表示中，域可以重名，給每列一個名字，稱為屬性，關系表示為：R(A1,A2,…,An)例如：FAMILY(FATHER,MOTHER,CHILD)MANWOMANCHILD王兵丁梅王一李平吳芳李一李平吳芳李二FAMILY關系模型基本概念在R(D1,D2,…,Dn)表示中，域15關系模型基本概念候選碼：能夠唯一標識一個元組的最小屬性組主碼：主屬性：候選碼中的屬性非碼屬性：不包含在任何候選碼中的屬性關系的性質：關系模型要求在一個關系中不能存在完全相同的元組(但實際商用關系數據庫系統(tǒng)支持重復元組)關系中元組行的序并不重要關系中列的序并不重要（但有些系統(tǒng)例外）關系模型基本概念候選碼：能夠唯一標識一個元組的最小屬性組16關系模型基本概念分量必須取原子值不同的列可以出自同一個域給定域：person={王兵，李平，張英，丁梅，吳芳}child={王義，李一，李二}MANWOMANCHILDfirstsecond王兵丁梅王一李平吳芳李一李二FAMILYbad關系模型基本概念分量必須取原子值MANWOMAN17關系模型基本概念構造FAMILY關系，仍然取personXpersonXchild的子集，表示為：FAMILY(FATHER,MOTHER,CHILD)此處dom(FATHER)=dom(MOTHER)=person關系模式：關系的描述形式化表示：R(U,D,dom,F)，簡記為R(U)或R(A1,A2,…,An)屬性向域的映象常常說明為屬性的類型和長度關系模式是型，關系是值關系模型基本概念構造FAMILY關系，仍然取personX18關系模型基本概念在關系模型中，實體和聯(lián)系都是用關系表示的例如：左圖

學生(學號，姓名，性別，專業(yè)，年齡)

課程(課程號，課程名，學時，學分)選修(學號，課程號，成績)一個關系數據庫是一組關系的集合；關系數據庫模式則是該數據庫所有關系模式的集合學生課程選修mn關系模型基本概念在關系模型中，實體和聯(lián)系都是用關系表示的學生19關系模型--關系的完整性關系模型的完整性是對關系的某種約束實體完整性：主碼中的屬性不可取空值(例子)參照完整性：例子：對于關系模式學生(學號，姓名，性別，專業(yè)，年齡)

課程(課程號，課程名，學時，學分)選修(學號，課程號，成績)外碼：設F是關系R的一個或一組屬性，但不是關系R的碼，如果F與關系S的主碼Ks相對應，則稱F為關系R的外碼關系模型--關系的完整性關系模型的完整性是對關系的某種約束20關系模型--關系的完整性參照關系R，被參照關系S參照完整性：F的取值必須為：或者取空值或者等于S中某個元組的主碼值例如：部門(部門號，部門名，電話)

雇員(雇員號，雇員名，職稱，部門號)雇員中部門號的取值部門雇員擁有1n關系模型--關系的完整性參照關系R，被參照關系S部門雇員擁有21關系模型--關系的完整性用戶定義的完整性：任何關系數據庫系統(tǒng)都應支持實體完整性和參照完整性用戶定義的完整性定義某一具體應用中所涉及的數據必須滿足的語義要求，例如年齡的取值關系數據庫系統(tǒng)提供定義和檢驗這類完整性機制關系模型--關系的完整性用戶定義的完整性：22關系模型--關系代數關系代數運算分為：傳統(tǒng)的集合運算和專門的關系運算集合運算前提：關系R和關系S具有相同的目，相應的屬性取自同一個域并：關系R和關系S的并記作：RS（下頁）差：關系R和關系S的差記作：R-S交：關系R和關系S的交記作：RS關系模型--關系代數關系代數運算分為：傳統(tǒng)的集合運算和專門的23關系模型--關系代數ABCABCABCa1b1c1a1b2c2a1b1c1a1b2c2a1b3c2a1b2c2a2b2c1a2b2c1a2b2c1a1b3c2ABCABCa1b2c2a1b1c1a2b2c1RSRSRSR-S關系模型--關系代數ABC24關系模型--關系代數R×SABCABCABCa1b1c1a1b1c1a1b2c2a1b2c2a1b1c1a1b3c2a2b2c1a1b1c1a2b2c1a1b2c2a1b2c2ABCa1b2c2a1b3c2a1b2c2a1b2c2a2b2c1a1b3c2a2b2c1a1b2c2a2b2c1a2b2c1a1b3c2a2b2c1a2b2c1RS關系模型--關系代數R×SABC25關系模型--關系代數廣義笛卡爾積：兩個分別為n和m目的關系R和S的廣義笛卡爾積是一個n+m列的元組的集合。若R有k1個元組，S有k2個元組，則廣義笛卡爾積有k1×k2個元組記作：R×S關系模型--關系代數廣義笛卡爾積：兩個分別為n和m目的關系R26關系的建立和修改--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關系的建立和修改--SQL-92SQL語言的簡單發(fā)展歷史27關系的建立和修改關系表建立CREATETABLEStudents(sidCHAR(20),nameCHAR(30),loginCHAR(20),ageINTEGER,gpaREAL)關系表刪除DROPTABLEStudents關系表修改ALTERTABLEStudentsADDCOLUMNmaiden-nameCHAR(10)關系的建立和修改關系表建立28關鍵字約束--實現實體完整性通過UNIQUE子句來定義候選碼(候選關鍵字)通過PRIMARYKEY子句來定義主碼(主關鍵字)CREATETABLEStudents(sidCHAR(20),nameCHAR(30),loginCHAR(20),ageINTEGER,gpaREAL,UNIQUE(name,age),UNIQUE(login),PRIMARYKEY(sid))關鍵字約束--實現實體完整性通過UNIQUE子句來定義候選碼29外鍵約束--實現參照完整性外鍵約束指的是兩個關系之間的關鍵字約束關系,考慮下列關系Students(sid,name,login,age,gpa)Enrolled(sid,cid,grade)從語義上來講,在關系Enrolled中出現的sid值,在關系Students中必須存在,Enrolled中的sid稱為外鍵,引用關系Students中的主關鍵字sid外鍵必須與被引用關系中的主關鍵字相匹配可以有不同的名字列數要相同,且要具有兼容的數據類型外鍵約束--實現參照完整性外鍵約束指的是兩個關系之間的關鍵字30外鍵約束----示例外鍵約束----示例31外鍵約束的語義在被參照關系中關鍵字的值在參照關系中不一定出現但在參照關系中出現的關鍵字值在被參照關系中必須要出現如果我們向關系Enrolled中插入元組<55555,Art104,A>,這個操作將被拒絕因為違反了外鍵約束外鍵約束的語義在被參照關系中關鍵字的值在參照關系中不一定出現32外鍵約束的語義對于操作:將關系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可以為空,空值并不違反外鍵約束外鍵約束的語義對于操作:將關系Students中的<536633外鍵約束的定義---SQL-92外鍵約束的定義---SQL-9234邏輯數據庫設計：ER到關系的轉換實體集到表的轉換實體集中的屬性映射為表中的屬性實體集中的(主)關鍵字映射為關系中的(主)關鍵字實體集中屬性的域映射為關系中屬性的域邏輯數據庫設計：ER到關系的轉換實體集到表的轉換35實體集到表的轉換--示例實體集到表的轉換--示例36多對多聯(lián)系集到表的轉換多對多聯(lián)系被映射為一個關系表，包括屬性：每個參加聯(lián)系的實體集的主關鍵字屬性，作為外鍵存在所有外鍵構成該實體集的主關鍵字聯(lián)系集本身的屬性--一般屬性多對多聯(lián)系集到表的轉換多對多聯(lián)系被映射為一個關系表，包括屬性37多對多聯(lián)系集到表的轉換--例1mn多對多聯(lián)系集到表的轉換--例1mn38多對多聯(lián)系集到表的轉換--例1多對多聯(lián)系集到表的轉換--例139多對多聯(lián)系集到表的轉換--例2mnp多對多聯(lián)系集到表的轉換--例2mnp40多對多聯(lián)系集到表的轉換--例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)多對多聯(lián)系集到表的轉換--例2CREATETABLEWo41一對多聯(lián)系集的翻譯1n一對多聯(lián)系集的翻譯1n42一對多聯(lián)系集的翻譯----方法一將一對多聯(lián)系翻譯為一個獨立的表一對多聯(lián)系集的翻譯----方法一將一對多聯(lián)系翻譯為一個獨立43一對多聯(lián)系集的翻譯----方法二將Manages和Departments翻譯為一個關系一對多聯(lián)系集的翻譯----方法二將Manages和Depa44關于聯(lián)系集到關系映射的思考題在一對多聯(lián)系中，Manages和Departments為什么可以合并為一個關系？對于一對多聯(lián)系翻譯的兩種方法的優(yōu)缺點是什么？對于一個多對多聯(lián)系集為什么必須映射為一個獨立的關系表？一對一聯(lián)系應如何翻譯？關于聯(lián)系集到關系映射的思考題在一對多聯(lián)系中，Manages和45思考題部分答案方法一和方法二的優(yōu)缺點方法一多產生一個關系對于有些查詢，方法一需要兩次連接，而方法二只需要一次連接即可方法二的缺點是浪費空間，如果有些部門沒有經理的話思考題部分答案方法一和方法二的優(yōu)缺點46具有參加約束的聯(lián)系集的翻譯1nnm具有參加約束的聯(lián)系集的翻譯1nnm47具有參加約束的1:n(1:1)聯(lián)系集的翻譯具有參加約束的1:n(1:1)聯(lián)系集的翻譯48具有參加約束的聯(lián)系集的翻譯ssn的非空定義反映了參加約束使用上面的第一種方法也可以表示Manages和Departments，但使用方法二比方法一好，(why?因為方法二浪費空間的缺點已不復存在)具有參加約束的聯(lián)系集的翻譯ssn的非空定義反映了參加約束49弱實體集的翻譯一個弱實體總是參加一個二元一對多聯(lián)系(?)全參加約束1m弱實體集的翻譯一個弱實體總是參加一個二元一對多聯(lián)系(?)1m50弱實體集的翻譯使用具有1:n聯(lián)系的第二種翻譯方法（Why?）,但必須考慮下面的具體要求必須考慮弱實體集有一個部分關鍵字當一個Owner實體被刪除以后,弱實體集中相應的實體也應被刪除弱實體集的翻譯使用具有1:n聯(lián)系的第二種翻譯方法（Why?）51弱實體集的翻譯弱實體集的翻譯52類層次的翻譯類層次的翻譯53類層次的翻譯--方法一三個實體集翻譯成三個關系實體集Employees的翻譯比較簡單關系Hourly_Emps的屬性包括:ssn,hourly_wages,hours_worked,;ssn是主關鍵字;同時ssn一個外鍵;當超類中實體被刪除時子類中的對象也必須刪除Contract_Emps的翻譯相類似思考題：為什么在關系Hourly_Emps的屬性中不包含屬性name和lot?

體現繼承性了嗎？類層次的翻譯--方法一三個實體集翻譯成三個關系54類層次的翻譯--方法一CREATETABLEHourly_Emps(ssnCHAR(20),hourly_wagesREAL,hours_workedINTEGER,PRIMARYKEY(ssn),FOREIGKEY(ssn)REFERENCESEmployees,ONDELETECASCADE)類層次的翻譯--方法一CREATETABLEHourl55類層次的翻譯--方法二三個實體集翻譯成兩個關系僅生成兩個關系:Hourly_Emps和Contract_Emps,他們都包含超類Employees的屬性,除了主關鍵字約束以外,不需要定義任何約束當然，對于overlap約束只能用通用約束機制來實現對于方法一來講，covering約束也只能用通用約束機制來實現類層次的翻譯--方法二三個實體集翻譯成兩個關系56類層次的翻譯--兩種方法的比較方法一:當查詢涉及到Employees的屬性和其它一些細節(jié)屬性時需要連接操作;當查詢僅涉及到Employees的屬性時則在Employees關系上進行即可;另一個優(yōu)點是可以存儲非Hourly_Emps和Contract_Emps的實體方法二:主要確定無法存儲非Hourly_Emps和Contract_Emps的實體,且name和lot出現了兩次;優(yōu)點是僅涉及到Hourly_Emps或Contract_Emps的查詢僅在一個關系上進行即可,不需要額外的連接操作,但涉及到所有雇員的查詢則需要在兩個關系上進行;類層次的翻譯--兩種方法的比較方法一:當查詢涉及到Empl57實例分析一個公司數據庫需要存儲雇員、部門和雇員小孩的信息。雇員工作在部門(一個雇員只能工作在一個部門)，每個部門由一個雇員管理，每個雇員小孩的名字是唯一的，假定小孩只有一個家長工作在這個公司，而且我們不關心哪些已經調離雇員的小孩情況。請畫出ER圖撲獲這些信息。雇員(ssn,salary,phone)部門(dno,dname,budget)小孩(name,age)實例分析一個公司數據庫需要存儲雇員、部門和雇員小孩的信息。雇58實例分析部門雇員小孩工作有1m管理n11ndnodnamebudgetssnsalaryphonenameage雇員(ssn,salary,phone,dno)部門(dno,dname,budget,ssnnotnull)小孩(ssn,name,age)實例分析部門雇員小孩工作有1m管理n11ndnodnameb59實例分析一個大學數據庫包括教授、課程信息。教授講授課程，下面幾種情況都是描述有關講授聯(lián)系集的，對于每一種情況畫ER圖描述教授可以在幾個學期講授同一門課程，但僅最近一次的講授活動需被記錄下來教授可以在幾個學期講授同一門課程，每次講授活動需被記錄下來每個教授必須講授課程每個教授只講授一門課程實例分析一個大學數據庫包括教授、課程信息。教授講授課程，下面60實例分析每個教授只講授一門課程，每門課程可有幾位教授講授假定一些課程可由一組教授聯(lián)合講授假定一些特定課程只能由一組教授聯(lián)合講授，且這些教授中的任一位不可能獨立講授這門課程（思考題）實例分析每個教授只講授一門課程，每門課程可有幾位教授講授61實例分析教授課程講授nm職工號姓名電話課號課時學分班級學期人數（1）實例分析教授課程講授nm職工號姓名電話課號課時學分班級學期人62實例分析教授課程講授nm職工號姓名電話課號課時學分班級學期人數教授課程講授nm職工號姓名電話課號課時學分班級學期人數？講授情況p（2）實例分析教授課程講授nm職工號姓名電話課號課時學分班級學期人63實例分析教授課程講授nm職工號姓名電話課號課時學分班級學期人數講授情況n（3）實例分析教授課程講授nm職工號姓名電話課號課時學分班級學期人64實例分析教授課程講授m1職工號姓名電話課號課時學分班級學期人數講授情況n（4，5）實例分析教授課程講授m1職工號姓名電話課號課時學分班級學期人65實例分析教授課程講授m1職工號姓名電話課號課時學分班級講授號人數講授情況n學期（6）實例分析教授課程講授m1職工號姓名電話課號課時學分班級講授號66實例分析教授課程m1職工號姓名電話課號課時學分n（7）組構成nmISA一般課程特定課程講授2講授11參考答案實例分析教授課程m1職工號姓名電話課號課時學分n（7）組構成67第三章關系模型--本章內容基礎知識回顧關系模型概述關系模型基本概念關系模型的完整性約束關系代數邏輯數據庫設計：ER到關系的轉換關系演算第三章關系模型--本章內容基礎知識回顧68基礎知識回顧數據庫發(fā)展以數據模型劃分第一代網狀、層次數據庫系統(tǒng)。代表：1969年IBM的IMS(informationManagementSystem);美國CODASYL(ConferenceOnDataSystemLanguage)下屬的DBTG（DataBaseTaskGroup）于60年代末70年代初提議的方法。層次數據庫是數據庫的先驅，而網狀數據庫是數據庫概念、方法、技術的奠基者。第二代關系數據庫系統(tǒng)。1970年IBM公司的研究員E.F.Codd提出了數據庫的關系模型，關系方法和關系數據理論的研究。代表：IBM的SystemR和Berkele大學的INGRES，成果：奠定了關系模型的理論基礎；研究了關系數據庫語言，有關系代數、關系演算、SQL語言、QBE等；研制了大量的RDBMS的原型，實現了查詢優(yōu)化、并發(fā)控制、故障恢復等關鍵技術；基礎知識回顧數據庫發(fā)展69基礎知識回顧數據庫發(fā)展第三代以面向對象數據模型為主要特征的數據庫系統(tǒng)。模型更加豐富、數據管理功能功能更加強大、能支持傳統(tǒng)數據庫難以支持的新的應用。特征：支持數據管理、對象管理和知識管理；保持或者繼承第二代數據庫的技術；對其他系統(tǒng)開放（支持數據庫語言標準和標準網絡協(xié)議）。僅支持面向對象數據模型并不能稱為第三代數據庫系統(tǒng)。基礎知識回顧數據庫發(fā)展70基礎知識回顧關系數據庫系統(tǒng)關系數據庫系統(tǒng)。產品的發(fā)展情況：(1)對關系模型的支持：第一階段（70年代）：僅支持關系數據結構、基本的關系操作（選擇、投影、連接）。如：dBASE第二階段（80年代)：SQL成為關系數據庫語言的國際標準第三階段（90年代）：加強了完整性、安全性的支持。(2)運行環(huán)境：第一階段：在大、中、小型機上的RDBMS，多用戶系統(tǒng)第二階段：提高可移植性，能在多種硬件平臺、和操作系統(tǒng)環(huán)境下運行；聯(lián)網，向分布式發(fā)展，支持多種協(xié)議。第三階段：分布式數據庫和客戶/服務器結構的數據庫系統(tǒng)的推出。追求開放性（可移植性、可連接性、可伸縮性）?；A知識回顧關系數據庫系統(tǒng)71基礎知識回顧關系數據庫系統(tǒng)關系數據庫系統(tǒng)。產品的發(fā)展情況：(3)RDBMS系統(tǒng)構成：第一階段：早期的RDBMS產品主要提供數據定義、數據存取、數據控制等基本操作和數據存儲組織、并發(fā)控制、安全性、完整性檢查、系統(tǒng)恢復等RDBMS的核心功能。第二階段：以RDBMS基本功能為核心，開發(fā)外圍軟件系統(tǒng)，如：FORM報表生成系統(tǒng)，REPORT報表系統(tǒng)、MENU菜單生成系統(tǒng)、GRAPHIC圖形軟件等等。為用戶提供了良好的第四代應用開發(fā)環(huán)境。(4)對應用的支持：第一階段：用于信息管理、輔助決策等應用領域。第二階段：聯(lián)機事務處理的應用領域，提高RDBMS事務處理的能力。第三階段：由集中到分布，由局部到整個企業(yè)甚至整個行業(yè)。支持整個企業(yè)的聯(lián)機事務處理?；A知識回顧關系數據庫系統(tǒng)72關系模型概述為什么要學習關系模型?關系模型是目前廣泛使用的一種數據模型IBMDB2,MiscrosoftSQLServer,Informix,Oracle,Sybase,…………….僅有少量的遺產系統(tǒng)使用舊的數據模型IBM的IMS目前仍在使用目前關系模型的競爭者:面向對象的數據模型Objectstore,Versant,Ontos,……….對象關系模型:InformixUniversalServer,UniSQL,O2,ORACLE,DB2,………...關系模型概述為什么要學習關系模型?73關系模型概述關系數據模型是由E.F.Codd于1970年提出在此之前大多數數據庫系統(tǒng)是基于層次數據模型和網狀數據模型的關系模型給數據庫領域帶來了一場革命，并取代了舊的數據模型,E.F.Codd并因此于1983年獲得TuringAwards在70年代中期，IBM和UC-Berkeley開發(fā)了早期的關系型數據庫管理系統(tǒng)關系模型概述關系數據模型是由E.F.Codd于1970年提出74關系模型概述現在的關系型數據庫系統(tǒng)有IBM的DB2InformixOracleSybaseMicrosoft的Access,SQLServerFox-xParadox關系模型概述現在的關系型數據庫系統(tǒng)有75關系模型概述關系模型是十分簡單的關系模型的數據結構非常單一，實體、聯(lián)系都表示成關系一個關系是一個具有行和列的二維表關系模型給出關系操作的能力，但不對RDBMS語言給出具體的語法要求查詢操作：選擇、投影、連接、除、并、交、差等更新操作：增加、刪除和修改一次一集合關系代數和關系演算高度非過程化關系模型概述關系模型是十分簡單的76關系模型概述關系模型的三類完整性約束系統(tǒng)支持：實體完整性和參照完整性用戶定義：用戶定義的完整性本章主要討論以下問題關系模型是如何表示數據的關系模型可以表示何種完整性約束數據是如何被查詢的如何將由ER模型表示數據庫概念模式轉換為關系模式(模式)的視圖(外模式)問題關系模型概述關系模型的三類完整性約束77關系模型基本概念關系域：一組具有相同數據類型值的集合笛卡爾積：給定一組域D1,D2,…,Dn，它們的笛卡爾積為：D1XD2X…Dn={(d1,d2,…,dn)|di∈Di,i=1,2,…n)元組：每一個元素(d1,d2,…,dn)叫做一個n元組，或元組分量：元素中的每一個值di叫做一個分量基數：若Di為有限集，其基數為mi,則D1XD2X…Dn的基數為：關系模型基本概念關系78關系模型基本概念例如：給定三個域D1=MAN={王兵，李平，張英}，D2=WOMAN={丁梅，吳芳}D3=CHILD={王一，李一，李二}D1XD2XD3={（王兵，丁梅，王一），（王兵，丁梅，李一），（王兵，丁梅，李二），（王兵，吳芳，王一），（王兵，吳芳，李一），…}笛卡爾積可以表示為一個二維表，表中的每一行對應一個元組，每一列對應一個域關系模型基本概念例如：給定三個域D1=MAN={王兵，李平，79關系模型基本概念MANWOMANCHILD王兵丁梅王一王兵丁梅李一王兵丁梅李二王兵吳芳王一王兵吳芳李一王兵吳芳李二李平丁梅王一李平丁梅李一李平丁梅李二李平吳芳王一李平吳芳李一李平吳芳李二MANWOMANCHILD張英丁梅王一張英丁梅李一張英丁梅李二張英吳芳王一張英吳芳李一張英吳芳李二續(xù)左表關系模型基本概念MANWOMANCHIL80關系模型基本概念關系:D1XD2X…Dn的子集叫做在域D1,D2,…,Dn上的關系表示為R(D1,D2,…,Dn)關系的目或度：n單元關系：n=1二元關系：n=2關系是一個二維表（子集）例如：假設王兵的妻子是丁梅，他們的孩子是王一，李平的妻子是吳芳，他們的孩子是李一和李二，則取笛卡爾積的一個子集構造一個關系FAMILY關系模型基本概念關系:D1XD2X…Dn的子集叫做在域D181關系模型基本概念在R(D1,D2,…,Dn)表示中，域可以重名，給每列一個名字，稱為屬性，關系表示為：R(A1,A2,…,An)例如：FAMILY(FATHER,MOTHER,CHILD)MANWOMANCHILD王兵丁梅王一李平吳芳李一李平吳芳李二FAMILY關系模型基本概念在R(D1,D2,…,Dn)表示中，域82關系模型基本概念候選碼：能夠唯一標識一個元組的最小屬性組主碼：主屬性：候選碼中的屬性非碼屬性：不包含在任何候選碼中的屬性關系的性質：關系模型要求在一個關系中不能存在完全相同的元組(但實際商用關系數據庫系統(tǒng)支持重復元組)關系中元組行的序并不重要關系中列的序并不重要（但有些系統(tǒng)例外）關系模型基本概念候選碼：能夠唯一標識一個元組的最小屬性組83關系模型基本概念分量必須取原子值不同的列可以出自同一個域給定域：person={王兵，李平，張英，丁梅，吳芳}child={王義，李一，李二}MANWOMANCHILDfirstsecond王兵丁梅王一李平吳芳李一李二FAMILYbad關系模型基本概念分量必須取原子值MANWOMAN84關系模型基本概念構造FAMILY關系，仍然取personXpersonXchild的子集，表示為：FAMILY(FATHER,MOTHER,CHILD)此處dom(FATHER)=dom(MOTHER)=person關系模式：關系的描述形式化表示：R(U,D,dom,F)，簡記為R(U)或R(A1,A2,…,An)屬性向域的映象常常說明為屬性的類型和長度關系模式是型，關系是值關系模型基本概念構造FAMILY關系，仍然取personX85關系模型基本概念在關系模型中，實體和聯(lián)系都是用關系表示的例如：左圖

學生(學號，姓名，性別，專業(yè)，年齡)

課程(課程號，課程名，學時，學分)選修(學號，課程號，成績)一個關系數據庫是一組關系的集合；關系數據庫模式則是該數據庫所有關系模式的集合學生課程選修mn關系模型基本概念在關系模型中，實體和聯(lián)系都是用關系表示的學生86關系模型--關系的完整性關系模型的完整性是對關系的某種約束實體完整性：主碼中的屬性不可取空值(例子)參照完整性：例子：對于關系模式學生(學號，姓名，性別，專業(yè)，年齡)

課程(課程號，課程名，學時，學分)選修(學號，課程號，成績)外碼：設F是關系R的一個或一組屬性，但不是關系R的碼，如果F與關系S的主碼Ks相對應，則稱F為關系R的外碼關系模型--關系的完整性關系模型的完整性是對關系的某種約束87關系模型--關系的完整性參照關系R，被參照關系S參照完整性：F的取值必須為：或者取空值或者等于S中某個元組的主碼值例如：部門(部門號，部門名，電話)

雇員(雇員號，雇員名，職稱，部門號)雇員中部門號的取值部門雇員擁有1n關系模型--關系的完整性參照關系R，被參照關系S部門雇員擁有88關系模型--關系的完整性用戶定義的完整性：任何關系數據庫系統(tǒng)都應支持實體完整性和參照完整性用戶定義的完整性定義某一具體應用中所涉及的數據必須滿足的語義要求，例如年齡的取值關系數據庫系統(tǒng)提供定義和檢驗這類完整性機制關系模型--關系的完整性用戶定義的完整性：89關系模型--關系代數關系代數運算分為：傳統(tǒng)的集合運算和專門的關系運算集合運算前提：關系R和關系S具有相同的目，相應的屬性取自同一個域并：關系R和關系S的并記作：RS（下頁）差：關系R和關系S的差記作：R-S交：關系R和關系S的交記作：RS關系模型--關系代數關系代數運算分為：傳統(tǒng)的集合運算和專門的90關系模型--關系代數ABCABCABCa1b1c1a1b2c2a1b1c1a1b2c2a1b3c2a1b2c2a2b2c1a2b2c1a2b2c1a1b3c2ABCABCa1b2c2a1b1c1a2b2c1RSRSRSR-S關系模型--關系代數ABC91關系模型--關系代數R×SABCABCABCa1b1c1a1b1c1a1b2c2a1b2c2a1b1c1a1b3c2a2b2c1a1b1c1a2b2c1a1b2c2a1b2c2ABCa1b2c2a1b3c2a1b2c2a1b2c2a2b2c1a1b3c2a2b2c1a1b2c2a2b2c1a2b2c1a1b3c2a2b2c1a2b2c1RS關系模型--關系代數R×SABC92關系模型--關系代數廣義笛卡爾積：兩個分別為n和m目的關系R和S的廣義笛卡爾積是一個n+m列的元組的集合。若R有k1個元組，S有k2個元組，則廣義笛卡爾積有k1×k2個元組記作：R×S關系模型--關系代數廣義笛卡爾積：兩個分別為n和m目的關系R93關系的建立和修改--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關系的建立和修改--SQL-92SQL語言的簡單發(fā)展歷史94關系的建立和修改關系表建立CREATETABLEStudents(sidCHAR(20),nameCHAR(30),loginCHAR(20),ageINTEGER,gpaREAL)關系表刪除DROPTABLEStudents關系表修改ALTERTABLEStudentsADDCOLUMNmaiden-nameCHAR(10)關系的建立和修改關系表建立95關鍵字約束--實現實體完整性通過UNIQUE子句來定義候選碼(候選關鍵字)通過PRIMARYKEY子句來定義主碼(主關鍵字)CREATETABLEStudents(sidCHAR(20),nameCHAR(30),loginCHAR(20),ageINTEGER,gpaREAL,UNIQUE(name,age),UNIQUE(login),PRIMARYKEY(sid))關鍵字約束--實現實體完整性通過UNIQUE子句來定義候選碼96外鍵約束--實現參照完整性外鍵約束指的是兩個關系之間的關鍵字約束關系,考慮下列關系Students(sid,name,login,age,gpa)Enrolled(sid,cid,grade)從語義上來講,在關系Enrolled中出現的sid值,在關系Students中必須存在,Enrolled中的sid稱為外鍵,引用關系Students中的主關鍵字sid外鍵必須與被引用關系中的主關鍵字相匹配可以有不同的名字列數要相同,且要具有兼容的數據類型外鍵約束--實現參照完整性外鍵約束指的是兩個關系之間的關鍵字97外鍵約束----示例外鍵約束----示例98外鍵約束的語義在被參照關系中關鍵字的值在參照關系中不一定出現但在參照關系中出現的關鍵字值在被參照關系中必須要出現如果我們向關系Enrolled中插入元組<55555,Art104,A>,這個操作將被拒絕因為違反了外鍵約束外鍵約束的語義在被參照關系中關鍵字的值在參照關系中不一定出現99外鍵約束的語義對于操作:將關系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可以為空,空值并不違反外鍵約束外鍵約束的語義對于操作:將關系Students中的<5366100外鍵約束的定義---SQL-92外鍵約束的定義---SQL-92101邏輯數據庫設計：ER到關系的轉換實體集到表的轉換實體集中的屬性映射為表中的屬性實體集中的(主)關鍵字映射為關系中的(主)關鍵字實體集中屬性的域映射為關系中屬性的域邏輯數據庫設計：ER到關系的轉換實體集到表的轉換102實體集到表的轉換--示例實體集到表的轉換--示例103多對多聯(lián)系集到表的轉換多對多聯(lián)系被映射為一個關系表，包括屬性：每個參加聯(lián)系的實體集的主關鍵字屬性，作為外鍵存在所有外鍵構成該實體集的主關鍵字聯(lián)系集本身的屬性--一般屬性多對多聯(lián)系集到表的轉換多對多聯(lián)系被映射為一個關系表，包括屬性104多對多聯(lián)系集到表的轉換--例1mn多對多聯(lián)系集到表的轉換--例1mn105多對多聯(lián)系集到表的轉換--例1多對多聯(lián)系集到表的轉換--例1106多對多聯(lián)系集到表的轉換--例2mnp多對多聯(lián)系集到表的轉換--例2mnp107多對多聯(lián)系集到表的轉換--例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)多對多聯(lián)系集到表的轉換--例2CREATETABLEWo108一對多聯(lián)系集的翻譯1n一對多聯(lián)系集的翻譯1n109一對多聯(lián)系集的翻譯----方法一將一對多聯(lián)系翻譯為一個獨立的表一對多聯(lián)系集的翻譯----方法一將一對多聯(lián)系翻譯為一個獨立110一對多聯(lián)系集的翻譯----方法二將Manages和Departments翻譯為一個關系一對多聯(lián)系集的翻譯----方法二將Manages和Depa111關于聯(lián)系集到關系映射的思考題在一對多聯(lián)系中，Manages和Departments為什么可以合并為一個關系？對于一對多聯(lián)系翻譯的兩種方法的優(yōu)缺點是什么？對于一個多對多聯(lián)系集為什么必須映射為一個獨立的關系表？一對一聯(lián)系應如何翻譯？關于聯(lián)系集到關系映射的思考題在一對多聯(lián)系中，Manages和112思考題部分答案方法一和方法二的優(yōu)缺點方法一多產生一個關系對于有些查詢，方法一需要兩次連接，而方法二只需要一次連接即可方法二的缺點是浪費空間，如果有些部門沒有經理的話思考題部分答案方法一和方法二的優(yōu)缺點113具有參加約束的聯(lián)系集的翻譯1nnm具有參加約束的聯(lián)系集的翻譯1nnm114具有參加約束的1:n(1:1)聯(lián)系集的翻譯具有參加約束的1:n(1:1)聯(lián)系集的翻譯115具有參加約束的聯(lián)系集的翻譯ssn的非空定義反映了參加約束使用上面的第一種方法也可以表示Manages和Departments，但使用方法二比方法一好，(why?因為方法二浪費空間的缺點已不復存在)具有參加約束的聯(lián)系集的翻譯ssn的非空定義反映了參加約束116弱實體集的翻譯一個弱實體總是參加一個二元一對多聯(lián)系(?)全參加約束1m弱實體集的翻譯一個弱實體總是參加一個二元一對多聯(lián)系(?)1m117弱實體集的翻譯使用具有1:n聯(lián)系的第二種翻譯方法（Why?）,但必須考