如何对数升级之后的数据库进行数据完整性和准确性的校验

Posted 2023-05-10

(3)数据库管理系统(DBMS)：对数据实行专门管理，提供安全性和完整性等统一机制，可以对数据库的建立、使用和维护进行管理。 (4)数据库系统(DBS)：是指 参考技术A 为了防止不符合规范的数据进入数据库，在用户对数据进行插入、修改、删除等操作时，DBMS自动按照一定的约束条件对数据进行监测，使不符合规范的数据不能进入数据库，以确保数据库中存储的数据正确、有效、相容。
1 数据的完整性
约束是用来确保数据的准确性和一致性。数据的完整性就是对数据的准确性和一致性的一种保证。
数据完整性(Data Integrity)是指数据的精确(Accuracy)和可靠性(Reliability)。
分为以下四类：
1) 实体完整性：规定表的每一行在表中是惟一的实体。
2) 域完整性：是指表中的列必须满足某种特定的数据类型约束，其中约束又包括取值范围、精度等规定。
3) 参照完整性：是指两个表的主关键字和外关键字的数据应一致，保证了表之间的数据的一致性，防止了数据丢失或无意义的数据在数据库中扩散。
4) 用户定义的完整性：不同的关系数据库系统根据其应用环境的不同，往往还需要一些特殊的约束条件。用户定义的完整性即是针对某个特定关系数据库的约束条件，它反映某一具体应用必须满足的语义要求。
2 完整性约束的类型：
可分为三种类型：与表有关的约束、域(Domain)约束、断言(Assertion)
1) 与表有关的约束:是表中定义的一种约束。可在列定义时定义该约束，此时称为列约束，也可以在表定义时定义约束，此时称为表约束。
2) 域(Domain)约束：在域定义中被定义的一种约束，它与在特定域中定义的任何列都有关系。
3) 断言(Assertion)：在断言定义时定义的一种约束，它可以与一个或多个表进行关联。
一、 与表有关的约束：包括列约束(表约束+NOT NULL)和表约束(PRIMARY KEY、foreign key、check、UNIQUE) 。
(1) not null（非空)约束： 只用于定义列约束。
语法如下：
Colunm_name datatype | domain not null
实例：
create table Employee
(
emp_id int not null,
emp_name varchar(10) not null,
address varchar(40) ,
)
创建之后，如果往表Employee表中非空约束中插入空值，insert into Employee values(1,null,'neimeng')将会出错。如下：
Msg 515, Level 16, State 2, Line 1
Cannot insert the value NULL into column 'emp_name', table 'Student.dbo.Employee';
column does not allow nulls. INSERT fails.
The statement has been terminated.
(2) unique(惟一)约束：用于指明创建惟一约束的列上的取值必须惟一。
语法如下：
Colunm_name datatype | domain unique
实例：
create table EmployeeInfo
(
emp_id int not null,
emp_name varchar(10) not null,
phone char(11) unique,
address varchar(40) ,
)
如下往EmployeeInfo插入数据时，如果两条记录的phone不惟一，
insert into EmployeeInfo values(1,'abcdwxc','neimeng','13612345678')
insert into EmployeeInfo values(2,'terry','neimeng','13612345678')
则会出现错误。如下：
(1 row(s) affected)
Msg 2627, Level 14, State 1, Line 2
Violation of UNIQUE KEY constraint 'UQ__EmployeeInfo__060DEAE8'. Cannot insert duplicate key in object 'dbo.EmployeeInfo'.
The statement has been terminated.
除了在定义列时添加unique约束外，也可以将unique约束作为表约束添加。即把它作为表定义的元素。
语法如下：
[CONSTRAINT constraint_name] unique (column1,column2,.....)
实例：
create table EmployeeInfo
(
emp_id int not null,
emp_name varchar(10) not null,
phone char(11)
address varchar(40) ,
constraint p_uniq unique(phone)
)
(3) primary key(主键)约束：用于定义基本表的主键，起惟一标识作用，其值不能为null,也不能重复，以此来保证实体的完整性。
语法如下：
Colunm_name datatype | domain primary key
实例：
drop table EmployeeInfo
create table EmployeeInfo
(
emp_id int primary key,
emp_name varchar(10) not null,
phone char(11),
address varchar(40) ,
)
如果向EmployeeInfo表插入的emp_id重复了或者插入时emp_id为null值，则会出错。
可以在创建表时，创建主键约束，也可创建表完成以后，创建主键，例如：
alter table EmployeeInfo
add constraint e_prim primary key(emp_id)
primary key 与 unique的区别：
1.在一个表中，只能定义一个primary key约束，但可定义多个unique约束。
2.对于指定为primary key的一个列或多个列的组合，其中任何一个列都不能出现空值，而对于unique所约束的惟一键，则允许为null,只是null值最多有一个。
(4) foreign key(外键)约束：定义了一个表中数据与另一个表中的数据的联系。
foreign key约束指定某一个列或一组列作为外部键，其中包含外部键的表称为子表，包含外部键所引用的主键的表称为父表。系统保证，表在外部键上的取值要么是父表中某一主键，要么取空值，以此保证两个表之间的连接，确保了实体的参照完整性。
语法如下：
Colunm_name datetype | domain references table_name(column)
[match full|partial|simple] //注：sqlserver不支持。
[referential triggered action]
说明：table_name为父表的表名，column为父表中与外键对应的主键值。
[match full|partial|simple]为可选子句，用于设置如何处理外键中的null值。
[referential triggered action]也为可选子句，用于设置更新、删除外键列时的操作准则。
可以为表的一列或多列创建foreign key 约束，如果为多列创建 foreign key约束，将分别与主表中的相应主键相对应。
实例：
create table EmployeeInfo
(
emp_id int primary key,
emp_name varchar(10) not null,
account char(4) primary key,
phone char(11)
address varchar(40) ,
)
create table Emp_Sal
(
emp_id int , account CHAR(4) ,salary DECIMAL(5,1),
CONSTRAINT E_SAL FOREIGN KEY(emp_id,account) REFERENCES EmployeeInfo (emp_id,account))
)
也可以表创建以后添加到表上。如下：
create table Emp_Sal
(
emp_id int ,emp_name varchar(10) not null, account CHAR(4) ,salary DECIMAL(5,1),
)
alter table Emp_Sal
add CONSTRAINT E_SAL FOREIGN KEY(emp_id,account) REFERENCES EmployeeInfo (emp_id,account)
该外键的作用：确保表Emp_Sal的每个emp_id列都对应表EmployeeInfo中相应的emp_id。此时，表EmployeeInfo为父表，而表Emp_Sal为子表。子表的emp_id列参照父表的emp_id列。
如果想在子表的emp_id列插入一个值，首先父表的emp_id列必须存在，否则会插入失败。如果想从父表的emp_id删除一个值，则必须无删除子表emp_id列中所有与之对应的值。
(注:foreign key 列上的取值可以取null)。
潜在问题：由于foreign key列上可以取空值,DBMS将跳过对foreign key约束的检查，因此如果插入Emp_Sal如下数据：
insert into Emp_Sal values(6,null,null) 则插入到Emp_Sal中，但其主表的相关列却不存在。
解决办法：
（1）将联合外键的列添加not null约束，但这限制了用户的部分操作。
（2）采用Match子句。(sqlserver不支持).
更新、删除操作规则：
在删除或更新有primary key值的行，且该值与子表的foreign key中一个或多个值相匹配时，会引起匹配完整性的丧失。
在foreign key创建语法中，提供了可选的on update和on delete子句，也就是上面的[referential triggered action]。可用此保持引用完整性。
on update / on delete
no action|cascade|restrict|set null|set default
no action:更新或删除父表中的数据时，如果会使子表中的外键违反引用完整性，该动作将被禁止执行。不过在某些条件下，可出现暂时的，但在数据的最终状态中，不能违反外键的引用完整性。
cascade: 当父表中被引用列的数据被更新或删除时，子表中的相应的数据也被更新或删除。
restrict:与no action规则基本相同，只是引用列中的数据永远不能违反外键的引用完整性，暂时的也不行。
set null:当父表数据被更新或删除时，子表中的相应数据被设置成Null值，前提是子表中的相应列允许null值。
set default:当父表数据被更新或删除时,子表中的数据被设置成默认值。前提是子表中的相应列设置有默认值。
(5) check（校验）约束：用来检查字段值所允许的范围。DBMS每当执行delete,insert或update语句时，都对这个约束过滤。如果为true，则执行。否则，取消执行并提示错误。
列定义语法如下：
Column datetype | domain check(search condition)
表约束语法如下：
constraint constraint_name check(search condition)
实例如下：
create table Emp_Sal
(
emp_id int , account CHAR(4) ,salary DECIMAL(5,1),
constraint validsal check(salary >=1000 and salary<=10000)
)
如果此时，再往表中插入如下语句则会出错：(因为不满足salary大于等于1000的约束。)
insert into Emp_Sal values(8,'12324343',800.0)
二、 域约束：(sqlserver 不支持)
语法如下：
create domain domain_name as data type
[default default_value]
[constraint constraint_name] check(value condition expression)
例如：
create domain valid_no as int
constraint constraint_no check(value between 100 and 999)
然后创建表时，使用valid_no域。
create table TestDomain
(
emp_id valid_no,
emp_name varchar(10),
)
三、断言约束：不必与特定的列绑定，可以理解为能应用于多个表的check约束，因此必须在表定义之外独立创建断言。
语法如下：
create assertion constraint_name
check search condition
例如：
create assertion name
check (Emp_Sal.emp_id in(select emp_id from EmployeeInfo where emp_name is not null)
添加断言后，每当试图添加或修改Emp_Sal表中的数据时，就对断言中的搜索条件求值，如果为false，则取消执行，给出提示

如何进行MDM的产品测试

AEAI MDM是数通畅联产品家庭里的基础数据治理平台，保证主数据在各个系统中的正确性、重用性和通用性。从系统应用度而言，主数据管理是把企业的多个业务系统中最核心的、最需要共享的数据（主数据）进行整合，集中进行数据清洗和标准化，并且以集成服务的方式把统一的、完整的、准确的、具有权威性的主数据，分发给需要使用这些数据的应用系统，包括各业务系统和决策支持系统等。

一款产品在上线前，会存在这样或那样的bug，随着后续MDM产品不断扩展功能，虽然其界面UI或功能会产生调整，但整体的构建和使用思路并不会改变。本人也进行了MDM的产品测试，通过在测试过程中总结出的经验，为后续进行产品测试的人员提供参考。 

1总体概述 

MDM可以将企业的黄金数据进行高度的数据统一，各业务系统复用一套主数据，就像一个大系统的各个业务功能模块，企业IT架构可以实现柔性调整、升级、改造，从而支撑企业的业务战略目标落地。 

1.1产品说明 

主数据作为一个统一管理基础数据的平台系统，其中的基础数据都是完整的、统一的、准确的，主数据平台的使用者为各个应用系统的相关负责人员，在主数据中存放的是各系统的基础数据，各个应用系统中存放的是其业务数据。主数据分为MDM和MDC两部分，MDM的功能以显示、管理各系统基础数据为主，MDC的功能以配置基础数据模型为主。 

1.2功能架构 

MDM功能架构图如下所示，分为主数据管理平台和MDC管理控制台两部分：

主数据管理平台主要用于数据的全生命周期管理，数据的同步下发，对数据进行清洗，保证其质量，并针对于数据管理情况进行可视化的视图展现。 

而一个完整的主数据生成方式就需要在MDC进行配置，包括了数据建模，功能建模，分发时用到的流程建模，系统对接以及参考数据、校验规则等配置。 

1.3解决方案 

应用集成方案 ESB + MDM 

统一身份方案  IDM + ESB 

基础数据方案 MDM + ESB 

数仓建设方案 DAP + ESB 

集成底座方案 IDM + MDM + ESB                           （iPaaS方案）  

数据中台方案 MDM + ESB + DAP                          （dPaaS方案） 

应用中心方案 MDM + ESB + Portal                        （aPaaS方案） 

全域集成方案 ESB + MDM + DAP + Portal + IDM （ePaaS方案） 

2测试内容 

MDM测试过程中需要注意测试流程，测试的V模型如下： 

由于本次测试是内部测试，所以到不了验收测试阶段，但如果只是功能方面的单元测试，那么肯定无法达到测试的整体效果。 

2.1测试流程 

MDM的主体测试流程如下： 

1.测试流程的主体是三个模块：数据建模—功能建模—数据管理； 

2.在测试时，数据建模过程中字段的关联定义可以和参考数据功能联动，字段的规则定义； 

3.功能建模在测试过程中，如果需要配置widget组件切换到功能组件中进行配置和测试； 

4.主数据类型如果为关联树，这时需跳转到分类数据建模中进行测试； 

5.在创建主数据前，进行数据下发对接的流程建模和应用配置模块的测试； 

6.数据管理模块进行功能测试完毕后，进行数据清洗的功能测试，针对于质量管理模块的功能测试完毕后，将数据导入到数据管理中； 

7.数据丰富或进行流程测试后，在数据分析中检测数据统计是否准确。 

2.2数据建模 

数据建模可以作为整体的测试开端，包括了整个后续的功能建模，数据管理等，都是基于数据建模进行落实的。 

包括了数据模型的创建，字段的校验方式等，都是从数据建模开始的。 

主数据创建成功后，从详情页进行建模页面的跳转和列表页进行建模的跳转，检查是否有不一样的地方。

来源系统与分发系统进行配置查看功能是否完备。 

在数据建模页面，新增字段，选择select、radio、widget字段就可以进行参考数据的配置。 

点击参考数据按钮，跳转到参考数据页面进行配置和测试。 

测试完毕后，添加校验规则进行测试。 

如果不会正则表达式，可以到网上查找正则表达式的公式，进行配置测试。 

2.3功能建模 

数据建模完毕后，进行功能建模的测试，功能建模是作用于整个数据管理模块的定义。 

包括了表单信息页面，针对每个字段的样式，页面的样式等都会在这里进行配置。 

甚至于页面中的每个按钮都可以进行设置。 

如果在功能建模中选择了树关联，则可以跳转到分类建模页面进行功能的相关测试。 

在分类建模页面进行不同组织的关联，不同的sql配置等。 

在表单的页面配置中，选择一些字段设置为widget组件，然后切换到功能组件中进行配置和测试。 

针对不同的组件类别和数据源类型，共可以组合出来6种组件配置，需要一次排列进行测试。 

流程建模部分可以让MDM与外部接口进行关联，主要作用于数据的分发。 

在流程调用节点中，配置相应的流程服务或数据库读写，既可以测试接口功能是否好使，也能测试该功能是否满足接口调用。 

应用配置也是MDM与其他业务系统进行打通，或者其他系统与MDM打通的重要功能之一。 

应用的新增修改、配置完毕后的token接口调用、主数据的关联情况、字段是否能够准确过滤等都是需要进行测试的。 

2.4数据管理 

功能建模测试完毕后，可以进行模型部署，部署完毕后对主数据页面进行刷新，刚刚新增的主数据就会在左边导航栏进行显示。 

针对于不同类型的主数据要进行不同主数据的生成和测试，保证一个流程完毕后在进行下一个测试。 

在基础的功能测试完毕后，切换到数据清洗页面进行清洗测试。 

根据功能配置中的清洗导出规则进行相应的测试。 

测试完毕后将数据导入到对应的主数据中，导入确认无误后切换到数据分析中进行数据比对，检测是否无误。 

2.5功能联测 

正如上边的数据建模—功能建模—数据管理这三步是循序渐进的，生成单表那么单表生成完毕后，再进行下一次的模型创建是最好的测试方式。包括在功能建模过程中，如果关联树后跳转到分类数据建模页面中。 

在这时，根据操作的顺序进行分类建模的测试即可。 

2.6其他功能 

MDM的其他功能也是围绕着基础数据的管理而使用的。在整体的主流程测试完毕之后，针对于其他部分的使用也需要进行相关的测试，例如：widget组件的配置： 

但是页面配置完毕后，需要记得回到功能配置中进行字段扩充，并实际生成主数据后，才算测试完毕。 

3功能测试 

介绍完MDM的测试流程，那么针对于MDM的基础功能数据管理的测试方式如下。 

3.1数据建模 

数据建模中根据模板类型和模板特性，可以组合出多种主数据类型。 

但在测试过程中，针对于每种主数据类型进行单独的一套测试，这样才能保证测试过程中的连贯。 

3.2功能建模 

功能建模是根据数据建模进行的进一步配置，根据不同数据模型生成不同的功能模型，主要的测试点为表单信息模块，其中包含了很多针对字段的调整功能，不同的显示类型、提供方式、约束方式等，都是在功能建模中需要进行测试的。 

3.3详细配置 

在生成主数据前，有很多可以让主数据更加丰富的地方； 

在流程定义列表中，针对于数据的分发流程的测试。 

字段的约束操作等。 

3.4数据管理 

数据管理即为最终生成的主数据，简单列表、简单列表关联树、树形表格、主从表等，这些都是在每一次主数据创建完毕后，在数据管理中整体测试到位后才算是测试完毕。 

删除节点、数据修改等基础功能需要测试外，针对于生成任务模块，在数据生成完毕后就会在分发任务中，生成对应的任务信息。 

如果是结合了ESB流程进行测试，那么针对于接口是否回写日志等，也可以进行关联性测试。 

4业务联测 

想要将一款产品测试到位，不仅只是对功能进行点击测试，一款产品的实际作用，需要各个模块之间的相互关联才是实现产品价值的必要条件。 

4.1接口服务 

在生成主数据后会，生成对应的API接口用于增删改查等主数据操作，这个接口是管控着主数据针对于上游系统的数据接收和下游系统的数据分发。在地址栏的后缀加上openapi会进入api页面（http://localhost:4040/mdm/openapi）。 

在将地址复制到soapUi中可以进行接口测试，接口的出参入参可以在MDC的API接口中进行查看。 

4.2应用配置 

MDM基础数据平台的作用是用于基础数据治理，而数据治理涉及到了数据同步和数据分发，在整个流程全部测试完毕后，就需要考虑主数据的实际应用功能，应用配置就是打通主数据与各个业务系统之间关联的必要一环。 

MDM无论是进行上游系统的数据同步，还是下游系统的数据接收，都需要获取其tokenId，所以在数据管理测试完毕后，就需要对于系统同步分发的必要功能进行测试了。 

4.3任务日志 

数据同步和分发也是在主数据的生成过程中进行测试的。如果在BPM中配置了ESB流程或者进行了数据同步测试，那么同步的日志信息就需要进行检查测试。 

数据分发时的分发任务，是否生成了分发的日志信息，信息是否回写等，这些在流程配置完毕后都需要进行全面的细致测试。 

4.4质量管理 

质量管控是MDM的重要功能之一，通过定时或手动等方式进行数据的质量管控，数据清洗方式通过不同的测试方式与应用配置中的交互逻辑都是需要测试的。 

5注意事项 

在测试过程中也有不少的测试要点，无论是产品在测试前的学习，熟悉产品之间的功能联系，亦或者是产品测试方式都会让测试有一个很好的效果。

5.1功能熟悉 

在测试MDM前，首先要对MDM的整体功能进行熟悉，了解整个产品的使用流程，但不要产生固定思维，固定思维包括：对功能过于熟悉产生了肌肉记忆、对这部分的功能非常熟悉，在开发过程中经常通过这种方式操作。所谓当局者迷旁观者清，跳出固定思维才能保证测试的客观性。 

5.2流程闭环 

在整个MDM系统中，所有的功能都是围绕着最后的主数据治理功能，所以在实际测试过程中，可以思考如何才能将整个功能串联起来。例如：数据建模-功能建模-数据管理是一套流程，然后进行数据分发，生成的任务管控，在生成完任务后，到监控统计中进行检查。 

在一套业务流程走完后，才算是一套流程闭环，而每次测试都是基于这种思路进行，不仅会让我们对于产品测试更加顺手，还能够提高产品的使用熟悉度，在后续的产品实际使用中，也省去了不少的学习时间。 

5.3破坏测试 

在测试过程中，如果按照产品的既定功能去操作，很大概率不会出现问题，但是客户不一定会按照产品的功能去操作，可能会点击很多功能，或者不按照顺序操作，所以在测试的过程中，不仅要对已有功能进行测试，还要进行一些非常规功能测试，例如：在之前的功能模型测试中，将所有表单都删除后，再进行部署保存等，在整个的测试过程中要时刻进行破坏测试。 

6心得体会 

在测试的过程中，通过进行产品测试，以及与之前使用的产品相结合，让我对于这款产品有了新的认知。 

6.1产品熟悉 

测试不仅是找问题的过程，也是产品熟悉的过程中，在使用前进行整体的、全面的测试，不仅是自己的工作任务，也是一个熟悉产品的过程。软件测试在公司中担当的是“质量管理”角色，可以及时纠正产品的错误并及时更正，确保产品的正常运作。 

6.2方案熟悉 

MDM不仅是一个主数据治理产品，它与我们公司的其他产品相互组合可以产生1+1>2的神奇效果，在搭配过程中，不同的产品组合可以解决企业不同的难题，在测试过程中去熟悉产品之间的关联和使用，也是自我提升的一种方式。 

6.3能力提升 

无论多么细致的测试，最终落实到项目中或多或少都会出现问题，想要在实际项目中进行不断地打磨，让产品更加完善，就需要技术部门与开发人员的共同努力，只有互相合作，互帮互助，才能将产品打磨成为一款精品。 

产品测试是在发布前的最后一道保障，只有把控好最后一道关才能将产品安全的交付到客户手中。在我对公司的每款产品进行测试的过程中，不仅能把发现问题进行解决，还能在一次次的测试中提升自己对产品的理解。在熟悉产品的过程中，针对于产品的衍生方案、实际项目中的应用、可以解决的事情等，都是我所需要去了解的。