GSS 技術部落格
在這個園地裡我們將從技術、專案管理、客戶對談面和大家分享我們多年的經驗，希望大家不管是喜歡或是有意見，都可以回饋給我們，讓我們有機會和大家對話並一起成長！
若有任何問題請來信：gss_crm@gss.com.tw
最近由一位大叔自創的洗腦神曲 PPAP 在網路上流傳，也引起大量的Kuso與模仿。剛好最近在準備Domain Model的課程，發現這首歌的情境剛好可以套(牽)用(拖)到 Recursive Pattern，這樣牽拖會太遠嗎？讓我們繼續看下去。
話說幾年前面試一位有開發ERP經驗的系統分析師，由於他是負責生產製造領域的，就請他說明一下他們的零組件、半成品、成品...的Table怎麼開（基本上就是考他對BOM表的了解）。他在白板上很有自信的畫了類似的下圖的Model，有一個成品檔，一個半成品檔，一個零組件檔，看起來應有盡有。接下來我就問他半成品可能會由多個零組件組成，每個零組件有可能會是多個半成品的組成零件，而且半成品A也可能和另一個半成品B再組合成半成品C，更不用說成品也可能是由半成品和零件組合而成。我已經忘了他後來在白板上畫了多少線，總之，這很明顯不是很穩定的設計。
回到前面的PPAP 也可以想成是BOM表的概念，
Pen * 1 + Apple * 1 = ApplePen
Pen * 1 + Pineapple * 1 = PineapplePen
ApplePen * 1 + PineapplePen * 1 = PenPinappleApplePen
這個看起來很像樹狀結構，有經驗的分析師一看就可以類比成像組織樹一樣，不管是Pen, Apple, Pineapple, 甚至是最後的 PPAP就像組織樹裡的科／課／股、局／處／室，每個組織多一個欄位記錄上層組織就可以了（如下圖）。
一般情況下，同一個單位的上層單位只會有一個；但有經驗的讀者就知道，每個公司裡可能會有很多種組織樹，有些是正規的組織樹，有些是簽核流程用的樹，如果每多一棵樹，就要加一個欄位去記錄組織的上層組織。
更何況，比較細心的讀者可能已經發現，這張圖和組織樹的差別在於，Pen出現了2次，這在單一組織樹裡是不會發生的，同一個單位不會同時掛在兩個組織下，光這一點就會讓這個Model不知道怎麼把樹長出來。
幸好，這種情況也不是今天才發生，早就有人整理出超實用的 【Recursive Pattern】 (Len Silverston, Paul Agnew.(2008). The Data Model Resource Book: Volume 3: Universal Patterns for Data Modeling.WILEY. )來解決這一連串的問題：
以前面的例子來說，每個零組件、半成品、成品，本質上都是零組件，彼此之間可以組合成另一個零組件，除了組合的關係外，也可能會再有其它關係，如：替代（沒有原子筆時可以用鉛筆？）。所以把上述 Pattern 的 ENTITY 替換成 PART，至於這個PART 是零件還是半成品就定義在 PART TYPE，而 PART ASSOCIATION 就記錄了每個PART 和每個 PART 彼此之間的關係。
這個Pattern 有多簡單呢？我們拿來套回組織樹就直接把ENTITY替換成ORGNIZATION就搞定了。
Workshop
學會了上述的Pattern之後，我們只要看到這種樹狀結構，或是像BOM表，或是Peer-to-Peer的關係就可以輕鬆套用這個Pattern。是不是很方便？是不是躍躍欲試？那我們馬上來現學現賣：假設你要設計高鐵票價表的Model，你可能會需要紀錄站與站之間的票價資訊，而票價又分商務艙、經濟艙、早鳥(65折、８折、９折...)，現在就動手畫看看吧。
話說幾年前面試一位有開發ERP經驗的系統分析師，由於他是負責生產製造領域的，就請他說明一下他們的零組件、半成品、成品...的Table怎麼開（基本上就是考他對BOM表的了解）。他在白板上很有自信的畫了類似的下圖的Model，有一個成品檔，一個半成品檔，一個零組件檔，看起來應有盡有。接下來我就問他半成品可能會由多個零組件組成，每個零組件有可能會是多個半成品的組成零件，而且半成品A也可能和另一個半成品B再組合成半成品C，更不用說成品也可能是由半成品和零件組合而成。我已經忘了他後來在白板上畫了多少線，總之，這很明顯不是很穩定的設計。
回到前面的PPAP 也可以想成是BOM表的概念，
Pen * 1 + Apple * 1 = ApplePen
Pen * 1 + Pineapple * 1 = PineapplePen
ApplePen * 1 + PineapplePen * 1 = PenPinappleApplePen
這個看起來很像樹狀結構，有經驗的分析師一看就可以類比成像組織樹一樣，不管是Pen, Apple, Pineapple, 甚至是最後的 PPAP就像組織樹裡的科／課／股、局／處／室，每個組織多一個欄位記錄上層組織就可以了（如下圖）。
一般情況下，同一個單位的上層單位只會有一個；但有經驗的讀者就知道，每個公司裡可能會有很多種組織樹，有些是正規的組織樹，有些是簽核流程用的樹，如果每多一棵樹，就要加一個欄位去記錄組織的上層組織。
更何況，比較細心的讀者可能已經發現，這張圖和組織樹的差別在於，Pen出現了2次，這在單一組織樹裡是不會發生的，同一個單位不會同時掛在兩個組織下，光這一點就會讓這個Model不知道怎麼把樹長出來。
幸好，這種情況也不是今天才發生，早就有人整理出超實用的 【Recursive Pattern】 (Len Silverston, Paul Agnew.(2008). The Data Model Resource Book: Volume 3: Universal Patterns for Data Modeling.WILEY. )來解決這一連串的問題：
以前面的例子來說，每個零組件、半成品、成品，本質上都是零組件，彼此之間可以組合成另一個零組件，除了組合的關係外，也可能會再有其它關係，如：替代（沒有原子筆時可以用鉛筆？）。所以把上述 Pattern 的 ENTITY 替換成 PART，至於這個PART 是零件還是半成品就定義在 PART TYPE，而 PART ASSOCIATION 就記錄了每個PART 和每個 PART 彼此之間的關係。
這個Pattern 有多簡單呢？我們拿來套回組織樹就直接把ENTITY替換成ORGNIZATION就搞定了。
Workshop
學會了上述的Pattern之後，我們只要看到這種樹狀結構，或是像BOM表，或是Peer-to-Peer的關係就可以輕鬆套用這個Pattern。是不是很方便？是不是躍躍欲試？那我們馬上來現學現賣：假設你要設計高鐵票價表的Model，你可能會需要紀錄站與站之間的票價資訊，而票價又分商務艙、經濟艙、早鳥(65折、８折、９折...)，現在就動手畫看看吧。
