高质量数据库建模系列课程<3> PPT & 讲义 - 实体以及实体的分类

浏览: 3396

广告:

欢迎参加我的课程:高质量数据库建模




上一节课, 我们讲到了高质量数据库建模的基本流程, 那么这一节课呢,我们开始介绍一些关系型数据库模型设计中的基本概念。 目的是为了方便未来的课程,当提到某些概念的时候,大家能明白概念所具备的含义。


在开始之前呢,先插播一段广告。

这里看到的是一个数据方面的组织,名字叫DataVersity在2012年对各个行业里面数据相关领域的工作人员做的调查统计,统计的内容是数据模型工程师,需要具备的技能。调查统计的方法是把相关的技能列出来,然后对于每项技能呢进行打分,Rank从1到10。有哪些技能呢?这里抽样了2007,2009,2012三年的数据的。

我这边列了一下,所有的技能列表。一共呢是11个:

1.Knowledge of the business:对业务知识的理解

2.Knowledge of data model patterns:了解数据模型设计的模式

3.Knowing the line between ideal and practical:清楚理想化模型,和现实应用的分界线

4.Knowing when to stop:知道什么时候停止,这个也就说不要over design。

5.knowledge of the DBMS:对数据库知识的了解

6.documentation skills:文档的技巧和能力

7.verbal communication skills:语言沟通能力

8.understanding of dimensional modeling:维度建模知识的掌握

9.knowledge of normalization:关系型模型规范化的知识

 

2012年开始呢,又有两个新的技能添加进来:

10.knowledge of non-traditional data stores:非传统数据存储的知识(也就是NOSQL DB)

11.knowing how to work with agile teams:知道怎么在Agile(也就是敏捷开发)模式下和Team合作。


然后我们发现,2007,2009,2012年,这三次调查,排在前三名的始终是:

1. 业务知识的理解

2. 沟通技巧

3. 关系型模型规范化的知识

 

其中业务知识的了解,占到30%,沟通技巧占到了25%,关系规范化建模占到了13%,这三个加起来,一共68%。

 

对于业务知识的了解呢,因为各个领域的差别是非常大,我这个课程里面会有很多和业务相关的例子,虽然呢,本课不是专门讲业务,但大家也多多少少会学到一点行业相关的知识。

本课的重点呢,是第二项沟通技巧和第三项关系型模型规范化的知识。

 

这里提到沟通技巧,可能有人就奇怪了,这沟通技巧和设计关系有这么大吗?

我告诉你,沟通技巧和你能够设计好数据模型关系非常大。

我们常说,要引导客户去谈需求。那怎么引导?

就需要去有计划,有结构的,去问问题,说白了,你得把问题问到点上,他才能给你你想要的答案。举个例子,你去找客户谈需求,上来就问,你需求是什么,告诉我呗?很多时候客户都没法给你一个理想的答案,一般就是给一个方向性的很草的内容,你按这个内容根本没法设计。

那怎么问问题啊?这个我们前面说了,数据建模师最重要的技能是业务的理解,首先你得了解业务知识,和客户有共同的语言,然后你才更容易问有价值的问题。此外就是在数据库建模方面,有一些模式结构可供我们参考,我们按照这个结构去问问题,就更容易得到正确并且完整的答案。这个呢,我今天的课程里就会讲到。


那么书归正传,我们来看一下,本节课要讲的概念都包括哪些?

首先呢,是实体和属性,然后是域,关系,键和约束。


首先,什么是实体?

一般是对“人”,“事”,“地点”,“物体”之类的抽象化定义。

就比如员工,公司,商店,这些都是实体。

实体呢,通常都是“名词”。

而数据库中的实体,也就是你想要在数据库中保存的信息。

在概念模型和逻辑模型中,我们称为实体,也就是Entity。

而最终在物理模型,以及数据库中实现呢,就是表,也就是Table。而实体中的实例,就是一行行的数据。

 

那通常来说,当看到一个业务场景,自上而下去定义实体都怎么做呢?

这里呢,我举一个简单的例子,你带着你的女朋友走进一家化妆品店,然后呢,化妆品店里的销售人员询问女友的购买意向,并且根据购买意向,以及她皮肤的特质向你们推荐一款适合她皮肤的化妆品。你的女友办理了会员卡,然后你在收银员处刷卡消费。

就是这么一个简单的场景,假设,我们要给这个化妆品店设计一套管理程序,因此需要设计一套数据模型,用来实现这个业务场景。我们需要怎么做呢?


首先呢,让我们去找这段话中的名词,看看都有哪些?你看我标红的这些词:

你女朋友 化妆品店 销售人员 购买意向 皮肤的特质 化妆品 会员卡 收银员 刷卡消费


你,你的女朋友,对于化妆品店而言,是什么啊?是客户,对吧?所以呢,称为Customer

接下来,化妆品店呢?Store

销售人员,收银员,是化妆品店的什么啊?员工,是吧,因此就是Employee

化妆品呢?是销售的产品,叫Product

会员卡呢,VIP Card

皮肤特质呢,Skin

购买意向,Indicated Order

刷卡消费, 就是下单,Order

 

这里呢,什么Customer啊,Store啊,Employee啊,都是实体。而你啊,女朋友啊,化妆品店啊,销售人员啊,等等,这些都是各个实体对应的实例。

 

然后呢,这里有两个地方需要注意一下,

一个是什么啊?我们刷卡消费了,用什么刷的啊?得有POS机对吧?而POS机呢也是化妆品店的资产。所以,这里我们称为Resource Item。为什么这块我要强调啊?就是说实际上某些业务场景里面啊,有隐藏的内容,需要你仔细阅读并把它翻出来,你看这个例子啊,没提POS机,但你要刷卡,肯定得用POS机,对吧?这个其实也是业务知识。

 

还有一个地方,购买意向。我给标红了。

这个就是我前面提到的两个Point,

第一,   概念模型是要确定范围的,所以只画项目范围内的实体。确定哪些做哪些不做。

第二,   我前面说过沟通技巧,你是不是得先把这些实体都列出来,然后拿这个再和客户或者BA去确认,哪些做哪些不做?所以沟通技巧其中之一就是,你得有沟通的基础,什么是沟通的基础啊?就是你得有些中间品的产出,拿着这个去问。比如上面我列出来的这些就是一种沟通的基础。

 

那我标红的意思是什么啊?购买意向这部分啊,虽然销售会问,但是不列入系统,我不去管理她的购买意向。


这里我多说几句啊,怎么是一个有效的沟通模式。有个模型,大概长成这样。

这是个循环,讲沟通的技巧。我不是讲这种soft skill的专业的老师哈,所以这个我也讲不太好,大家有兴趣课后可以去网上找找这种沟通技巧的教程。

第一步,首先是Explorer: 探索

按上面的例子,其实就是问客户,一个购买的场景是什么?然后呢,客户就把前面的买化妆品的场景给你讲一遍。

第二步是什么?Clarify,澄清。这里就是你把这个场景拆解了,分门别类的列出Customer,Store, Employee之类的实体。然后同时把隐藏的实体POS机和可能不在范围的购买意向也挑出来,去问客户是不是你理解的这样。

第三步,Confirm,也就是说客户得确认你说的对还是不对。按上面的例子,POS机是有的,然后购买意向不在范围呢。是吧,你得找客户确认了,购买意向不在范围内,不能自己随便定。

第四步:Action,就是说可以按这个建模了。

 

我这个讲的不太生动,我非常建议大家课后去找找类似的课程,这种课程非常好。


前面我们一再强调,沟通的技巧。这里再给个Tip。说沟通的技巧是有沟通的基础的,很重要的就是结构清楚,比如我有一个业务场景,我怎么分析它啊,让它结构清楚?

所以呢,实体有几种分类方式,我这里讲一下。

 

第一种,最常用的,大家也容易接受。就是5W1H

Who,What,When,Where,Why,  How

这种模式呢,是非常经典的,称为六合分析法。

 

这里我再强调一次,在数据建模的过程中的沟通技巧,也就是说你怎么引导客户去厘清需求,很重要的一点就是提问的技巧,这个其实啊不仅仅是问需求调研的客户,很多时候我们也这么问自己,然后去尝试找到答案,你的答案找到了,你的模型也就出来。

 

还有人更进一步,改成5W2H,除了How以外,又加了How Much,这个是广义的How Much,包括

HowMuch代表实现某实体的成本

HowMany代表实体实例的数据规模

HowOften表示实体内数据更新的频率

 

这个就有点复杂了,大家参考一下就行了,我们还是按5W1H来讲。

 

首先是Who

Who通常指与企业业务紧密联系的人员和组织。‘Who’经常需要和他所扮演的角色紧密结合。

这里给出的例子是:客户,员工,患者,学生,旅客,代理商,公司,部门,等等

对于某个业务场景的分析,首先就是看谁参与到了这个业务场景中,他们又分别扮演什么角色。比如我上面举的化妆品店的例子,你,你的朋友,销售,收银员就都是Who, 其实还有一个隐含的Who,就是这个化妆品公司。我们这里再强调一遍,who既代表个人,也代表组织。

 

接下来是What

What通常指企业业务相关的“事”等。最常见的是企业销售/采购的内容等等,这里给出的例子是商品,产品,原材料,服务,成品,半成品,课程,书籍。这些都是What。

还是回到上面的例子,说销售员根据皮肤的特质,推荐某化妆品,然后在收银台刷卡结账,这里出现的What,有哪些啊?

皮肤特质对吧,这是What

化妆品,还有什么?POS机,刷卡吗,要用POS机。

 

 

对于企业而言,业务流程中需要捕获日期或者时间,比如业务发生的时间, 货品交付的时间啊,等等。所以When也是非常重要的,其实When更多的时候是以属性的模式出现的,而作为实体更多是以时间表的形式存在。

比如:时间,日期,周,月份,季度,半年,财年

 

下一个,Where,指企业业务相关的地点,这个可以指具体的地点比如实体店,也可以指虚拟的网上商店。这里给了一些例子:商店、餐厅、地址、仓库、IP地址,网站等等。

 

下一个,Why,这个通常是指交易或者事件本身, 比如:销售、采购、订单等等

下一个,How, 这个通常是指,你们通过什么形式去管理的,最常见的就是交易类的文档信息,去表示以及记录企业是如何完成交易的。比如:合同,协议,发票等等。

 

其实啊,实体的分类有很多种方式,上面介绍的5W1H是按照实体的内容来分的。这里呢再举一个按内容分的模式,IBM的Industry Model。在我看来,这个分类方式虽然没有5W1H那么简单清楚,但其实是更适合于数据建模的。让我们来看看它是怎么分的:

1. 安排,Arrangement

安排代表了相关的双方或多方(含个人,企业,部门)之间存在或潜在的协议,用以规范相关产品、服务或资源的销售,交换或开通的职责。例如,申请、合同和许可证。

这个所谓的安排其实范围可以很广,像Assignment(分配), Allocation, Agreement都可以放进来。

 

这个是不是和上面How很像啊?

 

2. 业务指导, business direction

概括了相关方提供的产品和服务及遵循的业务流程等的计划策略。例如,法规、政策。

这个其实也是How,只是分类也精细了。这个什么时候最常用啊?比如产品的价格,会有浮动范围,这个范围就是典型的Business Direction。

 

3. 相关方,Involved Party

描述了所有参与者,它包括与企业相关者,企业对保持其信息感兴趣者。它也包括企业自身。例如客户、供应商、代理商、银行和员工。

这个很显然了,就是上面说的Who。

 

4. 下一个,产品(Product)

产品描述了所有企业感兴趣的国内及国际的产品和服务。这些产品可以是由企业直接营销、销售、租赁的,也可以由其它业务伙伴(如服务供应商,代理商)间接提供的。它还包括企业不提供但有兴趣的产品和服务,如竞争对手的产品和有市场前景的产品。

这个也很显然了,就是What

 

5. 事件,Event

事件描述了企业希望保存的业务活动的发生信息。。例如:业务交互、客户行为。

这个显然对应的是Why。

 

6. 资源,Resource Item

资源包括和描述了任何具有价值的有形的和无形的物件,它们由企业拥有、管理、使用或者在进行业务过程中涉及到的。例如:固定资产、财务资金。

这个对应的事What,也就是我们说的POS机。

 

7. 位置,Location

位置描述了定位事物的地点,信息的目的地(如接入号,email地址)或企业欲保存信息的有范围的区域(如国家、省市)。例如电话号码,IP地址或地理位置。

这个更显然了,Where

 

8. 分类,Classfication

分类通过定义一个或多个数据概念,和可应用于多个数据概念的业务概念组(如事件、相关方等)的分类目录结构,来组织和管理业务信息

 

这里我需要强调一下,这个上面5W1H是没有单列的,分类在计算机应用里面非常非常重要,尤其BI领域。因此这个被单列了。

 

这里多说几句,无论5W1H, 还是IBM的这套分类方法,其本身的目的无非就是让建模工程师能够将实体分门别类,这样能够化繁为简,使结构清晰明了,易于理解,具有启发意义并且避免分析遗漏。这种方式啊,是非常方便于分析以及有利于沟通的,但是大家在建模的过程中呢,也不要完全拘泥于这种当前的分类,可以根据实际情况自行增加或者减少这种分类。而对于一些模糊不清的实体,你也不知道具体应该分哪去,别太纠结,分哪去都没关系,只要别漏掉就行。


上面的分类方法都是按内容分的,还有一种分类方法,是按Pattern分的。

在Imhoff的书里面,她是这么分的,分成四种模式

主实体,也称基本实体

是用于定义不依赖于其他实体而能独立存在的实体,比如:产品,客户等等


子类型实体

是对于父实体的逻辑划分,而子类实体呢,能够继承父类实体的特征,属性和关系。比如,客户可以分为潜在客户和现有客户。而潜在客户,和现有客户都是客户这个实体的子实体,他们的关系是1:1的关系。

而客户这个实体:

可以有客户编号,客户姓名,客户电话,之类这些基本信息。

而潜在客户呢,可能会保存购买意向,等等信息。

现有客户呢,你可能会保存他的会员卡信息,等等。而无论潜在客户还是现有客户都仍然具备客户这个实体的属性,比如编号,姓名,电话等等。这里把客户这种实体叫做超类(Supertype),把潜在客户,现有客户这种实体叫做子类(Subtype)


属性类实体或者 特征实体

首先它也是依赖于其他实体而存在,是为了处理父实体的每个实例中多次出现的一组数据而创建的实体。比如客户地址就是客户的一个属性实体,一个客户可能有好几个地址。属性类实体和父实体之间的关系一般都是多对一的关系。


关联实体

是指依赖两个或者更多实体而存在的实体,这种实体记录交集数据。比如:销售代表去服务客户的分配实体。

 

这个四个还能归并一下,前面说的第一个类型,主实体,可以独立存在的实体,也称为强实体,而需要依赖其他实体而存在的实体,也就是后三个实体,称为弱实体。

到这呢,我们的实体部分的相关概念,基本就讲完了。这里我再强调一下,通常来讲,很多重要实体的定义都会在概念模型阶段确定,而在逻辑模型阶段呢,逐步完善。而对于数据建模师而言,这里面非常重要的一点就是,要学会建模的沟通方法,也就是说你怎么去启发客户了解你想要的信息。因此实体的分类方法就非常重要,比如5W1H,其实就是6种问题,当你去做需求分析的时候,可以用这6种问题问自己,也问客户,然后逐步澄清需求。

 

那么今天的课先暂时讲到这,下节课我们将详细描述属性以及相关的信息

推荐 5
本文由 BAO胖子 创作,采用 知识共享署名-相同方式共享 3.0 中国大陆许可协议 进行许可。
转载、引用前需联系作者,并署名作者且注明文章出处。
本站文章版权归原作者及原出处所有 。内容为作者个人观点, 并不代表本站赞同其观点和对其真实性负责。本站是一个个人学习交流的平台,并不用于任何商业目的,如果有任何问题,请及时联系我们,我们将根据著作权人的要求,立即更正或者删除有关内容。本站拥有对此声明的最终解释权。

0 个评论

要回复文章请先登录注册