实践千万条，基础第一条——数据库范式，第一条范式
在当前互联网流行的格局下，Redis、MongoDB等非关系数据库(NoSQL )占据了越来越多的视野，正如其释义(Not Only SQL )所言，NoSQL至今仍是在当前的大部分持久化场景中，关系数据库仍然占有不可替代的地位。 因此，能够设计规范合理的关系数据表也是所有后端程序员的必修课，但“规范合理”还有一个量化指标吗？ 虽然在普通领域没有答案，但在关系数据库中真的有。 这就是人们常说的“数据库范式”。
“来吧，你给翻译做翻译。 什么是范例？ ”
“不用翻译，是个范例哦！ ”
“翻译给你听。 什么是范例？ ”
"范例是最佳实践. "
“翻译翻译，**的范式是什么？ ”
“范例是前人经过多次实践和论证取得的经验的总结！ ”
“让你翻译，**的**这个范例是什么？ ”
“这样比较好。 否则，你错了，必须带我去枪毙！ ”
“啊，原来这就是范例啊！ ”
说到数据库范例，现在关系数据库有第一范例(1NF )、第二范例(2NF )、第三范例(3NF )、总线代码范例(BCNF )、第四范例(4NF )
的三种标准范式定义：
第一范式：如果关系模型r的所有属性都不能分解为更基本的数据单元，则r表示满足第一范式，缩写为1NF。 满足第一范式是规范关系模式的最低要求，否则很多基本操作都是这种关系模式无法实现的。
第二范式：如果关系模型r满足第一范式，且r的所有非主要属性完全依赖于r的所有候选主要属性，则r满足第二范式，并简单标记为2NF。
第三范式：关系模型r满足第二范式时，x是r的任意属性集；x非传递依赖于r的任意候选关键字时，r满足第三范式，简单记为3NF。
什么，定义太长了。 下面有紧凑的版本真是太好了。
第一范式：表格不能有表格。 队伍里不能有队伍。
第二范式：在满足第一范式的基础上，消除非主属性对主属性的部分依赖。
第三范式：在满足第二范式的基础上，消除对非主属性任一主属性的传递依赖。
以下，试着对上面的释义进行一般性说明。
第一范式：表格不能有表格。 队伍里不能有队伍。 我相信这是对相关数据表的基本要求，同时没有人能从物理上突破限制，真的可以在正反两面形成不同的子表。 但是，逻辑上的“列中不能有列”这一点容易被忽视。 例如，记录用户信息的用户表包含用于记录用户名的realname字段。 这在中国很常见，但放眼世界，很多国家都用firstname、lastname标记名称，但如果坚持在一个字段中记录名称，往往会出现问题。 因此，并不是所有的关系表都能轻易达到严格的第一范式哦。
范例2 )作为示例，设计包括字段course_id (路线)、stu_no (路线)、score (路线)、stu_name (名称)的单位表。 很多人相信看到这样的表面结构很快就能感受到奇妙的力量。 没错，是stu_name闯入的。 此表的主要属性是course_id和stu_no。 score完全依赖于主要属性，而stu_name只依赖于stu_no，不依赖于course_no
设计第三范式(依然是订单表、order_id (订单编号) total_fee总额)、customer_id (客户id )、customer_name (客户名称) )。 其中，由于主要属性是order_id，所有其他属性都依赖于order_id，因此当前表结构被认为符合第二个范例。 但是，这是一个原因，因为customer_id依赖于order_id，customer_name依赖于customer_id
Tips :本质上，数据库范式的演化过程是一个去除冗馀数据的过程。 实际上，了解三种范式对数据库的设计有很大的帮助，但不要绞尽脑汁。 由于业务场景的复杂性不在数据库范式的讨论范围之内，因此强加数据库设计规范容易增加数据库设计和编程的复杂性。 因此，适当合理的数据冗馀也可以接受哦。 很遗憾，“合适合理的数据冗馀”没有量化的概念。
3358 www.dengb.com/Oracle/1337634.html www.dengb.com true http://www.dengb.com/Oracle/13337634.htmltechartichche .