浅谈数据库基础设计(模型、规范化、关键字、完整性)
2015-04-21 09:35
281 查看
数据库的设计,首先要将现实世界中客观存在的事物及它们所具有的特性抽象为信息世界的实体和属性,然后使用实体联系图(ER图)表示实体、属性、实体之间的联系(概念数据模型),最后再将ER图转换为数据世界中的关系(数据表)。
表1.1
如图1.1所示(这里就不画ER图了,直接用表格显示),学生和课程是多对多的关系,学生-课程 是他们的联系,这里面一共是三张表
一般的数据表具有以下特点
1 表格中的每一列都是不可再分的基本数据项。
2 每列的名字不同,数据类型相同或者兼容。
3 行的顺序、列的顺序无关紧要。
4 关系中不能存在完全相同的两行。
根据以上特点,创建图1.1中的表
表1.2 课程表
表1.3 学生表
表1.4 学生选课表
数据库创建好了,这样看着是符合上面的特点,但是从关系规范化角度来看,还有很多要改善的地方,下面说下关系规范化
关系规范化分为三个范式(第一范式、第二范式、第三范式),目的是为了消除存储异常、减少数据冗余(重复),以保证数据的完整性(正确性 一致性)和存储效率。
(上面的表中,课程名称、姓名 在两个表中重复出现,数据冗余。容易出现数据不一致的情况,如输入的课程名称不规范等)
一、第一范式,要求每个属性都是不可再分的基本数据项。
所以以上数据表满足第一范式,第一范式也是最低要求,在这个基础上继续满足第二第三范式 就可以消除数据冗余等问题。
在说第二第三范式之前,先来了解下面的两个概念
1. 函数依赖
课程编号‘1’的课程是SQL Server,可以说课程名称完全能由课程编号决定,对于每一个课程编号,就会有一个并且只有一个课程名称与它对应,则称课程名称完全函数依赖于课程编号,或者说课程编号决定了课程名称。当然 学分、教师、系部编号 也完全函数依赖于课程编号。
表1.4学生选课表,主关键字为学号和课程名称,当给出学号和课程名称时,就能唯一的确定学生的选课状态,选课状态既依赖于学号,又依赖于课程名称,所以它完全函数依赖于主键(学号和课程名称)。 当给出学号时,就可以唯一确定学号对应的学生姓名,所以姓名只依赖于主键中的学号,而与主键中课程名称无关,所以姓名部分函数依赖于主键(学号和课程名称)。
2. 函数传递依赖
表1.2中,课程编号->系部编号,系部编号->系部名称,系部名称是通过系部编号的传递而依赖课程编号的,则课程编号和系部名称之间存在函数传递依赖关系。
二、第二范式,首先是满足第一范式,而且关系中的每一个非主属性完全函数依赖于主键。
单个属性作为主关键字的比较简单,因为主关键字的作用就是能唯一标识表中的每一行,关系中的非主属性都能完全函数依赖于主关键字,这样的关系是第二范式。
对于组合属性作为主关键字,通常要判断每一个非主属性是完全函数依赖还是部分函数依赖于主关键字。
表1.2 主关键字是课程编号,其它属性完全函数依赖于课程编号,所以它属于第二范式。
表1.4主关键字(学号 课程名称),表中选课状况完全函数依赖于主关键字,姓名只依赖于学号,与课程名称无关 部分函数依赖于主关键字,所以不属于第二范式。
(对于表1.4,规范时只需将学号、姓名分离出来组成一个关系就可以了,但是学生表中已经有了学号和姓名,所以删除姓名属性即可,如表1.5)
表1.5 学生选课表
三、第三范式,首先是满足第二范式,而且关系中的任何一个非主属性都不函数传递依赖于主关键字。
在关系中,首先找到主关键字,然后判断任何一个非主属性和主关键字之间是否存在函数传递依赖关系,如果存在,则要消除函数传递依赖关系。
表1.2是第二范式,但不是第三范式,它的主关键字是课程编号,系部名称和课程编号之间通过系部编号存在函数依赖关系的传递(可将系部编号和系部名称分离出来组成一个关系)
这样1.2表就分开为系部表1.6和课程表1.7,这样就满足第三范式了
表1.6 系部表
表1.7 课程表
表1.3学生表是第三范式,但是如果要插入/修改/删除班级属性,就可能出现数据不一致的情况,所以可以将学生表分离后构成1.8班级表和1.9学生表
表1.8 班级表
表1.9 学生表
同样道理,学生选课表也应该改成如表2.1所示
表2.1 学生选课表
表1.6、1.7、1.8、1.9、2.1 都满足第三范式的条件,所以这五个表都是第三范式。
上面说的主关键字和主键是一个意思,每个表中只能有一个主键,而且必须是唯一的并且不能为空。
外关键字也就是外键,实际上就是主键的副本,它允许为空,外键是一个公共关键字(连接两个表的公共属性),使用主键和外键建立表与表之间的联系。
数据完整性
数据完整性就是数据的正确性和一致性,它反映了现实世界中实体的本来面貌,如果一个人的身高是1800CM,年龄是300岁 那么就是完整性收到破坏,因为这样毫无意义,本身也不正确。 数据完整性分为列完整性、表完整性、参照完整性。
列完整性也可以称为域完整性或用户定义完整性,是指表中任意列的数据类型必须符合用户的定义,或者数据必须在规定的有限范围内。
如系部编号长度为2,输入 1234 就不符合
表完整性也可称为实体完整性,是指表中必须有一个主关键字,且主键值不能为空。
参照完整性也称为引用完整性,是指对外键值进行插入或修改时,一定要参照主键是否存在。对主键进行修改或删除时也要参照外键是否存在。这样才能使得通过公共关键字连接的两个表保证参照完整性,也就是两个表的主关键字、外关键字数据是一致的。
学生 | 学号 | 姓名 | 班级 | ||||
学生-课程 | 学号 | 姓名 | 课程名称 | 选课状态 | |||
课程 | 课程编号 | 课程名称 | 课程类别 | 学分 | 教师 | 系部编号 | 系部名称 |
如图1.1所示(这里就不画ER图了,直接用表格显示),学生和课程是多对多的关系,学生-课程 是他们的联系,这里面一共是三张表
一般的数据表具有以下特点
1 表格中的每一列都是不可再分的基本数据项。
2 每列的名字不同,数据类型相同或者兼容。
3 行的顺序、列的顺序无关紧要。
4 关系中不能存在完全相同的两行。
根据以上特点,创建图1.1中的表
表1.2 课程表
课程编号 | 课程名称 | 课程类别 | 学分 | 教师 | 系部编号 | 系部名称 |
1 | SQL Server | 信息技术 | 3 | 李良明 | 11 | 信息工程系 |
2 | Android | 信息技术 | 3 | 王倩 | 15 | 信息工程系 |
学号 | 姓名 | 班级 |
201004120237 | 张华 | P10软件二班 |
201004120238 | 张振 | P10软件二班 |
学号 | 姓名 | 课程名称 | 选课状态 |
201004120237 | 张华 | SQL Server | 报名 |
201004120238 | 张振 | Android | 报名 |
关系规范化分为三个范式(第一范式、第二范式、第三范式),目的是为了消除存储异常、减少数据冗余(重复),以保证数据的完整性(正确性 一致性)和存储效率。
(上面的表中,课程名称、姓名 在两个表中重复出现,数据冗余。容易出现数据不一致的情况,如输入的课程名称不规范等)
一、第一范式,要求每个属性都是不可再分的基本数据项。
所以以上数据表满足第一范式,第一范式也是最低要求,在这个基础上继续满足第二第三范式 就可以消除数据冗余等问题。
在说第二第三范式之前,先来了解下面的两个概念
1. 函数依赖
课程编号‘1’的课程是SQL Server,可以说课程名称完全能由课程编号决定,对于每一个课程编号,就会有一个并且只有一个课程名称与它对应,则称课程名称完全函数依赖于课程编号,或者说课程编号决定了课程名称。当然 学分、教师、系部编号 也完全函数依赖于课程编号。
表1.4学生选课表,主关键字为学号和课程名称,当给出学号和课程名称时,就能唯一的确定学生的选课状态,选课状态既依赖于学号,又依赖于课程名称,所以它完全函数依赖于主键(学号和课程名称)。 当给出学号时,就可以唯一确定学号对应的学生姓名,所以姓名只依赖于主键中的学号,而与主键中课程名称无关,所以姓名部分函数依赖于主键(学号和课程名称)。
2. 函数传递依赖
表1.2中,课程编号->系部编号,系部编号->系部名称,系部名称是通过系部编号的传递而依赖课程编号的,则课程编号和系部名称之间存在函数传递依赖关系。
二、第二范式,首先是满足第一范式,而且关系中的每一个非主属性完全函数依赖于主键。
单个属性作为主关键字的比较简单,因为主关键字的作用就是能唯一标识表中的每一行,关系中的非主属性都能完全函数依赖于主关键字,这样的关系是第二范式。
对于组合属性作为主关键字,通常要判断每一个非主属性是完全函数依赖还是部分函数依赖于主关键字。
表1.2 主关键字是课程编号,其它属性完全函数依赖于课程编号,所以它属于第二范式。
表1.4主关键字(学号 课程名称),表中选课状况完全函数依赖于主关键字,姓名只依赖于学号,与课程名称无关 部分函数依赖于主关键字,所以不属于第二范式。
(对于表1.4,规范时只需将学号、姓名分离出来组成一个关系就可以了,但是学生表中已经有了学号和姓名,所以删除姓名属性即可,如表1.5)
学号 | 课程名称 | 选课状态 |
201004120237 | SQL Server | 报名 |
201004120238 | Android | 报名 |
三、第三范式,首先是满足第二范式,而且关系中的任何一个非主属性都不函数传递依赖于主关键字。
在关系中,首先找到主关键字,然后判断任何一个非主属性和主关键字之间是否存在函数传递依赖关系,如果存在,则要消除函数传递依赖关系。
表1.2是第二范式,但不是第三范式,它的主关键字是课程编号,系部名称和课程编号之间通过系部编号存在函数依赖关系的传递(可将系部编号和系部名称分离出来组成一个关系)
这样1.2表就分开为系部表1.6和课程表1.7,这样就满足第三范式了
系部编号 | 系部名称 |
11 | 信息工程系 |
15 | 信息工程系 |
课程编号 | 课程名称 | 课程类别 | 学分 | 教师 | 系部编号 |
1 | SQL Server | 信息技术 | 3 | 李良明 | 11 |
2 | Android | 信息技术 | 3 | 王倩 | 15 |
表1.3学生表是第三范式,但是如果要插入/修改/删除班级属性,就可能出现数据不一致的情况,所以可以将学生表分离后构成1.8班级表和1.9学生表
班级编号 | 班级名称 | 系部编号 |
P10 | P10软件二班 | 11 |
P11 | P11软件二班 | 11 |
学号 | 姓名 | 班级编号 |
201004120237 | 张华 | P10 |
201004120238 | 张振 | P10 |
同样道理,学生选课表也应该改成如表2.1所示
学号 | 课程名称 | 选课状态 |
201004120237 | 1 | 报名 |
201004120238 | 2 | 报名 |
表1.6、1.7、1.8、1.9、2.1 都满足第三范式的条件,所以这五个表都是第三范式。
上面说的主关键字和主键是一个意思,每个表中只能有一个主键,而且必须是唯一的并且不能为空。
外关键字也就是外键,实际上就是主键的副本,它允许为空,外键是一个公共关键字(连接两个表的公共属性),使用主键和外键建立表与表之间的联系。
数据完整性
数据完整性就是数据的正确性和一致性,它反映了现实世界中实体的本来面貌,如果一个人的身高是1800CM,年龄是300岁 那么就是完整性收到破坏,因为这样毫无意义,本身也不正确。 数据完整性分为列完整性、表完整性、参照完整性。
列完整性也可以称为域完整性或用户定义完整性,是指表中任意列的数据类型必须符合用户的定义,或者数据必须在规定的有限范围内。
如系部编号长度为2,输入 1234 就不符合
表完整性也可称为实体完整性,是指表中必须有一个主关键字,且主键值不能为空。
参照完整性也称为引用完整性,是指对外键值进行插入或修改时,一定要参照主键是否存在。对主键进行修改或删除时也要参照外键是否存在。这样才能使得通过公共关键字连接的两个表保证参照完整性,也就是两个表的主关键字、外关键字数据是一致的。
相关文章推荐
- 运维角度浅谈MySQL数据库优化一个成熟的数据库架构并不是一开始设计就具备高可用、高伸缩等特性的,它是随着用户量的增加,基础架构才逐渐完善。这篇博文主要谈MySQL数据库发展周期中所面临的问题及优化方
- 数据库设计 基础概念:概念模型、逻辑模型、物理模型、实体、联系等
- EF基础知识小记四(数据库=>模型设计器)
- 数据库设计 范式 规范化实例
- 浅谈12306核心模型设计思路和架构设计
- 规范化-数据库设计原则
- 浅谈数据库设计技巧
- 浅谈REDIS数据库的键值设计
- 数据库基础-数据模型
- [读书笔记] 数据库设计基础
- 数据库基础:关系模型
- 浅谈数据库设计技巧
- 数据库物理模型设计的其他模式之单表模式
- 浅谈REDIS数据库的键值设计
- 关系数据库设计规范化流程
- [1] 数据库字段的规范化设计和冗余化设计
- 基于E-R模型的关系型数据库设计方法
- 浅谈数据库设计技巧(上)(转载)
- 黑马程序员——Java基础:static关键字、单例设计模式
- [导入]数据库物理模型设计的其他模式之自联结模式