关系数据库设计

好的关系设计的特点

设计选择

  • 更大的模式 比如department模式与student模式进行合并,得到两个模式的连接结果dept_stu 问题:

    • 数据冗余
    • 有些情况无法表示
  • 更小的模式: 如何发现一个模式需要分解成n个更小的模式? 函数依赖 定义这样的一条规则:如果存在模式(dept_name,budget),则dept_name可以作为主码,那么这就叫函数依赖 记作:x → y 有损分解 :分解过后无法表达一些重要的信息。 无损分解 :上面取反

异常

不符合范式的关系

  • 冗余数据
  • 修改异常
  • 删除异常
  • 插入异常

原子域与第一范式

一个域是原子的,如果该域的元素被认为是不可分的单元,我们称一个关系模式R属于第一范式。 简单来说:所有关系模式数据库都符合第一范式

第二范式

每个非主属性完全函数依赖于键码

使用函数依赖进行分解

码和函数依赖

一个关系满足需求定义的现实世界约束,称为关系的合法实例

  • 给定R的一个实例,我们说这个实例满足函数依赖x → y 的条件是:对于实例中的所有元组t1,t2 ,若t1[x] = t1[x] ,则t1[y] = t2[y]
  • 如果R中的每个合法实例都满足函数依赖,则我们说该函数依赖在R上成立 我们以两种方式使用函数依赖:
  • 判定关系的实例是否满足给定函数依赖集F
  • 说明合法关系集上的约束 平凡函数依赖 :如果y ⊆ x,则称x→y的函数依赖是平凡的 我们用F + 表达F集合的闭包,也就是能够从给定F集合推导出来的函数依赖集合

BC范式

属于BC范式的条件是: 对于F + 中所有形如a→b的函数依赖(a ⊆ R,b⊆R ),下面至少有一项成立:

  • a → b是平凡的函数依赖(b ⊆ a)
  • a是模式R的一个超码 分解不属于BCNF的一般规则: 设R为一个不属于BCNF的一个模式,则存在至少一个非平凡的函数依赖a→b,其中a不是R的超码,我们用两个模式取代R:
  • (a ∪ b)
  • (R - (b - a )) 进行迭代直到得到一个BCNF模式集合

BCNF和保持依赖

由于设计使得函数依赖的强制实施在计算很困难,因此称这个设计不是保持依赖的

第三范式

属于第三范式的条件,下面至少一项成立:

  • a → b是一个平凡的函数依赖
  • a 是R的一个超码
  • b - a的每个属性都包含于R的一个候选码中

函数依赖理论

函数依赖集的闭包

逻辑蕴含: A -> B,B-> h 那么 A -> H被逻辑蕴含

Amstrong 公理

  • 自反律
  • 增补律
  • 传递律
  • 合并律
  • 分解律
  • 伪传递律

属性集的闭包

如果 a → B,我们称属性B被a函数确定

正则覆盖

无损分解

R1,R2是R的分解,如果用R1,R2替代R没有信息损失,则该分解是无损分解

保持依赖

分解算法

BCNF分解

3NF分解

BCNF和3NF的比较

应用函数依赖进行数据库设计的目标:

  • BCNF
  • 无损
  • 保持依赖

使用多值依赖的分解

多值依赖

函数依赖有时成为 相等依赖 多值依赖成为 元组产生依赖 设R为关系模式,让a ⊆ R 且 b ⊆ R 多值依赖 a -> -> b在R上成立的条件是:

4NF分解

更多的范式

数据库设计过程

ER模型和规范化

属性和联系的命名

为性能去规范化

时态数据建模

时态数据时具有关联时间段的数据 快照 快照是指一个特定时间点上该数据的值

一些坑

  • 没有唯一键约束

业务上具有唯一特性的字段,即使是多个字段的组合,也必须建成唯一索引

如果没有唯一索引,很容易会被插入重复数据

  • 执行delete没带查询条件

执行删除操作时,要开启事务,同时要先查询核对影响的行数和数据准确性,再执行删除操作 ;执行删除操作后再次核实,如果情况不对立即回滚

  • 表结构修改没有兼容老数据

比如增加了一个非null字段

  • 时效性要求极高的场景查了备库

备库存放的数据可能不是最新的数据

  • 悬停时间较长的事务被kill
  • 表新增了供查询的字段,却没建索引,导致慢查询

results matching " "

No results matching " "

results matching " "

No results matching " "