① 书店销售管理系统数据库设计目的和意义
学号 1
课 程 设 计课程名称 《数据库系统原理》课程设计
题 目 书店销售管理系统
专 业
班 级
姓 名
成 绩
指 导 老 师
2019 年 12 月 30 日至 2019 年 1月 3日一、课程设计目的与任务《数据库系统原理课程设计》是针对计算机专业基础课《数据库系统原理》开设的课程设计，目的是使学生通过本课程设计之后，对数据库设计的基本概念、基本原理和优化技术有较全面的了解和领会，并能操作当前流行的DBMS，了解数据库在计算机应用系统的作用，独立地开发实现一个小型的基于DBMS上的应用系统。结合具体的开发案例，理解并初步掌握数据库系统需求分析、概念结构设计、逻辑结构设计、物理结构设计、应用功能设计（视图，索引，游标，存储过程，触发器等）数据录入及测试等系统设计与系统实施及维护管理的主要环节和步骤以及软件文档的制作能力。二、课程设计的题目与基本要求1．设计题目：书店销售管理系统数据库设计2.基本要求：（1）图书入库管理：维护入库图书信息（如图书编号、书名、作者、价格、图书分类、出版社等），自动计算库存。（2）图书查询统计：按图书分类，出版社、书名、作者等条件查询图书的详细信息。（3）销售管理： 销售过的图书都记录在销售列表中，方便统计收入。图书销售后，实时记录图书库存，按每天统计销售额、按每个月或季度统计销售额，并能根据销售数量统计生成畅销书名单。（4）设计报告内容包括：基本原理、设计方案的选择与确定，详细的设计过程及结果做出评价，分析存在的问题，提出改进意见并写出心得体会。三、学时分配进度安排
序号 设计内容 所用时间
1 选题及调研 1天
2 数据库结构设计 1天
3 数据库查询优化 1天
4 调试及撰写报告 1天
5 答辩 1天
合 计 1周
四、课程设计考核及评分标准1.设计报告要求课程设计报告要求逻辑清晰、层次分明、书写整洁。格式包括标题、提要、正文（包括①设计项目要求与说明。②数据模型分析。③软件流程分析。④调试分析。⑤实验数据分析。⑥答辩。⑦成绩评定。）附录(图纸、程序清单或软盘)。设计报告须每人一份，独立完成。2.图纸要求系统结构框图、概念模型图等。3.评分标准
评分依据 评分成绩
1．设计方案正确，具有可行性、创新性 30分
2．数据库测试性能达到任务书要求 25分
3．设计报告的规范化、内容充实、参考文献 15分
4．答辩 20分
5．平时成绩（考勤等） 10分
总分 100分
注：成绩等级：优（90分—100分）、良（80分—89分）、中（70分—79分）、及格（60分—69分）、60分以下为不及格。五、指导时间
周次 星期一 星期二 星期三 星期四 星期五
第17周 第3-4节 第3-4节 第3-4节 第3-4节
地点 233 231 现教 现教
1.引言Internet的迅速发展正以前所未有的深度和广度影响和改善着人类生活的各个方面，越来越多的人开始意识到Internet所起到的重大作用随着书店规模的不断扩大，员工人数的不断增多，使得书店管理的手工操作管理模式的局限性越发突出.本书店管理系统应用了科学的管理模式对员工.书籍.订单信息进行管理和维护，并且还提供了给类报表的打印,使原本非常复杂的手工管理变得简洁明了。计算机信息管理技术的应用，除了能在相当大的程度.上代替人工作业，从而减少人员工作量，减轻工作负担，减少工作中因人为原因而产生的错误从而避免不必要的损失外，更重要的是能建立准确畅通、简便的信息流通渠道，为工作提供所需要的准确、及时的信息以帮助做出正确而及时的选择与决定，从而给采用这门]技术的单位带来了巨大的可见或不可见的利益与效益。2.需求阶段分析2.1需求分析书店管理系统是适应时代发展的需要,提高管理的效率而开发设计的。通过对信息的收集、存储、传递、统计、分析、综合查询、报表输出和信息共享，及时为书店管理人员提供全面、准确的各种数据。实现了书店管理的简单化和规划化，提高了书店的工作效率，从而使书店能够以少的投入获得更好的社会效益与经济效益。2.2数据分析顾客表：应包含顾客号，顾客姓名以及顾客联系方式订单表：应包含订单号，销售图书号，销售数量，金额以及日期图书表：应包含图书编号，图书名，作者，单价，类别和出版社库存表：应包含图书编号，总量和余量2.3功能分析数据库应实现的功能有：（1）图书入库管理：维护入库图书信息（如图书编号、书名、作者、价格、图书分类、出版社等），自动计算库存。（2）按图书分类，出版社、书名、作者等条件查询图书的详细信息。（3）销售过的图书都记录，并且能显示每种图书的销售量，将销售量高的图书定为热销书，能够查询出某一天到某一天的销售额以及订单消息2.3.1书籍管理功能系统设置包括图书名称设置、书籍编号、书籍出版社、书籍价格、书籍类别。基本信息管理模块可以实现添加和重置书籍信息功能。
2.3.2订单管理功能系统设置包括顾客姓名设置、订单日期设置、订单编号设置、订单数量设置、订单金额设置。基本信息管理模块可以实现对订单的查询。2.3.3顾客管理功能系统设置包括顾客编号设置、顾客姓名设置、顾客联系方式设置。基本信息管理模块可以实现对顾客的查询。2.3.4库存管理功能系统设置包括图书编号、图书总量、图书余量设置。基本信息管理模块可以实现对图书数量的查询2.4安全性和完整性要求（1）安全性要求 ：系统安全性要求体现在数据库安全性、信息安全性和系统平台的安全性等方面。安全性先通过视图机制，不同的用户只能访问系统授权的视图，这样可提供系统数据一定程度上的安全性，再通过分配权限、设置权限级别来区别对待不同操作者对数据库的操作来提高数据库的安全性；系统平台的安全性体现在操作系统的安全性、计算机系统的安全性和网络体系的安全性等方面。（2）完整性要求：系统完整性要求系统中数据的正确性以及相容性。可通过建立主、外键，使用check约束，或者通过使用触发器和级联更新。3 .结构设计3.1总体功能模块图图3.13.2书籍信息模块图图3.23.3订单信息模块图图3.33.4顾客信息模块图图3.43.5数据字典表3.5.1顾客表
列名 数据类型 约束
顾客号（Gno） Char（7） primary key
姓名（Gname） Nchar（20） Not null
联系方式（Gnumber） Char（20）
表3.5.2订单表
列名 数据类型 约束
订单号（Dno） Char（7） primary key
购买图书号（Bno） Char（7） primary key
购买数量（Dshul） Int Not null
金额（Dmoney） Int Not null
日期（Dtime） Smalldatetime Not null
顾客号（Gno） Char（7） External code
表3.5.3 图书表
列名 数据类型 约束
编号（Bno） Char（7） primary key
书名（Bname） nchar (20) not null
作者（Bwriter） nchar (20) not null
价格（Bjiage） Int not null
类别（Bleibie） nchar (20) not null
出版社（Bcbs） nchar (20) not null
表3.5.4库存表
列名 数据类型 约束
编号（Bno） Char（7） Primary key
总量（Kzong） Int Not null
余量（Kyu） Int
3.6 ER图设计3.6..1顾客ER图3.6.2 图书ER图图3.6.3图3.6.4图3.6.54 逻辑结构设计4.1 关系模型顾客与订单是1：m类型 订单与库存是1：1类型 库存与图书是1：m类型 关系模型如下：顾客表（顾客号、姓名、联系方式）订单表（订单号、购买图书号、购买数量、金额、日期、顾客号）图书表（编号、书名、作者、价格、类别、出版社）库存表（编号、总量、余量）（——代表主键，...代表外码）4.2 函数依赖在顾客表中，顾客号是主码，其它属性完全依赖于顾客号在订单表中，订单号是主码，顾客号是外码，其余属性完全依赖于订单号在图书表中，编号是主码，其余属性完全依赖于编号在库存表中，编号是主码，其余属性完全依赖于编号5.物理结构设计5.1创建图书表use books /*创建图书表*/create table book(Bno char (7) primary key,Bname nchar (20) not null,Bwirter nchar (20) not null,Bjiage int not null,Bleibie nchar (20) not null,Bcbs nchar (20) not null,）5.2 创建顾客表use books /* 创建顾客表*/create table guke(Gno char(7) primary key,Gname nchar (20) not null,Gnumber char(20),）5.3创建库存表use books /*创建库存表*/Create table kucun(Bno char(7) primary key,
Kzong int not null,Kyu int,)5.4创建订单表use books /*创建订单表*/Create table Dingdan(Dno char(7) primary key,Bno char(7) primary key,Dshul int not null,Dmoney int not null,Dtime smalldatetime not null,Gno char(10) not null,)6 数据库的实施6.1 给各个表添加数据例use books /*给图书表添加一行数据*/insert into bookvalues('101','白夜行','东野圭吾','30','侦探','天空出版社')使用语句添加完数据的表如下：6.1.1图书表6.1.2订单表6.1.3 顾客表6.1.4库存表6.2创建存储过程6.2.1图书的存储过程create proc tushu@Bno char(7),@Bname nchar(20),@Bwirter nchar(20),@Bjiage int, @Bleibie nchar(20),@Bcbs nchar(20),@MM INTasif not exists (select * from bookwhere Bno=@Bno)BEGINinsert into bookvalues (@Bno,@Bname,@Bwirter,@Bjiage,@Bleibie,@Bcbs)INSERT INTO KucunVALUES (@Bno,@MM,@MM)ENDELSEBEGINUPDATE KucunSET Kzong=KZONG+@MMWHERE BNO=@BNOUPDATE KucunSET KYU=KYU+@MM
WHERE BNO=@BNOEND图5.2.16.2.2顾客的存储过程create proc gukecun@Gno char(7),@gname nchar(10),@gnumber nchar(20)asinsert into gukevalues (@Gno,@gname,@gnumber )图5.2.26.2.3 订单的存储过程create proc dingdan@dno char(10),@Bno char(10),@Dshul int,@Dtime smalldatetime, @Gno char(10)asdeclare @Dmoney intselect @Dmoney=@Dshul*Bjiagefrom book,Dingdaninsert into Dingdanvalues (@dno,@Bno,@Dshul,@Dmoney,@Dtime,@Gno)图5.2.36.3 创建触发器针对图书信息表创建一个触发器，当向表book插入一条信息时，自动显示表中book中的记录create trigger 插入显示on bookfor insertasSelect * from bookInsert into book values('115','幻想之城','中此撒','30','悬疑','飒飒我出版社')6.4 建立视图6.4.1建立视图建立一个图书类别为侦探的视图，包括图书编号，图书名，作者，单价以及图书总量和余量create view v_leibieasselect book.Bno ,bname,bwirter,bjiage,kzong,kyufrom book,Kucunwhere book.Bno =Kucun.Bno and Bleibie ='侦探'图6.4.1图6.4.26.5 调试运行6.5.1查询姓张的顾客的购买记录select * from Dingdan
where Gno in (select Gno from gukewhere Gname like '张%')图6.5.16.5.2 添加一条图书信息后图书表以及库存表的显示exec tushu'115','幻想之城','中此撒','30','悬疑','飒飒我出版社','60'图6.5.2图6.5.36.5.3 查询销售量在10本以上的书，以此为畅销书select SUM(dshul),bnofrom Dingdangroup by Bnohaving SUM(Dshul)>10图6.5.46.5.4查询某一天的销售额select sum (Dmoney )总金额 from Dingdanwhere Dtime between '2019-11-01 'and '2019-11-02'图6.5.57.设计体会一个个星期的时间非常快就过去了，这一个星期不敢说自己有多大的进步。获得了多少如识，但起码是了解了项目开发的部分过程。虽说上过数据库的课程，但是没有亲身经历过相关的设计工作细节。这次课程设计刚好提供了一个很好的机会。通过这次课程设计发现这其中需要的很多知识我们都接触过，去图书馆查资料的时侯发现我们前边所学到的仅仅是皮毛还有很多需要我们掌握的东西我们根本不知道。同时也发现有很多已经学过的东西我们没有理解到位，不能灵活运用于实际，不能很好的用来解决问题，这就需要我们不断的大量的实践，通过不断的自学，不断地发现问题，思考问题，进而解决问题。在这个过程中我们将深刻理解所学知识，同时也可以学到不少很实用的东西。本次课程设计即将结束，我完成了自己所选的课题。通过完成这次课程设计，我加深了对相关知识的理解，加强了知识之间的联吊，促进了知识的迁移和应用。从需求分析、概念结构设计、逻辑结构设计、物理结构设计。亲身体验了一回系统的设计开发过程。很多东西书上写的很清楚，貌似看着也很简单，思路非常清晰。但真正需要自己想办法去设计一个系统的时候才发现其中的难度。经常做到后面突然就发现自己-开始的设计有问题，然后又回去翻工在各种反复中不断完善自己的想法。
致谢在这次数据库的课程设计过程中，我选择了书店销售管理系统的设计与实现。该系统能够顺利的完成，得益于老师的悉心指导和同学的帮助。更重要的是老师帮我们解决了许多技术的难题，以至于我们能够将书店销售管理系统的功能做得尽可能的完善。在这过程中，我周围的同学给了我许多启发，让我把书店销售管理系统设计的更加完善，老师渊博的知识、开阔的视野和敏锐的思维给了我深深的启迪，使我不仅了解到许多新知识、开阔了视野，更提高了自身的数据库设计能力。另外，感谢老师给我们提供这样-一个课程设计的机会，使我们在学得专业知识的基础上能够自己动手并独立地完成数据库的设计与开发，使我们能够更多的学习-些实践应用知识，增强实际操作和动手应用能力。最后，我再一次感谢在整个课程设计期间，在各个方面给予我们帮助的老师和同学，正是因为有了你们的帮助，才使我们的课程设计得以顺利完成。参考文献[1]李彦，韩光林，李玉波. sql SERVE完全自学手册[M].北京:电子工业出版社,2007[2]萨师煊，王珊.数据库系统概论.北京:高等教育出版社.2005[3]Y.Daniel Liang.Java.万波. JAVA语言程序设计[M].第六版.北京:机械工业出版社，2008[4]《数据库原理及应用》 ，钱雪忠主编，北京邮电大学出版社，2007，第二版[5]《SQL server 2000数据仓库与Analysis Services》，Bain T着 ，中国电力出版社， 2003[6]《数据库技术与联机分析处理》 王珊主编，北京科学出版社，1998课程设计成绩评定表
课程设计题目 书店销售管理系统
课程设计学生答辩或质疑记录：
评 分 依 据 分 值 评分成绩
1．设计方案正确，具有可行性、创新性 30 分
2．系统调试与结果（系统功能正确、软件程序完整） 25分
3．设计报告的规范化、内容充实、参考文献 15分
4．平时成绩（考勤等） 10分
5．答辩 20分
总 分 100分
最终评定等级为：指导老师签字： 年 月 日
￥
5.9
网络文库VIP限时优惠现在开通,立享6亿+VIP内容
立即获取
书店销售管理系统数据库设计
学号 1
课 程 设 计
课程名称 《数据库系统原理》课程设计
题 目 书店销售管理系统
专 业
班 级
姓 名
成 绩
指 导 老 师
2019 年 12 月 30 日至 2019 年 1月 3日
一、课程设计目的与任务
第 1 页
《数据库系统原理课程设计》是针对计算机专业基础课《数据库系统原理》开设的课程设计，目的是使学生通过本课程设计之后，对数据库设计的基本概念、基本原理和优化技术有较全面的了解和领会，并能操作当前流行的DBMS，了解数据库在计算机应用系统的作用，独立地开发实现一个小型的基于DBMS上的应用系统。结合具体的开发案例，理解并初步掌握数据库系统需求分析、概念结构设计、逻辑结构设计、物理结构设计、应用功能设计（视图，索引，游标，存储过程，触发器等）数据录入及测试等系统设计与系统实施及维护管理的主要环节和步骤以及软件文档的制作能力。
② 请大伙给我解释一下数据库设计的基本原则！
数据库设计的三范式所谓范式，是关系型数据库关系模式规范化的标准，从规范化的宽松到严格，分别为不同的范式，通常使用的有第一范式、第二范式、第三范式及BC范式等。范式是建立在函数依赖基础上的。
函数依赖
定义：设有关系模式R(U)，X和Y是属性集U的子集，函数依赖是形为X→Y的一个命题，对任意R中两个元组t和s，都有t[X]=s[X]蕴涵t[Y]=s[Y]，那么FD X→Y在关系模式R(U)中成立。X→Y读作‘X函数决定Y’，或‘Y函数依赖于X’。通俗的讲，如果一个表中某一个字段Y的值是由另外一个字段或一组字段X的值来确定的，就称为Y函数依赖于X。函数依赖应该是通过理解数据项和企业的规则来决定的，根据表的内容得出的函数依赖可能是不正确的。
第一范式（1NF）
定义：如果关系模式R的每个关系r的属性都是不可分的数据项，那么就称R是第一范式的模式。
简单的说，每一个属性都是原子项，不可分割。1NF是关系模式应具备的最起码的条件，如果数据库设计不能满足第一范式，就不称为关系型数据库。关系数据库设计研究的关系规范化是在1NF之上进行的。
第二范式（2NF）
定义：如果关系模式R是1NF，且每个非主属性完全函数依赖于候选键，那么就称R是第二范式。
简单的说，第二范式要满足以下的条件：首先要满足第一范式，其次每个非主属性要完全函数依赖与候选键，或者是主键。也就是说，每个非主属性是由整个主键函数决定的，而不能由主键的一部分来决定。举个例子：
有股票日行情表的主键是股 票代码和交易日期组成。非主属性中有收盘价和成交量等，都是由主键，即股票代码和交易日期函数决定的，单独的股票代码或者交易日期都不能函数决定这些非主 属性。如果这个表中有非主属性股票简称，则股票简称是可以由股票代码来函数决定的，这样股票简称这个非主属性就不是完全函数依赖于候选键，这样的设计就不 满足第二范式。
第三范式（3NF）
定义：如果关系模式R是2NF，且关系模式R（U，F）中的所有非主属性对任何候选关键字都不存在传递依赖，则称关系R是属于第三范式。
简单的说，第三范式要满足以下的条件：首先要满足第二范式，其次非主属性之间不存在函数依赖。由于满足了第二范式，表示每个非主属性都函数依赖于主键。如果非主属性之间存在了函数依赖，就会存在传递依赖，这样就不满足第三范式。
举 个例子：在股票基本情况表中，主键是股票代码，有非主属性所属一级行业和所属二级行业。根据业务规则，所属二级行业能够函数决定所属一级行业，这就表示存 在这样一种关系：股票代码函数决定所属二级行业，所属二级行业函数决定所属一级行业，这就形成了传递依赖，这样的设计就不符合第三范式。不过在实际运用 中，为查询和使用的方便，有时也会违反第三范式。如上例，如果没有所属一级行业的属性，需要查询所属一级行业的相关股票，需要查询时使用函数来从二级行业 中函数生成所属一级行业，使用性能上会受影响。所以通常会加上所属一级行业的属性。
BC范式（BCNF）
BC范式是第三范式的增强版，不过也有人说是直接从1NF发展过来的，即每个属性，包括主属性或非主属性，都完全依赖于候选键，并且不存在传递依赖情况。
③ 数据仓库和传统数据库的区别和联系是什么
首先我们来了解数据仓库和数据库分别是什么：
1、数据库:是一种逻辑概念，用来存放数据的仓库，通过数据库软件来实现。数据库由很多表组成，表是二维的，一张表里面有很多字段。字段一字排开，对数据就一行一行的写入表中。数据库的表，在于能够用二维表现多维的关系。如：oracle、DB2、MySQL、Sybase、MSSQL Server等。
2、数据仓库：是数据库概念的升级。从逻辑上理解，数据库和数据仓库没有区别，都是通过数据库软件实现存放数据的地方，只不过从数据量来说，数据仓库要比数据库更庞大德多。数据仓库主要用于数据挖掘和数据分析，辅助领导做决策；
区别主要总结为以下几点：
1.数据库只存放在当前值，数据仓库存放历史值；
2.数据库内数据是动态变化的，只要有业务发生，数据就会被更新，而数据仓库则是静态的历史数据，只能定期添加、刷新；
3.数据库中的数据结构比较复杂，有各种结构以适合业务处理系统的需要，而数据仓库中的数据结构则相对简单；
4.数据库中数据访问频率较高，但访问量较少，而数据仓库的访问频率低但访问量却很高；
5.数据库中数据的目标是面向业务处理人员的，为业务处理人员提供信息处理的支持，而数据仓库则是面向高层管理人员的，为其提供决策支持；
6.数据库在访问数据时要求响应速度快，其响应时间一般在几秒内，而数据仓库的响应时间则可长达数几小时
④ 数据库设计的根本目的是什么
数据库设计的根本目标是要解决
A）数据共享问题 B）数据安全问题
C）大量数据存储问题 D）简化数据维护
一般书上很少这么提，大家在答这个题的时候，可以从数据库的概念上入手，数据库设计的根本目标是要解决应该是共享问题。四个答案可以做一些比较，最好的答案应该是A答案。你可以看一下数据库的概念，一般数据库是长期存储在计算机内有组织的可共享的数据集合。还有一个线索，数据库设计的六个阶段，每一个阶段主要做什么，或者是大家看数据库的一些范式，这个范式主要解决什么问题。从这一题大家一定要注意二级考试的公共基础知识，很多地方都考最根本，最主要的地方。
*************************
以上是转载的资料
呵呵，说一下我的理解：
数据库设计的目的即设计目标从根本上来说就是要实现数据的共享和安全存取，从细化及技术上来说，一个优秀的数据库设计必须要最终实现用户对于数据共享的具体要求，必须要在满足于用户的数据存取要求的基础上实现对于数据的关联性及优化，必须实现数据的安全性及可移植性，以保证用户数据能够简单的进行移植，必须要实现数据库的可扩容性结构以保证数据库对于用户未来数据要求的兼容性等等
⑤ 数据库与数据仓库的本质差别是什么
数据库与数据仓库的本质差别如下：
1、逻辑层面/概念层面：数据库和数据仓库其实是一样的或者及其相似的，都是通过某个数据库软件，基于某种数据模型来组织、管理数据。但是，数据库通常更关注业务交易处理（OLTP），而数据仓库更关注数据分析层面（OLAP），由此产生的数据库模型上也会有很大的差异。
2、数据库通常追求交易的速度，交易完整性，数据的一致性等，在数据库模型上主要遵从范式模型（1NF，2NF，3NF等），从而尽可能减少数据冗余，保证引用完整性；而数据仓库强调数据分析的效率，复杂查询的速度，数据之间的相关性分析，所以在数据库模型上，数据仓库喜欢使用多维模型，从而提高数据分析的效率。
3、产品实现层面：数据库和数据仓库软件是有些不同的，数据库通常使用行式存储，如SAP ASE，Oracle, Microsoft SQL Server，而数据仓库倾向使用列式存储，如SAP IQ，SAP HANA。
⑥ 数据库设计过程中，对于大批量的数据如何进行数据库优化
实例讲解MYSQL数据库的查询优化技术
作者：佚名 文章来源：未知 点击数：2538 更新时间：2006-1-19
数据库系统是管理信息系统的核心，基于数据库的联机事务处理（OLTP）以及联机分析处理(OLAP)是银行、企业、政府等部门最为重要的计算机应用之一。从大多数系统的应用实例来看，查询操作在各种数据库操作中所占据的比重最大，而查询操作所基于的SELECT语句在SQL语句中又是代价最大的语句。举例来说，如果数据的量积累到一定的程度，比如一个银行的账户数据库表信息积累到上百万甚至上千万条记录，全表扫描一次往往需要数十分钟，甚至数小时。如果采用比全表扫描更好的查询策略，往往可以使查询时间降为几分钟，由此可见查询优化技术的重要性。
笔者在应用项目的实施中发现，许多程序员在利用一些前端数据库开发工具（如PowerBuilder、Delphi等）开发数据库应用程序时，只注重用户界面的华丽，并不重视查询语句的效率问题，导致所开发出来的应用系统效率低下，资源浪费严重。因此，如何设计高效合理的查询语句就显得非常重要。本文以应用实例为基础，结合数据库理论，介绍查询优化技术在现实系统中的运用。
分析问题
许多程序员认为查询优化是DBMS（数据库管理系统）的任务，与程序员所编写的SQL语句关系不大，这是错误的。一个好的查询计划往往可以使程序性能提高数十倍。查询计划是用户所提交的SQL语句的集合，查询规划是经过优化处理之后所产生的语句集合。DBMS处理查询计划的过程是这样的：在做完查询语句的词法、语法检查之后，将语句提交给DBMS的查询优化器，优化器做完代数优化和存取路径的优化之后，由预编译模块对语句进行处理并生成查询规划，然后在合适的时间提交给系统处理执行，最后将执行结果返回给用户。在实际的数据库产品(如Oracle、Sybase等)的高版本中都是采用基于代价的优化方法，这种优化能根据从系统字典表所得到的信息来估计不同的查询规划的代价，然后选择一个较优的规划。虽然现在的数据库产品在查询优化方面已经做得越来越好，但由用户提交的SQL语句是系统优化的基础，很难设想一个原本糟糕的查询计划经过系统的优化之后会变得高效，因此用户所写语句的优劣至关重要。系统所做查询优化我们暂不讨论，下面重点说明改善用户查询计划的解决方案。
解决问题
下面以关系数据库系统Informix为例，介绍改善用户查询计划的方法。
1．合理使用索引
索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构。索引的使用要恰到好处，其使用原则如下：
●在经常进行连接，但是没有指定为外键的列上建立索引，而不经常连接的字段则由优化器自动生成索引。
●在频繁进行排序或分组（即进行group by或order by操作）的列上建立索引。
●在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。比如在雇员表的“性别”列上只有“男”与“女”两个不同值，因此就无必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度。
●如果待排序的列有多个，可以在这些列上建立复合索引（compound index）。
●使用系统工具。如Informix数据库有一个tbcheck工具，可以在可疑的索引上进行检查。在一些数据库服务器上，索引可能失效或者因为频繁操作而使得读取效率降低，如果一个使用索引的查询不明不白地慢下来，可以试着用tbcheck工具检查索引的完整性，必要时进行修复。另外，当数据库表更新大量数据后，删除并重建索引可以提高查询速度。
2．避免或简化排序
应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤。以下是一些影响因素：
●索引中不包括一个或几个待排序的列；
●group by或order by子句中列的次序与索引的次序不一样；
●排序的列来自不同的表。
为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表（尽管有时可能影响表的规范化，但相对于效率的提高是值得的）。如果排序不可避免，那么应当试图简化它，如缩小排序的列的范围等。
3．消除对大型表行数据的顺序存取
在嵌套查询中，对表的顺序存取对查询效率可能产生致命的影响。比如采用顺序存取策略，一个嵌套3层的查询，如果每层都查询1000行，那么这个查询就要查询10亿行数据。避免这种情况的主要方法就是对连接的列进行索引。例如，两个表：学生表（学号、姓名、年龄……）和选课表（学号、课程号、成绩）。如果两个表要做连接，就要在“学号”这个连接字段上建立索引。
还可以使用并集来避免顺序存取。尽管在所有的检查列上都有索引，但某些形式的where子句强迫优化器使用顺序存取。下面的查询将强迫对orders表执行顺序操作：
SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008
虽然在customer_num和order_num上建有索引，但是在上面的语句中优化器还是使用顺序存取路径扫描整个表。因为这个语句要检索的是分离的行的集合，所以应该改为如下语句：
SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001
UNION
SELECT ＊ FROM orders WHERE order_num=1008
这样就能利用索引路径处理查询。
4．避免相关子查询
一个列的标签同时在主查询和where子句中的查询中出现，那么很可能当主查询中的列值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。
5．避免困难的正规表达式
MATCHES和LIKE关键字支持通配符匹配，技术上叫正规表达式。但这种匹配特别耗费时间。例如：SELECT ＊ FROM customer WHERE zipcode LIKE “98_ _ _”
即使在zipcode字段上建立了索引，在这种情况下也还是采用顺序扫描的方式。如果把语句改为SELECT ＊ FROM customer WHERE zipcode >“98000”，在执行查询时就会利用索引来查询，显然会大大提高速度。
另外，还要避免非开始的子串。例如语句：SELECT ＊ FROM customer WHERE zipcode[2，3]>“80”，在where子句中采用了非开始子串，因而这个语句也不会使用索引。
6．使用临时表加速查询
把表的一个子集进行排序并创建临时表，有时能加速查询。它有助于避免多重排序操作，而且在其他方面还能简化优化器的工作。例如：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
AND cust.postcode>“98000”
ORDER BY cust.name
如果这个查询要被执行多次而不止一次，可以把所有未付款的客户找出来放在一个临时文件中，并按客户的名字进行排序：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
ORDER BY cust.name
INTO TEMP cust_with_balance
然后以下面的方式在临时表中查询：
SELECT ＊ FROM cust_with_balance
WHERE postcode>“98000”
临时表中的行要比主表中的行少，而且物理顺序就是所要求的顺序，减少了磁盘I/O，所以查询工作量可以得到大幅减少。
注意：临时表创建后不会反映主表的修改。在主表中数据频繁修改的情况下，注意不要丢失数据。
7．用排序来取代非顺序存取
非顺序磁盘存取是最慢的操作，表现在磁盘存取臂的来回移动。SQL语句隐藏了这一情况，使得我们在写应用程序时很容易写出要求存取大量非顺序页的查询。
有些时候，用数据库的排序能力来替代非顺序的存取能改进查询。
实例分析
下面我们举一个制造公司的例子来说明如何进行查询优化。制造公司数据库中包括3个表，模式如下所示：
1．part表
零件号零件描述其他列
（part_num）（part_desc）（other column）
102，032Seageat 30G disk……
500，049Novel 10M network card……
……
2．vendor表
厂商号厂商名其他列
（vendor _num）（vendor_name） （other column）
910，257Seageat Corp……
523，045IBM Corp……
……
3．parven表
零件号厂商号零件数量
（part_num）（vendor_num）（part_amount）
102，032910，2573,450,000
234，423321，0014，000，000
……
下面的查询将在这些表上定期运行，并产生关于所有零件数量的报表：
SELECT part_desc，vendor_name，part_amount
FROM part，vendor，parven
WHERE part.part_num=parven.part_num
AND parven.vendor_num = vendor.vendor_num
ORDER BY part.part_num
如果不建立索引，上述查询代码的开销将十分巨大。为此，我们在零件号和厂商号上建立索引。索引的建立避免了在嵌套中反复扫描。关于表与索引的统计信息如下：
表行尺寸行数量每页行数量数据页数量
（table）(row size)（Row count）（Rows/Pages）（Data Pages）
part15010，00025400
Vendor1501，000 2540
Parven13 15，000300 50
索引键尺寸每页键数量页面数量
（Indexes）(Key Size)（Keys/Page)(Leaf Pages）
part450020
Vendor45002
Parven825060
看起来是个相对简单的3表连接，但是其查询开销是很大的。通过查看系统表可以看到，在part_num上和vendor_num上有簇索引，因此索引是按照物理顺序存放的。parven表没有特定的存放次序。这些表的大小说明从缓冲页中非顺序存取的成功率很小。此语句的优化查询规划是：首先从part中顺序读取400页，然后再对parven表非顺序存取1万次，每次2页（一个索引页、一个数据页），总计2万个磁盘页，最后对vendor表非顺序存取1.5万次，合3万个磁盘页。可以看出在这个索引好的连接上花费的磁盘存取为5.04万次。
实际上，我们可以通过使用临时表分3个步骤来提高查询效率：
1．从parven表中按vendor_num的次序读数据：
SELECT part_num，vendor_num，price
FROM parven
ORDER BY vendor_num
INTO temp pv_by_vn
这个语句顺序读parven（50页），写一个临时表（50页），并排序。假定排序的开销为200页，总共是300页。
2．把临时表和vendor表连接，把结果输出到一个临时表，并按part_num排序：
SELECT pv_by_vn，＊ vendor.vendor_num
FROM pv_by_vn，vendor
WHERE pv_by_vn.vendor_num=vendor.vendor_num
ORDER BY pv_by_vn.part_num
INTO TMP pvvn_by_pn
DROP TABLE pv_by_vn
这个查询读取pv_by_vn(50页)，它通过索引存取vendor表1.5万次，但由于按vendor_num次序排列，实际上只是通过索引顺序地读vendor表（40＋2=42页），输出的表每页约95行，共160页。写并存取这些页引发5＊160=800次的读写，索引共读写892页。
3．把输出和part连接得到最后的结果：
SELECT pvvn_by_pn.＊，part.part_desc
FROM pvvn_by_pn，part
WHERE pvvn_by_pn.part_num=part.part_num
DROP TABLE pvvn_by_pn
这样，查询顺序地读pvvn_by_pn(160页)，通过索引读part表1.5万次，由于建有索引，所以实际上进行1772次磁盘读写，优化比例为30∶1。笔者在Informix Dynamic
Sever上做同样的实验，发现在时间耗费上的优化比例为5∶1(如果增加数据量，比例可能会更大)。
小结
20％的代码用去了80％的时间，这是程序设计中的一个着名定律，在数据库应用程序中也同样如此。我们的优化要抓住关键问题，对于数据库应用程序来说，重点在于SQL的执行效率。查询优化的重点环节是使得数据库服务器少从磁盘中读数据以及顺序读页而不是非顺序读页。
⑦ 数据课程设计心得体会
课程设计既可以指为掌握某一课程内容所进行的设计，也要指对某一门课程教学策划的研究活动，下面是为大家搜集整理的数据课程设计心得体会，欢迎阅读。
数据课程设计心得体会(一)
在我看来，数据库课程设计主要的目标是利用课程中学到的数据库知识和技术较好的开发设计出数据库应用系统，去解决各行各业信息化处理的要求。通过这次的课程设计，可以巩固我们对数据库基本原理和基础理论的理解，掌握数据库应用系统设计开发的基本方法，进一步提高我们综合运用所学知识的能力。
当我们这组决定做大学生就业咨询系统时，我们并没有着手写程序。而是大家一起商量这个系统概述、系统目标、系统需求、业务流程分析、数据流程分析和数据词典。当这些都准备好了之后，我们进行模块的分工。每个人都有自己的模块设计，而且写出来的代码要求可以实现相应模块的功能，得到理想的效果。当每个人都把自己的分工做好了，最后会由一个人把这些全部组合搭建在一起。我们使用的是Html和php相互嵌套使用，当一个系统做好了之后，我会好好地把程序都看一遍，理会其中的奥秘。
知识的获得是无止境的，只要你想学，只要你行动，没有什么会难倒我们的。回首这一个多星期的课程设计，我很欣慰。因为我有了动力，有了勇气。谢谢老师对我们的不懈帮助，谢谢学校给了我们这一次实践的机会，也谢谢组员们的关怀。这些美好的回忆美好的东西将永远伴随着我。
数据课程设计心得体会(二)
数据库课程设计大赛的尘嚣渐渐远去，怀着对这次大赛的些许不舍，怀着对当初课程设计开始时候的豪情万丈的决心的留恋，怀着通过这次课程设计积累的信心与斗志，我开始写这篇文章，贺老薯为自己的足迹留下哪怕是微不足道但是对自己弥足珍贵的痕迹并期望与大家共勉。
首先，让我的记忆追溯到大二暑假，在老含李大的指引下(老大劝我学ASP(ASP培训 ).net)，我接触到microsoft 公司的.net产品。那个时候我已经学过vc和asp，因为windows程序设计实验的课的关系，接触过VB(VB培训 )，但是没有专门去学他，因为习惯了c++里面的class，int，觉得vb的sub，var 看着就不是很顺心。我是一个好奇心很强的人，突然看到了一个号称“.net是用于创建下一代应用程序的理想而又现实的开发工具”，而且主推c#语言，由于对c语言的一贯好感，我几乎是立刻对他产生了兴趣。我就开始了对c#的学习，任何语言都不是孤立存在的，所以数据交互是很重要的，暑假的时候我把我们这学期的课本数据库系统概论看了一遍。我记得以前用c语言编程的时候，数据是在内存中申请空间，譬如使用数组等等。很耗费内存空间。这个时候就是数据库站出来的时候啦，于是我又装上了sql server2000，以前学asp的时候用的是access，那个时候只是照着人家做，理论是什么也不是很清楚。
开发的时候我想过用什么架构，c/s模式?模式有很多，怎么选择?我就上网搜索现在最流行的架构是什么。结果搜到了mvc架构，就是你啦。我决定用这个架构，不会，没关系，咱学。just do it!前期工作准备好后，那么我就得把我暑假学的.net加以实践。这个时候我更加深入的了解了利用ado.net操纵数据库的知识。并且对数据库里面的存储过程有了比较深入的了解。经过大概2个多星期的奋斗，我完成了我的数据库课程设计--基于.net数据集的图书馆管理系统。并最后非常荣幸的获得了大赛的一等奖以及以及新技术应用奖。
与其临渊羡鱼，不如退而结网。这次数据库课程设计给我的最大的印象就是如果自己有了兴趣，就动手去做，困难在你的勇气和毅力下是抬不了头的。从做这个数据库开始无论遇到什么困难，我都没有一丝的放弃的念头。出于对知识的渴望，出于对新技术的好奇，出于对一切未知的求知。我完成了这次数据库课程设计，不过这只是我学习路上的驿站，未来十年.net的核心技术就是xml[至少微软是这么宣传的]，我会继续学习它禅者，包括jave公司的j2ee我也很想试试，语言本来就是相通的，just do it!语言并不重要毕竟它仅仅是工具，用好一个工具并不是一件值得为外人道的事情，主要是了解学习思想。古语说的好：学无止境啊。
实际上从学习的经历来看，我们接触的知识体系都是属于比较老或比较传统的，与现在发展迅速的IT行业相比很多情况已不再适用，尤其是当开源模式逐渐走近开发者后更是如此。虽然是一个数据库课程设计，由于本人在选择项目的时候是本着对自己有实际应用价值的角度考虑的，所以其中也涉及到一些数据库以外的设计。总而言之，这次数据库设计心得体会不能用语言完全表达。
数据课程设计心得体会(三)
本次课程设计，使我对《数据结构》这门课程有了更深入的理解。《数据结构》是一门实践性较强的课程，为了学好这门课程，必须在掌握理论知识的同时，加强上机实践。
我的课程设计题目是线索二叉树的运算。刚开始做这个程序的时候，感到完全无从下手，甚至让我觉得完成这次程序设计根本就是不可能的，于是开始查阅各种资料以及参考文献，之后便开始着手写程序，写完运行时有很多问题。特别是实现线索二叉树的删除运算时很多情况没有考虑周全，经常运行出现错误，但通过同学间的帮助最终基本解决问题。
在本课程设计中，我明白了理论与实际应用相结合的重要性，并提高了自己组织数据及编写大型程序的能力。培养了基本的、良好的程序设计技能以及合作能力。这次课程设计同样提高了我的综合运用所学知识的能力。并对VC有了更深入的了解。《数据结构》是一门实践性很强的课程，上机实习是对学生全面综合素质进行训练的一种最基本的方法，是与课堂听讲、自学和练习相辅相成的、必不可少的一个教学环节。上机实习一方面能使书本上的知识变“活”，起到深化理解和灵活掌握教学内容的目的;另一方面，上机实习是对学生软件设计的综合能力的训练，包括问题分析，总体结构设计，程序设计基本技能和技巧的训练。此外，还有更重要的一点是：机器是比任何教师更严厉的检查者。因此，在“数据结构”的学习过程中，必须严格按照老师的要求，主动地、积极地、认真地做好每一个实验，以不断提高自己的编程能力与专业素质。
通过这段时间的课程设计，我认识到数据结构是一门比较难的课程。需要多花时间上机练习。这次的程序训练培养了我实际分析问题、编程和动手能力，使我掌握了程序设计的基本技能，提高了我适应实际，实践编程的能力。总的来说，这次课程设计让我获益匪浅，对数据结构也有了进一步的理解和认识。
数据课程设计心得体会(四)
两个星期的时间非常快就过去了，这两个星期不敢说自己有多大的进步，获得了多少知识，但起码是了解了项目开发的部分过程。虽说上过数据库上过管理信息系统等相关的课程，但是没有亲身经历过相关的设计工作细节。这次实习证实提供了一个很好的机会。
通过这次课程设计发现这其中需要的很多知识我们没有接触过，去图书馆查资料的时候发现我们前边所学到的仅仅是皮毛，还有很多需要我们掌握的东西我们根本不知道。同时也发现有很多已经学过的东西我们没有理解到位，不能灵活运用于实际，不能很好的用来解决问题，这就需要我们不断的大量的实践，通过不断的自学，不断地发现问题，思考问题，进而解决问题。在这个过程中我们将深刻理解所学知识，同时也可以学到不少很实用的东西。
从各种文档的阅读到开始的需求分析、概念结构设计、逻辑结构设计、物理结构设计。亲身体验了一回系统的设计开发过程。很多东西书上写的很清楚，貌似看着也很简单，思路非常清晰。但真正需要自己想办法去设计一个系统的时候才发现其中的难度。经常做到后面突然就发现自己一开始的设计有问题，然后又回去翻工，在各种反复中不断完善自己的想法。
我想有这样的问题不止我一个，事后想想是一开始着手做的时候下手过于轻快，或者说是根本不了解自己要做的这个系统是给谁用的。因为没有事先做过仔细的用户调查，不知道整个业务的流程，也不知道用户需要什么功能就忙着开发，这是作为设计开发人员需要特别警惕避免的，不然会给后来的工作带来很大的麻烦，甚至可能会需要全盘推倒重来。所以以后的课程设计要特别注意这一块的设计。
按照要求，我们做的是机票预订系统。说实话，我对这个是一无所知的，没有订过机票，也不知道航空公司是怎么一个流程。盲目开始设计的下场我已经尝过了，结果就是出来一个四不像的设计方案，没有什么实际用处。没有前期的调查，仅从指导书上那几条要求着手是不够的。
在需求分析过程中，我们通过上网查资料，去图书馆查阅相关资料，结合我们的生活经验，根据可行性研究的结果和客户的要求，分析现有情况及问题，采用Client/Server结构，将机票预定系统划分为两个子系统：客户端子系统，服务器端子系统。在两周的时间里，不断地对程序及各模块进行修改、编译、调试、运行，其间遇到很多问题：由于忘记了一些java语言的规范使得在调试过程中一些错误没有发现，通过这次课程设计，我对调试掌握得更加熟练了，意识到了程序语言的规范性以及我们在编程时要有严谨的态度，同时在写程序时如有一定量的注释，既增加了程序的可读性，也可以使自己在读程序时更容易。
我们学习并应用了SQL语言，对数据库的创建、修改、删除方法有了一定的了解，通过导入表和删除表、更改表学会了对于表的一些操作，为了建立一个关系数据库信息管理系统，必须得经过系统调研、需求分析、概念设计、逻辑设计、物理设计、系统调试、维护以及系统评价的一般过程，为毕业设计打下基础。
很多事情不是想象中的那么简单的，它涉及到的各种实体、属性、数据流程、数据处理等等。很多时候感觉后面的设计根本无法继续，感觉像是被前面做的各种图限制了。在做关系模型转换的时候碰到有些实体即可以认为是实体又可以作为属性，为了避免冗余，尽量按照属性处理了。
物理结构设计基本没有碰到问题，这一块和安全性、完整性不觉就会在物理结构设计中添加一些安全设置：主键约束、check约束、default定义等。最后才做索引的部分，对一些比较经常使用搜索的列，外键上建立索引，这样可以明显加快检索的速度，最后别忘记重要的安全性设置，限制用户访问权限，新建用户并和数据库用户做相应的映射。
不管做什么，我们都要相信自己，不能畏惧，不能怕遇到困难，什么都需要去尝试，有些你开始认为很难的事在你尝试之后你可能会发现原来她并没有你以前觉得的那样，自己也是可以的。如果没有自信，没有目标，没有信心就不可能把事情做好，当其他人都在迷茫的时候，自己一定要坚信目标，大学毕业出去即面临找工作，从学习这个专业，到以后从事这方面的工作都需要不断地去学习去实践，这次实践可以给我们敲一个警钟，我们面临毕业，面临择业，需要这些实践经验，在困难面前要勇于尝试，这是这次课程设计给我的最大感想!
以上基本是这次实习的体会了，设计进行的非常艰难，编码非常不容易，才发现做一个项目最重要的不在于如何实现，而是实现之前的需求分析和模块设计。创新很难，有些流行的系统其实现并不难，难的在于对市场的分析和准确定位。设计，是一个任重道远的过程。
⑧ 数据仓库的目的是什么
数据仓库组织的最根本目的就是能够更加便利，有序的进行仓库管理，让仓库数据化，可以让管理更加的便利的同时，更加的科学，安全。
数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据冲虚中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。
数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。
数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到当前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。
(8)数据库设计的根本目的扩展阅读：
数据仓库所提供的各种信息，肯定要准确的数据，但由于数据仓库流程通常分为多个步骤，包括数据清洗，装载，迹判山查询，展现等等，复杂的架构会更多层次，那么由于数据源有脏数据或者代码不严谨，都可以导致数据失真，客户看到错误的信息就可能导致分析出错误的决策，造成损失，而不姿中是效益。
之所以有的大型数据仓库系统架构设计复杂，是因为考虑到了未来3-5年的扩展性，这样的话，未来不用太快花钱去重建数据仓库系统，就能很稳定运行。主要体现在数据建模的合理性，数据仓库方案中多出一些中间层，使海量数据流有足够的缓冲，不至于数据量大很多，就运行不起来了。
⑨ 数据库技术的根本目标是什么
数据库技术的根本目标是解决数据的“共享问题”。
数据库技术是信息系统的一个核心技术。是一种计算机辅助管理数据的方法，它研究如何组织和存储数据，如何高效地获取和处理数据。
数据库技术是信息系统的一个核心技术。是一种计算机辅助管理数据的方法，它研究如何组织和存储数据，如何高效地获取和处理数据。是通过研究数据库的结构、存储、设计、管理以及应用的基本理论和实现方法，并利用这些理论来实现缺山对数据库中的数据进行处理、分析和理解的技术。即：数据库技术是研究、管理和应握仿用数据库的一门软件科学。
⑩ 数据库设计范式深入浅出
关系数据库设计之时是要遵守一定的规则的。尤其是数据库设计范式 现简单介绍1NF（第一范式），2NF（第二范式），3NF（第三范式）和BCNF，另有第四范式和第五范式留到以后再介绍。 在你设计数据库之时，若能符合这几个范式，你就是数据库设计的高手。
第一范式（1NF）：在关系模式R中的每一个具体关系r中，如果每个属性值 都是不可再分的最小数据单位，则称R是第一范式的关系。例：如职工号，姓名，电话号码组成一个表（一个人可能有一个办公室电话 和一个家里电话号码） 规范成为1NF有三种方法：
一是重复存储职工号和姓名。这样，关键字只能是电话号码。
二是职工号为关键字，电话号码分为单位电话和住宅电话两个属性
三是职工号为关键字，但强制每条记录只能有一个电话号码。
以上三个方法，第一种方法最不可取，按实际情况选取后两种情况。
第二范式（2NF）：如果关系模式R（U，F）中的所有非主属性都完全依赖于任意一个候选关键字，则称关系R 是属于第二范式的。
例：选课关系 SCI（SNO，CNO，GRADE，CREDIT）其中SNO为学号， CNO为课程号，GRADEGE 为成绩，CREDIT 为学分。 由以上条件，关键字为组合关键字（SNO，CNO）
在应用中使用以上关系模式有以下问题：
a.数据冗余，假设同一门课由40个学生选修，学分就 重复40次。
b.更新异常，若调整了某课程的学分，相应的元组CREDIT值都要更新，有可能会出现同一门课学分不同。
c.插入异常，如计划开新课，由于没人选修，没有学号关键字，只能等有人选修才能把课程和学分存入。
d.删除异常，若学生已经结业，从当前数据库删除选修记录。某些门课程新生尚未选修，则此门课程及学分记录无法保存。
原因：非关键字属性CREDIT仅念颤函数依赖于CNO，也就是CREDIT部分依赖组合关键字（SNO，CNO）而不是完全依赖。
解决方法：分成两个关系模式 SC1（SNO，CNO，GRADE），C2（CNO，CREDIT）。新关系包括两个关系模式，它们之间通过SC1中的外关键字CNO相联系，需要时再进行自然联接，恢复了原来的关系
第三范式（3NF）：如果关系模式R（U，F）中的所有非主属性对任何候选关键字都不存在传递信赖，则称关系R是属于第三范式的。
例：如S1（SNO，SNAME，DNO，DNAME，LOCATION） 各属性分别代表学号，
姓名，所在系，系名称，系地址。
关键字SNO决定各个属性。由于是单个关键字，没有部分依赖的问题，仔肆败肯定是2NF。但这关系肯定有大量的冗余，有关学生所在的几个属性DNO，DNAME，LOCATION将重复存储，插入，删除和修改时也将产生类似以上例的情况。
原因：关系中存在传递依赖造成的。即SNO - DNO。 而DNO - SNO却不存在，DNO - LOCATION, 因此关键辽 SNO 对 LOCATION 函数决定是通过传递依赖 SNO - LOCATION 实现的。也就是说，SNO不直接决定非主属性LOCATION。
解决目地：每个关系模式中不能留有传递依赖。
解决方法：分为两个关系 S（SNO，SNAME，DNO），D（DNO，DNAME，LOCATION）
注意：关系S中不能没有外关键字DNO。否则两个关系之间失去联系。
BCNF：如果关系模式R（U，F）的所有属性（包括主属性和非主属性）都不传递依赖于R的任何候选关键字，那么称关系R是属于BCNF的。或是关系模式R，如果每个决定因素都包含关键字（而不是被关键字所包含），则RCNF的关系模式。
例：配件管理关系模式 WPE（WNO，PNO，ENO，QNT）分别表仓库号，配件号，职工号，数量。有以下条件
a.一个仓库有多个职工雹举。
b.一个职工仅在一个仓库工作。
c.每个仓库里一种型号的配件由专人负责，但一个人可以管理几种配件。
d.同一种型号的配件可以分放在几个仓库中。
分析：由以上得 PNO 不能确定QNT，由组合属性（WNO，PNO）来决定，存在函数依赖（WNO，PNO） - ENO。由于每个仓库里的一种配件由专人负责，而一个人可以管理几种配件，所以有组合属性（WNO，PNO）才能确定负责人，有（WNO，PNO）- ENO。因为 一个职工仅在一个仓库工作，有ENO - WNO。由于每个仓库里的一种配件由专人负责，而一个职工仅在一个仓库工作，有 （ENO，PNO）- QNT。
找一下候选关键字，因为（WNO，PNO） - QNT，（WNO，PNO）- ENO ，因此 （WNO，PNO）可以决定整个元组，是一个候选关键字。根据ENO-WNO，（ENO，PNO）-QNT，故（ENO，PNO）也能决定整个元组，为另一个候选关键字。属性ENO，WNO，PNO 均为主属性，只有一个非主属性QNT。它对任何一个候选关键字都是完全函数依赖的，并且是直接依赖，所以该关系模式是3NF。
分析一下主属性。因为ENO-WNO，主属性ENO是WNO的决定因素，但是它本身不是关键字，只是组合关键字的一部分。这就造成主属性WNO对另外一个候选关键字（ENO，PNO）的部 分依赖，因为（ENO，PNO）- ENO但反过来不成立，而P-WNO，故（ENO，PNO）- WNO 也是传递依赖。
虽然没有非主属性对候选关键辽的传递依赖，但存在主属性对候选关键字的传递依赖，同样也会带来麻烦。如一个新职工分配到仓库工作，但暂时处于实习阶段，没有独立负责对某些配件的管理任务。由于缺少关键字的一部分PNO而无法插入到该关系中去。又如某个人改成不管配件了去负责安全，则在删除配件的同时该职工也会被删除。
解决办法：分成管理EP（ENO，PNO，QNT），关键字是（ENO，PNO）工作EW（ENO，WNO）其关键字是ENO
缺点：分解后函数依赖的保持性较差。如此例中，由于分解,函数依赖（WNO，PNO）- ENO 丢失了, 因而对原来的语义有所破坏。没有体现出每个仓库里一种部件由专人负责。有可能出现 一部件由两个人或两个以上的人来同时管理。因此，分解之后的关系模式降低了部分完整性约束。
一个关系分解成多个关系，要使得分解有意义，起码的要求是分解后不丢失原来的信息。这些信息不仅包括数据本身，而且包括由函数依赖所表示的数据之间的相互制约。进行分解的目标是达到更高一级的规范化程度，但是分解的同时必须考虑两个问题：无损联接性和保持函数依赖。有时往往不可能做到既有无损联接性，又完全保持函数依赖。需要根据需要进行权衡。
1NF直到BCNF的四种范式之间有如下关系：
BCNF包含了3NF包含2NF包含1NF
小结：
目地：规范化目的是使结构更合理，消除存储异常，使数据冗余尽量小，便于插入、删除和更新
原则：遵从概念单一化 "一事一地"原则，即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。
方法：将关系模式投影分解成两个或两个以上的关系模式。
要求：分解后的关系模式集合应当与原关系模式"等价"，即经过自然联接可以恢复原关系而不丢失信息，并保持属性间合理的联系。
注意：一个关系模式结这分解可以得到不同关系模式集合，也就是说分解方法不是唯一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。其根本目标是节省存储空间，避免数据不一致性，提高对关系的操作效率，同时满足应用需求。实际上，并不一定要求全部模式都达到BCNF不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高，查询频度极高的数据库系统更是如此。
在关系数据库中，除了函数依赖之外还有多值依赖，联接依赖的问题，从而提出了第四范式，第五范式等更高一级的规范化要求。在此，以后再谈。
各位朋友，你看过后有何感想，其实，任何一本数据库基础理论的书都会讲这些东西，考虑到很多网友是半途出家，来做数据库。特找一本书大抄特抄一把，各位有什么问题，也别问我了，自已去找一本关系数据库理论的书去看吧，说不定，对各位大有帮助。说是说以上是基础理论的东西，请大家想想，你在做数据库设计的时候有没有考虑过遵过以上几个范式呢，有没有在数据库设计做得不好之时，想一想，对比以上所讲，到底是违反了第几个范式呢？
我见过的数据库设计，很少有人做到很符合以上几个范式的，一般说来，第一范式大家都可以遵守，完全遵守第二第三范式的人很少了，遵守的人一定就是设计数据库的高手了，BCNF的范式出现机会较少，而且会破坏完整性，你可以在做设计之时不考虑它，当然在ORACLE中可通过触发器解决其缺点。以后我们共同做设计之时，也希望大家遵守以上几个范式。