汽车企业售后服务连锁门店管理系统的设计论文与实现-学位论文.doc

装订线长 春 大 学 毕业设计（论文）纸汽车企业售后服务连锁门店管理系统的设计与实现【摘要】 汽车营销服务在整个市场营销服务的过程中分为售前服务、售中服务和售后服务。汽车售后服务是为顾客保养汽车、维修汽车以及获得顾客对汽车产品和服务的反馈信息的一个平台。汽车售后服务是保障汽车消费者权益的有效途径，在整个汽车营销服务中起到了非常重要的作用。本系统是基于当前汽车后市场的现状而设计的管理系统。它采用C/S模式来设计，既充分利用了C/S模式交互性强、速度快、安全性高的优点，实现了汽车售后服务的管理，使汽车售后服务数字化、信息化。客户端可以实现客户关系管理，门店与总部共享数据，客户维修管理，服务站业务设置，客户服务以及财务统计等功能，为售后管理提供了方便。系统有三种角色，分别是管理员、服务站负责人、客户服务。管理员拥有全部权限，可以对系统用户、角色、服务站以及客服信息进行管理，同时也可以处理服务站业务并统计财务信息。当用户以客户服务角色登录，用户值可以对客服信息进行管理。服务站负责人则只能处理服务站业务。基于软件的安全性、易用性考虑，本系统采用SQL Server 2000作为后台数据库，客户端开发工具选择Visual C+ 6.0，采用ODBC技术连接数据库，程序动态配置数据源，减轻用户负担。【关键词】汽车 售后服务 连锁门店 C/S ODBCThe Design and Implement of Automobile Enterprise After-sales Service Chain Store Management System【Abstract】 The marketing service of automobile is divided into pre-sales service, on-sales service and after-sales service. After-sales service of automobile enterprise provides a platform, which can maintain automobile and get feedback about auto production and service from customers. After-sales service is an effective approach that guarantees automobile consumers rights and interests and it plays an increasingly important role in the whole automobile marketing service.This management system is based current automobile after-markets actuality. It adopt C/S mode, so it take advantage of strong points of C/S mode, strong communication, fast-speed and high security. The client programs can do the management of customers, share data with headquarters database, customers maintenance management, operations setting, customer service, statistic of finance and so on. It provides convenience for after-sales service. It has three roles, administrator, stationsmanager and customer service. Administrator own the whole privileges. You can manage the system user,role,station,customer service information and deal with the stations operations when you login as an administrator.If you login system as the role of customer service,you can deal with the customer service relative information. And if you login as a manager of station, you will only deal with the operation about stations.Considering the security and easy-using of software, this system use SQL Server 2000 as background database. The client programs choose Visual C+ 6.0 to develop, and it access database via ODBC. Program will configure data source when it runs.【Keyword】car service chain store C/S ODBC目 录1 前 言11.1课题来源11.2研究意义11.3相关背景11.4本论文已完成工作22 系统分析32.1 需求分析的概念32.2 需求分析的任务32.3 需求分析的方法32.4 系统功能需求42.5 系统性能需求62.5.1 硬件环境62.5.2 软件环境62.6 可行性研究62.6.1 技术可行性62.6.2 操作可行性72.6.3 经济可行性72.7 小结73 开发工具简介83.1 Visual C+ 介绍83.1.1 利用Visual C+/MFC开发Windows程序的优势83.1.2 MFC的ODBC类简介83.2 数据库介绍93.3 ODBC介绍93.4 本章小结104 系统总体设计114.1系统体系结构设计114.1.1 系统功能分析114.1.2 系统模块设计124.2 数据库设计134.2.1 数据库需求分析144.2.2 数据库概念结构设计144.2.3 数据库逻辑结构设计154.2.4 数据库表设计174.3 本章小结175 系统详细设计185.1 主界面设计195.2 系统各个模块设计205.2.1 系统登录模块设计205.2.2 用户管理模块设计215.2.3 客服管理模块设计245.2.4 服务站管理模块设计255.2.5 服务站业务处理模块设计265.2.6 财务统计模块设计305.3 本章小结316 系统实现326.1 编码326.2 测试理论326.3 测试内容336.3.1 单元测试336.3.2 集成测试346.3.3 确认测试356.3.4 系统测试366.3.5 测试结论366.4 本章小结367 结 论37致 谢38参考文献391 前 言1.1课题来源随着科学技术的飞速发展，几乎所有行业相继都出现了生产能力过剩的状况，当然也包括汽车经销商的售后服务方面。随着汽车技术的进步和科学技术的飞速发展，汽车产品已走入家庭，并且作为一种代步工具，逐渐进入民化。面对汽车这样的高科技产品，“坏了怎么办？”，“我如何去保养它？”等一系列问题总是困扰着客户，这在客观上就要求汽车经销商要提供优质的售后服务为客户保障。汽车企业做大做强,售后服务管理是关键环节,快速、准确、全面的信息反馈系统是提高企业对市场反应能力和科学决策的关键。售后服务的地位占在一个越来越重要的地位。现在已进入信息化时代，各行各业的业务都已迅猛发展，这样一来，人们的工作量也剧增。汽车售后服务也面临这样的问题，连锁店的出现，大量繁琐的数据，影响着人们工作的效率和生活质量。为此，汽车企业售后服务连锁门店管理系统的出现是必然的。1.2研究意义近年来,随着我国汽车工业迅速发展,汽车拥有量也大幅增加,达到了2600多万辆。我国庞大的汽车拥有量和快速的汽车销售增长,为汽车服务业的发展提供了巨大的成长空间。传统的汽车销售服务业,也正受到各方面的局限越来越大。随着信息经济、网络经济、知识经济新时代的到来, 汽车售后服务规模的扩大，汽车行业的多数企业建立了网络化售后服务体系。这种信息化管理系统的实施,改变了汽车行业传统的沟通方式,减少了售后服务的响应时间,实现了企业售后服务的高效、准备、可靠，使汽车售后服务更加完善。1.3相关背景据统计，汽车售后服务市场是汽车产业链中最稳定的利润来源，可占据总利润的60%左右，相对于目前整车销售的利润缩水，中国的汽车售后服务市场利润率仍就能高达40%。 从汽车下线进入用户群开始，到整车成为废弃物为止的全过程，都是汽车“后市场”各环节服务所关注的范畴。据世界排名前10位的汽车公司近10年的利润情况分析，在一个完全成熟的国际化汽车市场，汽车的销售利润约占整个汽车业利润的20%，零部件供应利润约占20%，有60%的利润是在其服务领域中产生的。这说明中国汽车后市场发展空间非常巨大，充满着无限的机遇。基于多方面的调研、考察，从系统功能的实现，技术的要求以及可行性等多方面进行考虑，认为本课题是一个适应现今汽车企业售后服务连锁门店管理需求的系统。1.4本论文已完成工作本论文从需求分析到系统设计、实现、测试做了详细介绍。已完成如下工作。(1)通过调研、与用户沟通完成需求分析，得到系统的功能需求；(2)设计数据库、系统模块；(3)详细设计各个模块；(4)实现系统，测试系统。共 39 页 第 2 页2 系统分析为了开发出真正满足用户需求的软件，首先必须知道用户的需求。对软件需求的深入理解是软件开发工作获得成功的前提和关键，不论我们把设计和编码做得如何出色，不能真正满足用户需求的程序只会给用户带来失望，给开发者带来烦恼。软件需求分析是系统开发的第一步也是最重要的一个环节，其基本任务是准确地回答“系统做什么？”这个问题，这需要在对用户需求进行充分调研的基础上，深入理解并描述出软件的功能、性能、接口等方面的需求，可以使用UML建模作为需求分析和系统设计的有效方法。2.1 需求分析的概念首先，我们先了解一下需求分析的概念。需求分析是发现、求精、建模、规格说明和复审的过程1。为了发现用户的真正需求，首先应该从宏观角度调查、分析用户所面临的问题。也就是说，需求分析的第一步是尽可能准确地了解用户当前的情况和需要解决的问题。之后，分析员对用户提出的初步要求反复求精多次细化，得出对目标系统的完整、准确和具体的要求。2.2 需求分析的任务需求分析的任务不是具体地解决客户的问题，而是准确地回答“目标系统必须做什么”这个问题。虽然在可行性研究阶段已经粗略了解了用户的需求，甚至还提出了一个一些可行的方案，但是，可行性研究的基本目的是用较小的成本在较短的时间内确定是否存在可行的解法，因此许多细节被忽略了。然而在最终的系统中缺不能遗漏任何一个微笑的细节，所以可行性研究并不能代替需求分析，它实际上并没有准确地回答“系统必须做什么”这个问题。需求分析的任务还不是确定系统怎样完成它的工作，而仅仅是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。2.3 需求分析的方法为了详尽地了解并正确地理解用户的需求，必须使用适当的技术与用户通信和沟通。需求分析的方法主要有访谈、简易的应用规格说明技术、快速建立软件原型三种。访谈是历史悠久的与用户通信的技术，至今仍被系统分析员广泛采用。为了促使用户与分析员密切合作共同分析需求，人们研究出一种面向团队的需求收集法，称为“简易的应用规格说明技术”。现在，这种技术已经成为信息系统界使用的主流技术。实践表明，快速建立软件原型是最准确、最有效和最强大的需求分析技术。快速应具备的基本特性是“快速”和“容易修改”，因此必须有适当的软件工具支持快速原型技术。通常使用第四代技术、可重用的软件构件及形式化规格说明与原型环境等工具，快速地构件和修改原型。2.4 系统功能需求需求分析阶段，开发人员不应该考虑代码或程序实现的细节，而应该把精力放在对现有业务逻辑的理解上，通过与用户之间的充分沟通，逐步理解并描述出得到用户确认的系统模型，包括用例模型和领域（domain，系统中关键的类）模型。软件开发人员在对用户进行需求调研的过程中，用户往往并不能立即准确描述出未来系统应该提供一些什么样的功能。因此，需要开发人员理解和分析需求，并将系统应该具有的功能通过用例图直观的描述出来，方便用户理解并做出评判，开发人员从而可以根据用户的反馈不断调整用例模型，直至完全正确、充分描述清楚系统功能。用例建模主要是分离出系统的活动参与者(Actor)和用例(Use Case)，用例是指对系统提供的功能的一种描述，而活动参与者是那些可能使用这些用例的人或外部系统，通过用例图可以描述出系统外部的执行者、系统的用例，以及它们之间的联系。(1)客户关系管理功能需求功能描述完成对客户资料的增删改查。用例模型客户关系管理用例模型如图2-1所示。图2-1 客户关系管理用例模型(2)服务站管理功能需求功能描述完成服务站的添加、修改、删除、查询以及服务站业务的设置。其中，服务站业务设置主要是设置服务站美容、维修两大派系业务的具体业务名称及费用。用例模型服务站管理用例模型如图2-2所示。图2-2 服务站管理用例模型(3)服务站业务处理功能需求功能描述a) 电话预约业务b) 汽车维修记录管理（配件损坏维修、返厂维修等 ） c) 汽车美容记录管理（汽车保养方面） 用例模型服务站业务处理用例模型如图2-3所示。图2-3 服务站业务处理用例模型(4)客户服务功能需求功能描述a) 客户咨询业务b) 客户建议受理c) 客户投诉受理d) 客户反馈处理用例模型客户服务用例模型如图2-4所示。图2-4 客户服务用例模型2.5 系统性能需求2.5.1 硬件环境CPU：AMD 3000+；内存：建议使用512MB或以上的RAM；显示驱动：256色、800*600分辨率；2.5.2 软件环境操作系统平台：Microsoft Windows 2000或Windows XP程序开发环境：Visual C+ 6.0数据库管理系统：Microsoft SQL Server 2000开发语言：Microsoft Visual C+ 6.02.6 可行性研究可行性研究的目的就是以最小的代价在尽可能短的时间内确定问题是否能够继续。必须明确的一点就是，可行性研究的目的不是解决问题，而是确定问题是否值得去解。如果问题没有可行的解，那么任何花在问题上的时间、资源和经费都是无谓的浪费。通常，我们要对方案从技术、经济、社会因素、用户操作等方面进行可行性分析，从而最终确定这项工程的可行性。本章将分别从这几个方面分析可行性。2.6.1 技术可行性本系统在开发过程中采用Visual C+。系统完成后，可以在运行稳定的大多数操作系统中运行，采用模块化的方法设计系统，模块的设计按照低耦合高内聚的原则，所以有较好的独立性、可扩展性、安全性。本系统在技术上是可行的。2.6.2 操作可行性用户最终看到的都是可视化的人机界面，全中文菜单。设计界面时也尽可能地简洁，尽量减少用户的输入动作，如使用下拉框或单选按钮等等，消除冗余的输入。设计时还有很多友情提示，可帮助用户节约学习时间。用户只需掌握一些计算机的基本操作就可以使用该系统功能。保持信息显示和数据输入之间的一致性。2.6.3 经济可行性系统在开发过程中利用的资源相对较少，并且不需要太高的硬件支持，同时系统的设计初衷是结合实际应用完成的，经济消耗不会很大，也不需要任何其它设备，所以在经济上可以开发本系统。2.7 小结本章完成了系统的需求分析和可行性研究，通过对技术、经济、操作三个方面可行性的分析，确定了本系统的可行性，并抽象出系统的分析模型，接下来第4章、第5章会详细描述系统设计阶段的任务。共 39 页 第 7 页3 开发工具简介本系统采用C/S模式开发，选择VC6.0作为客户端开发工具，Microsoft SQL Server 2000作为后台数据库。3.1 Visual C+ 介绍VC+6.0集成开发环境是集程序文件的输入、编辑、编译、连接、运行等各种操作为一体的、具有Windows窗口界面特色的环境。使用Visual C+的一个原因是它的灵活性，你可以彻底地控制整个开发环境，本系统使用VC开发客户端应用程序，其中用到了微软基础类库MFC，MFC是Win API与C+的结合，是API的封装。3.1.1 利用Visual C+/MFC开发Windows程序的优势MFC借助C+的优势为Windows开发开辟了一片新天地，同时也借助应用程序向导使开发者摆脱离了那些每次都必写基本代码，借助类向导和消息映射使开发者摆脱了定义消息处理时那种混乱和冗长的代码段。更令人兴奋的是利用C+的封装功能使开发者摆脱Windows中各种句柄的困扰，只需要面对C+中的对象，这样一来使开发更接近开发语言而远离系统。正因为MFC是建立在C+的基础上，所以要强调C/C+语言基础对开发的重要性。利用C+的封装性开发者可以更容易理解和操作各种窗口对象；利用C+的派生性开发者可以减少开发自定义窗口的时间和创造出可重用的代码；利用虚拟性可以在必要时更好的控制窗口的活动。而且C+本身所具备的超越C语言的特性都可以使开发者编写出更易用，更灵活的代码。 在MFC中对消息的处理利用了消息映射的方法，该方法的基础是宏定义实现，通过宏定义将消息分派到不同的成员函数进行处理。3.1.2 MFC的ODBC类简介MFC的ODBC类对较复杂的ODBC API进行了封装，提供了简化的调用接口，从而大大方便了数据库应用程序的开发。程序员不必了解ODBC API和SQL的具体细节，利用ODBC类即可完成对数据库的大部分操作。MFC的ODBC类主要包括五大类。CDatabase类：主要功能是建立与数据源的连接。CRecordset类：该类代表从数据源选择的一组记录（记录集），程序可以选择数据源中的某个表作为一个记录集，也可以通过对表的查询得到记录集，还可以合并同一数据源中多个表的列到一个记录集中通过该类可对记录集中的记录进行滚动、修改、增加和删除等操作。CRecordView类：提供了一个表单视图与某个记录集直接相连，利用对话框数据交换机制(DDX)在记录集与表单视图的控件之间传输数据。该类支持对记录的浏览和更新，在撤销时会自动关闭与之相联系的记录集。CFieldExchange类：支持记录字段数据交换（DFX），即记录集字段数据成员与相应的数据库的表的字段之间的数据交换。该类的功能与CDataExchange类的对话框数据交换功能类似。CDBException类：代表ODBC类产生的异常。概括地讲，CDatabase针对某个数据库，它负责连接数据源；CRecordset针对数据源中的记录集，它负责对记录的操作；CRecordView负责界面，而CFieldExchange负责CRecordset与数据源的数据交换。3.2 数据库介绍系统后台数据库Microsoft SQL Server 2000 能提供超大型系统所需的数据库服务。大型服务器可能有成千上万的用户同时连接到 SQL Server 2000 实例。SQL Server 2000 为这些环境提供了全面的保护，具有防止问题发生的安全措施。 SQL Server 2000 还在多个用户之间有效地分配可用资源，比如内存、网络带宽和磁盘 I/O。 SQL Server是一个C/S数据库服务器。 3.3 ODBC介绍ODBC是开放数据库互连的简称,是一种使用SQL的应用程序接口(API)，是微软公司开放服务结构中有关数据库的一个组成部分，它建立了一组规范，并提供了一组对数据库访问的标准API（应用程序编程接口）。这些API利用SQL来完成其大部分任务。ODBC本身也提供了对SQL语言的支持，用户可以直接将SQL语句送给ODBC。一个基于ODBC的应用程序对数据库的操作不依赖任何DBMS，不直接与DBMS打交道，所有的数据库操作由对应的DBMS的ODBC驱动程序完成。也就是说，不论是FoxPro、Access还是Oracle数据库，均可用ODBCAPI进行访问。由此可见，ODBC的最大优点是能以统一的方式处理所有的数据库。 应用程序要访问一个数据库，首先必须用ODBC管理器注册一个数据源，管理器根据数据源提供的数据库位置、数据库类型及ODBC驱动程序等信息，建立起ODBC与具体数据库的联系。这样，只要应用程序将数据源名提供给ODBC，ODBC就能建立起与相应数据库的连接。ODBC各部件之间的关系图如图3-1所示：图3-1 ODBC各部件之间的关系在访问ODBC数据源时需要ODBC驱动程序的支持。ODBC是为调用关系数据库提供统一途径的一类API,由于它适用于许多不同的数据库产品,因此是服务器扩展程序开发者们理所当然的选择。用Visual C+ 6.0安装程序可以安装SQL Server、 Access等驱动程序。3.4 本章小结通过对所选开发工具的了解，更加熟悉了各种开发工具的优缺点。选择VC和SQL Server既是由于二者的强大，又是由于本人较熟悉这两种工具，所以开发起来相对更容易些，开发周期也会相应缩短。共 39 页 第 10 页4 系统总体设计软件设计在软件工程过程中处于技术核心地位，是软件开发过程中决定软件产品质量的关键阶段。软件设计必须依据对软件产品的需求来进行。软件设计阶段包括总体设计和详细设计。本章将具体介绍总体设计阶段的工作，第6章将为大家介绍本系统详细设计阶段的具体内容。总体设计，也叫概要设计，其主要任务是通过仔细分析软件规格说明，适当地对软件进行功能分解，从而把软件划分为模块，并且设计出完成预定功能的模块结构。其中包括体系结构设计，接口设计，数据设计。4.1系统体系结构设计软件设计的基本原理要求，程序应该模块化，也就是说一个程序应该由若干个规模适中的模块按合理的层次结构组织而成。本节主要介绍程序体系结构的设计，也就是确定程序由哪些模块组成以及模块之间的关系。4.1.1 系统功能分析本系统是售后服务管理系统，采用C/S模式，分为总店客户端和服务站客户端。总店可以添加服务站点、设置站点业务及费用、财务汇总、客户服务管理，门店管理员可通过此系统管理维护售后服务信息。经过分析研究，本系统需要完成的主要功能如下。(1)系统管理完成系统角色和用户的管理、实现系统登录。系统中已有是三种角色：管理员、服务站负责人、客户服务。(2)服务站管理完成服务站的添加、修改、删除、查询。(3)服务站业务设置设置服务站美容、维修两大派系业务的具体业务名称及费用。(4)服务站业务管理主要完成基础业务的管理，包括电话预约业务、汽车维修记录管理、汽车美容记录管理等方面。(5)客户档案管理完成客户档案的增加和维护。(6)客户服务（客户服务受理）客户咨询业务客户建议受理客户投诉受理客户反馈处理4.1.2 系统模块设计模块化的设计方法更有利于我们开发一个大的系统，它将大问题分解而简化了问题。模块的设计应该满足低耦合、高内聚的原则，这样才能保证模块的独立性。本系统通过HIPO图来描述软件的体系结构。通常用层次结构图来描述软件的层次，图中的每一个矩形框代表一个模块，框间连线表示调用关系。本节内容将用层次结构图(H图)来描述软件的体系结构。本系统的层次结构图如图4-1所示。汽车企业售后服务连锁门店管理系统的设计与实现系统管理1.0客户管理2.0服务站管理4.0客服管理3.0服务站业务处理5.0登录1.1用户管理1.2角色管理1.3退出1.4客户咨询3.1客户建议3.2客户投诉3.3客户反馈3.4预约处理5.1美容记录5.2维修记录5.3服务站业务设置4.2服务站的增删改查4.1财务统计6.0图4-1 系统结构框图各模块描述说明如下。1.0 系统管理：包括系统角色和系统用户管理以及系统登录、退出的处理。1.1 登录模块：验证用户是否为系统合法用户。1.2 用户管理：系统用户（管理员，服务站负责人、客户服务）的增删改查。1.3 角色管理：系统角色的增删改查，可扩展。1.4 退出：退出系统。2.0 客户管理：客户信息的增删改查。3.0 客服管理：受理客户咨询、建议、投诉、反馈业务。3.1 客户咨询：客户咨询信息录入、修改、删除。3.2 客户建议：客户建议信息录入、修改、删除。3.3 客户投诉：客户投诉信息录入、修改、删除。3.4 客户反馈：客户反馈信息录入、修改、删除。4.0 服务站管理 ：包括服务站的管理以及服务站业务处理。4.1 服务站增删改查：可以添加服务站、修改服务站、删除服务站。4.2 服务站业务设置：设置服务站美容、维修两个派系下的具体子业务。5.0 服务站业务处理：包括对预约、美容、维修信息的增删改查。5.1 预约记录：预约记录的添加、修改、删除。5.2 美容记录：美容记录的添加、修改、删除。5.3 维修记录：维修记录的添加、修改、删除。6.0 财务统计：可以统计用户指定时间范围内某服务站维修、美容的财务信息。在系统的模块结构图形成过程中，产生了大量的模块，在进行详细设计时开发者应为每一个模块写一份说明。IPO图就是用来说明每个模块的输入、输出数据和数据加工的重要工具。所以，与H图中每个方框相对应的还有一个IPO图，对于每个模块的IPO图，将在下章详细设计阶段加以介绍。4.2 数据库设计数据库是存储在一起的相关数据的集合，这些数据是结构化的、无害的、无不必要的冗余的，并为多种应用服务。数据的存储独立于使用它的程序；对数据库插入新数据，修改和检索原有数据均能按一种公用的和可控制的方式进行。当某个系统中存在结构上完全分开的若干个数据库时，则该系统包含一个“数据库集合”。所谓数据库是指长期存储在计算机内的、有组织的、可共享的数据集合。数据库中的数据按一定的数据模型组织、描述和存储，具有较小的冗余度、较高的数据独立性和易扩展性，并可为各种用户共享2。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求。数据库设计通常是在一个通用的DBMS支持下进行，即利用现成的DBMS为基础。在数据库领域内，常把使用数据库的各类系统称为数据库应用系统。数据库应用系统的设计包括两部分。(1)结构设计，就是设计各级数据库模式，决定数据库系统的信息内容。(2)行为设计，决定数据库系统的功能，是事务处理等应用程序的设计。根据系统的结构和行为两方面特性，系统设计开发分为两个部分，一部分是作为数据库应用系统核心和基石的数据库设计，另一部分是相应的数据库应用软件的设计开发。这两部分是紧密相关、相辅相成的，组成统一的数据库工程，如图4-2所示。设计数据库是为了解用户的各个方面需求，包括现有的及将来可能增加的需求。数据库设计按照以下几个步骤进行。(1)数据库需求分析(2)数据库概念结构设计(3)数据库逻辑结构设计(4)数据库表结构设计4.2.1 数据库需求分析针对需求分析阶段得出的系统功能需求，我们进一步分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求，考虑到将来功能上的扩展，设计如下的数据项和数据结构。(1)用户信息，包含的数据项有用户编号、用户名、密码。(2)角色信息，包含的数据项有角色编号、角色名、角色说明。(3)服务站信息，包含的数据项有服务站编号、服务站名称、服务站负责人、办公电话、服务站地址。(4)业务信息，包含的数据项有业务编号、业务名称、业务说明。4.2.2 数据库概念结构设计将用户需求分析得到用户需求抽象为信息结构即概念模型的过程就是概念结构设计。它是整个数据库设计的关键。通常我们用E-R模型来描述概念模型。本文采用自顶向下的方法来设计概念结构。总体E-R图框架如图4-2所示。各个实体的属性不再介绍，下节逻辑结构设计产生的关系模式将会详细设计每个属性，与E-R图的属性是一致的。nnnnnnnnnnmmmmmmmmnm角色用户对应客户服务站管理管理咨询预约美容维修建议投诉反馈图4-2 总体E-R图框架4.2.3 数据库逻辑结构设计概念结构是独立于任何一种数据模型的信息结构。逻辑结构设计的任务就是把概念结构设计阶段设计好的基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构。设计逻辑结构时一般要分三步走。(1)将概念结构转换为一般的关系、网状、层次模型；(2)将转换来的关系、网状、层次模型向特定DBMS支持下的数据模型转换；(3)对数据模型进行优化。系统采用SQL Server 2000支持关系模型，将在之后介绍本系统逻辑结构的设计，并把第一、二步骤合并。本系统的逻辑结构的设计过程如下。第一步，E-R图向关系模型转换。E-R图向关系模型的转换要解决的问题是如何将实体型和实体间的联系转换为关系模式，如何确定这些关系模式的属性和码。将E-R图转化为关系模型实际上就是要将E-R图的三个要素实体型、实体的属性和实体型之间的联系转换为关系模式，转换一般遵循以下原则。一个实体型转化为一个关系模式，实体的属性就是关系的属性，实体的码就是关系的码。实体型间的联系有以下几种不同情况。(1)一个1：1的联系可以转换为一个独立的关系模式，也可以与任意一端对应的干系模式合并。(2)一个1：n的联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。(3)一个m：n的联系转换为一个独立的关系模式。按照以上原则，将E-R图转换为如下的关系模型，下划线为横线的表示为关系模式的主键，波浪线为外键。 角色表（角色ID，角色名称，角色说明）用户表（用户ID，用户名，密码）用户_角色对应表（用户ID，角色ID）汽车销售表（汽车ID，汽车品牌，汽车型号，车主名，购车时间，售后服务时间）客户表（客户ID，客户姓名，身份证号，客户电话，客户地址）服务站表（服务站ID，单位名称，经理姓名，职务，办公电话，手机，E-mail，办公地址）服务站业务表（业务ID，业务名称，业务类型，业务费用）预约维修登记表（预约ID，预约客户姓名，预约维修时间，预约维修服务站，登记时间，登记人，预约状态）汽车维修记录表（维修ID，维修类别，客户姓名，汽车ID，维修站点，维修时间，维修内容，维修费用，维修状态）客户咨询表（ID，咨询客户，咨询主题，咨询内容，咨询日期，处理办法，咨询受理人，咨询受理人，客户满意度）客户建议表（ID，建议客户，建议主题，建议内容，建议日期，处理办法，建议受理人，客户满意度）客户投诉表（ID，投诉客户，投诉站点，投诉主题，投诉内容，投诉日期，处理办法，投诉受理人，客户满意度）客户反馈表（ID，反馈客户，反馈主题，反馈内容，反馈日期，反馈受理人，客户满意度）第二步，数据模型的优化。数据库逻辑设计的结果不是唯一的。为了进一步提高数据库应用系统的性能，还应该根据应用需要适当地修改、调整数据模型的结构，这就是数据模型的优化。关系数据模型的优化通常以规范化理论为指导，方法为：(1)确定数据依赖。(2)对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。(3)按照数据依赖的理论对关系模式逐一分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。(4)按照需求分析阶段得到的处理要求，分析对于这样的应用环境这些模式是否合适，确定是否要对某些模式进行合并或分解。需要注意的一点就是，并不是规范化程度越高的关系就越好。规范化程度越高，涉及多个关系模式的查询就越低效，因为连接两个或多个关系模式的属性时，系统经常进行连接运算。所以，我们需要具体问题具体分析。一般情况下，关系模式规范到第三范式即可。分析上述关系模式，没有部分依赖和传递依赖，符合第三范式。4.2.4 数据库表设计关系数据库是利用数据库进行数据组织的一种方式，是现代流行的数据库系统中应用最为普遍的一种，也是最有效率的数据组织方式之一。在关系数据库里，所有的数据都按表(关系)进行组织和管理。系统的数据库中的表格结构按照上小节的关系模式设计，在数据库中可以查看。4.3 本章小结通过本章的总体设计，更加明确了本系统需要完成的功能，并通过数据库设计完成了系统的表结构设计。为以后的详细设计乃至编码的成功实现提供了保证，也为以后数据库语句的编写提供了保证。共 39 页 第 17 页5 系统详细设计详细设计阶段详细地设