数据库设计三⼤范式
为了建⽴冗余较⼩、结构合理的数据库，设计数据库时必须遵循⼀定的规则。在关系型数据库中这种规则就称为范式。范式是符合某⼀种设计要求的总结。要想设计⼀个结构合理的关系型数据库，必须满⾜⼀定的范式。
⼀、基础概念
要理解范式，⾸先必须对知道什么是关系数据库，如果你不知道，我可以简单的不能再简单的说⼀下：关系数据库就是⽤⼆维表来保存数据。表和表之间可以……（省略10W字）。
然后你应该理解以下概念：
实体：现实世界中客观存在并可以被区别的事物。⽐如“⼀个学⽣”、“⼀本书”、“⼀门课”等等。值得强调的是这⾥所说的“事物”不仅仅是看得见摸得着的“东西”，它也可以是虚拟的，不如说“⽼师与学校的关系”。
属性：教科书上解释为：“实体所具有的某⼀特性”，由此可见，属性⼀开始是个逻辑概念，⽐如说，“性别”是“⼈”的⼀个属性。在关系数据库中，属性⼜是个物理概念，属性可以看作是“表的⼀列”。
元组：表中的⼀⾏就是⼀个元组。
分量：元组的某个属性值。在⼀个关系数据库中，它是⼀个操作原⼦，即关系数据库在做任何操作的时候，属性是“不可分的”。
数据库属性的概念否则就不是关系数据库了。
码：表中可以唯⼀确定⼀个元组的某个属性（或者属性组），如果这样的码有不⽌⼀个，那么⼤家都叫候选码，我们从候选码中挑⼀个出来做⽼⼤，它就叫主码。
全码：如果⼀个码包含了所有的属性，这个码就是全码。
主属性：⼀个属性只要在任何⼀个候选码中出现过，这个属性就是主属性。
⾮主属性：与上⾯相反，没有在任何候选码中出现过，这个属性就是⾮主属性。
外码：⼀个属性（或属性组），它不是码，但是它别的表的码，它就是外码。
在实际开发中最为常见的设计范式有三个：
1．第⼀范式(确保每列保持原⼦性)【属性不可分】
第⼀范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原⼦值，就说明该数据库表
满⾜了第⼀范式。
第⼀范式的合理遵循需要根据系统的实际需求来定。⽐如某些数据库系统中需要⽤到“地址”这个属性，本来直接将“地址”属性设计成⼀个数据库表的字段就⾏。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就⾮要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进⾏存储，这样在对地址中某⼀部分操作的时候将⾮常⽅便。这样设计才算满⾜了数据库的第⼀范式，如下表所⽰。
上表所⽰的⽤户信息遵循了第⼀范式的要求，这样在对⽤户使⽤城市进⾏分类的时候就⾮常⽅便，也提⾼了数据库的性能。
2．第⼆范式(确保表中的每列都和主键相关)【符合第⼀范式，同时⾮主属性完全依赖于主键】
第⼆范式在第⼀范式的基础之上更进⼀层。第⼆范式需要确保数据库表中的每⼀列都和主键相关，⽽不能只与主键的某⼀部分相关（主要针对联合主键⽽⾔）。也就是说在⼀个数据库表中，⼀个表中只能保存⼀种数据，不可以把多种数据保存在同⼀张数据库表中。
⽐如要设计⼀个订单信息表，因为订单中可能会有多种商品，所以要将订单编号和商品编号作为数据库表的联合主键，如下表所⽰。
订单信息表
这样就产⽣⼀个问题：这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关，⽽仅仅是与商品编号相关。所以在这⾥违反了第⼆范式的设计原则。
⽽如果把这个订单信息表进⾏拆分，把商品信息分离到另⼀个表中，把订单项⽬表也分离到另⼀个表中，就⾮常完美了。如下所⽰。
这样设计，在很⼤程度上减⼩了数据库的冗余。如果要获取订单的商品信息，使⽤商品编号到商品信息表中查询即可。
3．第三范式(确保每列都和主键列直接相关,⽽不是间接相关)【符合2NF，并且消除传递依赖】
第三范式需要确保数据表中的每⼀列数据都和主键直接相关，⽽不能间接相关。
⽐如在设计⼀个订单数据表的时候，可以将客户编号作为⼀个外键和订单表建⽴相应的关系。⽽不可以在订单表中添加关于客户其它信息（⽐如姓名、所属公司等）的字段。如下⾯这两个表所⽰的设计就是⼀个满⾜第三范式的数据库表。
这样在查询订单信息的时候，就可以使⽤客户编号来引⽤客户信息表中的记录，也不必在订单信息表中多次输⼊客户信息的内容，减⼩了数据冗余。
通俗地理解三个范式
  通俗地理解三个范式，对于数据库设计⼤有好处。在数据库设计中，为了更好地应⽤三个范式，就必须通俗地理解三个范式(通俗地理解是够⽤的理解，并不是最科学最准确的理解)：
  第⼀范式：1NF是对属性的原⼦性约束，要求属性具有原⼦性，不可再分解；
  第⼆范式：2NF是对记录的惟⼀性约束，要求记录有惟⼀标识，即实体的惟⼀性；
  第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派⽣出来，它要求字段没有冗余。
  没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提⾼运⾏效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的⼯作放到物理数据模型设计时考虑。降低范式就是增加
字段，允许冗余。
BC范式（BCNF）：符合3NF，并且，主属性不依赖于主属性
若关系模式属于第⼀范式，且每个属性都不传递依赖于键码，则R属于BC范式。
通常
BC范式的条件有多种等价的表述：每个⾮平凡依赖的左边必须包含键码；每个决定因素必须包含键码。
BC范式既检查⾮主属性，⼜检查主属性。当只检查⾮主属性时，就成了第三范式。满⾜BC范式的关系都必然满⾜第三范式。
还可以这么说：若⼀个关系达到了第三范式，并且它只有⼀个候选码，或者它的每个候选码都是单属性，则该关系⾃然达到BC范式。⼀般，⼀个数据库设计符合3NF或BCNF就可以了。在BC范式以上还有第四范式、第五范式。
第四范式：要求把同⼀表内的多对多关系删除。
第五范式：从最终结构重新建⽴原始结构。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。