学生宿舍管理系统oracle数据库设计.doc

学生宿舍管理系统数据库设计 - 1. 系统需求分析阶段 1.1.2 需求分析阶段的任务 （1）处理对象： 系统要处理的对象包括宿舍楼基本信息、学生基本信息、宿舍基本信息、楼道工作人员基本信息、宿舍保卫处基本信息、宿舍事故基本信息、物品出入基本信息等七个方面，各个对象包括信息如下所示（详细的数据见于数据字典）： 1．宿舍楼基本信息(Dormitory)：包括 宿舍楼编号、宿舍楼所在校区、宿舍楼再校区中区域、每一幢宿舍楼楼管处的电话、宿舍楼楼管员信息等方面，这样可以方便管理者对宿舍楼的管理，提高查询效率； 2．学生基本信息(Student)：包括 学生编号、学生所在学院信息、学生姓名、学生性别、学生来自省份、学生出生日期、学生入学时间、学生所学专业、所在班级等方面的信息，可以方便学信息的查询和更新； 3．宿舍基本信息(Room，Fitment，FitmentDestruction，FitmentCompensate)：宿舍基本信息包括四个数据结构（宿舍信息(Room)，宿舍物品信息(Fitment)，宿舍物品损坏信息(FitmentDestruction),宿舍损坏物品赔偿信息）,每个数据结构中的数据项见数据字典； 4．楼道工作人员基本信息(Worker)：包括 工作人员编号、工作人员姓名、工作类型、工资、性别、联系方式、工作时间等数据项，可以方便管理人员对宿舍楼道工人的任用、信息查询及更改； 5．宿舍保卫处基本信息(SafeGuard)：包括保卫处名称、人员数目、负责人信息、联系电话等四方面的信息； 6．宿舍事故基本信息(Accident，AccidentResearch，AccidentCompensate)：事故信息包括三个数据结构（事故信息、事故处理信息、事故赔偿信息），具体的数据项见数据字典； 物品出入基本信息(ArticalInOut)：包括出入物品的学生信息、出入的物品信息、出入物品时的负责人信息、出入物品时间，尽量减少宿舍事故的发生，保障学生宿舍财产的安全。 （2）处理功能要求 系统主要完成一下几个功能： 1．宿舍楼基本信息查询与修改； 2．学生基本信息查询与更新； 3．每一幢宿舍楼中宿舍信息的查询与信息更新； 4．宿舍保卫处基本信息的查询和修改； 5．宿舍事故基本信息及事故处理信息的查询和修改； 6．宿舍楼物品出入审批及记录； （3）安全性和完整性要求 安全性先通过视图机制，不同的用户只能访问系统授权的视图，这样可提供系统数据一定程度上的安全性，再通过用户授权机制，欲用户登陆来识别用户级别，根据这个级别来分配用户权限，达到数据更高层次的安全保密功能。 完整性要求用于描述宿舍楼基本信息、学生基本信息、宿舍基本信息、楼道工作人员基本信息、宿舍保卫处基本信息、宿舍事故基本信息、物品出入基本信息中数据项能否为null，以及一些用户自定义完整性（符合实际要求），详细完整性要求见于系统的逻辑设计阶段。 1.1.3 需求分析阶段成果 （1）体会与收获 系统需求分析主要采取实地询问－记录和楼管处查询宿舍学生信息的方式，同时借鉴学长在做数据库开发这方面的经验。通过实地调查和询问，了解目前学生宿舍管理的现状，以及目前学生宿舍管理中一些问题，并对实际查询业务实地参与，了解了学生、楼管员、宿舍管理者、宿舍保卫人员对系统的信息处理要求，以及他（她）们对现存人工管理方式不能满足信息处理要求的苦恼。同时在调查中牵涉的许多的人际交流，恰当的询问方式，由于平时几乎没有做过这方面的调查，开始时有点胆怯和不知从何入手，但过了两三幢宿舍楼之后，开始的胆怯就感觉不到了。 （2）学生宿舍管理系统业务流程图 新生入住宿舍业务流程图： 查询业务流程图（查询宿舍学生信息、楼道工作人员信息、宿舍楼信息等）： 毕业生离宿业务流程图： 楼道工作人员任用业务流程图： 宿舍楼物品出入业务流程图： 宿舍事故处理业务流程图： （3）数据流程图 顶层数据流程图： 第2层数据流程图：从学生角度出发 第2层数据流程图：从管理者角度出发 图2.3 从管理者角度出发的2层数据流程图 第3层数据流程图：从新生角度出发 第3层数据流程图：从毕业生角度出发 第3层数据流程图：从宿舍楼物品出入出发 第3层数据流程图：从宿舍事故角度出入出发 第3层数据流程图：从楼道工作人员的任用角度出发 第3层数据流程图：从管理者和外来访客的角度出发 （4）数据字典 （a）数据项：系统涉及的数据项有71项 表1.1 数据项列表 数据项编号 数据项名 数据项含义 与其它数据项的关系 存储结构 别名 DI-1 StuNo 学生编号 char(9) 学号 DI-2 DepName 学生所在学院 char(20) 学院 DI-3 StuName 学生姓名 char(10) 姓名 DI