Python数据库：MySQL数据库的详细介绍与安装

最新推荐文章于 2024-07-17 09:26:14 发布

我是真的Cc

最新推荐文章于 2024-07-17 09:26:14 发布

阅读量953

点赞数 28

分类专栏：程序员文章标签：数据库 mysql oracle

本文链接：https://blog.csdn.net/zhendeC1/article/details/137839846

版权

程序员专栏收录该内容

255 篇文章 0 订阅

订阅专栏

本文介绍了数据库规范化的重要概念，包括1NF、2NF和3NF范式，以及它们如何减少冗余和提高数据一致性。还探讨了MySQL数据库的安装与卸载注意事项，以及在实际设计中平衡规范化与性能的需求。

摘要由CSDN通过智能技术生成

要设计规范化的数据库，就要求我们根据数据库设计范式――也就是数据库设计的规范原则来做。范式可以指导我们更好地设计数据库的表结构，减少冗余的数据，借此可以提高数据库的存储效率，数据完整性和可扩展性。

设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴德斯科范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一般说来，数据库只需满足第三范式(3NF）就行了。

2、三大范式

第一范式（1NF）

**所谓第一范式（1NF）是指在关系模型中，对列添加的一个规范要求，所有的列都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。**即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域。

例如:表1-1中，其中”工程地址”列还可以细分为省份，城市等。在国外，更多的程序把”姓名”列也分成2列,即”姓”和“名”。

虽然第一范式要求各列要保存原子性，不能再分，但是这种要求和我们的需求是相关联的，如上表中我们对”工程地址”没有省份，城市这样方面的查询和应用需求，则不需拆分，”姓名”列也是同样如此。

表1-1 原始表

工程号	工程名称	工程地址	员工编号	员工名称	薪资待遇	职务
P001	港珠澳大桥	广东珠海	E0001	Jack	6000/月	工人
P001	港珠澳大桥	广东珠海	E0002	Join	7800/月	工人
P001	港珠澳大桥	广东珠海	E0003	Apple	8000/月	高级技工
P002	南海航天	海南三亚	E0001	Jack	5000/月	工人

第二范式（2NF）

**在1NF的基础上，非Key属性必须完全依赖于主键。**第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。选取一个能区分每个实体的属性或属性组，作为实体的唯一标识。

第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。

例如:表1-1中，一个表描述了工程信息，员工信息等。这样就造成了大量数据的重复。按照第二范式，我们可以将表1-1拆分成表1-2和表1-3：

表1-2 工程信息表

工程编号	工程名称	工程地址
P001	港珠澳大桥	广东珠海
P002	南海航天	海南三亚

表1-3 员工信息表

员工编号	员工姓名	职务	薪资水平
E0001	Jack	工人	3000/月
E0002	Join	工人	3000/月
E0003	Apple	高级技工	6000/月

这样，表1-1就变成了两张表，每个表只描述一件事，清晰明了。

第三范式（3NF）

第三范式是在第二范式基础上，更进一层，第三范式的目标就是确保表中各列与主键列直接相关，而不是间接相关。即各列与主键列都是一种直接依赖关系，则满足第三范式。

第三范式要求各列与主键列直接相关，我们可以这样理解，假设张三是李四的兵，王五则是张三的兵，这时王五是不是李四的兵呢?从这个关系中我们可以看出，王五也是李四的兵，因为王五依赖于张三，而张三是李四的兵，所以王五也是。这中间就存在一种间接依赖的关系而非我们第三范式中强调的直接依赖。

现在我们来看看在第二范式的讲解中，我们将表1-1拆分成了两张表。这两个表是否符合第三范式呢。在员工信息表中包含：”员工编号”、”员工名称”、”职务”、”薪资水平”，而我们知道，薪资水平是有职务决定，这里”薪资水平”通过”职务”与员工相关，则不符合第三范式。我们需要将员工信息表进一步拆分，如下:

员工信息表：员工编号，员工名称，职务

职务表：职务编号，职务名称，薪资水平

现在我们已经了解了数据库规范化设计的三大范式，下面我们再来看看对表1-1优化后的数据表：

员工信息表(Employee)

员工编号	员工姓名	职务编号
E0001	Jack	1
E0002	Join	1
E0003	Apple	2

工程信息表(ProjectInfo)

工程编号	工程名称	工程地址
P001	港珠澳大桥	广东珠海
P002	南海航天	海南三亚

职务表(Duty)

职务编号	职务名称	工资待遇
1	工人	3000/月
2	高级技工	6000/月

工程参与人员记录表（Project_ Employee_info）

编号	工程编号	人员编号
1	P001	E0001
2	P001	E0002
3	P002	E0003

通过对比我们发现，表多了，关系复杂了，查询数据变的麻烦了，编程中的难度也提高了，但是各个表中内容更清晰了，重复的数据少了，更新和维护变的更容易了，哪么如何平衡这种矛盾呢？

4、范式与效率

在我们设计数据库时，设计人员、客户、开发人员通常对数据库的设计有一定的矛盾，客户更喜欢方便，清晰的结果，开发人员也希望数据库关系比较简单，降低开发难度，而设计人员则需要应用三大范式对数据库进行严格规范化，减少数据冗余，提高数据库可维护性和扩展性。由此可以看出，为了满足三大范式，我们数据库设计将会与客户、开发人员产生分歧，所以在实际的数据库设计中，我们不能一味的追求规范化，既要考虑三大范式，减少数据冗余和各种数据库操作异常，又要充分考虑到数据库的性能问题，允许适当的数据库冗余。