跳到主要內容區塊

計資中心電子報C&INC E-paper

專題報導

自我描述式系統文件設計-資料庫篇
  • 卷期:v0049
  • 出版日期:2019-06-20

作者:陳啟煌 / 臺灣大學計算機及資訊網路中心程式設計組副組長


大凡寫過稍具規模程式系統的程式師大概都逃不過系統文件撰寫的凌虐與荼毒。系統文件是重要的但需要時常維護與程式不脫節才有參考價值,但是維護是件苦差事不容易做到,本文提出一個將文件與資料庫結合防止脫節的方法...

 

前言

大家都要求要做的事情,那肯定重要;不過問到系統文件有沒有用?這個答案就要有一些前提了,正確的系統文件是非常有用的,可讓後續維護事半功倍且較不容易出錯;但如果是與系統實際情況脫勾沒有與時俱進的系統文件,它的殘值就很低。舉例來說,要進行建築裝修,委託案子是一棟4層樓的房子,但業主給的是2層樓的藍圖。您敢用來參考嗎?那維持文件與程式一致不就好了?這件事說得比較容易,但做起來不這麼簡單。

 

系統文件存在的用途不外乎開發前確認系統規劃,開發中確認各個工作事項的細節,開發完成作為後續維護之用。理論上在開發完成時會有一份與系統一致的文件,用來做驗收或是移交給維護單位。但是有人在用的系統,通常少不了後續大大小小的功能擴充或修補。在修改時忘記、遺漏或不知道一併去異動系統文件的情形是常發生的,文件與系統也是在這些時候越離越遠。因為他是兩件事,所以天生是可能脫勾的,但如果可以把他們變成一件事,那不就一定會保持一致了,這件事就成為我們努力的目標。為了目標比較容易達成,先把系統文件縮小到資料規格文件的製作。資料庫的資料庫列表和各個資料表的Schema是最基本的資料規格文件,如圖一所示。為了方便翻閱或是印出來給人瞻仰膜拜,通常會以Word製作,不過有人去改資料庫的時候可能忘記一併修正這份Word文件。為了避免這件事,最好的作法是需要時再產生這份文件,平常這些定義應該在一個資料庫或中介資料(metadata)內。平常維護的是metadata的資料。這樣說起來不是也會忘記維護metadata?這就要說到怎麼維護敘述資料庫的metadata了。

 

Art editor ImgArt editor Img
圖一

 

利用資料庫metadata找出資料庫規格所需資訊

資料庫和中介資料的特性是不像Word文書比較難加以比對,分析一下圖一所示的文件,資料表的名稱、資料表欄位的名稱、資料型態、是否是索引件等資料其實應該不用費心的去抄寫維護。因為資料庫本身就有這些資料,而且保證是即時且正確的。本篇以Microsoft SQL Server為例,資料庫本身存在不少system table,用來維持資料庫的運作,乍看一下好像跟使用者無關,但是裡面有不少資料可以參考,例如objects儲存了各種物件syscolumns儲存了欄位的資訊;而我的資料庫規格需要Table/View的列表或欄位明細,只消下一些SQL指令就可以列出我們需要的資料,如圖二所示。至於索引鍵可以參考sysindexes找出索引鍵資訊,以前辛苦維護的資料彈指之間就產生了,好處是隨時都可以更新資料。不會與資料庫脫節。

Art editor Img
Art editor Img
圖二

 

利用metadata的資訊當基礎,補齊規格表所需資訊

圖二與圖一比較後就可以知道要補齊的資訊如中文資料表名稱、中文欄位名稱、說明等等。好在平常就有資料字典的概念,中文的資料對應不難補齊;但是怎麼要讓他可以貼的牢牢的?這就要利用資料庫特有的功能,Microsoft SQL Server有提供擴充屬性,可以針對資料庫、資料表、欄位、預存程序等幾乎所有物件都能自行定義擴充屬性。利用這個特點,我們可以把所有跟資料庫相關的資訊保留在資料庫本身,資料庫可以自我描述資料型態等資訊,我們把屬於業務邏輯或是資料管理所需的資料都以擴充屬性寫進資料庫。之後隨時都可以取出運用,這也是本篇文章的目標---要設計有自我描述能力的系統文件。


如圖三所示,可以透過資料庫系統的介面一一設定,不過這樣做曠日廢時且容易輸入錯誤。可利用資料庫預存程序sp_addextendedproperty來新增資料庫擴充屬性; sp_updateextendedproperty來異動擴充屬性。微軟有宣告在未來的SQL Server版本中,會移除層級0類型的USER 和 TYPE。建議改用SCHEMA來當做層級0類型。為了未來的相容性,要改用Schema。

 


Art editor ImgArt editor Img

Art editor ImgArt editor Img
圖三

 

定期自動掃描資料庫異動及系統文件擴充屬性缺漏

因為所有資料系統文件皆以與資料庫綁定,加上資料庫本身的功能,所以可以定期以預存程式監控所有資料庫異動及是否有相對的擴充屬性尚未填寫。留下監控及異動記錄,即可產生資料庫版的版本控制。一般我們會進行程式的版本控制,不大會對於資料庫規格進行版本控制。但是透過監控異動記錄的時間與程式的簽入時間,我們很容易可以還原每個程式版本當時相對的資料庫規格。有助於瞭解程式的發展脈絡;必要時也可以用在上版失敗進行退版時的資料補救。

 

利用資料庫內建的使用者函數(user function) fn_listextendedproperty 可以查詢到資料庫內所有資料表或資料欄位的擴充屬性,如圖四所示。

Art editor Img
Art editor Img
圖四

 

可線上查閱或自動化輸出最新版系統規格文件

圖四查詢出來的資訊就是資料庫規格所需的資訊,結合sys.objects, syscolumns就足以組出原來的資料庫規格文件,這樣就解決了資料與描述資料的資訊綁定的問題。唯一的問題是不像原來的文件易於閱讀,關於這一點之前呈現的都是原始資料,利用這些資訊稍微加工做成線上查詢的網頁,或是輸出成文件檔,可利用Word Automation把資料庫規格文件排版格式成為與之前一致的系統文件;但是差別在產生文件的當下資料都是最新的,不會有與資料庫不一致的文件產生。

 

資料規格與程式碼結合驗證不漏接

資料庫的規格書會因為業務邏輯不同,定義每個資料欄位的限制、規則等細節。理論上程式設計師應該在每個資料輸入的頁面驗證規則,阻擋不和規則的資料進資料庫。但這一類的瑣事常會被忽略或遺忘,造成錯誤資料進系統甚至產生系統漏洞。結合程式語言的功能,如ASP.NET MVC架構,在屬於資料的Model部分將資料庫欄位的型態、中文名稱、檢驗規則等自動帶入,如圖五所示,即可自動檢查這些在資料庫規則需要定義的基本驗證。這些寫在擴充屬性的規則可能要自行撰寫model class的程式碼產生器來產生,並進行後續的資料庫更新同步檢查。

Art editor ImgArt editor Img
圖五

 

結語

資訊技術日新月異應該利用科技讓一些瑣事可以自動化,一方面減少人力的浪費;另一方面可以避免人為的錯誤。讓系統文件除了在驗收時發花功能外,在系統的生命週期內持續發揮作用,而且不需要花費太多成本維護。這個部分只是針對資料庫的文件,後續還有程式本身、系統設計等文件,未來看有沒有時間研究將這些文件陸續導入自動化維護。