第6章數據庫的保護技術

數據庫概論第6章數據庫的保護技術6.1數據庫的安全性6.2數據庫的完整性6.3并發(fā)控制6.4數據庫的恢復技術數據庫的安全性是指保護數據庫，防止不合法的使用，以免數據的泄露、更改和破壞。第6章數據庫的保護技術6.1.1計算機系統安全性為計算機系統建立和采取的各種安全保護措施，以保護計算機系統中的硬件、軟件及數據，防止因偶然或惡意的原因使系統遭到破壞，數據遭到更改或泄露等。1.計算機系統外部的安全問題(1)自然環(huán)境中的安全問題：如計算機機房、設備及其周邊環(huán)境的安全問題、防火、防盜、防人為進行物理破壞等問題；(2)社會環(huán)境中的安全問題：如各種規(guī)章制度的制定問題、對相關人員的管理和安全性教育等問題；(3)設備環(huán)境中的安全問題：如設備的定期檢查、維修及更新等問題。6.1.1計算機系統安全性(1)計算機系統中的安全問題：如病毒的侵入、黑客的攻擊等；(2)操作系統中的安全問題：如防止未經授權通過操作系統進入數據庫系統，進行非法操作；(3)數據庫系統中的安全問題：如用戶的身份確認問題、數據庫的操作權限問題；(4)應用系統中的安全問題：如各種應用程序本身存在的一些安全漏洞問題等。2.計算機系統內部的安全問題6.1.1計算機系統安全性6.1.2安全性控制的方法安全性控制就是要盡可能地杜絕所有可能的數據庫非法訪問。非法使用數據庫的情況編寫合法程序繞過DBMS及其授權機制直接或編寫應用程序執(zhí)行非授權操作通過多次合法查詢數據庫從中推導出一些保密數據6.1.2安全性控制的方法安全性不僅是數據庫層面的，在計算機系統都存在這一問題。計算機系統中，安全措施是一級一級層層設置

圖6-1安全控制模型6.1.2安全性控制的方法數據庫安全性控制的常用方法用戶標識和鑒別存取控制視圖數據審計數據加密1.用戶標識與鑒別用戶標識與鑒別（Identification&Authentication）系統提供的最外層安全保護措施6.1.2安全性控制的方法身份(Identification)認證口令(Password)認證系統核對口令以鑒別用戶身份

隨機數運算（ComputeringofRandomNumber）認證每個用戶預先約定好一個計算過程或者函數1.用戶標識與鑒別6.1.2安全性控制的方法2.用戶存取權限控制用戶存取權限指的是不同的用戶對于不同的數據對象允許執(zhí)行的操作權限。存取控制機制組成定義用戶權限合法權限檢查用戶權限定義和合法權檢查機制一起組成了DBMS的安全子系統6.1.2安全性控制的方法3.視圖機制把要保密的數據對無權存取這些數據的用戶隱藏起來，對數據提供一定程度的安全保護主要功能是提供數據獨立性，無法完全滿足要求間接實現了支持存取謂詞的用戶權限定義6.1.2安全性控制的方法4.審計審計是一種監(jiān)視措施，把用戶對數據庫的所有操作自動記錄下來放入審計日志中。審計日志的內容：操作類型、操作終端標識、操作者標識、操作日期和時間、操作所涉及的相關數據、操作的前象和后象。DBA利用審計日志，找出非法存取數據的人、時間和內容。6.1.2安全性控制的方法5.數據加密數據加密防止數據庫中數據在存儲和傳輸中失密的有效手段加密方法替換方法置換方法混合方法DBMS中的數據加密6.1.2安全性控制的方法第6章數據庫的保護技術6.1數據庫的安全性6.2數據庫的完整性

6.3并發(fā)控制6.4數據庫的恢復技術6.2數據庫的完整性數據庫的完整性數據的正確性和相容性數據的完整性和安全性是兩個不同概念數據的完整性防止數據庫中存在不符合語義的數據，也就是防止數據庫中存在不正確的數據防范對象：不合語義的、不正確的數據數據的安全性保護數據庫防止惡意的破壞和非法的存取防范對象：非法用戶和非法操作根據完整性約束條件的作用對象和狀態(tài)，數據庫完整性約束可分為六類：列級靜態(tài)約束元組級靜態(tài)約束關系級靜態(tài)約束列級動態(tài)約束元組級動態(tài)約束關系級動態(tài)約束6.2.1完整性約束條件的類型6.2.1完整性約束條件的類型（1）列級靜態(tài)約束：是對屬性值域的說明，即數據類型、數據格式和取值范圍的約束。（2）元組級靜態(tài)約束：是對元組各個屬性值之間關系的約束。（3）關系級靜態(tài)約束：是一個關系中各個元組之間或者若干個關系之間存在的各種聯系的約束。常見的關系級靜態(tài)約束有：實體完整性約束；參照完整性約束、函數依賴約束、統計依賴約束6.2.1完整性約束條件的類型（4）列級動態(tài)約束：是修改定義或屬性值時應滿足的約束條件，如將原來允許空值的屬性修改為不允許空值時，如果該屬性當前已存在空值，則將拒絕修改。（5）元組級動態(tài)約束：是修改某個元組的值時要參照該元組的原有值，新值和原有值之間應滿足某種約束條件。（6）關系級動態(tài)約束：是關系新舊狀態(tài)變化應滿足的約束條件。如事務的一致性、原子性等約束條件。關系級動態(tài)約束實現時的開銷較大。6.2.2完整性控制機制的功能

（1）定義功能：為用戶提供定義完整性約束條件的命令或工具。（2）檢查功能：能夠自動檢查用戶發(fā)出的操作請求是否違背了完整性約束條件。（3）保護功能：當發(fā)現用戶的操作請求使數據違背了完整性約束條件時，能夠自動采取一定的措施確保數據的完整性不遭破壞。1.參照關系中的外鍵取值問題【例】設一個企業(yè)的數據庫中有職工關系Employee和部門關系Depart，關系Employee的主鍵為職工號Eno，外鍵為部門號Dno關系Depart的主鍵為部門號DnoEmployee是參照關系,關系Depart為被參照關系在關系Employee中，當某一元組的Dno列值為空值，表示該職工尚未分配到任何具體的部門工作。這和具體實際的語義是相符的，因此，關系Employee的外鍵Dno列可以取空值。6.2.2完整性控制機制的功能

【例】在學生選課數據庫中，有學生關系Student和選課關系SCSC為參照關系，外鍵為Sno，Student為被參照關系，其主鍵為Sno。若關系SC的外鍵Sno為空值，而其對應的成績字段Grade中卻有值，則表明尚不存在的某個學生選修了某門課程。這顯然與實際情況是不相符的.因此，關系SC的外鍵Sno列值不能取空值。1.參照關系中的外鍵取值問題6.2.2完整性控制機制的功能

2.被參照關系中刪除元組的問題（1）級聯刪除（CascadesDelete）：就是將參照關系中所有外鍵值與被參照關系中要刪除元組主鍵值相同的元組一起刪除。如果被參照關系又是另一關系的參照關系，則這種刪除操作會持續(xù)級聯下去。（2）受限刪除（RestrictedDelete）：就是當參照關系中沒有任何元組的外鍵值與被參照關系中要刪除元組的主鍵值相同時，才允許執(zhí)行此刪除操作，否則拒絕執(zhí)行這個刪除操作。（3）置空值操作（NullifiesDelete）：就是刪除被參照關系的元組時，并將參照關系中與被參照關系中被刪除元組主鍵值相等的外鍵值置為空值。6.2.2完整性控制機制的功能

例如：要刪除Student關系中Sno=“0906064201”的元組，而SC關系中有3個元組的Sno都等于“0906064201”。級聯刪除：將SC關系中所有3個Sno=“0906064201”的元組一起刪除。受限刪除：系統將拒絕執(zhí)行此刪除操作。置空值刪除：將SC關系中所有Sno=“0906064201”的元組的Sno值置為空值。2.被參照關系中刪除元組的問題6.2.2完整性控制機制的功能

3.在參照關系中插入元組的問題（1）受限插入：僅當被參照關系中存在相應的元組，其主鍵值與參照關系插入元組的外鍵值相同時，系統才執(zhí)行插入操作，否則拒絕此操作（2）遞歸插入：首先向被參照關系中插入相應的元組，其主鍵值等于參照關系插入元組的外鍵值，然后向參照關系插入元組。6.2.2完整性控制機制的功能

4.元組中主鍵值的修改問題（1）不允許修改鍵碼：不允許進行主鍵值的修改。如果確實需要修改主鍵值，只能先刪除該元組，再將具有新主鍵值的元組插入到關系中。（2）允許修改主鍵：允許進行主鍵值的修改，但必須保證主鍵的唯一性和非空性。6.2.2完整性控制機制的功能

例如：將Student關系中Sno=“0906064201”的元組中Sno值改為“0906064215”。而SC關系中有3個元組的Sno=“0906064201”。級聯修改：將SC關系中3個Sno=“0906064201”元組中的Sno值也改為“0906064215”。如果參照關系同時又是另一個關系的被參照關系，則這種修改操作會繼續(xù)級聯下去。受限修改：只有SC中沒有任何元組的Sno=“0906064201”時，才能修改Student表中Sno=“0906064201”的元組的Sno值改為“0906064215”。置空值修改：將Student表中Sno=“0906064201”的元組的Sno值改為“0906064215”。而將SC表中所有Sno=“0906064201”的元組的Sno值置為空值。4.元組中主鍵值的修改問題6.2.2完整性控制機制的功能

6.2.3完整性設計原則（1）根據數據庫完整性約束的類型確定其實現的系統層次和方式，并提前考慮對系統性能的影響。一般情況下，靜態(tài)約束應盡量包含在數據庫模式中，而動態(tài)約束由應用程序實現。（2）實體完整性約束、參照完整性約束是關系數據庫最重要的完整性約束，在不影響系統關鍵性能的前提下需盡量應用。（3）要慎用目前主流DBMS都支持的觸發(fā)器功能，一方面由于觸發(fā)器的性能開銷較大，另一方面，觸發(fā)器的多級觸發(fā)不好控制，容易發(fā)生錯誤。（4）在需求分析階段就必須制定完整性約束的命名規(guī)范，盡量使用有意義的英文單詞、縮寫詞、表名、列名及下劃線等組合，使其易于識別和記憶。（5）要根據業(yè)務規(guī)則對數據庫完整性進行細致的測試，以盡早排除隱含的完整性約束間的沖突和對性能的影響。（6）要有專職的數據庫設計小組，自始至終負責數據庫的分析、設計、測試、實施及早期維護。數據庫設計人員不僅負責基于DBMS的數據庫完整性約束的設計實現，還要負責對應用軟件實現的數據庫完整性約束進行審核。（7）應采用合適的CASE工具來降低數據庫設計各階段的工作量。6.2.3完整性設計原則6.2.4觸發(fā)器

觸發(fā)器（Trigger）是用戶定義在關系表上的一類由事件驅動的特殊過程由服務器自動激活可以進行更為復雜的檢查和操作，具有更精細和更強大的數據控制能力

1.定義觸發(fā)器CREATETRIGGER語法格式

CREATETRIGGER<觸發(fā)器名>{BEFORE|AFTER}<觸發(fā)事件>ON<表名>FOREACH{ROW|STATEMENT}

［WHEN<觸發(fā)條件>］

<觸發(fā)動作體>6.2.4觸發(fā)器

定義觸發(fā)器的語法說明:1.創(chuàng)建者：表的擁有者2.觸發(fā)器名3.表名：觸發(fā)器的目標表4.觸發(fā)事件：INSERT、DELETE、UPDATE5.觸發(fā)器類型行級觸發(fā)器（FOREACHROW）語句級觸發(fā)器（FOREACHSTATEMENT）6.2.4觸發(fā)器

定義觸發(fā)器的語法說明:6.觸發(fā)條件觸發(fā)條件為真省略WHEN觸發(fā)條件7.觸發(fā)動作體觸發(fā)動作體可以是一個匿名SQL過程塊也可以是對已創(chuàng)建存儲過程的調用6.2.4觸發(fā)器

【例】定義一個BEFORE行級觸發(fā)器，為教師表Teacher定義完整性規(guī)則“教授的工資不得低于4000元，如果低于4000元，自動改為4000元”。

CREATETRIGGERInsert_Or_Update_SalBEFOREINSERTORUPDATEONTeacher

/*觸發(fā)事件是插入或更新操作*/FOREACHROW

/*行級觸發(fā)器*/ASBEGIN/*定義觸發(fā)動作體，是PL/SQL過程塊*/IF(new.Job='教授')AND(new.Sal<4000)THENnew.Sal:=4000;ENDIF;END; 6.2.4觸發(fā)器

【例】定義AFTER行級觸發(fā)器，當教師表Teacher的工資發(fā)生變化后就自動在工資變化表Sal_log中增加一條相應記錄

首先建立工資變化表Sal_logCREATETABLESal_log(EnoNUMERIC(4)referencesteacher(eno)，

SalNUMERIC(7，2)，

Usernamechar(10)，

DateTIMESTAMP)；6.2.4觸發(fā)器

CREATETRIGGERInsert_Sal

AFTERINSERTONTeacher/*觸發(fā)事件是INSERT*/FOREACHROWASBEGININSERTINTOSal_logVALUES(new.Eno，new.Sal，CURRENT_USER，CURRENT_TIMESTAMP);END;6.2.4觸發(fā)器

CREATETRIGGERUpdate_Sal

AFTERUPDATEONTeacher/*觸發(fā)事件是UPDATE*/FOREACHROWASBEGINIF(new.Sal<>old.Sal)THENINSERTINTOSal_logVALUES(new.Eno，new.Sal，CURRENT_USER，CURRENT_TIMESTAMP);ENDIF;END;6.2.4觸發(fā)器

2.激活觸發(fā)器觸發(fā)器的執(zhí)行，是由觸發(fā)事件激活的，并由數據庫服務器自動執(zhí)行一個數據表上可能定義了多個觸發(fā)器同一個表上的多個觸發(fā)器激活時遵循如下的執(zhí)行順序：（1）執(zhí)行該表上的BEFORE觸發(fā)器；（2）激活觸發(fā)器的SQL語句；（3）執(zhí)行該表上的AFTER觸發(fā)器。6.2.4觸發(fā)器

【例】執(zhí)行修改某個教師工資的SQL語句，激活上述定義的觸發(fā)器。

UPDATETeacherSETSal=800WHEREEname='陳平';

執(zhí)行順序是：執(zhí)行觸發(fā)器Insert_Or_Update_Sal執(zhí)行SQL語句“UPDATETeacherSETSal=800WHEREEname='陳平';”執(zhí)行觸發(fā)器Insert_Sal；執(zhí)行觸發(fā)器Update_Sal

6.2.4觸發(fā)器

2.激活觸發(fā)器3刪除觸發(fā)器刪除觸發(fā)器的SQL語法：

DROPTRIGGER<觸發(fā)器名>ON<表名>;觸發(fā)器必須是一個已經創(chuàng)建的觸發(fā)器，并且只能由具有相應權限的用戶刪除。【例】刪除教師表Teacher上的觸發(fā)器Insert_SalDROPTRIGGERInsert_SalONTeacher;6.2.4觸發(fā)器

1.空值（NULL）約束【例】創(chuàng)建student表，要求SNO、SNAME、SSEX字段為NOTNULL，SDEPT字段為NULL。CREATETABLEstudent(SNOCHAR(10)NOTNULL,SNAMECHAR（8）NOTNULL,SDEPTCHAR(10)NULL)6.2.5數據完整性控制2.默認（DEFAULT）約束定義默認約束的格式為：CREATETABLEtable_name/*指定表名*/(column_namedatatypeNOTNULL|NULL[DEFAULTconstraint_expression]/*默認值約束表達式*/[,…n])6.2.5數據完整性控制【例】創(chuàng)建student表，定義系名字段SDEPT的默認約束CREATETABLEstudent(SNOCHAR(10)NOTNULL,SNAMECHAR(8)NOTNULL,SSEXBITNOTNULL,SDEPTCHAR(10)DEFAULT“網絡工程”）6.2.5數據完整性控制2.默認（DEFAULT）約束在定義默認約束時指定了約束名。CREATETABLEstudent(SNOCHAR(10)NOTNULL,SNAMECHAR(8)NOTNULL,SSEXBITNOTNULL,SDEPTCHAR(10)CONSTRAINTsdept_defaultDEFAULT“網絡工程”）6.2.5數據完整性控制2.默認（DEFAULT）約束【例】刪除student表中的默認約束。

ALTERTABLEstudentDROPCONSTRAINTsdept_default2.默認（DEFAULT）約束6.2.5數據完整性控制3.檢查（CHECK）約束定義檢查約束的格式為：

CREATETABLEtable_name/*指定表名*/(column_namedatatypeNOTNULL|NULL[[check_name]CHECK(logical_expression)]/*CHECK約束表達式*/[…n])/*定義列名、數據類型、標識列、是否空值和CHECK約束*/6.2.5數據完整性控制【例6-20】創(chuàng)建books表，其中書的價格字段BOOK_VALUE的取值范圍0~200。CREATETABLEbooks(BOOK_IDSMALLINT,/*書號*/BOOK_NAMEVARCHAR(50)/*書名*/BOOK_VALUETINYINT

CHECK(BOOK_VALUE>=0ANDBOOK_VLAUE<=200)/*書的價格約束*/)3.檢查（CHECK）約束6.2.5數據完整性控制在修改表時也可創(chuàng)建CHECK約束，其格式為：

ALTERTABLEtable_nameADDCONSTRAINTcheck_nameCHECK(logic_expression)參數含義：關鍵字ADDCONSTRAINT表示在已定義的table_name表中增加一個約束定義約束名由check_name指定約束條件表達式為logic_expression。3.檢查（CHECK）約束6.2.5數據完整性控制【例】增加SC表中成績字段GRADE的CHECK約束，要求GRADE字段取值為0~100。

ALTERTABLESCADDCONSTRAINTgrade_constraintCHECK(GRADE<=0ANDGRADE<=100)3.檢查（CHECK）約束6.2.5數據完整性控制刪除CHECK約束的格式為：

ALTERTABLEtable_nameDROPCONSTRAINTcheck_name功能：在table_name指定的表中，刪除名為check_name的約束。3.檢查（CHECK）約束6.2.5數據完整性控制【例】刪除SC表中，成績字段GRADE的CHECK約束。

ALTERTABLESCDROPCONSTRAINTgrade_constraint3.檢查（CHECK）約束6.2.5數據完整性控制4.主鍵（PRIMARYKEY）約束創(chuàng)建PRIMARYKEY約束的格式為：CREATETABLEtable_name/*指定表名*/(column_namedatatype/*定義字段*/[CONSTRAINTconstraint_name]/*定義約束名*/NOTNULLPRIMARYKEY/*定義主鍵約束*/[CLUSTERED|NONCLUSTERED]

/*定義約束的索引類型*/[,…n])/*n表示可定義多個字段*/6.2.5數據完整性控制【例】建立一個SC表，其中屬性列SNO和CNO組成SC的主鍵。

CREATETABLESC(SNOCHAR(10)NOTNULL,CNOCHAR(10)NOTNULL,GRADENUMERIC(3),

CONSTRAINTSC_PRIMPRIMARYKEY(SNO,CNO))4.主鍵（PRIMARYKEY）約束6.2.5數據完整性控制通過修改表也可創(chuàng)建PRIMARYKEY約束，格式為：

ALTERTABLEtable_nameADD[CONSTRAINTconstraint_name]PRIMARYKEYCLUSTERED|NONCLUSTERED(column[,…n])4.主鍵（PRIMARYKEY）約束6.2.5數據完整性控制【例】對表student中SNO字段創(chuàng)建PRIMARYKEY約束。

ALTERTABLEstudentADDCONSTRAINTS_PKPRIMARYKEYCLUSTERDE(SNO)4.主鍵（PRIMARYKEY）約束6.2.5數據完整性控制刪除PRIMARYKEY約束的格式為：

ALTERTABLEtable_nameDROPCONSTRAINTconstraint_name[,…n]4.主鍵（PRIMARYKEY）約束6.2.5數據完整性控制【例】刪除例子中建立的PRIMARYKEY約束。

ALTERTABLESCDROPCONSTRAINTSC_PRIM4.主鍵（PRIMARYKEY）約束6.2.5數據完整性控制5.唯一(UNIQUE)約束唯一性約束用于指定一個或多個列的組合值具有唯一性，以防止在列中輸入重復的值。定義了UNIQUE約束的那些列稱為唯一鍵，系統自動為唯一鍵建立唯一索引，從而保證了唯一鍵的唯一性。PRIMARYKEY約束與UNIQUE約束的相同點在于：二者均不允許表中對應的字段存在重復值。6.2.5數據完整性控制PRIMARYKEY約束與UNIQUE約束的主要區(qū)別：（1）一個基本表只能創(chuàng)建一個PRIMARYKEY約束，但一個基本表可根據需要對不同的列創(chuàng)建若干個UNIQUE約束；（2）PRIMARYKEY字段的值不允許為NULL，而UNIQUE字段值可以取NULL；（3）一般創(chuàng)建PRIMARYKEY約束時，系統會自動產生索引，索引的默認類型為簇索引，創(chuàng)建UNIQUE約束時，系統會自動產生一個UNIQUE索引，索引的默認類型為非簇索引。5.唯一(UNIQUE)約束6.2.5數據完整性控制創(chuàng)建UNIQUE約束的格式為：CREATETABLEtable_name/*指定表名*/(column_namedatatype/*定義字段*/[CONSTRAINTconstraint_name]/*定義約束名*/NOTNULLUNIQUE/*定義主鍵約束*/[CLUSTERED|NONCLUSTERED]/*定義約束的索引類型*/[,…n])/*n表示可定義多個字段*/5.唯一(UNIQUE)約束6.2.5數據完整性控制【例】創(chuàng)建student表，其中SNAME字段具有唯一性。

CREATETABLEstudent(SNOCHAR(8),SNAMECHAR(10),SSEXCHAR(2),CONSTRAINTPK_SNOPRIMARYKEY(SNO),

CONSTRAINTUK_SNAMEUNIQUE(SNAME))5.唯一(UNIQUE)約束6.2.5數據完整性控制通過修改表也可創(chuàng)建UNIQUE約束，格式為：ALTERTABLEtable_nameADD[CONSTRAINTconstraint_name]UNIQUECLUSTERDE|NONCLUSTERED(column[,…n])5.唯一(UNIQUE)約束6.2.5數據完整性控制【例】對表student中的SNAME創(chuàng)建UNIQUE約束。

ALTERTABLEstudentADDCONSTRAINTs_UKUNIQUENONCLUSTERDE(SNAME)

刪除UNIQUE約束的格式與刪除PRIMARYKEY約束的格式相同?！纠縿h除例6-8創(chuàng)建的UNIQUE約束。

ALTERTABLEstudentDROPCONSTRAINTUK_SNAME5.唯一(UNIQUE)約束6.2.5數據完整性控制6.外鍵（FOREIGNKEY）約束定義外鍵約束的格式為：

CREATETABLEtable_name(colunm_namedatatype[FOREIGNKEY]REFERENCESref_table(ref_column)[…n])6.2.5數據完整性控制【例】定義student表中的SNO為主鍵，SC表中的SNO為外鍵。

CREATETABLEstudent(SNOCHAR(10)NOTNULLCONSTRAINTSNO_PKPRIMARYKEY,SNAMECHAR(8)NOTNULL,SDEPTCHAR(10)NULL)CREATETABLESC(SNOCHAR(10)NOTNULLFOREIGNKEYREFERENCESstudent(SNO),CNOCHAR(6)NOTNULL，GRADESMALLINT)6.外鍵（FOREIGNKEY）約束6.2.5數據完整性控制通過修改表也可定義外鍵約束，其格式為：ALTERTABLEtable_nameADD[CONSTRAINTconstraint_name]FOREIGNKEY(column[,…])REFERENCESref_table(ref_colunm[,…n])6.外鍵（FOREIGNKEY）約束6.2.5數據完整性控制【例】課程表course為主表，course.CNO為主鍵，SC表為從表，將SC中的CNO字段定義為外鍵。

ALTERTABLESCADDCONSTRAINTc_foreignFOREIGNKEY(CNO)REFERENCEScourse(CNO)6.外鍵（FOREIGNKEY）約束6.2.5數據完整性控制【例】刪除上例中SC表中的外鍵約束。

ALTERTABLESCDROPCONSTRAINTc_foreign6.外鍵（FOREIGNKEY）約束6.2.5數據完整性控制第6章數據庫的保護技術6.1數據庫的安全性6.2數據庫的完整性6.3并發(fā)控制6.4數據庫的恢復技術6.3并發(fā)控制多用戶數據庫系統的存在允許多個用戶同時使用的數據庫系統飛機定票數據庫系統銀行數據庫系統特點：在同一時刻并發(fā)運行的事務數可達數百個不同的多事務執(zhí)行方式

(1)事務串行執(zhí)行每個時刻只有一個事務運行，其他事務必須等到這個事務結束以后方能運行不能充分利用系統資源，發(fā)揮數據庫共享資源的特點T1T2T3事務的串行執(zhí)行方式6.3并發(fā)控制(2)交叉并發(fā)方式在單處理機系統中，事務的并行執(zhí)行是這些并行事務的并行操作輪流交叉運行單處理機系統中的并行事務并沒有真正地并行運行，但能夠減少處理機的空閑時間，提高系統的效率6.3并發(fā)控制事務的交叉并發(fā)執(zhí)行方式6.3并發(fā)控制6.3并發(fā)控制(3)同時并發(fā)方式多處理機系統中，每個處理機可以運行一個事務，多個處理機可以同時運行多個事務，實現多個事務真正的并行運行6.3并發(fā)控制事務并發(fā)執(zhí)行帶來的問題會產生多個事務同時存取同一數據的情況可能會存取和存儲不正確的數據，破壞事務一致性和數據庫的一致性6.3.1事務的基本概念1.事務定義

2.事務的特性定義一個數據庫操作序列一個不可分割的工作單位恢復和并發(fā)控制的基本單位事務和程序比較在關系數據庫中，一個事務可以是一條或多條SQL語句,也可以包含一個或多個程序。一個程序通常包含多個事務1.事務(Transaction)6.3.1事務的基本概念顯式定義方式

BEGINTRANSACTIONBEGINTRANSACTIONSQL語句1SQL語句1

SQL語句2SQL語句2

。。。。。。。。。。

COMMITROLLBACK隱式方式當用戶沒有顯式地定義事務時，DBMS按缺省規(guī)定自動劃分事務1.事務(Transaction)6.3.1事務的基本概念2.事務的ACID特性原子性（Atomicity）一致性（Consistency）隔離性（Isolation）持久性（Durability）6.3.1事務的基本概念3.事務例子BEGINTRANSACTION

READAA=A-RIFA<0

/*A中款數不足*/

THENBEGINDISPLAY“A中款數不足”

ROLLBACKENDELSE

/*撥款*/BEGINB=B+RDISPLAY“撥款完成”

COMMITEND6.3.1事務的基本概念6.3.2并發(fā)操作引發(fā)的問題設存款余額M=2000元，事務T1取款500元，事務T2取款300元。T1包含三個操作：讀取余額（READM）；計算余額（M=M-500）；更新余額（UPEATEM）。T2也包含三個操作：讀取余額（READM）；計算余額（M=M-300）；更新余額（UPEATEM）。如果T1和T2順序執(zhí)行，最后的存款余額應該是1200元。1．丟失更新丟失更新是指當兩個事務T1和T2讀入同一數據，并發(fā)執(zhí)行修改操作時，T2把T1或T1把T2的修改結果覆蓋掉，造成了數據的不一致問題。這個問題是由于兩個事務對同一數據并發(fā)地進行寫入所引起的，因而又被稱為寫-寫沖突（Write-wtiteConflict）。在銀行取款的例子中，如果T1和T2按表6-5所示順序執(zhí)行，最后得到錯誤結果M=1700元，原因是丟失了T1對數據庫的更新操作。6.3.2并發(fā)操作引發(fā)的問題順序事務T1M在數據庫中的值事務T21ReadM20002ReadM3M=M-5004M=M-3005UpdateM150061700UpdateM6.3.2并發(fā)操作引發(fā)的問題1．丟失更新2．讀“臟”數據讀“臟”數據問題（DirtyRead）是指事務T1更新了某一數據，并將修改后的值寫入磁盤，事務T2讀取了更新后的數據，其后事務T1由于某種原因被撤銷，事務T1已更新過的數據恢復原值，這樣事務T2讀到的數據就與數據庫中的數據不一致，是不正確的數據，稱為“臟”數據。這種由于一個事務讀取另一個更新事務尚未提交的數據引起的不一致問題，又被稱為讀-寫沖突（Read-writeConflict）。6.3.2并發(fā)操作引發(fā)的問題順序事務T1M在數據庫中的值事務T21ReadM2000M=M-500UpdateM15002ReadM3Rollback20002．讀“臟”數據6.3.2并發(fā)操作引發(fā)的問題3．不可重復讀不可重復讀（UnrepeatableRead）是指事務T1讀取數據后，事務T2進行讀取并進行更新操作，使T1再次讀取該數據進行校驗時，發(fā)現兩次讀取的數據值不一致，它也是由于讀-寫沖突引起的。6.3.2并發(fā)操作引發(fā)的問題不可重復讀有三種情形：（1）事務T1讀取某一數據后，事務T2對其做了修改，當事務T1再次讀該數據時，得到與前一次不同的值。表6-7中說明的就是這種情況。在銀行取款的例子中，如果事務T1和T2按表6-4所示順序執(zhí)行，則T1第一次讀取的M值為2000，第二次讀取的M值為1500，二者值不一致。（2）事務T1按一定條件從數據庫中讀取某些數據記錄后，事務T2刪除了其中的部分記錄，當事務T1再次按相同條件讀取數據時，發(fā)現某些記錄已經不存在了。（3）事務T1按一定條件從數據庫中讀取某些數據記錄后，事務T2插入了一些記錄，當事務T1再次按相同條件讀取數據時，發(fā)現多了一些記錄。3．不可重復讀6.3.2并發(fā)操作引發(fā)的問題順序事務T1M在數據庫中的值事務T21ReadM200021500ReadMM=M-500UpdateM3ReadM15003．不可重復讀6.3.2并發(fā)操作引發(fā)的問題6.3.2并發(fā)操作引發(fā)的問題數據不一致性：由于并發(fā)操作破壞了事務的隔離性并發(fā)控制就是要用正確的方式調度并發(fā)操作，使一個用戶事務的執(zhí)行不受其他事務的干擾，從而避免造成數據的不一致性實現并發(fā)控制的方法主要是基于封鎖的并發(fā)控制技術6.3.3封鎖的概念及類型1、什么是封鎖2、基本封鎖類型3、鎖的相容矩陣4、封鎖協議1、什么是封鎖封鎖就是事務T在對某個數據對象（例如表、記錄等）操作之前，先向系統發(fā)出請求，對其加鎖加鎖后事務T就對該數據對象有了一定的控制，在事務T釋放它的鎖之前，其它的事務不能更新此數據對象。6.3.3封鎖的概念及類型2、基本封鎖類型一個事務對某個數據對象加鎖后究竟擁有什么樣的控制由封鎖的類型決定?；痉怄i類型排它鎖（ExclusiveLocks，簡記為X鎖）共享鎖（ShareLocks，簡記為S鎖）6.3.3封鎖的概念及類型排它鎖又稱為寫鎖若事務T對數據對象A加上X鎖，則只允許T讀取和修改A，其它任何事務都不能再對A加任何類型的鎖，直到T釋放A上的鎖保證其他事務在T釋放A上的鎖之前不能再讀取和修改A2、基本封鎖類型6.3.3封鎖的概念及類型共享鎖又稱為讀鎖若事務T對數據對象A加上S鎖，則其它事務只能再對A加S鎖，而不能加X鎖，直到T釋放A上的S鎖保證其他事務可以讀A，但在T釋放A上的S鎖之前不能對A做任何修改2、基本封鎖類型6.3.3封鎖的概念及類型3、鎖的相容矩陣Y=Yes，相容的請求N=No，不相容的請求

T2T1XS-XNNYSNYY-YYY6.3.3封鎖的概念及類型6.3.4封鎖協議在運用X鎖和S鎖對數據對象封鎖時，需要約定一些規(guī)則：封鎖協議(LockingProtocol)何時申請X鎖和S鎖持鎖時間、何時釋放不同的封鎖協議，在不同程度上為并發(fā)操作的正確調度提供了一定的保證常用的封鎖協議：三級封鎖協議1、一級封鎖協議事務T在修改數據R之前必須先對其加X鎖，直到事務結束才釋放正常結束（COMMIT）非正常結束（ROLLBACK）一級封鎖協議可防止丟失修改在一級封鎖協議中，如果是讀數據，不需要加鎖的，所以它不能保證可重復讀和不讀“臟”數據。6.3.4封鎖協議順序T1T2M在數據庫中的值1XlockM獲得ReadM=200020002XlockMWait3M=M-500WriteM=1500CommitUnlockMWaitWaitWait

15004

獲得XlockMreadM=1500M=M-300WriteM=1200CommitUnlockM

12001、一級封鎖協議6.3.4封鎖協議順序T1T2M在數據庫中的值1

XlockM獲得ReadM=2000M=M-500WriteM=1500

2000

15002

ReadM=150015003ROLLBACKUnlockM

2000依然發(fā)生讀“臟”數據的問題1、一級封鎖協議6.3.4封鎖協議一級封鎖協議＋事務T在讀取數據R前必須先加S鎖，讀完后即可釋放S鎖。二級封鎖協議可以防止丟失修改和讀“臟”數據。在二級封鎖協議中，由于讀完數據后即可釋放S鎖，所以它不能保證可重復讀。2、二級封鎖協議6.3.4封鎖協議2、二級封鎖協議-防止讀“臟”數據順序T1T2M在數據庫中的值1XlockM獲得ReadM=2000M=M-500WriteM=15002000

15002SlockM3ROllBACKUnlockMWaitWait20004SlockM獲得ReadM=2000UnlockMCommit6.3.4封鎖協議2、二級封鎖協議-“不可重復讀”問題順序T1T2M的值N的值1

SlockM，N獲得ReadM=2000ReadN=1000UnlockM，NXlockNWaitWaitWait獲得2000

1000

2M+N=3000SlockM得到SlockNWaitWait獲得ReadN=1000N=N+200WriteN=1200CommitUlockN

12003ReadM＝2000ReadN=1200M+N=3200（驗算錯誤）

6.3.4封鎖協議3、三級封鎖協議一級封鎖協議＋事務T在讀取數據R前必須先加S鎖，直到事務結束才釋放S鎖。三級封鎖協議可防止丟失修改，讀“臟”數據和不可重復讀。6.3.4封鎖協議3、三級封鎖協議-防止不可重復讀順序T1T2M的值N的值1SlockM，N獲得ReadM=2000ReadN=1000M+N=3000XlockNWaitWaitWaitWait200010002ReadM=2000ReadN=1000M+N=3000CommitUnlockNWaitWaitWaitWait獲得ReadN=1000N=N+200WriteNCommitUnlockN12006.3.4封鎖協議封鎖協議小結三級協議的主要區(qū)別什么操作需要申請封鎖何時釋放鎖（即持鎖時間）6.3.4封鎖協議封鎖協議小結6.3.4封鎖協議6.3.5活鎖與死鎖封鎖技術可以有效地解決并行操作的一致性問題，但也帶來一些新的問題死鎖活鎖1.活鎖事務T1封鎖了數據R事務T2又請求封鎖R，于是T2等待。T3也請求封鎖R，當T1釋放了R上的封鎖之后系統首先批準了T3的請求，T2仍然等待。T4又請求封鎖R，當T3釋放了R上的封鎖之后系統又批準了T4的請求……T2有可能永遠等待，這就是活鎖的情形6.3.5活鎖與死鎖T1T2T3T4……nLockA……LockA……waitUnlockAwaitLockA……wait……wait……waitUnlockALockAwaitLockAwaitLockAwait……1.活鎖6.3.5活鎖與死鎖避免活鎖：采用先來先服務的策略當多個事務請求封鎖同一數據對象時按請求封鎖的先后次序對這些事務排隊該數據對象上的鎖一旦釋放，首先批準申請隊列中第一個事務獲得鎖1.活鎖6.3.5活鎖與死鎖2.死鎖事務T1封鎖了數據R1T2封鎖了數據R2T1又請求封鎖R2，因T2已封鎖了R2，于是T1等待T2釋放R2上的鎖接著T2又申請封鎖R1，因T1已封鎖了R1，T2也只能等待T1釋放R1上的鎖這樣T1在等待T2，而T2又在等待T1，T1和T2兩個事務永遠不能結束，形成死鎖6.3.5活鎖與死鎖2.死鎖-示例T1T2SlockA1SlockA2XlockA2Wait……XlockA1Wait……6.3.5活鎖與死鎖解決死鎖的兩類方法（1）

預防死鎖（2）

死鎖的診斷與解除2.死鎖6.3.5活鎖與死鎖（1）預防死鎖產生死鎖的原因是兩個或多個事務都已封鎖了一些數據對象，然后又都請求對已為其他事務封鎖的數據對象加鎖，從而出現死等待。預防死鎖的發(fā)生就是要破壞產生死鎖的條件6.3.5活鎖與死鎖一次封鎖法順序封鎖法（1）預防死鎖6.3.5活鎖與死鎖一次封鎖法要求每個事務必須一次將所有要使用的數據全部加鎖，否則就不能繼續(xù)執(zhí)行存在的問題降低系統并發(fā)度難于事先精確確定封鎖對象6.3.5活鎖與死鎖（1）預防死鎖順序封鎖法順序封鎖法是預先對數據對象規(guī)定一個封鎖順序，所有事務都按這個順序實行封鎖。順序封鎖法存在的問題維護成本數據庫系統中封鎖的數據對象極多，并且在不斷地變化。難以實現：很難事先確定每一個事務要封鎖哪些對象

6.3.5活鎖與死鎖（1）預防死鎖（2）

死鎖的診斷與解除死鎖的診斷超時法事務等待圖法6.3.5活鎖與死鎖超時法如果一個事務的等待時間超過了規(guī)定的時限，就認為發(fā)生了死鎖優(yōu)點：實現簡單缺點有可能誤判死鎖時限若設置得太長，死鎖發(fā)生后不能及時發(fā)現（2）

死鎖的診斷與解除6.3.5活鎖與死鎖等待圖法用事務等待圖動態(tài)反映所有事務的等待情況事務等待圖是一個有向圖G=(T，S)T為結點的集合，每個結點表示正運行的事務U為邊的集合，每條邊表示事務等待的情況若T1等待T2，則T1，T2之間劃一條有向邊，從T1指向T2（2）

死鎖的診斷與解除6.3.5活鎖與死鎖事務等待圖等待圖法（2）

死鎖的診斷與解除6.3.5活鎖與死鎖解除死鎖選擇一個處理死鎖代價最小的事務，將其撤消釋放此事務持有的所有的鎖，使其它事務能繼續(xù)運行下去（2）

死鎖的診斷與解除6.3.5活鎖與死鎖6.3.6可串行化調度與兩段鎖協議

DBMS對并發(fā)事務不同的調度可能會產生不同的結果1、什么樣的調度是正確的？2、如何保證并發(fā)操作的調度是正確的？

1、什么樣的調度是正確的？計算機系統對并行事務中并行操作的調度是隨機的，而不同的調度會產生不同的結果。將所有事務串行起來的調度策略一定是正確的調度策略。如果一事務運行過程中沒有其它事務在同時運行，也就是說它沒有受到其它事務的干擾，那么就可以認為該事務的運行結果是正確的或者預想的。6.3.6可串行化調度與兩段鎖協議

以不同順序串行執(zhí)行事務也有可能會產生不同的結果，但由于不會使數據庫置于不一致狀態(tài)，所以都可以認為是正確的。6.3.6可串行化調度與兩段鎖協議

1、什么樣的調度是正確的？可串行化(Serializable)調度多個事務的并發(fā)執(zhí)行是正確的，當且僅當其結果與按某一次序串行地執(zhí)行這些事務時的結果相同可串行性(Serializability)是并發(fā)事務正確調度的準則一個給定的并發(fā)調度，當且僅當它是可串行化的，才認為是正確調度6.3.6可串行化調度與兩段鎖協議

1、什么樣的調度是正確的？【例】現在有兩個事務，分別包含下列操作：T1：讀Y；X=Y+10；寫回X；T2：讀X；Y=X+10；寫回Y；現給出對這兩個事務不同的調度策略6.3.6可串行化調度與兩段鎖協議

1、什么樣的調度是正確的？對這兩個事務的不同調度策略串行執(zhí)行串行調度策略1串行調度策略2交錯執(zhí)行不可串行的調度可串行化的調度6.3.6可串行化調度與兩段鎖協議

1、什么樣的調度是正確的？保證并發(fā)操作調度正確性的方法封鎖方法：兩段鎖協議2.如何保證并發(fā)操作的調度是正確的？6.3.6可串行化調度與兩段鎖協議

兩段鎖協議兩段封鎖協議(Two-PhaseLocking，簡稱2PL)是最常用的一種封鎖協議，理論上證明使用兩段封鎖協議產生的是可串行化調度6.3.6可串行化調度與兩段鎖協議

指所有事務必須分兩個階段對數據項加鎖和解鎖在對任何數據進行讀、寫操作之前，事務首先要獲得對該數據的封鎖在釋放一個封鎖之后，事務不再申請和獲得任何其他封鎖6.3.6可串行化調度與兩段鎖協議

兩段鎖協議事務分為兩個階段第一階段是獲得封鎖，也稱為擴展階段事務可以申請獲得任何數據項上的任何類型的鎖，但是不能釋放任何鎖第二階段是釋放封鎖，也稱為收縮階段事務可以釋放任何數據項上的任何類型的鎖，但是不能再申請任何鎖6.3.6可串行化調度與兩段鎖協議

兩段鎖協議事務T1的封鎖序列是：

SlockX…XlockY…XlockZ…UnlockX…UnlockZ…UnlockY；事務T2的封鎖序列是：

XlockX…UnlockX…XlockY…XlockZ…UnlockZ….UnlockY；則事務T1遵守兩段鎖協議，而事務T2不遵守兩段鎖協議。6.3.6可串行化調度與兩段鎖協議

兩段鎖協議兩段鎖協議與防止死鎖的一次封鎖法一次封鎖法要求每個事務必須一次將所有要使用的數據全部加鎖，否則就不能繼續(xù)執(zhí)行，因此一次封鎖法遵守兩段鎖協議但是兩段鎖協議并不要求事務必須一次將所有要使用的數據全部加鎖，因此遵守兩段鎖協議的事務可能發(fā)生死鎖6.3.6可串行化調度與兩段鎖協議

兩段鎖協議兩段鎖協議與三級封鎖協議兩類不同目的的協議兩段鎖協議保證并發(fā)調度的正確性三級封鎖協議在不同程度上保證數據的一致性遵守第三級封鎖協議必然遵守兩段鎖協議6.3.6可串行化調度與兩段鎖協議

第6章數據庫的保護技術6.1數據庫的安全性6.2數據庫的完整性6.3并發(fā)控制6.4數據庫的恢復技術

6.4.1數據庫恢復技術1.數據轉儲2.日志文件轉儲是指DBA將整個數據庫復制到磁帶或另一個磁盤上保存起來的過程，備用的數據稱為后備副本或后援副本如何使用數據庫遭到破壞后可以將后備副本重新裝入重裝后備副本只能將數據庫恢復到轉儲時的狀態(tài)1.數據轉儲6.4.1數據庫恢復技術2.日志文件什么是日志文件日志文件的格式和內容6.4.1數據庫恢復技術什么是日志文件

日志文件(log)是用來記錄事務對數據庫的更新操作的文件6.4.1數據庫恢復技術2.日志文件日志文件的格式和內容日志文件的格式以記錄為單位的日志文件以數據塊為單位的日志文件6.4.1數據庫恢復技術2.日志文件6.4.2數據庫恢復策略1.事務故障的恢復2.系統故障的恢復3.介質故障的恢復1.事務故障的恢復事務故障：事務在運行至正常終止點前被終止恢復方法由恢復子系統應利用日志文件撤消（UNDO）此事務已對數據庫進行的修改事務故障的恢復由系統自動完成，對用戶是透明的，不需要用戶干預6.4.2數據庫恢復策略事務故障的恢復步驟1)反向掃描文件日志（即從最后向前掃描日志文件），查找該事務的更新操作。2)對該事務的更新操作執(zhí)行逆操作。即將日志記錄中“更新前的值”寫入數據庫。插入操作，“更新前的值”為空，則相當于做刪除操作刪除操作，“更新后的值”為空，則相當于做插入操作若是修改操作，則相當于用修改前值代替修改后值1.事務故障的恢復6.4.2數據庫恢復策略3)繼續(xù)反向掃描日志文件，查找該事務的其他更新操作，并做同樣處理。4)如此處理下去，直至讀到此事務的開始標記，事務故障恢復就完成了。事務故障的恢復步驟1.事務故障的恢復6.4.2數據庫恢復策略2.系統故障的恢復系統故障造成數據庫不一致狀態(tài)的原因未完成事務對數據庫的更新已寫入數據庫已提交事務對數據庫的更新還留在緩沖區(qū)沒來得及寫入數據庫恢復方法1)Undo故障發(fā)生時未完成的事務2)Redo已完成的事務系統故障的恢復由系統在重新啟動時自動完成，不需要用戶干預6.4.2數據庫恢復策略檢查點技術檢查點記錄的內容1)建立檢查點時刻所有正在執(zhí)行的事務清單2)這些事務最近一個日志記錄的地址重新開始文件的內容記錄各個檢查點記錄在日志文件中的地址2.系統故障的恢復6.4.2數據庫恢復策略具有檢查點的日志文件和重新開始文件檢查點技術2.系統故障的恢復6.4.2數據庫恢復策略3.介質故障的恢復1)重裝數據庫2)重做已完成的事務6.4.2數據庫恢復策略6.4.3數據庫的鏡像介質故障是對系統影響最為嚴重的一種故障，嚴重影響數據庫的可用性介質故障恢復比較費時為預防介質故障，DBA必須周期性地轉儲數據庫提高數據庫可用性的解決方案數據庫鏡像（Mirror）數據庫鏡像DBMS自動把整個數據庫或其中的關鍵數據復制到另一個磁盤上DBMS自動保證鏡像數據與主數據庫的一致性每當主數據庫更新時，DBMS自動把更新后的數據復制過去（如下圖所示）6.4.3數據庫的鏡像6.4.3數據庫的鏡像思考內容

第7章關系數據庫的設計理論

（2025秋季學期）

數據庫概論第7章關系數據庫的設計理論關系數據庫邏輯設計針對具體需求，如何構造一個合適的數據模式（二維表）第7章關系數據庫的設計理論7.1關系模式的設計問題7.2數據的函數依賴7.3關系數據庫模式的規(guī)范化理論7.4關系模式分解算法7.1關系模式的設計問題

關系模式由五部分組成，即它是一個五元組：R(U,D,DOM,F)R：關系名U：組成該關系的屬性名集合D：屬性組U中屬性所來自的域DOM：屬性向域的映象集合F：屬性間數據依賴關系集合7.1.1數據依賴關系模式R（U,D,DOM,F）簡化為一個三元組：

R（U,F）7.1.2數據依賴對關系模式的影響[例]建立一個描述學生信息的數據庫，該數據庫涉及的對象包括學生的學號(Sno)、所在系(Sdept)、系主任姓名(Mname)、課程名(Cname)和成績(Grade)。單一的關系模式：Student<U、F>U＝｛Sno,Sdept,Mname,Cname,Grade｝

屬性組U上的一組函數依賴F：

F＝｛Sno→Sdept,Sdept→Mname,(Sno,Cname)→Grade｝

SnoCnameSdeptMnameGrade7.1.2數據依賴對關系模式的影響U＝｛Sno,Sdept,Mname,Cname,Grade｝

存在的問題

數據冗余太大

插入問題

刪除問題

更新問題7.1.2數據依賴對關系模式的影響結論：Student關系模式不是一個好的模式?！昂谩钡哪Ｊ剑翰粫l(fā)生插入異常、刪除異常、更新異常，數據冗余應盡可能少。原因：由存在于模式中的某些數據依賴引起的。解決方法：通過分解關系模式來消除其中不合適的數據依賴。7.1.2數據依賴對關系模式的影響第7章關系數據庫的設計理論7.1關系模式的設計問題

7.2數據的函數依賴7.3關系數據庫模式的規(guī)范化理論7.4關系模式分解算法7.2.1函數依賴1.定義設R(U)是一個屬性集U上的關系模式，X和Y是U的子集。若對于r中任意兩個元組s和t，當s[X]=t[X]時，就有s[Y]=t[Y]，則稱屬性子集X函數決定屬性子集Y或者稱Y函數依賴于X，記為X→Y。否則就稱X不函數決定Y或者稱Y不函數依賴于X，記為X?Y。如果X→Y，且Y→X，則記為X←→Y。如果X→Y，則稱X為決定因素(determinant)。注意：

所有關系實例均要滿足語義范疇的概念數據庫設計者可以對現實世界作強制的規(guī)定7.2.1函數依賴【例7-1】圖書管理系統中的圖書借閱關系模式為R（讀者編號，姓名，圖書編號，書名，借書日期），由現實世界的語義可知，讀者編號唯一，圖書編號唯一，姓名和書名可以重復出現。求其函數依賴。

函數依賴：讀者編號→姓名，圖書編號→書名，（讀者編號，圖書編號）→借書日期7.2.1函數依賴【例7-2】指出學生關系S(學號，姓名，圖書證號，系別，系主任)中存在的函數依賴關系。關系S中存在下列函數依賴：學號→姓名(每個學號只能有一個學生姓名)

學號→系別(每個學號只能在一個系)

學號→圖書證號(每個學號只能有一個圖書證號)

系別→系主任(每個系只能由一名系主任)7.2.1函數依賴2．函數依賴的3種基本情形(1)平凡與非平凡函數依賴在關系模式R(U)中，對于U的子集X和Y，如果X→Y，但Y

X，則稱X→Y是非平凡的函數依賴若X→Y，但Y

X,則稱X→Y是平凡的函數依賴【例7-3】在關系SC(Sno,Cno,Grade)中，非平凡函數依賴：(Sno,Cno)→

Grade

平凡函數依賴：(Sno,Cno)→

Sno(Sno,Cno)→Cno7.2.1函數依賴(2)部分與完全函數依賴定義在R(U)中，如果X→Y，并且對于X的任何一個真子集X’，都有X’Y,則稱Y對X完全函數依賴，記作XFY。若X→Y，但Y不完全函數依賴于X，則稱Y對X部分函數依賴，記作XPY。

7.2.1函數依賴2．函數依賴的3種基本情形(2)部分與完全函數依賴

【例7-4】關系SC(Sno，Cno，Sname,Grade)

中(Sno,Cno)→Grade是完全函數依賴，

(Sno,Cno)→Sname是部分函數依賴因為Sno→Sname成立，且Sno是(Sno，Cno)的真子集。

7.2.1函數依賴2．函數依賴的3種基本情形

(3)傳遞與直接函數依賴定義在R(U)中，如果X→Y，(Y

X),Y→XY→Z，

則稱Z對X傳遞函數依賴。記為：X→Z

注意:如果Y→X，即X←→Y，則Z直接依賴于X。【例7-5】

在關系S(學號，姓名，圖書證號，系別，系主任)中，有：學號→系別,系別→系主任，則系主任傳遞函數依賴于學號。傳遞7.2.1函數依賴2．函數依賴的3種基本情形

7.2.2依賴的邏輯蘊含定義設F是在關系模式R上成立的函數依賴的集合，X→Y是一個函數依賴。如果對于R的每個滿足F的關系r也滿足X→Y，那么稱F邏輯蘊含X→Y，記為F=>X→Y。（用已知函數依賴判斷其他的函數依賴）定義設F是函數依賴集，被F邏輯蘊含的函數依賴全體構成的集合，稱為函數依賴集F的閉包（closure），記為F+。即F+=｛X→Y|F=>X→Y｝7.2.3Armstrong公理系統

關系模式R<U，F>來說有以下的推理規(guī)則：(1)自反律（Reflexivity）：若Y

X

U，則

X→Y為F所蘊含。(2)增廣律（Augmentation）：若X→Y為F所蘊含，且Z

U，則XZ→YZ為F所蘊含。(3)傳遞律（Transitivity）：若X→Y及Y→Z為F所蘊含，則X→Z為F所蘊含。Armstrong公理具有如下兩個性質：

有效性：由F出發(fā)根據Armstrong公理推導出的每一個函數依賴X→Y必定在F+中。

完備性：F+中的每一個函數依賴X→Y，必定可以由F出發(fā)，根據Armstong公理推導出。7.2.3Armstrong公理系統7.2.3Armstrong公理系統(1)合并律(unionrule)：如果X→Y和X→Z成立，那么X→YZ成立，即若F?X→Y，F?X→Z，則F?X→YZ。(2)偽傳遞律（pseudotransivityrule）：如果X→Y和WY→Z成立，那