企业内部文件管理系统
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
大连科技学院
数据库课程设计
题目企业内部文件管理系统
学生姓名 XXX 专业班级信管XX-x班
指导教师 XXX 职称 X教授
所在单位信息科学学院信息管理教研室
教学部主任XXX 完成日期 2017年6月24日
数据库课程设计评分标准
综合评定:(优、良、中、及格、不及格)指导教师签字:2017年6月24日
目录
1 绪论 (1)
1.1 课题简介 (1)
1.2 设计目的 (1)
1.3 设计内容 (1)
2 需求分析 (2)
2.1 需求概述 (2)
2.2 功能需求 (2)
3 数据库概念结构设计 (5)
3.1 局部概念模型设计 (5)
3.2 全局概念模型设计 (7)
4 数据库逻辑结构设计 (8)
4.1 E-R图向关系模型的转换 (8)
4.2 规范化处理 (8)
4.3 数据库结构 (8)
5 数据库物理结构设计 (10)
5.1 数据库建库 (10)
5.2 数据表及视图的建立 (10)
总结 (13)
参考文献 (14)
附录 (15)
1 绪论
1.1 课题简介
随着我国市场经济的快速发展和信息化水平的不断提高,如何利用先进的管理手段,提高企业管理的水平,是当今社会所面临的一个课题。在竞争越来越激烈的今天
企业如何提高办公效率显得越来越重要。尤其是对于大型企业来说,企业内部结构复杂,条文众多,横向和纵向间需要沟通信息,发送文件。如果没有一套可靠的企业内部文件管理系统,单凭文件发放,不仅效率低下,而且浪费纸张。
1.2 设计目的
内部行文管理模块的主要目标是实现对企业内部文件的编写、审核、发送、领导审批、办理结果等全过程的有效跟踪和控制并对需要永久性记录的文件实现归档管理等实现内部行文管理的电子化、自动化、提高部门之间的办公效率减少纸张浪费和时间浪费以达到快速、可靠的信息交互目的。而企业内部的文件管理是一项琐碎、复杂而又十分需要细致的工作,文件的基本资料,文件的传递和处理等一般不允许出错,如果实行手工操作,就会耗费工作人员大量的时间和精力,使用计算机进行企业内部文件工作的管理,能够保证各项信息准确无误、快速输出,从而提高公司效率。
1.3 设计内容
为了编制该系统,我参阅了企业内部文件管理的相关流程。
企业内部文件管理系统包括对文件的撰写、修改、接受和发送的功能。
第二,采用企业内部文件管理系统可以方便的对文件进行传输和修改。
同时,本系统采用了现代管理方法。广泛应用科学决策方法对各地的租赁房屋进行分类、整理、汇总到系统中,以实现高效性和准确性。
2 需求分析
2.1 需求概述
为方便企业内部文件管理,某公司决定开发企业内部文件管理系统。通过本企业内部文件管理系统,员工可以发布文件,对文件进行修改,以及进行文件的接收和发送操作。
2.2 功能需求
1.数据流图
(1)顶层数据流图
图2-1 顶层数据流图
(2)1层数据流图
图2-2 1层数据流图2.数据字典:
3 数据库概念结构设计
在系统设计的开始,首先考虑的是如何用数据模型来数据库的结构与语义,以对现实世界进行抽象。目前广泛使用的数据模型可分为两种类型,一种是独立于计算机系统的“概念数据模型”,如“实体联系模型”;另一种是直接面向数据库逻辑结构的“结构数据模型”。本系统采用“实体联系模型”(E-R图)来描述数据库的结构与语义,以对现实世界进行第一次抽象。
E-R图是直观表示概念模型的工具,它有四个基本成分:
矩形框,表示实体类型(考虑问题的对象)。
菱形框,表示联系类型(实体间的联系)。
椭圆形框,表示实体类型和联系类型的属性。对于关键码的属性,在属性名下划一横线。
直线,联系类型与其涉及的实体类型之间以直线连接。
3.1 局部概念模型设计
图3-1 员工实体图
图3-2 部门实体图
图3-3 文件信息实体图
3.2 全局概念模型设计
图3-3 系统E-R图
4 数据库逻辑结构设计
4.1 E-R图向关系模型的转换
概念设计中得到的E-R图是由实体、属性和联系组成的,而关系数据库逻辑设计的结果是一族关系模式的集合,所以讲E-R图转换为关系模型实际上是将实体、属性和联系转换成关系模式。
针对本实例,通过对房屋信息管理的内容和数据流程分析,本设计的数据项和数据结构如下:
部门(部门代码、部门名称、部门经理、部门人数)
员工(员工号、员工姓名、联系方式、性别、员工部门)
文件信息(文件编号、员工号、文件名称、文件作者、文件类型、文件创建日期)处理反馈(文件编号、部门代码、文件修改意见、文件反馈日期)
1.2规范化处理
要求至少满足三范式,每个关系模式必须有泛化过程。
1. 部门(部门代码、部门名称、部门经理、部门人数)
部门代码→部门代码,部门代码→部门经理,部门代码→部门人数
部门代码为主属性,其他为非主属性,满足三范式。
2. 员工(员工号、员工姓名、联系方式、性别、员工部门)
员工号→员工姓名,员工号→联系方式
员工号→性别,员工号→员工部门
员工号为主属性,其他为非主属性,满足三范式。
3.文件信息(文件编号、员工号、文件名称、文件作者、文件类型、文件创建日期)
文件编号、员工号→文件名称,文件编号、员工号→文件名称,
文件编号、员工号→文件作者,文件编号、员工号→文件类型,
文件编号、员工号→文件名称,文件编号、员工号→文件创建日期,
文件编号、员工号为主属性,其他为非主属性,满足三范式
4.处理反馈(文件编号、部门代码、文件修改意见、文件反馈日期)
文件编号、部门代码→文件修改意见,文件编号、部门代码→文件反馈日期
文件编号、部门代码为主属性,其他为非主属性,满足三范式。
4.3 数据库结构
KT租户基本信息表
表4-1 USKT部门表