数据库函数依赖范式

1. 函数依赖和范式是如何被逐渐认识和发展起来的

函数依赖和范式是数据库设计中的重要概念，它们的发展历程可以概括为以下几个阶段：

• 初始阶段

在数据库诞生的早期，数据被存储在文件中，没有数据模型或规范可言。随着数据库行旅的出现，人们开始探索如何组织数据以便于查询和管理。此时，人们主要使用实体-关系图（ERD）和层次模型来描述数据库中的数据结构，但是这些模型没有提供规范的方法来消除冗余数据或确保数据的一致性。

• 函数依赖理论的出现

20世纪60年代，数据库研究者开始探索如何减少数据冗余并确保数据的一致性。这个时期，E.F. Codd提出了关系模型的概念，他在1970年发表的一篇论文中详细描述了关系模档旁凳型和关系数据库的基本概念。Codd提出了函数依赖的概念，指出在一个关系中，某些属性的值可以通过其他属性的值推导出来。他还提出了第一范式的概念，要求关系中的每个属性都是原子的，启皮即不可再分。

• 范式理论的发展

在函数依赖理论的基础上，出现了更多的范式，包括第二范式、第三范式、BCNF范式等。这些范式描述了关系中的数据如何消除冗余和保持一致性。它们提供了规范的方法来设计和优化数据库模式，使得数据库更容易维护和查询。

• 实践中的应用

范式理论在数据库设计和优化中得到了广泛应用。在实践中，设计人员可以根据数据的特点和使用场景选择适当的范式，以便在不同的方面取得最佳性能。例如，第三范式适用于数据具有大量重复的情况，而BCNF范式适用于多对多关系的情况。

总之，函数依赖和范式是数据库设计中的重要概念，它们的发展历程可以追溯到数据库出现的早期。通过函数依赖理论和范式理论，人们可以更好地组织和优化数据库中的数据，以便于管理和查询。

2. 数据库范式问题！！

数据库中的范式问题．理论和时间要结合．
第一范式：当且仅当一个关系变量的所有的合法的值中，每一个元组的每个属性只含有
一个值时，该关系变量属于1 N F。
第二范式：（假定只有一个候选码，且该候选码是主码）当且仅当一个关系变量属于
1 N F，且该关系变量的每一个非码属性都完全函数依赖于主码时，该关系变量属于2 N F。
第三范式（假定关系变量只有一个候选码，且该候选码是主码）：当且仅当一个关系变
量属于2 N F且该关系变量的所有非码属性都不传递依赖于主码时，该关系变量属于3 N F。
注意：“不传递依赖”蕴涵不互相依赖，从这个意义上说，该术语的解释和本节开始的
解释一样。

多值依赖： R是一个关系变量， A、B和C是R的属性的子集。那么我们说B多值依赖于A
—符号如下：A→→B（读做“A多值决定B”，或简单地称为“ A双箭头B”）—当且仅当
对于每一个可能的合法R值，B值的集合对于给定的一组（ A值，C值）只依赖于A的值，而与
C的值无关。
很容易看出—参见[ 1 2 . 1 3 ]—对于给定的变量R{A,B,C}，多值依赖A→→B存在，当且
仅当多值依赖A→→C也存在。这样M V D总是成对的一起出现。因此通常用一种语句来表示它
们：A→→B|C。例如：C O U R S E→→T E A C H E R | T E X T。
在前面我们已经提到，多值依赖是一般化的函数依赖，在这种意义上讲每一个F D都是
M V D。更精确地说，一个F D就是一个只有一个依赖值（右边的）与一个给定的决定值相符合
的M V D。因此，如果A→B，那么一定A→→B。

第四范式：只要存在R的属性的子集A和B，满足非平凡的多值依赖，并且R的所有属
性也都函数依赖于A，这样的关系变量R满足4 N F。
换句话说，在R中的唯一的非平凡的依赖（函数依赖或多值依赖）是K→→X形式（例如：
一个超码K对另一个属性X的函数依赖）。同样，如果R是B C N F，并且R中的所有非平凡的多值
依赖事实上都是“非码函数依赖（ FDs out of key）”，则R是4 N F的。因此特别要注意的是，
4 N F包含了B C N F。

第五范式：一个关系变量R是第五范式—也称为投影-连接范式（ P J / N F）—当且仅当
R的每一个非平凡的连接依赖都被R的候选码所蕴涵。
注意：下面解释一下对于一个J D“被候选码所蕴涵”的含义。
关系变量S P J并不是5 N F；它满足一个特定的连接依赖，即3 D约束。这显然没有被其唯一
的候选码（这个候选码是其所有的属性值的组合）所蕴涵。可以表示其区别如下：关系变量
S P J并不是5 N F，因为（ a）它是可以被3分解的；（b）可3分解性并没有为其{ S #，P #，J # }是
一个候选码的事实所蕴涵。相反， 3分解后，由于三个投影S P、P J和J S根本不包括任何（非平
凡的）连接依赖，因此它们都是5 N F。

3. 请大伙给我解释一下数据库设计的基本原则！

数据库设计的三范式所谓范式，是关系型数据库关系模式规范化的标准，从规范化的宽松到严格，分别为不同的范式，通常使用的有第一范式、第二范式、第三范式及BC范式等。范式是建立在函数依赖基础上的。

函数依赖

定义：设有关系模式R(U)，X和Y是属性集U的子集，函数依赖是形为X→Y的一个命题，对任意R中两个元组t和s，都有t[X]=s[X]蕴涵t[Y]=s[Y]，那么FD X→Y在关系模式R(U)中成立。X→Y读作‘X函数决定Y’，或‘Y函数依赖于X’。通俗的讲，如果一个表中某一个字段Y的值是由另外一个字段或一组字段X的值来确定的，就称为Y函数依赖于X。函数依赖应该是通过理解数据项和企业的规则来决定的，根据表的内容得出的函数依赖可能是不正确的。

第一范式（1NF）

定义：如果关系模式R的每个关系r的属性都是不可分的数据项，那么就称R是第一范式的模式。
简单的说，每一个属性都是原子项，不可分割。1NF是关系模式应具备的最起码的条件，如果数据库设计不能满足第一范式，就不称为关系型数据库。关系数据库设计研究的关系规范化是在1NF之上进行的。

第二范式（2NF）

定义：如果关系模式R是1NF，且每个非主属性完全函数依赖于候选键，那么就称R是第二范式。
简单的说，第二范式要满足以下的条件：首先要满足第一范式，其次每个非主属性要完全函数依赖与候选键，或者是主键。也就是说，每个非主属性是由整个主键函数决定的，而不能由主键的一部分来决定。举个例子：
有股票日行情表的主键是股 票代码和交易日期组成。非主属性中有收盘价和成交量等，都是由主键，即股票代码和交易日期函数决定的，单独的股票代码或者交易日期都不能函数决定这些非主 属性。如果这个表中有非主属性股票简称，则股票简称是可以由股票代码来函数决定的，这样股票简称这个非主属性就不是完全函数依赖于候选键，这样的设计就不 满足第二范式。

第三范式（3NF）
定义：如果关系模式R是2NF，且关系模式R（U，F）中的所有非主属性对任何候选关键字都不存在传递依赖，则称关系R是属于第三范式。
简单的说，第三范式要满足以下的条件：首先要满足第二范式，其次非主属性之间不存在函数依赖。由于满足了第二范式，表示每个非主属性都函数依赖于主键。如果非主属性之间存在了函数依赖，就会存在传递依赖，这样就不满足第三范式。
举 个例子：在股票基本情况表中，主键是股票代码，有非主属性所属一级行业和所属二级行业。根据业务规则，所属二级行业能够函数决定所属一级行业，这就表示存 在这样一种关系：股票代码函数决定所属二级行业，所属二级行业函数决定所属一级行业，这就形成了传递依赖，这样的设计就不符合第三范式。不过在实际运用 中，为查询和使用的方便，有时也会违反第三范式。如上例，如果没有所属一级行业的属性，需要查询所属一级行业的相关股票，需要查询时使用函数来从二级行业 中函数生成所属一级行业，使用性能上会受影响。所以通常会加上所属一级行业的属性。

BC范式（BCNF）

BC范式是第三范式的增强版，不过也有人说是直接从1NF发展过来的，即每个属性，包括主属性或非主属性，都完全依赖于候选键，并且不存在传递依赖情况。