数据设计规范化
函数依赖、码、范式
今日小兔和我一起参加了西南大学一年一届的南京路模拟活动，我们挑上四年深藏在衣橱的旧服，或崭新或翻旧的书们，早早的在橘园广场上占了铺位，开始叫嚣开我们的跳蚤卖摊，为大学的生活再增添一份回忆，当然其收获也可以让我们带着沙哑的嗓子去饱餐几顿。如此我们就沉浸在这些欢乐之中。直到食堂关门、天下起雨、人烟袅袅。却意犹未尽，再待到下一个天晴。这等关系就造就了一种规范，晴天气，则可开铺。
那么来讨论下数据库设计里的规范。
函数依赖
设R(U)是属性集U上的关系模式。X,Y是U上的子集。若对于R(U)的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等，则称X函数确定Y或Y函数依赖于X，记为X->Y。
我的理解：函数依赖就像数学里的函数一样，y=f(x)，给一个x就能确定y的值，那么y就函数依赖于x，举个例子：在通讯表模式属性集U中，x为手机号码，y为手机联系人，x，y都是模式中的属性，若唯一的手机号码能够对应唯一的手机联系人，那么就存在y手机联系人函数依赖于手机号码x。
X->Y,但Y不属于X，则称X->Y是非平凡的函数依赖。
X->Y,但Y属于X，则称X->Y是平凡的函数依赖。
完全函数依赖
在R(U)中，如果X->Y，并且对于X的任何一个真子集X'，都有Y不函数依赖于X'，则称Y对于X完全函数依赖。记为：X -F-> Y。
我的理解：完全函数依赖需要知道，这里的X需要是一个属性集包括了多个属性，以确定属性集Y。举个例子：在通讯表模式属性集U中，X是(区号、座机号)这个属性集，Y是联系人。那么这里X(区号+座机号)才能确定Y(联系人)，而不能通过X中某一个真子集(区号)或者(座机号)就确定Y(联系人)。那么就说Y完全函数依赖于X。
相反的，若Y不完全函数依赖于X，则称为Y对于X部分函数依赖，记作：X -P-> Y。
传递函数依赖
在R(U)中，如果X->Y，(Y不属于X)，Y/>X,Y->Z,Z不属于Y，则称Z对于X传递函数依赖，记为：X-传递->Z。
我的理解：举个例子：在通讯表模式属性集U中，X为手机号码，Y为手机联系人，Z为联系人职位，Z联系人职位函数依赖于Y手机联系人，而Y手机联系人函数依赖于手机号码X，如此便形成了简单的Z联系人职位对于X手机号码的传递依赖。
码
设K为R<U,F>中的属性或属性集合，若K -F-> U则K为R的候选码。若候选码多于一个，则选择其中的一个为主码。包含在任何一个候选码中的属性，称为主属性。不包含在任何码中属性称为非主属性或非码属性。若整个属性组都是码，称为全码。
我的理解：对于通讯表模式所有属性(区号，座机号，联系人)，其主码可定为(区号，座机号)，那么区号，座机号称为主属性，联系人为非主属性。
外码
关系模式R中属性或属性组X并非R的码，但X是另一个关系模式的码，则称X是R的外部码。
我的理解：对于通讯表模式所有属性(区号，座机号，联系人)，其主码可定为(区号，座机号)，那么区号属性是区间表模式(区号，区间名)的码，那区号就为通讯表模式的外码。
范式
第一范式1NF：如果一个关系模式R的所有属性都是不可分的基本数据项，则R∈1NF。
我的理解：数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。举个例子：个人信息表模式中的地址属性，若在业务没有具体要求的情况下，其是不满足1NF的，地址可拆分为国家、省市、地区……单一数据。
第二范式2NF：若R属于1NF，且每一个非主属性完全依赖于码，则R属于2NF。
我的理解：若存在非主属性对码的部分依赖，则不满足2NF，举个例子：通讯表模式所有属性(区号，座机号，联系人，区域名称)，其主码可定为(区号、座机号)，但是属性(区域名称)仅函数依赖于主属性区号，即部分函数依赖于主码，则其不满足2NF。
第三范式3NF：关系模式R<U,F>中若不存在这样的码X，属性组Y及非主属性Z(Z不包含于Y)使得X->Y，Y->Z成立，X不函数依赖于Y，则称R<U,F>属于3NF。
我的理解：即每一个非主属性既不部分依赖于码也不传递依赖于码。举个例子：通讯表模式所有属性(区号，座机号，联系人，联系人地址)，其主码可定为(区号、座机号)，属性(联系人地址)函数依赖于属性(联系人)，(联系人)函数依赖于主码，因此(联系人地址)传递函数依赖于主码，则其不满足3NF。
BC范式BCNF：扩充的第三范式。关系模式R<U,F>满足3NF，若X->Y且Y不包含于X时X比含有码，则R<U,F>满足BCNF。
我的理解：每一个决定因素都包含码。所有非主属性对每一个码都是完全函数依赖；所有主属性对每一个不包含它的码，也是完全函数依赖；没有任何属性完全函数依赖于非码的任何一组属性。为了消除第三范式中主属性对码的部分依赖或传递依赖。举个例子关系模式STJ(学生、教师、课程)，业务是这样的：每一教师只教一门课，每门课有若干教师，某一学生选定某门课就对应一个固定的教师。那么存在以下函数依赖：(学生，课程)->(教师)，(学生，教师)->(课程)，(教师)->(课程)。那么可知(学生，课程)、(学生、教师)都是候选码，但(教师)作为决定因素却不包含码，因此不满足BCNF。
到这里，在大多数企业级开发中，能做到BCNF的数据库设计已经完全能够满足需求。其实在许多应用中，按其业务需要，不是范式走的愈高则愈好，而是在低级的范式要求下更能提高数据运用的效率和易用。所以此时，我又一次地强调业务决定技术的思想。抓老虎用长枪，抓老鼠用鼠夹。此等道理是在软件工程中尤其地体现。
对于在数据库设计中更为深层次的研究，包括多值依赖、第四范式、第五范式……则待到有此精力与时间再做推敲吧。