为什么ER建模是软件产品设计的核心：通过一个案例让你深刻理解

为什么ER建模是软件产品设计的核心：通过案例深入理解

编者注：你知道什么是ER建模吗？产品经理需要关注决定软件产品的可扩展性和灵活性的ER建模工作。本文作者举了一个在线教育公司ER建模的例子，让大家在老王和小李的对话中展现ER建模的魅力，同时加深对ER建模的理解。

ER建模：EntityRelationship，也称为实体建模，是软件工程中非常重要且基本的概念。

产品经理，尤其是B端产品经理，一定要掌握和重视ER建模工作。

ER建模的质量决定了软件产品的可扩展性和灵活性。不准确的ER建模可能会导致软件设计错误，甚至严重的业务问题。

如果我们将软件产品的设计比作建筑物的建造，那么ER建模抽象出来的物理对象就是建筑物的基础。围绕物理对象构建的应用程序功能是当地基不稳定或出现问题并且建筑物可能倒塌或无法按预期运行时建筑物的外观。

这些理论描述可能会让您感到困惑。接下来，我们将通过一个实际案例，带您深入了解ER建模的神奇之处。

在开始案例之前，我们先简单介绍一下ER设计的相关知识。

1.什么是ER建模？

软件设计的主要目标是精确地指定和抽象客观世界中的事物，并将其转化为计算机可以理解的面向对象的设计。

将客观事物抽象为设计对象称为ER建模。

例如，电商账户和订单是抽象实体，每个订单只能属于一个账户。这是账户和订单之间存在的一对多关系。

除了一对多关系之外，实体还可以具有零对多和多对多关系。

描述实体对象和关系的图称为ER图（例如UML、Chen、Crow'sFoot等）。作为产品经理，没关系，你需要画得简单、清晰。简单地表达设计的目的。例如上面提到的账户和订单实体关系图，可以很容易画出如下：

本文的目标是让每个人都能了解ER建模如何影响产品解决方案并定义业务，因此不涉及建模和设计方法的一些基础知识。

接下来我们进入我们的案例。

案例2：某在线教育公司ER建模

一家初创公司推出了一项针对幼儿的在线教育活动。由于单位客户成本较高，他成立了电子销售中心团队来完成销售工作。公司安排了资深产品专家老王负责产品方案的整体设计。小李是老王的助理兼初级产品经理。

老王决定利用这个机会培养一下小李，于是他一步步指导小李进行设计工作。

老王：小李，公司计划推出在线教育，我们会首先关注客户的模型设计。

小李：王老师，什么是客户建模？这个问题是不是很简单，完成正常的客户注册后下订单不就可以了吗？

老王：这项工作比你想象的要困难得多。客户模型的设计对整个公司的发展和体系结构有着全面的影响。慢慢的我会引导你去理解。不过首先你可以根据我刚才说的，用我教你的ER图，尝试画一个草图，我们会在此基础上一步步分析。

小李：好的，王总，我想我们面对的是典型的C端客户，他们只需要一个账户对象，每个账户下可以创建多个订单。ER图如下。

老王：很好账号和订单是两个很常见的项目。然后，在客户注册后，电子销售人员将开始监控服务。我们需要设计一个CRM系统供销售人员使用。您认为销售人员在CRM中应该管理的客户对象应该是账户？

小李：我认为销售人员在CRM中管理“账户”是没有问题的，但在我看来，销售人员应该监控客户，而不是账户，但我无法清楚地解释其中的关系和定义。

老王：你的感觉是对的。销售人员应该在CRM系统中管理客户，而不是他们的帐户。其实在销售管理中，我们认为新注册的客户、账户等都是潜在客户，而潜在客户就是指潜在客户。典型的CRM系统除了潜在客户之外还有商机的概念，但我们在这里不使用它。

小李：在我看来，CRM系统和客户登录账户之间没有明显的联系。出色地。

老王：不能说不重要。在数据建模中，我们需要清楚地区分这些对象的概念，并保证逻辑定义清晰。在我们公司，我们可以设计线索和客户是一对一的关系，销售人员和线索是一对多的关系，即一个销售人员可以有多个线索，每个线索只能属于0或1次销售。

小李：为什么领先可以属于0，什么意思？

老王：因为在CRM系统中，并不是每一个线索都有销售管理跟进，有些线索可能没有被存储或跟踪，所以线索和销售是一对多的，“多”是指“0或”更多”。我们改进一下ER图，如下：

小李：这张图看上去比较清晰，背后对应的设计思路也比较清晰。但我还是不明白为什么需要将账户和小费两个实体分开，除了让逻辑更清晰之外？

老王：物品的明确建模和设计不仅逻辑上更清晰，而且非常重要。这句话怎么理解呢？

ER模型最终转化为数据库表结构。潜在客户和客户可以分别存储在两个不同的数据库中，即CRM系统数据库和客户中心数据库。我们看一下下面的图片：

老王喝了一口水，继续说道：我在外面画了一张ER图。桶代表的是数据库，桶外面的矩形，可以看到，其实就是我们在ER图中描述的四个实体，分别属于三个数据库和各自的业务系统。

这样的ER图设计，清晰的传达到了底层的数据库设计和应用系统设计，保证了销售系统、用户中心、订单中心很好的解耦，相互独立，互不影响。其他。

例如：如果更新CRM系统时出现问题，不会影响用户中心系统，至少客户仍然可以登录访问应用程序。

而如果线索和账户设计为单一实体，对应的表结构设计可能是一个表，使得多个应用系统使用同一个数据库底层，可能会导致CRM销售拜访功能更新而出现问题。影响C最终用户登录到应用程序。

小李：原来如此，听起来很有道理。难怪我们创业时搭建的系统总是联网的，升级库存系统就能拉垮销售系统。

老王：系统捆绑往往是初创公司设计中为了快速上线而做出的妥协。比如每个业务系统做一套代码、一套数据库。当然，我在这里举这个例子主要是为了说明ER建模对数据库表设计和应用系统设计的转移和影响。

小李：是的，现在我对技术有了更深的理解。

老王：我们还是回到建模本身吧。目前的模式仍然存在很多问题。比如说现在的模式下，孩子的家长注册了账号我们该怎么办？

小李：我们可以分开报名吗？

老王：其实这个问题很严重，因为每次家长注册后，都会产生两个独立的线索，而CRM系统通常会设置两个后续销售。

但对于这个家庭来说，只需要为孩子购买一门课程即可。那么，两家厂商可能会进行恶意竞争，向顾客做出虚假承诺，甚至向家长做出不一致的陈述，以获取家长的佣金。，导致客户体验极差。

而且，一旦下单（顾客付款），就很难判断哪个卖家的信用更大。这就造成了卖家之间日常的争吵，对业务的发展非常不利。

小李：有道理，如果爸爸注册了，妈妈重新注册了，那么把妈妈的线索分配给以前关注过爸爸线索的卖家不就对了吗？

老王：对啊，问题是我们不知道爸爸和妈妈是不是一家人？我们的模型设计并没有预留这样的能力支持。你觉得改变它怎么样？

小李（思考）：是的，我们可以把以前的单一账户体系改为子母账户体系。这样就可以建立所有权关系，如果父亲和母亲互相关联账户，员工就可以识别同一个父母，不存在冲突。如下所示：

老王：很好，你的模型提供了数据底层的能力，是我们在应用层面解决销售冲突业务问题的前提。

小李：但是我还是不明白这个底层模型是如何支撑业务的，因为一般来说C端用户在注册的时候没有动力去链接家庭账号？

老王：一般来说，C端用户不会主动关联账号。但是当我们有了这个设计背后的数据的支持时，我们就可以执行各种功能来解决业务问题。同时，还必须与业务系统相结合。例如，销售部门可以明确规定，在第一次跟进新线索时，所有销售人员必须首先确认该帐户不是同一个家庭帐户或其他注册家长的手机号码。

如果发现这种情况，请在CRM系统中提供合并帐户和链接两个或多个帐户的功能。这样账户对应的线索也能找出一一对应的关系，所以。多个相关销售线索被分配给同一销售人员。同时，还可以提供C端功能，指导家长完成多个家庭手机号码的配对。

正是因为我们在数据建模中考虑了这个问题，为数据驱动设计做好了准备，我们才能在应用特征层面实现这些特征点，解决未来的业务问题。

小李：明白了，太棒了！如果销售部门明确表示需要确认账户是否重复，但销售人员仍不遵守规定，那么即使第二次后续销售成功，仍会评估佣金。属于第一业务员，只要规则明确，大家就必须遵守。

老王：你说得对！然而，您的主要和辅助帐户的设计可以让您感觉受到管理。还有其他解决方案吗？

小李（挠头）：我想不出来！

老王：其实我们公司的结构和我们面对的客户都是典型的家庭结构。在数据的底层，可以按照家庭模型进行建模，在账户之上设计一个家庭单元。账户都是同一级别的，属于特定的家族，也可以完成账户关系。如下所示：

小李：太棒了！家庭和账户是一对多，提示和账户是一对一，这确保了可以在数据底部识别多个提示。

老王：是的，其实账号本身和线索以及家人的关系并不是很合理。该账户仅代表用户访问系统的凭证，并不代表用户本人。

实际上，一个用户可以拥有多个手机号码。对于企业来说，识别唯一的客户及其背后的多个手机号码是理想的选择。因此，从建模严谨性的角度来看，我们还必须抽象出上级的实体。修改后的ER图如下：

小李：我不太明白这样做的目的是什么？图中你没有把parents和account设计成一对多的吗？

老王：家长和账号一对多的设计，增加了系统的一些复杂性，也让用户体验变得复杂。

事实上，在当今大多数互联网和企业业务中，客户和帐户都被设计为一对多，这对于业务来说并没有多大价值。因此，为了简化目的，采用一对一的设计。然而，对于某些公司来说这是必要的。采用一对多的设计。

例如，支付宝通过身份证识别唯一客户，并允许一个客户注册多个账户（实际上支付宝这样做是有历史原因的）。

但即使父母和账户是一对一的，我们仍然需要将两个实体（父母和账户）分开，以确保逻辑清晰。毕竟，账户只是登录凭据，并不代表用户本人。

我们可以在应用程序级别简化和呈现复杂的系统逻辑，但尽可能保持数据底层逻辑的准确性。虽然这增加了底层设计的复杂性，但可以保证应用层设计的系统灵活性。

小李：有道理。

老王：这种模式也存在影响业务的致命问题。

小李：啊？任何？我认为这很完美！

老王：现在的订单是和账户挂钩的。如果家里只有一个孩子，这样的模式是没有问题的，但是如果家里有几个孩子呢？事实上，目前的模型并不支持这种业务场景。

小李：是的，这个问题的核心是我们的模型中没有子实体！

老王：您认为如何改进这个模式？

小李：我想一下是否可以在家庭下面添加一个子实体，订单挂在子实体上。默认情况下，系统创建一个子项，并将采购订单挂在第一个子项上。如果家里有多个孩子，家长在添加孩子时也会得到支持，并可以为其他孩子购买订阅。ER图修改如下：

老王：那太好了。

小李：但是我还是很困惑，是不是太复杂了？事实上，如果有多个孩子，那不就解决了让顾客注册一个账户而不是合并家庭并支付订单的问题了吗？

老王：你对替代解决方案的看法是对的，但它们会失去客户体验并导致其他业务问题。

其实产品设计最重要的是能够把所有的业务场景和问题想通，然后经过大量的研究和开发，根据资源和实施周期做出合理的规划，先做减法。

尤其是在ER建模过程中，你需要非常仔细、全面地思考，因为你会发现ER建模过程会帮助你组织你的业务。过程。

确实，如果底层模型设计过于复杂，会导致研发工作量爆炸，但更重要的是，你可以清楚地考虑所有业务场景，评估不同设计的投入产出比，并与业务和技术人员进行沟通。管理者们充分沟通，最终制定出经过充分评估和论证的设计方案。

小李：原来如此，长辈说的千真万确！

老王：我们回到刚才提到的多孩子场景。事实上，上图的ER模型已经可以非常灵活地支持不同的业务需求。

例如，如果家里有两个孩子在某一天购买了课程并上课，而当时孩子的父母在其他地方，想观看两个孩子分别学习的情况（常见于在线学习）（班级监控功能），得益于该模型的支持，可以在C端app中执行强大的功能，分别查看两个孩子的班级状况。

小李：我理解如果没有这样的模式，要求家长注册账号，也会造成销售管理的混乱。

老王：是的。因此，这些问题我们需要思考清楚。另外需要重点关注的一点是ER建模最终会转化为数据库表格设计。在软件工程中，最终修改表结构后是非常麻烦的。

比如说，如果我们从一开始就按照最简单的方案来设计客户的模型，那么在未来的某一天，如果我们想要切换到上面理想的模型，那么研发的投入将是非常巨大的，甚至是不可能的。。。

软件系统重构中最麻烦的问题就是历史数据迁移到新的数据结构。

小李：我明白了，所以ER建模是一个非常重要的设计工作，需要充分讨论和仔细！

老王：是啊。接下来，我再问大家一个问题。

小李：我感觉头晕。您还有什么问题？

老王：如果孩子也有账号，需要用手机号登录系统，你的模型应该如何调整？

小李：啊，真的，我以为我们是做幼儿教育的，孩子们必须用父母的账号登录应用程序才能完成学业。但确实有可能，如果我们的教育产品延伸到中小学，今天每个人都会有手机。让我想想，不然这样改如何？

老王：你的设计没有问题，但是你不觉得抽象的实体有点多余吗，孩子和父母其实都是“人”，无非是不同年龄段的“人”。

小李：我想想，做成这样怎么样？最后，父母和孩子这两个实体被进一步抽象为“人”维度，并通过“人”的某个属性来表示是父母还是孩子（甚至不用标注，只需要按年龄和相关业务规则进行识别）。

这样的设计还好吗，看起来逻辑上是否清晰干净，但是工程应用起来是否复杂化了？嗯，这件事，还是需要找到技术负责人老李，详细讨论一下。

老王：是的，你需要和技术负责人沟通讨论，想得越复杂越好！不过，我还有一些问题想问你。

小李：请讲！

老王：在这个最终的模型中，订单应该与“人”相关还是与“账户”相关？如果人和账户是一对多的关系，应该如何下单？家长购买课程时收取的积分应该与“人”、账户还是“家庭”挂钩？学生在课堂上获得的奖励应该与“人”、账号还是“家庭”有关？

小李：哎呀，为什么这些问题看起来那么复杂，要留给我们这些聪明的读者去思考呢？哈哈！

老王：我觉得可行！

#专栏作家#

杨坤，公众号：PM杨坤（ID：pmYangKun）。所有人都是产品经理和《赢得B端》作者。他拥有12年互联网开发和产品设计经验，现任MankuConsulting首席执行官。

本文最初发表于人人都是产品经理。未经许可禁止转载。

封面图片由Unsplash提供，已获得CC0许可