paulwong

進銷存系統有幾個資料庫?

我在教授 軟體設計課程,尤其是以使用案例圖在說明架構設計時,每一個用套件(Package)所界定範圍的系統,係指軟體應用系統,但卻幾乎不會談及到資料庫。因 為,軟體應用系統與資料庫是兩個不同的層次,甚至,把資料庫視為是應用系統的 "私有倉儲(private storage)",會比較恰當。


不過,這衍生出一個問題,學員不容易分清楚如何 "mapping" 抽象面的架構設計至實體的 IT 系統,尤其是資料庫的問題。所以,我會先帶一個問題問學員:在設計層次的考量中,進銷存系統有幾個資料庫?


這一個問題要能回答得出來,其假設前提的考量必須要瞭解,在整體的架構設計中,設計團隊到底將 "進銷存" 視為是一個,還是三個,甚至多個的子系統?


參考下圖1,這是把 "進銷存" 視為是單一的系統,所以,資料庫只有一個。


好處是什麼? 就是簡單,開發也容易。進銷存相關的資訊處理,都是在同一個資料庫內,並沒有分散的問題,所以當處理銷貨需要查詢庫存資訊時,只要下 SQL 敘述直接連結庫存的 TABLE 即可。



圖1、將進銷存視為一個整體系統


參考下圖2,架構設計之初時,就已把 "進銷存" 分為三個子系統(Sub-system),或者也可以稱之為元件(Component),以凸顯子系統之間的溝通,是透過介面(Interface)的呼 叫。其實,論子系統的範圍與規模,稱為 "模組(Module)" 更為適合,不過,我個人並不喜歡以 "模組" 二字來稱之,因為,這個術語被業界給濫用了,已淪落為在業務面的術語,卻並沒有在實體的系統間,嚴格遵循透過介面的呼叫。


所以圖2,有三個資料庫。


當銷貨人員處理銷貨需要查詢庫存資訊時,需要透過庫存系統所提供的介面來呼叫,介面的實做可能是 "Web Service"、"Java Bean"、"Session Bean"、"COM+" 等,但絕對不能直接下 SQL 來呼叫位於庫存系統內的資料庫,否則,就違背了圖2的整體架構設計。不遵循整體架構設計的規範,私自偷偷連接,稱之為 "跳線"。



圖2、將進銷存分成三個獨立的子系統

上圖2的抽象設計與IT面的實做技術,比較困難,也需要花較多成本,以專案為主(Project-based)的開發,時程短、預算 低廉,不容易達成圖2的設計目標。但若重覆性的專案,專注在進銷存這個領域上,有豐富足夠的領域知識(Domain Knowledge),且打算產品化(Product),那麼,圖2的系統架構來得有彈性很多,"進"、"銷"、"存" 三個子系統(元件),均可以隨意抽換,各自更新或改版,而不會影響到另一個子系統,如同 PC 主機板內的硬體元件,可以造成 "PnP(Plug and Play)" 的效果。


請注意,上述問題的提問,會有幾個資料庫,是指抽象的邏輯設計層面,可千萬不要與實體的資料庫混為一 談。例如,圖2雖然需要三個資料庫,但若以 Oracle 資料庫系統,DBA 可以將邏輯層面的三個資料庫,切分為三個 "TABLE SPACE",然後放在同一個實體的 Oracle 資料庫系統內;而若是 MS SQL 或是 MySQL,則是切割為三個 "database",放入同一個實體資料庫系統內。


當然,若有地理位置或資料庫系統負載的問題,要分散至多個實體的資料庫系統,那也沒問題。例如,進銷存位於三個地點不同的廠,各自配置了三個實體資料庫,各自存放自己的資訊。這也是圖2架構設計的優點,一切分合自如!


e 化的系統設計,即使是 ERP 如此重視資料存取與處理的系統,應該要能摒除傳統以資料庫為中心的設計觀點,因為,系統整體的彈性度會不佳,很難應變需求面的頻繁變更,或是 IT 實體平台,包括資料庫系統的變更等。設計重心應該要轉移至 "Middleware",這個術語可能太貼近 IT 平台面了,倒不如乾脆這麼說,設計的重心就是回歸至以 "應用系統" 為主,是觀察應用系統可以提供那些服務(services)或功能(functions),這些服務與功能其實就是系統一個個可以量化的子目標(Sub- goal),次一步驟才是考量如何取得要能達成這些子目標的資訊(資料),要取得資訊,就是到實體的倉儲,也就是私有的資料庫系統去找,或是,透過標準的 程序,也就是透過標準的介面,至外部系統取得相關的資訓來處理。

posted on 2006-06-17 09:57 paulwong 阅读(537) 评论(0)  编辑  收藏 所属分类: Design Pattern


只有注册用户登录后才能发表评论。


网站导航: