第6章 數(shù)據(jù)庫設計(2016春)

2023/2/41第6章數(shù)據(jù)庫設計本章主要內(nèi)容6.1數(shù)據(jù)庫設計概述

6.2需求分析

6.3概念設計

6.4邏輯設計6.5模式求精

6.6物理設計

6.7數(shù)據(jù)庫實施

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

數(shù)據(jù)庫設計有別于其他軟件系統(tǒng)的設計，有其獨特的特點——以數(shù)據(jù)為中心。

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

6.1數(shù)據(jù)庫設計概述

6.2需求分析

6.3概念設計

6.4邏輯設計

6.5模式求精2023/2/45數(shù)據(jù)庫設計的任務和目標 一個成功的管理系統(tǒng)=50%的業(yè)務+50%的軟件

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

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

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

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

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

數(shù)據(jù)庫結構設計和對數(shù)據(jù)的處理設計密切結合

結構設計：就是設計各級數(shù)據(jù)庫模式，決定數(shù)據(jù)庫系統(tǒng)的信息內(nèi)容。

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

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

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

基于ER模型的數(shù)據(jù)庫設計方法；

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

基于3NF的數(shù)據(jù)庫設計方法；

S·Atre提出

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

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

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

Oracle公司開發(fā)的DesignerSybase公司開發(fā)的PowerDesigner

這些軟件簡稱為CASE（ComputerAidedSoftwareEngineering）工具?！糇詣踊O計法

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

6.2需求分析

6.3概念設計

6.4邏輯設計

6.5模式求精2023/2/418需求分析的任務對現(xiàn)實世界要處理的對象（組織、部門、企業(yè)等）進行詳細的調(diào)查，通過對原系統(tǒng)的了解，收集支持新系統(tǒng)的基礎數(shù)據(jù)并對其進行處理，在此基礎上確定新系統(tǒng)的功能?！粽{(diào)查分析用戶的活動

調(diào)查組織機構情況，調(diào)查各部門的業(yè)務活動情況?！羰占头治鲂枨髷?shù)據(jù)，確定系統(tǒng)邊界信息需求；處理需求；安全性；完整性的需求。2023/2/419◆

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

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

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

(4)系統(tǒng)功能說明；

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

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

(1)系統(tǒng)的硬件、軟件支持環(huán)境的選擇及規(guī)格要求（所選擇的數(shù)據(jù)庫管理系統(tǒng)、操作系統(tǒng)、漢字平臺、計算機型號及其網(wǎng)絡環(huán)境等）。

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

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

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

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

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

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

2023/2/425

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

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

數(shù)據(jù)結構

數(shù)據(jù)結構是數(shù)據(jù)項有意義的集合。內(nèi)容包括：數(shù)據(jù)結構名、含義說明，這些內(nèi)容組成數(shù)據(jù)項名。◆數(shù)據(jù)流

數(shù)據(jù)流可以是數(shù)據(jù)項，也可以是數(shù)據(jù)結構，它表示某一處理過程中數(shù)據(jù)在系統(tǒng)內(nèi)傳輸?shù)穆窂?。?nèi)容包括：數(shù)據(jù)流名、說明、流出過程、流入過程，這些內(nèi)容組成數(shù)據(jù)項或數(shù)據(jù)結構。2023/2/427◆

數(shù)據(jù)存儲

處理過程中數(shù)據(jù)的存放場所，也是數(shù)據(jù)流的來源和去向之一?？梢允鞘止{證，手工文檔或計算機文件?！籼幚磉^程

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

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

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

第三，應用需求常常在不斷改變，使系統(tǒng)設計也常常要進行調(diào)整甚至要有重大改變。

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

1．用戶參與的重要性

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

3．預測系統(tǒng)的未來改變2023/2/431第6章數(shù)據(jù)庫設計6.1數(shù)據(jù)庫設計概述

6.2需求分析

6.3概念設計

6.4邏輯設計

6.5模式求精2023/2/432

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

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

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

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

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

兩個實體集之間的聯(lián)系

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

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

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

兩個以上實體集之間的聯(lián)系

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

注意：為了簡化概念設計，通常將三元關系分解為適當?shù)牡葍r二元關系。◆

實體關系模型的表示方法

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

概念設計方法

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

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

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

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

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

[例6.2]NewCentury唱片公司決定將制作唱片的有關音樂人的信息存入數(shù)據(jù)庫中?！裘總€NewCentury中的音樂人都有No、姓名，地址、電話號碼等信息?！裘繕訕菲鞫加袠菲髅ㄈ缂㈦娮雍铣善?、長笛等），音樂的基調(diào)（如C、B-flat、E-flat）等信息?！裘繌埑加袠祟}、出版日期、格式（如CD和MC）、唱片標識碼等信息。2023/2/446◆每首歌曲都有標題和作者等信息。

◆每個音樂人可以演奏多種樂器，且一種樂器可以由多個音樂人演奏?！裘繌埑幸唤M歌曲，但一首歌曲只能出現(xiàn)在一張唱片中?！裘渴赘枨梢幻蚨嗝魳啡藖硗瓿?，一名音樂人可以完成多首歌曲。◆每個唱片只有一名制片人，一個音樂人可以制作多個唱片。2023/2/447音樂人唱片歌曲樂器電話號碼NO.樂器名音樂基調(diào)地址姓名演奏格式出版日期唱片標題作者標題唱片標識碼制作完成有n11nnmnm2023/2/448

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

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

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

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

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

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

6.2需求分析

6.3概念設計

6.4邏輯設計

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

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

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

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

轉換原則

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

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

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

[例6.5]

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

轉換步驟

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

畫出關系圖

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

實例分析

[例6.6]

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

[例6.7]

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

實例分析

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

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

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

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

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

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

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

6.2需求分析

6.3概念設計

6.4邏輯設計

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

示例:

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

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

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

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

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

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

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

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

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

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

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

圖書編號→書名借書證號、圖書編號，借出日期→應還日期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：某部隊擬建立干部檔案（軍官備案登記表），數(shù)據(jù)項有：編號，姓名，現(xiàn)軍銜，現(xiàn)任職務，入伍日期，最高學歷，低級軍銜及授予日期，曾擔任職務及任命日期，所取得各學歷及取得日期。2023/2/4103函數(shù)依賴關系：編號→姓名，編號→現(xiàn)軍銜，編號→現(xiàn)任職務，編號→入伍日期，編號→最高學歷(編號,低級軍銜)→授予日期(編號,曾擔任職務)→任命日期(編號,各學歷)→取得日期2023/2/4104表1（編號，姓名，現(xiàn)軍銜，現(xiàn)任職務，入伍日期，最高學歷）表2（編號，低級軍銜，授予日期）表3（編號，曾擔任職務，任命日期）表4（編號，學歷，取得日期）。2023/2/4105規(guī)范化步驟→2NF→3NF

→BCNF→4NF

規(guī)范化的目的就是構造合適的關系模式。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模式分解中的問題實例 表（職工，級別，工資）可以有兩種分解途徑，

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

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

不同行業(yè)機構的不同工資級別會有相同工資數(shù)額。按分解一，有可能導致同一職工對應不同的工資級別，從而丟失了有關職工工資級別的信息（丟失了函數(shù)依賴：職工級別）。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上的函數(shù)依賴X→Y成立，且X∩Y是空集，則分解R–Y和XY是無損連接分解。2023/2/4111

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

2023/2/4112

設計目標：無損連接