《机车检修分解管理信息系统的设计与实现论文.doc》由会员分享，可在线阅读，更多相关《机车检修分解管理信息系统的设计与实现论文.doc（43页珍藏版）》请在三一办公上搜索。
1、计 算 机 及 应 用毕业设计机车检修分解管理信息系统的设计与实现摘要：随着铁路改革步伐的加快，传统的机车检修质量控制已经不能满足当前铁路的发展，在铁路大提速的运输形势下，机车检修质量问题已经成为制约性要素，决定着机务部门各项工作的主动权。实验证明，一套完善的生产管理系统能有效的克服现行检修质量管理的诸多弊端，提高修车质量，压缩修车成本，不仅能对检修作业过程、作业质量实行有效卡控，还能对物料消耗，甚至对管理者的管理行为、政绩进行有效评价。本着此目标我们开发了机车检修分解管理信息系统，该系统采用C/S( Clientr/Server，客户端/服务器)架构体系， 以Delphi 6.0为开发语言，
2、Oracle 8.17为后台数据库。关键词：机车检修；分解管理；Delphi 6；Oracle 8.17；Client/Server架构目 录1 绪论11.1 引言11.2 系统开发的目的及意义12系统的开发环境与相关技术介绍22.1 系统开发环境与开发工具22.2 系统设计模式架构22.3 系统设计与实现的技术综述23 系统设计63.1系统分析63.2 系统功能设计83.3 数据库的设计与配置104系统实现234.1系统设计流程234.2 基础数据模块的设计实现234.3 机车接车会议决议模块的设计实现284.4 机车分解管理模块的设计实现304.5 用户管理模块的设计实现365 总结展望3
3、8参考文献3911 绪论1.1 引言随着计算机网络技术在铁路系统中各领域的广泛应用，为了适应当今市场的飞速发展和人民生活的需要，也为了给铁路发展带来新的机遇，把高科技产品计算机应用到管理和生产过程中，成为管理现代化、上水平必不可少的内容，同时按照铁道部铁路信息化总体规划建设总体规划的要求，结合铁道部220文件等部、路、分局关于机车运用检修的各种规章制度和ISO9000等质量体系标准的要求，满足机车检修质量信息化管理在空间和时间上的不断扩展的需求，我们开发了机车检修分解管理系统，该系统经过详细的需求调研分析、系统设计开发、系统培训实施等几个阶段，历经半年多的时间，经过双方大量艰苦而细致的工作，解
4、决了大量技术上、管理上等相关问题；同时经过1个多月的磨合与试运行，使得业务流程更加规范、软件系统更加稳定。1.2 系统开发的目的及意义通过计算机实现生产调度、质量跟踪控制等功能，规范基础管理工作，及时自动反馈各种信息，使整个分解过程都有迹可查，有据可依，使各种考核制度真正落实到实处，提高管理透明度，并实现各部门信息的共享。通过按车型、检修类型建立详细的机车检修指标，并对各种配件的更换情况做相应的记录，以便于进行个人、班组、车间指标完成情况和实际金额查询，年度/季度/月度配件更换率/更换金额查询，配件更换成本分析等分析决策功能；所有到生产处领料的更换配件领料票由每位分解检查人员根据分解检查结果通
5、过计算机按仓库分类开出，取消原有手工开票，以规范开票作业程序，从而达到降本增效、提高检修质量的目的；通过计算机管理，记录各项业务的实际操作情况，并通过查询统计及时有效地反映实际状况，从而为问题处理和决策分析提供准确及时的业务数据。通过数据信息实现对分解检查人员的考核、配件消耗考核，提高管理透明度、完善分厂考核机制；在系统中实现资源信息的安全共享，不同的业务人员都能够看到自己管辖范围内的所有信息数据，并能够向其它部门提供有效信息，以实现信息共享。2系统的开发环境与相关技术介绍2.1 系统开发环境与开发工具2.1.1后端运行环境l 服务器 ：Microsoft Windows 2000 Serve
6、rl 数据库 ：Oracle 8.17 l Web 服务：IISl 服务器端计算机最低配置：CPU P3.2GHz，256M RAM，10G HD2.1.2前端运行环境l 客户端：Windows XP/ Windows 2000 l 开发工具：Delphi 6l 客户端计算机最低配置：CPU P2.8GHz，128M RAM2.2 系统设计模式架构机车检修分解管理系统采用什么体系结构，应该从该厂现有的网络和计算机软硬件资源以及系统本身的特点去考虑。该厂本身有内部局域网和一定的计算机资源，为系统采用客户机/服务器结构提供了硬件支持。同时根据软件开发的目标，系统拟采用过程控制方式实现这种想法。与以
7、往的信息管理系统的单纯数据管理不同的是，过程控制方式必须依靠前面的信息输入的结果来决定下一个过程的开始，这样势必要求输入信息的正确性，否则过程控制将毫无意义。这就要求系统所选择的结构具有一定的安全性，同时检修分解管理系统的业务流程比较复杂，数据交换量大，这对网络流量也提出了要求。根据以上情况，结合几种体系结构的特点，本系统决定采用客户机/服务器（C/S）架构，首先是因为C/S架构具有安全性高、开放性好和数据交换能力强的特点，同时开发人员在C/S架构开发方面积累的经验和可供利用的丰富的资源会给开发带来一些方便。2.3 系统设计与实现的技术综述2.3.1 Delphi 概述14由Borland公司
8、推出的Delphi是全新的可视化编程环境，为我们提供了一种方便、快捷的Windows应用程序开发工具。它使用了Microsoft Windows图形用户界面的许多先进特性和设计思想，采用了弹性可重复利用的完整的面向对象程序语言(Object-Oriented Language)、当今世界上最快的编辑器、最为领先的数据库技术。Delphi它提供了500多个可供使用的构件，利用这些部件，开发人员可以快速地构造出应用系统。开发人员也可以根据自己的需要修改部件或用Delphi本身编写自己的部件。我们选用它作为系统编程语言，主要是由于其具有以下优点：l Delphi具有面向用户的图形界面，交互性强，界面
9、程序量少，可按用户的实际要求快速、方便的修改其界面。l Delphi具有开发周期短，见效快的优点。l Delphi作为Windows编程技术之一，所设计的程序有Windows环境所具有的五大优点，即标准的图形用户界面、动态链接（DLL）、多任务、设备独立性以及直接操作特性。同时，其事件驱动的编程机制使得程序设计起来容易，读起来直观，使用起来方便。l Delphi具有很多由第三方（即非Microsoft公司和用户以外的第三计算机软件开发方）开发的工具箱，使得Delphi程序设计非常简单。2.3.2应用程序的数据访问l 数据访问体系结构数据访问涉及三个主要的组成部分， 应用程序(Delphi)、数
10、据层(ADO)，以及真正的数据源。这些部分之间的关系构成了所有数据识别应用程序的基础结构。其如图3.1所示。图2.1数据访问体系结构l Delphi与数据库的连接ADOADO(ActiveX Data Objects)是微软公司提供的一种面向对象的编程接口，是一个用于存取数据源的COM组件。它提供了编程语言和统一数据访问方式OLE DB的一个中间层。允许开发人员编写访问数据的代码而不用关心数据库是如何实现的，而只用关心到数据库的连接。ADO 是对当前微软所支持的数据库进行操作的最有效和最简单直接的方法，它是一种功能强大的数据访问编程模式，从而使得大部分数据源可编程的属性得以直接扩展到你的Act
11、ive Server 页面上。ADO 数据提供程序的三个核心对象是：（1）ADOConnection：设置其ConnectionString属性，以便连接到指定的数据库；（2）ADOQuery：设置其Connection属性，指定连接数据源，并填写SQL语句，执行SQL命令；（3）DataSource：填充一个 DataSet，解析数据源的更新；2.3.3 ADO 操作Oracle数据库的步骤l 使用ADOConnection对象来连接数据库Var UserID,PassWrd,DataSource:String; /读取参数文件当中的数据库用户名、密码、服务名VConnString: str
12、ing;VConStr: WideString;Begin 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;l 创建一个ADOQuery对象来查询A
13、DOQuery1. Connection := ADOConnection1 ; /指定数据源连接ADOQuery1.Close;ADOQuery1. SQL.Clear;ADOQuery1.SQL .Add(selct * from 数据表 ); /对ADOQuery填写SQL语句ADOQuery1. Open;l 通过DataSource 使Grid与ADOQuery绑定DataSource1. DataSet := ADOQuery1;Grid. DataSource := DataSource1;2.3.4 数据库介绍15 本系统后台数据库采用Oracle，该数据库系统是在数据库领域一
14、直处于领先地位的Oracle（即甲骨文公司）的产品。可以说Oracle关系数据库系统是目前世界上流行的关系数据库管理系统，也是目前最流行的客户/服务器(CLIENT/SERVER)体系结构的数据库之一，该系统可移植性好、使用方便、功能强，适用于各类大、中、小、微机环境。它是一种高效率、可靠性好的适应高吞吐量的数据库解决方案。其特点包括以下几点16：1、ORACLE7.X以来引入了共享SQL和多线索服务器体系结构。这减少了ORACLE的资源占用，并增强了ORACLE的能力，使之在低档软硬件平台上用较少的资源就可以支持更多的用户，而在高档平台上可以支持成百上千个用户。 2、提供了基于角色(ROLE
15、)分工的安全保密管理。在数据库管理功能、完整性 检查、安全性、一致性方面都有良好的表现。 3、支持大量多媒体数据，如二进制图形、声音、动画以及多维数据结构等。 4、提供了与第三代高级语言的接口软件PRO*系列，能在C,C+等主语言中嵌入SQL语句及过程化(PL/SQL)语句，对数据库中的数据进行操纵。加上它有许多优秀的前台开发工具如POWERBUILD、SQL*FORMS、VISIABASIC等，可以快速开发生成基于客户端PC平台的应用程序，并具有良好的移植性。5、提供了新的分布式数据库能力。可通过网络较方便地读写远端数据库里的数据，并有对称复制的技术。系统主要用到以下数据库语句功能：SELE
16、CT：从数据库表中检索数据行和列INSERT：向数据库表添加新数据行DELETE：从数据库表中删除数据行UPDATE：更新数据库表中的数据3 系统设计3.1系统分析3.1.1 机车检修现行存在的主要问题随着市场化经济的不断发展，铁路机车检修行业的竞争日趋强烈，如何适应不断变化的市场需求，如何保证产品质量，这些都对传统的管理模式和检测手段，提出了新的挑战，具体表现在：（1）作业控制和检测手段滞后现有的检测试验手段滞后，影响了其检测结果，而且在检修质量管理考核上存在的人为因素不可控、技术标准不落实、质量控制不彻底、作业行为不规范等问题。（2）基础工作不完善，开票作业流程不规范机车检修指标、各种配件
17、的更换情况存在各种人为因素，并没有详细记录，缺乏对个人、班组、车间指标完成情况和实际金额查询，年度/季度/月度配件更换率/更换金额查询，配件更换成本分析等分析决策功能；手工开票存在多开票、重复开票等不符合要求等现象。（3）考核机制不健全对分解检查人员的考核、班组配件消耗考核等考核机制存在诸多的人为因素，影响考核效果。（4）各部门没有实现信息共享原有手工操作，没有实现信息化管理，没有实现信息资源的共享。3.1.2 系统可行性分析针对传统的管理方法和检测手段不能适应日趋市场化的铁路行业，我们提出了机车检修分解管理系统开发的课题，并经过多方调查和了解同时结合该机车厂自身条件，机车检修分解管理系统从技
18、术上、经济上、管理上均已具备实施的基本条件。（1）技术上的可行性技术方面的可行性就是根据现有的技术条件，所提出的要求能否达到。随着计算机的普及，硬件处理速度的提高和软件智能化的提高，采用电脑进行管理，已成为未来管理的主要模式。目前厂内各部门均有有多台计算机，并配有WINDOWS2000或WINDOWS XP操作平台，可作为客户端连接到数据库服务器上，而且大部分人员对计算机技术有一定的了解，有一定的计算机操作能力，实施新系统后只需经过简单的培训即可，而且我公司在使用Delphi6开发软件以及oracle数据库系统软件已在其他多个机务段成功实施，因此说本系统开发在技术上是可行的。（2）经济上的可行
19、性根据该厂的实际情况，开发一套机车检修分解管理系统软件，无论从设备费用，开发费用，运行费用还是培训费用，都在企业承受能力之内。然而，使用该软件带来的长期效益确是远远超出想象的，主要表现在：l 提高了工作效率及管理水平；l 节省了人力，减轻了手工处理的负担；l 提供信息及时，并且各部门信息共享，实现了无纸化办公，节约了成本；l 提高了员工素质，还可进一步促进有关管理方式与体制的合理改革。（3）管理上的可行性l 科学管理的基础工作是建立管理信息系统的前提l 经过调查了解，该厂的管理体制还算比较合理，规章制度也还比较完善，有一套自己的管理方法和程序，原始数据的来源与正确性和准确性有一定的保证，因此建
20、立本系统是可行的。l 社会环境因素要求管理现代化l 二十一世纪是知识经济时代，在信息技术如此发达的今天，一个企业要生存，要发展下去而不被淘汰，就必须跟上技术的发展。建立有效的企业管理信息系统，从而提高企业自身的管理水平，提高工作效率，有助于企业加强自身的竞争力，不被时代所淘汰。l 用户的积极参与l 总厂领导、分厂领导的重视，管理层的普遍支持，同时相关业务人员的积极参与，都为本系统的开发提供了有力保障。3.1.3 系统需求分析本系统的设计对象是针对机车厂检修分解管理，通过对机车厂进行详细的需求调研分析，了解到该厂对机车检修分解管理系统的需求主要包括以下几方面：l 完善基础工作l 按车型、检修类型
21、建立详细的机车检修指标，并对各种配件的更换情况做相应的记录，以便于进行个人、班组、车间指标完成情况和实际金额查询，年度/季度/月度配件更换率/更换金额查询，配件更换成本分析等分析决策功能l 规范开票作业程序，自动生成领料单l 所有到生产处领料的更换配件领料票由每位分解检查人员根据分解检查结果通过计算机按仓库分类开出，取消原有手工开票。（提供多次领料和补票功能）。l 完善分厂考核机制 分解检查人员的考核分解检查人员可以及时的了解到当前开票机车自己分管项目的更换金额，也可以了解到自己本月已发生的平均更换金额，并与自己的指标进行比较，确保指标的完成。分解室主任通过该系统月底可以对其个人指标完成情况进
22、行考核。 配件消耗考核车间根据修车计划、台量定额自动计算各班组的配件消耗情况，年度/季度/月度配件更换率/更换金额，并对其进行考核。l 各部门信息共享，实现无纸化办公在权限准许范围内实现各部门信息的高度共享。3.2 系统功能设计根据该机车厂的实际情况和面向用户的特点，本系统功能设计满足以下几个方面：l 基础数据维护l 局信息、段信息、部门信息、配件信息、分解指标、仓库信息、修理方法、修程设置、机车决议形式设置、机车检查内容设置。l 录入机车接车会议决议l 对入厂检修的机车信息进行录入；录入机车接车会议决议，对于已经维护好的机车检查内容，可以通过填写检查内容编号或选择的方式进行录入到机车会议决议
23、中去。l 维护空白分解明细书l 按车型、部门、分解员、班组、检修类型维护对应的分解明细书模板，即空白分解明细书；对于新增加的模板可以通过导入已存在模板的方式进行维护；对于已存在的模板可以导出到Excel表格中。l 填写机车分解明细书，形成领料单l 根据空白明细书模板，填写机车分解明细书，对每个配件在此次检修过程中更换数量、修理数量、修理方法进行填写（本次进厂检修过程的各次更换数量和修理数量之和小于等于设计数量；分解总金额不能超过其对应的分解指标金额），并自动按仓库生成领料单或退料单；l 如果空白模板中的配件信息有所更改，可以通过更新模板的方式进行更新分解明细书，以保证和空白模板中的信息一致。l
24、 各种查询分析功能 单台机车分解查询：可以按分解车间、配件金额、配件单价查询。 机车分解综合查询：可以按机车号、局段、检修类型、分解业务组、分解员、统计日期、配件金额、配件单价、配件查询。 预算统计分析：可以按检修类型、统计日期、每台车的平均更换金额、配件更换金额查询。 查询配件l 权限的管理与分配为拥有相同权限的用户设置为同一个用户组，根据用户组权限的不同，设置用户组的相关权限即设置用户的相关权限。3.2.1 系统总体功能模块在开始对系统进行初级论证的阶段， 经过多次讨论和协调，我们将整个系统规划设计为四个部分，基础数据维护、机车接车会议决议、分解明细书、用户管理。l 基础数据维护模块主要对
25、各模块中用到的基础参数进行维护设置，功能框图如图3.1所示：图3.1 基础数据维护模块l 机车决议模块主要完成对入厂机车信息的录入，同时完成对入厂机车接车会议决议内容进行填写，形成报表供各处室浏览，功能框图如图3.2所示：图3.2 机车接车会议决议模块l 机车分解明细书模块主要完成对各空白明细书模板的维护，以及机车具体分解明细书的填写，并形成领料单，同时进行各种分析统计，完善基础工作，规范开票作业程序，完善各种考核机制，功能框图如图3.3所示：图3.3 机车接车会议决议模块l 用户管理模块主要完成各用户权限及密码的设置管理，功能框图如图3.4所示：图3.4 用户管理模块3.3 数据库的设计与配
26、置3.3.1 数据库的设计数据库设计是信息系统设计的重要组成部分，是系统模型的最原始的表示和反映。数据库设计的好坏直接关系到开发周期和系统性能。尤其当一个项目由多人公共开发时，应当在开发之前进行设计约定，并编写设计规范，其目的是：l 使数据对象命名统一，合理；l 数据存储合理，没有冗余，要符合数据库设计的3个范式。即：表中每一个值都是原子项，只显示一次；表中每行都必须可以被唯一地区分；表中不会有多余的已存在其他表中包含的非关键字信息；l 数据对象的关系清晰明了，符合业务逻辑；l 保证数据的完整性；l 维护方便；数据库命名规范见表3.1：表3.1数据库命名规范表数据对象命名规范例如数据表表名采用
27、汉语拼音，前一个词采用全拼且字头大写，后面的采用简拼大写字头局信息表：JuXXB段信息表：DuanXXB表字段命名规范同上局编号：JuBH局名称：JuMC视图数据表名加前缀（view_）view_FeiJieZBB存储过程采用汉语拼音命名，加前缀（sp_）sp_ FeiJieZBB触发器表名_操作_触发时间FenJieMXSBTB_DELETE_BEFORE(在分解明细书标题表删除之前执行)3.3.2 数据库配置全局数据库名：FJGLSID：FJGL表空间名：QSY_SCGL_DATA表空间大小：2GB用户名：QSY_SCGL_DBA用户权限：DBA连接服务名：FJGL3.3.3 数据表的设计
28、数据表设计在整个系统的开发过程中具有举足轻重的地位，是本系统的核心和基础。本系统的模块虽然具有一定的独立性，但是它们的数据之间却相互制约和相互依存，它要求合理地设计数据库的数据逻辑，数据一致性和完整性，保证数据的安全，高效。通过分析、设计，本系统建立30多个数据表，下面列出部分数据表如下：1) 局信息表“JuXXB”，用来记录机车所属的局信息。设计见表3.2。表3.2局信息表(JuXXB)字段名称数据类型长度备注局编号(JuBH)字符（char）2主键局名称(JuMC)字符（char)20局简称(JuJC)字符（char）12操作员编号(CaoZuoYuanBH)字符（char)5来自职工信息
29、编制日期(BianZhiRQ)日期（date）系统当前日期2) 段信息表“DuanXXB”，用来记录机车所属的段信息。设计见表3.3。表3.3段信息表(DuanXXB)字段名称数据类型长度备注段编号(DuanBH)字符（char）4主键（前2个字符为局编号）段名称(DuanMC)字符（char)20段简称(DuanJC)字符（char）12操作员编号(CaoZuoYuanBH)字符（char)5来自职工信息编制日期（date）(BianZhiRQ)日期（date）系统当前日期3) 分解业务组表“FenJieYWZB”，用来记录分解业务组信息。设计见表3.4。表3.4分解业务组(FenJieYW
30、ZB)字段名称数据类型长度备注分解业务组编号(FJYeWuZuBH)字符（char）2主键分解业务组名称(FJYeWuZuMC)字符（char）20分解业务组简称(FJYeWuZuJC)字符（char）12操作员编号(CaoZuoYuanBH)字符（char）5来自职工信息编制日期(BianZhiRQ)日期（date）8取系统当前日期备注(BeiZhu)字符（varchar2）604) 分解人员表“FenJieRYB”，用来记录分解员信息。设计见表3.5。表3.5分解人员表(FenJieRYB)字段名称数据类型长度备注分解员编号(FenJieYuanBH)字符（char）4主键（前2位为分解业
31、务组编号）分解员姓名(FenJieYuanXM)字符（char）20操作员编号(CaoZuoYuanBH)字符（char）5来自职工信息编制日期(BianZhiRQ)日期（date）8取系统当前日期备注(BeiZhu)字符（varchar2）60班组编号(ShengChanBZBH)字符（char）6主键职工编号(ZhiGongBH)字符（varchar2）205) 配件信息表“PeiJianXXB”，用来记录配件信息。设计见表3.6。表3.6配件信息表(PeiJianXXB)字段名称数据类型长度备注配件编号1(PeiJianBH1)字符（char）12主键（内部编号）配件编号2(PeiJia
32、nBH2)字符（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)字符（char）2厂、外、自、物操作员编号(CaoZuoYuanBH)字符（char）5来自职工信息编制日期(BianZhiRQ)日期（date）8取系统当前日期备注(
33、BeiZhu)字符（varchar2）60等级分类(ABCFL)字符（char）1现为判断配件是否发生更换的标志父编号(Parent)字符（char）12部门编号(BuMenBH)字符（char）46) 分解指标表“FenJieZBB”，用来记录每个分解员、班组、车型、检修类型的分解指标。设计见表3.7。表3.7分解指标(FenJieZBB)字段名称数据类型长度备注分解员编号(FenJieYuanBH)字符（char）4主键生产班组编号(ShengChanBZBH)字符（char）6车型编号(CheXingBH)字符（char）4分解类型(FenJieLX)字符（char）2检修类型(Jian
34、XiuLX)字符（char）4金额(JinE)数值（Number）8（2）操作员编号(CaoZuoYuanBH)字符（char）5来自职工信息编制日期(BianZhiRQ)日期（date）取系统当前日期备注(BeiZhu)字符（varchar2）607) 机车决议标题表“JCJueYiBTB”，用来维护机车决议标题信息。设计见表3.8。表3.8机车决议标题(JCJueYiBTB)字段名称数据类型长度备注决议标题编号( JCJueYiBTBH)字符（char）12主键机车编号(JiCheBH)字符（char）11柴油机编号(ChaiYouJBH)字符（char）8参加者(CanJiaZhe)字符
35、（varchar2）200操作员编号(CaoZuoYuanBH)字符（char）5来自职工信息编制日期(BianZhiRQ)日期（date）备注(BeiZhu)字符（varchar2）200序号(XH)字符（varchar2）8(AName)字符（varchar2）1008) 机车决议内容表“JCJueYiNRB”，用来记录机车决议内容信息。设计见表3.9。表3.9机车决议内容 (JCJueYiNRB)字段名称数据类型长度备注决议标题编号( JCJueYiBTBH )字符（char）12主键序号(XH)数值（Number）3检查内容(JianChaNR)字符（varchar2）200形式(Xi
36、ngShi)字符（varchar2）50会议决议(HuiYiJueYi)字符（varchar2）40类别(LeiBie)字符（varchar2）16类别编号(LeiBieBH)字符（char）1小类编号(XiaoLeiBH)字符（char）1修改标志(XiuGaiBZ)字符（char）1机车决议标题(JCJueYiBTB) 机车决议内容 (JCJueYiNRB)9) 空白分解明细书标题表“KBFenJieMXSBTB”，用来记录空白明细书标题信息。设计见表3.10。表3.10空白分解明细书标题 (KBFenJieMXSBTB)字段名称数据类型长度备注分解标题编号(FJBiaoTiBH)字符（v
37、archar2）20主键分解标题名称(FJBiaoTiMC)字符（varchar2）20车型编号(CheXingBH)字符（char）2分解员编号(FenJieYuanBH)字符（char）4生产班组编号(ShengChanBZBH)字符（char）6分解类型(FenJieLX)字符（char）2编制日期(BianZhiRQ)日期（date）备注(BeiZhu)字符（varchar2）2010) 空白分解明细书内容表“KBFenJieMXSNRB”，用来记录空白明细书具体内容。设计见表3.11。表3.11空白分解明细书内容(KBFenJieMXSNRB)字段名称数据类型长度备注分解标题编号(F
38、JBiaoTiBH)字符（varchar2）20主键配件编号(PeiJianBH)字符（char）12配件分类编号(PJFenLeiBH)字符（char）5备注(BeiZhu)字符（varchar2）20序号(XH)数值（Number）4空白分解明细书标题 (KBFenJieMXSBTB)空白分解明细书内容(KBFenJieMXSNRB)11) 分解明细书标题表“FenJieMXSBTB”，用来记录机车分解明细书标题信息。设计见表3.12。表3.12分解明细书标题 (FenJieMXSBTB)字段名称数据类型长度备注分解标题编号(FJBiaoTiBH)字符（varchar2）30主键分解标题名
39、称(FJBiaoTiMC)字符（varchar2）60机车编号(JiCheBH)字符（char）11分解员编号(FenJieYuanBH)字符（char）4生产班组编号(ShengChanBZBH)字符（char）6分解类型(FenJieLX)字符（char）2金额类型(JinELX)字符（char）8生成料单(ShengChengLD)字符（char）1编制日期(BianZhiRQ)日期（date）备注(BeiZhu)字符（varchar2）2012) 分解明细书内容表“FenJieMXSNRB”，用来记录机车分解明细书信息。设计见表3.13。表3.13分解明细书内容(FenJieMXSNR
40、B)字段名称数据类型长度备注分解标题编号(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）20序号(XH)数值（Number）4部门编号(BuMenBH)字符（char）4本
41、次更换数量(BenCiGHSL)数值（Number）5(1)字段名称数据类型长度备注分解明细书标题 (KBFenJieMXSBTB) 分解明细书内容(KBFenJieMXSNRB)13) 功能模块表“GongNengMKB”，用来记录功能模块信息。设计见表3.14。表3.14功能模块表(GongNengMKB)字段名称数据类型长度备注功能模块编号(GongNengMKBH)数值（Number）8主键功能模块名称(GongNengMKMC)字符（varchar2）40功能模块描述(GongNengMKMS)字符（varchar2）200父模块编号(ParentID)数值（Number）8(Acc
42、essed)字符（char）1DEFAULT=”Y”操作员编号(CaoZuoYuanBH)字符（char）5编制日期(BianZhiRQ)日期（date）备注(BeiZhu)字符（varchar2）20014) 用户和用户组对应表“YongHuAndZuB”，用来用户和用户组的对应关系。设计见表3.15。表3.15用户和用户组对应表(YongHuAndZuB)字段名称数据类型长度备注用户编号(YongHuBH)数值（Number）8主键组编号(ZuBH)数值（Number）515) 用户组和功能模块对应表“ZuAndGongNengMKB”，用来记录用户组和功能模块的对应关系。设计见表3.16
43、。表3.16用户组和功能模块对应表(ZuAndGongNengMKB)字段名称数据类型长度备注组编号(ZuBH)数值（Number）5主键功能模块编号(GongNengMKBH)数值（Number）8功能模块名称(GongNengMKMC)字符（varchar2）40功能模块描述(GongNengMKMS)字符（varchar2）200父模块编号(ParentID)数值（Number）8(Accessed)字符（char）1DEFAULT=”Y”3.3.4 数据库关系结构表关系图反应出了各表之间的关系，本系统在建立数据表时，如果表中引用到其它表的字段，都是引用其它表中的编号，这样可以保证各表中数据的一致性。本系统数据库中各表之间的关系如下列各图所示。机车决议模块各表间的关系，如图3.5所示： 图3.5 机车决议表间关系图分解管理模块各表间的关系，如图3.6所示： 图3.6 分解管理表间关系图用户管理模块各表间的关系，如图3.7所示：图3.7 用
