数据库课程设计完成版.docx
《数据库课程设计完成版.docx》由会员分享，可在线阅读，更多相关《数据库课程设计完成版.docx（18页珍藏版）》请在冰豆网上搜索。
数据库课程设计完成版
1课程设计要求1
2数据库概念模式设计2
2.1整理的数据项2
2.2绘制ERD2
3数据库逻辑模式设计3
3.1一般逻辑模型设计3
3.1.1按四原则转化3
3.1.2转化的逻辑模型4
3.1.3逻辑模型的优化5
3.2具体逻辑模型设计6
4数据库保护设计7
4.1设计表间关系7
4.2完整性设计7
4.2.1出版社关系表7
4.2.2书籍关系表8
4.2.3借书人关系表8
4.2.4借还情况关系表8
5数据库实现9
5.1建立数据库9
5.2建立数据表10
5.2.1出版社关系表11
5.2.2书籍关系表11
5.2.3借书人关系表12
5.2.4借还情况关系表13
5.3数据库的表间关联13
6感想与体会14
1课程设计要求
一个图书借阅管理数据库要求提供以下服务：
（1）可随时查询书库中现有书籍的种类、数量与存放位置。
所有各类书籍均可由书号唯一标识。
（2）可随时查询书籍借还情况。
包括借书人单位、姓名、借书证号、借书日期和还书日期。
任何人可借多种书，任何一种书可为多个人所借，借书证号具有唯一性。
（3）当需要时，可通过数据库中保存的出版社电话、邮编及地址等信息向有关书籍的出版社增购有关书籍。
一个出版社可出版多种书籍，同一本书仅为一个出版社出版，出版社名具有唯一性。
根据以上的情景假设，进行如下的分析与设计：
（1）根据上述语义画出ER图。
（2）将ER模型转换成关系模型，并指出每个关系模式的主关键字。
（3）分析每个关系模式已经达到第几范式。
对于不符合第三范式要求的关系模式进行规范化。
（4）根据概念模型设计逻辑模型和保护设计。
（5）在SQLServer中实现。
2数据库概念模式设计
2.1整理的数据项
书号、种类、数量、存放位置、书籍出版社、出版社名称、电话、邮编、地址、联系人、借书证号、姓名、单位、借书日期、还书日期
2.2绘制ERD
3数据库逻辑模式设计
3.1一般逻辑模型设计
3.1.1按四原则转化
（1）原则一：
：
ER图中的每一个独立实体变换为一个关系，其属性变为关系的属性，其主标识变为关系的主码，由第一原则转化可得到：
出版社关系
出版社名称
电话
邮编
地址
联系人
主码
书籍关系
书号
书名
种类
数量
存放位置
书籍出版社
主码
借书人关系
借书证号
姓名
单位
主码
（2）原则二：
ER图中的从实体及相应的“的”联系变换为一个关系，从实体的属性加上主实体关系的主码构成这个关系的属性。
如果“的”联系是1：
1的，则以主实体关系的主码（作为外来码）为这个关系的主码；如果“的”联系是1：
M的，则以主实体关系的主码加上同一主实体个体联系的不同从属实体个体赖以相互区分的属性组，组成该关系的主码，此E-R图中没有“的”联系，所以无原则二
（2）原则三：
1：
M联系通过在“多”实体关系中增加相联系的“1”实体关系的主码及联系本身的属性来表达。
其中“1”实体主码为外来码，由第三原则转化可得到：
书籍关系
书号
书名
种类
数量
存放位置
书籍出版社
增购书籍出版社名称
主码
外码
（3）原则四：
M：
N联系转换成一个独立的关系，被联系实体关系的主码（作为外来码）和联系本身的属性作为该关系的属性，被联系实体关系的主码组成其复合主码，由第四原则转化可得到：
借还情况关系
书号
借书证号
借书日期
还书日期
外码
外码
主码（复合主码）
3.1.2转化的逻辑模型
经过整理总结得到以下四张关系表：
出版社关系
出版社名称
电话
邮编
地址
联系人
主码
书籍关系
书号
书名
种类
数量
存放位置
书籍出版社
增购书籍出版社名称
主码
外码
借书人关系
借书证号
姓名
单位
主码
借还情况关系
书号
借书证号
借书日期
还书日期
外码
外码
主码（复合主码）
3.1.3逻辑模型的优化
在出版社关系模式中，由于非主属性电话、邮编、地址、联系人都是依赖于主属性出版社名称，而且在此关系模式中的全部非主属性之间不存在传递关系，即每一个非主属性与主属性出版社名称都不传递依赖关系，所以出版社关系模式是属于第三范式，不需要再优化。
在书籍关系模式中，由于非主属性书名、种类、数量、存放位置、书籍出版社、增购书籍出版社名称都是完全依赖于主属性书号，而且非主属性之间不存在传递关系，即书籍关系模式中的每一个非主属性与主属性书号都不传递依赖关系，所以书籍关系模式是属于第三范式，不需要再优化。
在借书人关系模式中，非主属性姓名、单位都完全依赖于主属性借书证号，而且非主属性姓名、单位之间不存在传递关系，即此关系模式中的每一个非主属性都不传递依赖于主属性，所以借书人关系模式是属于第三范式，不需要再优化。
在借还情况关系模式中，非主属性借书日期、还书日期都完全依赖于复合关键字书号、借书证号，而且非主属性借书日期、还书日期之间不存在传递关系，即此关系模式中的每一个非主属性都不传递依赖于复合关键字，所以借还关系模式是属于第三范式，不需要再优化。
3.2具体逻辑模型设计
出版社关系表
字段名
字段类型
字段长度
小数点位数
是否主关键字
出版社名称
char
20
无
是
电话
tinyint
11
无
否
邮编
tinyint
6
无
否
地址
char
50
无
否
联系人
char
10
无
否
书籍关系表
字段名
字段类型
字段长度
小数点位数
是否主关键字
书号
char
20
无
是
书名
char
50
无
否
种类
char
20
无
否
数量
tinyint
10
无
否
存放位置
char
20
无
否
书籍出版社
char
20
无
否
增购书籍出版社名称
char
20
无
否
借书人关系表
字段名
字段类型
字段长度
小数点位数
是否主关键字
借书证号
tinyint
10
无
是
姓名
char
10
无
否
单位
char
20
无
否
借还情况关系表
字段名
字段类型
字段长度
小数点位数
是否主关键字
书号
char
20
无
是复合关键字
借书证号
tinyint
10
无
借书日期
datetime
8
无
否
还书日期
datetime
8
无
否
4数据库保护设计
4.1设计表间关系
（1）出版社表与书籍表是增购联系，通过字段增购书籍出版社名称相关联
（2）借还情况表与书籍表是借还情况联系，通过字段书号相关联
（3）借还情况表与借书人表是借还情况联系，通过字段借书证号相关联
（4）书籍表与借书人表是借还情况联系，通过字段书号、借书证号相联系
4.2完整性设计
4.2.1出版社关系表
（1）实体完整性设计
实体的关键字出版社名称取值唯一不为空
（2）参照完整性设计
由于在出版社关系表中的字段不参照任何表中字段，所以不需要进行设计参照完整性
（3）用户定义完整性设计
定义出版社名称为关键字，数据类型是字符型，长度不超过20；
属性电话的数据类型约束为整型，字节取值范围是0-11,且唯一不为空值；
属性邮编的数据类型为整型，其值域的字节取值范围是0-6；
属性地址的数据类型是字符型，字符长度不超过50；
联系人的数据类型是字符型，字符长度不超过10
4.2.2书籍关系表
（1）实体完整性设计
实体的主关键字书号取值唯一不为空值
（2）参照完整性设计
书籍关系与出版社关系存在参照与被参照关系，其中书籍关系是参照关系，出版社关系是被参照关系。
设定不允许被参照表中出版社表中的出版社名称发生删除操作；设定当被参照表出版社中的字段出版社名称进行更新操作时，书籍关系表中的增购书籍出版社名称也进行更新
（3）用户定义完整性设计
定义书号为主关键字，数据类型是字符型，字符长度不超过20；
属性书名的数据类型是字符型，字符长度不超过20，规定不为空；
属性数量的数据类型是整型，字节取值范围为1-10；
属性种类、存放位置、书籍出版社、增购书籍出版社名称的值域规定不为空，数据类型是字符型，字符长度不超过20
4.2.3借书人关系表
（1）实体完整性设计
实体的主关键字借书证号取值唯一不为空
（2）参照完整性设计
由于在借书人关系表中的任何字段都不参照于其他的表中的字段，所以不需要进行设计参照完整性
（3）用户定义完整性设计
定义借书证号为主关键字，数据类型是整型，取值范围是字节不超过10；
属性姓名的数据类型是字符型，长度不超过10，规定不为空；
属性单位的值域规定不为空，数据类型为字符不超过20
4.2.4借还情况关系表
（1）实体完整性设计
复合关键字书号、借书证号唯一不为空
（2）参照完整性设计
在书籍关系与借还情况关系中存在参照和被参照关系，书籍关系是被参照关系，借还情况关系是参照关系。
设计规定不允许被参照关系中的字段书号发生删除操作；当被参照关系书籍关系中的书号字段进行更新操作时，参照关系借还情况表中的书号也跟着进行更新；
在借书人关系与借还情况关系之间存在参照和被参照关系，其中借书人关系是被参照关系，借还情况是参照关系。
设计规定被参照表借书人表中的借书证号不允许发生删除操作；当被参照表借书人表中借书证号发生更新操作时，参照表中的借书证号也跟着进行更新操作
（3）用户定义完整性设计
定义书号、借书证号为复合关键字，设定唯一不为空值；
属性借书日期、还书日期的数据类型为datetime，长度都是8，值域规定不为空
5数据库实现
5.1建立数据库
语句和截图
Createdatabase图书馆
on
（name=library,
Filename='E:
\数据库课程设计\library.mdf'）
Logon
（name=library_log,
Filename='E:
\数据库课程设计\library.ldf'）
5.2建立数据表
建立模式
语句和截图
Createschemalibrary
5.2.1出版社关系表
Createtablelibrary.出版社
（出版社名称char（20）primarykey,
电话tinyintuniquenotnull,
邮编tinyint,
地址char（50）,
联系人char（10））
5.2.2书籍关系表
Createtablelibrary.书籍
（书号tinyintprimarykey,
书名char（50）notnull,
数量tinyint,
种类char（20）notnull,
存放位置char（20）notnull,
书籍出版社char（20）notnull,
增购书籍出版社名称char（20）notnullforeignkeyreferenceslibrary.出版社（出版社名称）
Ondeletenoaction
Onupdatecascade）
5.2.3借书人关系表
Createtablelibrary.借书人
（借书证号tinyintprimarykey,
姓名char（10）notnull,
单位char（20）notnull）
5.2.4借还情况关系表
Createtablelibrary.借还情况
（书号tinyintforeignkeyreferenceslibrary.书籍
Ondeletenoaction
Onupdatecascade,
借书证号tinyintforeignkeyreferenceslibrary.借书人
Ondeletenoaction
Onupdatecascade,
借书日期datetimenotnull,
还书日期datetimenotnull
Primarykey（书号,借书证号））
5.3数据库的表间关联
截图
6感想与体会
在做数据库课程设计之前，我自己觉得应该时一门比较难的，需要花费很多时间和精力去做的一门课程，但是，当在我慢慢接触这个课程设计，自己一点点地把它做下去的时候，才发觉它是一个很系统的东西，在这中间是有一种叫做“联系”的东西在里面，一步步的做下来，在不知不觉地就把这个这个课程设计做完了。
我想一件事情的难易程度是不能根据别人的话语或者是从一件事情的表面上去判断的，只有自己真的用心地去做了的话，那么就算是真的有一座山摆在你的面前，那么我们都会相信有愚公的一丝丝思想存在话，那么我们就不会感到没有路可以走了吧。
在这个课程设计中我了解到了其实我们现在学的每一门课程，特别是像数据库这样的课程，是需要一步步地了解，一步步的分析的，所以我们需要一个比较系统的知识结构，在这之前我体会最深的就是做每一件事情的时候都是需要准备的，在这次的数据库课程设计中，我在机房之外做的准备在机房里的时间还要多，这是一个真正的需要的一个部分，所以我想要是想干好一件事情的话，那么我们的准备工作是不能马虎的。
所以虽然这次的课程设计没有我想象中的那么难，也没有用我预想中的那么的时间去完成它，但是我觉得自己做得还是另自己满意的，毕竟这是经过了我自己的思考，经过了一段时间的准备，然后再根据书本的知识一步步地走过来的，一步步地来完善的，自己毕竟是真的有在这个课程里面留下过自己的痕迹，而且还得到了一些东西：
我们做一件事情，我们需要充足的时间和准备；我们要完成一件事情的话，需要我们系统的去思考问题。
升级会员 