1. 范式
    1. 1NF: 表中的任何属性都是原子性的, 不可再分.
    2. 2NF: 1NF + 数据表中的非主属性, 都与数据表中的候选键有完全依赖关系.
    3. 3NF: 2NF + 对任何非主属性都不传递依赖于候选键.
    4. BCNF(巴斯 - 科德范式): 它在 3NF 的基础上消除了主属性对候选键的部分依赖或者传递依赖关系。
    5. 4NF: 知道名字即可
    6. 5NF(第五范式又称完美范式): 知道名字即可
  2. 键: 数据库中的键由一个或多个属性组成
    1. 超键: 能唯一标识元组的属性集
    2. 候选键(码): 如果超键不包括多余的属性, 那这个超键就是候选键(不带冗余)
    3. 主键(主码): 候选键中选的一个
    4. 外键: 如果数据表R1中的某属性集不是R1的主键, 但是另一个数据表R2的主键, 那么这个属性集就是R1 的外键. (是否使用外键, 业界有巨大争议, 阿里要求表的数据一致性不由外键而是由应用程序保证)
    5. 主属性: 包含在任一候选键中的属性
    6. 非主属性: 与主属性相对, 不包含在任意一个候选键内的属性
  3. 问题
    1. 范式等级越高，设计出来的数据表就越多，进行数据查询的时候就可能需要关联多张表，从而影响查询效率。
    2. 范式本身存在一些问题，可能会带来插入，更新，删除等的异常情况, (现实使用中的异常, 并不是数据库本身的问题, 比如: 新建仓库, 但是没放任何物品, 而数据库某表主键是仓库名+物品名, 主键不为空, 那么就因为设计问题, 没法插入空的仓库数据, 必须要要求仓库有物品, 与现实情况冲突)
  4. 反范式优化: 空间换时间, 当冗余信息有价值或者能大幅度提高查询效率的时候, 我们就可以采取反范式的优化
  5. 数据仓库: 因为数据仓库通常存储历史数据，对增删改的实时性要求不强，对历史数据的分析需求强。这时适当允许数据的冗余度，更方便进行数据分析。
  6. 数据库与数据仓库比较:
    1. 数据库设计的目的在于捕获数据，而数据仓库设计的目的在于分析数据
    2. 数据库对数据的增删改实时性要求强，需要存储在线的用户数据，而数据仓库存储的一般是历史数据
    3. 数据库设计需要尽量避免冗余，但为了提高查询效率也允许一定的冗余度，而数据仓库在设计上更偏向采用反范式设计