? 何为关系模式？ 1.关系的描述称为关系模式（RelationSchema） 2.它可以形式化地表示为：R（U，D，dom，F），其中R为关系名，U为组成该关系的属性名集合，D为属性组U中属性所来自的域，dom为属性向域的映象集合，F为属性间数据的依赖关系集合。 3.通常简记
1.关系的描述称为关系模式（RelationSchema）
2.它可以形式化地表示为：R（U，D，dom，F），其中R为关系名，U为组成该关系的属性名集合，D为属性组U中属性所来自的域，dom为属性向域的映象集合，F为属性间数据的依赖关系集合。
3.通常简记为：R(U)或R(A1，A2，…,An)
4.其中R为关系名，U为属性名集合，A1，A2，…,An为各属性名。
关系模式的好坏有一定的衡量标准，而这个标准就是模式的范式（Normal Forms，简称为NF），范式的种类与数据依赖有着直接的联系，基于FD即函数依赖（functional dependency，简称FD）的范式有1NF、2NF、3NF、BCNF等等，下面重点介绍前三种。
（范式，数据库设计范式，数据库的设计范式）是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则。在关系数据库中，这种规则就是范式。关系数据库中的关系必须满足一定的要求，即满足不同的范式。
如果关系模式R的每个关系r的属性值都是不可分的原子值，也就是说数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。
例如：这种数据库表是符合第一范式的
然而这种的数据库表是不符合第一范式的
1.如果关系模式R是1NF，且每个非主属性完全函数依赖于候选键，那么称R是第二范式。
2.也就是说第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。
3.第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之，第二范式就是属性完全依赖于主键。
4.不符合第二范式带来的影响是出现数据冗余、删除异常、更新异常、插入异常等等。
例如：一个订单的表
从这个图上我们可以看出这个表是有问题的，因为这个表是以订单编号和产品编号为联合主键的，这样就会出现问题，问题就是产品的价格只是与产品编号有关，订购日期只是与订单编号有关，故而违背了第二范式的设计原则，应该将其拆分如下图：
订单信息：
产品信息：
这样设计，在很大程度上减小了数据库的冗余。如果要获取订单的信息，使用订单编号到订单信息表中查询即可。
a)如果关系模式R是1NF，且每个非主属性都不传递依赖于R的候选键。
b)也就是说满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。
c)再进一步在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C传递函数依赖于A。因此，满足第三范式的数据库表应该不存在如下依赖关系： 关键字段 → 非关键字段x → 非关键字段y
举例：同样是订单表
这样把客户信息和产品信息放入一个表中，在查询时就得输入客户的全部信息，那么就会造成数据的冗余，如果将其拆分，分类之后就会减少数据的冗余。
订单信息表：
顾客信息表：
这样在查询订单信息的时候，就可以使用顾客编号来引用顾客信息表中的记录，也不必在订单信息表中多次输入顾客信息的内容，减小了数据冗余。
1.满足1NF的关系为规范化的关系，否则为非规范化的关系。
2.规范化的本质是提高数据独立性，解决插入异常、删除异常、修改复杂、数据冗余等问题的方法。
3.规范化的基本思想是逐步消除数据依赖中不适合的部分。
(一) 第一范式目标（1NF）：确保每列的原子性。
(二) 第二范式目标（2NF）：确保表中的每列，都和主键有关。
(三) 第三范式目标（3NF）：确保每列都和主键列直接相关，而不是间接相关。
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
