資料庫初體驗

 文/黃國倫

資料庫(Database)廣義來說,為一個具有相關隱含意義的資料集合,通常為了特殊目的而建置,因此會有預定的使用族群,而資料庫可大可小、可簡單亦可複雜。舉例來說,一個班級的通訊錄,可能僅僅只有數十筆記錄,每筆只紀錄簡單姓名、電話、住址…等文字結構;而以數位典藏聯合目錄而言,則涵蓋了上百萬筆數位典藏資訊,數位格式包含文字、聲音與影像,資料關係更是錯綜複雜。無論資料量如何,皆可歸納為資料管理的一種,必須能針對資料進行組織、分類與儲存,並盡量滿足使用者檢索、統計分析、維護…等等需求。

<目錄>
3. 資料庫初體驗
3.1 資料管理的好幫手:資料庫
3.2 選擇適合的關聯式資料庫
3.3 資料庫設計DIY
3.4 書同文,編碼大不同

 

文/黃國倫

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或其他平台運作?
商業用途 是否用於公司營利之目的?

 


 

 

 

 

 

 

 

 

 

 

加入書籤
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Hemidemi
  • MyShare
  • Live
  • Technorati
  • TwitThis
  • RSS
  • Funp
  • Haohao
  • MySpace
  • plunk

回應

*
請輸入圖片中的文字
按下圖片中的文字取得錄音檔

Click to hear an audio file of the anti-spam word

  • Loading...


    Loading...

    Login






    註冊 | 忘記密碼

    Register





    A password will be mailed to you.
    登入 | 忘記密碼

    Retrieve password





    A confirmation mail will be sent to your e-mail address.
    登入 | Register