商品进销存管理系统设计论文--数据库设计论文

商品进销存管理系统设计论文--数据库设计论文内容摘要：

条件，确认软件测试的具体要求，定义详细的功能模块，以求达到协助系统开发的根本目的。 需求分析的原则需求分析的基本原则是：（1）需要能够表达和理解问题的信息域和功能域；（2）要能以层次化的方式对问题进行分解和不断细化；（3）要给出系统的逻辑视图和物理视图。 需求分析的一般步骤需求分析分为问题分析，需求描述，需求评审等几个步骤。 首先进行问题分析。 在该阶段，分析人员通过对问题以及环境的理解、分析和综合，清除用户需求的模糊性、歧义性和不一致性，并在用户的帮助下对互相冲突的要求进行折中，并为原始问题及其软件解建立模型。 它是形成需求规格说明、进行软件设计与实现的主要基础，例如面向数据流的分析方法、面向对象的分析方法以及面向数据的分析方法都属于需求建模方法。 接着进入需求描述阶段，以需求模型为基础，考虑到问题的软件可解性，生成规格说明和初步的用户手册。 总结需求分析的步骤为：（1）通过对现实化境的调查研究，获得当前系统的具体模型；11（2）去掉具体模型中的非本质因素，抽象出当前系统的逻辑模型；（3）分析当前系统与目标系统的差别、建立了目标的逻辑模型；（4）对目标进行完善和补充，并写出完整的需求说明；（5）对需求说明进行复审，直到确认文档齐全，并且符合用户的全部需求为止。 在本系统中需求分析的基本上步骤也是按照以上三个阶段进行的。 在任何的需求分析的一般步骤都必须遵守以上的步骤。 系统业务流程分析 业务流程图使用的基本符号业务流程图的符号如下图所示。 （1）业务处理的部门或单位。 它表达了某项业务参与的人或物。 （2）数据存储或文档，也是一种数据的载体，但这个数据是作为档案来保存的。 （3）业务数据流动及方向，它表达了业务数据的流动方向，这个方向用双箭头表示。 （4）各类文档、数据，它表明了数据的载体。 （5）业务功能描述，表明了业务处理功能，一般用一个简单的祈使句表示。 业务处理单位 存档 业务数据流动 文档、数据 业务功能描述或部门 及方向 图 业务流程图使用的符号12 进销存管理业务流程图开始数据期初设置及预警设置订货单销售开单入库登记入库红冲进货退货销售红冲销售退货应付款 应收款营业日终结算终合查询结束进销存信息系统流程图 系统数据流图分析 数据流程图图形符号在数据流程图所涉及到的一个主要符号用以下的图来表示。 数据来源和数据输出都可以用圆形表示。 在本系统中主要是用的圆形。 13P 0数据处理数据存储S 1E 1 数据来源F 1 输入数据流E 2 数据输出F 2 输出数据流 图 数据流图相关符号表示 系统功能的提出根据详细的需求分析，明确系统的功能如下：（1）员工基本信息管理：主要完成职工基本信息的管理，如员工基本信息的添加、修改、删除和查询；（2）员工考勤信息的管理：主要完成职工考勤信息的管理。 管理员工基本信息的考勤添加、修改、删除和考勤信息的查询；（3）员工评价信息管理：主要完成员工评价信息的管理，管理员工基本工作信息的添加好、修改和查询；（4）员工工资信息管理：主要完成员工工资信息的管理，主要是进行员工工资信息的添加、修改、删除和查询；（5）数据库管理部分：主要完成数据库的管理与维护；（6）系统管理部分：主要是完成用户的添加、密码信息的修改等。 数据字典数据字典是各类数据描述的集合，它是进行详细的数据收集和数据分析后所获得的主要成果。 数据字典通常包括一下 5 个部分：（1）数据项。 数据项是不可再分的数据单位。 （2）数据结构。 数据结构反映了数据之间的组合关系。 一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。 14（3）数据流。 数据流是数据结构在系统你传输的路径。 （4）数据存储。 数据存储是数据及其结构停留或保存的地方，也是数据流的来源和去向之一。 （5）处理过程。 处理过程的具体处理逻辑一般用判定表或判定树来描述。 数据字典是关于数据库中数据的描述，即对元数据的描述。 数据字典是在需求分析阶段建立，在数据库设计过程中不断修改、充实和完善的。 第三章 数据库设计第三章 数据库设计 数据库设计概述数据库设计是建立数据库及其应用系统的技术，是信息系统开发和建设中的核心技术，具体说，数据库设计是指对于一个非定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效的存储数据，满足各种用户的应用需求。 合理的数据库结构设计可以提高数据存储的效率，保证数据的完整和一致性。 另外，合理的数据库结构将非常有利于程序的实现。 数据库设计的一般性原则 数据库设计的一般性原则如下所示：第一个基本原则：对于每一个要存储其信息的实体（或事物） ，我们都应该给他一个自己的表；第二个处理规则：如果需要在一个列里存储多个值，那证明你的设想是有缺陷的。 简单的数据关系：一对一；一对多；多对一；多对多。 在数据库的设计中，要做到数据规范化、完整性、数据冗余和规范实例化。 数据库设计的步骤数据库设计分五个阶段：(1)规划；(2)需求分析；(3)概念结构设计；(4)逻辑结构设计；数据库物理设计。 16 数据库概念结构设计数据库概念设计的目标就是要产生反映企业组织信息需求的数据库概念结构，即概念模型。 概念模型概念模型是独立于数据库逻辑结构，独立与支持数据库的 DBMS，不依赖于计算机系统的。 概念模型是表达概念设计结果的工具。 它应该能够真实、充分的反映现实世界中事物和事物直接的联系；应该简洁、明晰、独立于机器，容易理解，方便数据库设计人员和应用人员进行交流；应该易于变动，便于修改；应该很容易向关系、层次或网状等各种数据模型转变，方便的导出与 DBMS 有关的逻辑模型。 从而使概念模型成为现实世界到机器世界的一个过度的中间层次。 概念模型有很多模型，其中最常用的方法之一是“实体—联系模型”（entity relationship model）,即使用 ER 图来描述某一组织的概念模型。 ER 图ER 模型是指直接从现实世界中抽象出实体类型及实体间联系，是一种描述静态数据结构的概念模型。 它的主要成分是实体、联系和属性。 可利用 ER模型进行数据库概念设计。 ER 图是直观表示概念模型的工具，在图中有四个基本成分如图：矩形框：表示实体类型（考虑问题的对象） ；菱形框：表示联系类型（实体间的联系） ；椭圆形框：表示实体类型和联系类型的属性；直线：联系类型与涉及的实体类型之间以直线连接，并在直线上标上联系的种类（1：1，1：N，M:N）。 具体图示如下：17实体 联系属性 系统 ER 图设计商品 客户供货商进货销售条码货号 拼音编码拼音编码供货商号名称名称 拼音编号客户编号PQNM 数据库与逻辑结构设计 逻辑结构设计设计的任务是把概念结构设计阶段设计完毕的基本 ER 图转化为与选用的具体机器上的 DBMS 产品所支持的数据模型相符的逻辑结构（包括数据库模式和外模式）。 这些模式在功能性、完整性和一致性约束及数据库的可扩充性等方面应满足用户的各种需求。 ER 图型关系模型的转化要解决的问题是如何将实体和实体间的关系转化为关系模式，如何确定这些关系模式的属性和代码。 数据表结构清单在这个系统中，设计了一个名为 Purchaseandsale 的数据库。 根据系统功能的需要，在其中总共设计了 6 个数据表，分别如下：18Product 表 用于存储产品的基本信息以及相关的库存数量；Supplier 表 用于存储供应商的基本信息；Customer 表 用于存储客户的基本信息；Users 表 用于存储系统用户的基本信息；Purchase 表 用于存储采购记录的基本信息；Sale 表 用于存储销售记录的基本信息。 Product 数据表结构Product 数据表主要用于存储企业的产品或原料信息，比如物品的名称、产地、 、规格、单位等。 另外，根据销售记录和采购记录计算得出的每种商品的库存数量也存放在 Product 数据表的库存字段中。 Product 数据表的结构如下表所示。 Product 数据表结构字段名 数据类型 长度 是否允许为空 说明商品名称 Nvarchar 255 否 主键，唯一标识产品记录产地 Nvarchar 40 是规格 Nvarchar 50 是包装 Nvarchar 50 是单位 Nchar 19 是库存 Int 4 是 产品的库存量，系统计算得出，默认为 0 数据表结构Supplier 数据表主要用于存储企业的供应商信息，比如供应商的编号、供应商的名称、供应商的联系地址、联系方式、开户银行和银行账号等。 Supplier 数据表的结构如下表所示。 Supplier 数据表结构字段名 数据类型 长度 是否允许为空 说明供应商简称 Nvarchar 10 否 主键，唯一标识供应商记录19供应商全称 Nvarchar 100 是 供应商单位全称地址 Nvarchar 100 是邮政编码 Nchar 6 是电话 Numeric 9 是传真 Numeric 9 是联系人 Nvarchar 30 是联系人电话 Numeric 9 是开户银行 Nvarchar 10 是银行账号 Numeric 13 是企业网址 Nvarchar 50 是 Customer 数据表结构Customer 数据表主要用于存储企业的客户信息，比如客户编号、客户的名称、客户的地址、联系方式、开户银行和银行账号等。 Customer 数据表的结构如下表所示：Customer 数据表结构字段名 数据类型 长度 是否允许为空 说明客户简称 Nvarcher 10 否 主键，唯一标识客户记录客户全称 Nvarcher 100 是 客户单位全称地址 Nvarcher 100 是邮政编码 Nchar 6 是电话 Numeric 9 是传真 Numeric 9 是联系人 Nvarcher 30 是联系人电话 Nvarcher 9 是开户银行 Nvarcher 100 是银行账号 Numeric 13 是企业网址 Nvarcher 50 是20 Users 数据表结构Users 数据表主要用于存储本系统的用户信息，包括用户的名称和系统登陆密码。 Users 数据表的结构如下图所示：字段名 数据类型 长度 是否允许为空 说明用户 Nvarchar 10 否 主键，唯一标识系统用户密码 nvarchar 10 是 用户密码，可以为空 Purchase 数据表结构Purchase 数据表主要用于存储企业的采购信息，比如采购商品的名称、价格、供应商编号、采购数量、采购日期、经手人等。 Purchase 数据表的结构如下表所示。 Purchase 数据表结构字段名 数据类型 长度 是否允许为空 说明商品名称 Nvarcher 255 否 外键，对应 Product 表中商品说明数量 Int 4 否 每笔采购记录必须有采购数量进价 Money 8 否 每笔采购记录必须有采购进价金额 Money 8 是 由数量和进价计算得出备注 Nvarcher 220 是供应商 Nvarcher 10 否 外键，对应 Supplier 表日期 Smalldatetime 4 否 每笔采购记录必须有采购时间经手人 Nvarcher 10 否 外键，对应 User 表票号 Nvarcher 50 否 每笔采购记录必须有唯一的票号 Sale 数据表结构Sale 数据表主要用于存储企业的销售信息，比如销售商品的名称、价格、21客户编号、销售数量、销售日期、经手人等。 Sale 数据表的结构如下表所示：Sale 数据表结构字段名 数据类型 长度 是否允许为空 说明商品名称 Nvarcher 255 否 外键，对应 Product 表数量 int 4 否 每笔采购记录必须有采购数量单价 Money 8 否 每笔采购记录必须有采购进价金额 Money 8 是 由数量和进价计算得出备注 Nvarcher 220 是客户 Nvarcher 10 否 外键，对应 Customer 表日期 smalldatetime 4 否 每笔采购必须有采购时间经手人 Nvarcher 10 否 外键，对应 User 表票号 Nvarcher 50 否 每笔采购记录必须有唯一的票号 各数据表的关系实际进销存业务中的一些数据是在多个业务活动中共享的，比如采购单中的商品必须在 Product 数据表中有相关记录，所以在本案例中也对上述的 6 个数据表设置了对应关系。 具体关系主要表现在一下几个方面：采购单，销售单中的经手人必须是企业中的合法员工，本案例中要求经手人必须是在 Users 数据表中有相应的记录；采购单、销售单中的产品必须在 Product 数据表中有相关记录。 如果采购一种新商品，必须先在 Product 数据表中增加这种商品的信息；采购单中的供应商必须是 Supplier 数据表中有相应的记录。 如果采购中发展了新的供。