第 3 章數據庫系統 3.2數據庫模式與範式

時間 2019-12-07

標籤數據庫系統 3.2 模式範式欄目 SQL 简体版

原文原文鏈接

第 3 章數據庫系統前端

隨着應用系統的規模愈來愈大，如今的系統開發大部分都是基於數據庫的應用，所以，做爲一名系統架構設計師，要熟練地掌握數據庫系統的設計方法和技術。程序員

本章在宏觀上就係統架構設計師必需要掌握的內容進行介紹，有關細節方面的知識，若是讀者感興趣，能夠參考數據庫專業教程。web

3.1 數據庫管理系統的類型算法

數據庫管理系統的類型一般有多個分類標準。如按數據模型分類、按用戶數分類、按數據庫分佈站點分類等。但咱們須要瞭解的，主要仍是按數據模型分類。數據庫

當前，許多商業 DBMS 中所用的主要數據模型還是關係數據模型。有些商業系統中實現了對象數據模型，但未獲得普遍使用。近幾年隨着 NoSQL 技術的興起，也產生了一些新的數據模型。目前常見的 DBMS 按數據模型劃分，包括：關係型 DBMS、文檔型 DBMS、鍵值型 DBMS、對象型 DBMS 等。安全

3.2 數據庫模式與範式服務器

數據庫模式與範式是數據庫系統中的兩個重要概念，是進行數據庫設計的基礎。網絡

3.2.1 數據庫的結構與模式數據結構

數據庫技術中採用分級的方法將數據庫的結構劃分爲多個層次。最著名的是美國 ANSI/ SPARC 數據庫系統研究組 1975 年提出的三級劃分法，如圖 3-1 所示。架構

三級抽象

數據庫系統劃分爲三個抽象級：用戶級、概念級、物理級。

（1）用戶級數據庫。用戶級數據庫對應於外模式，是最接近用戶的一級數據庫，是用戶能夠看到和使用的數據庫，又稱用戶視圖。用戶級數據庫主要由外部記錄組成，不一樣的用戶視圖能夠互相重疊，用戶的全部操做都是針對用戶視圖進行的。

（2）概念級數據庫。概念級數據庫對應於概念模式，介於用戶級和物理級之間，是全部用戶視圖的最小並集，是數據庫管理員可看到和使用的數據庫，又稱 DBA（DataBase Administrator，數據庫管理員）視圖。概念級數據庫由概念記錄組成，一個數據庫可有多個不一樣的用戶視圖，每一個用戶視圖由數據庫某一部分的抽象表示所組成。一個數據庫應用系統只存在一個 DBA 視圖，它把數據庫做爲一個總體的抽象表示。概念級模式把用戶視圖有機地結合成一個總體，綜合平衡考慮全部用戶要求，實現數據的一致性、最大限度下降數據冗餘、準確地反映數據間的聯繫。

（3）物理級數據庫。物理級數據庫對應於內模式，是數據庫的低層表示，它描述數據的實際存儲組織，是最接近於物理存儲的級，又稱內部視圖。物理級數據庫由內部記錄組成，物理級數據庫並非真正的物理存儲，而是最接近於物理存儲的級。

三級模式

數據庫系統的三級模式爲外模式、概念模式、內模式。

（1）概念模式。概念模式（模式、邏輯模式）用以描述整個數據庫中數據庫的邏輯結構，描述現實世界中的實體及其性質與聯繫，定義記錄、數據項、數據的完整性約束條件及記錄之間的聯繫，是數據項值的框架。

數據庫系統概念模式一般還包含有訪問控制、保密定義、完整性檢查等方面的內容，以及概念/物理之間的映射。

概念模式是數據庫中全體數據的邏輯結構和特徵的描述，是全部用戶的公共數據視圖。一個數據庫只有一個概念模式。

外模式是數據庫用戶（包括程序員和最終用戶）可以看見和使用的局部數據的邏輯結構和特徵的描述，是數據庫用戶的數據視圖，是與某一應用有關的數據的邏輯表示。一個數據庫能夠有多個外模式。一個應用程序只能使用一個外模式。

（2）外模式。外模式（子模式、用戶模式）用以描述用戶看到或使用的那部分數據的邏輯結構，用戶根據外模式用數據操做語句或應用程序去操做數據庫中的數據。外模式主要描述組成用戶視圖的各個記錄的組成、相互關係、數據項的特徵、數據的安全性和完整性約束條件。

（3）內模式。內模式是整個數據庫的最低層表示，不一樣於物理層，它假設外存是一個無限的線性地址空間。內模式定義的是存儲記錄的類型、存儲域的表示以及存儲記錄的物理順序，指引元、索引和存儲路徑等數據的存儲組織。

內模式是數據物理結構和存儲方式的描述，是數據在數據庫內部的表示方式。一個數據庫只有一個內模式。

內模式、模式和外模式之間的關係以下：

（1）模式是數據庫的中心與關鍵；

（2）內模式依賴於模式，獨立於外模式和存儲設備；

（3）外模式面向具體的應用，獨立於內模式和存儲設備；

（4）應用程序依賴於外模式，獨立於模式和內模式。

兩級獨立性

數據庫系統兩級獨立性是指物理獨立性和邏輯獨立性。三個抽象級間經過兩級映射（外模式—模式映射，模式—內模式映射）進行相互轉換，使得數據庫的三級造成一個統一的總體。

（1）物理獨立性。物理獨立性是指用戶的應用程序與存儲在磁盤上的數據庫中的數據是相互獨立的。當數據的物理存儲改變時，應用程序不須要改變。

物理獨立性存在於概念模式和內模式之間的映射轉換，說明物理組織發生變化時應用程序的獨立程度。

（2）邏輯獨立性。邏輯獨立性是指用戶的應用程序與數據庫中的邏輯結構是相互獨立的。當數據的邏輯結構改變時，應用程序不須要改變。

邏輯獨立性存在於外模式和概念模式之間的映射轉換，說明概念模式發生變化時應用程序的獨立程度。

希賽教育專家提示：邏輯獨立性比物理獨立性更難實現。

3.2.2 數據模型

數據模型主要有兩大類，分別是概念數據模型（實體—聯繫模型）和基本數據模型（結構數據模型）。

概念數據模型是按照用戶的觀點來對數據和信息建模，主要用於數據庫設計。概念模型主要用實體—聯繫方法（Entity-Relationship Approach）表示，因此也稱 E-R 模型。

基本數據模型是按照計算機系統的觀點來對數據和信息建模，主要用於 DBMS 的實現。基本數據模型是數據庫系統的核心和基礎。基本數據模型一般由數據結構、數據操做和完整性約束三部分組成。其中數據結構是對系統靜態特性的描述，數據操做是對系統動態特性的描述，完整性約束是一組完整性規則的集合。

經常使用的基本數據模型有層次模型、網狀模型、關係模型和麪向對象模型。

層次模型用樹形結構表示實體類型及實體間的聯繫。層次模型的優勢是記錄之間的聯繫經過指針來實現，查詢效率較高。層次模型的缺點是隻能表示 1:n 聯繫，雖然有多種輔助手段實現 m:n 聯繫，但比較複雜，用戶不易掌握。因爲層次順序的嚴格和複雜，致使數據的查詢和更新操做很複雜，應用程序的編寫也比較複雜。

網狀模型用有向圖表示實體類型及實體間的聯繫。網狀模型的優勢是記錄之間的聯繫經過指針實現，m:n 聯繫也容易實現，查詢效率高。其缺點是編寫應用程序的過程比較複雜，程序員必須熟悉數據庫的邏輯結構。

關係模型用表格結構表達實體集，用外鍵表示實體間的聯繫。其優勢有：

（1）創建在嚴格的數學概念基礎上；

（2）概念（關係）單一，結構簡單、清晰，用戶易懂易用；

（3）存取路徑對用戶透明，從而數據獨立性、安全性好，簡化數據庫開發工做。

3.2.2 關係代數

關係代數的基本運算主要有並、交、差、笛卡爾積、選擇、投影、鏈接和除法運算。

（1）並。計算兩個關係在集合理論上的並集，即給出關係 R 和 S（二者有相同元/列數），R∪S 的元組包括 R 和 S 全部元組的集合，形式定義以下：

RUSo{t|tÎRútÎS}

式中 t 是元組變量（下同）。顯然，R∪S=S∪R。

（2）差。計算兩個關係的區別的集合，即給出關係 R 和 S（二者有相同元/列數），R-S的元組包括 R 中有而 S 中沒有的元組的集合，形式定義以下：

R -So{t|tÎR ùtÏS}

（3）交。計算兩個關係集合理論上的交集，即給出關係 R 和 S（二者有相同元/列數），

R∩S 的元組包括 R 和 S 相同元組的集合，形式定義以下：

RISo{t |tÎRùtÎS}

顯然，R∩S = R-(R-S) 和 R∩S = S-(S-R)成立。

（4）笛卡爾積。計算兩個關係的笛卡爾乘積，令 R 爲有 m 元的關係，S 爲有 n 元的關係，則 R×S 是 m+n 元的元組的集合，其前 m 個元素來自 R 的一個元組，然後 n 個元素來自 S 的一個元組。造成定義以下：

R′So{t |t=<tr,ts >ùtr ÎRùts ÎS}

若 R 有 u 個元組，S 有 v 個元組，則 R×S 有 u×v 個元組。例如，有關係 R 與關係 S 如表 3-1 和表 3-2 所示。

對 R 與 S 作笛卡爾積運算，其結果有 4+2＝6 列，元組數量有 3*2＝6 條。如表 3-3

所示。

（5）投影。從一個關係中抽取指明的屬性（列）。令 R 爲一個包含屬性 A 的關係，

則

pA(R)o{t[A]|tÎR}

例如，對錶 3-1 關係 R 作投影操做， p1,2(R)，則結果如表 3-4 所示。

注意：在關係代數操做中涉及的數字表明的是列號，， p1,2(R)操做是對第 1 列與第 2

列作投影。

其中 F 表示選擇條件，是一個邏輯表達式（邏輯運算符+算術表達式）。選擇運算是從元組（行）的角度進行的運算。

（7）θ鏈接。θ鏈接從兩個關係的笛卡兒積中選取屬性之間知足必定條件的元組，記做：

其中 A 和 B 分別爲 R 和 S 上元數相等且可比的屬性組。θ 爲「=」的鏈接，稱爲等值鏈接，記做：

若是兩個關係中進行比較的份量必須是相同的屬性組，而且在結果中將重複的屬性去掉，則稱爲天然鏈接，記做：

例如，對錶 3-1 關係 R 與表 3-2 關係 S 作天然鏈接操做。結果集如表 3-6 所示。

（8）除。設有關係 R(X，Y)與關係 S(Z)，Y 和 Z 具備相同的屬性個數，且對應屬性出自相同域。關係 R(X，Y)÷S(Z)所得的商關係是關係 R 在屬性 X 上投影的一個子集，該子

集和 S(Z)的笛卡爾積必須包含在 R(X，Y)中，記爲 R÷S，其具體計算公式爲：

例如，對錶 3-1 的關係 R 與表 3-2 的關係 S 作除法運算。

求解過程爲：首先，按除運算定義要求，肯定 X，Y，Z 屬性集合。Y 是關係 R 中的屬性集合，Z 是 S 中所有屬性的集合，即 Z={U3，U4}，因爲 Y=Z，所以，Y={U3，U4}， X={U1， U2}。也就是說，R÷S 結果集包含屬性 U1 和 U2；而後，將關係 R 的 U一、U2（共有<a， b>、<c，a>兩個元組）與關係 S 做笛卡爾積操做，結果如表 3-7 所示。

經過檢查表 3-7，能夠發現元組<a，b>與 S(Z)的笛卡爾積被包含在 R(X，Y)中，而元組

<c，a>與 S(Z)的笛卡爾積有一個元組未被包含在 R(X，Y)中，因此，結果集中只有元組<a， b>。

3.2.4 數據的規範化

關係模型知足的肯定約束條件稱爲範式，根據知足約束條件的級別不一樣，範式由低到高分爲 1NF（第一範式）、2NF（第二範式）、3NF（第三範式）、BCNF（BC 範式）、4NF（第四範式）等。不一樣的級別範式性質不一樣。

把一個低一級的關係模型分解爲高一級關係模型的過程，稱爲關係模型的規範化。關係模型分解必須遵照兩個準則。

（1）無損鏈接性：信息不失真（不增減信息）。

（2）函數依賴保持性：不破壞屬性間存在的依賴關係。

規範化的基本思想是逐步消除不合適的函數依賴，使數據庫中的各個關係模型達到某種程度的分離。規範化解決的主要是單個實體的質量問題，是對於問題域中原始數據展示的正規化處理。

規範化理論給出了判斷關係模型優劣的理論標準，幫助預測模式可能出現的問題，是數據庫邏輯設計的指南和工具，具體有：

（1）用數據依賴的概念分析和表示各數據項之間的關係。

（2）消除 E-R 圖中的冗餘聯繫。

函數依賴

通俗地說，就像自變量 x 肯定以後，相應的函數值 f(x)也就惟一肯定了同樣，函數依賴是衡量和調整數據規範化的最基礎的理論依據。

例如，記錄職工信息的結構以下：職工工號（EMP_NO）

職工姓名（EMP_NMAE）所在部門（DEPT）。

則說 EMP_NO 函數決定 EMP_NMAE 和 DEPT，或者說 EMP_NMAE，DEPT 函數依賴於 EMP_NO，記爲：EMP_NO→EMP_NMAE，EMP_NO→DEPT。

關係 R<U，F>中的一個屬性或一組屬性 K，若是給定一個 K 則惟一決定 U 中的一個元組，也就是 U 函數徹底依賴於 K，就稱 K 爲 R 的碼。一個關係可能有多個碼，選中其中一個做爲主碼。

包含在任一碼中的屬性稱爲主屬性，不包含在任何碼中的屬性稱爲非主屬性。

關係 R 中的屬性或屬性組 X 不是 R 的碼，但 X 是另外一個關係模型的碼，稱 X 是 R

的外碼。

主碼和外碼是一種表示關係間關聯的重要手段。數據庫設計中一個重要的任務就是要找到問題域中正確的關聯關係，孤立的關係模型很難描述清楚業務邏輯。

第一範式

1NF 是最低的規範化要求。若是關係 R 中全部屬性的值域都是簡單域，其元素（即屬性）不可再分，是屬性項而不是屬性組，那麼關係模型 R 是第一範式的，記做 RÎ1NF。這一限制是關係的基本性質，因此任何關係都必須知足第一範式。第一範式是在實際數據庫設計中必須先達到的，一般稱爲數據元素的結構化。

例如，表 3-8 所示的結構就不知足 1NF 的定義。

表 3-8 爲非第一範式，分解如表 3-9 所示。

就知足了第一範式。通過處理後，就能夠以省、市爲條件進行查詢和統計了。

知足 1NF 的關係模型會有許多重複值，而且增長了修改其數據時引發疏漏的可能性。爲了消除這種數據冗餘和避免更新數據的遺漏，須要更加規範的 2NF。

第二範式

若是一個關係 R 屬於 1NF，且全部的非主屬性都徹底依賴於主屬性，則稱之爲第二範式，記做RÎ2NF。

爲了說明問題，現舉一個例子來講明：

有一個得到專業技術證書的人員狀況登記表結構爲：

省份、姓名、證書名稱、證書編號、覈准項目、發證部門、發證日期、有效期。

這個結構符合 1NF，其中「證書名稱」和「證書編號」是主碼，可是由於「發證部門」只徹底依賴於「證書名稱」，即只依賴於主關鍵字的一部分（即部分依賴），因此它不符合 2NF，這樣首先存在數據冗餘，由於證書種類可能很少。其次，在更改發證部門時，若是漏改了某一記錄，存在數據不一致。再次，若是得到某種證書的職工所有跳槽了，那麼這個發證部門的信息就可能丟失了，即這種關係不容許存在某種證書沒有得到者的狀況。

能夠用分解的方法消除部分依賴的狀況，而使關係達到 2NF 的標準。方法是，從現有關係中分解出新的關係表，使每一個表中全部的非關鍵字都徹底依賴於各自的主關鍵字。能夠分解成兩個表（省份、姓名、證書名稱、證書編號、覈准項目、發證日期、有效期）和（證書名稱、發證部門），這樣就徹底符合 2NF 了。

第三範式

若是一個關係 R 屬於 2NF，且每一個非主屬性不傳遞依賴於主屬性，這種關係是 3NF，記做 RÎ3NF。

從 2NF 中消除傳遞依賴，就是 3NF。例如，有一個表（職工姓名，工資級別，工資額），其中職工姓名是關鍵字，此關係符合 2NF，可是由於工資級別決定工資額，也就是說非主屬性「工資額」傳遞依賴於主屬性「職工姓名」，它不符合 3NF，一樣能夠使用投影分解的辦法分解成兩個表：（職工姓名，工資級別），（工資級別，工資額）。

BC 範式

通常知足 3NF 的關係模型已能消除冗餘和各類異常現象，得到比較滿意的效果，但不管 2NF 仍是 3NF 都沒有涉及主屬性間的函數依賴，因此有時仍會引發一些問題。由此引入 BC 範式（由 Boyeet 和 Codd 提出）。一般認爲 BCNF 是第三範式的改進。

BC 範式的定義：若是關係模型 R∈1NF，且 R 中每個函數依賴關係中的決定因素都包含碼，則 R 是知足 BC 範式的關係，記做 RÎBCNF。

當一個關係模型 R BCNF，則在函數依賴範疇裏，就認爲已完全實現了分離，消除了插入、刪除的異常。

綜合 1NF、2NF 和 3NF、BCNF 的內涵可歸納以下：

（1）非主屬性徹底函數依賴於碼（2NF 的要求）；

（2）非主屬性不傳遞依賴於任何一個候選碼（3NF 的要求）；

（3）主屬性對不含它的碼徹底函數依賴（BCNF 的要求）；

（4）沒有屬性徹底函數依賴於一組非主屬性（BCNF 的要求）。

3.2.5 反規範化

數據庫中的數據規範化的優勢是減小了數據冗餘，節約了存儲空間，相應邏輯和物理的I/O 次數減小，同時加快了增、刪、改的速度，可是對徹底規範的數據庫查詢，一般須要更多的鏈接操做，從而影響查詢速度。所以，有時爲了提升某些查詢或應用的性能而破壞規範規則，即反規範化（非規範化處理）。

常見的反規範化技術包括：

（1）增長冗餘列

增長冗餘列是指在多個表中具備相同的列，它經常使用來在查詢時避免鏈接操做。例如：以規範化設計的理念，學生成績表中不須要字段「姓名」，由於「姓名」字段能夠經過學號查詢到，但在反規範化設計中，會將「姓名」字段加入表中。這樣查詢一個學生的成績時，不須要與學生表進行鏈接操做，即可獲得對應的「姓名」。

（2）增長派生列

增長派生列指增長的列能夠經過表中其餘數據計算生成。它的做用是在查詢時減小計算量，從而加快查詢速度。例如：訂單表中，有商品號、商品單價、採購數量，咱們須要訂單總價時，能夠經過計算獲得總價，因此規範化設計的理念是無須在訂單表中設計「訂單總價」字段。但反規範化則不這樣考慮，因爲訂單總價在每次查詢都須要計算，這樣會佔用系

統大量資源，因此在此表中增長派生列「訂單總價」以提升查詢效率。

（3）從新組表

從新組表指若是許多用戶須要查看兩個錶鏈接出來的結果數據，則把這兩個表從新組成一個表來減小鏈接而提升性能。

（4）分割表

有時對錶作分割能夠提升性能。表分割有兩種方式。

水平分割：根據一列或多列數據的值把數據行放到兩個獨立的表中。水平分割一般在下面的狀況下使用。

狀況 1：表很大，分割後能夠下降在查詢時須要讀的數據和索引的頁數，同時也下降了索引的層數，提升查詢效率。

狀況 2：表中的數據原本就有獨立性，例如表中分別記錄各個地區的數據或不一樣時期的數據，特別是有些數據經常使用，而另一些數據不經常使用。

狀況 3：須要把數據存放到多個介質上。

垂直分割：把主碼和一些列放到一個表，而後把主碼和另外的列放到另外一個表中。若是一個表中某些列經常使用，而另一些列不經常使用，則能夠採用垂直分割，另外垂直分割能夠使得數據行變小，一個數據頁就能存放更多的數據，在查詢時就會減小 I/O 次數。其缺點是須要管理冗餘列，查詢全部數據須要鏈接操做。

3.3 數據庫設計

數據庫設計的過程是將數據庫系統與現實世界密切地、有機地、協調一致地結合起來的過程。數據庫的設計質量與設計者的知識、經驗和水平密切相關。做爲數據庫應用系統的重要組成部分，數據庫設計的成敗每每直接關係到整個應用系統的成敗。

以數據庫爲基礎的數據庫應用系統與其餘計算機應用系統相比每每具備數據量龐大、數據保存時間長、數據關聯複雜、用戶要求多樣化等特色。

數據庫設計中面臨的主要困難和問題有：

（1）同時具有數據庫知識與應用業務知識的人不多。懂得計算機與數據庫的人通常都缺少應用業務知識和實際經驗，而熟悉應用業務的人又每每不懂計算機和數據庫。

（2）項目初期每每不能肯定應用業務的數據庫系統的目標。

（3）缺少完善的設計工具和設計方法。

（4）需求的不肯定性。用戶老是在系統的開發過程當中不斷提出新的要求，甚至在數據庫創建以後還會要求修改數據庫結構或增長新的應用。

（5）應用業務系統千差萬別，很難找到一種適合全部業務的工具和方法，這就增長了研究數據庫自動生成工具的難度。所以，研製適合一切應用業務的全自動數據庫生成工具是不可能的。

3.3.1 數據庫設計的方法

目前已有的數據庫設計方法可分爲四類，即直觀設計法、規範設計法、計算機輔助設計法和自動化設計法。直觀設計法又稱單步邏輯設計法，它依賴於設計者的知識、經驗和技巧，缺少工程規範的支持和科學根據，設計質量也不穩定，所以愈來愈不適應信息管理系統發展的須要。爲了改變這種情況，1978 年 10 月來自 30 多個歐美國家的主要數據庫專家在美國新奧爾良市專門討論了數據庫設計問題，提出了數據庫設計規範，把數據庫設計分爲需求分析、概念結構設計、邏輯結構設計和物理結構設計 4 個階段。目前，經常使用的規範設計方法大多起源於新奧爾良方法，如基於 3NF 的設計方法、LRA 方法、面向對象的數據庫設計方法及基於視圖概念的數據庫設計方法等。架構設計師考試中，主要了解基於 3NF 的數據庫設計方法便可。

基於 3NF 的數據庫設計方法是由 S.Atre 提出的數據庫設計的結構化設計方法，其基本思想是在需求分析的基礎上，識別並確認數據庫模式中的所有屬性和屬性間的依賴，將它們組織成一個單一的關係模型，而後再分析模式中不符合 3NF 的約束條件，用投影和鏈接的辦法將其分解，使其達到 3NF 條件。其具體設計步驟分爲 5 個階段，如圖 3-2 所示。

3-2 基於 3NF 的數據庫設計方法

（1）設計企業模式。利用上述獲得的 3NF 關係模型畫出企業模式。具體包括：

分析應用環境，並設定環境中所使用的各類資料。

肯定每一種報表各自所包含的數據元素。

肯定數據元素之間的關係，如肯定主關鍵字和通常的數據元素。

對每一組或若干組數據元素推導出 3NF 的關係模型。

3NF 關係模型的基礎上畫出數據庫的企業模式。

（2）設計數據庫邏輯模式。根據上一步獲得的企業模式選定數據模型，從而得出適用於某個 DBMS 的邏輯模式。根據邏輯模式導出各類報表與事務處理所使用的外模式。

（3）設計數據庫物理模式（存儲模式）。根據數據庫的邏輯模式和給定的計算機系統設

計物理模式。

（4）評價物理模式。對物理模式估算空間利用狀況，並推算輸入輸出的機率。必要時根據物理模式調整各類報表與事務處理的外模式。對外模式進行存取時間的估算。

（5）數據庫實現。具體實現數據庫。

3.3.2 數據庫設計的基本步驟

分步設計法遵循自頂向下、逐步求精的原則，將數據庫設計過程分解爲若干相互獨立又相互依存的階段，每一階段採用不一樣的技術與工具，解決不一樣的問題，從而將問題局部化，減小了局部問題對總體設計的影響。目前，此方法已在數據庫設計中獲得了普遍應用並得到了較好的效果。

在分步設計法中，一般將數據庫的設計分爲需求分析、概念結構設計、邏輯結構設計和數據庫物理設計 4 個階段，如圖 3-3 所示。

需求分析

需求分析是指收集和分析用戶對系統的信息需求和處理需求，獲得設計系統所必需的需求信息，創建系統說明文檔。其目標是經過調查研究，瞭解用戶的數據要求和處理要求，並按必定格式整理造成需求說明書。需求說明書是需求分析階段的成果，也是從此設計的依據，它包括數據庫所涉及的數據、數據的特徵、使用頻率和數據量的估計，如數據名、屬性及其類型、主關鍵字屬性、保密要求、完整性約束條件、更改要求、使用頻率、數據量估計等。這些關於數據的數據稱爲元數據。在設計大型數據庫時，這些數據一般由數據字典來管理。用數據字典管理元數據有利於避免數據的重複或重名，以保持數據的一致性及提供各類統計數據，於是有利於提升數據庫設計的質量，同時能夠減輕設計者的負擔。

概念結構設計

它是數據庫設計的第二階段，其目標是對需求說明書提供的全部數據和處理要求進行抽象與綜合處理，按必定的方法構造反映用戶環境的數據及其相互聯繫的概念模型，即用戶的數據模型或企業數據模型。這種概念數據模型與 DBMS 無關，是面向現實世界的、極易爲用戶所理解的數據模型。爲保證所設計的概念數據模型能正確、完整地反映用戶的數據及其相互關係，便於進行所要求的各類處理，在本階段設計中可吸取用戶參與和評議設計。在進行概念結構設計時，可先設計各個應用的視圖（view），即各個應用所看到的數據及其結構，而後再進行視圖集成，以造成一個單一的概念數據模型。這樣造成的初步數據模型還要通過數據庫設計者和用戶的審查與修改，最後造成所需的概念數據模型。

邏輯結構設計

這一階段的設計目標是把上一階段獲得的與 DBMS 無關的概念數據模型轉換成等價的，併爲某個特定的 DBMS 所接受的邏輯模型所表示的概念模式，同時將概念設計階段獲得的應用視圖轉換成外部模式，即特定 DBMS 下的應用視圖。在轉換過程當中要進一步落實需求說明，並知足 DBMS 的各類限制。該階段的結果是用 DBMS 所提供的數據定義語言（DDL）寫成的數據模式。邏輯設計的具體方法與 DBMS 的邏輯數據模型有關。邏輯模型應知足數據庫存取、一致性及運行等各方面的用戶需求。

數據庫物理設計

物理設計階段的任務是把邏輯設計階段獲得的知足用戶需求的已肯定的邏輯模型在物理上加以實現，其主要內容是根據 DBMS 提供的各類手段，設計數據的存儲形式和存取路徑，如文件結構、索引設計等，即設計數據庫的內模式或存儲模式。數據庫的內模式對數據庫的性能影響很大，應根據處理需求及 DBMS、操做系統和硬件的性能進行精心設計。

實際上，數據庫設計的基本過程與任何複雜系統開發同樣，在每一階段設計基本完成後，

都要進行認真的檢查，看是否知足應用需求，是否符合前面已執行步驟的要求和知足後續步驟的須要，並分析設計結果的合理性。在每一步設計中，均可能發現前面步驟的遺漏或處理不當之處，此時，每每須要返回去從新處理並修改設計和有關文檔。因此，數據庫設計過程一般是一個反覆修改、反覆設計的迭代過程。

3.3.3 需求分析

需求分析是數據庫設計過程的第一步，是整個數據庫設計的依據和基礎。需求分析作得很差，會致使整個數據庫設計從新返工。需求分析的目標是經過對單位的信息需求及處理要求的調查分析獲得設計數據庫所必需的數據集及其相互聯繫，造成需求說明書，做爲後面各設計階段的基礎。所以，這一階段的任務是：

確認需求、肯定設計目標

數據庫設計的第一項工做就是要對系統的整個應用狀況進行全面、詳細的實地調查，弄清現行系統的組織結構、功能劃分、整體工做流程，收集支持系統總的設計目標的基礎數據和對這些數據的處理要求，明確用戶總的需求目標；經過分析，肯定相應的設計目標，即肯定數據庫應支持的應用功能和應用範圍，明確哪些功能由計算機完成或準備讓計算機完成，哪些環節由人工完成，以肯定應用系統實現的功能。這一階段收集到的基礎數據和一組數據流程圖是下一步進行概念設計的基礎。

分析和收集數據

這是整個需求分析的核心任務。它包括分析和收集用戶的信息需求、處理需求、完整性需求、安全性需求，以及對數據庫設計過程有用的其餘信息。

信息需求是指在設計目標範圍內涉及的全部實體、實體的屬性及實體間的聯繫等數據對象，包括用戶在數據處理中的輸入/輸出數據及這些數據間的聯繫。在收集中，要收集數據的名稱、類型、長度、數據量、對數據的約束及數據間聯繫的類型等信息。

處理需求是指爲了得到所需的信息而對數據加工處理的要求。它主要包括，處理方式是實時仍是批處理，各類處理髮生的頻度、響應時間、優先級別及安全保密要求等。所要收集的其餘信息還有企業在管理方式、經營方式等方面可能發生的變化等。

分析和收集數據的過程是數據庫設計者對各種管理活動進行深刻調查研究的過程，調查對象包括數據管理部門的負責人、各使用部門的負責人及操做員等各種管理人員，經過與各種管理人員相互交流，逐步取得對需求的一致認識。

整理文檔

分析和收集獲得的數據必須通過篩選整理，並按必定格式和順序記載保存，通過審覈成爲正式的需求說明文檔，即需求說明書。實際上，需求說明書是在需求分析的過程當中逐漸整理造成的，是隨着這一過程的不斷深刻而反覆修改與完善的對系統需求分析的全面描述。由用戶、領導和專家共同評審，是之後各設計階段的主要依據。這一步的工做是進行全面的彙總與整理，使之系統化，以造成標準化的統一形式。

3.3.4 概念結構設計

概念結構設計階段所涉及的信息不依賴於任何實際實現時的環境，即計算機的硬件和軟件系統。概念結構設計的目標是產生一個用戶易於理解的，反映系統信息需求的總體數據庫概念結構。概念結構設計的任務是，在需求分析中產生的需求說明書的基礎上按照必定的方法抽象成知足應用需求的用戶的信息結構，即一般所稱的概念模型。概念結構的設計過程就是正確選擇設計策略、設計方法和概念數據模型並加以實施的過程。

概念數據模型的做用是：提供可以識別和理解系統要求的框架；爲數據庫提供一個說明性結構，做爲設計數據庫邏輯結構，即邏輯模型的基礎。

概念模型的描述工具應該可以體現概念模型的特色，如 E-R 模型。近年來，因爲面向對象數據模型具備更豐富的語義、更強的描述能力而愈來愈受到人們的重視，不但出現了商品化的面向對象 DBMS，並且開始實際應用於概念模型的設計中，做爲數據庫概念設計的工具。 Teory 等人提出的擴展的 E-R 模型增長了相似面向對象數據模型中的廣泛化和聚合等語義描述機制，爲這種最爲人們熟悉的數據模型注入了新的生機，爲概念模型的描述增長了一種理想的選擇。

概念結構的設計策略主要有自底向上、自頂向下、由裏向外和混合策略。在具體實現設計目標時有兩種極端的策略或方案，一是創建一個覆蓋整個單位全部功能域的全局數據庫，稱之爲全局方案或全局策略；另外一種則是對每個應用都創建一個單獨的數據庫，稱之爲應用方案或應用策略。

因爲各個部門對於數據的需求和處理方法各不相同，對同一類數據的觀點也可能不同，它們有本身的視圖，因此能夠首先根據需求分析階段產生的各個部門的數據流圖和數據字典中的相關數據設計出各自的局部視圖，而後進行視圖集成。

視圖設計

在實體分析法中，局部視圖設計的第一步是肯定其所屬的範圍，即它所對應的用戶組，而後對每一個用戶組創建一個僅由實體、聯繫及它們的標識碼組成的局部信息結構（局部數據模式）框架，最後再加入有關的描述信息，造成完整的局部視圖（局部數據模式）。這樣作的目的是爲了集中精力處理好用戶數據需求的主要方面，避免因可有可無的描述細節而影響局部信息結構的正確性。整個過程可分爲 4 個步驟：肯定局部視圖的範圍；識別實體及其標識；肯定實體間的聯繫；分配實體及聯繫的屬性。

（1）肯定局部視圖的範圍。需求說明書中標明的用戶視圖範圍能夠做爲肯定局部視圖範圍的基本依據，但它一般與子模式範圍相對應，有時由於過大而不利於局部信息結構的構造，故可根據狀況修改，但也不宜分得太小，太小會形成局部視圖的數量太大及大量的數據冗餘和不一致性，給之後的視圖集成帶來很大的困難。

局部視圖範圍肯定的基本原則是：

各個局部視圖支持的功能域之間的聯繫應最少。

實體個數適量。一個局部視圖所包含的實體數量反映了該局部視圖的複雜性，按照信息論中「7 2」的觀點，人們在同一時刻可同時顧及的事情通常在 5～9 之間，其中以 6 或 7 最

爲適當。所以，一個局部視圖內的實體數不宜超過 9 個，不然就會過於複雜，不便於人們理解和管理。

（2）識別實體及其標識。在需求分析中，人們已經初步地識別了各種實體、實體間的聯繫及描述其性質的數據元素，這些統稱爲數據對象，它們是進一步設計的基本素材。這一步的任務就是在肯定的局部視圖範圍內，識別哪些數據對象做爲局部視圖的基本實體及其標識，並定義有關數據對象在 E-R 模型中的地位。

（3）肯定實體間的聯繫。實際上，識別聯繫的主要任務是在需求分析階段完成的。這裏的工做一是從局部視圖的角度進行一次審覈，檢查有無遺漏之處，二是確切地定義每一種聯繫。

在現實世界中，諸多形式的聯繫大體可分爲三類：存在性聯繫、功能性聯繫和事件聯繫。存在性聯繫如學校有教師、教室有學生、工廠有產品、產品有顧客等；功能性聯繫如教師講授課程、教師參與科研、倉庫管理員管理倉庫等；事件聯繫如學生借書、產品發運等。

根據上述分類仔細檢查在給定的局部視圖範圍內是否有未識別的聯繫，在確認全部的聯繫都已識別並沒有遺漏以後，還需對聯繫進行正確的定義。定義聯繫就是對聯繫語義的仔細分析，識別聯繫的類型，肯定實體在聯繫中的參與度。

① 二元聯繫的類型與定義。二元聯繫是指兩個實體類之間的聯繫。根據參與聯繫的兩

個實體類值之間的對應關係分爲一對1、一對多及多對多三種類型。

一對一聯繫：這是一種最簡單的聯繫類型。若對於實體集 A 中的每個實體，實體集 B 中至多有一個實體與之聯繫，反之亦然，則稱實體集 A 與實體集 B 具備一對一聯繫，記爲 1:1。例如在一個施工單位中，若是規定每項工程最多隻能由一名工程師負責管理，而一名工程師最多也只能負責一項工程，則工程師與工程間的這種管理聯繫即是一對一聯繫。

一對多聯繫：若對於實體集 A 中的每個實體，實體集 B 中有 n 個實體（n≥0）與之聯繫；反之，對於實體集 B 中的每個實體，實體集 A 中至多有一個實體與之聯繫，則稱實體集 A 與實體集 B 有一對多的聯繫，記爲 1:n。以專業與學生間的關係爲例：如規定一個專業能夠管理許多學生，每一個學生只能屬於一個專業，這種聯繫就是一對多聯繫。

多對多聯繫：若對於實體集 A 中的每個實體，實體集 B 中有 n 個實體（n≥0）與之聯繫，反過來，對實體集 B 中每個實體，實體集 A 中也有 m 個實體（m≥0）與之聯繫，則稱實體集 A 與實體集 B 具備多對多聯繫，記爲 m:n。教師與學生這兩個實體類間的教與學的聯繫就是多對多的聯繫。這時，只有<教師、學生>對才能肯定一個特定的教學聯繫。所以，通常狀況下能夠以兩個關聯實體的標識拼湊做爲聯繫的標識。但這種方法對某些狀況就不能構成有效的聯繫標識。當一個實體值在同一個聯繫上可能存在多個不一樣的聯繫值時，就會出現這種狀況。如教師與其講授的課程之間的聯繫，同一個教師可講授幾門不一樣的課程，也能夠屢次講授同一門課程，這是一種特殊的多對多聯繫。顯然，對於教師與講授課程間的聯繫，如在教師檔案中要求記錄擔任教學工做的狀況，就須要在聯繫標識中增長表示授課日期的屬性，即其合適的聯繫標識可能爲（教師號，課程號，授課日期）。

實體類內部的聯繫：這種聯繫發生在同一類實體的不一樣實體之間，所以稱爲內部聯繫或自聯繫，它也是一種二元聯繫，其表示方式與前面的二元聯繫並沒有不一樣，要注意仔細區別同一實體類中的不一樣實體在聯繫中扮演的不一樣角色及聯繫標識的選擇。例如在職工類實體中間就存在着管理者與被管理者的聯繫。一個職工能夠管理別的職工，稱爲管理者或領導者。一個管理者能夠管理多個職工，而一個職工最多隻從屬於一位管理者，從而構成了一對多聯繫。若規定全部職工都要受管理（最高管理者考慮本身管理本身），但不是全部職工都是管理者，則此聯繫在「多」端呈現強制性。其中每一個聯繫實體包含兩個職工號值：職工號和管理員職工號，以區別不一樣的實體在聯繫中的角色。

若略去實體與其屬性圖，以上實體間的二元聯繫可用圖 3-4 表示。

② 多元聯繫的識別與定義。兩個以上的實體類之間的聯繫稱爲多元聯繫。例如在供應商向工程供應零件這類事件中，若是任一供應商可向任一工程供應任一種零件，則爲了肯定哪一個供應商向哪一個工程供應了何種零件，就必須定義一個三元聯繫，由於只有供應商、工程及零件三者一塊兒才能惟一地肯定一個聯繫值。其聯繫的標識由參與聯繫的實體類的標識拼接而成，在此例中由供應商、工程、零件三個實體類的標識拼接而成。

視圖集成

視圖集成就是要將反映各用戶組數據的局部數據模式綜合成單位中某個肯定範圍內的單一數據視圖，即全局數據模式，又稱模式彙總。該全局數據模式是將來數據庫結構的基礎，所以視圖集成是數據庫設計過程當中一個十分重要的步驟，也是一項較爲複雜和困難的任務。當全部局部視圖設計完畢，就可開始視圖集成。集成過程當中會發生一些衝突，衝突的表現和處理策略以下：

① 同名異義。爲了發現不一樣視圖間的同名異義問題，能夠列出全部同名數據對象，而後逐一判別其語義。對同名異義衝突一般採用換名加以解決，既可對同名者之一換名，也可對二者都給以從新命名。識別語義的主要方法是進行值域分析。

② 異名同義。識別異名同義比較困難，通常由設計者對全部對象一個不漏地逐一鑑別。它一樣採用換名的方法解決。若歸併時試圖將它們合併爲一個對象，則能夠把其中之一的名稱做爲合併後的對象名；若集成後，它們仍以兩個不一樣的對象存在，則可對其一換名。固然，若原名都不合適，則能夠對二者都從新命名。

③ 同名不一樣層次。若是兩個對象同名，但其中之一是做爲一個視圖中的實體，而另外一個是另外一視圖中的屬性，則在集成時就會發生同名不一樣層次的衝突。解決這種衝突的辦法有兩個，一是將屬性轉換爲實體，二是將實體變換成屬性。

例如，設一局部視圖中有一部門實體 DEPT，而在另外一與之集成的視圖中有職工實體

EMP，且 EMP 有屬性 DEPT，因而發生了同名不一樣層次的衝突。此時，可將 EMP 的 DEPT

屬性去掉，另設一個實體 DEPT 與 EMP 創建聯繫，這時再與另外一視圖集成就容易多了。再如，設一局部視圖中有一名爲 STOR 的倉庫實體，其中含有一屬性部門號（DEPT-NO）；

在另外一局部視圖中有一單位實體 DEPT，其中僅含有一個屬性 DEPT-NO。對這類同名不一樣層次的衝突，可將 DEPT 實體變換爲其所在視圖中與 DEPT 相關的另外一實體的屬性，而後再進行集成。

希賽教育專家提示：實體變換爲屬性時一般要知足一些特定條件，例如，該實體一般只含有一個與同名屬性具備共同特徵的屬性，且必定存在一個與該實體存在聯繫的另外的實體。

④ 雖同名同義，但對象聯繫測度不一樣。所謂聯繫測度是指實體的聯繫是一對1、一對多仍是多對多。若同名同義對象在一個局部視圖中爲一對多聯繫，在另外一局部視圖中爲多對多聯繫，則在集成時將發生聯繫測度衝突。通常而言，一對多包含一對一，多對多包含一對多。因此解決這種衝突的方法每每取較高測度爲集成後的相應聯繫的測度。

3.3.5 邏輯結構設計

數據庫邏輯結構設計的任務就是把概念結構設計階段設計好的基本 E-R 圖轉換爲與具體機器上的 DBMS 產品所支持的數據模型相符合的邏輯結構。這一階段是數據庫結構設計的重要階段。

數據庫邏輯設計的基礎是概念設計的結果，而其成果應包括某 DBMS 所支持的外模式、概念模式及其說明及創建外模式和概念模式的 DDL 程序。所以，進行邏輯設計前，必須瞭解數據庫設計的需求說明和概念設計的成果（包括 E-R 圖和其餘文檔），並仔細閱讀有關 DBMS 的文件。數據庫的外模式和概念模式是用戶所看到的數據庫，是應用程序訪問數據庫的接口，所以在數據庫邏輯設計階段，還必須提供應用程序編制的有關說明，最好試編一些典型的訪問數據庫的應用程序，以檢驗所設計的概念模式是否知足使用要求。概念模式是數據庫的基礎，它的設計質量對數據庫的使用和性能，以及數據庫在從此發展過程當中的穩定性均有直接的影響。爲了設計出可以正確反映一個項目數據間內在聯繫的好的概念模式，設計時必須正確處理各類應用程序之間、數據庫性能與數據模式的合理性和穩定性之間的各類矛盾，對設計中出現的各類矛盾要權衡利弊，分清主次，按統籌兼顧的原則加以正確處理。

邏輯結構設計通常分爲如下幾個步驟：

（1）將概念結構向通常關係模型轉化。

（2）將第一步獲得的結構向特定的 DBMS 支持下的數據模型轉換。

（3）依據應用的需求和具體的 DBMS 的特徵進行調整與完善。

下面以經常使用的 E-R 模型和擴充 E-R 模型爲主，針對關係數據庫的邏輯設計介紹基本原則和方法。

基本E-R 模型向關係模型的轉換

基本 E-R 模型主要包含實體和聯繫兩個抽象概念，實體和聯繫自己還可能附有若干屬性。其轉換的基本原則是，實體和聯繫分別轉換成關係，屬性則轉換成相應關係的屬性。所以，E-R 模型向關係模型的轉換比較直觀，但不一樣元數的聯繫具體轉換方法稍有不一樣，下面根據不一樣的狀況分別討論。

（1）一對一聯繫。設有兩個實體 E1 和 E2 之間爲一對一聯繫。此狀況存在三種可能的轉換方案。

方案 1：將實體 E一、E2 和聯繫名 R 分別轉換成爲關係 E一、E2 和 R，它們的屬性分別轉爲相應關係的屬性，即獲得：

El（k1，a） E2（k2，b）

R（k1，k2，r）（k2 是候選關鍵字）

其中屬性下面帶一橫線者爲關係的關鍵字。

方案 2：將實體 El 轉換爲關係 El ，將實體 E2 與聯繫名 R 一塊兒轉換成關係 E2 ，E2 的屬性由 E2 和 R 的屬性加上 E1 的關鍵字組成，其關鍵字 k一、k2 爲其候選關鍵字。轉換後的關係爲：

E1（kl，a）

E2′（k2，b，k1，r），（k1 是候選關鍵字）

方案 3：與方案 2 相似，不過把實體E1 與聯繫R 一塊兒轉換成關係E1 後，其結果爲：

E1′（kl，a，k2，r），（k2 是候選關鍵字）

E2（k2，b）

上述三個方案實際上可歸結爲轉換成三個關係和轉換成兩個關係兩種。若是每一個實體的屬性數較少，而聯繫的屬性與兩個實體之一關係又較密切，則可採用方案 2 或方案 3，其優勢是可減小關係數，有利於減小鏈接運算從而提升查詢效率，但若是每一個實體的屬性較多，且合併後，會形成較大數據冗餘和操做異常，則以採用方案 1 爲宜。

（2）一對多聯繫。這種狀況存在兩種轉換方案，其一是把兩個實體類和一個聯繫類分

別轉換成對應的關係，實體類的屬性轉換爲對應關係的屬性，其標識屬性即爲對應關係的關鍵字，而聯繫類轉換獲得的關係，其屬性由兩個實體的標識屬性和聯繫類自己的屬性組成，並以多端實體類的標識屬性爲其關鍵字。其轉換結果爲三個關係。第二個方案是轉換

成兩個關係，設少端和多端的兩個實體類分別爲 El、E2，聯繫名 R。轉換時，將實體類 El 轉換爲一個關係 El，E2 和 R 合起來轉換成一個關係 E2′，E2′的屬性由 E2 和 R 的屬性加上 E1 的標識屬性組成，並以 E 2 的標識屬性爲其關鍵字。

（3）多對多聯繫。由兩個實體類之間多對多聯繫組成的 E-R 模型向關係模型轉換時，將兩個實體類和一個聯繫類分別轉換成關係，實體類的屬性分別轉換成對應關係的屬性，其標識屬性爲其關鍵字，由聯繫類轉換獲得的關係的屬性由兩個實體類的標識屬性和聯繫類自己的屬性組成，其關鍵字是由兩個聯繫的實體類的標識屬性組成。

（4）多元聯繫。實體類分別轉換爲相應的關係，三個實體類間的多元聯繫轉換爲以該聯繫名爲關係名的關係，關係的屬性由各實體的標識屬性及其聯繫的屬性組成，並以各實體的標識屬性爲其關鍵字。例如圖 3-5 所示的部件（PART）、工程（PROJECT）和供應者（SUPPLIER）三者之間的聯繫爲 PJS，其屬性爲 QTY。轉換時，把 PART、PROJECT、 SUPPLIER 和聯繫 PJS 分別轉換爲相應的關係，其結果以下：

（5）自聯繫。自聯繫是同一實體集的實體間的聯繫。例如對於職工實體類內部有領導與被領導的聯繫，在部件這個實體集的實體之間有組成成分與組成者之間的聯繫等，均屬於實體類的自聯繫。在這種聯繫中，參與聯繫的實體雖然來自同一實體類，但所起的做用不同。

（6）弱實體類的轉換。一個實體類，若是它的存在依賴於另外一實體類，則稱之爲弱實體類。例如職工的親屬（DEPENDENTS）是依賴於職工（EMPLOYEE）實體類而存在的，由於實體集親屬（DEPENDENTS）是弱實體類，它們之間的關係如圖 3-6 所示。因爲弱實體類不

能獨立地存在，而是由其餘實體標識而存在，因此不能單獨地轉換成一個關係，所以圖 3-6

可轉換成以下兩個關係：

EMPLOYEE（empno，name，birthday） DEPENDENTS（empno，name，sex，age，kinship）

其中 kinship 表示職工親屬與職工的關係，能夠取值爲「配偶」、「兒子」、「女兒」等。

數據模型的優化

由 E-R 圖表示的概念模型轉換獲得的關係模型通過規範化之後，基本上能夠反映一個企業數據的內在聯繫，但不必定能知足應用的所有須要和系統要求，所以，還必須根據需求分析對模型作進一步的改善和調整，其內容主要是改善數據庫的性能和節省存儲空間兩個方面。

（1）改善數據庫性能的考慮。查詢速度是關係數據庫應用中影響性能的關鍵問題，必須在數據庫的邏輯設計和物理設計中認真加以考慮，特別是那些對響應時間要求較苛刻的應用，應予以特別注意。

就數據庫的邏輯設計而論，可從下列幾個方面提升查詢的速度。

① 減小鏈接運算。鏈接運算對關係數據庫的查詢速度有着重要的影響，鏈接的關係越多，參與鏈接的關係越大，開銷也越大，於是查詢速度也越慢。對於一些經常使用的、性能要求較高的數據庫查詢，最好是一元查詢，但這與規範化的要求相矛盾。有時爲了保證性能，每每不得不犧牲規範化要求，把規範化的關係再合併起來，稱之爲逆規範化。固然，這樣作會引發更新異常。總之，逆規範化有得有失，設計者可根據實際狀況進行權衡。

② 減少關係大小及數據量。被查詢的關係的大小對查詢速度影響較大。爲了提升查詢速度，能夠採用水平分割或垂直分割等方法把一個關係分紅幾個關係，使每一個關係的數據量

減小。例如，對於大學中有關學生的數據，既能夠把全校學生的數據集中在一個關係中，也能夠用水平分割的方法，分系創建關係，從而減小了每一個關係的元組數。前者對全校範圍內的查詢較方便，後者則能夠顯著提升對指定系的查詢速度。也可採用垂直分割的方法，把經常使用數據與很是用數據分開，以提升經常使用數據的查詢速度。例如，高校中教職工檔案，屬性不少，有些需常常查詢，有些則不多查詢，若是放在一塊兒，則關係的數據量就會很大，影響查詢速度，所以把經常使用屬性和很是用屬性分開，就可提升對經常使用屬性的查詢速度。

③ 儘可能使用快照。快照是某個用戶所關心的那部分數據，與視圖同樣是一種導出關係，但它與視圖有兩點不一樣：一是視圖是虛關係，數據庫中並不存儲做爲視圖的導出關係，僅僅保留它的定義，快照則是一個由系統事先生成後保留在數據庫中的實關係；二是視圖隨數據當前值的變化而變化，快照則不隨原來關係中數據的改變而及時改變，它只反映數據庫中某一時刻的狀態，不反映數據庫的當前狀態，猶如照片只反映某一時刻的情景，不能反映情景變化同樣，之因此稱它爲快照，緣由就在於此。但它與照片又有不一樣，快照不是一成不變的，它能夠由系統週期性地刷新，或由用戶用命令刷新。刷新時用當前值更新舊值。在實際應用中，快照可知足至關一部分應用的須要，甚至有些應用就是須要快照，而不是當前值。例如註明列出「某年某月某日截止」的統計或報表就是快照。因爲快照是事先生成並存儲在數據庫中的，於是可大大縮短響應時間。目前很多 DBMS，如 Oracle、 MS SQL Server 等支持快照。對不支持快照的 DBMS，用戶也能夠把須要做爲實關係使用的導出關係做爲一個獨立關係存於數據庫中，但這種作法只能供查詢使用，對它們的刷新及管理由用戶負責。

（2）節省存儲空間的一些考慮。儘管隨着硬件技術的發展，提供給用戶使用的存儲空間愈來愈大，但畢竟是有限度的。而數據庫，尤爲是複雜應用的大型數據庫，須要佔用較大的外存空間。所以，節省存儲空間還是數據庫設計中應該考慮的問題，不但要在數據庫的物理設計中考慮，並且還應在邏輯設計中加以考慮。在數據庫邏輯設計中可採起如下措施：

① 縮小每一個屬性佔用的空間。減小每一個屬性佔用的空間，是節省存儲空間的一個有效的措施。一般能夠有兩種方法：即用編碼和用縮寫符號表示屬性，但這兩種方法的缺點是失去了屬性值含義的直觀性。

② 採用假屬性。採用假屬性能夠減小重複數據佔用的存儲空間。設某關係模型 R 的屬性 A 和 B 之間存在函數依賴 A→B，B 的每個值須要佔用較大的空間，但 B 的域中不一樣的值卻比較少，A 的域中具備較多的不一樣值，則 B 的同一值可能在多個元組中重複出現，從而須要佔用較多的空間。爲了節省空間，可利用屬性 B 的域中不一樣值少的特色，對 B 的值進行分類，用 B′表示 B 的類型，則 A→B 可分解成兩個函數依賴，即：

A→B′，B′→B

這樣，就可用 B′代替原來元組較多的關係 R 中的屬性 B，而另外創建一個較小的關係 R′來描述 B′與 B 的對應關係。這裏 B′在原關係 R 中起了屬性 B 的替身的做用，因此稱 B′ 爲假屬性。例如，在職工關係中，職工的經濟情況這一屬性一般由職工號決定，一個大型企業的職工人數不少，如每一職工逐一填寫，就要佔用較多的空間，爲了節省空間可把經濟情況分爲幾種類型，在元組較多的職工關係中用經濟情況的類型代替原來的經濟情況，這裏經濟情況的類型就是假屬性，另外創建一個較小的關係來描述每種經濟情況類型的具體內容。

希賽教育專家提示：數據庫設計與數學問題求解不一樣，它是一項綜合性工做，受到各類各樣的要求和因素的制約，有些要求每每又是彼此矛盾的，所以，設計結果很難說是最佳的，經常有得有失，設計者必須根據實際狀況，綜合運用上述原則和有關理論，在基本合理的整體設計的基礎上，作一些仔細的調整，力求最大限度地知足用戶各類各樣的要求。

3.3.6 物理結構設計

數據庫在實際的物理設備上的存儲結構和存取方法稱爲數據庫的物理結構。數據庫物理設計是利用已肯定的邏輯結構及 DBMS 提供的方法、技術，以較優的存儲結構、數據存取路徑、合理的數據存儲位置及存儲分配，設計出一個高效的、可實現的物理數據庫結構。顯然，數據庫的物理設計是徹底依賴於給定的硬件環境和數據庫產品的。數據庫物理設計過程如圖 3-7 所示。

因爲不一樣的 DBMS 提供的硬件環境和存儲結構、存取方法，以及提供給數據庫設計者的系統參數、變化範圍有所不一樣，所以，爲了設計出一個較好的存儲模式，設計者必須瞭解如下幾方面的問題，作到心中有數。

（1）瞭解並熟悉應用要求，包括各個用戶對應的數據視圖，即數據庫的外模式（子模式），分清哪些是主要的應用，瞭解各個應用的使用方式、數據量和處理頻率等，以便對時間和空間進行平衡，並保證優先知足應用的時間要求。

（2）熟悉使用的 DBMS 的性能，包括 DBMS 的功能，提供的物理環境、存儲結構、存取方法和可利用的工具。

（3）瞭解存放數據的外存設備的特性，如物理存儲區域的劃分原則，物理塊的大小等有關規定及 I/O 特性等。

存儲模式和概念模式不同，它不是面向用戶的，通常的用戶不必定也不須要了解數據庫存儲模式的細節。因此數據庫存儲模式的設計能夠沒必要考慮用戶理解的方便，其設計目標主要是提升數據庫的性能，其次是節省存儲空間。

在進行物理設計時，設計人員可能用到的數據庫產品是多種多樣的。不一樣的數據庫產品所提供的物理環境、存儲結構和存取方法有很大差異，能供設計人員使用的設計變量、參數範圍也大不相同，所以沒有通用的物理設計方法可遵循，只能給出通常的設計內容和原則。

3.4 事務管理

數據庫系統運行的基本工做單位是事務，事務至關於操做系統中的進程，是用戶定義的一個數據庫操做序列，這些操做序列要麼全作要麼全不作，是一個不可分割的工做單位。事務具備如下特性：

（1）原子性（Atomicity）：數據庫的邏輯工做單位。

（2）一致性（Consistency）：使數據庫從一個一致性狀態變到另外一個一致性狀態。

（3）隔離性（Isolation）：不能被其餘事務干擾。

（4）持續性（永久性）（Durability）：一旦提交，改變就是永久性的。

事務一般以 BEGIN TRANSACTION（事務開始）語句開始，以 COMMIT 或 ROLLBACK 語句結束。COMMIT 稱爲「事務提交語句」，表示事務執行成功的結束。ROLLBACK 稱爲「事務回退語句」，表示事務執行不成功的結束。從終端用戶來看，事務是一個原子，是不可分割的操做序列。事務中包括的全部操做要麼都作，要麼都不作（就效果而言）。事務不該該丟失或被分割地完成。

3.4.1 併發控制

在多用戶共享系統中，許多事務可能同時對同一數據進行操做，稱爲「併發操做」，此時數據庫管理系統的併發控制子系統負責協調併發事務的執行，保證數據庫的完整性不受破壞，同時避免用戶獲得不正確的數據。

數據庫的併發操做帶來的問題有：丟失更新問題、不一致分析問題（讀過期的數據）、依賴於未提交更新的問題（讀了「髒」數據）。這三個問題須要 DBMS 的併發控制子系統來解決。處理併發控制的主要方法是採用封鎖技術。它有兩種類型：排他型封鎖（X 封鎖）和共

享型封鎖（S 封鎖），分別介紹以下：

（1）排他型封鎖（簡稱 X 封鎖）。若是事務 T 對數據 A（能夠是數據項、記錄、數據集，乃至整個數據庫）實現了 X 封鎖，那麼只容許事務 T 讀取和修改數據 A，其餘事務要等事務 T 解除 X 封鎖之後，才能對數據 A 實現任何類型的封鎖。可見 X 封鎖只容許一個事務獨鎖某個數據，具備排他性。

（2）共享型封鎖（簡稱 S 封鎖）。X 封鎖只容許一個事務獨鎖和使用數據，要求太嚴。須要適當放寬，例如能夠容許併發讀，但不容許修改，這就產生了 S 封鎖概念。S 封鎖的含義是：若是事務 T 對數據 A 實現了 S 封鎖，那麼容許事務 T 讀取數據 A，但不能修改數據 A，在全部 S 封鎖解除以前毫不容許任何事務對數據 A 實現 X 封鎖。

數據庫是一個共享資源，它容許多個用戶程序並行地存取數據庫中的數據，可是，若是系統對並行操做不加以控制，就會存取不正確的數據，破壞數據庫的完整性。

在多個事務併發執行的系統中，主要採起封鎖協議來進行處理。

（1）一級封鎖協議。事務 T 在修改數據 R 以前必須先對其加 X 鎖，直到事務結束才釋放。一級封鎖協議可防止丟失修改，並保證事務 T 是可恢復的。但不能保證可重複讀和不讀「髒」數據。

（2）二級封鎖協議。一級封鎖協議加上事務 T 在讀取數據 R 以前先對其加 S 鎖，讀完後便可釋放 S 鎖。二級封鎖協議可防止丟失修改，還可防止讀「髒」數據，但不能保證可重複讀。

（3）三級封鎖協議。一級封鎖協議加上事務 T 在讀取數據 R 以前先對其加 S 鎖，直到事務結束才釋放。三級封鎖協議可防止丟失修改、防止讀「髒」數據與防止數據重複讀。

（4）兩段鎖協議。全部事務必須分兩個階段對數據項加鎖和解鎖。其中擴展階段是在對任何數據進行讀、寫操做以前，首先要申請並得到對該數據的封鎖；收縮階段是在釋放一

個封鎖以後，事務不能再申請和得到任何其餘封鎖。若併發執行的全部事務均遵照兩段封鎖協議，則對這些事務的任何併發調度策略都是可串行化的。遵照兩段封鎖協議的事務可能發生死鎖。

下面討論封鎖的粒度。所謂封鎖的粒度便是被封鎖數據目標的大小。在關係數據庫中，封鎖粒度有屬性值、屬性值集、元組、關係、某索引項（或整個索引）、整個關係數據庫、物理頁（塊）等幾種。

封鎖粒度小則併發性高，但開銷大；封鎖粒度大則併發性低，但開銷小。綜合平衡照顧不一樣需求以合理選取適當的封鎖粒度是很重要的。

採用封鎖的方法當然能夠有效防止數據的不一致性，但封鎖自己也會產生一些麻煩，最主要的就是死鎖問題。所謂死鎖是指多個用戶申請不一樣封鎖，因爲申請者均擁有一部分封鎖權而又需等待另外用戶擁有的部分封鎖而引發的永無休止的等待。通常來說，死鎖是能夠避免的，目前採用的辦法有如下幾種：

（1）預防法。此種方法是採用必定的操做方式以保證避免死鎖的出現，順序申請法、一次申請法等便是此類方法。所謂順序申請法是指對封鎖對象按序編號，在用戶申請封鎖時必須按編號順序（從小到大或反之）申請，這樣能避免死鎖發生。所謂一次申請法便是指用戶在一個完整操做過程當中必須一次性申請它所須要的全部封鎖，並在操做結束後一次性歸還全部封鎖，這樣也能避免死鎖的發生。

（2）死鎖的解除法。此種方法容許產生死鎖，並在死鎖產生後經過解鎖程序以解除死鎖。這種方法須要有兩個程序，一是死鎖檢測程序，用它測定死鎖是否發生，另外一是解鎖程序，一旦經測定系統已產生死鎖則啓動解鎖程序以解除死鎖。有關死鎖檢測及解鎖技術請參閱相應的資料，這裏不作進一步討論。

3.4.2 故障與恢復

數據庫的故障可用事務的故障來表示，主要分爲四類：

（1）事務故障。事務在運行過程當中因爲種種緣由，如輸入數據的錯誤、運算溢出、違反了某些完整性限制、某些應用程序的錯誤，以及併發事務發生死鎖等，使事務未運行至正常終止點就被撤銷，這種狀況稱爲「事務故障」。

（2）系統故障。系統故障是指系統在運行過程當中，因爲某種緣由（如操做系統或數據庫管理系統代碼錯誤、操做員操做失誤、特定類型的硬件錯誤（如 CPU 故障）、忽然停電

等形成系統中止運行），導致事務在執行過程當中以非正常方式終止，這時內存中的信息丟失，但存儲在外存儲設備上的數據不會受影響。

（3）介質故障。系統在運行過程當中，因爲某種硬件故障，如磁盤損壞、磁頭碰撞或因爲操做系統的某種潛在的錯誤、瞬時強磁場干擾，使存儲在外存上的數據部分損失或所有損失，稱爲「介質故障」。這類故障比前兩類故障的可能性雖然小得多，但破壞性卻最大。

（4）計算機病毒。計算機病毒是一種人爲破壞計算機正常工做的特殊程序。經過讀寫染有病毒的計算機系統中的程序與數據，這些病毒能夠迅速繁殖和傳播，危害計算機系統和數據庫。目前大多數病毒是在 PC 和其兼容機上傳播的。有的病毒一侵入系統就立刻摧毀系統，有的病毒有較長的潛伏期，有的病毒則只在特定的日期發生破壞做用，有的病毒感染系統全部的程序和數據，有的隻影響特定的程序和數據。

在數據庫系統中，恢復的基本含義就是恢復數據庫自己。也就是說，在發生某種故障使數據庫當前的狀態已經再也不正確時，把數據庫恢復到已知爲正確的某一狀態。目前數據庫系統中最經常使用的恢復方法是轉儲和登記日誌文件，可根據故障的不一樣類型，採用不一樣的恢復策略。

2．故障的恢復

（1）事務故障的恢復。事務故障是指事務未運行至正常終止點前被撤銷，這時恢復子系統應對此事務作撤銷處理。事務故障的恢復是由系統自動完成的，不須要用戶干預，步驟以下：

反向掃描文件日誌，查找該事務的更新操做。

對該事務的更新操做執行逆操做。

繼續反向掃描日誌文件，查找該事務的其餘更新操做，並作一樣處理。

如此處理下去，直至讀到此事務的開始標記，事務故障恢復完成。

（2）系統故障的恢復。系統故障發生時，形成數據庫不一致狀態的緣由有兩個：一是因爲一些未完成事務對數據庫的更新已寫入數據庫；二是因爲一些已提交事務對數據庫的更新還留在緩衝區沒來得及寫入數據庫。系統故障的恢復是在從新啓動時自動完成的，不須要用戶干預，步驟以下：

正向掃描日誌文件，找出在故障發生前已經提交的事務，將其事務標識記入重作（Redo）隊列。同時找出故障發生時還沒有完成的事務，將其事務標識記入撤銷（Undo）隊列。

對撤銷隊列中的各個事務進行撤銷處理：反向掃描日誌文件，對每一個 Undo 事務的更新操做執行逆操做。

對重作隊列中的各個事務進行重作處理：正向掃描日誌文件，對每一個 Redo 事務從新執行日誌文件登記的操做。

（3）介質故障與病毒破壞的恢復。在發生介質故障和遭病毒破壞時，磁盤上的物理數據庫被破壞，這時的恢復操做可分爲三步：

裝入最新的數據庫後備副本，使數據庫恢復到最近一次轉儲時的一致性狀態。

從故障點開始反向讀日誌文件，找出已提交事務標識將其記入重作隊列。

從起始點開始正向閱讀日誌文件，根據重作隊列中的記錄，重作全部已完成事務，將數據庫恢復至故障前某一時刻的一致狀態。

（4）具備檢查點的恢復技術。檢查點記錄的內容可包括：

創建檢查點時刻全部正在執行的事務清單。

這些事務最近一個日誌記錄的地址。採用檢查點的恢復步驟以下：

從從新開始文件中找到最後一個檢查點記錄在日誌文件中的地址，由該地址在日誌文件中找到最後一個檢查點記錄。

由該檢查點記錄獲得檢查點創建時全部正在執行的事務清單隊列（A）。

創建重作隊列（R）和撤銷隊列（U），把 A 隊列放入 U 隊列中，R 隊列爲空。

從檢查點開始正向掃描日誌文件，如有新開始的事務 T1，則把 T1 放入 U 隊列，如有提交的事務 T2，則把 T2 從 U 隊列移到 R 隊列，直至日誌文件結束。

U 隊列的每一個事務執行 Undo 操做，對 R 隊列的每一個事務執行 Redo 操做。

DBA 要作的基本操做是：

重裝最近轉儲的後援副本。

運行日誌文件，執行系統提供的恢復命令。

數據庫安全和恢復是數據庫系統正常運行的保證。大型數據庫管理系統通常都提供了實現安全機制的保證，即由系統提供了相應的功能，但小型的數據庫管理系統並不是都具備相應功能，所以有時須要人工的輔助措施，用以保證數據庫的安全和恢復。

3.5 備份與恢復

數據庫中的數據通常都十分重要，不能丟失，由於各類緣由，數據庫都有損壞的可能性

（雖然很小），因此事先制定一個合適的、可操做的備份和恢復計劃相當重要。備份和恢復計劃的制訂要遵循如下兩個原則：

（1）保證數據丟失的狀況儘可能少或徹底不丟失，由於性價比的要求，這要取決於現實系統的具體要求。

（2）備份和恢復時間儘可能短，保證系統最大的可用性。數據庫備份按照不一樣方式可分爲多種，這裏按照備分內容分爲物理備份和邏輯備份兩類。

物理備份是在操做系統層面上對數據庫的數據文件進行備份，物理備份分爲冷備份和熱備份兩種。冷備份是將數據庫正常關閉，在中止狀態下利用操做系統的 copy、cp、tar、 cpio 等命令將數據庫的文件所有備份下來，當數據庫發生故障時，將數據文件複製回來，進行恢復。熱備份也分爲兩種，一種是不關閉數據庫，將數據庫中須要備份的數據文件依次置於備份狀態，相對保持靜止，而後再利用操做系統的 copy、cp、tar、cpio 等命令將數據庫的文件備份下來，備份完畢後再將數據文件恢復爲正常狀態，當數據庫發生故障時，恢復方法同冷備份同樣。熱備份的另一種方式是利用備份軟件（例如，veritas 公司的 netbackup，legato公司的 network 等）在數據庫正常運行的狀態下，將數據庫中的數據文件備份出來。

爲了提升物理備份的效率，一般將徹底、增量、累積三種備份方式相組合。徹底備份是將數據庫的內容所有備份，做爲增量、累積的基礎；增量備份是隻備份上次徹底、增量或累積備份以來修改的數據；累積備份是備份自上次徹底或累積備份以來修改過的數據。一個備份週期一般由一個徹底備份和多個增量、累積備份組成。因爲增量或累計備份導出的數據少，因此其導出的文件較小，所須要的時間較少。利用一個徹底備份和多個增量、累積備份恢復數據庫的步驟以下：

（1）首先從徹底備份恢復數據庫。

（2）而後按照時間順序從早到晚依次導入多個增量和累積備份文件。

邏輯備份是指利用各數據庫系統自帶的工具軟件備份和恢復數據庫的內容，例如， Oracle 的導出工具爲 exp，導入工具爲 imp，能夠按照表、表空間、用戶、全庫等四個層次備份和恢復數據；Sybase 的全庫備份命令是 dump database，全庫恢復命令是 load database，另外也可利用 BCP 命令來備份和恢復指定表。

在數據庫容量不大的狀況下邏輯備份是一個很是有效的手段，既簡單又方便，但如今隨着數據量的愈來愈大，利用邏輯備份來備份和恢復數據庫已力不從心，速度也很慢。針對大型數據庫的備份和恢復通常結合磁帶庫採用物理的徹底、增量、累積三種備份方式相組合來進行。但不管任什麼時候候邏輯備份都是一種很是有效的手段，特別適合於平常維護中的部分指定表的備份和恢復。

3.6 分佈式數據庫系統

近年來，隨着計算機技術與網絡技術的發展，特別是 Internet 的興起，分佈式數據庫系統獲得了很快的發展和應用。

3.6.1 分佈式數據庫的概念

分佈式數據庫系統是相對於集中式數據庫系統而言的，是將數據庫技術與網絡技術相結合的產物。分佈式數據庫（Distributed DataBase，DDB）比較確切的定義是：分佈式數據庫是由一組數據組成的，這組數據分佈在計算機網絡的不一樣計算機上，網絡中的每一個結點具備獨立處理的能力，成爲場地自治，它能夠執行局部應用，同時，每一個結點也能經過網絡通訊子系統執行全局應用。負責分佈式數據庫的創建、查詢、更新、複製、管理和維護的軟件，稱爲分佈式數據庫管理系統（Distributed DataBase Management System， DDBMS）。分佈式數據庫管理系統保證分佈式數據庫中數據的物理分佈對用戶的透明性。一個計算機網絡組成的計算機系統，在配置了分佈式數據庫管理系統，並在其上創建了分佈式數據庫和相應的應用程序後，就稱其爲分佈式數據庫系統（Distributed DataBase System，DDBS）。分佈式數據庫管理系統是分佈式數據庫系統的核心。

分佈式數據庫的特色從上面的定義能夠看出分佈式數據庫系統有如下幾個特色：

（1）數據的分佈性。分佈式數據庫中的數據分佈於網絡中的各個結點，它既不一樣於傳統的集中式數據庫，也不一樣於經過計算機網絡共享的集中式數據庫系統。

（2）統一性。主要表如今數據在邏輯上的統一性和數據在管理上的統一性兩個方面。分佈式數據庫系統經過網絡技術把局部的、分散的數據庫構成一個在邏輯上單一的數據庫，從而呈如今用戶面前的就如同是一個統一的、集中式的數據庫。這就是數據在邏輯上的統一性，所以，它不一樣於由網絡互聯的多個獨立數據庫。分佈式數據庫是由分佈式數據庫管理系通通一管理和維護的，這種管理上的統一性又使它不一樣於通常的分佈式文件系統。

（3）透明性。用戶在使用分佈式數據庫時，與使用集中式數據庫同樣，無須知道其所關心的數據存放在哪裏，存儲了幾回。用戶須要關心的僅僅是整個數據庫的邏輯結構。

與集中式數據庫相比，分佈式數據庫具備下列優勢：

（1）堅固性好。因爲分佈式數據庫系統是由多個位置上的多臺計算機構成的，在個別結點或個別通訊鏈路發生故障的狀況下，它仍然能夠下降級別繼續工做，若是採用冗餘技術，還能夠得到必定的容錯能力。所以，系統的堅固性好，即系統的可靠性和可用性好。

（2）可擴充性好。可根據發展的須要增減結點，或對系統從新配置，這比用一個更大的系統代替一個已有的集中式數據庫要容易得多。

（3）可改善性能。在分佈式數據庫中可按就近分佈，合理地冗餘的原則來分佈各結點上的數據，構造分佈式數據庫，使大部分數據能夠就近訪問，避免了集中式數據庫中的瓶頸問題，減小了系統的響應時間，提升了系統的效率，並且也下降了通訊費用。

（4）自治性好。數據能夠分散管理，統一協調，即系統中各結點的數據操縱和相互做用是高度自治的，不存在主從控制，所以，分佈式數據庫較好地知足了一個單位中各部門但願擁有本身的數據，管理本身的數據，同時又想共享其餘部門有關數據的要求。

雖然分佈式數據庫系統與集中式數據庫相比有很多優勢，但同時也須要解決一些集中式數據庫所沒有的問題。首先，異構數據庫的集成問題是一項比較複雜的技術問題，目前還很難用一個通用的分佈式數據庫管理系統來解決這一問題。其次，若是數據庫設計得很差，數據分佈不合理，以至遠距離訪問過多，尤爲是分佈鏈接操做過多，不但不能改善性能，反而會使性能下降。

分佈式數據庫的分類

分佈式數據庫及其分佈式數據庫管理系統，根據許多因素有不一樣的分類方法，總的原則是分佈式數據庫及 DDBMS 必須是其數據和軟件一定分佈在用計算機網絡鏈接的多個場地上。從應用須要或自己的特徵方面考慮可將它從如下幾個方面來劃分：

（1）按 DDBMS 軟件同構度來分。當全部服務器軟件（或每一個 LDBMS）和全部客戶軟件均用相同的軟件時稱爲同構型分佈式數據庫；反之，則稱爲異構型分佈式數據庫。

（2）按局部自治度來分。當對 DDBMS 的存取必須經過客戶軟件，則系統稱爲無局部自治；當局部事務容許對服務器軟件進行直接存取，則系統稱爲有必定的局部自治。自治的兩個分別是無局部自治和聯邦型 DDBMS 或稱多數據庫系統。多數據庫系統本質上是集中式與分佈式的混合體：對一個局部用戶而言，它是自治的，那麼是一個集中式 DBS；對一個全局用戶而言，則是一個分佈式 DBS，但這個 DDBS 沒有全局概念模式，只有一個由各局部數據庫提供給全局容許共享的有關模式的集成。

（3）按分佈透明度來分。分佈透明度的另外一個概念是模式集成度。若用戶能夠對集成模式操做不須要涉及任何片斷、重複、分佈等信息時，則這類 DDBMS 稱爲有高度分佈透明（或高度模式集成）；若用戶必須知道全部關於片斷、分配、重複等信息時，則這類 DDBMS 沒有分佈透明，沒有模式集成度。當系統不提供分佈透明，用戶查詢時必須指定特定的場地、特定的片斷等信息，固然 DDBMS 能夠部分分佈透明（介於二者之間）。

分佈式數據庫的目標

理想的分佈式系統使用時應該精確得像一個非分佈式系統。歸納起來有如下 12 條具體規則和目標：

（1）局部結點自治性。網絡中的每一個結點是獨立的數據庫系統，它有本身的數據庫，運行它的局部 DBMS，執行局部應用，具備高度的自治性。

（2）不依賴中心結點。即每一個結點具備全局字典管理、查詢處理、併發控制和恢復控制等功能。

（3）能連續操做。該目標使中斷分佈式數據庫服務狀況減至最少，當一個新場地合併到現有的分佈式系統或從分佈式系統中撤離一個場地不會致使任何沒必要要的服務中斷；在分佈式系統中可動態地創建和消除片斷，而不停止任何組成部分的場地或數據庫；應儘量在不使整個系統停機的狀況下對組成分佈式系統的場地的 DBMS 進行升級。

（4）具備位置獨立性（或稱位置透明性）。用戶沒必要知道數據的物理存儲地，可工做可像數據所有存儲在局部場地同樣。通常位置獨立性須要有分佈式數據命名模式和字典子系統的支持。

（5）分片獨立性（或稱分片透明性）。分佈式系統若是可將給定的關係分紅若干塊或片，可提升系統的處理性能。利用分片將數據存儲在最頻繁使用它的位置上，使大部分操做爲局部操做，減小網絡的信息流量。若是系統支持分片獨立性，那麼用戶工做起來就像數據全然不是分片的同樣。

（6）數據複製獨立性。是指將給定的關係（或片斷）可在物理級用許多不一樣存儲副本或複製品在許多不一樣場地上存儲。支持數據複製的系統應當支持複製獨立性，用戶工做可像它全然沒有存儲副本同樣地工做。

（7）支持分佈式查詢處理。在分佈式數據庫系統中有三類查詢：局部查詢、遠程查詢和全局查詢。局部查詢和遠程查詢僅涉及單個結點的數據（本地的或遠程的），查詢優化採用的技術是集中式數據庫的查詢優化技術。全局查詢涉及多個結點上的數據，其查詢處理和優化要複雜得多。

（8）支持分佈事務管理。事務管理有兩個主要方面：恢復控制和併發控制。在分佈式系統中，單個事務會涉及多個場地上的代碼執行，會涉及多個場地上的更新，能夠說每一個事務是由多個「代理」組成的，每一個代理表明在給定場地上的給定事務上執行的過程。在分佈式系統中必須保證事務的代理集或者所有一致交付，或者所有一致回滾。

（9）具備硬件獨立性。但願在不一樣硬件系統上運行一樣的 DBMS。

（10）具備操做系統獨立性。但願在不一樣的操做系統上運行 DBMS。

（11）具備網絡獨立性。若是系統可以支持多個不一樣的場地，每一個場地有不一樣的硬件和不一樣的操做系統，則要求該系統能支持各類不一樣的通訊網絡。

（12）具備 DBMS 獨立性。實現對異構型分佈式系統的支持。理想的分佈式系統應該提供 DBMS 獨立性。

上述的全功能分佈式數據庫系統的準則和目標起源於：一個分佈式數據庫系統，對用戶來講，應當看上去徹底像一個非分佈式系統。值得指出的是，現實系統出於對某些方面的特別考慮，對上述各方面作出了種種權衡和選擇。

3.6.2 分佈式數據庫的架構

分佈式數據庫系統的模式結構有六個層次，如圖 3-8 所示，實際的系統並不是都具備這種結構。在這種結構中各級模式的層次清晰，能夠歸納和說明任何分佈式數據庫系統的概念和結構。

圖 3-8 的模式結構從總體上能夠分爲兩大部分：下半部分是集中式數據庫的模式結構，表明了各局部場地上局部數據庫系統的基本結構；上半部分是分佈式數據庫系統增長的模式級別。

（1）全局外模式。它們是全局應用的用戶視圖，是全局概念模式的子集。

（2）全局概念模式。它定義分佈式數據庫中數據的總體邏輯結構，數據就如同根本沒有分佈同樣，可用傳統的集中式數據庫中所採用的方法定義。全局概念模式中所用的數據模型應該易於向其餘層次的模式映像，一般採用關係模型。這樣，全局概念模式包括一組全局關係的定義。

（3）分片模式。每個全局關係能夠劃分爲若干不相交的部分，每一部分稱爲一個片斷，即「數據分片」。分片模式就是定義片斷及全局關係到片斷的映像。這種映像是一對多的，即每一個片斷來自一個全局關係，而一個全局關係可對應多個片斷。

（4）分佈模式。由數據分片獲得的片段仍然是 DDB 的全局數據，是全局關係的邏輯部分，每個片斷在物理上能夠分配到網絡的一個或多個不一樣結點上。分佈模式定義片斷的存放結點。分佈模式的映像類型肯定了分佈式數據庫是冗餘的仍是非冗餘的。若映像是一對多的，即一個片斷分配到多個結點上存放，則是冗餘的分佈數據庫，不然是不冗餘的分佈數據庫。

根據分佈模式提供的信息，一個全局查詢可分解爲若干子查詢，每一子查詢要訪問的數據屬於同一場地的局部數據庫。由分佈模式到各局部數據庫的映像（映像 4）把存儲在局部場地的全局關係或全局關係的片斷映像爲各局部概念模式採用局部場地的 DBMS 所支持的數據模型。

分片模式和分佈模式均是全局的，分佈式數據庫系統中增長的這些模式和相應的映像使分佈式數據庫系統具備了分佈透明性。

（5）局部概念模式。一個全局關係經邏輯劃分紅一個或多個邏輯片段，每一個邏輯片段被分配在一個或多個場地上，稱爲該邏輯片段在某場地上的物理映像或物理片段。分配在同一場地上的同一個全局概念模式的若干片段（物理片段）構成了該全局概念在該場地上的一個物理映像。

一個場地上的局部概念模式是該場地上全部全局概念模式在該場地上物理映像的集合。因而可知，全局概念模式與場地獨立，而局部概念模式與場地相關。

（6）局部內模式。局部內模式是 DDB 中關於物理數據庫的描述，相似於集中式 DB 中的內模式，但其描述的內容不只包含局部本場地的數據的存儲描述，還包括全局數據在本場地的存儲描述。

在圖 3-8 的六層模式結構中，全局概念模式、分片模式和分佈模式是與場地特徵無關的，是全局的，所以它們不依賴於局部 DBMS 的數據模型。在低層次上，須要把物理映像映射成由局部 DBMS 支持的數據模型。這種映像由局部映射模式完成。具體的映射關係，

由局部 DBMS 的類型決定。在異構型系統中，可在不一樣場地上擁有類型的局部映射模式。這種分層的模式結構爲理解 DDB 提供了一種通用的概念結構。它有三個顯著的特徵：

（1）數據分片和數據分配概念的分離，造成了「數據分佈獨立型」概念。

（2）數據冗餘的顯示控制。數據在各個場地的分配狀況在分配模式中一目瞭然，便於系統管理。

（3）局部 DBMS 的獨立性。這個特徵也稱爲「局部映射透明性」。此特徵容許在不考慮局部 DBMS 專用數據模型的狀況下研究 DDB 管理的有關問題。

分佈式數據庫系統與並行數據庫系統的區別

分佈式數據庫系統與並行數據庫系統具備不少類似點：它們都是經過網絡鏈接各個數據處理結點的，整個網絡中的全部結點構成一個邏輯上統一的總體，用戶能夠對各個結點上的數據進行透明存取等。但分佈式數據庫系統與並行數據庫系統之間仍是存在着顯著的區別的，主要表如今如下幾個方面：

（1）應用目標不一樣。並行數據庫系統的目標是充分發揮並行計算機的優點，利用系統中的各個處理機結點並行地完成數據庫任務，提升數據庫的總體性能。分佈式數據庫系統主要目的在於實現各個場地自治和數據的全局透明共享，而不要求利用網絡中的各個結點來提升系統的總體性能。

（2）實現方式不一樣。因爲應用目標各不相同，在具體實現方法上，並行數據庫與分佈式數據庫之間也有着較大的區別。在並行數據庫中，爲了充分發揮各個結點的處理能力，各結點間採用高速通訊網絡互聯，結點間數據傳輸代價相對較低。當負載不均衡時，能夠將工做負載過大的結點上的任務經過高速通訊網絡送給空閒結點處理，從而實現負載平衡。在分佈式數據庫系統中，各結點（場地）間通常經過局域網或廣域網互聯，網絡帶寬比較低，各場地之間的通訊開銷較大，所以在查詢處理時通常應儘可能減小結點間的數據傳輸量。

（3）各結點的地位不一樣。在並行數據庫中，各結點之間不存在全局應用和局部應用的概念。各個結點協同做用，共同處理，而不可能有局部應用。

在分佈式數據庫系統中，各結點除了能經過網絡協同完成全局事務外，還有本身結點場地的自治性。也就是說，分佈式數據庫系統的每一個場地又是一個獨立的數據庫系統，除了擁有本身的硬件系統（CPU、內存和磁盤等）外，還擁有本身的數據庫和本身的客戶，可運行本身的 DBMS，執行局部應用，具備高度的自治性。這是並行數據庫與分佈式數據庫之間最主要的區別。

數據分片和透明性

將數據分片，使數據存放的單位不是關係而是片斷，這既有利於按照用戶的需求較好地組織數據的分佈，也有利於控制數據的冗餘度。分片的方式有多種，水平分片和垂直分片是兩種基本的分片方式，混合分片和導出分片是較複雜的分片方式。

分佈透明性指用戶沒必要關心數據的邏輯分片，沒必要關心數據存儲的物理位置分配細節，也沒必要關心局部場地上數據庫的數據模型。從圖 3-8 的模式結構能夠看到分佈透明性包括：分片透明性、位置透明性和局部數據模型透明性。

（1）分片透明性是分佈透明性的最高層次。所謂分片透明性是指用戶或應用程序只對全局關係進行操做而沒必要考慮數據的分片。當分片模式改變時，只要改變全局模式到分片模式的映像（映像 2），而不影響全局模式和應用程序。全局模式不變，應用程序沒必要改寫，這就是分片透明性。

（2）位置透明性是分佈透明性的下一層次。所謂位置透明性是指，用戶或應用程序應當瞭解分片狀況，但沒必要了解片斷的存儲場地。當存儲場地改變時，只要改變分片模式到分配模式的映像（映像 3），而不影響應用程序。同時，若片斷的重複副本數目改變了，那麼數據的冗餘也會改變，但用戶沒必要關心如何保持各副本的一致性，這也提供了重複副本的透明性。

（3）局部數據模型透明性是指用戶或應用程序應當瞭解分片及各片段存儲的場地，但沒必要了解局部場地上使用的是何種數據模型。模型的轉換及語言等的轉換均由映像 4 來完成。

分佈式數據庫管理系統分佈式數據庫管理系統的任務，首先就是把用戶與分佈式數據庫隔離開來，使其對用戶而言，整個分佈式數據庫就好像是一個傳統的集中式數據庫。換句話說，一個分佈式數據庫管理系統與用戶之間的接口，在邏輯上與集中式數據庫管理系統是一致的。可是考慮到分佈式數據庫的特色，其物理實現上又與集中式數據庫不一樣。下面以一種分佈式數據庫管理。

以系統 DDBMS 的結構爲例來分析它的主要成分和功能，如圖 3-9 所示。

由圖 3-9 能夠看出，DDBMS 由 4 部分組成：

（1） LDBMS（局部 DBMS）。局部場地上的數據庫管理系統的功能是創建和管理局部數據庫，提供場地自治能力、執行局部應用及全局查詢的子查詢。

（2） GDBMS（全局 DBMS）。全局數據庫管理系統的主要功能是提供分佈透明性，協調全局事務的執行，協調各局部 DBMS 以完成全局應用，保證數據庫的全局一致性，執行併發控制，實現更新同步，提供全局恢復功能。

（3）全局數據字典。存放全局概念模式、分片模式、分佈模式的定義及各模式之間映像的定義；存放有關用戶存取權限的定義，以保證全局用戶的合法權限和數據庫的安全性；存放數據完整性約束條件的定義，其功能與集中式數據庫的數據字典相似。

（4） CM（Communication Management，通訊管理）。在分佈數據庫各場地之間傳送消息和數據，完成通訊功能。

DDBMS 功能的分割和重複及不一樣的配置策略就致使了各類架構。

（1）全局控制集中的 DDBMS。這種結構的特色是全局控制成分 GDBMS 集中在某一結點上，由該結點完成全局事務的協調和局部數據庫轉換等一切控制功能，全局數據字典只有一個，也存放在該結點上，它是 GDBMS 執行控制的依據。它的優勢是控制簡單，易實現更新一致性。但因爲控制集中在某一特定的結點上，不只容易造成瓶頸並且系統較脆弱，一旦該結點出故障，整個系統就會癱瘓。

（2）全局控制分散的 DDBMS。這種結構的特色是全局控制成分 GDBMS 分散在網絡的每個結點上，全局數據字典也在每一個結點上有一份，每一個結點都能完成全局事務的協調和局部數據庫轉換，每一個結點既是全局事務的參與者又是協調者，通常稱這類結構爲徹底分佈的 DDBMS。它的優勢是結點獨立，自治性強，單個結點退出或進入系統均不會影響整個系統的運行，可是全局控制的協調機制和一致性的維護都比較複雜。

（3）全局控制部分分散的 DDBMS。這種結構是根據應用的須要將 GDBMS 和全局數據字典分散在某些結點上，是介於前兩種狀況之間的架構。

局部 DBMS 的一個重要性質是：局部 DBMS 是同構的仍是異構的。同構和異構的級別能夠有三級：硬件、操做系統和局部 DBMS。其中最主要的是局部 DBMS 這一級，由於硬件和操做系統的不一樣將由通訊軟件處理和管理。

異構型 DDBMS 的設計和實現比同構型 DDBMS 更加複雜，它要解決不一樣的 DBMS 之間及不一樣的數據模型之間的轉換。所以在設計和實現 DDBMS 時，如果用自頂向下的方法進行，即並不存在已運行的局部數據庫，則採用同構型的結構比較方便。如果採用自底向上設計 DDBMS 的方法，即現已存在的局部數據庫，而這些數據庫可能採用不一樣的數據模型

（層次、網狀或關係），或者雖然模型相同但它們是不一樣廠商的 DBMS（如 Informix、Sybase、 Db二、Oracle），這就必須開發異構型的 DDBMS。要解決異構數據庫模型的同種化問題，是研製異構型 DDBMS 的關鍵所在，所謂同種化就是尋找合適的公共數據模型，採用公共數據模型與異構數據模型（局部）之間的轉換，不採用各結點之間的一對一轉換。這樣能夠減小轉移次數。設有 N 個結點，用公共數據模型時轉換次數爲 2N，而各結點之間一對一轉換則需 N（N1）次。

3.7 數據倉庫

傳統的操做型數據庫主要是面向業務的，所執行的操做基本上也是聯機事務處理，但隨着企業規模的增加，歷史積累的數據愈來愈多，如何利用歷史數據來爲將來決策服務，就顯得愈來愈重要了，而數據倉庫就是其中的一種技術。

3.7.1 數據倉庫的概念

著名的數據倉庫專家 W.H.Inmon 在《Building the Data Warehouse》一書中將數據倉庫定義爲：數據倉庫（Data Warehouse）是一個面向主題的、集成的、相對穩定的、且隨時間

變化的數據集合，用於支持管理決策。

面向主題的操做型數據庫的數據組織面向事務處理任務（面向應用），各個業務系統之間各自分離，而數據倉庫中的數據是按照必定的主題域進行組織的。主題是一個抽象的概念，是指用戶使用數據倉庫進行決策時所關心的重點方面，一個主題一般與多個操做型信息系統相關。例如，一個保險公司所進行的事務處理（應用問題）可能包括汽車保險、人壽保險、健康保險和意外保險等，而公司的主要主題範圍多是顧客、保險單、保險費和索賠等。 2．集成的在數據倉庫的全部特性中，這是最重要的。面向事務處理的操做型數據庫通

常與某些特定的應用相關，數據庫之間相互獨立，而且每每是異構的。而數據倉庫中的數據是在對原有分散的數據庫數據抽取、清理的基礎上通過系統加工、彙總和整理獲得的，必須消除源數據中的不一致性，以保證數據倉庫內的信息是關於整個企業的一致的全局信息。

相對穩定的操做型數據庫中的數據一般實時更新，數據根據須要及時發生變化。數據倉庫的數據主要供企業決策分析之用，所涉及的數據操做主要是數據查詢，一旦某個數據進入數據倉庫之後，通常狀況下將被長期保留，也就是數據倉庫中通常有大量的查詢操做，但修改和刪除操做不多，一般只須要按期地加載、刷新。
隨時間變化的操做型數據庫主要關心當前某一個時間段內的數據，而數據倉庫中的數據一般包含歷史信息，系統記錄了企業從過去某一時點（如開始應用數據倉庫的時點）到目前的各個階段的信息，經過這些信息，能夠對企業的發展歷程和將來趨勢作出定量分析和預測。數據倉庫反映歷史變化的屬性主要表如今：

（1）數據倉庫中的數據時間期限要遠遠長於傳統操做型數據系統中的數據時間期限，傳統操做型數據系統中的數據時間期限可能爲數十天或數個月，數據倉庫中的數據時間期限每每爲數年甚至幾十年；

（2）傳統操做型數據系統中的數據含有「當前值」的數據，這些數據在訪問時是有效的，固然數據的當前值也能被更新，但數據倉庫中的數據僅僅是一系列某一時刻（多是傳統操做型數據系統）生成的複雜的快照；

（3）傳統操做型數據系統中可能包含也可能不包含時間元素，如年、月、日、時、分、秒等，而數據倉庫中必定會包含時間元素。

數據倉庫雖然是從傳統數據庫系統發展而來，可是二者仍是存在着諸多差別，如：從數據存儲的內容看，數據庫只存放當前值，而數據倉庫則存放歷史值；數據庫數據的目標是面向業務操做人員的，爲業務處理人員提供數據處理的支持，而數據倉庫則是面向中高層管理人員的，爲其提供決策支持等。表 3-10 詳細說明了數據倉庫與傳統數據庫的區別。

3.7.2 數據倉庫的結構

從數據倉庫的概念結構看，通常來講，數據倉庫系統要包含數據源、數據準備區、數據倉庫數據庫、數據集市/知識挖掘庫及各類管理工具和應用工具，如圖 3-10 所示。數據倉庫創建以後，首先要從數據源中抽取相關的數據到數據準備區，在數據準備區中通過淨化處理後再加載到數據倉庫數據庫，最後根據用戶的需求將數據導入數據集市和知識挖掘庫中。當用戶使用數據倉庫時，能夠利用包括 OLAP（On-Line Analysis Processing，聯機分析處理）在內的多種數據倉庫應用工具向數據集市/知識挖掘庫或數據倉庫進行決策查詢分析或知識挖掘。數據倉庫的建立、應用能夠利用各類數據倉庫管理工具輔助完成。

數據倉庫的參考框架

數據倉庫的參考框架由數據倉庫基本功能層、數據倉庫管理層和數據倉庫環境支持層組成，如圖 3-11 所示。

（1）數據倉庫基本功能層。數據倉庫的基本功能層部分包含數據源、數據準備區、數據倉庫結構、數據集市或知識挖掘庫，以及存取和使用部分。本層的功能是從數據源抽取數據，對所抽取的數據進行篩選、清理，將處理過的數據導入或者說加載到數據倉庫中，根據用戶的需求設立數據集市，完成數據倉庫的複雜查詢、決策分析和知識的挖掘等。

（2）數據倉庫管理層。數據倉庫的正常運行除了須要數據倉庫功能層提供的基本功能外，還須要對這些基本功能進行管理與支持的結構框架。數據倉庫管理層由數據倉庫的數據管理和數據倉庫的元數據管理組成。

數據倉庫的數據管理層包含數據抽取、新數據需求與查詢管理，數據加載、存儲、刷新和更新系統，安全性與用戶受權管理系統及數據歸檔、恢復及淨化系統等四部分。

（3）數據倉庫的環境支持層。數據倉庫的環境支持層由數據倉庫數據傳輸層和數據倉庫基礎層組成。數據倉庫中不一樣結構之間的數據傳輸須要數據倉庫的傳輸層來完成。

數據倉庫的傳輸層包含數據傳輸和傳送網絡、客戶/服務器代理和中間件、複製系統及數據傳輸層的安全保障系統。

數據倉庫的架構大衆觀點的數據倉庫的架構如圖 3-12 所示。

（1）數據源。是數據倉庫系統的基礎，是整個系統的數據源泉。一般包括企業內部信息和外部信息。內部信息包括存放於 RDBMS（關係型 DBMS）中的各類業務處理數據和各種文檔數據。外部信息包括各種法律法規、市場信息和競爭對手的信息等。

（2）數據的存儲與管理。是整個數據倉庫系統的核心。數據倉庫的真正關鍵是數據的存儲和管理。數據倉庫的組織管理方式決定了它有別於傳統數據庫，同時也決定了其對外部數據的表現形式。要決定採用什麼產品和技術來創建數據倉庫的核心，則須要從數據倉庫的技術特色着手分析。針對現有各業務系統的數據，進行抽取、清理，並有效集成，按照主題進行組織。數據倉庫按照數據的覆蓋範圍能夠分爲企業級數據倉庫和部門級數據倉庫（一般稱爲數據集市）。

（3） OLAP 服務器。對分析須要的數據進行有效集成，按多維模型予以組織，以便進行多角度、多層次的分析，並發現趨勢。其具體實現能夠分爲：ROLAP、MOLAP 和 HOLAP。ROLAP 基本數據和聚合數據均存放在 RDBMS 之中；MOLAP 基本數據和聚合數據均存放於多維數據庫中；HOLAP 基本數據存放於 RDBMS 之中，聚合數據存放於多維數據庫中。

（4）前端工具。主要包括各類報表工具、查詢工具、數據分析工具、數據挖掘工具及各類基於數據倉庫或數據集市的應用開發工具。其中數據分析工具主要針對 OLAP 服務器，報表工具、數據挖掘工具主要針對數據倉庫。

3.7.3 數據倉庫的實現方法

數據倉庫的特性決定了數據倉庫的設計不一樣於傳統的數據庫設計方法。數據倉庫系統的原始需求一般不是很明確，而且需求仍在不斷變化、增長，因此，數據倉庫的創建是一個過程，從創建簡單的基本框架着手，不斷豐富和完善整個系統。這一過程將由如下幾部分構成：需求分析、概念模型設計、邏輯模型設計、物理模型設計和數據倉庫生成。

從總體的角度來看，數據倉庫的實現方法主要有自頂向下法、自底向上法和聯合方法。

自頂向下法

在該方法中，首先應找出數據倉庫解決方案所要知足的商業需求，把商業需求視爲實現數據倉庫的首要任務。數據倉庫是一種功能而不是一種特徵，數據倉庫保存信息，並之外部工具易於顯示和操做的方式組織這些信息。所以，若是不借助於能夠利用這種功能的外部工具，最終用戶就沒法將這種功能嵌入數據倉庫中。這樣，就很難定出該功能的範圍，除非用廣義上的商業術語，如「數據倉庫將包含有關客戶、供應商、市場、產品的信息」。自頂向

下方法的優勢和缺點如表 3-11 所示。

規劃和實現數據倉庫的自頂向下方法通常用於如下狀況：

（1）實現單位比較熟悉技術，並具備根據商業需求採用自頂向下方法開發應用程序的豐富經驗。

（2）決策層（總經理、決策者、投資者）徹底清楚數據倉庫的預測目標。

（3）決策層（總經理、決策者、投資者）徹底清楚數據倉庫用做哪些機構的決策支持工具。

（4）決策層（總經理、決策者、投資者）徹底清楚數據倉庫已是商業過程當中的一個子過程。

若是技術是成熟的和衆所周知的，或者必須解決的商業問題是顯而易見的，那麼自頂向下方法是頗有用的。採用自頂向下方法能夠將技術和商業目標有機地結合起來。

自底向上法

自底向上方法通常從實驗和基於技術的原形入手。先選擇一個特定的、衆所周知的商業問題的子集，再爲該子集制訂方案。實現自底向上通常是比較快的。自底向上能夠使一個單位在發展時用盡量少的經費和時間，就能夠在作出有效的投入以前評估技術的收益狀況。在數據倉庫領域，自底向上方法是快速實現數據集市、部門級數據倉庫的有效手段。自底向上方法的優勢和缺點如表 3-12 所示。

規劃和實現數據倉庫的自底向上方法通常用於如下狀況：

（1）企業尚未確實掌握數據倉庫技術，但願進行技術評估來決定運行該技術的方式、地點和時間。

（2）企業但願瞭解實現和運行數據倉庫所須要的各類費用狀況。

（3）企業在對數據倉庫進行投資選擇。自底向上方法對於但願從數據倉庫投資中快速獲得回報的用戶是很是有效的。該方法

能夠使企業充分利用各類技術，無須冒很大風險。

聯合方法

在以上兩種方法的聯合方法中，企業在保持自底向上方法的快速實現和機遇應用的同時，還能夠利用自頂向下方法的規劃和決策性質。這種方法依賴於如下兩個因素：

（1）自頂向下的結構、標準和設計小組，能夠從一個項目向另一個項目傳遞知識，也能夠把戰術決策變爲戰略決策。

（2）自底向上方法的項目小組，它直接負責在短時間內實現一個集中的、部門級的商務解決方案。

聯合方法具備以上兩種方法的優勢，可是難以做爲一個項目來管理。該方法通常用於：

（1）實現企業擁有經驗豐富的設計師，有能力創建、證實、應用和維護數據結構、技術結構及企業模型，能夠很容易地從具體（運做系統中的元數據）轉移到抽象。

（2）企業擁有固定的項目小組，徹底清楚數據倉庫技術應用的場所。他們能夠清楚地看到當前的商務需求。

聯合方法適合數據倉庫技術的快速試運行，而且保留了創建長遠的決策方案的機會。

3.8 數據挖掘

隨着數據庫技術的迅速發展及數據庫管理系統的普遍應用，人們積累的數據愈來愈多。激增的數據背後隱藏着許多重要的信息，人們但願可以對其進行更高層次的分析，以便更好地利用這些數據。目前的數據庫系統能夠高效地實現數據的錄入、查詢、統計等功能，但沒法發現數據中存在的關係和規則，沒法根據現有的數據預測將來的發展趨勢。缺少挖掘數據背後隱藏的知識的手段，致使了「數據爆炸但知識貧乏」的現象。

3.8.1 數據挖掘的概念

數據挖掘（Data Mining）技術是人們長期對數據庫技術進行研究和開發的結果。起初各類商業數據是存儲在計算機的數據庫中的，而後發展到可對數據庫進行查詢和訪問，進而發展到對數據庫的即時遍歷。數據挖掘使數據庫技術進入了一個更高級的階段，它不只能對過

去的數據進行查詢和遍歷，而且可以找出過去數據之間的潛在聯繫，從而促進信息的傳遞。如今數據挖掘技術在商業應用中已經能夠立刻投入使用，由於對這種技術進行支持的三種基礎技術已經發展成熟，它們是海量數據蒐集、強大的多處理器計算機和數據挖掘算法。

從技術角度來看，數據挖掘就是從大量的、不徹底的、有噪聲的、模糊的、隨機的實際應用數據中，提取隱含在其中的、人們事先不知道的、但又是潛在有用的信息和知識的過程。這個定義包括好幾層含義：數據源必須是真實的、大量的、含噪聲的；發現的是用戶感興趣的知識；發現的知識要可接受、可理解、可運用；並不要求發現放之四海而皆準的知識，僅支持特定的發現問題。

還有不少和這一術語相近的術語，如從數據庫中發現知識、數據分析、數據融合（Data Fusion），以及決策支持等。

何爲知識？從廣義上理解，數據、信息也是知識的表現形式，可是人們更把概念、規則、模式、規律和約束等看作知識。原始數據能夠是結構化的，如關係數據庫中的數據；也能夠是半結構化的，如文本、圖形和圖像數據；甚至是分佈在網絡上的異構型數據。發

現知識的方法能夠是數學的，也能夠是非數學的；能夠是演繹的，也能夠是概括的。發現的知識能夠被用於信息管理，查詢優化，決策支持和過程控制等，還能夠用於數據自身的維護。所以，數據挖掘是一門交叉學科，它把人們對數據的應用從低層次的簡單查詢，提高到從數據中挖掘知識，提供決策支持。在這種需求牽引下，匯聚了不一樣領域的研究者，尤爲是數據庫技術、人工智能技術、數理統計、可視化技術、並行計算等方面的學者和工程技術人員，投身到數據挖掘這一新興的研究領域，造成新的技術熱點。

從商業角度來看，數據挖掘是一種新的商業信息處理技術，其主要特色是對商業數據庫中的大量業務數據進行抽取、轉換、分析和其餘模型化處理，從中提取輔助商業決策的關鍵性數據。

簡而言之，數據挖掘實際上是一種深層次的數據分析方法。數據分析自己已經有不少年的歷史，只不過在過去數據收集和分析的目的是用於科學研究，另外，因爲當時計算能力的限制，對大量數據進行分析的複雜數據分析方法受到很大限制。如今，因爲各行業業務自動化的實現，商業領域產生了大量的業務數據，這些數據再也不是爲了分析的目的而收集，而是因爲純機會的商業運做而產生。分析這些數據也再也不是單純爲了研究的須要，更主要是爲商業決策提供真正有價值的信息，進而得到利潤。但全部企業面臨的一個共同問題是：企業數據量很是大，而其中真正有價值的信息卻不多，所以從大量的數據中經過深層分析，得到有利於商業運做、提升競爭力的信息，就像從礦石中淘金同樣，數據挖掘也所以而得名。

所以，數據挖掘能夠描述爲：按企業既定業務目標，對大量的企業數據進行探索和分析，揭示隱藏的、未知的或驗證已知的規律性，並進一步將其模型化的先進有效的方法。

數據挖掘與傳統的數據分析（如查詢、報表、聯機應用分析）的本質區別是數據挖掘是在沒有明確假設的前提下去挖掘信息、發現知識。數據挖掘所獲得的信息應具備先知，有效和可實用三個特徵。

先前未知的信息是指該信息是預先不曾預料到的，即數據挖掘是要發現那些不能靠直覺發現的信息或知識，甚至是違背直覺的信息或知識，挖掘出的信息越是出乎意料，就可能越有價值。在商業應用中最典型的例子就是一家連鎖店經過數據挖掘發現了小孩紙尿布和啤酒之間有着驚人的聯繫。

特別要指出的是，數據挖掘技術從一開始就是面向應用的。它不只是面向特定數據庫的簡單檢索查詢調用，並且要對這些數據進行微觀、中觀乃至宏觀的統計、分析、綜合和推理，以指導實際問題的求解，企圖發現事件間的相互關聯，甚至利用已有的數據對將來的活動進行預測。例如，加拿大 BC 省電話公司要求加拿大 Simon Fraser 大學知識發現研究組，根據其擁有十多年的客戶數據，總結、分析並提出新的電話收費和管理辦法，制定既有利於公司又有利於客戶的優惠政策。這樣一來，就把人們對數據的應用，從低層次的末端查詢操做，提升到爲各級經營決策者提供決策支持。這種需求驅動力比數據庫查詢更爲強大。

3.8.2 數據挖掘的功能

數據挖掘經過預測將來趨勢及行爲，作出前攝的、基於知識的決策。數據挖掘的目標是從數據庫中發現隱含的、有意義的知識，主要有如下五類功能。

自動預測趨勢和行爲數據挖掘自動在大型數據庫中尋找預測性信息，以往須要進行大量手工分析的問題現在能夠迅速直接由數據自己得出結論。一個典型的例子是市場預測問題，數據挖掘使用過去有關促銷的數據來尋找將來投資中回報最大的用戶，其餘可預測的問題包括預報破產及認定對指定事件最可能作出反應的羣體。
關聯分析數據關聯是數據庫中存在的一類重要的可被發現的知識。若兩個或多個變量的取值之間存在某種規律性，就稱爲關聯。關聯可分爲簡單關聯、時序關聯、因果關聯。關聯分析的目的是找出數據庫中隱藏的關聯網。有時並不知道數據庫中數據的關聯函數，即便知道也是不肯定的，所以關聯分析生成的規則帶有可信度。
1. 聚類數據庫中的記錄可被劃分爲一系列有意義的子集，即聚類。聚類加強了人們對

客觀現實的認識，是概念描述和誤差分析的先決條件。聚類技術主要包括傳統的模式識別方法和數學分類學。20 世紀 80 年代初，Mchalski 提出了概念聚類技術及其要點，即在劃分對象時不只要考慮對象之間的距離，還要求劃分出的類具備某種內涵描述，從而避免了傳統技術的某些片面性。

概念描述概念描述就是對某類對象的內涵進行描述，並歸納這類對象的有關特徵。概念描述分爲特徵性描述和區別性描述，前者描述某類對象的共同特徵，後者描述不一樣類對象之間的區別。生成一個類的特徵性描述只涉及該類對象中全部對象的共性。生成區別性描述的方法不少，如決策樹方法、遺傳算法等。
誤差檢測數據庫中的數據常有一些異常記錄，從數據庫中檢測這些誤差頗有意義。誤差包括不少潛在的知識，如分類中的反常實例、不知足規則的特例、觀測結果與模型預測值的誤差、量值隨時間的變化等。誤差檢測的基本方法是，尋找觀測結果與參照值之間有意義的差異。

3.8.3 數據挖掘經常使用技術

經常使用的數據挖掘技術包括關聯分析、序列分析、分類、預測、聚類分析及時間序列分析等。

關聯分析

關聯分析主要用於發現不一樣事件之間的關聯性，即一個事件發生的同時，另外一個事件也常常發生。關聯分析的重點在於快速發現那些有實用價值的關聯發生的事件。其主要依據是事件發生的機率和條件機率應該符合必定的統計意義。

對於結構化的數據，以客戶的購買習慣數據爲例，利用關聯分析，能夠發現客戶的關聯購買須要。例如，一個開設儲蓄帳戶的客戶極可能同時進行債券交易和股票交易，購買紙尿褲的男顧客常常同時購買啤酒等。利用這種知識能夠採起積極的營銷策略，擴展客戶購買的產品範圍，吸引更多的客戶。經過調整商品的佈局便於顧客買到常常同時購買的商品，或者經過下降一種商品的價格來促進另外一種商品的銷售等。

對於非結構化的數據，以空間數據爲例，利用關聯分析，能夠發現地理位置的關聯性。例如，85%的靠近高速公路的大城鎮與水相鄰，或者發現一般與高爾夫球場相鄰的對象等。

序列分析

序列分析技術主要用於發現必定時間間隔內接連發生的事件。這些事件構成一個序列，

發現的序列應該具備廣泛意義，其依據除了統計上的機率以外，還要加上時間的約束。

分類分析

分類分析經過分析具備類別的樣本的特色，獲得決定樣本屬於各類類別的規則或方法。利用這些規則和方法對未知類別的樣本分類時應該具備必定的準確度。其主要方法有基於統計學的貝葉斯方法、神經網絡方法、決策樹方法及支持向量機（support vector machines）等。

利用分類技術，能夠根據顧客的消費水平和基本特徵對顧客進行分類，找出對商家有較大利益貢獻的重要客戶的特徵，經過對其進行個性化服務，提升他們的忠誠度。

利用分類技術，能夠將大量的半結構化的文本數據，如 WEB 頁面、電子郵件等進行分類。能夠將圖片進行分類，例如，根據已有圖片的特色和類別，能夠斷定一幅圖片屬於何種類型的規則。對於空間數據，也能夠進行分類分析，例如，能夠根據房屋的地理位置決定房屋的檔次。

聚類分析

聚類分析是根據物以類聚的原理，將自己沒有類別的樣本彙集成不一樣的組，而且對每個這樣的組進行描述的過程。其主要依據是聚到同一個組中的樣本應該彼此類似，而屬於不一樣組的樣本應該足夠不類似。

仍以客戶關係管理爲例，利用聚類技術，根據客戶的我的特徵及消費數據，能夠將客戶羣體進行細分。例如，能夠獲得這樣的一個消費羣體：女性佔 91%，所有無子女、年齡在 31 歲到 40 歲佔 70%，高消費級別的佔 64%，買過針織品的佔 91%，買過廚房用品的佔 89%，買過園藝用品的佔 79%。針對不一樣的客戶羣，能夠實施不一樣的營銷和服務方式，從而提升客戶的滿意度。

對於空間數據，根據地理位置及障礙物的存在狀況能夠自動進行區域劃分。例如，根據分佈在不一樣地理位置的 ATM 機的狀況將居民進行區域劃分，根據這一信息，能夠有效地進行 ATM 機的設置規劃，避免浪費，同時也避免失掉每個商機。

對於文本數據，利用聚類技術能夠根據文檔的內容自動劃分類別，從而便於文本的檢索。

預測

預測與分類相似，但預測是根據樣本的已知特徵估算某個連續類型的變量的取值的過程，而分類則只是用於判別樣本所屬的離散類別而已。預測經常使用的技術是迴歸分析。

時間序列

分析時間序列分析的是隨時間而變化的事件序列，目的是預測將來發展趨勢，或者尋找

類似發展模式或者是發現週期性發展規律。

3.8.4 數據挖掘的流程

數據挖掘是指一個完整的過程，該過程從大型數據庫中挖掘先前未知的，有效的，可實用的信息，並使用這些信息作出決策或豐富知識。

數據挖掘環境示意圖如圖 3-13 所示。

數據挖掘的流程大體以下：

問題定義在開始數據挖掘以前，最早的也是最重要的要求就是熟悉背景知識，弄清用戶的需求。缺乏了背景知識，就不能明肯定義要解決的問題，就不能爲挖掘準備優質的數據，也很難正確地解釋獲得的結果。要想充分發揮數據挖掘的價值，必須對目標有一個清晰明確的定義，即決定到底想幹什麼。
1. 創建數據挖掘庫

要進行數據挖掘必須收集要挖掘的數據資源。通常建議把要挖掘的數據都收集到一個數據庫中，而不是採用原有的數據庫或數據倉庫。這是由於大部分狀況下須要修改要挖掘的數據，並且還會遇到採用外部數據的狀況；另外，數據挖掘還要對數據進行各類紛繁複雜的統計分析，而數據倉庫可能不支持這些數據結構。

分析數據

分析數據就是一般所進行的對數據深刻調查的過程。從數據集中找出規律和趨勢，用聚類分析區分類別，最終要達到的目的就是搞清楚多因素相互影響的、十分複雜的關係，發現因素之間的相關性。

調整數據

經過上述步驟的操做，對數據的狀態和趨勢有了進一步的瞭解，這時要儘量對問題解決的要求能進一步明確化、進一步量化。針對問題的需求對數據進行增刪，按照對整個數據挖掘過程的新認識組合或生成一個新的變量，以體現對狀態的有效描述。

模型化

在問題進一步明確，數據結構和內容進一步調整的基礎上，就能夠創建造成知識的模型。這一步是數據挖掘的核心環節，通常運用神經網絡、決策樹、數理統計、時間序列分析等方法來創建模型。

評價和解釋

上面獲得的模式模型，有多是沒有實際意義或沒有實用價值的，也有多是其不能準確反映數據的真實意義，甚至在某些狀況下是與事實相反的，所以須要評估，肯定哪些是有效的、有用的模式。評估的一種辦法是直接使用原先創建的挖掘數據庫中的數據來進行檢驗，另外一種辦法是另找一批數據並對其進行檢驗，再一種辦法是在實際運行的環境中取出新鮮數據進行檢驗。

數據挖掘過程的分步實現，不一樣的步驟須要不一樣專長的人員，他們大致能夠分爲三類。

（1）業務分析人員。要求精通業務，可以解釋業務對象，並根據各業務對象肯定出用於數據定義和挖掘算法的業務需求。

（2）數據分析人員。精通數據分析技術，並較熟練地掌握統計學，有能力把業務需求轉化爲數據挖掘的各步操做，併爲每步操做選擇合適的技術。

（3）數據管理人員。精通數據管理技術，並從數據庫或數據倉庫中收集數據。

由上可見，數據挖掘是一個多種專家合做的過程，也是一個在資金上和技術上高投入的過程。這一過程要反覆進行，在反覆過程當中，不斷地趨近事物的本質，不斷地優選問題的解決方案。

3.9 NoSQL

NoSQL 即 Not Only SQL，可直譯「不只僅是 SQL」，這項技術正在掀起一場全新的數據庫革命性運動。

在本章 3.2.2 節曾提到數據的模式包括多種類型，如層次模型、網狀模型、關係模型等，而在實際應用過程當中，幾乎都是在用關係模型，主流的數據庫系統都是關係型的。但隨着互聯網 web2.0 網站的興起，傳統的關係數據庫在應付 web2.0 網站，特別是超大規模和高併發的 SNS 類型的 web2.0 純動態網站已經顯得力不從心，暴露了不少難以克服的問題，而非關係型的數據庫則因爲其自己的特色獲得了很是迅速的發展。這也就使得 NoSQL 技術進入了人們的視野。

NoSQL 的出現打破了長久以來關係型數據庫與 ACID 理論大一統的局面。NoSQL 數據

存儲不須要固定的表結構，一般也不存在鏈接操做。在大數據存取上具有關係型數據庫沒法比擬的性能優點。

關係型數據庫中的表都是存儲一些格式化的數據結構，每一個元組字段的組成都同樣，即便不是每一個元組都須要全部的字段，但數據庫會爲每一個元組分配全部的字段，這樣的結構能夠便於表與表之間進行鏈接等操做，但從另外一個角度來講它也是關係型數據庫性能瓶頸的一個因素。而非關係型數據庫以鍵值對存儲，它的結構不固定，每個元組能夠有不同的字段，每一個元組能夠根據須要增長一些本身的鍵值對，這樣就不會侷限於固定的結構，能夠減小一些時間和空間的開銷。

與關係型數據庫相比，NoSQL 數據庫具備如下幾個優勢：

易擴展

NoSQL 數據庫種類繁多，可是一個共同的特色都是去掉關係數據庫的關係型特性。數據之間無關係，這樣就很是容易擴展。無形之間，在架構的層面上帶來了可擴展的能力。

大數據量，高性能

NoSQL 數據庫都具備很是高的讀寫性能，尤爲在大數據量下，一樣表現優秀。這得益於它的無關係性，數據庫的結構簡單。通常 MySQL 使用 Query Cache，每次表一更新 Cache 就失效，它是一種大粒度的 Cache，在針對 web2.0 的交互頻繁的應用，Cache 性能不高。而 NoSQL 的 Cache 是記錄級的，是一種細粒度的 Cache，因此 NoSQL 在這個層面上來講性能就高不少了。

靈活的數據模型

NoSQL 無須事先爲要存儲的數據創建字段，隨時能夠存儲自定義的數據格式。而在關係數據庫裏，增刪字段是一件很是麻煩的事情。若是是很是大數據量的表，增長字段簡直就是一個噩夢。這點在大數據量的 web2.0 時代尤爲明顯。

高可用

NoSQL 在不太影響性能的狀況，就能夠方便地實現高可用的架構。好比 Cassandra， HBase 模型，經過複製模型也能實現高可用。

固然，NoSQL 也存在不少缺點，例如，並未造成必定標準，各類產品層出不窮，內部混亂，各類項目還需時間來檢驗，缺少相關專家技術的支持等。

3.10 大數據

大數據（big data），指沒法在必定時間範圍內用常規軟件工具進行捕捉、管理和處理的數據集合，是須要新處理模式才能具備更強的決策力、洞察發現力和流程優化能力的海量、高增加率和多樣化的信息資產。

大數據的特色

業界一般用 4 個 V(即 Volume、Variety、Value、Velocity)來歸納大數據的特徵。

Volume：指的是數據體量巨大，從 TB 級別躍升到 PB 級別（1PB=1024TB）、EB 級別

（1EB=1024PB），甚至於達到 ZB 級別（1ZB=1024EB）。截至目前，人類生產的全部印刷材料的數據量是 200PB，而歷史上全人類說過的全部話的數據量大約是 5EB。當前，典型我的計算機硬盤的容量爲 TB 量級，而一些大企業的數據量已經接近 EB 量級。

例如，在交通領域，某市交通智能化分析平臺數據來自路網攝像頭/傳感器、公交、軌道交通、出租車以及省際客運、旅遊、化危運輸、停車、租車等運輸行業，還有問卷調查和地理信息系統數據。4 萬輛車天天產生 2000 萬條記錄，交通卡刷卡記錄天天 1900

萬條，手機定位數據天天 1800 萬條，出租車運營數據天天 100 萬條，電子停車收費系統

數據天天 50 萬條，按期調查覆蓋 8 萬戶家庭等，這些數據在體量上就達到了大數據的規模。

Variety：指的是數據類型繁多。這種類型的多樣性也讓數據被分爲結構化數據和非結構化數據。相對於以往便於存儲的以文本爲主的結構化數據，非結構化數據愈來愈多，包括網絡日誌、音頻、視頻、圖片、地理位置信息等，這些多類型的數據對數據的處理能力提出了更高要求。

Value：指的是價值密度低。價值密度的高低與數據總量的大小成反比。以視頻爲例，一部 1 小時的視頻，在連續不間斷的監控中，有用數據可能僅有 1-2 秒。如何經過強大的機器算法更迅速地完成數據的價值「提純」成爲目前大數據背景下亟待解決的難題。固然把數據集成在一塊兒，並完成「提純」是能達到 1+1 大於 2 的效果的，這也正是大數據技術的核心價值之一。

Velocity：指的是處理速度快。這是大數據區分於傳統數據挖掘的最顯著特徵。根據 IDC 的「數字宇宙」的報告，預計到 2020 年，全球數據使用量將達到 35.2ZB。在如此海量的數據面前，處理數據的效率就是企業的生命。