到底什么是数据模型和数据建模

三墩IT人资深架构师斌哥，为您讲述他对数据模型和数据建模的思考。...

↑ 点击上方蓝色文字关注我们

作者简介

本文作者 — 斌哥，浙江移动资深IT架构师，文末有帅照哦 ^_^

在互联网公司数据模型的设计中，很多角色会参与其中，产品经理、数据分析师、开发人员，也包括关心数据的领导，说着诸如数据模型、数据建模、数据埋点、数据体系、指标体系的术语，也是含义众多，标准不一。而在电信领域虽然有较成熟的eTom模型或者BOSS规范做参考，但在项目建设中却又觉得模型规范太过于抽象或者遥远不切实际，不如自己根据需求画两张表，填几个字段省事，缺少对模型概念的提取和抽象。

最近看到的项目设计开发较少有对概念和逻辑模型的设计，移动公司本身也缺少围绕数据做运营的理念，所以在设计中融入运营指标体系一直是个大难题，2012年时曾经和产品、数据的同事有过交流，整理过一个例子，简单做个分享，希望对数据模型和数据建模概念的理解有一定帮助。

以下为旧文：

在一个系统的整体设计和实现中，数据的体现有不同层次，而数据也必然是和产品和业务相结合的。完整的业务模型应该包括数据模型和业务流程。而在数据体系上，从层次上我们可以划分为：指标体系 - 概念模型 - 逻辑模型 - 物理模型。

在产品设计的角度上往往看到的比较多的是UI界面，大部分PRD中提供的都是一个手机页面再接着一个手机页面，比如：

下载 -》访问 -》注册 -》登录 -》游戏

这个是业务流程，做得比较细的产品经理会在流程上标注出核心的业务数据，也就是我们通常所说的数据埋点。而从领导的角度更多看的是产品的成功与否如何做衡量？所以在一个产品设计开始就会先制定一些KPI指标，比如用户活跃度。如果指标是多维度的来做衡量的，就是指标体系。（一个好的指标体系肯定不会是以单个指标来衡量的，比如谷歌衡量用户体验的指标体系提到的HEART）

但这些都不是数据建模或者数据模型，数据模型通常是会从中抽象出概念模型，再经过设计和开发人员逐步细化到逻辑和物理模型。基于业务流程的数据埋点往往会偏重于主流程，分支会被忽略，维度可能考虑不全；而基于指标体系的数据设计关注点会偏于狭窄，并且指标只是计算的结果，而如何计算得到的才是关键。而要保证从产品设计到最终实现，数据指标定义和提取的一致性，模型的建立和一致的理解非常关键的。

拿一个“Facebook设计主管谈如何利用数据做决策”来简单分析一下之间的区别：

Julie讲述了自己的产品设计团队通过数据来分析用户是如何利用不同功能的，她以图片上传功能为例进行讲述。她的团队得出了以下几个数据：

87%的用户在第一屏中的相册专辑名字提示框中选择类型57%的用户打开文件选择功能来选择他们想上传的图片52%的用户点击上传按钮48%的用户会等待上传进度完成

问题1：少于50%的用户能够成功上传图片

解决方案：为了提高上传成功率，Facebook将Java/flash facebook文件选择功能改成浏览器原生文件选择功能，结果上传量提高11%。为了提高上传效率，在上传前不显示专辑创建功能。

问题2：团队发现上传图片的用户中有85%仅仅上传一张图片。

解决方案：团队发现用户不知道使用shift来选择多个图片进行上传，所以加了一个提示，在上传开始前出现上传多张图片的提示。结果数据从85%降低到40%。

纯从这段话中去理解，按以前的习惯我会先列出其中所有的名词：

用户、图片、相册、专辑、第一屏、文件、文件选择功能、上传按钮、java/flash选择、浏览器原声文件选择、浏览器、上传按钮、上传进度、上传量、上传成功率、上传效率、shift选择方式、提示

可以看到短短的一段话中，包含的信息量非常大。（很诧异很多设计在讲模型的时候几乎没啥，移动互联网项目说的就是下载、访问、付费，而电信领域BOSS项目也往往就是几张物理表混杂在一起）

然后我们来做一些分析，这是一个相册的产品，提供了专辑的管理和图片上传等功能。

首先我们可以看到关注的指标上传效率，具体的量化指标是上传量、上传成功率，还可以看到一个隐含指标是单个用户的上传量（团队发现上传图片的用户中有85%仅仅上传一张图片），这是领导关心的（或者应该还是说产品设计团队关心的）；

其次我们可以大致了解这个图片上传的业务流程是怎样的，并且把数值量化进去，以最开始添加图片的用户基数为100来计：

添加图片(100) -》创建专辑，选择专辑类型(87) -》选择文件(57) -》点击上传按钮(52) -》显示上传进度 -》等待进度完成(48)

整体的上传成功率为48%，也就是少于50%的用户能够成功上传图片。这是产品设计人员通常意义讲的数据埋点，在这个流程上面如果说做了数据埋点，记录了所有的操作，但却没有能体现Facebook所做的优化点“将Java/flash facebook文件选择功能改成浏览器原生文件选择功能”。另外即使单纯说上传成功率，这里的上传成功率是指所有用户的上传成功率还是所有用户所有上传记录的上传成功率呢？其实没有一个清晰的定义，这里涉及一个如何把一个用户的一次交互行为通过什么标示完成地连接在一起。我们的数据往往不同的行为由不同的系统或者不同的表来做记录，之间是断裂的，到了最后就演变成按用户能大致关联一下就ok了。

那么我们把以上的名词转化为数据模型应该是怎样的呢？画一个简单的概念模型：

虽然没有去细画实体的标识和主要属性，但我们发现在画概念模型的时候，我们需要关注其他一些信息：比如浏览器、操作系统、网络这些维度；关注添加图片、创建相册、选择文件等这些接触记录是需要统一标识；另外我们可以在选择文件中标注选择方式，在点击上传按钮中增加上传类型。数据的记录不再是零散的，而且数据之间是有关系的。

在概念模型画出来之后，就可以基于模型进行数据的演练，看上文中所涉及的数据或者指标都应该是如何从模型中得到的。比如上传成功率，就应该知道是从进度完成的上传记录除以发起“添加图片”的记录；而将Java/flash facebook文件选择功能改成浏览器原生文件选择功能，可以从点击上传按钮的记录中根据上传类型获取到。

这样的数据模型表达方式并非要去替代原有的PRD中的产品流程，它是数据需求描述的补充，在具体的开发设计中又可以根据此概念模型逐步细化到逻辑模型和物理模型。

这样的图该谁来画呢？产品设计人员、数据分析人员、开发设计人员，抑或是得有个数据架构设计人员的角色？数据架构的设计还是任重道远。