資料庫系統概念筆記-引言

 資料庫管理系統（DBMS）由一個互相關聯的數據的集合和一組用以訪問這些數據的程式組成。這個數據集合通常稱作資料庫，其中包含了關於某個企業的信息。

  DBMS的主要目標是要提供一種可以方便、高效地存取資料庫信息的途徑。

1.1 數據視圖

1.1.1 數據抽象

 一個可用的系統必須能高效地檢索數據。這種高效性的需求促使設計者在資料庫中使用了複雜的數據結構來表示數據，但是，有很多資料庫用戶不懂這些。為此，資料庫的系統開發人員通過如下幾個層次上的抽象來對用戶屏蔽複雜性，以簡化用戶與系統的交互：

• 物理層  最低層次的抽象。描述數據實際上是怎樣存儲的，詳細描述複雜的底層數據結構；
• 邏輯層  比物理層稍高的抽象，描述資料庫中存儲什麼及這些數據間存在什麼關係。邏輯層的用戶不必知道物理層的複雜性，這稱作物理數據獨立性；
• 視圖層  最高層次的抽象，只描述整個資料庫的某個部分

 我們可以用程式設計語言的數據類型進行表達以上三層數據抽象：

type instructor = record
  ID:        char(5),
  name:      char(20),
  dept_name: char(20),
  salary:    numeric(8,2)
end;

 以上代碼定義了一個具有4個欄位的新記錄instructor。每個欄位有一個欄位名和所屬類型。對一個大學來說，可能包括幾個這樣的記錄類型：

1. department，包含欄位dept_name, building, budget
2. course，包含欄位course_id, title, dept_name, credits
3. students，包含欄位ID, name, dept_name, tot_cred

 在物理層，以上3個記錄可能被描述為連續存儲位置組成的存儲塊，不過，這些記錄是怎樣存儲的複雜細節都被資料庫的編譯器屏蔽了，使用資料庫的程式設計人員不需要理解這麼複雜的東西。

 在邏輯層，只需要關心存儲什麼，開發人員先定義記錄類型，以後就可以進行記錄的增加、更新、刪除、檢索，開發人員不需要關心數據是如何存儲的。

 在視圖層，連記錄的類型都被屏蔽了，資料庫只向用戶提供了某一部分數據。例如，大學註冊辦公室的職員只能看見資料庫中關於學生的那部分信息，而不能訪問涉及教師工資的信息。

1.1.2 實例和模式

 因為隨著事件的推移，資料庫會發生增刪改，資料庫會發生改變。特定時刻存儲在資料庫中的信息的集合就稱作資料庫的一個實例，而資料庫的總體設計就稱作資料庫模式。這裡要註意，資料庫昨天的實例和今天的實例可能是不一樣的。

 資料庫系統還可以分為幾種不同的模式：物理模式在物理層描述資料庫的設計；邏輯模式則在邏輯層描述資料庫設計；在視圖層的模式可稱為子模式。

 用類比來形象介紹實例和模式。在咱地球上，存在人這種類型，人又可以分為亞洲人、歐洲人、非洲人、美洲人等，其中亞洲人又可以分為中國人、日本人、越南人等，其中中國人又可以分為北京人、河北人、河南人等，以此類推，細分下去，還可以分出哪個鄉村的人，比如小明的戶籍是亞洲的某個某市某鎮某縣，我們還會發現童年時、成年時、老年時的小明又是大不一樣的。類比起來，這裡模式相當於類型，而實例相當於某個時刻具體的東西。比如，模式可相當於亞洲人，中國人，北京人，某個鄉村的人，實例相當於某個時刻的小明，其實，實例也不僅僅是一個人，將中國人視作一個群體，則實例也可以相當於某個時刻的中國人。

1.1.3 數據模型

 資料庫結構的基礎是數據模型。數據模型是一個描述數據，數據聯繫，數據語義以及一致性約束的概念工具的集合。數據模型提供了一種描述物理層、邏輯層以及視圖層的資料庫設計方式。

 主要有4種數據模型：

• 關係模型
• 實體-聯繫模型
• 基於對象的數據模型
• 半結構化的數據模型

1.2 資料庫語言

 最常見的資料庫語言是SQL了，SQL語言可以分出數據定義語言（DDL）和數據操縱語言（DML），其中DDL用來定義資料庫模式，DML用來表達資料庫的查詢和更新。

 1.2.1 數據操縱語言

 數據操縱語言（DML）是這樣一種語言，它使得用戶可以訪問或操縱那些按照某種適當的數據模型組織起來的數據，有以下訪問類型：

• query    對存儲在資料庫中的信息進行檢索
• insert    向資料庫中插入新的信息
• delete   從資料庫中刪除信息
• update  修改資料庫中存儲的信息

 其中查詢是要求對信息進行檢索的語句，DML中涉及信息檢索的部分稱作查詢語言。

1.2.2 數據定義語言

 資料庫模式是通過一系列定義來說明的，這些定義由一種數據定義語言（DDL）的特殊語言來表達。

 存儲在資料庫中的數據值必須滿足某些一致性約束。例如，假設大學要求一個系的賬戶餘額必須不能為負值。DDL語言提供了指定這種約束的工具。每當資料庫被更新時，資料庫系統都會檢查這些約束。通常，約束可以是關於資料庫的任意謂詞。資料庫系統實現可以以最小代價測試完整性約束。

• 域約束。就是範圍檢查，比如學生成績的範圍只能是0到100分。
• 參照完整性。比如，一個course記錄中的dept_name值必須出現在department關係中的某個記錄的dept_name屬性中，我們不希望有人把course記錄的dept_name隨便改成一個不存在的值
• 斷言。一個斷言就是資料庫需要時刻滿足的某一條件。例如，“每一學期每一個系必須至少開設5門課程”，必須表達成一個斷言。斷言創建以後，系統會檢測其有效性。如果斷言有效，則以後只有不破壞斷言的資料庫更新才被允許。
• 授權。用戶對資料庫的操作許可權有讀許可權、插入許可權、刪除許可權、修改許可權，有有些用戶應該只擁有讀許可權，我們就可以只對其授權讀許可權。

 DDL以一些指令作為輸入，生成一些輸出。DDL的輸出放在數據字典中，數據欄位包含了元數據，元數據是關於數據的數據。可把數據字典看作一種特殊的表，這種表只能由資料庫系統本身（不是常規的用戶）來訪問和修改。在讀取和修改實際的數據前，資料庫系統先要參考數據字典。

1.3 關係資料庫

 關係資料庫基於關係模型，使用一系列的表來表達數據以及這些數據之間的聯繫。

1.3.1 表

 每個表有多個列，每個列有唯一的名字，以下表格展示了一個關係資料庫的示例。

第一個表是instructor表，例如，ID為22222的名叫Einstein的教師是物理系的成員，他的年薪為95 000美元。第二個表是department表，例如，生物系在Waston大樓，經費預算為90 000美元。

 關係模型是基於記錄的模型的一個實例。基於記錄的模型，之所有由此稱謂，是因為資料庫的結構是幾種固定格式的記錄。每個表包含一種特定類型的記錄。每種定義固定數目的欄位或屬性。表的列對應記錄的屬性。

1.3.2 數據操縱語言

 下麵是一個SQL查詢的例子，它找出歷史系的所有教員的名字：

SELECT instructor.name
FROM instructor
WHERE instructor.dept_name = "History";

 這個查詢指定了從instructor表中要取回的是dept_name為History的那些行，並且這些行的name屬性要顯示出來。更具體點，執行本查詢的結果就是一個表，它有一列name和若幹行，每一行都是dept_name為History的一個教員的名字。

 查詢還可以涉及來自不止一個表的信息。例如，下麵的查詢將找出與經費預算超過95 000美元的系相關聯的所有教員的ID和系名：

SELECT instructor.ID, department.dept_name
FROM instructor, department
WHERE instructor.dept_name = department.dept_name AND
  department.budget > 95000;

 結果將是一張表，這個表有兩列和若幹行。

 1.3.3 數據定義語言

 通過DDL語言，我們可以定義表、完整性約束、斷言，等等。

 例如，以下的SQL DDL語句定義了department表：

CREATE TABLE department
(
  dept_name char(20),
  building  char(15),
  budget    numeric(12,2)
);

 上面的DDL語句執行的結果就是創建了department表，該表有3個列：dept_name、building 和 budget，每個列有一個與之相關的數據類型。

1.4 資料庫設計

 資料庫系統被設計用來管理大量信息。資料庫設計的主要內容是資料庫模式的設計。

1.4.1 設計過程

 第一步，全面刻畫預期的資料庫用戶的數據需求，制定出用戶需求的規格文檔；

 第二步，選擇一個數據模型，並運用該選定的數據模型的概念，將那些需求轉換成一個資料庫的概念模型。在這個概念設計階段開發出來的模式提供了企業的詳細概述，重點是描述數據以及它們之間的聯繫，而不是指定的物理存儲細節；

    從關係模型的角度來看，概念設計階段涉及決定資料庫應該包括哪些屬性，以及如何將這些屬性組織到多個表中。前者基本上是商業的決策，而後者主要是電腦科學的問題，解決這個問題主要有兩種方法：一種是使用實體-聯繫模型，另一種是引入一套演算法，這套演算法將所有的屬性集作為輸入，生成一組關係表；

    一個開發完全的概念模式還將指出企業的功能需求。在功能需求說明中，用戶描述數據之上的各種操作，例如更新數據、檢索特定的數據、刪除數據等。

 第三步，邏輯設計階段，設計者將高層的概念模式映射到要使用的資料庫系統的實現模型上；

 第四步，物理設計階段，上一步設計者將得到的特定於系統的資料庫模式用到本階段中，此階段指定資料庫的物理特性，這些特性包括文件組織的形式以及內部的存儲結構。

1.4.2 大學機構的資料庫設計

 在需求分析階段中的需求描述是制定資料庫的概念結構的基礎。以下是大學的主要特性：

• 大學分成多個系。每個系由自己的名字（dept_name）來標識，坐落在特定的建築物（building）中，有它的經費預算（budget）；
• 每個系有一個開設課程列表。沒門課程有課程號（course_id）、課程名（title）、系名（dept_name）和學分（credits），還可能有先修要求（prerequisites）；
• 教師由個人唯一的標識號（ID）來標識。每位教師有姓名（name），所在的系（dept_name）和工資（salary）；
• 學生由個人唯一的標識號（ID）來標識。每位學生有姓名（name）、主修的系（dept_name）和已修學分數（tot_cred）；
• 大學維護一個教室列表，詳細說明樓名（building）、房間號（room_number）和容量（capacity）；
• 大學維護開設的所有課程（開課）的列表。每次開課由課程號（course_id）、開課號（sec_id）、年（year）和學期（semester）來標識，與之相關的有學期；（semester）、年（year）、樓名（building）、房間號（room_number）和時段號（time_slot_id，即上課的時間）；
• 系有一個教學任務列表，說明每位教師的授課情況；
• 大學有一個所有學生課程註冊的列表，說明每位學生在哪些課程的哪次開課中註冊了。

1.4.3 實體-聯繫模型

 實體-聯繫（E-R）數據模型使用一組稱作實體的基本對象，以及這些對象間的聯繫。實體是現實世界中可區別於其他對象的一件“事情”或一個“物體”。例如，每個人是一個實體，每個銀行賬戶也是一個實體。

 資料庫中實體通過屬性集合來描述。例如，屬性dept_name、building 與 budget可以描述大學中的一個系，並且它們組成了 department 實體集的屬性。

 聯繫是幾個實體之間的關聯。例如，member 聯繫將一位教師和她所在的系關聯在一起。同一類型的所有實體的集合稱作實體集，同一類型的所有聯繫的集合稱作聯繫集。

 資料庫的總體邏輯結構（模式）可以用實體-聯繫圖進行圖形化標識。最常用的畫圖方法是採用同一建模語言（UML）。在我們使用的基於UML符號中，E-R圖如下表示：

• 實體集用矩形標識，實體名在頭部，屬性名列在下麵；
• 聯繫集用連接一對相關的實體集的菱形表示，聯繫名放在菱形內部。

 除了實體和聯繫外，E-R模型還描繪了資料庫必須遵守的對其內容的某些約束。一個重要的約束是映射基數，它標識通過某個聯繫集能與一實體進行關聯的實體數目。例如，如果一位教師只能屬於一個系，E-R模型就能表達出這種約束。

1.5 數據存儲和查詢

1.5.1 存儲管理器

 存儲管理器是資料庫系統中負責在資料庫中存儲的低層數據與應用程式以及向系統提交的查詢之間提供介面的部件。存儲管理器負責與文件管理器進行交互。原始數據通過操作系統提供的文件系統存儲在磁碟上。存儲管理器將各種DML語句翻譯成為底層文件系統命令。因此，存儲管理器負責資料庫中數據的存儲、檢索和更新。

 存儲管理部件包括：

• 許可權及完整性管理器，它檢測是否滿足完整性約束，並檢查試圖訪問數據的用戶的許可權；
• 事務管理器，它保證即使發生了故障，資料庫也保持在一致（正確）的狀態，並保證併發事務的執行不發生衝突；
• 文件管理器，它管理磁碟存儲空間的分配，管理用於標識磁碟上所存儲信息的數據結構；
• 緩衝區管理器，它負責將數據從磁碟上取到記憶體中來，並決定哪些數據應被緩衝存儲在記憶體中。

 存儲管理器實現了幾種數據結構，作為系統物理實現的一部分：

• 數據文件，存儲資料庫自身；
• 數據字典，存儲關於資料庫結構的元數據，尤其是資料庫模式；
• 索引，提供對數據項的快速訪問。

1.5.2 查詢處理器

 查詢處理器組件包括：

• DDL解釋器，它解釋DDL語句並將這些定義記錄在數據字典中；
• DML編譯器，將查詢語言中的DML語句翻譯為一個執行方案，包括一系列查詢執行引擎能理解的低級指令
• 查詢執行引擎，執行由DML編譯器產生的低級指令。

1.6 事務管理

 通常，對資料庫的幾個操作合起來就可以形成一個邏輯單元，稱作事務。比如資金轉賬，其中一個系（A系）的賬戶進行取出操作，而另一個系（B系）的賬戶進行存入操作。顯然，這兩個操作必須保證要麼都發生要麼都不發生。這種要麼都發生要麼都不發生的要求稱為原子性。除此之外，資金轉賬還必須保持資料庫的一致性。也就是說，A和B的餘額之和應該是保持不變的。這種正確性的要求稱作一致性。最後，當資金轉賬成功結束後，即使發生了系統故障，賬戶A和賬戶B的餘額也應該保持轉賬成功結束後的新值，這種保持的要求稱作持久性。

1.7 資料庫體繫結構

 現在我們可以給出一個資料庫系統各個部分以及它們之間聯繫的圖了。

 資料庫系統的體繫結構很大程度上取決於資料庫系統所運行的電腦系統。資料庫系統可以是集中式的、客戶/伺服器式的；也可以使針對並行電腦體繫結構設計資料庫系統；分散式資料庫包含地理上分離的多台電腦。

 資料庫應用通常分為兩或三部分，如下圖所示，在一個兩層體繫結構中，應用程式駐留在客戶機上，通過查詢語言表達式來調用伺服器上的資料庫系統功能，像ODBS和JDBC這樣的應用程式介面標準被用於進行客戶端和伺服器的交互。

 而在一個三層體繫結構中，客戶機只作為一個前端並且不包含任何直接的資料庫調用。客戶端通常通過一個表單界面與應用伺服器進行通信。而應用伺服器與資料庫系統通信以訪問數據。應用程式的業務邏輯，也就是說在何種條件下做出何種反應，被嵌入到應用伺服器中，而不是分佈在多個客戶機上。

                                   系統體繫結構圖

                                                          兩層和三層體繫結構圖

1.8 數據挖掘與信息檢索

 數據挖掘指的是半自動地分析大型資料庫並從中找出有用的模式的過程。和人工智慧中的知識發現（也稱為機器學習）或者統計分析一樣，數據挖掘試圖從數據中尋找規則或模式。但是，數據挖掘和機器學習、統計分析不一樣的地方在於它處理大量的主要存儲在磁碟上的數據。也就是說，數據挖掘就是在資料庫中發現知識。

 文本數據也爆炸式增長。文本數據是非結構化的，與關係資料庫中嚴格的結構化數據不同。查詢非結構化的文本數據被稱為信息檢索。信息檢索系統和資料庫系統很大程度上是相同的——特別是基於輔助存儲器的數據存儲和檢索。但是信息系統領域與資料庫系統所強調的重點是不同的，信息系統重點強調基於關鍵詞的查詢，文檔與查詢的相似度，以及文檔的分析、分類和索引。

1.9 資料庫用戶和管理員

使用 資料庫的人員可分為資料庫用戶和資料庫管理員。

1.9.1 資料庫用戶和用戶界面

 根據所期望的與系統交互方式的不同，資料庫系統的用戶可以分為四種不同類型。系統為不同類型的用戶設計了不同的用戶界面。

• 無經驗的用戶是預設經驗的用戶，他們通過激活事先已經寫好的應用程式同系統進行交互。此類用戶的典型用戶界面是表格界面，用戶只需要填寫表格的相應項就可以了。無經驗的用戶也可以很簡單地閱讀資料庫產生的報表。考慮一個學生，他在課程註冊的過程中想通過Web界面來註冊一門課程。應用程式首先驗證該用戶的身份，然後允許他去訪問一個表格，他可以在表格中填入想填的信息。表格信息被送回給伺服器上的Web應用程式，然後應用程式確定該課程是否還有空額，如果有，就把這位學生的信息添加到資料庫中的該課程花名冊中。
• 應用程式員是編寫應用程式的電腦專業人員。此類用戶甚至可以直接用資料庫客戶端登錄資料庫，隨意地增刪改查數據。
• 老練的用戶不通過編寫程式來同系統交互，而是用資料庫查詢語言或數據分析軟體這樣的工具來表達他們的要求。分析員通過提交查詢來研究資料庫中的數據，所以屬於這一類用戶。
• 專門的用戶是編寫專門的不適合於傳統數據處理框架的資料庫應用的富有經驗的用戶。這樣的應用包括：計算你輔助設計系統、知識庫和專家系統。

1.9.2 資料庫管理員

使用DBMS的一個主要原因是可以對數據和訪問這些數據的程式進行集中控制。對系統進行集中控制的人稱作資料庫管理員（DataBase Administrator, DBA）。DBA的作用包括：

• 模式定義
• 存儲結構及存取方法定義
• 模式及物理組織的修改
• 數據訪問授權
• 日常維護