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

编辑导语:ER建模你知道是什么吗?对于产品经理来说必须重视ER建模工作,它决定了软件产品的扩展性和灵活性。本文作者X例举了某在线教育X的ER建模的例子,让大家在老王和小李的对话中,展现ER建模的魅力,同时加深对于ER建模的理解。

ER建模:Entity Relationship,也叫实体建模,是软件工程中非常重要且核心的概念。

对于产品经理,尤其是一名B端产品经理,必须掌握并且重视ER建模工作。

ER建模的好坏,决定了软件产品的扩展性和灵活性。ER建模不准确,有可能导致软件设计缺陷,甚至带来严重的X问题。

如果将软件产品设计比喻成盖大楼,那么ER建模抽象出的实体对象就是大楼的根基,围绕实体对象建设的应用功能就是大楼的外貌,根基决定了大楼的结构和功能,如果根基不稳或错误,大楼就有可能崩塌或不符合预期。

这些偏理论的叙述可能会让大家感到困惑,接下来,我们X一个实际案例,让大家深刻理解ER建模的魅力。

在案例开始之前,我们再稍微对ER设计相关知识,做一个非常简单的介绍。

一、什么是ER建模

软件设计的核心要点,就是将客观世界的事物,准确的提炼抽象,变成计算机可以理解的面向对象的设计。

我们将客观事物抽象成对象设计的过程,就叫ER建模,抽象出来的对象,就叫做实体(Entity),除了抽象出实体,我们还需要关心实体的属性,以及实体之间的关系(Relationship)。

比如电商中的账号和订单,就是抽象出的实体,一个账号可能有多个订单,每个订单只可能归属于一个账号,这就是账号和订单之间存在的一对多关系。

除了一对多关系,实体之间可能还存在零对多,多对多的关系。

描述实体对象和关系的图形,叫做ER图,ER图的呈现方式有很多种规范(比如UML,Chen,Crow’s Foot等等),绘制方fǎ不重要,作为一名产品经理,只需要简单清晰地表达出设计意图即可。比如上述提到的账号、订单实体关系图,可以简单绘制如下:

为什么说ER建模是软件产品设计的核心:X一个案例让你深刻理解!

本文的重点,在于让大家理解ER建模如何影响了产品方案并决定了X,所以关于建模的一些基础知识和设计方fǎ论不展开讲述。

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

二、案例:某在线教育X的ER建模

某初创X开展在线教育X,面向低龄儿童,因为客单价高,X电销中心团队完成X工作。X安排了资深产品X老王负责整体产品方案设计,小李是老王的助手,初级产品经理。

老王决定借这个机会锻炼培养小李,因此手把手指导小李参与设计工作。

老王:小李啊,X计划开展在线教育X,让我们首先聚焦在客户的模型设计部分,你可以聊聊你的想fǎ啊。

小李:王X,客户建模是什么?这个问题不是很简单么,我们只需要一个C端的app,有一套账号中心,客户完成常规注册后,在X的引导下下单不就可以了么?

老王:这个工作会比你预想的复杂很多,客户模型的设计,对整个X的开展,和系统的建设,都有全面的影响。慢慢我会引导你理解。不过你可以先基于你刚刚的说fǎ,尝试用我教你的ER图,画一个cǎo图出来,我们在此基础上一步步展开分析。

小李:好啊王X,我认为我们面对的是典型的C端客户,只需要一个账号对象,每个账号下可以创建多个订单,ER图如下:

为什么说ER建模是软件产品设计的核心:X一个案例让你深刻理解!

老王:很好,账号和订单是很常见的两个实体。那么,客户注册后,会由电销X人员跟进X,我们需要设计CRM系统给X人员使用。你认为X人员在CRM中cāo作管理的客户对象应该是什么,是账号么?

小李:我觉得X人员在CRM中管理cāo作的对象是“账号”好像没什么问题,但又感觉怪怪的,感觉X人员跟进的应该是客户,而不是账号,但我说不清楚这里边的关系和定义。

老王:你的感觉是正确的,X人员在CRM系统中管理的应该是客户,而不应该是客户的账号。实际在X管理中,我们认为新注册的客户、账号等等,都属于X线索,线索就是指潜在客户。在典型的CRM系统中除了线索,还有商机的概念,不过在我们这里用不到。

小李:好像这样清晰一些了,感觉CRM系统和客户的登录账号就没有明显关系嘛。

老王:也不能说没有关系,只是我们在做数据建模的时候,要分清楚这些对象的概念,保证逻辑定义的清晰。在我们的X中,可以设计线索和账号就是一对一关系,X人员和线索是一对多关系,即一个X可以拥有多条线索,每个线索只能属于0个或1个X。

小李:为什么一个线索还可能属于0个X呢,这是什么意思呢?

老王:因为在CRM系统中,并不是每条线索都有X管理跟进,有些线索可能是无人维护跟进状态,所以线索和X是1对多,其中的“多”,是指“0或多个”。我们将ER图完善,如下:

为什么说ER建模是软件产品设计的核心:X一个案例让你深刻理解!

小李:这个图看起来更清晰了,背后对应的设计思路也比较明确。不过我还是有点不理解,为什么非要把账号和线索这两个实体分开,除了逻辑上更清晰,还有什么好处呢?

老王:对实体进行明确的建模和设计,除了逻辑上更清晰以外,还有很重要的一点,这样做,可以降低软件系统设计的耦合性。如何理解这句话呢?

ER模型最终会转化成数据库表结构设计,线索和账号可以分别保存在两张数据表,进一步讲,隶属于两个不同的数据库,即CRM系统的数据库,和账号中心的数据库。我们来看下边这张图:

为什么说ER建模是软件产品设计的核心:X一个案例让你深刻理解!

老王喝了口水,继续说道:我在ER图外边绘制了两个框,圆桶X数据库,圆桶外边的矩形XX系统,可以看到,实际上我们在ER图中描述的四个实体,分别隶属于三个数据库,和各自的X系统。

这样的ER图设计,被清晰地传导到数据库底层设计,以及应用系统的设计,可以保证X系统、用户中心、订单中心三者很好地解耦合,各自X,互不影响。

例如:CRM系统如果更新时出了问题,并不会影响到用户中心系统,至少客户还可以登录访问app。

而如果线索和账号被设计成一个实体,对应的表结构设计可能就是一张表,就会导致多个应用系统使用同一个数据库底层,可能造成CRM更新一个X拜访的功能,出问题影响到C端用户登录app。

小李:明白了,听起来很有道理,ER建模不仅在逻辑上很清晰,还能在物理存储上也很清晰。怪不得我们以前X创业时做的系统,总说耦合在一起,非常sǐ板,仓库系统做个升级,能把X系统干趴下。

老王:很多时候系统耦合,都是创业X为了快速上线,做的设计方案的妥协,比如各个X系统做成一套代码,一套数据库。当然,我在这里举这个例子,主要是想说明ER建模对数据库表设计、对应用系统设计的传导和影响。

小李:嗯嗯,这下对技术的理解又深刻一层。

老王:我们再回到建模设计本身。现在的模型,依然存在很多问题。比如说,在目前的模型中,如果小朋友的bàbàmāmā都注册了账号,该怎么办?

小李:听起来没啥问题啊,那就各自注册呗?

老王:其实问题很严重,因为bàbàmāmā各自注册后,会产生两条没有关系的X线索,CRM系X般情况下会分配给两个X跟进。

但对于这个家庭来讲,实际上只需要给孩子X一次课程,那么,两名X为了各自搞定家长获得提成,可能就会产生è意竞争,给客户做出虚假的承诺,甚至给bàbàmāmā表述不一致,造成极差的客户体验。

而且如果成单(客户付费),很难说清楚到底是哪个X的功劳更大,这就会造成X人员之间天天打架扯皮,非常不利于X开展。

小李:有道理,那如果bàbà注册了,māmā再注册,让māX线索分配给之前跟进bàbà线索的X,不就可以了么?

老王:说的没错,问题是,我们并不知道bàbà和māmā是否是一家人啊?我们的模型设计,并没有预留这样的能力支撑。你想想该怎么修改呢?

小李(沉思中):有了,我们可以将以前的单一账号X,改成子母账号X,账号可以彼此建立归属关系,这样如果bàbà和māmābǎng定彼此账号,X人员就能够识别同一家庭的家长,就不会有X了。如下图:

为什么说ER建模是软件产品设计的核心:X一个案例让你深刻理解!

老王:很好,你的这个模型,在数据底层X了能力支持,是我们在应用层面解决XXX问题的一个前提基础。

小李:不过我还是没想明白,这个底层模型如何支持X,因为一般C端用户并没有动力在注册时做家庭账号关联啊?

老王:你说的很对,一般C端用户并不会主动去做账号关联,但是如果我们有这个数据底层设计的支持,就可以在应用系统层面做各种功能,来解决X问题,同时还要结合XX。

比如:X部门可以明确做出规定,所有X在第一次跟进新线索时,必须先确定该账号不是同一家庭账号,或者不是已注册家长的其他X号。

如果发现是,则在CRM系统中X功能,做账号合并,将两个或多个账号关联起来,这样和账号一一对应的线索,也就能梳理出关联关系了,让多个相关的线索被调配给同一名X。同时也可以在C端X功能,引导家长完成家庭多X号的bǎng定。

正因为我们在数据建模时考虑到了这个问题,做好了数据底层设计的准备工作,未来才能在应用功能层面实现这些功能点,解决X问题。

小李:明白了,真是神奇!如果X部门已经明文规定了要确认是否重复账号,而X人员依然不遵守规定,那么即便第二个X跟进开发成功,佣金依然判定属于第一名X,只要规则明确,大家就必须遵守,纠纷就容易解决了。

老王:你说的很对!不过你的子母账号的设计,可能会造成一种管理和被管理的感觉,在C端的体验并不是特别好,是否有其他方案呢?

小李(挠挠头):想不出来啊!

老王:其实我们的X、X的客户结构,就是典型的家庭结构。在数据底层,可以按照家庭的模型来建模,在账号之上设计一个家庭实体,账号都在同一个层级,隶属于某一个家庭,这样也可以完成账号关系的bǎng定和关联。如下图:

为什么说ER建模是软件产品设计的核心:X一个案例让你深刻理解!

小李:精彩!家庭和账号是一对多,线索和账号一对一,这样就能在数据底层,保证可以对多线索进行唯一性识别!

老王:是的,实际上,账号本身和线索、家庭关联,也并不是很合理。账号只X一个用户访问系统的凭证,并不X用户自身。

在现实中,一个用户完全可能有多个X号,对于企业来讲,理想的情况,是能够识别唯一的客户,以及他背后的多个X号。所以,从建模的严谨性来讲,我们还需要抽象出一个实体,就是家长。修改后的ER图如下:

为什么说ER建模是软件产品设计的核心:X一个案例让你深刻理解!

小李:我不太理解,这样做的目的是什么呢?你在图中,也没有将家长和账号设计成一对多啊?

老王:家长和账号设计成一对多,会一定程度增加系统的复杂性,也会让用户的cāo作体验变复杂。

实际上,目前大多数X跟X的X中,客户和账号设计成一对多,对X价值并不是特别大,所以为了简化,都采用了一对一的设计方案,但是某些X,就必须采用一对多设计了。

比如支付宝,XX来识别唯一客户,同时允许一个客户注册多个账号(其实支付宝这样做也是X原因导致的)。

但是,即便是家长和账号一对一,为了保证逻辑的清晰,我们也需要将两个实体(家长和账号)分离开,毕竟,账号只是是登陆凭证,他不X用户自身。

我们可以在应用层面将复杂的系统逻辑简化呈现,但是如果可能,就尽量在数据底层保持逻辑的严谨性,虽然会带来底层设计的复杂度,但这可以保证系统在应用层面设计的灵活性。

小李:很有道理,受教了!

老王:这个模型中,还有致命问题,会影响到X。

小李:啊?还有啊?我以为已经很完美了!

老王:目前订单是关联在账号下的。如果一个家庭有一个小朋友,这样的模型是没问题的,如果一个家庭有多个小朋友,该怎么办?实际上目前的模型不支持这个X场景。

小李:是啊,这个问题的核心,是我们的模型中没有小朋友的实体!

老王:进步很快啊,那你思考下这个模型该如何完善?

小李:我想想,是不是可以这样,在家庭下增加一个孩子实体,订单挂在孩子实体上,系统默认创建一个孩子,X的订单就挂在第一名孩子身上。如果家里有多个孩子,那么也支持家长增加孩子,并且可以zhēn对其他孩子X订单。ER图修改如下:

为什么说ER建模是软件产品设计的核心:X一个案例让你深刻理解!

老王:非常棒,你的这个模型,很好地解决了先前的X问题!

小李:不过我还是有困惑,这样做,会不会太复杂了?其实如果有多个小孩,那么让客户再注册个账号,不要合并家庭,创建订单支付,不就解决了么?

老王:你说的很对,确实有变通的处理方案,但会损失客户体验,并带来其他的X问题。

实际上,我们做产品设计,重要的是能够想清楚所有的X场景和问题,然后基于研发资源和实现周期,做出一个综合评估后的合理方案,这是一个首先做加fǎ,再做减fǎ的过程。

尤其是在ER建模的过程中,必须思考的非常缜密,全面,因为你会发现,ER建模的过程,就是帮你梳理X的过程。

确实,如果底层模型设计过于复杂,可能会造成研发工作量指数级的上升,但更重要的是,你能考虑清楚所有X场景,评估不同设计的投入产出比,和X人员、技术负责人一起充分沟通,最终做出一个充分评估论证的设计方案。

小李:明白了,前辈所言极是!

老王:我们回到刚刚提到的多孩场景,实际上,你在上图绘制的ER模型,已经能够非常灵活的支持各种X诉qiú。

比如说,如果一个家庭下,有两个小朋友都X了课程,并在某一天同时上课,而此时孩子的bàbàmāmā分别在外地,想各自分别去看两个宝贝上课的情况(在线教育常见的监课功能),正因为有这个模型的支持,才能在C端的app做出强大的功能,父母各自登陆,查询到家庭下的两个孩子,并且分别切换看两个孩子上课的情况。

小李:明白,确实,如果没有这个模型,而让家长再注册个账号,在X管理上也会带来混乱。

老王:是的。所以,这些问题,我们都要想清楚。另外有一点需要十分关注,ER建模最终会转换成数据库表设计,在软件工程中,一旦表结构定型,以后再想修改,是非常麻烦的事情。

比如,如果我们一上来就按照最简单的方案设计了客户模型,那么未来有一天,想切换到上述理想模型,研发的投入上会非常巨大,甚至是无fǎ完成的。

软件系统重构,最头疼的问题就是如何将X数据迁移到新的数据结构下边。

小李:理解,所以,ER建模,是一个非常核心的设计工作,必须充分探讨,务必谨慎!

老王:没错。接下来,我再问你个问题,刚刚绘制的ER模型,还是有瑕疵。

小李:我晕,还有啥问题啊?

老王:如果孩子也有账号,也需要用自己的X号登陆系统,你的模型该怎么调整?

小李:啊,真是,我还以为我们做的是幼儿教育,小朋友都得用bàbàmāX账号登陆app完成学xí。不过确实有这种可能性,如果我们的教育产品拓展到小学或初中,现在的小朋友都是有X的。我想想,要不然,改这样?

为什么说ER建模是软件产品设计的核心:X一个案例让你深刻理解!

老王:你这么设计是没有问题,但你不觉得抽象的实体有些冗余么,孩子和家长,实际上都是“人”嘛,无非是不同年龄的“人”。

小李:我想想,呃,要不改成这样?最终家长和孩子这两个实体,被进一步抽象到“人”的维度,X“人”的某个属性来标记是家长还是孩子(甚至都不需要标记,只需要X年龄进行识别,并产生相关的X规则)。

不过,这样设计及好么,会不会在逻辑上看起来清晰干净,但是会让工程实现变得复杂?嗯,这个事儿,还得找技术负责人老李好好再合计合计。

为什么说ER建模是软件产品设计的核心:X一个案例让你深刻理解!

老王:对,一定要和技术负责人一起沟通探讨,而且想的越复杂越好!不过,我还有问题要问你。

小李:您请讲!

老王:在最后的这个模型中,订单究竟应该挂在“人”上,还是挂在“账号”上呢?如果人和账号是一对多关系,订单又该怎么挂呢?家长X课程产生的积分应该挂在“人”上呢,还是账号上呢,还是“家庭”上呢?X上课获得的奖励应该挂在“人”上呢,还是账号上呢,还是“家庭”上呢?

小李:mā呀,怎么感觉无穷无尽的复杂啊,我想,这些问题,就留给我们聪明的读者来思考吧!哈哈!

老王:我看行!

#专栏作家#

yáng堃,X号:PMyáng堃(ID:pmYangKun)。人人都是产品经理专栏作家,《决胜B端》作者,12年X研发、产品设计经验,曾任VΙPKID产品总监,百度高级产品经理,现为慢酷咨询创始人兼CEO。

本文原创发布于人人都是产品经理,未经许可,jìn止转载

题图来自 Unsplash,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!

2人打赏
收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 为什么ER建模是软件产品设计的核心:通过一个案例让你深刻理解 https://www.xiongfawang.com/2014.html

常见问题

相关文章

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

分享本文封面