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