文章目錄

• 第一章 數據庫應用系統開發方法
• • 1.1 數據庫應用系統生命周期
  • • 1.1.1 軟件工程與軟件開發方法
    • 1.1.2 DBAS生命周期模型
  • 1.2 規劃與分析
  • • 1.2.1 系統規劃與定義
    • 1.2.2 可行性分析
    • 1.2.3 項目規劃
  • 1.3 需求分析
  • • 1.3.1 數據需求分析
    • 1.3.2 功能需求分析
    • • 1.數據處理需求分析
      • 2.業務規則需求分析
    • 1.3.3 性能需求分析
    • 1.3.4 其他需求分析
    • • 1. 存儲需求分析
      • 2. 安全性需求分析
      • 3.備份和恢復需求分析
  • 1.4 系統設計
  • • 1.4.1概念設計
    • • 1.數據庫概念模型設計
      • 2. 系統總體設計
    • 1.4.2邏輯設計
    • • 1.數據庫邏輯結構設計
      • 2.應用程序概要設計
      • 3.數據庫事務概要設計
    • 1.4.3 物理設計
    • • 1.數據庫物理結構設計
      • 2.數據庫事務詳細設計
      • 3.應用程序詳細設計
• 第二章 需求分析
• • 2.1 需求分析
  • • 2.1.1 需求分析的概念與意義
    • 2.1.2 需求獲取的方法
    • 2.1.3 需求分析過程
  • 2.2 需求分析方法
  • • 2.2.1 需求分析方法概述
    • 2.1.2 DFD需求建模方法
    • • 1. DFD方法的基本元素
      • 2. DFD圖
      • 3. DFD建模過程
    • 2.2.3 其他需求建模方法
    • • 1. IDEF0方法簡介
      • 2. UML用例模型簡介
    • 2.2.4 DFD和IDEF0比較
• 第三章 數據庫結構設計
• • 3.1 數據庫概念設計
  • • 3.1.1 概念設計的任務
    • 3.1.2 概念設計的依據及過程
    • • 1.概念設計的依據
      • 2.概念設計的過程
    • 3.1.3 數據建模方法
    • • 1.ER建模方法
      • 2. IDEF1X建模方法
  • 3.2 數據庫邏輯設計
  • • 3.2.1 概述
    • 3.3.2 邏輯設計實例
  • 3.3 數據庫物理設計
  • • 3.3.1 物理設計概述
    • 3.3.2 數據庫的物理結構
    • 3.3.3 索引
    • • 1. 索引技術
      • 2.索引技術分類
      • 3. 有序索引
    • 3.3.4 數據庫物理設計
    • • 1. 物理設計內容
      • 2. 數據庫邏輯模式描述
      • 3.DB文件組織與存取設計
      • 4. 數據分布設計
      • • （1）不同類型數據的物理分布
        • （2）應用數據的劃分與分布
        • （3）派生屬性劃分
        • （4）關系模式去規范化
    • 3.3.5 其他物理設計環節
    • • 1. 確定系統配置
      • 2. 物理模式評估
• 第四章 數據庫應用系統功能設計與實施
• • 4.1 軟件體系結構與設計過程
  • • 4.1.1 軟件體系結構
    • 4.1.2 軟件設計過程
    • • 1.概要設計
      • 2.詳細設計
      • 3.關于軟件總體設計
  • 4.2 DBAS總體設計
  • • 4.2.1 DBAS體系結構設計
    • • 1. 客戶/服務器結構
      • 2. 瀏覽器/服務器結構
    • 4.2.2 DBAS軟件總體設計
    • 4.2.3 軟硬件選型與配置設計
    • 4.2.4 業務規則初步設計
  • 4.3 DBAS功能概要設計
  • • 4.3.1 表示層概要設計
    • 4.3.2 業務邏輯層概要設計
    • 4.3.3 數據訪問層概要設計
  • 4.4 DBAS功能詳細設計
  • • 4.4.1 表示層詳細設計
    • 4.4.2 業務邏輯層詳細設計
    • 4.5 應用系統安全架構設計
    • • 4.5.1 數據安全設計
      • 1. 數據庫的安全性保護
      • 2. 數據庫的完整性保護
      • 3. 數據庫的并發控制
      • 4.數據庫的備份與恢復
      • 5.數據加密傳輸
    • 4.5.2 環境安全設計
    • • 1. 漏洞與補丁
      • 2. 計算機病毒防護
      • 3. 網絡環境安全
      • 4. 物理環境安全
    • 4.5.3 制度安全設計
  • 4.6 DBAS實施
  • • 4.6.1 創建數據庫
    • 4.6.2 數據裝載
    • 4.6.3 編寫與調試應用程序
    • 4.6.4 數據庫系統試運行
    • • 1. 功能測試
      • 2. 性能測試
• 第五章 UML與數據庫應用
• • 5.1 DBAS建模
  • 5.2 DBAS業務流程與需求表達
  • • 5.2.1 業務流程與活動圖
    • 5.2.2 系統需求與用例圖
    • • 1. 系統
      • 2. 角色
      • 3. 用例
  • 5.3 DBAS系統內部結構的表達
  • • 5.3.1 系統結構與類圖
    • • 1. 屬性
      • 2. 操作
      • 3. 關系
      • • • 1. 關聯關系
          • 1. 雙向關聯
          • 2. 單向關聯
          • 3. 多重性
          • 4.關聯類
          • 5. 聚集
        • 2. 繼承關系
        • 3. 依賴關系
        • 4. 精化關系
    • 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.2 使用TOP限制結果集
• 第九章 安全管理
• • 9.1 安全控制概述
  • • 1.數據庫安全控制的目標
    • 2.數據庫安全的威脅
    • 3.安全控制模型
    • 4.授權和認證
  • 9.2 存取控制
  • • 9.2.1 自主存取控制
    • • 1.權限種類
      • 2.用戶分類
    • 9.2.2 強制存取控制
  • 9.3 審計跟蹤
  • 9.4 統計數據庫的安全性
  • 9.5 SQL server的安全控制
  • • 9.5.1 身份驗證模式
    • • 1.windows身份驗證模式
      • 2.混合驗證模式
    • 9.5.2 登錄賬戶
    • • 1.建立登錄賬戶
      • 2.修改登錄賬戶屬性
      • 3. 刪除登錄賬戶
    • 9.5.3 數據庫用戶
    • • 1.建立數據庫用戶
      • 2.Guest用戶
      • 3.刪除數據庫用戶
    • 9.5.4 權限管理
    • • 1. 對象級別的權限
      • • （1）授權語句

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

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

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

• 瀑布模型
• 快速原型模型
• 螺旋模型

1.1.2 DBAS生命周期模型

• 項目規劃
• 需求分析
• 系統設計
• 實施與部署
• 運行與維護

1.2 規劃與分析

1.2.1 系統規劃與定義

任務陳述

確定任務目標

確定系統范圍和邊界

確定用戶視圖

1.2.2 可行性分析

經濟可行性

技術可行性

操作可行性

開發方案選擇

1.2.3 項目規劃

1.3 需求分析

DBAS需求分析規范說明書

1.3.1 數據需求分析

數據字典包括數據項、數據結構、數據流、數據存儲和處理過程五部分

1.3.2 功能需求分析

1.數據處理需求分析

分析結果可表示為數據流圖（DFD）或DBAS應支持的各種數據處理事務規范
事務規范包括：

• 事務名稱
• 事務描述。功能、性能、完整性約束等方面的描述
• 事務所訪問的數據項
• 事務用戶。啟動或執行該事務的事件或用戶

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

2.業務規則需求分析

應用領域業務規則描述了應用領域中的業務功能、處理流程和步驟

1.3.3 性能需求分析

性能指標包括：

• 數據響應時間
• 系統吞吐量
• 允許并發訪問的最大用戶數
• 每TPS代價值

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

• 系統硬件資源
• 網絡通信設備性能
• 操作系統環境
• 數據庫邏輯設計和物理設計質量
• DBMS的配置與性能
• 數據庫應用程序自身

1.3.4 其他需求分析

1. 存儲需求分析

• 初始數據庫大小
• 數據庫增長速度

2. 安全性需求分析

• DBAS系統應達到的安全控制級別
• 各類用戶數據的數據視圖和視圖訪問權限

3.備份和恢復需求分析

• 備份數據庫的時間和備份周期
• 備份全部數據還是其中一部分
• 備份方式是采用完全備份還是差異備份

1.4 系統設計

1.4.1概念設計

概念設計包括數據庫概念模型設計和系統總體設計

1.數據庫概念模型設計

2. 系統總體設計

• DBAS體系結構設計
• 系統硬件平臺的選型和配置
• 應用軟件結構設計
• 業務規則初步設計
• 對系統關鍵技術進行方案選型和初步設計

1.4.2邏輯設計

1.數據庫邏輯結構設計

2.應用程序概要設計

3.數據庫事務概要設計

1.4.3 物理設計

1.數據庫物理結構設計

2.數據庫事務詳細設計

3.應用程序詳細設計

第二章 需求分析

2.1 需求分析

2.1.1 需求分析的概念與意義

需求分析就是對待開發的系統要做什么，完成什么功能的全面描述。
軟件產品的下列特性使得需求獲取困難重重：

• 軟件功能復雜
• 需求的可變性
• 軟件產品的不可見性

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

2.1.2 需求獲取的方法

面談

實地觀察

問卷調查

查閱資料

2.1.3 需求分析過程

標識問題

建立需求模型

描述需求

• 需求概述
• 功能需求
• 信息需求
• 性能需求
• 環境要求
• 其他需求

確認需求
需求確認與評審以下項目：

• 功能需求
• 數據需求
• 性能
• 數據管理
• 其他需求

2.2 需求分析方法

2.2.1 需求分析方法概述

結構化分析與功能建模方法有DFD和IDEF0等
基本特征是抽象和分解
優點：

• 不過早陷入具體細節
• 從整體或宏觀入手分析問題
• 通過圖形化模型對象直觀地表示系統要做什么，完成什么功能
• 圖形化建模方法方便分析員理解和描述系統
• 模型對象不涉及太多屬術語，便于用戶理解術語

2.1.2 DFD需求建模方法

DFD建模方法，也被稱為過程建模和功能建模方法
核心是數據流

1. DFD方法的基本元素

• 數據流：用一個箭頭表示數據的流向
• 處理：表示對數據進行的加工或變換，以矩形框表示
• 數據存儲：表示數據庫形式（文件形式）存儲的數據
• 外部項（又稱數據源或數據終點）：以圓角框或平行四邊形表示

2. DFD圖

自頂向下，逐步細化

3. DFD建模過程

明確目標，確定系統范圍

建立頂層DFD

構建第一層DFD

開發DFD層次結構圖

• 保持均勻的模型深度
• 按困難程度進行選擇
• 如果一個處理難以確切命名可以對它重新分解

檢查確認DFD圖

• 父圖中描述過的數據流必須在相應的子圖中出現
• 一個處理至少有一個輸入流和一個輸出流
• 一個存儲必定有流入的數據流和流出的數據流
• 一個數據流至少有一端是處理框
• 模型圖中至少有一端是處理框

2.2.3 其他需求建模方法

1. IDEF0方法簡介

基本元素矩形框和箭頭
矩形框代表功能活動，寫在矩形框中的短語描述功能活動的名稱，活動的編號按照要求寫在矩形框右下角指定位置

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

2. UML用例模型簡介

面向對象建模

2.2.4 DFD和IDEF0比較

• IDEF0不是強調流或順序，而是強調數據約束
• IDEF0中箭頭語義更豐富，不僅表示數據流還表示如何影響矩形所表示的活動
• 模型組成元素不同。IDEF0圖中箭頭從哪里來到哪里去可在專門文檔說明，不必表示在圖中

第三章 數據庫結構設計

3.1 數據庫概念設計

3.1.1 概念設計的任務

定義和描述應用領域涉及到是數據范圍

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

描述清楚數據之間的關系

定義和描述數據的約束

說明數據安全性要求

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

保證信息模型方便地轉換為數據庫的邏輯結構

3.1.2 概念設計的依據及過程

1.概念設計的依據

依據：需求說明書、功能模型、在需求分析階段收集到的應用領域或問題域的各類報表
構造：信息模型，數據庫概念設計說明書

2.概念設計的過程

明確建模目標

定義實體集：分類標識、概括命名

定義聯系

建立信息模型

確定實體集屬性

對信息模型進行集成和優化

3.1.3 數據建模方法

1.ER建模方法

• 實體或實例：指客觀存在并且可以相互區分的事物
• 實體集：表示一個現實的和抽象事物的集合，這些事物具有相同的屬性
• 屬性：用于描述一個實體集的性質和特征，每個屬性的取值范圍稱為域
• 碼：實體集中唯一標識每一個實例的屬性或屬性組稱為實體集的碼
• 聯系：描述現實世界事物的聯系
  • 一對一聯系
  • 一對多聯系
  • 多對多聯系

符號：

• 矩形框標識實體集
• 菱形框標識聯系
• 橢圓或圓角矩形框表示屬性

2. IDEF1X建模方法

建模元素：

• 實體集
  • 獨立實體集：每個實例都能被唯一地標識而不決定于它與其他實體集的聯系，矩形框表示
  • 從屬實體集：實體集的一個實例的唯一標識依賴于實體集與實體集的聯系，用圓角矩形框表示
    
• 聯系
  • 標定型聯系：在確定型連接聯系中，如果子女實體集中的每個實例都是由它與雙親 的聯系而確定的。
  • 非標定型聯系：在確定型連接聯系中，子女實體集中每一個實例都能被唯一地確認而無需了解與之相聯系的雙親實體集的實例
  • 分類聯系：是兩個或多個實體集之間的聯系，且在這些實體集中存在一個一般實體集，它的每一個實例都恰好與一個且僅一個分類實體集的一個實例相聯系。
  • 非確定關系：多對多

3.2 數據庫邏輯設計

3.2.1 概述

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

3.3.2 邏輯設計實例

規則：

一個實體型轉化為一個關系模式，實體的屬性就是關系的屬性，實體的碼就是關系的碼

一個m:n的聯系轉化為一個關系模式。關系的屬性是與該聯系相連的各實體的鍵以及聯系本身的屬性；關系的鍵是各實體鍵的組合。“選修”聯系是一個m:n的聯系，可以將它轉化為如下關系模式：選修（學號,課程號，成績）

一個1:n的聯系可以轉化為一個獨立關系模式，或者與n端對應的關系模式合并

轉化為獨立的關系模式：關系的屬性為與聯系相連的各實體的鍵以及聯系本身的屬性；關系的鍵為n端實體的鍵

與n端對應的關系模式合并：合并后關系的屬性為在n端關系中加上1端關系的鍵以及聯系本身的屬性；合并后關系的鍵不變。這種方法可以減少系統中關系的個數，一般情況下傾向于采用這種方法

一個1:1的聯系可以轉化為一個獨立的關系模式，也可與任一端的關系模式合并

• 轉化為一個獨立的關系模式。關系的屬性為與該關系相連的各實體的鍵以及聯系本身的屬性。每個實體的鍵是這個關系的候選碼
• 與某一段對應的關系合并。合并后關系的屬性，加入對應關系的鍵和聯系本身的屬性，合并后的鍵不變

三個或三個以上實體之間的一個多元聯系轉化為一個關系模式。關系屬性為該多元聯系相連的各個實體的鍵以及該聯系本身的屬性。關系的鍵是各個實體鍵的組合。例如“講授”是一個三元聯系，講授（教工號，課程號，書號）

同一實體集的實體間的聯系，即自聯系也可按照上述1:1,1:n,m:n三種情況分別處理處理。教師實體集內部存在領導與被領導的1:n的自聯系，可以將該聯系與教師實體合并，這時主鍵職工號將多次出現，可以用不同的屬性名加以區分，教師：{職工號，姓名，性別，職稱，系主任）

具有相同鍵的關系模式可以合并。目的是減少系統中關系的個數。合并方法，將其中一個關系模式的所有屬性加入到另一個關系模式中，然后去掉其中的同義屬性（可能同名也可能不同名），并適當調整屬性的次序

3.3 數據庫物理設計

3.3.1 物理設計概述

通常數據庫物理設計并不包括文件和數據庫具體的實現細節
需要了解不同文件組織方式、索引技術及其使用方法

3.3.2 數據庫的物理結構

3.3.3 索引

1. 索引技術

索引技術的關鍵是建立記錄域取值到記錄的物理地址間的映射關系，這種映射關系被稱為索引
在設計和創建索引時，應確保對性能的提高程度大于在存儲空間和處理資源方面的代價

2.索引技術分類

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

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

在一個文件中查找某個或某些特定文件記錄時，需要給出記錄應滿足的查詢條件。這種查詢條件形如“文件記錄在它的某個或某些記錄域/屬性上的取值滿足…條件”。這些用于數據文件中查找記錄的屬性或屬性集合就是文件查找碼。對于存儲有關系表數據的數據庫文件，該文件的查找碼可以是關系表的主碼或候選碼，也可以是關系表的其他非主屬性。

3. 有序索引

數據庫中的數據文件經常采用順序文件結構，文件的數據記錄按照某個特定的查找碼值的升序或降序順序地儲存在文件中。
索引文件建立的方法：首先選定數據文件中的某個或某些記錄域作為查找碼，然后建立起數據記錄在查找碼上的取值與該記錄物理地址間的映射關系，組成索引項。所有索引項作為索引記錄存儲在索引文件中。索引文件根據某個特定的查找碼值的升序或降序存儲索引記錄，并且也組織為順序文件。
一個數據文件可以有多個查找碼和多個索引文件

幾類主要的有序索引及其特點：

• 聚集索引和非聚集索引
  • 聚集索引：數據文件中國數據記錄的排列順序與索引文件中索引項的排列順序一致，或者說索引文件中按照其查找碼指定的順序與數據文件中數據文件的排列順序相一致。
  • 非聚集索引：數據文件中數據記錄的排列順序與索引文件中的索引項的排序不一致。
• 稠密索引與稀疏索引
  • 稠密索引：數據文件中每個查找碼在索引文件中都對應一個索引記錄
  • 稀疏索引：只是一部分查找碼的值有對應的索引記錄
• 主索引與輔索引
  • 主索引：在數據文件的主碼屬性值上建立的索引
  • 輔索引：在數據文件的非主屬性上建立的索引
• 唯一索引：可以確保索引列不包含重復的值。在多列唯一索引的情況下，可確保每個值的組合是唯一的。例如在last_name,first_name,middle_initial列的組合上創建了唯一索引full_name，則該表中任何兩個人都不可以具有相同的全名。
• 單層索引和多層索引
  當數據文件很大時，即使采用稀疏索引，建立的索引文件也會很大。可以對索引項本身再建立起一級稀疏索引，組成二層索引結構
  多層索引的典型例子是B數和B+樹索引

3.3.4 數據庫物理設計

1. 物理設計內容

數據庫邏輯模式描述

文件組織與存取設計

數據分布設計

確定系統配置

物理模式評估

2. 數據庫邏輯模式描述

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

設計基本表業務規范

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

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

基本表1

基本表2

基本表3

I

R

U

D

I

R

U

D

I

R

U

D

事務1

*

*

*

*

*

事務2

*

*

*

*

*

事務3

*

*

*

*

事務4

*

*

*

*

*

注： I-插入 R-讀取 U-更新 D-刪除

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

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

---

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

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

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

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

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

B樹和B+樹文件是實際數據庫系統中非常廣泛的索引文件結構，適合于定義在大數據量基本表上、基于查找碼的等值查詢、范圍從查詢、模糊查詢和部分查詢。B樹和B+樹屬于動態索引，可以隨著數據文件的內容變化不斷調整，保證數據查詢的性能不會惡化。

如某些頻繁執行且需要進行多表連接的操作的查詢，可以考慮將這些基本表組織為聚集文件，以改善查詢效率。

---

可以根據以下原則決定是否為一個基本表建立索引：

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

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

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

---

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

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

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

參與連接操作的屬性

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

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

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

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

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

4. 數據分布設計

（1）不同類型數據的物理分布

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

（2）應用數據的劃分與分布

對基本表的劃分可以依據下面不同原則

• 根據數據使用特征分：例如，如果一個基本表中有部分數據被頻繁查詢，并且要求查詢響應速度快，則可以將基本表分為頻繁使用分區和非頻繁使用分區，分別存儲在不同磁盤上。對頻繁使用分區中數據可以建立B+樹等多層索引，以提高數據訪問速度；對非頻繁使用分區中的數據可以不建或只建立單層索引
• 根據時間、地點劃分
• 分布式數據庫系統（DDBS）中的數據劃分。采用水平劃分和垂直劃分。數據劃分和分布的原則是數據應靠近其使用者，以降低查詢過程中的數據傳輸代價，提高數據訪問響應速度，并且通過副本冗余機制提高數據可靠性。

（3）派生屬性劃分

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

（4）關系模式去規范化

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

3.3.5 其他物理設計環節

1. 確定系統配置

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

2. 物理模式評估

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

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

4.1.1 軟件體系結構

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

4.1.2 軟件設計過程

軟件設計可分為概要設計和詳細設計兩大步驟。

1.概要設計

概要設計的任務是建立軟件系統的總體結構和模塊間的關系，定義各功能的接口，設計全局數據庫或數據結構，規定設計約束，制定測試計劃。
概要設計的要求：良好的總體結構，功能模塊間較低的耦合程度和功能模塊內較高的內聚度，并盡量降低接口復雜度。

2.詳細設計

3.關于軟件總體設計

對于大型復雜軟件系統，可根據逐步抽象和層次化原則，將概要設計分解為兩個步驟：

軟件總體結構設計，也就是對軟件需求進行分解。按照一定原則將其劃分為幾個若干個子系統；定義各個子系統應實現的功能和相互間的交互關系和通信機制。

將每個子系統進一步劃分為功能模塊，定義各個功能模塊的數據結構、相互間交互關系，根據需要，每個模塊進一步分解為多個子模塊

系統-子系統-模塊-子模塊
可將上述概要設計第一步稱為軟件總體設計，第二步稱為軟件概要設計。整個軟件設計過程都由總體設計、概要設計和詳細設計三步驟組成。

4.2 DBAS總體設計

廣義上，DBAS設計包括結構設計、過程設計和數據設計三個方面。
DBAS設計第一步是DBAS概念設計，包括數據庫概念模型設計和系統總體設計，概念模型設計屬于數據設計范疇，系統總體設計涵蓋結構設計，過程設計則由其后的事務和應用程序的概要設計和詳細設計完成。此外，數據設計除了數據庫設計之外還包括事務和應用程序中的數據結構設計。
DBAS總體設計內容：

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

4.2.1 DBAS體系結構設計

兩種常見DBAS體系結構

1. 客戶/服務器結構

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

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

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

2. 瀏覽器/服務器結構

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

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

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

4.2.2 DBAS軟件總體設計

4.2.3 軟硬件選型與配置設計

軟硬件選型涉及內容包括：

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

考慮以下因素：

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

4.2.4 業務規則初步設計

業務流程圖

4.3 DBAS功能概要設計

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

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

4.3.1 表示層概要設計

遵循以下原則

用戶應當感覺系統的運行始終在自己控制下

當系統發生錯誤或程序運行時間長時應該提供有意義的反饋信息

一個好的用戶界面應該容忍用戶的各種操作錯誤

用戶界面應該遵循一定的標準和常規

用戶界面應采取靈活多樣的數據輸入方式，盡量減少用戶的輸入負擔

使用web界面設計應具有簡潔性；清晰分類信息，導航；界面一致性；界面美觀與交互性能折中平衡

4.3.2 業務邏輯層概要設計

高內聚，松耦合

• 單一責任原則
• 獨立功能，減少功能重疊
• 接口簡單明確
• 某兩個構件間的關系比較復雜的話，應該進一步進行模塊劃分
• 構件過于復雜，可以考慮將其細分

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

4.3.3 數據訪問層概要設計

4.4 DBAS功能詳細設計

4.4.1 表示層詳細設計

原型迭代法

初步設計

用戶界面細節設計

原型設計與改進

4.4.2 業務邏輯層詳細設計

4.5 應用系統安全架構設計

4.5.1 數據安全設計

• 安全性保護：防止非法用戶對數據庫的非法使用，以避免數據的泄露篡改或破壞
• 完整性保護：即保證數據源的正確性和一致性
• 并發控制：即保證多個用戶能共享數據庫，并維護數據的一致性
• 數據庫的備份與恢復
• 數據加密傳輸

1. 數據庫的安全性保護

• 用戶身份鑒別
• 權限控制
• 視圖機制

2. 數據庫的完整性保護

數據庫中數據的正確性、一致性和相容性。

3. 數據庫的并發控制

常用技術：封鎖技術，一段時間禁止某用戶對數據對象做某些操作以避免數據不一致的問題
基本的封鎖一般包括排他鎖（x鎖）和共享鎖（s鎖）兩種類型
不可避免帶來死鎖問題，可以考慮以下原則：

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

4.數據庫的備份與恢復

數據庫恢復首先要建立冗余數據，然后利用這些冗余數據實施恢復

• 雙機熱備
• 數據轉儲
• 數據加密傳輸

5.數據加密傳輸

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

4.5.2 環境安全設計

1. 漏洞與補丁

2. 計算機病毒防護

• 安裝殺毒軟件，定期查殺病毒
• 計算機實時監控

3. 網絡環境安全

• 防火墻
• 入侵檢測系統
• 網絡隔離

4. 物理環境安全

4.5.3 制度安全設計

4.6 DBAS實施

創建數據庫

裝載數據

編寫與調試應用程序

數據庫試運行

4.6.1 創建數據庫

數據定義語言DDL
創建數據庫應該考慮：

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

4.6.2 數據裝載

篩選數據

轉換數據格式

輸入數據

檢驗數據

4.6.3 編寫與調試應用程序

4.6.4 數據庫系統試運行

1. 功能測試

2. 性能測試

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

第五章 UML與數據庫應用

5.1 DBAS建模

統一建模語言
UML的定義由語義和表示法兩部分組成。語義用自然語言描述，而表示法定義了UML可視化標準表示符號
UML語義是定義在一個四層（四個抽象級別）建模概念框架中，這四層分別：

元元模型層，組成了UML的最基本的元素“事物”，代表要定義的所有事物。

元模型層，組成了UML的基本元素，包括面向對象和面向組件的概念。這一層的每個概念都是元元模型中“事物”概念的實例。

模型層，組成了UML的模型，這一層中每個概念都是元模型層中概念的一個實例，這一層的模型通常叫做類模型或類型模型

用戶模型層，這層所有的元素都是UML模型的實例，這層中每個概念都是模型層的一個實例（通過分類）也是元模型層的一個實例。這一層的模型通常叫對象模型或實例模型。

視圖是對系統的模型在某方面的投影，注重于系統的某個方面
UML中包括五種視圖，結構視圖、實現視圖、行為視圖、環境視圖、用例視圖
UML2.0有十三種不同的圖
結構圖：類圖，對象圖，復合結構圖，包圖，組件圖，部署圖
行為圖：用例圖，交互圖（順序圖、通信圖、交互概述圖、時間圖）、狀態圖和活動圖

5.2 DBAS業務流程與需求表達

5.2.1 業務流程與活動圖

可以并行執行
起始點：指一連串活動的開始點。在一張活動圖中，必須有且只有一個起始點。
結束點：指一連串活動的終點。在一張活動圖中，可以有多個結束點。
加粗直線為同步條，表示這之后的活動路線可以并行執行，或在其上的所有并行活動執行完畢后，到此轉為順序執行。

5.2.2 系統需求與用例圖

用例模型是把滿足用戶需求的所有功能表示出來的工具。
用例模型由用例、角色、系統三部分組成。

1. 系統

長方框，系統的名字寫在方框上或方框里面，方框內部還可以包含該系統中用符號表示的用例。

2. 角色

角色是與系統交互的人或其他實體。所謂“與系統交互”指的是角色從系統中接收消息，或是向系統提交消息。一個角色可以執行多個用例，反過來，一個用例可以被多個角色使用。角色是類，所以它擁有與類相同的關系描述。在用例圖中用通用化關系來描述角色之間的行為。
通用化關系是指把某些角色的共同行為抽取出來作為通用行為，這些通用行為構成它們的超類。這樣在定義某一具體角色時，僅僅定義其不同的行為。角色之間的通用化關系用帶空心三角形（作為箭頭）的直線表示，箭頭的方向指向超類。

3. 用例

用例代表一個完整的功能，是所有動作的集合。動作是系統的一次操作，如與角色通信、進行計算，在系統內部進行的工作都可以稱為動作。
用例用橢圓表示，用例位于系統邊界的內部。用例與角色有連接關系，此關系屬于關聯又稱為通信關聯。這種關聯表明哪種角色能與該用例通信。關聯關系是雙向的一對一關系，表示不僅角色不僅可以與用例通信。用戶也可以與該角色通信，表示方法是一條連接角色和用例的帶箭頭直線。
用例之間存在關系，包括擴展、使用、組合三種。

• 擴展關系
  擴展使用的是繼承關系，即通用化關系的另一種體現形式。如果有一個用例，在這個用例的基礎上加入新的動作形成了另一個用例，即后者是通過繼承前者的屬性并加入新內容而來的，則前者稱為通用化用例，后者稱為擴展用例。擴展用例可以根據需要有選擇的繼承通用用例的部分行為。用例之間的擴展關系可以用帶有構造型<<extend>>標志的通用化關系
• 使用關系
  一個用例使用另一個用例時構成了使用關系，用例之間的使用關系用構造型具有<<use>>標志的通用化關系。
• 組合關系
  把相關的用例打成包，當做一個整體對待
  

5.3 DBAS系統內部結構的表達

5.3.1 系統結構與類圖

1. 屬性

屬性包括屬性的名稱、類型和缺省值。
可見性 名稱: 類型=缺省值 {約束性}

可見性

公有 +

受保護 #

私有 -

名稱

類型

缺省值

約束性：列出該屬性所有可能的取值，在定義枚舉類型的屬性時經常使用，每個枚舉值之間用逗號分隔，此外還可以用來說明該屬性的其他信息，比如屬性的持久性等。

2. 操作

可見性 名稱（參數表）：返回類型表達式（約束性）

可見性

名稱

參數表

返回類型表達式：可選項，依賴語言的描述

約束性

3. 關系

1. 關聯關系

1. 雙向關聯

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

2. 單向關聯

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

3. 多重性

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

4.關聯類

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

5. 聚集

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

2. 繼承關系

人們將具有共同特性的元素抽象成類別，并通過增加其內涵進一步分類。在面向對象方法中前者被稱為一般元素、基類元素或父元素，將后者稱為特殊元素或子元素
繼承關系表示為一頭為空心三角形的連線

3. 依賴關系

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

4. 精化關系

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

關系圖例

單向關聯	單向實線箭頭
雙向關聯	連接實線
共享聚集	空心菱形實線箭頭
組成	實心菱形實線箭頭
關聯類	連接虛線
依賴	虛線箭頭
繼承	實心三角形虛線箭頭
精化	空心三角形虛線箭頭

5.3.2 系統結構與順序圖

針對每一個特定的用例，如何用類圖所規范的對象，來完成用例交付的任務，就必須用順序圖表達。
順序圖有兩個坐標軸：縱向表示時間的持續過程，橫向表示對象，每一個對象用矩形框表示，縱向的虛線表示對象在序列中的執行情況，稱為對象的“生命線”
對象間的通信用對象生命線之間的水平消息線表示，消息線的箭頭說明消息的類型，單步、異步、簡單
順序圖中后面發生消息應該比前面發生的線畫的低一些，以表示他們之間的時間關系

當一個對象銷毀時，打一個x標記

5.3.3 系統結構與通信圖

通信圖是交互圖的一種，也稱為協作圖
順序圖和通信圖都描述交互，但是順序圖強調的是時間，通信圖強調的是空間
通信圖中主要元素基本和順序圖相同，只是在消息的傳遞上要特別表達消息的傳遞是由哪一個對象到另外一個對象

5.4 DBAS系統微觀設計的表達

5.4.1 微觀設計與對象圖

對象圖被用來描述特定時間點所有對象在系統中的結構，也可以把對象圖當成系統在某一時間的快照
對象圖是類圖的一個實例，對象之間的關系是類之間的關系

5.4.2 微觀設計與狀態機圖

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

5.4.3 微觀設計與時間圖

整個矩形框就是一個生命線

5.5 DBAS系統宏觀設計的表達

5.5.1 宏觀設計與包圖

包圖可以表達不同系統的包、命名空間或不同的項目間彼此的關系
包是一種組合機制，把模型元素通過內在的語義連在一起成為一個整體叫包
包通常被稱為子系統
包的圖示類似書簽卡片，由兩個長方形組成，小長方形位于大長方形的右上角
包圖是表明包與包之間關系的類圖

5.5.2 宏觀設計與交互概述圖

利用活動圖作為基礎，只是在控制流間連接的UML元素并非活動，而是交互圖（包括順序圖、通信圖、時間圖及交互概述圖）

5.5.3 宏觀設計與復合結構圖

復合結構圖最重要的元素是部件，一個部件可以代表某個實體組件，也可以代表一個子系統
部件與部件之間連接關系主要是裝配關系，這種關系通過接口溝通。部件與外部部件連接時必須通過端口才能實現，用正方形圖示。

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

5.6.1系統實現與組件圖

在UML中組件表示為一個大方塊且在它的左邊有兩個突出的小方塊

5.6.2 系統實現與部署圖

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

總結

第六章 高級數據查詢

6.1 一般數據查詢功能擴展

6.1.2 使用TOP限制結果集

top n [percent][with ties]

top n 取前n行
top n percent 取查詢結果前n%
with ties 表示包括最后一行取值并列的結果

第九章 安全管理

9.1 安全控制概述

安全性：保護數據以防止不合法用戶故意造成的破壞
完整性：保護數據以防止合法用戶無意中造成的破壞

1.數據庫安全控制的目標

數據庫安全控制的目標是保護數據免受意外或故意的丟失、破壞或濫用。

2.數據庫安全的威脅

• 可用性的損失。意味著用戶不能訪問數據或系統或者兩者都不能訪問
• 機密性數據的損失。機密性數據的損失是指數據庫中關鍵性機密數據的損失
• 私密性數據的損失。私密性數據的損失是指個人數據的損失
• 偷竊和欺詐
• 意外的損害

3.安全控制模型

4.授權和認證

授權是將合法訪問數據庫或數據庫對象的權限授予用戶的過程。
認證是一種鑒定用戶身份的機制
授權控制有時也被認為是訪問控制

• 自主存取控制
  用戶對不同的數據對象具有不同的存取權限，而且沒有固定的關于哪些用戶對哪些對象具有哪些存取權限的限制
• 強制存取控制
  每一個數據對象被標以一定的密級，每一個對象被授予一個許可證級別

9.2 存取控制

9.2.1 自主存取控制

1.權限種類

• 對數據庫管理系統進行維護
• 對數據庫中的對象和數據進行操作的權限
  • 語句權限：對數據庫對象的操作權限，包括創建、刪除和修改數據庫對象
  • 對象權限：對數據庫數據操作的權限，包括對表、視圖數據的增刪改查權限，存儲過程的執行權

2.用戶分類

系統管理員

數據庫對象擁有者。創建數據庫對象的用戶即為數據庫對象擁有者。

普通用戶

9.2.2 強制存取控制

將全部實體劃分為主體客體兩大類
敏感度標記被分為若干級別，例如絕密，秘密，可信和公開
主體的敏感度標記被稱為許可證級別，客體的敏感度標記被稱為密級

• 僅當主體的許可證級別大于或等于客體的密級時，該主體才能讀取相應的客體
• 僅當主體的許可證級別等于客體密級時，該主體才能寫相應的客體
  通用安全性分級模式

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 身份驗證模式

1.windows身份驗證模式

2.混合驗證模式

9.5.2 登錄賬戶

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 數據庫用戶

讓登錄賬戶成為數據庫用戶的操作是映射 。一個登錄賬戶可以映射為多個數據庫中的用戶。 默認情況下，新建立的數據庫只有一個用戶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）授權語句

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

grant select on Address to RoseQdm

例11

總結

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

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