第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关,而不能只与主键的某一部分相关(主要针对联合主键而言)。也就是说在一个数据库表中,一个表中只能保存一种数据,不可以把多种数据保存在同一张数据库表中。
+----------+-------------+-------+ | employee | department | head | +----------+-------------+-------+ | Jones | Accountint | Jones | | Smith | Engineering | Smith | | Brown | Accounting | Jones | | Green | Engineering | Smith | +----------+-------------+-------+
上表描述了被雇佣者,工作部门和领导的关系。我们把能够唯一表示数据库中表的一行的数据成为这个表的主键。表中 head 列不和主键相关。因此,该表是不符合第二范式的,为了使上面的表符合第二范式,需要将它拆分为两个表:
-- employee 为主键 +----------+-------------+ | employee | department | +----------+-------------+ | Brown | Accounting | | Green | Engineering | | Jones | Accounting | | Smith | Engineering | +----------+-------------+ -- department 为主键 +-------------+-------+ | department | head | +-------------+-------+ | Accounting | Jones | | Engineering | Smith | +-------------+-------+
第三范式(3NF)
满足 2NF 的前提下,非主键外的所有字段必须互不依赖,即需要确保数据表中的每一列数据都和主键直接相关,而不能间接相关。
简而言之,第三范式(3NF)要求一个关系中不包含已在其它关系已包含的非主关键字信息。例如,存在一个部门信息表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表,则根据第三范式(3NF)也应该构建它,否则就会有大量的数据冗余。
3.关于反范式
范式的优点是明显的,它避免了大量的数据冗余,节省了存储空间,保持了数据的一致性。范式化的表通常更小,可以更好地放在内存里,所以执行操作会更快。那么是不是只要把所有的表都规范为 3NF 后,数据库的设计就是最优的呢?这可不一定。范式越高意味着表的划分更细,一个数据库中需要的表也就越多,用户不得不将原本相关联的数据分摊到多个表中。稍微复杂一些的查询语句在符合范式的数据库上都可能需要至少一次关联,也许更多,这不但代价昂贵,也可能使一些索引策略无效。
所以我们在进行数据库设计时,并不会完全按照范式要求来做,有时候也会进行反范式设计。通过增加冗余或重复的数据来提高数据库的读性能,减少关联查询时,join 表的次数。
以上就是详解MySQL 数据库范式的详细内容,更多关于MySQL 数据库范式的资料请关注其它相关文章!
更多相关Mysql内容来自木庄网络博客
标签:Mysql
相关阅读 >>
更多相关阅读请进入《mysql》频道 >>

数据库系统概念 第6版
本书主要讲述了数据模型、基于对象的数据库和XML、数据存储和查询、事务管理、体系结构等方面的内容。