文/黃國倫
資料庫(Database)廣義來說,為一個具有相關隱含意義的資料集合,通常為了特殊目的而建置,因此會有預定的使用族群,而資料庫可大可小、可簡單亦可複雜。舉例來說,一個班級的通訊錄,可能僅僅只有數十筆記錄,每筆只紀錄簡單姓名、電話、住址…等文字結構;而以數位典藏聯合目錄而言,則涵蓋了上百萬筆數位典藏資訊,數位格式包含文字、聲音與影像,資料關係更是錯綜複雜。無論資料量如何,皆可歸納為資料管理的一種,必須能針對資料進行組織、分類與儲存,並盡量滿足使用者檢索、統計分析、維護…等等需求。
文/黃國倫
3. 資料庫初體驗
3.1 資料管理的好幫手:資料庫
什麼是資料庫?
什麼是關聯式資料庫?
關聯式資料庫可以幫我們解決什麼問題?
資料庫(Database)廣義來說,為一個具有相關隱含意義的資料集合,通常為了特殊目的而建置,因此會有預定的使用族群,而資料庫可大可小、可簡單亦可複雜。舉例來說,一個班級的通訊錄,可能僅僅只有數十筆記錄,每筆只紀錄簡單姓名、電話、住址…等文字結構;而以數位典藏聯合目錄而言,則涵蓋了上百萬筆數位典藏資訊,數位格式包含文字、聲音與影像,資料關係更是錯綜複雜。無論資料量如何,皆可歸納為資料管理的一種,必須能針對資料進行組織、分類與儲存,並盡量滿足使用者檢索、統計分析、維護…等等需求。
一般對於資料量需求不大、關係簡單之資料,是可以採用Word、Excel…等文件格式紀錄,這也算是廣義資料庫的一種;但若資料彼此間關係稍微複雜,就會有不少維護困難與著錄限制。以人名權威資料庫為例,若以Excel紀錄姓名與參考書目關係可以簡單表示如下:
表一
姓名
|
參考書目
|
編著者
|
文徵明
|
明人傳記資料
|
國立中央圖書館
|
蘇東坡
|
中國歷代人名大辭典
|
沈起煒
|
王錫爵
|
明人傳記資料
|
國立中央圖書館
|
王安石
|
中國歷代一百名人傳
|
沈起煒
|
以此表格資料為例,可以整理出欄位彼此關係如下︰
其中『姓名』與『參考書目』為多對一關係,如『文徵明』與『王錫爵』同時參考自『明人傳記資料』;『參考書目』與『編著者』也為多對一關係,如『中國歷代人名大辭典』與『中國歷代一百名人傳』皆為『沈起煒』所撰寫。
乍看之下很合理,但實際著錄時卻有可能會發生一些問題,如『姓名』與『參考書目』也有可能是一對多關係,如『文徵明』有可能同時參考自『明人傳記資料』與『中國歷代人名大辭典』,在關係圖中可以很簡單加入參考關係,而在表格之著錄也很直覺就會將『參考書目』改成如下,但問題來了,『編著者』要如何著錄,才能清楚區分此『編著者』屬於哪個『參考書目』呢?
表二
姓名
|
參考書目
|
編著者
|
文徵明
|
明人傳記資料、中國歷代人名大辭典
|
國立中央圖書館、???
|
而在資料維護上,同樣也會有一些困難,如發現資料著錄錯誤,要將所有『明人傳記資料』改為『明人傳記資料索引』,將所有『中國歷代人名大辭典』的『編著者』由『沈起煒』改為『張撝之、沈起煒、劉德重』,若要修改筆數有成千,甚至上萬筆時,那實在也只能說是一件苦差事了。
表三
姓名
|
參考書目
|
編著者
|
文徵明
|
明人傳記資料索引
|
國立中央圖書館
|
蘇東坡
|
中國歷代人名大辭典
|
張撝之、沈起煒、劉德重
|
王錫爵
|
明人傳記資料索引
|
國立中央圖書館
|
王安石
|
中國歷代一百名人傳
|
沈起煒
|
……
|
中國歷代人名大辭典
|
張撝之、沈起煒、劉德重
|
……
|
明人傳記資料索引
|
國立中央圖書館
|
……
|
……
|
……
|
……
|
……
|
……
|
所以有發現真正問題所在嗎?其實癥結點就在於『姓名與書目彼此間關係可能會有一對一、一對多、多對一、多對多的關係存在,若單純使用Excel這類電子文件著錄,試圖只用一個表格去表達姓名與書目,在很多情況下是無法適當呈現出資料彼此間之關係的』。所以應該重新考慮表一,將其拆成如下之表四、表五兩個表格,再加上表六去紀錄姓名與書目之間的關係。
表四
PEOPLE_ID
|
NAME
|
1
|
文徵明
|
2
|
蘇東坡
|
3
|
王錫爵
|
4
|
王安石
|
表五
BOOK_ID
|
BOOK
|
BOOK_AUTHOR
|
1
|
明人傳記資料
|
國立中央圖書館
|
2
|
中國歷代人名大辭典
|
沈起煒
|
3
|
中國歷代一百名人傳
|
沈起煒
|
此外,SQL依照用途可簡單區分為三大類:資料定義語言(Data Definition Language,簡稱DDL)、資料操作語言(Data Manipulation Language,簡稱DML)及資料控制語言(Data Control Language,簡稱DCL)。資料定義語言可以用來定義資料庫的資料結構,就像資料表名稱、欄位名稱、以及各欄位屬性等等;資料操作語言則是用來進行資料操作,例如:資料庫中新增、刪除、更新、與查詢資料的操作功能;而資料控制語言可以針對資料庫內部進行交易處理及系統效能維護。因此只要學會這三大類的SQL語言,幾乎就可以應付各種資料庫管理工作。但礙於篇幅關係,本章節並不詳細介紹SQL用法,有興趣者可參考SQL相關書籍。<目錄>
3.2 選擇適合的關聯式資料庫
有哪些關聯式資料庫可供選擇?
優點為何?限制為何?
目前市面上常見之關聯式資料庫有Microsoft Office Access、Oracle Database、Microsoft SQL Database、MySQL、PostgreSQL,基本上都具備關聯式資料庫基本功能,茲分別簡介如下:
n Microsoft Access
MS Office Access適合資料量小,需求不大之使用者。其單一表格可支援2GB資料量、支援基本的交易鎖定(Transaction Lock)、支援與MS Office套件作一些功能上的結合,更重要的是也支援SQL結構化查詢語言。但只支援255個使用者同時上線,無法使用預存程序(Store Procedure)或觸發(Trigger)…等功能,只能執行於Microsoft Windows作業系統上,更多產品相關資訊可參考http://www.microsoft.com/access/。
n Oracle Database
商業資料庫,由專業資料庫廠商Oracle推出,一般常見功能皆具備,可說是目前市面上功能最齊全的資料庫。也因其功能眾多,其所提供之資料庫管理者介面相當複雜,甚至有些進階功能無法透過介面去管理,只能透過命令列(CommandLine)方式進行設定,價格昂貴。其除可與Java做緊密結合,亦可於Linux、FreeBSD、MSWindows、Solaris…等作業系統上執行。更多產品相關資訊可參考http://www.oracle.com/database/。
在選擇資料庫時,除了根據資料管理的需求外,也要考慮資料量規模、預算、作業系統平台、資料庫功能…等等實際專案需求;若以作業系統平台為考量,僅限制在Linux上運作,則MS Office Access、MS SQL Database就無法列入考慮;若非商業用途,而預算又不足時,就可以考慮MySQL或PostgreSQL,端看不同需求,而有不同資料庫選擇。在這裡提供幾個評估因素,讓各位在選擇資料庫產品時可以先進行自我需求分析,以了解資料庫應具備的特性:
評估因素 |
說明 |
資料複雜度 |
是否支援有多對多的關係?
是否提供欄位格式限制?日期、數字、長文字?
|
資料量 |
最大的資料儲存筆數? |
資料查詢需求 |
是否支援SQL查詢?
是否提供AND、OR、部份符合、大於、小於條件查詢? |
使用者數量 |
同一時間最多使用人數? |
跨平台要求 |
是否能在Windows、Linux或其他平台運作? |
商業用途 |
是否用於公司營利之目的? |
…詳全文