入门

摘要：本文了解了MySQL关系型数据库和SQL语言的基本知识。

1 MySQL数据库

MySQL是一个关系型数据库管理系统，由瑞典MySQL AB公司开发，目前属于Oracle公司。

MySQL使用的SQL语言是用于访问数据库的最常用的标准化语言。

特性：

• 使用C和C++编写，并使用多种编译器进行测试，保证源代码的可移植性。
• 支持AIX、Linux、MacOS、Solaris、Windows等多种操作系统。
• 为多种编程语言提供了API，包括C、C++、Python、Java、Perl、PHP和Ruby等。
• 提供TCP/IP、ODBC和JDBC等多种数据库连接途径。
• 支持多线程，充分利用CPU资源。
• 优化的SQL查询算法，有效地提高查询速度。
• 既能够作为一个单独的应用程序应用在客户端服务器网络环境中，也能够作为一个库而嵌入其他的软件中。
• 提供多语言支持，常见的编码如中文的GB2312、BIG5，日文的Shift_JIS等都可以用作数据表名和数据列名。
• 提供用于管理、检查、优化数据库操作的管理工具。
• 支持大型的数据库，可以处理拥有上千万条记录的大型数据库。
• 支持多种存储引擎。

概念：

• 数据库（Database）：是按照一定结构组织存储在一起的相关数据的集合，这些数据可以被多个用户和应用程序共享。
• 表（Table）：是数据库中存储数据的基本单位，由行和列组成，对应记录和字段。例如，一个学生表可以包含学号和姓名等字段，每一行代表一条学生记录。
• 字段（Field）：是表中的一列，具有特定的数据类型。例如，姓名字段的数据类型可能是字符串。
• 记录（Record）：是表中的一行，包含字段的具体值。一个学生记录包含该学生的学号和姓名等实际信息。

2 SQL语言

SQL（Structured Query Language，结构化查询语言）是一种数据库查询和程序设计语言，用于存取数据以及查询、更新和管理关系数据库系统。

与其他程序设计语言（如C、Java等）不同的是，SQL由很少的关键字组成，每个SQL语句通过一个或多个关键字构成。

优点：

• 一体化：SQL集数据定义、数据操作和数据控制于一体，可以完成数据库中的全部工作。
• 使用方式灵活：SQL具有两种使用方式，可以直接以命令方式交互使用，也可以嵌入使用，嵌入C、C++、Fortran、COBOL、Java等语言中使用。
• 非过程化：只提操作要求，不必描述操作步骤，也不需要导航。使用时只需要告诉计算机做什么，而不需要告诉它怎么做。
• 语言简洁、语法简单、好学好用：在ANSI标准中，只包含94个英文单词，核心功能只用6个动词，语法接近英语口语。

注意：

• SQL语句不区分大小写，许多SQL开发人员习惯对关键字进行大写，而对表或者列的名称使用小写，这样可以提高代码的可阅读性和可维护性。
• 大多数数据库都支持通用的SQL语句，同时不同的数据库具有各自特有的SQL语言特性。
• 某些数据库系统要求在每条SQL命令的末端使用分号。分号是在数据库系统中分隔每条SQL语句的标准方法，这样就可以在对服务器的相同请求中执行一条以上的语句。

3 范式

3.1 定义

设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。

但是有些时候一昧的追求范式减少冗余，反而会降低数据读写的效率，这个时候就要反范式，利用空间来换时间。

3.2 名词

想要正确理解范式的知识，必须先对涉及到的概念名词有一定的了解。

• 实体：可以理解为表，一张表可以看做是一种实体。
• 属性：可以理解为表的字段，一个字段可以看做是一个属性。
• 元组：可以理解为表的记录，一条记录可以看做是一个元组。
• 主属性：候选键中的所有属性，所有候选键中的所有属性。
• 非主属性：不在候选键中的所有属性。

3.3 说明

目前关系数据库有六种范式：

• 第一范式（1NF）
• 第二范式（2NF）
• 第三范式（3NF）
• 巴斯-科德范式（BCNF，又称为修正的第三范式）
• 第四范式（4NF）
• 第五范式（5NF，又称完美范式）

满足最低要求的范式是第一范式（1NF），在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。

一般说来，数据库只需满足第三范式（3NF）就行了。

3.3.1 第一范式（1NF）

要求每个属性都是原子数据项，即每个属性只包含一个值，并且不能有重复的属性。

第一范式确保表中的每个属性都是不可分割的基本数据项。

违背第一范式的数据：

在课程中存在多个值的情况，违背了第一范式。

修改后的数据：

3.3.2 第二范式（2NF）

要求在满足第一范式的基础上，非主属性完全依赖候选键，不能只依赖候选键的一部分。

第二范式确保在候选键为属性组的情况下，表中没有部分依赖问题。

违背第二范式的数据：

将学号和课程作为候选键，共同决定成绩，但姓名只依赖学号，存在部分依赖的情况，违背了第二范式。

修改后的数据：

将学号和姓名单独拆分出来：

3.3.3 第三范式（3NF）

要求在满足第二范式的基础上，非主属性只能依赖主属性，不能依赖其他非主属性。

第三范式确保表中没有传递依赖问题。

违背第三范式的数据：

将学号作为主键，学号决定报考的目标，报考的目标决定所在的省市，存在传递依赖的情况，违背了第三范式。

修改后的数据：

将目标和省市单独拆分出来：

3.3.4 巴斯-科德范式（BCNF）

要求在满足第三范式的基础上，非主属性只能完全依赖主属性，不能部分依赖主属性，也不能依赖其他非主属性。

巴斯-科德范式确保在候选键为属性组的情况下，表中没有部分依赖和传递依赖问题。

违背巴斯-科德范式的数据：

将学号和课程作为主键，同时学号和教师作为候选键，都能决定成绩，但是课程也能决定教师，存在主属性部分依赖主键的情况，违背了巴斯-科德范式。

修改后的数据：

将课程和教师单独拆分出来：

3.3.5 第四范式（4NF）

要求在满足巴斯-科德范式的基础上，当某个属性的值确定时，只能有一条记录与之对应。

第四范式确保表中没有多值依赖问题。

违背第四范式的数据：

将学号作为主键，同时对应多个课程和多个爱好，并且课程和爱好之间没有关联，存在多值依赖的情况，违背了第四范式。

修改后的数据：

将学号和爱好单独拆分出来：

3.3.6 第五范式（5NF）

要求在满足第四范式的基础上，不存在任何通过连接操作生成的冗余数据，即不存在多对多关系。

第五范式确保表中没有连接依赖问题。

违背第五范式的数据：

将学号作为主键，同时对应多个课程和多种考试，并且课程和考试之间存在多对多的关系，存在连接依赖的情况，违背了第五范式。

修改后的数据：

将学号和考试单独拆分出来：