轉《“資料建模”讀書筆記 》

最近逛書店發現一本資料建模的好書--《資料建模：分析與設計的工具和技巧》(Data Modeler's Workbench：Tools and Techniques for Analysis and Design)，作者Steve Hoberman。粗讀完一遍後，感覺這本書的確無愧於譯者和國外專家們的盛讚："這本書充滿了對改進資料模型和設計有益的技術和技巧，並且它還極富閱讀樂趣--一個了不起的結合！任何一個資料建模者都應該擁有一本Steve Hoberman的關於資料建模工具和技術的書。"

　　儘管我對自己所掌握的資料建模知識有一定的自負，讀完該書後，還是獲益良多。本著好書大家一起分享的想法，我把該書的每個章節的總結和技巧建議列出來，以方便手頭暫時沒有該書的朋友在資料建模時參考。該書所介紹的工具和模版可在作者的Web網站下載，地址是：
　　www.wiley.com/compbooks/hoberman

　　第一章：使用趣聞、類比和簡報來闡明資料建模的概念

　　在一般的日常溝通中。我們可能會說出並聽到許多故事、或者趣聞這些故事涉及的論題範圍很大。有些例子是周末發生在我們自己身邊的事情，或者是與我們的工作項目有關的經曆。這些趣聞有助於加強我們和周圍人們的關係，增進我們的愉悅情緒，而且對我們有教育作用。我們能夠把由語言表達出來的東西形象化。有時，當故事結束時，給我們留下的是以前未曾想到的資訊或更多的認識。在解釋資料建模概念時，趣聞是極其有效。原因有如下幾個：
　　它們建立起持久的形象。
　　它們引人入勝、使人愉悅。
　　它們增經人們之間的關係。
　　它們減緩壓力。

　　成功編造並講述一個資料建模方面的趣聞有下面三個簡單的步驟：
　　1)定義一個論題。要在心中保證，你講述的這個趣聞有一個特定的目標或論題，也就是說，這個故事是為瞭解釋一個資料建模的概念或術語。
　　2)選擇你的故事。我們可以選擇的故事類型多種多樣。我們要考慮選擇一個有趣並有益，而且能夠明白無誤地傳達主題意圖的簡短的故事。
　　3)演練你的故事。一旦找到了合適的故事，你要好好演練一番，直到你自信它能夠在兩分鐘的時間內充分表達你的論題。要避免講述拖拖拉拉的故事。

　　資料模型類比
　　類比就是把兩個或多個概念進行相互比較，以強調它們之間的相似或差異。類比是介紹外來事物或新鮮事物的一個很好的技巧，尤其是向非電腦專業的人士介紹電腦的專業知識時。Hoberman在資料建模中最常見的幾個類比如下（他用這些類比輕鬆的打動管理層給他漲了一倍的工資^_^）：
　　主體領域模型是一個居高臨下的視點。
　　資料模型是一個設計圖。
　　企業模型是一個世界地圖。
　　標準就是城市規劃。
　　中繼資料倉儲庫是一個圖書館。
　　資料倉儲是"心臟"。

　　第二章：中繼資料賓果遊戲
　　簡單來說，即通過賓果卡片遊戲的方式，調動項目團隊成員的積極性，來確定資料模型，並確定中繼資料的有效性。中繼資料賓果遊戲強調"共贏"，如果運氣好，遊戲結束時每個人都能贏。

　　第三章：確保高品質的定義
　　本章集中討論一個被稱為"定義檢查單"(Definition Checklist)的工具，它包含了確保定義的品質處於最高水平的準則。

　　第四章：資料建模者的專案計劃
　　本章重點介紹確定資料建模階段、任務、工具和時限的四個工具：
　　·資料建模階段的工具：用來確定最高層次上的資料建模步驟。
　　·階段-任務-工具：提取出"資料建模階段"的各個階段並把他們分解成資料建模任務。
　　·優先順序三角形：你可以從以下三項中取兩項極值：很高的品質、最短的時間與最低的成本，但你永遠也別想三者兼得。
　　·可靠的估算工具："主體域工作量時限"根據應用程式的類型，確定每個資料建模階段應占整個項目的百分比。"任務工作量工具"提取在"階段-任務-工具"中確定的每項任務，並列出它們應占整個資料建模工作產品的百分比。這兩個工具的組合可使你向專案經理提供一份具有一定精確度的合理估算。

　　第五章：主體域分析
　　本章主要探討五個關鍵的工具，這五個工具對資料建模工作的主體域分析階段有幫組作用。它們應該按照下面的順序被逐個完成：
　　1)主體域檢查單：新應用程式中的主體域的完整列表，還有各個主體域的定義和同義字（或別名）。
　　2)主體域CRUD(Create Read Update Delete)矩陣：包含新應用程式和現有應用程式之間的主體域方面的差別和重複之處，確定應用程式的範圍。
　　3)In-the-Know模版：確定完成這個新應用程式的資料間模工作產品所需要的、被用作資源的人員和文檔。
　　4)主體域家族樹：包含每一個主體域的源應用程式和若干其他的關鍵資訊，闡明主體域資料將來自哪裡。
　　5)主體域力度矩陣：使用一個試算表的格式，記錄每一個度量和事實主體域的發布層次。

　　第六章：主體域建模
　　本章闡述三個隊主體域資訊進行建模的強大工具：
　　·"業務清理板"模型。
　　·"應用程式清理板"模型。
　　·"早期現實性檢查"模型。

　　第七章：邏輯資料分析
　　本章關注四個邏輯資料分析工具，它們應該按照下面的次序被使用：
　　1)資料元素家族樹：包含應用程式的資料元素的完整列表，以及每個資料元素的來源和變換資訊，還有其他幾個關鍵的資料元素中繼資料。
　　2)資料元素粒度矩陣：用一個試算表的格式，來記錄每個度量和事實的發布層次。
　　3)資料品質記錄模板：展示每個資料元素的員資料和一些實際資料的對比。
　　4)資料品質確認模板：記錄每個資料元素的中繼資料和一些實際資料的對比的結果。

　　第八章：正常化之旅和反向正常化生存指南（強烈推薦：是我目前所讀過最好的關係型資料庫的正常化技術文檔）
　　正常化是一個剔除冗餘並應用規則的過程，它的目的是為了更好的理解和表達存在於資料元素之間的依賴性和參與性。正常化包含6個層次，最高層是第五範式(5NF)。一般的技術文檔上都認為達到3NF即可，Steve Hoberman給我們指明了更高的目標：5NF。Graeme Simsion寫過一本名為《Data Modeling Essentials》的書，在這本書中，他寫道："較高層次的範式常被從業者誤解並因此而被忽視，或為了支援不可靠的建模時間而被引用。"但是，我們需要理解這些較高層次的正常化，因為它們體現了額外的正常化機會，並幫組我們進一步減少冗餘資訊、改進設計的靈活性。儘管餘下的三個正常化層次有可能僅僅產生次數很少的變化，但它們仍然具有一些提高靈活性和效率的機會。下面是BCNF&4NF&5NF的定義(比國內教材上羅列的數學公式容易理解得多^_^)：
　　BCNF=3NF＋下面的規則：
　　每一個資料元素都完全依賴於鍵、整個鍵，而且除依賴於這個鍵以外，不依賴於任何其他資料元素。
　　4NF=3NF+下面的規則：
　　要把主鍵中擁有三個或更多外建資料元素、切割格外鍵之間不存在約束的那些實體分解成兩個或更多個實體。
　　5NF=4NF+下面的規則：
　　把主鍵中擁有三個或更多的外鍵資料元素，且這些外鍵資料元素之間存在著約束的實體分解成為所有的約束都需要的多對多的關係。

　　當我們攀上5NF的頂峰後，再根據實際需求情況來進行"反向正常化"增加資料冗餘，從而簡化開發，提高查詢速度。反向正常化是這樣一個過程：在定義了一個可靠的、完全正常化了的資料結構之後，你藉助這個過程，有選擇地引入一些重複的資料，以促進特殊效能需求的實現。Steve Hoberman的"反向正常化生存指南"給如何適當增加冗餘提供了一套可計算的評分標準。通過考察每個關係的6個問題，累加各個問題的得分之後，當得分大於等於10時，我們將對該關係進行反向正常化。

　　"反向正常化生存指南"的計分規則：
　　1.關係是什麼類型的：該問題確定我們所分析的關係的類型。父實體對於子實體具有什麼樣的關係？
　　層次關係(20分)
　　同等關係(-10分)
　　確定關係(-20分)
　　2.參與率是多少：該問題確定一個關係中的每個實體的參與性。換句話說，對於一個給定的父實體數值，大概會有幾個子實體數值？父與子的關係越接近"一對一"，我們對它進行反向正常化的機會就越大。
　　多達"一對五"的比率(20分)
　　多達"一對一百"的比率(-10分)
　　超過"一對一百"的比率(-20分)
　　3.父實體中有多少個資料元素
　　少於10個資料元素(20分)
　　資料元素的數量介於10到20之間(-10分)
　　多於20個資料元素(-20分)
　　4.使用率是多少：當使用者需要來自子的資訊時，通常情況下，它們是否還需要來自父的資訊呢？換句話說，這兩個實體的耦合或相關程度如何？
　　相互之間的關聯很強(30分)
　　相互之間的關聯較弱或者沒有關聯(-30分)
　　5.父實體時一個預留位置嗎：在不遠的將來，我們是否還打算向父實體加入更多的資料元素或關係？如果答案是"不"，那麼進行反向正常化的可行性就更強。
　　是(20分)
　　不(-20分)
　　6.變動對比率是多少：該問題是為了確定，在同一時間周期內，兩個實體的插入和更新的頻度是否相近。如果其中一個實體很少變化，而另一個實體卻變動頻繁，那麼，我們就非常傾向於保持它們的正常化狀態，把它們放在各自的表中。
　　相同(20分)
　　不同(-20分)

　　"反向正常化生存指南"的使用方法：
　　1)把模型中的關係按照優先順序排序
　　2)選擇一個關係
　　3)對這個關係回答提問
　　4)如果得分等於或大於10，就進行反向正常化
　　5)返回步驟二，直到完成所有的關係。

　　第九章：抽象化安全指南和組件
　　看過我的"淺談資料庫設計技巧(上) "的朋友應該還記得我舉的第二個例子：網上電子商務平台上的商品資訊表的設計。本章將我在上面例子中所用的方法上升到了理論階段，採用了物件導向的設計，將所有商品的共有屬性提取出來，抽象成一個超類，再加入一個表來記錄各個不同實體之間的細節來實現超類的派生，從而實現設計的靈活性。當出現下面兩種條件的任何場合，抽象化都是極其有用的：
　　設計需要永久維持下去：要求以後儘可能的不修改資料庫設計
　　需求可能發生變化：應用程式的需求發生變化，而要求商務程序重組或進行功能更新
　　資料倉儲：當新的分類類型從源應用程式中傳過來時，我們無須對資料倉儲的設計進行任何改動，而只需在分類類型實體加入一個新行即可
　　中繼資料倉儲庫：和資料倉儲的要求類似

　　當然，抽象化會大大增加工作量和開發的複雜度，而人們通常關注的是非常短期的應用和眼前的成本，而不關心將來的高得多的成本。所以，我非常贊同敏捷式軟體開發 (Agile Software Development)這個觀點：在最初幾乎不進行預先設計，但是一旦需求發生變化，此時作為一名追求卓越的程式員，應該從頭審查整個架構設計，在此次修改中設計出能夠滿足日後類似修改的系統架構。

　　"抽象組件"就是小型的抽象模型片段，在許多的建模場合(無論是什麼行業、組織，甚至什麼主體域的建模場合)中，它們都可被反覆使用。在鍵模階段多次使用抽象化之後，你將開始看到出現的抽象化結構的趨勢。這些"抽象組件"有如下的目的：
　　加快設計速度
　　加快開發速度
　　提供通用且有用的機構

　　第十章：資料模型美化技巧
　　本章通過關注如何改進邏輯和物理資料模型的視覺外觀，使我們的設計超越直接的應用程式需求。本章中討論了五個類別的美化技巧：
　　邏輯資料元素排列技巧：這些技巧是一個推薦的、對你的邏輯資料模型中的每一個實體的資料元素進行排序的方法。
　　物理資料元素排序技巧：這些技巧關注資料模型中每一個實體的最佳布局。
　　實體布局技巧：這些技巧關注資料模型中的每一個實體的最佳布局
　　關係布局技巧：這些技巧關注如何調整重疊的關係線條以及看起來穿越（而不是繞過）無關實體的關係
　　吸引注意力的技巧：這些技巧關注如何在我們的涉及中突出的某些元素、實體或關係。

　　第十一章：規劃一個長盛不衰的資料建模生涯
　　對資料建模者的十大忠告清單：
　　1)記住：靈活性、準確性和背景
　　2)建模只是你的工作的一小部分
　　3)嘗試其他角色
　　4)瞭解95/5規則：95%的時間將花費在5%的資料元素上
　　5)資料建模從不令人厭煩：如果你一直在做資料建模工作，而且發現自己經常感到厭煩，那麼，你的確該改變一下了。這可能不是資料建模領域本身令人厭煩，而是你所在的特定的任務、公司或行業不再令人興奮。冒險一下，嘗試著道一個不同的項目或行業中進行資料建模工作吧！
　　6)站在技術前沿
　　7)盡量不要在模型上牽扯感情因素：建模者必須理解，人們在評審過程中的意見並不是針對模型的建立者，而是針對這個模型的內容。即那句老話：對事不對人。
　　8)讓你的創造力展開翅膀：在考慮記錄資料需求和改進設計的新方法時，要緊可能有創造性。有創造性也許就意味著修改本書中的某些工具。這還可能意味著提出你自己的試算表或其他工具。
　　9)單純的理論太昂貴了：在設計活動過程中，你要確保把這個觀點牢記在心。為這個應用程式掏腰包的部門和組織期望看到的是能看得著的實用結果。
　　10)成為一個了不起的會講故事的人：作為一名資料建模者，講故事是工作的一個很重要的部分。為了幫組教化和影響專案經理以及對我們行業缺乏理解的其他人，我們需要講故事或趣聞。

　　最後，我個人覺得，Steve Hoberman所提出的"抽象組件"的觀念和物件導向設計中的的"設計模式"非常類似。即資料庫專家在多次的資料建模後，將各個項目中的類似部分抽象化，提取出特定的建模模型片段，以後只需在新的項目中對這些模型片段細化派生，即可快速構建出適合於該項目的資料庫結構描述。不過，這些建模模型片段並沒有統一，形成標準，目前也沒有出版這類的書籍。本人正在陸續總結自己在這方面的經驗，但是自知水平有限，不敢在高人面前班門弄斧，只希望自己日後陸續發布的相關文章能起到拋轉引玉的作用，爭取由中國的程式員率先統一出資料建模領域的"設計模式"。