《全國計算機等級考試四級教程—數據庫工程師》第一章引論數據庫技術產生于20世紀60年代，是信息系統的核心技術和重要基礎；計算機科學與技術學科劃分為四個專業方向：計算機科學（CS）；計算機工程（CE）；軟件工程（SE）；信息技術（IT）。1．1基本概念1．1．1信息與數據信息、物質、能量是組成客觀世界并促進社會發展的三大基本要素；信息（Information）--是客觀世界事物的存在方式和運動狀態的反映，是對事物之間相互聯系、相互作用的描述。信息具有可感知、可存儲、可加工、可傳遞和可再生的自然屬性。數據（Data）--是描述現實世界事物的符號記錄，是用物理符號記錄下來的可以識別的信息。不同的物理符號體現出數據的不同表現形式。信息與數據間存在固有聯系，數據是信息的符號表示，或稱為載體。信息則是數據的語義解釋，是數據的內涵，信息以數據的形式表現出來，并為人們理解和接受。數據處理（DataProcessing）--是指對數據進行分類、收集、組織、存儲，進而從已數據出發，抽取或推導出新的數據，這些數據表示了新的信息。數據管理（DataManagement）--是指對數據的分類、收集、組織、編碼、存儲、檢索和維護，是數據處理業務的重要環節。數據處理與數據管理的區別在于，數據處理除了具有數據管理功能外，還可通過數據管理得到的數據進一步深加工，從中獲取新的數據和信息。1．1．2數據庫系統數據庫（DB，DataBase）--是長期存儲在計算機內有組織的、大量的、共享的數據集合；數據庫管理系統（DBMS，DatabaseManagementSystem）--是指在計算機系統中，位于用戶與操作系統之間的數據管理系統軟件，是數據庫系統的核心。數據庫系統（DBS，DataBaseSystem）--是指在計算機系統中引入數據庫后的軟硬件系統構成，DBS一般分成三個層次：（1）計算機硬件平臺；（2）系統軟件和應用軟件；（3）用戶；在不引起混淆和歧義的情況下，數據庫系統簡稱為數據庫。（狹義的）數據庫系統—是由數據庫和數據庫管理系統組成的軟件系統，主要為用戶提供數據存儲和查詢、插入、修改、刪除、更新等數據管理功能。（狹義的）數據庫應用系統（DBAS，DataBaseApplicationSystem）—是由數據庫、數據庫管理系統、數據庫應用程序組成的軟件系統，它面向具體應用領域，提供了更為復雜的數據處理功能。數據庫技術—是研究數據庫的結構、存儲、設計、管理和使用的一門計算機應用學科。數據庫技術與其它計算機科學有密切關系：數據庫技術以文件系統為基礎發展而來，DBMS需要操作系統的支持，數據庫以文件形式存儲在外部存儲上的；數據庫與數據結構的關系很密切，數據庫技術不僅用到數據結構中的鏈表、樹、圖等知識，各種數據模型本身就屬于復雜數據結構；主流的關系數據庫系統，其理論基礎是關系數據模型，而該模型是在離散數學集合論中“關系”這一基本概念上發展起來的；當用戶訪問數據庫，DBMS對用戶提交的查詢操作類似于，計算機編譯系統對程序的編譯過程；開發一些大型的DBS或DBMS的過程，要遵循軟件工程的開發模式。1．2數據模型1．2．1數據模型概念1、數據模型（DataModel）--是數據庫系統的形式框架，是用來描述數據的一組概念和定義，包括描述數據、數據聯系、數據操作、數據語義以及數據一致性的概念工具；2、數據模型應滿足：（1）能夠比較真實地模擬現實世界；（2）容易為人們所理解；（3）便于在計算機上實現。數據模型的組成：數據結構：用于描述系統的靜態特征，從語法角度表述了客觀世界中數據對象本身的結構和數據對象之間的關聯關系，是刻畫一個數據模型性質最重要的方面。在數據庫系統中，通常按照數據結構的類型來區分、命名各種數模，如層次、網狀、關系數模。數據操作：用于描述系統的動態特征，是一組對數據庫中各種數據對象允許執行的操作和操作規則組成的集合。數據操作可以是檢索、插入等，數模必須定義這些操作的確切含義、操作符號、操作規則以及實現操作的數據庫語言。數據完整性約束：是一組完整性規則的集合，它定義了數模必須遵守的語義約束，也規定了數據庫中數據內部及數據之間聯系所必須滿足的語義約束。它限定了數據庫的狀態以及狀態的變化，以便維護數據的正確性、有效性。1．2．2數據模型分類用數據模型這一概念來描述數據庫的結構和語義，通過現實世界—信息世界—機器世界的抽象轉換過程構建數據庫，并根據模型所定義的規范去管理和使用數據。建模過程：（1）將現實世界的數據對象抽象為信息世界中的某一信息結構；（2）再將信息結構轉換為機器世界中某一具體DBMS支持的數據模型，并存儲于計算機中。數據模型分類：概念數據模型（概念模型）：按用戶的觀點對數據和信息進行建模，是現實世界到信息世界的第一層抽象，強調其語義表達功能，易于用戶理解，是用戶與設計人員交流的語言，主要用于數據庫設計。最常用的是實體—聯系模型。數據結構模型（表示型/實現型）：是機器世界中與具體DBMS相關的數據模型，包括關系模型、網狀模型和層次模型物理數據模型：屬底層數據模型，描述數據的實際存儲方式。1．3數據視圖與模式結構1．3．1數據視圖與數據抽象數據視圖：指從某個角度看到的客觀世界數據對象的特征，是對數據對象某一方面特征的描述。數據抽象：是一種數據描述和數據庫設計原則，是指專注于數據對象的某方面特征，而忽略其他特征。集和值：集是指對某一類數據的結構和屬性的說明，值是集的一個具體賦值；數據模式：對數據庫中數據某方面結構和特征的描述，它僅涉及集的描述，不涉及具體的值。1．3．2三級模式結構數據庫三級模式結構—外部級、概念級和內部級，分別定義了外模式、模式和內模式，用于從不同角度描述數據庫結構。模式：也稱邏輯模式、概念模式；對數據庫中全體數據的邏輯結構和特征的描述，是所有用戶的公共數據視圖；模式不僅定義了數據的邏輯結構，還定義了數據之間的聯系、與數據的關的安全性和完整性要求；一個數據庫只有一個模式，建立在某種數據結構模型基礎上。外模式：也稱子模式、用戶模式、用戶視圖；是對數據庫用戶能夠看見和使用的局部數據的邏輯結構和特征的描述。一個數據庫可以有多個外模式，每個外模式描述了某個特定用戶所使用的局部數據的邏輯結構和特征，是與某一應用有關的數據的邏輯表示。外模式還是保證數據安全的有力措施，每個用戶只能看見和訪問所對應的外模式中的數據，其它數據對他是不可見的。內模式：也稱物理模式、存儲模式；是對數據庫中數據的物理結構和存儲方式的描述，代表了數據在數據庫內部的表示方式和物理組織結構；1．3．3二級映象與數據獨立性外模式/模式映象：定義了數據庫中不同用戶的外模式與數據庫邏輯模式之間的對應關系；可有多個外模式/模式映象，對于每個外模式，需要一個外模式/模式映象來定義該外模式與模式之間的對應關系；當模式發生變化時，只需調整外模式/模式間的映象關系，而外模式無需修改，保證了數據與應用程序的邏輯獨立性，稱為數據的邏輯獨立性。模式/內模式映象：定義了數據庫中數據全局邏輯結構，與這些數據在系統中的物理存儲組織結構之間的對應關系。模式/內模式映象是唯一的；當內模式發生變化時，只需調整模式/內模式映象關系，而模式無需修改，保證了數據庫中的數據與應用程序間的物理獨立性，稱為數據的物理獨立性。1．4數據庫系統體系結構數據庫系統體系結構：是指數據庫系統的組成構件、各構件的功能及各構件間的協同工作方式；分類：集中式：全部數據和數據管理功能均集中在一臺計算機上的數據庫系統；包括單用戶和主從式兩種，單用戶DBS是指系統由一個用戶獨占，不同機器間不能共享數據；主從式DBS是指一個主機帶多個分時多用戶的DBS；分布式：數據庫中的數據在邏輯上是一個整體，但在物理上卻可以分布在網絡中不同數據管理節點上；客戶/服務器：將DBMS和數據庫應用分開，網絡中某些節點上的計算機專門執行DBMS功能，負責數據管理服務，稱為數據庫服務器；其他節點的計算機上安裝DBMS的外圍應用開發工具，支持用戶的應用，主要負責數據表示服務，稱為客戶端；并行式：硬件平臺是并行計算機系統，使用多個CPU和多個磁盤進行并行數據處理和磁盤訪問操作，以提高執行速度；WEB式：由通過互聯網連接起來的客戶端、WEB服務器、數據庫服務器組成。1．5數據庫管理系統1．5．1數據庫管理系統的功能數據定義功能：DBMS提供了數據定義語言（DDL），用戶利用DDL定義數據庫對象的三級模式結構，描述數據庫的結構特征。數據操縱功能：DBMS提供數據操縱語言（DML），用戶利用DML對數據進行查詢、插入、刪除或更新；數據庫運行管理和控制功能數據庫的建立和維護功能1．5．2數據庫系統的全局結構DBS可分為用戶、人機交互界面、DBMS和磁盤四個層次；用戶可分為四類：數據庫管理員DBA；專業用戶；應用程序員；終端用戶；DBMS可分為兩部份：查詢處理器：面向用戶查詢請求；包括以下幾個功能模塊：DML編譯器、嵌入式DML的預編譯器、DDL編譯器、查詢執行引擎；存儲管理器：面向數據存儲訪問，包括以下幾個功能模塊：權限和完整性管理器、事務管理器、文件管理器、緩沖區管理器；磁盤存儲的類型：以數據庫文件方式存儲的應用數據；數據字典；為提高查詢速度而設置的數據庫引擎；DMS運行時的統計分析數據；日志信息。1．6數據庫技術的發展和應用第一代DBS：60年代末70年代初，層次型和網狀型DBS；第二代DBS：70年代后期，關系數據庫系統；新型DBS：80年代，分布式數據庫系統；90年代，面向對象數據庫系統、網絡數據庫系統第二章數據庫應用系統生命周期2．1數據庫應用系統生命周期2．1．1軟件工程與軟件開發方法軟件工程：指導計算機軟件開發和維護的工程科學，它采用工程化的概念、原理、技術和方法，以及正確的項目管理技術，來開發和維護軟件；它將系統化、規范化、定量化方法應用于軟件的開發、操作和維護，也就是將工程化應用于軟件生產；軟件工程的目標：在給定成本、進度的前提下，開發出滿足用戶需求并具有下述特征的軟件產品：可修改性、有效性、可靠性、可理解性、可維護性、可重用性、可適應性、可移植性、可追蹤性和可互操作性。軟件生命周期：指軟件產品從考慮其概念開始，到該產品交付使用的整個時期，包括概念階段、需求階段、設計階段、實現階段、測試階段、安裝部署及交付階段；軟件項目管理：為了能使軟件開發按預定的質量、進度和成本進行，而對成本、質量、進度、人員、風險等進行分析和有效管理的一系列活動。軟件工程以關注軟件質量為特征，由方法、工具和過程三部分組成；軟件過程模型（軟件開發模型）：是對軟件過程的一種抽象表示，表示了軟件過程的整體框架和軟件開發活動各階段間的關系，常見的有：瀑布模型、快速原形模型、增量模型和螺旋模型。2．1．2DBAS軟件組成數據庫應用軟件在內部可看作由一系列軟件模塊/子系統組成，這些模塊/子系統可分成兩類：與數據訪問有關的數據庫事務模塊：利用DBMS提供的數據庫管理功能，以數據庫事務方式直接對數據庫中的各類應用數據進行操作，模塊粒度較??；與數據訪問無直接關聯的應用模塊：在許多與數據處理有關的應用系統中，對數據庫的訪問只是整體中的一部分，其他功能則與數據庫訪問無直接關系，這部分模塊粒度可以比較大。DBAS設計開發的硬件方面：主要涉及根據系統的功能、性能、存儲等需求選擇和配置合適的計算機硬件平臺，并與開發好的DBAS軟件系統進行集成，組成完整的數據庫應用系統；2．1．3DBAS生命周期模型數據庫應用系統的生命周期模型：參照軟件開發瀑布模型的原理，DBAS的生命周期由項目規劃、需求分析、系統設計、實現和部署、運行管理與維護等5個基本活動組成；將快速原形模型和增量模型的開發思路引入DBAS生命周期模型，允許漸進、迭代地開發DBAS；根據DBAS的軟件組成和各自功能，細化DBAS需求分析和設計階段，引入了數據組織與存儲設計、數據訪問與處理設計、應用設計三條設計主線，分別用于設計DBAS中的數據庫、數據庫事務和應用程序；將DBAS設計階段細分為概念設計、邏輯設計、物理設計三個步驟，每一步的設計內容又涵蓋了三條設計主線。2．2規劃與分析2．2．1系統規劃與定義定義：系統規劃與分析是面向將要開發的DBAS，通過了解用戶實際需求，明確該系統需要實現的目標和任務，并從數據管理和數據處理的角度，確定系統中數據庫軟件的功能、性能范圍；系統規劃與定義包括：任務陳述：描述所要開發的DBAS的總體目標；確定任務目標；確定系統范圍和邊界；確定用戶視圖；2．2．2可行性分析可行性分析包括以下四方面：經濟可行性：對項目進行成本效益分析；DBAS的成本主要包括：A、軟硬件購置費用；B、系統開發費用；C、系統安裝、運行、維護費用。技術可行性：是根據用戶提出的系統功能、性能及實現系統的各項約束條件，對系統軟件、硬件、技術方案作出評估和選擇建議；硬件可行性研究是分析DBAS的硬件平臺環境和設置；軟件可行性研究包括：對可用的DBMS和操作系統的選型評估，對中間件和開發環境的選型建議，對DBAS開發模式和編程語言的建議；技術方案的選擇是根據系統技術需求，提出DBAS可能采用的合理技術方案和關鍵技術；操作可行性：是論證是否具備DBAS開發所需的各類人員資源、軟件資源、硬件資源和工作環境等，以及為支持DBAS開發如何去改進加強這幾方面資源。開發方案選擇：目的是提出并評價實現系統的各種開發方案，從中選出一種適用于DBAS軟件的開發方案；2．2．3項目規劃項目規劃是項目管理者對資源、成本和進度做出合理估算，并在此基礎上制定切實可行的DBAS項目開發計劃。項目規劃包括以下內容：確定項目的目標和范圍；根據DBAS軟件開發模型，分解和定義整個項目包括的工作活動和任務；估算完成該項目的規模和所需各種資源；制定合理的DBAS項目計劃3、項目規劃的結果應形成數據庫應用系統項目計劃文檔，即項目計劃書。2．3需求分析數據庫應用系統需求是指用戶對DBAS在功能、性能、行為、設計約束等方面的期望和要求；DBAS需求分析是在已經明確的DBAS系統范圍基礎上，通過對應用問題的理解和分析，采用合適的工具和符號，系統地描述DBAS的功能特征、性能特征和約束，并形成需求規范說明文檔；需求分析過程由需求獲取、需求分析、需求描述和規范說明、需求驗證等組成；DBAS的需求分析包括：數據需求分析；數據處理需求分析；業務需求分析；分析數據庫系統在性能、存儲、安全、備份與恢復等方面的要求；2．3．1數據與數據處理需求分析數據需求分析：是從對數據組織與存儲的設計角度，辨識應用領域所管理的各類數據項和數據結構，與數據處理需求分析結果一起，組成數據字典；數據處理需求分析：是從數據訪問和處理的角度，明確對各類數據項所需進行的數據訪問操作，分析結果可表示為數據流圖或事務規范；事務規范包括：（1）事務名稱；（2）事務描述；（3）事務所訪問的數據項；（4）事務用戶；2．3．2業務規則需求分析1、業務規則需求分析：是從DBAS高層目標和整體功能出發，分析系統或系統中一些大粒度子系統應具有的業務類型和功能，明確用戶或外部系統與DBAS的交互模式；2．3．3性能需求分析DBAS的性能指標：數據操作響應時間（或數據訪問響應時間）：從提交請求到返回結果的時間；系統吞吐量：指系統在單位時間內所完成的事務或查詢的數量，單位為TPS；允許并發訪問的最大用戶數：在保證響應時間的前提下，系統最多允許多少用戶同時訪問數據庫；每TPS代價值，用于衡量系統性價比的指標影響DBAS性能的因素：系統硬件資源；網絡通信設備性能；操作系統環境；數據庫的邏輯設計和物理設計質量，數據庫配置參數；DBAS的配置和性能；數據庫應用程序自身。2．3．4其它需求分析存儲需求分析：是指估計DBAS系統需要的數據存儲量，包括：（1）初始數據庫大??；（2）數據庫增長速度；存儲總量估算可采用：根據數據字典中每個數據項的結構描述信息，估計每個數據項的容量，將所有數據項的容量累加；安全性需求分析：DBAS系統應達到的安全控制級別；各類用戶的數據視圖和視圖訪問權限；DBAS應有的口令保護機制或其它安全認證機制，用以控制用戶登錄數據庫系統。備份和恢復需求分析：DBAS運行過程中備份數據庫的時間和備份周期；所需備份的數據是全部數據庫數據，還是一部分；備份方式是采用完全備份還是采用差異備份。2．4系統設計2．4．1概念設計數據庫概念模型設計：是根據數據需求分析階段得到的需求結果，分析辨識需要組織存儲在數據庫中的各類應用領域數據對象的特征及其相互之間關聯關系，并采用概念數據模型表示出來，得到獨立于具體DBMS的數據庫概念模型；ER方法：（1）選擇局部應用；（2）分別設計各個局部ER圖；（3）局部ER圖合并；系統總體設計：確定DBAS體系結構；系統硬件平臺和操作系統、數據庫管理系統等系統軟件的選型和配置；應用軟件結構設計對需求分析階段識別出的業務規則進行初步設計，細化業務規則流程，明確采用的關鍵技術和算法；對系統采用的關鍵技術進行方案選型和初步設計。2．4．2邏輯設計數據庫邏輯結構設計：指從數據庫的概念模型出發，設計表示為邏輯模式的數據庫邏輯結構。ER圖轉換為初始關系模式；對初始關系模式進行優化；檢查關系表對數據庫事務的支持性；確定關系模式的完整性約束；從數據安全性和獨立性出發，設計用戶視圖。應用程序概要設計（II）；數據庫事務概要設計；2．4．3物理設計數據庫物理結構設計：主要指數據文件在外存上的存儲結構和存取方法，它依賴于系統具體的硬件環境、操作系統和DBMS；數據庫邏輯模式調整；選擇或配置基本關系表的文件組織形式；數據分布設計；安全模式設計；確定系統配置；物理模式評估；數據庫事務詳細設計：根據事務流程，利用SQL語句、數據庫訪問接口，采用高級程序設計語言或DBMS提供的事務實現機制，設計數據庫事務。應用程序詳細設計：2．5實現與部署建立數據庫結構；數據加載；事務和應用程序的編碼及測試；系統集成、測試與試運行；系統部署；2．6運行管理與維護2．6．1日常維護數據庫的備份與恢復完整性維護安全性維護存儲空間管理并發控制及死鎖處理2．6．2系統性能監控和分析統計數據可以通過兩種途徑收集：由DBMS本身自動收集和存儲統計數據通過監控系統得到2．6．3系統性能優化調整糸統性能優化的手段有：數據查詢調整與優化、索引調整、數據庫摸式調整、DBMS和操作系統參數調整等。模式調整主要涉及邏輯模式調整，可以從下考慮：已達到第三范式的基本表，不要進一步規范化為BCNF；在分布式數據庫中，對一個基本表中某些頻繁被訪問的數據，可以按水平分區或垂直分區方式拆分基本表。2．6．4系統升級改進應用桯序；數據庫重組；DBMS和OS版本升級第3章需求分析及功能建模方法3．1需求分析概述3．1．1需求分析概念所謂需求分折：就是對待開發的系統要做什么，完成什么功能的全面描述。需求分析的工作：通過對需求的調查、了解、觀察和分析，通過對原始數據的收集、分類和抽象，并采用有效的技術、工具，對原始資料進行加工整理，描述開發目標、實現的功能及其相互關系等活動的集合；需求的定義：客戶對一個待開發的系統在實現目標、完成功能、應達到的性能、安全性、可靠性等方面的期望和要求的集合；需求獲取的困難：軟件功能復雜；需求的可變性；需求分析階段的主要任務：分析當前的業務流程，包括體系結構，各職能部門完成的主要任務、關系及其交流的信息。需求分析的結果通常以模型等建模工具和方法描述系統的信息流、功能結構及完成各功能需要的數據。功能模型和軟件需求規格說明書是軟件開發的依據，將指導后續的開發工作。需求分析工作是系統分析員與用戶不斷交互的過程中完成的。3．1．2系統分析員的職能系統分析員的主要要任務：是確定應用信息系統及軟件產品應該達到的各項功能性要求和非功能性要求，即用戶要做什么。系統分析員應該具備的素質：獲取需求的能力；管理及溝通能力；技術素養；3．1．3需求獲取的方法常用的幾種獲取需求的方法：（1）面談；（2）實地觀察；（3）問卷調查；（4）查閱資源；3．1．4需求分析過程標識問題：需求分析的第一步，通過對問題的識別和標識獲得所求解問題及其運行環境的理解；標識問題從現行系統的業務流程做起，理解現行系統的業務流程；在標識理解需求的同時，還要注意確定系統的人機界面；2、建立需求模型：模型是對現實原形所作的一種抽象，其本質是只關心與研究內容有關的因素，而忽略無關的因素，其目的是把復雜的事物變得簡單，便于認識和分析；目前常用的模型方法主要有DFD數據流圖和IDEFO，都屬于結構化分析方法，其特征是抽象和分解；首先對應用領域進行全面的分析，發現并找出同類事物的本質，用抽象方法把這類事物的非主要方面剔除，把握住事物的內部規律或本質，就可以找到解決辦法；然后采用自上而下逐步求精的方法對復雜的問題進行分解；結構化分析及建模方法的主要優點：不過早陷入具體的細節；從整體或宏觀入手分析問題；通過圖形化的模型對象直觀地表示系統要做什么，完成什么功能；圖形化建模方法方便系統分析員理解和描述系統；模型對象不涉及太多的技術術語，便于用戶理解；3、描述需求：需求描述的目標：對軟件項目功能性和非功能性的需求全面描述；功能性需求：指需要計算機實際解決的問題或實現的具體功能，明確描述系統必須做什么，實現什么功能以及輸入輸出等；非功能性需求：軟件項目對實際運行環境的要求；需求描述主要由需求模型和需求說明書組成，說明書側重文字說明，內容如下：需求概述；功能需求；信息需求；性能需求；環境需求；其他需求；在對需求進行分析過程中，系統分析員要經?？紤]的問題：描述的需求是完全的嗎？需求描述是正確的和一致的嗎？描述的這些需求是可行的、實際可操作的嗎？描述中的每一條需求都是客戶需要的嗎？4、確認需求：評審委員會審核下列內容：功能需求；數據需求；性能；數據管理；其他需求。3．2DFD建模方法3．2．1DFD方法的基本對象數據流：具有名字且有流向的數據，用標有名字的箭頭表示。處理：表示對數據的加工和變換，在圖中用矩形框表示。數據存儲：表示用數據庫形式存儲的數據，對其存取分別以指向或離開數據存儲的箭頭表示；數據源及數據終點：表示當前系統的數據來源和去向，其圖形符號以平行四邊形表示。3．2．2開發DFD圖DFD圖采用自頂而下逐步細化的結構化分析方法表示目標系統；DFD方法應以軟件項目的功能為中心進行抽象和分解，以數據流的變換來分析數據對企業中各類業務活動的影響；3．2．4數據字典數據字典包括以下說明信息：源點及終點詞條描述；數據流詞條描述；數據存儲；處理描述；數據元素詞條描述。3．3IDEF0建模方法3．3．1概述IDEF0的基本思想是結構化分析方法，強調自頂而下有控制地逐步地展開細節，全面地描述系統，且通過建模來理解一個系統。一個模型由圖形文字說明、詞匯表及相互的交叉引用表組成。IDEF方法的優點：具有模型元素單一、語義豐富、更易于從全局角度分析考察問題，模型容易理解。3．3．2IDEF0方法1、基本元素矩形：代表活動，活動名稱標在矩形內，活動編號按要求標在矩形框右下角指定位置；箭頭：左邊的輸入箭頭代表完成活動需要的數據、上方的控制箭頭描述了影響活動的執行的事件或約束、右邊的輸出箭頭說明由活動產生的結果及信息、下方進入的機制箭頭表示實施該活動的物理手段或資源。輸入輸出箭頭描述活動是什么（what）、控制箭頭描述為何這么做（why）、機制箭頭表示如何做（how）。2、IDEF0模型一個IDEF0模型由一組圖形組成，這些圖形組成一個由父到子的層次結構圖，這組圖形把一個復雜事物按自頂向下逐步細化的方式分解成一個個簡單的或多個組成部分；建模規則矩形框：用動詞為矩形內活動命名，每個矩形要至少有一個控制箭頭和輸出箭頭，可以沒有輸入，但不可以同時沒有輸入和控制。箭頭：箭頭代表數據約束，而不是代表流或順序；其他：ICOM碼：只有一端與矩形相連的箭頭叫邊界箭頭，這些箭頭表示父矩形框的輸入、控制和輸出。IDEF0用專門的記號ICOM碼來說明父子圖中的箭頭關系。子圖中每個邊界箭頭的開端分別用字母I、C、O、M來標明是輸入、控制、輸出及機制，再用一個數字表示其在父矩形框中箭頭的相對位置。結點號：IDEF0模型是一組有一定層次結構的圖形，通常用結點號來標志圖形或矩形框在層次圖中的位置；模型名：每個模型有一個名字，通常用名字代表主題，用子名字表示不同的模型。基本名字與子名字間用“/”隔開，如A/B/C，A是主題、B是模型號、C是結點號。3．3．3建模過程及步驟IDEF0建模過程及步驟：明確目的，確定范圍：在建模前首先要明確目的和意圖，確定問題域；建立內外關系圖A-0圖：根據系統目標、功能建立內外關系圖A-0圖，以確定整個模型的內外關系，確定系統的邊界；構造頂層圖：把A-0圖分解成3~6個主要部分得到A0圖，A0圖是模型真正的頂層圖；開發IDEF0層次結構圖：對A0圖中的每個矩形框進行分解，就形成了基本的圖形層次結構。在分解時要列出所有的數據項和活動表，分解的次序采用以下原則：保持在同一水平上進行分解，均勻的模型深度；按困難程序進行選擇；寫文字說明；檢查確認圖形；3．4DFD與IDEF0的比較DFD與IDEF0共同點：都是結構化分析思想，強調自頂而下逐步求精的方法對現實世界建模，先抓住主要的問題，形成較高層次的抽象，再由粗到細、由表及里地逐步細化，將一個大問題分解成幾個小問題，對這小問題再進行分析求解；DFD與IDEF0區別：DFD圖用箭頭（數據流）來描述數據移動的方向、數據處理及處理之間的數據依賴關系。IDEF0圖也用箭頭代表數據流，但在IDEF0中不是強調流或順序，而是強調數據約束。從表達形式上看，DFD圖與IDEF0圖都是用箭頭和處理表達一個企業或組織的業務流程。但IDEF0圖的箭頭不僅能夠表示數據流，還可以表示控制流和說明處理或實施方式的一些約束；從模型元素的組成上來看，DFD模型由4種元素組成，即外部頂、數據流、數據存儲和處理。而IDEF0模型元素的組成更加簡單，只有2種元素組成，即箭頭和活動；從模型規范上來講，IDEF方法更加規范；IDEF0模型結構清楚，便于理解和溝通。第四章數據庫概念設計及數據建模4．1數據庫概念設計概述4．1．1數據庫概念設計的任務定義和描述應用領域涉及的數據范圍；獲取應用領域或問題域的信息模型；描述清楚數據的屬性特征；描述清楚數據之間的關系；定義和描述數據的約束；說明數據的安全性要求；支持用戶的各種數據處理需求；保證信息模型方便地轉換成數據庫的邏輯結構，同時便于用戶理解。4．1．2概念設計過程概念設計的依據：是需求分析階段的文檔，通過對這些文檔的分析理解，構造出信息模型，編寫數據庫概念設計說明書，信息模型和數據庫概念設計說明書是數據庫邏輯設計的依據；概念設計的基本步驟：確定實體集；確定聯系和聯系類型；建立由信息模型表示的企業模型；確定實體集屬性；對信息模型優化。4．2數據建模方法數據建模方法的共同特點是：能夠真實客觀地描述現實世界中的數據及數據之間的關系；組成模型的概念少，語義清楚，容易理解；不同概念的語義不重疊，概念無多義性；用圖形方式描述數據，數據直觀易懂，有利于數據庫設計者和用戶交流；這種數據模型容易轉換成數據庫邏輯設計階段需要的數據結構。4．3ER建模方法4．3．1基本概念實體或實例：指客觀存在并可相互區分的事物，可以是一個具體的人或物，也可以是抽象的事件或概念；實體集：表示一個現實的和抽象事物的集合，這些事物必須具有相同的屬性或特征。屬性：用于描述一個實體集的性質和特征；碼：實體集中能惟一標識每一個實例的屬性或屬性組；聯系：描述現實世界中實體之間的關系。（1）一對一聯系；（2）一對多聯系；（3）多對多聯系4．3．2ER方法語法ER方法中用矩形框表示實體集，矩形框內寫上實體集的名稱；ER模型用菱形表示聯系，聯系名寫在菱形框內；ER模型中實體集的屬性用橢圓或圓角矩形框表示，屬性名字寫在其中。4．4IDEF1X建模方法4．4．1IDEF1X概述IDEF0側重描述系統功能，被稱為功能建模方法；IDEF1X側重分析、抽象和概括應用領域中的數據，稱為數據建模方法；IDEF1X方法具有豐富的語法和語義；實體集分為（1）獨立標識符實體集；（2）從屬標識符實體集；實體集之間的聯系分為：（1）標定型聯系；（2）非標定型聯系；（3）分類聯系；（4）不確定聯系4．4．2IDEF1X模型元素實體集：實體集語義：如果一個實體集的每一個實例都能被惟一地標識，而不決定于它與其他實體的聯系，那么該實體集稱為獨立實體集；否則就叫從屬實體集；實體集語法：IDEF1X用矩形框來表示獨立實體集，用圓角矩形框來表示從屬實體集；聯系：聯系語義：標定型聯系：一個“確定型聯系”中，如果子女實體集中的每個實例都是由它與雙親的聯系而確定的，這個關系稱為“標定型聯系”；非標定型聯系：一個“確定型聯系”中，如果子女實體集中的每一個實例都能被惟一地確認而無需了解與之相聯系的雙親實體集的實例，這個問題關系叫“非標定型聯系”。分類聯系：是兩個或多個實體集之間的聯系，且在這些實體集中存在一個一般實體集，它的每一個實例都恰好與一個且僅一個分類實體集的一個實例相聯系。不確定聯系：一個非確定聯系又稱為多對多聯系，這種聯系關聯的兩個實體集之間，任一實體集的一個實例都將對應另一實體集的0個、1個或多個實例。聯系的語法：標定聯系語法：在IDEF1X圖中，聯系的語法用直線表示，在一個標定型聯系中，子女實體集總是一個從屬實體集，用圓角矩形框表示；非標定聯系語法：如果兩個實體集之間有關系，并且是一個非標定聯系，就用一條虛線把它們連接起來。分類聯系語法：一般實體集的一個實例只能與分類實體集的一個實例相對應；不確定聯系m:n的語法：不確定聯系用一個兩端帶有實心圓的線段描述，表示多對多的連接關系。屬性屬性的語義：用來描述一類現實或抽象事物的特征或性質。一個屬性的具體取值叫屬性實例，它由屬性的類型和值來定義。屬性的語法主碼和非主碼屬性語法：在一個實體集中屬性要有惟一的名字，屬性名由名詞表示，主碼屬性名后加（PK）標注，被列在屬性列表的頂端，并用水平線將主碼和其他屬性分開。外碼語法：在外碼屬性后加“FK”來識別由聯系繼承得到的外來屬性。4．4．3建模過程1、第一階段：建模規劃及準備建模目標：目標說明：回答將構造的模型完成什么功能，涉及的問題和數據范圍，同時說明是一個當前系統模型還是待建模型。范圍說明：在建模初期要給出模型覆蓋的問題范圍；建模計劃項目說明；收集數據；定義實體；定義聯系；定義碼屬性；定義非碼屬性；確認模型；評審驗收。組織隊伍：包括項目負責人、建模者、信息源、課題專家、評審委員會第二階段：定義實體集目標是標識和定義應用領域中的實體集，方法是分類標識原始材料中的所有名詞；區別實體集名詞和非實體集名詞的方法，是否具有下列特征：它能夠被描述或說明嗎？有多少同類的實例嗎？每個實例可以被標識和區分嗎？第三階段：定義聯系標識實體集之間的聯系：建立聯系矩陣，聯系矩陣由一個二維數組表示。把實體集沿水平和垂直兩方向列出，分析兩個實體間的聯系，有聯系就用“X”表示，不存在聯系用“null”表示。聯系只標識直接關系，不標識間接關系。定義聯系：包括表示依賴、命名聯系、關于聯系的說明；當實體集之間的依賴關系建立后，就可以命名聯系了。聯系的名字可以動詞表示。原則必須是具體的、簡明的和有意義的。構造實體級數：實體級圖的范圍和數目,依賴于建模的規模和建模問題涉及的實體集數目。第四階段：定義健分解不確定的聯系：把實體級圖中不確定的關系轉換成確定的連接形式，把每一個不確定的聯系轉換成為兩個確定的聯系；標識碼屬性：碼屬性是那些能夠惟一識別實體集中每一個實例的屬性；遷移主碼：把一個實體集的主碼復制到其他有關實體集的過程，但要遵守以下規則：在一個聯系中，遷移總是從父到子或從一般實體集移向分類實體集；主碼屬性才能被遷移，如主碼由多個屬性組成，則要全部遷移；第五階段：定義屬性標識和定義非主屬性；建立屬性的所有者；確認屬性的定義；繪制局部數據視圖；實體集的名稱和編號寫在矩形框外的上面；主碼屬性寫在矩形框內水平線的上面并用“PK”標注；外碼屬性寫在矩形框內水平線的下面并用“FK”標注；非主屬性也可以寫在矩形框內水平線的下面；第五章關系數據庫邏輯設計5．1概述5．2基本概念5．2．1關系模型關系模型采用一個二維表格在計算機中組織、存儲、處理和管理數據。關系名（數據庫名）：由字母數字組成；屬性名；關系模式和關系：描述模式描述關系的靜態結構，由模式名、關系模式所包含的屬性及屬性值所滿足的條件組成模式定義。元組：描述關系中的行；域：它定義關系的每個屬性取值的類型；主碼：能夠惟一標識關系中每一個元組的屬性或屬性組；關系的數學定義：關系模式是建立在集合集論的基礎上的，用數學的概念定義關系有；定義一：域是值的集合，同一個域中的值具有相同的數據類型；定義二：定義三：當關系引用了屬性名后關系具有以下屬性：[1]不能有重復的元組；[2]元組上下無序；[3]按屬性名引用時屬性左右無序；[4]所有屬性值都是原子項（不可再分）；總結：關系是一張二維表，表中的一行被稱為一個元組，一列稱為屬性，由一組域值組成。關系是元組的集合，關系中的每個元組在數學上被定義為這個關系所涉及的全部域值中笛卡兒積的一個元素。5．2．2關系數據庫關系數據庫是按照二維表組織和存儲的相互關聯的關系的集合，關系數據庫模式是關系模式的集合；5．2．3關系的完整性關系的完整性（完整性約束）：是對關系的某種約束規則和關系滿足的定義。通常這組約束規則用來限定和檢查數據庫所含實例的合法性和正確性；完整性約束分靜態和動態兩種，靜態完整性約束是基于關系模式的，主要有主碼、外碼約束和域約束組成；動態完整性約束是基于企業的業務規則的。靜態完整性約束規則：主碼約束：主碼必須滿足：惟一性：在一個關系中不存在兩個元組，它們具有相同的主碼值；最小性：不存在從組成主碼的屬性集中去掉一個屬性，還仍能保持數據的惟一性；外碼約束：用戶定義的完整性：5．3關系數據庫設計理論5．3．1問題的提出究竟一個關系數據庫包含哪些屬性是合理的，如何評價一個關系模式設計的優劣？5．3．2函數依賴函數依理論利用一個關系中屬性之間的依賴關系評價和優化關系模式，以保證存儲到數據庫中的關系具有較好特性；函數依賴：設R（U）為一關系模式，X和Y為屬性全集U的子集，若對于R（U）的任意一個可能的關系r，r中不可能存在兩個元組在X上的屬性值相等，而在Y上的屬性值不等，則稱“X函數決定Y”或“Y函數依賴于X”，并記作XY，其中X稱為決定因素，因為根據函數依賴定義，給定一個X，就能惟一決定一個Y。這里討論的函數關系與數學上的不同，是不能計算的，是一個關系中屬性之間存在的依賴關系；它是一種語義范疇的概念，只能根據兩個屬性之間的語義來確定一個函數依賴是否存在。完全與部分函數依賴：在關系模式R（U）中，如果XY成立，并且對X的任何真子集X’不能函數決定Y，則稱Y對X是完全函數依賴，被記作X---f---Y。若XY，但Y不完全函數依賴于X，則稱Y對X是部分函數依賴，記作X--pY；傳遞函數依賴：在關系R（U）模式中，如果X決定Y，（Y不屬于X），Y不決定X，Y決定Z，則稱Z對X傳遞函數依賴。平凡與非平凡函數依賴：若X決定Y，但Y屬于X，則稱XY是平凡函數依賴，否則稱非平凡函數依賴；即平凡函數依賴，僅當其右邊的屬性集是左邊屬性集的子集時成立；非平凡函數依賴，僅當其右邊的屬性集至少有一個屬性不屬于左邊有集合時成立；完全非平凡函數依賴：僅當其右邊的屬性集中屬性都不在左邊的集合時成立；碼：在關系模式R（U）中，K為R的屬性或屬性組，若K函數決定A1.A2….An，則K為關系模式R的候選碼，包含在候選碼中的屬性稱為主屬性，否則為非主屬性；若一個關系的候選碼不止一個，則選定其中一個作為關系R的主碼；關系的碼屬性除了必須完全函數決定關系的所有其他屬性外，還必須滿足最小化規則，即在關系模式R（U）中，不存在一個K的真子集能夠函數決定R的其他屬性。函數依賴的推理規則：自反律：若Y（包含于）X（包含于）U，則XY成立；增廣律：若XY，且Z（包含于）U，則XZYZ成立；傳遞律：若XY，YZ，則XZ成立；合并規則：若XY，XZ成立，則XYZ；分解規則：若XY和Z（包含于）Y成立，則XZ也成立；偽傳遞規則：若XY，YWZ，則XWZ成立；屬性集閉包：設F是屬性集U上的函數依賴集，X為U的一個子集，那么對于F，屬性集X關于F的閉包（用X+表示）為：X+={A|XA}由屬性集團包的定義可知，若想判斷函數依賴XY是否成立，只要計算X關于函數依賴集F的閉包，若Y是X閉包中的一個元素則XY成立；確定關系的碼：利用迭代算法計算X+，步驟如下：選X作為閉包X+的初值X（0）；由X（i）計算X（i+1）時，它是由X（0）并上屬性集合A所組成，其中A滿足下列條件：Y（包含于）X（i），且F中存在函數依賴YZ，而A（包含于）Z。因為U是有窮的，所以會得到X（i）=X（i+1），此時X（i）為所求的X+。5．3．3規范化設計方法第一范式：定義：設關系模式R（F，U），如果R的每一個屬性都是不可分的數據項，則此關系模式為第一范式；一個給定關系和第一范式（1NF）的區別：一個關系中的數據按照行和列的形式組織，每個元組具有相同數目的屬性個數，且每一個元組的屬性值具有統一的數據類型和長度；元組或屬性的排列與順序無關，每個元組必須通過一個屬性或屬性組惟一識別；第一范式實際上對關系增加了一個約束，即關系中元組的每個屬性都只取一個值，第一范式是對關系模式的基本要求，不滿足第一范式的數據庫就不是關系數據庫。第二范式：定義：若關系模式R（F，U）是1NF，且每個非主屬性完全函數依賴于碼，則稱R為第二范式，即在2NF中不存在非主屬性對碼的部分依賴；僅滿足第一范式關系會存在種種問題，要消除必須用更高級的范式標準來設計，稱為標準化；具體做法是將大的關系分解成多個小的關系，使分解后的關系滿足更高級范式的要求。第二范式實際上對關系增加了一個約束，就是關系中的每一個屬性必須完全依賴于主碼，即在第一范式的基礎上，消除非主屬性對主碼的部分函數依賴可達到2NF；第三范式：定義：若關系R（U，F）為第一范式，且不存在非主屬性對主碼的傳遞函數依賴，則稱R為第三范式；第三范式是在第二范式的基礎上對關系又增加了一個約束，就是關系中的每一個非主屬性必須只依賴于主碼。即2NF的基礎上，消除非主屬性對主碼的傳遞函數依賴可達到3NF。改進的第三范式：定義：如果關系模式R是1NF，且每個屬性既不相存在部分函數依賴也不存在傳遞函數依賴于候選碼，則稱R是改進的第三范式（BCNF）。多值依賴與4NF：多值依賴：表示關系中屬性（如A、B、C）之間的依賴，對于A的每個值，都存在一個B或C的值的集合，而且B和C的值相互獨立，記為：AB、AC第四范式：如果關系模式R屬于1NF，對于R的每個非平凡的多值依賴XY（Y不屬于X），X含有候選碼，則R是第四范式。即是從BCNF范式中消除主碼內的獨立依賴集（非平凡多值依賴）可達4NF；連接依賴與5NF連鎖依賴：設關系模式R，R的屬性子集為R1、R2、R3、R4、R5、R6、R7….，當且僅當R的每個合法值等于R1、R2、R3、R4、R5、R6、R7…的投影連接時，稱R滿足連接依賴；第五范式：設R是一個滿足5NF的關系模式，當且僅當R的每一個非平凡連接依賴都被R的候選碼所蘊含，即從4NF中消除非候選碼所蘊含的連接依賴為5NF；總結：范式表達了關系模式滿足的條件，也是衡量關系模式設計優劣的標準；利用范式進行規范化設計的目的是消除數據冗余，避免出現異常，使結構更合理；規范化設計的基本過程是對關系進行的分解，消除屬性間不合理的數據依賴，用一組等價的子關系代替原有的關系；數據庫規范化的程序越高，其關系表就越多，從而增加了表之間連接運算的代價，影響了數據庫的執行速度和性能。所以通常關系模式規范化工作僅做到3NF，這樣既使關系中不合理的屬性基本消除，規范化程度也不太高，保證數據庫有較好的性能。5．4數據庫模式設計5．4．1初始關系模式的設計把ER圖轉換成關系模式：把ER模型中的每個實體集轉換成一個同名的關系，實體集的屬性就是關系的屬性，實體集的碼就是關系的碼；把ER模型中的每個聯系轉換成一個關系，與該聯系相連的各實體集的碼以及聯系的屬性轉換成為關系的屬性。若聯系為1：1，則每個實體集的碼均是該關系的候選碼；若聯系為1：n，則關系的碼為n端實體集的碼；若聯系為m：n，則關系的碼為各實體集碼的組合；合并具有相同碼的關系檢查確認對象：檢查轉換后的每個關系名和屬性名是否符合數據庫設計關于統一命名的約定；5．4．2優化關系模式模式分解原則：分解具有無損連接性：分解后的關系能夠恢復成原來的關系；分解保持函數依賴：無損連接和保持函數依賴是用于衡量一個模式分解是否導致原有模式中部分信息丟失的兩個標準；當一個關系被分解后會出現幾種結果，既有無損連接，又能保持函數依賴是較理想的分解結果，意味著在分解的過程中沒有丟失原有模式的任何信息；一般情況下，分解到3NF就足夠了，但在3NF關系下，仍存在一定程度上的更新異?；虿灰恢碌碾[患，但與數據庫性能比較起來是可以忽略的，因為在數據庫設計過程中通過增加一些數據約束，就可以解決3NF引起的數據問題了。優化屬性：確定各字段的類型和長度；確認模式滿足需要：5．4．3數據完整性設計指定義數據庫中存儲的數據值滿足的約束條件，通過對存儲的數據值的約束維護關系的完整性。數據值滿足條件分為：域約束：限制指定列的取值及范圍；主碼約束：定義每個關系的主碼值不空，且惟一；引用完整性約束：定義不同模式的屬性間滿足的條件，及一個關系模式中屬性間可能滿足的條件；5．4．4安全模式和外模式的設計根據選定的DBMS支持的安全控制特征來確定；根據不同用戶對數據庫存取特點定義相關的外模式；第六章存儲技術與數據庫物理設計6．1文件組織6．1．1數據庫的物理結構數據庫中的應用數據是以文件形式存儲在外存上的，文件在邏輯上被組織成記錄的序列，即每個DB文件可看作是邏輯記錄的集合；一個文件在磁盤上占有一定的物理存儲空間，文件中的每個邏輯記錄被映射存儲到某個特定的磁盤塊上，一個文件在物理上可以看作是由存放文件記錄的一系列磁盤塊組成，稱為物理文件；文件的邏輯記錄與磁盤間的映射關系是由操作系統或DBMS來管理的，當需要對一個文件的邏輯記錄進行操作時，先要根據這種映射關系找到該邏輯記錄所在的磁盤塊，然后再進行操作。從數據庫物理結構角度需要解決如下問題：文件的組織；文件的結構；文件的存取；索引技術；6．1．2文件組織數據庫與文件的對應關系在外存中，數據庫以文件形式組織，文件由邏輯記錄組成，記錄由多個域組成；一個關系數據庫包括一張或多張關系表，關系表與文件的對應關系有如下方式：每張關系表單獨用一個文件來存儲，由DBMS通過OS的文件管理功能來管理；現代中大型DBMS是由OS直接分配一塊大的磁盤空間，DBMS將該磁盤空間作為數據庫磁盤文件直接管理，DB的所有關系表都存儲在該文件中；關系表在邏輯上由一系列元組組成，元組由多個屬性組成，每個元組可以用磁盤文件中的一個邏輯記錄來存儲，記錄包括多個域，對應元組的多個屬性；2、文件記錄格式：數據庫文件通常采用兩種邏輯記錄格式：定長記錄格式和變長記錄格式；6．2文件結構與存取6．2．1堆文件堆文件也稱無序文件，記錄隨機在存儲在文件物理空間是，新插入的記錄存儲在文件的末尾；堆文件常常用作存儲那些將來使用，但目前不清楚如何使用的記錄，為了實現文件記錄的有效存取，堆文件經常與附加的存取路徑一起使用；查找操行平均需要搜索（B+1）/2個磁盤塊，效率比較低；插入操作十分簡單，先讀文件頭，找到最末磁盤地址，將最末磁盤塊讀入內存，將需插入的新記錄寫入磁盤塊的末端，最后將修改過的磁盤塊寫回磁盤；刪除比較復雜，可以先找到被刪除記錄所在的磁盤塊，讀入內存后在內存緩沖區刪除記錄，最后再寫回磁盤；也可以在每個記錄的磁盤空間增加一個刪除標志位，當需要刪除記錄時，將標示位置1；6．2．2順序文件順序文件按照文件記錄在查詢碼上的取值的大小順序排列各個記錄；順序文件的每個記錄中有一個指針字段，根據查詢碼大小用指針將各個記錄按序連接起來；文件建立時，應盡量使記錄的物理順序與查找碼的順序一致，以減少訪問磁盤塊的次數；根據查詢條件對順序文件進行查詢時，如查詢條件定義在查找碼上，則使用二分法查找技術快速找到記錄，如條件不在查找碼上，則必須從頭到尾依次掃描磁盤塊，與堆文件一致，所以順序文件的訪問效率也不高；順序文件插入工作包括定位和插入：定位：在指針鏈中找到插入的位置，即插入記錄在哪個記錄的前面；插入：如有自由空間，則在該位置插入新記錄，如沒有自由空間，則只能插入溢出塊中，重新調整記錄指針鏈關系，保證記錄順序；6．2．3聚集文件聚集文件是一種具有多種記錄類型文件，存儲了來自多個關系表的數據，每個關系表對應文件中的一種記錄類型；當數據庫中數據量效大時，對數據庫查詢需要多次訪問磁盤文件，嚴重影響性能指標，為了降低多表操作時的磁盤訪問次數，提高多表查詢速度，可采用聚集文件；聚集文件將不同關系表中有關聯關系的記錄存儲在同一磁盤塊內，從而減少多表查詢時磁盤塊的訪問次數，提高處理速度；6．2．4索引文件是一種利用索引技術技術快速文件訪問的文件組織和存取方法；6．2．4散列文件是一種利用散列函數支持快速文件訪問的文件組織和存取方法；6．3索引技術6．3．1基本概念索引技術：是一種快速文件訪問技術，它將一個文件的每個記錄在某個或某些域（屬性）上的取值與該記錄的物理地址直接聯系起來，提供了一種根據記錄域的取值快速訪問文件記錄的機制；它的關鍵是建立取值域到記錄的物理地址劉的映射關系，這種映射關系叫索引；索引技術分類：有序索引技術：利用索引文件實現記錄域（查找碼）取值到記錄物理地址間的映射關系，索引文件由索引記錄組成，每個記錄中記載一個索引項，索引項記錄了某個特定的查找碼值和具有該值的數據文件記錄的物理地址；散列技術：利用一個散列函數實現記錄域取值到記錄物理地址間的直接映射關系；有序索引：有序索引作為基于索引文件的索引技術，需要考慮兩個問題：（1）如何組織索引文件中的索引記錄；（2）如何從索引文件出發，訪問數據文件中的數據記錄；當需要采用有序索引機制快速訪問數據文件時，首先要為該數據文件建立一個索引文件，它是索引記錄和索引項的集合；索引文件建立的方法：首先選定某些記錄域作為查找碼，然后建立數據記錄在查找碼上的取值與物理地址間的映射關系，組成索引項。所有索引項作為索引記錄存儲在索引文件中，索引文件根據某個特定的查找碼值的順序組織為順序文件；一個數據文件可以有多個查找碼和索引文件；6．3．2有序索引的分類及特點聚集索引與非聚集索引對數據文件和它的一個特定的索引文件，如果數據文件中數據記錄的排列順序與索引文件中索引項的排列順序相一致，則該索引文件稱為聚集索引，否則稱為非聚集索引；在一個數據文件上除了建立一個聚集索引外，還可建立多個非聚集索引；稠密索引和稀疏索引如果數據文件中的每個查找碼都在索引文件中都對應一個索引記錄，稱為稠密索引，如果只一部分對應，則稱為稀疏索引；主索引和輔索引在數據文件包含主碼的屬性集上建立索引稱為主索引，在非主碼屬性上建立的索引稱為輔索引；4、單層索引和多層索引單層索引（線性索引）：索引項根據鍵值在索引文件中順序排列，組織成一維線性結構，每個索引項直接指向數據文件中的數據記錄；當數據文件很大時，即使采用稀疏索引，建成的索引文件也很大，導致效率低下，為解決該問題，可對索引文件中的索引項本身再建立一級稀疏索引，組成2層索引結構；進一步地，可建立多層樹型索引結構來快速定位；6．4散列技術6．4．1散列文件散列是一種快速查找技術，它利用定義在文件記錄上的查找碼，通過計算一個散列函數，以散列函數值作為記錄的物理地址，實現對文件記錄直接快速訪問。首先指定文件記錄的一個域作為查找碼（散列域），然后定義一個查找碼上的函數（散列函數），函數的輸入為查找碼值，輸出為物理地址；一般使用桶作為基本的存儲單位，一個桶可存放多個文件記錄，物理地址可以是記錄所在的桶號，散列函數的輸出可以是桶號；6．4．2散列函數散列方法依賴于好的散列函數，它應該盡可能均勻地將查找碼分布到各個桶中，具體要滿足如下兩個條件：地址的分布是均勻的；地址的分布是隨機的；6．4．3桶溢出產生桶溢出的兩個原因：文件初始設計時，為文件記錄預留的存儲空間不足；散列函數的均勻分布性不好；設計散列函數時，應根據文件大小決定物理空間，一般應有20%余量，再設計合適的桶數目和桶大小，盡可能留有一些空閑桶，降低桶溢出的可能性；桶溢出的現象是難免的，需要DBS采用相應的桶溢出處理機制；散列方法的缺點：為了避免桶溢出。必須選一合適的散列函數，但這比較復雜，而且不象索引文件那樣可以據數據記錄變化動態調整。6．5數據字典數據字典（系統目錄）中存儲了數據庫對象的各類描述信息和DBMS所需的控制信息，全稱數據庫元數據；數據庫對象的各類描述信息：包括外模式、模式、內模式以及它們之間的映射的描述；DBMS所需的控制信息：包括查詢優化、安全性檢查、用戶權限驗證等；數據字典主要包括：關系模式信息；與視圖描述有關的信息；關系的存儲結構和存取方法信息；完整性約束信息；安全性有關信息；數據庫運行統計信息；6．6數據庫物理設計6．6．1設計步驟和內容數據庫物理結構設計：在具體的硬件環境、OS、DBMS約束下，根據數據庫邏輯設計結果，設計合適的數據庫物理結構。目標是存儲空間占用少、訪問效率高和維護代價低；一旦選定了硬件平臺、OS和DBMS，數據庫的數據存儲和存取方式等可用的物理模式也就隨之確定了；數據庫物理設計主要包括以下步驟：數據庫邏輯模式調整：將數據庫邏輯模式及其視圖轉換為DBMS支持的基本表和視圖，并利用DBMS提供的完整性機制設計業務規則；文件組織與存取設計：配置基本表的文件組織形式，據實際情況為基本表設計合適的存取方法和路徑；數據分布設計：安全模式設計：確定系統配置：物理模式評估：6．6．2數據庫邏輯模式調整物理數據庫設計首先需要根據數據庫邏輯結構信息，設計目標DBMS平臺支持的基本表的模式信息，這些模式信息代表了所要開發的具體目標數據庫的結構，這個過程稱為數據庫邏輯模式調整，主要包括如下設計內容：實現目標數據庫基本表和視圖：采用目標DBMS所支持的建表方法，設計基本表及其面向模型的完整性約束；設計基本表業務規則；6．6．3DB文件組織與存取設計1、分析事務的數據訪問特性使用事務-基本表交叉引用矩陣，分析系統內數據庫事務對各個基本表的訪問情況，確定事務訪問了哪些基本表，對這些基本表執行了何種操作，并進一步分析各操作涉及到的基本表屬性；估計各事務的執行頻率；對每張基本表，匯總所有作用于該表上的各事務的操作頻率信息；了解并選擇數據庫文件結構如果數據庫中的一個基本表中的數據量很少，并且操作非常頻繁，該基本表可采用堆文件組織方式；順序文件支持基于查找碼的順序訪問，也支持快速二分查找；如果用戶查詢是基于散列域值的等值匹配，特別是如果訪問順序是隨機的，散列文件比較合適。但散列文件組織不適合以下情況：基于散列值域的非精確查詢；基于非散列域進行查詢時；B-樹和B+樹文件是實際數據庫系統中使用非常廣泛的索引文件結構，適合于定義在大數據量基本表上、基于查找碼的等值查詢等；如果某此重要而頻繁的用戶查詢經常需要進行多表連接操作，可考慮將這些基本表組織為聚集文件；設計存取路徑：為數據庫文件設計合理的物理存儲位置；為基本表設計索引機制：索引可以提高文件存取速度，改善訪問性能，但索引由DBMS管理，它的建立、維護需要一定的系統開銷，數據的操作會引起索引的重新調整，還占用一定的存儲空間，可根據如下原則決定是否為一個基本表建立索引：對于經常需要查詢、連接、統計操作，且數據量大的基本表可考慮建立索引，而對于經常執行插入、刪除、更新操作或小數據量的基本表應盡量不建立索引；一個基本表上除了可以建立一個聚集索引外，還可以建立多個非聚集索引，但索引越多，對表內數據更新所需的開銷越大，對于一個更新頻繁的表應少建或不建索引；索引可以由用戶根據需要隨時創建或刪除，以提高數據查詢性能；6．6．4數據分布設計1、不同類型數據的物理分布各種數據在系統中的作用不同，使用的頻率也不一樣，應根據實際使用情況放在合適的物理介質上；使用頻率低但數據量大的，可以放在磁帶中，而使用頻繁，要求響應時間短的，必須放在支持直接存取的磁盤存儲介質上；應用數據的劃分和分布根據數據的使用特征劃分：可將基本表劃分為頻繁使用分區和非頻繁使用分區，分別存放在不同的磁盤上，對前者可考慮建立B+樹等多層索引，而后者不建立或只建立單層索引；根據時間、地點劃分；分布式數據庫系統中的數據劃分：3、派生屬性數據分布派生屬性指該屬性的取值可根據表中其他屬性的取值惟一確定；對帶有派生屬性的基本表可采用兩種實現方式：將派生屬性作為基本表內單獨一列，稱為派生列；派生屬性不出現在基本表中；關系模式的去規范化在數據庫物理設計階段，可以對考慮數據庫中某些3NF、BCNF模式是否可以降低其規范化程度，以提高查詢效率，這稱為關系模式的去規范化處理，但不滿足3NF的關系模式又可能導致數據庫訪問異常，因此，設計基本表時，需在規范化和查詢效率間權衡；6．6．5安全模式設計1、系統安全設計是指為數據庫服務器合法用戶分配用戶名和口令，使其能夠正常登錄服務器訪問所需的數據，還可采用基于CA認證的系統安全控制機制；數據安全設計是指通過數據庫系統視圖機制和授權機制為用戶對數據庫對象訪問的權限；引用數據視圖機制，只給用戶需求的那部分數據訪問權限，防止由合法用戶造成信息泄密，另外數據視圖還可以防止基本表發生改變時，影響用戶的訪問；權限是允許用戶對一給定的數據庫對象可執行的操作；數據庫安全設計需要根據用戶需求，采用授權機制，為用戶分配合法訪問的權限；6．6．6確定系統配置要根據實際應用系統的運行情況配置系統參數；6．6．7物理模式評估在設計過程中，通過對時間效率、空間效率、維護代價和用戶要求權衡考慮，擇優采用；評估物理數據庫的方法完全依賴所選用的DBMS，主要從定量估算各方案的存儲空間、存取時間和維護代價入手；第七章數據庫應用系統功能設計7．1軟件體系結構與設計過程7．1．1軟體體系結構軟件體系結構又稱軟件架構，軟件體系結構={構件，連接件，約束}。構件是組成系統的具有一定獨立功能的不同粒度的程序模塊、獨立程序或軟件子系統，是組成軟件的系統元素；連接件將不同的構件連接起來，表示了構件間的相互作用；約束一般是對象連接時的規則，或指明了構件連接的條件。軟件體系結構描述了軟件系統的總體組織和層次結構、系統元素及其功能分配、全局控制、系統元素間的協調和交互、數據存取等；7．1．2軟件設計過程概要設計定義：是建立軟件系統的總體結構和模塊間的關系，定義各功能模塊的接口，設計全局數據庫、規定設計約束、制定組裝測試計劃；一個好的概要設計要求是：良好的總體結構、功能模塊間較低的耦合度和較高的內聚度，并盡量降低模塊接口的復雜性；可以采用層次結構圖表示軟件總體結構，圖中節點代表功能模塊。詳細設計是細化概要設計產生的功能模塊，形成可編程的程序模塊，并用某種過程設計語言設計程序模塊的內部細節，為編寫軟件代碼提供依據。可選用結構化設計方法、面向對象設計方法等；關于軟件總體設計一些大的DBAS可根據逐步抽象和層次化原則，將概要設計分解成兩個步驟：首先是軟件總體結構設計，即對軟件需求進行分解；第二步是將每個子系統進一步劃分為功能模塊，定義各模塊的數據結構、相互間交互關系；7．2DBAS總體設計7．2．1系統總體設計任務：是根據系統規劃與分析結果，特別是技術可行性分析，以及系統需求規范，確定系統總體框架，作為后續設計活動的基礎。確定DBAS體系結構指將系統從功能、層次結構、地理分布等角度進行分解，劃分為多個子系統。定義各子系統應實現的功能，設計全局控制，明確各子系統間的交互和接口關系；可以從功能角度進行分解，也可以根據DBAS自身固有的層次結構特征進行分解；將系統分解為多個子系統后，需選擇和設計合適的系統體系結構，將這些子系統組織起來，并設計它們之間的交互關系；DBAS體系結構可采用一些通用體系結構，也可根據DBAS所屬的特定應用領域相關的