數(shù)據(jù)庫工程師考點全包含

1、數(shù)據(jù)庫工程師 概念要點 馮宗寶 2012-9-5始數(shù)據(jù)庫（DB）：長期存儲在計算機中有組織的、大量的、共享的數(shù)據(jù)集合。數(shù)據(jù)庫管理系統(tǒng)（DBMS）是計算機系統(tǒng)中位于用戶與操作系統(tǒng)之間的數(shù)據(jù)管理系統(tǒng)軟件，是數(shù)據(jù)庫系統(tǒng)的核心。數(shù)據(jù)庫系統(tǒng)的定義與層次結構數(shù)據(jù)庫系統(tǒng)（DBS）是指在計算機系統(tǒng)中引入數(shù)據(jù)庫后的軟硬件系統(tǒng)構成。數(shù)據(jù)庫系統(tǒng)的層次結構包括硬件、軟件、用戶。數(shù)據(jù)模型DATA MODEL 是數(shù)據(jù)庫系統(tǒng)的形式框架，是用來描述數(shù)據(jù)的一組概念和定義。數(shù)據(jù)模型應滿足三方面要求：l 能夠比較真實地模擬現(xiàn)實世界；l 容易為人們所理解；l 便于在計算機上實現(xiàn)。目前，還沒有一種數(shù)據(jù)模型能夠很好地同時滿足這三方面的要

2、求。數(shù)據(jù)模型三要素n 數(shù)據(jù)結構:精確地描述了系統(tǒng)的靜態(tài)特征n 數(shù)據(jù)操作：動態(tài)特征各種數(shù)據(jù)對象允許執(zhí)行的操作和操作規(guī)則n 完整性約束：一組完整性規(guī)則的集合，它定義了數(shù)據(jù)模型必須遵守的語義約束。數(shù)據(jù)模型的分類概念模型：數(shù)據(jù)結構模型 包含 關系模式、網狀模式、層次模式物理數(shù)據(jù)模型概念數(shù)據(jù)模型;也可簡稱為概念模型，是按用戶的觀點對數(shù)據(jù)和信息進行建模。是現(xiàn)實世界到信息世界的第一層抽象，強調起語義表達功能，易于用戶理解。數(shù)據(jù)結構模型 也稱為表示型 或者實現(xiàn)型 的數(shù)據(jù)結構模型是機器世界中與DBMS相關的數(shù)據(jù)模型。數(shù)據(jù)結構模型提供的概念能夠被最終用戶所理解，同時也不會與數(shù)據(jù)在計算機中實際的組織形式相差太遠。物

3、理數(shù)據(jù)模式 屬于底層數(shù)據(jù)模式，通過諸如記錄格式、記錄順序和存取路徑等表示信息，描述數(shù)據(jù)在數(shù)據(jù)庫系統(tǒng)中的實際存儲方式。數(shù)據(jù)視圖和模式結構數(shù)據(jù)庫系統(tǒng)的兩種機構形式數(shù)據(jù)庫系統(tǒng)是一類復雜數(shù)據(jù)管理系統(tǒng)，數(shù)據(jù)庫系統(tǒng)結構按考慮的層次和角度不同，分為如下兩種形式：1、 從數(shù)據(jù)庫管理系統(tǒng)角度看，數(shù)據(jù)庫系統(tǒng)采用三級模式結構，包括外模式、模式、內模式。2、 從數(shù)據(jù)庫最終用戶角度看，數(shù)據(jù)庫系統(tǒng)的結構分分為集中式結構、分布式結構、客戶/服務器結構和并行結構。數(shù)據(jù)視圖與數(shù)據(jù)抽象數(shù)據(jù)視圖(Data View）是指從某一個角度看到的客觀世界數(shù)據(jù)對象的特征。數(shù)據(jù)抽象（Data Abstrct） 是一種數(shù)據(jù)描述和數(shù)據(jù)庫設計原則，

4、是指專注于數(shù)據(jù)對象的某個方面特征。三級模式結構 數(shù)據(jù)庫的模式結構分為外部級、概念級和內部級3個層次 在這三個層次的基礎上分別定義了外模式、模式、內模式 外模式：也稱子模式、用戶模式活用戶視圖，是數(shù)據(jù)庫用戶能夠看見和使用的局部數(shù)據(jù)的邏輯機構和特征的描述。模式（Schema）：也稱為邏輯模式或概念模式，是對數(shù)據(jù)庫中全體數(shù)據(jù)的邏輯結構和特征描述，是所有用戶的公共數(shù)據(jù)視圖，一個數(shù)據(jù)庫只有一個模式。內模式：也稱為物理模式或者存儲模式 是對數(shù)據(jù)庫中數(shù)據(jù)物理結構和存儲方式的描述，代表了數(shù)據(jù)在數(shù)據(jù)庫內部的表示方式和物理組織結構。例1下列模式中能夠給出數(shù)據(jù)庫物理存儲結構與物理存取方法的是 。 A內模式 B外模式

5、 C概念模式 D邏輯模式二級映像與數(shù)據(jù)獨立性兩層映像機制數(shù)據(jù)庫系統(tǒng)中的DBMS為三級模式結構提供了兩層映像（mapping）機制，外模式/模式機制映像、模式/內模式映像機制。這兩層映像機制保證了數(shù)據(jù)庫中數(shù)據(jù)邏輯獨立性和物理獨立性。1、 外模式/模式映像機制 保證了數(shù)據(jù)的邏輯獨立性外模式/模式映像機制定義了數(shù)據(jù)庫中不同用戶的外模式與數(shù)據(jù)庫邏輯模式之間的對應關系。2、 模式/內模式映像機制 保證了數(shù)據(jù)的物理獨立性數(shù)據(jù)獨立性的作用數(shù)據(jù)庫中數(shù)據(jù)的邏輯獨立性和物理獨立性使得數(shù)據(jù)定義和描述與應用程序相分離，而且由于DBMS負責數(shù)據(jù)的存取和管理，用戶不必要考慮存取路徑等細節(jié)，從而簡化了數(shù)據(jù)庫應用程序開發(fā)，保

6、證了應用程序的相對穩(wěn)定性，降低了應用程序的維護代價。數(shù)據(jù)庫系統(tǒng)體系結構數(shù)據(jù)庫系統(tǒng)體系結構類型集中式結構、分布式結構、客戶服務器結構、并行結構、WEB結構1、 集中式DBS全部數(shù)據(jù)和管理功能集中在一臺計算機上的數(shù)據(jù)庫系統(tǒng)2、 分布式DBS分布式計算機系統(tǒng)與數(shù)據(jù)庫技術結合的產物 滿足地理上不同用戶的需求3、 客戶服務器DBS將DBMS與數(shù)據(jù)庫應用分開 較為開放式的一種網絡數(shù)據(jù)庫系統(tǒng)4、 并行DBS處理大型復雜數(shù)據(jù)管理應用領域中海量數(shù)據(jù)5、 WebDBS與網絡技術結合的產物 由客戶端、WEB服務器、數(shù)據(jù)庫服務器組成.數(shù)據(jù)庫管理系統(tǒng)(DBMS)數(shù)據(jù)庫管理系統(tǒng)的功能1) 數(shù)據(jù)定義功能 定義數(shù)據(jù)庫的三級模

7、式結構 2) 數(shù)據(jù)操縱功能查詢插入刪除更新3) 數(shù)據(jù)庫運行管理和控制功能統(tǒng)一管理和控制數(shù)據(jù)庫的建立運行維護4) 數(shù)據(jù)庫的建立和維護功能數(shù)據(jù)的備份 恢復功能數(shù)據(jù)庫系統(tǒng)的全局結構數(shù)據(jù)庫系統(tǒng)自上而下分為用戶、人機交互界面、DBMS、磁盤4個層次。DBMS可分為兩部分，面向用戶的請求查詢處理器和面向數(shù)據(jù)存儲訪問的存儲管理器用戶類型Ø 數(shù)據(jù)庫管理員Ø 專業(yè)用戶Ø 應用程序員Ø 終端用戶查詢處理器類型l DML編譯器l 嵌入式DML的預編譯器l DDL編譯器l 查詢執(zhí)行引擎存儲處理器類型l 權限和完整性管理器l 事務管理器l 文件管理器l 緩沖區(qū)管理器磁盤存儲的數(shù)據(jù)

8、類型ü 以數(shù)據(jù)文件方式存儲的應用數(shù)據(jù)ü 數(shù)據(jù)字典ü 為提高數(shù)據(jù)庫查詢速度而設置的數(shù)據(jù)庫索引ü 記錄DBS運行時用戶對DB的操作情況的日志信息數(shù)據(jù)庫技術的發(fā)展和應用數(shù)據(jù)管理的三個階段人工管理文件管理數(shù)據(jù)庫管理數(shù)據(jù)庫應用系統(tǒng)生命周期2012-9-8軟件生命周期的概念軟件生命周期是指軟件產品從考慮起概念開始，到該產品不再使用的整個時期。一般包括概念階段、設計階段、實現(xiàn)階段、測試階段、測試階段、安裝部署與交付階段、運行階段和維護階段。這些階段可以重復，也可以迭代。軟件開發(fā)模型瀑布模型 （也稱軟件生命周期模型）、快速原型模型、增量模型、螺旋模型將DBMS設計階段細

9、分為概念設計、邏輯階段、物理設計三個步驟，每一步的設計內容又涵蓋了3條設計主線。規(guī)劃與分析系統(tǒng)規(guī)劃與定義的具體內容包括：ü 任務陳述ü 確定任務目標ü 確定系統(tǒng)范圍和邊界ü 確定用戶視圖可行性分析可行性分析的目的在明確了DBMS的任務目標和系統(tǒng)范圍之后需要從技術、經濟、操作等方面進行項目的可行性分析、評估判斷DBMS開發(fā)項目在現(xiàn)有技術和經濟條件下是否可行，是否能夠達到預期目標可行性分析的內容經濟可行性：成本效益分析技術可行性：系統(tǒng)功能、性能以及實現(xiàn)系統(tǒng)的各項約束條件操作可行性：論證開發(fā)方案選擇：最佳方案項目規(guī)劃項目規(guī)劃的內容：確定項目規(guī)劃的目標和范圍根據(jù)

10、DBMS軟件開發(fā)模型，分解和定義整個項目包括的工作活動和任務。估算完成該項目的規(guī)模及所需各種資源制訂合理的DBMS項目計劃，包括進度、成本和質量等方面的預測和控制方案項目規(guī)劃的成果項目規(guī)劃的成果應形成數(shù)據(jù)庫應用系統(tǒng)項目計劃文檔、也就是項目計劃書需求分析 2012-9-9需求的概念數(shù)據(jù)庫應用系統(tǒng)需求指用戶對DBMS在功能、性能、行為、設計約束等方面的期望和要求。需求分析的概念DBMS需求分析是在已經明確的DBMS系統(tǒng)范圍基礎上，通過對應用問題的理解和分析，采用合適的工具和符號，系統(tǒng)地描述DBMS的功能特征、性能、特征和約束，并形成需求規(guī)范說明文檔。需求分析過程由需求獲取、需求分析、需求描述與規(guī)范

11、說明、需求驗證等步驟組成。需求分析的具體內容：ü 數(shù)據(jù)需求分析ü 數(shù)據(jù)處理需求分析ü 業(yè)務需求分析ü 分析數(shù)據(jù)庫系統(tǒng)絕對性能、存儲、安全、備份與恢復等方面的要求.數(shù)據(jù)字典的內容ü 數(shù)據(jù)項ü 數(shù)據(jù)結構ü 數(shù)據(jù)流ü 數(shù)據(jù)存儲ü 數(shù)據(jù)處理數(shù)據(jù)項是數(shù)據(jù)的最小組成單位.事務規(guī)范的內容:數(shù)據(jù)處理需求分析結果也可以表示為事務規(guī)范.事務規(guī)范包括以下幾個方面事務描述信息:事務名稱事務描述事務所訪問的數(shù)據(jù)項事務用戶性能需求分析性能需求分析主要內容ü 數(shù)據(jù)操作響應時間活數(shù)據(jù)項訪問時間ü 系統(tǒng)吞吐量:系統(tǒng)單位

12、時間內完成的事務數(shù).每秒事務數(shù)(TPS)ü 允許并發(fā)訪問的最大用戶數(shù),指在保證單個用戶查詢響應時間的前提下,系統(tǒng)最多允許多少用戶同時訪問數(shù)據(jù)庫ü 每TPS代價值,用于衡量系統(tǒng)性價比的指標.。對商業(yè)數(shù)據(jù)庫應用系統(tǒng)，既要有好的系統(tǒng)性能，又要有好的使用成本。影響DBMS性能的主要因素ü 系統(tǒng)硬件資源ü 網絡通訊設備性能ü 操作系統(tǒng)環(huán)境ü 數(shù)據(jù)庫邏輯設計和物理設計質量ü DBMS的配置和性能。如DBMS所采用的查詢優(yōu)化策略、索引優(yōu)化策略、數(shù)據(jù)庫管理配置策略參數(shù)數(shù)據(jù)庫應用程序本身軟件生存期從應用系統(tǒng)規(guī)劃、需求分析、設計、實現(xiàn)、維護直到

13、最后被新的系統(tǒng)取代而停止使用的整個期間其中設計又包括概念設計、邏輯設計、物理設計問答題：數(shù)據(jù)庫應用系統(tǒng)功能設計包括哪兩個方面？每個方面主要由哪些設計步驟組成？2009.4數(shù)據(jù)庫應用系統(tǒng)功能設計包括數(shù)據(jù)庫事務設計和應用程序設計。與數(shù)據(jù)庫應用系統(tǒng)概念設計、邏輯設計、物理設計相對應，應用程序設計分為總體設計、概要設計、詳細設計，數(shù)據(jù)庫事務設計則由事務概要設計和事務詳細設計組成。試述數(shù)據(jù)庫設計過程中各個階段上的設計描述。Ø 需求分析：準確了解與分析用戶需求（包括數(shù)據(jù)處理）Ø 概念結構設計：通過對用戶需求進行綜合、歸納與抽象，形成一個獨立于具體DBMS的概念模型。Ø 邏輯結

14、構設計：將概念結構轉換為某個DBMS所支持地方數(shù)據(jù)模型，并對其進行優(yōu)化。Ø 數(shù)據(jù)庫物理設計：為邏輯數(shù)據(jù)模型選取一個最合適應用環(huán)境的物理結構（包括存儲結構和方式）Ø 數(shù)據(jù)庫實施：Ø 數(shù)據(jù)庫運行與維護數(shù)據(jù)庫的實施主要包括以下工作：Ø 用DDL定義數(shù)據(jù)庫結構Ø 數(shù)據(jù)裝載，4步：篩選數(shù)據(jù)，轉換數(shù)據(jù)格式，輸入數(shù)據(jù)，校驗數(shù)據(jù)Ø 編寫與調試應用程序Ø 數(shù)據(jù)庫試運行其中，數(shù)據(jù)庫的試運行和應用程序的編寫調試是同時進行的。數(shù)據(jù)庫的維護工作主要包括：Ø 數(shù)據(jù)庫的轉儲和恢復Ø 數(shù)據(jù)庫安全性和完整性控制Ø 數(shù)據(jù)庫性能的監(jiān)

15、控分析和改造Ø 數(shù)據(jù)庫的重組和重構對數(shù)據(jù)庫的監(jiān)控分析分為：自動監(jiān)控機制和管理員實現(xiàn)的手動監(jiān)控機制對數(shù)據(jù)庫架構體系的監(jiān)控：空間信息，空間使用率，剩余大小，空間是否具有自動擴充能力，那些表的擴充能力將引起空間的擴展，段的使用空間與區(qū)間數(shù)。對數(shù)據(jù)庫數(shù)據(jù)性能的監(jiān)控：數(shù)據(jù)緩沖區(qū)的命中率，庫緩沖、用戶鎖、鎖與等待、回滾數(shù)、臨時段使用情況、索引使用情況、等待時間和共享池數(shù)據(jù)庫空間管理：無論使用何種數(shù)據(jù)庫，對空間的管理主要包括創(chuàng)建數(shù)據(jù)庫空間，更改空間大小，刪除空間，修改空間大小，新建、移動、關聯(lián)數(shù)據(jù)文件。分析評價數(shù)據(jù)庫性能主要有數(shù)據(jù)庫吞吐量、數(shù)據(jù)庫用戶響應時間系統(tǒng)吞吐量：單位時間內系統(tǒng)處理的事務數(shù)：

16、TPS數(shù)據(jù)庫用戶響應時間=系統(tǒng)服務時間+用戶等待時間索引使用的原則包括：Ø 經常在查詢中作為條件被使用的列，應為起建立索引Ø 頻繁進行排序或分組的列，應為其建立索引Ø 一個列的值域最大時，Ø 如果待排序的列有多個，應在這些列上建立符合索引Ø 可以使用系統(tǒng)工具來檢查索引的完整性，必要時進行修復。 故障管理事務：作為單個邏輯工作單元執(zhí)行的一系列操作。一個邏輯工作單元要成為一個事務，必須要滿足所謂的ACID（原子性、一致性、隔離性、持久性）原子性：要么執(zhí)行，要么都不執(zhí)行一致性：所有數(shù)據(jù)都保持一致性狀態(tài)。隔離性：由并發(fā)事務所作的修改必須與任何其他并發(fā)事

17、務所作的修改隔離持久性：事務調度DBMS是數(shù)據(jù)庫系統(tǒng)中的“操作系統(tǒng)”，他負責人與數(shù)據(jù)庫之間的交互使人能夠對數(shù)據(jù)庫進行控制和使用.。在數(shù)據(jù)庫的控制和使用過程中，用戶現(xiàn)象DBMS發(fā)送操作指令，DBMS再將所有的操作分解并組織成事務來執(zhí)行。在實際的數(shù)據(jù)庫系統(tǒng)中，事務是很頻繁的，而且并發(fā)的情況是時有發(fā)生的，所以必須進行事務調度，并處理好并發(fā)機制。事務的特征：原子性（atomicty）:事務是相對獨立的一個邏輯體，對于一個成功的執(zhí)行，他必將全部完成；反之將一個操作都不執(zhí)行。一致性（Consistency）隔離性(Isolation):持久性（Durability）：事務的調度ü 串行調度

18、52; 并發(fā)調度并發(fā)執(zhí)行的正確性問題ü 丟失更新問題(Lost update)ü 不可重復讀取問題(Non-Repeatable Read)ü 臟數(shù)據(jù)問題（Dirty Read）ü 不一致分析問題怎樣的并發(fā)調度才是好的并發(fā)調度？ü 能夠做到與串行調度一樣的結果ü 保證DBMS每時每刻都在執(zhí)行某個操作ü 同時進行并發(fā)調度的事務保持在一個合理、適合的水平，既不太多，也不太少使用前趨圖可以對是否可以串行化調度進行判斷:構造調度優(yōu)先圖使用廣度優(yōu)先或者環(huán)度優(yōu)先算法進行環(huán)檢測.。如果，檢查出有向環(huán)，則是不可串行化調度；如果沒有檢測出環(huán)，

19、則是可串行化調度。制圖原則：事務A對某數(shù)據(jù)項的讀操作在事務B的寫操作之前；事務A對某數(shù)據(jù)項的寫作在事務B的讀作之前；事務A對某數(shù)據(jù)項的寫作在事務B的寫操作之前；一般的，在進行并發(fā)調度的時候，如果事務操作并不涉及同一個數(shù)據(jù)對象，則出現(xiàn)問題的可能性要小。并發(fā)控制技術ü 基于鎖的并發(fā)控制技術ü 基于時間戳的并發(fā)控制技術ü 多版本并發(fā)技術ü 確認并發(fā)控制技術ü 多粒度鎖技術ü 對索引進行鎖控制的并發(fā)控制技術基于鎖的并發(fā)控制：ü Exclusive Lock 排它鎖 X鎖 互斥鎖 獨占鎖：其他事務不能對該數(shù)據(jù)項進行任何操作 該事務只能

20、對其進行讀取操作ü Shared Lock共享鎖 S鎖 讀鎖 只能讀取 其他事務可以對該事務進行S鎖封鎖粒度在對操作數(shù)據(jù)對象進行封鎖操作時，會涉及數(shù)據(jù)項的大小問題，這被稱為封鎖粒度，簡稱鎖粒度?？蓪㈡i粒度大小依次劃分為：屬性值、屬性值集、記錄、表、索引項、整個索引、整個數(shù)據(jù)庫。大型數(shù)據(jù)庫-多粒度加鎖協(xié)議小型數(shù)據(jù)庫-單粒度加鎖協(xié)議封鎖協(xié)議：一級封鎖協(xié)議：進行寫入操作時才加鎖，只加互斥鎖，沒有共享鎖。二級封鎖協(xié)議：在一級封鎖協(xié)議的基礎上，要求在讀取數(shù)據(jù)前，必須加上共享鎖，讀取完成以后在釋放。三級封鎖協(xié)議：在一級封鎖協(xié)議的基礎上，要求事務在讀取數(shù)據(jù)錢，必須加上共享鎖，知道事務結束才釋放。一

21、級封鎖協(xié)議二級封鎖協(xié)議三級封鎖協(xié)議不一致分析問題丟失更新問題不可重復讀取問題臟數(shù)據(jù)問題兩段鎖協(xié)議ü 加速階段ü 解鎖階段例：數(shù)據(jù)庫系統(tǒng)處理死鎖一般采用哪兩類方法？死鎖預防：主要是通過采用死鎖預防機制杜絕死鎖產生的可能性。一種方法是事務一開始就將事務可能會操作的所有數(shù)據(jù)項和資源進行封鎖，但這種方法可行性較差；另一種方法是對事務的加鎖申請進行統(tǒng)計，并使用優(yōu)先級進行排序。死鎖預防機制：分為死鎖的檢測和恢復。檢測可以使用超時檢測和等待圖檢測。處理一般是破壞死鎖條件，讓處于死鎖的某些事務撤銷，使其釋放數(shù)據(jù)項或資源，過一段時間，再將撤銷的事務進行重新提交。死鎖與活鎖的相同點：死鎖和活鎖

22、都會使得議一些事務的執(zhí)行狀況處于停止不前的狀態(tài)。死鎖與活鎖的不同點：形成原因不同：死鎖是以鏈條死循環(huán)的形式等待資源；而活鎖中處于等待狀態(tài)的事務所等待的資源總是被其他事務搶占。系統(tǒng)狀態(tài)不同：死鎖會造成多個事務的循環(huán)等待；而活鎖中大多數(shù)事務都在正常進行，只有一個或者少數(shù)事務處于等待狀態(tài)。預防機制不同：死鎖的預防機制一方面不健全的，另一方面也是比較消耗資源的；而活鎖的預防機制相對簡單，只需要在調度策略中加上先來先服務機制即可。排除機制不同：死鎖需要將部分事務撤銷，以釋放數(shù)據(jù)項或者資源。而活鎖只需要將長期處于等待狀態(tài)的事務調度到下一輪執(zhí)行即可?；謴秃筒l(fā)控制的基本單位:事務數(shù)據(jù)庫系統(tǒng)4大故障:事務內部

23、故障、系統(tǒng)故障、介質故障、計算機病毒每種故障需要用不同的方法來處理事務故障系統(tǒng)故障(SOFT Crash)介質故障（HARD Crash）計算機病毒數(shù)據(jù)轉儲動態(tài)轉儲靜態(tài)轉儲常用的三種轉儲方式：完全轉儲、完全轉儲加增量轉儲（效率高）、完全轉儲加差量轉儲。（占用較少時間與空間）數(shù)據(jù)庫鏡像的用途：數(shù)據(jù)庫恢復 提高數(shù)據(jù)庫可用性關系數(shù)據(jù)庫操作語言SQL支持的數(shù)據(jù)類型Char:數(shù)據(jù)類型可用來存儲固定長度的普通編碼字符型數(shù)據(jù)。比如身份證號碼等數(shù)據(jù)。Varchar:用來存儲變長的普通編碼字符型數(shù)據(jù)。Text:用于存儲大量變長的普通編碼字符型數(shù)據(jù)Int:用于存儲之間的整數(shù)。CREAT TABLE 車輛信息 (車牌號CHAR(7)NOT NULLPRIMARY KEYCHECK(車牌號LIKE京A-Z0-90-90-90-90-9),車型CHAR(6)DEFULT轎車,發(fā)動機號CHAR(6)NOTNULL,行駛里程INT CHECK(行駛里程>=0),車輛所有人CHAR(8)NOT NULL,聯(lián)系電話CHAR(13)UNIQUE)CREATE TABLE 課表（課程號INTIDENTITY(1000,1)PRIMARYKEY,課程名CHAR(20)NOT NULLUNIQUE,學分TINYINTCHECK(學分>=1AND學分<