引言：數據庫設計 Step by Step (4)中我們討論了泛化關(guān)系、聚合關(guān)系、三元關(guān)系等高級實(shí)體關(guān)系模型構件及其語(yǔ)義。從本次講座開(kāi)始我將引領(lǐng)大家開(kāi)始數據庫設計之旅，我們將從需求分析開(kāi)始，途中將經(jīng)過(guò)概念數據建模、多視圖集成、ER模型轉化為SQL、范式化等過(guò)程，最終得到完整、可用的SQL表。
需求分析在數據庫生命周期中至關(guān)重要，通常也是涉及人員最多的步驟。數據庫設計師在這個(gè)階段必須走訪(fǎng)最終用戶(hù)，與他們進(jìn)行訪(fǎng)談，從而確定用戶(hù)想在系統中存儲什么數據以及想怎樣使用這些數據。我們將需求分析分為兩個(gè)步驟：1.理解用戶(hù)需求；2.提取業(yè)務(wù)規則。這次我們先討論“理解用戶(hù)需求”。
設計定制化產(chǎn)品——無(wú)論是一個(gè)數據庫、一幅平面廣告或一個(gè)玩具，都是一個(gè)“翻譯”的過(guò)程。我們需要把浮現在客戶(hù)腦海中的模糊想法、愿望挖掘出來(lái)，并“翻譯”成滿(mǎn)足他們需求的現實(shí)產(chǎn)品。
這個(gè)“翻譯”過(guò)程的第一步就是理解用戶(hù)的需求。設計最好的訂單處理系統對于需要一個(gè)電路設計工具的客戶(hù)來(lái)說(shuō)毫無(wú)意義。對客戶(hù)需求理解的不完全會(huì )造成錯誤或無(wú)用的設計與開(kāi)發(fā)，這浪費了你、你的團隊還有客戶(hù)的時(shí)間與金錢(qián)。（牢記數據庫是整個(gè)應用開(kāi)發(fā)的根基）
制定一個(gè)計劃
我們首先制定了一個(gè)計劃，其中包含挖掘客戶(hù)需求的一系列步驟。遵循這些步驟能更好地理解客戶(hù)需求，但在一些項目中我們不需要遵循所有的步驟。舉例來(lái)說(shuō)，如果客戶(hù)是單個(gè)人且需求很明確時(shí)，我們就不需要進(jìn)行“搞清誰(shuí)是誰(shuí)”與“頭腦風(fēng)暴”了。當客戶(hù)的數據需要保密時(shí)，我們就不能“嘗試客戶(hù)的工作”了。在另一些項目中，調整這些步驟的順序會(huì )更為合適。例如我們可能在去拜訪(fǎng)客戶(hù)和觀(guān)察他們工作之前先進(jìn)行“頭腦風(fēng)暴”。
以下按照最普遍的順序列出了各個(gè)步驟。大家根據不同項目的情況可進(jìn)行靈活調整，目標只有一個(gè)就是更好地理解用戶(hù)需求。
下面我們將一一解釋每一個(gè)步驟。
列出問(wèn)題清單
我們需要思考，向客戶(hù)問(wèn)些什么問(wèn)題可以幫助我們了解項目的目標和范疇（scope）。以下幾個(gè)方面的問(wèn)題可以作為起始點(diǎn)。
功能：
以下問(wèn)題主要涉及系統應完成的功能與目標。
- 系統應該做些什么？
- 為什么你想建這個(gè)系統？
- 系統看上去應該是怎樣的？
- 需要些什么報表？
- 用戶(hù)需要自己定義新報表嗎？
- 系統的操作者會(huì )是誰(shuí)？
數據需求：
這些問(wèn)題是為了弄清項目的數據需求。了解需要些什么數據能幫助我們定義數據庫表。
- 系統界面上需要展現哪些數據？
- 這些數據應該由誰(shuí)來(lái)提供？
- 這些數據是如何關(guān)聯(lián)的？
- 這些工作現在是如何處理的？數據來(lái)自哪里？
數據完整性：
這些問(wèn)題能幫助我們在構建數據庫時(shí)定義完整性約束。
- 哪些數據是必須填寫(xiě)的？(eg: 一條客戶(hù)記錄必須有電話(huà)信息嗎？)
- 數據的有效域是什么？(eg: 電話(huà)號碼是否有格式規定？地址數據應有多長(cháng)？)
- 系統是否需要根據郵編來(lái)檢驗城市的有效性？
- 系統中是否必須在定義了客戶(hù)之后才能下訂單？
- 系統要求多高的可用性等級？(系統需要7×24的可用性嗎？數據的備份頻率要多高？)
安全性：
這些問(wèn)題能幫助我們了解客戶(hù)對權限控制與審計方面的需求。
- 是否每個(gè)用戶(hù)都需要一個(gè)不同的密碼？
- 是否需要控制不同的用戶(hù)所能訪(fǎng)問(wèn)的數據？(eg: 銷(xiāo)售代表有權限看到客戶(hù)的信用卡賬號，但訂單錄入專(zhuān)員卻不能)
- 存儲在數據庫中的數據是否需要加密？
- 誰(shuí)做了什么操作是否需要記錄以便于審計？(eg: 記錄銷(xiāo)售代表提高客戶(hù)級別的操作，在需要時(shí)可以追溯操作的原因)
- 系統中的客戶(hù)分成幾個(gè)級別？每個(gè)級別的客戶(hù)有多少？
- 是否已有文檔記錄了用戶(hù)的工作與權責？
環(huán)境：
這些問(wèn)題能幫助我們了解當前項目將代替其他什么系統或流程，以及項目將與其他哪些系統進(jìn)行交互。
- 當前項目是要代替或升級現有的某系統嗎？
·是否有描述現有系統的文檔？
·現有系統的哪些功能是需要的？哪些是不需要的？
·現有系統處理些什么數據？這些數據是如何存儲的？數據之間是如何關(guān)聯(lián)的？
·是否有關(guān)于現有系統數據的文檔？
- 當前項目必須與其他哪些系統交互？
·項目與其他系統之間如何交互？
·新項目是否需要向現有系統提供數據？如何提供？
·新項目是否需要接收現有系統的數據？如何接收？
·是否有關(guān)于其他系統的文檔？
- 客戶(hù)的整個(gè)業(yè)務(wù)流程是怎樣的？(了解在整個(gè)業(yè)務(wù)流程中當前項目的作用)
拜訪(fǎng)客戶(hù)
了解我們要設計和搭建的系統的最好方式是詢(xún)問(wèn)客戶(hù)。拿著(zhù)我們在上一步中準備的問(wèn)題清單安排與客戶(hù)進(jìn)行會(huì )面。這不會(huì )像閑聊那么輕松，向客戶(hù)了解需求是一個(gè)冗長(cháng)且折磨人的過(guò)程。
有時(shí)我們的窮追猛問(wèn)會(huì )使客戶(hù)筋疲力竭感到不快。在這些時(shí)候我們必須更為耐心，可以分幾次多次會(huì )議來(lái)了解需求，每次針對幾個(gè)問(wèn)題或流程。我們的目標是對我們要解決的問(wèn)題有一個(gè)完全且徹底的理解。
即使我們的項目只是去解決整個(gè)業(yè)務(wù)中的一小部分問(wèn)題，我們也要試圖去了解客戶(hù)的整體業(yè)務(wù)流程，這可能會(huì )給我們帶來(lái)意想不到的收獲。
搞清誰(shuí)是誰(shuí)
意識到不同的客戶(hù)可能對項目有不同的愿景。我們需要分辨出誰(shuí)是領(lǐng)導，誰(shuí)是積極支持者，誰(shuí)是旁觀(guān)者，誰(shuí)是唱反調者。
以下列出了一些常見(jiàn)的客戶(hù)角色：
挖掘客戶(hù)大腦
一旦搞清楚誰(shuí)是誰(shuí)之后，我們就要與項目執行負責人討論客戶(hù)需要什么?？蛻?hù)希望的解決方案是怎樣的，需要包含什么數據，怎樣呈現，以及不同數據之間如何關(guān)聯(lián)。
與盡可能多的利益相關(guān)者進(jìn)行交流，我們需要考慮每個(gè)人的意見(jiàn)，但心中要牢記項目執行負責人最為理解客戶(hù)的需求并具有最終決定權。
根據項目的規模，這一過(guò)程短則幾個(gè)小時(shí)，長(cháng)則需要幾周才能完成。
嘗試客戶(hù)的工作
觀(guān)察客戶(hù)每日的工作能幫助我們更好的理解業(yè)務(wù)。如果我們能做一會(huì )兒客戶(hù)的工作來(lái)了解其中包括的內容那就最好了。
即使我們不能實(shí)際嘗試客戶(hù)的工作，一般我們還是可以坐在他們身邊近距離觀(guān)察。告訴客戶(hù)我們將稍稍降低他們的工作效率并問(wèn)一些愚蠢且惱人的問(wèn)題，之后我們就可以開(kāi)問(wèn)了。在這個(gè)過(guò)程中要進(jìn)行記錄，學(xué)習盡可能多的東西。有些時(shí)候外行者的一些看法可能轉化為客戶(hù)怎么也不會(huì )想到的好主意。
學(xué)習現有操作
在嘗試客戶(hù)的工作之后，我們還可以看一下是否有其他途徑能了解現有流程。通常公司有描述客戶(hù)角色和職責的操作手冊或文檔。
尋找客戶(hù)現在使用的數據存儲方式，可能是關(guān)系型數據庫系統或是電子表格或是紙質(zhì)的單據等等。了解這些數據是怎樣使用的，之間是如何關(guān)聯(lián)的。一般物理數據庫之間是通過(guò)包含冗余信息來(lái)相互關(guān)聯(lián)的，如：客戶(hù)ID。
頭腦風(fēng)暴
此刻我們已經(jīng)對客戶(hù)的業(yè)務(wù)和需求較為了解了。為了確認沒(méi)有什么遺漏，我們需要安排頭腦風(fēng)暴。召集項目執行負責人和盡可能多的客戶(hù)代表與利益相關(guān)者，向他們描述前期了解到的需求情況，之后讓他們暢所欲言談?wù)勂渲杏惺裁磫?wèn)題或還缺什么。
在這個(gè)過(guò)程中我們不急于答應或排除任何客戶(hù)的要求，我們先把客戶(hù)說(shuō)到的東西記錄下來(lái)，并確定這些方面我們已經(jīng)考慮到了。在正式開(kāi)發(fā)前，我們會(huì )與項目執行負責人一起根據項目的規模與交付期限確定需求的優(yōu)先級。
展望未來(lái)
在頭腦風(fēng)暴過(guò)程中思考一下將來(lái)的需求。問(wèn)問(wèn)客戶(hù)他們的業(yè)務(wù)在將來(lái)是否會(huì )變化或他們希望系統將來(lái)能包含什么功能。
我們可以把他們的一些想法放入當前的項目中，即使不能也可以使我們知道將來(lái)可能會(huì )有些什么擴展，在設計數據庫時(shí)我們能預先留有余地。
理解客戶(hù)的質(zhì)疑
一些熱心且懂些技術(shù)的用戶(hù)會(huì )跑來(lái)建議我們如何設計系統，應該創(chuàng )建怎樣結構的數據表。我們可能覺(jué)得這些建議毫無(wú)意義甚至可笑。但在忽視這些建議之前我們應謹慎思考用戶(hù)提出這些建議或質(zhì)疑的深層原因是什么?？蛻?hù)比我們更了解業(yè)務(wù)，他們的建議或質(zhì)疑中可能蘊含著(zhù)我們還未了解到的業(yè)務(wù)變化點(diǎn)或某些特殊業(yè)務(wù)情況。
弄清客戶(hù)的真正需求
有時(shí)客戶(hù)并不了解自己的真正需求。他們能看到問(wèn)題的表象，但未必清楚其根源。我們需要幫助客戶(hù)尋找到問(wèn)題的根源并針對問(wèn)題的源頭提出解決方案。
有時(shí)客戶(hù)認為數據庫或新系統能神奇般的提高銷(xiāo)售，減少成本。事實(shí)上一個(gè)設計精良的數據庫能減少輸入差錯，提高操作效率，提供數據報表，幫助客戶(hù)管理數據等等。我們在與客戶(hù)溝通的過(guò)程中需要告訴他們新系統能做些什么，不能做些什么，讓客戶(hù)建立起正確的預期。
優(yōu)先級
經(jīng)過(guò)先前的步驟，我們已列出一張長(cháng)長(cháng)的期望功能列表。其中的某些功能可能不切實(shí)際或超出了當前項目的范疇。為了使項目規?？煽?，我們要與客戶(hù)一起定義功能的優(yōu)先級。
一般我們可以把功能分為三個(gè)等級。第一優(yōu)先級是在本期開(kāi)發(fā)中必須包含的功能，沒(méi)有完成這些功能意味著(zhù)項目的失敗。第二優(yōu)先級是可以放到下一期開(kāi)發(fā)的功能，當第一優(yōu)先級的功能完成后，我們可以把第二優(yōu)先級的部分功能提到當期開(kāi)發(fā)。第三優(yōu)先級是那些相對不重要或超出項目范疇的功能，我們可以忽略這些功能。
有些情況下優(yōu)先級是可能轉化的。當第一優(yōu)先級的某功能非常難實(shí)現時(shí)，我們可以與客戶(hù)進(jìn)行溝通，確認該功能是否如此重要，是否能移到第二優(yōu)先級中以避免影響項目進(jìn)度。當第二優(yōu)先級中的某些功能很容易實(shí)現，我們可以把該功能調整到第一優(yōu)先級列表中。但做這些調整之前必須與客戶(hù)溝通，得到客戶(hù)的認可。
驗證你的理解
梳理我們對業(yè)務(wù)和需求的理解，并一一與客戶(hù)進(jìn)行確認。當客戶(hù)說(shuō)“但是”、“除了”、“有時(shí)”等詞時(shí)，我們要特別當心，確認客戶(hù)只是強調了我們已經(jīng)知道的東西，而沒(méi)有出現新的情況。在這個(gè)階段客戶(hù)可能會(huì )想到他們之前沒(méi)有考慮到的例外情況。
例外情況是數據庫設計的大害。在需求分析階段把例外情況挖掘出來(lái)，我們才能在數據庫設計時(shí)有所準備。例如，我們向客戶(hù)確認退貨流程說(shuō)：“到這里收貨員會(huì )輸入RMA號并點(diǎn)擊完成按鈕是嗎？”客戶(hù)可能會(huì )說(shuō)：“嗯…這是大多數情況，但有時(shí)沒(méi)有RMA號，收貨員會(huì )填入None?！边@就是一個(gè)客戶(hù)之前沒(méi)有告訴我們的重要例外情況，我們必須立刻記錄下來(lái)。再有一個(gè)例子，假設客戶(hù)使用的紙質(zhì)訂單有配送地址與賬單地址兩個(gè)欄目。我們向客戶(hù)確認時(shí)說(shuō)：“訂單需要有一個(gè)配送地址和一個(gè)賬單地址?！笨蛻?hù)打斷說(shuō)：“有時(shí)我們需要兩個(gè)配送地址，因為訂單不同部分可能要送到不同的地方?！?，并找出一張訂單，第二個(gè)配送地址被標注在訂單的邊沿處。這是一個(gè)重大例外，在紙上可以很容易的進(jìn)行標注，但在數據庫的一個(gè)表單元中增加一個(gè)地址是不可能的。只有知道這一例外，我們才能用設計的方法解決這一需求。
撰寫(xiě)需求文檔
需求文檔描述了我們要構建的系統，該文檔也被稱(chēng)為需求規格說(shuō)明。需求文檔要講清楚我們將構建怎樣的系統，該系統會(huì )完成什么工作，包含哪些功能點(diǎn)，并描述客戶(hù)如何使用該系統來(lái)解決他們的問(wèn)題。需求文檔明確了項目將完成的功能，這也避免了系統交付時(shí)出現爭執的情況。
需求文檔中應定義可交付成果，即里程碑。里程碑是可直觀(guān)展現并能驗證的中間成果?？蛻?hù)通過(guò)里程碑能衡量項目的進(jìn)度。在需求文檔中還需定義最終交付成果，這也是確定項目是否完成的標準。
用例圖是一種非常好的需求分析工具，可以作為需求文檔的一部分。用例圖的最主要功能就是用來(lái)表達系統的功能性需求或行為。用例圖從業(yè)務(wù)角度上體現誰(shuí)來(lái)使用系統、用戶(hù)希望系統提供什么樣的服務(wù)，以及用戶(hù)需要為系統提供的服務(wù)，也便于軟件開(kāi)發(fā)人員最終實(shí)現這些功能。在官方文檔中用例圖包含六個(gè)元素，分別是：參與者(Actor)、用例(Use Case)、關(guān)聯(lián)關(guān)系(Association)、包含關(guān)系(Include)、擴展關(guān)系(Extend)以及泛化關(guān)系(Generalization)。但是有些UML的繪圖工具多提供了一種直接關(guān)聯(lián)關(guān)系(Directed Association)。
eg：用戶(hù)管理的用例圖如下所示，圖中人形圖標表示參與者，橢圓表示用例（圖的出處請參見(jiàn)“總結與參考”）
主要內容回顧
1. 搞清哪個(gè)客戶(hù)扮演哪個(gè)角色
2. 從客戶(hù)的腦海中挖掘信息
3. 尋找關(guān)于用戶(hù)角色、職責、現有流程和現有數據的文檔
4. 觀(guān)察客戶(hù)的工作，學(xué)習他們的業(yè)務(wù)操作
5. 進(jìn)行頭腦風(fēng)暴，把收集到的功能需求點(diǎn)按優(yōu)先級分成第一、第二和第三級
6. 確認對客戶(hù)需求的理解
7. 撰寫(xiě)需求文檔，包含可驗證的里程碑和用例
用例圖參考
1. 初學(xué)UML之-------用例圖（http://blog.csdn.net/dl88250/archive/2007/10/16/1826713.aspx）
2. UML用例圖（http://www.alisdn.com/wordpress/?p=1161）
聯(lián)系客服
