【Domain Model】從 PPAP 牽拖 Recursive Pattern

 

最近由一位大叔自創的洗腦神曲 PPAP 在網路上流傳,也引起大量的Kuso與模仿。剛好最近在準備Domain Model的課程,發現這首歌的情境剛好可以套(牽)用(拖)到 Recursive Pattern,這樣牽拖會太遠嗎?讓我們繼續看下去。

話說幾年前面試一位有開發ERP經驗的系統分析師,由於他是負責生產製造領域的,就請他說明一下他們的零組件、半成品、成品…的Table怎麼開(基本上就是考他對BOM表的了解)。他在白板上很有自信的畫了類似的下圖的Model,有一個成品檔,一個半成品檔,一個零組件檔,看起來應有盡有。接下來我就問他半成品可能會由多個零組件組成,每個零組件有可能會是多個半成品的組成零件,而且半成品A也可能和另一個半成品B再組合成半成品C,更不用說成品也可能是由半成品和零件組合而成。我已經忘了他後來在白板上畫了多少線,總之,這很明顯不是很穩定的設計。

bom_wrong

回到前面的PPAP 也可以想成是BOM表的概念,
ppap
Pen * 1 + Apple * 1 = ApplePen
Pen * 1 + Pineapple * 1 = PineapplePen
ApplePen * 1 + PineapplePen * 1 = PenPinappleApplePen

 

這個看起來很像樹狀結構,有經驗的分析師一看就可以類比成像組織樹一樣,不管是Pen, Apple, Pineapple, 甚至是最後的 PPAP就像組織樹裡的科/課/股、局/處/室,每個組織多一個欄位記錄上層組織就可以了(如下圖)。

org_1

一般情況下,同一個單位的上層單位只會有一個;但有經驗的讀者就知道,每個公司裡可能會有很多種組織樹,有些是正規的組織樹,有些是簽核流程用的樹,如果每多一棵樹,就要加一個欄位去記錄組織的上層組織。

更何況,比較細心的讀者可能已經發現,這張圖和組織樹的差別在於,Pen出現了2次,這在單一組織樹裡是不會發生的,同一個單位不會同時掛在兩個組織下,光這一點就會讓這個Model不知道怎麼把樹長出來。

幸好,這種情況也不是今天才發生,早就有人整理出超實用的 【Recursive Pattern】 (Len Silverston, Paul Agnew.(2008). The Data Model Resource Book: Volume 3: Universal Patterns for Data Modeling.WILEY. )來解決這一連串的問題:

recursive

以前面的例子來說,每個零組件、半成品、成品,本質上都是零組件,彼此之間可以組合成另一個零組件,除了組合的關係外,也可能會再有其它關係,如:替代(沒有原子筆時可以用鉛筆?)。所以把上述 Pattern  的 ENTITY 替換成 PART,至於這個PART 是零件還是半成品就定義在 PART TYPE,而 PART ASSOCIATION 就記錄了每個PART 和每個 PART 彼此之間的關係。

part_model

這個Pattern 有多簡單呢?我們拿來套回組織樹就直接把ENTITY替換成ORGNIZATION就搞定了。

org_model

Workshop

學會了上述的Pattern之後,我們只要看到這種樹狀結構,或是像BOM表,或是Peer-to-Peer的關係就可以輕鬆套用這個Pattern。是不是很方便?是不是躍躍欲試?那我們馬上來現學現賣:假設你要設計高鐵票價表的Model,你可能會需要紀錄站與站之間的票價資訊,而票價又分商務艙、經濟艙、早鳥(65折、8折、9折…),現在就動手畫看看吧。

 

 

作者: 刀疤叔愛牽拖

刀疤-英勇的勳章 牽拖-小強的剋星 -刀疤叔愛牽拖-

【Domain Model】從 PPAP 牽拖 Recursive Pattern 有 “ 2 則迴響 ”

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *