模式是描述数据库的一种方式，用于说明数据库中有哪些表，表有那些列，通过这些结构，设计出一个符合功能需求的数据库结构。
在设计中，往往需要考虑如何将实际的需求进行抽象转化，尽量避免冗余和错误的关系模型模式，这就是数据库逻辑设计问题。
问题主要有以下几种，为了有效系统解决这些问题提出了规范化理论
首先第一个部分是数据依赖关系：定义见图片
首先是函数依赖，函数依赖我觉得更合适应该是称为映射依赖，这个依赖表现了数据库中各个属性间一对一联系关系，一个属性映射到另一组属性的一种关系。
他强调这个映射需要像函数一样，相同的自变量总是要映射到相同的应变量上。
完全或部分 函数依赖
解读一下：
X是个集合，如果只有X中所有元素一起做映射，才能映射到Y上，取出子集的话就没有这种映射关系了，说明是Y完全函数依赖X。（只有通过所有的X才能映射到Y）
反之如果X的子集也可以映射到Y，则是部分函数依赖
属性满足了函数依赖规则，可以根据对相互依赖之间这些属性的关系进行一个分类。
"基于唯一属性（主键）的完全依赖"
关系中的某些唯一的属性或其组合可被整个关系所完全依赖
通过所有这些唯一的属性，就可以映射到整个关系的一行
那么如果这个映射关系的应变量自变量不在一个表上那么称之为外来键。
了解了函数依赖属性后，接下来可以学习范式了
范式就是通过不同种类的函数依赖，属性约束等构建起的规则，数据库结构的设计必须要满足这些规则，才具备范式的属性
数据库范式的设计：
1NF, Normal form
"所有属性不可分"
2NF
"一个候选键连到所有非主键"
例子
寻找其中的所有函数依赖关系，然后将表格进行分解，分解成小的几个表，从而满足这一规则
3NF
"没有依赖到非主属性的传递函数依赖"
传递依赖就是在一个关系中，主键A 依赖 主键B，主键B依赖非主键C 同时 主键A也依赖非主键C。
依赖存在一个"短路"的情况
3NF就是不允许这种规则发生
分解方法
"分解再重组，将存在传递的组分离到不同的关系中去"
BCNF
"所有函数依赖关系中，自变量皆含有一个及以上的候选键"
码即为主键
分解方法
多值依赖
在X值相等的情况下 可以导出不同的Y Z 值对
上面这个表格中，X可以导出不同的Y值，Y值之后也到导出了不同的Z值
但是更具体的定义是：
对R的任一个关系r，r在(X,Z)上的每个值对应一组Y的值，这组值仅仅决定于X值而与Z值无关。
反过来也可以 X Y对应， 而Z可以随便的变化
把没有直接联系、但有间接的联系称为多值依赖的数据依赖。
如以下这个这个表，课程 数学仅能对应到教师 邓军，邓军这门课却可以使用多种参考书，这是由邓军决定的，和数学无关，数学只能映射到邓军。
而且当且仅当映射到了邓军之后，邓军又能选各种不同（大于1）的参考书，这样才满足多值依赖，不然只是简单的函数依赖（多值依赖的退化版）
