电子科技大学数据库与软件工程实验四（课程设计）
E-R图设计，关系模式
适用于网工和物联网专业
目录
相关内容涉及隐私部分没有列出
此部分是期末考试最后一个大题
注明：本章节没有结果截图，可以根据图题信息自己截取，因为信息涉及个人隐私就没有放出来
第一章 概述
1.1软件工程的起源
1.1.1软件危机
软件工程学科的产生背景是为了应对解决软件危机。
20 世纪60年代以前，计算机刚刚投入实际使用，软件设计往往只是为了一个特定的应用而在指定的计算机上设计和编制，采用密切依赖于计算机的机器代码或汇编语言，软件的规模比较小，文档资料通常也不存在，很少使用系统化的开发方法，设计软件往往等同于编制程序，基本上是个人设计、个人使用、个人操作、自给自足的私人化的软件生产方式。
60年代中期，大容量、高速度计算机的出现，使计算机的应用范围迅速扩大，软件开发急剧增长。高级语言开始出现；操作系统的发展引起了计算机应用方式的变化；大量数据处理导致第一代数据库管理系统的诞生。软件系统的规模越来越大，复杂程度越来越高，软件可靠性问题也越来越突出。原来的个人设计、个人使用的方式不再能满足要求，迫切需要改变软件生产方式，提高软件生产率，软件危机开始爆发 。
1.1.2软件工程概念提出
1968年，北大西洋公约组织（NATO）在联邦德国的国际学术会议创造软件危机（Software crisis）一词。而1960年代中期开始爆发众所周知的软件危机，为了解决问题，在1968、1969年连续召开两次著名的NATO会议，并同时提出软件工程的概念。
在软件开发中遇见的问题找不到解决的方法，问题积累起来，形态尖锐的矛盾，导致了软件危机。由于当时单个的程序开发技术已经不能应用到大型、复杂的软件系统。导致花费时间长、预计的费用高、不可靠、难以维护。为了更加有效的解决质疑问题，从而催生了软件工程学科。
1.2软件工程的定义
计算机百科全书上的软件工程定义：
应用计算机科学、数学及管理科学等原理，以工程化方法制作软件的工程。它借鉴传统工程的原则、方法，创建软件以达到提高质量，降低成本的目的。
其中，计算机科学、数学用于构造模型与算法，工程科学用于指定规范、设计范型、评估成本 及确定权衡，管理科学用于计划、资源、质量、成本等管理。
软件工程是一门指导计算机软件开发和维护的工程学科。软件工程师一门交叉性学科。
首次NATO会议上的软件工程定义：
软件工程是用来建立和使用合理的工程原则，以经济地获取可靠的、且在真实机器上可高效工作的软件。
IEEE中软件工程定义：
(1)将系统化的、规范的、可量化的方法应用到软件的开发、运行及维护中，即将工程化方法应用于软件；
(2)在(1)中所述方法的研究。
1.3层次化的软件工程
软件工程是层次化的技术，具体可分为以下四个层次：
工具层：在软件开发过程中，工具提供了自动或半自动化的支持，例如：建模工具 Rational Rose。
方法层:方法提供了开发软件在技术上需要的一系列的任务，包括需求分析、编程、测试等。
过程层:过程提供了开发的框架，使得软件能够合理、及时的被开发。
质量保证层: 建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。 软件质量保证的目的是使软件过程对于管理人员来说是可见的。 它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。
图1-1 软件工程层次图
此外软件工程一个多学科融合的学科，涉及了数学、工程学、计算机科学、心理学、管理学和经济学等学科的知识，一个系统化、标准化和层次化的工程。
1.4软件工程管理的意义
1）虽然软件在开发项目时即使没有其项目管理，该软件项目依然会成功，但是软件开发的本意在于盈利，而项目管理恰恰是盈利的保证，这便使得软件在进行开发工作时，一个好的项目管者对该项目所产生的作用非同小可；在软件开发工作中，虽然实施项目管理可以满足盈利者对该项软件项目的诸多要求，但是本质上就是在利用各个项目以及各个方面的干系人进行相互协作的同时，再把相关资源融入到软件开发项目之中，进而实现预期的目标。
2）当前，我国许多软件开发企业在发展时，不论是在产品型软件上，还是在项目型软件上，这些软件开发公司在其软件开发及管理方式上都没有找到切合本公司实际情况的管理模式。虽然有一些个别的软件开发公司依据相关理论拟定出了相关管理方案，然而这在根本上依然无法解决软开发中所会遇到的时间、利润、质量掌控等问题。因此，这便导致了工作时间延长、风险发生机率不稳定、软件产品质量不可控等问题，特别是到了软件开发的最后阶段，还常常会出现维护困难和升级困难等问题，这样不仅会威胁到软件用户的利益，同时还会损害软件开发企业的效益。据上所述，在开展软件开发工作时，对其实施有效的项目管理工作不仅可以保证软件开发的成功率，同时还能让企业的盈利额度得到最大的提升。
1.5软件工程管理的现状
1）随着当今信息科技水平的不断提高，软件开发与生产工作的规模也就越显庞大，而与此同时，软件开发的各项环节也就变得复杂化起来，因此，这便使得一些规模较小的，或者是小作坊式的软件开发模式无法再适应现今社会飞速发展的需要；而现阶段，许多软件企业都在发展的同时积极并努力地将项目管理模式融入到软件开发工作中来，进而对软件开发工作实施合理的、科学的、有效的管理；软件项目管理工作的实施，满足了对利润、工作人员、效率、质量和风险等因素的管理要求，使得软件开发工作可以在预期的利润、效率及质量需求下得到完善。
2）在开展软件开发工作时，各个项目的负责人员都要在规定的时间内完成自己所负责的领域工作，然后利用规范化、合理化、科学化的管理方针进行项目管理，这样不仅可以帮助企业降低对相关技术人员的要求，同时还从根本上降低了软件产品研发时所需要的资金投入；对软件开发工作实施项目管理，不仅有利于企业在利润上的获得，同时还能帮助一些软件开发人员的个人企业能力得到进一步的提高。
3）当前，软件开发工作正在向多样化与复杂化靠近，特别是许多开发团队在进行常会软件开发工作时，甚至会出现同一时间不同版本的情况，再加上一些多地点一起研发和开发与保护并存等问题的出现，这便为软件开发与管理工作做成了严重的困难与影响。倘若不对此给予严格的管理，或者在管理中稍有不慎，那么将会对软件开发工作带了一系列的干扰性问题，比如版本区分混淆和工作人员相互干扰等。
1.5软件工程管理的重要性
在计算机软件开发过程中，项目管理主要包括项目的成本，质量，风险，进度等，是否能够按照预期计划完成，能够排除外界多种干扰因素，在对开发过程中的人员质量风险等方面进行合理的安排和控制，然而涉及项目管理过程中影响因素包括：产品的工作量、应用资源、配置等多方面，同时，相比其他的管理来说，软件项目管理同样需要进行多方的配合和项目管理。近年来，随着网络技术的发展，在很多领域都运用了计算机，因此，从软件开发上来看占据越来越大的比重。由于软件开发所涉及的流程比较复杂，需要多个岗位进行配合，而且软件开发是一个复杂的大型项目，面临的风险较大，因此在后期管理过程中难度也较高，在开发过程中还很容易遇到很多问题，不同的方案管理者无法完全避免问题的产生，因此需要制定有效的措施来解决在软件开发时遇到的多种问题。
1.6软件工程的目标
软件工程的目标是在一定的成本和时间要求之下，付出较低的开发成本；达到所需的软件功能；取得较好的软件性能；开发的软件易于移植；需要较低的维护费用；能按时完成开发工作，及时交付使用。
在软件设计中，通常要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征。合适的设计方法有助于这些特征的实现，以达到软件工程的目标。
第二章 需求分析
2.1应用和用户需求分析
2.1.1应用环境分析
本次数据库主要应用于学生基本信息管理系统的需求。学生基本信息的管理包括学生的基本信息，学生的学校信息，学员信息，专业信息，住宿信息等等。从一个学生基本信息当中可以分解出许多的基本的实体。
学校可能有多个校区，每个校区都会有宿舍楼，当然我们设定所有校区的宿舍楼都是标准化的，意思就是所有校区的宿舍楼的楼栋号都是统一编号的。
专业信息只需要记录学生的专业，一个学生可能会修读两门或者两门以上的专业，但是我们只记录学生的主修专业。一个专业只属于一个学院。
从以上的基本信息当中可以看到，主要分解为学生信息管理，后勤信息管理，专业信息管理。
2.1.2应用特征
本次数据库应用主要是针对于高校的学生信息管理，一般来说主要场景包含的用户有学生、教务处、辅导员以及后勤管理人员。
系统存储的内容在一年之内变化的内容较少，可能只有极少的学生需要进行信息的调整。但是在年纪更换时刻可能需要大范围的信息调整，所以需要设计满足批量操作。其次，系统的信息录入主要是在学生入学进行各项事务办理的情况下，在之后的学年里面，可能会定期开放权限让学生们维护自己的信息。其余还有一些更换校区，调整专业等需求。在大部分情况之下，服务的是不同用户查询的需求。综上所述，系统需要具有增删查改等基本的操作，之后可能会设计一些复杂的操作。
2.1.3用户需求
用户主要有：学生，后勤管理人员，教务处管理人员，学院教务处管理人员。
学生需求：可以查看自己的信息，然后再有权限的情况下可以修改的自己的信息。
后勤管理人员的需求：后勤管理人员主要管理整个学校的宿舍信息，比如组团编号，房间命名，为新入学的学生分配房间。通信也可以利用宿舍编号等信息快速的查找学生的信息。
教务处管理人员：负责所有学院的信息的管理，以及整个学校不同校区之间的人员管理调配。同时可以快速的修改，查询学生的信息。
学院教务处管理人员：负责学院内信息管理，学院学生专业的划分，同时可以快速查询、修改学生们的信息。
2.2功能性分析
功能性分析主要是对于学生基本信息数据库建立的系统设计分析，对学生可能发生数据流向的操作分析。根据本次的学生基本信息管理系统的需求，学生会有转专业的需求而更换学院，学生也有可能因为升级更换校区，学生也有可能因为升级更换宿舍，学生也有可能因为别的因素留级或者退学等等。
2.2.1学生转专业
图2-1 学生转专业数据流向
学生可能会因为转专业而更换所属的学院，但是学生的主键学号不会发生变化。
2.2.2学生因升级更换校区
图2-2 学生因升级更换校区和宿舍
学生分布在所属学院所在的校区，并且可能会根据情况进行调整。例如某学
年计算机学院在校区1，第二年可能调整到校区3。同时学生也会更换宿舍，办理新的宿舍入住手续，学生的宿舍所属的建筑类别也会发现变化。
2.2.3学生因退学信息变化
图2-3 学生因退学信息发生变化
学生因为退学或者其他因素退学，入学时候的信息登记将会被移除。
2.3数据需求的具体的描述
2.3.1主要数据结构的描述
针对于需求分析，我们要分析数据结构对应于需求的实体。
（1）学生
| 数据结构: | 学生 | ||
| 含义说明: | 是学生基本信息管理系统的主体数据结构，定义了一个学生的有关信息 | ||
| 组成: | 学号、姓名、性别、出生日期、民族、身份证号、政治面貌以及手机号码，可能联系之后还会有宿舍编号，专业编号，学院编号等 |
（2）专业
| 数据结构: | 专业 | ||
| 含义说明: | 是学生基本信息管理系统的基本数据结构，定义一个学生与学院之间的关系 | ||
| 组成: | 专业代码，专业名称，专业所属学院 |
（3）学院
| 数据结构: | 学院 | ||
| 含义说明: | 是学生基本信息管理系统的基本数据结构，定义学院的详细信息 | ||
| 组成: | 学院编号，学院名称，院长姓名，学院电话，学院所属校区，学院 |
（4）宿舍
| 数据结构: | 宿舍 | ||
| 含义说明: | 是学生基本信息管理系统的基本数据结构，定义一个学生的住宿详细信息 | ||
| 组成: | 宿舍编号，宿舍房间号，宿舍楼层，宿舍所属楼栋号 |
（5）楼栋建筑
| 数据结构: | 楼栋建筑 | ||
| 含义说明: | 是学生基本信息管理系统的基本数据结构，定义宿舍楼的相详细信息 | ||
| 组成: | 楼栋编号，所属组团号，楼栋类别，楼栋所属校区 |
（6）校区
| 数据结构: | 校区 | ||
| 含义说明: | 是学生基本信息管理系统的基本数据结构，定义校区的信息 | ||
| 组成: | 校区编号，校区名称，校区地址 |
2.3.2部分主要数据项的描述
数据项主要对应于实体的属性，下面列出了学生实体以及宿舍实体的主要数据项的描述。
（1）学号
| 数据项名: | 学号 | ||
| 含义说明: | 唯一标识每一个学生 | ||
| 别名: | 学生编号，学生ID | ||
| 类型: | 字符类型 | ||
| 长度: | 最大长度为20 | ||
| 取值范围: | 最大为20位全为9 | ||
| 取值含义: | 前四位标识学生入学年份，后面几位分别描述学生的学院，班级，班级编号等信息 |
（2）宿舍编号
| 数据项名: | 宿舍编号 | ||
| 含义说明: | 在一个学校内，唯一标识一间宿舍 | ||
| 别名: | 宿舍ID | ||
| 类型: | 字符类型 | ||
| 长度: | 4 | ||
| 取值范围: | 0000-9999 | ||
| 取值含义: | 前两位标识楼栋号，后面三位标识门牌号 |
（3）性别
| 数据项名: | 性别 | ||
| 含义说明: | 标识学生性别 | ||
| 别名: | 无 | ||
| 类型: | 字符类型 | ||
| 长度: | 4 | ||
| 取值范围: | 男或者女 |
其余数据项的分析，也是如此。由于所有的数据项众多，在此就不再一一列出描述。
2.3.3部分处理过程描述
设计学生基本信息管理数据库的话，需要确定一般基本的处理过程。一般的处理过程一般有，学生入学信息导入，分配专业，分配宿舍，转校等操作。下面对部分的处理过程进行描述，其他的处理过程进行类似的处理。
（1）入学信息导入
| 处理过程: | 入学信息导入 | ||
| 说明: | 学生信息录入 | ||
| 输入: | 学生各种基本信息 | ||
| 输出: | 学生基本信息已录入 | ||
| 处理: | 新生报到之前，自行先填入学生基本信息 |
（2）分配宿舍
| 处理过程: | 分配宿舍 | ||
| 说明: | 为入学学生分配宿舍 | ||
| 输入: | 学生，宿舍编号 | ||
| 输出: | 宿舍已安排 | ||
| 处理: | 新生在报道以后，为学生安排宿舍房间，宿舍对应编号插入到学生信息表格中 |
2.4可行性分析
经济可行性：本次数据库在个人电脑上就可以完整全部的操作，个人本地磁盘最够庞大的话，就可以满足大量数据存储的需要。
技术可行性：系统的设计根据以上的分析需要增删查改功能，功能并不复杂，当前的技术条件就可以很好地满足需要。
用户可行性：本次数据库系统的设计能够直观地表示信息，满足不同用户的不同的需求。
第三章 系统设计
3.1根据需求分析确定实体、属性和实体间的联系
3.1.1确定实体及其属性
经过上述分析，可以得到在本次数据库设计中需要的实体有：学生，校区，建筑，专业，校区，寝室，年级。
学生：包含的属性有学号、姓名、性别、出生日期、民族、身份证号、政治面貌以及手机号码等等。其中学号和身份证号极其组合都可以作为学生信息表的主键，但是由于身份证号一般过长，我们选择学号作为主键/主码。
专业：包含的属性有专业代码，专业名称。专业代码可以作为主键。
校区：包含的属性有校区编号，校区名称以及校区地址。校区编号可以作为主键。
宿舍：包含的属性有宿舍房间号，宿舍所属楼栋，宿舍楼层。
建筑：包含的属性有建筑的类别，建筑楼栋号，建筑所属校区。
年级：包含的属性可能就是年级编号。
下图是实体及其属性的展现图。
图3-1 实体集的属性
3.1.2实体之间的联系
学生与专业之间属于隶属关系，而且学生与专业之间的对应关系是m:1。
专业与学院之间属于隶属关系，而且专业与学院之间的对应关系是m:1。
学生与宿舍之间属于隶属关系，而且学生与宿舍之间的对应关系是m:1。
学生与年级之间属于隶属关系，而且学生与年级之间的对应关系是m:1。
宿舍与楼栋建筑之间属于隶属关系，而且宿舍与楼栋建筑之间的对应关系是m:1。
楼栋建筑与校区之间属于隶属关系，而且楼栋建筑与校区之间的对应关系是m:1。
他们之间的联系可以概括为下图：（下面没有包含实体的属性，在设计E-R图时会标出）
图3-2 实体关联图
实体之间的大致联系如上图所示。
但是会存在一定的问题。
（1）问题1及解决方案
问题：从学生到校区有两条关系链，即“学生>宿舍>建筑楼栋>校区”，“学生>年级&学院>校区”。
解决办法保留一条关系链。
将其中一条关系链剔除得到如下的简易的实体之间的关系图。
图3-3 改进后的实体之间的关系图
（2）问题2及解决方案
问题：以上实体之间关系图，不满足其中一个功能要求学生分布在所属学院所在的校区，并且可能会根据情况进行调整。例如某学年计算机学院在校区1，第二年可能调整到校区3。）
分析：考虑到学院里面是不同年级学生可能会因为年级在不同校区上课，但是我们考虑到学生必然会进行住宿，而不同的宿舍楼又是位于不同校区的，这就可以满足学生分布在所属学院所在的校区，并且可能会根据情况进行调整这种情况。
相关解决方案：当因为年级需要更换校区的时候，只需要修改后勤管理的住宿信息，就可以反映校区的变化。
综合以上情况，年级可以作为学生的一个属性进行处理。得到最终的实体关系联系图。
图3-4 最终的实体之间的联系图
3.2E-R模型的设计
3.2.1设计局部E-R模型
根据第二章中的应用环境分析，学生基本信息管理系统可以分为三个部分，
学生学籍信息管理系统，学生宿舍住宿管理系统，后勤宿舍楼管理系统。
下面是三个系统的局部E-R图的设计。
（1）学生学籍信息管理模型
图3-5 学生学籍基本信息关系模型
（2）学生宿舍住宿管理模型
图3-6 学生宿舍住宿管理信息关系模型
（3）后勤宿舍楼管理模型
图3-7 后勤宿舍楼管理信息关系模型
3.2.2根据局部E-R图确定总体E-R图
将以上局部E-R模型进行修改得到总体的E-R图。
|
|
图3-8 总体E-R图
3.2.3优化确定最终E-R模型
由于初步得到的E-R模型里面，不存在冗余的传递链和冗余的属性信息，图3-8中的总体E-R图就是最终的E-R图模型。
3.3 E-R模型向关系模式转换
3.3.1转换的规则
（1）实体的转换：每个实体都转换为一个关系模式。
=实体的名称→关系的名称
=实体的属性→关系的属性
=实体的主属性→关系的键
（2）联系的转换：每个联系转换成一个关系模式
①1:1、1:N和子类的联系不需要增加单独的关系模式；
②M:N的联系需要增加单独的关系模式。
当不增加单独的关系模式时，联系的转换需要对与联系相关的实体的关系模式作适当的修改——通常需要增加键属性。
3.3.2学生学籍信息E-R图转关系模式
学生与专业之间是多对1的关系，把“1”端实体的主属性作为“N”端实体对应的关系中的外键属性。将专业的主键-专业代码组为学生实体的对应关系中的外键属性。
对于专业和学院多对一之间的E-R图转换为关系模式，将学院的主键-学员编号组为专业实体的对应关系中的外键属性。
综上，将学生学籍信息E-R图转换如下的关系模式。
| 学生学籍信息的关系模式 |
| 学生（学号，姓名，性别，年级，年龄，民族，出生日期，政治面貌，身份证号，电话号码，专业代码（FK）） 专业（专业代码，专业名称，学院编号(FK)） 学院（学院编号，学院名称，学院院长姓名，学院电话） |
3.3.3学生住宿信息E-R图转关系模式
学生实体与宿舍实体之间是多对一的关系，将宿舍实体的主键-宿舍编号作为学生实体的外键属性。
将学生住宿信息E-R图转换如下的关系模式。
| 学生住宿信息的关系模式 |
| 学生（学号，姓名，性别，年龄，民族，出生日期，政治面貌，身份证号，电话号码，宿舍编号（FK）） 宿舍（宿舍编号，宿舍房间号，宿舍楼层，楼栋编号） |
3.3.4后勤宿舍楼管理E-R图转关系模式
楼栋建筑实体与校区实体之间多对一的关系，将校区实体的主键-校区编号作为楼栋建筑的外键属性。
将后勤宿舍楼管理E-R图转换如下的关系模式。
| 后勤宿舍楼管理的关系模式 |
| 楼栋建筑（楼栋编号，组团号，建筑类别，校区编号(FK)） 校区（校区编号，校区名称，校区地址） |
3.3.6总体E-R图转换为关系模式
将上述部分E-R图转换的关系模式进行综合，得到总体的关系模式。
| 总体关系模式 |
| 学生（学号，姓名，性别，年龄，民族，出生日期，政治面貌，身份证号，电话号码，专业代码（FK），宿舍编号（FK）） 专业（专业代码，专业名称，学院编号（FK）） 学院（学院编号，学院名称，学院院长姓名，学院电话） 宿舍（宿舍编号，宿舍房间号，宿舍楼层，楼栋编号（FK）） 楼栋建筑（楼栋编号，组团号，建筑类别，校区编号（FK）） 校区（校区编号，校区名称，校区地址） |
3.4数据库基本表的设计
根据前面的数据字典和关系模式，现在给出数据库各个基本表的设计。
| STUDENT（学生基本信息表） | ||||
| 属性 | 属性含义 | 数据类型 | 数据长度（字节） | 备注 |
| STUID | 学号 | VARCHAR2 | 20 | 主键 |
| STUNAME | 姓名 | VARCHAR2 | 10 | - |
| GENDER | 性别 | VARCHAR2 | 2 | - |
| AGE | 年龄 | VARCHAR2 | 2 | - |
| GRADE | 年级 | VARCHAR2 | 2 | - |
| NATION | 民族 | DATE | - | - |
| BIRTHDAY | 出生日期 | VARCHAR2 | 2 | - |
| POLITICAL | 政治面貌 | VARCHAR2 | 150 | - |
| IDNUMBER | 身份证号 | VARCHAR2 | 30 | - |
| TELNUMBER | 电话号码 | VARCHAR2 | 30 | - |
| PROFESSIONALID | 专业编号 | VARCHAR2 | 2 | 外键 |
| COLLEGEID | 学院编号 | VARCHAR2 | 2 | 外键 |
| DORMID | 宿舍编号 | VARCHAR2 | 5 | 外键 |
| DORM（宿舍基本信息表） | ||||
| 属性 | 属性含义 | 数据类型 | 数据长度（字节） | 备注 |
| DORMID | 宿舍编号 | VARCHAR2 | 5 | 主键 |
| DORMNAME | 房间号 | VARCHAR2 | 5 | - |
| DORMHEIGTHID | 楼层 | VARCHAR2 | 10 | - |
| DORMBUILDINGID | 宿舍所属楼栋号 | VARCHAR2 | 2 | 外键 |
| DORMBUILDING（宿舍基本信息表） | ||||
| 属性 | 属性含义 | 数据类型 | 数据长度（字节） | 备注 |
| DORMBUILDINGID | 楼栋号 | VARCHAR2 | 5 | 主键 |
| ZUTUNID | 组团名 | VARCHAR2 | 30 | - |
| DORMBUILDING NAME | 楼栋类别 | VARCHAR2 | 30 | - |
| DORMBUILDNLO CALCAMPUS | 楼栋所属校区 | VARCHAR2 | 2 | 外键 |
| DORMBUILDING（楼栋建筑基本信息表） | ||||
| 属性 | 属性含义 | 数据类型 | 数据长度（字节） | 备注 |
| DORMBUILDINGID | 楼栋号 | VARCHAR2 | 5 | 主键 |
| ZUTUNID | 组团名 | VARCHAR2 | 30 | - |
| DORMBUILDING NAME | 楼栋类别 | VARCHAR2 | 30 | - |
| DORMBUILDNLO CALCAMPUS | 楼栋所属校区 | VARCHAR2 | 2 | 外键 |
| PROFESSIONAL（专业基本信息表） | ||||
| 属性 | 属性含义 | 数据类型 | 数据长度（字节） | 备注 |
| PROFESSIONALID | 专业代码 | VARCHAR2 | 2 | 主键 |
| PROFESSIONAL LOCALCOLLEGEID | 专业隶属学院 | VARCHAR2 | 2 | - |
| PROFESSIONA LNAME | 专业名称 | VARCHAR2 | 200 | 外键 |
| COLLEGE（学院基本信息表） | ||||
| 属性 | 属性含义 | 数据类型 | 数据长度（字节） | 备注 |
| COLLEGEID | 学院编号 | VARCHAR2 | 2 | 主键 |
| COLLEGENAME | 学院名称 | VARCHAR2 | 20 | - |
| COLLEGE PRESIDENT | 院长 | VARCHAR2 | 5 | - |
| COLLEGE PRESIDENT TELNUMBER | 学院电话 | VARCHAR2 | 20 | - |
| COLLEGELOCAL CAMPUSID | 学院所处学校ID | VARCHAR2 | 2 | 外键 |
| CAMPUS（校区基本信息表） | ||||
| 属性 | 属性含义 | 数据类型 | 数据长度（字节） | 备注 |
| CAMPUSUD | 校区编号 | VARCHAR2 | 2 | 主键 |
| CAMPUSNAME | 校区名称 | VARCHAR2 | 10 | - |
| ADDRESS | 地址 | VARCHAR2 | 10 | - |
第四章 代码与实现
4.1创建各种基本表代码实现
| 创建基本表的代码 |
| CREATE TABLE CAMPUS ( CAMPUSID VARCHAR2(2) NOT NULL , --校区ID，校区类型和长度约束，不能为空 CAMPUSNAME VARCHAR2(10 BYTE) NOT NULL , --校区名字，字符类型最长为10字节，不能为空 ADDRESS VARCHAR2(100 BYTE) NULL, --校区地址，字符类型最长为100字节，可以为空 CONSTRAINT CAMPUS_PK PRIMARY KEY(CAMPUSID) --设定校区基本表的主键为校区ID ); ALTER TABLE CAMPUS ADD CONSTRAINT CK_CAMPUS_CAMPUSID CHECK(CAMPUSID = '1' OR CAMPUSID = '2'); --更改约束条件为校区的ID只能为1或2，根据实际情况电子科技大学有清水河和沙河两个校区而——定。 ALTER TABLE CAMPUS ADD CONSTRAINT CK_CAMPUS_CAMPUSNAME CHECK(CAMPUSNAME = '清水河校区' OR CAMPUSNAME = '沙河校区'); --约束校区的名字只能为清水——河或者沙河校区
CREATE TABLE COLLEGE ( --创建学院基本表 COLLEGEID VARCHAR2(2) NOT NULL , --学院ID，校区类型和长度约束，不能为空 COLLEGENAME VARCHAR2(20 BYTE) NOT NULL , --学院名称，校区类型和长度约束，不能为空 COLLEGEPRESIDENT VARCHAR2(10 BYTE) NULL , --院长，字符，最长10字节，可为空 COLLEGEPRESIDENTTELNUMBER VARCHAR2(20) NULL ,--学院电话，可为空 --COLLEGELOCALCAMPUSID VARCHAR2(2) NOT NULL ,--学院所处校区ID，不能为空 CONSTRAINT COLLEGE_PK PRIMARY KEY(COLLEGEID)--设置学院ID为学院基本表的主键 --CONSTRAINT COLLEGE_FK FOREIGN KEY(COLLEGELOCALCAMPUSID) REFERENCES CAMPUS(CAMPUSID) --设置校区基本表的校区ID为学院基本表的外键 );
CREATE TABLE DORMBUILDING( --创建楼栋建筑基本表 DORMBUILDINGID VARCHAR2(5) NOT NULL , --楼栋号，变长字符类型，不超过5字节，不为空 ZUTUANID VARCHAR2(30) NULL,--组团号，变长字符类型，不超过30字节，可为空 DORMBUILDINGNAME VARCHAR2(30 BYTE) NOT NULL ,--楼栋类别，变长字符类型，不超过30字节，不可为空 CAMPUSID VARCHAR2(2) NOT NULL , CONSTRAINT DORMBUILDING_PK PRIMARY KEY(DORMBUILDINGID), CONSTRAINT DORMBUILDING_FK FOREIGN KEY(CAMPUSID) REFERENCES CAMPUS(CAMPUSID) ); ALTER TABLE DORMBUILDING ADD CONSTRAINT CK_DORMBUILDING_CAMPUSID CHECK(CAMPUSID = '1' OR CAMPUSID = '2');
CREATE TABLE DORM ( --创建宿舍基本表 DORMID VARCHAR2(5) NOT NULL ,--宿舍编号，变长字符类型，不超过5字节，不可为空 DORMNAME VARCHAR2(5 BYTE) NOT NULL ,--房间号，变长字符类型，不超过5字节，不可为——空 DORMHEIGTHID VARCHAR2(10) NOT NULL , --宿舍楼层，不可为空 DORMBUILDINGID VARCHAR2(5) NOT NULL ,--宿舍所属楼栋号，不能为空 CONSTRAINT DORM_PK PRIMARY KEY(DORMID),--设置宿舍编号为宿舍基本表的主键 CONSTRAINT DORM_FK FOREIGN KEY(DORMBUILDINGID) REFERENCES DORMBUILDING(DORMBUILDINGID)--设置建筑楼栋的主键为宿舍基本表的外键 );
CREATE TABLE PROFESSIONAL ( --创建专业基本表 PROFESSIONALID VARCHAR2(4) NOT NULL , --专业代码，不可为空 PROFESSIONALLOCALCOLLEGEID VARCHAR2(2) NOT NULL ,--专业隶属学院，不可为空 PROFESSIONALNAME VARCHAR2(100) NOT NULL ,--专业名称，不可为空 CONSTRAINT PROFESSIONAL_PK PRIMARY KEY(PROFESSIONALID),--设置专业代码为主键 CONSTRAINT PROFESSIONAL_FK FOREIGN KEY(PROFESSIONALLOCALCOLLEGEID) REFERENCES COLLEGE(COLLEGEID)--设置学院基本表中的主键为专业基本表的外键 );
CREATE TABLE STUDENT --创建学生基本表 ( STUID VARCHAR2(20) NOT NULL, --学号，不可为空 STUNAME VARCHAR2(10) NOT NULL,--学生姓名，不可为空 GENDER VARCHAR2(2) NOT NULL,--性别：男或者女 AGE NUMBER(2) NOT NULL,--年龄：0~100 GRADE VARCHAR2(4) NOT NULL,--年级：大一~博五 NATION VARCHAR2(2) NOT NULL, --民族，不可为空 BIRTHDAY DATE,--出生日期，DATE类型 POLITICAL VARCHAR2(10),--政治面貌 IDNUMBER VARCHAR2(30) NOT NULL,--身份证号 TELNUMBER VARCHAR2(30) NOT NULL,--电话号码 PROFESSIONALID VARCHAR2(4) NOT NULL,--专业代码 --COLLEGEID VARCHAR2(2) NOT NULL,--学院编号 DORMID VARCHAR2(5) NOT NULL,--宿舍编号 CONSTRAINT STUDENT_PK PRIMARY KEY(STUID),--设置学号为学生基本表的主键 CONSTRAINT STUDENT_FK1 FOREIGN KEY(PROFESSIONALID) REFERENCES PROFESSIONAL(PROFESSIONALID),--设置专业基本表的主键为学生基本表的外键 --CONSTRAINT STUDENT_FK2 FOREIGN KEY(COLLEGEID) REFERENCES COLLEGE10(COLLEGEID),--设置 CONSTRAINT STUDENT_FK2 FOREIGN KEY(DORMID) REFERENCES DORM(DORMID)--设置宿舍基本表的主键为学生基本表的外键 ); ALTER TABLE STUDENT ADD CONSTRAINT CK_STUDENT_GENDER CHECK(GENDER = '男' OR GENDER= '女'); --更改约束条件，取值范围为男或者女 ALTER TABLE STUDENT ADD CONSTRAINT CK_STUDENT_AGE CHECK(AGE >=0 AND AGE<=100); |
4.2插入数据
| 插入数据的代码 |
| INSERT INTO CAMPUS VALUES ('1', '清水河校区', '四川省成都市郫都区西源大道合作街道2006号'); INSERT INTO CAMPUS VALUES ('2', '沙河校区', '四川省成都市成华区建设北路二段4号'); INSERT INTO COLLEGE VALUES ('01', '信息与通信工程学院','孔院长','01347265283'); INSERT INTO PROFESSIONAL VALUES ('0****3', '01','**工程'); INSERT INTO DORMBUILDING VALUES ('2*', '**团','学知苑','1'); INSERT INTO DORM VALUES ('27633', '6**','*楼','27'); INSERT INTO STUDENT VALUES ('20200888', '**', '*',20,'大三','汉',TO_DATE('2002-**-**','*******dd'),'共青团员','****','***','0103','27**'); |
4.3创建视图
| 学生宿舍管理视图 |
| ---创建视图，学生宿舍管理视图 CREATE VIEW STU_DORM AS SELECT E1.STUID AS 学号,E1.STUNAME AS 姓名,E1.TELNUMBER AS 联系方式,E2.DORMNAME AS 宿舍房间,E3.DORMBUILDINGID AS 楼栋号,E3.ZUTUANID AS 组团,E4.CAMPUSNAME AS 所在校区 FROM STUDENT E1, DORM E2,DORMBUILDING E3,CAMPUS E4 WHERE E1.DORMID=E2.DORMID AND E2.DORMBUILDINGID=E3.DORMBUILDINGID AND E3.CAMPUSID=E4.CAMPUSID; |
| 教务处管理视图 |
| ---创建视图，教务处可以显示的学生的视图 CREATE VIEW STU_INFO AS SELECT E1.STUID AS 学号,E1.STUNAME AS 姓名,E1.TELNUMBER AS 联系方式,E1.GRADE AS 年级,E2.PROFESSIONALNAME AS 专业名称,E3.COLLEGENAME AS 所属学院,E6.CAMPUSNAME AS 所在校区 FROM STUDENT E1, PROFESSIONAL E2,COLLEGE E3,DORM E4,DORMBUILDING E5,CAMPUS E6 WHERE E1.PROFESSIONALID=E2.PROFESSIONALID AND E2.PROFESSIONALLOCALCOLLEGEID=E3.COLLEGEID AND E1.DORMID=E4.DORMID AND E4.DORMBUILDINGID=E5.DORMBUILDINGID AND E5.CAMPUSID=E6.CAMPUSID; |
第五章 测试
注明：本章节没有结果截图，可以根据图题信息自己截取，因为信息涉及个人隐私就没有放出来
5.1基本表创建结果和数据
5.1.1基本表创建结果
（1）校区基本表
| 图5-1 校区基本表 |
（2）学院基本表
|
图5-2 学院基本表 |
（3）专业基本表
| 图5-3 专业基本表 |
（4）宿舍基本表
| 图5-4 宿舍基本表 |
（5）楼栋建筑基本表
| 图5-5 楼栋建筑基本表 |
（6）学生基本表
| 图5-6 学生基本表 |
5.1.2基本表存储信息的生成
| 图5-7 学生基本表存储的数据 |
| 图5-8 专业基本表存储的数据 |
| 图5-9 学院基本表存储的数据 |
| 图5-10 宿舍基本表存储的数据 |
| 图5-11 楼栋建筑基本表存储的数据 |
| 图5-12 校区基本表存储的数据 |
5.2视图的创建和测试
（1）学生住宿管理信息视图
| 图5-13 学生住宿管理信息视图创建成功截图 |
| 图5-14学生住宿管理信息视图 |
（2）学生学籍信息视图
| 图5-15 | ||
| 图5-16 学生学籍信息视图 |
5.3建立表的关系模型图
|
|
5.4应用便利性测试
5.4.1查询便利性测试
| 应用场景1：学院教务处管理人员查询某一个专业所有的学生 |
| SELECT E1.* FROM STUDENT E1,PROFESSIONAL E2 WHERE E1.PROFESSIONALID=E2.PROFESSIONALID AND E2.PROFESSIONALNAME='**工程'; |
结果如下：
| 图5-18查询结果截图 |
| 应用场景二：后勤管理人员查询学生信息（查询视图） |
| SELECT * FROM STU_DORM WHERE "姓名"='**' |
结果：
| 图5-19 查询结果截图 |
5.4.2修改便利性测试
| 场景一：学生因为转学院信息变更 |
| INSERT INTO COLLEGE VALUES('02','电子工程学院','***','246***838'); INSERT INTO PROFESSIONAL VALUES('0201','02','电子信息与集成电路专业'); UPDATE STUDENT SET PROFESSIONALID='0201'; SELECT * FROM STU_INFO WHERE "学号"='**'; |
结果：
| 图5-20 修改信息后查询视图截图 |
5.5测试结果分析以及结论
本数据库查询和修改以及删除信息都十分的高效和便利。从测试的结果来看，本数据库可以方便的创建视图，以及修改基本表的数据，满足了后勤管理人员，教务管理人员，辅导员，学生等多用户的需求。
5.6相关错误记录和解决方案
（1）删除表的时候表中有属性充当了外键报错
|
|
图5-21相应解决方案：删除表的时候，要注意删除的顺序，删除的表的属性不会被其他表充当外键或者有其他联系，当然可以采用级联删除。
（2）插入数据时顺序不对报错
|
图5-22 插入数据时错误截图 |
相应解决方案：插入数据的时候，要注意插入的顺序，需要外键的需要最后再进行插入。
第六章 总结
6.1思考题
1、请举例说明本次设计中的数据库表如何来满足数据库三大范式。
第一范式要求：基本表的属性不可再分。很显然以上基本表里面的属性都是不可以再分的。
第二范式要求非主属性完全函数依赖于主属性。由于本数据库里面的候选码是单属性，每一张基本表的逐渐都是单属性，所以根据推论（关系模式符合1NF，并且候选码都是单属性，则一定是第二范式），以上设计满足第二范式。
第三范式是满足第二范式，消除了非主属性对码的传递函数依赖关系。
分析每一张表：
学生基本表，主属性只有学号和身份证号，但是二者互相决定，其余的非主属性都不能相互决定，在表中不存在任何的函数传递依赖。
专业基本表，主属性只有专业代码，非主属性之间又不能相互决定，所以也不存在函数传递依赖。
后面的学院基本表，宿舍基本表也都不存在函数传递依赖。
楼栋建筑和校区基本表也不存在函数传递依赖。
校区基本表：校区编号和校区名称以及校区地址都是可以互相决定的，都是一对一的关系，虽说有校区编号"校区名称"校区地址，但是校区名称"校区编号，所以不存在函数传递依赖，楼栋建筑基本表的分析也是如此。
综上，数据库表的设计满足数据库三大范式。
2、用一张视图来展示学生的基本信息、所在学院、所住寝室、所在校区的情况。请写出创建视图的代码，以及查询该视图信息的 SELECT 命令和结果截图。
| 创建视图的代码： |
| CREATE VIEW SRU2_DORM_INFO AS SELECT E1.*,E3.COLLEGENAME,E4.DORMNAME,E5.ZUTUANID,E6.CAMPUSNAME FROM STUDENT E1,PROFESSIONAL E2,COLLEGE E3,DORM E4,DORMBUILDING E5,CAMPUS E6 WHERE E1.PROFESSIONALID=E2.PROFESSIONALID AND E2.PROFESSIONALLOCALCOLLEGEID=E3.COLLEGEID AND E1.DORMID=E4.DORMID AND E4.DORMBUILDINGID=E5.DORMBUILDINGID AND E5.CAMPUSID=E6.CAMPUSID; |
| SELECT查询代码： |
| SELECT * FROM SRU2_DORM_INFO WHERE STUID='2020******' |
6.2总结与心得体会
在本次实验过程中，通过对学生基本信息数据库进行设计，从基本的需求分析做起，采用自上而下的设计思路，锻炼了自己的管理和分层次设计的能力。
其次，对E-R模型有了更加深入的了解，对于一个复杂的关系模式的设计，可以分解成许多局部的实体或者实体之间的关联，然后画出局部的E-R图，转换成关系模式之后，然后在设计出总的关系模式。
在整个数据库的设计过程当中，运用软件工程的思想进行设计，使得自己节省了很多的时间。
腾讯云面向开发者汇聚海量精品云计算使用和开发经验，营造开放的云计算技术生态圈。
更多推荐
16
0- 0
已为社区贡献1条内容
所有评论(0)