数据库 |
您所在的位置：网站首页 › 企业的三张报表之间的关系 › 数据库 |
数据库
|
第一章 概述
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）结构 字段数据类型长度是否允许空值STUIDCHAR13否STUSEXCAHR5否STUNAMEVCHAR10否STUNATVCHAR5是STUTELCHAR11否STUPOLVCHAR10是STUBIRDATE/否STUIDCARDCHAR18否MAJIDCHAR4否DIDCHAR10否以下是学生表（T_STU）的其他完整性约束 表 3.4‑2 学生表（T_STU）完整性约束 约束名约束内容STU_PK定义T_STU的主键为STUIDSTUSEX_CHECK约束性别的取值只能为男女STUID _CHECK约束学号为13位STUTEL _CHECK约束电话号为11位STUIDCARD _CHECK约束身份证号码为18位其中的寝室号和专业号虽然也有长度的限制，但是由于是外键，我们只需要在寝室和专业表中定义他们的完整性约束，减少了约束的冗余。 ② 专业表（T_MAJOR）结构 表 3.4‑3 专业表（T_MAJOR）结构 字段数据类型长度是否允许空值MAJIDCHAR4否MAJNAMEVARCHAR20否COLNAMEVARCHAR20否以下是专业表（T_MAJOR）的完整性约束 表 3.4‑4 专业表（T_MAJOR）完整性约束 约束名约束内容MAJOR_PK定义T_MAJOR表的专拣为MAJIDMAJID_CHECK约束专业ID为4位③ 学院表（T_COLLEGE）结构 表 3.4‑5 学院表（T_COLLEGE）结构 字段数据类型长度是否允许空值COLNAMEVARCHAR20否AREANAMEVARCHAR10否以下是学院表（T_COLLEGE）的完整性约束 表 3.4‑6 学院表（T_COLLEGE）表级完整性约束 约束名约束内容COLLEGE_PK定义T_COLLEGE表的主键为COLNAME④ 课程表（T_COURSE）结构 表 3.4‑7 课程表（T_COURSE）结构 字段数据类型长度是否允许空值COUIDCHAR11否COUNAMEVARCHAR20否COUTEACHERVARCHAR20否COLNAMEVARCHAR20否以下是课程表（T_COURSE）的完整性约束 表 3.4‑8 课程表（T_COURSE）完整性约束 约束名约束内容COURSE_PK定义T_COURSE表的主键为COUIDCOUID_CHECK约束COUID的长度为11位⑤ 校区表（T_AREA）结构 表 3.4‑9 校区表（T_AREA）结构 字段数据类型长度是否允许空值AREANAMEVARCHAR10否AREALOCVARCHAR20否以下是校区表（T_AREA）的完整性约束 表 3.4‑10 校区表（T_AREA）完整性约束 约束名约束内容AREA_PK定义AREA表的主键为AREANAME⑥ 宿舍楼表（T_BUILDING）结构 表 3.4‑11 宿舍楼表（T_BUILDING）结构 字段数据类型长度是否允许空值BIDCHAR6否AREANAMEVARCHAR10否BTYPEVARCHAR10否以下是宿舍楼表（T_BUILDING）完整性约束 表 3.4‑12 宿舍楼表（T_BUILDING）完整性约束 约束名约束内容BUILDING_PK定义BUILDING表的主键为BIDBID_CHECK约束BID的长度为6位BTYPE_CHECK约束BTYPE的取值只能是本科生公寓、研究生公寓、‘博士生公寓’⑦ 寝室表（T_DORM）结构 表 3.4‑13 寝室表（T_DORM）结构 字段数据类型长度是否允许空值DIDCHAR8否DNUMNUMBER2,0否BIDCHAR6否以下是寝室表（T_DORM）完整性约束 表 3.4‑14 寝室表（T_DORM）完整性约束 约束名约束内容DORM_PK定义寝室表的主键位DIDDID_CHECK约束DID的长度为8⑧ 选修表（T_LEARN）结构 表 3.4‑15 选修表（T_LEARN）结构 字段数据类型长度是否允许空值LEASTUIDCHAR13否LEACOUIDCHAR11否LEAGRADENUMBER3,0是以下是选修表（T_LEARN）完整性约束 表 3.4‑16 选修表（T_LEARN）完整性约束 约束名约束内容LEA_PK定义选修表的主键为LEAGRADE_CHECK约束成绩的取值在0到100之间 3.4.2 外键约束根据关系模型，我们将设置各表中外键的参考，其名称和内容如下表所示： 表 3.4‑17 外键约束说明表 外键约束名约束内容STU_MAJ_FK定义学生表和专业表中“专业”字段的外键参考STU_DORM_FK定义学生表和寝室表中“寝室号”字段的外键参考MAJ_COL_FK定义专业表和学院表中“学院名”字段的外键参考COL_AREA_FK定义学院表和校区表中“校区名称”字段的外键参考BUI_AREA_FK定义宿舍楼表和校区表中“校区名称”字段的外键参考DOR_BUI_FK定义寝室表和寝室楼表中“寝室楼号”字段的外键参考COU_COL_FK定义课程表和学院表中“开设学院”字段的外键参考LEA_STU_FK定义选修表和学生表中“学号”字段的外键参考LEA_COU_FK定义选修表和课程表中“课程编号”字段的外键参考 3.5 用户和权限授予规划在2.4中，我们分析了各部门的职责，我们需要建立用户并授予相应权限。为了防变各部门操作，我们将建立学生的基本信息视图，供各个部门查询。 下表为用户和用户权限及对应部门： 表 3.5‑1 用户权限授予规划 用户名授予部门用户权限转让U_ROOT技术管理部DBA权限是U_STUDENT学工部对STU，MAJOR，COLLEGE的全部权限，对信息视图的SELECT权限否U_TEACH教务处对COURSE表和LEARN表的全部权限，对基本信息视图的SELECT权限否U_LOGISTICS后勤处对BUILDING表和DORM表的全部权限，信息视图的SELECT权限否 第四章 代码与实现在这部分中，我们将借助Oracle数据库和SQL语言，进行表格的建立和关系的设置，同时进行数据的插入，视图的建立，以及相应的用户权限设置。 4.1 Oracle简介Oracle Database，又名Oracle RDBMS，或简称Oracle。是甲骨文公司的一款关系数据库管理系统。它是在数据库领域一直处于领先地位的产品。可以说Oracle数据库系统是世界上流行的关系数据库管理系统，系统可移植性好、使用方便、功能强，适用于各类大、中、小微机环境。它是一种高效率的、可靠性好的、适应高吞吐量的数据库方案。符合我们的应用场景。 4.2 表的建立在这部分中，我们使用数据库定义语言(DDL)对各数据表进行建立，其语句和结果如下所示： CREATE TABLE T_STU( -- 学生实体 STUID CHAR(13) NOT NULL, -- 学生实体的主键 STUSEX CHAR(5) NOT NULL, STUNAME VARCHAR(10) NOT NULL, STUNAT VARCHAR(5), -- 民族 STUTEL CHAR(11) NOT NULL, STUPOL VARCHAR(10), -- 政治面貌 STUBIR DATE NOT NULL, -- 出生年月 STUIDCARD CHAR(18) NOT NULL, -- 身份证号 MAJID CHAR(4) NOT NULL, -- 专业ID DID CHAR(9) NOT NULL, -- 宿舍ID -- 表级完整性约束 CONSTRAINT STU_PK PRIMARY KEY(STUID), -- 检查字段长度和域的列级完整性约束 CONSTRAINT STUSEX_CHECK CHECK(STUSEX IN('男','女')), CONSTRAINT STUID_CHECK CHECK(LENGTH(STUID) = 13), CONSTRAINT STUTEL_CHECK CHECK(LENGTH(STUTEL) = 11), CONSTRAINT STUIDCARD_CHECK CHECK(LENGTH(STUIDCARD) = 18) ENABLE ); CREATE TABLE T_MAJOR( -- 专业实体 MAJID CHAR(4) NOT NULL, -- 专业ID 该实体的主键 MAJNAME VARCHAR(20) NOT NULL, COLNAME VARCHAR(20) NOT NULL, CONSTRAINT MAJOR_PK PRIMARY KEY(MAJID), CONSTRAINT MAJID_CHECK CHECK(LENGTH(MAJID) = 4) ENABLE ); CREATE TABLE T_COLLEGE( -- 学院实体 COLNAME VARCHAR(20) NOT NULL, -- 学院名称 作为该实体的主键 AREANAME VARCHAR(10) NOT NULL, CONSTRAINT COLLEGE_PK PRIMARY KEY (COLNAME) ENABLE ); CREATE TABLE T_COURSE( -- 课程实体 COUID CHAR(11) NOT NULL, -- 课程序号 作为实体的主键 COUNAME VARCHAR(30) NOT NULL, -- 课程名 COUTEACHER VARCHAR(20) NOT NULL, -- 授课老师 COLNAME VARCHAR(20) NOT NULL, -- 开设学院 CONSTRAINT COURSE_PK PRIMARY KEY (COUID), CONSTRAINT COUID_CHECK CHECK(LENGTH(COUID) = 11) ENABLE ); CREATE TABLE T_AREA( -- 校区实体 AREANAME VARCHAR(10) NOT NULL, --校区名称 作为主键 AREALOC VARCHAR(20) NOT NULL, CONSTRAINT AREA_PK PRIMARY KEY (AREANAME) ENABLE ); CREATE TABLE T_BUILDING( -- 宿舍楼实体 BID CHAR(6) NOT NULL, -- 宿舍楼ID 主键 AREANAME VARCHAR(10) NOT NULL, BTYPE VARCHAR(10) NOT NULL, CONSTRAINT BUILDING_PK PRIMARY KEY (BID), CONSTRAINT BID_CHECK CHECK(LENGTH(BID) = 6), CONSTRAINT BTYPE_CHECK CHECK(BTYPE IN ('本科生公寓','研究生公寓','博士生公寓')) ENABLE ); CREATE TABLE T_DORM( -- 寝室实体 DID CHAR(9), -- 寝室ID 主键 DNUM NUMBER(2,0), BID CHAR(6), CONSTRAINT DORM_PK PRIMARY KEY (DID), CONSTRAINT DID_CHECK CHECK(LENGTH(DID) = 9) ENABLE ); -- 处理学生选课和课程之间 M：N的关系 CREATE TABLE T_LEARN( STUID CHAR(13) NOT NULL, -- 选课学生学号 COUID CHAR(11) NOT NULL, -- 课程ID LEAGRADE NUMBER(3,0), CONSTRAINT LEA_PK PRIMARY KEY (STUID,COUID), -- 共同做为主键 CONSTRAINT LEAGRADE_CHECK CHECK(LEAGRADE>0 AND LEAGRADE |
【本文地址】
今日新闻 |
推荐新闻 |