1.關連式資料模型
1-1 前言
傳統上,企業公司的資料處理,大都是按照部門或應用加以分類。因此,早期企業公司的電腦大多是為了處理各個部門或者應用系統的大量資料而裝置的;
例如一家汽車製迼公司,可能有產品製造部門、會計部門;而一家餐館,可以
有編製顧客帳單之應用系統、維護應收帳款之檔案系統等。而每一個部門或每
一種應用系統原則上都有它自己的主要檔案,而各個部門或應用系統都有自己
所需的資料,和更新檔案及提供資訊所需的程式。利用這種資料處理方式來存
取資料,最大的好處是程式的設計方式相當單純,因為每個檔案系統均針對該
部門或應用系統的特殊處理要求來設計,因此所設計出來的系統較容易滿足各
部門或應用系統之要求。但是相隨衍生的問題卻不少。
┌─────────────────────────────┐
│ ┌──────────────────────┐ │
│ │ ┌─────┐ ┌─────┐│ │
│ │應用系統 ─
│應用程式一│←→│檔案系統一││ │
│ │(或部門一)└─────┘ └─────┘│ │
│ └──────────────────────┘ │
│
│
│ ┌──────────────────────┐ │
│ │ ┌─────┐ ┌─────┐│ │
│ │應用系統 二
│應用程式二│←→│檔案系統二││ │
│ │(或部門二)└─────┘ └─────┘│ │
│ └──────────────────────┘ │
│
│
│ ┌──────────────────────┐ │
│ │ ┌─────┐ ┌─────┐│ │
│ │應用系統 N
│應用程式N│←→│檔案系統N││ │
│ │(或部門N)└─────┘ └─────┘│ │
│ └──────────────────────┘ │
│
│
└─────────────────────────────┘
1-2 傳統的資料處理
一、資料重複
相同的資料欄位值會重複出現在不同的檔案系統上。例如:在一家公司裡,銷
售員的地址資料、學歷資料年齡資料也可能會重複地出現在人事管理部門、會
計部門、產品銷售部門;須要在這麼多的檔案中輸入、保存及維護這些相同的
資料,代價何其昂貴啊!舉例來說吧!當某一位銷售員的地址資料有所更動時
,就必須到所儲存地址資料的檔案系統中,去更正這些舊有的地址資料,否則
就會造成資料的不一致。
二、資料的不完整
不同的應用系統間之資料往往關係十分密切。例如:陳先生向銀行辦理個人小
額貨款買了一部卡拉OK,然而因未履約,故其卡拉OK須被取回,並降低了他的
個人小額貸款的信用等級。但陳先生在銀行裡,也曾辦過房屋貸款,假使房屋
貸款所對應的信用等級未隨之同時更新的話,那就產生混亂了。然而要維持資
料的完整性,就須執行好幾個程式來更新資料,此將花費很高的費用。
三、資料的不安全
由於企業公司各部門各自為政,公司的資料分散在不同的檔案系統上,對於敏
感性和機密性較高的資料,無法做有效的集中管理;往往會因某些部門負摃人
的管理不善,而讓商業間諜有機可乘,從中盜取機密資料。
四、應用程式的不穩定
在程式上,我們往往利用Format或者Picture來定義資料之精確格式。例如:有一
個學校在該校的學生姓名存在各個不同的檔案中,居然用很多種不同的資料格
式。因此,一旦有姓名格式發生變化,如增長或減短,或刪除時,相對應的程
式也要跟著修改,同時資料檔案庫也要隨之改變,甚至連帶地擷取資料的邏輯
也要跟著翻新了。因之,應用程式的穩定性不佳。而改程式往往是最浪費時間
和金錢的。
由於不同應用系統間的資料息息相關,而當這種關係愈來愈複雜後,傳統的資
料處理技術就再也難以勝任愉快了。於是有新的資料處理技術─資料庫系統之
提倡。資料庫系統的觀念主要強調資料應該是集中式的與整合式的,資料的異
動在系統中僅需一次即可完成。
1-3 資料庫系統的優點
使用資料庫系統的優點,大致可歸納如下:
(一).避免資料的大量重複─相同的資料在資料庫內只需出現一次即可,
但在非不得已時,亦可重複出現。如此可使重複性資料減至最少。
(二).資料獨立─資料庫之結構與內含資料發生變動時,不影響使用者之
程式,亦即使用者程式無須隨之修改。
(三).避免資料不致的現象─資料庫由專人統一管理維護,資料有所異動
,亦一次同時更新,因此不會發生同樣的資料項目而資料值卻不相
同的現象。
(四).維持資料的完整性或整體性─各部門資料均集中在一起,因此可隨
時提供經營管理者所需的各種整體性資訊。
(五).簡化程式撰寫工作─應用程式不需描述資料庫之結構與資料記錄間
的相互關係,同時欲存取資料庫資料,亦有一定之方法與格式,因
此程式撰寫工作可大為簡化,程式設計員之生產力將大為提高。
(六).保護資料的安全─由於資料庫管理系統對其內部資料有完善的保護
功能,故資料不易被偷取或破壞。
(七).資料共通性─資料庫可包容各部門之資料,因之資料庫愈大資料的
價值就愈高,它不僅可供更多使用者使用,且可提供更詳細與完整
的資料。
1-4 關連式資料模型
關連式資料模型是由E.F.
Codd在1970年所提出。它將每一個檔案用一此表格,
又叫關連,來表示。而表格上的每一欄位稱做一個領域,它代表一筆記錄的最
基本資料項。例如職稱的領域代表公司裡所有可能的職稱。年齡的領域代表公
司裡所有員工的可能年齡。例如下面的關連表示一個EMPLOYEE記錄檔案。其
中領域EMPLOYEE
NAME = {C.C CHANG,R.H.
LEE,W.H.
TSAI,M.Y.
LEE
, L.H. HWANG,....},領域EMPLOYEE
NUMBER = {1041,2172,1437,
4012,3128,....}等。
表1
EMPLOYEE 關連
┌───────┬────────┬──┬──┬─────┬───┐
│EMPLOYEE NAME │EMPLOYEE NUMBER │SEX │AGE │ TITLE │SALARY│
├───────┼────────┼──┼──┼─────┼───┤
│C.C. CHANG │ 1041 │ M │ 37 │MANAGER
│ 79000│
│R.H. LEE │ 2172 │ F │ 28 │SECRETARY │ 28000│
│W.H. TSAI │ 1437 │ M │ 30 │MANAGER
│ 60000│
│M.Y. LEE │ 4012 │ F │ 35 │ASSISTANT │ 23000│
│L.H. HWANG │ 3128 │ F │ 35 │DIRECTOR │
31000│
│D.J. BUEHRER
│
4412
│ M │ 40 │MANAGER │ 62000│
└───────┴────────┴──┴──┴─────┴───┘
而在關連中的每一列分別代表一筆記錄,又叫一個元素組。至於DEPARTMENT
關連可以用表2來表示。
表2
DEPARTMENT 關連
┌────────┬────────┬──────┬──────┐
│DEPARTMENT
NAME │DEPARTMENT CODE │
MANAGER │PHONE NUMBER│
├────────┼────────┼──────┼──────┤
│COMPUTER │ 117
│C.C. CHANG │ 2263420 │
│ACCOUNTING │ 120
│W.H. TSAI │ 2547326 │
│ENGINERRING │ 137
│D.J. BUEHRER│ 2263410 │
└────────┴────────┴──────┴──────┘
由於關連結構中的各個關連無主從關係,亦無鍵相連繫,故要表示EMPLOYEE與
DEPARTMENT間的關係,則需仰賴另一關連的穿針引線,此關連包含EMPLOYEE
關連和DEPARTMENT關連之主鍵屬性。
表3
DEPT-EMP 關連
┌─────────┬────────┐
│DEPARTMENT NUMBER│EMPLOYEE
NUMBER │
├─────────┼────────┤
│ 117 │ 1041 │
│ 117 │ 2172 │
│ 117 │ 3128 │
│ 120 │ 1437 │
│ 120 │ 4012 │
│ 137 │ 4012 │
└─────────┴────────┘
1-5 關連式資料庫系統之應用
1-5-1
鍵型態
在每一個關連中,如果我們仔細檢查每一筆元素組,均可以發現一個特性,那
就是某一個屬性,或某一組(多於一個)屬性之組合,可以唯一用來代表該筆
元素組,因此該屬性或該組屬性就可以稱做該關連的主鍵(Primary
Key)。
例如,在下面的關連S中,SNO可以當作主鍵,而SNAME也可以被用來當作主
鍵,然而在一個關連中我們最多只選用一個主鍵就夠了,譬如選SNO當作主鍵
斯足矣。值得一提的是,不一定每一個關連均要宣告一個主鍵。而在關關連中
夠資格當主鍵的單一屬性或屬性組均被稱為候選鍵(CandidateKey),
┌─────────────────┐
│
SNO SNAME STATUS SCITY │
├─────────────────┤
│S001 SMITH 20 LONDON │
│S002 JONES 10 PARIS │
│S003 BLAQE 30 PARIS │
│S004 CLARK 20 LONDON │
│S005 ADAMS 30 ATHENS │
└─────────────────┘
若該鍵沒有被選上擔任主鍵,則就稱之為替換鍵(Alternate
Key),如SNAME
沒有被選上擔任主鍵,則它稱之為替換鍵。
在關連SP中,屬性SP和屬性組(SNO
PNO)均為候選鍵,而我們若選上屬性SP
當做主鍵,則(SNO
PNO)就稱之為替換鍵。
┌───────────────┐
│ SP SNO PNO QTY │
├───────────────┤
│ SP01 S001 P001 120.00 │
│ SP02 S001 P002 200.00 │
│ SP03 S001 P003 100.00 │
│ SP04 S002 P004 300.00 │
│ SP05 S002 P005 230.00 │
│ SP06 S003 P001 150.00 │
│ SP07 S003 P003 400.00 │
└───────────────┘
然而,在關連的所有屬性中,有一些屬性常常會出現在查詢條件中,這一煩的
屬性可以被事先宣告為次鍵(Secondary
Key)。例如:一個SQL的查詢有可能
是這樣宣告的:SELECT PNAME FROM P WHERE COLOR = 'RED' OR WEIGHT < 16.00,
在查詢條件子句中出現了屬性COLOR和屬性WEIGHT。假使該兩項屬性事先曾
經宣告為次鍵的話,則系統會針對該兩項屬性,分別為它們建立索引檔案,以
加速查詢結果的回覆速度。
在關連中除了主鍵之外,還帶有一個或多個外來鍵(Foreign
Key)。身為外來
鍵的屬性一定要對應到別的關連的主鍵上;換言之,假如我們說甲關連的某一
個屬性主鍵型態為外來鍵,那麼該鍵值必須與某一個關連的某一筆元素組之主
鍵值吻合。舉個例來說吧!例如在關連SP中的每一個SNO之值均對應到關連S之
某一筆元素組之主鍵值SNO,所以在關連SP中,SNO稱之為外來鍵,特別除帶
一提的是,外來鍵可以看成〞指到〞某一個關連之主鍵之〞假想〞指標,而且
外來鍵與所對應之主鍵名稱可以取不同的名字。