2013年9月9日星期一

自製記帳軟件 - Schema


在上一篇中已經指出了 Schema 在開發 Database 中有如建築藍圖, 在為 Database 加磚蓋瓦前必須再三思量, 也必須跟未來的使用者好好溝通. 那如何設計 Schema 呢? 以前設計 Schema 是一件很痛苦的事情, 設計者必須一字一字的在 MySQL Admin 的 Command Line Interface 下輸入整個 Schema... 正如劉德華所說: "今時今日這個態度是不夠的." 所以 MySQL AB 在2003年招攬了DBDesigner4 的開發者 Michael G. Zinner 加入之後, 開發出了MySQL GUI Tools Bundle. 在2007年, MySQL 推出了MySQL Workbench 5.0, 並逐漸成為 MySQL 的旗艦圖形介面產品. 從此以後, 設計 Schema 的權柄, 就由小眾神級高人手中飛到尋常百姓家了. 有關 MySQL Workbench 的故仔就說到這裡.

如果大家有留心看文頂那幅圖(我很懷疑有沒有人看), 有沒有發覺好像一張水管佈置圖呢? 再細心點看, 我相信聰明的各位一定會發現, 所有"水管"都直接間接的連到正中間那個方格. 其實這就是我自家製的記帳軟件背後關聯式資料庫的 Schema. 關聯式資料庫是在上世紀七十年代 Edgar Frank "Ted" Codd (1923-2003) 提出的關聯模型基礎上發展出來的資料庫. 關聯式資料庫就好像我們常見的族譜, 由一種類似父母與子女的關係所編織而成, 更進一步的相關定義與歷史, 請大家去問 Google 大神好了, 畢竟已經超出我能力.



中間這圖就更清楚的顯示了, 資料表 (Table, 即頂端是藍色那些方塊) 間的關係, 這種關係是建立在不同資料表中的資料欄 (Field) 的關聯. 在上圖中以橙色所標示的關係是一種"一對多(One to Many)" 的關係. 左手邊的資料表 <tbl_company> 是用來記錄主公司的資料, 而另一邊的資料表 <tbl_mvoucher> 則是用記錄所有傳票的主要資料. 其中關聯的資料欄分別是 <tbl_company> 的 <<id_company INT>> 及 <tbl_mvoucher> 的 <<co_mvoucher INT>>, 而該關聯的性質是一對多. 形象化一點說明: 在這個關係中, 主公司的編號 (ID) 在 <tbl_company> 只會出現一次, 但是在 <tbl_mvoucher> 則可以出現無數次. 情況就如同, 一間公司可以有無數多張傳票 (Voucher) . 

何謂一對多, 就是指一筆特定資料在資料表甲只會出現一次, 而在資料表乙則可以出現無數次. 而關聯性質不是只有一對多, 它還可以設定為"一對一 (One to One)" , "多對多 (Many to Many)" 及"多對一 (Many to One)". 直覺上"多對多"這種關聯性最有彈性, 但是當你使用查詢 (Query) 去組合兩個有多對多關聯的資料表時, 它卻會引出一個資料性夢魘: 笛卡兒乘績 (Cartesian Product). 當然, 你有可能為的就是要得到這樣的結果, 但是在簿記或會計之中, 笛卡兒乘績的用處應該不大.

既然公司的編號只出現一次, 那為什麼不把公司資料直接放在 <tbl_mvoucher>? 這是因為遵從了資料庫正規化 (Database Normalization) , 亦節省了資料庫在硬盤(Hard Drive) 及記憶體 (RAM) 上所佔據的位元空間從而縮短系統反應時間(Response Time). 說了這麼多, 那<<id_company INT>> 及 <<co_mvoucher INT>> 中的 "INT" 是什麼呢? 這個 "INT" 指的是資料的形態. 這是未來會講及的. 


沒有留言:

發佈留言