資料庫系統是資訊科技中的重要技術成員之一,也是資訊系統中扮演資料保存系統的角色。就像是企業裡許多作業人員所使用的檔案櫃一般,資料庫系統可以想像成電子化的檔案櫃。
身為電子化檔案櫃的角色,也應具備有檔案櫃原有的功能,甚至要多些附加功能才是。所以,一個電子化的檔案櫃,起碼要能夠完成下列工作要求。
這些動作,說穿了就是資訊系統的新增(Create)、查詢(Retrieve)、更新(Update)、刪除(Delete),CRUD四大資料處裡的功能。此四大功能中,以查詢的功能最為重要。新增時,要先確認是否已經有相同資料存在,所以要先查詢一次。更新時,也得先把要更新的那一筆或者是一群記錄資料找出來,才能夠進行更新。刪除也是一樣,也是得先找到欲刪除的那一筆資料,確認無誤之後才可以刪除。
目前最為廣泛使用的資料庫系統為「關聯式資料庫」,其英文名稱為Relational Database(RDB)。由於關聯式資料庫容易表達,且可用數學的集合,來解釋資料庫內資料的行為。所以,關聯式資料庫非常適合用來教授的語言。要怎樣才能算是一個關聯式資料庫呢?簡單的說,必須滿足下列兩個條件:
資料表才是真正存放資料的地方,且需針對資料表中要存放甚麼樣的資料內容,加以定義清楚。檢視只是針對一個或多個資料表所產生的關聯進行運算指令,其運算後之結果只是暫存性質,檢視關閉後,資料立即消失。
討論關聯式資料庫時,有個觀念要先建立,否則會被一些名詞混淆。設計發展資料庫時,習慣切割成Logical Mode與Physical Mode兩個模式。
此二者在思考邏輯上,有些模型所使用的名稱,也有所不同。兩者差異請參考下表。
Logical Mode | Physical Mode |
---|---|
個體 Entity | 資料表 Table |
關係 Relation | 關係 Relation |
屬性 Attribute | 欄位 Field or Column |
案例 instance | 記錄列 Record or Row |
記錄列 Record or Row | 資料型態 Data Type |
(無相對名稱) | 檢視 View |
Logical Mode Physical Mode 個體 Entity 關係 Relation 資料表 Table 屬性 Attribute 欄位 Field or Column 案例 instance 記錄列 Record or Row 定義域 Domain 資料型態 Data Type (無相對名稱) 檢視 View 有時候在與使用者或技術團隊的溝通中,並不會分的這麼清楚。所以,在學習過程中,自行注意兩者之差別。
關聯式資料庫是由許多二維表格所集結而成的。此二維表格英文稱之為Table,有人翻成資料表,有些直接翻為表格,是關聯式資料庫中最重要元素。其實,在還沒有電腦化之前,人們已經很習慣使用這種方式來表達一群資料之集合。所幸,這種表達方式也非常適合以電腦方式來呈現。例如,我們收集了一堆客戶的資料,並以資料表的方式呈現如下。
客戶編號 | 客戶姓名 | 公司簡稱 | 聯絡電話 | 建檔日期 | 碰面次數 |
---|---|---|---|---|---|
0001 | 錢大海 | 大同 | (03) 26543244 | 2014/01/03 | 1 |
0003 | 何必問 | 宏碁 | (02) 23454251 | 2014/01/06 | 3 |
0018 | 趙之建 | 惠普 | (04) 54837235 | 2014/04/12 | 5 |
0112 | 孫斯平 | 宏碁 | (02) 23454251 | 2014/04/15 | 2 |
0113 | 周新欣 | 大同 | (03) 26543242 | 2014/05/11 | 5 |
0120 | 錢大海 | 東元 | (02) 43475843 | 2014/05/16 | 6 |
這些內容不是隨便亂放的。先來看看有些基本定義。
每個資料表都要有一個名稱來代表之,建議採用名詞為主。大部分的資料庫系統,除了資料內容可支援中文之外,資料表名稱或欄位名稱,並不支援中文,所以盡量以英文來命名。
資料表名稱長度,不宜過長或太短,且不可以有空白。許多資料表設計者,常常是以子系統來區隔資料表,只用一兩個單字,或者是子系統名稱的英文縮寫,作為資料表名稱的前置字,後面再加上數字。例如說EP001可能代表人事系統的第001個資料表。這雖然具有安全保密之效果,但對後續維修會造成困擾。建議可以用每個英文字的第一個字大寫,字與字之間可以留'_'底線,或者是不留任何字元,這樣子的方式來設定資料表名稱。
每一個欄位(Column)稱之為屬性,也就是我們所關心的一個事實。一個資料表就是把許多所我們關心且有關連性的事實放在一起。在上述客戶資料表中,每一列(Row)代表一筆獨立的客戶資料。依每個關心的事實,為特定的客戶蒐集資料。整個客戶資料表,就是把每個客戶所關心的事實資料,收集在一起而成為一個集合。
也可以這麼解釋,一個資料表,就是我們所關心一群個體(Entities)的集合體。用資料表名稱來代表這些集合體的抽象結果的集合名詞。每個個體都各自攜帶有屬性,這些屬性是目前對這些個體所關心的事實。當然,會隨著時間或目的之不同,這些關心的事實會有些調整。一個被稱為關聯式資料庫的資料表,應該具備有下列特性:
在客戶資料表中的「客戶編號」、「客戶姓名」、「公司簡稱」、「聯絡電話」、「建檔日期」、「碰面次數」等皆稱為欄位(Field)亦稱之為屬性,也就是我們所關心的幾項事實。而每個客戶,就是一筆筆帶著這些屬性的記錄列。 可以想像一下,一個表格就好像是一間會議室,把這些客戶都請進到會議室來,形成一個集合體。每個客戶進來會議室給發一張牌子掛在身上,上面有「客戶編號」、「客戶姓名」、「公司簡稱」、「聯絡電話」、「建檔日期」、「碰面次數」的空白位置,請客戶自行填上自己的資料。這樣子,每個客戶都擁有自己專屬的屬性值了。 這些收集資料的屬性,將會隨著妳所關心的事實而有所改變。例如說,妳想要把帳單直接寄回客戶,那妳就必須要留有地址這個欄位,並收集資料存放之。至於說,怎麼知道需要訂定哪些欄位,這就是系統分析與設計的範疇了。資訊系統的發展,就是在找出會有哪些個體(資料表),個體應該要攜帶哪些欄位(屬性值),也稱之為系統分析與設計的過程。這個過程之後,接著要考慮的是,真正在資料庫中建立表格,讓使用者可以輸入實際的資料。此為資料庫的設計了,也就是建立資料表的結構(Schema)了。
一個資料表應該要有哪些欄位呢?每個欄位又應該要填哪種類型的純量呢?要回答這些問題,就是在設計資料表結構了。英文是用Schema來代表,但有些人用Meta-data來代表資料結構。也就是用來描述資料庫的資料表的意思。資料表與Schema其實是一體的兩面,一個是看設計面,一個是看資料面。上述客戶資料表的Schema可設計下表。
欄位 | 資料型態 | 可否Null | 是鍵值 | 預設值 |
---|---|---|---|---|
客戶編號 | varchar(4) | No | PK | |
客戶姓名 | varchar(10) | Yes | No | |
公司簡稱 | varchar(20) | Yes | No | |
聯絡電話 | varchar(10) | Yes | No | |
建檔日期 | datetime | Yes | No | Now() |
碰面次數 | Int | Yes | No | 0 |
幾個重要元素解釋如下:
與資料表名稱一樣,不是每個資料庫系統都有支援中文的欄位名稱,所以盡量採用英文命名。
每家資料庫系統對於欄位名稱長度限制也不一樣,不過大部分都可以接受很長的欄位名稱。盡可能使用足以辨識意義的欄位名稱,所有字都用小寫。
每個欄位能夠攜帶都甚麼樣的資料,其實是有限定的。我們可以簡單地用「文字」、「數字」與「日期」這三種不同的純量類型來區分。
凡可用ASCII編碼方式儲存的資料即屬之。所以,包含有文字數字與特殊符號才可以輸入。中文字當然也算是。
又可分成整數類、浮點類等不同類型,類型不同是可以轉換,但會失去精準度。不同資料庫系統,對於不同型態可能使用不同長度的位元數來表達。一般,整數是32bit,表示可以這個欄位可以存放的數字範圍−2147483648(-231) ~ 2147483647(231 - 1)。其他類推。
有分日期、時間和日期時間合併的。有些資料庫系統視為文字型態,也有些視為數字型態。
當欄位設定成不同資料型態時,就會限制使用者能夠輸入哪些資料。例如說,客戶資料表中,已經將碰面次數設定為整數類的資料型態,我們就不可以輸入含有小數點的數字,或者輸入文字類的資料,否則系統就會出現錯誤。
實作於資料庫系統時,廠牌不同,其所提供的資料型態會有些差異。因此,建立資料表結構與所選取的資料庫系統有密切關係,所以,在設計時一定要參考資料庫系統所提供規格書之內容。
鍵值的觀念非常的重要,他影響ER-Model建模過程的思維邏輯,務必多加注意。以下用比較通俗的方式進行描述。
延續客戶資料表的議題。今把客戶請到同一間會議室裡。此時,您想請一位客戶到台前來,最簡單的方式,也是最直覺方式,就是用客戶姓名來呼叫客戶,也就是用姓名這個屬性(事實)來辨識不同的客戶。
從資料表中可知,若請"何必問"這個客戶時,沒有爭議,只有他會到台前來。但若改請"錢大海"呢,這就麻煩了,因為有兩個"錢大海",一個是來自"大同",另一個是"東元"。現實社會中,還可用手點一下,但在電腦世界,就會不知所措。若能有個屬性,能夠明確指出是哪一個客戶,可保證不會搞錯。
凡欄位的內容值能夠確保只可被叫出一個(the one and only one)客戶時,此欄位就稱為具有鍵值(KEY)的特性。在此客戶中,「客戶編號」就是鍵值,因為可以確保每一個客戶都會有獨一無二(unique)的「客戶編號」。姓名並不是鍵值,因為有可能會有同名同姓的機會存在。被用來代表此個體Unique的欄位者,則給一個特定名詞叫做主鍵值(Primary Key)。其他的欄位也可以當作鍵值時,稱之為候選鍵(Candidate Key, or Alternate Key)。
例如,客戶的身份證號是鍵值。每個人的身份證號都應該要不一樣,若一樣,那就是表示出問題了。一般而言,一個資料只要有一個主鍵值即可,卻可擁有零個或多個候選鍵。用了客戶編號當主鍵值時,身分證號單純扮演候選鍵的角色。但是,一定被設定為鍵值時,這個欄位的資料內容就不可以是空值。
另外,還有一種情境是當資料表裡所有欄位,都不能當作主鍵值時,或者是為了管理目的,此時就需自行建立一個欄位當作主鍵值。其實,在客戶的資料表中,「客戶編號」就是自行產生的主鍵值。若有自行產生的主鍵值時,就需要注意編碼方式,盡可能使用有意義的編碼。有時候會採取流水號,這個是用來控管交易之目的。若中間有跳號,表示這筆交易是有問題的。
有時候光靠一個欄位並不能確保是唯一值,當需要依靠兩個以上的欄位才能夠決定是哪一筆資料時,也就是多個欄位合併成一個主鍵值,我們給個特定的名稱叫複合鍵(Composite Key)。
例如,會議室的椅子編號是從1到10,若要知道坐在編號3椅子上的客戶是誰時,會有兩種狀況發生。若這公司只有一間會議室,當然可以馬上知道坐在椅子編號為3的客戶是誰。若這家公司有好多間會議室,那麼就需要在加一個鍵值會議室編號,配合椅子編號,能夠真正的找出是哪一位客戶。所以由(會議室編號+椅子編號)才能找出唯一值時,此兩者結合成複合鍵成為主鍵值。