《数据库的设计》PPT课件.ppt

第一章,数据库的设计,课程内容回顾,数据库有哪些基本操作？ 建库 建表 加约束 创建登录帐户 基本的数据操纵语句有哪些？语法是？ 增（INSERT） 删（DELETE） 改（UPDATE） 查（SELECT） 常用的聚合函数有哪些？ 表连接分为哪几种类型？,2,课程目标,了解设计数据库的基本步骤 熟练使用T-SQL实现建库、建表、加约束 掌握T-SQL编程，实现功能强大的查询 掌握创建索引、视图，快速访问数据库 掌握创建存储过程，实现复杂的业务规则,3,本章目标,了解设计数据库的步骤 掌握如何绘制数据库的E-R图 理解数据库的规范化三大范式,4,为什么需要设计数据库,5,修建茅屋需要设计吗？,修建大厦需要设计吗？,结论：当数据库比较复杂时我们需要设计数据库,为什么需要设计数据库,良好的数据库设计 节省数据的存储空间 能够保证数据的完整性 方便进行数据库应用系统的开发,6,糟糕的数据库设计： 数据冗余、存储空间浪费 内存空间浪费 数据更新和插入的异常,软件项目开发周期,需求分析阶段：分析客户的业务和数据处理需求; 概要设计阶段：设计数据库的E-R模型图，确认需求信息的正确和完整; 详细设计阶段：将E-R图转换为多张表，进行逻辑设计，并应用数据库设计的三大范式进行审核; 代码编写阶段：选择具体数据库进行物理实现，并编写 代码实现前端应用; 软件测试阶段： 安装部署：,7,现实世界,数 据 库,软件项目开发周期,在现实开发过程中 软件产品开发周期一般由:规划,设计,实施,稳定和发布五个阶段组成, 每个阶段又都是重复的相互迭代的过程,这个过程需要多方的合作找出最佳的实践过程. 其中设计我们还能划分为概要设计与详细设计,8,软件项目开发周期,第一阶段:规划(plan) 目标:规划软件的整体架构 各部门完成标准: 1.市场开发人员 衡量市场机会提供市场机会文件(mod) 定义用户需求提供市场需求文件(mrd) 认定主要用户案例user scenarios 2.项目经理 确定产品的视觉提供产品视觉文件 确定查品功能定义,定义项目和产品的深广度 定义小组的组建计划,用户协助计划 3.产品设计和用户研究人员 概念性设计,用户界面图形化(visualize ui) 4.开发/测试人员 调查将可使用的流程,技术和工具 5.服务人员 评估潜在的用户流量 评估推行和维护此产品的可行性,9,软件项目开发周期,第二阶段:设计(design) 目标:确定如何开发 各部门完成标准 1.市场开发人员：对新功能设计提供反馈意见,完成品牌战略推荐文件 2.项目经理： 完成功能规范（functional specs）提供功能规范设计 完成由下至上的日成表 3.产品设计和用户研究人员：用户界面模型设计 4.开发人员：完成开发体系的机构设计 5.测试人员：完成总体测试计划（细化） 里程碑：规划和设计的完成是软件开发的第一个里程碑 规划和设计的迭代过程：规划的形成是经过“设计”确认，重新定位和校正， 在设计过程中重新估价可能改变规划时的决定,10,软件项目开发周期,第三个阶段：实施（implement） 主要里程碑，多个小产品周期 完成标准： 1.市场开发人员：推广计划文件，完成市场定位和咨询策略框架 完成市场推广计划蓝图 2.项目经理：修正功能规范，管理进度，风险，相关性及关系 3.产品设计和用户研究人员：冻结用户界面模型设计上的改变 4.开发人员：编写代码和修理bugs 5.测试人员：编写测试功能规范，完成测试工具和流程的准备工作 单元测试 完成编写代码（code complete）,11,软件项目开发周期,第四阶段：稳定 完成标准： 发布市场测试（bata）版 发布技术测试（bata）版 继续bug triage 达到零个bug,测试版本被内部采用 部门责任： 1.市场开发人员：完成包装。推广公关，广告计划，产品演示 2.项目经理：组织triage会议,消除程序bug 3.开发人员：修理bugs ,只在设计改变的情况下写新的代码 4.测试人员：发现bugs ,记录bugs 最后整体测试 5.服务人员：安装测试版本,12,软件项目开发周期,第五个阶段：发布 完成标准： 产品发布推广 产品售后服务 技术支持开始运作 部门责任： 1.市场人员：执行产片市场的推广计划 2.项目经理：收尾工作，筹备下一个产品 3.开发人员：修理bugs 4.测试人员：记录bugs ，做最后的测试修改 5.为用户提供售后服务，技术支持,13,软件项目开发周期注意事项,开发过程实践关键： 1.利用工作流程和相应模板书写相应的文档文件（需求文档，设计文档，测试文档） 2.评估开发周期指定详细的进度管理 3.风险无处不在不要忽略各种危险信号，不要担心失败而隐瞒实况 4.工具管理：着中重复性工作的工具开发（例如测试工具），提高开发效率 5.沟通管理：各个部门协调工作，及时通过email 会议沟通 6.bug 管理：开发测试阶段bugs 和用户实际使用过程中碰到的bugs 都要及时采集记录和处理 7.源代码管理 ：使用vss 或者css 等源代码管理软件 管理软件版本,14,软件项目开发周期,1.开发人员开发出程序，深信里面没有缺陷。 2.产品测试。发现了20个缺陷。 3.开发人员修改了其中的10个，并向测试部门解释另外10个不是真正的缺陷。 4.测试人员发现修改后的缺陷中有5个仍然有问题，并且又发现了15个新缺陷。 5.第3步和第4步重复了3遍。 6.由于市场的压力和由过度乐观的开发计划产生的仓促的产品声明，产品正式发布了。 7.用户发现了137个新缺陷。 8.最初的开发人员，兑换了他们的忠诚支票，走的无影无踪了。 9.新召集的开发团队修改了137个缺陷中的大部分，但又导致了456个新缺陷。 10.最初的开发人员从新公司给欠薪的测试部门送来了一张明信片。测试部门全体辞职。 11.公司用最近发布的带有783个缺陷的产品的利润买进股票抵制了竞争对手的恶意收购。 12.董事会带来了一位新CEO。他招聘了新的开发人员重做这个产品。 13.开发人员开发出程序，深信里面没有缺陷,15,设计数据库的步骤,收集信息： 与该系统有关人员进行交流、坐谈，充分理解数据库需要完成的任务,16,BBS论坛的基本功能： 用户注册和登录，后台数据库需要存放用户的注册信息和在线状态信息； 用户发贴，后台数据库需要存放贴子相关信息，如贴子内容、标题等； 论坛版块管理：后台数据库需要存放各个版块信息，如版主、版块名称、贴子数等；,设计数据库的步骤,标识对象（实体Entity） 标识数据库要管理的关键对象或实体,17,实体一般是名词： 用户：论坛普通用户、各版块的版主。 用户发的主贴 用户发的跟贴（回贴） 版块：论坛的各个版块信息,设计数据库的步骤,18,论坛用户 呢称 密码 电子邮件 生日 性别 用户的等级 备注信息 注册日期 状态 积分,主贴 发贴人 发贴表情 回复数量 标题 正文 发贴时间 点击数 状态 最后回复时间,回贴 贴子编号 回贴人, 回贴表情 标题 正文 回贴时间 点击数,版块 版块名称 版主 本版格言 点击率 发贴数,标识每个实体的属性（Attribute）,设计数据库的步骤,标识对象之间的关系（Relationship）,19,跟贴和主贴有主从关系：我们需要在跟贴对象中表明它是谁的跟贴； 版块和用户有关系：从用户对象中可以根据版块对象查出对应的版主用户的情况； 主贴和版块有主从关系：需要表明发贴是属于哪个版块的； 跟贴和版块有主从关系：需要表明跟贴是属于哪个版块的；,绘制E-R图,E-R（EntityRelationship）实体关系图,20,绘制E-R图,21,管理,bbsUser （用户，版主）,出生日期,昵称,版块名称,版主,bbsSection （版块）,绘制E-R图,映射基数,22,一对一,X X X X,Y Y Y Y,X X X X,Y Y Y Y,一对多,X X X X,Y Y Y,多对一,X X X X,Y Y Y Y,多对多,绘制E-R图,23,论坛E-R图,如何将E-R图转换为表,24,将各实体转换为对应的表，将各属性转换为各表对应的列 标识每个表的主键列，需要注意的是：没有主键的表添加ID编号列，它没有实际含义，用于做主键或外键，例如用户表中的“UID”列，版块表中添加“SID”列，发贴表和跟贴表中的“TID”列 在表之间建立主外键，体现实体之间的映射关系,如何将E-R图转换为表,25,UID主键,TID主键,RID主键,SID主键,如何将E-R图转换为表,26,添加各表之间的关系,数据规范化,仅有好的RDBMS并不足以避免数据冗余，必须在数据库的设计中创建好的表结构 Dr E.F.codd 最初定义了规范化的三个级别，范式是具有最小冗余的表结构。这些范式是： 第一范式(1st NF First Normal Fromate) 第二范式(2nd NFSecond Normal Fromate) 第三范式(3rd NF Third Normal Fromate),27,第一范式 (1st NF),第一范式的目标是确保每列的原子性 如果每列都是不可再分的最小数据单元（也称为最小的原子单元），则满足第一范式（1NF）,28,第一范式 (1st NF),在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。 所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。 如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。 在第一范式（1NF）中表的每一行只包含一个实例的信息。 例如，对于员工信息表，不能将员工信息都放在一列中显示，也不能将其中的两列或多列在一列中显示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表中只出现一次。 简而言之，第一范式就是无重复的列。,29,第二范式 (2nd NF),如果一个关系满足1NF，并且除了主键以外的其他列，都依赖与该主键，则满足第二范式（2NF） 第二范式要求每个表只描述一件事情,30,第二范式 (2nd NF),第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。 第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。如员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。 第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。 简而言之，第二范式就是非主属性非部分依赖于主关键字。,31,第三范式 (3rd NF),如果一个关系满足2NF，并且除了主键以外的其他列都不传递依赖于主键列，则满足第三范式（3NF）,32,第三范式 (3rd NF),满足第三范式（3NF）必须先满足第二范式（2NF）。第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。 例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。 简而言之，第三范式就是属性不依赖于其它非主属性。,33,规范化实例,假设某建筑公司要设计一个数据库。公司的业务规 则概括说明如下： 公司承担多个工程项目，每一项工程有：工程号、工程名称、施工人员等 公司有多名职工，每一名职工有：职工号、姓名、性别、职务（工程师、技术员）等 公司按照工时和小时工资率支付工资，小时工资率由职工的职务决定（例如，技术员的小时工资率与工程师不同） 公司定期制定一个工资报表，如图-1所示,34,规范化实例,35,图-1 某公司的工资表,规范化实例,36,图-2 某公司的项目工时表,规范化实例,表中包含大量的冗余，可能会导致数据异常： 更新异常 例如，修改职工号=1001的职务，则必须修改所有职工号=1001的行 添加异常 若要增加一个新的职工时，首先必须给这名职工分配一个工程。或者为了添加一名新职工的数据，先给这名职工分配一个虚拟的工程。（因为主关键字不能为空） 删除异常 例如，1001号职工要辞职，则必须删除所有职工号1001的数据行。这样的删除操作，很可能丢失了其它有用的数据,37,规范化实例,采用这种方法设计表的结构，虽然很容易产生工资报表，但是每当一名职工分配一个工程时，都要重复输入大量的数据。这种重复的输入操作，很可能导致数据的不一致性。,38,应用范式规范化设计,39,一张表描述了多件事情，如图-3所示。,图-3 函数依赖图,工程信息,员工信息,项目工时信息,应用第二范式规范化,40,图-4 应用第二范式,工程表,员工表,项目工时表,满足第三范式吗？,应用第三范式规范化,41,工程表,员工表,职务表,工程表,规范化和性能的关系,为满足某种商业目标，数据库性能比规范化数据库更重要 通过在给定的表中添加额外的字段，以大量减少需要从中搜索信息所需的时间 通过在给定的表中插入计算列（如成绩总分），以方便查询 进行规范化的同时，还需要综合考虑数据库的性能。,42,总结 1-1,在需求分析阶段，设计数据库的一般步骤为： 收集信息 标识对象 标识每个对象的属性 标识对象之间的关系 在概要设计阶段和详细设计阶段，设计数据库的步骤为： 绘制E-R图 将E-R图转换为表格 应用三大范式规范化表格,43,总结 1-2,为了设计结构良好的数据库，需要遵守一些专门的规则，称为数据库的设计范式。 第一范式（1NF）的目标：确保每列的原子性。 第二范式（2NF）的目标：确保表中的每列，都和主键相关 。 第三范式（3NF）的目标：确保每列都和主键列直接相关，而不是间接相关 。,44,