① 数据库三范式具体是
数据库三范式如下：
第一范式（1NF）：强调的是列的原子性，即数据库表的每一列都是不可分割的原子数据项。
第二范式（2NF）：要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性。（在1NF基础上消除非主属性对主键的部分函数依赖）
第三范式（3NF）：任何非主属性不依赖于其它非主属性。（在2NF基础上消除传递依赖）
② 数据库 关系模式 范式问题
1.
f={订单号
->订货日期，订单号
->客户号，产品编号
->品名，产品编号
->价格,客户号->客户名称，客户号->客户电话}
2.
L类：订单号，产品编号，客户号
N类：数量
所以订单号，产品编号，客户号，数量一定是R的候选码成员
由于(订单号，产品编号，数量)+=订单号，订货日期，客户号，客户名称，客户电话，产品编号，品名，价格，数量
所以订单号，产品编号，数量是R的候选码
3.第一范式，因为R中的非主属性部分依赖于候选码
③ 数据库反范式化表设计和表的垂直和水平拆分什么意思
1.水平拆分：
是根据主要查询条件，水平分表。例如，用户关系表， 根据用户id：
用户id为 1， 2， 3， 4，5 的五个用户，采用取模的方式水平分表。将uid mod 3，取余数
这样，id为1，4的用户就在 t_user_1 的表里， id 为2，5 的用户在 t_user_2的表里，id为3的就在t_user_3的表里。这样，所有用户就平均水平分布在三个表里。
查询时，根据查询条件，动态算出，该用户信息存储在哪个表里
2.垂直拆分：
是根据数据量进行分表。例如，网购订单表：
数据量过大，可能单表几千万条数据。那么，垂直分表， 将id为1-1000000放在第一张表里。
将id 1000000－2000000的放在第二张表里。这样，就实现了垂直分表。
查询时，根据查询条件，动态算出，该订单信息存储在哪个表里
同样可以，水平分库， 垂直分库。 也可以两者相结合，形成数据库矩阵集群。 数据表的矩阵。
数据库范式：
目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。
具体可查看：http://ke..com/link?url=tUvhPptcmwVSWfG_
为了维持范式，会降低数据库的查询性能，大量冗余信息等。在实际生产环境，很多情况下，不能去实现这种范式，所以要违反范式的定义，就是反范式数据库设计。
范式只是一个理想化状态，仅用于关系型数据库。
④ 数据库三大范式是什么
数据库三大范式是：
第一范式（1NF）：属性不可分割，即每个属性都是不可分割的原子项。（实体的属性即表中的列）
第二范式（2NF）：满足第一范式；且不存在部分依赖，即非主属性必须完全依赖于主属性。（主属性即主键；完全依赖是针对于联合主键的情况，非主键列不能只依赖于主键的一部分）
第三范式（3NF）：满足第二范式；且不存在传递依赖，即非主属性不能与非主属性之间有依赖关系，非主属性必须直接依赖于主属性，不能间接依赖主属性。（A -> B，B ->C，A -> C）
数据库管理系统是数据库系统的核心组成部分，主要完成对数据库的操作与管理功能，实现数据库对象的创建、数据库存储数据的查询、添加、修改与删除操作和数据库的用户管理、权限管理等。它的安全直接关系到整个数据库系统的安全，其防护手段主要有：
（1）使用正版数据库管理系统并及时安装相关补丁。
（2）做好用户账户管理，禁用默认超级管理员账户或者为超级管理员账户设置复杂密码；为应用程序分别分配专用账户进行访问；设置用户登录时间及登录失败次数限制， 防止暴力破解用户密码。
（3）分配用户访问权限时，坚持最小权限分配原则，并限制用户只能访问特定数据库，不能同时访问其他数据库。
（4）修改数据库默认访问端口，使用防火墙屏蔽掉对 外开放的其他端口，禁止一切外部的端口探测行为。
（5）对数据库内存储的重要数据、敏感数据进行加密存储，防止数据库备份或数据文件被盗而造成数据泄露。
（6）设置好数据库的备份策略，保证数据库被破坏后能迅速恢复。
（7）对数据库内的系统存储过程进行合理管理，禁用掉不必要的存储过程，防止利用存储过程进行数据库探测与攻击。
（8）启用数据库审核功能，对数据库进行全面的事件跟踪和日志记录。
⑤ 数据结构中的1范式，2范式，3范式，bc范式，4范式，5范式。怎么理解希望解释的直白些。
这个不是数据结构的内容，属于数据库设计的范畴。规范化设计数据库可以减少数据冗余，减少数据插入、更新异常。
1范式，2范式，3范式，bc范式，4范式，5范式是规范化标准。
比如：目前的所有商用数据库设计出来的表至少必须满足第一范式（1nf：即满足表的所有属性都是不能再分解的原子属性）。
2范式-5范式这些标准多是根据表的属性间的不同程度的函数依赖（从1nf到5nf逐步提高标准）来区分的。由数据库设计者把握设计出来的数据库规范化到什么程度。理论上满足的规范化程度越高，设计出来的数据库越有效、稳定。但有时候考虑到数据查询、表连接的频率问题，不得不反规范化，减低满足的标准才能提高程序执行效率。
简单的讲可以这样理解：
第一范式：指表中的属性都是原子属性，不能再拆分了。
第二范式：在第一范式的基础上，要求非主属性都完全函数依赖于主键。
第三范式：在第二范式的基础上，要求要求没有非主属性传递依赖于主键。
BC范式：在第三范式基础上，要求所有非主键属性都必须依赖于主键。
第四范式：在BC范式基础上，要求表中存在的多值依赖都必须是对主键函数依赖。
第五范式：在第四范式的基础上，继续拆分表格，消除多值依赖。
在一个表中：
主属性：所有包含在候选码里的属性。
非主属性：不包含在候选码里的属性。
候选码：一个或者一组可以唯一标识一条记录且不含多余属性的属性。
函数依赖：表中属性X的值可以唯一确定Y的值，则说：X确定Y，或Y依赖于X（记作X->Y）。
传递依赖：X->Y，Y->Z。则可以说Z传递依赖于X。
多值依赖：一个属性的值可以确定一组属性。（函数依赖是一种特殊的多值依赖，依赖的整组属性只有1个，而不是多个）
（例如假设有一个人事资料的数据表，我们根据表中记录的一个人的姓名，我们可以查到他的年龄即有： 姓名->年龄。在没有同名存在的情况下，姓名就是这个表的候选键（码），因为姓名可以唯一确定一条记录的其他属性，例如：姓名->(性别、年龄、职位)，同时我们把姓名选为该表的主键（含主属性）。姓名以外的其他属性即为非主属性。有时候一个表可以有多个候选键，则需要选择其中一组作为主键，所有候选键包括的属性都是主属性。）
以上内容都是根据自己理解信手敲出。并没有严谨的校对教科书的概念。如有疏漏错误实属正常，如有人补漏改错不胜荣幸。
⑥ 数据库的三大范式
1、第一范式（1NF）
所谓第一范式（1NF）是指在关系模型中，对于添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。
即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域。
说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的设计基本要求，一般设计中都必须满足第一范式（1NF）。
不过有些关系模型中突破了1NF的限制，这种称为非1NF的关系模型。换句话说，是否必须满足1NF的最低要求，主要依赖于所使用的关系模型。
2、第二范式（2NF）
在1NF的基础上，非码属性必须完全依赖于候选码（在1NF基础上消除非主属性对主码的部分函数依赖）
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。
第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。选取一个能区分每个实体的属性或属性组，作为实体的唯一标识。
例如在员工表中的身份证号码即可实现每个一员工的区分，该身份证号码即为候选键，任何一个候选键都可以被选作主键。
在找不到候选键时，可额外增加属性以实现区分，如果在员工关系中，没有对其身份证号进行存储，而姓名可能会在数据库运行的某个时间重复。
无法区分出实体时，设计辟如ID等不重复的编号以实现区分，被添加的编号或ID选作主键。（该主键的添加是在ER设计时添加，不是建库时随意添加）
第二范式（2NF）要求实体的属性完全依赖于主关键字。
所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。
为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。
3、第三范式（3NF）
在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）
第三范式（3NF）是第二范式（2NF）的一个子集，即满足第三范式（3NF）必须满足第二范式（2NF）。
简而言之，第三范式（3NF）要求一个关系中不包含已在其它关系已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。
那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。
如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。
简而言之，第三范式就是属性不依赖于其它非主属性，也就是在满足2NF的基础上，任何非主属性不得传递依赖于主属性。
(6)数据库反第一范式扩展阅读
设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。
目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。
满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一般说来，数据库只需满足第三范式(3NF）就行了。
参考资料：网络-数据库范式
⑦ 什么是反范式
反范式是通过增加冗余数据或数据分组来提高数据库读性能的过程。在某些情况下， 反范式有助于掩盖关系型数据库软件的低效。关系型的范式数据库即使做过优化， 也常常会带来沉重的访问负载。
数据库的范式设计会存储不同但相关的信息在不同的逻辑表， 如果这些表的存储在物理上也是分离的，那么从几个表中完成数据库的查询可能就会很慢 (比如JOIN操作)。如果JOIN操作的表很多，那么可能会慢得离谱。 有两个办法可以解决这个问题。首选的方法是使逻辑上的设计遵循范式， 但允许数据库管理系统(DBMS)在磁盘上存储额外的冗余信息来加快查询响应。 在这种情况下，DBMS还要保证冗余副本与原始数据的一致性。 这种方法通常在SQL中以索引视图(微软的SQL Server)或物化视图(Oracle)实现。 视图将信息表示为方便查询的格式，索引确保视图上的查询进行了优化。
更常见的做法是对数据做反范式设计。这种方法同样能提高查询响应速度， 但此时不再是DBMS而是数据库设计者去保证数据的一致性。 数据库设计者们通过在数据库中创建规则来保证数据的一致性，这些规则叫约束。 这样一来，数据库设计的逻辑复杂度就增加了，同时额外约束的复杂度也增加了， 这使该方法变得危险。此外，“约束”在加快读操作(SELECT)的同时，减慢了写操作 (INSERT, UPDATE和DELETE)。这意味着一个反范式设计的数据库， 可能比它的范式版本有着更差的写性能。
反范式数据模型与没有范式化的数据模型不同。 只有在范式化已经达到一定的满意水平并且所需的约束和规则都已经建立起来， 才进行反范式化。例如，所有的关系都属于第三范式， 连接的关系和多值依赖得到了妥善处理。
⑧ 数据库中第一范式，第二范式，第三范式、、、、是什么，怎么区分
第一范式：一言以蔽之：“第一范式的数据表必须是二维数据表”，第一范式是指数据库的每一列都是不可分割的基本数据项，强调列的原子性，试题中某一属性不能拥有几个值。比如数据库的电话号码属性里面不可以有固定电话和移动电话值。 说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
第二范式建立在第一范式的基础上，即满足第二范式一定满足第一范式，第二范式要求数据表每一个实例或者行必须被唯一标识。除满足第一范式外还有两个条件，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。每一行的数据只能与其中一列相关，即一行数据只做一件事。只要数据列中出现数据重复，就要把表拆分开来。
第三范式若某一范式是第二范式，且每一个非主属性都不传递依赖于该范式的候选键，则称为第三范式，即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。
(8)数据库反第一范式扩展阅读：
范式是符合某一种级别的关系模式的集合。关系数据库中的关系必须满足一定的要求，满足不同程度要求的为不同范式。