1、全國計算機等級考試四級教程數據庫工程師第一章 引 論1、 數據庫技術產生于20世紀60年代，是信息系統的核心技術和重要基礎；2、 計算機科學與技術學科劃分為四個專業方向：計算機科學（CS）；計算機工程（CE）；軟件工程（SE）；信息技術（IT）。11 基本概念111 信息與數據1、 信息、物質、能量是組成客觀世界并促進社會發展的三大基本要素；2、 信息（Information）-是客觀世界事物的存在方式和運動狀態的反映，是對事物之間相互聯系、相互作用的描述。信息具有可感知、可存儲、可加工、可傳遞和可再生的自然屬性。3、 數據（Data）-是描述現實世界事物的符號記錄，是用物理符號記錄下來的可以

2、識別的信息。不同的物理符號體現出數據的不同表現形式。4、 信息與數據間存在固有聯系，數據是信息的符號表示，或稱為載體。信息則是數據的語義解釋，是數據的內涵，信息以數據的形式表現出來，并為人們理解和接受。5、 數據處理（Data Processing）-是指對數據進行分類、收集、組織、存儲，進而從已數據出發，抽取或推導出新的數據，這些數據表示了新的信息。6、 數據管理（Data Management）-是指對數據的分類、收集、組織、編碼、存儲、檢索和維護，是數據處理業務的重要環節。7、 數據處理與數據管理的區別在于，數據處理除了具有數據管理功能外，還可通過數據管理得到的數據進一步深加工，從中獲取

3、新的數據和信息。112 數據庫系統1、 數據庫（DB，DataBase）-是長期存儲在計算機內有組織的、大量的、共享的數據集合；2、 數據庫管理系統（DBMS，Database Management System）-是指在計算機系統中，位于用戶與操作系統之間的數據管理系統軟件，是數據庫系統的核心。3、 （廣義的）數據庫系統（DBS，DataBase System）-是指在計算機系統中引入數據庫后的軟硬件系統構成，DBS一般分成三個層次：（1）計算機硬件平臺；（2）系統軟件和應用軟件；（3）用戶；在不引起混淆和歧義的情況下，數據庫系統簡稱為數據庫。4、 （狹義的）數據庫系統是由數據庫和數據庫管理

4、系統組成的軟件系統，主要為用戶提供數據存儲和查詢、插入、修改、刪除、更8有新等數據管理功能。5、 數據庫應用系統（DBAS，DataBase Application System）是由數據庫、數據庫管理系統、數據庫應用程序組成的軟件系統，它面向具體應用領域，提供了更為復雜的數據處理功能。6、 數據庫技術是研究數據庫的結構、存儲、設計、管理和使用的一門計算機應用學科。7、 數據庫技術與其它計算機科學有密切關系：（1） 數據庫技術以文件系統為基礎發展而來，DBMS需要操作系統的支持，數據庫以文件形式存儲在外部存儲上的；（2） 數據庫與數據結構的關系很密切，數據庫技術不僅用到數據結構中的鏈表、樹、圖

5、等知識，各種數據模型本身就屬于復雜數據結構；（3） 主流的關系數據庫系統，其理論基礎是關系數據模型，而該模型是在離散數學集合論中“關系”這一基本概念上發展起來的；（4） 當用戶訪問數據庫，DBMS對用戶提交的查詢操作類似于，計算機編譯系統對程序的編譯過程；（5） 開發一些大型的DBS或DBMS的過程，要遵循軟件工程的開發模式。12 數據模型121 數據模型概念1、數據模型（Data Model）-對現實世界的特征抽象。是數據庫系統的形式框架，是用來描述數據的一組概念和定義，包括描述數據、數據聯系、數據操作、數據語義以及數據一致性的概念工具；2、數據模型應滿足3個條件：（1）能夠比較真實地模擬現

6、實世界；（2）容易為人們所理解；（3）便于在計算機上實現。3、 數據模型的組成：（1） 數據結構：用于描述系統的靜態特征，從語法角度表述了客觀世界中數據對象本身的結構和數據對象之間的關聯關系，是刻畫一個數據模型性質最重要的方面。在數據庫系統中，通常按照數據結構的類型來區分、命名各種數模，如層次、網狀、關系數模。（2） 數據操作：用于描述系統的動態特征，是一組對數據庫中各種數據對象允許執行的操作和操作規則組成的集合。數據操作可以是檢索、插入等，數模必須定義這些操作的確切含義、操作符號、操作規則以及實現操作的數據庫語言。（3） 數據完整性約束：是一組完整性規則的集合，它定義了數模必須遵守的語義約束

7、，也規定了數據庫中數據內部及數據之間聯系所必須滿足的語義約束。它限定了數據庫的狀態以及狀態的變化，以便維護數據的正確性、有效性。122 數據模型分類1、 用數據模型這一概念來描述數據庫的結構和語義，通過現實世界信息世界機器世界（建模過程）的抽象轉換過程構建數據庫，并根據模型所定義的規范去管理和使用數據。2、 建模過程：（1）將現實世界的數據對象抽象為信息世界中的某一信息結構；（2）再將信息結構轉換為機器世界中某一具體DBMS支持的數據模型，并存儲于計算機中。3、 數據模型分類：（由上到下）（1） 概念數據模型（概念模型）：按用戶的觀點對數據和信息進行建模，是現實世界到信息世界的第一層抽象，強調

8、其語義表達功能，易于用戶理解，是用戶與設計人員交流的語言，主要用于數據庫設計。最常用的是實體聯系模型。（2） 數據結構模型（表示型/實現型）：是機器世界中與具體DBMS相關的數據模型，包括關系模型、網狀模型和層次模型（3） 物理數據模型：屬底層數據模型，描述數據的實際存儲方式。13 數據視圖與模式結構131 數據視圖與數據抽象1、 數據視圖：指從某個角度看到的客觀世界數據對象的特征，是對數據對象某一方面特征的描述。2、 數據抽象：是一種數據描述和數據庫設計原則，是指專注于數據對象的某方面特征，而忽略其他特征。3、 集和值：集是指對某一類數據的結構和屬性的說明，值是集的一個具體賦值；4、 數據模

9、式：對數據庫中數據某方面結構和特征的描述，它僅涉及集的描述，不涉及具體的值。132 三級模式結構（從數據庫管理系統角度）1、 數據庫三級模式結構外部級、概念級和內部級，分別定義了外模式、模式和內模式，用于從不同角度描述數據庫結構。2、 模式：（1） 也稱邏輯模式、概念模式；（2） 對數據庫中全體數據的邏輯結構和特征的描述，是所有用戶的公共數據視圖；（3） 模式不僅定義了數據的邏輯結構，還定義了數據之間的聯系、與數據的關的安全性和完整性要求；（4） 一個數據庫只有一個模式，建立在某種數據結構模型基礎上。3、 外模式：（1） 也稱子模式、用戶模式、用戶視圖；（2） 是對數據庫用戶能夠看見和使用的局

10、部數據的邏輯結構和特征的描述。（3） 一個數據庫可以有多個外模式，每個外模式描述了某個特定用戶所使用的局部數據的邏輯結構和特征，是與某一應用有關的數據的邏輯表示。（4） 外模式還是保證數據安全的有力措施，每個用戶只能看見和訪問所對應的外模式中的數據，其它數據對他是不可見的。4、 內模式：（1） 也稱物理模式、存儲模式；（2） 是對數據庫中數據的物理結構和存儲方式的描述，代表了數據在數據庫內部的表示方式和物理組織結構；133 二級映象與數據獨立性1、 外模式/模式映象：（1） 定義了數據庫中不同用戶的外模式與數據庫邏輯模式之間的對應關系；（2） 可有多個外模式/模式映象，對于每個外模式，需要一個

11、外模式/模式映象來定義該外模式與模式之間的對應關系；（3） 當模式發生變化時，只需調整外模式/模式間的映象關系，而外模式無需修改，保證了數據與應用程序的邏輯獨立性，稱為數據的邏輯獨立性。2、 模式/內模式映象：（1） 定義了數據庫中數據全局邏輯結構，與這些數據在系統中的物理存儲組織結構之間的對應關系。（2） 模式/內模式映象是唯一的；（3） 當內模式發生變化時，只需調整模式/內模式映象關系，而模式無需修改，保證了數據庫中的數據與應用程序間的物理獨立性，稱為數據的物理獨立性。14 數據庫系統體系結構1、 數據庫系統體系結構（從用戶角度）：是指數據庫系統的組成構件、各構件的功能及各構件間的協同工作

12、方式；2、 分類：（1） 集中式：全部數據和數據管理功能均集中在一臺計算機上的數據庫系統；包括單用戶和主從式兩種，單用戶DBS是指系統由一個用戶獨占，不同機器間不能共享數據；主從式DBS是指一個主機帶多個分時多用戶的DBS；（2） 分布式：數據庫中的數據在邏輯上是一個整體，但在物理上卻可以分布在網絡中不同數據管理節點上；（3） 客戶/服務器：將DBMS和數據庫應用分開，網絡中某些節點上的計算機專門執行DBMS功能，負責數據管理服務，稱為數據庫服務器；其他節點的計算機上安裝DBMS的外圍應用開發工具，支持用戶的應用，主要負責數據表示服務，稱為客戶端；（4） 并行式：硬件平臺是并行計算機系統，使用

13、多個CPU和多個磁盤進行并行數據處理和磁盤訪問操作，以提高執行速度；（5） WEB式： 由通過互聯網連接起來的客戶端、WEB服務器、數據庫服務器組成。15 數據庫管理系統151 數據庫管理系統的功能（1） 數據定義功能：DBMS提供了數據定義語言（DDL），用戶利用DDL定義數據庫對象的三級模式結構，描述數據庫的結構特征。（2） 數據操縱功能：DBMS提供數據操縱語言（DML），用戶利用DML對數據進行查詢、插入、刪除或更新；（3） 數據庫運行管理和控制功能（4） 數據庫的建立和維護功能152 數據庫系統的全局結構（圖）1、 DBS可分為用戶、人機交互界面、DBMS和磁盤四個層次；2、 用戶可

14、分為四類：數據庫管理員DBA；專業用戶；應用程序員；終端用戶；3、 DBMS可分為兩部份：（1） 查詢處理器：面向用戶查詢請求；包括以下幾個功能模塊：DML編譯器、嵌入式DML的預編譯器、DDL編譯器、查詢執行引擎；（2） 存儲管理器：面向數據存儲訪問，包括以下幾個功能模塊：權限和完整性管理器、事務管理器、文件管理器、緩沖區管理器；4、 磁盤存儲的類型：（1） 以數據庫文件方式存儲的應用數據；（2） 數據字典；（3） 為提高查詢速度而設置的數據庫引擎；（4） DMS運行時的統計分析數據；（5） 日志信息。 16數據庫技術的發展和應用1、 第一代DBS：60年代末70年代初，層次型和網狀型DBS

15、；2、 第二代DBS：70年代后期，關系數據庫系統；3、 新型DBS：80年代，分布式數據庫系統；90年代，面向對象數據庫系統、網絡數據庫系統第二章 數據庫應用系統（DBAS）生命周期21數據庫應用系統生命周期211 軟件工程與軟件開發方法1、 軟件工程：指導計算機軟件開發和維護的工程科學，它采用工程化的概念、原理、技術和方法，以及正確的項目管理技術，來開發和維護軟件；它將系統化、規范化、定量化方法應用于軟件的開發、操作和維護，也就是將工程化應用于軟件生產；2、 軟件工程的目標：在給定成本、進度的前提下，開發出滿足用戶需求并具有下述特征的軟件產品：可修改性、有效性、可靠性、可理解性、可維護性、

16、可重用性、可適應性、可移植性、可追蹤性和可互操作性。3、 軟件生命周期：（以及開發周期）指軟件產品從考慮其概念開始，到該不再使用的整個時期（產品交付使用的整個時期），包括概念階段、需求階段、設計階段、實現階段、測試階段、安裝部署及交付階段；4、 軟件項目管理：為了能使軟件開發按預定的質量、進度和成本進行，而對成本、質量、進度、人員、風險等進行分析和有效管理的一系列活動。5、 軟件工程以關注軟件質量為特征，由方法、工具和過程三部分組成；6、 軟件過程模型（軟件開發模型）：是對軟件過程的一種抽象表示，表示了軟件過程的整體框架和軟件開發活動各階段間的關系，常見的有：瀑布模型、快速原形模型、增量模型和

17、螺旋模型。212 DBAS（面向某個特定領域，實現特定功能的計算機軟件、硬件的集成體）軟件組成1、 數據庫應用軟件在內部可看作由一系列軟件模塊/子系統組成，這些模塊/子系統可分成兩類：（1） 與數據訪問有關的數據庫事務模塊：利用DBMS提供的數據庫管理功能，以數據庫事務方式直接對數據庫中的各類應用數據進行操作，模塊粒度較??；（2） 與數據訪問無直接關聯的應用模塊：在許多與數據處理有關的應用系統中，對數據庫的訪問只是整體中的一部分，其他功能則與數據庫訪問無直接關系，這部分模塊粒度可以比較大。2、 DBAS設計開發的硬件方面：主要涉及根據系統的功能、性能、存儲等需求選擇和配置合適的計算機硬件平臺，

18、并與開發好的DBAS軟件系統進行集成，組成完整的數據庫應用系統；213 DBAS生命周期模型1、 數據庫應用系統的生命周期模型：（圖，p17）（1） 參照軟件開發瀑布模型的原理，DBAS的生命周期由項目規劃、需求分析、系統設計、實現和部署、運行管理與維護等5個基本活動組成；（2） 將快速原形模型和增量模型的開發思路引入DBAS生命周期模型，允許漸進、迭代地開發DBAS；（3） 根據DBAS的軟件組成和各自功能，細化DBAS需求分析和設計階段，引入了數據組織與存儲設計、數據訪問與處理設計、應用設計三條設計主線，分別用于設計DBAS中的數據庫、數據庫事務和應用程序；（4） 將DBAS設計階段細分為

19、概念設計、邏輯設計、物理設計三個步驟，每一步的設計內容又涵蓋了三條設計主線。22 規劃與分析（圖p18）221 系統規劃與定義1、 定義：系統規劃與分析是面向將要開發的DBAS，通過了解用戶實際需求，明確該系統需要實現的目標和任務，并從數據管理和數據處理的角度，確定系統中數據庫軟件的功能、性能范圍；2、 系統規劃與定義包括：（1） 任務陳述：描述所要開發的DBAS的總體目標；（2） 確定任務目標；（3） 確定系統范圍和邊界；（4） 確定用戶視圖；222 可行性分析1、 可行性分析包括以下四方面：（1） 經濟可行性：對項目進行成本效益分析；DBAS的成本主要包括：A、軟硬件購置費用；B、系統開發

20、費用；C、系統安裝、運行、維護費用。（2） 技術可行性：是根據用戶提出的系統功能、性能及實現系統的各項約束條件，對系統軟件、硬件、技術方案作出評估和選擇建議；A、 硬件可行性研究是分析DBAS的硬件平臺環境和設置；B、 軟件可行性研究包括：對可用的DBMS和操作系統的選型評估，對中間件和開發環境的選型建議，對DBAS開發模式和編程語言的建議；C、 技術方案的選擇是根據系統技術需求，提出DBAS可能采用的合理技術方案和關鍵技術；（3） 操作可行性：是論證是否具備DBAS開發所需的各類人員資源、軟件資源、硬件資源和工作環境等，以及為支持DBAS開發如何去改進加強這幾方面資源。（4） 開發方案選擇：

21、目的是提出并評價實現系統的各種開發方案，從中選出一種適用于DBAS軟件的開發方案；223 項目規劃1、 項目規劃是項目管理者對資源、成本和進度做出合理估算，并在此基礎上制定切實可行的DBAS項目開發計劃。2、 項目規劃包括以下內容：（1） 確定項目的目標和范圍；（2） 根據DBAS軟件開發模型，分解和定義整個項目包括的工作活動和任務；（3） 估算完成該項目的規模和所需各種資源；（4） 制定合理的DBAS項目計劃3、項目規劃的結果應形成數據庫應用系統項目計劃文檔，即項目計劃書。23 需求分析1、 數據庫應用系統需求是指用戶對DBAS在功能、性能、行為、設計約束等方面的期望和要求；2、 DBAS需

22、求分析是在已經明確的DBAS系統范圍基礎上，通過對應用問題的理解和分析，采用合適的工具和符號，系統地描述DBAS的功能特征、性能特征和約束，并形成需求規范說明文檔；3、 需求分析過程由需求獲取、需求分析、需求描述和規范說明、需求驗證等組成；4、 DBAS的需求分析包括：（1） 數據需求分析；（2） 數據處理需求分析；（3） 務需求分析；（4） 分析數據庫系統在性能、存儲、安全、備份與恢復等方面的要求；231 數據與數據處理需求分析（承上分別介紹）1、 數據需求分析：是從對數據組織與存儲的設計角度，辨識應用領域所管理的各類數據項和數據結構，與數據處理需求分析結果一起，組成數據字典；包括5個部分（

23、Def:是一種用戶可以訪問的記錄數據庫和應用程序元數據的目錄，它詳細描述系統中的全部數據）2、 數據處理需求分析：是從數據訪問和處理的角度，明確對各類數據項所需進行的數據訪問操作，分析結果可表示為數據流圖或事務規范；（DFD）3、 事務規范包括：（1）事務名稱；（2）事務描述；（3）事務所訪問的數據項；（4）事務用戶；232 業務規則需求分析1、業務規則需求分析：是從DBAS高層目標和整體功能出發，分析系統或系統中一些大粒度子系統應具有的業務類型和功能，明確用戶或外部系統與DBAS的交互模式；233 性能（能做到什么程度）需求分析1、 DBAS的性能指標：（1） 數據操作響應時間（或數據訪問響

24、應時間）：從提交請求到返回結果的時間；（2） 系統吞吐量：指系統在單位時間內所完成的事務或查詢的數量，單位為TPS；（TPC是指事務處理性能委員會）（3） 允許并發訪問的最大用戶數：在保證響應時間的前提下，系統最多允許多少用戶同時訪問數據庫；（4） 每TPS代價值，用于衡量系統性價比的指標2、 影響DBAS性能的因素：（1） 系統硬件資源；（2） 網絡通信設備性能；（3） 操作系統環境；（4） 數據庫的邏輯設計和物理設計質量，數據庫配置參數；（5） DBAS的配置和性能；（6） 數據庫應用程序自身。234 其它需求分析1、 存儲需求分析：是指估計DBAS系統需要的數據存儲量，包括：（1）初始數

25、據庫大??；（2）數據庫增長速度；存儲總量估算可采用：根據數據字典中每個數據項的結構描述信息，估計每個數據項的容量，將所有數據項的容量累加；2、 安全性需求分析：（1） DBAS系統應達到的安全控制級別；（2） 各類用戶的數據視圖和視圖訪問權限；（3） DBAS應有的口令保護機制或其它安全認證機制，用以控制用戶登錄數據庫系統。3、 備份和恢復需求分析：（1） DBAS運行過程中備份數據庫的時間和備份周期；（2） 所需備份的數據是全部數據庫數據，還是一部分；（3） 備份方式是采用完全備份還是采用差異備份。24 系統設計241 概念設計（DB概念模型設計和總體設計）1、 數據庫概念模型設計：是根據數

26、據需求分析階段得到的需求結果，分析辨識需要組織存儲在數據庫中的各類應用領域數據對象的特征及其相互之間關聯關系，并采用概念數據模型表示出來，得到獨立于具體DBMS的數據庫概念模型；2、 ER方法：（1）選擇局部應用；（2）分別設計各個局部ER圖；（3）局部ER圖合并；3、 系統總體設計：（1） 確定DBAS體系結構；（2） 系統硬件平臺和操作系統、數據庫管理系統等系統軟件的選型和配置；（3） 應用軟件結構設計（軟件程序概要設計）（4） 對需求分析階段識別出的業務規則進行初步設計，細化業務規則流程，明確采用的關鍵技術和算法；（5） 對系統采用的關鍵技術進行方案選型和初步設計。242 邏輯設計1、

27、數據庫邏輯結構設計：指從數據庫的概念模型出發，設計表示為邏輯模式的數據庫邏輯結構。（即從ER圖到關系模型）（1） ER圖轉換為初始關系模式；（2） 對初始關系模式進行優化；（3） 檢查關系表對數據庫事務的支持性；（4） 確定關系模式的完整性約束；（5） 從數據安全性和獨立性出發，設計用戶視圖。2、 應用程序概要設計（II）；（在上細化）3、 數據庫事務概要設計；243 物理設計1、 數據庫物理結構設計：主要指數據文件在外存上的存儲結構和存取方法，它依賴于系統具體的硬件環境、操作系統和DBMS；（1） 數據庫邏輯模式調整；（2） 選擇或配置基本關系表的文件組織形式；（3） 數據分布設計；（4）

28、安全模式設計；（5） 確定系統配置；（6） 物理模式評估；2、 數據庫事務（相當于VB的事件）詳細設計：根據事務流程，利用SQL語句、數據庫訪問接口，采用高級程序設計語言或DBMS提供的事務實現機制，設計數據庫事務。3、 應用程序詳細設計：25 實現與部署1、 建立數據庫結構；2、 數據加載；3、 事務和應用程序的編碼及測試；4、 系統集成、測試與試運行；5、 系統部署；26 運行管理與維護261 日常維護（1） 數據庫的備份與恢復（2） 完整性維護（3） 安全性維護（4） 存儲空間管理（5） 并發控制及死鎖處理262 系統性能監控和分析1、 統計數據可以通過兩種途徑收集：（1） 由DBMS本

29、身自動收集和存儲統計數據（2） 通過監控系統得到263 系統性能優化調整1、 糸統性能優化的手段有：數據查詢調整與優化、索引調整、數據庫摸式調整、DBMS和操作系統參數調整等。2、 模式調整主要涉及邏輯模式調整，可以從下考慮：（1） 已達到第三范式的基本表，不要進一步規范化為BCNF；（2） 在分布式數據庫中，對一個基本表中某些頻繁被訪問的數據，可以按水平分區或垂直分區方式拆分基本表。264 系統升級1、 改進應用桯序；2、 數據庫重組；3、 DBMS和OS版本升級第3章 需求分析及功能建模方法31 需求分析概述311 需求分析概念1、 所謂需求分折：就是對待開發的系統要做什么，完成什么功能的

30、全面描述。2、 需求分析的工作：通過對需求的調查、了解、觀察和分析，通過對原始數據的收集、分類和抽象，并采用有效的技術、工具，對原始資料進行加工整理，描述開發目標、實現的功能及其相互關系等活動的集合；3、 需求的定義：客戶對一個待開發的系統在實現目標、完成功能、應達到的性能、安全性、可靠性等方面的期望和要求的集合；4、 需求獲取的困難：（1） 軟件功能復雜；（2） 需求的可變性；5、 需求分析階段的主要任務：分析當前的業務流程，包括體系結構，各職能部門完成的主要任務、關系及其交流的信息。6、 需求分析的結果通常以模型等建模工具和方法描述系統的信息流、功能結構及完成各功能需要的數據。7、 功能模

31、型和軟件需求規格說明書是軟件開發的依據，將指導后續的開發工作。8、 需求分析工作是系統分析員與用戶不斷交互的過程中完成的。312 系統分析員的職能1、 系統分析員的主要要任務：是確定應用信息系統及軟件產品應該達到的各項功能性要求和非功能性要求，即用戶要做什么。2、 系統分析員應該具備的素質：（1） 獲取需求的能力；（2） 管理及溝通能力；（3） 技術素養；313 需求獲取的方法常用的幾種獲取需求的方法：（1）面談；（2）實地觀察；（3）問卷調查；（4）查閱資源；314 需求分析過程1、 標識問題：（1） 需求分析的第一步，通過對問題的識別和標識獲得所求解問題及其運行環境的理解；（2） 標識問題

32、從現行系統的業務流程做起，理解現行系統的業務流程；（3） 在標識理解需求的同時，還要注意確定系統的人機界面；2、建立需求模型：（1） 模型是對現實原形所作的一種抽象，其本質是只關心與研究內容有關的因素，而忽略無關的因素，其目的是把復雜的事物變得簡單，便于認識和分析；（2） 目前常用的模型方法主要有DFD數據流圖和IDEFO，都屬于結構化分析方法，其特征是抽象和分解；（3） 首先對應用領域進行全面的分析，發現并找出同類事物的本質，用抽象方法把這類事物的非主要方面剔除，把握住事物的內部規律或本質，就可以找到解決辦法；然后采用自上而下逐步求精的方法對復雜的問題進行分解；（4） 結構化分析及建模方法的

33、主要優點：（A） 不過早陷入具體的細節；（B） 從整體或宏觀入手分析問題；（C） 通過圖形化的模型對象直觀地表示系統要做什么，完成什么功能；（D） 圖形化建模方法方便系統分析員理解和描述系統；（E） 模型對象不涉及太多的技術術語，便于用戶理解；3、描述需求：（1） 需求描述的目標：對軟件項目功能性和非功能性的需求全面描述；（2） 功能性需求：指需要計算機實際解決的問題或實現的具體功能，明確描述系統必須做什么，實現什么功能以及輸入輸出等；（3） 非功能性需求：軟件項目對實際運行環境的要求；（4） 需求描述主要由需求模型和需求說明書組成，說明書側重文字說明，內容如下：需求概述；功能需求；信息需求；

34、性能需求；環境需求；其他需求；（5） 在對需求進行分析過程中，系統分析員要經?？紤]的問題：（A） 描述的需求是完全的嗎？（B） 需求描述是正確的和一致的嗎？（C） 描述的這些需求是可行的、實際可操作的嗎？（D） 描述中的每一條需求都是客戶需要的嗎？4、確認需求：1、 評審委員會審核下列內容：功能需求；數據需求；性能；數據管理；其他需求。32 DFD建模方法321 DFD方法的基本對象1、 數據流：具有名字且有流向的數據，用標有名字的箭頭表示。2、 處理：表示對數據的加工和變換，在圖中用矩形框表示。3、 數據存儲：表示用數據庫形式存儲的數據，對其存取分別以指向或離開數據存儲的箭頭表示；4、 數據

35、源及數據終點：表示當前系統的數據來源和去向，其圖形符號以平行四邊形表示。322 開發DFD圖1、 DFD圖采用自頂而下逐步細化的結構化分析方法表示目標系統；2、 DFD方法應以軟件項目的功能為中心進行抽象和分解，以數據流的變換來分析數據對企業中各類業務活動的影響；323 建模案例（p43）；324 數據字典1、 數據字典包括以下說明信息：（1） 源點及終點詞條描述；（2） 數據流詞條描述；（3） 數據存儲；（4） 處理描述；（5） 數據元素詞條描述。33 IDEF0建模方法331 概述1、 IDEF0的基本思想是結構化分析方法，強調自頂而下有控制地逐步地展開細節，全面地描述系統，且通過建模來理

36、解一個系統。一個模型由圖形文字說明、詞匯表及相互的交叉引用表組成。2、 IDEF方法的優點：具有模型元素單一、語義豐富、更易于從全局角度分析考察問題，模型容易理解。332 IDEF0方法1、基本元素（1） 矩形：代表活動，活動名稱標在矩形內，活動編號按要求標在矩形框右下角指定位置；（2） 箭頭：左邊的輸入箭頭代表完成活動需要的數據、上方的控制箭頭描述了影響活動的執行的事件或約束、右邊的輸出箭頭說明由活動產生的結果及信息、下方進入的機制箭頭表示實施該活動的物理手段或資源。（3） 輸入輸出箭頭描述活動是什么（what）、控制箭頭描述為何這么做（why）、機制箭頭表示如何做（how）。2、IDEF0

37、模（1） 一個IDEF0模型由一組圖形組成，這些圖形組成一個由父到子的層次結構圖，這組圖形把一個復雜事物按自頂向下逐步細化的方式分解成一個個簡單的或多個組成部分；3、 建模規則（1） 矩形框：用動詞為矩形內活動命名，每個矩形要至少有一個控制箭頭和輸出箭頭，可以沒有輸入，但不可以同時沒有輸入和控制。（2） 箭頭：箭頭代表數據約束，而不是代表流或順序；（3） 其他：（A） ICOM碼：只有一端與矩形相連的箭頭叫邊界箭頭，這些箭頭表示父矩形框的輸入、控制和輸出。IDEF0用專門的記號ICOM碼來說明父子圖中的箭頭關系。子圖中每個邊界箭頭的開端分別用字母I、C、O、M來標明是輸入、控制、輸出及機制，再

38、用一個數字表示其在父矩形框中箭頭的相對位置。（B） 結點號：IDEF0模型是一組有一定層次結構的圖形，通常用結點號來標志圖形或矩形框在層次圖中的位置；（C） 模型名：每個模型有一個名字，通常用名字代表主題，用子名字表示不同的模型?；久峙c子名字間用“/”隔開，如A/B/C，A是主題、B是模型號、C是結點號。333 建模過程及步驟1、 IDEF0建模過程及步驟：（1） 明確目的，確定范圍：在建模前首先要明確目的和意圖，確定問題域；（2） 建立內外關系圖A-0圖：根據系統目標、功能建立內外關系圖A-0圖，以確定整個模型的內外關系，確定系統的邊界；（3） 構造頂層圖：把A-0圖分解成36個主要部分

39、得到A0圖，A0圖是模型真正的頂層圖；（4） 開發IDEF0層次結構圖：對A0圖中的每個矩形框進行分解，就形成了基本的圖形層次結構。在分解時要列出所有的數據項和活動表，分解的次序采用以下原則：（A） 保持在同一水平上進行分解，均勻的模型深度；（B） 按困難程序進行選擇；（5） 寫文字說明；（6） 檢查確認圖形；34 DFD與IDEF0的比較1、 DFD與IDEF0共同點：都是結構化分析思想，強調自頂而下逐步求精的方法對現實世界建模，先抓住主要的問題，形成較高層次的抽象，再由粗到細、由表及里地逐步細化，將一個大問題分解成幾個小問題，對這小問題再進行分析求解；2、 DFD與IDEF0區別：（1）

40、DFD圖用箭頭（數據流）來描述數據移動的方向、數據處理及處理之間的數據依賴關系。IDEF0圖也用箭頭代表數據流，但在IDEF0中不是強調流或順序，而是強調數據約束。（2） 從表達形式上看，DFD圖與IDEF0圖都是用箭頭和處理表達一個企業或組織的業務流程。但IDEF0圖的箭頭不僅能夠表示數據流，還可以表示控制流和說明處理或實施方式的一些約束；（3） 從模型元素的組成上來看，DFD模型由4種元素組成，即外部頂、數據流、數據存儲和處理。而IDEF0模型元素的組成更加簡單，只有2種元素組成，即箭頭和活動；（4） 從模型規范上來講，IDEFO方法更加規范；（5） IDEF0模型結構清楚，便于理解和溝通

41、。第四章 數據庫概念設計及數據建模41 數據庫概念設計概述411 數據庫概念設計的任務1、 定義和描述應用領域涉及的數據范圍；2、 獲取應用領域或問題域的信息模型；3、 描述清楚數據的屬性特征；4、 描述清楚數據之間的關系；5、 定義和描述數據的約束；6、 說明數據的安全性要求；7、 支持用戶的各種數據處理需求；8、 保證信息模型方便地轉換成數據庫的邏輯結構，同時便于用戶理解。412 概念設計過程1、 概念設計的依據：是需求分析階段的文檔，通過對這些文檔的分析理解，構造出信息模型，編寫數據庫概念設計說明書，信息模型和數據庫概念設計說明書是數據庫邏輯設計的依據；2、 概念設計的基本步驟：（1）

42、確定實體集；（2） 確定聯系和聯系類型；（3） 建立由信息模型表示的企業模型；（4） 確定實體集屬性；（5） 對信息模型優化。 3、 概念設計的方法（自頂向下、自底向上、逐步擴張、混合策略）42 數據建模方法1、 數據建模方法的共同特點是：（1） 能夠真實客觀地描述現實世界中的數據及數據之間的關系；（2） 組成模型的概念少，語義清楚，容易理解；（3） 不同概念的語義不重疊，概念無多義性；（4） 用圖形方式描述數據，數據直觀易懂，有利于數據庫設計者和用戶交流；（5） 這種數據模型容易轉換成數據庫邏輯設計階段需要的數據結構。43 ER建模方法431 基本概念1、 實體或實例：指客觀存在并可相互區分

43、的事物，可以是一個具體的人或物，也可以是抽象的事件或概念；2、 實體集：表示一個現實的和抽象事物的集合，這些事物必須具有相同的屬性或特征。3、 屬性：用于描述一個實體集的性質和特征；4、 碼：實體集中能惟一標識每一個實例的屬性或屬性組；（以及域）5、 聯系：描述現實世界中實體之間的關系。（1）一對一聯系；（2）一對多聯系；（3）多對多聯系432 ER方法語法1、 ER方法中用矩形框表示實體集，矩形框內寫上實體集的名稱；2、 ER模型用菱形表示聯系，聯系名寫在菱形框內；3、 ER模型中實體集的屬性用橢圓或圓角矩形框表示，屬性名字寫在其中。補充：1、ER建模步驟：局部（以數據字典為依據，自底而上）

44、（確定范圍，識別實體、確定關系、定義屬性）到全局。 2、全局（合并和重構）合并：消除沖突（屬性，命名，結構）；沖突：消除冗余。44 IDEF1X 建模方法441 IDEF1X概述1、 IDEF0側重描述系統功能，被稱為功能建模方法；IDEF1X側重分析、抽象和概括應用領域中的數據，稱為數據建模方法；2、 IDEF1X方法具有豐富的語法和語義；3、 實體集分為（1）獨立標識符實體集；（2）從屬標識符實體集；4、 實體集之間的聯系分為：（1）標定型聯系；（2）非標定型聯系；（3）分類聯系；（4）不確定聯系442 IDEF1X模型元素1、 實體集：（1） 實體集語義：如果一個實體集的每一個實例都能被

45、惟一地標識，而不決定于它與其他實體的聯系，那么該實體集稱為獨立實體集；（存在鍵區）否則就叫從屬實體集；（2） 實體集語法：IDEF1X用矩形框來表示獨立實體集，用圓角矩形框來表示從屬實體集；2、 聯系：（1） 聯系語義：（A） 標定型聯系：一個“確定型聯系”（一對多）中，如果子女實體集中的每個實例都是由它與雙親的聯系而確定的，這個關系稱為“標定型聯系”（在子實體中做外鍵時，在鍵區，反之成立）；（B） 非標定型聯系：一個“確定型聯系”中，如果子女實體集中的每一個實例都能被惟一地確認而無需了解與之相聯系的雙親實體集的實例，這個問題關系叫“非標定型聯系”。（C） 分類聯系：是兩個或多個實體集之間的聯

46、系，且在這些實體集中存在一個一般實體集，它的每一個實例都恰好與一個且僅一個分類實體集的一個實例相聯系。（D） 不確定聯系：一個非確定聯系又稱為多對多聯系，這種聯系關聯的兩個實體集之間，任一實體集的一個實例都將對應另一實體集的0個、1個或多個實例。（2） 聯系的語法：（A） 標定聯系語法：在IDEF1X圖中，聯系的語法用直線表示，在一個標定型聯系中，子女實體集總是一個從屬實體集，用圓角矩形框表示；（B） 非標定聯系語法：如果兩個實體集之間有關系，并且是一個非標定聯系，就用一條虛線把它們連接起來。（C） 分類聯系語法：一般實體集的一個實例只能與分類實體集的一個實例相對應；（D） 不確定聯系m:n的

47、語法：不確定聯系用一個兩端帶有實心圓的線段描述，表示多對多的連接關系。3、 屬性（1） 屬性的語義：用來描述一類現實或抽象事物的特征或性質。一個屬性的具體取值叫屬性實例，它由屬性的類型和值來定義。（2） 屬性的語法（A） 主碼和非主碼屬性語法：在一個實體集中屬性要有惟一的名字，屬性名由名詞表示，主碼屬性名后加（PK）標注，被列在屬性列表的頂端，并用水平線將主碼和其他屬性分開。（B） 外碼語法：在外碼屬性后加“FK”來識別由聯系繼承得到的外來屬性。443 建模過程1、第一階段：建模規劃及準備（1） 建模目標：（A） 目標說明：回答將構造的模型完成什么功能，涉及的問題和數據范圍，同時說明是一個當前

48、系統模型還是待建模型。（B） 范圍說明：在建模初期要給出模型覆蓋的問題范圍；（2） 建模計劃（A） 項目說明；（B） 收集數據；（C） 定義實體；（D） 定義聯系；（E） 定義碼屬性；（F） 定義非碼屬性；（G） 確認模型；（H） 評審驗收。（3） 組織隊伍：包括項目負責人、建模者、信息源、課題專家、評審委員會2、 第二階段：定義實體集（1） 目標是標識和定義應用領域中的實體集，方法是分類標識原始材料中的所有名詞；（2） 區別實體集名詞和非實體集名詞的方法，是否具有下列特征：（A） 它能夠被描述或說明嗎？（B） 有多少同類的實例嗎？（C） 每個實例可以被標識和區分嗎？3、 第三階段：定義聯系（

49、1） 標識實體集之間的聯系：建立聯系矩陣，聯系矩陣由一個二維數組表示。把實體集沿水平和垂直兩方向列出，分析兩個實體間的聯系，有聯系就用“X”表示，不存在聯系用“null”表示。聯系只標識直接關系，不標識間接關系。（2） 定義聯系：包括表示依賴、命名聯系、關于聯系的說明；當實體集之間的依賴關系建立后，就可以命名聯系了。聯系的名字可以動詞表示。原則必須是具體的、簡明的和有意義的。（3） 構造實體級數：實體級圖的范圍和數目,依賴于建模的規模和建模問題涉及的實體集數目。4、 第四階段：定義?。?） 分解不確定的聯系：把實體級圖中不確定的關系轉換成確定的連接形式，把每一個不確定的聯系轉換成為兩個確定的聯

50、系；（2） 標識碼屬性：碼屬性是那些能夠惟一識別實體集中每一個實例的屬性；（3） 遷移主碼：把一個實體集的主碼復制到其他有關實體集的過程，但要遵守以下規則：（A） 在一個聯系中，遷移總是從父到子或從一般實體集移向分類實體集；（B） 主碼屬性才能被遷移，如主碼由多個屬性組成，則要全部遷移；5、 第五階段：定義屬性（1） 標識和定義非主屬性；（2） 建立屬性的所有者；（3） 確認屬性的定義；（4） 繪制局部數據視圖；（A） 實體集的名稱和編號寫在矩形框外的上面；（B） 主碼屬性寫在矩形框內水平線的上面并用“PK”標注；（C） 外碼屬性寫在矩形框內水平線的下面并用“FK”標注；（D） 非主屬性也可以

51、寫在矩形框內水平線的下面；第五章 關系數據庫邏輯設計51 概述52 基本概念521 關系模型1、 關系模型采用一個二維表格在計算機中組織、存儲、處理和管理數據。（1） 關系名（數據庫名）：由字母數字組成；（2） 屬性名；（3） 關系模式和關系：描述模式描述關系的靜態結構，由模式名、關系模式所包含的屬性及屬性值所滿足的條件組成模式定義。（4） 元組：描述關系中的行；（5） 域：它定義關系的每個屬性取值的類型；（6） 主碼：能夠惟一標識關系中每一個元組的屬性或屬性組；（7） 關系的數學定義：關系模式是建立在集合集論的基礎上的，用數學的概念定義關系有；（A） 定義一：域是值的集合，同一個域中的值具有

52、相同的數據類型；（B） 定義二：笛卡爾積的定義（相當于一張二維表）（C） 定義三：關系的定義（笛卡爾積的子集（二維表），域的順序不能改）（D） 當關系引用了屬性名后關系具有以下屬性：1 不能有重復的元組；2 元組上下無序；3 按屬性名引用時屬性左右無序；4 所有屬性值都是原子項（不可再分）；（8） 總結：關系是一張二維表，表中的一行被稱為一個元組，一列稱為屬性，由一組域值組成。關系是元組的集合，關系中的每個元組在數學上被定義為這個關系所涉及的全部域值中笛卡兒積的一個元素。522 關系數據庫1、 關系數據庫是按照二維表組織和存儲的相互關聯的關系的集合，關系數據庫模式是關系模式的集合；523 關系

53、的完整性1、 關系的完整性（完整性約束）：是對關系的某種約束規則和關系滿足的定義。通常這組約束規則用來限定和檢查數據庫所含實例的合法性和正確性；2、 完整性約束分靜態和動態兩種，靜態完整性（相當于邏輯的，真理的）約束是基于關系模式的，主要有主碼、外碼約束和域約束組成；動態完整性約束（基于現實）是基于企業的業務規則的。3、 靜態完整性約束規則：（1） 主碼約束：主碼必須滿足：（A） 惟一性：在一個關系中不存在兩個元組，它們具有相同的主碼值；（B） 最小性：不存在從組成主碼的屬性集中去掉一個屬性，還仍能保持數據的惟一性；候選碼：符合主碼條件，但沒有被選為主碼。（2） 外碼約束：（外碼的定義：有兩個

54、關系R和S，X是R得屬性組，非碼；是S的碼，則稱X是R得外碼）外碼為空或碼的值（否者查找失?。?） 用戶定義的完整性：（性別只為男和女）53 關系數據庫設計理論531 問題的提出究竟一個關系數據庫包含哪些屬性是合理的，如何評價一個關系模式設計的優劣？（插入、更新、刪除異常）補充（關系代數）1、 傳統的集合運算。（并、交、差、笛卡爾積）；2、 專門的關系運算。（選擇、投影、連接、自然連接、除法）532 函數依賴函數依理論利用一個關系中屬性之間的依賴關系評價和優化關系模式，以保證存儲到數據庫中的關系具有較好特性；1、 函數依賴：（1） 設R（U）為一關系模式，X和Y為屬性全集U的子集，若對于R（

55、U）的任意一個可能的關系r，r中不可能存在兩個元組在X上的屬性值相等，而在Y上的屬性值不等，則稱“X函數決定Y”或“Y函數依賴于X”，并記作XY，其中X稱為決定因素，因為根據函數依賴定義，給定一個X，就能惟一決定一個Y。（翻譯：只要X上的屬性值相等，則Y上的屬性只就相等）（2） 這里討論的函數關系與數學上的不同，是不能計算的，是一個關系中屬性之間存在的依賴關系；它是一種語義范疇的概念，只能根據兩個屬性之間的語義來確定一個函數依賴是否存在。2、 完全（f）與部分函數（p）依賴：（1） 在關系模式R（U）中，如果XàY成立，并且對X的任何真子集X不能函數決定Y，則稱Y對X是完全函數依賴，

56、被記作X-f-àY。（2） 若XàY，但Y不完全函數依賴于X，則稱Y對X是部分函數依賴，記作X-pàY（即至少存在一個真子集X函數決定Y）；3、 傳遞函數依賴：在關系R（U）模式中，如果X決定Y，（Y不屬于X），Y不決定X，Y決定Z，則稱Z對X傳遞函數依賴。4、 平凡與非平凡函數依賴：（1） 若X決定Y，但Y屬于X，則稱XàY是平凡函數依賴，否則稱非平凡函數依賴；（2） 即平凡函數依賴，僅當其右邊的屬性集是左邊屬性集的子集時成立；（全屬于）（3） 非平凡函數依賴，僅當其右邊的屬性集至少有一個屬性不屬于左邊有集合時成立；（部分）（4） 完全非平凡函數依賴：僅當其右邊的屬性集中屬性都不在左邊的集合時成立；（都不屬于）5、 碼：（1） 在關系模式R（U）中，K為R的屬性或屬性組，若K完全函數決定A1.A2.An，則K為關系模式R的候選碼（應理解為一個屬性組），包含在候選碼中的屬性稱為主屬性，否則為非主屬性；（2） 若一個關系的候選碼不止一個，則選定其中一個作為關系R的主碼；（3） 關系的