引言：一步一步設(shè)計你的數(shù)據(jù)庫四中我們討論了泛化關(guān)系、聚合關(guān)系、三元關(guān)系等高級實體關(guān)系模型構(gòu)件及其語義。從本次講座開始我將引領(lǐng)大家開始數(shù)據(jù)庫設(shè)計之旅，我們將從需求分析開始，途中將經(jīng)過概念數(shù)據(jù)建模、多視圖集成、ER模型轉(zhuǎn)化為SQL、范式化等過程，最終得到完整、可用的SQL表。

需求分析在數(shù)據(jù)庫生命周期中至關(guān)重要，通常也是涉及人員最多的步驟。數(shù)據(jù)庫設(shè)計師在這個階段必須走訪最終用戶，與他們進行訪談，從而確定用戶想在系統(tǒng)中存儲什么數(shù)據(jù)以及想怎樣使用這些數(shù)據(jù)。我們將需求分析分為兩個步驟：1.理解用戶需求；2.提取業(yè)務(wù)規(guī)則。這次我們先討論“理解用戶需求”。

[[30880]] 

設(shè)計定制化產(chǎn)品——無論是一個數(shù)據(jù)庫、一幅平面廣告或一個玩具，都是一個“翻譯”的過程。我們需要把浮現(xiàn)在客戶腦海中的模糊想法、愿望挖掘出來，并“翻譯”成滿足他們需求的現(xiàn)實產(chǎn)品。

這個“翻譯”過程的第一步就是理解用戶的需求。設(shè)計最好的訂單處理系統(tǒng)對于需要一個電路設(shè)計工具的客戶來說毫無意義。對客戶需求理解的不完全會造成錯誤或無用的設(shè)計與開發(fā)，這浪費了你、你的團隊還有客戶的時間與金錢。(牢記數(shù)據(jù)庫是整個應(yīng)用開發(fā)的根基)

制定一個計劃

我們首先制定了一個計劃，其中包含挖掘客戶需求的一系列步驟。遵循這些步驟能更好地理解客戶需求，但在一些項目中我們不需要遵循所有的步驟。舉例來說，如果客戶是單個人且需求很明確時，我們就不需要進行“搞清誰是誰”與“頭腦風(fēng)暴”了。當(dāng)客戶的數(shù)據(jù)需要保密時，我們就不能“嘗試客戶的工作”了。在另一些項目中，調(diào)整這些步驟的順序會更為合適。例如我們可能在去拜訪客戶和觀察他們工作之前先進行“頭腦風(fēng)暴”。

以下按照最普遍的順序列出了各個步驟。大家根據(jù)不同項目的情況可進行靈活調(diào)整，目標(biāo)只有一個就是更好地理解用戶需求。

1. 列出問題清單
2. 拜訪客戶
3. 搞清誰是誰
4. 挖掘客戶大腦
5. 嘗試客戶的工作
6. 學(xué)習(xí)現(xiàn)有操作
7. 頭腦風(fēng)暴
8. 展望未來
9. 理解客戶的質(zhì)疑
10. 弄清客戶的真正需求
11. 優(yōu)先級
12. 確認(rèn)你的理解
13. 撰寫需求文檔

下面我們將一一解釋每一個步驟。

我們需要思考，向客戶問些什么問題可以幫助我們了解項目的目標(biāo)和范疇（scope）。以下幾個方面的問題可以作為起始點。

功能：

以下問題主要涉及系統(tǒng)應(yīng)完成的功能與目標(biāo)。

1. 系統(tǒng)應(yīng)該做些什么?
2. 為什么你想建這個系統(tǒng)?
3. 系統(tǒng)看上去應(yīng)該是怎樣的?
4. 需要些什么報表?
5. 用戶需要自己定義新報表嗎?
6. 系統(tǒng)的操作者會是誰?

數(shù)據(jù)需求：

這些問題是為了弄清項目的數(shù)據(jù)需求。了解需要些什么數(shù)據(jù)能幫助我們定義數(shù)據(jù)庫表。

1. 系統(tǒng)界面上需要展現(xiàn)哪些數(shù)據(jù)?
2. 這些數(shù)據(jù)應(yīng)該由誰來提供?
3. 這些數(shù)據(jù)是如何關(guān)聯(lián)的?
4. 這些工作現(xiàn)在是如何處理的?數(shù)據(jù)來自哪里?

數(shù)據(jù)完整性：

這些問題能幫助我們在構(gòu)建數(shù)據(jù)庫時定義完整性約束。

1. 哪些數(shù)據(jù)是必須填寫的?(eg: 一條客戶記錄必須有電話信息嗎?)
2. 數(shù)據(jù)的有效域是什么?(eg: 電話號碼是否有格式規(guī)定?地址數(shù)據(jù)應(yīng)有多長?)
3. 系統(tǒng)是否需要根據(jù)郵編來檢驗城市的有效性?
4. 系統(tǒng)中是否必須在定義了客戶之后才能下訂單?
5. 系統(tǒng)要求多高的可用性等級?(系統(tǒng)需要7×24的可用性嗎?數(shù)據(jù)的備份頻率要多高?)

安全性：

這些問題能幫助我們了解客戶對權(quán)限控制與審計方面的需求。

1. 是否每個用戶都需要一個不同的密碼?
2. 是否需要控制不同的用戶所能訪問的數(shù)據(jù)?(eg: 銷售代表有權(quán)限看到客戶的信用卡賬號，但訂單錄入專員卻不能)
3. 存儲在數(shù)據(jù)庫中的數(shù)據(jù)是否需要加密?
4. 誰做了什么操作是否需要記錄以便于審計?(eg: 記錄銷售代表提高客戶級別的操作，在需要時可以追溯操作的原因)
5. 系統(tǒng)中的客戶分成幾個級別?每個級別的客戶有多少?
6. 是否已有文檔記錄了用戶的工作與權(quán)責(zé)?

環(huán)境：

這些問題能幫助我們了解當(dāng)前項目將代替其他什么系統(tǒng)或流程，以及項目將與其他哪些系統(tǒng)進行交互。

1.當(dāng)前項目是要代替或升級現(xiàn)有的某系統(tǒng)嗎?

•是否有描述現(xiàn)有系統(tǒng)的文檔?

•現(xiàn)有系統(tǒng)的哪些功能是需要的?哪些是不需要的?

•現(xiàn)有系統(tǒng)處理些什么數(shù)據(jù)?這些數(shù)據(jù)是如何存儲的?數(shù)據(jù)之間是如何關(guān)聯(lián)的?

•是否有關(guān)于現(xiàn)有系統(tǒng)數(shù)據(jù)的文檔?

2.當(dāng)前項目必須與其他哪些系統(tǒng)交互?

•項目與其他系統(tǒng)之間如何交互?

•新項目是否需要向現(xiàn)有系統(tǒng)提供數(shù)據(jù)?如何提供?

•新項目是否需要接收現(xiàn)有系統(tǒng)的數(shù)據(jù)?如何接收?

•是否有關(guān)于其他系統(tǒng)的文檔?

3.客戶的整個業(yè)務(wù)流程是怎樣的?(了解在整個業(yè)務(wù)流程中當(dāng)前項目的作用)

拜訪客戶

了解我們要設(shè)計和搭建的系統(tǒng)的最好方式是詢問客戶。拿著我們在上一步中準(zhǔn)備的問題清單安排與客戶進行會面。這不會像閑聊那么輕松，向客戶了解需求是一個冗長且折磨人的過程。

有時我們的窮追猛問會使客戶筋疲力竭感到不快。在這些時候我們必須更為耐心，可以分幾次多次會議來了解需求，每次針對幾個問題或流程。我們的目標(biāo)是對我們要解決的問題有一個完全且徹底的理解。

即使我們的項目只是去解決整個業(yè)務(wù)中的一小部分問題，我們也要試圖去了解客戶的整體業(yè)務(wù)流程，這可能會給我們帶來意想不到的收獲。

搞清誰是誰

意識到不同的客戶可能對項目有不同的愿景。我們需要分辨出誰是領(lǐng)導(dǎo)，誰是積極支持者，誰是旁觀者，誰是唱反調(diào)者。

以下列出了一些常見的客戶角色：

1. 項目發(fā)起人——一般是管理層的某位領(lǐng)導(dǎo)，他是項目的最高推動者。他會為項目協(xié)調(diào)資源，解決項目遇到的一些障礙，但他不會參與到項目每天的事務(wù)中。
2. 項目執(zhí)行負(fù)責(zé)人——他對于客戶的需求和整個業(yè)務(wù)最為了解。他是了解用戶需求階段最重要的人，他必須有足夠的時間來幫助我們定義項目目標(biāo)以及回答我們的問題。當(dāng)別人對某業(yè)務(wù)環(huán)節(jié)遲疑不決時，我們需要向他請教。
3. 客戶代表——客戶代表是回答我們問題的人，他們也可能成為系統(tǒng)的最終用戶。他們可能是某一部分業(yè)務(wù)的專家，我們需要與多個客戶代表進行訪談來了解業(yè)務(wù)全貌。
4. 利益相關(guān)者——這是項目將影響到的人，其中某些人可能同時也是客戶代表。這些人可能對項目也有興趣，但未必對系統(tǒng)都有發(fā)言權(quán)。我們在進行系統(tǒng)設(shè)計時也需要考慮對這些人的影響(特別是附帶損害)。
5. 唱反調(diào)者——這是我們需要關(guān)注的一些人。如果唱反調(diào)者只是讓其他人理性或現(xiàn)實地來看待項目，而并不是徹底反對這個項目的話，他將是我們非常好的資源，他將幫助我們說服其他對項目抱有不切實幻想的客戶。而如果唱反調(diào)者對整個項目抱有抵觸時，我們就必須非常小心，有時需要項目執(zhí)行負(fù)責(zé)人出面來協(xié)調(diào)這些人。

挖掘客戶大腦

一旦搞清楚誰是誰之后，我們就要與項目執(zhí)行負(fù)責(zé)人討論客戶需要什么?？蛻粝Ｍ慕鉀Q方案是怎樣的，需要包含什么數(shù)據(jù)，怎樣呈現(xiàn)，以及不同數(shù)據(jù)之間如何關(guān)聯(lián)。

與盡可能多的利益相關(guān)者進行交流，我們需要考慮每個人的意見，但心中要牢記項目執(zhí)行負(fù)責(zé)人最為理解客戶的需求并具有最終決定權(quán)。

根據(jù)項目的規(guī)模，這一過程短則幾個小時，長則需要幾周才能完成。

嘗試客戶的工作

觀察客戶每日的工作能幫助我們更好的理解業(yè)務(wù)。如果我們能做一會兒客戶的工作來了解其中包括的內(nèi)容那就最好了。

即使我們不能實際嘗試客戶的工作，一般我們還是可以坐在他們身邊近距離觀察。告訴客戶我們將稍稍降低他們的工作效率并問一些愚蠢且惱人的問題，之后我們就可以開問了。在這個過程中要進行記錄，學(xué)習(xí)盡可能多的東西。有些時候外行者的一些看法可能轉(zhuǎn)化為客戶怎么也不會想到的好主意。

學(xué)習(xí)現(xiàn)有操作

在嘗試客戶的工作之后，我們還可以看一下是否有其他途徑能了解現(xiàn)有流程。通常公司有描述客戶角色和職責(zé)的操作手冊或文檔。

尋找客戶現(xiàn)在使用的數(shù)據(jù)存儲方式，可能是關(guān)系型數(shù)據(jù)庫系統(tǒng)或是電子表格或是紙質(zhì)的單據(jù)等等。了解這些數(shù)據(jù)是怎樣使用的，之間是如何關(guān)聯(lián)的。一般物理數(shù)據(jù)庫之間是通過包含冗余信息來相互關(guān)聯(lián)的，如：客戶ID。

頭腦風(fēng)暴

此刻我們已經(jīng)對客戶的業(yè)務(wù)和需求較為了解了。為了確認(rèn)沒有什么遺漏，我們需要安排頭腦風(fēng)暴。召集項目執(zhí)行負(fù)責(zé)人和盡可能多的客戶代表與利益相關(guān)者，向他們描述前期了解到的需求情況，之后讓他們暢所欲言談?wù)勂渲杏惺裁磫栴}或還缺什么。

在這個過程中我們不急于答應(yīng)或排除任何客戶的要求，我們先把客戶說到的東西記錄下來，并確定這些方面我們已經(jīng)考慮到了。在正式開發(fā)前，我們會與項目執(zhí)行負(fù)責(zé)人一起根據(jù)項目的規(guī)模與交付期限確定需求的優(yōu)先級。

展望未來

在頭腦風(fēng)暴過程中思考一下將來的需求。問問客戶他們的業(yè)務(wù)在將來是否會變化或他們希望系統(tǒng)將來能包含什么功能。

我們可以把他們的一些想法放入當(dāng)前的項目中，即使不能也可以使我們知道將來可能會有些什么擴展，在設(shè)計數(shù)據(jù)庫時我們能預(yù)先留有余地。

理解客戶的質(zhì)疑

一些熱心且懂些技術(shù)的用戶會跑來建議我們?nèi)绾卧O(shè)計系統(tǒng)，應(yīng)該創(chuàng)建怎樣結(jié)構(gòu)的數(shù)據(jù)表。我們可能覺得這些建議毫無意義甚至可笑。但在忽視這些建議之前我們應(yīng)謹(jǐn)慎思考用戶提出這些建議或質(zhì)疑的深層原因是什么。客戶比我們更了解業(yè)務(wù)，他們的建議或質(zhì)疑中可能蘊含著我們還未了解到的業(yè)務(wù)變化點或某些特殊業(yè)務(wù)情況。

弄清客戶的真正需求

有時客戶并不了解自己的真正需求。他們能看到問題的表象，但未必清楚其根源。我們需要幫助客戶尋找到問題的根源并針對問題的源頭提出解決方案。

有時客戶認(rèn)為數(shù)據(jù)庫或新系統(tǒng)能神奇般的提高銷售，減少成本。事實上一個設(shè)計精良的數(shù)據(jù)庫能減少輸入差錯，提高操作效率，提供數(shù)據(jù)報表，幫助客戶管理數(shù)據(jù)等等。我們在與客戶溝通的過程中需要告訴他們新系統(tǒng)能做些什么，不能做些什么，讓客戶建立起正確的預(yù)期。

優(yōu)先級

經(jīng)過先前的步驟，我們已列出一張長長的期望功能列表。其中的某些功能可能不切實際或超出了當(dāng)前項目的范疇。為了使項目規(guī)模可控，我們要與客戶一起定義功能的優(yōu)先級。

一般我們可以把功能分為三個等級。第一優(yōu)先級是在本期開發(fā)中必須包含的功能，沒有完成這些功能意味著項目的失敗。第二優(yōu)先級是可以放到下一期開發(fā)的功能，當(dāng)?shù)谝粌?yōu)先級的功能完成后，我們可以把第二優(yōu)先級的部分功能提到當(dāng)期開發(fā)。第三優(yōu)先級是那些相對不重要或超出項目范疇的功能，我們可以忽略這些功能。

有些情況下優(yōu)先級是可能轉(zhuǎn)化的。當(dāng)?shù)谝粌?yōu)先級的某功能非常難實現(xiàn)時，我們可以與客戶進行溝通，確認(rèn)該功能是否如此重要，是否能移到第二優(yōu)先級中以避免影響項目進度。當(dāng)?shù)诙?yōu)先級中的某些功能很容易實現(xiàn)，我們可以把該功能調(diào)整到第一優(yōu)先級列表中。但做這些調(diào)整之前必須與客戶溝通，得到客戶的認(rèn)可。

驗證你的理解

梳理我們對業(yè)務(wù)和需求的理解，并一一與客戶進行確認(rèn)。當(dāng)客戶說“但是”、“除了”、“有時”等詞時，我們要特別當(dāng)心，確認(rèn)客戶只是強調(diào)了我們已經(jīng)知道的東西，而沒有出現(xiàn)新的情況。在這個階段客戶可能會想到他們之前沒有考慮到的例外情況。

例外情況是數(shù)據(jù)庫設(shè)計的大害。在需求分析階段把例外情況挖掘出來，我們才能在數(shù)據(jù)庫設(shè)計時有所準(zhǔn)備。例如，我們向客戶確認(rèn)退貨流程說：“到這里收貨員會輸入RMA號并點擊完成按鈕是嗎?”客戶可能會說：“嗯…這是大多數(shù)情況，但有時沒有RMA號，收貨員會填入None。”這就是一個客戶之前沒有告訴我們的重要例外情況，我們必須立刻記錄下來。再有一個例子，假設(shè)客戶使用的紙質(zhì)訂單有配送地址與賬單地址兩個欄目。我們向客戶確認(rèn)時說：“訂單需要有一個配送地址和一個賬單地址。”客戶打斷說：“有時我們需要兩個配送地址，因為訂單不同部分可能要送到不同的地方。”，并找出一張訂單，第二個配送地址被標(biāo)注在訂單的邊沿處。這是一個重大例外，在紙上可以很容易的進行標(biāo)注，但在數(shù)據(jù)庫的一個表單元中增加一個地址是不可能的。只有知道這一例外，我們才能用設(shè)計的方法解決這一需求。

撰寫需求文檔

需求文檔描述了我們要構(gòu)建的系統(tǒng)，該文檔也被稱為需求規(guī)格說明。需求文檔要講清楚我們將構(gòu)建怎樣的系統(tǒng)，該系統(tǒng)會完成什么工作，包含哪些功能點，并描述客戶如何使用該系統(tǒng)來解決他們的問題。需求文檔明確了項目將完成的功能，這也避免了系統(tǒng)交付時出現(xiàn)爭執(zhí)的情況。

需求文檔中應(yīng)定義可交付成果，即里程碑。里程碑是可直觀展現(xiàn)并能驗證的中間成果?？蛻敉ㄟ^里程碑能衡量項目的進度。在需求文檔中還需定義最終交付成果，這也是確定項目是否完成的標(biāo)準(zhǔn)。

用例圖是一種非常好的需求分析工具，可以作為需求文檔的一部分。用例圖的最主要功能就是用來表達(dá)系統(tǒng)的功能性需求或行為。用例圖從業(yè)務(wù)角度上體現(xiàn)誰來使用系統(tǒng)、用戶希望系統(tǒng)提供什么樣的服務(wù)，以及用戶需要為系統(tǒng)提供的服務(wù)，也便于軟件開發(fā)人員最終實現(xiàn)這些功能。在官方文檔中用例圖包含六個元素，分別是：參與者(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)。

1. 參與者：是指用戶在系統(tǒng)中扮演的角色
2. 用例：是指外部可見的系統(tǒng)功能，對系統(tǒng)提供的服務(wù)進行描述
3. 關(guān)聯(lián)關(guān)系：連接參與者和用例，表示該參與者代表的外部系統(tǒng)實體與該用例描述的系統(tǒng)需求有關(guān)
4. 包含關(guān)系：是來自于用例的抽象，即從數(shù)個不同的Use Case中，分離出公共的部分，而成為可以復(fù)用的用例
5. 擴展關(guān)系：表示某一個用例的對話流程中，可能會根據(jù)條件臨時插入另外一個用例，而前者稱為基礎(chǔ)用例后者稱為擴展用例
6. 泛化關(guān)系：一個用例可以被特別列舉為一個或多個用例，這被稱為用例泛化

eg：用戶管理的用例圖如下所示，圖中人形圖標(biāo)表示參與者，橢圓表示用例（圖的出處請參見“總結(jié)與參考”）

[[30882]] 

主要內(nèi)容回顧

1. 搞清哪個客戶扮演哪個角色

2. 從客戶的腦海中挖掘信息

3. 尋找關(guān)于用戶角色、職責(zé)、現(xiàn)有流程和現(xiàn)有數(shù)據(jù)的文檔

4. 觀察客戶的工作，學(xué)習(xí)他們的業(yè)務(wù)操作

5. 進行頭腦風(fēng)暴，把收集到的功能需求點按優(yōu)先級分成第一、第二和第三級

6. 確認(rèn)對客戶需求的理解

7. 撰寫需求文檔，包含可驗證的里程碑和用例

原文鏈接：http://www.cnblogs.com/DBFocus/archive/2011/05/28/2061142.html

【編輯推薦】

1. 一步一步設(shè)計你的數(shù)據(jù)庫一
2. 一步一步設(shè)計你的數(shù)據(jù)庫二
3. 一步一步設(shè)計你的數(shù)據(jù)庫三
4. 一步一步設(shè)計你的數(shù)據(jù)庫四
5. 數(shù)據(jù)庫設(shè)計，你了解多少