机车检修分解管理信息系统的设计与实现论文

1、i 计 算 机 及 应 用 毕 业 设 计 ii 机车检修分解管理信息系统的设计与实现 摘要：随着铁路改革步伐的加快，传统的机车检修质量控制已经不能满足当前铁路 的发展，在铁路大提速的运输形势下，机车检修质量问题已经成为制约性要素，决定 着机务部门各项工作的主动权。 实验证明，一套完善的生产管理系统能有效的克服现行检修质量管理的诸多弊端， 提高修车质量，压缩修车成本，不仅能对检修作业过程、作业质量实行有效卡控，还 能对物料消耗，甚至对管理者的管理行为、政绩进行有效评价。本着此目标我们开发 了机车检修分解管理信息系统 ，该系统采用 c/s( clientr/server，客户端/服务器)架 构体

2、系， 以 delphi 6.0 为开发语言，oracle 8.17 为后台数据库。 关键词：机车检修；分解管理；delphi 6；oracle 8.17；client/server 架构 iii 目 录 1 1 绪论绪论.1 1.1 引言.1 1.2 系统开发的目的及意义.1 2 2 系统的开发环境与相关技术介绍系统的开发环境与相关技术介绍.2 2.1 系统开发环境与开发工具.2 2.2 系统设计模式架构.2 2.3 系统设计与实现的技术综述.2 3 3 系统设计系统设计.6 3.1 系统分析.6 3.2 系统功能设计.8 3.3 数据库的设计与配置.10 4 4 系统实现系统实现.23 4.

3、1 系统设计流程.23 4.2 基础数据模块的设计实现.23 4.3 机车接车会议决议模块的设计实现.28 4.4 机车分解管理模块的设计实现.30 4.5 用户管理模块的设计实现.36 5 5 总结展望总结展望.38 参考文献参考文献.39 1 1 1 绪论 1.1 引言 随着计算机网络技术在铁路系统中各领域的广泛应用，为了适应当今市场的飞速 发展和人民生活的需要，也为了给铁路发展带来新的机遇，把高科技产品计算机应用 到管理和生产过程中，成为管理现代化、上水平必不可少的内容，同时按照铁道部 铁路信息化总体规划建设总体规划的要求，结合铁道部 220 文件等部、路、分局 关于机车运用检修的各种规

4、章制度和 iso9000 等质量体系标准的要求，满足机车检修 质量信息化管理在空间和时间上的不断扩展的需求，我们开发了机车检修分解管理 系统 ，该系统经过详细的需求调研分析、系统设计开发、系统培训实施等几个阶段， 历经半年多的时间，经过双方大量艰苦而细致的工作，解决了大量技术上、管理上等 相关问题；同时经过 1 个多月的磨合与试运行，使得业务流程更加规范、软件系统更 加稳定。 1.2 系统开发的目的及意义 通过计算机实现生产调度、质量跟踪控制等功能，规范基础管理工作，及时自动 反馈各种信息，使整个分解过程都有迹可查，有据可依，使各种考核制度真正落实到 实处，提高管理透明度，并实现各部门信息的共

5、享。 通过按车型、检修类型建立详细的机车检修指标，并对各种配件的更换情况做相 应的记录，以便于进行个人、班组、车间指标完成情况和实际金额查询，年度/季度/ 月度配件更换率/更换金额查询，配件更换成本分析等分析决策功能；所有到生产处 领料的更换配件领料票由每位分解检查人员根据分解检查结果通过计算机按仓库分类 开出，取消原有手工开票，以规范开票作业程序，从而达到降本增效、提高检修质量 的目的；通过计算机管理，记录各项业务的实际操作情况，并通过查询统计及时有效 地反映实际状况，从而为问题处理和决策分析提供准确及时的业务数据。通过数据信 息实现对分解检查人员的考核、配件消耗考核，提高管理透明度、完善分

6、厂考核机制； 在系统中实现资源信息的安全共享，不同的业务人员都能够看到自己管辖范围内的所 有信息数据，并能够向其它部门提供有效信息，以实现信息共享。 2 2 系统的开发环境与相关技术介绍 2.1 系统开发环境与开发工具 2.1.1 后端运行环境后端运行环境 服务器 ：microsoft windows 2000 server 数据库 ：oracle 8.17 web 服务：iis 服务器端计算机最低配置：cpu p3.2ghz，256m ram，10g hd 2.1.2 前端运行环境前端运行环境 客户端：windows xp/ windows 2000 开发工具：delphi 6 客户端计算机

7、最低配置：cpu p2.8ghz，128m ram 2.2 系统设计模式架构 机车检修分解管理系统采用什么体系结构，应该从该厂现有的网络和计算机软硬 件资源以及系统本身的特点去考虑。 该厂本身有内部局域网和一定的计算机资源，为系统采用客户机/服务器结构提 供了硬件支持。同时根据软件开发的目标，系统拟采用过程控制方式实现这种想法。 与以往的信息管理系统的单纯数据管理不同的是，过程控制方式必须依靠前面的信息 输入的结果来决定下一个过程的开始，这样势必要求输入信息的正确性，否则过程控 制将毫无意义。这就要求系统所选择的结构具有一定的安全性，同时检修分解管理系 统的业务流程比较复杂，数据交换量大，这对

8、网络流量也提出了要求。 根据以上情况，结合几种体系结构的特点，本系统决定采用客户机/服务器 （c/s）架构，首先是因为 c/s 架构具有安全性高、开放性好和数据交换能力强的特 点，同时开发人员在 c/s 架构开发方面积累的经验和可供利用的丰富的资源会给开发 带来一些方便。 2.3 系统设计与实现的技术综述 2.3.1 delphi 概述14 由 borland 公司推出的 delphi 是全新的可视化编程环境，为我们提供了一种方 便、快捷的 windows 应用程序开发工具。它使用了 microsoft windows 图形用户界面 的许多先进特性和设计思想，采用了弹性可重复利用的完整的面向对

9、象程序语言 (object-oriented language)、当今世界上最快的编辑器、最为领先的数据库技术。 delphi 它提供了 500 多个可供使用的构件，利用这些部件，开发人员可以快速 3 地 构造出应用系统。开发人员也可以根据自己的需要修改部件或用 delphi 本身编写自 己的部件。我们选用它作为系统编程语言，主要是由于其具有以下优点： delphi 具有面向用户的图形界面，交互性强，界面程序量少，可按用户的实际 要求快速、方便的修改其界面。 delphi 具有开发周期短，见效快的优点。 delphi 作为 windows 编程技术之一，所设计的程序有 windows 环境所具

10、有的 五大优点，即标准的图形用户界面、动态链接（dll） 、多任务、设备独立性 以及直接操作特性。同时，其事件驱动的编程机制使得程序设计起来容易，读 起来直观，使用起来方便。 delphi 具有很多由第三方（即非 microsoft 公司和用户以外的第三计算机软件 开发方）开发的工具箱，使得 delphi 程序设计非常简单。 2.3.2 应用程序的数据访问 数据访问体系结构 数据访问涉及三个主要的组成部分， 应用程序(delphi)、数据层(ado)，以 及真正的数据源。这些部分之间的关系构成了所有数据识别应用程序的基础结构。 其如图 3.1 所示。 delphi 与数据库的连接ado ado

11、(activex data objects)是微软公司提供的一种面向对象的编程接口，是 一个用于存取数据源的 com 组件。它提供了编程语言和统一数据访问方式 ole 图图 2.12.1 数据访问体系结构数据访问体系结构 4 db 的一个中间层。允许开发人员编写访问数据的代码而不用关心数据库是如何 实现的，而只用关心到数据库的连接。ado 是对当前微软所支持的数据库进行 操作的最有效和最简单直接的方法，它是一种功能强大的数据访问编程模式，从 而使得大部分数据源可编程的属性得以直接扩展到你的 active server 页面上。 ado 数据提供程序的三个核心对象是： （1）adoconnect

12、ion：设置其 connectionstring 属性，以便连接到指定的数 据库； （2）adoquery：设置其 connection 属性，指定连接数据源，并填写 sql 语 句，执行 sql 命令； （3）datasource：填充一个 dataset，解析数据源的更新； 2.3.3 ado 操作 oracle 数据库的步骤 使用 adoconnection 对象来连接数据库 var userid,passwrd,datasource:string; /读取参数文件当中的数据库用户名、密码、服务名 vconnstring: string; vconstr: widestring; beg

13、in vconnstring:=vconnstring+provider=msdaora.1;+passwrd+ userid +datasource; vconnstring := vconnstring + persist security info=true; vconstr := widestring(vconnstring); with adoconnection1 do begin connectionstring:=vconstr; connected := true; end; end; 创建一个 adoquery 对象来查询 adoquery1. connection :=

14、adoconnection1 ; /指定数据源连接 adoquery1.close; adoquery1. sql.clear; adoquery1.sql .add(selct * from 数据表 ); /对adoquery填写sql语句 5 adoquery1. open; 通过 datasource 使 grid 与 adoquery 绑定 datasource1. dataset := adoquery1; grid. datasource := datasource1; 2.3.4 数据库介绍15 本系统后台数据库采用 oracle，该数据库系统是在数据库领域一直处于领先地位 的

15、oracle（即甲骨文公司）的产品。可以说 oracle 关系数据库系统是目前世界上流行 的关系数据库管理系统，也是目前最流行的客户/服务器(client/server)体系结构 的数据库之一，该系统可移植性好、使用方便、功能强，适用于各类大、中、小、微 机环境。它是一种高效率、可靠性好的适应高吞吐量的数据库解决方案。 其特点包括以下几点16： 1、oracle7.x 以来引入了共享 sql 和多线索服务器体系结构。这减少了 oracle 的资源占用，并增强了 oracle 的能力，使之在低档软硬件平台上用较少 的资源就可以支持更多的用户，而在高档平台上可以支持成百上千个用户。 2、提供了基于

16、角色(role)分工的安全保密管理。在数据库管理功能、完整性 检查、安全性、一致性方面都有良好的表现。 3、支持大量多媒体数据，如二进制图形、声音、动画以及多维数据结构等。 4、提供了与第三代高级语言的接口软件 pro*系列，能在 c,c+等主语言中嵌入 sql 语句及过程化(pl/sql)语句，对数据库中的数据进行操纵。加上它有许多优秀的 前台开发工具如 power build、sql*forms、visia basic 等，可以快速开发生 成基于客户端 pc 平台的应用程序，并具有良好的移植性。 5、提供了新的分布式数据库能力。可通过网络较方便地读写远端数据库里的数 据，并有对称复制的技术

17、。 系统主要用到以下数据库语句功能： select ：从数据库表中检索数据行和列 insert ：向数据库表添加新数据行 delete ：从数据库表中删除数据行 update ：更新数据库表中的数据 6 3 系统设计 3.1 系统分析 3.1.1 机车检修现行存在的主要问题 随着市场化经济的不断发展，铁路机车检修行业的竞争日趋强烈，如何适应不断变化的市场 需求，如何保证产品质量，这些都对传统的管理模式和检测手段，提出了新的挑战，具体表现在： （1）作业控制和检测手段滞后 现有的检测试验手段滞后，影响了其检测结果，而且在检修质量管理考核上存在的人为因素 不可控、技术标准不落实、质量控制不彻底、作

18、业行为不规范等问题。 （2）基础工作不完善，开票作业流程不规范 机车检修指标、各种配件的更换情况存在各种人为因素，并没有详细记录，缺乏 对个人、班组、车间指标完成情况和实际金额查询，年度/季度/月度配件更换率/更换 金额查询，配件更换成本分析等分析决策功能；手工开票存在多开票、重复开票等不 符合要求等现象。 （3）考核机制不健全 对分解检查人员的考核、班组配件消耗考核等考核机制存在诸多的人为因素，影 响考核效果。 （4）各部门没有实现信息共享 原有手工操作，没有实现信息化管理，没有实现信息资源的共享。 3.1.2 系统可行性分析 针对传统的管理方法和检测手段不能适应日趋市场化的铁路行业，我们提

19、出了 机车检修分解管理系统开发的课题，并经过多方调查和了解同时结合该机车厂自 身条件，机车检修分解管理系统从技术上、经济上、管理上均已具备实施的基本条件。 （1）技术上的可行性 技术方面的可行性就是根据现有的技术条件，所提出的要求能否达到。随着计算 机的普及，硬件处理速度的提高和软件智能化的提高，采用电脑进行管理，已成为未 来管理的主要模式。目前厂内各部门均有有多台计算机，并配有 windows2000 或 7 windows xp 操作平台，可作为客户端连接到数据库服务器上，而且大部分人员对计算 机技术有一定的了解，有一定的计算机操作能力，实施新系统后只需经过简单的培训 即可，而且我公司在使

20、用 delphi6 开发软件以及 oracle 数据库系统软件已在其他多 个机务段成功实施，因此说本系统开发在技术上是可行的。 （2）经济上的可行性 根据该厂的实际情况，开发一套机车检修分解管理系统软件，无论从设备费用， 开发费用，运行费用还是培训费用，都在企业承受能力之内。然而，使用该软件带来 的长期效益确是远远超出想象的，主要表现在： 提高了工作效率及管理水平； 节省了人力，减轻了手工处理的负担； 提供信息及时，并且各部门信息共享，实现了无纸化办公，节约了成本； 提高了员工素质，还可进一步促进有关管理方式与体制的合理改革。 （3）管理上的可行性 科学管理的基础工作是建立管理信息系统的前提

21、经过调查了解，该厂的管理体制还算比较合理，规章制度也还比较完善，有 一套自己的管理方法和程序，原始数据的来源与正确性和准确性有一定的保 证，因此建立本系统是可行的。 社会环境因素要求管理现代化 二十一世纪是知识经济时代，在信息技术如此发达的今天，一个企业要生存， 要发展下去而不被淘汰，就必须跟上技术的发展。建立有效的企业管理信息 系统，从而提高企业自身的管理水平，提高工作效率，有助于企业加强自身 的竞争力，不被时代所淘汰。 用户的积极参与 总厂领导、分厂领导的重视，管理层的普遍支持，同时相关业务人员的积极 参与，都为本系统的开发提供了有力保障。 3.1.3 系统需求分析 本系统的设计对象是针对

22、机车厂检修分解管理，通过对机车厂进行详细的需求调 研分析，了解到该厂对机车检修分解管理系统的需求主要包括以下几方面： 完善基础工作 按车型、检修类型建立详细的机车检修指标，并对各种配件的更换情况做相 应的记录，以便于进行个人、班组、车间指标完成情况和实际金额查询，年 度/季度/月度配件更换率/更换金额查询，配件更换成本分析等分析决策功能 规范开票作业程序，自动生成领料单 8 所有到生产处领料的更换配件领料票由每位分解检查人员根据分解检查结果 通过计算机按仓库分类开出，取消原有手工开票。 （提供多次领料和补票功能） 。 完善分厂考核机制 分解检查人员的考核 分解检查人员可以及时的了解到当前开票机

23、车自己分管项目的更换金 额，也可以了解到自己本月已发生的平均更换金额，并与自己的指标进行 比较，确保指标的完成。分解室主任通过该系统月底可以对其个人指标完 成情况进行考核。 配件消耗考核 车间根据修车计划、台量定额自动计算各班组的配件消耗情况，年度/ 季度/月度配件更换率/更换金额，并对其进行考核。 各部门信息共享，实现无纸化办公 在权限准许范围内实现各部门信息的高度共享。 3.2 系统功能设计 根据该机车厂的实际情况和面向用户的特点，本系统功能设计满足以下几个方面： 基础数据维护 局信息、段信息、部门信息、配件信息、分解指标、仓库信息、修理方法、 修程设置、机车决议形式设置、机车检查内容设置

24、。 录入机车接车会议决议 对入厂检修的机车信息进行录入；录入机车接车会议决议，对于已经维护好 的机车检查内容，可以通过填写检查内容编号或选择的方式进行录入到机车 会议决议中去。 维护空白分解明细书 按车型、部门、分解员、班组、检修类型维护对应的分解明细书模板，即空 白分解明细书；对于新增加的模板可以通过导入已存在模板的方式进行维护； 对于已存在的模板可以导出到 excel 表格中。 填写机车分解明细书，形成领料单 根据空白明细书模板，填写机车分解明细书，对每个配件在此次检修过程中 更换数量、修理数量、修理方法进行填写（本次进厂检修过程的各次更换数 量和修理数量之和小于等于设计数量；分解总金额不

25、能超过其对应的分解指 标金额） ，并自动按仓库生成领料单或退料单； 9 如果空白模板中的配件信息有所更改，可以通过更新模板的方式进行更新分 解明细书，以保证和空白模板中的信息一致。 各种查询分析功能 单台机车分解查询：可以按分解车间、配件金额、配件单价查询。 机车分解综合查询：可以按机车号、局段、检修类型、分解业务组、分 解员、统计日期、配件金额、配件单价、配件查询。 预算统计分析：可以按检修类型、统计日期、每台车的平均更换金额、 配件更换金额查询。 查询配件 权限的管理与分配 为拥有相同权限的用户设置为同一个用户组，根据用户组权限的不同，设置 用户组的相关权限即设置用户的相关权限。 3.2.

26、1 系统总体功能模块 在开始对系统进行初级论证的阶段， 经过多次讨论和协调，我们将整个系统规 划设计为四个部分，基础数据维护、机车接车会议决议、分解明细书、用户管理。 基础数据维护模块 主要对各模块中用到的基础参数进行维护设置，功能框图如图 3.1 所示： 图 3.1 基础数据维护模块基础数据维护模块 机车决议模块 主要完成对入厂机车信息的录入，同时完成对入厂机车接车会议决议内容进 行填写，形成报表供各处室浏览，功能框图如图 3.2 所示： 10 图 3.2 机车接车会议决议模块机车接车会议决议模块 机车分解明细书模块 主要完成对各空白明细书模板的维护，以及机车具体分解明细书的填写，并 形成领

27、料单，同时进行各种分析统计，完善基础工作，规范开票作业程序，完善 各种考核机制，功能框图如图 3.3 所示： 图 3.3 机车接车会议决议模块机车接车会议决议模块 用户管理模块 主要完成各用户权限及密码的设置管理，功能框图如图 3.4 所示： 11 图 3.4 用户管理模块用户管理模块 3.3 数据库的设计与配置 3.3.1 数据库的设计 数据库设计是信息系统设计的重要组成部分，是系统模型的最原始的表示和反映。 数据库设计的好坏直接关系到开发周期和系统性能。尤其当一个项目由多人公共开发 时，应当在开发之前进行设计约定，并编写设计规范，其目的是： 使数据对象命名统一，合理； 数据存储合理，没有冗

28、余，要符合数据库设计的 3 个范式。即：表中每一个值 都是原子项，只显示一次；表中每行都必须可以被唯一地区分；表中不会有多 余的已存在其他表中包含的非关键字信息； 数据对象的关系清晰明了，符合业务逻辑； 保证数据的完整性； 维护方便； 数据库命名规范见表 3.1： 表 3.1 数据库命名规范表 数据对象数据对象命名规范命名规范例如例如 数据表表名采用汉语拼音，前一个词采用全拼且字头大 写，后面的采用简拼大写字头 局信息表：juxxb 段信息表：duanxxb 表字段命名规范同上局编号：jubh 局名称：jumc 视图数据表名加前缀（view_） view_feijiezbb 存储过程采用汉语拼

29、音命名，加前缀（sp_） sp_ feijiezbb 触发器表名_操作_触发时间 fenjiemxsbtb_delete_before (在分解明细书标题表删除之前执 行) 3.3.2 数据库配置 全局数据库名：fjgl sid：fjgl 表空间名：qsy_scgl_data 12 表空间大小：2gb 用户名：qsy_scgl_dba 用户权限：dba 连接服务名：fjgl 3.3.3 数据表的设计 数据表设计在整个系统的开发过程中具有举足轻重的地位，是本系统的核心和基 础。本系统的模块虽然具有一定的独立性，但是它们的数据之间却相互制约和相互依 存，它要求合理地设计数据库的数据逻辑，数据一致性

30、和完整性，保证数据的安全， 高效。通过分析、设计，本系统建立 30 多个数据表，下面列出部分数据表如下： 1)局信息表“juxxb”，用来记录机车所属的局信息。设计见表 3.2。 表 3.2 局信息表(juxxb) 字段名称数据类型长度备注 局编号(jubh)字符（char）2主键 局名称(jumc)字符（char)20 局简称(jujc)字符（char）12 操作员编号(caozuoyuanbh)字符（char)5来自职工信息 编制日期(bianzhirq)日期（date）系统当前日期 2)段信息表“duanxxb”，用来记录机车所属的段信息。设计见表 3.3。 表 3.3 段信息表(dua

31、nxxb) 字段名称数据类型长度备注 段编号(duanbh)字符（char）4主键（前 2 个字符为局编 号） 段名称(duanmc)字符（char)20 段简称(duanjc)字符（char）12 操作员编号(caozuoyuanbh)字符（char)5来自职工信息 编制日期（date）(bianzhirq)日期（date）系统当前日期 3)分解业务组表“fenjieywzb”，用来记录分解业务组信息。设计见表 3.4。 表 3.4 分解业务组(fenjieywzb) 13 4)分解人员表“fenjieryb”，用来记录分解员信息。设计见表 3.5。 表 3.5 分解人员表(fenjiery

32、b) 5)配件信息表“peijianxxb”，用来记录配件信息。设计见表 3.6。 表 3.6 配件信息表(peijianxxb) 字段名称数据类型长度备注 分解业务组编号(fjyewuzubh)字符（char）2主键 分解业务组名称 (fjyewuzumc) 字符（char）20 分解业务组简称(fjyewuzujc)字符（char）12 操作员编号(caozuoyuanbh)字符（char）5来自职工信息 编制日期(bianzhirq)日期（date）8取系统当前日期 备注(beizhu)字符 （varchar2） 60 字段名称数据类型长度备注 分解员编号(fenjieyuanbh)字符

33、（char）4主键（前 2 位为分解业务 组编号） 分解员姓名(fenjieyuanxm)字符（char）20 操作员编号(caozuoyuanbh)字符（char）5来自职工信息 编制日期(bianzhirq)日期（date）8取系统当前日期 备注(beizhu)字符 （varchar2） 60 班组编号(shengchanbzbh)字符（char）6主键 职工编号(zhigongbh)字符 （varchar2） 20 14 6)分解指标表“fenjiezbb”，用来记录每个分解员、班组、车型、检修类型的分 解指标。设计见表 3.7。 表 3.7 分解指标(fenjiezbb) 字段名称数据

34、类型长度备注 配件编号 1(peijianbh1)字符（char）12主键（内部编号） 配件编号 2(peijianbh2)字符（char）12（外部编号） 配件名称(peijianmc)字符 （varchar2） 40 配件简称(peijianjc)字符 （varchar2） 20 规格型号(guigexinghao)字符 （varchar2） 40 设计数(shejishu)数值 （number） 5 单位(danwei)字符 （varchar2） 8 单价(danjia)数值 （number） 8（2 ） 仓库编号(cangkubh)字符（char）4 来源(laiyuan)字符（cha

35、r）2厂、外、自、物 操作员编号(caozuoyuanbh)字符（char）5来自职工信息 编制日期(bianzhirq)日期（date）8取系统当前日期 备注(beizhu)字符 （varchar2） 60 等级分类(abcfl)字符（char）1现为判断配件是否发生更 换的标志 父编号(parent)字符（char）12 部门编号(bumenbh)字符（char）4 15 7) 机车决议标题表“jcjueyibtb”，用来维护机车决议标题信息。设计见表 3.8。 表 3.8 机车决议标题(jcjueyibtb) 8) 机车决议内容表“jcjueyinrb”，用来记录机车决议内容信息。设计见

36、表 3.9。 表 3.9 机车决议内容 (jcjueyinrb) 字段名称数据类型长度备注 分解员编号(fenjieyuanbh)字符（char）4主键 生产班组编号 (shengchanbzbh) 字符（char）6 车型编号(chexingbh)字符（char）4 分解类型(fenjielx)字符（char）2 检修类型(jianxiulx)字符（char）4 金额(jine)数值（number）8（2 ） 操作员编号(caozuoyuanbh)字符（char）5来自职工信息 编制日期(bianzhirq)日期（date）取系统当前日期 备注(beizhu)字符 （varchar2） 60

37、 字段名称数据类型长度备注 决议标题编号( jcjueyibtbh)字符（char）12主键 机车编号(jichebh)字符（char）11 柴油机编号(chaiyoujbh)字符（char）8 参加者(canjiazhe)字符 （varchar2） 200 操作员编号(caozuoyuanbh)字符（char）5来自职工信息 编制日期(bianzhirq)日期（date） 备注(beizhu)字符 （varchar2） 200 序号(xh)字符 （varchar2） 8 (aname)字符（varchar2）100 16 机车决议标题(jcjueyibtb) 机车决议内容 (jcjueyin

38、rb) 9) 空白分解明细书标题表“kbfenjiemxsbtb”，用来记录空白明细书标题信息。 设计见表 3.10。 表 3.10 空白分解明细书标题 (kbfenjiemxsbtb) 10)空白分解明细书内容表“kbfenjiemxsnrb”，用来记录空白明细书具体 内容。设计见表 3.11。 表 3.11 空白分解明细书内容(kbfenjiemxsnrb) 字段名称数据类型长度备注 决议标题编号( jcjueyibtbh )字符（char）12 序号(xh)数值（number）3 主键 检查内容(jianchanr)字符 （varchar2） 200 形式(xingshi)字符 （var

39、char2） 50 会议决议(huiyijueyi)字符 （varchar2） 40 类别(leibie)字符 （varchar2） 16 类别编号(leibiebh)字符（char）1 小类编号(xiaoleibh)字符（char）1 修改标志(xiugaibz)字符（char）1 字段名称数据类型长度备注 分解标题编号(fjbiaotibh)字符 （varchar2） 20主键 分解标题名称(fjbiaotimc)字符 （varchar2） 20 车型编号(chexingbh)字符（char）2 分解员编号(fenjieyuanbh)字符（char）4 生产班组编号 (shengchanb

40、zbh) 字符（char）6 分解类型(fenjielx)字符（char）2 编制日期(bianzhirq)日期（date） 备注(beizhu)字符 （varchar2） 20 17 空白分解明细书标题 (kbfenjiemxsbtb)空白分解明细书内容(kbfenjiemxsnrb) 11)分解明细书标题表“fenjiemxsbtb”，用来记录机车分解明细书标题信息。 设计见表 3.12。 表 3.12 分解明细书标题 (fenjiemxsbtb) 12)分解明细书内容表“fenjiemxsnrb”，用来记录机车分解明细书信息。设 计见表 3.13。 表 3.13 分解明细书内容(fenj

41、iemxsnrb) 字段名称数据类型长度备注 分解标题编号(fjbiaotibh)字符 （varchar2） 20 配件编号(peijianbh)字符（char）12 主键 配件分类编号(pjfenleibh)字符（char）5 备注(beizhu)字符 （varchar2） 20 序号(xh)数值 （number） 4 字段名称数据类型长度备注 分解标题编号(fjbiaotibh)字符 （varchar2） 30主键 分解标题名称(fjbiaotimc)字符 （varchar2） 60 机车编号(jichebh)字符（char）11 分解员编号(fenjieyuanbh)字符（char）4

42、生产班组编号(shengchanbzbh)字符（char）6 分解类型(fenjielx)字符（char）2 金额类型(jinelx)字符（char）8 生成料单(shengchengld)字符（char）1 编制日期(bianzhirq)日期（date） 备注(beizhu)字符 （varchar2） 20 18 分解明细书标题 (kbfenjiemxsbtb) 分解明细书内容(kbfenjiemxsnrb) 13)功能模块表“gongnengmkb”，用来记录功能模块信息。设计见表 3.14。 表 3.14 功能模块表(gongnengmkb) 14)用户和用户组对应表“yonghuand

43、zub”，用来用户和用户组的对应关系。 字段名称数据类型长度备注 分解标题编号(fjbiaotibh)字符 （varchar2） 30 配件编号(peijianbh)字符（char）12 主键 配件分类编号(pjfenleibh)字符（char）5 修理数量(xiulisl)数值 （number） 5 更换数量(genghuansl)数值 （number） 5 金额(jine)数值 （number） 10(2) 修理方法编号(xiuliffbh)字符 （varchar2） 20 修理方法名称(xiuliffmc)字符 （varchar2） 30 备注(beizhu)字符 （varchar2）

44、20 序号(xh)数值 （number） 4 部门编号(bumenbh)字符（char）4 本次更换数量(bencighsl)数值 （number） 5(1) 字段名称数据类型长度备注 字段名称数据类型长度备注 功能模块编号(gongnengmkbh)数值 （number） 8主键 功能模块名称(gongnengmkmc)字符 （varchar2） 40 功能模块描述(gongnengmkms)字符 （varchar2） 200 父模块编号(parentid)数值 （number） 8 (accessed)字符（char）1default=”y” 操作员编号(caozuoyuanbh)字符（c

45、har）5 编制日期(bianzhirq)日期（date） 备注(beizhu)字符 （varchar2） 200 19 设计见表 3.15。 表 3.15 用户和用户组对应表(yonghuandzub) 15)用户组和功能模块对应表“zuandgongnengmkb”，用来记录用户组和功 能模块的对应关系。设计见表 3.16。 表 3.16 用户组和功能模块对应表(zuandgongnengmkb) 3.3.4 数据库关系结构 表关系图反应出了各表之间的关系，本系统在建立数据表时，如果表中引用到其 它表的字段，都是引用其它表中的编号，这样可以保证各表中数据的一致性。本系统 数据库中各表之间的

46、关系如下列各图所示。 机车决议模块各表间的关系，如图 3.5 所示： 字段名称数据类型长度备注 用户编号(yonghubh)数值 （number） 8 组编号(zubh)数值 （number） 5 主键 字段名称数据类型长度备注 组编号(zubh)数值 （number） 5 功能模块编号(gongnengmkbh)数值 （number） 8 主键 功能模块名称(gongnengmkmc)字符 （varchar2） 40 功能模块描述(gongnengmkms)字符 （varchar2） 200 父模块编号(parentid)数值 （number） 8 (accessed)字符（char）1de

47、fault=”y” 图图 3.53.5 机车决议表间关系图机车决议表间关系图 20 分解管理模块各表间的关系，如图 3.6 所示： 用户管理模块各表间的关系，如图 3.7 所示： 图图 3.73.7 用户管理表间关系图用户管理表间关系图 图图 3.63.6 分解管理表间关系图分解管理表间关系图 21 3.3.5 视图、存储过程与触发器的设计 （1）视图的设计17 视图是一个虚拟表，其内容由查询定义，视图的作用类似于筛选。定义视图的筛 选可以来自当前或其它数据库的一个或多个表，或者其它视图。视图是存储在数据库 中的查询的 sql 语句，视图有很多优点，主要表现在： 视点集中 简化操作 定制数据

48、合并分割数据 安全性 本系统使用的视图，简单介绍如下： view_fenjiezbb:按车型、分解员、生产班组、检修类型查询对应的分解指标； view_yonghuandzu:根据用户编号和组编号查找所在组名称及登录名； view_yonghuxxb:根据用户表中的职工编号查找其对应的职工姓名及所在 班组； fenjiemxsbtb_view: 从 fenjiemxsbtb ,chexingxxb ,xiuchengxxb 中查找标题 编号对应的标题名称、车型名称、修程名称及其它相关信息； jcjueyibtb_view:通过机车决议标题编号，查找其标题对应的详细标题名称 及其它相关信息 （2

49、）存储过程的设计18 存储过程是 oracle 服务器上一组预先编译好的 transact-sql 语句，它以一个名 称存储在数据库中，并作为一个独立的数据库对象，也可以作为一个单元，供用户在 22 应用程序中调用。存储过程存储在数据库内，可通过来自应用程序的调用执行，并且 支持用户声明的变量、有条件执行以及其他强大的编程功能。可以接受和输出参数， 返回执行存储过程的状态值，而且还可以嵌套调用。 存储过程的优点如下： 存储过程因为 sql 语句已经预编译过了，因此运行的速度比较快。 存储过程可以接受参数、输出参数、返回单个或多个结果集以及返回值，可以 向程序返回错误原因。 存储过程运行比较稳定

50、，不会有太多的错误。只要一次成功，以后都会按这个 程序运行。 存储过程主要是在服务器上运行，减少对客户机的压力。 存储过程可以包含程序流、逻辑以及对数据库的查询，同时可以实体封装和隐 藏数据逻辑。 存储过程可以在单个存储过程中执行一系列 sql 语句。 存储过程可以从自己的存储过程内引用其它存储过程，这可以简化一系列复杂 语句。 本系统使用的存储过程，简单介绍如下： insert_fenjiezbb：用于向 fenjiezbb 表添加分解指标信息； deltree：用于删除 zuandgongnengmkb 表和 gongnengmkb 表的功能模 块； （3）触发器的设计19 触发器是一种特

51、殊类型的存储过程，在使用触发器之前可以与存储过程进行比较， 触发器主要是通过事件进行触发而被执行的，不由用户直接调用，而存储过程可以通 过存储过程名称而被直接调用。创建触发器时会对其进行定义，以便在对特定表或列 作特定类型的数据修改时执行。它在指定的表中的数据发生变化时自动生效。唤醒调 用触发器以响应 insert、update 或 delete 语句。触发器可以查询其它表， 并可以包含复杂的 transact-sql 语句。将触发器和触发它的语句作为可在触发器内 回滚的单个事务对待。如果检测到严重错误（例如，磁盘空间不足） ，则整个事务即 自动回滚。 触发器的优点如下： 触发器可通过数据库中

52、的相关表实现级联更改；不过，通过级联引用完整性约 束可以更有效地执行这些更改。 触发器可以强制比用 check 约束定义的约束更为复杂的约束。与 check 23 约束不同，触发器可以引用其它表中的列。例如，触发器可以使用另一个表中 的 select 比较插入或更新的数据，以及执行其它操作，如修改数据或显示 用户定义错误信息。 触发器也可以评估数据修改前后的表状态，并根据其差异采取对策。 本系统使用的触发器，简单介绍如下： fenjiemxsbtb_delete_before：删除分解明细书标题表时先删除其分 解 标题编号对应的分解明细书内容表中的记录； fenjiemxsbtb_update

53、_after：分解明细书标题表中的分解标题编号修改 后同时修改分解标题编号对应的分解明细书内容表的分解标题编号； fenjiejcxxb_delete_before：删除分解机车信息时，把分解明细书标题 表中对应该机车的记录也删除； jcjueyibtb_delete_before：删除机车决议标题时，删除其标题编号对应 的机车决议内容表中的记录； juxxb_delete_before：删除局信息时，删除该局下面对应的段信息； yonghuxxb_delete_before：删除用户信息时，同时删除 yonghuandzb 表中的对应的该用户记录； yonghuzb _before_dele

54、te：删除用户组时，同时删除 yonghuandzb 和 zuandgongnengmkb 表中该组对应的记录； 3.3.6 数据库的建立 数据库是信息系统的核心，管理信息系统的开发应该围绕数据库而展开。在检验 认证业务管理系统中，为了灵活、方便并且易于维护，在前期分析的基础上我采用 sql 脚本的方式建立数据库。 sql 教本包含以下几部分： sql 脚本的说明； 数据库的建立和初始化； 数据表的建立； 视图的建立； 存储过程的建立； 向表中插入的部分初始化的数据； 后期对数据库对象的修改和维护； 下面是数据库脚本的基本结构和部分实例： 24 /*/ /* 戚墅堰机车车辆厂 */ /*项目：

55、机车检修分解管理系统 */ /*作者：李景梅 */ /*说明：建立数据库及相关对象 */ /* 此脚本基于 oracle8i 的 plsql 编写 */ /*/ /*/ / 建立表 / /*/ drop table juxxb; create table juxxb ( jubh char(2) not null, jumc varchar2(20), jujc varchar2(12), caozuoyuanbh char(5), bianzhirq date, constraint pk_ juxxb primary key (jubh) ); /*/ / 建立视图 / /*/ creat

56、e or replace view qsy_scgl_dba.view_yonghuandzu as ( select yhz.yonghubh,yhz.zubh,z.zumc,yh.yonghudlm from yonghuxxb yh,yonghuzb z,yonghuandzb yhz where yh.yonghubh=yhz.yonghubh and z.zubh=yhz.zubh ) /*/ / 建立存储过程 / 25 /*/ create or replace procedure deltree (parent number) as begin for c1 in (select

57、 gongnengmkbh from gongnengmkb start with parentid=parent connect by parentid=prior gongnengmkbh) loop delete from zuandgongnengmkb where gongnengmkbh=c1.gongnengmkbh; delete from gongnengmkb where gongnengmkbh=c1.gongnengmkbh; end loop; commit; end; /*/ / 建立触发器 / /*/ create or replace trigger fenji

58、emxsbtb_delete_before declare begin delete from fenjiemxsnrb where fenjiemxsnrb.fjbiaotibh=:fenjiemxsbtb.fjbiaotibh; end; /*/ 4 系统实现 4.1 系统设计流程 机车入厂后，召开机车接车会议，段方司乘人员描述机车故障情况提出检修要求， 26 双方讨论后，形成会议记录。会议结束后，负责机车接车会议决议的人员，负责建立 机车会议决议标题，把实际入厂的机车信息维护好，并根据会议记录填写该机车接车 会议决议内容，填写后形成按检查类别形成机车决议报表，提供给段方司乘人员，并 提供

59、给各部门按照此决议进行检修分解。同时，负责分解的分解员根据接车会议情况 上车检查机车配件损坏情况，并根据检查情况对配件需进行更换或修理等情况进行填 写，即根据空白分解明细书模板填写机车具体的分解明细书，填写时不能超过配件的 设计数量（即最大数量） 、不能超过该分解员的指定分解指标；填写保存后，系统根 据配件所属仓库情况，自动按仓库形成领料单；系统根据发生的配件情况，形成各种 报表供各部门查询，并进行统计分析。系统流程图如图 4.1 所示： 图图 4.1 系统设计流程图系统设计流程图 4.2 基础数据模块的设计实现 4.2.1 局段信息设置 设置局、段信息，对局段进行增、删、改操作；在左边树型结

60、构中选择第一层 “铁路局” ，点击右键弹出编辑菜单，点击增加，弹出输入局信息窗口，增加局信息； 在左边树型结构中选择第二层如“北京铁路局” ，点击右键弹出编辑菜单，点击增加， 增加该局下面的段信息。如图 4.2 所示： 27 图图 4.2 局段信息设置界面局段信息设置界面 4.2.2 车型信息设置 设置车型信息，对车型进行增、删、改操作；如图4.3所示： 图图 4.3 车型信息设置界面车型信息设置界面 以下是增加或修改车型信息后，保存到数据库中实现的代码： procedure tfrmchexingsz.btnokclick(sender: tobject); var command: tad