Raymond's Cabin

for sharing thoughts

0%

数据库基础

Posted on Valine:

我们平日里说得很多的数据库，指的是能够以一定方式（数据结构）去组织、储存在一起，能为多个用户共享，具有尽可能小的冗余度，并且能够与应用程序彼此独立的数据集合。

每个数据库都有一个或多个不同的 API 用于创建、访问、管理、搜索和复制所保存的数据。

数据库表

一个数据库通常包含有一个或者多个表

  • 表是一种数据结构，是相关数据项的集合，由列和行组成
  • 每一个表由一个名字标识（如“客户”、“订单”）
  • 表中包含若干带有数据的记录（也称为行）
    • 数据库每一列都有列名
    • 每一行包含一个相关的数据集

数据库相关的基本概念

实体

  • 在现实世界中客观存在的，并且可以相互区分的对象或事物
  • 如：“公司”、“项目”、“员工”

属性

  • 实体所具有的某一属性
  • 如：“公司名”、“地址”等都是实体“公司”的属性

主键，也称码

  • 表中可以唯一确定一行数据的某个属性（或属性组）
  • 如 [员工号]、[员工号, 绩效评定月份]
  • 不同的表结构，对应的码不同

主属性

  • 包含在任何一个码中的属性都是主属性
  • 如上例的“员工号”“绩效评定月份”便是主属性

非主属性

  • 与主属性相反
  • 没有在任何候选码中出现过的属性便是非主属性

另：

  • 数据表：数据的矩阵，表面上看是一张电子表格
  • 列：一列（数据元素）包含相同类型的数据
  • 行：一条记录，即一组相关的数据
  • 冗余：存储两倍数据，可使系统速度更快
  • 外键：关联两张表的标识
  • 复合键：将多个列作为一个索引
  • 索引：对数据表中一列或多列的值进行排序的结构，类似于目录
  • 参照完整性：要求关系中不允许引用不存在的实体；与实体完整性时关系模型必须满足的完整性约束条件

关系型数据库

指的是采用了关系模型（二维表格模型）来组织数据的数据库。

优点：

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

关系型数据库管理系统（Relational Database Management System, RDBMS），是 SQL 的基础，也是所有现代数据库系统的基础。
市面上流行的所有数据库系统，包括 MS Access, SQL Server, IBM DB2, MySQL 等等，都是基于 RDBMS 来开发的。

关系型数据库中数据表的关系

函数依赖

在一张表中，如果在属性（或属性组）X 完全确定时，必定能确定属性 Y 的值

  • 那么在该数据表中，不会存在任意两条记录，它们在 X 属性（或属性组）上的值相同，而在 Y 属性上的值不同
  • 即 Y 函数依赖于 X，X → Y，X 与 Y 一一对应

完全函数依赖

如存在 X → Y，且：

  • 对 X 任意一个真子集 X’，都不存在 X‘ → Y，则 X → Y 是一个完全函数依赖
  • 非正式记法：X >> Y

部分函数依赖

如存在 X → Y，且：

  • 在 X 中存在一个真子集 X’，使 X‘ → Y，则 X → Y 是一个部分函数依赖
  • 非正式记法：X > Y

传递函数依赖

  • 如果 X → Y，Y → Z，且 Y 不属于 X，Y → X 不成立
    • 称 Z 传递函数依赖于 X
    • 非正式记法：X >>> Z
  • 如 Y 属于 X，则 Z 部分传递函数依赖于 X

范式（normalization）

范式（normal form, NF）：符合某一种级别的关系模式的集合，表达一个关系内部个属性之间的联系的合理化程度。

关系型数据库范式：

第一范式（1NF，1971）

  • 数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值
    • 即：实体中某个属性不能有多个值或不能有重复属性
    • 对属性的原子性约束，具有原子性，不可再分解
    • 不能是集合、数组、记录等非原子数据项
    • 简而言之：没有重复的列
  • 所有关系型数据库的最基本要求
  • 符合 1NF 的关系中的每个属性都不可再分（属性的原子性）

第二范式（2NF，1971）：消除了非主属性对于主键（码）的部分函数依赖

  • 在满足 1NF 的基础上，表中非 key 属性完全依赖于主键
    • 对记录的唯一性约束，要求记录（实体）有唯一性
    • 指不能存在仅依赖 key 一部分的属性
    • 如存在：这个属性和 key 的这一部分应该分离出来形成新的实体
    • 新实体和原实体是一对多的关系
  • 数据库表中每个实例或记录必须可以被唯一地拆分
    • 选出一个能区分每个实体的属性或属性组，作为实体的唯一标识

2NF 的例子：

  • 某一表中的字段：学号、课程号、姓名、学分
  • 学分依赖于课程号，姓名依赖于学号：不符合第二范式
  • 可根据{课程号, 学分}分成一张表，{学号, 姓名}分成另一张表
    • 由此便中断了原表中数据的联系
    • 解决方法：{学号, 课程号}分一张表

第三范式（3NF，1971）：消除了非主属性对于主键的传递函数依赖（间接相关）

  • 对字段冗余性的约束
  • 确保表中各列与主键列直接相关（直接依赖关系），而不是间接相关
    • 任何字段不能由其他字段派生出来，要求字段没有冗余

此外还有 4NF，5NF（完美范式），6NF 等，但是对于绝大多数场景的数据库设计来说，能做到 3NF 已经基本足够。

优缺点

范式的优点：

  • 范式化的数据库更新起来更快
  • 范式化之后，只有很少的重复数据，只需要修改更少的数据
  • 范式化的表更小，可在内存中执行
  • 很少的冗余数据，在查询时需要更少的 distinct 或 group by 语句

范式的缺点：

  • 范式化的表在查询时经常需要很多关联：因为单独一个表内不存在冗余数据和重复数据
    • 导致稍微复杂一些的查询语句在查询范式的 schema 上可能需要多次关联
    • 增加查询的代价，可能使一些索引策略无效

反范式

没有冗余的数据库未必是最好的数据库；有时为了提高运行效率，必须降低范式标准，适当保留冗余数据。

我们可以通过在表中增加冗余或重复的数据提高数据库读写性能：

  • 概念数据模型设计时：遵守第三范式
  • 物理数据模型设计时：降低范式标准
    • 增加字段，减少查询时的关联，提高效率

反范式的优点：

  • 避免关联：因为所有的数据几乎都可在一张表上显示
  • 可设计有效的索引

反范式的缺点：

  • 表格内冗余较多，删除数据时会造成表有些有用的信息丢失；
  • 因此反范式一定要适度

实际的应用往往是混用范式和反范式。