评测师考试知识点整理.docx
《评测师考试知识点整理.docx》由会员分享，可在线阅读，更多相关《评测师考试知识点整理.docx（27页珍藏版）》请在冰豆网上搜索。
评测师考试知识点整理
一、数据库范式
范式:
英文名称就是NormalForm,它就是英国人E、F、Codd（关系数据库的老祖宗）在上个世纪70年代提出关系数据库模型后总结出来的,范式就是关系数据库理论的基础,也就是我们在设计数据库结构过程中所要遵循的规则与指导方法。
目前有迹可寻的共有8种范式,依次就是:
1NF,2NF,3NF,BCNF,4NF,5NF,DKNF,6NF。
通常所用到的只就是前三个范式,即:
第一范式（1NF）,第二范式（2NF）,第三范式（3NF）。
下面就简单介绍下这三个范式。
◆第一范式（1NF）:
强调的就是列的原子性,即列不能够再分成其她几列。
考虑这样一个表:
【联系人】（姓名,性别,电话）
如果在实际场景中,一个联系人有家庭电话与公司电话,那么这种表结构设计就没有达到1NF。
要符合1NF我们只需把列（电话）拆分,即:
【联系人】（姓名,性别,家庭电话,公司电话）。
1NF很好辨别,但就是2NF与3NF就容易搞混淆。
◆第二范式（2NF）:
首先就是1NF,另外包含两部分内容,一就是表必须有一个主键;二就是没有包含在主键中的列必须完全依赖于主键,而不能只依赖于主键的一部分。
考虑一个订单明细表:
【OrderDetail】（OrderID,ProductID,UnitPrice,Discount,Quantity,ProductName）。
因为我们知道在一个订单中可以订购多种产品,所以单单一个OrderID就是不足以成为主键的,主键应该就是（OrderID,ProductID）。
显而易见Discount（折扣）,Quantity（数量）完全依赖（取决）于主键（OderID,ProductID）,而UnitPrice,ProductName只依赖于ProductID。
所以OrderDetail表不符合2NF。
不符合2NF的设计容易产生冗余数据。
可以把【OrderDetail】表拆分为【OrderDetail】（OrderID,ProductID,Discount,Quantity）与【Product】（ProductID,UnitPrice,ProductName）来消除原订单表中UnitPrice,ProductName多次重复的情况。
◆第三范式（3NF）:
首先就是2NF,另外非主键列必须直接依赖于主键,不能存在传递依赖。
即不能存在:
非主键列A依赖于非主键列B,非主键列B依赖于主键的情况。
考虑一个订单表【Order】（OrderID,OrderDate,CustomerID,CustomerName,CustomerAddr,CustomerCity）主键就是（OrderID）。
其中OrderDate,CustomerID,CustomerName,CustomerAddr,CustomerCity等非主键列都完全依赖于主键（OrderID）,所以符合2NF。
不过问题就是CustomerName,CustomerAddr,CustomerCity直接依赖的就是CustomerID（非主键列）,而不就是直接依赖于主键,它就是通过传递才依赖于主键,所以不符合3NF。
通过拆分【Order】为【Order】（OrderID,OrderDate,CustomerID）与【Customer】（CustomerID,CustomerName,CustomerAddr,CustomerCity）从而达到3NF。
第二范式（2NF）与第三范式（3NF）的概念很容易混淆,区分它们的关键点在于,2NF:
非主键列就是否完全依赖于主键,还就是依赖于主键的一部分;3NF:
非主键列就是直接依赖于主键,还就是直接依赖于非主键列。
◆BCNF就是比第三范式更严格一个范式。
它要求关系模型中所有的属性（包括主属性与非主属性）都不传递依赖于任何候选关键字。
也就就是说,当关系型表中功能上互相依赖的那些列的每一列都就是一个候选关键字时候,该满足BCNF。
BCNF实际上就是在第三范式的基础上,进一步消除了主属性的传递依赖。
3. 举例
有这样一个配件管理表WPE（WNO,PNO,ENO,QNT）,其中WNO表示仓库号,PNO表示配件号,ENO表示职工号,QNT表示数量。
有以下约束要求:
（1） 一个仓库有多名职工;
（2） 一个职工仅在一个仓库工作;
（3） 每个仓库里一种型号的配件由专人负责,但一个人可以管理几种配件;
（4） 同一种型号的配件可以分放在几个仓库中。
分析表中的函数依赖关系,可以得到:
（1） ENO->WNO;
（2） （WNO,PNO）->QNT
（3） （WNO,PNO）->ENO
（4） （ENO,PNO）->QNT
可以瞧到,候选键有:
（ENO,PNO）;（WNO,PNO）。
所以,ENO,PNO,WNO均为主属性,QNT为非主属性。
显然,非主属性就是直接依赖于候选键的。
所以此表满足第三范式。
而我们观察一下主属性:
（WNO,PNO）->ENO;ENO->WNO。
显然WNO对于候选键（WNO,PNO）存在传递依赖,所以不符合BCNF、
解决这个问题的办法就是分拆为两个表:
管理表EP（ENO,PNO,QNT）;工作表EW（ENO,WNO）。
但这样做会导致函数依赖（WNO,PNO）->ENO丢失。
4. 应用
虽然,不满足BCNF,也会导致一些冗余与一致性的问题。
但就是,将表分解成满足BCNF的表又可能丢失一些函数依赖。
所以,一般情况下不会强制要求关系表要满足BCNF。
◆第四范式（4NF）
1. 定义
第四范式需要满足以下要求:
（1） 必须满足第三范式
（2） 表中不能包含一个实体的两个或多个互相独立的多值因子。
2. 说明
显然,第四范式也就是一个比第三范式严格的范式。
第四范式的意思就是:
当一个表中的非主属性互相独立时（3NF）,这些非主属性不应该有多值。
若有多值就违反了第四范式。
定义比较抽象,可以参照下面的例子理解。
3. 举例
有这样一个用户联系方式表TELEPHONE（CUSTOMERID,PHONE,CELL）。
CUSTOMERID为用户ID,PHONE为用户的固定电话,CELL为用户的移动电话。
本来,这就是一个非常简单的第3范式表。
主键为CUSTOMERID,不存在传递依赖。
但在某些情况下,这样的表还就是不合理的。
比如说,用户有两个固定电话,两个移动电话。
这时,表的具体表示如下:
CUSTOMERID
PHONE
CELL
1000
8828-1234
149088888888
1000
8838-1234
149099999999
由于PHONE与CELL就是互相独立的,而有些用户又有两个与多个值。
这时此表就违反第四范式。
在这种情况下,此表的设计就会带来很多维护上的麻烦。
例如,如果用户放弃第一行的固定电话与第二行的移动电话,那么这两行会合并不？
等等
解决问题的方法为,设计一个新表NEW_PHONE（CUSTOMERID,NUMBER,TYPE）、这样就可以对每个用户处理不同类型的多个电话号码,而不会违反第四范式。
4. 应用
显然,第四范式的应用范围比较小,因为只有在某些特殊情况下,要考虑将表规范到第四范式。
所以在实际应用中,一般不要求表满足第四范式。
◆ 第五范式（5NF）
1. 定义
第五范式有以下要求:
（1） 必须满足第四范式
（2） 表必须可以分解为较小的表,除非那些表在逻辑上拥有与原始表相同的主键。
2. 说明
第五范式就是在第四范式的基础上做的进一步规范化。
第四范式处理的就是相互独立的多值情况,而第五范式则处理相互依赖的多值情况。
3. 举例
有一个销售信息表SALES（SALEPERSON,VENDOR,PRODUCT）。
SALEPERSON代表销售人员,VENDOR代表供与商,PRODUCT则代表产品。
在某些情况下,这个表中会产生一些冗余。
可以将表分解为PERSON_VENDOR表（SALEPERSON,VENDOR）;PERSON_PRODUCT表（SALEPERSON,PRODUCT）;VENDOR_PRODICT表（VENDOR,PRODUCT）。
二、分布式数据库系统的透明性
1、分片透明性:
用户不必关心数据就是如何分片,她们对数据的操作在全局关系上进行的,即关心如何分片对用户就是透明的,因此,当分片改变时应用程序可以不变。
***分片透明性就是最高层次的透明性,如果用户能在全局关系一级操作,则数据如何分布,如何存储等细节不必关心,其应用程序的编写与集中式数据库相同。
2、复制透明性:
用户不用关心数据库在网络中的各个节点的复制情况,被复制的数据的更新都由系统自动完成。
***在分布式数据库系统中,可以把一个场地的数据复制到其她场地存放,应用程序可以使用复制到本地的数据在本地完成分布式操作,避免通过网络传输数据,提高了系统的运行与查询效率。
但就是对于复制数据的更新操作,就要涉及到对所有复制数据的更新。
3、位置透明性:
用户不必知道所操作的数据放在何处,即数据分配到哪个或哪些站点存储对用户就是透明的。
因此,数据分片模式的改变,如把数据从一个站点转移到另一个站点将不会影响应用程序,因而应用程序不必改写。
4、逻辑透明性（局部映像透明性）:
它就是最低层次的透明性,该透明性提供数据到局部数据库的映像,即用户不必关心局部DBMS支持哪种数据模型、使用哪种数据操纵语言,数据模型与操纵语言的转换就是由系统完成的。
因此,局部映像透明性对异构型与同构异质的分布式数据库系统时非常重要的。
三、堆得简单介绍以及堆排序
首先瞧一下堆的定义:
对于n个元素的序列{k1,k2,k3,……,kn},当且仅当满足下列关系时,称之为堆:
K（i）<=K（2*i）&&K（i）<=K（2*i+1） 此时的堆为小顶堆
K（i）>=K（2*i）&&K（i）>=K（2*i+1） 此时的堆为大顶堆
（i=1,2,……,n/2（下取整））
注意:
堆得存储就是用一维数组来存储的。
若将堆对应的序列瞧成就是一个完全二叉树,则堆得含义表明:
完全二叉树中所有非终端结点的值均不大于（或不小于）其左右孩子结点的值。
因此,若序列{K1,K2,……,Kn}就是大顶堆,则堆顶元素必为序列中n个元素的最大值;反之,若序列就是小顶堆,则堆顶元素必为序列中n个元素的最小值。
堆排序就就是利用的这个性质。
堆排序的过程如下:
假设要从小到大排序,我们构建一个大顶堆,则堆顶元素就是最大值。
将堆顶元素与最后一个元素互换,则最后一个元素变成了n个元素中的最大值。
之后再将剩下的n-1个元素调整成为大顶堆,将堆顶元素与第n-1个元素互换,则第n-1个元素变成了n个元素中的次大值……循环这个过程,不断调整堆,最后得到一个有序的序列。
在上面堆排序的过程中,有两个问题需要解决:
（1）如何将一个初始的序列构建成一个大顶堆？
（2）再得到最大元素后,剩下的n-1个元素如何再次调整成为一个大顶堆？
实际上,初始序列构建大顶堆也就是一个不断调整堆得过程。
因此,只要解决第二个问题就可以。
下图就是一个大顶堆:
当把堆顶元素20与最后一个元素互换之后,最后一个元素变成了序列中的最大值。
如下图:
但就是,此时堆顶元素违反了大顶堆的性质,堆顶元素的左右孩子仍旧满足大顶堆的性质。
因此,此时需要对堆进行调整。
因为左子树的值大于右子树的值,所以将3与17互换,如下图:
此时,左子树又违反了大顶堆得性质,所以需要调整左子树,如下图:
至此,一次调整完毕,堆顶元素成为了次大元素。
实际上,调整堆就就是这样一个不断筛选比较的过程,不断的与左右子树比较,一直到不需要交换为止。
将一个无序序列构建成一个大顶堆的过程就就是一个反复筛选的过程。
将此序列瞧成就是一个完全二叉树,则最后一个非叶子节点就是第n/2（下取整）个元素,因此,筛选只需从第n/2（下取整）个元素开始。
假设有序列:
{49,38,65,97,76,13,27},初始二叉树就是:
从第3个元素,也就就是65开始调整堆,65大于左右子树的值,因此不需要调整。
然后就是第2个元素,也就就是从38开始调整堆,38与左右子树比较,将97与38互换,调整后如下图:
然后就是第1个元素,也就就是从49开始调整堆,49与左右子树比较,将97与49互换,互换之后,因为49破坏了左子树大顶堆的性质,因此需要继续调整,将49与左右子树比较,然后将49与76互换,调整过程如下图:
至此,将一个无序的序列调整成为了一个大顶堆。
同理,堆排序也分为两个过程:
（1）将初始化序列调整成为一个大顶堆
（2）用最后一个元素与堆顶元素交换,然后不断调整剩下的元素成为一个新的大顶堆。
代码如下:
+ViewCode?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
constintN=8;
intnum[N]={-1,49,38,65,97,76,13,27}; //从第一个元素开始存储
//调整堆的函数
voidheapAdjust（intpos,inttotal）{
inttemp=num[pos];
for（intj=2*pos;j<=total;j*=2）{
if（j if（num[j] j+=1;
}
}
if（temp>=num[j]） //不需要再继续向下调整了
break;
num[pos]=num[j];
pos=j;
}
num[pos]=temp;
}
voidheapSort（）{
//首先将数组构建成一个大顶堆
for（inti=（N-1）/2;i>=1;--i）{
heapAdjust（i,N-1）;
}
//开始堆排序
for（inti=N-1;i>1;--i）{
inttemp=num[i]; //交换第一个元素与最后一个元素
num[i]=num[1];
num[1]=temp;
heapAdjust（1,i-1）; //交换完之后,重新调整堆
}
}
四、UML类图
类图（ClassDiagram）:
类图就是面向对象系统建模中最常用与最重要的图,就是定义其它图的基础。
类图主要就是用来显示系统中的类、接口以及它们之间的静态结构与关系的一种静态模型。
类图的3个基本组件:
类名、属性、方法。
泛化（generalization）:
表示is-a的关系,就是对象之间耦合度最大的一种关系,子类继承父类的所有细节。
直接使用语言中的继承表达。
在类图中使用带三角箭头的实线表示,箭头从子类指向父类。
实现（Realization）:
在类图中就就是接口与实现的关系。
这个没什么好讲的。
在类图中使用带三角箭头的虚线表示,箭头从实现类指向接口。
依赖（Dependency）:
对象之间最弱的一种关联方式,就是临时性的关联。
代码中一般指由局部变量、函数参数、返回值建立的对于其她对象的调用关系。
一个类调用被依赖类中的某些方法而得以完成这个类的一些职责。
在类图使用带箭头的虚线表示,箭头从使用类指向被依赖的类。
关联（Association）:
对象之间一种引用关系,比如客户类与订单类之间的关系。
这种关系通常使用类的属性表达。
关联又分为一般关联、聚合关联与组合关联。
后两种在后面分析。
在类图使用带箭头的实线表示,箭头从使用类指向被关联的类。
可以就是单向与双向。
聚合（Aggregation）:
表示has-a的关系,就是一种不稳定的包含关系。
较强于一般关联,有整体与局部的关系,并且没有了整体,局部也可单独存在。
如公司与员工的关系,公司包含员工,但如果公司倒闭,员工依然可以换公司。
在类图使用空心的菱形表示,菱形从局部指向整体。
组合（Composition）:
表示contains-a的关系,就是一种强烈的包含关系。
组合类负责被组合类的生命周期。
就是一种更强的聚合关系。
部分不能脱离整体存在。
如公司与部门的关系,没有了公司,部门也不能存在了;调查问卷中问题与选项的关系;订单与订单选项的关系。
在类图使用实心的菱形表示,菱形从局部指向整体。
多重性（Multiplicity）:
通常在关联、聚合、组合中使用。
就就是代表有多少个关联对象存在。
使用数字、、星号（数字）表示。
如下图,一个割接通知可以关联0个到N个故障单。
聚合与组合的区别
这两个比较难理解,重点说一下。
聚合与组合的区别在于:
聚合关系就是“has-a”关系,组合关系就是“contains-a”关系;聚合关系表示整体与部分的关系比较弱,而组合比较强;聚合关系中代表部分事物的对象与代表聚合事物的对象的生存期无关,一旦删除了聚合对象不一定就删除了代表部分事物的对象。
组合中一旦删除了组合对象,同时也就删除了代表部分事物的对象。
实例分析
联通客户响应OSS。
系统有故障单、业务开通、资源核查、割接、业务重保、网络品质性能等功能模块。
现在我们抽出部分需求做为例子讲解。
大家可以参照着类图,好好理解。
1.通知分为一般通知、割接通知、重保通知。
这个就是继承关系。
2.NoticeService与实现类NoticeServiceImpl就是实现关系。
3.NoticeServiceImpl通过save方法的参数引用Notice,就是依赖关系。
同时调用了BaseDao完成功能,也就是依赖关系。
4.割接通知与故障单之间通过中间类（通知电路）关联,就是一般关联。
5.重保通知与预案库间就是聚合关系。
因为预案库可以事先录入,与重保通知没有必然联系,可以独立存在。
在系统中就是手工从列表中选择。
删除重保通知,不影响预案。
6.割接通知与需求单之间就是聚合关系。
同理,需求单可以独立于割接通知存在。
也就就是说删除割接通知,不影响需求单。
7.通知与回复就是组合关系。
因为回复不能独立于通知存在。
也就就是说删除通知,该条通知对应的回复也要级联删除。
经过以上的分析,相信大家对类的关系已经有比较好的理解了。
大家有什么其它想法或好的见解,欢迎拍砖。
一、类的属性的表示方式
在UML类图中,类使用包含类名、属性（field）与方法（method）且带有分割线的矩形来表示,比如下图表示一个Employee类,它包含name,age与email这3个属性,以及modifyInfo（）方法。
那么属性/方法名称前加的加号与减号就是什么意思呢？
它们表示了这个属性或方法的可见性,UML类图中表示可见性的符号有三种:
·+:
表示public
·-:
表示private
·#:
表示protected（friendly也归入这类）
因此,上图中的Employee类具有3个私有属性与一个公有方法。
实际上,属性的完整表示方式就是这样的:
可见性 名称:
类型[=缺省值]
中括号中的内容表示就是可选的
二、类的方法的表示方式
上图中我们已经瞧到了方法的表示形式。
实际上,方法的完整表示方式如下:
可见性 名称（参数列表）[:
返回类型]
同样,中括号中的内容就是可选的。
比如在下图的Demo类中,定义了3个方法:
·public方法method1接收一个类型为Object的参数,返回值类型为void
·protected方法method2无参数,返回值类型为String
·private方法method3接收类型分别为int、int[]的参数,返回值类型为int
三、类与类之间关系的表示方式
1、关联关系
关联关系又可进一步分为单向关联、双向关联与自关联。
（1）单向关联
我们可以瞧到,在UML类图中单向关联用一个带箭头的直线表示。
上图表示每个顾客都有一个地址,这通过让Customer类持有一个类型为Address的成员变量类实现。
（2）双向关联
从上图中我们很容易瞧出,所谓的双向关联就就是双方各自持有对方类型的成员变量。
在UML类图中,双向关联用一个不带箭头的直线表示。
上图中在Customer类中维护一个Product[]数组,表示一个顾客购买了那些产品;在Product类中维护一个Customer类型的成员变量表示这个产品被哪个顾客所购买。
（3）自关联
自关联在UML类图中用一个带有箭头且指向自身的直线表示。
上图的意思就就是Node类包含类型为Node的成员变量,也就就是“自己包含自己”。
2、聚合关系
上图中的Car类与Engine类就就是聚合关系（Car类中包含一个Engine类型的成员变量）。
由上图我们可以瞧到,UML中聚合关系用带空心菱形与箭头的直线表示。
聚合关系强调就是“整体”包含“部分”,但就是“部分”可以脱离“整体”而单独存在。
比如上图中汽车包含了发动机,而发动机脱离了汽车也能单独存在。
3、组合关系
组合关系与聚合关系见得最大不同在于:
这里的“部分”脱离了“整体”便不复存在。
比如下图:
显然,嘴就是头的一部分且不能脱离了头而单独存在。
在UML类图中,组合关系用一个带实心菱形与箭头的直线表示。
4、依赖关系
从上图我们可以瞧到,Driver的drive方法只有传入了一个Car对象才能发挥作用,因此我们说Driver类依赖于Car类。
在UML类图中,依赖关系用一条带有箭头的虚线表示。
5、继承关系
继承关系对应的就是extend关键字,在UML类图中用带空心三角形的直线表示,如下图所示中,Student类与Teacher类继承了Person类。
6、接口实现关系
这种关系对应implement关键字,在UML类图中用带空心三角形的虚线表示。
如下图中,Car类与Ship类都实现了Vehicle接口。
到了这里,UML类图中最常见的表示方式我们就介绍完了,有了这些我们就能读懂常见的UML类图了,剩下的遇到时再查即可。
五、常见的系统测试主要有以下内容:
（1）恢复测试。
监测系统的容错能力
（2）安全性测试。
检测系统的安全机制、保密措施就是否完善,主要就是为了检验系统的防范能力
（3）压力测试。
也称为强度测试,就是对系统在异常情况下的承受能力的测试,就是检查系统在极限状态下运行时,性能下降的幅度就是否在允许的范围内
（4）性能测试。
检查系统就是否满足
升级会员 