資料庫系統原理

FUNDAMENTALS Of DATABASE Systems

－Third Edition

Ramez Elmasri

Shamkant B. Navathe 著

藍㆗賢、吳郁瑩、 李火山、陳銘智 譯

資料庫系統原理

資料庫和資料庫系統已經成為現代社會日常生活不可或缺的要素，在一天例行 的生活中，大部分的人就會遇到很多和資料庫交談的活動，例如到銀行去存款 或提款，想訂旅館或是預訂機位，使用一個電腦化的圖書館目錄尋找書目，或 者是向出版社訂閱雜誌，我們的日常生活活動都有機會牽扯到一些資料庫的存 取，甚至現今我們從超級市場買東西時，都會為了維持超市存貨清單而做資料 庫的自動更新。

上面這些互動就是所謂的傳統資料庫應用的例子，裡面大部分存取的資訊不是 文字就是數字，在過去幾年中，先進的技術已經引領出令人興奮的新資料庫系 統 應 用， 多媒 體 資料 庫現 在 可以 儲存 圖 片、 影片 和 聲音 訊息 ， 地理 資訊 系統

（GIS）能儲存和分析地圖、天氣資料和衛星影像。資料倉儲和線上分析處理系 統〈OLAP〉則是很多公司用來從大型資料庫提取和分析有用資訊以供決策之 用，即時和主動資料庫技術則使用於控制工業和製造程序，資料庫搜尋技術已 被應用於全球資訊網，其可用來改善使用者從網際網路搜尋所需資訊的效率。

想了解資料庫技術的原理，我們必須從傳統資料庫應用的基礎開始，所以在這 一 章 1.1 節 我 們 定 義 什 麼 是 資 料 庫 ? 以 及 定 義 了 其 他 基 本 術 語 。 在 1.2 節

CHAPTER

1 資料庫和資料的使用者

提供了一個叫 UNIVERSITY 的簡易資料庫例子來說明我們的討論，1.3 節描述 一些資料庫系統的主要特性。

然後在 1.4 與 1.5 節裡，將使用資料庫系統以及與資料庫系統交談的人，依照其 工作性質來分類。在 1.6、1.7 和 1.8 節裡提供了更完整的討論，其內容是資料 庫系統所提供的各種功能，與使用資料庫方法時所得到的一些隱含的好處。1.9 節是本章的摘要。

對於資料庫系統只想看快速簡介的讀者可以研讀1.1 節到 1.5 節，然後略過或只 瀏覽1.6 節到 1.8 節，接著繼續研讀第 2 章。

1.1 簡介

對於成長中的電腦應用來說，資料庫與資料庫技術有其重大的衝擊。我們可以 說，幾乎只要用到電腦的領域，包括商業、工程、醫學、法律、教育和圖書科 學等等，資料庫都扮演著一個關鍵的角色。資料庫這個字眼實在太普遍了，所 以我們必須先定義資料庫。我們最初的定義是相當的籠統。

資料庫（database）是相關資料的集合 ¹。藉由資料（data），我們能得知所 記錄下來的事情及它隱含的意義。舉例來說，考慮你所認識的人的姓名、電話 號碼、地址。你可能已經將這些資料記載在有索引的通訊錄裏，或者用個人電 腦和 DBASE IV、DBASE V、Microsoft ACCESS、EXCEL 等軟體存在磁片 裡。這就是一個具有隱含意義的相關資料集合，因此是一個資料庫。

前面對於資料庫的定義相當的籠統；舉例來說，我們也可以把組成這一頁的單 字集合起來，作為相關資料，構成一個資料庫。不過，通常資料庫這個術語的 條件限制較多。一個資料庫會隱含有以下幾種特性：

1 我們將在單數與多數㆗使用字詞資料，在資料庫㆗是普遍的；無論是單數或多數文章將決定 之。在標準英語㆗，資料(data)是多數的；而(datum) 是單數的。

資 料 庫 代 表 真 實 世 界 裡 的 某 一 方 面 ， 有 時 我 們 將 之 稱 為 迷 你 世 界

（miniworld）或論域（Universe of Discourse，簡稱 UoD）。迷你世 界的改變會反應在資料庫上。

就理論上來說，資料庫與資料的集合，在原義上是相連貫的。隨機抽取 任何一類的資料，並不能稱為一個資料庫。

資料庫是為了特定目的而設計、建立並塞入資料。它有一群預定的使用 者，以及這些使用者所感興趣的一些預想的應用程式。

換 句 話說 ，一 個 資料 庫的 資 料來 源是 從 衍生 的資 料 得來 的， 並 且在 真實 世界 裡，它與事件以及對資料庫內容很有興趣的使用者有某種程度的互動。

資料庫可以是任意大小和多樣的複雜度。舉例來說，前面提到的姓名與地址，

可能僅僅只有幾百筆記錄 (record)，每一筆記錄有簡單的結構。另一方面，一 個以卡片記錄的大型圖書館可能就有五十萬張書卡放在不同的目錄，主要以作 者的姓氏、主題、書名來區分各個目錄，每個圖書目錄再分別按照字母的順序 編排。而美國國稅局（Internal Revenue Service）所維護的資料庫則更大更複 雜，記錄所有納稅人所填的稅單。假設有一億個納稅人，平均每個納稅人檔案 有五個表單，每個表單大約有兩百個字元的資訊，所以我們就必須要有一個能 夠容納 100*（10⁶）*200*5 個字元（位元組，bytes）的資料庫。假設 IRS 保 存了之前三份的納稅人表單，並加上目前的表單，因此我們需要一個大小為 4*

（10¹¹） Bytes (400 gigabyte)的資料庫。這些大量的資料必須要加以組織與 管理，如此使用者才能在需要時做搜尋、檢索與更新資料。

資料庫可以由人工或電腦化來產生和維護，圖書館的書卡目錄資料庫就是一個 用 人 工來 建立 及 維護 的例 子 。電 腦化 的 資料 庫可 以 有為 其特 別 設計 的應 用程 式，或是資料庫管理系統來建立及維護資料庫。

資料庫管理系統（DBMS）是許多程式的集合，它讓使用者有能力去建立與維 護資料庫。因此 DBMS 是一種一般用途的軟體系統，以便於各種應用程式定 義、建構、與處理資料庫。定義（defining）資料庫是指定欲儲存在資料庫裡的

資料的資料型態、結構與限制等。建構（constructing）資料庫則是在 DBMS 的控制下，將資料本身存到儲存媒體上的過程。處理（manipulating）資料庫 包括查詢資料庫以取回特定的資料、更新資料庫以反應迷你世界的改變，以及 由資料產生報表等諸如此類的函數。

使用一般用途的 DBMS 軟體來實作電腦化資料庫並非絕對必要的。我們可以自 己寫程式組來建立與維護資料庫，事實上我們可以建立自己特訂用途的 DBMS 軟體。在這兩種情況下，不管我們是否使用一般用途的 DBMS 軟體，除了資料 庫本身以外，通常我們都得使用一個相當重要的軟體來處理資料庫。我們稱資 料庫與這個軟體合稱為資料庫系統（database system）。 圖 1.1 說明了這些 觀念。

圖1.1 簡單的資料庫系統環境，圖例說明第 1.1 節的概念與技術

Application Programs/Queries

Software to Process Queries/Programs

Software to Access Stored Data Users/Programmers

DATBASE SYSTEM

DBMS SOFTWARE

Stored Database Definition (Meta-Data)

Stored Database

1.2 範例

讓我們來看大部分讀者可能都熟悉的例子，一個在大學環境中用來維護有關學 生、課程、和成績相關資訊的 UNIVERSITY 資料庫，圖 1.2 呈現出資料庫結構 和資料庫的一些資料範例，這個資料庫是由五個檔案所組成起來的，每個檔案 都 用 相 同 的 型 態 來 儲 存 資 料 記 錄 ²，STUDENT 檔 存 每 個 學 生 的 資 料 ， COURSE 檔 存 每 門 課 程 的 資 料 ， SECTION 檔 存 每 個 學 期 課 程 的 資 料 ， GRADE_REPORT 檔 存 每 個 學 生 在 不 同 學 期 修 完 該 課 程 的 成 績 資 料 ， PREREQUISITE 檔則存每個課程的先修課程資料。

STUDEN Name StudentNumber Class Major Smith 17 1 CS Brown 8 2 CS

COURSE CourseName CourseNumber CreditHoure Department Intro to Comprter CS1310 4 CS

Data Structures CS3320 4 CS Discrete Mathematics MATH2410 3 MATH Database CS3380 3 CS

SECTION Sectionldentifier CourseNumber Semester Year Instructor 85 MATH2410 Fall 98 King 92 CS1310 Fall 98 Anderson 102 CS3320 Spring 99 Knuth 112 MATH2410 Fall 99 Chang 119 CS1310 Fall 99 Anderson 135 CS3380 Fall 99 Stone

2 在概念層，檔案(file)是排序或未排序記錄的收集區。

GRADE_REPORT StudentNumber Sectionldentifier Grade

17 112 B

17 119 C

8 85 A

8 92 A

8 102 B

8 135 A

PREREOUISITE CourseNumber PrerequisiteNumber CS3380 CS3320 CS3380 MATH2410 CS3320 CS1310

圖 1.2 一個資料庫儲存學生記錄與成績的例子

要定義這樣的資料庫，我們必須指定每個檔案記錄的結構，以不同型態的資料 元素（data element）儲存在每個記錄裏，在圖 1.2 中，每一筆 STUDENT 記 錄 包 括 了 代 表 學 生 的 姓 名 （Name ） 、 學 號 （ StudentNumber ） 、 年 級

（Class：freshman 或 1，sophomore 或 2，…）及主修（Major：MATH，

computer science、或 CS，…）的資料；每一筆 COURSE 記錄包括了代表課 程 名 稱 （CourseName ） 、 課 程 代 碼 （ CourseNumber ） 、 每 週 上 課 時 數

（CreditHours）和系所（Department：提供此課程的系所）的資料；以此類 推。我們也必須在記錄裏替每個資料元素指定一個資料型態（data type）。例 如，我們可以將 STUDENT 中的 Name 指定為一個由英文字母組成的字串，

STUDENT 的 CourseNumber 指定為整數，GRADE_REPORT 的 Grade 指定 為集合｛A，B，C，D，F，I｝裡的其中一個字元。我們也可以用一種編碼方式 來表示一個資料項。例如，在圖 1.2 中，我們以１來代表大一、２代表大二、

３ 代 表 大 三 、 ４ 代 表 大 四 、 ５ 代 表 研 究 所 學 生 的 方 式 來 表 示 STUDENT 的 Class。

要建構 UNIVERSITY 這個資料庫，我們得先將一些代表每個學生、每節課程、

每 學 期課 程、 成 績報 表以 及 先修 課程 等 的資 料， 儲 存到 適當 的 檔案 裡。 請注 意，不同檔案的記錄，都可能跟其他檔案裡的記錄相關。例如，在 STUDENT

檔裡的 Smith 這筆記錄，就與在 GRADE_REPORT 中兩筆 Smith 修課成績的 記錄相關。同樣的，在 PREREQUISITE 檔案裡的每一筆記錄都與兩筆課程記 錄有關：一個代表該課程，另一個則代表修課前必須預先修過的課程。大多數 中大型的資料庫都包含了多種記錄，而且記錄之間也存在著許多的關係。

資料庫的處理包含了查詢與更新。查詢的範例有：「取得 Smith 的成績單【所 有課程與成績的列表】」；列出 1999 秋季有修過資料庫課程的學生姓名和成 績；「資料庫的先修課程是什麼？」。更新的範例則有：「將 Smith 的班級改 成 Sophomore」；「在這學期建立一門新的課程」；「把上學期 Smith 的資料 庫課程的成績輸入為 A」。這些日常用的查詢與更新，都必須在資料庫系統語 言處理前，就預先正確的指定好才行。

1.3 資料庫方法的特徵

資料庫方法的一些特徵有別於以程式處理檔案的方法。在傳統的檔案處理(file processing)上，每個使用者所定義與實作的檔案都是特定應用所需的。例如，

有個使用者為註冊組，它保存了學生成績的檔案，同時實作一些程式以便列印 學生成績單並且把新的成績輸入到檔案裡。第二個使用者為出納組，它記錄了 學生支出的費用與他們繳的學費。雖然兩個使用者都對學生的資料有興趣，但 是卻各自持有不同的檔案與處理這些檔案的程式，因為他們所需的資料檔案並 不是從其他使用者取得。這種定義與儲存資料的重複性導致儲存空間的浪費，

以及在共同資料更新上耗費多餘的勞力。

在資料庫的方法中，只需維護一個定義過一次就可讓不同的使用者來存取的資 料倉庫。就資料庫的方法與傳統的方法來比較，有下列幾種主要的特徵。

1.3.1 資料庫系統的自我描述特性

資料庫方法的基本特徵是：資料庫系統不但包含了資料庫本身，同時也包含了 完整的資料庫定義或描述。這定義儲存在系統目錄(system catalog)裡，其中包

含像是每個檔案的結構、資料項的儲存格式與型態、各種不同資料的限制等資 訊。儲存在目錄裡的資訊稱之為中繼資料(meta-data)，它描述主要資料庫的結 構如圖 1.1。

目錄是給 DBMS 軟體用的，使用者若需要資料庫結構的資訊時，也會用到它。

一般DBMS 套裝軟體不是為任何指定資料庫應用程式所寫的，所以 DBMS 軟體 一定要引用目錄，才能知道特定資料庫的檔案結構，像是它將要存取的資料型 態與格式(format)。無論是哪一個資料庫的應用，譬如大學的資料庫、銀行的資 料庫、或公司的資料庫，只要把資料庫的定義儲存在目錄裡，DBMS 軟體都能 運作得很好。

傳統的檔案處理，資料定義代表應用程式本身的一部份。因此，這些程式被限 制只能與一個特定資料庫一起運作，這個特定資料庫的結構必須在應用程式裡 宣告。例如，PASCAL 程式可能用 record 來宣告資料庫結構；C++的程式可能 用struct 或 class 來宣告；而 COBOL 程式可用 Data Division 敘述來定義他的 檔案。然而，檔案處理軟體程式只能存取特定資料庫，而 DBMS 軟體藉由目錄 裡取出資料庫的定義，使用這些定義，來存取不同的資料庫。

如圖 1.2 的範例所示，DBMS 儲存了目錄裡所有檔案的定義。只要有存取需求 產生，比方說存取 STUDENT 的 Name 的話，DBMS 軟體就會參考目錄以決定 STUDENT 檔案的結構，以及在 STUDENT 記錄裡 Name 資料項的位置與大 小。相反的，典型的檔案處理應用程式、檔案結構，每個存取資料項的程式的 程式碼還得含有STUDENT 記錄裡 Name 欄位的正確位置。

1.3.2 程式與資料間的獨立性，及資料抽象化

傳統的檔案處理，資料檔案的結構內嵌在存取程式裡，檔案結構若是有任何改 變的話，就得改變所有存取這個檔案的程式。反之，DBMS 存取程式在大部分 情況下並不需要做這樣的改變。資料檔案的結構儲存在 DBMS 目錄裡和存取程 式是隔離的。我們稱這種特性為程式資料獨立(program-data independence)，

例如，某個檔案存取程式寫成只能存取如圖 1.3 所示 STUDENT 記錄的結構。

假如我們想在每個記錄中加入另一欄資料，如 Birthdate，這樣的程式可能就沒 辦法執行，必須做修改才行。相較之下，在 DBMS 的環境下，我們只需改變目 錄中 STUDENT 記錄裡的描述反應出包含新資料項 Birthdate 即可；不需改變 任何程式。下一次 DBMS 程式參考目錄時，記錄的新結構就能存取及使用了。

在物件導向(object-oriented)與物件關聯(object-relational)資料庫裏(參閱第 3 篇)，使用者可定義資料的操作成資料庫定義的一部份。操作(Operation)又稱為 函數(function))可分成兩部份。操作介面(Operation Interface)(或 signature)包 括操作名稱(Operation Name)與其引數(或參數)的資料型態。

資料項目名稱 在記錄㆗的起始位置 長度(以字元或位元組為單位)

Name 1 30

StudentNumber 31 4

Class 35 4

Major 39 4

圖 1.3 STUDENT 記錄的儲存格式

這種操作的實作(或 method)是分開來指定的，而且能在不影響介面的情況下有 所變動。使用者應用程式經由操作名稱和引數(argument)來呼叫這些操作，而 不管這些操作如何實作出來，使用者應用程式就可以操作這些資料。這可稱為 程式操作獨立(program-operation independence)。

這種讓程式資料(program-data)獨立和程式操作(program-operation)獨立的特 性稱為資料抽象化(data abstraction)。DBMS 提供使用者並沒有包括資料是如 何 儲 存 的 細 節 或 是 操 作 是 如 何 實 作 出 來 的 資 料 概 念 表 徵(conceptual representation)，通常，資料模型(data model)提供這種概念表徵(conceptual representation)的資料抽象化型態。資料模型(data model)使用了邏輯概念，

如物件、屬性、與其相互關係，比起電腦儲存概念來說，這可能較容易為大多 數使用者所瞭解。因此，資料模型隱藏了大部份資料庫使用者不感興趣的儲存 和實作的細節。

再以圖 1.2 為例，在檔案內部實作上可能用記錄長度來定義，即每筆記錄的字 元（Bytes）數，而每個資料項可以用在記錄裡的起始位元組與以位元組為單位 的長度指定。因此，STUDENT 記錄可用如圖 1.3 所示的方式表示。但是，資 料庫使用者並不會去關心記錄裡的每個資料項在哪，或是它的長度有多長；而 會比較關心當它參考 STUDENT 的 Name 時，所傳回來的值是否正確。圖 1.2 顯示 STUDENT 記錄的概念表徵。許多檔案儲存組織的其他細節，像是檔案所 指定的存取路徑，可以被 DBMS 隱藏起來，不讓資料庫使用者看到；我們將在 5、6 章討論儲存的細節。

在資料庫的方法中，每個檔案的詳細結構和組織都儲存在目錄裡。資料庫使用 者參照檔案的概念表徵，並且當 DBMS 軟體有需要時，DBMS 就會從目錄取出 檔案儲存的細節。許多資料模式都能提供資料庫使用者這樣的資料抽象化。本 書的主要部份在致力於呈獻讀者們各種資料模型及它們用來將資料表示抽象化 的概念。

近來的趨勢正朝向物件導向和物件關聯資料庫，抽象化往前更進一步，不但包 含了資料結構，同時包含了資料的操作。通常，這些操作會提供使用者所能瞭 解的迷你世界活動的抽象化。舉例來說，CALCULATE_GPA 操作就可以應用 在學生物件上來計算平均成績。像這樣的操作能夠由使用者查詢或程式引用，

但使用者卻不必了解內部如何實作操作的細節。就此意義而言，迷你世界活動 的抽象化可以當作抽象化的操作(abstract operation)，讓使用者來使用。

1.3.3 支援資料多重景觀

資 料 庫通 常會 有 很多 使用 者 ，每 位使 用 者可 能會 需 要一 個不 同 的資 料庫 觀點

（perspective）或景觀(view)。景觀可以當作資料庫的一個子集合，或是包含 由資料庫檔案所衍生，但沒有真的儲存起來的虛擬資料(virtual data)。某些使用 者可能不需要去了解他們所參照的資料是儲存的還是衍生出來的。對一個多使 用者的 DBMS 而言，它的使用者有各種不同的應用，因此它必須提供定義多重 景觀(multiple views)的功能。

例如圖 1.2 資料庫的其中一位使用者，可能只對每個學生的成績單感到興趣；

這使用者的景觀就如同圖 1.4(a)所示。

(a)

Student Transcript TRANSCRIPT STUDENnAME

CourseNumber Grade Semester Year Sectionld

CS1310 C Fall 99 119 Smith

MATH2410 B Fall 99 112

MATH2410 A Fall 98 85 CS1310 A Fall 98 92 CS3320 Brown B Spring 99 102

CS3380 A Fall 99 135

(b)

TRANSCRIPT STUDENnAME CourseNamber Prerequisites CS3320

Database CS3380

MATH2410 Data Structures CS3320 CS1310

圖 1.4 兩個景觀衍生自圖 1.2 (a)學生成績單、(b)必修課程表

第二位使用者可能只對檢查學生所註冊選修的每門課程之必要條件感興趣，則 他所需要的可能是如圖 1.4(b)所示的景觀。

1.3.4 資料分享與多使用者交易處理

多使用者 DBMS，就如同字面上的意義，必須能讓多位使用者同時存取資料 庫。對單一資料庫而言，多個應用程式的資料必須整合和維護。DBMS 必須包 括一個並行控制(concurrency control)軟體，確保當數個使用者嘗試更新同一筆 資料時，可以用一種受控制的方式來執行，使得更新的結果是正確的。例如，

當幾名售票員試著劃飛機座位時，DBMS 應該要確保每個座位只能讓一位售票 員 劃 位 給 一 位 乘 客 ， 這 種 應 用 程 式 的 型 態 通 常 稱 為 線 上 交 易 處 理(on-line transaction processing 簡稱 OLTP)應用程式。多使用者 DBMS 軟體的基本任 務，就是在確保目前的並行交易操作能正確無誤的執行。前述這些特性是區分

DBMS 和傳統檔案處理軟體最重要的部分，1.6 節我們將討論描繪 DBMS 特徵 的其他功能，首先，我們將描繪在資料庫環境中有不同工作型態的特性。

1.4 舞台上的演員

對一個小型的個人資料庫來說，如 1.1 節所討論的通訊錄，通常可以由一個人 來定義、建構與處理這資料庫。然而，一個擁有數百位使用者的大型資料庫卻 是需要很多人投入設計、使用與維護的工作。在本節裡，我們指出一些每天使 用大型資料庫工作人員，他們被稱為「舞台上的演員」，在 1.5 節中，我們要 去探討一些可被稱為是「幕後工作者」的人，這些人的工作在維護資料庫系統 環境，不過對於資料庫本身並沒有很大的興趣。

1.4.1 資料庫管理員

只要是多人使用相同資源的組織裡，都需要一個帶頭的管理員來監督和管理這 些 資 源。 在資 料 庫環 境裡 ， 主要 的資 源 就是 資料 庫 本身 ，而 次 要的 資源 則是 DBMS 與 其 他 相 關 軟 體 。 管 理 這 些 資 源 則 是 資 料 庫 管 理 員 (database administrator，簡稱 DBA)的責任。DBA 負責授權存取資料庫、協調監督資料 庫的使用，還有負責所需的軟硬體資源。對於安全系統被破壞，或者系統反應 慢等問題，DBA 也要負責處理。在大型的組織裡，會有同僚來協助 DBA 執行這 些功能。

1.4.2 資料庫設計師

資料庫設計師(database designers)負責辨認將要儲存在資料庫裡的資料，及選 擇適當的結構來表示和儲存資料。這些任務大多是在資料庫真正實作和輸入資 料之前，就已經著手進行了。資料庫設計師的責任是與所有可能會去用資料庫 的使用者們做溝通，以便瞭解他們的需求，提供符合這些需求的設計。在許多 情況下，當資料庫設計完成後，設計師會成為 DBA 的幕僚，去協助其他同事工 作。資料庫設計師通常會和每一群可能使用此資料庫的使用者交談，並開發出