看到这个数据库设计,我终于明白了我和其他软测人的差距

01

测试人员为什么要懂数据库设计?

更精准的掌握业务,针对接口测试、Web 测试,都是依照项目/产品需求进行用例设计,如果掌握数据库设计知识,能直接面对开发的数据表,更好、更精准的理解业务逻辑;有的项目中,测试人员还会参与到数据库设计的评审中

更正确的数据库断言,面对接口测试、接口自动化测试,能针对业务特点,快速的构建数据库断言语句

数据库测试与验证,包括数据有效性的验证,设计是否合理(比如是否有插入异常、更新异常、删除异常),数据库压力测试,数据库同步验证等

走向测试开发的基础,如果想逐步成长,进入测试开发的工作中,数据库设计是必须要掌握的基础技能

由此可见,测试从业人员熟悉并掌握数据库设计知识是现实的需要,也是想往上发展的基础。

02

如何进行数据库设计?

要进行数据库设计,需要掌握一些基础技能,包括:

数据库基础知识,包括基本常识、常用概念

数据库设计步骤,掌握如何分析需求,完成概念模型、逻辑模型、物理模型

范式,熟悉常用的规范及要求

实战,掌握根据需求绘制 E-R 图、物理模型设计,并落地到数据库产品

基本常识一

数据(Data):承载各类软件业务中重要的载体都称之为数据,数据的类型包括数值、文本、图片、音频、视频等

数据库(DB,Database ):存放上述各类数据的场所或仓库,提供持久化,不易丢失;并且有合理的组织形式,可管理,还能共享

数据库管理系统(DBMS,Database Management System):对数据加进行管理,提供对数据库的存储管理、安全控制、备份、审计等处理

基本常识二

关系型数据库:传统的数据落地存储模式,建立在严格的数据概念基础上,数据间有规范化的关系,支持 ACID 特性;常见的产品有 MySQL、Oracle、DB2、SQL Server 等

非关系型数据库:随着互联网的快速发展,异构数据、大数据的到来,高可扩展和高伸缩性的需求增加,产生了各种的非关系型数据库;其特点是非关系型、分布式、扩展方便,但不能完全满足 ACID 特性;

常见的非关系型数据库有:

键值型:Memcached、Redis,多用于缓存

列分组型:Hbase 等,多用于日志和一些博客平台

文档型:MongoDB 等,表结构可动态变化,多用于不同结构的日志处理

图数据库:Neo4j 等,一般做推荐引擎或关系图谱

基础概念

数据表:也称二维表,基础的数据保存单位,由列(字段)和行(记录)组成,如下图

字段:规范数据表结构的最小单元,尽量做到不可再分,如下图的浅蓝底部分

数据类型:描述字段的类型,可以有整型、字符串等

主键:唯一的标识一条记录的字段,如下图的学号、课程 ID、成绩 ID 等

外键:引用其他表数据的字段,如下图成绩表中灰色底的学号和课程 ID,引用来自于学生表和课程表

视图:组合一个或多个表输出数据子集,具有隐藏数据复杂性,查询简单等特性,如现在想要设计一个学生成绩的报表,就可以针对下图三个表组织一个视图呈现

函数:类似于程序语言的方法,一般做简单的按规则数据替换或转换

存储过程:预编译,可有输入/输出参数,可包含程序流、逻辑处理、事务等操作,用于处理比较复杂的操作,如数据加工

数据完整性:关联表通过外键要能找到主表数据,否则为数据不完整

数据冗余:重复存储了某些内容,占用存储空间,也会带来不一致的风险

数据库设计步骤

需求分析:识别软件需求中的数据的种类、范围、数量、相互间的交流情况和约束条件等

概念模型设计:当软件系统的用户需求确定后,要根据用户需求抽象出其中常见的对象,以及对象间的关系,称做 E-R(Entity-Relationship)图;常用实体-关系图表示概念模型;如一个教学信息系统中,会抽象出老师、班级、课程、学生等实体,并涉及到老师教授课程、老师带领班级、学生所在班级等关系

逻辑模型设计:将概念模型细化,细化出概念模型中实体的属性,实体间关系通过哪些属性体现;如教学信息系统中,老师实体包括 ID、姓名、性别等特征,通过在课程表上关联老师 ID 建立起关系

物理模型设计:将上述模型的实体、属性、关系,根据实际的数据库产品,落地成对应的物理表,并构建起表的字段、主键、外键、约束、默认值、是否可空、视图等

验证设计:运行基于上述构建数据库的业务系统,来验证设计的数据 CRUD 时的正确性、合理性

运行与维护:随着业务需求的不断迭代,数据库也需要一直的优化和重新设计,以保存数据正确性、合理性,还要考虑新旧业务的兼容与扩展

范式

概述

范式(NF,Normal Form),是关系数据库的理论基础

主要用于数据库结构的设计提供规则和指导,使得设计出的数据具有最好的存储性能、更容易被理解、数据完整性更佳

一共有 6 种,一般设计中满足 1NF、2NF、3NF 即可

常见的不满足 3NF 后带的问题有:数据冗余、插入异常、更新异常、删除异常

第一范式(1NF)

规则:要求数据表中所有字段都是原子性不可分割的;一般的设计都能满足 1NF;右图满足 1NF

不遵守带来的问题:后续业务处理不方便,如下图左要按省份分类数据

第二范式(2NF)

规则:在 1NF 基础上,所有非主键列都完全依赖于主键,而不是部分,能有效减少冗余、保证数据完成性;如下图针对组合主键学号 + 课程 ID,右图右计满足 2NF

不遵守带来的问题:数据冗余、插入异常、更新异常、删除异常;如一个学生有多门课程,就冗余多个学生姓名、新设立一门课程因没有学生考试而必须将学生信息置空、删除某个学员可能导致课程都没有了

第三范式(3NF)

在 2NF 基础上,所有非主键列都直接依赖于主键,不能传递依赖,也能有效减少冗余、保证数据完整性;如下图针对主键课程 ID,右图设计满足 3NF

不遵守带来的问题:主要是数据冗余、插入异常、删除异常等

实战:基于角色的访问控制(RBAC)

需求

一般项目/产品的基础需要,就是需要对不同的用户进行功能授权****

而且,由于用户足够多,天然的会根据人员所在的部门、岗位等情况,某一类人具有相同的授权,也就是需要有“角色”的存在

E-R 图

物理模型

一般的设计过程中,针对 1 对多,会拆成主-外键关系;针对多对多,会添加一个中间表

小型项目数据库设计,可以直接使用 Excel 进行

中大型项目数据库设计,可以使用 PowerDesigner、PDMan 等工具

具体见附件:《基础角色的访问控制》数据库设计、RBAC.pdm

————————————————

版权声明:本文为CSDN博主「软件测试小小白」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。

原文链接:https://blog.csdn.net/fx20211108/article/details/122003423

你可能感兴趣的:(看到这个数据库设计,我终于明白了我和其他软测人的差距)