数据,界面,循环 – 我是如何进行数据建模的

根据前言的介绍,设计、界面是一个相互影响的环,因此事实上从哪一点介入这个环并不重要,甚至完全取决与个人的喜好。对于个人而言,数据的建模方式也许可以说得更加精彩,因此就以“数据如何进行建模”作为这个环的切入点。

在小型应用的开发中,我是一个重数据而轻业务的人,也许很多注重领域业务的人会对此嗤之以鼻,但这确实是我经过不少项目之后的切身体会,并且也有一套自己的说法,具体的内容希望日后有机会可以写成博文进一步交流。

而在这里可以先不管业务、逻辑是否重要,事实上对于任何一个项目,数据的建模都是不可少的环节。在数据建模的过程中,我始终遵从一个原则:“数据的最终目的是与用户交互”,因此我对数据的建模是站在“交互”的角度出发的。

基本概念

首先,对于数据建模这一环节,会有几个下文中频繁使用的概念:

  • Dataset:数据集,指一类数据的所有个体的集合。
  • Data Item:数据项,指一类数据的某个拥有可自我描述的属性的完整个体。
  • Operation:操作,指针对Dataset或者Data Item进行的操作,在现有多数应用中,操作以增、删、查、改的基本形式存在,通过相互组合衍生出不同的交互方案。

引用实例

为了更好说明数据建模的整个过程,举一个例子,下文也将以这个简单的例子为基础,一步一步展示如何从无到有形成数据的模型。

假设我们需要制作一个简单的系统,需求如下:

  • 可以注册用户。
  • 已经注册的用户可以发表文章。
  • 已经注册的用户可以对文章进行评论。

第一步,推导Dataset及Data Item

在以上的需求中,我们可以得到3个Dataset,即用户文章评论

随后这3个数据都是实打实的数据,即有“个体”和“群体”之分,因此可以抽出3个Data Item。

在这一步之后,可以得出一张简单的图,如下图所示,其中蓝色的圆为Dataset,黄色的圆为Data Item,这张图表示了组成一个系统的基本数据定义:

第二步,确立Operation

将Operation加入到数据建模中,并且作为非常重要的一步,这可能是我的建模方式与其他标准方案的最大差距。因为我的理论是“数据为交互而存在”,因此交互,即对数据的操作,本身也应当作为数据模型的一部分,并且是不可或缺的一部分。

首先,可以使用业界公认的方式,将数据的操作划分为列表(L)、查看(R)、修改(M)、删除(D)、创建(C)这五类,其中L主要针对Dataset,R和C主要针对Data Item,M和D则可以同时作用于Dataset及Data Item。

当然如果换一种更为灵活的角度,甚至可以将Dataset本身也看成一个Data Item,这样Dataset也将查看的操作,这往往就是应用中的“统计”、“概览”、“监控”之类对数据进行全局描述的部分了。

作为一个简单的示例,在此就先比较没脑地给各Dataset及Data Item加上相关的Operation,最终可以得到如下图所示的效果:

第三步,设计操作关系

我的建模方案的另一个特定是,我将关联(Relation)加在Operation之上,而非Dataset之上。这么做的原因依旧是那句话,“数据是为了交互而存在”,而这个数据模型的意义,也是希望可以通过它来改进界面及交互的设计,而非单纯地对数据进行定义,因此交互性远比静态数据的存在更为重要。

那么如何针对Operation来建立关联呢?

简单来说,我们在做一个操作的时候,总是希望有相关的内容可以提供参考,比如:

  • 当查看一个用户的信息时,会想知道他发过哪些文章。
  • 当看一个文章时,会想看到相关的评论。
  • 当看到一个评论比较有趣时,会想看一看作者的详细资料。

根据这些交互的设想,便会很容易地推导出Operation之间的关系:

  • 查看用户时,希望看到他的文章 – User.R到PostSet.L的关系。
  • 查看文章时,需要看到评论 – Post.R到CommentSet.L的关系。
  • 查看评论时,希望看到作者详细信息 – Comment.R到User.R的关系。

随后将这些关系通过有向的线段标识在图上,可以得到更加完整的模型,如下图所示(为了保证图尽可能地简洁明了,下图中并没有将所有的关系画出,仅仅表达意思):

这张图也就是我的数据建模的方法的最终产品,其特点在于:

  • 除了数据定义之外,加入了对操作的定义。
  • 将“关联”定义在操作之间,而非数据之间。

初看这张图并不能说明问题,但是他对接下去界面及交互的设计有着重大的意义,将在下一篇中详细阐述这张图是如何指导界面和交互的设计的。