公司信息查询系统课程设计

东莞理工学院机械学院《数据库及其应用》

课程设计

2015-2016 第一学期

题目：公司信息管理系统数据库课程设计

*组员同学请按学号为序

指导教师：董敬然

目录第一章设计目标

1.1 用户调查

1.2 问题范围与边界

1.3 功能规划（*影响窗体设计）

第二章概念设计

2.1 业务细节描述

2.2 概念设计过程（参阅课堂练习）

第三章逻辑设计

3.1 ER模型转为关系模型

3.2 范式检查

第四章物理设计

4.1数据表设计

4.2数据完整性约束设计

实体完整性（主键）

域完整性（数据类型、范围）

用户定义的完整性（有效性规则）

参照完整性（外键及表关系）

4.3查询设计（*支持窗体设计和查询设计）

4.4窗体设计（*影响查询设计）

4.5报表设计（*影响查询设计）

4.5切换面板设计

第五章试运行与总结

5.1体会与收获

1设计目标

1.1 用户调查

随着经济全球化和信息的高速发展，信息化管理成为企业实现现代化管理的工具之一，企业信息化管理整合公司内部资源，提高生产效率提供了平台。计算机在企业管理中应用的普及，利用计算机实现企业信息管理势在必行。计算机管理所无法比拟的优点是检索迅速、查找方便、可靠性高、存储量大、保密性好、寿命长、成本低等。这些优点能够极大地提高信息管理的效率,也是企业的科学化、正规化管理,与世界接轨的重要条件。根据公司实际情况，创建一套公司信息管理系统是十分必要的。

1.2问题范围与边界

公司信息管理主要包括员工实体，产品实体，供应商实体，客户实体的信息保存于查询管理。公司信息管理系统是一个简单的应用软件，不涉及硬件和软件的集成，本文将系统的边界定义为软件的边界。

1.3功能规划

产品信息查询：产品基本信息，根据产品ID查询，根据产品名称查询，根据产品是否过期查询，根据产品安全库存量查询

员工信息查询：员工基本信息，根据员工ID查询，根据员工姓名查询，根据员工性别查询，根据员工出生日期范围查询，根据员工雇佣日期范围查询供应商信息查询：供应商基本信息，根据供应商ID查询，根据供应商名称查询

客户信息查询：客户基本信息查询，根据客户ID查询，根据客户姓名查询

2概念设计

2.1业务细节描述

某公司信息管理系统的员工对公司各种产品的进货订单和销售订单进行签订、确认；供应商向公司提供特定的产品；公司向客户销售不同产品。

2.2概念设计过程

2.2.1确定业务过程中相互作用的实体

公司实体，员工实体，销售订单实体，进货订单实体，产品实体，供应商实体，客户实体

2.2.2将实体之间的作用转换为联系

工作、签订、确认进货、确认销售、供应、销售

2.2.3确定实体之间的作用时的数量关系

公司—1—<工作>—N—员工

员工—1—<签订>—Q—进货订单

员工—1—<签订>—T—销售订单

进货订单—C—<确认进货>—M—产品

销售订单—1—<确认销售>—P—产品

产品—B—<供应>—1—供应商

产品—D—<销售>—S—客户

2.2.4确定每个实体集的属性和键

（1）公司（公司ID，公司名称，公司规模等级，公司总资产规模）

（2）员工（员工ID，姓名，性别，出生年月，雇佣日期，公司ID，职称，办公地址，联系方式，照片）

（3）产品（产品ID，产品名称，生产日期，保质期限，官方售价，库存量，订购量）

（4）供应商（供应商ID，供应商名称，地址，联系方式）

（5）客户（客户ID，姓名，性别，出生年月，所属公司，联系方式，工作地址，照片）

（6）进货订单（进货ID，员工ID，类员工，供应商ID，供应商，签订日期，发货日期，到货日期，收货地址，产品数量，总计货款）

（7）销售订单（销售订单ID，客户ID，员工ID，员工，订购日期，发货日期，到货日期，收货地址，产品数量，总计货款）

2.2.5确定各实体集之间的联系类型

（1）公司-员工E-R图：

（2）员工-进货订单E-R图：

（3）员工-销售订单E-R图：

（4）进货订单-产品E-R图：

（5）销售订单-产品E-R图

（6）产品-供应商E-R图：

（7）产品-客户E-R图：

3物理设计

3.1 E-R模型转换为关系模型

(2)关系模型

关系模型是对关系数据结构的描述。

①公司（公司ID，公司名称，公司规模等级，公司总资产规模）

②员工（员工ID，姓名，性别，出生年月，雇佣日期，公司ID，职称，办公地址，联系方式，照片）

③进货订单（进货ID，员工ID，员工，供应商ID，供应商，签订日期，发货日期，到货日期，收货地址，产品数量，总计货款）

④销售订单（销售订单ID，客户ID，员工ID，员工，订购日期，发货日期，到货日期，收货地址，产品数量，总计货款）

⑤产品（产品ID，产品名称，生产日期，保质期限，官方售价，库存量，订购量）

⑥供应商（供应商ID，供应商名称，地址，联系方式）

⑦客户（客户ID，姓名，性别，出生年月，所属公司，联系方式，工作地址，照片）

⑧供应（供应ID，供应商ID，进货订单ID，产品ID）

⑨销售（销售ID，销售订单ID，客户ID，产品ID）

⑩确认进货（确认进货ID，进货订单ID，产品ID）

确认销售（确认销售ID，销售订单ID，产品ID）

3.2范式检查

每个规范化只有一个主题。如果某个关系有两个或多个主题，就应该分解为多个关系。规范化的过程就是不断分解关系的过程。大多数业务数据库设计中只需要考虑第一范式、第二范式和第三范式。现在对本公司信息管理系统进行范式检查。

第一范式（1NF）：

关系模型都满足第一范式，即符合关系定义的二维表格（关系）都满足第一范式。列的取值只能是原子数据；每一列的数据类型相同，每一列有唯一的列名（属性）；列的先后顺序无关紧要，行的先后顺序也无关紧要。根据第四章的数据表，可推导出，该数据库符合第一范式。就员工实体分析，它的属性有5个：姓名，编号，性别，年龄，工龄，住址。在“员工”关系中，每一项的数据都是最原始状态，每一列的数据都是从对应的属性中范围取值，每列或每行颠倒顺序对运行结果无任何影响。其他实体也都具备这样特征。因此，该数据库的关系符合第一范式。

第二范式（2NF）：

第二范式要求每个关系只包含一个实体集的信息，所有非关键字属性依赖于关键字属性。每个以单个属性作为主键的关系主动符合第二范式。很明显，公司关系只包含了公司集的信息，员工关系只包含了员工的信息，产品关系只包含了产品的信息，供应商只包含了供应商的信息，客户关系只包含了客户信息。另外，就员工实体看，其关键字属性为员工编号，其他属性均为非关键字且都以员工编号为主干而唯一生成的，即都依赖于员工编号，他们形成了父子关系。经分析，其他实体也都有这样的特点。总之，该数据库的关系的每一个给关键字属性都完全函数依赖于关键字属性，则关系满足第二范式。

第三范式（3NF）：

由前文可知，员工实体关系满足第二范式。此外，就员工和产品这两个实体来说，彼此的属性没有内部关联，比如员工的住址非关键字属性的选择对产品的数量非关键属性的确定完全没影响，两者相互独立，没有依赖传递。同时，其他实体关系非关键字属性也具有这样的特点。由此，该数据库关系的所有非关键字属性相互独立，任何属性其属性值的改变都不会影响其他属性，则该关系满足第三范式。

综上所诉，该业务数据库课程设计符合第一范式、第二范式和第三范式。

4物理设计

4.1数据表设计

(1)公司信息表

(2)产品信息表

(3)员工信息表

(4)供应商信息表

(5)客户信息表

(6)销售订单信息表

(7)进货订单信息表

4.2数据完整性约束设计

4.2.1实体完整性（主键）

(1)公司实体主键——公司ID

(2)员工实体主键——员工ID

(3)产品实体主键——产品ID

(4)供应商实体主键——供应商ID

(5)客户实体主键——客户ID

(6)进货订单实体主键——进货ID

(7)销售订单实体主键——销售订单ID

4.2.2参照完整性（外键及表关系）

4.3查询设计（*支持窗体设计和查询设计）

（1）产品信息查询:

产品基本信息查询:

②根据产品ID查询:

③根据产品名称查询:

④根据产品是否过期查询:

⑤根据产品安全库存量查询：

（2）员工信息查询：

①员工基本信息查询：

②根据员工ID查询：

根据员工姓名查询：

④根据员工性别查询：

⑤根据员工出生日期范围查询：

⑥根据员工雇用日期范围查询：

（3）客户信息查询：

①客户基本信息查询：

②根据客户ID查询：

③根据客户姓名查询：

（4）供应商信息查询:

①供应商基本信息查询：

②根据供应商ID查询：

③根据供应商名称查询：

4.4窗体设计（*影响查询设计）（1）主菜单（主界面）：

（2）产品信息查询菜单：

（3）员工信息查询菜单：

（4）客户信息查询菜单：

（5）供应商信息查询菜单：

4.5报表设计（*影响查询设计） (1)产品报表

(2)员工报表

(3)客户报表

(4)供应商报表

5试运行与总结

5.1体会与收获

课程设计是一个很好的实践过程，通过课程设计，把从课本上学到的理论知识运用到实际中，知识需要温故而知新，从实践中发掘对理论知识更深层的认识与理解。

本次数据库的课程设计是一个团队合作的过程，我们在整个数据库设计的过程中遇到不少难题，那时候才发现理论是完全不等同于实践的，纸上谈兵终究不能解决实际的问题。在实践中，我们发现了自己的不足，对知识的掌握及运用存在诸多的不完善。

课程设计过程中，我们按部就班，从数据的系统需求分析做起，到概念结构的设计、逻辑结构设计、物理设计，最后到数据库的试运行，虽然很多东西书上写的很清楚，貌似看着也很简单，思路非常清晰，但真正需要自己想办法去设计一个系统的时候才发现其中的难度，在概念结构设计阶段，我们需要处理信息，辨别实体与属性，不知道是认识上存在差异，还是其他的一些原因，我们组员之间经常在这一节上存在争论，然后到最后还是没能讨论出一个合理的结果，我们就只能又重新查阅相关资料，查找相关事例，把问题搞个明白。当然，在整个课程设计中我们所遇到的大大小小的问题不为少数，但是，我们并没有放弃，我们积极讨论，请教其他同学，找到解决的方法，这个过程是辛苦的，难熬的，但是到了最后一步，设计的系统实现了预期的基本功能，我们的心情又是喜悦的、激动的。

有付出就会有收获，这次的课程设计给了我们团队很多经验与体会，我们明白了“纸上得来终觉浅，绝知此事要躬行”的道理，我们更深刻地理解到了团队合作的重要性，实践是验证真理的唯一标准，只有把理论知识运用的实践中，我