图书仓库管理系统.doc

很好的图书仓库管理系统 有需要的人可以看看吧 还行 课程设计

当然在设计应用程序时，程序设计人员是无法确定TQuery部件中的SQL 语句是否会返回一个查询结果的。对于这种情况应当用Try…Except模块来设计程序。在 Try 部分调用Open方法，而在Except部分调用ExceSQL方法，这样才能保证程序的正确运行。
Delphi中用ADOQuery来使用SQL语句同样十分方便。在ADOQuery组件中首先通过ConnectionString属性值来联接数据源，然后就通过双击SQL…属性值来写入SQL语句。在Delphi中调用数据库，就可以调用ADOQuery组件，通过修改其中的SQL…属性中的SQL语句来实现对数据库的各项操作。
值得注意的是，ADOQuery组件只有在激活的情况下才可以被正确地使用，这样就提出了一个问题，也就是说，在每次修改ADOQuery组件的SQL…属性时都必须先行进行关闭，待清除掉SQL…中所有的SQL语句后才可以添加新的SQL语句。而且，在每一次修改完成以后，还应该记得重新将ADOQuery激活。其它的使用方法与TTQuery有许多的相似之处。
§3.3 Access 简介
建立一个数据库我们有多种选择，现在市场上有各种各样的数据库，而且每一种数据库都有其自身的特点，不能说哪一种更好，只能在其中寻找一种能更好地适应系统需求、更好地满足用户的要求以及适应开发人员的习惯。在本系统中，做为图书仓库管理系统是一个比较小的应用系统，它所产生和处理的数据量也比较小。因此，没有必要使用像SQL Server和Oracle这样的大型数据库。我首先想到的数据库是Borland公司的Paradox数据库。另外，Microsoft Office中的Access数据库在计算机上的应用比较普及，是开发小型数据库系统的比较理想的选择，所以，在本系统中我选择了Access数据库。
Access做为一个数据库管理系统，它被集成在Microsoft Office中。Access数据库处理的基本结构，采取关系型数据库模式。与其他的数据库系统相比，Access更加简单易学，一个普通的计算机用户可以很快地掌握它。Access 2000的功能十分强大，利用它可以方便地实现对信息保存、维护、查询、统计、打印、交流、发布，而且它可以十分方便地与Office其他组件交流数据，这些功能对一个一般用户而言已经足够了。
第四章  系统总体设计
软件系统的总体设计大约要经历可行性分析和项目开发计划，需求分析，概要设计，详细设计，编码，测试以及维护等七个阶段。可行性分析和项目开发计划在前面已经叙述，下面所要做的是进行软件需求分析，概要设计和详细设计。编码过程将在下一节论述，而测试和维护过程不在本文叙及。
§4.1   系统需求分析
在经过前一阶段的分析之后，我确定了我的开发课题为图书仓库管理。现在所要做的是要准确定义系统必须做什么以及系统必须具备的功能。
软件需求分析中我采用结构化分析方法（Structured Analysis,简称SA），SA是面向数据流进行需求分析的方法，像所有的软件分析方法（如面向对象分析方法、IDEF方法等等）一样，SA也是一种建模活动，它使用简单易读的符号，根据软件内部数据传递、变换的关系，自顶向下逐层分解，描绘满足功能要求的软件模型。
在系统中我采用数据流图（DFD）这种半形式化的描述方式表达需求。它是一种功能模型，以图形的方式描绘数据在系统中流动和处理的过程，只反映系统必须完成的逻辑功能。它有四种基本图形符号：
◆ →：箭头，表示数据流；
◆ 〇：圆或椭圆，表示加工；
◆ ═：双杠，表示数据存储；
◆ □：方框，表示数据的源点或终点。
为了表达较为复杂问题的数据处理过程，用一张数据流图是不够的，要按照问题的层次结构进行逐步分解，并以一套分层的数据流图反映这种结构关系。在这里我一共使用了三层数据流图，即顶层图，0层图和1层图（也是底层图）。
在多层数据流图中，顶层流图仅包含一个加工，它代表被开发系统，它的输入流是该系统的输入数据了，输出流是该系统的输出数据；底层流图是指其加工不需要再做分解的数据流图，中间层流图表示对其上层父图的细化，它的每一步加工可能继续细化成子图。
经过对系统的分析首先得到系统的顶层DFD，如下： 
一步细化得到系统的0层DFD，如下：

再进一步细化每一个数据加工功能，得到系统的1层DFD图。
在这里只给出有关入库管理和出库管理的1层数据流图，它们是系统的关鍵部分，也是主要的部分。通过以上对数据流图的分析之后，我们已大体地了解了系统的功能和目标，接下来所要做的就是系统功能模块的划分和数据库的设计，也就是系统的概要设计。
§4.2   系统概要设计
在软件需求分析阶段，搞清楚了软件“做什么”的问题，形成了目标系统的逻辑模型。现在我们所要做的就是要把软件“做什么”的逻辑模型变换为“怎么做”的物理模型，即着手实现软件的需求。首先，我们需要描述的是系统的总的体系结构。
4.2.1  系统结构设计
系统的概要设计中最重要的就是系统的模块化。模块化是指解决一个复杂问题时自项向下逐层把软件系统划分成若干个模块的过程。每个模块完成一个特定的功能，所有的模块按某种方法组织起来，成为一个整体，完成整个系统所要求的功能。
 将系统划分为多个模块是为了降低软件系统的复杂性，提高可读性、可维护性，但模块的划分不能是任意的，应尽量保持其独立性。也就是说，每个模块只完成系统要求的独立的子功能，并且与其他模块的联系最少且接口简单，即尽量做到高内聚低耦合，提高模块的独立性，为设计高质量的软件结构奠定基础。
在系统的概要设计中我采用结构化设计（Structure Design，简称SD），SD以需求分析阶段产生的数据流图DFD为基础，按一定的步骤映射成软件结构。我首先将整个系统化分为几个小问题，小模块，在系统中，我设计了用户管理、库存管理、入库管理、出库管理、员工管理和供应商管理6个小模块。然后，进一步细分模块，添加细节。比如，用户管理我又将其分为用户注册、用户注销、密码修改；库存管理分为库存记录查询、库存记录修改、库存记录打印等等。
以下就是系统的结构图：（在这里为了表达方便我将结构图分开来表达。）
    在得到系统的第一层功能模块图后，经过进一步地细化，得一系统的子功能模块图：

4.2.2  数据库设计
在信息世界中，信息从客观事物出发流经数据库，通过决策机构最后又回到客观世界，信息的这一循环经历了三个领域：信息世界，数据世界，现实世界。现实世界的事物反映到人的头脑中，人的大脑对它有个认识过程，经过分析（选择、命名、分类等）进入信息世界。这些信息再进一步加工、编码，然后进数据世界，而软件系统的开发工作需要考虑这两个方面的问题，也就是要考虑系统开发所需要的数据，以及如何对这些数据进行操作。这两个问题贯穿了整个软件系统的开发过程，这也就是数据库的设计问题，软件设计的一个核心。
4.2.2.1  ER图设计
在系统设计的开始，我首先考虑的是如何用数据模型来数据库的结构与语义，以对现实世界进行抽象。目前广泛使用的数据模型可分为两种类型，一种是独立于计算机系统的“概念数据模型”，如“实体联系模型”；另一种是直接面向数据库逻辑结构的“结构数据模型”。在本系统中我采用“实体联系模型”（ER模型）来描述数据库的结构与语义，以对现实世界进行第一次抽象。ER模型直接从现实世界抽象出实体类型及实体间联系，然后用ER图来表示数据模型。它有两个明显的优点：接近于人的思维，容易理解；与计算机无关，用户容易接受。但ER模型只能说明实体间语义的联系，不能进一步说明详细的数据结构，它只是数据库设计的第一步。
ER图是直观表示概念模型的工具，它有四个基本成分：
◆ 矩形框，表示实体类型（考虑问题的对象）。
◆ 菱形框，表示联系类型（实体间的联系）。
◆ 椭圆形框，表示实体类型和联系类型的属性。对于关键码的属性，在属性名下划一横线。
◆直线，联系类型与其涉及的实体类型之间以直线连接。
本系统为图书仓库管理，主要管理图书的入库、出库以及库存等事项。仓库根据需要可以查询图书供应商的信息，同时还需要了解在入库和出库中员工的参与情况。依据仓库管理的实际情况，考虑了多方面的因素以后，确定系统的ER图如下：
（为了表达的方便，在这里我没有在一张图上表达出所有的关系，而是用一张总体ER图，和几张实体属性关系图来表达数据库的结构。）
在该数据库中，我设计了三个实体，分别是库存、员工和供应商以及两个联系类型入库和出库。在本系统中库存是核心，也是基本，没有了库存其它的也就没有什么意义了。员工记录的添加是考虑到责任问题，也就是说，在仓库管理的实际运用中，出现了责任不清的现象，特别是由于仓库的进出图书数量都比较大时产生了一系列问题，所以在设计数据库时，我特别考虑到这一点，加入了员工记录这一实体。供应商信息的添加主要出于对图书来源问题的思考。通过添加供应商信息可以比较清楚地了解图书的进货渠道，从图书的质量到供应商的信誉都可以进行了解，同时可以为以后的图书进购提供一定有用的信息。
入库联系类型将库存信息、供应商信息和员工信息联系在一起，可以方便地实现三个实体之间的联接，而出库联系类型则将库存信息和员工信息较好地联接起，同时这两个联系类型又都具有各自特有的属性。
下面就是各实体及联系类型的属性图：(带#号的属性为关键字段)4.2.2.2  数据库表格设计
在完成系统的ER图之后，需要将ER模型转化为关系模型，也就是说，要设计出数据库所需要的表格。在这里，我选用的是关系数据库。因为关系数据库中的二维表格可以很清楚地描述数据之间的联系。
在这里不得不提到一个概念——范式。其实在上一节的ER图设计中，已经运用了范式的思想，不仅如此，在数据库的表格设计中更离不开范式的思想，它是数据库设计的基础，如果不注意这个问题将会导致一系列问题的出现。
我在系统中定义的表格都严格地按照范式的思想和要求去完成，数据库中的所有表格都达到了三范式的要求。根据系统ER图，针对本系统的特点，在对所搜集的数据进行规范化之后，定义了如下六张表格，分别是库存信息表，入库信息表，出库信息表，员工信息表，供应商信息表和密码信息表。通过对这六张表格的操作可以较好地完成系统设计的各项功能，六张表格之间有着不同程度的联系。（说明：在以下数据表中，K代表主键，#代表外键，字段值不为空。）
BookRecord 表（库存信息表） 
 字段名称 数据类型 说明
K BookID 数字 图书编号
 BookName 文本 图书名
 Author 文本 作者
 Publisher 文本 出版社
 PubDate 日期/时间 出版日期
 Price 货币 价格
 BookType 文本 图书类型
 Number1 数字 库存数量
 Addation 文本 备注
图4.13  库存信息表
库存信息表主要用于记录仓库中现存放的所有图书的详细信息，包括图书编号、书名、作者、出版社、图书类型等有关图书的各类信息，它即是该数据库的主表，也是系统主界面的主要内容。
在该表中图书编号是主键，它按图书入库的先后次序来编写，每当有图书入库，系统自动给出图书编号，这样我们按图书编号来查找图书是比较方便的。考虑到编号比较难于记忆，所以使用了出版社和图书类型两个字段，在系统中我提供了出版社和图书类型的分类查找，而且全部采用自动生成，每当系统中有新的出版社类型和图书类型，弹出菜单会自动添中新类型，这样就可以比较方便地实现按出版社和按图书类型查找。此外，库存数量也是一个比较关键的字段，该字段是在系统初始化时就给定的，每当有图书入库或出库操作，系统就会自动修改图书的库存数量，以保持数据的一致性。做为备注