通用查询器的设计与实现论文.doc

xx大学毕业设计(论文) 第 IV 页

毕 业 论 文

论文题目
通用查询器的设计

与实现
学生姓名

学生学号

专业班级

学院名称

指导老师

学院院长

年5月20日

通用查询器的设计与实现
摘 要
随着计算机技术的发展，软件变得越来越复杂，软件的开发也变得越来越困难。人们发现，根据以往的开发模式，要在控制的时间和成本内，开发出高质量的软件产品，几乎是不可能的。于是人们想到了各种各样的方法来进行改进。软件重用无疑是这些方法中最重要的方法之一。通过软件重用，人们不仅可以利用标准化的软件模块快速构建特定的应用程序，而且可以在开发软件时使用以前开发的，已经验证过的没有错误的模块，从而极大的提高软件产品的生产效率，减轻开发人员的工作强度和开发成本。
本文在深入分析查询语句的组成结构的基础上，设计和实现了一个通用查询器。该通用查询器由数据描述，模板管理，数据查询，多语言接口等部分组成。数据描述允许用户通过自己角度说明数据表和字段；模板管理使用户能够重用以前的查询条件；数据查询则根据用户输入，动态生成SQL语句，进行数据查询；多语言接口则使程序界面可以用不同的语言进行显示。
通用查询器采用独立的模块化设计和基于XML文件的数据存储方式，以动态的方式根据用户输入生成SQL语句。这样保证了通用查询器的可移植性，可维护性，使其能够作为一个组件与各个信息系统进行集成，是对软件组件级重用的一次有益尝试。
最后对通用查询器进行了测试。测试结果表明，通用查询器完全能够根据用户输入，动态生成正确的SQL语句，并将用户需要的数据显示给用户，完成了数据查询的功能。但是在其与其它信息系统集成上，还有待进一步进行验证。

关键字：软件重用，组件，MVC结构，N层，SQL语句

The Design and Implementation of Common Query
Abstract

Along with the development of computer technology, software become more and more complex, and the development of software become more and more difficult. Software developers find that according to past development method, it is impossible to create a high quality software production within defined time and cost. So developers think out many methods to improve software development process and software quality. Software reuse is absolutely one of the most important methods. Software reuse improve the efficiency of software development greatly, and reduce the development time and cost.
According to the analysis of the structure of SQL query sentence, this paper introduces the design and implement of common query. This common query is made up of four parts, data description, modules management, data query, and multilanguage interface. These four parts allow user to describe data table and field, to use templates created before, to search useful data.
The common query is created as a module, and use XML files to store data, create SQL sentence dynamic. With them, the common query is easy to transplant and maintenance, and is easy to build into other information system. It is a very good attempt of software reuse.
At the end, we test it. The results show that the common query can create correct SQL query sentence according to user’s input, and give useful data to user who need it. As to working with other information system, it need further confirm.

Key Words: software reuse，module，MVC architecture，N-tier，SQL sentence

目 录

第一章 绪 论 1
1.1 课题研究背景 1
1.2 软件复用的概念和现状 2
1.2.1 软件复用的概念 2
1.2.2 软件复用的现状 2
1.3 论文组织结构 3
第二章 组件设计目标及策略 4
2.1 组件设计目标和要求 4
2.2 系统分析 4
2.3 功能划分 5
2.3.1 数据描述模块 6
2.3.2 模板管理模块 6
2.3.3 数据查询模块 6
2.3.4 多语言接口模块 7
2.4 总结 7
第三章 组件开发方案 8
3.1 体系结构 8
3.1.1 两层或三层体系结构 8
3.1.2 N层体系结构 9
3.1.3 组件形式 10
3.2 系统开发环境与开发模型 10
3.2.1 开发环境 10
3.2.2 开发模型 11
3.3 总结 11
第四章 组件设计与实现 12
4.1 通用查询器自身数据的设计 12
4.1.1 字段关联的设计 12
4.1.2 模版的设计 13
4.2 功能模块的设计 14
4.2.1 数据描述模块 14
4.2.2 模板管理 16
4.2.3 数据查询模块 17
4.2.4 多语言接口 20
4.3 系统环境 20
4.4 总结 20
第五章 组件设计与实现的关键技术 21
5.1 基于XML文件的数据存储 21
5.1.1 问题的产生 21
5.1.2 基于XML文件的数据存储 21
5.2 SQL查询语句的动态生成 22
5.2.1 问题的产生 22
5.2.2 SQL查询语句的动态生成 23
5.3 总结 23
第六章 结束语 25
参考文献 26
致 谢 27
附录 主要源程序 28

xx大学软件学院
大学毕业设计(论文) 第 31 页
第一章 绪 论
1.1 课题研究背景

软件工程从1968年第一次在国际会议上提出来[1]，到现在已经发展了近40年了。经过这40年的研究与实践，软件开发方法和技术方面有了已经有了很大的进步，但是，软件危机仍然没有得到彻底解决[2]。软件开发的效率非常低下，而成本却非常高昂。软件开发人员被迫不断应付变幻莫测的需求，无穷无尽的Bug，痛苦不堪的后期维护。软件项目开发往往超过预期的时间和成本范围，甚至有很多项目因此而失败。据美国专家标准技术研究员的一份报告显示，占据世界软件销售额85％的大型软件，其开发失败率却高达70％[3]。如何才能提高软件开发的效率，减少开发人员的工作量，提高开发项目的成功率呢？
软件重用(Software Reuse)，是解决这个问题的一个重要途径。通过软件重用，开发人员可以像开发硬件产品一样，在构件库中查找需要的构件，进而使用它们快速的构建需要的软件，极大地减少了开发人员的开发工作量。通过软件重用，开发人员可以选用在以前项目中测试过的没有错误的构件，避免将新的错误带入到项目中，减少项目的测试成本，同时又增加了软件的健壮性。通过使用软件重用，软件的后期维护变得更为简单：当需求发生变化或者软件产生错误时，仅仅需要更换其对应的软件构件就可以了，而不用影响软件的其它部件甚至软件的整体构架。
总而言之，通过软件复用，可以充分利用已有的各项成果，避免重复劳动，增加技术积累，提高软件水平，加快开发速度，保证开发质量，这对于项目管理部门是极为重要的[4]。

1.2 软件复用的概念和现状

1.2.1 软件复用的概念
软件复用(Software Reuse)起源于软件开发的最初阶段。当开发人员将一段代码从一段程序拷贝到另一段程序的时候，他们就开始了软件复用。
软件复用思想的正式提出是在1968年。在1968年的北大西洋公约组织(NATO)会议上，Mcllroy第一次提出了可复用库的思想，说明软件复用思想的产生。而后在1983年，Freeman又进一步拓广了软件重用的概念[5]。经过了这些年的发展，软件复用不再仅仅是代码之间的拷贝，而是形成了一整套可重用软部件的管理体系。
软件复用是指重复的使用为了重用目的而设计的软件的过程，包括为重用而进行开发和使用重用进行开发两方面[6]。这个定义说明软件的复用远远不是重复使用那样简单。
首先，这里所说的软件并不单指代码，而应包括在软件开发过程中所产生的各种产品：代码，二进制程序，设计文档，测试用例，体系架构等等。这些都可以作为可重用的软部件。
其次，软件的复用包括创建可复用软部件和使用可复用软部件两部分。创建可复用软部件就是在进行软件开发时，对于那些将来可以重用的软部件要进行特殊的设计，实现和测试，并且在开发完成后，对这些软部件要进行标识，分类，收集，存储，为将来的重用做准备。使用可复用软部件时，要对已经收集的软部件进行查找，分析，裁减，以确保软部件适应新系统的需要。
因此，软件复用是以一个可重用软部件库为中心的管理体系，将合适的可重用软部件放入库中，并从库中选取合适的软部件构建新系统。
1.2.2 软件复用的现状
目前，软件复用在软件开发领域得到了广泛的应用。
在代码级复用方面，很多软件开发语言都编写了丰富的例程库，开发人员只需要调用这些例程库的方法，就可以完成相当多的功能，大大减轻了开发人员的开发工作量。并且这些例程库还在不断的扩大，丰富。
在组件级重用方面，目前有相当多的学者和开发人员在研究和使用。国内外很多规模较大的软件公司都建立了以公司为单位的可重用软部件库。目前，在使用的组件主要分为两大类：一种是微软公司推出的ActiveX，一种是SUN公司推出的JavaBean。ActiveX已经做到操作系统级兼容，即在Windows视窗系统下运行，支持Windows视窗系统的各类开发工具。而JavaBean在所有支持Java的平台上都可以运行[7]。在研究方向上，目前也分为两种：一种是组件模型标准化研究，主要体现为CORBA，COM/DCOM，JavaBean；另一种事基于组件的软件开发方法的研究，软件生产线是基于组件开发方法中的一个研究热点[8]。
作为对软件复用中组件级复用的尝试，目前也有些人在研究通用查询器。例如，舒红平和刘魁为管理信息系统(MIS)设计的通用查询组件[9]，王红霞，石岗和蒋玉玲用ASP.Net设计的通用查询器[10]，张晖和何瑞春在“哈密铁路分局机关局域网”上应用的通用查询器[11]，等等。这些查询器或者是基于Java，或者是基于.Net；或者是C/S模式，或者是B/S模式。它们都应用在了实际的项目中，并且取得了很好的效果。但是纵观他们的设计，都只考虑到查询的各种可能性，要么缺少对多种数据库的支持，要么缺少可扩展性，无法进行裁减，这些都影响了其通用性。

1.3 论文组织结构

论文全文共分六章。第一章：绪论，简要介绍软件复用的基本概念，软件复用和通用查询器目前的研究现状。第二章：组件设计目标及策略。通过提出组件设计目标及策略。根据组件分析对组件进行功能划分，并对各个功能模块的需求进行了详细分析。第三章：组件开发方案。本章通过对组件可选择的开发模型进行的分析与比较，选择基于MVC的四层构架。并确定了组件开发使用的技术方案，同时也进一步确定了组件具体的开发环境以及开发模型。第四章：组件设计与实现。详细阐述了组件自有数据类型的设计，分析、介绍了组件的各个功能模块的设计，最后简要描述了系统的实现。第五章：组件设计与实现的关键技术。论述了组件分析与设计中所使用的关键技术和方法。第六章：结束语。总结了组件开发工作并对未来的工作进行展望。

第二章 组件设计目标及策略
本章首先提出通用查询器组件的设计目标，并根据目标对组件进行分析，依照分析，得到了组件的功能结构及功能划分，通过对数据描述，模版管理，数据查询，多语言界面，多数据库支持等的详细分析，简要描述了系统的基本流程。

2.1 组件设计目标和要求

考虑到通用查询器是作为一个组件，应该方便的与各种信息系统进行集成，通用查询器应满足一下目标或要求：
1，可移植性：通用查询器应该满足多种不同信息系统的需要，可以在各个不同的信息系统之间进行移植。
2，实时性：当用户确认查询后，通用查询器应该能够很快的显示查询结果。
3，国际化支持：通用查询器应该能够显示多种语言。
4，可裁减性：通用查询器应该能够进行裁减，以更好适应不同的信息系统。
5，可用性：通用查询器应该能够引导用户方便输入查询条件，而不是直接的SQL查询语句。

2.2 系统分析

考虑到通用查询器作为一个可以重用的组件，程序完成后，能完成基本的查询操作；可以与其它信息系统方便的进行集成；能够显示不同的语言；能够对不同的数据库进行支持；能方便用户输入查询条件；用户能对它方便的进行配置。
对大部分使用信息系统的用户来说，数据库中的表和列之类的信息是无法理解的，因此在用户输入查询条件时应对其进行引导，尽量采用用户熟悉的方式进行。由于通用查询器其接受输入和显示输出都是在自己的界面上进行，而且配置信息都是采用自己的文件存储，与和它集成的信息系统关系不大，因此在外部接口方面目前可以暂不考虑，可以留待下一版本开发。由于与之集成的信息系统环境各不相同，界面语言，数据库系统都不尽相同，通用查询器应该可以支持多种数据库和多语言显示。为了适应不同的信息系统，通用查询器应容易修改，因此要采用比较开放的结构。为了不依赖特定的数据库，增强其移植性，组件自身所需要的数据应独立存储。
数据描述
数据查询
模板管理
根据分析，得到组件的拓扑结构图，如图2-1所示：

通用查询器

多语言接口

图2-1 系统拓扑结构图

2.3 功能划分

通
用
查
询
器
数据描述
在上述拓扑结构图的基础上，对组件进行进一步分析，对各功能模块进行更详细的划分，得到组件的功能层次结构图，如图2-2所示：
数据初始化

表描述

字段描述

条件模版管理

模板管理

显示模版管理

生成SQL语句

数据查询
显示结果

语言文件扫描

多语言接口

界面显示

图2-2 组件功能层次结构图
从组件的功能结构图看，通用查询器共分为四个模块，分别是数据描述模块，模版管理模块，数据查询模块，多语言接口模块。下面分别详细阐述各模块的具体功能：
2.3.1 数据描述模块
数据描述模块是从用户的角度对数据库中的表和字段进行描述。由于在数据库中，表名称和字段名称都是用英文表示，不利于普通用户的理解和使用。因此设计这个模块来允许用户从自己的角度来重新定义表和字段的各种含义。
数据描述包括对表的描述和对字段的描述。在表的描述中，对于不同的表，不能有相同的描述。对字段的描述包括对字段含义的描述和字段关联性的描述。字段的关联性描述允许将某一表的某一个字段与另一个表的另一个字段相关联，对应于数据库中表的外键。正是由于表外键的存在，不同的两个列可以表示相同的数据，因此可以拥有相同的描述。
2.3.2 模板管理模块
模版分为条件模版和显示模版。条件模版是在用户输入查询条件时使用的，显示模版是向用户返回查询结果是使用的。通过模版的管理，用户可以方便的使用以前用过的模版，减少用户使用的工作量。
模版的信息以数据表为基础，模版的信息来自数据表，并且没有经过用户描述的数据表不能为模版提供基础。模版的标识ID要能够唯一标识模版，因此标识ID不允许有重复。同一个表为基础的模版不允许有相同的名称。不同的模版允许拥有完全相同的模版信息。显示模版和条件模版属于不同的模版类型，其标识ID统一处理，其它信息均分开处理。对同一个表的显示模版和条件模版可以分别设置和取消设置默认模版。
2.3.3 数据查询模块
数据查询模块允许用户根据条件模版添加，修改，删除查询条件。接受用户输入的查询条件后，程序根据输入，条件模版和显示模版动态的生成SQL查询语句，进行数据的查询。获取数据后，根据显示模版将结果返回给用户。
要查询的数据表必须有显示模版和条件模版，否则不能进行查询；数据表具有默认显示模版时，查询结果自动按默认显示模版显示，否则将提示用户选择显示模版。查询模块根据数据描述时字段的关联信息支持一级子查询，不支持多级子查询。用户没有输入查询条件时，将按条件模版查询表中的所有数据。
2.3.4 多语言接口模块
多语言接口模块主要是提供多语言支持，供用户选择适合自己的语言，并同时修改程序界面和提示，出错信息。
多语言接口模块默认提供中文支持。在没有其它语言文件时将显示中文界面。

2.4 总结

在这一章中，我们首先考虑了通用查询器作为一个查询组件应该满足的一些基本需求。从这些需求出发，我们对通用查询器的功能范围进行概括，并对功能模块进行了划分和设计。在下一章中，我们将根据这章确定的需求和功能模块来思考通用查询器的实现方案和整体架构。

第三章 组件开发方案
本章通过对组件可选择的几种开发技术方案进行分析和比较，选择了基于MVC的四层模型进行开发，通过对组件的两种技术方案进行简单的比较，确定了组件的开发技术方案，以及开发环境。

3.1 体系结构

虽然通用查询器只是一个简单的数据库查询组件，也没有复杂的业务逻辑，但是良好的分层结构，有利于组件今后进行裁减和修改，为后面的重用打下良好的基础。这里的层次体系结构与基于大型应用的C/S，B/S网络体系层次有一定的区别。这里的层次体系结构是指通用查询器组件内部的层次结构，没有考虑数据库这一层。层次结构可以分为两层或三层，N层。
3.1.1 两层或三层体系结构
两层体系结构指通用查询器整个组件只有表现层和业务层两层。表现层为用户界面，负责接受用户的各种输入并负责向用户返回查询结果，而业务层则是界面的后台类，它包括了从判断用户输入，到执行业务逻辑，到完成数据访问的所有功能。
两层体系结构的层次简单，容易设计，能够很快上手进行编码实现。但是这种简单的设计隐藏着很大的局限。
(1)逻辑混乱，不容易理解。在一个界面的后台类里面，没有将业务逻辑和表达逻辑分开[12]。在后台类代码里面，哪些负责显示数据，哪些执行业务逻辑，哪些执行数据访问，它们的调用关系怎样，这些都非常不清晰。其它程序员很难理解代码的含义。
(2)不易修改和扩展。由于大量代码堆积在一个后台类里面，当需要修改某个功能或者要增加对新数据库的支持时，要对整个代码做大量修改，甚至可能要修改整个程序的所有代码，这对整个开发项目来说是个巨大的灾难。
这样的程序维护性和扩展性很差，无法根据不同的信息系统进行修改和裁减，也无法作为一个可重用组件去适应各种不同的信息系统。
而三层体系结构将业务层分为了业务逻辑层和数据访问层，在两层体系结构的基础上有了很大的提高。但是业务逻辑层仍然包括了对用户数据的分析和业务逻辑的执行，还是存在两层体系结构的巨大局限性。
3.1.2 N层体系结构
N层体系结构是在三层体系结构的基础上发展起来的。与著名的MVC架构结合后，N层体系结构将三层结构中的业务逻辑层进一步划分为控制层和业务逻辑层。这样就形成了基于MVC体系的四层构架：
(1)表现层：即为组件的用户界面，负责接受用户的输入并且向用户返回各种输出。
(2)控制层：即为用户界面的后台类。一方面负责对用户的输入进行判断：当用户的输入合法时，根据其输入类型的不同，调用不同的业务逻辑模块执行功能；当用户输入不合法时，返回提示信息。另一方面，负责将业务逻辑模块执行的结果传递给表现层。
(3)业务逻辑层：为单独的类。负责接受控制层传递过来的用户输入，并执行一定的功能。需要时调用不同的数据访问模块访问各种数据库，获取数据。执行完成后将执行结果返回给控制层。
(4)数据访问层：为单独的类。负责接受业务罗基层传递过来的参数，访问特定的数据库，进行数据操作。并将执行结果返回给业务逻辑层。
通过这四层的划分，分离了程序的表现，控制和数据，具有设计清晰，可扩展，可维护，以及较高的交互性等特点[13]。当需要对组件功能进行修改时，仅仅需要修改业务逻辑层的部分代码即可。当需要增加对新数据库的支持时，只要在数据访问层添加相应模块，并在业务逻辑层添加对其的调用就行了。
这样的设计做到了高内聚低耦合，能够满足作为一个可重用组件的要求。因此通用查询器的设计就采用基于MVC的四层体系架构。
3.1.3 组件形式
使用基于MVC的四层体系架构实现通用查询器，其两种方法可供选择：一种是做成组件式的dll文件形式，另一种是做成独立的应用程序。
(1)组件式的dll形式
做成组件式的dll形式，最适合通用查询器，因为其本身就是作为一个查询组件来进行设计实现的。这样很容易被加载集成到其它的信息系统中。
但是在当前的环境下，缺乏与之集成的信息系统。作为一个单独的dll文件，其本身无法运行，我们无法对其进行调试修改。其开发过程将变得非常困难。
(2)单独的应用程序
做成单独的应用程序，应该说是不附合通用查询器作为一个组件的设计的。虽然这样设计还是可以与其它信息系统进行集成。但是其它信息系统在使用时，将启动一个新的进程来执行，这样相比于dll形式将消耗更多的系统资源。
但是，在现在的情况下，单独的应用程序更加方便我们的开发调试。当发现问题时，我们能够更加快速的修改。
通过权衡之后，决定在当前的版本中采用开发成单独应用程序的形式，先确保通用查询器的功能能够正常执行，在以后的版本中再将其转化成dll的形式。

3.2 系统开发环境与开发模型

通用查询器采用基于MVC的四层架构作为体系结构，设计做成一个单独的应用程序，其开发环境和开发模型可以进一步具体化。
3.2.1 开发环境
操作系统：Windows XP系统专业版(集成SP2)
集成开发环境：微软Visual Studio 2005
开发语言：C#
数据库：Oracle 10g (目前仅支持Oracle数据库，下一版本将加入SQL Server数据库)
3.2.2 开发模型
组件开发的基于MVC的四层架构体系如图3-1所示：

数据库
数据
访问
层
业务
逻辑
层
控
制
层
表
现
层

图3-1 通用查询器体系结构

在整个体系中，表现层为程序界面，接受用户输入并显示查询结果；控制层对用户输入进行合法性判断，并根据输入的不同调用不同的功能；业务逻辑层负责完成具体的功能；数据访问层则完成对数据的操作。这样通过对业务逻辑层的修改，可以完善已有功能，增加新功能；通过对数据访问层的扩展，可以增加对不同数据库的支持。这样可以在程序维护时将影响减少到最低。

3.3 总结

在这一章里，我们根据通用查询器的特点，选取了几个比较流行的系统架构进行比较。通过展示它们之间的优缺点，结合通用查询器易裁减，易移植的特点，选取了基于MVC的四层架构作为其体系结构，并确定暂时将通用查询器设计成单独的程序。体系结构的确定为后面的实现奠定了良好的基础。下一章，我们将讨论具体的数据结构和业务逻辑的设计。

第四章 组件设计与实现
本章从第二章组件设计目标中所确定的各功能模块出发，详细论述了通用查询器组件自身使用数据的设计，以及各主要功能模块的设计，最后简要论述了系统的实现。

4.1 通用查询器自身数据的设计

显示模版列表

用户ID：PK
表描述：PK
模版名：PK
模版ID
是否默认模版
条件模版列表

用户ID：PK
表描述：PK
模版名：PK
模版ID
是否默认模版
模版列表

模版ID：PK
字段名：PK
数据表列表

表名：PK
表描述
字段关联列表

主字段表名：PK
主字段名：PK
关联字段表名
关联字段名
显示字段名
显示字段描述
关联类型
字段描述列表

表名：PK
字段名：PK
数据类型
字段关联
字段描述
虽然通用查询器作为一个数据库查询组件，其大部分数据都是直接来自信息系统数据库，但是它自身也需要存储一部分数据，比如用户对表和字段的描述，用户建立的条件模板和显示模版等，为用户更好的使用查询器提供了便利。下面就通用查询器自身所使用的数据进行说明。

图4-1通用查询器E-R图

4.1.1 字段关联的设计
在一般的数据库中，表与表之间通过外键来进行关联是很常见的事。通过表与表之间相同的字段进行关联，外键可以将不同的表联系起来，在数据级保持数据的一致性，完整性和安全性。
为了实现表与表之间字段的关联，我们专门设计了一张表来存储字段的关联信息，那就是字段关联列表。如图4-1所示，字段关联列表(ColumnAsso)含有七个属性，描述主字段的属性两个，用来唯一确定主字段；描述关联字段的属性两个，用来唯一确定关联字段；描述显示字段的属性两个，用于数据查询和结果显示；描述关联类型的属性一个。
如果在条件模版中某个字段发生了关联，那么SQL语句的生成将产生很大的变化。在查询语句中，程序不会在使用关联中的主字段，而会去查找并使用关联字段，将用户输入的主字段的条件转移给关联字段，并使得主字段和关联字段相等。比如说，t1表的c1字段关联了t2表的c2字段，用户输入的条件包含c1>1。那么此时，在“select”子句和“from”子句都不会有t1表和c1字段，而会以t2表和c2字段代替，即为“select t2.c2 from t2”。而在“where”子句中，也将不会有“t1.c1>1”，而会用“t2.c2>1”代替，并且加上“and t1.c1=t2.c2”来保证两个字段之间的关联。
通过这样的设计，比较好的实现了模拟数据库中表与表的关联，并且通过在生成SQL查询语句时字段的替代，较好的实现了在表与表之间存在关联的情况下的一级子查询，增强了查询功能。
4.1.2 模版的设计
在通用查询器中，模版分为条件模版和显示模版。条件模版表示在用户输入查询条件时要使用的字段的集合，存储在条件模版列表(CondTempalate)中。显示模版表示在向用户显示查询结果时需要使用的字段的集合，存储在显示模版列表(DispTempalate)中。而模版所包含的字段则存储在模版列表(Tempalate)中。模版是用户进行数据查询的基础，没有模版将无法查询。而通过使用模版，用户可以减少查询的步骤，减少工作量。
由于条件模板和显示模版在数据结构的设计上是完全一样的，只是使用时用途不同。在此就仅以条件模版为例，来说明模版的设计情况。
模版是以数据库中的某一个表为基础的，而且只有经用户描述过的表才能建立模版。模版中所有的字段都只能来自那张基础表，不能来自其它表，这样确保了每个模版的独立性。如图4-1所示，条件模版包含五个属性，用户ID表示创建者；表描述是指用户对作为模版基础的表的描述；模版名是指创建者为模版指定的名字，在以同一个表为基础的所有模版中，模版名不能出现重复；模版ID是一个用程序逻辑保证的自增一的数，可以用来唯一确定一个模版，该ID在所有的条件模板和显示模版中都是唯一的；默认模版确定模版是否是指定默认。模版列表则包含两个属性，所在的模版ID和字段名称。
模版的使用逻辑也很简单。在界面上，通过用户的点击就可以确定模版名和模版所在数据表的描述。由于数据表描述具有唯一性，由数据表描述可以获取数据表名；由模版名和表描述可以获取模版ID；由于模版ID的唯一性，可以由ID获取模版包含的字段名；有数据表名和字段名就可以唯一确定数据表中的某一列了。
通过这样的设计，特别是将模版信息和其所包含的字段集合分开存储，减少了数据的冗余程度，使各个表的功能相对独立，表与表的关系相对清楚。虽然在XML文件里，这种外键的关联没有其它系统来保证数据的一致性和完整性，但是通过精心设计的业务逻辑功能，完全可以由通用查询器本身来保证。

4.2 功能模块的设计

在这一节，将详细讨论通用查询器组件确定的各个模块及其逻辑。在第二章，通过对通用查询器的分析，我们将整个组件分为数据描述，模版管理，数据查询，多语言接口四个模块。这里将详细讨论这四个模块的逻辑和流程。
4.2.1 数据描述模块
数据描述模块主要是允许用户通过自己的角度对数据表和字段进行描述。在用户更好的理解数据表和字段的含义时，为他们使用通用查询器提供便利。该模块主要包含三个功能：数据初始化，表描述，字段描述。
(1)数据初始化
数据初始化是根据用户选择，先一步将有关表和字段的信息存储起来，为后面的表描述和字段描述做好准备。其逻辑伪程序如下：
begin
if(选择的字段的个数为0吗)
提示“没有选择要描述的字段”
else
if(选择的表已经存在描述)
提示“是否重新描述？”
if(用户选择是)
删除TableDesc中对应表的记录
删除ColumnDesc中对应选定字段的记录
插入TableDesc选定表的记录
插入ColumnDesc中选定字段的记录
end
end
end
(2)表描述
表描述允许用户通过自己的角度对数据表的含义进行描述。其逻辑伪程序如下：
begin
检查用户输入的描述是否已经用于其它表
if(是)
提示“同一描述不能用于不同表”
else
用用户的输入更新TableDesc表
end
(3)字段描述
字段描述允许用户通过自己的角度对字段的含义进行描述。
其逻辑非常简单，直接用用户输入更新ColumnDesc表。这里就不用伪程序描述了。
4.2.2 模板管理
通过模版，用户可以很方便的使用以前使用过的查询条件和显示方法，减少了用户使用通用查询器的工作量。模版管理包括条件模版和显示模版的管理，每个管理又包含了模版的增，删，改三种操作。这里仅以条件模版为例来说明，显示模版的操作和条件模版完全一样。
(1)创建模版
创建模版允许用户将经常使用的查询条件保存成模版，方便今后的使用。其逻辑的伪程序如下：
begin
用户是否从可选字段中选择了模版的字段
if(是)
提示用户输入模版名
检测模版名是否已经存在
if(是)
提示是否更新原有模版
if(是)
删除Tempalate表中对应模版的所有字段
将用户选择的字段加入Tempalate表
end
else
将新模版信息加入CondTempalate表
将用户选择的字段加入Tempalate表
else
提示用户没有选择模版字段
end
(2)修改模版
修改模版允许用户对原有模版进行修改，以适应新需要。其逻辑流程伪程序如下：
begin
用户是否从可选字段中选择了模版字段
if(是)
删除Tempalate表中对应模版的所有字段
将用户选择的字段加入Tempalate表
else
提示用户没有选择模版字段
end
(3)删除模版
删除模版允许用户将不用的模版删除掉。
其逻辑流程非常简单，只是从CondTempalate表中删除对应模版的信息，从Tempalate表中删除该模版对应的所有字段的信息。
4.2.3 数据查询模块
数据查询模块允许用户添加，修改，删除查询条件，并进行数据查询。
(1)添加查询条件
用户可以将自己的查询条件提交给程序，其逻辑流程伪程序如下：
begin
检查查询条件信息是否完整
if(是)
检查查询条件与前面条件的关系是否正确
if(正确)
检查子条件的开始结束是否匹配
if(是)
将查询条件加入到条件列表
else
提示子条件开始与结束不匹配
else
提示关系不正确，请修改
else
提示输入信息不完整
end
(2)修改查询条件
用户可以对已经提交的查询条件进行修改，其逻辑流程伪程序如下：
begin
检测用户是否选择要修改的条件
if(是)
检测修改后的信息是否完整
if(是)
检查子条件的开始结束是否匹配
if(是)
按用户输入修改条件列表中相应条件信息
else
提示子条件开