2023/2/41第6章數據庫設計本章主要內容6.1數據庫設計概述

6.2需求分析

6.3概念設計

6.4邏輯設計6.5模式求精

6.6物理設計

6.7數據庫實施

6.8數據庫運行和維護2023/2/42何謂數據庫設計？數據庫設計是指對于一個給定的應用環境，構造（設計）出某種數據庫管理系統所支持的優化的數據庫邏輯模式和物理結構，并據此建立數據庫及其應用系統，使之能夠有效地存儲和管理數據，滿足各種用戶的應用需求，包括信息管理要求和數據處理要求。數據庫已經成為現代信息系統的基礎和核心部分，而數據庫設計的好壞直接影響到整個系統的效率和質量。2023/2/43

數據庫設計有別于其他軟件系統的設計，有其獨特的特點——以數據為中心。

由于DBMS和前臺開發技術進步，數據的表現形式可以比較容易的實現。設計人員把注意力放在數據的組織結構和數據處理過程中的流向問題。2023/2/44第6章數據庫設計

6.1數據庫設計概述

6.2需求分析

6.3概念設計

6.4邏輯設計

6.5模式求精2023/2/45數據庫設計的任務和目標 一個成功的管理系統=50%的業務+50%的軟件

50%的成功軟件=25%的數據庫設計+25%的程序◆數據庫設計的任務

狹義上講，就是對某個給定的應用領域，設計優化的數據庫邏輯結構和物理結構，并建立數據庫。廣義地講是數據庫及其應用系統的設計，即設計整個的數據庫應用系統。2023/2/46◆

數據庫設計的目標創建一個完整的、盡可能規范化的和完全集成的概念、邏輯和物理數據庫模型。具體要達到以下要求：

減少有害的數據冗余，提高程序共享性； 保證數據的獨立性，可修改，可擴充； 訪問數據庫的時間要短； 數據庫的存儲空間要小； 要保證數據的安全性和保密性； 易于維護。2023/2/47數據庫設計的特點◆三分技術，七分管理，十二分數據

數據庫的建設中不僅涉及數據庫的設計和開發等技術，也涉及管理問題。這里的管理不僅僅包括項目管理，也包括與該項目關聯的企業的業務管理。基礎數據的收集、整理是非常繁瑣吃力的事情。2023/2/48◆

數據庫結構設計和對數據的處理設計密切結合

結構設計：就是設計各級數據庫模式，決定數據庫系統的信息內容。

行為設計：它決定數據庫系統的功能，是事務處理等應用程序的設計。2023/2/49現實世界數據分析功能分析概念模型設計邏輯模型設計物理數據庫設計子模式設計建立數據庫功能模型功能說明事務設計程序說明應用程序設計程序編碼調試結構與行為設計分離示意圖結構設計行為設計2023/2/410數據分析功能分析概念模型設計邏輯模型設計物理數據庫設計子模式設計建立數據庫數據庫功能模型功能說明事務設計程序說明應用程序設計程序調試程序運行結構與行為設計結合示意圖現實世界2023/2/411數據庫設計方法◆直觀設計法(手工試湊法)

數據庫設計只是一種經驗的反復實施，而不能稱為是一門科學，缺乏科學分析理論基礎和工程手段的支持，所以設計質量很難保證。◆規范設計法(新奧爾良法)

新奧爾良法將數據庫設計分成需求分析（分析用戶需求）、概念設計（信息分析和定義）、邏輯設計（設計實現）和物理設計（物理數據庫設計）。2023/2/412常用的規范設計方法

基于ER模型的數據庫設計方法；

P.P.S.chen于1976年提出

基于3NF的數據庫設計方法；

S·Atre提出

ODL（ObjectDefinitionLanguage）方法； 語義對象模型（SemanticObject）方法。2023/2/413ODL（ObjectDefinitionLanguage）方法

ODL是利用面向對象的術語（如C++中的類、對象、子類、繼承等概念）說明數據庫結構的推薦標準語言,它是IDL(InterfaceDefinitionLanguage,接口定義語言)的擴展。ODL的主要作用是書寫面向對象數據庫設計（正如用E/R圖進行關系數據庫概念模型設計一樣），進而將其轉換成面向對象數據庫管理系統(OODBMS)的說明。2023/2/414◆計算機輔助設計法

計算機輔助設計法是指在數據庫設計的某些過程中模擬某一規范化設計的方法，并以人的知識或經驗為主導，通過人機交互方式實現設計中的某些部分。

Oracle公司開發的DesignerSybase公司開發的PowerDesigner

這些軟件簡稱為CASE（ComputerAidedSoftwareEngineering）工具。◆自動化設計法

2023/2/415數據庫設計的步驟按規范設計法可將數據庫設計分為四個階段：系統需求分析階段、概念結構設計階段、邏輯結構設計階段、物理設計階段。而一個完整的數據庫系統的開發過程還需增加數據庫實施和數據庫運行與維護兩個階段。2023/2/416不滿意不滿意需求收集和分析應用需求(數據、處理)設計概念結構設計邏輯結構數據模型優化設計物理結構評價設計,性能預測物理實現試驗性運行使用維護數據庫需求分析階段概念設計階段邏輯設計階段物理設計階段數據庫實施數據庫運行和維護轉換規則、DBMS功能、優化方法應用要求、DBMS詳細特征數據庫設計2023/2/417第6章數據庫設計6.1數據庫設計概述

6.2需求分析

6.3概念設計

6.4邏輯設計

6.5模式求精2023/2/418需求分析的任務對現實世界要處理的對象（組織、部門、企業等）進行詳細的調查，通過對原系統的了解，收集支持新系統的基礎數據并對其進行處理，在此基礎上確定新系統的功能。◆調查分析用戶的活動

調查組織機構情況，調查各部門的業務活動情況。◆收集和分析需求數據，確定系統邊界信息需求；處理需求；安全性；完整性的需求。2023/2/419◆

編寫需求分析說明書(系統分析報告)(1)系統概況，系統的目標、范圍、背景、歷史和現狀；

(2)系統的原理和技術，對原系統的改善；

(3)系統總體結構與子系統結構說明；

(4)系統功能說明；

(5)數據處理概要、工程體制和設計階段劃分；

(6)系統方案及技術、經濟、功能和操作上的可行性。2023/2/420隨系統分析報告要提供下列附件：

(1)系統的硬件、軟件支持環境的選擇及規格要求（所選擇的數據庫管理系統、操作系統、漢字平臺、計算機型號及其網絡環境等）。

(2)組織機構圖、組織之間聯系圖及各機構功能業務一覽圖。

(3)數據流程圖、功能模塊圖和數據字典等圖表。2023/2/421需求分析的方法

主要方法有自頂向下和自底向上兩種。(a)自頂向下的需求分析(b)自底向上的需求分析………………需求需求……需求…需求需求需求需求需求需求需求需求需求需求…需求…

需求分析的方法2023/2/422自頂向下的分析方法（StructuredAnalysis，簡稱SA方法）是最簡單實用的方法。SA方法從最上層的系統組織機構入手，采用逐層分解的方式分析系統，并把每一層用數據流圖（DataFlowDiagram，DFD）和數據字典（DataDictionary，DD）描述。2023/2/423

數據流圖表達了數據和處理過程的關系。在數據流圖中，用命名的箭頭表示數據流，用圓圈表示處理，用矩形或其他形狀表示數據的存儲。數據流數據流數據存儲數據來源處理數據輸出處理需求信息需求數據流圖2023/2/424讀者借書登記資格核查借書單書籍

一個簡單的系統可用一張數據流圖來表示。當系統比較復雜時，為了便于理解，控制其復雜性，可以采用分層描述的方法。一般用第一層描述系統的全貌，第二層分別描述各子系統的結構。

2023/2/425

數據字典是對系統中數據的詳細描述，是各類數據結構和屬性的清單。它與數據流圖互為注釋。數據字典貫穿于數據庫需求分析直到數據庫運行的全過程，在不同的階段其內容和用途各有區別。在需求分析階段，數據字典通常包含以下五部分內容：◆數據項

數據項是數據的最小單位，其具體內容包括：數據項名、含義說明、別名、類型、長度、取值范圍、與其他數據項的關系。2023/2/426◆

數據結構

數據結構是數據項有意義的集合。內容包括：數據結構名、含義說明，這些內容組成數據項名。◆數據流

數據流可以是數據項，也可以是數據結構，它表示某一處理過程中數據在系統內傳輸的路徑。內容包括：數據流名、說明、流出過程、流入過程，這些內容組成數據項或數據結構。2023/2/427◆

數據存儲

處理過程中數據的存放場所，也是數據流的來源和去向之一。可以是手工憑證，手工文檔或計算機文件。◆處理過程

處理過程的處理邏輯通常用判定表或判定樹來描述，數據字典只用來描述處理過程的說明性信息。2023/2/428

需求分析得到的DFD圖集和數據字典中的內容必須返回用戶，并且用非專業術語與用戶交流。在反饋時，設計者與用戶一起檢查與修改那些沒有如實反映現實世界的錯誤或遺漏。修改DFD圖、補充數據字典的過程可能需要反復多次，最終取得用戶的認可。最終形成的數據流圖和數據字典為“需求分析說明書”的主要內容，這是下一步進行概念設計的基礎。也是將來系統維護的基礎。2023/2/429需求分析過程中要注意的３點：

第一，應用部門的業務人員常常缺少計算機的專業知識，而數據庫設計人員又常常缺乏應用領域的業務知識，因此相互的溝通往往比較困難。第二，不少業務人員往往對開發計算機系統有不同程度的抵觸情緒。有的認為需求調查影響了他們的工作，給他們造成了負擔，特別是新系統的建設常常伴隨企業管理的改革，這會遇到不同部門不同程度的抵觸。2023/2/430

第三，應用需求常常在不斷改變，使系統設計也常常要進行調整甚至要有重大改變。

面對這些困難，設計人員特別應該注意：

1．用戶參與的重要性

2．用原型法來幫助用戶確定他們的需求

3．預測系統的未來改變2023/2/431第6章數據庫設計6.1數據庫設計概述

6.2需求分析

6.3概念設計

6.4邏輯設計

6.5模式求精2023/2/432

概念設計就是將需求分析得到的用戶需求抽象為信息結構，即概念(語義)數據模型(簡稱概念模型)。概念模型作為概念設計的表達工具，為數據庫提供一個說明性結構，是設計數據庫邏輯結構（邏輯模型）的基礎。概念模型必須具備以下特點：

語義表達能力豐富；易于交流和理解； 易于修改和擴充；易于向各種數據模型轉換。

2023/2/433人們提出了許多概念模型，如語義對象模型(SemanticObjectModel，簡稱SOM)、實體關系(Entity-Relationship，簡稱ER)

模型等。目前應用最普遍的是實體關系模型，它將現實世界的信息結構統一用屬性、實體以及它們之間的聯系來描述。2023/2/434實體關系模型2023/2/435◆

基本概念實體(Entity)。客觀存在并可相互區別的事物稱為實體。實體可以是具體的人、事、物，也可以是抽象的概念或聯系。屬性(Attribute)。屬性為實體的某一方面特征的抽象表示。如教師實體可由教師編號、姓名、年齡、性別、職稱等屬性來刻畫。域(Domain)。屬性的取值范圍稱為屬性的域。如：教師實體中，屬性性別的域為男和女。2023/2/436主碼(PrimaryKey)。碼也稱關鍵字，它是能夠唯一標識一個實體的屬性集。如：教師實體的主碼為教師編號。聯系(Relationship)。現實世界的事物總是存在著這樣或那樣的聯系，這種聯系必然要在信息世界中得到反映。事物之間的聯系可分為兩類：一類是實體內部的聯系，如組成實體的各屬性之間的關系；另一類是實體之間的聯系，即不同實體之間的聯系。2023/2/437◆

兩個實體集之間的聯系

1:1聯系：如果對于A中的一個實體，B中至多有一個實體與其發生聯系，反之，B中的每一實體至多對應A中一個實體，則稱A與B是1:1聯系。

1:n聯系：如果對于A中的每一實體，實體B中有一個以上實體與之發生聯系，反之，B中的每一實體至多只能對應于A中的一個實體，則稱A與B是1:n聯系。

m:n聯系：如果A中至少有一實體對應于B中一個以上實體，反之，B中也至少有一個實體對應于A中一個以上實體，則稱A與B為m:n聯系。2023/2/438兩個實體集之間的３類聯系2023/2/439◆

兩個以上實體集之間的聯系

例如：導師、學生、課題之間的三元關系。

注意：為了簡化概念設計，通常將三元關系分解為適當的等價二元關系。◆

實體關系模型的表示方法

ER圖是直觀表示概念模型的工具，ER圖的基本思想就是分別用矩形框、橢圓形框和菱形框表示實體、屬性和聯系，使用無向邊將屬性與其相應的實體連接起來，并將聯系分別和有關實體相連接，注明聯系類型。2023/2/441◆

概念設計方法

設計概念結構的ER模型可采用自頂向下、自底向上、逐步擴張和混合策略四種方法。其中最常用的方法是自底向上。自底向上方法是先定義各局部應用的概念結構ER模型，然后將它們集成，得到全局概念結構ER模型。2023/2/442[例6.1]

在簡單的教務管理系統中，有如下語義約束：

一個學生可選修多門課程，一門課程可被多個學生選修。學生和課程之間是多對多的聯系；

一個教師可講授多門課程，一門課程可以由多個教師講授。教師和課程之間也是多對多的聯系；

一個系可有多個教師，一個教師只能屬于一個系。系和教師是之間一對多的聯系，同樣系和學生之間也是一對多的聯系。2023/2/443n1系屬于教師擁有學生講授選修課程mmnm1m學號姓名性別年齡成績課程號課程名教師號姓名性別職稱系名電話教務管理系統的基本ER圖2023/2/444一個好的ER模式，除了能夠準確、全面的反映用戶需求之外，還應該達到下列要求：◆實體類型的個數應盡量少；◆實體類型所含屬性個數應盡可能少；◆實體類型間的聯系應無冗余。2023/2/445典型實例

[例6.2]NewCentury唱片公司決定將制作唱片的有關音樂人的信息存入數據庫中。◆每個NewCentury中的音樂人都有No、姓名，地址、電話號碼等信息。◆每樣樂器都有樂器名（如吉他、電子合成器、長笛等），音樂的基調（如C、B-flat、E-flat）等信息。◆每張唱片都有標題、出版日期、格式（如CD和MC）、唱片標識碼等信息。2023/2/446◆每首歌曲都有標題和作者等信息。

◆每個音樂人可以演奏多種樂器，且一種樂器可以由多個音樂人演奏。◆每張唱片有一組歌曲，但一首歌曲只能出現在一張唱片中。◆每首歌曲由一名或多名音樂人來完成，一名音樂人可以完成多首歌曲。◆每個唱片只有一名制片人，一個音樂人可以制作多個唱片。2023/2/447音樂人唱片歌曲樂器電話號碼NO.樂器名音樂基調地址姓名演奏格式出版日期唱片標題作者標題唱片標識碼制作完成有n11nnmnm2023/2/448

[例6.3]設計一個科研檔案管理系統的ER圖。

教師：教師編號、姓名、性別、年齡、出生日期、工作時間、職稱、政治面貌、文化程度；

研究生：研究生學號、姓名、指導教師編號、指導教師姓名、專業代碼、班級；

項目：項目編號、項目名稱、項目來源、項目級別、開始時間、結束時間；

論文：論文編號、論文題目、論文級別、發表刊物、發表時間、主辦單位；

專業：專業代碼、專業名稱、學科代碼、學科名稱。2023/2/449每位研究生都有一位教師作為導師，一個教師可以指導多名研究生（教師和研究生之間存在一對多的關系）。每個項目都有多名教師和研究生參加，并有一位教師作為項目負責人（項目和研究生之間、項目和教師之間都是多對多的關系）。每篇論文由一名以上教師或研究生完成，按作者順序排列（教師和論文之間、研究生和論文之間都是多對多的關系）。每位研究生只屬于某一專業（研究生和專業之間是一對多的關系）。2023/2/450nmmm11nnn項目研究生專業教師論文科研檔案管理ER圖參加指導發表參加屬于發表編號名稱成果學號姓名專業代碼專業名稱教師編號教師姓名論文編號論文名稱級別刊物nnm排名排名排名排名2023/2/451ER模型定義了一種特殊類型的實體，弱實體（weakentity）。弱實體的存在依賴于另一個實體（其所依賴的實體不存在，弱實體就不存在）。例：建筑物（建筑名稱，省，市，區，街道），公寓（建筑名稱，公寓編號，樓層，門牌號，面積，月租）。2023/2/452數據建模產品中的ER圖（變體）。2023/2/453第6章數據庫設計6.1數據庫設計概述

6.2需求分析

6.3概念設計

6.4邏輯設計

6.5模式求精2023/2/454概述

概念結構設計階段得到的ER模型是用戶模型，它獨立于任何一種數據模型，獨立于任何一個具體的DBMS，是一個與計算機軟、硬件的具體性能無關的全局概念模式。為了建立用戶所要求的數據庫，需要把上述概念模型轉換為某個具體的DBMS所支持的數據模型，即邏輯結構設計。

數據庫邏輯設計的任務是將概念結構轉換成特定DBMS所支持的數據模型的過程。關系數據庫邏輯設計的結果是一組關系模式的定義。2023/2/455初始關系模式設計關系模式規范化模式評價是否修正以DBMS語法描述物理設計模式修正否是邏輯設計的步驟2023/2/456初始關系模式設計

初始關系模式設計過程就是ER圖向關系模式的轉換。ER圖向關系模式轉換的實質是要將ER圖中的實體、屬性和聯系轉換成關系模式。2023/2/457

轉換原則

一個實體轉換為一個關系模式，實體的屬性就是關系的屬性，實體的鍵就是關系的鍵。具有相同主鍵的關系可以合并。一個聯系轉換為一個關系模式，分為以下幾種情況。2023/2/458

一個1:1的聯系可以轉化為一個獨立的關系模式，也可以與任意一端對應的關系模式合并。一個1:n的聯系可以轉換為一個獨立的關系模式，也可以與n端對應的關系模式合并。

一個n:m的聯系轉換為一個關系。關系的屬性由聯系本身的屬性和與之聯系的實體的主鍵組成，關系的主鍵由聯系中各實體的主鍵組合而成(組合鍵)。2023/2/459

[例6.5]

將[例6.1]所示教務管理系統的ER圖轉換成一組初始關系模式。

轉換步驟

2023/2/460n1系屬于教師擁有學生講授選修課程mmnm1m學號姓名性別年齡成績課程號課程名教師號姓名性別職稱系名電話教務管理系統的基本ER圖2023/2/461

畫出關系圖

邏輯設計中，ER圖轉換為關系模式后，應該考慮數據的完整性。實體完整性通過確定主鍵已完成。用戶定義的完整性在實現階段完成。對于參照完整性，可以用關系圖來描述。2023/2/4622023/2/463

實例分析

[例6.6]

將［例6.2］設計的NewCentury唱片公司信息管理系統的ER圖轉換為關系模式，并畫出相應的關系圖。2023/2/464音樂人唱片歌曲樂器電話號碼NO.樂器名音樂基調地址姓名演奏格式出版日期唱片標題作者標題唱片標識碼制作完成有n11nnmnm2023/2/4652023/2/466

[例6.7]

將［例6.3］中設計的教師和研究生科研檔案管理系統的ER圖轉換為關系模式，并畫出相應的關系圖。

實例分析

2023/2/467nmmm11nnn項目研究生專業教師論文科研檔案管理ER圖參加指導發表參加屬于發表編號名稱成果學號姓名專業代碼專業名稱教師編號教師姓名論文編號論文名稱級別刊物nnm排名排名排名排名2023/2/4682023/2/469UML與數據庫設計2023/2/470統一建模語言

UnifiedModelingLanguage(UML)又稱統一建模語言或標準建模語言，是始于1997年一個OMG標準，它是一個支持模型化和軟件系統開發的圖形化語言，為軟件開發的所有階段提供模型化和可視化支持。面向對象的分析與設計方法的發展在80年代末至90年代中出現了一個高潮，UML是這個高潮的產物。2023/2/471

作為一種建模語言，UML的定義包括UML語義和UML表示法兩個部分。

(1)UML語義：描述基于UML的精確元模型定義。元模型為UML的所有元素在語法和語義上提供了簡單、一致、通用的定義性說明，使開發者能在語義上取得一致，消除了因人而異的最佳表達方法所造成的影響。此外UML還支持對元模型的擴展定義。

(2)UML表示法：定義UML符號的表示法，為開發者或開發工具使用這些圖形符號和文本語法為系統建模提供了標準。這些圖形符號和文字所表達的是應用級的模型，在語義上它是UML元模型的實例。2023/2/472UML中的基本元模型有：角色（actor）、用例圖（usecase）、類（class）、包（package）、消息（message）、關聯（association）、聚集（aggregation）等。如下圖所示：2023/2/473UML提供了兩大類，共9種圖形支持建模。其分類和各個圖形的作用，如下表：2023/2/474用例圖

用例圖用于建模系統所要實現的功能。它包括角色（Actor）、用例（UseCase）、系統邊界、角色與用例之間和用例與用例之間的關聯（Association）。2023/2/475類圖類是面向對象技術的重要概念，它抽象地概括具有同樣屬性和行為的所有對象的共性。觀察我們周圍的事物就會發現它們很自然地都有各自所屬的種類（汽車、洗衣機，……）。各種事物又都可能具有某些屬性，并且它們以某種方式體現出各自的行為，我們可以認為這種行為是一組操作。2023/2/476學生管理信息系統中的一個用例圖2023/2/477學生管理信息系統中的一個類圖2023/2/478學生管理信息系統中的一個狀態圖2023/2/479UML建模工具Visio、RationalRose、PowerDesign簡介

ROSE是直接從UML發展而誕生的設計工具，它的出現就是為了對UML建模的支持，ROSE一開始沒有對數據庫端建模的支持，但是在現在的版本中已經加入數據庫建模的功能。ROSE主要是在開發過程中的各種語義、模塊、對象以及流程，狀態等描述比較好，主要體現在能夠從各個方面和角度來分析和設計，使軟件的開發藍圖更清晰，內部結構更加明朗（但是它對客戶了解系統的功能和流程等并不一定很有效），對系統的代碼框架生成有很好的支持，但對數據庫的開發管理不是很好。2023/2/480PowerDesigner原來是對數據庫建模而發展起來的一種數據庫建模工具。直到7.0版才開始對面向對象的開發的支持，后來又引入了對UML的支持。PowerDesigner對數據庫建模的支持很好，對UML的建模使用到的各種圖的支持比較滯后（但是在最近得到加強，所以使用它來進行UML開發的并不多，很多人都是用它來作為數據庫的建模）。如果使用UML分析，它的優點是生成代碼時對Sybase的產品PowerBuilder的支持很好（其它UML建模工具需要一定的插件），其他面向對象語言如C++，Java，VB,C#等支持也不錯。2023/2/481UML建模工具Visio原來僅僅是一種畫圖工具，能夠用來描述各種圖形（從電路圖到房屋結構圖），VISIO2000開始引進從軟件分析設計到代碼生成的全部功能，可以說是目前最能夠用圖形方式來表達各種商業圖形用途的工具（對軟件開發中的UML支持僅僅是其中很少的一部分）。它跟微軟的office產品的能夠很好兼容。能夠把圖形直接復制或者內嵌到WORD的文檔中。但是對于代碼的生成更多是支持微軟的產品如VB,VC++,MSSQLServer等。所以它可以說用于圖形語義的描述比較方便，但是用于軟件開發過程的迭代開發則有點牽強。2023/2/482第6章數據庫設計6.1數據庫設計概述

6.2需求分析

6.3概念設計

6.4邏輯設計

6.5模式求精2023/2/483關系數據庫設計中存在的問題

示例:

考慮為管理職工的工資信息而設計一個關系模式。2023/2/484在表中包含著兩類信息：

職工個人的工資信息；各個級別的工資數額。問題：

如果我希望知道在這個單位8級工的工資是多少，能否查詢到？2023/2/485問題：

插入異常：如果沒有職工具有8級工資，則8級工資的工資數額就難以插入。

刪除異常：如果僅有職工趙明具有4級工資，如果將趙明刪除，則有關4級工資的工資數額信息也隨之刪除了。2023/2/486

數據冗余：職工很多，工資級別有限，每一級別的工資數額反復存儲多次。

更新異常：如果將5級工資的工資數額調為620，則需要找到每個具有5級工資的職工，逐一修改。2023/2/487解決之道：分解!2023/2/488有關學生的關系模式S(學號,姓名,系號,主任,課程編號,成績)它有哪些數據冗余？2023/2/489★規范化理論問題的提出

針對一個具體問題，如何構造一個合適的數據模式。即應該構造幾個關系模式（表），每個關系有那些屬性組成？2023/2/490定義：設R(U)是屬性集U上的關系模式。X，Y是U的子集。若對于R(U)的任意一個可能的關系r，r中不可能存在兩個元組在X上的屬性值相等，而在Y上的屬性值不等，則稱X函數確定Y或Y函數依賴于X，記為X→Y。記號x→y稱x函數確定y，或y函數依賴于x。稱X為決定因素。例如：學號姓名，（學號，課程）成績2023/2/491注意：函數依賴是語義范疇的概念，我們只能根據語義來確定函數依賴。例如在沒有同名的情況下，姓名→年齡是成立的，而在有同名的情況下，這個函數依賴就不成立了。平凡函數依賴：如果XY，但Y不是X的子集，則稱其為非平凡的函數依賴，否則稱為平凡的函數依賴。

如（學號，姓名）姓名是平凡的函數依賴2023/2/492

函數依賴可分為三類：完全函數依賴，部分函數依賴和傳遞函數依賴。定義：在R(U)中有X、YU，如果X→Y，并且對于X的任何一個真子集X'?，都有Y不函數依賴于X'，則稱Y對X是完全函數依賴的。定義：在R(U)中，如果X→Y，并且對于X的某個真子集X'，有X'→Y，則稱Y對X部分函數依賴。定義：在R(U)中，如果X→Y（Y不包含于X，X不依賴于Y），且Y→Z，則稱Z對X傳遞函數依賴。2023/2/493例1：某單位有一資料室，它管理的數據有讀者信息、圖書信息、借閱信息。讀者信息：借書證號，讀者姓名，性別，部門，學歷，部門電話，個人電話，電子信箱等；圖書信息：圖書編號，分類號，書名，作者，出版社，單價等；借閱信息：借書證號，圖書編號，書名，借出日期，應還日期等。2023/2/494函數依賴關系（讀者信息）：借書證號→讀者姓名借書證號→性別借書證號→部門借書證號→學歷部門→部門電話借書證號→個人電話借書證號→電子信箱2023/2/495函數依賴關系（圖書信息）：

圖書編號→分類號圖書編號→書名圖書編號→作者圖書編號→出版社圖書編號→單價函數依賴關系（借閱信息）：

圖書編號→書名借書證號、圖書編號，借出日期→應還日期2023/2/496范式理論1NF：任一屬性不能同時具有多個值（關系中每一分量不可再分。即不能以集合、序列等作為屬性值）。2NF：屬性必須完全依賴唯一標識符。3NF：屬性間不存在傳遞依賴。BCNF：每一個決定因素都包含碼。2023/2/497例2

：R(學號，姓名，課程編號，課程名稱，學分，成績)唯一標識符(Key)：

(學號，課程編號)不符合2NF依賴關系：

學號→姓名，課程編號→課程名稱，課程編號→學分，(學號，課程編號)→成績2023/2/498例3

：

S(學號，姓名，性別，學院，院長)。

唯一標識符(Key)：

學號不符合3NF依賴關系：

學號→姓名，學號→性別，學號→學院，學院→院長2023/2/499問題的解決辦法：拆分關系（表）2023/2/4100關于例2R(學號，姓名，課程編號，課程名稱，學分，成績)R1(學號，姓名)R2(課程編號，課程名稱，學分)R3(學號，課程編號，成績)學號→姓名，課程編號→課程名稱，課程編號→學分,(學號，課程編號)→成績2023/2/4101關于例3S(學號，姓名，性別，學院，院長)S1(學號，姓名，性別，學院)S2(學院，院長)

學號→姓名，學號→性別，學號→學院，學院→院長2023/2/4102例4：某部隊擬建立干部檔案（軍官備案登記表），數據項有：編號，姓名，現軍銜，現任職務，入伍日期，最高學歷，低級軍銜及授予日期，曾擔任職務及任命日期，所取得各學歷及取得日期。2023/2/4103函數依賴關系：編號→姓名，編號→現軍銜，編號→現任職務，編號→入伍日期，編號→最高學歷(編號,低級軍銜)→授予日期(編號,曾擔任職務)→任命日期(編號,各學歷)→取得日期2023/2/4104表1（編號，姓名，現軍銜，現任職務，入伍日期，最高學歷）表2（編號，低級軍銜，授予日期）表3（編號，曾擔任職務，任命日期）表4（編號，學歷，取得日期）。2023/2/4105規范化步驟→2NF→3NF

→BCNF→4NF

規范化的目的就是構造合適的關系模式。2023/2/4106范式之間的關系

定理：關系模式R若滿足3NF，則必定滿足2NF。反證：若R3NF，但R2NF，則按2NF定義，一定有非主屬性部分依賴于碼；設X為R的碼，則存在X的真子集S，以及非主屬性Z（其中Z

不包含于S），使得S

Z成立；于是在R中存在碼X，屬性組S，以及非主屬性Z，使得XS，SZ成立（并且X不依賴于S）；這與R3NF矛盾，所以R2NF。2023/2/4107

定理：關系模式R若滿足BCNF，則必定滿足3NF。

證明略，請大家看參考書。2023/2/4108模式分解中的問題實例 表（職工，級別，工資）可以有兩種分解途徑，

分解一：（職工，工資），（工資，級別）丟失函數依賴

分解二：（職工，級別），（工資，級別）

不同行業機構的不同工資級別會有相同工資數額。按分解一，有可能導致同一職工對應不同的工資級別，從而丟失了有關職工工資級別的信息（丟失了函數依賴：職工級別）。2023/2/4109R(A,B,C)∏AB(R)∏BC(R)∏AB(R)∏BC(R)R(A,B,C)∏AB(R)∏BC(R)∏AB(R)∏BC(R)有損分解無損分解2023/2/4110

將R分解為R1和R2的分解是無損連接分解的條件是，R1∩R2→R1，或R1∩R2→R2。如果有R上的函數依賴X→Y成立，且X∩Y是空集，則分解R–Y和XY是無損連接分解。2023/2/4111

判定一個分解是否為依賴保持分解的算法比較復雜。請看參考文獻。

2023/2/4112

設計目標：無損連接