数据库原理课程设计编写规范模板文档格式.docx

数据库原理课程设计编写规范模板文档格式.docx

《数据库原理课程设计编写规范模板文档格式.docx》由会员分享，可在线阅读，更多相关《数据库原理课程设计编写规范模板文档格式.docx（8页珍藏版）》请在冰豆网上搜索。

其它标准如下：

一、页面设置：

上2.5cm，下25cm，左2.5cm，右2cm，页眉1.5cm，页脚1.75cm。

采用单倍行距，标准字符间距。

西文、数字等符号均采用TimesNewRoman体字。

二、摘要：

独占一页；

论文题目用小2号黑体字、居中；

“摘要”用3号黑体字、居中；

正文用小4号宋体字。

关键词用小4号黑体字、居左顶格、单独占行，关键词之间用分号间隔。

三、目录：

“目录”用小2号黑体字、居中；

目录内容最少列出第一级标题（章）和第二级标题（节）；

前者用4号黑体字，后者用4号宋体字，第三级标题用4号楷体字，居左顶格、单独占行，每一级标题后应标明起始页码。

四、页眉：

奇数页书写“数据库原理课程设计”，用宋体小五号书写。

偶数页书写“学生姓名：

课程设计的题目”，用宋体小五号书写。

五、页脚：

页码居右，用TimesNewRoman字体小五号书写。

六、正文的层次划分和编排方法

正文是论文的主要组成部分，题序层次是文章结构的框架。

章条序码统一用阿拉伯数字表示，题序层次可以分为若干级，各级号码之间加一小圆点，末尾一级码的后面不加小圆点，层次分级一般不超过4级为宜，示例如下：

第一级（章）1，2，3，…

第二级（条）1.1,1.2,…2.1,2.2,…3.1,3.2,……

第三级（条）1.1.1,1.1.2,…1.2.1,1.2.2,…2.1.1,2.1.2,…2.2.1,2.2.2,…

第四级（条）1.1.1.1,1.1.1.2,…1.2.2.1,1.2.2.2,……2.1.1.1,2.1.1.2,…2.2.2.1,2.2.2.2

如果有前言或其它类似形式的章，可以不编序号，也可以编为“0”。

题序层次编排格式为：

章条编号一律左顶格，编号后空一个字距，再写章条题名。

题名下面的文字一般另起一行，也可在题名后，但要与题名空一个字距。

如在条以下仍需分层，则通常用a，b，…或1）,2）,…编序，左空2个字距。

打印论文，论文题目用黑体一号字，居中放置，并且距下文双倍行距。

第一级（章）题序和题名用黑体小二号字，第二级（条）题序和题名用黑体小三号字，第三级（条）题序和题名用黑体四号字，第四级（条）题序和题名用黑体小四号字，各级与上下文间均单倍行距。

正文各层次内容用宋体小四号字（英文用新罗马体12），单倍行距。

七、图表

论文中的选图及制图力求精炼。

适于文字说明的，就不要用图。

所有图表均应精心设计，不得勾画。

各类图表的绘制均应符合国家标准。

论文中的表一律不画左右端线，表的设计应简单明了。

图表中所涉及到的单位一律不加括号，用“，”与量值隔开。

图表均应有标题，并按章编号（如图1-1、表2-2等）。

图表标题均居中书写，字号比正文小一号。

文档格式规范

文档中除了在封面应有题目、班级、姓名、学号和课程设计日期以外，其正文一般有如下几个方面的内容：

需求分析：

明确用户的各种需求，然后在此基础上确定新系统的功能。

新系统必须充分考虑今后可能的扩充和改变。

此阶段文档要求画出数据流图，但要求给出数据字典，对系统的信息要求（数据分析）和处理要求（功能分析）要详尽。

这是系统的起点也是关键。

概要结构设计：

对需求分析阶段收集到的数据进行分类、组织，形成实体、实体的属性,初步标识实体的码,设计分E-R图。

各子系统的分E-R图设计好以后,下一步要将所有的分E-R图综合成一个系统的总E-R图。

确定实体之间的联系类型（1:

1,1:

n,m:

n）。

（划分实体和属性的基本准则参照教材，同时考虑合并E-R图所产生的冲突问题和冗余问题。

）

逻辑结构设计：

把概念结构设计阶段设计好的基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构，即将实体和实体间的联系转换为关系模式，并确定这些关系模式的属性和码。

（转换原则参见教材）。

根据所学得的关系模式规范化理论，对关系模式进行优化，使其基本满足三范式要求。

物理结构设计：

为给定的逻辑数据模型选取一个最适合应用环境的物理结构，要求详细写出基本表的结构，包括表名、各个字段名、字段描述、类型、长度、是否为空等，同时标出基本表的主码、外码、索引等。

课题设计说明书参考实例

（客房预定系统设计）

一、需求分析：

给出数据流图（同学们写的时候必须给出），数据字典（数据项、数据结构、数据流、数据存储和处理过程）

文字描述：

顾客可以用电话或上网注册的方式预定。

其方式不同，但提交的内容是相同的：

需要的房间类型，房间数，客人人数，预定时间，退房时间等。

服务台查询客房管理部，看看是否有满足客人要求的客房。

如果有，则记录下客人的需要，同时客房管理部通知财务部准备收预约金，同时反馈给客人确认信息。

如果客人要求的客房无法提供，则通知顾客无法满足

此处加上数据字典部分。

二、概念设计

◆实体：

顾客，服务台，客房，客房管理部，财务部

◆局部视图：

1、顾客－预定－服务台

事务规则：

一个服务台可以为多个顾客服务

一个顾客在一个服务台进行预订活动

2、服务台－查询－客房管理部

一个客房管理部可以为多个服务台服务

每个服务台最终只和一个客房管理部联系

3、客房管理部－管理－客房

1个客房管理部管理多个客房

一个客房由一个客房管理部管理

4、客房管理部－财务收入－财务部

一个酒店或旅馆只会有一个客房管理部和财务部（1：

1）

◆视图集成

•局部视图集成会发生冲突，主要是同名异义、同义异名的问题

•同名异义：

如“服务台—联系电话；

顾客—联系电话”

•同义异名：

如“顾客—身份证号；

财务部—顾客身份证号”

三、逻辑设计

将E-R图转化为关系模式（不是最终的）

•顾客（姓名，性别，身份证号，联系电话，家庭住址，客房种类，房间数，订房日期，退房日期，服务台台号，当值服务员工号）3NF

•服务台（服务台台号，服务台联系电话，订房编号）3NF

•客房（客房编号，客房种类，客房位置，客房单价，客房设备，今日状态）2NF

•客房管理部（订房编号，客房编号）3NF

•财务部（订房编号，预约金，身份证号）3NF

其中，“客房”是2NF，因为：

客房编号—>

客房种类，客房位置，今日状态；

客房种类—>

客房单价，客房设备。

因而存在传递依赖，需要分解。

将客房分解为客房和客房信息设定两个实体：

•R1：

客房（客房编号，客房种类，客房位置）

•R2：

客房信息设定（客房种类，客房单价，客房设备）

规范化得到最终的关系模式

●顾客（姓名，性别，身份证号，联系电话，家庭住址，客房种类，房间数，订房日期，退房日期，服务台台号，当值服务员工号）3NF

●服务台（服务台台号，服务台联系电话，订房编号）3NF

●客房（客房编号，客房种类，客房位置，今日状态）3NF

●客房信息设定（客房种类，客房单价，客房设备）3NF

●客房管理部（订房编号，客房编号）3NF

●财务部（订房编号，身份证号，预约金）3NF

四、检验是否满足用户需求

◆例行事务需求

1.客户订房

查询客房信息，修改客房空闲状态，修改财务报表

2.客户退房

修改客房空闲状态，删除客户信息

◆查询事务需求

1.查询某一客户的订房情况

根据顾客身份证号查询表财务部信息和客房管理部信息

2.查询是否有满足用户要求的客房

•查询某种客房的空闲房间数

•查询某一客房何时会空闲（查客房信息和客房信息设定）

3.报表需求

•生成顾客订房信息

用到的表：

客房信息，顾客信息

•生成客房标准信息

客房信息设定

五、其它数据库对象（物理数据库设计）的考虑

1、合法用户名字、权限、角色

2、视图（一个或一个以上）

3、触发器（一个或一个以上）

4、索引

六、备份及恢复策略

制定恢复策略