mysql设计关系模式_数据库 关系模式 学习笔记

模式是描述数据库的一种方式，用于说明数据库中有哪些表，表有那些列，通过这些结构，设计出一个符合功能需求的数据库结构。

在设计中，往往需要考虑如何将实际的需求进行抽象转化，尽量避免冗余和错误的关系模型模式，这就是数据库逻辑设计问题。

问题主要有以下几种，为了有效系统解决这些问题提出了规范化理论

首先第一个部分是数据依赖关系：定义见图片

首先是函数依赖，函数依赖我觉得更合适应该是称为映射依赖，这个依赖表现了数据库中各个属性间一对一联系关系，一个属性映射到另一组属性的一种关系。

他强调这个映射需要像函数一样，相同的自变量总是要映射到相同的应变量上。

完全或部分 函数依赖

解读一下：

X是个集合，如果只有X中所有元素一起做映射，才能映射到Y上，取出子集的话就没有这种映射关系了，说明是Y完全函数依赖X。(只有通过所有的X才能映射到Y)

反之如果X的子集也可以映射到Y，则是部分函数依赖

属性满足了函数依赖规则，可以根据对相互依赖之间这些属性的关系进行一个分类。

"基于唯一属性(主键)的完全依赖"

关系中的某些唯一的属性或其组合可被整个关系所完全依赖

通过所有这些唯一的属性，就可以映射到整个关系的一行

那么如果这个映射关系的应变量自变量不在一个表上那么称之为外来键。

了解了函数依赖属性后，接下来可以学习范式了

范式就是通过不同种类的函数依赖，属性约束等构建起的规则，数据库结构的设计必须要满足这些规则，才具备范式的属性

数据库范式的设计：

1NF, Normal form

"所有属性不可分"

2NF

"一个候选键连到所有非主键"

第二范式(2NF)是在第一范式(1NF)的基础上建立起来的，即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。例如员工信息表中加上了员工编号(emp_id)列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。

第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之，第二范式就是属性完全依赖于主键。

例子

寻找其中的所有函数依赖关系，然后将表格进行分解，分解成小的几个表，从而满足这一规则

3NF

"没有依赖到非主属性的传递函数依赖"

传递依赖就是在一个关系中，主键A 依赖 主键B，主键B依赖非主键C 同时 主键A也依赖非主键C。

依赖存在一个"短路"的情况

3NF就是不允许这种规则发生

简而言之，第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式(3NF)也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。

分解方法

"分解再重组，将存在传递的组分离到不同的关系中去"

BCNF

"所有函数依赖关系中，自变量皆含有一个及以上的候选键"

码即为主键

分解方法

多值依赖

在X值相等的情况下 可以导出不同的Y Z 值对

上面这个表格中，X可以导出不同的Y值，Y值之后也到导出了不同的Z值

但是更具体的定义是：

对R的任一个关系r，r在(X,Z)上的每个值对应一组Y的值，这组值仅仅决定于X值而与Z值无关。

反过来也可以 X Y对应， 而Z可以随便的变化

把没有直接联系、但有间接的联系称为多值依赖的数据依赖。

如以下这个这个表，课程 数学仅能对应到教师 邓军，邓军这门课却可以使用多种参考书，这是由邓军决定的，和数学无关，数学只能映射到邓军。

而且当且仅当映射到了邓军之后，邓军又能选各种不同(大于1)的参考书，这样才满足多值依赖，不然只是简单的函数依赖(多值依赖的退化版)