2016年8月10日 星期三

資料庫設計-中

資料庫設計-上 我提到資料表正規化的方法,在這一篇要講資料庫設計的工具,資料庫設計的工具有很多,有人擅長使用UML用物件導向的角度分析來建模,也有人喜歡用DFD+ERD來建模,我個人的偏好是後者,這裡並不會分析哪種方法比較好或比較差,而是把重點放在建立出來的資料庫模型能夠符合系統的需求,在系統開發時不會在茫茫資料表中迷失的方法就是好方法。



實體關聯圖(ERD)

Table正規化是為了降低資料的重複性與避免更新異常的狀況發生把大雜燴般的資料堆拆分成數個Table的方法,那實體關聯圖(Entity Relationship Diagram)就是把這些拆分出來的關聯Table用圖形化來呈現的一種工具,用來表現資料庫的整體邏輯結構。

ERD用了很多圖形來定義實體(Entity)與實體之間的關聯(Relation),像是長方形代表實體,橢圓形代表屬性,菱形代表關連性,有興趣的可以參考ERD理論說明 ,但是我需要的其實很簡單就是能夠很快速很明確的知道整體資料庫設計的結構,因此我只用了其中幾種圖示來表現ERD,最常使用的就是長方形的實體(Entity)圖示跟各種關聯線,關聯線的種類如下



圖示說明
one
many
zero to one
one to one
one to many

關聯線代表兩個實體之間的關聯,所以關聯線首尾兩端的圖示會兩兩出現,而且ERD圖會因為工具或使用習慣的不同會有不一樣的畫法,像是1..n或是1..*都是代表著one to many。了解這些圖示的用法後,就可以著手製作ERD,製作方法可以直接用手畫或是用工具來畫,我的習慣是在構思階段時,會連同待會要講的DFD都用手繪的方式打草稿,待整個資料結構大致底定後才會用工具製作,至於工具的使用我常用的有Draw.ioVisual Paradigm,Draw.io單純就是一個線上的Visio like的繪圖網站,用法相當直覺方便,我個人非常推荐。至於Visual Paradigm是一個非常強大的商業邏輯分析輔助工具,現在採Saas的方式收費,缺點是不是很好上手,要弄懂要花一點時間。

依照正規化拆分出來的Table繪製的簡化ERD

參考文件


資料流程圖(Data Flow Diagram)

資料流程圖主要用來呈現資料在商業流程中移動的方式,可以幫助我們確定規劃的商業流程是否有所疏漏。

主要使用的圖示

圖示描述
notation (process)Process Node,主要用來表達商業活動或是系統功能,資料會在Process Node經過處理或是運算,Process Node通常不會用來呈現太過detail的內容,而會是一個粗略的商業活動描述,像是"接受訂單",因此Process Node代表的會是一個相關工作或是功能的集成。
notation (enternal entity)External Entity,也就是系統外部的來源或是目的地,可以是人、外部系統或是產出的結果,是資料流程的發起或終點或兩者皆是。
notation (data store)Data Store,用來存放資料的地方,資料的存放可以是暫存或是永久的存放,也不一定就是資料庫,只要是資料存放的地方皆可以用這圖示來表示。
notation (data flow)Data Flow,用來表現資料流動的方向
 

DFD繪製範例

在畫DFD有幾點要注意:
  1. External Entity不可以直接存取Data Store
  2. External Entity不可以直接跟另一個External Entity做資料流程的交換
  3. Data Flow名稱需為名詞而不是動詞,像是發票(n.)而不是列印發票(v.)

參考文件


沒有留言: