数据库的规范化

一、基础概念

实体:现实世界中客观存在并可以被区别的事物。比如“一个学生”、“一本书”、“一门课”等。

属性:教科书上解释为:“实体所具有的某一特性”,由此可见,属性一开始是个逻辑概念,比如说,“性别”是“人”的一个属性。在关系数据库中,属性又是个物理概念,属性可以看作是“表的一列”。

元组:表中的一行就是一个元组。

分量:元组的某个属性值。

码:表中可以唯一确定一个元组的某个属性(或者属性组),如果这样的码有不止一个,那么大家都叫候选码,我们从候选码中挑一个出来做老大,它就叫主码。

全码:如果一个码包含了所有的属性,这个码就是全码。

主属性:一个属性只要在任何一个候选码中出现过,这个属性就是主属性。

非主属性:与上面相反,没有在任何候选码中出现过,这个属性就是非主属性。

外码:一个属性(或属性组),它不是码,但是它别的表的码,它就是外码。

二、函数依赖

1、函数依赖

设X,Y是关系R的两个属性集合,当任何时刻R中的任意两个元组中的X属性值相同时,则它们的Y属性值也相同,则称X函数决定Y,或Y函数依赖于X记作X→Y。

2、平凡函数依赖

当关系中属性集合Y是属性集合X的子集时,存在函数依赖X→Y,即一组属性函数决定它的所有子集,这种函数依赖称为平凡函数依赖。

3、非平凡函数依赖

当关系中属性集合Y不是属性集合X的子集时,存在函数依赖X→Y,则称这种函数依赖为非平凡函数依赖。

4、完全函数依赖

设X,Y是关系R的两个属性集合,X’是X的真子集,存在X→Y,但对每一个X’都有X’!→Y,则称Y完全函数依赖于X。

5、部分函数依赖

设X,Y是关系R的两个属性集合,存在X→Y,若X’是X的真子集,存在X’→Y,则称Y部分函数依赖于X。

6、传递函数依赖

设X,Y,Z是关系R中互不相同的属性集合,存在X→Y(Y !→X),Y→Z,则称Z传递函数依赖于X。

三、5大范式及其特点

1NF:原子性 字段不可再分,否则就不是关系数据库(所以在正常的关系数据库中是不可能创建出不符合1NF的表的);

2NF:唯一性 一个表只说明一个事物,1NF消除非主属性对码的部分函数依赖之后就是2NF;

3NF:每列都与主键有直接关系,2NF消除非主属性对码的传递函数依赖之后就是3NF;

BCNF:3NF消除主属性对码的部分函数依赖和传递函数依赖之后就是BCNF(换句话说就是BCNF范式既检查非主属性,又检查主属性,而3NF只检查非主属性);

4NF:限制关系模式的属性间不允许有非平凡且非函数依赖的多值依赖(只考虑函数依赖的话,最高到BCNF,如果考虑到多值依赖最高到4NF)。

关于4NF还是没搞清楚。

时间: 2024-10-01 07:49:12

数据库的规范化的相关文章

sql数据库设计学习---数据库设计规范化的五个要求

http://blog.csdn.net/taijianyu/article/details/5945490 一:表中应该避免可为空的列: 二:表不应该有重复的值或者列: 三: 表中记录应该有一个唯一的标识符  在数据库表设计的时候,数据库管理员应该养成一个好习惯,用一个ID号来 唯一的标识行记录,而不要通过名字.编号等字段来对纪录进行区分.每个表都应该有一个ID列,任何两个记录都不可以共享同一个ID值.另外,这个ID值最 好有数据库来进行自动管理,而不要把这个任务给前台应用程序.否则的话,很容

规范化-数据库设计原则

关系数据库设计的核心问题是关系模型的设计.本文将结合具体的实例,介绍数据库设计规范化的流程. 摘要 关系型数据库是当前广泛应用的数据库类型,关系数据库设计是对数据进行组织化和结构化的过程,核心问题是关系模型的设计.对于数据库规模较小的情况,我们可以比较轻松的处理数据库中的表结构.然而,随着项目规模的不断增长,相应的数据库也变得更加复杂,关系模型表结构更为庞杂,这时我们往往会发现我们写出来的SQL语句的是很笨拙并且效率低下的.更糟糕的是,由于表结构定义的不合理,会导致在更新数据时造成数据的不完整.

Oracle数据库设计第三范式

一.数据库设计范式及其意义和不足 数据库的设计范式是数据库设计所需要满足的规范,数据库的规范化是优化表的结构和优化把数据组织到表中的方式,这样使数据更明确,更简洁.实践中,通常把一个数据库分成两个或多个表并定义表之间的关系以做到数据隔离,添加.删除和修改某个字段只需要在一个表中进行,接着可以通过定义的关系传递到数据库中剩余的表中(和分层思想的意义所在很相似).这样我们可以消除很多错误或垃圾数据出现的机会并减轻更新信息所必要的工作量. 目前,主要有六种范式:第一范式.第二范式.第三范式.BC范式.

MySQL性能调优与架构设计——第9章 MySQL数据库Schema设计的性能优化

MySQL性能调优与架构设计——第9章 MySQL数据库Schema设计的性能优化 前言: 很多人都认为性能是在通过编写代码(程序代码或者是数据库代码)的过程中优化出来的,其实这是一个非常大的误区.真正影响性能最大的部分是在设计中就已经产生了的,后期的优化很多时候所能够带来的改善都只是在解决前妻设计所遗留下来的一些问题而已,而且能够解决的问题通常也比较有限.本章将就如何在 MySQL 数据库 Schema 设计的时候保证尽可能的高效,尽可能减少后期的烦恼. 9.1 高效的模型设计 最规范的就一定

SQL Server 数据库设计

一.数据库设计的必要性 在实际的软件项目中,如果系统中需要存储的数据量比较大,需要设计的表比较多,表与表之间的关系比较复杂,那我们就需要进行规范的数据库设置.如果不经过数据库的设计,我们构建的数据库不合理.不恰当,那么数据库的维护.运行效率会有很大的问题.这将直接影响到项目的运行性和可靠性. 二.什么是数据库设计 数据库设计实际上就是规划和结构化数据库中的数据对象以及这些数据对象之间的关系过程. 三.数据库设计的重要性 ? 不经过设计的数据库或是设计糟糕的数据库很可能导致 1. 数据库运行效率地

关系型数据库与NoSQL的对比

SQL(结构化的查询语言)数据库是过去四十年间存储数据的主要方式.20世纪90年代末随着Web应用和MySQL.PostgreSQL和SQLite等开源数据库的兴起,用户爆炸式的增长. NoSQL数据库自从20世纪60年代就已经存在了,直到MongoDB, CouchDB, Redis 和 Apache Cassandra等数据库的流行才获取了更多的关注. 你可以很容易地找到许多关于如何使用一款特定的SQL或NoSQL的教程,但是很少有讨论你为什么优先的使用一款而不适用另一款.我希望我能够填补这

写给开发者看的关系型数据库设计

目录 一 Codd的RDBMS12法则——RDBMS的起源 二 关系型数据库设计阶段 三 设计原则 四 命名规则 数据库设计,一个软件项目成功的基石.很多从业人员都认为,数据库设计其实不那么重要.现实中的情景也相当雷同,开发人员的数量是数据库设计人员的数倍.多数人使用数据库中的一部分,所以也会把数据库设计想的如此简单.其实不然,数据库设计也是门学问. 从笔者的经历看来,笔者更赞成在项目早期由开发者进行数据库设计(后期调优需要DBA).根据笔者的项目经验,一个精通OOP和ORM的开发者,设计的数据

关系型数据库设计

转自:http://www.cnblogs.com/MeteorSeed/archive/2013/03/27/2880054.html ------------------------------------------------------------------------------------- 目录 一 Codd的RDBMS12法则——RDBMS的起源 二 关系型数据库设计阶段 三 设计原则 四 命名规则 数据库设计,一个软件项目成功的基石.很多从业人员都认为,数据库设计其实不那么

mysql数据库优化之表的设计和慢查询定位

一.数据库优化包含的方面 数据库优化是一种综合性的技术.并非通过某一种方式让数据库效率提高非常多.而是通过多方面的提高.从而使得数据库性能提高. 主要包含: 1.表的设计合理化(3范式) 2.给表加入合适的索引.怎样使用索引 3.分表技术(水平切割.垂直切割) 4.定时清除数据垃圾,定时碎片整理 5.多用存储过程和触发器 6.对mysql配置进行优化 7.读写分离 8.mysqlserver硬件升级. 二.数据库的设计 步骤: 1.收集信息:与该系统有关人员进行交流.充分了解数据库须要完毕的任务