欢迎光临
一个有态度、有温度的分享型博客

数据库设计遵循的准则

为了设计出冗余较小,结构合理的数据库,在设计数据库时应遵循哪些准则?

数据库设计只有遵循一定的规则,才能设计出冗余较小、结构合理的数据库,在关系数据库中,需要遵循的准则就是我们常说的三范式,要想设计出结构合理的关系型数据库,遵循3范式是最基本的要求。

在实际开发中,最常用的的三个基本准则如下:

1.第一范式—1NF(确保每列的原子性)

所谓第一范式(1NF)是指数据库表中的每一列都是不可分割的基本数据项,同一列中不能有多个值;从实体的角度来讲,就是实体不能有重复的属性或者某个属性不能有多个值。如果一个实体出现重复的属性,就可能需要重新定义一个新的实体,新的实体由重复的属性组成。第一范式(1NF)要求数据库表中的每一行只包含一个实体的信息,简而言之,第一范式就是无重复的列。在任何一个关系型数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系型数据库。
第一范式的合理性需要根据系统的实际需求来确定。比如某些数据库系统中需要用到”地址”这个属性,本来直接将”地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问”地址”属性中的”城市”部分,那么就非要将”地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储,这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式,如下表所示。

用户信息

上表所示的用户信息遵循了第一范式的要求,这样在对用户使用城市进行分类的时候就非常方便,也提高了数据库的性能。

2.第二范式—2NF(属性完全依赖于主属性)

第二范式(2NF)要求数据库表中的每个实例或行必须可以被唯一的区分,要达到这一要求,就需要保证数据库表中的每一列都需要完全依赖于主键,而不是部分依赖于主键(针对联合主键而言)。为了实现唯一的区分,通常要为表加一个列,以存储各个实例的唯一标识。例如,员工信息表加上员工编号,因为每个员工的员工编号是唯一的,因此每个员工可以被唯一的区分。这个唯一的作为唯一标识的属性列称为主关键字或者主属性、主键、主码。第二范式(2NF)是在第一范式(1NF)的基础上建立的,因此要满足第二范式(2NF)就必须先满足第一范式(1NF)。

比如要设计一个订单信息表,因为订单中可能会有多种商品,所以要将订单编号和商品编号作为数据库表的联合主键,如下表所示:

订单表

那么问题来了:这个表中的订单编号和商品编号作为联合主键,但表中的商品名称、单位、数量等信息,仅仅部分依赖于商品编号,而不是完全依赖于联合主键,因此违反了第二范式(2NF)的设计原则。

3.第三范式—3NF(属性不依赖于其他非主属性)

第三范式(3NF)是在第二范式(2NF)的基础上建立的,同样的,要满足第三范式(3NF)就必须先满足第二范式(2NF)。第三范式(3NF)要求属性不依赖于其他非主属性,目的是消除传递依赖,简而言之,第三范式(3NF)要求一个数据库表中不包含已在其他表中存在的非关键字属性信息。
比如在设计一个订单数据表的时候,可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息(比如姓名、所属公司等)的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表:

第三范式

这样查询时,就可以使用客户信息来引用客户信息表中的记录,也不必在订单信息表中多次输入客户信息的内容,减少了数据冗余。

参考文章:

  1. 数据库设计三大范式
  2. 数据库设计准则(第一、第二、第三范式说明)
  3. Oracle设计规范

— EOF — 看完了,留个脚印 ^_^

转载请注明出处:容休博客 » 数据库设计遵循的准则

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址