数据模型设计

建议完成【产品需求梳理】文档的学习后再学习本篇文档。 在完成了产品需求梳理之后，您已经决定了您的应用软件中需要哪些功能，这时候需要开始构建数据模型了。当您在设计数据模型时，一般建议用纸笔或者其他可视化软件来进行记录和设计，通常我们会推荐按照如下的设计步骤进行数据模型的设计

识别对象

在开始设计数据模型之前，一般我们已经梳理出了业务需求清单和最终应用程序展现的高保真或低保真图。这一节，我们还是以个人知识付费平台为例，利用上一节中已经完成的产品需求思维导图以及高保真设计稿来进行数据模型对象的识别。

• 根据业务需求抽取出需要进行信息分析的对象。实际上，这里的对象也可以理解为在上一节中梳理出来的核心功能抽象出来的实体，例如“用户”、“课程合集”、“课程订单”
• 先将最主要的对象罗列出来，接着可以通过用户在使用应用程序时操作流程的视角来识别出其他实体或抽象的对象。这个思考方式是完善数据模型时最主要的技巧！在个人知识付费平台的用户视角中，我们首先可以找出“用户”和“课程合集”两个实体对象，然后用户是如何在应用上“购买”课程的呢？他通过在首页浏览课程合集内容，进入到课程合集中查看课程详情内容，课程详情内容包含了“章节”、“课程”、“FAQ”等，通过“立即购买”生成“订单”来实现课程合集的购买。 我们不要求在这一步就把所有可能涉及到的对象全部找出来，数据模型的设计是一个不断修改优化的过程，需要与设计稿相结合，有时候可能页面设计上的需求导致了我们数据模型的修改。

确定关键属性

在找出了对象后，我们先快速的为他们确定一些关键属性。实际上，在上一节细化核心功能时，我们基本上就已经确定了每个对象的关键属性。在设计数据模型时，我们需要思考如何准确命名这些对象以及其关键属性名称来区分他们。

• 用户：用户名、头像、邮箱、手机号码、
• 课程合集：课程合集名称、封面图、卖点内容、语种、章节名称、课程名称、FAQ
• 课程合集订单：购买者、课程合集、购买时间、数量、价格、折扣金额、实付金额

  ⚠️ 这一阶段罗列的属性不需要是准确的，它的类别也不重要 重要的是通过罗列这些对象的关键属性为我们更清晰的明白他们之间可能存在的关系，以及如何更合适的设计

画草图

我们可以通过绘制 UML （Unified Modeling Language）图来建立一个对象关系草图来表示他们之间数据传递的方式。同时可以将上一步罗列的关键属性加入到对象当中。当然你也在纸上完成最终逻辑数据模型的，完全可以按照习惯的方式来。

绘制UML图

使用UML（Unified Modeling Language）来绘制数据模型并不是必须的

然而依托于飞书强大的协同办公能力，以及在文档中添加/编辑UML图，目前我们通常会用飞书的UML图绘制工具制作数据模型。

我们建议在绘制草图的时候就开始使用UML工具来制作，主要有两个原因：

• 通过接下来的设计步骤最终它会形成一个可以应用在Zion上的逻辑数据模型；
• 我们可以将绘制的数据模型方便地同步给项目各方。

飞书文档绘制步骤

• 在飞书中新建一个文档或者在已有的项目相关文档中插入UML图

• 在左侧UML下找到“类图”的第二个，拖动到画布中用来添加数据模型的对象，也就是数据表

• 表头“account”对应的是“数据表名称”，“field”对应的是“字段名”，“type”对应的是“字段类型”

以对象“用户”举例，我们可以将数据表名称修改为“account (用户)”。 可以在名称后面加中文备注 我们通常会将数据表的第一个字段改为“id”，其类型是“bigserial”（自增长的大整数） . 将“field”改为之前找到的关键属性“username(用户名)”，type 指的是这个属性的数据类型，name一般是以文本呈现，所以是text类型。 再继续完成剩余对象数据表的添加，这里可能会有疑问，为什么合集、章节、课程、FAQ以及评价是不同的表，以及订单表中为什么没有购买者的姓名以及课程的详细信息？你可以参考【数据模型概念】来进一步了解，也可以继续往下看

接下来，我们将为对象也就是数据表之间建立关系，建立关系的目的是让数据表之间可以相互引用数据，如果你了解了【数据模型概念】这时候我们需要思考两个问题：

1. 他们之间是什么类型的关系？是1：1还是1：N，还是M：N？
2. 哪个对象是被引用方，哪个对象是引用方？ 我们来看一下“合集”和“章节”两个对象之间的关系，一个课程合集有多个章节，在章节表中，需要记录这个章节是属于哪一个课程合集，所以我们会给“合集”对“章节”建立1：N关系，“合集”就是引用方（也叫一的一方），而“章节”就是被引用方（也叫N的一方/多的一方），建立关系实际上就是在被引用的数据表中新增一个用来记录引用方的字段（这个字段在 Zion 中为表之间添加关系后是自动添加的，不需要自己添加），这个字段一般就是引用方的id（因为id拥有“唯一”的特性）

点击被引用对象，点击并拖动字段旁出现的蓝色箭头图标，将其拖动到引用对象的关系字段（account）上。然后可以通过点击表头位置选中数据表后来拖动调整他们的布局。 我们可以通过点击关系线，然后拖动关系线上的蓝色航点来改变它的走线。双击关系线上的非航点位置，为其添加关系类型的描述，这里修改为“1:N”，然后在右侧编辑窗口打开它的背景色，这样就不会被关系线遮挡了。 至此你已经学会了在UML工具上绘制数据模型所需的所有基本技能了，并且在绘制数据模型时，你也能够根据需求来梳理好对象之间的关系。

找出数据属性

为各个对象添加所需的属性，完善数据表的字段。我们同样可以利用用户操作流程的角度结合设计步骤第二步【确定关键属性】来思考，找出现有对象外其他业务需要添加的数据。思考这个问题可以发现在步骤一中遗漏的对象。

回到个人知识付费平台中的几个例子：

• 用户有必要知道订单的状态，因此需要添加“订单状态”字段。
• 用户虽然只看到上线的商品，但是管理者需要对课程合集的状态进行管理，不再售卖的课程合集需要下架，并且可以在修改商品状态后及时的反馈给用户，因此需要添加“状态”字段# 分配属性 将上一步骤中的数据分配到对象中并且添加字段的类型以说明数据的业务含义。 这意味着我们可以通过数据表中添加的字段，反向来检查是否符合业务的需求，以及应用程序功能的满足情况。 另外，数据表的关系字段是否正确的添加在了引用方的数据表中？新属性的添加之后通常会使我们更清晰的明白数据表之间的正确关系 关系字段的命名规则： 通常情况下我们在引用方中添加的关系字段用被引用方的数据表名称表示。 而且对于1：N关系往往会采用名词复数的形式。 他是字段名称来表示是否是关系字段的提示，同时也代表了这个字段可以重复出现某一个数据。 当然也有很多时候我们会自定应关系字段名称来更好的表达他对应的含义，比如“分类”的自关联“父级分类”字段。 然后关系字段的类型填写被引用的数据表名称。 比如： “媒体库”中引用商品的关系字段更合适的字段名是“products(商品)：product” 在此基础上完善UML图的制作

校验完善

最终确定数据模型并验证其准确性。 这里的验证不仅仅是作为数据模型的制作方自己，还需要通过制作的逻辑数据模型和业务需求方确定页面设计与功能的实施是否能实现，有没有可以优化或调整的内容。 另外不要忘记数据模型是一个不断修改优化的过程，通过制作数据模型往往可以得到对业务逻辑更深入的理解。 通过以上步骤我们会得到一个理想的逻辑数据模型，接下来可以在 Zion 实现项目物理数据模型的制作。 值得一提的是，以上的设计步骤并不一定是线性的，实际上很多时候我们会交替进行，反复优化得到最终的数据模型。这些过程在放到具体的数据库工具之前，也就是物理数据模型制作之前都是合理且必要的。 而一旦在 Zion 上制作完数据模型并且将数据进行绑定和上线之后，修改数据模型将会带来很多不必要的麻烦。

在 Zion 中搭建数据模型

数据模型是搭建应用的核心，一般我们建议您利用 UML 图设计好了数据模型，并且确认不再会有特别大的变动之后再进入到 Zion 中搭建您的数据模型，数据模型搭建的操作方式您可以参考【数据模型】

在下一节中，我们将探讨如何进行用户界面与交互设计