范式

范式概念：数据库设计需要遵循的规范，这些规范可以优化数据的储存与设计，要遵循后面的范式，就必须遵循前面的范式。 范式分类：目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。一般数据库设计满足第三范式即可。 第一范式定义：表中的每一个列都是不可分割的原子数据项。 第二范式定义：在第一范式的基础上，非码属性必须完全依赖码，（在第一范式的基础上，消除非码属性部分函数依赖码），为了理解这句话，我们要了解几个概率，函数依赖（A-->B）：指的是一个属性（组）A的值可以完全确定B的值，那么可以叫做B函数依赖A，完全函数依赖：如果A是一个属性组，B的值由A属性组中所有属性共同所确定，那么就叫B完全函数依赖A。部分函数依赖：如果A是一个属性组，B的值由A属性组某个，某几个属性确定，那么就叫B部分函数依赖A，传递函数依赖(A-->B,B-->C)：如果B属性函数依赖A属性，C属性函数依赖B，那么C叫做传递函数依赖A。码：在一个表中，一个属性（组），被其他属性所完全函数依赖，则这个属性（组）叫码。 第三范式定义：在第二范式的基础上，任何非主属性不能函数依赖其他非主属性（在第二范式的基础上消除传递函数依赖关系）主属性：码属性组中的所有属性， 非主属性：除过码属性组的属性。

数据库基础 传统的文件系统管理的缺陷 编写应用程序不方便； 数据冗余不可避免； 应用程序依赖性； 不支持对文件的并发访问； 数据间联系弱 难以按用户视图表示数据； 无阶段性安全控制功能。 数据库管理系统的优点 相互关联的数据的集合； 较少的数据冗余； 程序与数据相互独立； 保证数据的安全、可靠； 最大限度地保证数据的正确性； 数据可以并发使用并能同时保证一致性。 数据库管理系统 数据库是数据的汇集，它以一定的组织形式存在于存储介质上 DBMS是管理数据库的系统软件，它实现数据库系统的各种功能。是数据库系统的核心 DBA: 负责数据库的规划、设计、协调、维护和管理等工作 应用程序指以数据库为基础的应用程序； 关系型数据Key/Value 数据库 关系：关系就是二维表。并满足如下性质： 表中的行、列次序并不在重要 行row：表中的每一行，又称为一条记录（record) 列column:表中的没一列，称为属性，字段 主键(Primary key):用于唯一确定一个记录的字段 域domain：属性的取值范围，如，性别只能是‘男’和‘女’两个值 外键(Foreign key):用于表之间的一对多的关系 唯一键（Uniq key):可以为null, 非关系型数据库：NO SQL（not only SQL) mencached redis mogoDB RDBMS MySQL: MySQL,

ER图 Entity Relationship，实体关系图。 1、先画出所有实体，矩形圈出来 2、再画出每个实体的属性，椭圆圈出来，实体、属性之前用实线连接。为了方便找出主键，作为主键的属性可以画一条下划线。 3、标注实体之间的关联关系：一对一（1,1）、一对多（1,n），多对多（m,n）。关系用菱形表示，并在菱形2边的线上标上1、m、n这些表示2个实体之间关联关系的字符。 关联关系： 一对一，一个人只对应一张身份证，一张身份证也只对应一个人。（2个一对一） 一对多，一个用户可以拥有多个订单，一个订单只能属于一个用户。（1个一对一、1个一对多） 多对多，一个老师可以教多个学生，一个学生可以有多个老师。（2个一对多） 比如实体A、B，先把A作为1，看B是1还是多；再把B作为1，看A是1还是多。 如果2个都是一对一，那A、B就是一对一； 如果1个一对一、1个一对多，那A、B是一对多； 如果2个都是一对多，那A、B就是多对多。 数据库三大范式 数据库有8种范式（Normal Form），通常只用到前3种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）。 1NF 属性的原子性（不可再分） 数据库中的每一个字段都要是不可再分隔的基本 2NF 属性完全依赖于主键 一张表中的每一条记录都要是可区分的，只通过主键来区分，所以一张表必须要有一个unique字段。

第一范式：每个列不可拆分 第二范式：在第一范式上，非主键列完全依赖主键，而不能依赖主键一部分 第三范式：在第二范式上，非主键列只能依赖主键，不依赖其他非主键 设计数据库结构，尽量遵守3范式。考虑性能等问题，可以不严格遵守。 来源： https://www.cnblogs.com/ivy-xu/p/12540145.html

在目前的企业信息系统中，数据库还是最佳的数据存储方式，虽然已经有很多的书籍在指导我们进行数据库设计，但应该那种方式是设计数据库的表结构的最好方法、设计时应遵从什么样的原则、四个范式如何能够用一种方式达到顺畅的应用等是我一直在思考和总结的问题，下文是我针对这几个问题根据自己的设计经历准备总结的一篇文章的提纲，欢迎大家一块进行探讨，集思广益。其中提到了领域建模的概念，但未作详细解释，希望以后能够有时间我们针对这个命题进行深入探讨。 1)不应该针对整个系统进行数据库设计，而应该根据系统架构中的组件划分，针对每个组件所处理的业务进行组件单元的数据库设计；不同组件间所对应的数据库表之间的关联应尽可能减少，如果不同组件间的表需要外键关联也尽量不要创建外键关联，而只是记录关联表的一个主键，确保组件对应的表之间的独立性，为系统或表结构的重构提供可能性。 2)采用领域模型驱动的方式和自顶向下的思路进行数据库设计，首先分析系统业务，根据职责定义对象。对象要符合封装的特性，确保与职责相关的数据项被定义在一个对象之内，这些数据项能够完整描述该职责，不会出现职责描述缺失。并且一个对象有且只有一项职责，如果一个对象要负责两个或两个以上的职责，应进行分拆。 3)根据建立的领域模型进行数据库表的映射，此时应参考数据库设计第二范式：一个表中的所有非关键字属性都依赖于整个关键字。关键字可以是一个属性

http://www.cnblogs.com/RunForLove/p/5693986.html 数据库设计的三大范式：为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。 　　在实际开发中最为常见的设计范式有三个：第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式；第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中；第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。总结一下，就是： 第一范式(确保每列保持原子性)； 第二范式(确保表中的每列都和主键相关)； 第三范式(确保每列都和主键列直接相关,而不是间接相关)。 　　在目前的企业信息系统中，数据库还是最佳的数据存储方式，虽然已经有很多的书籍在指导我们进行数据库设计，但应该那种方式是设计数据库的表结构的最好方法、设计时应遵从什么样的原则、四个范式如何能够用一种方式达到顺畅的应用等是我一直在思考和总结的问题

文章目录 第一范式（1 NF） 第二范式（2 NF） 第三范式（3 NF） 第一范式（1 NF） 数据表中所有的字段都是不可分割的原子值 不满足第一范式，一般通过拆列解决 若字段值还可以继续拆分开，显然就不满足第一范式，如有一个列字段中存了“湖北省武汉市xxx地区”，这样不满足第一范式，我们需要拆开为几列，当然开发中我们不一定非要满足第一范式，有时候开发时会发现不拆比拆开更好 第二范式（2 NF） 在满足第一范式的前提下，要求除了主键外的每一列都完全依赖于主键，否则不满足第二范式 不满足第二范式，一般通过拆表解决 打个比方，联合主键时候，其他非主键字段其实只依赖于联合主键中的一个列，这样是不满足第二范式的 第三范式（3 NF） 在满足第二范式的前提下，要求表中除了主键意外，其他列不能有传递依赖 可以通过拆表来解决 打个比方，学生表，主键为学号，表中还有身份证号，这样学生姓名还依赖于身份账号，这样就是传递依赖，不满足第三范式 来源： CSDN 作者： abcnull 链接： https://blog.csdn.net/abcnull/article/details/104758806

范式：符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度。 简单来说可以把它粗略的理解为一张数据表的表结构所符合的某种设计标准的级别。就像英语46级，相对代表了英语水平的高低。 满足这些规范的数据库是简洁的，结构明晰的，同时，不会发生增删改操作异常。 数据库范式分为 1NF 2NF 3NF BCNF 4NF 5NF一般我们在设计数据库结构的时候最多只要满足到BCNF就可以了，符合高一级的范式必须符合第一级的范式。 一般设计数据库表的时候符合第三范式就很不错了。 1NF的定义：符合1NF的关系中的每个属性都不可以再分。 在使用数据库管理系统的时候比如mysql,SqlServer等创建的数据表都满足1NF，如果不满足这个范式，是不能创建成功数据表的。属性不可再分割的意思是每一个字段都是最小的，不包含其他字段。不重复，原子性。 例如：字段：姓名 不包含其他字段：年龄。 注意：这里说的是字段而不是字段的值！ 下面是一个 学生表！ 这种就是错误的，性别不能包含班级，科目，老师 下面这种才是正确的1NF 1NF存在的问题： 数据冗余，插入异常，删除异常，修改异常的问题。 数据冗余：张三的很多信息都要重复很多次 插入异常：如果要新建一个班级，并且有班级主任。但是因为还没有学生开始学习，所以主键（id就是学号）是空的，肯定是不能插入的。 删除异常

范式是数据库规范化的⼀个⼿段，是数据库设计中的⼀系列原理和技术，⽤于减少数据库中的数据冗余，并增进数据的⼀致性。 数据规范化通常是将⼤表分成较⼩的表，并且定义它们之间的关系。这样做的⽬的是为了避免冗余存放数据，并确保数据的⼀致性。添加、删除和修改数据等操作可能需要修改多个表，但只需要修改⼀个地⽅即可保证所有表中相关数据的⼀致性。由于数据分布在多个表之间，因此检索信息可能需要根据表之间的关系联合查询多个表。 数据规范化的实质是简单写、复杂读。写⼊操作⽐较简单，对于不同的信息，分别修改不同的表即可;⽽读取数据则相对复杂，检索数据的时候，可能需要编写复杂的SQL来联合查询多个表。 第一范式（1NF） 第⼀范式是指数据库表的每⼀列(属性)都是不可分割的基本数据项，这就要求数据库的 每⼀列都只能存放单⼀值 ，即实体中的某个属性不能有多个值或不能有重复的属性。 第⼀范式是对关系模式的基本要求。 关键点: 每⼀列都只能存放单⼀值 例如:我们开发微博时的 User 表和微博表，⼀个⽤户可以发表多个微博，但设计时需要将⽤户 数据和微博数据单独存放。 第二范式（2NF） 第⼆范式（2NF）是在第⼀范式（1NF）的基础上建⽴起来的，⼀个数据表符合第⼆范式的前提是该数据表符合第⼀范式。 它的规则是要求数据表⾥的所有数据都要和该数据表的主键有完全相依的关系; 如果有哪些数据只和主键的⼀部分有关的话

摘要 数据库性能对软件整体性能有着至关重要的影响，对于Mongodb数据库常用的性能优化方法主要有： 范式化与反范式化； 填充因子的使用； 索引的使用； 一. 范式化与反范式化 范式是为了消除重复数据减少冗余数据，从而让数据库内的数据更好的组织，让磁盘空间得到更有效利用的一种标准化标准，满足高等级的范式的先决条件是满足低等级范式。在数据库设计阶段，明确集合的用途是对mongodb数据库性能调优非常重要的一步。根据集合中数据最常用的操作，对于频繁更新和频繁查询的集合，我们最需要关注的重点是他们的范式化程度。 1.1 范式化 1.1.1 范式化的优点： 范式化的数据库更新起来更加快； 范式化之后，只有很少的重复数据，只需要修改更少的数据； 范式化的表更小，可以在内存中执行； 很少的冗余数据，在查询的时候需要更少的distinct或者group by语句。 1.1.2 范式化的缺点： 范式化的表，在查询的时候经常需要很多的关联，因为单独一个表内不存在冗余和重复数据。这导致，稍微复杂一些的查询语句在查询范式的schema上都可能需要较多次的关联。这会增加让查询的代价，也可能使一些索引策略无效。因为范式化将列存放在不同的表中，而这些列在一个表中本可以属于同一个索引。 1.1.3 范式化设计的例子： 以存储一篇图书及其作者为例，作者的信息包括作者的姓名，年龄，国籍。使用范式化的设计如下： {