数据库——基于软件工程的数据库设计与实现报告

最新推荐文章于 2025-03-01 19:34:06 发布

夏夏夏至

最新推荐文章于 2025-03-01 19:34:06 发布

阅读量2.8k

点赞数 5

文章标签：软件工程数据库 sql

本文链接：https://blog.csdn.net/qq_45945307/article/details/131362158

版权

本文详细阐述了软件工程管理的现状与挑战，强调了其重要性和意义，并以学生信息管理系统为例，进行了需求分析，包括应用环境、适用用户群体和功能分析。接着，文章深入到系统设计阶段，包括概念设计、E-R图绘制、数据表建立、外键约束和用户权限规划。最后，介绍了数据插入、视图查看、用户权限测试以及性能测试的过程，展示了如何将软件工程管理原则应用于数据库系统的实现和优化。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

第一章概述

1.1 软件工程管理的概述

所谓计算机软件工程化管理就是指在软件开发、应用、测试等各个环节中广泛采用工程管理方面的知识、理论与经验，从而对计算机软件研发的各个环节进行定义、管理与评估，使每个项目、环节、研发活动都能够有序地进行，从而确保计算机软件研发的质量、提高软件的应用性与维护性，降低生产研发过程中的投资成本。

在近年来的开发与研究过程中，人们逐渐形成对计算机软件全新的认识与理解，并制定科学化、现代化的研究目标，在工程化管理的基础上，实现计算机软件开发流程的精细化、有序化、高效化，有效利用生产中人力、物力、财力等各方面资源…。

1.2 软件工程管理的现状

软件工程管理这门学科具有两个显著的特征，即：创造性、挑战性。当前，针对软件工程，并未确定一个有效的、成熟的管理模式。一些常见的问题表现如下：

其一，缺乏软件工程管理系统性的培训。软件企业的项目经理是由技术能力较强的员工来担任，但是这些员工通常是仅仅具备了较强的技术能力，他们自身并未掌握丰富的软件工程管理相关知识，这就导致在具体管理工作方面缺乏相应的经验，直接影响到了软件工程项目管理工作的效果。

其二，缺乏软件工程计划意识。软件企业的项目经理不仅缺乏对软件开发的总体计划意识，同时还缺乏对软件开发阶段的计划意识。因此，在开展软件工程项目管理工作的过程中，计划的执行效果和可行性偏低。

其三，缺乏管理意识。软件开发企业的项目经理，通常会将自身大量的精力放在技术研发与管理方面，而忽略了软件工程管理这项工作的重要性。因此，在实际的工作过程中，经常会出现任务分配不得当、项目计划完成效果偏低等问题，对软件工程工程管理工作带来负面影响。

其四，软件工程管理工作日益复杂。当前，软件工程项目的规模正在逐步扩大，参与到项目中的人员也越来越多，这就导致软件工程管理工作变得日益复杂，增加了管理工作的难度。

1.3 软件工程的意义

软件项目的开发其实是一个工程，整个开发过程是可以有效组织起来的；了解软件工程的知识可以帮助开发者把控开发过程的各个阶段，获得解决问题的最佳实践，寻找方法来帮助我们高效完成任务；并且借助工具来协助管理，提升开发效率。软件工程的尤其应用必要性：

软件的不断变化的性质

软件的性质，即其组件和功能在满足需求方面始终保持不变，并且会不时进行更改。因此，不可能将一切(例如需求，设计等)都确定为软件开发的初始阶段。因此，如果我们在项目中遵循软件工程技术，那么我们将有可能处理此类更改。

软件日益复杂

随着更多的功能和更多的模块添加到软件中，集成这些功能模块变得很困难。这在软件的开发和维护期间增加了复杂性。同样，在某些情况下，我们可能也需要更改设计和现有代码。因此，如果我们从一开始就遵循软件工程规范，那么这种情况就可以得到妥善的处理。

为了提高软件质量

提高软件的质量，以便我们可以体验与它的良好连接，并且使我们易于使用它。

软件行业处于危机中

根据进行的调查，只有大约15-17％的软件开发可以成功并达到最终部署阶段。余下的由于反复失败而被迫取消开发计划，而其他的则因预算超支而被迫取消。他们大多因为开发人员在开始开发任务之前没有做出明智的计划。如果他们遵循软件工程的准则，那么由于故障或由于预算超支而被取消的项目案例将大大减少。

软件故障

即使在部署软件之后，很多软件也面临着巨大的潜在故障可能。发生这种情况往往是因为软件测试阶段未正确执行。如果在开发任何项目时都遵循软件工程规范，则也可以消除此问题。

第二章需求分析

2.1 应用环境

学生信息管理是学校学生管理工作的重要部分，完善的学生信息系统支撑着学生的基本信息，住宿，课程，成绩等诸多子信息系统。基于数据库设计的学生信息管理系统的开发能大大减轻管理人员工作量﹐并且使得学生管理工作信息化，更加稳定高效。同时能使各部门不同人员能够在权限范围内获得信息。

该系统主要包括学生信息管理、课程和成绩信息管理、学院和专业管理，学院和校区管理等。为实现这些功能，基本的功能描述如下所示：

完成各项栏目的数据的录入和修改，并提交数据库保存。其中的数据包括学生信息、课程成绩信息、学院专业信息等。
实现基本信息的查询。包括学生信息的查询、课程信息的查询和成绩的查询等。
实现信息的修改。主要包括各学生基本信息的修改、学生选修课程情况修改、开设课程的成绩修改等。
其他实际运行中的具体功能

对于该信息系统有如下要求：

能准确表示业务数据
使用方便、易于维护
对最终用户操作的响应时间合理
便于数据的检索和修改
维护数据库的工作较少
冗余数据最少或不存在

2.2 适用用户群体

该数据库设计适用于与中小规模院校。

2.3 功能分析

针对使用中具体情况，我们的数据库具有以下功能：

学生入学时会记录身份信息，包括姓名、性别、出生日期、民族、身份证号、学号、政治面貌、手机号码等相关信息。
学校有多个学院和多个校区。学生可因转专业而更换所属学院，但其入学时分配的学号不变。学生分布在所属学院所在的校区，并且可能会根据情况进行调整。
学院有多个专业，学生属于不同的专业，允许学生转专业和对专业的名称以及所属学院进行修改
学院开设多门课程，学生可以修读多门课程，系统需要记录学生修读的课程信息和成绩情况。
每个校区有多栋宿舍楼，宿舍楼的类别有博士生公寓、硕士生公寓和本科生公寓。
系统需要完整记录学生的基本信息、当前所在学院、所在校区、所住宿舍楼寝室，以及其他可能需要的信息。

2.4 部门权限分析

为了便于不同部门的管理和信息的保护，我们应当建立视图，并且对用户进行权限的授予，将部门所需要的数据给予用户，而隐藏其他数据，我们的部门设计有：

技术管理部门，负责建立维护数据库，拥有DBA权限；
学工部，负责学生基本信息的维护，能够获取学生的基本信息
教务处，负责课程和成绩信息的录入
后勤部，负责宿舍管理

其余的信息基本无需变动，如有变动可以交由技术管理部进行变动。

第三章系统设计

3.1 概念设计

3.1.1 实体和属性分析

由需求分析，我们可以确定该学生信息管理系统的实体主要有：学生、专业、学院、校区、宿舍楼、宿舍、课程。

根据需求和实际应用情况，我们设计各实体的属性如下所示：

学生实体的属性：姓名、性别、出生日期、民族、身份证号、学号、政治面貌、手机号码
专业实体的属性：专业名称，专业代码
学院实体的属性：学院名称
校区实体的属性：校区名称，所在位置
宿舍楼实体的属性：宿舍楼编号，宿舍楼类型
宿舍实体的属性：宿舍编号，宿舍人数
课程实体的属性：课程名称，课程序号，授课教师，课程教室

同时我们对其中的部分属性做出规范要求，要求宿舍楼编号为“校区号+组团号+楼栋号”，要求宿舍编号为“宿舍楼编号+寝室号”。

3.1.2 实体之间的联系

针对实体之间的关系，结合需求分析和实际应用情况，有如下表述：

学生和专业之间有1:n的关系，一个学生仅能修读一个专业，一个专业有多个学生修读
学生和宿舍之间有1:n的关系，一个学生仅能居住于一个寝室，一个寝室有多个学生
学生和课程之间有m:n的关系，一个学生可以修读多个课程，一个课程有多个学生修读
专业和学院之间有1:n的关系，一个专业仅能属于一个学院，一个学院开设多个专业
学院和课程之间有1:n的关系，一个课程仅能由一个学院开设，一个学院可以开设多门课程
学院和校区之间有1:n的关系，一个学院仅能位于一个校区，一个校区内有有多个学院
校区和宿舍楼之间有1:n的关系，一个楼栋仅能位于一个校区，一个校区内有多个楼栋
宿舍楼和宿舍之间有1:n的关系，一个宿舍仅能位于一个楼栋，一个楼栋有多个寝室

3.2 总体E-R图

这一部分，我们使用E-R图进行逻辑设计，E-R图的各部分表述约定如下：

实体用方框表示，联系用菱形框表示，属性用椭圆框表示；
在框中标注实体名、联系名、属性名；
主键由下划线指出

图 3.2‑1 学生信息管理系统E-R图设计

3.3 概念设计

首先根据上图，将七个实体转换为七个模式，约定主键用斜体给出：

① 学生（学号，姓名，性别，民族，手机号，政治面貌，出生日期，身份证号）

② 专业（专业ID，专业名称）

③ 学院（学院名称）

④ 课程（课程代码，课程名称，任课老师）

⑤ 校区（校区名称，地点）

⑥ 宿舍楼（楼栋号，类型）

⑦ 宿舍（宿舍号，人数）

而后针对1:n的关系，在各模式中增加外键，修改如下所示，为了醒目，增加的外键内容用粗体标出：

① 学生（学号，姓名，性别，民族，手机号，政治面貌，出生日期，身份证号，专业ID，宿舍号）

② 专业（专业ID，专业名称，学院名称）

③ 学院（学院名称，校区名称）

④ 课程（课程代码，课程名称，任课老师，学院名称）

⑤ 校区（校区名称，地点）

⑥ 宿舍楼（楼栋号，类型，校区名称）

⑦ 宿舍（宿舍号，人数，楼栋号）

对于m:n的课程和学生之间的关系，我们需要生产新的关系模式：

① 修读（课程代码，学号，成绩）

最后得到八个关系模式如下所示：

① 学生（学号，姓名，性别，民族，手机号，政治面貌，出生日期，身份证号，专业ID，宿舍号）

② 专业（专业ID，专业名称，学院名称）

③ 学院（学院名称，校区名称）

④ 课程（课程代码，课程名称，任课老师，学院名称）

⑤ 校区（校区名称，地点）

⑥ 宿舍楼（楼栋号，类型，校区名称）

⑦ 宿舍（宿舍号，人数，楼栋号）

⑧ 修读（课程代码，学号，成绩）

3.4 数据表的建立

在这部分，我们根据设计好的模式，建立数据表和各字段，给出其类型和大小，以及列完整性约束和表级完整性约束：

我们首先规定表以及视图和属性和命名规则：

表采用 T_**
视图采用 V_**
用户采用U_***
属性命名使用表名+属性名，外键使用参照表中的命名，便于自然连接
主键采用 **ID，主键约束使用**_PK
外键约束采用 __FK
属性域约束名使用***_CHECK
所有的对象命名采用英文

我们将分两部分，从数据表的字段，列完整性约束和主键约束，以及第二部分的外键约束来叙述我们的表。

3.4.1 表数据字段，列完整性约束和主键约束

以下是各模式的表结构：

① 学生表（T_STU）结构

表 3.4‑1 学生表（T_STU）结构

字段	数据类型	长度	是否允许空值
STUID	CHAR	13	否
STUSEX	CAHR	5	否
STUNAME	VCHAR	10	否
STUNAT	VCHAR	5	是
STUTEL	CHAR	11	否
STUPOL	VCHAR	10	是
STUBIR	DATE	/	否
STUIDCARD	CHAR	18	否
MAJID	CHAR	4	否
DID	CHAR	10	否

以下是学生表（T_STU）的其他完整性约束

表 3.4‑2 学生表（T_STU）完整性约束

约束名	约束内容
STU_PK	定义T_STU的主键为STUID
STUSEX_CHECK	约束性别的取值只能为男女
STUID _CHECK	约束学号为13位
STUTEL _CHECK	约束电话号为11位
STUIDCARD _CHECK	约束身份证号码为18位

其中的寝室号和专业号虽然也有长度的限制，但是由于是外键，我们只需要在寝室和专业表中定义他们的完整性约束，减少了约束的冗余。

② 专业表（T_MAJOR）结构

表 3.4‑3 专业表（T_MAJOR）结构

字段	数据类型	长度	是否允许空值
MAJID	CHAR	4	否
MAJNAME	VARCHAR	20	否
COLNAME	VARCHAR	20	否

以下是专业表（T_MAJOR）的完整性约束

表 3.4‑4 专业表（T_MAJOR）完整性约束

约束名	约束内容
MAJOR_PK	定义T_MAJOR表的专拣为MAJID
MAJID_CHECK	约束专业ID为4位

③ 学院表（T_COLLEGE）结构

表 3.4‑5 学院表（T_COLLEGE）结构

字段	数据类型	长度	是否允许空值
COLNAME	VARCHAR	20	否
AREANAME	VARCHAR	10	否

以下是学院表（T_COLLEGE）的完整性约束

表 3.4‑6 学院表（T_COLLEGE）表级完整性约束

约束名	约束内容
COLLEGE_PK	定义T_COLLEGE表的主键为COLNAME

④ 课程表（T_COURSE）结构

表 3.4‑7 课程表（T_COURSE）结构

字段	数据类型	长度	是否允许空值
COUID	CHAR	11	否
COUNAME	VARCHAR	20	否
COUTEACHER	VARCHAR	20	否
COLNAME	VARCHAR	20	否

以下是课程表（T_COURSE）的完整性约束

表 3.4‑8 课程表（T_COURSE）完整性约束

约束名	约束内容
COURSE_PK	定义T_COURSE表的主键为COUID
COUID_CHECK	约束COUID的长度为11位

⑤ 校区表（T_AREA）结构

表 3.4‑9 校区表（T_AREA）结构

字段	数据类型	长度	是否允许空值
AREANAME	VARCHAR	10	否
AREALOC	VARCHAR	20	否

以下是校区表（T_AREA）的完整性约束

表 3.4‑10 校区表（T_AREA）完整性约束

约束名	约束内容
AREA_PK	定义AREA表的主键为AREANAME

⑥ 宿舍楼表（T_BUILDING）结构

表 3.4‑11 宿舍楼表（T_BUILDING）结构

字段	数据类型	长度	是否允许空值
BID	CHAR	6	否
AREANAME	VARCHAR	10	否
BTYPE	VARCHAR	10	否

以下是宿舍楼表（T_BUILDING）完整性约束

表 3.4‑12 宿舍楼表（T_BUILDING）完整性约束

约束名	约束内容
BUILDING_PK	定义BUILDING表的主键为BID
BID_CHECK	约束BID的长度为6位
BTYPE_CHECK	约束BTYPE的取值只能是本科生公寓、研究生公寓、‘博士生公寓’