?

?????????最近逛書店發現一本數據建模的好書——《數據建模：分析與設計的工具和技巧》(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)返回步驟二，直到完成所有的關系。

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

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

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

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

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

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