数据库设计方法与原则

第一范式 第一范式（1NF）：属性不可分。 第一范式的特点： 有主关键字 主键不能为空。 主键不能重复。 字段不可以再分。
下表是否满足第一范式?
StudyNo | Name | Sex | Contact 20040901 john Male Email:kkkk@ee.net,phone:222456 20040901 mary Famale Email:kkk@fff.net phone:123455
数据库规范化
将ER图装换为表格
数据库规范化
将ER图装换为表格
使用范式
数据库基本概念回顾：
实体：现实世界中客观存在并可以被区别的事 物。比如“一个学生”、“一本书”、“一门 课”等等。它也可以是虚拟的，比如说“老师 与学校的关系”。 属性：实体所具有的某一特性，比如说，“性 别”是“人”的一个属性。在关系数据库中， 属性又是个物理概念，属性可以看作是“表的 一列”。
数据库设计方法与原则
-----周波
学习目标
1.
数据库设计概述
2.
规范化
3.
第一范式
4. 第二范式 第三范式
5.
数据库设计概述
概述
这里我们思考两个问题：修建茅屋需要设计吗？ 修建大厦需要设计吗？结论是：当数据库比较 复杂（如数据量大，表较多，业务关系复杂） 时，我们需要先设计数据库。
数据库设计概述
违反第二范式的例子 解决：
第三范式 第三范式（3NF）（不依赖于其它非主属性[消除传递
依赖] ）。 例: StudyNo|Name|Sex| Email|bounsLevel|bouns 40901 john Malekkkk@ee.net 良 $1000 40902 mary famale kkk@fff.net 差 $600 这个完全满足了第二范式,但是bounsLevel和bouns存在传 递依赖。
违反第一范式的示例
以上的表格是否又满足第一范式呢？
课堂示例一 注意：这两种情况都不满足第一范式。不满 足第一范式的数据库，不是关系数据库！所 以，我们在任何关系数据库管理系统中，做 不出这样的“表”来。
第二范式 第二范式（2NF）：非主属性完全依赖于码。 定义：如果关系模式R是第一范式的，而且关 系中每一个非主属性不部分依赖于主键，称R 是第二范式的。 所以第二范式的主要任务就是满足第一范式的 前提下，消除部分函数依赖。 观察这个表格是否满足第二范式：
使用范式
数据库基本概念回顾：
主属性：一个属性只要在任何一个候选码中出 现过，这个属性就是主属性。 非主属性：与上面相反，没有在任何候选码中 出现过，这个属性就是非主属性。 外码：一个属性（或属性组），它不是码，但 是它别的表的码，它就是外码。
课堂示例一
范式（6个）
好了，上面已经介绍了我们掌握范式所需要的 全部基础概念，下面我们就来讲范式。范式可以 理解为一种规范等级，范式的包含关系。一个数 据库设计如果符合第二范式，一定也符合第一范 式。如果符合第三范式，一定也符合第二范式…
汇总
1.
自定义控件概述
2.
扩展现有控件
3.
直接从Control类继承
4. 汇总
复合控件
5.
思考：
那么，如果我们希望他满足第二范式，仿照刚才的例子我们应该怎样做了？
违反第二范式的例子 解决：
1、校长要新增加一门课程叫“微积分”，教材是《大学数 学》，怎么办？学生还没选课，而学生又是主属性，主属 性不能空，课程怎么记录呢，教材记到哪呢(插入异常) 2、下学期没学生学一年级语文（上）了，学一年级语文 （下）去了，那么表中将不存在一年级语文（上），也就 没了《小学语文1》。这时候，校长问：一年级语文（上） 用的什么教材啊？……郁闷了吧?(删除异常) 3、校长说：一年级语文（上）换教材，换成《大学语文》。 有10000个学生选了这么课，改动好大啊！改累死了…… 郁闷了吧？（修改异常） 那应该怎么解决呢？投影分解，将一个表分解成两个或若 干个表。
数据库规范化
绘制ER图
数据库规范化
将ER图装换为表格
将各实体转换为对应的表，将各属性转换为各 表对应的列。 标识每个表的主键列，需要注意的是：没有主 键的表添加ID编号列，它没有实际含义，用于 做主键或外键，例如用户表中的“UID”列，版 块表中添加“SID”列，发贴表和跟贴表中的 “TID”列 在表之间建立主外键，体现实体之间的映射关 系。
数据库规范化
CREATE TABLE Student ( stuid INTEGER NOT NULL, stuname VARCHAR(200), sclass VARCHAR(200), coursename VARCHAR(20), sdegree FLOAT tname VARCHAR(20) )
良好的数据库设计能够：
节省数据的存储空间。 能够保证数据的完整性。 方便进行数据库应用系统的开发。
糟糕的数据库设计：
数据冗余、存储空间浪费。 内存空间浪费。 数据更新和插入的异常。
数据库规范化
来自百度文库
规范化
在设计和操作维护数据库时，关键的步骤就是 要确保数据正确地分布到数据库的表中。使用 正确的数据结构，不仅便于对数据库进行相应 的存取操作，而且可以极大地简化应用程序的 其他内容（查询、窗体、报表、代码等）。正 确进行表设计的正式名称就是“数据库规范化”。 后面我们将通过实例来说明具体的规范化的工 程。
第三范式 在来看一个示例：
第三范式 有什么问题吗？想想： 1、老师升级了，变教授了，要改数据库，表中有N 条，改了N次……（修改异常） 2、没人选这个老师的课了，老师的职称也没了记 录……（删除异常） 3、新来一个老师，还没分配教什么课，他的职称 记到哪？……（插入异常） 请同学们思考，如何解决？
数据库规范化
收集信息（与该系统有关人员进行交流、 坐谈，充分理解数据库需要完成的任务）
BBS论坛的基本功能： • 用户注册和登录，后台数据库需要存放用户 的注册信息和在线状态信息； • 用户发贴，后台数据库需要存放贴子相关信 息，如贴子内容、标题等； • 论坛版块管理：后台数据库需要存放各个版 块信息，如版主、版块名称、贴子数等；
表一
StudyNo | Name | Sex | 01 john Male 02 mary famale 表二 ClassNo | ClassAddress 200401 A楼2 200402 A楼3 Email | Phone | ClassNo kkkk@ee.net 222456 200401 kkk@fff.net 123455 200402
数据库规范化
标识对象（标识数据库要管理的关键对象 或实体）
实体一般是名词： • 用户：论坛普通用户、各版块的版主。 • 用户发的主贴。 • 论用户发的跟贴（回贴）。
数据库规范化
标识每个实体的属性（Attribute）
数据库规范化
标志对象之间的关系（Attribute）
跟贴和主贴有主从关系：我们需要在跟贴对象 中表明它是谁的跟贴。 版块和用户有关系：从用户对象中可以根据版 块对象查出对应的版主用户的情况。 主贴和版块有主从关系：需要表明发贴是属于 哪个版块的。 跟贴和版块有主从关系：需要表明跟贴是属于 哪个版块的。
StudyNo | Name | Sex | Email|Phone | ClassNo | ClassAddress 01 john Male k@ee.net 222456 A楼2单元 02 mary Famale kkk@fff.net 123455 A楼3
第二范式的例子 这个表完全满足于第一范式主键由StudyNo和 ClassNo组成，这样才能定位到指定行，但是 ,ClassAddress部分依赖于关键字(ClassNo-〉 ClassAddress),所以要变为两个表：
第二范式的例子 再来看一个例子：
违反第二范式的例子 分析：
一个学生上一门课，一定在特定某个教室。所以有（学生，课程）－>教室 一个学生上一门课，一定是特定某个老师教。所以有（学生，课程）－>老师 一个学生上一门课，他老师的职称可以确定。所以有（学生，课程）－>老师 称一个学生上一门课，一定是特定某个教材。所以有（学生，课程）－>教材 一个学生上一门课，一定在特定时间。所以有（学生，课程）－>上课时间 因此（学生，课程）是一个码。 然而，一个课程，一定指定了某个教材，一年级语文肯定用的是《小学语文1》 那么就有课程－>教材。（学生，课程）是个码，课程却决定了教材，这就叫 不完全依赖，或者说部分依赖。出现这样的情况，就不满足第二范式！
--学生编号 --学生姓名 --班级名称 --课程名称 --课程分数 --老师名字
请同学们结合表中的数据和结构观察这张表会存 在哪些缺点。
数据库规范化
缺点：
数据冗余、存储空间浪费。 内存空间浪费。 数据更新和插入的异常。
数据库规范化
设计数据库的一般步骤：
– 收集信息。 – 抽取对象。 – 抽取每个对象的属性。 – 考虑对象之间的关系。 – 绘制E-R图。 – 将E-R图转换为表格。 – 最后应用三大范式规范化表格。 下面我们以一个BBS简易论坛的数据库设计为例 来看看设计数据库的步骤：
使用范式
数据库基本概念回顾：
元组：表中的一行就是一个元组。 分量：元组的某个属性值。在一个关系数据库 中，它是一个操作原子，即关系数据库在做任 何操作的时候，属性是“不可分的”。否则就 不是关系数据库了。 码：表中可以唯一确定一个元组的某个属性（ 或者属性组），如果这样的码有不止一个，那 么大家都叫候选码，我们从候选码中挑一个出 来做老大，它就叫主码。
第三范式 解决：
更改为： 表一： StudyNo|Name |Sex| Email | bouunsNo 20040901 john Male kkkk@ee.net 1 20040902 mary Famale kkk@fff.net 2
表二： bounsNo | bounsLevel | bouns 1 优秀 $1000 2 良 $600