版權聲明：本文為CSDN博主「RanLZ」的原創文章，轉載請附上原文出處鏈接。

計算機三級 數據庫技術

---

第一章 數據庫應用系統開發方法

---

1.1 數據庫應用系統生命周期

1.1.1 軟件工程與軟件開發方法

瀑布模型

快速原型模型

螺旋模型

1.1.2 DBAS生命周期模型

$ps.$按照瀑布模型原理設計

$DBAS$ 的生命周期由以下五個基本活動組成:

項目規劃

需求分析

系統設計

實現與部署

運行與維護

$3$條設計主線:

數據組織與存儲設計

數據訪問與處理設計

應用設計

設計階段分為以下3個步驟：

概念設計

邏輯設計

物理設計

1.2 規劃與分析

1.2.1 系統規劃與分析

任務稱述

確定任務目標

確定系統范圍和邊界

確定用戶視圖

1.2.2 可行性分析

經濟可行性

技術可行性

操作可行性

開發方案選擇

1.2.3 項目規劃

確定項目的目標和范圍

更加 $DBAS$ 軟件開發模型，分解和定義整個項目包括的工作活動和任務

估算完成該項目的規模及所需各種資源

制定合理的 $DBAS$ 項目計劃

1.3 需求分析

需求獲取

需求分析

需求描述

規范說明

需求驗證

1.3.1 數據需求分析

描述用戶需要組織的信息內容形成數據字典。

數據字典包括以下五部分：

數據項

數據結構

數據流

數據存儲和處理過程

1.3.2 功能需求分析

描述系統要做什么。

1.數據處理需求分析

數據處理需求分析結果可表示為數據流圖 $(DFD)$ 或 $DBAS$ 應支持的各種數據處理事務規范。

事務規范包括以下幾方面的事物描述信息：

事務名稱。

事務描述。功能、性能、完整性約束等方面的描述。

事務所訪問的數據項。

事務用戶。啟動或執行該事務的事件或用戶。

數據需求分析與數據處理需求分析的結果組織在一起，可以構成數據字典文檔，該文檔也被成為數據規范說明書。

2.業務規則需求分析

應用領域業務規則（又稱為業務處理邏輯、業務邏輯）描述了應用領域中的業務功能、處理流程和步驟。

1.3.3 性能描述

描述系統應當做到什么程度。

$DBAS$ 性能指標：

數據操作響應時間，或數據訪問響應時間。

系統吞吐量。

運行并發訪問的最大用戶數。

每 $TPS$ 代價值。

影響 $DBAS$ 性能的主要因素：

系統的硬件資源。

網絡通信設備性能。

操作系統環境。

數據庫的邏輯設計和物理設計質量。

$DBMS$ 的配置和性能。

數據庫應用程序自身。

1.3.4 其他需求分析

1.存儲需求分析

初始數據庫大小。

數據庫增長速度。

2.安全性需求分析

$DBAS$ 系統應達到的安全控制級別。

各類用戶的數據視圖和視圖訪問權限。

$DBAS$ 應有的口令保護機制或者其他安全認證機制。

3.備份和恢復需求分析

$DBAS$ 運行過程中備份數據庫的時間和備份周期。

備份數據是備份全部數據，還是其中的一部分。

備份方式是采用完全備份還是采用差異備份。

1.4 系統設計

如果需求分析階段的任務是解決“干什么”的問題，那么系統設計階段的任務是確定”怎么干“。

1.4.1 概念設計

1.數據庫概念模型設計

數據庫概念模型可能采用多種方式表示，如最常見的 $ER$ 方法。

2.系統總體設計

$DBAS$ 體系結構設計。

$DBAS$ 系統硬件平臺的選型和配置。

應用軟件結構設計。

業務規則初步設計。

對系統關鍵技術進行方案選型和初步設計。

1.4.2 邏輯設計

數據庫邏輯結構設計。

應用程序概要設計。

數據庫事務概要設計。

1.4.3 物理設計

數據庫物理結構設計。

數據庫事務詳細設計。

應用程序詳細設計。

1.5 實現與部署

建立數據庫結構。

數據加載。

事務和應用程序的編碼及測試。

系統集成、測試與試運行。

系統部署。

1.6 運行管理與維護

主要包括日常維護、系統監控與分析、系統性能優化調整、系統進化升級等。

---

第二章 需求分析

---

2.1 需求分析

2.1.1 需求分析的概念與意義

需求分析是描述待開發的系統所要完成的功能。

目標是深入描述軟件的功能和性能，確定軟件設計的約束和軟件同其他系統元素接口細節，定義軟件的其他有效需求。

軟件產品的下列特性使得需求獲取困難重重：

軟件功能復雜

需求的可變性

軟件產品的不可見性

通常，一個計算機應用系統的需求分析工作是在系統分析人員與用戶不斷交互的過程中完成的。

2.1.2 需求獲取的方法

面談

實地觀察

問卷調查

查閱資料

2.1.3 需求分析過程

標識問題

建立需求模型

描述需求
1). 需求概述
2). 功能需求
3). 信息需求
4). 性能需求
5). 環境需求
6). 其他需求

確認需求
需要評審委員會審核下列內容：
1). 功能需求
2). 數據需求
3). 性能
4). 數據管理
5). 其他需求

2.2 需求分析方法

2.2.1 需求分析方法概述

結構化分析與功能建模方法主要有 $DFD$ 、$IDEF0$ 等。

結構化分分析方法的基本特征是 抽象 和 分解。

結構化分析及建模方法的主要優點是：

不過早陷入具體的細節。

從整體或宏觀入手分析問題。

通過圖像化的模型對象直觀地表示系統要做什么，完成什么功能。

圖像化建模方法方便系統分析員理解和描述系統。

模型對象不涉及太多技術術語，便于用戶理解模型。

2.2.2 DFD需求建模方式

$DFD$ 建模方法的核心是 數據流。

1.DFD方法的基本元素

數據流。數據流用一個箭頭描述數據的流向，箭頭上標注的內容可以是信息說明或數據項。

處理。在圖中用矩形框表示。指向處理的數據流為該處理的輸入數據，離開處理的數據流為該處理的輸出數據。

數據存儲。對其進行的存取分別以指向或離開數據存儲的箭頭表示。

外部項(也稱數據源或數據終點)。以圓角框或平行四邊形表示。

2.DFD圖

采用自頂向下逐步細化的結構化分析方法表示目標系統。

3.DFD建模過程

明確目標，確定系統范圍。

建立頂層 $DFD$ 圖。

構建第一層 $DFD$ 分解圖。

開發 $DFD$ 層次結構圖。

保持均勻的模型深度。

按困難程度進行選擇。

如果一個處理難以確切命名，可以考慮對它重新進行分解。

檢查確認 $DFD$ 圖。

父圖中描述過的數據流必須要在相應的子圖中出現。

一個處理至少有一個輸入流和一個輸出流。

一個存儲必定有流入的數據流和流出的數據流。

一個數據流至少有一端是處理框。

模型圖中表達和描述的信息是全面的、完整的、正確的、一致的。

2.2.3其他需求建模方法

1.IDEF0方法簡介

$IDEF0$ 描述系統功能及相互關系；

$IDEF1$ 描述系統信息及其數據之間的聯系；

$IDEF2$ 用于系統模擬，建立動態模型。

組成 $IDEF0$ 圖的基本元素是矩形框和箭頭。

矩形框代表功能活動，寫在矩形框中的動詞短語描述功能活動的名稱，活動的編號按照要求寫在矩形框右下角指定位置。

• 左側輸入箭頭表示活動需要的數據；
• 矩形框上方控制箭頭描述了影響這個活動執行的事件或約束條件；
• 右邊輸出箭頭說明由活動產生的結果和信息；
• 下方的進入的機制箭頭表示實施該活動的物理手段或完成活動需要的資源（計算機系統、人或組織）。

輸入與控制二者的作用是有區別的，輸入強調被活動消耗或變化的內容，而控制強調對活動的約束條件。

每個箭頭所表示的數據用一個名詞短語描述，數據可以是信息或對象。

2.UML用例模型簡介

$UML$ 方法采用面向對象思想建模，其中的用例模型用于描述系統功能需求。

2.2.4 DFD與IDEF0比較

在 $IDEF0$ 圖中箭頭不是強調流或順序，而是強調數據約束。

相對 $DFD$ 圖，$IDEF0$ 圖中的箭頭有更加豐富的語義，不僅能夠表示出數據流，還可以表示出控制流和說明處理或活動實例方式的一些約束。

兩個模型的組成元素更簡單，$IDEF0$ 模型結構更清楚，容易理解，更適合用于大型復雜系統的需求建模。

---

第三章 數據庫結構設計

---

3.1 數據庫概念設計

概念設計是數據庫設計的核心環節。通過對用戶需求進行綜合、歸納與抽象，形成一個獨立于具體DBMS的概念模型。

3.1.1 概念設計的任務

定義和描述應用領域涉及的數據范圍。

獲取應用領域或問題領域的信息模型。

描述清楚數據的屬性特征。

描述清楚數據之間的關系。

定義和描述數據的約束。

說明數據的安全性要求。

支持用戶的各種數據處理需求。

保證信息模型能轉化成數據庫的邏輯結構(即數據庫模式)。

3.1.2 概念設計的依據及過程

1.概念設計的依據

依據：數據庫概念設計以需求分析的結果為依據，即說明書、$DFD$ 圖以及需求階段收集到的應用領域中的各類報表等。

結果：概念設計需要構造信息模型( $ER$ )與編寫概念設計說明書。

2.概念設計的過程

明確建模目標。（確定模型覆蓋的問題范圍）

定義實體集。(自底向上標識和定義實體集）

定義聯系。（實體間關聯關系）

建立信息模型。（構造 $ER$ 模型）

確定實體集屬性。（屬性描述一個實體集的特征或性質）

對信息模型進行集成與優化。（檢查和消除命名不一致、結構不一致等）

概念設計是 $DB$ 設計的核心環節。概念數據模型是對現實世界的抽象和模擬。

3.1.3 數據建模方法

1.ER建模方法

實體或實例：客觀存在并可相互區分的事物叫實體。

實體集：同型實體的集合稱為實體集。

屬性：實體所具有的某一特性。一個實體可以由若干個屬性來刻畫。每個屬性的取值范圍稱為域。

碼：實體集中能唯一標識每一個實例的屬性或屬性組稱為該實體集的碼。用來區別同一實體集中的不同實體的稱為主碼。

聯系：描述實體之間的相互關系，聯系也可以有屬性。同類聯系的集合稱為聯系集。

• 一對一聯系（1：1）
• 一對多聯系（1：n）
• 多對多聯系（m：n）

符號
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-dg1Rovot-1581409962530)(en-resource://database/1977:0)]

2.IDEF1X建模方法（了解）

$IDEF1X$ 側重分析、抽象和概括應用領域中的數據需求，被稱為數據建模方法。

3.2 數據庫邏輯設計

3.2.1 概述

數據庫邏輯設計的任務是把數據庫概念設計的結果（ $ER$ 模型），轉換為具體的數據庫管理系統支持的數據模型。

3.2.2 個人補充

1.關系模型

關系模型就是用二維表結構來表示實體及實體之間聯系的模型。

關系的描述稱為關系模式。關系模式由五部分組成，即它是一個五元組：R(U,D,DOM,F)。

• R：關系名。
• U：組成該關系的屬性名集合。
• D：屬性組U中屬性所來自的域。
• DOM：屬性到域的映射
• F：屬性組U上的一組數據依賴。

由于 $D$ 、$DOM$對模式設計的關系不大，這里把關系模式簡化為一個三元組：R<U,F>

當且僅當 $U$上的一個關系 $R$ 滿足 $F$ 時，$R$ 稱為關系模式 $R<U,F>$ 的一個關系

關系數據庫設計的核心：關系模式的設計。

2.數據依賴

定義：設 $R(U)$ 是一個屬性集 $U$ 上的關系模式，$X$ 和 $Y$ 是 $U$ 的子集。若對于 $R(U)$ 的任意一個可能的關系 $r$ , $r$ 中不可能存在兩個元組在 $X$ 上屬性組相等，而在 $Y$ 上的屬性值不等，則稱“X函數確定Y”或“Y函數依賴于X”，記作$X\to Y$。

2.1函數依賴

普遍存在于生活中，這種依賴關系類似于數學中的函數 $y=f(x)$，自變量x確定之后，相應的函數值y也就唯一地確定了。

2.2多值依賴

教師號可能多值依賴課程號，因為給定一個（課程號，參考書號）的組合，可能有對應多個教師號。這是因為多個老師可以使用相同或不同的參考書上同一門課。

簡單點講，函數就是唯一確定的關系；多值依賴卻。

2.3函數依賴的幾種特例

2.3.1 平凡函數依賴與非平凡函數的依賴

如果$X\to Y$，且$Y?X$，則 $X\to Y$ 稱為非平凡函數依賴。

若$Y?X$，則稱 $X\to Y$ 為平凡函數依賴。

由于$Y?X$時，一定有 $X\to Y$，平凡函數依賴必然成立，沒有意義，所以一般所說的函數依賴總是指非平凡函數依賴。

2.3.2 完全函數依賴與部分函數依賴

完全函數依賴：

成績依賴于學號和課程號兩個字段的組合；但只知道學號無法確定成績，同理只知道課程號也無法確定成績；只有學號和課程號組合在一起才能標識哪個學生哪門課程的成績；

因此 (學號,課程號) $\to$ 成績 是“完全函數依賴”。

部分函數依賴:

姓名、性別和班級三個屬性只依賴于主鍵中的學號，與“課程號”無關。

因此（學號，課程號) $\to$ 姓名 是“部分函數依賴”。

課程名和學時數只依賴于課程號，

因此（學號，課程號) $\to$ 課程名 是“部分函數依賴”。

2.3.3 傳遞函數依賴

班主任依賴于班級，與學號無關，與課程號也無關。又因班級依賴于學號，所以班主任間接依賴于學號。

因此，（學號，課程號） $\to$ 班主任 是“傳遞函數依賴”。

3.候選碼、主碼、外碼

如果某屬性組的值能唯一確定整個元組的值，則稱該屬性組為候選碼或侯選關鍵字。

候選碼如果有多個，可以選其中的一個作為主碼。

屬性或屬性組 $X$ 不是關系模式 $R$ 的碼（不是主碼或候選碼），但 $X$ 是另一個關系模式的碼，則稱 $X$ 是 $R$ 的外部碼，也稱外碼 。

4.范式

關系模式滿足的約束條件稱為范式。根據滿足規范化的程度不同，范式由低到高分為1NF，2NF，3NF，BCNF，4NF，5NF。

• 1NF：如果關系模式 $R$ ，其所有屬性都是不可再分的基本數據項，則稱 $R$ 屬于第一范式，$R\in 1NF$。
• 2NF：如關系模式 $R\in 1NF$，且每個非主屬性完全函數依賴于主碼，則稱 $R$ 屬于第二范式，$R\in 2NF$。
• 3NF：如果關系模式 $R$ 為 $2NF$ ，并且 $R$ 中的每個非主屬性不傳遞依賴于 $R$ 的主碼，則稱關系 $R$ 是屬于第3范式的，$R\in 3NF$。
• BCNF：滿足3NF且不允許主鍵的一部分被另一部分或其它部分所決定（即滿足3范式，并且主屬性之間沒有依賴關系）。

3.3 數據庫物理設計

3.3.1 物理設計概述

概述：物理數據庫設計是設計數據庫的存儲結構和物理實現方法。

目的：將數據的邏輯描述轉換為實現技術規范，設計數據存儲方案，以便提供足夠好的性能并確保數據庫數據的完整性、安全性、 可靠性。

3.3.2 數據庫的物理結構

物理設備上的存儲結構與存取方法稱為數據庫的物理結構 。

數據庫中的數據以文件形式存儲在外設存儲介質上。

一個文件在物理上可看作是存放記錄的一系列磁盤塊組成的，成為物理文件。

數據庫的物理結構需要解決如下問題：文件組織、文件結構、文件存取、索引技術。

3.3.3 索引

索引是數據庫中獨立的存儲結構，其作用是提供一種無須掃描每個頁面（存儲表格數據的物理塊）而快速訪問數據頁的方案。

1.索引技術

索引技術是一種快速數據訪問技術。

索引技術的關鍵：建立記錄域取值到記錄的物理地址間的映射關系，即索引。

2.索引技術分類

有序索引技術：也被稱為索引文件機制。利用索引文件實現記錄域取值到記錄物理地址之間的映射關系。記錄域就是查找碼，查找碼也稱排序域。

散列技術：也稱哈希索引機制。散列技術利用一個散列函數實現記錄域取值到記錄物理地址間的直接映射關系。這里記錄域就是查找碼，也稱散列函數的排序域或散列域

3.有序索引

聚集索引和非聚集索引

• 聚集索引：數據文件中數據記錄的排列順序與索引文件中索引項的排列順序一致，或者說索引文件中按照其查找碼指定的順序與數據文件中數據文件的排列順序相一致。
• 非聚集索引：數據文件中數據記錄的排列順序與索引文件中的索引項的排序不一致。
• 一個數據文件只可建立一個聚集索引，但可建立多個非聚集索引。

稠密索引與稀疏索引

• 稠密索引：數據文件中每個查找碼在索引文件中都對應一個索引記錄。
• 稀疏索引：只是一部分查找碼的值有對應的索引記錄。

主索引與輔索引

• 主索引：在數據文件的主碼屬性值上建立的索引
• 輔索引：在數據文件的非主屬性上建立的索引

唯一索引：可以確保索引列不包含重復的值。在多列唯一索引的情況下，可確保每個值的組合是唯一的。

單層索引和多層索引：當數據文件很大時，即使采用稀疏索引，建立的索引文件也會很大。可以對索引項本身再建立起一級稀疏索引，組成二層索引結構多層索引的典型例子是B數和B+樹索引。

3.3.4 數據庫物理設計

目標：目標是得到存儲空間占用少，數據訪問效率高和維護代價低的數據庫物理模式。

1. 物理設計內容

數據庫邏輯模式描述：根據數據庫邏輯結構信息設計目標DBMS可支持的關系表（這里稱為基本表）的模式信息。

文件組織與存取設計：根據應用情況將易變部分與穩定部分、存取頻率較高部分與存取頻率較低部分分開存放，以提高系統性能。

數據分布設計

確定系統配置

物理模式評估

影響數據文件存儲結構的因素：

• 存取時間
• 存儲空間利用率
• 維護代價
• ps.這三個方面常常是相互矛盾的

解決辦法：

• 適當冗余
• 增加聚簇功能
• ps.必須進行權衡，選擇一個折中方案。

2. 數據庫邏輯模式描述

面向目標數據庫描述基本表和視圖

設計基本表業務規范

3.DB文件組織與存儲設計

使用事務-基本表交叉引用矩陣

估計各事務的執行頻率，即單位時間內事務的執行次數

對于每張基本表，匯總所有作用于該表上的各事務的操作頻率信息，得到如下數據訪問估計信息：該表是否被頻繁訪問，該表中哪些屬性列的訪問頻率較高和作用于這些屬性上的操作類型和查詢條件類型（等值查詢，范圍查詢）

3.1基本表選擇合適的文件結構的原則：

如果數據庫中的一個基本表中的數據量很少，并且插入、刪除、更新等操作很頻繁，該基本表可以采用堆文件組織方式。堆文件無需建立索引，維護代價非常低，向表中加載數據訪問效率較低，但在數據量較少時，定位文件記錄的時間非常短。當需要向新創建的基本表批量加載數據時，可將表的文件結構優先選為堆文件，向表中加載數據后重新調整文件結構，如改為數據查詢效率更高的B+樹文件。

順序文件支持基于查找碼的順序訪問，也支持快速的二分查找。如果用戶的查詢條件定義在查找碼上，則順序文件是比較合適的文件結構

如果用戶查詢是基于散列域值的等值匹配，特別是如果訪問順序是隨機的，則散列文件比較合適，但散列文件組織不適合下列情況：

• 基于散列域值的非精確查詢（模糊查詢，范圍查詢）
• 基于非散列域的查詢

B樹和B+樹文件是實際數據庫系統中非常廣泛的索引文件結構，適合于定義在大數據量基本表上、基于查找碼的等值查詢、范圍從查詢、模糊查詢和部分查詢。B樹和B+樹屬于動態索引，可以隨著數據文件的內容變化不斷調整，保證數據查詢的性能不會惡化。
5.如某些頻繁執行且需要進行多表連接的操作的查詢，可以考慮將這些基本表組織為聚集文件，以改善查詢效率。

3.2一個基本表建立索引的原則：

對于經常需要進行查詢、連接、統計操作的，且數據量較大的可以考慮建立索引；而對于經常進行插入、刪除、更新操作或小數據量的基本表應盡量避免建立索引 。

一個表上除了可以建立一個聚集索引外還可以建立多個非聚集索引。多個索引為用戶提供了多個查找碼快速訪問文件的手段。但是索引越多，對表內數據更新時維護索引所需要的開銷就越大。因此對于一個更新頻繁的表應該不建或減少索引。

索引可以由用戶根據需要隨時創建或刪除，以提高數據查詢性能。

3.3對于基本表可以考慮在下面屬性上建立索引：

表的主碼（大部分關系型數據庫會自動會為主碼建立唯一索引）。

在where查詢子句中引用率較高的屬性。

參與連接操作的屬性。

在Order by子句、group by子句中出現過的屬性。

在某一范圍內頻繁搜索的屬性，但只有當使用索引查詢其結果不超過記錄總數20%時索引才有明顯效果。

如果where子句中同時包含一個表的多個屬性，則可以考慮為這些屬性建立多屬性索引；如果數據庫文件需要頻繁執行精確匹配查詢（等值查詢），則可以考慮建立散列索引，而B+樹等有序索引更適合于范查詢。

當一個屬性有較多的不同值時，使用索引有明顯的作用；當一個屬性的不同值很少時，使用索引沒有好處。

對于包含大量空值的屬性建立索引要仔細考慮，因為很多數據庫管理系統中的索引不引用具有空值的行，對空值的查找要使用全表掃描來實現。

4.數據分布設計

4.1不同類型數據的物理分布

數據庫備份數據、日志文件備份數據用于故障恢復，使用頻率低且數據量大，可以存儲在磁帶中。而應用數據、索引和日志使用頻繁，要求響應時間短，必須放在支持直接存取的磁盤存儲介質上。

4.2應用數據的劃分與分布

• 根據數據的使用特征劃分（頻繁使用分區和非頻繁使用分區）
• 根據時間、地點劃分（時間或地點相同的屬于同一分區）
• 分布式數據庫系統（DDBS）中的數據劃分（水平劃分或垂直劃分）
• 派生屬性數據分布（增加派生列或不定義派生屬性）
• 關系模式的去規范化（降低規范化提高查詢效率）

4.3派生屬性劃分

派生屬性指該屬性取值可以根據表中其他屬性的取值唯一確定。

44關系模式去規范化

在數據庫物理設計階段，可以根據實際需要對數據庫中某些3NF、BCNF模式考慮是否可以降低其規范化程度，以提高查詢效率。

3.3.5其他物理設計環節

確定系統配置：數據庫配置參數（如允許同時使用數據庫的用戶數、允許同時打開數據庫對象數、數據庫初始空間大小），磁盤塊使用參數，內存緩存區參數（如緩存區個數和大小），時間片大小，裝填因子，鎖的大小。

物理模式評估：對數據庫物理設計結果從存取時間、存儲空間、維護代價等方面進行評估，重點是時間和空間效率。

---

第四章 數據庫應用系統功能設計與實施

---

4.1 軟件體系結構與設計過程

4.1.1 軟件體系結構

軟件體系結構又稱軟件架構，軟件體系結構 = {構件，連接件，約束}。

軟件體系結構是軟件系統中最本質的東西。良好的體系結構必須是普適、高效和穩定的。

軟件體系結構有多種風格和類型 ，如分層體系結構、模型-視圖-控制器（$MVC$ ）體系結構、客戶端/服務器體系結構等。

4.1.2 軟件設計過程

• 軟件開發由設計、實現、測試三個環節組成，設計又包含概要設計和詳細設計。
• 概要設計的任務是進行軟件總體結構設計，可采用層次結構圖建立軟件總體結構圖。
• 詳細設計的任務是進行數據設計、過程設計及人機界面設計。
• 設計原則：模塊化、信息隱藏、抽象與逐步求精。
• 軟件設計可選用結構化設計方法、面向對象設計方法或面向數據設計方法等。

4.2 DBAS總體設計

DBAS總體設計的任務是確定系統總體框架， 主要內容包括：

• DBAS體系結構設計；
• 軟件體系結構設計；
• 軟件硬件選型與配置設計；
• 業務規則初步設計。

4.2.1 DBAS體系結構設計

將系統從功能、層次/結構、地理分布等角度進行分解，劃分為多個子系統，定義各子系統功能；設計系統的全局控制，明確各子系統間的交互和接口關系。

1.客戶/服務器體系結構（C/S）

$C/S$ 結構將數據庫管理功能與數據庫應用相分離，將 $DBMS$ 數據管理功能在客戶端和服務器之間進行合理的分布和配置。其中數據庫服務器完成DBMS核心功能。而客戶端或應用服務器則負責完成用戶交互功能，接受用戶數據，根據業務規則處理應用任務，生成并向數據庫服務器發出數據操作請求，然后從數據庫服務器接受數據查詢結果并通過客戶端反饋給用戶。

兩層 $C/S$ 結構的數據庫應用系統，其特點：

• $DBAS$ 的數據管理和數據處理功能被分解并分布在客戶端和數據庫服務器上。客戶端人機交互，數據庫服務器數據管理。
• 數據庫服務器可以為多個客戶端應用提供共享的數據管理功能，避免了為每一個新的應用單獨開發對應的服務器端數據管理功能，提高了應用程序相對于數據庫的獨立性，減少了應用程序的開發和維護代價。
• 客戶端可以通過網絡訪問多個不同數據源。
• 客戶端除了完成人機交互功能外，還需要完成面向應用的數據處理功能，負荷較重，屬于典型的胖客戶端。

2. 瀏覽器/服務器結構（B/S）

三層瀏覽器/服務器（ $B/S$ ）結構，數據處理功能分解并分布在表示層、功能層和數據層三個層次上，分別由 $Web$ 瀏覽器、$Web$ 應用服務器和數據庫服務器來實現，其特點是：

• 表示層位于客戶端，由Web瀏覽器實現。客戶端功能單一，一般只安裝 $Web$ 瀏覽器。沒有其他用戶應用程序，屬于典型的瘦客戶端。
• 功能層位于 $web$ 應用服務器，實現面向具體應用領域的業務規則。
• 數據層位于數據庫服務器，通過 $DBMS$ 完成具體的數據存儲和數據存取等數據管理功能。

三層 $B/S$ 結構將人機交互、應用邏輯處理和數據管理三類功能相互分離，提高了系統的可維護性。

4.2.2 DBAS軟件總體設計

應用軟件總體設計得到的系統總體結構和分層模塊結構可以用模塊結構圖表示。

4.2.3 軟硬件選型與配置設計

為保證DBAS功能性能順利實現，總體設計階段需要對軟硬件設備做出合理選擇，并進行初步配置設計。
軟硬件選型涉及內容包括：

• 網絡及網絡設備選型。
• 數據存儲設備及備份方案制定。
• 應用服務器、Web服務器選型。
• 確定系統終端軟件環境。
• 確定軟件平臺及開發語言、工具。
• 系統中間件及第三方軟件選型。

考慮以下因素：

• 數據規模：數據量大小、數據增長速度。
• 系統性能：系統響應時間、并發訪問需求、系統吞吐量、實時性需求、峰值時系統響應速度。
• 安全可靠性：數據安全性、數據傳輸安全性、系統訪問安全性、設備可靠性。
• 用戶需求：用戶的特性化需求。
• 項目預算情況。

4.2.4 業務規則初步設計

任務：從系統的角度，規劃 $DBAS$ 的業務流程，使之符合客戶的實際業務需要。

DBAS的各項業務活動具有邏輯上的先后關系，可將它們表示成一個操作序列，并用業務流程圖表示。

4.3 DBAS功能概要設計

在總體設計結果基礎上，將DBAS應用軟件進一步細化為模塊/子模塊，組成應用軟件的系統-子系統-模塊-子模塊層次結構，并從結構、行為、數據三方面進行設計。

功能角度DBAS系統通常劃分四個層次實現：

• 表示層：負責所有與用戶交互的功能。
• 業務邏輯層：負責根據業務邏輯需要將表示層獲取的數據進行組織后，傳遞給數據訪問層，或將數據訪問層獲取的數據進行相應的加工后傳遞給表示層用于展示。
• 數據訪問層：負責與DBMS系統進行交互，提取或存入應用系統所需的數據。
• 數據持久層：負責保存和管理應用系統數據。

4.3.1 表示層概要設計

人機界面設計，影響系統易用性。目前第四代是 $WIMP$（窗口、圖標、菜單、指示器）與 $Web$ 技術、多任務處理技術相結合。

設計原則：

• 用戶應當感覺系統的運行始終在自己控制下。
• 當系統發生錯誤或程序運行時間長時應該提供有意義的反饋信息。
• 一個好的用戶界面應該容忍用戶的各種操作錯誤。
• 用戶界面應該遵循一定的標準和常規。
• 用戶界面應采取靈活多樣的數據輸入方式，盡量減少用戶的輸入負擔。
• 使用 $web$ 界面設計應具有簡潔性；清晰分類信息，導航；界面一致性；界面美觀與交互性能折中平衡。

4.3.2 業務邏輯層概要設計

設計原則：高內聚低（松）耦合，即構件單一原則；構件獨立功能；接口簡單明確；構件間關系簡單，過于復雜，就細化，分解。

高內聚和松耦合是相互矛盾的，分解程度越粗的系統耦合性越低，分解越細的系統內聚度越高。

設計內容：結構，行為，數據，接口，故障處理、安全設計，系統維護和保障等。

4.3.3 數據訪問層概要設計

任務：針對 $DBAS$ 的數據處理需求設計用于操作數據庫的各類事務。

事務概要設計核心在于辨識和設計事務自身處理邏輯，注重流程，不考慮與平臺相關、具體操作方法和事務實現機制。

一個完整的事務概要設計包括事務名稱、訪問的關系表及其數據項、事務邏輯（事務描述）、事務用戶（使用、啟動、調用該事務的軟件模塊和系統）。

4.3.4 個人補充

• 事務：事務（Transaction）是訪問并可能更新數據庫中各種數據項的一個程序執行單元（unit）。
• 事務的特性：原子性、一致性、隔離性、持續性。稱為ACID特性。
• 原子性（atomicity）。一個不可分割的工作單位。
• 一致性（consistency）。從一個一致性狀態變到另一個一致性狀態。
• 隔離性（isolation）。執行不能被其他事務干擾。
• 持久性（durability）。永久性（permanence），指一個事務一旦提交，它對數據庫中數據的改變就應該是永久性的。

4.4 DBAS功能詳細設計

4.4.1 表示層詳細設計

人機界面采用原型迭代法合適，三個步驟：

• 初步設計：設計人機交互命令系統并優化。（總體設計）
• 用戶界面細節設計。如組織形式、風格、彩色，操作方式。（概要設計）
• 原型設計與改進（詳細設計）

4.4.2 業務邏輯層詳細設計

設計各模塊內部處理流程和算法、具體數據結構、對外詳細接口等。

4.5 應用系統安全結構設計

4.5.1 數據安全設計

• 安全性保護：防止非法用戶對數據庫的非法使用，避免數據泄露、篡改或破壞。
• 完整性保護：保證數據源的正確性、一致性和相容性。
• 并發性控制：保證多個用戶能共享數據庫，并維護數據一致性。
• 數據備份與恢復：系統失效后的數據恢復，配合定時備份數據庫，不丟失數據。
• 數據加密傳輸：將一些高級的敏感數據通過一定的加密算法后傳輸。

1.數據庫安全性保護

主要保護方式：

• 用戶身份鑒別：Windows身份驗證、SQL身份驗證。
• 權限控制：對后臺數據庫是不同用戶對數據的不同存取需求設置不同權限；對前臺 程序是為每個合法用戶設定權限等級，外部用戶設置有限查詢功能。
• 視圖機制：通過視圖機制把保密數據對無權用戶隱藏。

2.數據庫的完整性保護

數據庫的完整性指數據庫中數據的正確性、一致性及相容性。

方法：設置完整性檢查，即對數據設置一些約束條件（如實體完整性、參考完整性、用戶自定義完整性）。

完整性約束條件作用對象：列（類型、范圍、精度、排序）、元組（記錄中各屬性之間的聯系約束）、關系（若干記錄間、關系集合與集合之間的聯系）三種級別。

DBAS中，完整性約束功能包括完整性約束條件設置和檢查。

3.數據庫的并發控制

并發訪問：事務在時間上重疊執行。

常用技術：封鎖技術，一段時間禁止某用戶對數據對象做某些操作以避免數據不一致的問題。

基本的封鎖一般包括排他鎖（$X$ 鎖）和共享鎖（$S$ 鎖）兩種類型。

• 排它鎖（簡記為 $X$ 鎖），寫鎖，若事務 $T$ 對數據對象 $A$ 加上 $X$ 鎖，則只允許 $T$ 讀取和修改 $A$ ，其它任何事務都不能再對 $A$ 加任何類型的鎖，直到 $T$ 釋放 $A$ 上的鎖. 排它鎖保證了其它事務在 $T$ 釋放 $A$ 上的鎖之前不能再讀取和修改 $A$。
• 共享鎖（簡記為 $S$ 鎖），讀鎖，若事務 $T$ 對數據對象 $A$ 加上 $S$ 鎖，則其它事務只能再對 $A$ 加 $S$ 鎖，而不能加 $X$ 鎖，直到 $T$ 釋放 $A$ 上的 $S$ 鎖。共享鎖保證了其它事務可以讀 $A$ ，但在 $T$ 釋放 $A$ 上的 $S$ 鎖之前不能對 $A$ 做任何修改。

不可避免帶來死鎖問題，可以考慮以下原則：

• 按同一順序訪問資源。
• 避免事務中的用戶交互。
• 采取小事務模式，盡量縮短事務的長度，減少占有鎖時間。
• 盡量使用記錄級別的鎖（行鎖），少用表級別的鎖。
• 使用綁定連接，使同一應用所打開的兩個或多個連接可以相互合作。次級連接獲得的任何鎖可以像由主連接獲得的鎖那樣持有，反之亦然，因此不會相互阻塞。

4.數據庫的備份與恢復

數據庫恢復的基本原理：利用存儲在系統其他存儲器上的冗余數據（即數據備份）來重建。
數據庫備份與恢復策略：

• 雙機熱備（基于Active/Standby方式的服務器熱備）。
• 數據轉儲（也稱為數據備份）。
• 數據加密存儲（針對高敏感數據）。

5.數據加密傳輸

常見的數據加密傳輸手段：

• 數字安全證書
• 對稱密鑰加密
• 數字簽名
• 數字信封

實施：購買第三方中間件產品整合是一個快速有效的解決方案。

4.5.2 環境安全設計

• 漏洞與補丁：定期查找漏洞更新補丁。
• 計算機病毒防護：殺毒軟件；實時監控。
• 網絡環境安全：防火墻；入侵檢測系統；網絡隔離（邏輯隔離與物理隔離）。
• 物理環境安全 ：如防盜設施；UPS；溫濕度報警器等。

4.5.3 制度安全設計

管理層面安全措施。

4.6 DBAS實施

DBAS實施階段主要包括以下工作：

創建數據庫
考慮因素：初始空間大小；數據庫增量大小；訪問性能（如并發數，訪問頻率）

數據裝載
步驟：篩選數據—轉換數據格式—輸入數據—校驗數據

編寫與調試應用程序

數據庫系統試運行（功能測試與性能測試）

4.6.1 創建數據庫

數據定義語言DDL.

創建數據庫應該考慮：

• 初始空間大小
• 數據庫增量大小
• 訪問性能

4.6.2 數據裝載

• 篩選數據
• 轉換數據格式
• 輸入數據
• 檢驗數據

4.6.3 編寫與調試應用程序

4.6.4 數據庫系統試運行

功能測試

性能測試

應該先測試DBMS的恢復功能，做好數據庫轉儲和恢復工作。

---

第五章 UML與數據庫應用系統

---

5.1 DBAS建模

5.1.1 統一建模語言（UML）

$UML$ 是一種基于面向對象的可視化的通用($General$ )建模語言，該方法結合了 $Booch$ , $OMT$ , 和 $OOSE$ 方法的優點，統一了符號體系，并從其它的方法和工程實踐中吸收了許多經過實際檢驗的概念和技術。

UML只是一種建模語言，不是一種建模方法。

建模方法應包括建模語言和建模過程兩部分:

建模語言：提供這種方法用于表示建模結果的符號。（圖形符號：可視化）

建模過程：描述建模時需要遵循的步驟。

UML由語義（自然語言）與表示法（可視化標準符號）組成。
其語義定義在一個四層建模概念框架中：

• 元元模型（Meta-Meta Model），代表要定義的所有事物。
• 元模型（ Meta Model ），UML的基本元素 ，“事物”概念的實例。
• 模型層（ Model ），UML的模型，類模型或類型模型。
• 用戶模型（ User Model ），UML模型的實例，對象模型或實例模型。

視圖是對系統的模型在某方面的投影，注重于系統的某個方面。

UML中包括五種視圖：

• 結構視圖、
• 實現視圖、
• 行為視圖、
• 環境視圖、
• 用例視圖。

UML2.0有十三種不同的圖：

• 結構圖：類圖，對象圖，復合結構圖，包圖，組件圖，部署圖
• 行為圖：用例圖，交互圖（順序圖、通信圖、交互概述圖、時間圖）、狀態圖和活動圖

5.2 DBAS業務流程與需求表達

5.2.1 業務流程與活動圖

活動圖主要描述系統、用例和程序模塊中邏輯流程的執行次序，并行次序。最適合描述系統或子系統的工作流程。

活動圖用于低層次程序模塊的作用類似于流程圖，但活動圖可以描述并行操作，而流程圖只能描述串行操作。

一張活動圖中有且只能有一個起點，可有多個結束點。

• 起始點：指一連串活動的開始點。在一張活動圖中，必須有且只有一個起始點。
• 結束點：指一連串活動的終點。在一張活動圖中，可以有多個結束點。
• 加粗直線為同步條，表示這之后的活動路線可以并行執行，或在其上的所有并行活動執行完畢后，到此轉為順序執行。
• 分區：在整個活動表達上，是一個非常重要的概念。可以利用分區來將活動分配給對應的角色。

5.2.2 系統需求與用例圖

系統需求：用戶心中的真正期望。

用例模型是把滿足用戶需求的所用功能表示出來的工具。

用例模型由用例、角色和系統三部分組成。

• 系統：各種用例的“黑匣子”。
• 角色：與系統交互的人或其他實體。
• 用例：完整功能所有動作（一次操作）集合。

1.角色之間的關系

通用化關系：指把某些角色的行為抽取出來作為通用行為，這些通用行為構成超類。

角色是與系統交互的人或其他實體。所謂“與系統交互”指的是角色從系統中接收消息，或是向系統提交消息。一個角色可以執行多個用例，反過來，一個用例可以被多個角色使用。角色是類，所以它擁有與類相同的關系描述。在用例圖中用通用化關系來描述角色之間的行為。

通用化關系是指把某些角色的共同行為抽取出來作為通用行為，這些通用行為構成它們的超類。這樣在定義某一具體角色時，僅僅定義其不同的行為。角色之間的通用化關系用帶空心三角形（作為箭頭）的直線表示，箭頭的方向指向超類。

2.用例之間的關系

用例代表一個完整的功能，是所有動作的集合。動作是系統的一次操作，如與角色通信、進行計算，在系統內部進行的工作都可以稱為動作。

用例用橢圓表示，用例位于系統邊界的內部。用例與角色有連接關系，此關系屬于關聯又稱為通信關聯。這種關聯表明哪種角色能與該用例通信。關聯關系是雙向的一對一關系，表示不僅角色不僅可以與用例通信。用戶也可以與該角色通信，表示方法是一條連接角色和用例的帶箭頭直線。

用例之間存在關系，包括擴展、使用、組合三種：

• 擴展： 一用例增加新內容成為另一個用例。用例之間的擴展關系可以用帶有構造型$<<extend>>$標志的通用化關系。
• 包含（使用）： 一個用例使用另一個用例。用例之間的使用關系用構造型具有$<<include>>$標志的通用化關系。
• 關聯（組合）： 把相關用例打成包當作整體。

ps. $uses$ 和 $extends$ 是 $UML1.1$ 中的 $stereotypes$（構造），它們在 $UML1.3$ （Rose2003中已經舍棄了 $uses$ 關系）中被修訂為 $include$（代替了原有的 $uses$ ）和 $extend$；

5.3 DBAS系統內部結構的表達

5.3.1 系統結構與類圖

系統內部結構一般分為靜態結構和動態結構。

在UML中，用類圖來描述系統靜態結構，用順序圖和通信圖來表示系統動態結構。

類圖主要表達的是問題領域的概念模型。類圖由類名、屬性及操作組成。

1.屬性

屬性包括屬性的名稱、類型和缺省值。$UML$ 規定其語法為：可見性 名稱: 類型=缺省值 {約束性}

• 可見性：不同屬性具有不同的可見性。常用的由公有、受保護、私有，在 $UML$ 中分別用 $+$、KaTeX parse error: Expected 'EOF', got '#' at position 1: #?、$?$ 表示。
• 名稱：是一個字符串，表示屬性名稱。
• 類型：定義屬性的種類。
• 缺省值：屬性的初始值。
• 約束性：列出該屬性所有可能的取值，在定義枚舉類型的屬性時經常使用，每個枚舉值之間用逗號分隔，此外還可以用來說明該屬性的其他信息，比如屬性的持久性等。

2.操作

操作描述了類的動態行為，在 $UML$ 中，操作的語法定義如下：可見性 名稱（參數表）：返回類型表達式{約束性}

• 可見性：“+”表示公有操作、“#”表示受保護的操作、“-”表示私有操作。
• 名稱。
• 參數表：其語法與屬性的參數相同，參數的個數是任意的。
• 返回類型表達式：可選項，依賴于語言的描述。
• 約束性。

3. 關系

3.1 關聯關系

3.1.1 雙向關聯

通常情況下關聯是雙向的，其圖示是連接兩個類之間的直線.

3.1.2 單向關聯

如果類和類之間的關聯是單向的則稱為導航關聯。導航關聯采用實體箭頭連接兩個類，只有箭頭所指的方向上才有這種關聯關系。

3.1.3 多重性

如果關聯上沒有角色名，則隱含著用類名作為角色名。
角色具有多重性，表示有多少對象參與該關聯。多重性表示參與對象的數目的上下界限制。*代表0到無窮大，“1”是“1…1"的簡寫，"6…10"表示6到10個對象。沒有明確標識關聯的重數則為1。

3.1.4 關聯類

關聯類通過一根虛線與關聯連接，用于描述關聯可能需要記錄的一些信息

3.1.5 聚集

聚集是一種特殊的關聯，它表示類之間整體與部分的關系。部分可以參加多個整體則構成共享聚集，整體擁有部分，部分與整體共存則構成了組成關系。
共享聚集表示為空心菱形,組成表示為實心菱形。

3.2 繼承關系

人們將具有共同特性的元素抽象成類別，并通過增加其內涵進一步分類。

在面向對象方法中前者被稱為一般元素、基類元素或父元素，將后者稱為特殊元素或子元素。

繼承關系表示為一頭為空心三角形的連線。

3.3 依賴關系

有兩個元素 $X$ 和 $Y$ ，如果修改元素 $X$ 的定義會引起元素 $Y$ 定義的修改，則稱元素 $Y$ 依賴于元素 $X$ 。

3.4 精化關系

表示同一事物的兩種描述之間的關系。對同一事物的兩種描述建立在不同的抽象層上。比如定義了某種抽象數據類型，然后將其實現為某種語言中的類，那么抽象定義的類型與用語言實現的類之間就是精化關系，這種情況叫實現，用帶空心的三角形的虛線表示。

3.5 匯總

5.3.2 系統結構與順序圖

針對每一個特定的用例，如何用類圖所規范的對象，來完成用例交付的任務，就必須用順序圖表達。

順序圖有兩個坐標軸：縱向表示時間的持續過程，橫向表示對象，每一個對象用矩形框表示，縱向的虛線表示對象在序列中的執行情況，稱為對象的“生命線”。

對象間的通信用對象生命線之間的水平消息線表示，消息線的箭頭說明消息的類型，單步、異步、簡單。

順序圖中后面發生消息應該比前面發生的線畫的低一些，以表示他們之間的時間關系。

5.3.3 系統結構與通信圖

通信圖是交互圖的一種，也稱為協作圖。

通信圖顯示對象間組織交互關系和鏈接。不側重交互順序，用序列號來確定消息及其并發線程的順序。

通信圖中主要元素基本和順序圖相同，只是在消息的傳遞上要特別表達消息的傳遞是由哪一個對象到另外一個對象。

順序圖強調時間，通信圖強調空間。

5.4 DBAS系統微觀設計的表達

5.4.1 微觀設計與對象圖

對象圖是類圖的實例，描述特定時間中所有對象在系統中的結構，是一個快照。

5.4.2 微觀設計與狀態機圖

狀態圖用來描述有關事件或對象的狀態轉移。

狀態圖只能有一個起始狀態，可有多個結束狀態。

狀態間的轉移由事件驅動。

當一個對象或某一個事件有非常復雜的狀態轉換時，可以用狀態機圖描述這個過程。

5.4.3 微觀設計與時間圖

當狀態的轉換由時間因素決定時，使用時間圖來描述狀態的變化。

描述時間驅動的狀態轉換，即當狀態維持多少時間后轉移。

時間圖中，整個矩形框就是一個生命線。

5.5 DBAS系統宏觀設計的表達

5.5.1 宏觀設計與包圖

宏觀設計指將涉及的焦點放在研究比較大范圍中的元素之間的聯系，如包、命名空間、子系統等。

一個良好的命名空間，便于開發人員理解，并使得各個命名空間之間能夠松耦合，而命名空間內則可滿足高內聚的要求。

包圖表示系統中不同包、命名空間或不同項目間的彼此關系。也就是邏輯層次上與實體層次上的關聯性。

5.5.2 宏觀設計與互概述圖

是將活動圖和順序圖嫁接在一起的圖 。

以活動圖為基礎，在控制流間連接交互圖，從而將所有交互圖關系呈現出來。

交互概述圖可以把不同的交互圖結合在同一張圖中來表達。

5.5.3 宏觀設計與復合結構圖

外部系統的整合關系著項目的成敗。

在項目開始前，最好將待開發的系統與外部系統的關系做一個初步的定義。

復合結構圖最重要的元素是部件，一個部件可以代表某個實體組件，也可以代表一個子系統。

復合結構圖適用于系統間的溝通接口，適合做構架師在初期階段評估系統復雜度的工具，也可以是系統維護的參考圖。

5.6 DBAS系統實現與部署的表達

5.6.1 系統實現與組件圖

組件圖用來表示系統的靜態實現視圖。

用來展現一組組件間的組織和依賴，用于對源代碼、可執行的發布、物理數據庫等的系統建模。

組件是邏輯設計中定義的概念和功能在物理構架中的實現。

5.6.2 系統實現與部署圖

部署圖又叫配置圖，描述系統中硬件和軟件的物理配置情況與系統體系結構。

部署圖說明實體組件，如可執行程序，將如何部署到實際的計算機中。

部署圖要在項目進行集成測試前提供。

---

第六章 高級數據查詢

---

6.1 一般數據查詢功能擴展

6.1.0 補充 SELECT語句

SELECT [DISTINCT] [TOP n] select_list -- 查詢指定的列 [INTO new_table] --將查詢結果創建到新表 [FROM table_source] --查詢行所在的表 [WHERE search_conditition] --指定返回行的搜索條件 [GROUP BY group_by_expression] --指定查詢結果的分組條件 [HAVING search_condition] --指定組或聚合函數的搜索條件 [ORDER BY order_expression [ASC|DESC]] --指定結果集的排序方式 [COMPUTE expression] --在結果集的末尾生成匯總數據行

6.1.1 使用Top限制結果集

TOP n [percent][WITH TIES]

• Top n 前n行
• Top n [percent]前n%行
• [WITH TIES]：包括最后一行取值并列的結果。
  注意：在使用 $TOP$ 謂詞時，要寫在 $SELECT$ 單詞的后邊（如果有 $DISTINCT$ 的話，則 $TOP$ 寫在 $DISTINCT$ 的后邊）、查詢列表的前邊。

6.1.2 使用CASE函數

簡單 $CASE$ 函數的語法格式為：

CASE 測試表達式WHEN 布爾表達式1 then 結果表達式1WHEN 布爾表達式2 then 結果表達式2……WHEN 布爾表達式n then 結果表達式n[ELSE 結果表達式n+1] END

搜索 $CASE$ 函數的語法格式為：

CASE WHEN 布爾表達式1 then 結果表達式1WHEN 布爾表達式2 then 結果表達式2……WHEN 布爾表達式n then 結果表達式n[ELSE 結果表達式n+1] END

6.1.3 將查詢結果保存到新表中

包含 $INTO$ 子句的 $SELECT$ 語句的語法格式為：

SELECT 查詢列表序列 INTO <新表名>FROM 數據源 …… --其他行過濾、分組等子句

注意：表名前加#為局部臨時表，##為全局臨時表，只有表名為永久表。

例子：SELECT * INTO #HD_Customer FROM Table_Customer WHERE ……

6.2 查詢結果的并、交、差運算

6.2.1 并運算

并運算（UNION）：將多個查詢結果合并為一個結果集。
語法：

SELECT 語句1 UNION [ALL] SELECT 語句2 UNION [ALL] …… SELECT 語句n

使用UNION注意：

• 要進行合并的查詢，SELECT中列數必須相同，語義相同。
• 每個相對應列的數據類型隱式兼容，如char（20）與varchar（40）。
• 合并后結果采用第一個SELECT語句的列標題。
• 若需排序，則GROUP BY語句寫在最后一個SELECT之后，且排序的一句是第一個SELECT中的列名。

6.2.2 交運算

交運算：返回同時在兩個集合中出現的記錄。

語法：

SELECT 語句1 INTERSECT SELECT 語句2 INTERSECT …… SELECT 語句n

6.2.3 差運算

差運算：返回第一個集合中有而第二個集合中沒有的的記錄。

語法：

SELECT 語句1 EXCEPT SELECT 語句2 EXCEPT …… SELECT 語句n

6.3 相關子查詢

子查詢是一條包含在另一條 $SELECT$ 語句里的 $SELECT$ 語句。外層的 $SELECT$ 語句叫外層查詢，內層的 $SELECT$ 語句叫內層查詢（或子查詢）。子查詢總是寫在圓括號中。

包含子查詢的語句通常采用以下格式中的一種：

• WHERE 表達式 [NOT] IN (子查詢)
• WHERE 表達式 比較運算符 (子查詢)
• WHERE [NOT] EXISTS (子查詢)

6.3.1 使用子查詢進行基于集合的測試

--實例： SELECT Cname,Address FROM Table_Customer WHERE Address IN(SELECT Address FROM Table_Customer WHERE Cname=‘王曉’) AND Cname！= ‘王曉’

6.3.2 使用子查詢進行比較測試

--實例： --查詢單價最高的商品的名稱和單價 SELECT Goodname，SaleUnitPrice FROM Table_Goods a WHERE SaleUnitPrice= (SELECT MAX(SaleUnitPrice) FROM Table_Goods)

6.3.3 使用子查詢進行存在性測試

--實例： --查詢購買了單價高于2000元商品額顧客的會員卡號。 SELECT DISTINCT CardID FROM Table_SaleBill WHERE EXISTS(SELECT * FROM Table_SaleBillDetail WHERE SaleBillID=Table_SaleBill.SaleBillID AND UnitPrice>2000)

6.4 其他形式的子查詢

6.4.1 替代表達式的子查詢

在SELECT的選擇列表中嵌入了一個只返回一個標量值的子查詢。

--實例： SELECT Cname，Address(SELECT COUNT(*) FROM Table_SaleBill aJOIN Table_Customer b ON a.CardID=b. CardID WHERE CustomerID=‘C001’）AS TotalTimes FROM Table_Custmer Where CustomerID=‘C001’

6.4.2 派生表

也稱為內聯視圖，是將子查詢作為一個表處理，產生的新表為“派生表”。

--實例：查詢至少買了G001和G002兩種商品的顧客號和顧客名。 SELECT CustomerID,CName FROM (SELECT * FROM Table_SaleBill a JOIN Table_SaleBillDetail bON a.SaleBillID=b. SaleBillID WHERE GoodsID=‘G001’) AS T1 JOIN (SELECT * FROM Table_SaleBill a JOIN Table_SaleBillDetail bON a.SaleBillID=b. SaleBillIDWHERE GoodsID=‘G002’) AS T2 ON T1.CardID=T2.CardID JOIN Table_Customer c ON c.CardID=T1. CardID

6.5 其他一些查詢功能

6.5.1 開窗函數

SQL Server 中，一組行被稱為一個窗口。
與聚合函數一樣，開窗函數也是對行集組進行聚合計算，但是它不像普通聚合函數那樣每組只返回一個值，開窗函數可以為每組返回多個值，因為開窗函數所執行聚合計算的行集組是窗口。

與聚合函數不同的是，開窗函數在聚合函數后增加了一個OVER 關鍵字。

開窗函數的調用格式為： 函數名（列）OVER（選項）

• OVER 關鍵字：表示把函數當成開窗函數而不是聚合函數。
• SQL 標準允許將所有聚合函數用做開窗函數，使用OVER 關鍵字來區分這兩種用法。

其他排名函數

• DENSE_RANK()：排名是連續整數
• NTILE()：將有序分區中的行劃分到指定數目的組中，編號從1開始，函數返回此行所屬的組的編號。
• ROW_NUMBER()：返回結果集中每個分區內的序列號，每個分區的第一行從1開始。

6.5.2 公用表表達式

公用表表達式（CommonTableExpression，CTE）：將查詢結果集指定一個臨時名字，這些命名的結果集就是公用表表達式。

--格式： WITH <common_table_expression>[,…n] <common_table_expression>::=expression_name[(column_name [,…n])] AS(SELECT語句)

---

第七章 數據庫及數據庫對象（補充）

---

7.1 創建及維護數據庫

7.1.1 SQL Server數據庫的組成

SQL Server將數據庫映射為一組操作系統文件：

• 數據文件
  • .mdf：主要數據文件。只有一個，大小不得小于3MB。
  • .ndf ：次要數據文件。有0個或多個，可在一個磁盤或多個磁盤存放。
• 日志文件
  • .ldf：事務日志文件。至少有一個日志文件。

7.1.2 數據庫文件組

兩種類型的文件組：

• 主文件組（PRIMARY）：系統定義，包含主要數據文件和任何沒有明確分配的其他文件組的其他數據文件，系統表所有頁均分配在主文件組中。
• 用戶定義文件組：在定義或修改數據庫時用 $FILEGROUP$ 關鍵字指定。

注意：

日志文件不在文件組中，日志空間與數據空間分開管理。

一個文件不可以是多個文件組成員。

若文件組包含多個文件，則在所有文件被填滿后才會自動循環增長。

文件加入數據庫中后，不能移動到其他文件組。

只能指定一個文件組為默認文件組。

7.1.3 數據庫文件的屬性

定義數據庫的數據文件和日志文件所需信息：

• 文件名及其位置 ：邏輯文件名，物理文件名
• 初始大小：不能小于model數據庫主要數據文件的大小

增長方式：可指定文件是否自增長（默認）。

最大大小：文件增長的最大限制。默認無限制。

7.1.4 用T-SQL創建數據庫

創建數據庫一般有兩種方式：

通過SQL Server Management Studio創建數據庫。

通過T-SQL語句創建數據庫。

$T?SQL$ 語法格式：

7.1.5 說明

• PRIMARY ：指定為主要數據庫文件，沒有指定默認第一個文件是主要數據文件。
• LOG ON ：自動創建日志文件，大小為數據文件總和25%或512KB中大的。
• NAME ：邏輯文件名，唯一。
• FILENAME ：物理文件名。
• SIZE：初始大小，.mdf大小不小于model，.ndf默認為1MB。
• MAXSIZE：最大大小，未指定則文件自動增長到磁盤滿。
• UNLIMITED ：增長無限制，一般指定為日志文件2TB，數據文件16TB.
• FILEGROWTH：指定文件自動增量，不超過MAXSIZE.默認數據文件1MB，日志文件為當前文件的10%。
• FILEGROUP ：文件組邏輯名，唯一，不能是系統名。
• DEFAULE ：指定該文件組為默認文件組。
  

7.1.6 修改數據庫

1.擴大數據庫空間

• 擴大數據庫中已有文件的大小
• 為數據庫添加新的文件

2.收縮數據庫空間

• 即釋放數據庫中未使用的空間，文件的收縮從末尾開始。
• 自動收縮：AUTO_SHRINK，默認false。
• 手工收縮：收縮數據庫中某個文件大小；
• 按比例收縮整個數據庫大小。

3.添加和刪除數據庫文件

ALTER DATABASE database { ADD FILE < filespec > [ ,...n ] [ TO FILEGROUP filegroup_name ] | ADD LOG FILE < filespec > [ ,...n ] | REMOVE FILE logical_file_name | ADD FILEGROUP filegroup_name | REMOVE FILEGROUP filegroup_name | MODIFY FILE < filespec > | MODIFY NAME = new_dbname | MODIFY FILEGROUP filegroup_name {filegroup_property | NAME = new_filegroup_name } | SET < optionspec > [ ,...n ] [ WITH < termination > ] | COLLATE < collation_name > }

4.擴大指定文件的大小：

ALTER DATABASE STU_DB MODIFY FILE（NAME=student_data, SIZE=8MB）

5.添加新的數據文件：

ALTER DATABASE STU_DB ADD FILE（NAME=student_data2， FILENAME=‘E:\Data\student_data2.ndf’, SIZE=6MB,FILEGROWTH=0）

6.收縮整個數據庫的大小：

DBCC SHRINKDATABASE

例1：DBCC SHRINKDATABASE（students，20）
收縮數據庫，該數據庫所用文件都有20%可用空間

7.收縮指定文件的大小：

DBCC SHRINKFILE

例2：DBCC SHRINKFILE（students_data1，4）
收縮數據庫到4MB大小

8.刪除數據庫文件：

ALTER DATABASE STU_DB REMOVE FILE student_log1

注意：

• 添加文件時，每個文件組中的數據文件按比例填充，日志文件是依次增加的。
• 文件為空才能刪除。

7.1.7 分離和附加數據庫

1.分離數據庫

作用：

• 實現將數據庫從一臺數據庫服務器移到另一臺，不需要重建。
• 從實例中刪除，不刪除數據文件和日志文件，保持了數據文件和日志文件完整一致。
• 使用sp_detach_db系統存儲過程實現，如：EXEC sp_detach_db‘student’，‘true’

2.附加數據庫

將分離的數據庫重新附加到數據庫管理系統中。

必須指定主要數據文件的物理存儲位置和文件名。

CREATE DATABASE …… FOR ATTACH|ATTACH_REBUILD_LOG

例：

CREATE DATABASE students On（FILENAME=‘F：\Data\Students_data1.mdf’） FOR ATTACH

7.2 架構

架構（Schema，也稱模式），是數據庫下的一個邏輯命名空間，是數據庫對象的容器，一個數據庫包含一個或多個構架，同一個數據庫內架構名唯一。

7.2.1 定義構架

CREATE SCHEMA [<構架名>] AUTHORIZATION<用戶名>

7.2.3 刪除構架

DROP SCHEMA [<構架名>]

7.3 分區表

7.3.1 基本概念

分區表是將表中的數據按水平分割成不同子集，并將數據子集存儲在數據庫一個或多個文件組中。物理上將大表分成幾個小表，邏輯上還是一個大表。

合理使用分區能提高數據庫性能。

是否創建分區取決于表當前數據量大小，以及將來數據量，還取決于表中數據的操作特點。

表包含（或將包含）以多種不同方式使用的大量數據

數據是分段的，比如以年份分隔。

7.3.2 創建分區表

三個步驟：

創建分區函數：告訴DBMS以什么方式進行分區

CREATE PARTITION FUNCTION

創建分區方案：作用是將分區函數生成的分區映射到文件組中

CREATE PARTITION SCHEME

使用分區創建表。

7.4 索引

7.4.1 創建索引

7.4.2 刪除索引

7.5 索引視圖

7.5.1 基本概念

標準視圖也稱虛擬表，返回結果集與基本表一致。標準視圖的結果集不永久存放；

建立唯一聚集索引的視圖，稱為索引視圖，也稱為物化視圖。建立索引后，視圖的結果集存放在數據庫中。

對基本表的修改會反映到索引視圖存儲的數據中。

7.5.2 定義索引視圖

創建聚簇索引前視圖必須符合的條件：

• 定義索引視圖時，視圖只能引用基本表，不能是其他視圖。
• 引用的所以基本表和視圖同一數據庫，所有者相同。
• 必須用SCHEMABINDING選項建視圖。
• 視圖中表達式引用的所有函數必須確定。
• 對視圖建立的第一個索引是唯一聚簇索引，之后在創建其他。

　CREATE VIEW;WITH SCHEMABINDING; CREATE UNIQUE CLUSTERED INDEX …

---

第八章 數據庫后臺編程

---

8.1 存儲過程

8.1.1 基本概念

使用T-SQL語言編寫代碼時，有兩種方式存儲和執行代碼：

• 在客戶端存儲代碼，通過客戶端程序或SQL命令向DBMS發出操作請求，由DBMS將結果返回給用戶程序。
• 以子程序的形式將程序模塊存儲在數據庫中，供有權限的用戶通過調用反復執行。

存儲過程：即存儲在數據庫中供所有用戶程，序調用的子程序。

存儲過程分為三類：

系統存儲過程

用戶自定義存儲過程

擴展存儲過程

用戶自定義存儲過程是由用戶創建并能完成某一特定功能（如查詢用戶所需數據信息）的存儲過程。

擴展存儲過程是 SQL Server 可以動態裝載并執行的動態鏈接庫 (DLL)。擴展存儲過程使您得以使用象 C 這樣的編程語言創建自己的外部例程。對用戶來說，擴展存儲過程與普通存儲過程一樣，執行方法也相同。

存儲過程的優點：

極高的執行效率。

增強代碼的重用性和共享性。

使用存儲過程可以減少網絡流量。

使用存儲過程保證安全性。

在大型數據庫中，應用程序訪問數據庫的最主要方式就是存儲過程。

存儲過程可以在系統啟動時自動執行。

8.1.2 創建、執行和刪除存儲過程

存儲過程定義包含兩個主要組成部分：

過程名稱及其參數的說明；

過程的主體（其中包含執行過程操作的Transact-SQL語句）。創建存儲過程的語法格式如下：

創建存儲過程：

執行存儲過程：

刪除存儲過程：

DROP PROCEDURE

8.2 用戶定義函數

用戶定義函數：類似于編程語言中的函數，其結構與存儲過程類似，但函數必須有一個 $RETURN$ 子句，用于返回函數值。

兩類用戶定義函數：標量函數和表值函數。前者返回單個數據值，表值函數返回一個表。

8.2.1 創建和調用標量函數

1.定義標量函數：

CREATE FUCTION [schema_name. ] function_name ( [ { @ parameter_name [AS] [type_schema_name. ] parameter_data_type[ =default ] }[,···n]] ) RETURNS return_data_type [AS ] BEGINfunction_bodyRETURN scalar_expression END [;]

各參數說明：

• schema_name：用戶定義函數所屬框架的名稱。
• function_name：用戶定義函數的名稱。
• @ parameter_name：用戶定義函數中的參數
• [type_schema_name. ] parameter_data_type ：參數的數據類型及其所屬的架構，后者為可選項。
• [ =default ]：參數的默認值。
• return_data_type：用戶定義函數的返回值類型。
• function_body：定義函數值的一系列T-SQL語句。
• scalar_expression：指定標量函數返回的標量值。

2.調用標量函數：

注意：

• 調用時需要提供函數擁有者名和函數名；
• 可以在任何出現表達式的SQL語句中調用類型一致的標量函數。

8.2.2 創建和調用內聯表值函數

1.創建內聯表值函數：

CREATE FUCTION [schema_name. ] function_name ( [ { @ parameter_name [AS] [type_schema_name. ] parameter_data_type[ =default ] }[,···n]] ) RETURNS TABLE [AS ]RETURN [ ( ] select_stmt [ ) ] [;]

參數說明：select_stmt是定義內聯表值函數返回值的單個SELECT語句；表值函數沒有返回變量，沒有函數體，只返回一個查詢結果。

2.調用內聯表值函數：

使用內聯表值函數與視圖類似，其作用相當于帶參數的視圖。

8.2.3 創建和調用多語句表值函數

創建多語句表值函數：

CREATE FUCTION [schema_name. ] function_name ( [ { @ parameter_name [AS] [type_schema_name. ] parameter_data_type[ =default ] }[,···n]] ) RETURNS @ return_variable TABLE <table_type_definition> [AS ]BEGINfuction_bodyRETURNEND [;] <table_type_definition>:: = ( { <column_definition> <column_constraint>| <computed_column_definition>}[<table_constraint>][，···n])

參數說明：

• function_body：定義函數值的一系列T-SQL語句。
• table_type_definition：定義返回的表的結構。

調用建多語句表值函數:在SELECT的FROM子句中使用。

8.2.4 刪除用戶自定義函數

DROP FUNCTION { [schema_name. ] function_name} [，···n ]

8.3 觸發器

8.3.1 基本概念

觸發器：特殊存儲過程，在對表中的數據進行UPDATE、INSERT、DELETE操作時自動觸發執行，常用于保證業務規則和數據完整性，增強數據完整性約束能力。

SQL Server 2008支持三種類型的觸發器：

DML、

DDL、

登錄觸發器。

適用場合：

完成比CHECK（只能實現同一表列之間取值約束）約束更復雜的數據約束。

保證數據庫性能而維護的非規范化數據。

可實現復雜的商業規則。

評估數據修改前后的表狀態，并采取對策。

8.3.2 創建觸發器

CREATE TRIGGER trigger_name ON { table | view } [WITH ENCRYPTION] { FOR | AFTER | INSTEAD OF } { [ INSERT ] [ , ] [ UPDATE ] [ , ] [ DELETE ] } AS sql_statement[…n]

參數說明：

• FOR或AFTER：后觸發型，操作、約束檢查完成后觸發。
• INSTEAD OF ：前觸發型，數據操作語句最多定義一個觸發器。執行觸發器而非引發語句。若滿足完整性約束則需要重新執行這些數據操作。

注意：

• 一個表可建多個觸發器，每個觸發器可由三個操作觸發。ALTER類型同一操作上建立多個觸發器，INSTEAD OF類型同一操作上建立一個觸發器。
• 所有建立和更改數據庫以及數據庫對象的語句、DROP語句不允許砸在觸發器中用。
• 觸發器不要返回任何結果。

8.3.3 刪除觸發器

DROP TRIGGER
實例
DROP TRIGGER OperateCon
DROP TRIGGER UnitPriceConsistent
DROP TRIGGER DeleteCust

8.4 游標

游標：實現對SELECT結果集的逐行處理。

8.4.1 游標的組成

游標結果集（SELECT返回結果集）與游標當前行指針（指向結果集中某一行）
　　
特點：定位特定行；從當前位置檢索一行或多行；支持當前行數據修改；對修改結果提供不同級別的可見性支持。

8.4.2 使用游標

1.聲明游標

ISO標準語法:DECLARE cursor_name[1] CURSOR FOR select_statement[2]
　　
參數說明:[1]INSENSTITIVE:創建臨時副本，對臨時表操作，否則對基本表；SCROLL:范圍，否則只支持NEXT；[2]READ ONLY:禁止更新 UPDATE 更新列指定列或所有。

2.打開游標

OPEN cursor_name

3.提取數據

FETCH [1]FROM cursor_name [INTO @ variable_name[,…n]]

4.關閉游標

CLOSE cursor_name
可以再次打開。

5.釋放游標

DEALLOCATE cursor_name
釋放分配給游標的所有資源。

---

第九章 安全管理

---

9.1 安全控制概述

數據庫安全性不同于數據的完整性。

• 安全性：保護數據以防止不合法用戶故意造成破壞。（確保用戶被允許做其想做的事情。）
• 完整性：保護數據以防止合法用戶無意中造成的破壞。（確保用戶做的事情是正確的。）

9.1.1 數據庫安全控制的目標

保護數據免受意外或故意的丟失、破壞或濫用。

9.1.2 數據庫安全的威脅

安全計劃需要考慮：可用性損失，機密性數據損失,私密性數據損失，偷竊和欺詐，意外的損害。

9.1.3 安全控制模型

包括四階段：

身份驗證（用戶）

操作權限控制（數據庫應用程序與數據庫管理系統）

文件操作控制（操作系統）

加密存儲與冗余（數據庫）

9.1.4 授權和認證

認證是一種鑒定用戶身份的機制。授權是將合法訪問數據庫或數據庫對象的權限授予用戶的過程。包括認證用戶對對象的訪問請求。

DBMS通常采用自主存取控制和強制存儲控制兩種方案來解決安全控制問題。

9.2 存取控制

9.2.1 自主存取控制

又稱自主安全模式， 通過SQL的GRANT,REVOKE,DENY語句來實現。

權限種類：維護權限與操作權限（語句權限與對象權限）

用戶分類：系統管理員（sa）、數據庫對象擁有者、普通用戶。

9.2.2 強制存取控制

為避免自主存取模式下數據的“無意泄露”，采取強制存取控制。

DBMS將全部實體分為主體和客體兩大類。

• 主體：系統活動實體，實際用戶和進程。
• 客體：被動實體，受主體操縱，包括文件、基本表、視圖。

敏感度標記被分為若干級別，例如絕密，秘密，可信和公開。

主體的敏感度標記被稱為許可證級別，客體的敏感度標記被稱為密級

• 僅當主體的許可證級別大于或等于客體的密級時，該主體才能讀取相應的客體。
• 僅當主體的許可證級別等于客體密級時，該主體才能寫相應的客體。

通用安全性分級模式：D類最小保護，C類自主保護，B類強制保護，A類驗證保護

自主保護：C類分為兩個子類C1和C2，C1安全級別低于C2

C1子類對所有權和存儲權限區分，雖然它允許用戶擁有自己的私有數據，但仍然支持共享數據的概念

C2子類還需要通過注冊、審計以及資源隔離以支持安全責任說明

強制保護：B類分為三個子類B1 B2 B3，B1安全級別最低，B3最高

B1要求標識化安全保護，并要求每個數據對象都標以一定的密級，同時還要求安全策略的非形式化說明

B2要求安全策略的形式化說明，能夠識別并消除隱蔽通道（隱蔽通道的例子有從合法查詢結果推斷不合法查詢結果）

B3子類要求支持審計和恢復以及指定安全管理者

驗證保護：A類要求安全機制是可靠的且足夠支持對指定安全策略給出嚴格的數學證明。

9.3 審計跟蹤

審計跟蹤實質上是一種特殊的文件或數據庫。系統自動記錄用戶對常規數據的所有操作。

審計跟蹤對數據安全有輔助作用。

9.4 統計數據庫的安全性

統計數據庫提供基于各種不同標準的統計信息或匯總數據。

統計數據庫安全系統用于控制對統計數據庫的訪問。

統計數據庫允許用戶查詢聚合類型的信息，如總和、平均等，但不允許查詢個人信息。

9.5 SQL Server 的安全控制

9.5.1 身份驗證模式

Windows身份驗證模式：SQL Server通過Windows操作系統獲得用戶信息，驗證登錄名和密碼，一般推薦。

混合身份驗證模式；Windows授權用戶和SQL授權用戶可以登錄。

9.5.2 登錄帳戶

SQL Server自身負責身份驗證的賬戶，內置系統賬戶與用戶自己創建。

登錄到SQL Server的Windows網絡賬戶，可以是組賬戶或用戶賬戶。

1.建立登錄賬戶

例1：創建SQL server 身份驗證的登錄賬戶

create login SQL_User1 with password = '12345678'

例2：創建Windows身份驗證的登錄賬戶，從Windows域賬戶創建[TEST\Win_User2]登錄賬戶

create login [TEST\Win_User2] from windows

例3：創建SQL server身份驗證的登錄賬戶。要求該用戶首次連接服務器時必須更改密碼

create login SQL_User3 with password = '123456789' must_change

2.修改登錄賬戶屬性

例4：啟用或禁用的登錄賬戶

alter login SQL_User1 enable

例5：修改登錄賬戶的密碼

alter login SQL_User1 with password='12345'

例6：更改賬戶名

alter login SQL_User3 with name = 'NewUser'

3. 刪除登錄賬戶

例7：刪除登錄賬戶

drop login SQL_User2

9.5.3 數據庫用戶

用戶有了登錄帳戶，只能連接到SQL服務器，并不具有訪問數據庫的權限。

讓登錄賬戶成為數據庫用戶的操作是映射 。一個登錄賬戶可以映射為多個數據庫中的用戶。 默認情況下，新建立的數據庫只有一個用戶dbo，他是數據庫的擁有者

1.建立數據庫用戶

例8 使SQL_User2登錄賬戶成為某數據庫中的用戶，并且用戶名同登錄名

create user SQL_User2

例9 首先創建名為SQL_JWC且具有密碼的SQL Server身份驗證的服務器登錄名，然后在test數據庫中創建與此登錄名對應的數據庫用戶JWC 、

create login SQL_JWC with password='123456' go use test go create user JWC for login SQL_JWC go

2.Guest用戶

--啟用guest用戶 grant connect to guest --禁用guest用戶 revoke connect to guest

3.刪除數據庫用戶

drop user user_name

9.5.4 權限管理

登錄賬戶成為合法用戶后沒有任何操作權限，就需要為用戶授予數據庫數據及其對象的操作權限。

1.對象級別的權限

操作權限使用說明

select	允許用戶查詢數據
insert	允許用戶插入數據
update	允許用戶修改數據
delete	允許用戶刪除數據
references	如果用戶要插入數據的表上有外鍵約束，而用戶在外鍵所引用的表上沒有select權限，則擁有該權限的用戶能夠向這樣的表插入數據
execute	允許用戶具有執行存儲過程和標量函數的權限

1.1 授權語句

例10：授予用戶RosaQdm對Address表具有select權限

grant select on Address to RoseQdm

例11：授予用戶 RosaQdM 對 HumanResources. EmployeeInfo 存儲過程具有 EXECUTE 權限

GRANT EXECUTE ON OBJECT :: HumanResources. EmployeeInfo To RosaQdm

例12：使用 GRANT OPTION 選項，授予用戶 Wanida 對 vEmployee 視圖中 EmployeeID 列具有 REFERENCES 權限。

GRANT REFERENCES ( EmployeeID）ON vEmployeeTo Wanida WITH GRANT OPTION

1.2 拒絕語句

例13：拒絕用戶 RosaQdm 對 Person. Address 表具有 select 權限

DENY select ON OBJECT :: Person. Address to RoseQdm

例14：拒絕用戶 RosaQdM 對 HumanResources. EmployeeInfo 存儲過程具有 EXECUTE 權限

DENY EXECUTE ON HumanResources. EmployeeInfo To RosaQdm

例15：拒絕 GRANT OPTION 選項，授予用戶 Wanida 對 HumanResources. vEmployee 視圖中 EmployeeID 列具有 REFERENCES 權限。

DENY REFERENCES ( EmployeeID）ON OBJECT :: HumanResources. vEmployeeTo Wanida CASCADE;

1.3 收權語句

例16：撤銷用戶 RosaQdm 對 Person. Address 表具有 select 權限

REVOKE select ON OBJECT :: Person.Address to RoseQdm

例17：撤銷用戶 RosaQdM 對 HumanResources. EmployeeInfo 存儲過程具有 EXECUTE 權限

REVOKE EXECUTE ON HumanResources. EmployeeInfo FROM To RosaQdm

2.語句級別的權

2.1 授權語句

例18：授權用戶 RosaQdM 具有創建表的權限。

GRANT CREATE TABLE TO RosaQdM

例19： 授權用戶 user1 和 user2 都具有創建表和視圖權限。

GRANT CREATE TABLE, CREATE VIEW TO user1，user2

2.2 拒絕語句

例20：拒絕用戶 user1 具有創建表的權限。

DEMY CREATE TABLE TO user1

2.3 收權語句

例21：收回用戶 RosaQdM 具有創建表的權限。

REVOKE CREATE TABLE FROM RosaQdM

9.5.5 角色

定義：一組具有相同權限的用戶就是角色。

SQL Server 2008中，角色分為預定義的系統角色和用戶角色兩種。

• 系統角色又分為固定服務器角色（服務器級角色）和固定數據庫角色（數據庫級角色）。
• 用戶角色均是數據庫級角色。

1.固定服務器角色

• Bulkadmin：執行BULK INSERT語句權限。
• Dbcreator：創建、修改、刪除還原數據庫權限。
• Diskadmin：具有管理磁盤文件的權限
• Processadmin管理運行進程權限。
• Securtyadmin：專門管理登錄賬戶、讀取錯誤日志執行CREATE DATABASE 權限的賬戶，便捷。
• Serveradmin：服務器級別的配置選項和關閉服務器權限。
• Setupadmin：添加刪除鏈接服務器。
• Sysadmin：系統管理員 ，Windows超級用戶自動映射為系統管理員。
• Public：系統預定義服務器角色，每個登錄名都是這個角色的成員。沒有授予或拒絕特定權限，則將具有這個角色權限。

2.固定數據庫角色

定義在數據庫級別上，存在于每個數據庫中。用戶加入固定數據庫角色就具有數據庫角色權限。

• Db_accessadmin:添加或刪除數據庫權限
• Db_backupoperator：備份數據庫、日志權限
• Db_datareader:查詢數據庫數據權限
• Db_datawriter：具有插入、刪除、更改權限
• Db_ddladmin：執行數據定義的權限
• Db_denydatareader：不允許具有查詢數據庫中所有用戶數據的權限。
• Db_denydatawriter：不允許具有插入、刪除、更改數據庫中所有用戶數據權限。
• Db_owner：具有全部操作權限，包括配置、維護、刪除數據庫。
• Db_securityadmin：具有管理數據庫角色、角色成員以及數據庫中語句和對象的權限。

3.用戶定義的角色

• 用戶定義的角色屬于數據庫一級。
• 用來簡化使用數據庫時的權限管理。
• 用戶定義的角色成員可以是用戶定義角色或數據庫用戶。注意： 角色中的成員擁有的權限=成員自身權限+所在角色權限。但若某個權限在角色中被拒絕，則成員不再擁有。

3.1創建用戶定義的角色

CREATE ROLE
實例：

CREATE ROLE MathDept [AUTHORIZATION Software]

注意：為用戶定義角色授權、添加、刪除用戶定義的角色中的成員與固定數據庫角色一致。

3.2刪除用戶定義角色

DROP ROLE
實例：

DROP ROLE MathDept

9.6 Oracle的安全管理

Oracle的安全機制分為數據庫級的安全控制、表級、列級、行級的安全控制。

數據庫級的安全性通過用戶身份認證和授予用戶相應系統權限來保證；

表級、列級、行級的安全性通過授予或回收對象權限保證。支持集中式、分布式、跨平臺應用。

Oracle系統通常設置兩級安全管理員：

全局級：負責管理、協調，維護全局數據一致性和安全性；

場地級：負責本結點數據庫安全性，用戶管理、系統特權與角色管理。

9.6.1 用戶與資源管理

按權限大小劃分為DBA用戶和普通用戶。

• DBA用戶由DBMS自動創建，sys與system用戶，擁有全部系統特權。
• 普通用戶：由DBA用戶或有相應特權的用戶創建，并授予系統特權。

1.建立用戶：

例32：建立一個Oracle 數據庫用戶 user1.

CREATE USER use1 IDENTIFIED BY u66771 DEFAULT TABLESPACE student（存儲在student表空間） QUOTA 5M ON student（限制使用空間為5M）

2.管理用戶和資源：

例33：將user1用戶對student表空間的空間使用額增至60MB

ALTER USER user1 QUOTA 60M ON student

將自己的密碼修改為w12345

ALTER USER user 1 IDENTIFIED BY w12345

3.刪除用戶

例34：從數據庫中刪除USER1用戶及其所擁有的全部數據庫對象。

DROP USER user1 CASCADE

9.6.2 權限管理

1.系統特權

三種默認特權：

Connect： 不能建立任何對象，可以查詢數據字典及訪問數據庫對象。

Recource ：可建立數據庫對象（表、視圖、索引……）

DBA ：擁有預定義的全部權限 。

2.對象特權

用于維護表級、行級、列級數據的安全性。
實例：

GRANT all ON dep TO user1 GRANT select(tno,tname,sal) ON teacher TO user2

---

第十章 數據庫運行維護與優化

---

10.1 數據庫運行維護基本工作

DBAS進入運行維護階段的主要任務：

保證數據庫系統安全、可靠且高效率地運行。

數據庫的運行除了DBMS與數據庫外，還需要各種系統部件協同工作。

首先必須有各種相應的應用程序，其次各應用程序與DBMS都需要在操作系統（OS）支持下工作。

維護工作包括：

• 數據庫轉儲與恢復
• 數據庫安全性、完整性控制
• 檢測并改善數據庫性能
• 數據庫的重組和重構

重組不修改數據庫原有設計的邏輯結構和物理結構，重構部分修改模式和內模式

10.2 運行狀態監控與分析

數據庫的監控分析：指管理員借助工具監測DBMS的運行情況，掌握系統當前或以往的負荷、配置、應用等信息，并分析監測數據的性能參數和環境信息，評估DBMS的整體運行狀態。
根據監控分析實現不同，分為：

• 數據庫系統建立的自動監控機制
• 由DBMS自動監測數據庫的運行情況。
• 管理員手動實施的監控機制

根據監控對象不同，分為：

• 數據庫構架體系的監控：監控空間基本信息、空間使用率與剩余空間大小等。
• 數據庫性能監控：監控數據緩沖區命中率、庫緩沖、用戶鎖、索引使用、等待事件等。

10.3 數據庫存儲空間管理

空間使用情況變化帶來的問題：

• 降低數據庫系統服務性能
• 空間溢出導致災難停機事故

SQL Server數據庫中 一個邏輯上的數據庫直接和一組物理上的數據文件對應，沒有表空間概念。

DBMS對空間的管理包括：創建數據庫空間、更改空間大小、刪除空間、修改空間狀態，新建、移動、關聯數據文件等。

10.4 數據庫性能優化

數據庫性能優化是DBAS系統上線后最常見的運行維護任務之一。

進行數據庫性能優化時，首先要確定優化目標，一般從數據庫運行環境、參數調整、模式調整、數據庫存儲優化、查詢優化幾個方面考慮。

10.4.1 數據庫運行環境與參數調整

一般來說，可以從外部環境、調整內存分配、調整磁盤I/O、調整資源競爭等幾個方面著手改變數據庫參數，提高其性能。

1.外部調整

外部調整：數據庫性能和外部環境有很大關系，主要外部條件包括：CPU（CPU的處理能力是衡量計算機性能的一個標志）、網絡（大量的SQL數據在網絡上傳輸會導致網速變慢）。

CPU使用情況判斷依據：對于一臺數據庫服務器，如業務空閑時使用率超過90%。說明服務器缺乏CPU資源，如高峰時CPU使用率仍然低，說明服務器CPU資源充足。

解決方案；增加CPU數量或者終止需要許多資源的進程。

2.調整內存分配

調整內存分配：調整相關參數控制數據庫內存分配，很大程度改善數據庫系統性能。

3.調整磁盤I/O

調整磁盤I/O：數據庫性能優劣的重要度量是響應時間。
改善方法：令I/O時間最小化，減少磁盤上文件競爭帶來的瓶頸。

4.調整競爭

調整競爭：

修改參數以控制連接到數據庫的最大進程數。

減少調度進程的競爭

減少多線程服務進程競爭

減少重做日志緩沖區競爭

減少回滾段競爭。

10.4.2 模式調整與優化

數據庫的規范化過程：高效率利用存儲空間，減少數據的冗余，減少數據的不一致性。

問題：規范化關系解決了數據維護的異常，并使數據冗余最小化，但會導致數據處理性能下降。

反規范化：將規范化關系轉換為非規范化的關系的過程。

反規范化方法：增加派生冗余列、增加冗余列、重新組表、分割表和新增匯總表等方法。都會破壞數據完整性。　
采用反規范化技術從實際出發均衡利弊。

1.增加派生性冗余列

增加的列由表中的一些數據項經過計算生成。

作用：查詢時減少連接操作，避免使用聚合函數。

例如：銷售單據明細表（單據編號，商品編號，單價，數量，總價），總價=單價*數量，屬于派生性增加冗余列。

2.增加冗余列

在多個表中增加具有相同語義的列，常用來在查詢時避免連接操作。（外碼不屬于這種情況）

3.重新組表

當用戶經常查看的某些數據是由多個表連接之后才能得到，就可以考慮先把這些數據重新組成一個表，這樣在查詢時會減少連接提高效率。

4.分割表（重點）

• 水平分割：根據行的使用特點進行分割，分割之后所有表的結構都相同。而存儲的數據不同。使用并（Union）操作。
• 垂直分割：根據列的特點分割，分割后所得表除了都包含主碼外其他列都不相同。通常將常用列與不常用列分別放在不同表中，查詢減少I/O次數。缺點是使用連接（Join）操作

5.新增匯總表

大量執行報表等匯總操作會影響性能。

為降低匯總操作的時間，將頻繁使用的統計中間結果或最終結果存儲在匯總表中，從而降低數據訪問量和匯總操作的CPU計算量。

如：日銷售額統計表

10.4.3 存儲優化

1.物化視圖（索引視圖）

定義：包括一個查詢結果的數據庫對象，是預先計算并保存表連接或聚集等耗時較多的操作結果。（一個定期刷新數據的視圖，自動刷新或人工刷新）

適用于多個數據量較大的表進行連接操作及分布式數據庫中在多站點的表進行連接時使用。

物化視圖還可以進行遠程數據的本地復制（物化視圖的存儲也稱為快照），用于實施數據庫間的同步。

2.聚集

聚集是物理存儲表中數據的可選擇的方法。

一個聚集是一組表，將經常一起使用的具有同一公共列值的多個表中的數據行存儲在一起，由公共列構成聚集碼。

作用：最小化必須執行的I/O次數。

注意：將記錄插入聚集的表之前，必須建立聚集索引，且按聚集碼進行索引；對于劇集中的多個表，聚集值只存儲一次。

劣勢：聚集表的插入、更新、刪除性能差，具體使用要權衡。

10.4.4 查詢優化

效率低下的SQL語句常常是系統效率不佳的主要原因。常用優化方法如下：

1.合理使用索引

權衡：索引提高查詢效率，索引增加系統開銷。

建立索引原則：

是否為一個屬性建索引：該屬性是碼或存在某個查詢中被使用。

在哪些屬性建立索引：若一個關系的多個屬性共同出現在若干個查詢中，一般會采用多屬性索引。

是否建立聚簇索引：聚簇索引適合范圍查詢，可建立多屬性索引。優點體現在數據記錄存取過程中。

使用散列還是樹索引：散列適合等值查詢；關系數據庫多使用B+索引，支持作為搜索碼的屬性上的等值查詢和范圍查詢。

索引使用原則：

經常在查詢中作為條件被使用的列，應為其建立索引。

頻繁進行排序或分組的列，應為其建立索引。

一個列的值域很大時，應為其建立索引。

如果待排列的列有多個，建復合索引。

可以使用系統工具來檢查索引完整性，必要時進行修復。當數據表更新大量數據后，刪除并重建索引以提高查詢。

索引建立完成后，運行期間還需調優。

調優的目的：動態地評估需求。

索引調整和修改的原因：

• 由于缺少索引，某些查詢語句執行時間過長。
• 某些索引自始至終沒有使用，卻占用了較多磁盤空間。
• 某些索引建立在被頻繁改變的屬性上，導致系統開銷過大。

2.避免或簡化排序

ORDER BY和GROUP BY語句的執行涉及排序，磁盤排序開銷很大，應利用索引自動以適當的次序產生輸出。
影響優化器的因素：

由于現有索引不足，導致排序索引中不包括一個或幾個待排序的列。

Group by和order by子句中列的次序與索引次序不一致。

排列的列來自不同的表。

為避免不必要的排序，要正確地增建索引，合理合并數據庫表，如排序不可避免，則簡化它，如縮小排序列的范圍。

3.消除對大型表數據的順序存取

嵌套查詢中，對表的順序存取嚴重影響查詢效率。

優化方法：對連接列進行索引，或使用并集來避免順序存取。

4.避免復雜正則表達式

原因：消耗較多CPU資源進行字符串匹配。

5.使用臨時表加速查詢

將表的一個子集進行排序并創建臨時表。

6.用排序來取代非順序磁盤存取

原因：非順序磁盤存取最慢。使用以數據庫排序功能為基礎的SQL替代非順序存取。

7.不充分的連接條件。

原因：左（右）外連接包含與NULL數據匹配，相比內連接，代價可能很高。

8.存儲過程

盡量使用自帶返回參數，而非自定義返回參數，減少不必要參數，避免數據冗余。

9.不要隨意使用游標

原因：占用較多系統資源。尤其是大規模并發情況下，很容易使得系統資源耗盡而崩潰。

10.事務處理

一旦將多個處理放入事務，會降低系統處理速度。將頻繁操作的多個可分割的處理過程放入多個存儲過程中，這樣就大大提高系統響應速度。

10.4.5 SQL Server 性能工具

1.SQL Server Profiler

用來監視SQL Server事件的多用途監控工具（性能、存儲過程、T-SQL語句運行等監控）。結果存儲在一個跟蹤文件中，可通過分析文件診斷問題。

2.數據庫引擎優化顧問

測試數據庫工作負荷（一組在數據庫中執行的T-SQL語句），給出優化建議。

---

第十一章 故障管理

---

11.1 故障管理概述

11.1.1 故障類型及其解決方案

1.事務內部的故障

事務內部故障：事務故障導致數據不一致，分為預期的（大部分）和非預期的。

• 預期的事務內部故障：可通過事務過程本身發現的。解決辦法：事務回滾
• 非預期的事務內部故障：不能由事務程序處理的故障，如運算溢出等。事務故障的恢復由系統自動完成。

2.系統故障

又稱軟故障，運行期間，由于硬件故障、數據庫軟件及OS漏洞、突然斷電等故障，導致數據不一致。

解決辦法：重啟后，撤銷（UNDO）所有未提交的事務；重做（REDO）所有已提交的事務；

3.介質故障

又稱硬故障，運行期間由于磁頭碰撞、磁盤損壞、強磁干擾、天災人禍等，使得數據丟失的一類故障。導致物理存儲設計損壞，數據文件及數據全部丟失，破壞性最大。

容錯策略：軟件容錯及硬件容錯。

4.軟件容錯：

使用數據庫備份及事務日志文件，通過恢復技術，恢復數據庫到備份結束時的狀態。若故障導致事務日志文件丟失，則不能完全恢復。

5.硬件容錯：

一種方案是使用雙物理存儲設備，如雙硬盤鏡像。缺點：自然災害或機房水災、火災導致雙硬盤同時損壞，則失去保護作用。

另一種方案是設計兩套相同的數據庫系統，通過數據庫軟件機制，同步變化數據。

6.計算機病毒故障

病毒是惡意的計算機程序，破壞OS及數據庫系統（破壞數據文件為主）。

解決辦法：防火墻、殺毒軟件、數據庫備份文件。

11.1.2 數據庫恢復技術概述

無論哪種故障，恢復的基本原理是冗余。

數據庫恢復：把數據庫從錯誤狀態恢復到某一已知的正確狀態。

在DBMS中，數據庫恢復子系統占10%以上。

恢復機制涉及兩個問題：如何建立冗余數據；如何利用這些冗余數據實施數據庫恢復。

建立冗余據的技術：
數據備份、登記日志文件、數據庫復制、數據庫鏡像、為段設立保存點以及使用后備段與現行頁表來支持對段的保存等。最常用的是數據備份和登記日志文件。

11.2 數據轉儲

數據轉儲即數據備份：指DBA或DBMS定期復制數據庫，并將其存放到其他介質的過程。這些保存的副本被稱為后援副本或后備副本。

11.2.1 靜態轉儲和動態轉儲

1.靜態轉儲

靜態轉儲：期間系統不能運行其他事務，不允許任何存取、修改活動。

靜態轉儲保證數據的一致性，但降低了數據庫的可用性。轉儲和事務是互斥的。

2.動態轉儲

動態轉儲：即允許轉儲和事務并發執行。

動態轉儲不能保證轉儲數據的一致性。

動態轉儲+日志文件（記錄轉儲期間各事務對數據庫的修改活動記錄）：既保證數據一致性又提高了數據庫的可用性。

11.2.2 數據轉儲機制

完全轉儲：對數據庫中所有數據進行轉儲。占據較多時間和空間，但恢復時間短。

增量轉儲：只復制上次轉儲后發生變化的文件或數據塊。 所需時間及空間短，但只能和完全轉儲配合才能對數據庫進行恢復。

差量轉儲：對最近一次數據庫完全轉儲以來發生的數據變化進行轉儲。

11.2.3 多種轉儲方法結合使用

• 僅使用完全轉儲：占據時間和空間多，代價大。
• 完全轉儲+增量轉儲：恢復時間較長。
• 完全轉儲+差量轉儲：恢復時間短。

11.3 日志文件

11.3.1 日志文件的概念

DBMS運行中，將所有事務的修改操作登記到日志文件。

作用：事務故障恢復和系統故障恢復必須使用日志文件。

在動態轉儲方式中必須建立日志文件。

在靜態轉儲方式中也可使用日志文件。

11.3.2 日志文件的格式與內容

兩種格式：

1.以記錄為單位的日志文件

需要記錄的內容：

各個事務的開始標記 BEGIN TRANSACTION

各個事務的結束標記 COMMIT OR ROLLBACK

各個事務的所有更新操作

2.以數據塊為單位的日志文件

日志記錄的內容包括：事務標識和被更新的數據塊

11.3.3 登記日志文件的原則

登記的次序嚴格按并行事務執行的時間次序。保證事務對數據庫的操作的可再現性和正確性。

必須先寫日志文件，后寫數據庫。 先后順序導致必然性。

11.3.4 檢查點

1.檢查點的作用

檢查點的作用:最大限度地減少數據完全恢復時必須執行的日志部分。

2.檢查點的引入

在日志中增加檢查點記錄，增加一個“重新開始文件”。
　　
檢查點記錄的內容：建立檢查點時刻正執行的事務清單；這些事務最近一個日志記錄的地址。

重新開始文件記錄的內容：各個檢查點記錄在日志中的地址。

3.基于檢查點的恢復步驟

從“重新開始文件”中找到最后一個檢查點記錄在日志文件中的地址，從而找到最后一個檢查點記錄。

由該檢查點記錄得到執行的事務清單ACTIVE_LIST。

從檢查點開始正向掃描文件。

對UNDO-LIST中的事務執行UNDO， 對REDO-LIST中的事務執行REDO。

11.4 硬件容錯方案

11.4.1 概述

由于數據庫運行的硬件故障、機房電力故障、機房自然災害等，要求從硬件級別對DBMS進行保護。

從DBMS運行所需要的各種環境出發，分析支撐數據庫系統運行的環節。

相關度最緊密的技術：數據庫存儲保護技術，服務器容錯技術及數據庫鏡像與容災技術。

11.4.2 磁盤保護技術

RAID：廉價冗余磁盤陣列，多塊磁盤構成的一個整體。
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-ROnrtopg-1581906147983)(en-resource://database/2053:0)]

RAID依靠冗余技術 數據保護：

鏡像冗余
　　即把所有的數據復制到其他設備。
　　額外開銷大：更多的磁盤、控制器、電纜。

校驗冗余
　　對成員磁盤的數據執行異或（XOR）操作，得到其校驗值，并存放在另外的校驗盤上。
　　實現復雜，但比鏡像冗余占據的空間小。

RAID根據所采用的方法不同，分為RAID-0，RAID-1，RAID-1E，RAID-5，RAID-6，　RAID-7，RAID-10，RAID-50，RAID-60。

• RAID-0：將多個磁盤合并成一個大的磁盤，不具有冗余，并行I/O，速度最快。
• RAID-1：兩組以上的N個磁盤相互作鏡像，在一些多線程操作系統中能有很好的讀取速度，理論上讀取速度等于硬盤數量的倍數，另外寫入速度有微小的降低。只要一個磁盤正常即可維持運作，可靠性最高。
• RAID-5：RAID Level 5是一種儲存性能、數據安全和存儲成本兼顧的存儲解決方案。它使用的是Disk Striping（硬盤分區）技術。RAID 5至少需要三顆硬盤，RAID 5不是對存儲的數據進行備份，而是把數據和相對應的奇偶校驗信息存儲到組成RAID5的各個磁盤上，并且奇偶校驗信息和相對應的數據分別存儲于不同的磁盤上。
• RAID-10：RAID0與RAID-1的組合體，繼承了前者的快速，后者的安全。 RAID-10冗余度為50%。

11.4.3 服務器容錯技術

引入服務器容錯原因
　　解決服務器硬件異常問題。

服務器容錯技術簡介
　　采用兩臺相同的服務器，共享存儲設備。（雙機熱備，Active-Standby）
　　兩臺服務器之間會有私有網絡進行心跳檢測。

服務器接管過程
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-DJztPdnJ-1581906147984)(en-resource://database/2057:0)]

其他服務器容錯技術
　　硬件級別：自行設計制造的專用軟硬件架構。
　　軟件級別：專門的服務器級別容錯技術，如Oracle提供了RAC架構。

11.4.4 數據庫鏡像與數據庫容災

引入數據庫鏡像原因
　　前面幾種恢復技術都必須及時正確地轉儲數據庫。
數據庫鏡像簡介
　　是一種用于提高數據庫可用性的解決方案，它根據DBA的要求，自動把整個數據庫或關鍵數據復制到另一個磁盤上。
數據庫鏡像分類

• 雙機互備援模式：兩臺機器均為工作機。正常狀況下均為系統提供支持，互相監視對方的運行情況。
• 雙機熱備份模式：一臺為工作機，一臺為備份機。工作機為系統提供支持，備份機監視工作機的運行情況。

工作方式
　　“數據庫鏡像會話”中，主體服務器和鏡像服務器作為“伙伴”進行通信和協作。在會話中扮演互補角色。一旦出現故障，使用“角色切換”過程來互換主體服務器和鏡像服務器。

SQL Server數據庫鏡像簡介
　　SQL Server數據庫鏡像是將數據庫事務處理從一個SQL Server數據庫移到不同的SQL Server數據庫。
　　鏡像的復制是一個備用的復制，不能直接訪問，只用來進行錯誤恢復。
　　“見證服務器”使鏡像服務器自動識別。
　　兩種運行模式 ：“高安全性模式”及運行模式。
SQL Server數據庫鏡像提供三種實現方式：
　　高可用性。兩臺服務器同步事務寫入，支持自動錯誤恢復。
　　高保護性。兩臺服務器同步事務寫入，手工錯誤恢復。
　　高性能。兩臺服務器寫入不同步，手工錯誤恢復。

---

附錄 參考文獻

---

[1] 何玉潔，劉乃嘉. 全國計算機等級考試三級教程——數據庫技術. 2019版. 北京：高等教育出版社，2019.
[2] 小賢賢233. 計算機三級數據庫技術筆記. CSDN, 2020.
[3] 233網校. 計算機三級數據庫技術. 233網校，2020.

總結

以上是生活随笔為你收集整理的计算机三级 数据库技术 学习笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。