2023年评测师考试知识点整理

数据库范式范式:英文名称是ＮormaｌForm,它是英国人E．Ｆ.Ｃodd（关系数据库的老祖宗)在上个世纪７0年代提出关系数据库模型后总结出来的，范式是关系数据库理论的基础,也是我们在设计数据库结构过程中所要遵循的规则和指导方法。目前有迹可寻的共有8种范式,依次是:１NF，2NF，3NＦ,BCNF，4NF,5ＮF,DKNＦ，6NＦ。通常所用到的只是前三个范式，即:第一范式（1NF)，第二范式（２NF)，第三范式（３ＮF）。下面就简朴介绍下这三个范式。

◆第一范式(1NF):强调的是列的原子性,即列不可以再提成其他几列。ﻫ考虑这样一个表：【联系人】（姓名,性别,电话）ﻫ假如在实际场景中,一个联系人有家庭电话和公司电话，那么这种表结构设计就没有达成1NF。要符合1ＮＦ我们只需把列（电话）拆分,即:【联系人】（姓名，性别,家庭电话，公司电话)。1NF很好辨别，但是2NF和3NF就容易搞混淆。ﻫ◆第二范式(2NF）:一方面是１NF，此外包含两部分内容，一是表必须有一个主键;二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。ﻫ考虑一个订单明细表：【OｒderDetaiｌ】(ＯrderＩD，ProｄｕctID,UnitPrｉcｅ,Ｄiscounｔ，Quａntｉｔy,ＰroductNaｍe)。ﻫ由于我们知道在一个订单中可以订购多种产品,所以单单一个OrderID是局限性以成为主键的,主键应当是（ＯrｄerID,ＰroduｃtＩD)。显而易见Ｄiscｏunt（折扣），Quantity（数量)完全依赖（取决）于主键（OdｅrID,PｒoｄuctID）,而ＵｎitＰricｅ,ＰroductNaｍｅ只依赖于ＰroduｃｔIＤ。所以OrderＤetail表不符合２NＦ。不符合2ＮＦ的设计容易产生冗余数据。ﻫ可以把【OrderDetａil】表拆分为【OrｄｅrDetail】(OrderID,ＰrodｕctID,Dｉscounｔ,Quanｔity)和【Prｏduｃｔ】(ＰroｄuｃtID，UniｔＰrice，ProｄuctNaｍｅ)来消除原订单表中UnitPriｃe，PrｏducｔName多次反复的情况。

◆第三范式（3NF)：一方面是2NF，此外非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列A依赖于非主键列B,非主键列Ｂ依赖于主键的情况。

考虑一个订单表【Order】（OrderＩD，OrderDatｅ,CｕsｔomerID,CusｔomerNaｍe，ＣusｔomｅrAdｄr，CｕstｏmerCｉtｙ)主键是(OrｄｅrID)。ﻫ其中ＯrderDａte，ＣｕstoｍerID,CustoｍｅrＮaｍe,CusｔoｍerAｄdr,CｕstomeｒCiｔy等非主键列都完全依赖于主键(OrderＩＤ),所以符合２NF。但是问题是CustomerＮaｍｅ,CｕsｔoｍerAddr，CustomerＣitｙ直接依赖的是CustoｍeｒID(非主键列）,而不是直接依赖于主键,它是通过传递才依赖于主键，所以不符合3NF。

通过拆分【Ordｅｒ】为【Order】（OｒdｅｒID，OrdeｒＤate,CuｓtomerID)和【Custoｍeｒ】（CｕstomerID,ＣuｓtomerＮamｅ,CustomｅrＡddr,ＣusｔoｍeｒCity)从而达成3ＮF。

第二范式（2NF）和第三范式(3NF）的概念很容易混淆,区分它们的关键点在于，2NＦ：非主键列是否完全依赖于主键，还是依赖于主键的一部分;3NＦ:非主键列是直接依赖于主键,还是直接依赖于非主键列。◆BＣNF是比第三范式更严格一个范式。它规定关系模型中所有的属性(涉及主属性和非主属性)都不传递依赖于任何候选关键字。也就是说,当关系型表中功能上互相依赖的那些列的每一列都是一个候选关键字时候,该满足ＢCNF。ＢCNＦ事实上是在第三范式的基础上,进一步消除了主属性的传递依赖。3．

举例有这样一个配件管理表WＰE（ＷNO，PNO,EＮO,QNＴ）,其中WNＯ表达仓库号,PＮO表达配件号，ENＯ表达职工号，ＱNT表达数量。有以下约束规定:(1）

一个仓库有多名职工;(2)

一个职工仅在一个仓库工作;(３）

每个仓库里一种型号的配件由专人负责,但一个人可以管理几种配件;(4)

同一种型号的配件可以分放在几个仓库中。分析表中的函数依赖关系,可以得到：（1)

ENO->ＷNO;(2)

(WNO，PNO)-＞QNT（3)

(WNO,ＰNＯ）-＞ＥNＯ(4）

（EＮO，ＰNＯ）-＞QNT可以看到，候选键有：（ENO,PNO);(WNO,PNO)。所以,ENO，PNＯ,WＮO均为主属性,QNＴ为非主属性。显然,非主属性是直接依赖于候选键的。所以此表满足第三范式。而我们观测一下主属性：(WＮO,PNO)->ENO;ENO->WNO。显然WＮＯ对于候选键（WNO,PNＯ)存在传递依赖，所以不符合BＣNＦ.解决这个问题的办法是分拆为两个表:管理表ＥＰ(EＮO，PNO,QＮＴ）;工作表EW(ＥNO,ＷNO)。但这样做会导致函数依赖(ＷNO,ＰＮO)－>ＥNO丢失。4．

应用虽然，不满足BCＮF,也会导致一些冗余和一致性的问题。但是，将表分解成满足BCNF的表又也许丢失一些函数依赖。所以，一般情况下不会强制规定关系表要满足BCNF。◆第四范式（４ＮF)１.

定义第四范式需要满足以下规定：(1）

必须满足第三范式(2）

表中不能包含一个实体的两个或多个互相独立的多值因子。2.

说明

显然，第四范式也是一个比第三范式严格的范式。

第四范式的意思是:当一个表中的非主属性互相独立时（３NF），这些非主属性不应当有多值。若有多值就违反了第四范式。定义比较抽象,可以参照下面的例子理解。３．

举例有这样一个用户联系方式表ＴELEPHONE(CUSTOMＥRIＤ,PHＯＮＥ,CELL)。

CＵSTOＭEＲＩD为用户ＩＤ,PHONE为用户的固定电话，CＥLＬ为用户的移动电话。

本来，这是一个非常简朴的第３范式表。主键为ＣＵＳTOＭERID,不存在传递依赖。但在某些情况下,这样的表还是不合理的。比如说，用户有两个固定电话,两个移动电话。这时，表的具体表达如下:CUSTOMEＲIDＰHＯNECＥLＬ1０00８828-1234８1000８8３8-12３49

由于ＰHONE和CELL是互相独立的，而有些用户又有两个和多个值。这时此表就违反第四范式。

在这种情况下，此表的设计就会带来很多维护上的麻烦。例如，假如用户放弃第一行的固定电话和第二行的移动电话，那么这两行会合并吗？等等

解决问题的方法为，设计一个新表NEＷ＿PＨONE(CUSTOMERID,NUＭBER,ＴYPE).这样就可以对每个用户解决不同类型的多个电话号码,而不会违反第四范式。4.

应用显然,第四范式的应用范围比较小,由于只有在某些特殊情况下，要考虑将表规范到第四范式。所以在实际应用中,一般不规定表满足第四范式。◆

第五范式（5NF)1．

定义第五范式有以下规定:（1)

必须满足第四范式（2)

表必须可以分解为较小的表，除非那些表在逻辑上拥有与原始表相同的主键。2．

说明第五范式是在第四范式的基础上做的进一步规范化。第四范式解决的是互相独立的多值情况,而第五范式则解决互相依赖的多值情况。3．

举例有一个销售信息表SＡLEＳ（SALEPＥＲＳON，VENDOR,PＲOＤUCＴ)。ＳALEＰERSON代表销售人员,VEＮDＯR代表供和商,PRODUCT则代表产品。在某些情况下，这个表中会产生一些冗余。可以将表分解为PERSON_VＥNＤOR表(SAＬEＰERSON，VENDＯR);PERＳON＿PROＤＵCＴ表（SAＬEPＥRＳON，ＰRＯDUＣT);ＶＥNDOR_PRODＩＣT表（VEＮDOＲ,PRODUCT)。分布式数据库系统的透明性１.分片透明性：用户不必关心数据是如何分片，他们对数据的操作在全局关系上进行的，即关心如何分片对用户是透明的,因此,当分片改变时应用程序可以不变。＊**分片透明性是最高层次的透明性,假如用户能在全局关系一级操作,则数据如何分布，如何存储等细节不必关心，其应用程序的编写与集中式数据库相同。2.复制透明性：用户不用关心数据库在网络中的各个节点的复制情况,被复制的数据的更新都由系统自动完毕。***在分布式数据库系统中，可以把一个场地的数据复制到其他场地存放,应用程序可以使用复制到本地的数据在本地完毕分布式操作，避免通过网络传输数据，提高了系统的运营和查询效率。但是对于复制数据的更新操作，就要涉及到对所有复制数据的更新。3．位置透明性：用户不必知道所操作的数据放在何处，即数据分派到哪个或哪些站点存储对用户是透明的。因此,数据分片模式的改变，如把数据从一个站点转移到另一个站点将不会影响应用程序，因而应用程序不必改写。4.逻辑透明性（局部映像透明性):它是最低层次的透明性，该透明性提供数据到局部数据库的映像，即用户不必关心局部DBMS支持哪种数据模型、使用哪种数据操纵语言，数据模型和操纵语言的转换是由系统完毕的。因此,局部映像透明性对异构型和同构异质的分布式数据库系统时非常重要的。堆得简朴介绍以及堆排序一方面看一下堆的定义:对于n个元素的序列{k１,k2,ｋ3,……,kn｝,当且仅当满足下列关系时，称之为堆:K(ｉ)<=K(2*i)＆＆K(i)<=K(2＊i+1）

此时的堆为小顶堆Ｋ（i)>=K(2*i)＆&K(i）>=K(2*i+1)

此时的堆为大顶堆（i=1,２,……，n／2(下取整))注意:堆得存储是用一维数组来存储的。若将堆相应的序列当作是一个完全二叉树，则堆得含义表白：完全二叉树中所有非终端结点的值均不大于（或不小于)其左右孩子结点的值。因此,若序列{K1,K2,……,Kn}是大顶堆，则堆顶元素必为序列中n个元素的最大值;反之,若序列是小顶堆，则堆顶元素必为序列中ｎ个元素的最小值。堆排序就是运用的这个性质。堆排序的过程如下：假设要从小到大排序，我们构建一个大顶堆，则堆顶元素是最大值。将堆顶元素和最后一个元素互换,则最后一个元素变成了n个元素中的最大值。之后再将剩下的ｎ-1个元素调整成为大顶堆,将堆顶元素和第n-１个元素互换,则第n－1个元素变成了ｎ个元素中的次大值……循环这个过程,不断调整堆,最后得到一个有序的序列。在上面堆排序的过程中,有两个问题需要解决:(１）如何将一个初始的序列构建成一个大顶堆?(2）再得到最大元素后，剩下的ｎ-1个元素如何再次调整成为一个大顶堆?事实上，初始序列构建大顶堆也是一个不断调整堆得过程。因此，只要解决第二个问题就可以。下图是一个大顶堆:

当把堆顶元素２０和最后一个元素互换之后，最后一个元素变成了序列中的最大值。如下图:

但是，此时堆顶元素违反了大顶堆的性质，堆顶元素的左右孩子依旧满足大顶堆的性质。因此，此时需要对堆进行调整。由于左子树的值大于右子树的值,所以将3和17互换,如下图:此时，左子树又违反了大顶堆得性质,所以需要调整左子树,如下图:至此,一次调整完毕，堆顶元素成为了次大元素。事实上，调整堆就是这样一个不断筛选比较的过程，不断的和左右子树比较,一直到不需要互换为止。将一个无序序列构建成一个大顶堆的过程就是一个反复筛选的过程。将此序列当作是一个完全二叉树,则最后一个非叶子节点是第n/2（下取整)个元素，因此,筛选只需从第ｎ/2(下取整)个元素开始。假设有序列：｛49,38,65,97,76,１3，２7}，初始二叉树是:

从第3个元素,也就是6５开始调整堆,6５大于左右子树的值,因此不需要调整。然后是第2个元素，也就是从38开始调整堆,38和左右子树比较,将９7和3８互换，调整后如下图：

然后是第1个元素，也就是从4９开始调整堆,49和左右子树比较,将９7和49互换,互换之后,由于４９破坏了左子树大顶堆的性质,因此需要继续调整，将４9和左右子树比较，然后将4９和76互换,调整过程如下图:

至此,将一个无序的序列调整成为了一个大顶堆。同理，堆排序也分为两个过程：（1）将初始化序列调整成为一个大顶堆(2)用最后一个元素和堆顶元素互换，然后不断调整剩下的元素成为一个新的大顶堆。代码如下：

HYＰERLＩNＫ＂"+ViewCｏdeHYPEＲLＩNK""?1234567８9101１１21３141516171８１920212223２４252627282９3031323３ｃｏｎｓtintN=8;iｎｔnum[N]={-1,4９，3８,65,97，７6，13,2７｝;

／/从第一个元素开始存储

／/调整堆的函数ｖｏｉｄheａpＡdjust(ｉntpos，intｔｏtal){

ｉnｔtｅmp＝num［ｐos];

ｆｏr(intj＝２*poｓ;j<=totａl;ｊ＊＝2){

ｉｆ(ｊ<totａl){

//说明尚有右子树

if(nuｍ[j］<nｕm［j+1]){

//筛选出左右子树中较大的值

ｊ+＝１;

｝

}

if(teｍp＞=num[j])

／/不需要再继续向下调整了

break;

ｎum[pos]=nuｍ[j];

pos=j;

}

nｕm［pｏｓ]=temp;｝

vｏiｄhｅapSort(){

／/一方面将数组构建成一个大顶堆

fｏr（iｎti=(N-1）/2;ｉ>＝1;-－i）｛

heapAdjuｓt（i,N－1);

}

//开始堆排序

for(iｎtｉ=Ｎ-1;i>1；--i){

inttemp=ｎum［i];

//互换第一个元素和最后一个元素

num［i］＝num[1];

ｎum[1]＝temｐ；

ｈeapAdjｕsｔ(１,i－1);

//互换完之后,重新调整堆

}}UMＬ类图类图(ClａssDiａgｒam）:类图是面向对象系统建模中最常用和最重要的图,是定义其它图的基础。类图重要是用来显示系统中的类、接口以及它们之间的静态结构和关系的一种静态模型。类图的3个基本组件:类名、属性、方法。泛化(gｅneｒａｌizａtion）：表达is-a的关系，是对象之间耦合度最大的一种关系,子类继承父类的所有细节。直接使用语言中的继承表达。在类图中使用带三角箭头的实线表达,箭头从子类指向父类。实现（Ｒｅaliｚatｉoｎ):在类图中就是接口和实现的关系。这个没什么好讲的。在类图中使用带三角箭头的虚线表达,箭头从实现类指向接口。依赖(Depenｄencｙ)：对象之间最弱的一种关联方式，是临时性的关联。代码中一般指由局部变量、函数参数、返回值建立的对于其他对象的调用关系。一个类调用被依赖类中的某些方法而得以完毕这个类的一些职责。在类图使用带箭头的虚线表达，箭头从使用类指向被依赖的类。关联(Aｓsｏciaｔｉoｎ)：对象之间一种引用关系,比如客户类与订单类之间的关系。这种关系通常使用类的属性表达。关联又分为一般关联、聚合关联与组合关联。后两种在后面分析。在类图使用带箭头的实线表达，箭头从使用类指向被关联的类。可以是单向和双向。聚合(Aggrｅgａｔion):表达hａｓ－a的关系，是一种不稳定的包含关系。较强于一般关联,有整体与局部的关系,并且没有了整体,局部也可单独存在。如公司和员工的关系,公司包含员工，但假如公司倒闭，员工仍然可以换公司。在类图使用空心的菱形表达，菱形从局部指向整体。组合（Compoｓition）:表达ｃontains-ａ的关系,是一种强烈的包含关系。组合类负责被组合类的生命周期。是一种更强的聚合关系。部分不能脱离整体存在。如公司和部门的关系，没有了公司，部门也不能存在了;调查问卷中问题和选项的关系；订单和订单选项的关系。在类图使用实心的菱形表达,菱形从局部指向整体。多重性(Multｉplｉｃity）:通常在关联、聚合、组合中使用。就是代表有多少个关联对象存在。使用数字..星号（数字）表达。如下图，一个割接告知可以关联０个到Ｎ个故障单。聚合和组合的区别这两个比较难理解，重点说一下。聚合和组合的区别在于:聚合关系是“has-ａ”关系,组合关系是“ｃｏｎtａinｓ-ａ”关系；聚合关系表达整体与部分的关系比较弱，而组合比较强;聚合关系中代表部分事物的对象与代表聚合事物的对象的生存期无关，一旦删除了聚合对象不一定就删除了代表部分事物的对象。组合中一旦删除了组合对象，同时也就删除了代表部分事物的对象。实例分析联通客户响应OSS。系统有故障单、业务开通、资源核查、割接、业务重保、网络品质性能等功能模块。现在我们抽出部分需求做为例子讲解。大家可以参照着类图，好好理解。１．告知分为一般告知、割接告知、重保告知。这个是继承关系。2.NotiｃｅＳｅrvice和实现类NoticeSeｒviｃeIｍpl是实现关系。３．NoｔiceSeｒｖｉcｅImpｌ通过save方法的参数引用Ｎｏｔｉce,是依赖关系。同时调用了BａseDao完毕功能，也是依赖关系。4．割接告知和故障单之间通过中间类(告知电路)关联，是一般关联。5．重保告知和预案库间是聚合关系。由于预案库可以事先录入,和重保告知没有必然联系，可以独立存在。在系统中是手工从列表中选择。删除重保告知,不影响预案。6.割接告知和需求单之间是聚合关系。同理,需求单可以独立于割接告知存在。也就是说删除割接告知,不影响需求单。7.告知和回复是组合关系。由于回复不能独立于告知存在。也就是说删除告知，该条告知相应的回复也要级联删除。通过以上的分析,相信大家对类的关系已有比较好的理解了。大家有什么其它想法或好的见解，欢迎拍砖。一、类的属性的表达方式在UML类图中,类使用包含类名、属性（ｆｉeld)和方法(ｍeｔhoｄ）且带有分割线的矩形来表达,比如下图表达一个Emplｏyeｅ类，它包含name,ａｇｅ和email这3个属性，以及mｏdifyＩnｆo()方法。那么属性/方法名称前加的加号和减号是什么意思呢?它们表达了这个属性或方法的可见性，UMＬ类图中表达可见性的符号有三种:·+:表达puｂliｃ·-:表达privａte·#:表达protectｅｄ(frienｄly也归入这类)因此,上图中的Ｅmployeｅ类具有３个私有属性和一个公有方法。

事实上,属性的完整表达方式是这样的:可见性

名称：类型[=缺省值]中括号中的内容表达是可选的

二、类的方法的表达方式上图中我们已经看到了方法的表达形式。事实上,方法的完整表达方式如下：可见性

名称(参数列表)［:返回类型]同样,中括号中的内容是可选的。

比如在下图的Deｍo类中，定义了3个方法：

·puｂｌｉｃ方法metｈｏd1接受一个类型为Objｅct的参数,返回值类型为vｏｉd·pｒｏtecteｄ方法method2无参数,返回值类型为String·private方法method3接受类型分别为ｉnｔ、inｔ[]的参数,返回值类型为inｔ

三、类与类之间关系的表达方式1、关联关系关联关系又可进一步分为单向关联、双向关联和自关联。（1)单向关联我们可以看到,在UML类图中单向关联用一个带箭头的直线表达。上图表达每个顾客都有一个地址，这通过让Custoｍｅr类持有一个类型为Addrｅsｓ的成员变量类实现。

（２)双向关联从上图中我们很容易看出，所谓的双向关联就是双方各自持有对方类型的成员变量。在UML类图中,双向关联用一个不带箭头的直线表达。上图中在Cｕsｔomｅr类中维护一个Prｏduct[]数组，表达一个顾客购买了那些产品；在Proｄuｃt类中维护一个Ｃustomｅr类型的成员变量表达这个产品被哪个顾客所购买。

（３)自关联自关联在ＵML类图中用一个带有箭头且指向自身的直线表达。上图的意思就是Nodｅ类包含类型为Ｎodｅ的成员变量,也就是“自己包含自己”。

2、聚合关系上图中的Car类与Engｉnｅ类就是聚合关系(Caｒ类中包含一个Enｇｉne类型的成员变量）。由上图我们可以看到，UML中聚合关系用带空心菱形和箭头的直线表达。聚合关系强调是“整体”包含“部分”,但是“部分”可以脱离“整体”而单独存在。比如上图中汽车包含了发动机，而发动机脱离了汽车也能单独存在。

３、组合关系组合关系与聚合关系见得最大不同在于:这里的“部分”脱离了“整体”便不复存在。比如下图：显然,嘴是头的一部分且不能脱离了头而单独存在。在UML类图中，组合关系用一个带实心菱形和箭头的直线表达。

4、依赖关系从上图我们可以看到,Ｄriver的drive方法只有传入了一个Car对象才干发挥作用,因此我们说Driver类依赖于Cａr类。在UML类图中,依赖关系用一条带有箭头的虚线表达。

5、继承关系继承关系相应的是ｅxtｅnd关键字，在UＭL类图中用带空心三角形的直线表达，如下图所示中,Stｕdｅnt类与Ｔｅaｃher类继承了Person类。

6、接口实现关系这种关系相应iｍplemｅｎt关键字,在UMＬ类图中用带空心三角形的虚线表达。如下图中，Ｃａｒ类与Ship类都实现了Vｅhｉｃle接口。

到了这里，UML类图中最常见的表达方式我们就介绍完了,有了这些我们就能读懂常见的UML类图了,剩下的碰届时再查即可。常见的系统测试重要有以下内容：（１)恢复测试。监测系统的容错能力(2）安全性测试。检测系统的安全机制、保密措施是否完善,重要是为了检查系统的防范能力(3）压力测试。也称为强度测试，是对系统在异常情况下的承受能力的测试，是检查系统在极限状态下运营时，性能下降的幅度是否在允许的范围内（4）性能测试。检查系统是否满足系统设计方案说明书对性能的规定(5）可靠性、可用性和可维护性测试(6)安装测试单元测试的重要内容：ﻩ单元测试是指对软件中的最小可测试单元进行检查和验证。重要测试的内容为:边界测试、错误解决测试、途径测试、局部数据结构测试和模块接口测试。网络测试指标通常网络测试的四个指标为吞吐量，延时,丢包率和背靠背性能。1、吞吐量：指被测试设备或被测试系统在不丢包的情况下,可以达成的最大包转发速率。２、丢包率:通过测试由于缺少资源而未转发的包的比例来显示高负载状态下系统的性能。3、延时：指测量系统在有负载条件下转发数据包所需的时间。4、背靠背性能:指通过以最大帧速率发送突发传输流,并测量包丢失时的最大突发长度(总包数量)来测试缓冲区容量。基本途径测试法概念ﻩ它在程序控制流图的基础上,通过度析控制流图的环路复杂性,导出基本可执行途径的集合，然后据此设计测试用例。设计出的测试用例要保证在测试中程序的每一条可执行语句至少执行一次。决策表法设计测试用例环节１、拟定规则个数。有ｎ个条件的决策表有２n个规则（每个条件取真、假值）。2、列出所有的条件桩和动作桩。３、填入条件项。4、填入动作项,得到初始决策表。５、简化。合并相似规则或者相同动作。单缓冲和双缓冲解决时间某文献占10个磁盘块，现要把该文献磁盘块逐个读入主存缓冲区,并送用户区进行分析。假设一个缓冲区与一个磁盘块大小相同,把一个磁盘块读入缓冲区的时间为１00μs，将缓冲区的数据传送到用户区的时间是5０μs,CPU对一块数据进行分析的时间为50μs。在单缓冲区和双缓冲区结构下,读入并分析完该文献的时间分别是（）。A.１500μｓ,1000μsB．1