MySQL数据库理论基础及范式浅析

MySQL数据库基础知识

  MySQL是一种开放源代码的关系型数据库管理系统（RDBMS），使用最常用的数据库管理语言——结构化查询语言（SQL）进行数据库管理，由于其速度、可靠性和适应性而备受关注，大多数人都认为在不需要事务化处理的情况下，MySQL是管理内容最好的选择。
  MySQL在网络环境中使用客户端/服务器（Client/Server）架构，其核心程序扮演者服务器角色，他管理者对磁盘数据库和内存的访问，而各客户端程序连接到服务器并提出请求。MySQL Server进行多线程操作，可支持多个客户端连接的同时访问，Client客户端程序被用于和Server进行通信以修改服务器端Server管理的数据库信息。二者进行交互时使用的通信协议如下：

• TCP/IP协议
• Unix Socket(不同主机）
• 共享内存（相同主机）
• 管道

关系型数据库与非关系型数据库

  关系型数据库：是指采用了关系模型（二维表格模型）来组织数据得数据库，也就是由二维表及其之间的联系所组成的一个数据组织。
  关系模型中的常用概念：

• 关系：一张二维表，每个关系具有一个关系名，也就是表名；
• 元组：二维表中的一行，在数据库中被称为记录；
• 属性：二维表中的一行，在数据库中被称为字段；
• 域：属性的取值范围，也就是数据库中某一列值的取值范围；
• 关键字：一组可以唯一标识元组的属性，数据库中常称为主键，由一个或多个列构成；
• 关系模式：指这对关系的描述，其格式为：关系名（属性1、属性2、····、属性N），在数据库中称为表结构。

  关系型数据库的优点：

• 使用方便：关系型数据库通常使用SQL语言使得操作关系型数据库非常方便；
• 容易理解：二维表结构是非常贴近逻辑世界的概念，关系模型相对网状和层次等模型来说更易被理解；
• 易于维护：丰富的完整性（实体完整性、参照完整性和用户自定义完整性）大大减低了数据冗余和数据不一致的概率。

  数据库事务必须具备ACID特性：分别指Atomic原子性，Consistency一致性，Lsolation隔离性，Durability持久性。

  非关系型数据库：又被称为NoSQL（Not Only SQL），指非关系型，分布式数据库，且不能保证遵循ACID原则的数据存储系统，其内部存储依靠键值对<Key，Value>存储，且结构不固定，每一个元组可有不一样的字段，不局限于固定的结构，可根据需要增加键值对。

  关系型数据库和非关系型数据库的比较：

• 查询速度：NoSQL数据库将数据存储与缓存中，不需要经过SQL层解析，而关系型数据库将数据存储在硬盘内，因此查询速度会比NoSQL慢；
• 数据存储格式：NoSQL内部存储除了键值对<Key，Value>形式，还有文档、图片等，可以存储基础类型及对象或者是集合的形式，二关系型数据库只能存储基础类型；
• 扩展性：关系型数据库类似join这样的多表查询机制的限制从而导致难以扩展，而NoSQL是基于键值对，数据间没有耦合性，所以较容易扩展；
• 持久存储：NoSQL不使用持久存储，大量数据的存储还需要使用关系型数据库；
• 成本：NoSQL数据库部署简单，且软件位开源，不需要时延Oracle花费大量成本购买使用，相较关系型数据库价格便宜；
• 数据一致性：NoSQL一般强调的是数据最终一致性，不必像关系型数据库强调数据强一致性，从NoSQL中读到的可能是处于中间态的数据，且不提供对事物处理。

数据库范式设计

  为了建立冗余小、结构合理的数据库，设计数据库需要遵循一定的规则，在关系型数据库我们将这种规则称为范式。范式是符合某一中设计要求的总结，要想设计一个结构合理的关系型数据库，需要满足一定的范式。通俗来说范式可理解为一张数据表的表结构所符合的某种设计标准的级别，例如装修的建材，最环保的是E0级别，然后是E1、E2级别等。
  关系数据库有六种范式：第一范式（1NF），第二范式（2NF），第三范式（3NF），巴德斯科范式（BCNF)，第四范式（4NF）和第五范式（5NF）。
  满足最低要求的范式为第一范式，在第一范式的基础上进一步满足更多要求的为第二范式，以此类推，一般的数据库只需满足第三范式（3NF）。越高范式数据库的冗余度越低。但也不能说数据库范式越高越好，范式越高意味表越多，多表联合查询的机率越大，SQL语句效率就会变低。
  范式的设计优点：

• 减少数据冗余
• 消除异常（插入、更新、删除）
• 让数据组织更有逻辑性

范式的基本概念

  关键码与属性：

• 候选码和主码：表中可唯一确定一个元组的某个属性（或属性组）称作候选码，我们从许多个候选码中挑一个为主码；
• 全码：如果一个码包含了所有属性，这个码就叫全码；
• 主属性：一个属性只要在任何一个候选码中出现过，这个属性就称为主属性；
• 非主属性：与上相反，没有在任何候选码中出现过的属性就是非主属性；
• 外码：一个属性（或属性组），它不是码，但是别的表的码，也就是外码。

 函数依赖：
  设R(U)是一个属性集U 上的关系模式，X和Y是U的子集，若对于R(U)的任意两个可能的具体关系r1、r2,若r1[x] == r2[x] 则r1[y] == r2[y]，或者若r1[x] != r2[x]则r1[y] != r2[y]，称X决定Y，或者Y函数依赖于X，记作X->Y,就像我们学过的函数一样，给一个确定的输入（属性集X），就会有一个确定的输出（属性集Y）。

  部份依赖：设X，Y是关系R上的两个属性集合，存在X→Y，若X‘ 是X的真子集，且存在X’ →Y，则称Y部份依赖与于X。
  示例：学生基本信息表R中（学号，身份证号，姓名），学号的属性取值唯一，在R关系中，（学号，身份证号）→（姓名），（学号）→（姓名），（身份证号）→（姓名），因此姓名部分依赖于（学号，身份证号）。
  完全依赖：设X,Y是关系R的两个属性集合，若X‘ 是X的真子集，且存在X →Y，但对每一个X’ 都有 X’ !→ Y，则称Y完全依赖于X。
  示例：学生基本信息表R中（学号，班级，姓名）假设不同班级中有相同的学号，班级内的学号不能相同，则在R关系中（学号，班级）→（姓名），但（学号）→（姓名）不成立，（班级）→（姓名）不成立，所以姓名完全函数依赖于（学号，班级）。
  传递依赖：设X，Y，Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递依赖于X。
  示例：在关系R（学号，宿舍，用电量）中，（学号）→（宿舍），（宿舍）!→（学号），（宿舍）→（用电量），则符合传递依赖。

  函数依赖和属性的关系：

• 如果X和Y之间是一对一（1:1）关系，如学校和校长，则存在函数依赖X→Y和Y→X。
• 如果X和Y之间是一对多（1:n）关系，如年龄和姓名，则存在函数依赖Y→X。
• 如果X和Y之间是多对多（m:n）关系，如学生和课程，则X和Y之间不存在函数依赖。

第一范式（1NF）：每一列保持原子性

  符合1NF的关系，（“关系模式”和”关系“的区别就像类和对象的区别，“关系”是“关系模式“的实例，”关系“可理解为带数据的表，而”关系模式”就是这张表结构）,第一范式的定义为：符合1NF的关系中每个属性不可再分，下图即不符合1NF的要求：

  1NF是所有关系型数据库中最基本的要求，若不满足则不是关系型数据库。但第一范式仍存在大量的数据冗余、插入异常、删除异常和更新异常，因此我们引入第二范式。

第二范式（2NF）：属性完全依赖主键

  首先要说明的是满足第二范式必须先满足第一范式。其次第二范式要求数据表每一个实例或者行中必须被唯一标识：

• 表中必须有一个主键；
• 没有包含在主键中的列必须完全依赖与主键，而不能只依赖主键的部分。
    我们可理解为每行属于只能与其中一列有关，当主码确定后该表中的其他列也会随之被确定，如果数据表中是联合主键，但有的列只依赖联合主键中的一个或一部分属性组成的联合主键我们则需要对表进行拆分，使其满足第二范式。如下所示：

学号	姓名	年龄	课程名称	成绩	学分

  上表中的联合主键为（学号，课程名称），学分只与课程名称有关，与学号无关，即只依赖于联合主键的一个字段不满足第二范式。因此会存在：

• 数据冗余：每条记录会有相同的信息；
• 删除异常：删除所有学生成绩，就把课程信息删除了；
• 插入异常：学生未选课，则无法记录进数据库；
• 更新异常：调整课程学分，所有的行都需要调整。

 我们需要将其拆分使其满足第二范式，将 （学号，课程名称，成绩）划分为选课关系表，将（课程名称，学分）划为课程信息表：
  学生：Student（学号，姓名，年龄）
  课程：Course（课程名称，学分）
  选课关系：StudentCourse（学号、课程名称、成绩）

第三范式（3NF）：属性不依赖于其他属性

  某一范式位第二范式，且每一个非主属性不能传递依赖于该范式的候选键，称为第三范式。如下例：

员工id	姓名	年龄	Email	部门id	部门名称	部门电话

  上表中员工id可唯一确定员工信息，但部门id可确定部门名称和部门电话，则部门信息传递依赖于员工id，因此不满足第三范式，如若想满足第三范式同样我们要对表进行拆分：
员工表

员工id	姓名	年龄	Email	部门id

部门信息表

部门id	部门名称	部门电话

  一般来说数据库只需满足第三范式就足够了。

  总结：

• 第一范式：列不可再分；
• 第二范式：在第一范式的基础上，消除部分依赖；
• 第三范式：建立在第二范式的基础上，消除传递依赖。

巴德科斯范式（BCNF)：每个表中只有一个候选键

  BCNF是在第三范式的基础上消除了主属性对码的部分和传递函数依赖，也就是第三范式的一种特殊情况，即每个表中只有一个候选键，在上面第三范式的员工表中，每个员工的Email都唯一，所以此表存在多个候选键（员工id，Email），此时存在关键字决定关键字的情况，不符合BCFN范式，因此我们需要将表拆分成：
员工表

员工id	姓名	年龄	部门id

Emali

Email	员工id

  这样也就进一步消除了主属性的部分和传递依赖。

如有不懂可看：如何理解关系型数据库的常见设计范式