互聯網產品初期需求確定與數據庫模型設計——基於Visio和Xmind

很多互聯網產品有個共性，就是其業務核心在數據庫中，各種客戶端包括網頁、桌面、手機App，本質上只是將數據庫中的數據，按照一定的結構和組織呈現在用戶面前。

因此對於一款互聯網產品的初期開發，數據庫模型的設計是非常重要的。並且數據庫的模型設計與產品需求有直接的關聯，通過設計數據庫模型，能將產品需求與實現有效的結合起來。

本文介紹一種本人獨創的，利用Microsoft Visio繪圖工具和Xmind思維導圖實現的產品需求確定和數據庫原型的設計方法，經過實際使用效果不錯，圖形化文檔能非常直觀的展現出產品的業務邏輯。

這裏以一個簡單的微博應用爲例，對這種方法進行介紹。

產品基本需求確定（核心需求）

應用的基本需求如下：

用戶可以進行註冊登錄

每個用戶可以發佈微博

每條微博可以同時配多張圖片

用戶可以評論別人的微博

用戶可以互相加好友（這裏加好友是雙向的）

數據表關係模型的設計

這裏我們使用的是關係型數據庫，可參考《關係型數據庫的基本概念》：

http://www.hainter.com/relational-database

根據以上基本需求，擬定基本數據表User、Post、Img，分別表示用戶，微博，圖片。

User和Post之間存在一個一對多的關係，也就是每個用戶能發佈多條微博，每條微博由一個用戶發佈。同樣，Post和Img之間也是一對多的關係。

User和User之間有一個多對多的關係，每個用戶可以加多個其他用戶爲好友。而User和Post之間也有一個多對多的關係，就是評論，每個用戶可以評論多條微博，每個微博可以被多個用戶評論。

據此，可以利用Visio的數據流圖繪製關係圖如下。我們用單向箭頭表示一對多關係，用雙向箭頭表示多對多關係。

Visio的使用可參考文章《Microsoft Visio繪圖工具快速入門》

http://www.hainter.com/visio-quick-start

圖例如下

從實現的角度來看，對於一對多的關係，例如User和Post，只需要在Post表中添加一個外鍵指向User即可。而對於多對多的關係，例如User和Post，則需要用一個新的表Comment，並設置兩個外鍵分別指向User和Post實現。因此，我們把圖中多對多關係畫成下面的形式。

在這個圖中，每個圓形代表一個數據表。並且很巧的是，每個圓形上的箭頭剛好標示了每個數據表所包含的外鍵，例如Friend表有兩個外鍵，均指向User，Img有一個指向Post的外鍵。

在關係型數據庫中，還有一種關係是一對一的關係。這種關係用的不多，因爲一對一的兩張表，可以將他們的字段直接合到一張表中。但是由於各種原因，處於安全性、性能等的考慮，就可能會用到。

這裏舉一個可能不是很恰當的例子。原先User表中只保存了用戶的基本信息，而產品已經投入運營。由於產品更新，產生了新的數據需求。用戶可以付費申請VIP用戶權限，VIP用戶可以保存更多個性化的個人信息進行展示。這時VIP用戶只是所有用戶的一個子集。

雖然我們可以修改User表，給每條記錄都添加VIP用戶專用的字段，但是這樣可能會造成一定的空間浪費，另外可能會使得User表的大小增加很多，引起一些問題。

這時我們可以考慮直接新建一張表VipUserInfo，專門用戶存儲VIP用戶的附加信息，並設置一個外鍵指向User。此時，VipUserInfo和User就構成了一種一對一的關係，每條VipUserInfo記錄對應一條User記錄，且每條User記錄最多隻對應一條VipUserInfo記錄。於是我們可以把整個數據表畫成下面的樣子。

新的圖例如下

至此，數據庫的關係模型已經畫好了。可以很清晰的看到每個產品功能在數據層面的實現。

產品詳細需求 / 界面概念圖 / 數據表字段模型的設計

數據庫的表級設計完成了，就可以根據產品的詳細需求，進行字段級的設計了。字段級設計的同時，確定和完善產品的詳細需求。由於細節很容易漏掉，後期再去做太多本可以避免的修改，會比較費時間和混亂，可以結合客戶端的界面概念圖或交互原型進行考慮，這樣就不會很抽象，更容易想清楚每個細節。

由於這裏着重於產品功能設計，因此概念圖的設計不需要花費很多精力做的非常精美，只需要初步確定有哪些界面，每個界面大概有哪些元素即可。不關注元素之間的排版，也不關注用於的操作，更不需要畫的很精緻，可以直接手工繪製簡單的草圖。這個過程應該由商業和市場人員、產品人員、交互設計人員、技術架構實現人員共同參與討論，並且要明確討論的主題。需要記住，概念草圖的使用，只是爲了方便直觀的分析產品有哪些細節需求，而不是爲了設計出最終的界面；界面後期的完善美化，由美工和交互設計人員完成就可以了。