數據庫設計

• 數據庫設計定義
  數據庫設計 是指對于一個給定的應用環境，構造（設計）優化的數據庫邏輯模式和物理結構，并據此建立數據庫及其應用系統，使之能夠有效的存儲和管理數據，滿足各種用戶的應用需求，包括信息管理要求和數據操作要求。

• 數據庫設計的特點

  • 數據庫建設的基本規律
    三分技術，七分管理，十二分基礎數據

  • 結構（數據）設計和行為（處理）設計相結合

• 數據庫設計方法
  • 新奧爾良（New Orleans） 方法
    屬于規范設計法，思想：過程迭代逐步求精
  • 基于 E-R 模型的數據庫設計方法（最常用的方法）
  • 3NF(第三范式)設計方法
  • ODL(Object Definition Language) 面向對象數據庫設計方法

• 數據庫設計基本步驟
  • 需求分析
  • 概念結構設計
  • 邏輯結構設計
  • 物理結構設計
  • 數據庫實施
  • 數據庫運行和維護

需求分析的方法

調查用戶需求的具體步驟：

1. 調查組織機構情況，包括了解該組織的部門組成情況，各部門的職責等，為分析信息流程做準備
2. 調查各部門的業務活動情況，包括了解各個部門輸入和使用什么數據，如何加工處理這些數據，輸出什么信息，輸出到什么部門，輸出結果的格式是什么。這是調查的重點
3. 再熟悉了業務活動基礎上，協助用戶明確對新系統的各種要求，包括信息要求，處理要求，安全性與完整性要求
4. 確定新系統的邊界，對前面調查的結果進行初步分析，確定哪些功能由計算機完成或將來準備讓計算機完成，哪些活動由人工完成，由計算機完成的功能就是新系統應該實現的功能。

常用的調查方法：

1. 跟班作業，通過親身參加業務工作來了解業務活動情況
2. 開調查會。通過與用戶座談來了解業務活動情況及用戶需求
3. 請專人調查
4. 詢問，對某些調查中的問題，可以找專人詢問
5. 設計調查表請用戶填寫。如果調查表設計的合理，這種方法是很有效的
6. 查閱記錄，查閱與原系統有關的數據記錄

數據字典

數據字典：系統中各類數據描述的集合。進行詳細的數據收集和數據分析所獲得的主要成果

1. 數據項
   不可分的數據單位
   數據項描述 = |數據項名，數據項含義說明，別名，數據類型，長度，取值范圍，取值含義，與其他數據項的邏輯關系，數據項之間的聯系|

2. 數據結構
   數據結構反應了數據之間的組合關系，一個數據結構可以由若干個數據項組成，也可以由若干個數據結構組成，或由若干個數據結構混合組成，對數據結構的描述通常包含以下內容：
   數據結構描述 = |數據結構名，含義說明，組成：|數據項或數據結構||

3. 數據流
   數據流是數據結構在系統內傳輸的路徑。對數據流的描述通常包括下面的內容
   數據流描述 = |數據流名，說明，數據流來源，數據流去向，組成：|數據結構|,平均流量，高峰期流量|

4. 數據存儲
   數據存儲描述 = |數據存儲名，說明，編號，輸入的數據流，輸出的數據流，責成|數據結構|，數據量，存取頻度，存取方式|

5. 處理過程
   處理過程描述 = |處理過程名，說明，輸入:|數據流|，輸入:|數據流|,處理：|簡要說明||

   數據字典是關于數據庫中數據的描述，即元數據，而不是數據本身

概念結構設計

將需求分析得到的用戶需求抽象為信息結構即概念模型的過程就是概念結構設計

• 概念結構
  特點如下：

  1. 能真實、充分地反映現實世界，包括事物和事物之間的聯系，能滿足用戶對數據的處理要求，是對現實世界的一個真實模型
  2. 易于理解，從而可以用它和不熟悉計算機的用戶交換意見，用戶的積極參與是數據庫設計成功的關鍵
  3. 易于更改，當應用環境和應用要求更改時，容易對概念模型修改和擴充
  4. 易于向關系、網狀、層次等各種數據模型轉換。

  概念模型的工具是 E-R 模型

概念結構設計的方法與步驟

• 自頂向下，首先定義全局概念結構的框架，然后逐步細化
• 自底向上，首先定義各個局部應用的概念結構，然后將他們集成起來，得到全局概念結構。
• 逐步擴展。首先定義最重要的核心概念結構，然后向外擴充，以滾雪球的方式逐步生成其他概念結構，直至總體概念結構
• 混合策略。即將自頂下下和自底向上相結合，用自頂向下策略設計一個全局概念結構的框架，以它為骨架集成自底向上策略中設計的各局部概念結構

經常采用的策略是自底向上的方法，即自頂向下的錦訊需求分析，然后再自底向上的設計概念結構

需求分析--> 分 E-R 圖--> 總 E-R 圖

數據抽象與局部視圖設計

三種抽象

• 分類 （Classification）
• 聚集 （Aggregation）
• 概括 （Generalization）

E-R 圖調整：
為了簡化 E-R 圖的處置，現實世界的事物能作為屬性對待的，盡量作為屬性對待。

屬性：

• 作為屬性，不能再具有需要描述的性質。屬性必須是不可分割的數據項，不能包含其他屬性
• 屬性不能與其他實體具有聯系，即 E-R 圖中所表示的聯系是實體之間的聯系

根據需求分析結果 畫出第一層數據流圖，第二層數據流圖等

分別設計它們的 分 E-R 圖 再匯總成 局部應用的 分 E-R 圖

視圖的集成

將所有的分 E-R 圖綜合成一個系統的總 E-R 圖。

• 兩種集成方式

  • 多個分 E-R 圖一次集成
  • 逐步集成，用累加的方式一次集成兩個分 E-R 圖

• 集成過程

  • 合并，解決各分 E-R 圖之間的沖突，將各分 E-R 圖合并起來生成初步 E-R 圖
  • 修改和重構。消除不必要的冗余，生成基本 E-R 圖

• 合并分 E-R 圖，生成初步 E-R 圖

  1. 屬性沖突
     屬性域沖突，即屬性值得類型、取值范圍或取值集合不同、例如零件號，有的部門把它定義為整數，有的部門把它定義為字符型。不同的部門對零件號和編碼也不同。又如年齡，某些部門以出生年月日期形式表示職工的年齡，而另一些部門用整數表示職工的年齡。
     屬性取值單位沖突，例如，零件的重量有的以公斤為單位，有的以斤為單位，有的以克為單位。

  屬性沖突需要各部門討論協商，解決起來并非易事

  2. 命名沖突
     同名異議，不同意義的對象在不同的局部應用中具有相同的名字
     異名同義（一義多名），即同一意義的對象在不同的局部應用中具有不同的名字。如對科研項目，財務科稱為項目，科研處稱為課題，生產管理處稱為工程

  處理命名沖突通常也像處理屬性沖突一樣，通過討論，協商等行政手段加以解決

  3. 結構沖突
     同一對象在不同應用中具有不同的抽象，例如，職工在某一局部應用中被當做實體，而在另一局部應用中則被當做屬性

  解決辦法，通常是把屬性變換為實體 或 把實體變換為屬性，使同一對象具有相同的抽象。

同一實體在不同分 E-R 圖中所包含的屬性個數和屬性排列次序不完全相同。

解決辦法，使該實體的屬性取各分 E-R 圖中屬性的并集，再適當調整屬性的次序

• 消除不必要的冗余，設計基本 E-R 圖

邏輯結構設計

邏輯結構設計步驟

• 將概念結構轉換為一般關系、網狀、層次模型
• 將轉換來的關系、網狀、層次模型向指定

DBMS 支持下的數據模型轉換。

• 對數據模型進行優化

• E-R 圖向關系模型的轉換
  一個實體型轉換為一個關系模式，實體的屬性就是關系的屬性，實體的碼就是關系的碼

對于實體型間的聯系則有一下不同的情況：

1. 一個 1:1 聯系可以轉換為一個獨立的關系模式，也可以與任意一端對應的關系模式合并。如果轉換為一個獨立的關系模式，則與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性，每個實體的碼均是該關系的候選碼。如果與某一端實體對應的關系模式合并，則需要在該關系模式的屬性中加入另一個關系模式的碼和聯系本身的屬性。

2. 一個 1：n 聯系可以轉換為一個獨立的關系模式，也可以與 n 端 對應的關系模式合并。如果轉換為一個獨立的關系模式，則與該聯系相連的各實體的碼以及聯系本身的屬性均轉化為關系的屬性，而關系的碼為 n 端實體的碼

3. 一個 m:n 聯系轉換為一個關系模式。與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性，各實體的碼組成關系的碼或關系碼的一部分

4. 3 個或 3 個以上實體間的一個多元聯系可以轉換為一個關系模式。與該多元聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性，各實體的碼組成關系的碼或關系嗎的一部分

5. 具有相同碼的關系模式可以合并

• 數據模型的優化

  1. 確定數據依賴，按需求分析階段所得到的語義，分別寫出每個關系模式內部各屬性之間的數據依賴以及不同關系模式屬性之間的數據依賴。

  2.對于各個關系模式之間的數據依賴進行極小化處理，消除冗余的聯系

  3. 按照數據依賴的理論對關系模式逐一進行分析，考察是否存在部分函數依賴、傳遞函數依賴、多值依賴等，確定各關系模式分別屬于第幾范式

  4. 按照需求分析階段得到的處理要求，分析對于這樣的應用環境這些模式是否合適，確定是否要對某些模式進行合并或分解

  5. 對關系模式進行必要的分解，提高數據操作的效率和存儲空間的利用率。常用的兩種分解方法是水平分解和垂直分解。

     水平分解是把（基本）關系的元祖分成若干子集合，定義每個子集合為一個子關系，以提高系統的效率。根據“80/20”原則，一個大關系中，經常被使用的數據只是關系的一部分，約20%，可以把經常使用的數據分解出來，形成一個子關心。如果關系 R 上 具有 n 個事物，而且多數事物存取的數據不想交，則 R 可以分解為少于或等于 n 個子關系， 使每個事物存取的數據對應一個關系

     垂直分解就是把關系模式 R 的屬性分解為若干子集合，形成若干子關系模式。垂直分解的原則是，經常在一起使用的屬性從 R 中 分解出來形成一個子關系模式。垂直分解可以提高某些事物的效率，但也可以使另一些事務不得不執行鏈接操作，從而降低了效率。因此是否進行垂直分解取決于分解后 R 上的所有事務的總效率是否得到了提高。垂直分解需要確保無損鏈接性和保持函數依賴，即保證分解后的關系具有無損連接性和保持函數依賴性。

• 設計用戶子模式 （view 視圖模式）

  1. 使用更符合用戶習慣的別名

  2. 可以對不同級別的用戶定義不同的 View，以保證系統的安全性

  3. 簡化用戶對系統的使用

數據庫的物理設計

數據庫物理設計通常分為兩步：

1. 確定數據庫的物理結構，在關系數據庫中主要指存取方法和存儲結構

2. 對物理結構進行評價，評價的終點是時間和空間效率

• 數據庫物理設計的內容和方法
  查詢：

  • 查詢的關系
  • 查詢條件所設計的屬性
  • 鏈接條件所涉及的屬性
    - 查詢的投影屬性

  更新：

  • 被更新的關系
  • 每個關系上的更新操作條件所涉及的屬性
  • 修改操作要改變的屬性值

內容：

• 為關系模式選擇存取方法

• 設計關系、索引等數據庫文件的物理存儲結構

• 關系模式存取方法選擇
  存取方法是快讀存取數據庫中的數據，常用的有三類

• 索引存取方法
  根據應用要求確定對關系的哪些屬性列建立索引、哪些屬性列建立組合索引、哪些索引要設計為唯一索引等

  1. 如果一個（或一組）屬性經常在查詢條件中出現，則考慮在這個（或這組）屬性上建立索引（或組合索引）
  2. 如果一個屬性經常違最大值和最小值等聚集函數的參數，則考慮在這個屬性上建立索引。
  3. 如果一個（或一組）屬性經常在鏈接操作的鏈接條件中出現，則考慮在這個（或這組）屬性上建立索引

• 聚簇存取方法
  為了提高某個屬性（或屬性組）的查詢素的，把這個或這些屬性（稱為聚簇碼）上具有相同值得元祖集中存放在連續的物理塊稱為聚簇

  1. 經常在一起進行連接操作的關系可以建立聚簇
  2. 如果一個關系的一組屬性經常出現在相等比較條件中，則該單個關系可建立聚簇
  3. 如果一個關系的一個（或一組）屬性上的值重復率很高，則此單個關系可建立聚簇。

• HASH 存取方法的選擇
  如果一個關系的屬性主要出現在等值鏈接條件中或主要出現在相等比較選擇條件中，而且滿足下列兩個條件之一，則此關系可以選擇 HASH 存取方法。
  1. 如果一個關系的大小可以預知，而且不變
  2. 如果關系的大小動態改變，而且數據庫管理系統提供了動態 HASH 存取方法

• 確定數據庫的存儲結構
  確定數據庫物理結構主要指確定數據的存放位置和存儲結構，包括：確定關系、索引、聚簇、日志、備份等存儲安排和存儲結構，確定系統配置等

  1. 確定數量的存放位置
  2. 確定系統配置

• 評價物理結構
  對時間效率、空間效率、維護代價和各種用戶要求進行權衡。

數據庫的實施和維護

• 數據的載入和應用程序的調試
  先載入少量數據調試，運行合格后，再大批輸入數據，逐步增加數據量。。。

• 數據庫調試試運行
  首先調試運行DBMS 的恢復功能。

• 數據庫的運行和維護
  下面都是 DBA 的職責

  • 數據看的轉儲 和 恢復
  • 數據庫的安全性、完全性控制
  • 數據庫性能的監督、分析和改造
  • 數據庫的重組織與重構造