自製記帳軟件 - 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" 指的是資料的形態. 這是未來會講及的. 

自製記帳軟件 - 思考

動機有了, 工具選了, 是時候思考想要的目標有幾多.  在思考時要將目標分為幾個類別, 並設定先後次序, 好讓自己不會在漫長的開發過程中迷失了. 

思辯

在這階段可以先不想電腦硬體及網絡設備, 因為這些都是金錢可以解決的問題. 要多花時間去細心思考的是如何將日常工作的流程在電腦內重現. 為此, 我有段時間真的自我閉關, 甚至學周伯通以自言自語來跟自己思辯, 只為解決一些在類比世界沒有但卻會在電腦世界發生的邏輯問題. 再一次, 香煙真是好伴侶... (香港政府忠告市民: 吸煙危害健康).

另一個需思考再思考的就是整個系統背後的 Database Schema. Schema 是什麼呢? 它就是讓資料庫管理軟件知道如何儲存你所輸入的資訊, 其關聯性及屬性. 如果以建築大廈作例子, 那 Schema 就是你系統中的建築藍圖. 即是當你設計一個 Schema 時, 你要想像及考慮到整個工作流程及如何達到目標, 換句話說這是 "商業邏輯"! 

Point of No Return

再用建築大廈來說明思考在設計 Database Schema 的重要, 因為 Database Schema 是沒有 Trial & Error 的機會, 而 P.N.R. 就在落實 Schema 前的那一刻. 想像一下你在設計一座住宅大廈的時候, 你會為未來的目標住客設計出適合他們生活習慣或品味的間隔, 睡房和廁所的數目, 廚房的位置, 客廳大小, 甚至樓高, 每方尺承重等等不同的屬性. 當藍圖落實後, 工程師及工人就可以開始根據你的藍圖來動工. 突然市場氣氛轉變, 然後老闆跟你說: "啊, 我們要將這大廈轉變為辦公大樓!" 

於是你叫停工序, 打開藍圖一一審視可修改之處 (在這裡"關聯式資料庳"再一次跟大廈結構很相似; 就是環環相扣, 是真真正正的 "牽一髮而動全身"). 但是你發現, 如果你修改A, 就必須改B, 而修改B, 就要把C也改掉. 如此類推直到修改最核心的部份為止. 然而當你修改最核心的部份, 就變成整個架構都要修改! 緊記的是, 當你的完成度越高, 要修改的東西就越多. 

在分析後你可能發現, 打掉重來可能是邏輯上最合理的辦法, 但往往因為經濟政治等問題而有所不能. 到最後你只能作一些小修小補, 甚至不惜潛建來達到目的. 這樣的成品出來之後不是失敗缺乏效益, 就是成了四不像. 

祖師爺

上圖是 Luca Pacioli (1445-1517) 的肖像. 在文藝復興時期這樣的肖像油畫對被繪者來說, 可說是一種非常高的榮譽. Pacioli 被譽為會計之父,  雖然他並非複式簿記的發明人, 但是他是第一個梳理複式簿記的流程, 規則並全面以阿拉伯數字論述其數學思想及出版的人, 因為其關於複式簿記的部份被獨立成書並暢銷歐洲各國, 促使歐洲揮別難於計算的羅馬數字, 擁抱我們現在日常所見的阿拉伯數字. 所以更被現代某些人說他是這個日漸資料化世界的奠基人! 

說說題外話, 在 Wikipedia 上的 Database Schema 題目有十一種不同語言版本, 亞洲的有韓文(非常簡短)及日文, 但是沒有中文. 為何會這樣的呢?

自製記帳軟件 - 工具

唐吉訶德的馬盾與矛

決定了要自製記帳軟件之後, 就要面對用什麼樣的工具來完成這個"唐吉訶德"式的壯舉. 畢竟唐吉訶德再荒唐也有一匹瘦馬, 一面皮盾, 和一支長予

"En un lugar de la Mancha, de cuyo nombre no quiero acordarme, no ha mucho tiempo que vivía un hidalgo de los de lanza en astillero, adarga antigua, rocín flaco y galgo corredor." - Don Quijote de la Mancha

在 "自製記帳軟件 - 原因" 中已經簡單地說了罐頭式軟件的幾種主要限制: 彈性, 分工及版權. 為了要避免這幾種限制, 在決定工具前我花了不少時間去研究十多個廠商的開發軟件及資料庫伺服器的功能, 特性及版權. 在兼顧了自己的開發能力, 輔助工具, 價格及普及性後, 我決定了以Microsoft Access 及 MySQL Community Server 作前店後居式的配搭來開發自家製的記帳軟件.

前店
我知道很多IT人對 Microsoft Access 都是不屑一顧, 但是我選擇的原因是它可以大幅度減輕我開發的負擔, 尤其不用跟DLL打交道, 就已經功德無量, 更不用提它簡單的報表(Report)設計系統了. 另方面 Microsoft 一直很負責任地提供 Microsoft Access Runtime 給用戶免費下載, 令到在分發及佈署在客戶端時更方便容易. 當然 Microsoft Access 都有它的不足之處; 第一, 它是一個檔案式的資料庫管理系統; 第二, 資料檔容易損壞. 雖然有如此重大的缺點, 但是用作使用者介面(不儲存資料), 它的內建功能是可以讓我相對而言輕鬆地完成任務.

後居
選擇 MySQL Community Server 是一個折衷的方案. 自Oracle 於2009年收購並將 MySQL 納入為旗下產品線後, 開源社區便一直擔心 MySQL Community Server 會逐漸被 Oracle 遺棄. 有見於此, Michael Widenius 於2009年推出了MariaDB, 一個完全與MySQL相容的開源資料庫管理系統 (海豚對上海獅). 那為何我還是選擇以MySQL來開發呢? 因為 Oracle 提供了豐富的免費工具如MySQL Workbench等, 讓我可以更直覺地設計 Schema. 換句話說, 因為我懶...

後居的居所
MySQL Community Server 雖然叫伺服器, 但是它並不是一個完整的作業系統, 所以要找一個作業系統如 Microsoft Windows 來讓它住進去並提供服務. 但是為了省錢又要穩定, 我最後選擇了CentOS, 一個 Red Hat Enterprise Linux 的開源版, 來作這個"後居的居所". 等等! Linux 不是很複雜的嗎? 呵呵,  十年前 Linux 可能是很複雜很難上手, 但是現在各個 Linux Distributions 已經非常之 Down to the Earth 了. 如果有興趣的可以從 Ubuntu, Fedora, 及 CentOS 等 Distributors 下載他們的 Live CD ISO, 然後燒成開機光碟, 再插入電腦內後享受一下非視窗系的另類風格. 但小心不要按了 Install to Hard disk 的選項, 除非你知道自己在幹什麼...

聲明: 文中所提及的商標及產品名稱均屬其版權及商標持有人.