数据库三大范式是:
第一范式(1NF):属性不可分割,即每个属性都是不可分割的原子项。(实体的属性即表中的列)
第二范式(2NF):满足第一范式;且不存在部分依赖,即非主属性必须完全依赖于主属性。(主属性即主键;完全依赖是针对于联合主键的情况,非主键列不能只依赖于主键的一部分)
第三范式(3NF):满足第二范式;且不存在传递依赖,即非主属性不能与非主属性之间有依赖关系,非主属性必须直接依赖于主属性,不能间接依赖主属性。(A ->B,B ->C,A ->C)
数据库管理系统是数据库系统的核心组成部分,主要完成对数据库的 *** 作与管理功能,实现数据库对象的创建、数据库存储数据的查询、添加、修改与删除 *** 作和数据库的用户管理、权限管理等。它的安全直接关系到整个数据库系统的安全,其防护手段主要有:
(1)使用正版数据库管理系统并及时安装相关补丁。
(2)做好用户账户管理,禁用默认超级管理员账户或者为超级管理员账户设置复杂密码;为应用程序分别分配专用账户进行访问;设置用户登录时间及登录失败次数限制, 防止暴力破解用户密码。
(3)分配用户访问权限时,坚持最小权限分配原则,并限制用户只能访问特定数据库,不能同时访问其他数据库。
(4)修改数据库默认访问端口,使用防火墙屏蔽掉对 外开放的其他端口,禁止一切外部的端口探测行为。
(5)对数据库内存储的重要数据、敏感数据进行加密存储,防止数据库备份或数据文件被盗而造成数据泄露。
(6)设置好数据库的备份策略,保证数据库被破坏后能迅速恢复。
(7)对数据库内的系统存储过程进行合理管理,禁用掉不必要的存储过程,防止利用存储过程进行数据库探测与攻击。
(8)启用数据库审核功能,对数据库进行全面的事件跟踪和日志记录。
作用嘛,主要是规范数据库设计,且视你自己实现的功能而定。满足范式要求的数据库设计是结构清晰的,同时可避免数据冗余和 *** 作异常。这并意味着不符合范式要求的设计一定是错误的,在数据库表中存在1:1或1:N关系这种较特殊的情况下,合并导致的不符合范式要求反而是合理的。 关系数据库的几种设计范式介绍 1 第一范式(1NF)在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。 所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或 者不能有重复的属性。如果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系 。在第一范式(1NF)中表的每一行只包含一个实例的信息。例如,对于图3-2 中的员工信息表,不能将员工信息都放在一列中显示,也不能将 其中的两列或多列在一列中显示;员工信息表的每一行只表示一个员工的信息,一个员工的信息在表中只出现一次。简而言之,第一范式就是 无重复的列。 2 第二范式(2NF)第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要 求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的唯一标识。如图3-2 员工信息 表中加上了员工编号(emp_id)列,因为每个员工的员工编号是唯一的,因此每个员工可以被唯一区分。这个唯一属性列被称为主关键字或主 键、主码。 第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个 属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以 存储各个实例的唯一标识。简而言之,第二范式就是非主属性非部分依赖于主关键字。 3 第三范式(3NF)满足第三范式(3NF)必须先满足第二范式(2NF)。简而言之,第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主 关键字信息。例如,存在一个部门信息表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在图3-2的员工信息表中 列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表,则根据第三范式(3NF)也 应该构建它,否则就会有大量的数据冗余。简而言之,第三范式就是属性不依赖于其它非主属性。欢迎分享,转载请注明来源:内存溢出
评论列表(0条)