数据库设计方法与原则

1、数据库设计方法与原则数据库设计方法与原则-周波周波学习目标学习目标5.4.3.2.1.数据库设计概述数据库设计概述规范化规范化第一范式第一范式第二范式第二范式第三范式第三范式数据库设计概述数据库设计概述v 概述 这里我们思考两个问题：修建茅屋需要设计吗？修建大厦需要设计吗？结论是：当数据库比较复杂（如数据量大，表较多，业务关系复杂）时，我们需要先设计数据库。数据库设计概述数据库设计概述n良好的数据库设计能够：n节省数据的存储空间。n能够保证数据的完整性。n方便进行数据库应用系统的开发。n糟糕的数据库设计：n数据冗余、存储空间浪费。n内存空间浪费。n数据更新和插入的异常。数据库规范化数据库规范化

2、v规范化 在设计和操作维护数据库时，关键的步骤就是要确保数据正确地分布到数据库的表中。使用正确的数据结构，不仅便于对数据库进行相应的存取操作，而且可以极大地简化应用程序的其他内容（查询、窗体、报表、代码等）。正确进行表设计的正式名称就是“数据库规范化”。后面我们将通过实例来说明具体的规范化的工程。数据库规范化数据库规范化CREATE TABLE Student ( stuid INTEGER NOT NULL, -学生编号 stuname VARCHAR(200), -学生姓名 sclass VARCHAR(200),-班级名称 coursename VARCHAR(20),-课程名称 sde

3、gree FLOAT -课程分数 tname VARCHAR(20)-老师名字)请同学们结合表中的数据和结构观察这张表会存在哪些缺点。数据库规范化数据库规范化v缺点：n数据冗余、存储空间浪费。n内存空间浪费。n数据更新和插入的异常。数据库规范化数据库规范化v设计数据库的一般步骤： 收集信息。 抽取对象。 抽取每个对象的属性。 考虑对象之间的关系。 绘制E-R图。 将E-R图转换为表格。 最后应用三大范式规范化表格。下面我们以一个BBS简易论坛的数据库设计为例来看看设计数据库的步骤：数据库规范化数据库规范化v收集信息（与该系统有关人员进行交流、坐谈，充分理解数据库需要完成的任务） BBS论坛的基

4、本功能： 用户注册和登录，后台数据库需要存放用户的注册信息和在线状态信息； 用户发贴，后台数据库需要存放贴子相关信息，如贴子内容、标题等； 论坛版块管理：后台数据库需要存放各个版块信息，如版主、版块名称、贴子数等；数据库规范化数据库规范化v标识对象（标识数据库要管理的关键对象或实体） 实体一般是名词： 用户：论坛普通用户、各版块的版主。 用户发的主贴。 论用户发的跟贴（回贴）。数据库规范化数据库规范化v标识每个实体的属性（Attribute）数据库规范化数据库规范化v标志对象之间的关系（Attribute） 跟贴和主贴有主从关系：我们需要在跟贴对象中表明它是谁的跟贴。 版块和用户有关系：从用户

5、对象中可以根据版块对象查出对应的版主用户的情况。 主贴和版块有主从关系：需要表明发贴是属于哪个版块的。 跟贴和版块有主从关系：需要表明跟贴是属于哪个版块的。数据库规范化数据库规范化v绘制ER图数据库规范化数据库规范化v将ER图装换为表格 将各实体转换为对应的表，将各属性转换为各表对应的列。 标识每个表的主键列，需要注意的是：没有主键的表添加ID编号列，它没有实际含义，用于做主键或外键，例如用户表中的“UID”列，版块表中添加“SID”列，发贴表和跟贴表中的“TID”列 在表之间建立主外键，体现实体之间的映射关系 。数据库规范化数据库规范化v将ER图装换为表格数据库规范化数据库规范化v将ER图装

6、换为表格使用范式使用范式v数据库基本概念回顾： 实体：现实世界中客观存在并可以被区别的事物。比如“一个学生”、“一本书”、“一门课”等等。它也可以是虚拟的，比如说“老师与学校的关系”。 属性：实体所具有的某一特性，比如说，“性别”是“人”的一个属性。在关系数据库中，属性又是个物理概念，属性可以看作是“表的一列”。 使用范式使用范式v数据库基本概念回顾： 元组：表中的一行就是一个元组。 分量：元组的某个属性值。在一个关系数据库中，它是一个操作原子，即关系数据库在做任何操作的时候，属性是“不可分的”。否则就不是关系数据库了。 码：表中可以唯一确定一个元组的某个属性（或者属性组），如果这样的码有不止

7、一个，那么大家都叫候选码，我们从候选码中挑一个出来做老大，它就叫主码。 使用范式使用范式v数据库基本概念回顾： 主属性：一个属性只要在任何一个候选码中出现过，这个属性就是主属性。 非主属性：与上面相反，没有在任何候选码中出现过，这个属性就是非主属性。 外码：一个属性（或属性组），它不是码，但是它别的表的码，它就是外码。课堂示例一课堂示例一v范式（范式（6个）个）好了，上面已经介绍了我们掌握范式所需要的全部基础概念，下面我们就来讲范式。范式可以理解为一种规范等级，范式的包含关系。一个数据库设计如果符合第二范式，一定也符合第一范式。如果符合第三范式，一定也符合第二范式第一范式第一范式v第一范式（1

8、NF）：属性不可分。v第一范式的特点： 有主关键字 主键不能为空。 主键不能重复。 字段不可以再分。v下表是否满足第一范式?StudyNo|Name | Sex | Contact20040901 john Male Email:,phone:22245620040901 mary Famale Email: phone:123455 违反第一范式的示例违反第一范式的示例以上的表格是否又满足第一范式呢？课堂示例一课堂示例一注意：这两种情况都不满足第一范式。不满足第一范式的数据库，不是关系数据库！所以，我们在任何关系数据库管理系统中，做不出这样的“表”来。第二范式第二范式v第二范式（2NF）：非

9、主属性完全依赖于码。 定义：如果关系模式R是第一范式的，而且关系中每一个非主属性不部分依赖于主键，称R是第二范式的。所以第二范式的主要任务就是满足第一范式的前提下，消除部分函数依赖。 观察这个表格是否满足第二范式：StudyNo|Name | Sex | Email|Phone | ClassNo | ClassAddress01 john Male 222456 A楼2单元02 mary Famale 123455 A楼3第二范式的例子第二范式的例子v这个表完全满足于第一范式主键由StudyNo和ClassNo组成，这样才能定位到指定行，但是,ClassAddress部分依赖于关键字(Cla

10、ssNo-ClassAddress),所以要变为两个表：表一StudyNo|Name | Sex | Email | Phone | ClassNo 01 john Male 222456 200401 02 mary famale 123455 200402 表二ClassNo | ClassAddress200401 A楼2200402 A楼3第二范式的例子第二范式的例子再来看一个例子：违反第二范式的例子违反第二范式的例子分析：一个学生上一门课，一定在特定某个教室。所以有（学生，课程）教室一个学生上一门课，一定是特定某个老师教。所以有（学生，课程）老师一个学生上一门课，他老师的职称可以确定

11、。所以有（学生，课程）老师称一个学生上一门课，一定是特定某个教材。所以有（学生，课程）教材一个学生上一门课，一定在特定时间。所以有（学生，课程）上课时间因此（学生，课程）是一个码。然而，一个课程，一定指定了某个教材，一年级语文肯定用的是小学语文1那么就有课程教材。（学生，课程）是个码，课程却决定了教材，这就叫不完全依赖，或者说部分依赖。出现这样的情况，就不满足第二范式！思考： 那么，如果我们希望他满足第二范式，仿照刚才的例子我们应该怎样做了？违反第二范式的例子违反第二范式的例子解决：1、校长要新增加一门课程叫“微积分”，教材是大学数学，怎么办？学生还没选课，而学生又是主属性，主属性不能空，课程

12、怎么记录呢，教材记到哪呢(插入异常)2、下学期没学生学一年级语文（上）了，学一年级语文（下）去了，那么表中将不存在一年级语文（上），也就没了小学语文1。这时候，校长问：一年级语文（上）用的什么教材啊？郁闷了吧?(删除异常)3、校长说：一年级语文（上）换教材，换成大学语文。有10000个学生选了这么课，改动好大啊！改累死了郁闷了吧？（修改异常）那应该怎么解决呢？投影分解，将一个表分解成两个或若干个表。违反第二范式的例子违反第二范式的例子解决：第三范式第三范式v第三范式（3NF）（不依赖于其它非主属性消除传递依赖 ）。例:StudyNo|Name|Sex| Email|bounsLevel|bouns40901 john M 良 $100040902 mary famale 差 $600这个完全满足了第二范式,但是bounsLevel和bouns存在传递依赖。第三范式第三范式解决：更改为：表一：StudyNo|Name |Sex| Email | bouunsNo20040901 john Male 120040902 mary Famale 2表二：bounsNo | bounsLevel | bouns1 优秀 $10002 良 $600 第三范式第三范式在来看一个