娱乐世界工业设备有限公司欢迎您!  客服热线:021-63212618
为什么ER建模是软件产品设计的核心:通过一个案

为什么ER建模是软件产品设计的核心:通过一个案

  ER筑模:Entity Relationship,也叫实体筑模,是软件工程中特殊首要且中央的观点。

  ER筑模的口舌,决策了软件产物的扩展性和聪明性。ER筑模不正确,有恐怕导致软件打算缺陷,以至带来重要的营业题目。

  倘使将软件产物打算比喻成盖大楼,那么ER筑模笼统出的实体对象便是大楼的基本,缠绕实体对象征战的操纵功用便是大楼的外观,基本决策了大楼的布局和功用,倘使基本不稳或谬误,大楼就有恐怕崩塌或不切合预期。

  这些偏外面的阐发恐怕会让群众觉得怀疑,接下来,咱们通过一个实践案例,让群众深切会意ER筑模的魅力。

  软件打算的中央重点,便是将客观全邦的事物,正确的提炼笼统,酿成阴谋性能够会意的面向对象的打算。

  咱们将客观事物笼统成对象打算的流程,就叫ER筑模,笼统出来的对象,就叫做实体(Entity),除了笼统出实体,咱们还必要合切实体的属性,以及实体之间的相合(Relationship)。

  比方电商中的账号和订单,便是笼统出的实体,一个账号恐怕有众个订单,每个订单只恐怕归属于一个账号,这便是账号和订单之间存正在的一对众相合。

  形容实体对象和相合的图形,叫做ER图,ER图的显现体例有良众种典范(比方UML,Chen,Crow’s Foot等等),绘制本领不首要,举动一名产物司理,只必要浅易显露地外达出打算图谋即可。比方上述提到的账号、订单实体相合图,能够浅易绘制如下:

  本文的要点,正在于让群众会意ER筑模奈何影响了产物计划并决策了营业,于是合于筑模的少许基本常识和打算本领论不张开讲述。

  某草创公司发展正在线训诲营业,面向低龄儿童,由于客单价高,创造电销中央团队结束出售办事。公司调整了资深产物专家老王控制具体产物计划打算,小李是老王的助手,低级产物司理。

  老王:小李啊,公司策划发展正在线训诲营业,让咱们最初聚焦正在客户的模子打算一面,你能够聊聊你的念法啊。

  小李:王教授,客户筑模是什么?这个题目不是很浅易么,咱们只必要一个C端的app,有一套账号中央,客户结束常例注册后,正在出售的辅导下下单不就能够了么?

  老王:这个办事会比你预睹的繁杂良众,客户模子的打算,对悉数营业的发展,和体例的征战,都有通盘的影响。逐步我会辅导你会意。但是你能够先基于你刚才的说法,测验用我教你的ER图,画一个草图出来,咱们正在此基本上一步步张开领悟。

  小李:好啊王教授,我以为咱们面临的是典范的C端客户,只必要一个账号对象,每个账号下能够创筑众个订单,ER图如下:

  老王:很好,账号和订单是很常睹的两个实体。那么,客户注册后,会由电销出售职员跟进效劳,咱们必要打算CRM体例给出售职员运用。你以为出售职员正在CRM中操作收拾的客户对象应当是什么,是账号么?

  小李:我以为出售职员正在CRM中收拾操作的对象是“账号”近似没什么题目,但又觉得怪怪的,觉得出售职员跟进的应当是客户,而不是账号,但我说不领略这里边的相合和界说。

  老王:你的觉得是准确的,出售职员正在CRM体例中收拾的应当是客户,而不应当是客户的账号。实践正在出售收拾中,咱们以为新注册的客户、账号等等,都属于出售线索,线索便是指潜正在客户。正在典范的CRM体例中除了线索,另有商机的观点,但是正在咱们这里用不到。

  小李:近似如许显露少许了,觉得CRM体例和客户的登录账号就没有昭着相合嘛。

  老王:也不行说没相合系,只是咱们正在做数据筑模的时刻,要分领略这些对象的观点,包管逻辑界说的显露。正在咱们的营业中,能够打算线索和账号便是一对一相合,出售职员和线索是一对众相合,即一个出售能够具有众条线个出售。

  老王:由于正在CRM体例中,并不是每条线索都有出售收拾跟进,有些线索恐怕是无人爱护跟进形态,于是线对众,个中的“众”,是指“0或众个”。咱们将ER图美满,如下:

  小李:这个图看起来更显露了,背后对应的打算思绪也比力清楚。但是我照旧有点不会意,为什么非要把账号和线索这两个实体离开,除了逻辑上更显露,另有什么好处呢?

  老王:对实体举行清楚的筑模和打算,除了逻辑上更显露以外,另有很首要的一点,如许做,能够低浸软件体例打算的耦合性。奈何会意这句话呢?

  ER模子最终会转化成数据库外布局打算,线索和账号能够区分保管正在两张数据外,进一步讲,附属于两个分别的数据库,即CRM体例的数据库,和账号中央的数据库。咱们来看下边这张图:

  老王喝了口水,络续说道:我正在ER图外边绘制了两个框,圆桶代外数据库,圆桶外边的矩形代外营业体例,能够看到,实践上咱们正在ER图中形容的四个实体,区分附属于三个数据库,和各自的营业体例。

  如许的ER图打算,被显露地传导到数据库底层打算,以及操纵体例的打算,能够包管出售体例、用户中央、订单中央三者很好地解耦合,各自独立,互不影响。

  比方:CRM体例倘使更新时出了题目,并不会影响到用户中央体例,起码客户还能够登录拜访app。

  而倘使线索和账号被打算成一个实体,对应的外布局打算恐怕便是一张外,就会导致众个操纵体例运用统一个数据库底层,恐怕酿成CRM更新一个出售造访的功用,出题目影响到C端用户登录app。

  小李:领略了,听起来很有原因,ER筑模不单正在逻辑上很显露,还能正在物理存储上也很显露。怪不得咱们以前公司创业时做的体例,总说耦合正在一同,特殊固执,堆栈体例做个升级,能把出售体例干趴下。

  老王:良众时刻体例耦合,都是创业公司为了速捷上线,做的打算计划的妥协,比方各个营业体例做成一套代码,一套数据库。当然,我正在这里举这个例子,苛重是念申明ER筑模对数据库外打算、对操纵体例打算的传导和影响。

  老王:咱们再回到筑模打算自己。现正在的模子,如故存正在良众题目。比方说,正在目前的模子中,倘使小好友的爸爸妈妈都注册了账号,该若何办?

  老王:本来题目很重要,由于爸爸妈妈各自注册后,会形成两条没相合系的出售线索,CRM体例通常情形下会分派给两个出售跟进。

  但看待这个家庭来讲,实践上只必要给孩子进货一次课程,那么,两名出售为了各自搞定家长得回提成,恐怕就会形成恶意逐鹿,给客户做出子虚的同意,以至给爸爸妈妈外述纷歧律,酿成极差的客户体验。

  并且倘使成单(客户付费),很难说领略结果是哪个出售的收获更大,这就会酿成出售职员之间天天打斗扯皮,特殊倒霉于营业发展。

  小李:有原因,那倘使爸爸注册了,妈妈再注册,让妈妈的线索分派给之前跟进爸爸线索的出售,不就能够了么?

  老王:说的没错,题目是,咱们并不清晰爸爸和妈妈是否是一家人啊?咱们的模子打算,并没有预留如许的才力支持。你念念该若何删改呢?

  小李(深思中):有了,咱们能够将以前的简单账号系统,改成子母账号系统,账号能够相互筑设归属相合,如许倘使爸爸和妈妈绑定相互账号,出售职员就可以识别统一家庭的家长,就不会有冲突了。如下图:

  老王:很好,你的这个模子,正在数据底层供应了才力援手,是咱们正在操纵层面管理出售冲突营业题目的一个条件基本。

  小李:但是我照旧没念领略,这个底层模子奈何援手营业,由于通常C端用户并没有动力正在注册时做家庭账号合系啊?

  老王:你说的很对,通常C端用户并不会主动去做账号合系,然而倘使咱们有这个数据底层打算的援手,就能够正在操纵体例层面做各式功用,来管理营业题目,同时还要联络营业轨制。

  比方:出售部分能够清楚做出法则,一共出售正在第一次跟进新线索时,必需先确定该账号不是统一家庭账号,或者不是已注册家长的其他手机号。

  倘使挖掘是,则正在CRM体例中供应功用,做账号统一,将两个或众个账号合系起来,如许和账号逐一对应的线索,也就能梳理出合系相合了,让众个合连的线索被调配给统一名出售。同时也能够正在C端供应功用,辅导家长结束家庭众手机号的绑定。

  正由于咱们正在数据筑模时思虑到了这个题目,做好了数据底层打算的打定办事,来日才气正在操纵功用层面告竣这些功用点,管理营业题目。

  小李:领略了,真是奇特!倘使出售部分依然明文法则了要确认是否反复账号,而出售职员如故不坚守法则,那么即使第二个出售跟进斥地获胜,佣金如故断定属于第一名出售,只须正派清楚,群众就必需坚守,瓜葛就容易管理了。

  老王:你说的很对!但是你的子母账号的打算,恐怕会酿成一种收拾和被收拾的觉得,正在C端的体验并不是特殊好,是否有其他计划呢?

  老王:本来咱们的营业、面对的客户布局,便是典范的家庭布局。正在数据底层,能够依据家庭的模子来筑模,正在账号之上打算一个家庭实体,账号都正在统一个层级,附属于某一个家庭,如许也能够结束账号相合的绑定和合系。如下图:

  小李:精美!家庭和账号是一对众,线索和账号一对一,如许就能正在数据底层,包管能够对众线索举行独一性识别!

  老王:是的,实践上,账号自己和线索、家庭合系,也并不是很合理。账号只代外一个用户拜访体例的凭证,并不代外用户本身。

  正在实际中,一个用户全体恐怕有众个手机号,看待企业来讲,理念的情形,是可以识别独一的客户,以及他背后的众个手机号。于是,从筑模的苛谨性来讲,咱们还必要笼统出一个实体,便是家长。删改后的ER图如下:

  小李:我不太会意,如许做的主意是什么呢?你正在图中,也没有将家长和账号打算成一对众啊?

  老王:家长和账号打算成一对众,会必然水平加众体例的繁杂性,也会让用户的操作体验变繁杂。

  实践上,目前大大都互联网跟公司的营业中,客户和账号打算成一对众,对营业价格并不是特殊大,所认为了简化,都采用了一对一的打算计划,然而某些营业,就必需采用一对众打算了。

  比方付出宝,通过身份证来识别独一客户,同时应允一个客户注册众个账号(本来付出宝如许做也是史乘出处导致的)。

  然而,即使是家长和账号一对一,为了包管逻辑的显露,咱们也必要将两个实体(家长和账号)分脱节,事实,账号只是是登岸凭证,他不代外用户本身。

  咱们能够正在操纵层面将繁杂的体例逻辑简化显现,然而倘使恐怕,就尽量正在数据底层仍旧逻辑的苛谨性,固然会带来底层打算的繁杂度,但这能够包管体例正在操纵层面打算的聪明性。

  老王:目前订单是合系正在账号下的。倘使一个家庭有一个小好友,如许的模子是没题目的,倘使一个家庭有众个小好友,该若何办?实践上目前的模子不援手这个营业场景。

  小李:我念念,是不是能够如许,正在家庭下加众一个孩子实体,订单挂正在孩子实体上,体例默认创筑一个孩子,进货的订单就挂正在第一名孩子身上。倘使家里有众个孩子,那么也援手家长加众孩子,而且能够针对其他孩子进货订单。ER图删改如下:

  小李:但是我照旧有怀疑,如许做,会不会太繁杂了?本来倘使有众个小孩,那么让客户再注册个账号,不要统一家庭,创筑订单付出,不就管理了么?

  老王:你说的很对,确实有变通的治理计划,但会牺牲客户体验,并带来其他的营业题目。

  实践上,咱们做产物打算,首要的是可以念领略一共的营业场景和题目,然后基于研发资源和告竣周期,做出一个归纳评估后的合理计划,这是一个最初做加法,再做减法的流程。

  特别是正在ER筑模的流程中,必需思量的特殊苛密,通盘,由于你会挖掘,ER筑模的流程,便是助你梳理营业的流程。

  确实,倘使底层模子打算过于繁杂,恐怕会酿成研发办事量指数级的上升,但更首要的是,你能思虑领略一共营业场景,评估分别打算的加入产出比,和营业职员、技巧控制人一同充沛疏通,最终做出一个充沛评估论证的打算计划。

  老王:咱们回到刚才提到的众孩场景,实践上,你正在上图绘制的ER模子,依然可以特殊聪明的援手各式营业诉求。

  比方说,倘使一个家庭下,有两个小好友都进货了课程,并正在某一天同时上课,而此时孩子的爸爸妈妈区分正在边境,念各自区分去看两个瑰宝上课的情形(正在线训诲常睹的监课功用),正由于有这个模子的援手,才气正在C端的app做出重大的功用,父母各自登岸,盘问抵家庭下的两个孩子,而且区分切换看两个孩子上课的情形。

  小李:领略,确实,倘使没有这个模子,而让家长再注册个账号,正在出售收拾上也会带来紊乱。

  老王:是的。于是,这些题目,咱们都要念领略。其余有一点必要非常合怀,ER筑模最终会转换成数据库外打算,正在软件工程中,一朝外布局定型,自此再念删改,口舌常障碍的事变。

  比方,倘使咱们一上来就依据最浅易的计划打算了客户模子,那么来日有一天,念切换到上述理念模子,研发的加入上会特殊广大,以至是无法结束的。

  小李:会意,于是,ER筑模,是一个特殊中央的打算办事,必需充沛探求,务必郑重!

  老王:倘使孩子也有账号,也必要用自身的手机号登岸体例,你的模子该若何调理?

  小李:啊,真是,我还认为咱们做的是小儿训诲,小好友都得用爸爸妈妈的账号登岸app结束练习。但是确实有这种恐怕性,倘使咱们的训诲产物拓展到小学或初中,现正在的小好友都是有手机的。我念念,要否则,改如许?

  老王:你这么打算是没有题目,但你不以为笼统的实体有些冗余么,孩子和家长,实践上都是“人”嘛,无非是分别年纪的“人”。

  小李:我念念,呃,要不改成如许?最终家长和孩子这两个实体,被进一步笼统到“人”的维度,通过“人”的某个属性来记号是家长照旧孩子(以至都不必要记号,只必要通过年纪举行识别,并形成合连的营业正派)。

  但是,如许打算及好么,会不会正在逻辑上看起来显露清洁,然而会让工程告竣变得繁杂?嗯,这个事儿,还得找技巧控制人老李好好再合计合计。

  老王:对,必然要和技巧控制人一同疏通探求,并且念的越繁杂越好!但是,我另有题目要问你。

  老王:正在结尾的这个模子中,订单收场应当挂正在“人”上,照旧挂正在“账号”上呢?倘使人和账号是一对众相合,订单又该若何挂呢?家进步货课程形成的积分应当挂正在“人”上呢,照旧账号上呢,照旧“家庭”上呢?学生上课得回的赞美应当挂正在“人”上呢,照旧账号上呢,照旧“家庭”上呢?

  小李:妈呀,若何觉得无限无尽的繁杂啊,我念,这些题目,就留给咱们敏捷的读者来思量吧!哈哈!

  人人都是产物司理专栏作家,《决胜B端》作家,12年互联网研发、产物打算履历,曾任VIPKID产物总监,高级产物司理,现为慢酷商讨创始人兼CEO。

相关产品推荐

在线客服 :

服务热线:021-63212618

电子邮箱: admin@yixiehui.com

公司地址:北京市朝阳区工人体育场

友情链接:
Copyright © 2019 娱乐世界工业设备有限公司 版权所有 网站地图