MySQL-103

[TOC]

基础知识

范式的作用:解决如何建表,建几张表的问题。

一个好的设计模式,应该不会发生插入异常/删除异常/更新异常,数据冗余也应该尽可能的少。

关系模式三元组:$R$ U: 属性组,属性集合,F: U 上的函数依赖

函数依赖

  • 学号 —> 姓名,姓名依赖于学号,姓名也完全取决于学号,所以姓名完全函数依赖于学号。姓名 = f(学号)

  • (学号,性别) —> 姓名,姓名依赖于(学号,性别) ,但是姓名并不是完全依赖于学号与性别,姓名只是对学号和性别部分函数依赖

  • X —> Y Y —> Z : X —> Z,Z 对 X 传递函数依赖

候选码 / 主码 / 主属性 / 外码

一组能唯一确定一条元组的属性集合。如果候选码不止一个,那么则选定其中的一个为主码Primary Key)。

主码中的属性称为主属性

如果一个属性或者属性组 X 并非 关系模式R 的码,但 X 是另一个关系模式(一张表就是一个关系模式)的码,那么则称 X 是 R 的外码(外键)。

关系模式经常存在的问题

一张错误的关系模式
  • 数据冗余(系主任存储冗余)

  • 更新异常(数据冗余导致更新表的时候带来债务,例如更换系主任时,必须修改每一条学生数据)

  • 插入异常(如果一个系刚成立,没有学生,就无法将该系及其系主任的信息存入数据库)

  • 删除异常(删除学生的时候,会把系和系主任也删除了)

范式

范式:符合某一种级别的关系模式的集合。

范式

第一范式:每一个属性都是不可分的数据项。

第二范式:若 R 属于 1NF,且每一个非主属性完全函数依赖于码,则 R 属于 2NF。一个关系模式(表)不属于 2NF,会产生 插入异常,修改异常,删除异常等问题。

满足第二范式的关系模式

第三范式:每一个非主属性,既不部分依赖于码,也不传递依赖于码。图6.5的关系模式,由于存在传递函数依赖,所以需要将其拆开。

注意:并不是规范化程度越高,关系就越优,当查询设计到多表查询时,连接运算会导致查询效率降低。有时候,第二范式,甚至第一范式,是比较折中的选择

数据库恢复技术 / Transaction

Transaction

Transaction:用户定义的一个数据库操作脚本,这些操作要么全做要么全不做,是一个原子操作。在关系型数据库中,一个事务可以是一条 SQL语句或一个存储过程。

Transaction 举例:从账户 A 中取出一万元,存入账户 B。需要定义一个 transaction,包含两个操作,从 A 中减去一万元,然后想 B 中加入一万元。

Transaction 的三个命令

  • begin transaction

  • commit:提交事务的所有操作,将事务中所有对数据库的更新写入磁盘,事务正常结束

  • rollback:撤销事务的执行,回滚到初始状态

Transaction 的四大特性:ACID

  • 原子性(Atomicity)

  • 一致性(Consistency):事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态

  • 隔离性(Isolation):一个事务的隔离并不会被其他事务干扰

  • 持续性(Durability):transaction 一旦提交,其改变就应该是持久性的

多个事务交叉运行,需要数据库管理系统拥有并发控制机制,一个事务被迫中断,则需要 DBMS 拥有中断恢复机制

恢复技术

事务意外中断在所难免,那么如何进行现场的恢复?

恢复的原理:冗余。(数据备份和日志)