資料模型的溝通

必須承認，自己在溝通方面的表現實在很差勁。

早在幾個月前，我就曾談過了一些自己對於「官職表資料模型」的看法（可參考 官職表：行政組織與任職人員 與 官職表的模型問題）。我也曾嘗試與老師、實驗室成員溝通自己的想法，但很可惜地都不怎麼成功。

隨著時間的流逝，慢慢地實驗室終於有人必須面對資料模型的問題。八月底的實驗室會議，學弟被老師罵到臭頭，在我看來也是因為溝通不良的緣故。

溝通本來就不是一件容易的事。但是為什麼連學術殿堂上的專業溝通，都顯得如此吃力呢？我漸漸地認為，一個頗重要的原因，是在於「溝通者所關注的焦點不同，卻使用類似的語彙」。

什麼意思呢？且讓我嘗試用以下的圖來解釋（這裡套用的詞彙，是自己左思右想後，覺得比較合適的。雖然我覺得，應該早就存在類似的圖表來解說 data modeling 的問題，但手頭實在也找不到這樣的資訊，就先誇大地說是自己的發現吧）。


項老師在理論方面（Abstract Model 的部分）非常拿手。在主導 THDL（台灣歷史數位圖書館）計畫多年後，他也明瞭資料建構的困難（人工建置、修訂 metadata 的成本極高）。但麻煩出在，即使有了抽象模型，也建構了適當的基礎資料；但一碰上實作，還是會產生很多系統開發、效能、以及後續維護改進的問題。

學弟挨罵的原因，是因為資料庫儲存地名資訊的每一列，id 都是用 a.b.c.d 這樣的編碼方式，來表示地名間的階層關係。老師認為，將階層關係直接寫在資料庫裡，將會失去資料建構的彈性：如果以後發現在節點 b 與 c 之間，還有一個節點 x，那麼不是整個資料表都需要重新建置嗎？

換句話說，項老師以為，資料表是由 Excel 之類人工建立的表單（contruction model）直接對應產生。因此，「將階層資訊編碼在 id 欄位」，就表示在 Excel 的表單裡，每一列都需要人工建置這樣的階層編碼。

但其實，階層編碼不必然都是由人工所產生的。如果有良好的建構模型，我們可以寫程式（上圖齒輪的部分），在彙整建構模型所提供的資訊時，自動產生這樣的編碼。

此外，實作上用關聯式資料庫來處理階層資訊，有時反而必須在效率上付出代價。因此若階層資訊是靜態的，深度也並不大，直接把階層資訊編碼在欄位裡，或許反而是合宜的處理方式呢。

於是，結果是溝通時大家關心不同的地方，但都用同樣的「模型」一詞（沒有區分各種模型），以致類似「雞同鴨講」了。老師關心資料建構的問題，但學弟只展示系統的運作方式 (application model)，以及秀出資料庫的資料表 (implementation model)，卻並沒有好好地說明建構的模型（原始資料該用什麼格式儲存有什麼欄位、該如何將這些資訊彙整入資料庫）！

上星期五我花了許多時間，利用上面的圖表，向兩位學弟說明「官職表」與「地名沿革」的資料模型問題。最後，他們表示同意我的想法與觀點。最近對於自己的溝通能力已經沮喪到不行，能夠得到一些正面的回應，還真很令人感到高興呢。