编辑导语：ER建模你知道是什么吗？对于产品经理来说必须重视ER建模工作，它决定了软件产品的扩展性和灵活性。本文作者通过例举了某在线教育公司的ER建模的例子，让大家在老王和小李的对话中，展现ER建模的魅力，同时加深对于ER建模的理解。
ER建模：Entity Relationship，也叫实体建模，是软件工程中非常重要且核心的概念。
对于产品经理，尤其是一名B端产品经理，必须掌握并且重视ER建模工作。ER建模的好坏，决定了软件产品的扩展性和灵活性。ER建模不准确，有可能导致软件设计缺陷，甚至带来严重的业务问题。
如果将软件产品设计比喻成盖大楼，那么ER建模抽象出的实体对象就是大楼的根基，围绕实体对象建设的应用功能就是大楼的外貌，根基决定了大楼的结构和功能，如果根基不稳或错误，大楼就有可能崩塌或不符合预期。
这些偏理论的叙述可能会让大家感到困惑，接下来，我们通过一个实际案例，让大家深刻理解ER建模的魅力。在案例开始之前，我们再稍微对ER设计相关知识，做一个非常简单的介绍。什么是ER建模软件设计的核心要点，就是将客观世界的事物，准确的提炼抽象，变成计算机可以理解的面向对象的设计。
我们将客观事物抽象成对象设计的过程，就叫ER建模，抽象出来的对象，就叫做实体，除了抽象出实体，我们还需要关心实体的属性，以及实体之间的关系。比如电商中的账号和订单，就是抽象出的实体，一个账号可能有多个订单，每个订单只可能归属于一个账号，这就是账号和订单之间存在的一对多关系。
除了一对多关系，实体之间可能还存在零对多，多对多的关系。
描述实体对象和关系的图形，叫做ER图，ER图的呈现方式有很多种规范，绘制方法不重要，作为一名产品经理，只需要简单清晰地表达出设计意图即可。比如上述提到的账号、订单实体关系图，可以简单绘制如下：本文的重点，在于让大家理解ER建模如何影响了产品方案并决定了业务，所以关于建模的一些基础知识和设计方法论不展开讲述。接下来，进入我们的案例。
案例：某在线教育公司的ER建模某初创公司开展在线教育业务，面向低龄儿童，因为客单价高，成立电销中心团队完成销售工作。公司安排了资深产品专家老王负责整体产品方案设计，小李是老王的助手，初级产品经理。老王决定借这个机会锻炼培养小李，因此手把手指导小李参与设计工作。老王：小李啊，公司计划开展在线教育业务，让我们首先聚焦在客户的模型设计部分，你可以聊聊你的想法啊。
小李：王老师，客户建模是什么？这个问题不是很简单么，我们只需要一个C端的app，有一套账号中心，客户完成常规注册后，在销售的引导下下单不就可以了么？老王：这个工作会比你预想的复杂很多，客户模型的设计，对整个业务的开展，和系统的建设，都有全面的影响。慢慢我会引导你理解。不过你可以先基于你刚刚的说法，尝试用我教你的ER图，画一个草图出来，我们在此基础上一步步展开分析。小李：好啊王老师，我认为我们面对的是典型的C端客户，只需要一个账号对象，每个账号下可以创建多个订单，ER图如下：老王：很好，账号和订单是很常见的两个实体。
那么，客户注册后，会由电销销售人员跟进服务，我们需要设计CRM系统给销售人员使用。你认为销售人员在CRM中操作管理的客户对象应该是什么，是账号么？小李：我觉得销售人员在CRM中管理操作的对象是“账号”好像没什么问题，但又感觉怪怪的，感觉销售人员跟进的应该是客户，而不是账号，但我说不清楚这里边的关系和定义。老王：你的感觉是正确的，销售人员在CRM系统中管理的应该是客户，而不应该是客户的账号。实际在销售管理中，我们认为新注册的客户、账号等等，都属于销售线索，线索就是指潜在客户。
在典型的CRM系统中除了线索，还有商机的概念，不过在我们这里用不到。小李：好像这样清晰一些了，感觉CRM系统和客户的登录账号就没有明显关系嘛。老王：也不能说没有关系，只是我们在做数据建模的时候，要分清楚这些对象的概念，保证逻辑定义的清晰。
在我们的业务中，可以设计线索和账号就是一对一关系，销售人员和线索是一对多关系，即一个销售可以拥有多条线索，每个线索只能属于0个或1个销售。小李：为什么一个线索还可能属于0个销售呢，这是什么意思呢？老王：因为在CRM系统中，并不是每条线索都有销售管理跟进，有些线索可能是无人维护跟进状态，所以线索和销售是1对多，其中的“多”，是指“0或多个”。我们将ER图完善，如下：小李：这个图看起来更清晰了，背后对应的设计思路也比较明确。
不过我还是有点不理解，为什么非要把账号和线索这两个实体分开，除了逻辑上更清晰，还有什么好处呢？老王：对实体进行明确的建模和设计，除了逻辑上更清晰以外，还有很重要的一点，这样做，可以降低软件系统设计的耦合性。如何理解这句话呢？ER模型最终会转化成数据库表结构设计，线索和账号可以分别保存在两张数据表，进一步讲，隶属于两个不同的数据库，即CRM系统的数据库，和账号中心的数据库。我们来看下边这张图：老王喝了口水，继续说道：我在ER图外边绘制了两个框，圆桶代表数据库，圆桶外边的矩形代表业务系统，可以看到，实际上我们在ER图中描述的四个实体，分别隶属于三个数据库，和各自的业务系统。这样的ER图设计，被清晰地传导到数据库底层设计，以及应用系统的设计，可以保证销售系统、用户中心、订单中心三者很好地解耦合，各自独立，互不影响。
例如：CRM系统如果更新时出了问题，并不会影响到用户中心系统，至少客户还可以登录访问app。而如果线索和账号被设计成一个实体，对应的表结构设计可能就是一张表，就会导致多个应用系统使用同一个数据库底层，可能造成CRM更新一个销售拜访的功能，出问题影响到C端用户登录app。小李：明白了，听起来很有道理，ER建模不仅在逻辑上很清晰，还能在物理存储上也很清晰。
怪不得我们以前公司创业时做的系统，总说耦合在一起，非常死板，仓库系统做个升级，能把销售系统干趴下。老王：很多时候系统耦合，都是创业公司为了快速上线，做的设计方案的妥协，比如各个业务系统做成一套代码，一套数据库。当然，我在这里举这个例子，主要是想说明ER建模对数据库表设计、对应用系统设计的传导和影响。小李：嗯嗯，这下对技术的理解又深刻一层。
老王：我们再回到建模设计本身。现在的模型，依然存在很多问题。比如说，在目前的模型中，如果小朋友的爸爸妈妈都注册了账号，该怎么办？小李：听起来没啥问题啊，那就各自注册呗？老王：其实问题很严重，因为爸爸妈妈各自注册后，会产生两条没有关系的销售线索，CRM系统一般情况下会分配给两个销售跟进。
但对于这个家庭来讲，实际上只需要给孩子购买一次课程，那么，两名销售为了各自搞定家长获得提成，可能就会产生恶意竞争，给客户做出虚假的承诺，甚至给爸爸妈妈表述不一致，造成极差的客户体验。而且如果成单，很难说清楚到底是哪个销售的功劳更大，这就会造成销售人员之间天天打架扯皮，非常不利于业务开展。小李：有道理，那如果爸爸注册了，妈妈再注册，让妈妈的线索分配给之前跟进爸爸。
