互联网产品初期需求确定与数据库模型设计——基于Visio和Xmind

很多互联网产品有个共性，就是其业务核心在数据库中，各种客户端包括网页、桌面、手机App，本质上只是将数据库中的数据，按照一定的结构和组织呈现在用户面前。

因此对于一款互联网产品的初期开发，数据库模型的设计是非常重要的。并且数据库的模型设计与产品需求有直接的关联，通过设计数据库模型，能将产品需求与实现有效的结合起来。

本文介绍一种本人独创的，利用Microsoft Visio绘图工具和Xmind思维导图实现的产品需求确定和数据库原型的设计方法，经过实际使用效果不错，图形化文档能非常直观的展现出产品的业务逻辑。

这里以一个简单的微博应用为例，对这种方法进行介绍。

产品基本需求确定（核心需求）

应用的基本需求如下：

用户可以进行注册登录

每个用户可以发布微博

每条微博可以同时配多张图片

用户可以评论别人的微博

用户可以互相加好友（这里加好友是双向的）

数据表关系模型的设计

这里我们使用的是关系型数据库，可参考《关系型数据库的基本概念》：

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

根据以上基本需求，拟定基本数据表User、Post、Img，分别表示用户，微博，图片。

User和Post之间存在一个一对多的关系，也就是每个用户能发布多条微博，每条微博由一个用户发布。同样，Post和Img之间也是一对多的关系。

User和User之间有一个多对多的关系，每个用户可以加多个其他用户为好友。而User和Post之间也有一个多对多的关系，就是评论，每个用户可以评论多条微博，每个微博可以被多个用户评论。

据此，可以利用Visio的数据流图绘制关系图如下。我们用单向箭头表示一对多关系，用双向箭头表示多对多关系。

Visio的使用可参考文章《Microsoft Visio绘图工具快速入门》

http://www.paincker.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记录。于是我们可以把整个数据表画成下面的样子。

新的图例如下

至此，数据库的关系模型已经画好了。可以很清晰的看到每个产品功能在数据层面的实现。

产品详细需求 / 界面概念图 / 数据表字段模型的设计

数据库的表级设计完成了，就可以根据产品的详细需求，进行字段级的设计了。字段级设计的同时，确定和完善产品的详细需求。由于细节很容易漏掉，后期再去做太多本可以避免的修改，会比较费时间和混乱，可以结合客户端的界面概念图或交互原型进行考虑，这样就不会很抽象，更容易想清楚每个细节。

由于这里着重于产品功能设计，因此概念图的设计不需要花费很多精力做的非常精美，只需要初步确定有哪些界面，每个界面大概有哪些元素即可。不关注元素之间的排版，也不关注用于的操作，更不需要画的很精致，可以直接手工绘制简单的草图。这个过程应该由商业和市场人员、产品人员、交互设计人员、技术架构实现人员共同参与讨论，并且要明确讨论的主题。需要记住，概念草图的使用，只是为了方便直观的分析产品有哪些细节需求，而不是为了设计出最终的界面；界面后期的完善美化，由美工和交互设计人员完成就可以了。