數據建模指的是對現實世界各類數據的抽象組織，確定資料庫需管轄的範圍、數據的組織形式等直至轉化成現實的資料庫。 將經過系統分析後抽象出來的概念模型轉化為物理模型後，在visio或erwin等工具建立資料庫實體以及各實體之間關係的過程（實體一般是表）。
在軟體工程中，數據建模是運用正式的數據建模技術，建立信息系統的數據模型的過程。
基本介紹
- 中文名：數據建模
- 外文名：data modeling
基本介紹,分類,主要活動,如何進行,概念建模,概念建模階段,邏輯建模,物理建模,建立過程,
基本介紹
數據建模是一種用於定義和分析數據的要求和其需要的相應支持的信息系統的過程。因此，數據建模的過程中，涉及到的專業數據建模工作，與企業的利益和用戶的信息系統密切相關。
從需求到實際的資料庫，有三種不同的類型。用於信息系統的數據模型作為一個概念數據模型，本質上是一組記錄數據要求的最初的規範技術。數據首先用於討論適合企業的最初要求，然後被轉變為一個邏輯數據模型，該模型可以在資料庫中的數據結構概念模型中實現。一個概念數據模型的實現可能需要多個邏輯數據模型。數據建模中的最後一步是確定邏輯數據模型到物理數據模型中到對數據訪問性能和存儲的具體要求。數據建模定義的不只是數據元素，也包括它們的結構和它們之間的關係。
分類
1、使用計算機描述一個系統的行為。例如，電子表格程式可以用來處理財務數據，代表公司的行為；開發商業計畫；評估公司經營改變可能造成的影響。
主要活動
建模過程中的主要活動包括：
確定數據及其相關過程（如實地銷售人員需要查看線上產品目錄並提交新客戶訂單）。
定義數據（如數據類型、大小和默認值）。
確保數據的完整性（使用業務規則和驗證檢查）。
定義操作過程（如安全檢查和備份）。
選擇數據存儲技術（如關係、分層或索引存儲技術）。
一定要知道建模通常會以意想不到的方式涉及公司的管理。例如，當對哪些數據元素應由哪些組織來維護有新的見解時，數據所有權（以及數據維護、準確性和及時性的隱含責任）通常會遭到質疑。數據設計常常促使公司認識到企業數據系統是如何相互依存的，並且鼓勵公司抓住協調後的數據規劃所帶來的效率提高、成本節約和戰略性機遇。
在結束建模時，您已經完全定義了應用程式的要求，確定了可能被其他企業級應用程式重複使用的數據和服務，並為將來擴展奠定了強有力的基礎。
如何進行
概念建模
數據建模大致分為三個階段，概念建模階段，邏輯建模階段和物理建模階段。其中概念建模和邏輯建模階段與資料庫廠商毫無關係，換言之，與MySQL，SQL Server，Oracle沒有關係。物理建模階段和資料庫廠商存在很大的聯繫，因為不同廠商對同一功能的支持方式不同，如高可用性，讀寫分離，甚至是索引，分區等。
概念建模階段
實際工作中，在概念建模階段，主要做三件事：
1. 客戶交流
2. 理解需求
3. 形成實體
這也是一個疊代，如果先有需求，儘量去理解需求，明白當前項目或者軟體需要完成什麼，不明白或者不確定的地方和客戶及時交流，和客戶double confirm過的需求，落實到實體（Package）；但是好多時候我們需要通過先和客戶交流，進而將交流結果落實到需求，之後進一步具體到實體；本文可能會涉及到一些來自於EA（Enterprise Architect 7.1）建模術語，（EA中將每個實體視為一個Package）。這裡並不對各種建模工具進行比較，如Visio，EA，PowerDesigner， ERWin等；其實作為員工的我們選擇性很少，公司有哪個產品的Licence，我們就用哪個吧。
舉例說明：在一個B2C電子商務網站中，這樣的需求再普通不過了：客戶可以在該網站上自由進行購物！我們就以這個簡單例子，對其進行細分，來講解整個數據建模的過程，通過上面這句話，我們可以得出三個實體：客戶，網站，商品；就像Scrum（敏捷開發框架的一種）中倡導的一樣每個Sprint，都要產出確確實實的東西，OK，概念建模階段，我們就要產出實體。客戶和商品（我們將網站這個實體扔掉，不需要它。）
在創建這兩個實體（Package）的時候，我們記得要講對需求的理解，以及業務規則，作為Notes添加到Package中，這些信息將來會成為數據字典中非常重要的一部分，也就是所謂的元數據。BTW，EA或者其他建模工具應該都可以自動生成數據字典，只不過最終生成的格式可能不太一樣。如在Customer這個Package的Notes上，我們可以這樣寫，用戶都要通過填寫個人基本信息以及一個信箱來註冊賬戶，之後使用這個信箱作為登錄帳號登錄系統進行交易。
在概念建模階段，我們只需要關注實體即可，不用關注任何實現細節。很多人都希望在這個階段把具體表結構，索引，約束，甚至是存儲過程都想好，沒必要！！因為這些東西使我們在物理建模階段需要考慮的東西，這個時候考慮還為時尚早。可能有的人在這個階段擔心會不會丟掉或者漏掉一些實體?也不用擔心，2013年好多公司都在採用Scrum的開發模式，只要你當前抽象出來的實體滿足當前的User Story，或者當前的User Story裡面的實體，你都抽象出來了，就可以了！如果你再說，我們User Story太大，實體太多，不容易抽象，那就真沒辦法了，建議你們的團隊重新開Sprint 計畫會議。
邏輯建模
對實體進行細化，細化成具體的表，同時豐富表結構。這個階段的產物是，可以在資料庫中生成的具體表及其他資料庫對象（包括，主鍵，外鍵，屬性列，索引，約束甚至是視圖以及存儲過程）。我在實際項目中，除了主外鍵之外，其他的資料庫對象我都實在物理建模階段建立，因為其他資料庫對象更貼近於開發，需要結合開發一起進行。如約束，我們可以在web page上做JavaScript約束，也可以在業務邏輯層做，也可以在資料庫中做，在哪裡做，要結合實際需求，性能以及安全性而定。
針對Customer這個實體以及我們對需求的理解，我們可以得出以下幾個表的結構，用戶基本信息表（User），登錄賬戶表（Account），評論表（Commnets,用戶可能會對產品進行評價），當然這個案例中我們還會有更多的表，如用戶需要自己上傳頭像（圖片），我們要有Picture表。
針對產品實體，我們需要構建產品基本信息表（Product），通常情況下，我們產品會有自己的產品大類（ProductCategory）甚至產品小類（ProductSubCategory），某些產品會因為節假日等原因進行打折，因為為了得到更好的Performance我們會創建相應ProductDiscount表，一個產品會有多張圖片，因此產品圖片表（ProductPicture）以及產品圖片關係表（ProductPictureRelationship），（當然我們也可以只設計一張Picture表，用來存放所有圖片，用戶，產品以及其他）有人說產品和圖片是一對多的關係，不需要創建一個關係表啊?是的，我認為只要不是一對一的關係，我都希望創建一個關係表來關聯兩個實體。這樣帶來的好處，一是可讀性更好，實現了實體和表一一對應的關係，二是易於維護，我們只需要維護一個關係表即可，只有兩列（ProductID和PictureID），而不是去維護一個Picture表。
客戶進行交易，即要和商品發生關係，我們需要Transaction表，一個客戶會買一個或者多個商品，因為一筆Transaction會涉及一個或多個Products，因此一個Transaction和ProductDiscount之間的關係（ProductDiscount和Product是一一對應的關係）需要創建，我們稱其為Item表，裡面保存TransactionID以及這筆涉及到的ProductDiscountID（s），這裡插一句，好多系統都需要有審計功能，如某個產品歷年來的打折情況以及與之對應的銷售情況，我們這裡暫不考慮審計方面的東西。
就這樣，我們根據需求我們確定下來具體需要哪些表，進一步豐富每一個表屬性（Column），當然這裡面會涉及主鍵的選取，或者是使用代理鍵（Surrogate Key），外鍵的關聯，約束的設定等細節，這裡筆者認為只要能把每個實體屬性（Column）落實下來就是很不錯了，因為隨著項目的開展，很多表的Column都會有相應的改動。至於其他細節，不同資料庫廠商，具體實現細節不盡相同。關於主鍵的選取多說一句，有的人喜歡所有的表都用自增長ID作為主鍵，而有的人希望找到唯一能標識當前記錄的一個屬性或者多個屬性作為主鍵；自增長ID作為代理主鍵，對於將來以多個類似當前Transaction System作為數據源，構建數據倉庫的時候，這些自增長ID主鍵會是一個麻煩（多個系統中，相同表存在大量主鍵重複）；使用一個屬性或多個屬性作為作為主鍵，不管主鍵是可編輯的，讀寫效率是我們必須考慮得。所以並沒有一個放之四海而皆準的原則，筆者只是給大家推薦一些考慮的因素。
物理建模
EA可以將在邏輯建模階段創建的各種資料庫對象生成為相應的SQL代碼，運行來創建相應具體資料庫對象（大多數建模工具都可以自動生成DDL SQL代碼）。但是這個階段我們不僅僅創建資料庫對象，針對業務需求，我們也可能做如數據拆分（水平或垂直拆分），如B2B網站，我們可以將商家和一般用戶放在同一張表中，但是針對PERFORMANCE考慮，我們可以將其分為兩張表；隨業務量的上升，Transaction表越來越大，整個系統越來越慢，這個時候我們可以考慮數據拆分，甚至是讀寫分離（即實現MASTER-SLAVE模式，MYSQL/SQLSERVER可以使用Replication，當然不同存儲引擎採用不同的方案），這個階段也會涉及到集群的事情，如果你是架構師或者數據建模師，這個時候你可以跟DBA說，Alright,I am done with it,now is your show time.
相信大家都知道範式，更有好多人把3NF奉為經典，3NF確實很好，但是3NF是幾十年前提出來的，那個時候的數據量以及訪問頻率和2012年完全不是一個數量級的；因此我們絕對不能一味地遵守3NF；在整個數據建模過程中，在保證數據結構清晰的前提下，儘量提高性能才是我們關注的要點，因此筆者大力倡導數據適當冗餘!
上面筆者是結合一些實際例子表達自己對數據建模的觀點，希望對讀著有用。在數據建模過程中，不要希望一步到位將資料庫設計完整，筆者不管是針對data warehouse還是Transactional Database設計，從來沒有過一次成功的經歷。隨著項目的進行，客戶和開發團隊對業務知識與日增長，因此原來的設計也在不斷完善中。畢竟，數據建模或者設計資料庫不是我們的最終目的，我們需要的是一個健壯，性能優越，易擴展，易使用的軟體！
建立過程
選擇變數與重構變數
在進行建模之前，首先要考慮的是使用哪些變數來建立模型，需要從業務邏輯和數據邏輯兩個方面來考慮：
業務邏輯：變數基於收集到的數據，而數據在收集時，會產生與業務層面相關的邏輯。
數據邏輯：通常從數據的完整性、集中度、是否與其他變數強相關（甚至有因果關係）等角度來考慮，比如某個變數在業務上很有價值，但缺失率達到90%，或者一個非布爾值變數卻集中於兩個值，那么這個時候我們就要考慮，加入這個變數是否對後續分析有價值。
在選擇變數時，業務邏輯應該優先於數據邏輯，蓋因業務邏輯是從實際情況中自然產生，而建模的結果也要反饋到實際中去，因此選擇變數時，業務邏輯重要程度相對更高。
而在變數本身不適合直接拿來建模時，例如調查問卷中的滿意度，是漢字的“不滿意”“一般”“滿意”，那么需要將其重構成“1”（對應不滿意）“2”（對應一般）“3”（對應滿意）的數字形式，便於後續建模使用。
除這種重構方式之外，將變數進行單獨計算（如取均值）和組合計算（如A*B）也是常用的重構方法。其他的重構方法還有很多種。
選擇算法
我們在建模時，目標是解決商業問題，而不是為了建模而建模，故此我們需要選擇適合的算法。常用建模算法包括相關、聚類、分類（決策樹）、時間序列、回歸、神經網路等。
以對消費者的建模為例，舉一些場景下的常用算法對應：
劃分消費者群體：聚類，分類；
購物籃分析：相關，聚類；
購買額預測：回歸，時間序列；
滿意度調查：回歸，聚類，分類；
等等。
確定算法後，要再看一下變數是否滿足算法要求，如果不滿足，回到選擇/重構變數，再來一遍。如果滿足，進入下一步。
設定參數
算法選定後，需要用數據分析工具進行建模。針對不同的模型，需要調整參數，例如聚類模型中的K-means算法，需要給出希望聚成的類別數量，更進一步需要給出的起始的聚類中心和疊代次數上限。
這些參數在後續測試中會經過多次調整，很少有一次測試成功的情況。
載入算法與測試結果
算法跑完之後，要根據算法的輸出結果來確定該算法是否能夠解決問題，比如K-means的結果不好，那么考慮換成系統聚類算法來解決。或者回歸模型輸出的結果不滿足需求，考慮用時間序列來做。
如果不需要換算法，那么就測試一下算法輸出的結果是否有提升空間，比如聚類算法中指定聚類結果包含4類人群，但發現其中的兩類特徵很接近，或者某一類人群沒有明顯特徵，那么可以調整參數後再試。
在不斷的調整參數，最佳化模型過程中，模型的解釋能力和實用性會不斷的提升。當你認為模型已經能夠滿足目標需求了，那就可以輸出結果了。一個報告，一些規則，一段代碼，都可能成為模型的輸出。在輸出之後，還有最後一步：接收業務人員的反饋，看看模型是否解決了他們的問題。
以上，就是建模的一般過程。
