[科普中國]-數(shù)據(jù)建模

概述

數(shù)據(jù)建模是一種用于定義和分析數(shù)據(jù)的要求和其需要的相應(yīng)支持的信息系統(tǒng)的過程。因此，數(shù)據(jù)建模的過程中，涉及到的專業(yè)數(shù)據(jù)建模工作，與企業(yè)的利益和用戶的信息系統(tǒng)密切相關(guān)。

從需求到實(shí)際的數(shù)據(jù)庫，有三種不同的類型。用于信息系統(tǒng)的數(shù)據(jù)模型作為一個概念數(shù)據(jù)模型，本質(zhì)上是一組記錄數(shù)據(jù)要求的最初的規(guī)范技術(shù)。數(shù)據(jù)首先用于討論適合企業(yè)的最初要求，然后被轉(zhuǎn)變?yōu)橐粋€邏輯數(shù)據(jù)模型，該模型可以在數(shù)據(jù)庫中的數(shù)據(jù)結(jié)構(gòu)概念模型中實(shí)現(xiàn)。一個概念數(shù)據(jù)模型的實(shí)現(xiàn)可能需要多個邏輯數(shù)據(jù)模型。數(shù)據(jù)建模中的最后一步是確定邏輯數(shù)據(jù)模型到物理數(shù)據(jù)模型中到對數(shù)據(jù)訪問性能和存儲的具體要求。數(shù)據(jù)建模定義的不只是數(shù)據(jù)元素，也包括它們的結(jié)構(gòu)和它們之間的關(guān)系1。

分類1、使用計(jì)算機(jī)描述一個系統(tǒng)的行為。例如，電子表格程序可以用來處理財(cái)務(wù)數(shù)據(jù)，代表公司的行為；開發(fā)商業(yè)計(jì)劃；評估公司經(jīng)營改變可能造成的影響。

2、使用計(jì)算機(jī)以數(shù)學(xué)方法描述物體和它們之間的空間關(guān)系。例如，計(jì)算機(jī)輔助設(shè)計(jì) (CAD) 程序可在屏幕上生成物體，使用方程式產(chǎn)生直線和形狀，依據(jù)它們相互之間及與所在的二維或三維空間的關(guān)系精確放置。

3、應(yīng)用程序和數(shù)據(jù)建模是為應(yīng)用程序確定、記錄和實(shí)現(xiàn)數(shù)據(jù)和進(jìn)程要求的過程。這包括查看現(xiàn)有的數(shù)據(jù)模型和進(jìn)程，以確定它們是否可被重復(fù)使用，并創(chuàng)建新數(shù)據(jù)模型和進(jìn)程，以滿足應(yīng)用程序的獨(dú)特要求。

主要活動建模過程中的主要活動包括：

確定數(shù)據(jù)及其相關(guān)過程（如實(shí)地銷售人員需要查看在線產(chǎn)品目錄并提交新客戶訂單）。

定義數(shù)據(jù)（如數(shù)據(jù)類型、大小和默認(rèn)值）。

確保數(shù)據(jù)的完整性（使用業(yè)務(wù)規(guī)則和驗(yàn)證檢查）。

定義操作過程（如安全檢查和備份）。

選擇數(shù)據(jù)存儲技術(shù)（如關(guān)系、分層或索引存儲技術(shù)）。

一定要知道建模通常會以意想不到的方式涉及公司的管理。例如，當(dāng)對哪些數(shù)據(jù)元素應(yīng)由哪些組織來維護(hù)有新的見解時，數(shù)據(jù)所有權(quán)（以及數(shù)據(jù)維護(hù)、準(zhǔn)確性和及時性的隱含責(zé)任）通常會遭到質(zhì)疑。數(shù)據(jù)設(shè)計(jì)常常促使公司認(rèn)識到企業(yè)數(shù)據(jù)系統(tǒng)是如何相互依存的，并且鼓勵公司抓住協(xié)調(diào)后的數(shù)據(jù)規(guī)劃所帶來的效率提高、成本節(jié)約和戰(zhàn)略性機(jī)遇。

在結(jié)束建模時，您已經(jīng)完全定義了應(yīng)用程序的要求，確定了可能被其他企業(yè)級應(yīng)用程序重復(fù)使用的數(shù)據(jù)和服務(wù)，并為將來擴(kuò)展奠定了強(qiáng)有力的基礎(chǔ)1。

如何進(jìn)行概念建模數(shù)據(jù)建模大致分為三個階段，概念建模階段，邏輯建模階段和物理建模階段。其中概念建模和邏輯建模階段與數(shù)據(jù)庫廠商毫無關(guān)系，換言之，與MySQL，SQL Server，Oracle沒有關(guān)系。物理建模階段和數(shù)據(jù)庫廠商存在很大的聯(lián)系，因?yàn)椴煌瑥S商對同一功能的支持方式不同，如高可用性，讀寫分離，甚至是索引，分區(qū)等。

概念建模階段實(shí)際工作中，在概念建模階段，主要做三件事：

1. 客戶交流

2. 理解需求

3. 形成實(shí)體

這也是一個迭代，如果先有需求，盡量去理解需求，明白當(dāng)前項(xiàng)目或者軟件需要完成什么，不明白或者不確定的地方和客戶及時交流，和客戶double confirm過的需求，落實(shí)到實(shí)體（Package）；但是好多時候我們需要通過先和客戶交流，進(jìn)而將交流結(jié)果落實(shí)到需求，之后進(jìn)一步具體到實(shí)體；本文可能會涉及到一些來自于EA（Enterprise Architect 7.1）建模術(shù)語，（EA中將每個實(shí)體視為一個Package）。這里并不對各種建模工具進(jìn)行比較，如Visio，EA，PowerDesigner， ERWin等；其實(shí)作為員工的我們選擇性很少，公司有哪個產(chǎn)品的Licence，我們就用哪個吧。

舉例說明：在一個B2C電子商務(wù)網(wǎng)站中，這樣的需求再普通不過了：客戶可以在該網(wǎng)站上自由進(jìn)行購物！我們就以這個簡單例子，對其進(jìn)行細(xì)分，來講解整個數(shù)據(jù)建模的過程，通過上面這句話，我們可以得出三個實(shí)體：客戶，網(wǎng)站，商品；就像Scrum（敏捷開發(fā)框架的一種）中倡導(dǎo)的一樣每個Sprint，都要產(chǎn)出確確實(shí)實(shí)的東西，OK，概念建模階段，我們就要產(chǎn)出實(shí)體。客戶和商品（我們將網(wǎng)站這個實(shí)體扔掉，不需要它。）

在創(chuàng)建這兩個實(shí)體（Package）的時候，我們記得要講對需求的理解，以及業(yè)務(wù)規(guī)則，作為Notes添加到Package中，這些信息將來會成為數(shù)據(jù)字典中非常重要的一部分，也就是所謂的元數(shù)據(jù)。BTW，EA或者其他建模工具應(yīng)該都可以自動生成數(shù)據(jù)字典，只不過最終生成的格式可能不太一樣。如在Customer這個Package的Notes上，我們可以這樣寫，用戶都要通過填寫個人基本信息以及一個郵箱來注冊賬戶，之后使用這個郵箱作為登錄帳號登錄系統(tǒng)進(jìn)行交易。

在概念建模階段，我們只需要關(guān)注實(shí)體即可，不用關(guān)注任何實(shí)現(xiàn)細(xì)節(jié)。很多人都希望在這個階段把具體表結(jié)構(gòu)，索引，約束，甚至是存儲過程都想好，沒必要?。∫?yàn)檫@些東西使我們在物理建模階段需要考慮的東西，這個時候考慮還為時尚早?？赡苡械娜嗽谶@個階段擔(dān)心會不會丟掉或者漏掉一些實(shí)體?也不用擔(dān)心，2013年好多公司都在采用Scrum的開發(fā)模式，只要你當(dāng)前抽象出來的實(shí)體滿足當(dāng)前的User Story，或者當(dāng)前的User Story里面的實(shí)體，你都抽象出來了，就可以了！如果你再說，我們User Story太大，實(shí)體太多，不容易抽象，那就真沒辦法了，建議你們的團(tuán)隊(duì)重新開Sprint 計(jì)劃會議2。

邏輯建模對實(shí)體進(jìn)行細(xì)化，細(xì)化成具體的表，同時豐富表結(jié)構(gòu)。這個階段的產(chǎn)物是，可以在數(shù)據(jù)庫中生成的具體表及其他數(shù)據(jù)庫對象（包括，主鍵，外鍵，屬性列，索引，約束甚至是視圖以及存儲過程）。我在實(shí)際項(xiàng)目中，除了主外鍵之外，其他的數(shù)據(jù)庫對象我都實(shí)在物理建模階段建立，因?yàn)槠渌麛?shù)據(jù)庫對象更貼近于開發(fā)，需要結(jié)合開發(fā)一起進(jìn)行。如約束，我們可以在web page上做JavaScript約束，也可以在業(yè)務(wù)邏輯層做，也可以在數(shù)據(jù)庫中做，在哪里做，要結(jié)合實(shí)際需求，性能以及安全性而定。

針對Customer這個實(shí)體以及我們對需求的理解，我們可以得出以下幾個表的結(jié)構(gòu)，用戶基本信息表（User），登錄賬戶表（Account），評論表（Commnets,用戶可能會對產(chǎn)品進(jìn)行評價），當(dāng)然這個案例中我們還會有更多的表，如用戶需要自己上傳頭像（圖片），我們要有Picture表。

針對產(chǎn)品實(shí)體，我們需要構(gòu)建產(chǎn)品基本信息表（Product），通常情況下，我們產(chǎn)品會有自己的產(chǎn)品大類（ProductCategory）甚至產(chǎn)品小類（ProductSubCategory），某些產(chǎn)品會因?yàn)楣?jié)假日等原因進(jìn)行打折，因?yàn)闉榱说玫礁玫腜erformance我們會創(chuàng)建相應(yīng)ProductDiscount表，一個產(chǎn)品會有多張圖片，因此產(chǎn)品圖片表（ProductPicture）以及產(chǎn)品圖片關(guān)系表（ProductPictureRelationship），（當(dāng)然我們也可以只設(shè)計(jì)一張Picture表，用來存放所有圖片，用戶，產(chǎn)品以及其他）有人說產(chǎn)品和圖片是一對多的關(guān)系，不需要創(chuàng)建一個關(guān)系表啊?是的，我認(rèn)為只要不是一對一的關(guān)系，我都希望創(chuàng)建一個關(guān)系表來關(guān)聯(lián)兩個實(shí)體。這樣帶來的好處，一是可讀性更好，實(shí)現(xiàn)了實(shí)體和表一一對應(yīng)的關(guān)系，二是易于維護(hù)，我們只需要維護(hù)一個關(guān)系表即可，只有兩列（ProductID和PictureID），而不是去維護(hù)一個Picture表。

客戶進(jìn)行交易，即要和商品發(fā)生關(guān)系，我們需要Transaction表，一個客戶會買一個或者多個商品，因?yàn)橐还PTransaction會涉及一個或多個Products，因此一個Transaction和ProductDiscount之間的關(guān)系（ProductDiscount和Product是一一對應(yīng)的關(guān)系）需要創(chuàng)建，我們稱其為Item表，里面保存TransactionID以及這筆涉及到的ProductDiscountID（s），這里插一句，好多系統(tǒng)都需要有審計(jì)功能，如某個產(chǎn)品歷年來的打折情況以及與之對應(yīng)的銷售情況，我們這里暫不考慮審計(jì)方面的東西。

就這樣，我們根據(jù)需求我們確定下來具體需要哪些表，進(jìn)一步豐富每一個表屬性（Column），當(dāng)然這里面會涉及主鍵的選取，或者是使用代理鍵（Surrogate Key），外鍵的關(guān)聯(lián)，約束的設(shè)置等細(xì)節(jié)，這里筆者認(rèn)為只要能把每個實(shí)體屬性（Column）落實(shí)下來就是很不錯了，因?yàn)殡S著項(xiàng)目的開展，很多表的Column都會有相應(yīng)的改動。至于其他細(xì)節(jié)，不同數(shù)據(jù)庫廠商，具體實(shí)現(xiàn)細(xì)節(jié)不盡相同。關(guān)于主鍵的選取多說一句，有的人喜歡所有的表都用自增長ID作為主鍵，而有的人希望找到唯一能標(biāo)識當(dāng)前記錄的一個屬性或者多個屬性作為主鍵；自增長ID作為代理主鍵，對于將來以多個類似當(dāng)前Transaction System作為數(shù)據(jù)源，構(gòu)建數(shù)據(jù)倉庫的時候，這些自增長ID主鍵會是一個麻煩（多個系統(tǒng)中，相同表存在大量主鍵重復(fù)）；使用一個屬性或多個屬性作為作為主鍵，不管主鍵是可編輯的，讀寫效率是我們必須考慮得。所以并沒有一個放之四海而皆準(zhǔn)的原則，筆者只是給大家推薦一些考慮的因素。

物理建模EA可以將在邏輯建模階段創(chuàng)建的各種數(shù)據(jù)庫對象生成為相應(yīng)的SQL代碼，運(yùn)行來創(chuàng)建相應(yīng)具體數(shù)據(jù)庫對象（大多數(shù)建模工具都可以自動生成DDL SQL代碼）。但是這個階段我們不僅僅創(chuàng)建數(shù)據(jù)庫對象，針對業(yè)務(wù)需求，我們也可能做如數(shù)據(jù)拆分（水平或垂直拆分），如B2B網(wǎng)站，我們可以將商家和一般用戶放在同一張表中，但是針對PERFORMANCE考慮，我們可以將其分為兩張表；隨業(yè)務(wù)量的上升，Transaction表越來越大，整個系統(tǒng)越來越慢，這個時候我們可以考慮數(shù)據(jù)拆分，甚至是讀寫分離（即實(shí)現(xiàn)MASTER-SLAVE模式，MYSQL/SQLSERVER可以使用Replication，當(dāng)然不同存儲引擎采用不同的方案），這個階段也會涉及到集群的事情，如果你是架構(gòu)師或者數(shù)據(jù)建模師，這個時候你可以跟DBA說，Alright,I am done with it,now is your show time.

相信大家都知道范式，更有好多人把3NF奉為經(jīng)典，3NF確實(shí)很好，但是3NF是幾十年前提出來的，那個時候的數(shù)據(jù)量以及訪問頻率和2012年完全不是一個數(shù)量級的；因此我們絕對不能一味地遵守3NF；在整個數(shù)據(jù)建模過程中，在保證數(shù)據(jù)結(jié)構(gòu)清晰的前提下，盡量提高性能才是我們關(guān)注的要點(diǎn)，因此筆者大力倡導(dǎo)數(shù)據(jù)適當(dāng)冗余!

上面筆者是結(jié)合一些實(shí)際例子表達(dá)自己對數(shù)據(jù)建模的觀點(diǎn)，希望對讀著有用。在數(shù)據(jù)建模過程中，不要希望一步到位將數(shù)據(jù)庫設(shè)計(jì)完整，筆者不管是針對data warehouse還是Transactional Database設(shè)計(jì)，從來沒有過一次成功的經(jīng)歷。隨著項(xiàng)目的進(jìn)行，客戶和開發(fā)團(tuán)隊(duì)對業(yè)務(wù)知識與日增長，因此原來的設(shè)計(jì)也在不斷完善中。畢竟，數(shù)據(jù)建?；蛘咴O(shè)計(jì)數(shù)據(jù)庫不是我們的最終目的，我們需要的是一個健壯，性能優(yōu)越，易擴(kuò)展，易使用的軟件3！

建立過程選擇變量與重構(gòu)變量在進(jìn)行建模之前，首先要考慮的是使用哪些變量來建立模型，需要從業(yè)務(wù)邏輯和數(shù)據(jù)邏輯兩個方面來考慮：

業(yè)務(wù)邏輯：變量基于收集到的數(shù)據(jù)，而數(shù)據(jù)在收集時，會產(chǎn)生與業(yè)務(wù)層面相關(guān)的邏輯。

數(shù)據(jù)邏輯：通常從數(shù)據(jù)的完整性、集中度、是否與其他變量強(qiáng)相關(guān)（甚至有因果關(guān)系）等角度來考慮，比如某個變量在業(yè)務(wù)上很有價值，但缺失率達(dá)到90%，或者一個非布爾值變量卻集中于兩個值，那么這個時候我們就要考慮，加入這個變量是否對后續(xù)分析有價值。

在選擇變量時，業(yè)務(wù)邏輯應(yīng)該優(yōu)先于數(shù)據(jù)邏輯，蓋因業(yè)務(wù)邏輯是從實(shí)際情況中自然產(chǎn)生，而建模的結(jié)果也要反饋到實(shí)際中去，因此選擇變量時，業(yè)務(wù)邏輯重要程度相對更高。

而在變量本身不適合直接拿來建模時，例如調(diào)查問卷中的滿意度，是漢字的“不滿意”“一般”“滿意”，那么需要將其重構(gòu)成“1”（對應(yīng)不滿意）“2”（對應(yīng)一般）“3”（對應(yīng)滿意）的數(shù)字形式，便于后續(xù)建模使用。

除這種重構(gòu)方式之外，將變量進(jìn)行單獨(dú)計(jì)算（如取均值）和組合計(jì)算（如A*B）也是常用的重構(gòu)方法。其他的重構(gòu)方法還有很多種。

選擇算法我們在建模時，目標(biāo)是解決商業(yè)問題，而不是為了建模而建模，故此我們需要選擇適合的算法。常用建模算法包括相關(guān)、聚類、分類（決策樹）、時間序列、回歸、神經(jīng)網(wǎng)絡(luò)等。

以對消費(fèi)者的建模為例，舉一些場景下的常用算法對應(yīng)：

劃分消費(fèi)者群體：聚類，分類；

購物籃分析：相關(guān)，聚類；

購買額預(yù)測：回歸，時間序列；

滿意度調(diào)查：回歸，聚類，分類；

等等。

確定算法后，要再看一下變量是否滿足算法要求，如果不滿足，回到選擇/重構(gòu)變量，再來一遍。如果滿足，進(jìn)入下一步。

設(shè)定參數(shù)算法選定后，需要用數(shù)據(jù)分析工具進(jìn)行建模。針對不同的模型，需要調(diào)整參數(shù)，例如聚類模型中的K-means算法，需要給出希望聚成的類別數(shù)量，更進(jìn)一步需要給出的起始的聚類中心和迭代次數(shù)上限。

這些參數(shù)在后續(xù)測試中會經(jīng)過多次調(diào)整，很少有一次測試成功的情況。

加載算法與測試結(jié)果算法跑完之后，要根據(jù)算法的輸出結(jié)果來確定該算法是否能夠解決問題，比如K-means的結(jié)果不好，那么考慮換成系統(tǒng)聚類算法來解決?；蛘呋貧w模型輸出的結(jié)果不滿足需求，考慮用時間序列來做。

如果不需要換算法，那么就測試一下算法輸出的結(jié)果是否有提升空間，比如聚類算法中指定聚類結(jié)果包含4類人群，但發(fā)現(xiàn)其中的兩類特征很接近，或者某一類人群沒有明顯特征，那么可以調(diào)整參數(shù)后再試。

在不斷的調(diào)整參數(shù)，優(yōu)化模型過程中，模型的解釋能力和實(shí)用性會不斷的提升。當(dāng)你認(rèn)為模型已經(jīng)能夠滿足目標(biāo)需求了，那就可以輸出結(jié)果了。一個報告，一些規(guī)則，一段代碼，都可能成為模型的輸出。在輸出之后，還有最后一步：接收業(yè)務(wù)人員的反饋，看看模型是否解決了他們的問題4。

以上，就是建模的一般過程。