仓库管理系统.doc

毕 业 设 计（论文）

题 目： 仓库管理系统

专 业： 信息工程系

摘 要
本系统主要完成对图书仓库的库存管理，包括图书入库、出库、库存，员工信息，供应商信息以及密码管理等六个方面。系统可以完成对各类信息的浏览、查询、添加、删除、修改、报表等功能。
系统的核心是入库、库存和出库三者之间的联系，每一个表的修改都将联动的影响其它的表，当完成入库或出库操作时系统会自动地完成库存的修改。查询功能也是系统核心之一，在系统中即有单条件查询和多条件查询，也有精确查询和模糊查询，系统不仅有静态条件查询，也有动态条件查询，其目的都是为了方便用户使用。系统有完整的用户添加、删除和密码修改功能。
系统采用Microsoft Office中的Access 2000来设计数据库，并使用当前优秀的开发工具—Delphi 6.0 ，它有着最为灵活的数据库结构，对数据库应用有着良好的支持。
论文主要介绍了本课题的开发背景，所要完成的功能和开发的过程。重点的说明了系统设计的重点、设计思想、难点技术和解决方案。

关键字：数据库，Delph 6，数据库组件，仓库管理

目 录
第一章 引言 ……………………………………………………………………………5
1.1 课题来源 …………………………………………………………………………5
1.2 开发工具的选择 …………………………………………………………………5
1.3 所做的主要工作 …………………………………………………………………6
第二章 数据库概论 ……………………………………………………………………6
2.1 数据库理论基础 …………………………………………………………………9
2.1.1 数据库模型…………………………………………………………………9
2.1.2 数据库体系结构 ………………………………………………………10
2.1.3 数据的独立性 ……………………………………………………………11
2.1.4 范式 ………………………………………………………………………11
2.2 SQL语言基础 ……………………………………………………………………12
2.2.1 SQL查询 ………………………………………………………………12
2.2.2 SQL数据更新 …………………………………………………………13
第三章数据库开发工具 ………………………………………………………………13
3.1 Delphi 6.0 简介 ………………………………………………………………14
3.2 Delphi 6.0 控件 ………………………………………………………………14
3.2.1 ADO数据访问组件 ………………………………………………………14
3.2.2 数据控制类DataControl ……………………………………………15
3.2.3 数据访问类DataAccess ……………………………………………15
3.2.4 SQL语言在Delphi中的应用 …………………………………………16
3.3 Access 简介 …………………………………………………………………17
第四章 系统总体设计 ………………………………………………………………17
4.1 系统需求分析 …………………………………………………………………17
4.2 系统概要设计 …………………………………………………………………18
4.2.1 系统结构设计 …………………………………………………………18
4.2.2 数据库设计 ……………………………………………………………18
4.3系统详细设计 ……………………………………………………………………21
第五章 系统应用程序设计 ……………………………………………………………22
5.1 入库、出库窗体模块的实现………………………………………………………25
5.2 查询功能的实现……………………………………………………………………31
5.3 系统登陆窗体模块的实现…………………………………………………………31
5.4 用户管理功能的实现………………………………………………………………32
5.4.1 密码修改窗体模块的实现 ……………………………………………32
5.4.2 用户注销窗体模块的实现 ………………………………………………34
结束语 ……………………………………………………………………………………59
致谢 ………………………………………………………………………………………60
参考文献 …………………………………………………………………………………61

第一章 引 言
§1.1 课题来源
随着社会经济的迅速发展和科学技术的全面进步，计算机事业的飞速发展，以计算机与通信技术为基础的信息系统正处于蓬勃发展的时期。随着经济文化水平的显著提高，人们对生活质量及工作环境的要求也越来越高。书籍做为人类的精神食粮，在现代社会中越来越受到重视，大量的书籍出现在市场上，人们有了各种各样不同的选择。与此同时，为了管理大量的图书，图书仓库也大量的出现，仓库的管理问题也就提上了日程。随着图书的大量增加，其管理难度也越来越大，如何优化仓库的日常管理也就成为了一个大众化的课题。
在计算机飞速发展的今天，将计算机这一信息处理利器应用于仓库的日常管理已是势必所然，而且这也将为仓库管理带来前所未有的改变，它可以带来意想不到的效益，同时也会为企业的飞速发展提供无限潜力。主要体现在：
极大提高了仓库工作人员的工作效率，大大减少了以往入出存流程繁琐，杂乱，周期长的弊端。
基于仓库管理的全面自动化，可以减少入库管理、出库管理及库存管理中的漏洞，可以节约不少管理开支，增加企业收入。
仓库的管理的操作自动化和信息的电子化，全面提高了仓库的管理水平。
通过对仓库管理日常工作的详细调查，搜集了大量的资料，从系统结构的组织，功能的实现，技术的要求以及可行性等多方面进行考虑，认为本课题是一个适应现今图书仓库管理需求的计算机信息管理系统，具有一定的实际开发价值和使用价值。
§1.2 开发工具的选择
现在，市场上可以选购的应用开发产品很多，流行的也有数十种。目前在我国市场上最为流行、使用最多、最为先进的可用作企业级开发工具的产品有：
Microsoft公司的Visual Basic 6.0版
Microsoft公司的Visual C++6.0版
Borland公司的Delphi 6.0版
Delphi 6 是可视化的快速应用程序开发语言，它提供了可视化的集成开发环境，这一环境为应用程序设计人员提供了一系列灵活而先进的工具，可以广泛地用于种类应用程序设计。在Delphi 6 的集成开发环境中，用户可以设计程序代码、运行程序、进行程序错误的调试等，可视化的开发方法降低了应用程序开发的难度。
§1.3 本文所做工作
引言部分介绍了本系统的课题来源以及对数据库开发工具的选择。
第二章介绍了数据库的发展，关系数据库，数据库体系结构，并系统介绍了SQL语言，为设计和理解应用程序做了铺垫。
第三章系统介绍了Delphi 6.0及其部分控件，SQL语言在Delphi 6.0中的应用，以及Access等。
第四章是本文的主体，按照软件工程的要求，从需求分析开始，经过概要设计最后到详细设计，完成对整个系统的设计。
第五章根据第四章的设计结果利用Access 2000和Delphi 6.0进行了具体的窗体和应用程序设计。
总结部分介绍了设计体会和编程体会，并指出了系统设计中的不足和改进的方向。
§2.1数据库理论基础
2.1.1 数据库模型
模型是对现实世界的抽象。在数据库技术中，我们用模型的概念描述数据库的结构与语义，对现实世界进行抽象，表示实体类型及实体间联系的模型称为“数据模型” 。
目前广泛作用的数据模型可分为两种类型。
一种是独立于计算机系统的模型，完全不涉及信息在系统中的表示，只是用来描述某个特定组织所关心的信息结构，这类模型称为“概念数据模型” 。
另一种数据模型是直接面向数据库的逻辑结构，它是现实世界的第二层抽象。 这类模型涉及到计算机系统和数据库管理系统，又称为“结构数据模型” 。
（1）层次模型。
层次模型的特点是记录之间的联系通过指针实现，查询效率较高。但层次模型有两个缺点：一是只能表示1∶N联系，虽然有多种辅助手段实现了M∶N联系，但都较复杂，用户不易掌握，二是由于树型结构层次顺序的严格和复杂，引起数据的查询和更新操作也很复杂，因此，编写应用程序也很复杂。
（2）网状模型。
网状模型的特点：记录之间联系通过指针实现，M∶N联系也容易实现（每个M∶N联系可拆成两个1∶N联系），查询效率较高。网状模型的缺点是编写应用程序比较复杂，程序员必须熟悉数据库的逻辑结构。
（3）关系模型。关系模型的主要是用二维表格结构表达实体集，用外键表示实体间联系。关系模型是由若干个关系模式组成的集合。关系模式相当于前面提到的记录类型，它的实例称为关系，每个关系实际上是一张二维表格。
关系模型和网状、层次模型的最大区别是：关系模型用表格数据而不是通过指针链来表示和实现实体间联系。关系模型的数据结构简单、易懂。只需用简单的查询语句就可对数据库进行操作。
（4）面向对象模型。目前，关系数据库的使用已相当普遍，但是，现实世界中仍然存在着许多含有复杂数据结构的应用领域，例如，CAD数据、图形数据等，而关系模型在这方面的处理能力就显得力不从心。因此，人们需要更高级的数据库技术来表达这类信息。面向对象的概念最早出现在程序设计语言中，随后迅速渗透到计算机领域的每一个分支。面向对象数据库是面向对象概念与数据库技术相结合的产物。
2.1.2 数据库体系结构
数据库的体系结构分三级：内部级（internal）,概念级（conceptual）和外部级（external）。这个三级结构有时也称为“三级模式结构”，或“数据抽象的三个级别”，最早是在1971年通过的DBTG报告中提出，后来收入在1975年的美国ANSI/SPARC报告中。虽然现在DBMS的产品多种多样，在不同的操作系统支持下工作，但是大多数系统在总的体系结构上都具有三级模式的结构特征。从某个角度看到的数据特性称为“数据视图”（data view）。
外部级最接近用户，是单个用户所能看到的数据特性。单个用户使用的数据视图的描述称为“外模式”。
概念级涉及到所有用户的数据定义，是全局的数据视图。全局数据视图的描述称为“概念模式”。
内部级最接近于物理存储设备，涉及到实际数据存储的结构。物理存储数据视图的描述称为“内模式”。
数据库的三级模式结构是数据的三个抽象级别。它把数据的具体组织留给DBMS去做，用户只要抽象地处理数据，而不必关心数据在计算机中的表示和存储，这样就减轻了用户使用系统的负担。
三级结构之间往往差别很大，为了实现这三个抽象级别的联系和转换，DBMS在三级结构之间提供两个层次的映象（mappings）:外模式/模式映象，模式/内模式映象。此处模式是概念模式的简称。
2.1.3 数据的独立性
由于数据库系统采用三级模式结构，因此系统具有数据独立性的特点。在数据库技术中，数据独立性是指应用程序和数据之间相互独立，不受影响。数据独立性分成物理数据独立性和逻辑数据独立性两级。
（1）物理数据独立性
如果数据库的内模式要进行修改，即数据库的存储设备和存储方法有所变化，那么模式/内模式映象也要进行相当的修改，使概念模式尽可能保持不变。也就是对内模式的修改尽量不影响概念模式，当然，对于外模式和应用程序的影响更小，这样，我们称数据库达到了物理数据独立性。
（2）逻辑数据独立性
如果数据库的概念模式要进行修改，譬如增加记录类型或增加数据项，那么外模式/模式映象也要进行相应的修改，使外模式尽可能保持不变。也就是对概念模式的修改尽量不影响外模式和应用程序，这样，我们称数据库达到了逻辑数据独立性。
现有关系系统产品均提供了较高的物理独立性，而对逻辑独立性的支持尚有欠缺，例如，对外模式的数据更新受到限制等。
2.1.4 范式
建立起一个良好的数据指标体系，是建立数据结构和数据库的最重要的一环。一个良好的数据指标体系是建立DB的必要条件，但不是充分条件。我们完全可以认为所建指标体系中的一个指标类就是关系数据库中的一个基本表，而这个指标类下面的一个个具体指标就是这个基本表中的一个字段。但如果直接按照这种方式建库显然还不能算最佳。对于指标体系中数据的结构在建库前还必须进行规范化的重新组织。
在数据的规范化表达中，一般将一组相互关联的数据称为一个关系(relation)，而在这个关系下的每个数据指标项则被称为数据元素(data element)，这种关系落实到具体数据库上就是基本表，而数据元素就是基本表中的一个字段(field)。
在对表的形式进行了规范化定义后，数据结构还有五种规范化定义，定名为规范化模式，称为范式。在这五种范式中，一般只用前三种，对于常用系统就足够了。而且这五种范式是“向上兼容”的，即满足第五范式的数据结构自动满足一、二、三、四范式，满足第四范式的数据结构自动满足第一、二、三范式，……，依此类推。
第一范式(first normal form，简称1st NF)就是指在同一表中没有重复项出现，如果有则应将重复项去掉。这个去掉重复项的过程就称之为规范化处理。在本文所讨论的开发方法里，1st NF实际上是没有什么意义的。因为我们按规范化建立的指标体系和表的过程都自动保证了所有表都满足1st NF。
第二范式(second normal form，简称 2nd NF)是指每个表必须有一个(而且仅一个)数据元素为主关键字(primary key)，其它数据元素与主关键字一一对应。例如，在图l9.7中如果我们将合同号定义为主关键字(其它数据元素中的记录数据都有可能重名，故不能作为主关键字)，故只要知道了一个合同记录的合同号，就可以唯一地在同一行中找到该合同的任何一项具体信息。通常我们称这种关系为函数依赖(functional depEndence)关系。即表中其它数据元素都依赖于主关键字，或称该数据元素唯一地被主关键字所标识。
第三范式(third normal form，简称 3rd NF)就是指表中的所有数据元素不但要能够唯一地被主关键字所标识，而且它们之间还必须相互独立，不存在其它的函数关系。也就是说对于一个满足了 2nd NF的数据结构来说，表中有可能存在某些数据元素依赖于其它非关键宇数据元素的现象，必须加以消除。
§2.2 SQL语言基础
2.2.1 SQL查询
数据查询是关系运算理论在SQL语言中的主要体现，SELECT 语句是SQL查询的基本语句，当我们在对一个数据库进各种各样的操作时，使用的最多的就是数据查询，在以SQL为基础的关系数据库中，使用的最多的就是SELECT查询语句。
SELECT语句的完整句法如下：
SELECT 目标表的列名或列表达式序列
FROM 基本表和（或）视图序列
[WHERE 行条件表达式]
[GROUP BY 列名序列]
[HAVING 组条件表达式]
[ORDER BY列名 [ASC│DEAC]…]
2.2.2 SQL数据更新
使用数据库的目的是为了有效地管理数据，而数据的插入、删除和修改则是必不可少的一个功能。在本系统中就大量地使用了数据插入、删除和修改这三种操作，现做一个简单地介绍。
●数据插入
往数据库的基本表中插入数据使用的是INSERT语句，其方式有两种：一种是元组值的插入，另一种是查询结果的插入。在本系统中使用的是前一种方式，其句法如下：
INSERT INTO 基本表名（列表名）VALUES（元组值）
●数据删除
往数据库的基本表中删除数据使用的是DELETE语句，其句法如下：
DELETE FROM 基本表名 [WHERE 条件表达式]
在些作一点说明，删除语句实际上是“SELECT * FROM 基本表名 [WHERE 条件表达式]”和DELETE操作的结合，每找到一个元组，就把它删除。此外，DELETE语句只能从一个基本表中删除元组，WHERE子句中条件可以嵌套，也可以是来自几个基本表的复合条件。
●数据修改
当需要修改基本表中元组的某些列值时，可以用UPDATE语句实现，其句法如下：
UPDATE基本表名
SET列名=值表达式[，列名=值表达式…]
[WHERE条件表达式]
在Delphi中使用SQL语句是很方便的，一般来说，都是通过TQuery组件来使用SQL语言的。有一点要进行说明，虽然通过TQuery组件来使用SQL语言很方便，但考虑到自己对不同组件的理解程度、个人习惯以及其它各个方面，在本系统中我采用的是ADO组件来对数据库进行操作。最简单的方法比如在TADOQuery组件的SQL属性中就可以键入SQL语句，至于详细的使用方法在后面进行介绍。
第三章 数据库开发工具
§3.1 Delphi 6.0 简介
Delphi类可以粗略地分成两部分：一部分是组件类，这些组件类通常以某种方式出现在组件面板上，当用户从组件面板上点取一个类的图标后，在程序中就自动生成了该类的对象（非可视组件除外）；另一部分是功能类，这此功能类的对象通常出现在程序代码中，起着不可代替的作用，但是这些功能类在组件面板上是找不到的。在Delphi中，每一个类的祖先都是Tobject类,整个类的层次结构就像一棵倒挂的树，在最顶层的树根即为Tobject类。这样，按照面向对象编程的基本思想，就使得用户可用Tobject类这个类型代替任何其它类的数据类型。实际上在Delphi的类库中，Tobject类派生出了为数相当众多的子类，它们形成了一个庞大的体系，通常情况下，如果不自行开发组件，就不必了解整个类的体系结构，只用到类层次树的叶结点就足够了。
窗口组件类是窗口化的可视化组件类，在Delphi的类库中占有最大的份额。在实际编程中，窗口组件类的对象都有句柄，可以接受输入焦点和包含其它组件。
图形组件与窗口组件并列，是另一大类组件。图形组件不是基于窗口的，因而不能有窗口句柄，不能接受输入焦点和包含其它组件。从图8-43中可以看出，图形组件的基类是TgraphicControl,在实际编程中，它们必须寄生于它们的宿主——窗口组件类的对象，由它们的拥有者负责其显示，而且它们还能触发一些和鼠标活动相关的事件。图形控件最典型的例子是Tlabel和TspeedButton。由此可以看出图形组件的功能很弱，有读者会问图形组件的用处何在呢？其实使用图形组件的最大好处在于节省资源，正是因为它们的功能较弱，所以使用的系统资源就要少。在一个应用程序中，如果能在不影响其功能的前提下合理大量地使用图形组件，将会大减少程序对系统资源的消耗。
非可视组件是与可视组件相并列的另一类组件，非可视组件在程序运行中是不可见的（除各种对话框组件之外，事实上有人认为对话框组件不能归入非可视组件，应该是另一种介于可视与非可视之间的组件）。
§3.2 Delphi 6.0 控件
用Delphi6开发数据库应用，重点是和各种数据库组件打交道，当然也要使用其它的一些组件，现在就我在系统设计中所使用的重要组件给与简单介绍。
3.2.1 ADO数据访问组件
ADO数据对象(Active Data Objects)实际是一种提供访问各种数据类型的链接机制。ADO设计为一种极简单的格式，通过ODBC的方法同数据库接口中，可以使用任何一种ODBC数据源，即不止适合于SQL Server、Oracle、Access等数据库应用程序，也适合于Excel表格、文本文件、图形文件和无格式的数据文件。ADO是基于OLE-DB之上的技术，因此ADO通过其内部的属性和方法提供统一的数据访问接口方法。ADO使您的客户端应用程序能够通过OLE DB提供访问和操作在数据库服务器中的数据。ADO支持用于建立C/S和Web的应用程序的主要功能。其主要优点是易于使用、高速度、低内存支出和占用磁盘空间较少。ADO同时具有远程数据服务(RDS)功能，通过RDS可以在一次往返过程中实现将数据从服务器移动到客户端应用程序和Web页、在客户端对数据进行处然后将更新结果返回服务器的操作。
利用ADO数据访问组件，可以只使用ADO结构与数据库取得联系并对其中的数据进行操作，而在这些过程中完全不需要使用BDE。大多数的ADO连接和数据集组件都是与基于BDE的连接和数据集组件相类似的。TADOConnection组件与基于BDE的应用程序中的Tdatabase组件类似。TADOTable与Ttable，TADOQuery与Tquery，以及TADOStoreProc和TstoredProc之间都具有这种类似的对应关系。使用这些ADO组件的方式与我们常使用的数据访问组件（基于BDE）都有许多相同之处。TTADODataSet没有直接的BDE对应组件，但它提供了许多与Ttable和Tquery相同的功能。同样，TADOCommand也没有相对应的BDE组件，它是在Delphi/ADO环境中完成特定功能的组件。Delphi 6.0通过ADO数据集访问组件，可以不借助BDE数据引擎而是通过微软的OLEDB来访问更为广泛的数据库中的数据。ADO数据集访问组件与常用的数据访问组件是并列的关系。
在系统中我主要使用的是ADOTablet和ADOQuery两个组件。
3.2.2 数据控制类DataControl
数据控制类负责数据库数据的显示，并把用户对数据的修改传回。这里的绝大多数组件，如DBText, DBEdit, DBMemo, DBImage, DBListBox, DBComboBox, DBCheckBox, DBRadioGroup, DBLookupListBox, DBLookupCombox, DBCtrGrid的功能和对应的非数据感知组件相同，如TEdit框，TRadioGroups单选按钮组等，只不过在显示数据库数据时要用而已。
在系统中主要使用数据网格控件DBGrid和数据库导航器控件DBNavigator。
3.2.3 数据访问类DataAccess
数据库应用系统中数据访问是一个首要问题，包括单用户和 C/S系统，都必须联系
Tdatabase：当一个基于BDE的数据库应用程序需要一个永久数据库连接时，需要定制向一个数据库服务器的连接时，需要事务控制和特殊的数据库别名时就得用到Tdatabase对象。特别是当连接到一个远程的SQL数据库服务器时，如果要利用BDE进行数据库事务处理，那么，TDatabase对象的威力就体现出来了。在一个应用程序中为每一个数据库连接显示的声明Tdatabase对象要根据需要而定，不是必需的。对一个数据库连接，如果没有显示的声明并实例化TDatabase对象，系统就会产生一个带有默认属性的TDatabase对象。
TdataSource对象用于在DataSet对象（包括Tquery,TstoredProc,Ttable等）和数据感知组件之间提供一个连接的纽带，以便在窗体上显示数据库中的数据，在数据库中导航定位与编辑数据集中的数据。如果一个DataSet对象中的数据想在数据感知组件中显示和修改，它就必须和TdataSource对象相联系。同样，一个数据感知组件如果想和数据源相联系以便显示和操纵数据，就必须以TDataSource对象为中介。
用Delphi6作数据库应用开发概括来说如下：先利用数据存取组件和实际的数据库建立连接，并用Tsession对象和Tdatabase对象管理这些连接。然后以Tdatasource对象为中介，用数据感知组件向用户显示数据库的内容并接受用户的查询和修改等操作。
3.2.4 SQL语言在Delphi中的应用
在Delphi中使用SQL语言非常方便，一般来说，都是通过Tquery组件来使用SQL语言的。可以在TQuery组件的SQL属性中设置SQL语句。设计程序时，在该组件的属性对话框中选择SQL属性，单击带省略号的按钮，就可以打开String List Editor对话框，然后我们就可以在对话框中添加SQL语句。还可以使用Delphi的SQL Builder来自动生成SQL语句，这样可以避免手工编写SQL而可能造成的语法错误。
静态SQL语句在程序设计时便已固定下来，它不包含任何参数和变量。
动态SQL语句，也被称作参数化的语句，在其中间包含着表示字段名或表名的参数，例如下面的语句是一条动态SQL语句：
Select * From Students Where StudentCode =: StudentCode;
其中的变量StudentCode便是一个参数变量，它由一个冒号引导，在程序运行过程中，必须要为该参数赋值，该条SQL语句才能正确执行，每次运行应用程序时可以为该参数变量赋予不同的值。为参数赋值有三种方法：
①根据参数在SQL语句中出现的顺序，设置TQuery部件的Params属性值为参数赋值。
②直接根据SQL语句中各参数的名字，调用ParamByName方法来为各参数赋值。
③将TQuery部件的DataSource属性设置为另一个数据源，这样将另一个数据源中与当前TQuery部件的SQL语句中的参数名相匹配的字段值赋给其对应的参数。利用这种方法也能实现所谓的连接查询，创建主要—明细型数据库应用。
在程序运行过程中，要想设置TQuery部件的SQL属性，必须首先调用Close方法，关闭TQuery部件，然后再调用Clear方法清除SQL属性中现存的SQL命令语句， 最后再调用Add方法为SQL属性设置新的SQL命令语句。例如：
Query1.Close {关闭Query1)
Query1.SQL.Clear {清除SQL属性中的SQL命令语句}
Query1.SQL.Add(‘Select * From Students‘);
Query1.SQL.Add(‘ Where Name ="Lucy" ‘);
在为TQuery部件设置SQL属性时调用Close方法总是很安全的，如果TQuery部件已经被关闭了，调用Close方法时不会产生任何影响。在应用程序中为SQL属性设置新的SQL 命令语句时，必须要调用Clear方法以清除SQL属性中现存的SQL命令语句，如果不调用Clear方法，便调用Add方法向SQL属性中设置SQL命令语句，那么新设置的SQL命令语句会追加在现存SQL命令语句后面， 在程序运行时常常会出现出乎意料的查询结果甚至程序无法运行下去。
在这里要特别注意的，一般情况下TQuery部件的SQL属性只能包含一条完整的SQL语句，它不允许被设置成多条SQL语句。当然有些数据库服务器也支持在TQuery部件的SQL属性中设置多条SQL语句，只要数据库服务器允许这样，我们在编程时可以为 SQL 属性设置多条SQL语句。
在为TQuery部件设置完SQL属性的属性值之后，也即编写好适当的SQL程序之后，可以有多种方式来执行SQL程序。
在设计过程中，设置完TQuery部件的SQL属性之后将其Active属性的值置为True， 这样便可以执行SQL属性中的SQL程序，如果应用中有与TQuery部件相连的数据浏览部件( 如TDDGrid TDBEdit等)那么在这些数据浏览部件中会显示SQL程序的执行结果。
在应用程序运行过程中，通过程序调用TQuery部件的Open方法或ExecSQL 方法可以执行其SQL属性中的SQL程序。Open方法和ExecSQL方法是不一样的。Open方法只能用来执行SQL语言的查询语句(Select命令)， 并返回一个查询结果集，而ExecSQL方法还可以用来执行其它常用的SQL语句(如INSERT, UPDATE, DELETE等命令)，例如：
Query1.Open (这样会返回一个查询结果集)
如果调用Open方法，而没有查询结果时，会出错。此时应该调用ExecSQL 方法来代替Open方法。如：
Query1.ExecSQL (没有返回结果)
当然在设计应用程序时，程序设计人员是无法确定TQuery部件中的SQL 语句是否会返回一个查询结果的。对于这种情况应当用Try…Except模块来设计程序。在 Try 部分调用Open方法，而在Except部分调用ExceSQL方法，这样才能保证程序的正确运行。
Delphi中用ADOQuery来使用SQL语句同样十分方便。在ADOQuery组件中首先通过ConnectionString属性值来联接数据源，然后就通过双击SQL…属性值来写入SQL语句。在Delphi中调用数据库，就可以调用ADOQuery组件，通过修改其中的SQL…属性中的SQL语句来实现对数据库的各项操作。
§3.3 Access 简介
Access做为一个数据库管理系统，它被集成在Microsoft Office中。Access数据库处理的基本结构，采取关系型数据库模式。与其他的数据库系统相比，Access更加简单易学，一个普通的计算机用户可以很快地掌握它。
第四章 系统总体设计
软件系统的总体设计大约要经历可行性分析和项目开发计划，需求分析，概要设计，详细设计，编码，测试以及维护等七个阶段。可行性分析和项目开发计划在前面已经叙述，下面所要做的是进行软件需求分析，概要设计和详细设计。编码过程将在下一节论述，而测试和维护过程不在本文叙及。
§4.1 系统需求分析
在经过前一阶段的分析之后，我确定了我的开发课题为图书仓库管理。现在所要做的是要准确定义系统必须做什么以及系统必须具备的功能。
软件需求分析中我采用结构化分析方法（Structured Analysis,简称SA），SA是面向数据流进行需求分析的方法，像所有的软件分析方法（如面向对象分析方法、IDEF方法等等）一样，SA也是一种建模活动，它使用简单易读的符号，根据软件内部数据传递、变换的关系，自顶向下逐层分解，描绘满足功能要求的软件模型。
在系统中我采用数据流图（DFD）。它是一种功能模型，以图形的方式描绘数据在系统中流动和处理的过程，只反映系统必须完成的逻辑功能。它有四种基本图形符号：
◆ →：箭头，表示数据流；
◆ 〇：圆或椭圆，表示加工；
◆ ═：双杠，表示数据存储；
◆ □：方框，表示数据的源点或终点。
在多层数据流图中，顶层流图仅包含一个加工，它代表被开发系统，它的输入流是该系统的输入数据了，输出流是该系统的输出数据；底层流图是指其加工不需要再做分解的数据流图，中间层流图表示对其上层父图的细化，它的每一步加工可能继续细化成子图。
§4.2 系统概要设计
在软件需求分析阶段，搞清楚了软件“做什么”的问题，形成了目标系统的逻辑模型。现在我们所要做的就是要把软件“做什么”的逻辑模型变换为“怎么做”的物理模型，即着手实现软件的需求。首先，我们需要描述的是系统的总的体系结构。
4.2.1 系统结构设计
系统的概要设计中最重要的就是系统的模块化。模块化是指解决一个复杂问题时自项向下逐层把软件系统划分成若干个模块的过程。每个模块完成一个特定的功能，所有的模块按某种方法组织起来，成为一个整体，完成整个系统所要求的功能。
将系统划分为多个模块是为了降低软件系统的复杂性，提高可读性、可维护性，但模块的划分不能是任意的，应尽量保持其独立性。也就是说，每个模块只完成系统要求的独立的子功能，并且与其他模块的联系最少且接口简单，即尽量做到高内聚低耦合，提高模块的独立性，为设计高质量的软件结构奠定基础。
4.2.2 数据库设计
在信息世界中，信息从客观事物出发流经数据库，通过决策机构最后又回到客观世界，信息的这一循环经历了三个领域：信息世界，数据世界，现实世界。现实世界的事物反映到人的头脑中，人的大脑对它有个认识过程，经过分析（选择、命名、分类等）进入信息世界。这些信息再进一步加工、编码，然后进数据世界，而软件系统的开发工作需要考虑这两个方面的问题，也就是要考虑系统开发所需要的数据，以及如何对这些数据进行操作。这两个问题贯穿了整个软件系统的开发过程，这也就是数据库的设计问题，软件设计的一个核心。
ER图设计
在系统设计的开始，我首先考虑的是如何用数据模型来数据库的结构与语义，以对现实世界进行抽象。目前广泛使用的数据模型可分为两种类型，一种是独立于计算机系统的“概念数据模型”，如“实体联系模型”；另一种是直接面向数据库逻辑结构的“结构数据模型”。
ER图是直观表示概念模型的工具，它有四个基本成分：
◆ 矩形框，表示实体类型（考虑问题的对象）。
◆ 菱形框，表示联系类型（实体间的联系）。
◆ 椭圆形框，表示实体类型和联系类型的属性。对于关键码的属性，在属性名下划一横线。
◆直线，联系类型与其涉及的实体类型之间以直线连接。
入库联系类型将库存信息、供应商信息和员工信息联系在一起，可以方便地实现三个实体之间的联接，而出库联系类型则将库存信息和员工信息较好地联接起，同时这两个联系类型又都具有各自特有的属性。
在完成系统的ER图之后，需要将ER模型转化为关系模型，也就是说，要设计出数据库所需要的表格。
BookRecord 表（库存信息表）
字段名称 数据类型 说明
K BookID 数字 图书编号
BookName 文本 图书名
Author 文本 作者
Publisher 文本 出版社
PubDate 日期/时间 出版日期
Price 货币 价格
BookType 文本 图书类型
Number1 数字 库存数量
Addation 文本 备注
库存信息表主要用于记录仓库中现存放的所有图书的详细信息，包括图书编号、书名、作者、出版社、图书类型等有关图书的各类信息，它即是该数据库的主表，也是系统主界面的主要内容。
Shopkeeper 表（供应商信息表）
字段名称 数据类型 说明
K ShopkeeperID 数字 供应商编号
ShopkeeperName 文本 供应商姓名
Address 文本 地址
PostNo 数字 邮编
OfficePhone 文本 办公电话
HomePhone 文本 住宅电话
Email 文本 E-mail
PayType 文本 付款方式
供应商信息表主要用于记录有关供应商的各类信息，包括姓名、地址、电话、付款方式等。它主要用来为系统提供供应商的有关信息，在系统中入库记录是与供应商记录相联系的，通过入库记录可以查找相关的供应商信息。
InRecord 表（入库信息表）
字段名称 数据类型 说明
K InID 数字 入库编号
# BookID 数字 图书编号
# EmployeeID 数字 员工编号
# ShopkeeperID 数字 供应商编号
Number 数字 入库数量
BuyDate 日期/时间 入库日期
OutRecord 表