系统原理-范式

一、函数依赖

记 A->B 表示 A 函数决定 B,也可以说 B 函数依赖于 A。

如果 {A1,A2,... ,An} 是关系的一个或多个属性的集合,该集合函数决定了关系的其它所有属性并且是最小的,那么该集合就称为键码。

对于 A->B,如果能找到 A 的真子集 A',使得 A'-> B,那么 A->B 就是部分函数依赖,否则就是完全函数依赖。

对于 A->B,B->C,则 A->C 是一个传递函数依赖。

二、范式

高级别范式依赖于低级别范式

  1. 第一范式(1NF):属性不可分
  2. 第二范式(2NF):每个非主属性完全依赖于键码。
  3. 第三范式(3NF):非主属性不传递依赖于键码

三、特点

  • 在范式化的数据库中,每个事实数据会出现并且只出现一次。
  • 在反范式化的数据库中,信息是冗余的,可能会存储在多个地方。

范式的优点

当为性能问题寻求帮助时,常会被建议对schema进行范式化设计,尤其是写密集的场景。

  • 范式化的更新操作通常比反范式快。
  • 当数据较好地范式化时,就只有很少或者没有重复数据,所以只需要修改更少的数据。
  • 范式化的表通常更小,可以更好地放在内存里,所以执行操作会更快。
  • 很少有多余的数据意味着检索列表数据时更少需要DISTINCT或者GROUP BY语句。
范式的缺点
  • 通常需要关联。稍微复杂一些的查询语句在符合范式的schema上都可能需要至少一次关联,也许更多。
    • 代价昂贵
    • 可能使一些索引策略无效。如,范式化可能将列存放在不同的表中,而这些列如果在一个表中本可以属于同一个索引。

反范式的优点
  • 所有数据都在一张表中,可以很好地避免关联。大部分查询最差情况是全表扫描。当数据比内存大时,这可能比关联要快得多,因为这样避免了随机IO。全表扫描基本上是顺序IO,跟引擎的实现有关。
  • 能使用更有效的索引策略。
反范式的缺点
  • 冗余数据
  • 修改异常:修改了一个记录中的信息,但是另一个记录中相同的信息却没有被修改。
  • 删除异常:删除一个信息,那么也会丢失其它信息。
  • 插入异常:缺少属性,无法加入
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。