数据库设计三大范式

数据库设计三大范式

一个设计合理的表,能给服务器性能带来很大的提高,因此如何设计出比较合理的表就比较重要了,设计范式(范式,数据库设计范式,数据库的设计范式)是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则。在关系数据库中,这种规则 就是范式。关系数据库中的关系必须满足一定的要求,即满足不同的范式,一般我们设计数据库表的时候只要满足第三范式(3NF)就够了,下面就对这几种范式进行简单讲解。

概念

在介绍三大范式之前我们先要了解几种概念:

键字=码字,所以 主键=主码=主关键字,候选键=候选码=候选关键字

  • 候选码(候选键、关键字、关键码):能够唯一标识一条记录的最小属性集,比如成绩表中有学号、课程号,学号或者课程单独一个都不能确定一条记录,那么(学号、课程号)就是一个候选码。候选码可以1个,也可以多个。当有多个的时候,任意选一个作为主码(也就是通俗我们讲的primary key),非常像“复合主键”这个概念,因为有些表的主键是多个属性构成的,没人规定主键只能由一个属性构成啊,只是我们大多数见到的是这样罢了

  • 主码(主键):某个能够唯一标识一条记录的最小属性集(是从候选码里人为挑选的一条)

  • 主属性:主属性从候选码中来,因为候选码可能有多个,每个候选码可能包含多个属性,但只要在候选码中出现过的属性,都叫主属性

  • 非主属性:与主属性定义相反,没有在候选码中出现过的属性叫非主属性

  • 完全依赖:(x,y)->z必须由x和y一起得到z,这样的关系就称为z是(x,y)的完全依赖

  • 部分依赖:(x,y)->z且x->z或者y->z,也就是说根据x能到z或者根据y能得到z,这样的关系就称为z是(x,y)的部分依赖(非完全依赖)

  • 传递依赖:x->y y->z或(x,y)->m m->z,这样的关系称为z是x的传递依赖或者说z是(x,y)的传递依赖

三大范式介绍

第一范式(1NF)

第一范式:有主键,具有原子性,字段不可分割

  1. 每一列属性都是不可再分的属性值,确保每一列的原子性
  2. 两列的属性相近或相似或一样,尽量合并属性一样的列,确保不产生冗余数据
CREATE TABLE `user` (
  `user_id` varchar(50) NOT NULL COMMIT '人员编号',
  `name` varchar(50) DEFAULT NULL COMMENT '姓名',
  `mobile` varchar(11) DEFAULT NULL COMMENT '电话',
  `email` varchar(50) DEFAULT NULL COMMENT '邮箱',
  `address` varchar(50) DEFAULT NULL COMMENT '地址'
  PRIMARY KEY (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户表';

上面这个user表其实不满足第一范式,因为地址的话里面包含省份、市、区、街道等,假如要根据省份进行分类的话就不能完成了,我们要包装每一列的属性都是不可再分的状态,因此我们对user表重新进行拆分,满足第一范式,拆分后的表如下:

CREATE TABLE `user` (
  `user_id` varchar(50) NOT NULL COMMIT '人员编号',
  `name` varchar(50) DEFAULT NULL COMMENT '姓名',
  `mobile` varchar(11) DEFAULT NULL COMMENT '电话',
  `email` varchar(50) DEFAULT NULL COMMENT '邮箱',
  `province` varchar(50) DEFAULT NULL COMMENT '省'
  `city` varchar(50) DEFAULT NULL COMMENT '市'
  `address` varchar(50) DEFAULT NULL COMMENT '详细地址'
  PRIMARY KEY (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户表';
第二范式(2NF)

第二范式:首先满足第二范式的前提是一定要满足第一范式。如果关系模式R满足第一范式,并且R得所有非主属性都完全依赖于R的每一个候选关键属性,称R满足第二范式,简记为2NF。比如一个关系的关键码为(x,y),非主属性为z首先因为(x,y)是关键码,所以一定能得到z,如果存在x->z或者y->z则说明z是部分依赖,则不满足2NF,否则满足2NF。

简单来说就是,表中非主键列对主键列是完全依赖,要求每个表只描述一 件事情。也就是说在一个数据库表中,一个表中只能保存一种数据,不可以把多种数据保存在同一张数据库表中。

我们来看个例子:

CREATE TABLE `order_goods` (
    `order_id` VARCHAR (11) NOT NULL COMMENT '订单编号',
    `goods_id` VARCHAR ( 11 ) NOT NULL COMMENT '商品编号',
    `goods_name` VARCHAR ( 100 ) DEFAULT NULL COMMENT '商品名称',
    `price` DECIMAL ( 5, 2 ) DEFAULT NULL COMMENT '商品价格',
    `customer_name` VARCHAR ( 50 ) NOT NULL COMMENT '客户名称',
    `customer_mobile` VARCHAR ( 11 ) DEFAULT NULL COMMENT '客户电话',
PRIMARY KEY ( `order_id`, `goods_id` ) 
) ENGINE = INNODB DEFAULT CHARSET = utf8 COMMENT = '订单商品表';

因为订单中可能会有多种商品,所以要将订单编号(order_id)和商品编号(goods_id)作为数据库表的联合主键。上面这个表设计的有什么问题呢是否符合第二范式呢?显然是不符合的,商品名称、商品价格并非完全依赖于该表的主键(订单编号,商品编号),啥意思呢,也就是说我们根据商品编号能够得到商品名称和商品价格,换句话说实际上商品名称和商品价格只跟商品编号有关,因此不满足第二范式。我们将表进行拆分如下:

CREATE TABLE `goods` (
    `goods_id` VARCHAR ( 11 ) NOT NULL COMMENT '商品编号',
    `goods_name` VARCHAR ( 100 ) DEFAULT NULL COMMENT '商品名称',
    `price` DECIMAL ( 5, 2 ) DEFAULT NULL COMMENT '价格',
PRIMARY KEY (`goods_id` ) 
) ENGINE = INNODB DEFAULT CHARSET = utf8 COMMENT = '商品表';

CREATE TABLE `order` (
    `order_id` VARCHAR (11) NOT NULL COMMENT '订单编号',
    `goods_id` VARCHAR ( 11 ) NOT NULL COMMENT '商品编号',
    `customer_name` VARCHAR ( 50 ) NOT NULL COMMENT '客户名称',
    `customer_mobile` VARCHAR ( 11 ) DEFAULT NULL COMMENT '客户电话',
PRIMARY KEY ( `order_id`) 
) ENGINE = INNODB DEFAULT CHARSET = utf8 COMMENT = '订单表';
第三范式(3NF)

第三范式:首先满足第三范式必然要先满足第二范式,再者就是没有传递依赖,表中的列不存在对非主键列的传递依赖,也就是不能存在x->y y->z或(x,y)->m m->z。

CREATE TABLE `student` (
    `student_colde` VARCHAR ( 11 ) NOT NULL COMMENT '学号',
    `name` VARCHAR ( 100 ) DEFAULT NULL COMMENT '姓名',
    `age` INT ( 3 ) DEFAULT NULL COMMENT '年龄',
    `sex` VARCHAR ( 2 ) DEFAULT NULL COMMENT '性别',
    `school` VARCHAR ( 100 ) DEFAULT NULL COMMENT '所在院校',
    `address` VARCHAR ( 100 ) DEFAULT NULL COMMENT '院校地址',
    `tel` VARCHAR ( 100 ) DEFAULT NULL COMMENT '院校电话',
PRIMARY KEY ( `student_colde` ) 
) ENGINE = INNODB DEFAULT CHARSET = utf8 COMMENT = '学生表';

上面这个表我们可以看到主键是学号(student_code),其他列也就是非主键列,但是我们能根据学号->所在院校 ->院校地址,也就是说上面的表中存在传递依赖的关系,因此不符合第三范式。将上表进行改造:

CREATE TABLE `student` (
    `student_colde` VARCHAR ( 11 ) NOT NULL COMMENT '学号',
    `name` VARCHAR ( 100 ) DEFAULT NULL COMMENT '姓名',
    `age` INT ( 3 ) DEFAULT NULL COMMENT '年龄',
    `sex` VARCHAR ( 2 ) DEFAULT NULL COMMENT '性别',
    `school` VARCHAR ( 100 ) DEFAULT NULL COMMENT '所在院校',
    PRIMARY KEY ( `student_colde` ) 
) ENGINE = INNODB DEFAULT CHARSET = utf8 COMMENT = '学生表';

CREATE TABLE `school` (
    `school` VARCHAR ( 100 ) DEFAULT NULL COMMENT '所在院校',
    `address` VARCHAR ( 100 ) DEFAULT NULL COMMENT '院校地址',
    `tel` VARCHAR ( 100 ) DEFAULT NULL COMMENT '院校电话',
PRIMARY KEY ( `school` ) 
) ENGINE = INNODB DEFAULT CHARSET = utf8 COMMENT = '学校表';

总结

在我们设计数据库时,可以按照三大范式来进行设计,这样可以建立结构合理、冗余较小的数据库,但是具体设计的时候要结合实际,有时候多一些冗余字段能够对性能有所提高,通过空间换时间,因此要结合实际灵活运用。

参考博客

数据库之设计范式

数据库中1NF,2NF,3NF的判别

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,377评论 6 496
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,390评论 3 389
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 159,967评论 0 349
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,344评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,441评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,492评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,497评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,274评论 0 269
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,732评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,008评论 2 328
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,184评论 1 342
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,837评论 4 337
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,520评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,156评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,407评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,056评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,074评论 2 352

推荐阅读更多精彩内容