学生宿舍管理系统数据库设计案例

1、同学宿舍治理系统数据库设计案例企业工资治理系统设计目 录1. 系统需求分析阶段 . 错误 .未指定书签；1.1 系统目标设计 . 错误 .未指定书签；1.2 系统功能分析 . 错误 .未指定书签；1.3 功能模块分析 . 错误 .未指定书签；1.4 系统全局数据流图 . 错误 .未指定书签；1.5 数据字典 . 错误 .未指定书签；2. 概念设计阶段 . 错误 .未指定书签；2.1 概念模型设计 . 错误 .未指定书签；2.2 新系统流程 . 错误 .未指定书签；3规律设计阶段 . 错误 .未指定书签；3.1 规律设计的任务和目标 . 错误 .未指定书签；3.2 数据组织 . 错误 .未指定书

2、签；3.2.1 将图转换为关系模型 . 错误 .未指定书签；3.2.2 模型优化 . 错误 .未指定书签；3.2.3 数据库模式定义 . 错误 .未指定书签；3.2.4 用户子模式设计 . 错误 .未指定书签；3.3 数据处理 . 错误 .未指定书签；4物理设计阶段 . 错误 .未指定书签；4.1 物理设计阶段的目标与任务 . 错误 .未指定书签；4.2 数据储备方面 . 错误 .未指定书签；4.3 系统功能模块 . 错误 .未指定书签；4.3.1 员工基本信息治理模块 . 错误 .未指定书签；4.3.2 部门信息治理模块 . 错误 .未指定书签；4.3.3 基本工资治理模块 . 错误 .未指

3、定书签；4.3.4 出勤信息治理模块 . 错误 .未指定书签；4.3.5 奖惩信息治理模块 . 错误 .未指定书签；4.3.6 津贴治理模块 . 错误 .未指定书签；4.3.7 职称信息治理模块 . 错误 .未指定书签；4.3.8 员工工资治理模块 . 错误 .未指定书签；5数据库实施阶段 . 错误 .未指定书签；5.1 建立数据库、数据表、视图、索引 . 错误 .未指定书签；5.1.1 建立数据库 . 错误 .未指定书签；/ 46 同学宿舍治理系统数据库设计案例5.1.2 建立数据表 . 错误 .未指定书签；5.1.3 建立视图 . 错误 .未指定书签；5.1.4 建立索引 . 错误 .未指

4、定书签；5.2 数据入库 . 错误 .未指定书签；5.3 创建各个功能的储备过程 . 错误 .未指定书签；6系统调试和测试 . 错误 .未指定书签；附录 1 数据库规律结构定义 . 错误 .未指定书签；附录 2 储备过程定义 . 错误 .未指定书签；附录 3 全部的运行语句 . 错误 .未指定书签；I / 46 同学宿舍治理系统数据库设计案例1. 系统需求分析阶段1.1 引言通过对同学宿舍楼的实地调查,明白到现在的同学宿舍治理仍停留在完全的人工治理阶段,楼管处没有标准的住宿同学存档信息；这中人工治理方式费时、费事、费劲,造成工作效率低下；开发出合适的同学宿舍治理系统,可以便利同学宿舍的治理,提

5、高宿舍管理工作效率及查询效率；1.2 目标与任务1.2.1 需求分析阶段的目标（ 1）明白目前宿舍治理的现状以及 2022 的功能和特点；（ 2）通过实地调查和问答记录的方式明白宿舍治理的工作业务流程,并记录和处理相关的数据；1.2.2 需求分析阶段的任务（ 1）处理对象：系统要处理的对象包括宿舍楼基本信息、同学基本信息、宿舍基本信息、楼道工作人员基本信息、宿舍保卫处基本信息、宿舍事故基本信息、物品出入基本信息等七个方面,各个对象包括信息如下所示（具体的数据见于 数据字典）：1宿舍楼基本信息 ：包括 宿舍楼编号、宿舍楼所在校区、宿舍楼再校区中区域、每一幢宿舍楼楼管处的电话、宿舍楼楼管员信息等方

6、面,这样可以便利治理者对宿舍楼的治理,提高查询效率；2同学基本信息 ：包括同学编号、同学所在学院信息、同学姓名、同学性别、学生来自省份、同学诞生日期、同学入学时间、同学所学专业、所在班级等方面的信息,可以便利学信息的查询和更新；3宿舍基本信息 , ：宿舍基本信息包括四个数据结构（宿舍信息 ,宿舍物品信息 ,宿舍物品损坏信息 , 宿舍损坏物品赔偿信息）,每个数据结构中的数据项见数据字典；4楼道工作人员基本信息 ：包括 工作人员编号、工作人员姓名、工作类型、工资、性别、联系方式、工作时间等数据项,可以便利治理人员对宿舍楼道工人的任用、信息查询及更换；5宿舍保卫处基本信息 ：包括保卫处名称、人员数目

7、、负责人信息、联系电话等四方面的信息；6宿舍事故基本信息 , ：事故信息包括三个数据结构（事故信息、事故处理信息、0 / 46 同学宿舍治理系统数据库设计案例事故赔偿信息）,具体的数据项见数据字典；物品出入基本信息 ：包括出入物品的同学信息、出入的物品信息、出入物品时的负责人信息、出入物品时间,尽量削减宿舍事故的发生,保证同学宿舍财产的安全；（ 2）处理功能要求系统主要完成一下几个功能：1宿舍楼基本信息查询与修改；2同学基本信息查询与更新；3每一幢宿舍楼中宿舍信息的查询与信息更新；4宿舍保卫处基本信息的查询和修改；5宿舍事故基本信息及事故处理信息的查询和修改；6宿舍楼物品出入审批及记录；（ 3

8、）安全性和完整性要求安全性先通过视图机制,不同的用户只能拜访系统授权的视图,这样可供应系统数据肯定程度上的安全性,再通过用户授权机制,欲用户登陆来识别用户级别,依据这个级别 来安排用户权限,达到数据更高层次的安全保密功能；完整性要求用于描述宿舍楼基本信息、同学基本信息、宿舍基本信息、楼道工作人员 基本信息、宿舍保卫处基本信息、宿舍事故基本信息、物品出入基本信息中数据项能否为,以及一些用户自定义完整性（符合实际要求）1.2.3 需求分析阶段成果（ 1）同学宿舍治理系统业务流程图新生入住宿舍业务流程图：,具体完整性要求见于系统的规律设计阶段；1 / 46 同学宿舍治理系统数据库设计案例查询业务流程

9、图（查询宿舍同学信息、楼道工作人员信息、宿舍楼信息等）：毕业生离宿业务流程图：2 / 46 同学宿舍治理系统数据库设计案例楼道工作人员任用业务流程图：宿舍楼物品出入业务流程图：宿舍事故处理业务流程图：3 / 46 同学宿舍治理系统数据库设计案例（ 2）数据流程图顶层数据流程图：第 2 层数据流程图：从同学角度动身第 2 层数据流程图：从治理者角度动身4 / 46 同学宿舍治理系统数据库设计案例第 3 层数据流程图：从新生角度动身第 3 层数据流程图：从毕业生角度动身第 3 层数据流程图：从宿舍楼物品出入动身5 / 46 同学宿舍治理系统数据库设计案例第 3 层数据流程图：从宿舍事故角度出入动身

10、第 3 层数据流程图：从楼道工作人员的任用角度动身第 3 层数据流程图：从治理者和外来访客的角度动身6 / 46 同学宿舍治理系统数据库设计案例（ 3）数据字典（ a）数据项：系统涉及的数据项有 71 项表 1.1 数据项列表数据项编号数据项名数据项含义与其它数据项的关系储备结构别名1 同学编号等于9 学号2 同学所在学院20 学院3 同学姓名10 姓名4 同学性别2 性别5 同学来自省份10 祖籍6 同学诞生时间诞生日期7 同学入学时间20 入学时间8 同学所在专业专业9 同学所在班级编号编号5 10 工作人员编号编号11 工作人员姓名10 姓名12 工作类型8 工作类型13 工作人员工资月

11、工资2 14 工作人员性别性别15 工作人员联系方式12 电话16 工作人员工作时间30 工作时间17 宿舍编号6 舍号18 舍长信息10 舍长19 宿舍同学信息同上10 舍员 1 20 宿舍同学信息同上10 舍员 2 21 宿舍同学信息同上10 舍员 3 7 / 46 同学宿舍治理系统数据库设计案例数据项编号数据项名数据项含义与其它数据项的关系储备结构别名22 宿舍同学信息同上10 舍员 4 23 宿舍同学信息同上10 舍员 5 24 宿舍同学信息同上10 舍员 6 25 宿舍同学所属年级等于4 年级26 宿舍同学所在学院等于20 学院27 宿舍同学所学专业等于20 专业28 同学所在班级编

12、号等于2 班级29 宿舍楼编号等于4 宿舍楼号30 宿舍楼所属校区校区31 宿舍楼在校区位置4 宿舍区位32 宿舍楼管处电话12 电话33 宿舍楼楼管员信息10 楼管员34 保卫处名称等于15 名字35 保卫处人员总数人员数目10 36 保卫处负责人信息负责人37 保卫处电话12 电话38 宿舍物品名称16 宿舍物品39 宿舍物品价格价格40 每一种宿舍的数量16 数量41 损坏物品信息物品名42 损坏的同学信息等于9 同学43 损坏物品宿舍信息等于6 舍号44 损坏物品的数量等于16 数量45 赔偿物品信息物品名46 需赔偿同学信息等于9 同学47 赔偿价格等于10 赔偿价格48 赔偿负责人

13、信息负责人49 赔偿日期等于10 日期50 赔偿物品数量数量51 事故编号编号52 事故类型类型53 事故缺失物品30 物品名54 事故缺失物品数量数量9 55 事故受害同学同学56 事故发生日期等于15 日期57 事故负责人信息负责人58 受害人联系方式12 同学电话59 事故是否属实核查8 / 46 同学宿舍治理系统数据库设计案例数据项编号数据项名数据项含义与其它数据项的关系储备结构别名60 事故调查编号等于4 编号事故调查名称15 调查61 事故调查负责人10 负责人62 63 事故调查结果等于10 结果事故赔偿同学信息同学64 65 事故赔偿物品信息等于30 物品名事故赔偿日期日期66

14、 15 事故赔偿负责单位负责单位67 要求物品出入同学等于10 同学68 69 出入物品信息等于20 物品名出入物品审查人10 负责人70 71 出入物品日期日期72 物品出入序号序号（ b）数据结构：表 1.2 数据结构列表数据结数据结构名数据结构组成构编号含义1 宿舍同学信息, 2 宿舍楼工作人员信息, , , 3 宿舍信息, , 4 宿舍楼信息5 宿舍保卫处信息6 宿舍物品配备信息9 / 46 同学宿舍治理系统数据库设计案例数据结数据结构名数据结构组成构编号含义7 宿舍物品损坏信息, 宿 舍 损 坏 物 品 赔 偿 信8 息, , 9 宿舍事故注册信息, 10 宿舍事故调查信息11 12

15、 事 故 损 失 物 品 赔 偿 信 息宿舍楼物品出入信息（ 4）处理规律描述（判定表或判定树）表 1.3 处理规律列表判定条件宿舍基本信息模块、决策同学基本信息模块、宿舍楼基本信息模块、宿舍楼配备物品基本信息模块、宿舍事故基本信息模块、宿舍 判定用户查询涉及的功能模块 楼物品出入基本信息模块、宿舍楼保卫处基本信息模块、楼道 工人基本信息模块：先确定查询所涉及的功能模块；然后,确 定要查询的内容,确定查询数据流向；最终显示查询结果；判定用户修改要涉及的模块,同 时把相应的修改数据传到相应的 模块之中宿舍基本信息模块、宿舍楼基本信息模块、同学基本信息模块、宿舍楼配备物品基本信息模块、宿舍事故基本

16、信息模块、宿舍 楼物品出入基本信息模块、宿舍楼保卫处基本信息模块、楼道 工人基本信息模块：先确定更新所涉及的功能模块；然后,把 更新信息传送到相应的模块中；最终,进行相应的更新操作；10 / 46 同学宿舍治理系统数据库设计案例2. 概念设计阶段2.1 引言概念设计阶段主要是将需求分析阶段得到的用户需求抽象为信息结构概念模型的过程 ,它是整个数据库设计的关键,包括概念模型设计和新系统流程两个阶段；2.2 概念模型设计（ 1）依据不同的对象,从第3 层数据流程图（中层数据流程图）入手,分别画出分E R图：（ a）从数据流程图图2.4 与图2.5 抽象出的分E R 图：图 3.1 分 E R 图

17、1 图 3.2 分 E R 图 2 图 3.3 分 E R 图 3 （ b）从数据流程图图2.6 与图 2.8 抽象出的分E R 图：图 3.4 分 E R 图 4 （ c）从数据流程图图2.7 抽象出的分E R 图：图 3.5 分 E R 图 5 11 / 46 同学宿舍治理系统数据库设计案例（ 2）各分 E R 图中每个实体的属性如下所示：同学： , ；宿舍： , ；宿舍楼：, ；宿舍物品：, ；楼道工作人员：, , , ；保卫处：, ；各分 E R 图中联系的属性如下所示：物品出入：, ；宿舍物品处理：包含物品损坏和物品赔偿两个数据结构 将在规律设计阶段给出 ；事故：包含宿舍事故注册、宿

18、舍事故调查、事故缺失物品赔偿三个数据结构 具体的 结构将在系统规律设计阶段给出 ；（ 3）合并各分图 ,排除属性冲突、命名冲突、结构冲突等三类冲突,得到初步图,再排除不必要冗余,得到的基本图如下所示：12 / 46 同学宿舍治理系统数据库设计案例2.3 新系统流程 新系统流程图：3规律设计阶段3.1 规律设计的任务和目标 以上的概念设计阶段是独立于任何一种数据模型的,但是规律设计阶段就与选用的产品发生关系了,系统规律设计的任务就是将概念设计阶段设计好的基本图转换为选用产品所支持的数据模型相符合的规律结构；具体内容包括数据组织（将图转换成关系模型、模型优化、数据库模式定义、用户子模式设计）3.2

19、 数据组织3.2.1 将图转换为关系模型、数据处理（画出系统功能模块图）两大任务由于宿舍楼与楼道工人的联系方式是1（一对多） ,可以将其之间的联系与n 端实体楼13 / 46 同学宿舍治理系统数据库设计案例道工人合并,宿舍楼与宿舍之间的联系、宿舍与同学之间的联系方式也是 1,同样也将其 之间的联系与 n 端实体宿舍、同学合并,而宿舍物品与同学、同学与楼道工作人员之间的 联系方式就是（多对多）,这样要把它们之间的联系转化为独立的关系模式,保卫处与同学 之间的联系是 1（一对多） ,但是它们之间的联系事故就包含数据结构,为了便于模型优化,将其联系也转化成独立的关系模式,具体的基本图向关系模型的转化

20、如下：楼道工人： （, , ,）；宿舍楼： （,）；宿舍：（,）；宿舍物品： （,）；同学：（,）；保卫处：, ；物品出入：, , , ；宿舍物品处理包含两个数据结构（宿舍物品损坏信息,宿舍物品损坏赔偿信息）,基于表的 各个属性都是原子项的考虑,现将宿舍物品处理分解为：宿舍物品损坏、宿舍损坏物品赔 偿,具体如下：宿舍物品损坏：（, , ,）；（排除命名冲突）宿舍物品损坏赔偿：（,）；（排除命名冲突）宿舍事故包含三个数据结构（宿舍事故注册信息、宿舍事故调查信息、宿舍事故缺失物 品赔偿信息） ,同样基于表的原子性的考虑也将事故分解为：事故注册、事故调查、事故赔偿,具体如下：事故注册： （,）；事故

21、调查： （,）；事故赔偿： （,）；（注：标有直线下划线的为主属性,标有波浪线下划线的是外键属性,主属性与外键属性一起构成主码）3.2.2 模型优化关系模式, ,不存在非主属性对主属性的部分函数依靠,也不存在传递函数依 赖,已经达到了 3,但是宿舍关系模式（）中存在着一些不应当有的数据冗余,现将模型 优化为：（,）；虽然中仍存在一些数据冗余,但可以提高查询效率；14 / 46 同学宿舍治理系统数据库设计案例3.2.3 数据库模式定义 表 2.1 数据库模式定义表编号规律结构基本表 定义完整性和安全性 T （详见附录1 1）（详见附录1 1）T 2 （详见附录1 2）（详见附录1 2）T 3 （

22、详见附录1 3）（详见附录1 3）T 4 （详见附录1 4）（详见附录1 4）T 5 （详见附录1 5）（详见附录1 5）T 6 （详见附录1 6）（详见附录1 6）T 7 （详见附录1 7）（详见附录1 7）T 8 （详见附录1 8）（详见附录1 8）T 9 （详见附录1 9）（详见附录1 9）T 10 （详见附录1 10 ）（详见附录1 10）T 11 （详见附录1 11）（详见附录1 11）T 12 （详见附录1 12 ）（详见附录1 12）3.2.4用户子模式设计表 2.2 用户子模式设计 列表编号用户子模式 作用 共性：供应数据保密和安全爱护机制V 1 便于查询和修改楼道工人的基本信

23、息V 2 便利宿舍楼的基本信息的查询、更新V 3 以便于宿舍的基本信息的查询和更新V 4 用于宿舍楼配备物品的基本信息的查询V 5 便于查询和更换同学的基本信息V 6 便利同学查询宿舍保卫处的基本信息V 7 以便于物品出入的治理和信息的查询、更换V 8 便于宿舍物品损坏的的登记及处理和信息的查询V 9 查询损坏物品赔偿的基本信息,便于宿舍物品的治理V 10 便利同学事故的注册及保卫人员对事故注册的查询V 11 便于同学查询宿舍事故调查的基本信息V 12 便利宿舍事故赔偿的信息查询和更新3.3 数据处理 系统功能模块图：15 / 46 同学宿舍治理系统数据库设计案例4物理设计阶段4.1 物理设计

24、阶段的目标与任务数据库的物理设计就是为规律数据模型选取一个最合适应用要求的物理结构的过程,在这个阶段中要完成两大任务：（ 1）确定数据库的物理结构,在关系数据库中主要是存取方法和储备结构；（ 2）对物理结构进行评判,评判的重点是时间和空间效率；4.2 数据储备方面为数据库中各基本表建立的索引如下：1. 由于基本表,的主码,常常在查询条件和连接操作的连接条件中显现,且它们的值唯独,考虑在两个属性上建立唯独性索引；2. 的主码, ,常常在查询条件中显现,且它们的组合值唯独,考虑在它们之上建立组合索引；3. 基本表的一属性,常常在查询条件中显现,且常常显现在相等的比较条件中,考虑在其之上建立聚簇索引

25、；4. 基本表、的属性值几乎不会有什么变化,更新率很低,可考虑适当建立索引；5. 基本表, ,的属性值常常发生变化,权衡系统为爱护索引付出的代价,可考虑不建立索引,也可以适当建立索引；4.3 系统功能模块16 / 46 同学宿舍治理系统数据库设计案例4.3.1 楼道工人基本的信息查询和更新模块将实现对楼道工人基本信息的查询和更新（修改、插入、删除）操作,便利于楼道工 人的任用和更换,具体的功能模块图如下：图 4.2 楼道工人基本信息的查询、更新功能模块图4.3.2 注：表示系统给用户的信息,以下与此相同 宿舍楼基本信息的查询和更新模块将完成对宿舍楼基本信息的查询、更新（修改、插入、删除）操作,

26、便于宿舍的集中 治理,具体的功能模块图如下所示：17 / 46 同学宿舍治理系统数据库设计案例图 4.3 宿舍楼基本信息的查询、更新功能模块图4.3.3 宿舍基本信息的查询和更新模块将达到对宿舍基本信息的查询、更新（修改、插入、删除）操作的目的,具体的功能模块图如下所示：图 4.4 宿舍基本信息的查询、更新功能模块图18 / 46 同学宿舍治理系统数据库设计案例4.3.4 同学基本信息的查询和更新模块将完成对同学基本信息的查询和插入、删除、修改等更新操作,具体的功能模块如下所示：图 4.5 宿舍同学基本信息的查询、更新功能模块图4.3.5 宿舍物品的查询和更新模块将实现对宿舍物品基本信息的查询

27、、插入、删除、修改等操作,以便利于宿舍物品的配备,具体的功能模块图如下：19 / 46 同学宿舍治理系统数据库设计案例 图 4.6 宿舍物品基本信息的查询、更新功能模块图 4.3.6 宿舍事故的查询和更新模块 将实现对宿舍事故的插入和更新操作,便利宿舍事故的快速处理,准时明白事故处理 的结果,具体的功能模块图如下：图 4.7 宿舍事故基本信息的查询、更新功能模块图 4.3.7 宿舍物品处理的查询和更新模块 将完成对宿舍物品处理基本信息的查询、插入、删除、修改等操作,便利于宿舍物品 的处理,具体的功能模块图如下所示：图 4.8 宿舍物品处理基本信息的查询、更新功能模块图20 / 46 同学宿舍治

28、理系统数据库设计案例4.3.8 宿舍保卫处基本信息的查询和更新模块将实现对宿舍保卫处基本信息的查询和更新（包括更换、插入、删除）操作,便利于宿舍意外事故的处理,具体的功能模块图如下：图 4.9 宿舍楼保卫处基本信息的查询、更新功能模块图5数据库实施阶段5.1 建立数据库、数据表、视图、索引5.1.1 建立数据库; 5.1.2 建立数据表（ 1）楼道工人基本信息表的建立：（5 ）, , 10 8 , , 2 , 21 / 46 同学宿舍治理系统数据库设计案例12 , 30 , , 4 , 4 , , , , , , = 0, = 男 = 女 ;（ 2）宿舍楼基本信息表的建立： , 4 , , ,

29、 4 , 12 10 , 0 0 0; （ 7）宿舍楼物品出入基本信息表的建立： 9 , , , 16 9 , , , 4 , 4 , 23 / 46 同学宿舍治理系统数据库设计案例, , , , , , , 0; （ 8）宿舍配备物品损坏基本信息表的建立： 16 , , 9 6 , , , 4 , 4 , , , , , , , , = 0; （ 9）宿舍损坏配备物品赔偿基本信息表的建立： 16 , , 9 , 15 , , , , , = 0; （ 10）宿舍事故注册基本信息表的建立： , 10 , , 9 , 30 , , 24 / 46 同学宿舍治理系统数据库设计案例15 , , 12

30、 , , , , 0,; （ 11）宿舍事故调查基本信息表的建立： , 15 , 15 , , , , ,; （ 12）宿舍事故赔偿基本信息表的建立： , 9 , , 30 , 5.1.3 15 , , , ; 建立视图（ 1）用于查询和更新楼道工人基本信息的视图定义如下：编号,姓名,工作类型,工资,性别,联系方式,工作时间,宿舍楼编号,校区,区位 * ; （ 2）便利于宿舍楼基本信息查询、更新的视图定义如下：宿舍楼编号,校区,区位,楼管处电话,楼管 * 25 / 46 同学宿舍治理系统数据库设计案例; （ 3）显示宿舍基本信息的视图定义如下：宿舍编号,舍长,年级,学院,专业,宿舍楼编号,校区

31、,区位 * ; （ 4）可用于宿舍楼配备物品基本信息查询、更新的视图定义如下：物品名,价格,数量,宿舍楼编号,校区,区位 * ; （ 5）用于查询和更新同学基本信息的视图定义如下：学号,学院,姓名,性别,祖籍,诞生日期,入学时间,专业,班级,宿舍编号,宿舍楼编号,校区,区位 * ; （ 6）显示宿舍保卫处基本信息的视图定义如下：名称,人员数目,负责人,电话 * ; （ 7）以便于物品出入治理和出入物品信息查询、更新的视图定义如下：学号,出入物品,负责人,日期,序号,宿舍楼编号,校区,区位 * ; （ 8）便于宿舍配备物品损坏登记及损坏宿舍物品查询的视图定义如下：物品名,学号,宿舍号,损坏数量,

32、宿舍楼编号,校区,区位 * 26 / 46 同学宿舍治理系统数据库设计案例; （ 9）用于查询损坏物品赔偿基本信息,便于宿舍物品治理的视图定义如下：物品名,学号,负责人,日期,赔偿数量 * ；（ 10）便利同学事故的注册及保卫人员对事故注册查询的视图定义如下：编号,事故类型,学号,日期,缺失物品,属实,负责单位,缺失数量,同学联系方式 * ; （ 11）便于宿舍以外事故调查的视图定义如下：编号,调查名称,负责单位,调查结果 * ；（ 12）便利宿舍事故赔偿信息查询和更换的视图定义如下：编号,学号,赔偿物品,日期,负责单位 * ; 5.1.4 建立索引; ; , ; ; ; ; 27 / 46

33、同学宿舍治理系统数据库设计案例5.2 数据入库系统包括宿舍同学基本信息治理、楼道工人基本信息治理、宿舍楼基本信息治理、宿舍基本信息治理、宿舍事故基本信息治理、宿舍楼物品出入基本信息治理、宿舍楼保卫处基本信息治理、宿舍配备物品及处理治理等八大功能模块,共有 12 张基本表 ,牵涉到大量数据的录入 ,又由于时间限制 ,采纳事先在中录入数据 ,然后使用 2022 数据导入 /导出向导功能 ,直接将数据导入到相应的基本表中；当然,附录中也给出了各个基本表插入元组的储备功能,具体内容请参阅附录 2；5.3 创建各个功能的储备过程系统共创建了 16 个储备过程,具体列表如下：表 3.1 创建的储备过程列表

34、：编号储备过程名称定义2-1 作用1 p1 详见附录在中插入一元组2 p2 详见附录2-2 在中插入一元组3 p3 详见附录2-3 在中插入一元组4 p4 详见附录2-4 在中插入一元组5 p5 详见附录2-5 在中插入一元组6 p6 详见附录2-6 在中插入一元组7 p7 详见附录2-7 在中插入一元组8 p8 详见附录2-8 在中插入一元组9 p9 详见附录2-9 在中插入一元组10 p10 详见附录2-10 在中插入一元组11 p11 详见附录2-11 在中插入一元组12 p12 详见附录2-12 在中插入一元组13 p13 详见附录2-13 在中匹配 查询14 p14 详见附录2-14

35、 在中匹配 查询15 p15 详见附录2-15 在中删除元组16 p16 详见附录2-16 在中更新操作（其他表的查询、修改、删除与表的大致相同,这里不再具体列出）28 / 46 同学宿舍治理系统数据库设计案例附录 1 数据库规律结构定义1.楼道工人 基本信息表,用于记录楼道工人的基本信息：表 2.3 楼道工人基本信息表属性名数据类型取值范畴是否是主属性或外键完整性5 00000 99999 是10 大于 500 （元 /月）否8 否否2 男、女否12 00 99 否30 否是4 四周八方其中之一是4 四周八方其中之一是2.宿舍楼 基本信息表,用于记录宿舍楼的基本信息：表 2.4 宿舍楼基本信

36、息表属性名数据类型取值范畴是否是主属性或外键完整性4 00 99 是四周八方其中之一是4 四周八方其中之一是12 否10 否3.宿舍 基本信息表,用于记录宿舍的基本信息：表 2.5 宿舍基本信息表属性名数据类型取值范畴是否是主属性或外键完整性6 01-001 99-999 是10 00 99 否4 否20 否20 否是4 四周八方其中之一是4 四周八方其中之一是29 / 46 同学宿舍治理系统数据库设计案例4.宿舍楼配备物品 基本信息表,用于记录宿舍楼配备物品的基本信息：表 2.6 宿舍配备物品基本信息属性名数据类型取值范畴是否是主属性或外键完整性5.宿舍同学16 是大于 0 否大于 0 否0

37、0 99 是4 四周八方其中之一是4 四周八方其中之一是 基本信息表,用于记录宿舍同学的基本信息：图 2.7 宿舍同学基本信息属性名数据类型取值范畴 999999999 是否是主属性或外键完整性9 00000000是20 男、女否10 否2 否10 否否否6.宿舍保卫处20 否大于 0 小于 10 否601-001 99-999 是00 99 是4 四周八方其中之一是4 四周八方其中之一是 基本信息表,用于记录保卫处的基本信息：图 2.8 宿舍保卫处基本信息属性名数据类型取值范畴是否是主属性或外键完整性7.宿舍楼物品出入15 是大于 0 否10 否12 否 基本信息表,用于记录物品出入的基本信

38、息：图 2.9 宿舍楼物品出入基本信息属性名数据类型取值范畴 999999999 是否是主属性或外键完整性9 00000000是30 / 46 同学宿舍治理系统数据库设计案例属性名数据类型取值范畴是否是主属性或外键完整性16 否9 否是8.宿舍配备物品损坏4 大于 0 是00 99 是四周八方其中之一是4 四周八方其中之一是 基本信息表,用于记录物品损坏的基本信息：图 2.10 宿舍配备物品损坏基本信息属性名 数据类型 取值范畴 是否是主属性或外键 完整性16 是9 00000000 999999999 是6 01-001 99-999 是大于等于 0 否00 99 是4 四周八方其中之一 是

39、4 四周八方其中之一 是9.宿舍配备物品损坏赔偿 基本信息表,记录损坏物品赔偿的基本信息：图 2.11 宿舍配备物品损坏赔偿基本信息属性名数据类型取值范畴 999999999 是否是主属性或外键完整性16 00000000是9 是10 是否10. 宿舍事故注册大于等于0 否基本信息表,用于记录宿舍事故注册的基本信息：2.12 宿舍事故注册基本信息属性名数据类型取值范畴是否是主属性或外键完整性10 00009999 是否30 00000000999999999 是是30 否否31 / 46 同学宿舍治理系统数据库设计案例属性名数据类型取值范畴是否是主属性或外键完整性11.宿舍事故调查15 是大于

40、等于0 否12 否 基本信息表,用于记录宿舍事故调查的基本信息：图 2.13 事故调查基本信息属性名数据类型取值范畴是否是主属性或外键完整性15 00009999 是是15 是否12. 宿舍事故赔偿 基本信息表,用于记录宿舍事故赔偿的基本信息：图 2.14 宿舍事故赔偿基本信息属性名数据类型取值范畴 999999999 是否是主属性或外键完整性10 00009999 是00000000是30 否否15 是32 / 46 同学宿舍治理系统数据库设计案例附录 2 储备过程定义11 的定义 : p1 5, 10 ,8, , 2, 30, , 4, 4 , , , , , , , , ; 22 的定义 : p2 , 4, 4, 12, 10 , , , , ; 33 的定义 : p3 6, 10, 4, 20, 20, , 4, 4 33 / 46 同学宿舍治理系统数据库设计案例, , , , , , , ; 44 的定义 : p4 16, , , , 4, 4 , , , , , ; 55 的定义 : p5 9, 20, 10, 2, 10, , , 20, , 6, , 4, 4