数据库课程设计指导书.docx
《数据库课程设计指导书.docx》由会员分享，可在线阅读，更多相关《数据库课程设计指导书.docx（23页珍藏版）》请在冰豆网上搜索。
数据库课程设计指导书
第五章课程设计
5.1实验简介
实验名称：
管理系统的后台数据库设计
建议学时：
一周
实验目的：
本实验的目的是为了让学生能够全面了解数据库应用系统的整个开发过程，逐步掌握系统开发的以下相关技术：
（一）巩固数据库理论知识，熟悉一种具体的数据库管理系统（例如：
SQLServer）的使用方法。
（二）掌握针对特定应用环境数据库的设计。
（三）综合使用SQLServer中数据库、表、视图、索引、触发器、存储过程的创建使用方法。
（四）体会运用软件工程的设计思想进行软件系统开发的过程与方法。
通过本课程设计，有助于学生巩固数据库系统的理论，掌握数据库的设计方法及数据库的运用和开发技术。
实验内容及步骤:
针对某部门或公司的实践调研，通过系统需求分析、数据库概念设计、逻辑设计,用SQL上机编程、调试和应用实现数据库的设计,最终完成某管理系统的后台数据库设计。
（一）系统需求分析和系统设计
用软件工程的方法进行系统需求分析和系统设计得出系统的数据流图数据字典和信息模型。
（二）数据库设计
按数据库设计方法和规范化理论得出符合3NF的逻辑模型，外模型和物理模型。
（三）数据库定义和数据安全性与完整性定义
定义数据库、基本表、视图和安全性、完整性约束的要求。
（四）应用程序设计和程序调试
设计并编写输入/输出、查询/统计、数据维护等功能模块的应用程序，要求至少使用表、视图、索引的创建命令，表中数据的增、删、改、查询的命令，存储过程的创建和使用命令，触发器的创建和使用命令。
（五）撰写课程设计报告
对系统的各个功能模块进行集成、总调试，撰写课程设计报告。
课程设计安排：
三人为一组，每组一个课题，每组设组长一名，负责该组设计工作的协调、分工等，小组成员分工需明确，确保每个成员都有一定的任务量。
课程设计建议持续一周（7天），具体日程安排如表5.1所示。
表5.1课程设计安排表
时间
内容安排
第1天
按组讨论、对系统功能进行需求分析并进行明确分工
第2天
概念模型设计：
设计E-R模型，详细描述实体的属性和实体之间的联系
第3天
逻辑结构设计：
实现E-R图向关系模型的转换；物理结构设计：
表的属性设置等
第4-6天
实现表的创建，视图的创建；建立索引；实现列、行及参照完整性；向表中插入数据；查询数据；设计存储过程、触发器
第7天
完成课程设计报告
考核形式：
通过程序实现、总结报告和学习态度，并结合学生的动手能力，独立分析解决问题的能力和创新精神综合考评。
考核方式采用平时检查、程序检查和课程设计报告检查结合的办法。
成绩分优、良、中、及格和不及格五等。
考核标准包括：
1、程序代码（50%）
2、学生的工作态度、动手能力、创新精神及出勤率（30%）
3、课程设计报告（20%）
5.2参考选题及功能要求
1.机票预定信息系统
系统功能的基本要求：
航班基本信息，包括航班的编号、飞机名称、机舱等级等；机票信息，包括票价、折扣、当前预售状态及经手业务员等；客户基本信息，包括姓名、联系方式、证件及号码、付款情况等。
需实现基本信息的录入、修改和删除，需按照一定条件查询、统计符合条件的航班、机票等信息，实现机票的预订、退订功能。
2.长途汽车信息管理系统
系统功能的基本要求：
线路信息，包括出发地、目的地、出发时间、所需时间等；汽车信息，包括汽车的种类及相应的票价、最大载客量等；票价信息，包括售票情况、查询、打印相应的信息。
需实现基本信息的录入、修改和删除，需按照一定条件查询、统计符合条件的汽车及车票等信息，实现车票的预订、退订功能。
3.人事信息管理系统
系统功能基本要求：
员工各种信息，包括员工的基本信息，如编号、姓名、性别、学历、所属部门、毕业院校、健康情况、职称、职务、奖惩等。
需实现员工各种信息的录入、修改；对转出、辞退、退休员工信息的删除；需按照一定条件查询、统计符合条件的员工信息。
4.超市会员管理系统
系统功能的基本要求：
会员的基本信息，包括姓名、性别、年龄、工作单位、联系方式等；加入会员的基本信息，包括成为会员的基本条件、优惠政策、优惠时间等；会员购物信息，包括购买物品编号、物品名称、所属种类，数量，价格等；会员返利信息，包括会员积分的情况，享受优惠的等级等。
需实现基本信息的录入、修改和删除；能按照一定条件查询符合条件的会员信息；需对货物流量及消费人群进行统计输出。
5.客房管理系统
系统功能的基本要求：
客房各种信息，包括客房的类别、当前的状态、负责人等；客房信息的查询和修改，包括按房间号查询住宿情况、按客户信息查询房间状态等。
需要实现退房、订房、换房等信息的修改。
对查询、统计结果打印输出。
6.药品存销信息管理系统
系统功能基本要求：
药品信息，包括药品编号、药品名称、生产厂家、生产日期、保质期、用途、价格、数量、经手人等；员工信息，包括员工编号、姓名、性别、年龄、学历、职务等；客户信息，包括客户编号、姓名、联系方式、购买时间、购买药品编号、名称、数量等；入库和出库信息，包括当前库存信息、药品存放位置、入库数量和出库数量等。
需实现基本信息的录入、修改和删除；需按照一定条件查询、统计符合条件的药品、客户、入库、出库的信息。
7.学生选课管理信息系统
系统功能基本要求：
教师信息，包括教师编号、教师姓名、性别、年龄、学历、职称、毕业院校，健康状况等；学生信息，包括学号、姓名、所属院系、已选课情况等；教室信息，包括可容纳人数、空闲时间等；选课信息，包括课程编号、课程名称、任课教师、选课的学生情况等；成绩信息，包括课程编号、课程名称、学分、成绩。
需实现基本信息的录入、修改和删除；需按照一定条件查询，统计学生的选课情况、成绩情况、教师情况和教室情况。
8.图书管理系统
系统功能基本要求：
图书信息，包括图书编号、图书名称、所属类别等；读者信息，包括读者编码、姓名、性别、专业等；借还书信息，包括图书当前状态、被借还次数、借阅时间等。
需实现基本信息的录入、修改和删除；需按照一定条件查询，统计图书信息、读者信息和借还书信息。
能实现借书、还书功能。
9.学生成绩管理系统
系统功能基本要求：
学生信息，学号、姓名、性别、专业、年级等；学生成绩信息，包括学号、课程编号、课程名称、分数等；课程信息，包括课程编号、课程名称、任课教师等。
需实现基本信息的录入、修改和删除；需按照一定条件查询，统计学生成绩，但不能任意修改成绩。
10.网上书店管理信息
系统功能基本要求：
书籍信息，包括图书编号、图书种类、图书名称、单价、内容简介等；购书者信息，包括购买编号、姓名、性别、年龄、联系方式购买书的名称等；购买方式，包括付款方式、发货手段等。
需实现基本信息的录入、修改和删除；根据读者信息查询购书情况、书店的销售情况。
11.教室管理信息系统
系统功能基本要求：
教室信息，包括教室容纳人数、教室空闲时间、教室设备等；教师信息，包括教师姓名、教授课程、教师职称、安排上课时间等；教室安排信息，包括何时空闲、空闲的开始时间、结束时间等。
需实现基本信息的录入、修改和删除；需按照一定条件查询，统计教室使用情况。
12论坛管理信息系统
系统功能基本要求;
作者信息，包括作者昵称、性别、年龄、职业、爱好等；贴子信息，包括贴子编号、发贴日期、时间、等级等；回复信息，包括回复作者昵称、回复时间等。
需实现基本信息的录入、修改和删除；需按照一定条件查询，统计作者信息、帖子情况和回复情况。
13.职工考勤管理信息系统
系统功能基本要求:
职工信息，包括职工编号、职工姓名、性别、年龄、职称等；出勤记录信息，包括上班打卡时间，下班打卡时间，缺勤记录等；出差信息，包括出差起始时间、结束时间、统计总共天数等；请假信息，包括请假开始时间，结束时间，统计请假天数等；加班信息，包括加班开始时间、结束时间、统计加班总时间。
需实现基本信息的录入、修改和删除；需按照一定条件查询，统计职工的考勤情况和加班情况。
14.个人信息管理系统
系统功能基本要求:
通讯录信息，包括通讯人姓名、联系方式、工作地点、城市、备注等；备忘录信息，包括什么时间、事件、地点等；日记信息，包括时间、地点、事情、人物等；个人财物管理，包括总收入，消费项目、消费金额、消费时间、剩余资金等。
需实现基本信息的录入、修改和删除；需按照一定条件查询，统计个人信息。
15.办公室日常管理信息系统
系统功能基本要求:
文件管理信息，包括文件编号、文件种类、文件名称、存放位置等；考勤管理，包括姓名、年龄、职务、日期、出勤情况等；需查询员工的出勤情况。
会议记录，包括会议时间、参会人、记录员、会议内容等；办公室日常事务管理，包括时间、事务、记录人。
需按条件查询，统计。
16.轿车销售信息管理系统
系统功能基本要求:
轿车信息，包括轿车的编号、型号、颜色、生产厂家、出厂日期、价格等；员工信息，包括员工编号、姓名、性别、年龄、籍贯、学历等；客户信息，包括客户名称、联系方式、地址、业务联系记录等；轿车销售信息，包括销售日期、轿车类型、颜色、数量、经手人等。
需实现基本信息的录入、修改和删除；需按条件查询，统计销售情况。
17.高校学生宿舍管理系统
系统功能基本要求:
宿舍楼信息，包括楼号，层数，寝室数等；学生信息，包括学号、姓名、性别、院系、班级、所在宿舍号等；宿舍信息，包括宿舍号，所在楼号，所在层数，床位数，实际人数等；宿舍事故信息，包括宿舍号，事故原因，事故时间，是否解决等。
需实现宿舍信息的添加、修改、删除及查询；学生信息的添加、修改、删除及查询；宿舍备品及事故的查询等功能。
18.员工工资管理系统
系统功能基本要求:
员工基本信息，包括员工号，员工名，性别，出生日期，职称，职务等；员工考勤信息，包括员工号，迟到，早退，旷工，请假等；员工工种信息，包括员工的工种、等级，基本工资等信息；员工津贴信息，包括员工的加班时间，加班类别、加班天数、津贴情况等；员工月工资，包括员工号，基本工资，津贴，扣款，应发工资，实发工资等。
要求能够设定员工每个工种的基本工资；管理加班津贴，根据加班时间和类型给予不同的加班津贴；按照不同工种的基本工资情况、员工的考勤情况产生员工的每月的月工资；生成员工的年终奖金，员工的年终奖金计算公式＝（员工本年度的工资总和＋津贴的总和）/12；生成企业工资报表。
能够查询单个员工的工资情况、每个部门的工资情况、按月的工资统计；
5.3实验报告要求
1．封面（含实验课程名称、专业、班级、小组成员的学号及姓名、指导教师及职称、开课学期、完成时间）；
2．设计题目；
3．实验目的；
4．软硬件环境；
5．实验设计简述（简要说明设计题目的基本情况）；
6．系统需求分析与功能设计（根据课题的要求进行简单的需求分析，设计相应的数据流图，得出相应的系统功能需要，系统数据流图）；
7．概念模型设计（按数据库设计方法和规范化理论，从实践概括抽象出ER模型）；
8．逻辑模型设计（按数据库设计方法和规范化理论得出符合3NF的逻辑模型，ER图设计，ER图转化为相应的关系模式，设计数据库的逻辑模型）；
9．物理模型设计（存储记录结构设计，物理文件的安排和建立索引）；
10．实现（数据库结构设计的程序代码，增、删、改、查等基本操作的程序代码）；
11．实验总结（主要对本实验开发过程进行归纳和总结，还应包括在设计过程中所遇到的技术难点及解决方法，尚存在的问题以及进一步开发的见解与建议。
）；
12．参考文献。
13．系统功能基本要求：
5.4参考实例——交易中心管理系统
（一）实验目的
针对零件交易中心的实践调研，通过系统需求分析、数据库概念设计、逻辑设计到上机编程、调试和应用等全过程完成零件交易中心管理系统的后台数据库设计。
（二）实验设计简述
零件交易中心管理系统主要提供顾客和供应商之间完成零件交易的功能，其中包括供应商信息、顾客信息以及零件信息。
此系统可以让供应商增加、删除和修改所提供的零件产品，还可以让顾客增加、删除和修改所需求的零件。
交易员可以利用顾客提出的需求信息和供应商提出的供应信息来提出交易的建议，由供应商和顾客进行确认后即完成这笔交易。
（三）系统需求分析
l．供应商
供应商的操作流程图如图5-1所示。
图5-1供应商操作分类表
2．顾客
顾客的地位和供应商几乎是对称的，所以功能分类上也很相似．顾客的操作流程图如图5-2所示。
图5-2顾客操作分类表
3．交易员
交易员的工作就是提出交易和完成交易。
这里需要仔细考虑的问题是：
一个交易如何产生，并如何达成，可以用图5-3来说明这个问题。
在处理交易的时候可能面临如下问题：
（1）一个交易只能在交易双方都同意的情况下才可以进行，所以数据库中的供求信息只能作为达成某个交易的基础；
（2）交易的双方可能不同时使用这个系统，因此需要系统提供一个双方交换信息的方式；
（3）系统需要提供一种方便系统（交易员）向用户提出建议来促成交易的途径，并在保证数据库数据完整性的情况下达成交易。
图5-3交易员操作图
（四）概念模型设计
数据库需要表述的信息有以下几种：
（1）零件信息
（2）供应商信息
（3）顾客信息
（4）供应商集和零件集之间的供应联系ER模型如图5-4所示。
图5-4供应商和零件之间的联系（供应）ER模型
（5）顾客集和零件集之间的求购联系ER图如图5-5所示。
图5-5顾客和零件之间的联系（求购）ER模型
（6）交易（三元联系）
可以用E/R模型表述该模型的设计，E/R图如图5-6所示。
图5-6全局ER模型
（五）逻辑模型设计
通过ER模型到关系模型的转化，可以得到如下关系模式：
（1）零件实体集转换为关系：
Part（ID，Color，Name，Weight，Intro）
（2）供应商实体集转换为关系Provider（ID，Name，Addtess，Tel，Intro）
（3）顾客实体集转换为关系Customer（ID，Name，Addtess，Tel）
（4）供应联系转换为关系Supply（PartlD，ProviderlD，Price，Quantity）
（5）求购联系转换为关系OfferToBuy（CustomerlD，PartID，Price，Quantity）
（6）交易联系转换为关系Business（CustomerlD，ProviderlD，PartID，Price，Quantity）
每个关系模式的主键码都用下划线标出。
同时，对于从联系导出的关系Supply（供应），OfferToBuy（求购）和Business（交易），使用与之相联系的实体集的主键码作为自己的键码，必须符合外键码约束。
对于Customer（顾客），Provider（供应商）和Part（零件）之间，不存在直接的约束，所以可以存在没有供应商供应同时也没有顾客求购的零件。
（六）物理模型设计
1．存储记录结构设计
表5.2Part表
列名
类型
长度
约束
ID
smallint
PRIMARYKEY
Color
varchar
20
Name
varchar
20
NOTNULL
Weight
int
DEFAULT0
Intro
text
其他表类似。
2．为了提高在表中搜索元组的速度，在实际实现的时候应该基于键码建立索引是各表中建立索引的表项：
（1）part（ID）
（2）Provider（ID）
（3）Customer（ID）
（4）Supply（PartID，ProviderID>
（5）OfferTOBuy（CustomerID，PartID）
（6）Business（CustomerlD，ProviderID，PartID）
（七）实现
1．建立Part表
CREATETABLEPart（
IDsmallintIDENTITY（1,1）PRIMARYKEYCLUSTERED,
Colorvarchar（20）,
Namevarchar（20）NOTNULL,
WeightintDEFAULT0,
Introtext）
2．建立Provider表
CREATETABLEProvider（
IDsmallintIDENTITY（1,1）PRIMARYKEYCLUSTERED,
Namevarchar（20）NOTNULL,
passwordvarchar（8）NOTNULL,
Addressvarchar（30）,
Telvarchar（20）,
Introtext）
3．建立Customer表
CREATETABLECustomer（
IDSmallintIDENTITY（1,1）PRIMARYKEYCLUSTERED,
Namevarchar（20）NOTNULL,
Addressvarchar（30）,
TeLVarchar（20））
4．建立Supply表
CREATETABLESupply（
PartIDSmallint,
ProviderIDsmallint,
Priceint,
QUantityint,
CONSTRAINTPK_SUPPLYPRIMARYKEYCLUSTERED（PartID,ProviderID）,
CONSTRAINTFK_SUPPLY_PARTIDFOREIGNKEY（PartID）REFERENCESPart（ID）,
CONSTRAINTFK_SUPPLY_PROVIDERIDFOREIGNKEY（ProviderID）REFERENCESProvider（ID））
5．建立OfferToBuy表
CREATETABLEOfferToBuy（
CustomerIDsmallint,
PartIDSmallint,
Priceint,
Quantityint,
CONSTRAINTPK_OFFERTOBUYPRIMARYKEYCLUSTERED（CustomerID,PartID）,
CONSTRAINTFK_OFFERTOBUY_CUSTOMERIDFOREIGNKEY（CustomerID）REFERENCESCustomer（ID）,
CONSTRAINTFK_OFFERTOBUYFOREIGNKEY（PartID）
REFERENCESPart（ID））
6．建立Business表
CREATETABLEBusiness（
CustomerIDsmallint,
ProviderIDsmallint,
PartIDSmallint,
Priceint,
Quantityint,
CONSTRAINTPK_BUSINEssPRIMARYKEYClUSTERED（CuscomerID,ProviderID,
PartID）,
CONSTRAINTFK_BUSINESS_CUSTOMERIDFOREIGNKEY（CustomerID）
REFERENCESCustomer（ID）,
CONSTRAINTFK_BUSINESS_PROVIDERlDFOREIGNKEY（ProviderID）
REFERENCESProvider（ID）,
CONSTRAINTFK_BUSINESS_PARTIDFOREIGNKEY（PartID）
REFERENCESPart（ID））
7．供应商操作
（1）注册（register）
INSERTINTOProvider（Name，password，Address，TeI，Intro）
VALUES（#Name，#password，#Address，#Tel，#Intro）
在登记操作后，供应商得到一个唯一的ID，可以根据这个ID采查询和修改供应商的数据。
（2）注销（unregister）
DELETEProviderWHERE（ID=#ID）；
（3）修改个人馆息（update）
UPdateProviderSet（Name=#Name,Address=#Address，Tel=#Tel，Intro=#Intro）
WHERE（ID＝#ID）；
（4）增加供应项（add_supply_item）
INSERTINTOSupply（PartID，Providerid，Price，Quantity）
VALUES（#PartID，#ProvderlD，#Price；#Quantily）；
（5）删除供应项（delete_supply_item）
DELETESupPly
WHERE（PartlD=#PartIDANDProvideID=#ProviderlD）；
（6）修改供应项（update_supply_item）
UPDATESupplySET（Price=#Price，Quantity=#Quantity）
WHERE（PartlD=#PartIDANDProviderID=#ProviderID）‘
很明显，系统并没有提供面向供应商修改零件信息的接口，所以供应商提供的零件必须已经在零件表中存在；可以这祥假设，交易所的管理员负责更新零件信息，而供应商可以向交易所申请增加某种零件的信息．事实上顾客也可以提出这样的要求。
8．顾客操作
（1）注册（register）
INSERTINTOCustomer（Name，Address，Tel）
VALUES（#Name，#Address，#Tel）；
在登记操作后，顾客得到一个唯一的ID，可以根据这个ID来查询和修改顾客的数据．
（2）注销（unregister）
DELETECustomer
WHERE（3）修改个人信息（update）
UPDATECustomerSet（Name=#Name，Address=#Address，Tel=#Tel）
WHERE（1D=#ID）；
（4）增加需求项（add_OfferToBuy_item）
INSERTINTOOfferToBuy（PartID,CustomeriD，Price，Quantity）
VALUES（#PartID，#CustomerID，#Price，#Quantity）'
（5）删除需求项（delete_OfferToBuy_iterm）
DELETEOfferToBuy
WHERE（PartlD=#PartlDANDCustomerlD=#CustomerID）；
（6）修改需求项（叩date_OfferToBuy_item）
UPDATEOfferToBuySET（Price=#Price，Quantity=#Quantity
WHERE（PartlD=#PartIDANDCustomeriD=#CustomerID）
9．交易员
针对需求分析中提出的问题，我们提出了“协议书”的解决方案，方案的说明如下：
（1）每个交易在达成以前都作为协议书保存在数据库中，协议书具有和交易一样的完备信息，可以在条件成熟的情况下转为一个达成的交易；
（2）协议书只有在供应商和顾客都签字的情况下才有效；有效的协议书由交易员签发，协议书一经签发，就生效，表明一个交易的达成，数据库中的数据将同时予以修改；
（3）协议书可以由供应商、顾客或者交易员
升级会员 