评测师考试知识点整理Word文档下载推荐.docx
《评测师考试知识点整理Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《评测师考试知识点整理Word文档下载推荐.docx（28页珍藏版）》请在冰点文库上搜索。
第二范式（2NF）和第三范式（3NF）的概念很容易混淆，区分它们的关键点在于，2NF：
非主键列是否完全依赖于主键，还是依赖于主键的一部分；
3NF：
非主键列是直接依赖于主键，还是直接依赖于非主键列。
◆BCNF是比第三范式更严格一个范式。
它要求关系模型中所有的属性（包括主属性和非主属性）都不传递依赖于任何候选关键字。
也就是说，当关系型表中功能上互相依赖的那些列的每一列都是一个候选关键字时候，该满足BCNF。
BCNF实际上是在第三范式的基础上，进一步消除了主属性的传递依赖。
3．
举例
有这样一个配件管理表WPE（WNO,PNO,ENO,QNT）,其中WNO表示仓库号，PNO表示配件号，ENO表示职工号，QNT表示数量。
有以下约束要求：
（1）
一个仓库有多名职工；
（2）
一个职工仅在一个仓库工作；
（3）
每个仓库里一种型号的配件由专人负责，但一个人可以管理几种配件；
（4）
同一种型号的配件可以分放在几个仓库中。
分析表中的函数依赖关系，可以得到：
ENO->
WNO;
（WNO，PNO）->
QNT
ENO
（ENO，PNO）->
可以看到，候选键有：
（ENO,PNO）;
（WNO,PNO）。
所以，ENO,PNO,WNO均为主属性，QNT为非主属性。
显然，非主属性是直接依赖于候选键的。
所以此表满足第三范式。
而我们观察一下主属性：
（WNO,PNO）->
ENO;
WNO。
显然WNO对于候选键（WNO,PNO）存在传递依赖，所以不符合BCNF.
解决这个问题的办法是分拆为两个表：
管理表EP（ENO，PNO，QNT）；
工作表EW（ENO，WNO）。
但这样做会导致函数依赖（WNO,PNO）->
ENO丢失。
4．
应用
虽然，不满足BCNF，也会导致一些冗余和一致性的问题。
但是，将表分解成满足BCNF的表又可能丢失一些函数依赖。
所以，一般情况下不会强制要求关系表要满足BCNF。
◆第四范式（4NF）
1．
定义
第四范式需要满足以下要求：
必须满足第三范式
表中不能包含一个实体的两个或多个互相独立的多值因子。
2．
说明
显然，第四范式也是一个比第三范式严格的范式。
第四范式的意思是：
当一个表中的非主属性互相独立时（3NF），这些非主属性不应该有多值。
若有多值就违反了第四范式。
定义比较抽象，可以参照下面的例子理解。
有这样一个用户联系方式表TELEPHONE（CUSTOMERID,PHONE,CELL）。
CUSTOMERID为用户ID,PHONE为用户的固定电话,CELL为用户的移动电话。
本来，这是一个非常简单的第3范式表。
主键为CUSTOMERID，不存在传递依赖。
但在某些情况下，这样的表还是不合理的。
比如说，用户有两个固定电话，两个移动电话。
这时，表的具体表示如下：
CUSTOMERID
PHONE
CELL
1000
8828-1234
149088888888
8838-1234
149099999999
由于PHONE和CELL是互相独立的，而有些用户又有两个和多个值。
这时此表就违反第四范式。
在这种情况下，此表的设计就会带来很多维护上的麻烦。
例如，如果用户放弃第一行的固定电话和第二行的移动电话，那么这两行会合并吗？
等等
解决问题的方法为，设计一个新表NEW_PHONE（CUSTOMERID,NUMBER,TYPE）.这样就可以对每个用户处理不同类型的多个电话号码，而不会违反第四范式。
显然，第四范式的应用范围比较小，因为只有在某些特殊情况下，要考虑将表规范到第四范式。
所以在实际应用中，一般不要求表满足第四范式。
◆
第五范式（5NF）
第五范式有以下要求：
必须满足第四范式
表必须可以分解为较小的表，除非那些表在逻辑上拥有与原始表相同的主键。
第五范式是在第四范式的基础上做的进一步规范化。
第四范式处理的是相互独立的多值情况，而第五范式则处理相互依赖的多值情况。
有一个销售信息表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（i）>
此时的堆为大顶堆
（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<
total）{
//说明还有右子树
if（num[j]<
num[j+1]）{
//筛选出左右子树中较大的值
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）性能测试。
检查系统是否满足系统设计方案说明书对性能的要求
（5）可靠性、可用性和可维护性测试
（6）安装测试
六、单元测试的主要内容：
单元测试是指对软件中的最小可测试单元进行检查和验证。
主要测试的内容为：
边界测试、
升级会员 