(2)销售人员与客户之间的ER图
客户需要通过销售人员的介绍、销售而购买汽车，一个销售人员能向几个客户销售汽车，同样，也可以有几个销售人员想一个客户销售汽车，因此销售人员实体与客户实体之间是m:n联系。在销售人员向客户销售的过程中产生了数量的属性，其两之间的ER图如图3.5所示。
性别 姓名 住址 备注 客户 客户编号 联系方式 出库时间 销售 数量 工号 销售人员 联系方式 性别 姓名
(3)客户与汽车之间的ER图
每个客户能购买一辆或几辆汽车，而一辆汽车只能销售给一个客户，所以客户与汽车之间的联系类型是1:n，在销售汽车给客户的过程中，产生了数量与出库日期的属性。客户实体与汽车实体之间的ER图如
第10页
3.3系统全局ER图
将上面三个图合并，同时对各个属性进行整合，就得到系统全局ER图。在整合的过程中，各局部ER图的属性发生如下的冲突，所以需要重新进行定义。
（1）姓名:姓名属性分别在两处出现，需要重新定义。根据所处位置，分别定义为销售人员的姓名和客户的姓名。
（2）性别:性别属性分别在两处出现，需要重新定义。根据所处位置，分别定义为销售人员的性别和客户的性别。
（3）联系方式:联系方式属性分别在两处出现，需要重新定义。根据所处位置，分别定义为销售人员的联系方式和客户的联系方式。 （4）备注:备注属性分别在两处出现，需要重新定义。根据所处位置，分别定义为汽车信息的备注和客户信息的备注。
（5）数量：数量属性分别出现在两处，需要重新定义。处在汽车对
第11页
象中的数量定义为汽车的库存数量，而处在销售关系中的数量属性则定义为汽车的销售数量， 整合后的ER图如图所示。
性别 姓名
备注 住址 性别 销售人员 M N 工号 联系方式 客户 客户编号 联系方式 销售 1 出库时间 数量 供应商 姓名 备注 型号 汽车 品牌 数量 入库时间 编号 颜色 4．逻辑结构设计
逻辑结构设计是将全局概念模型（ER图）转换成DBMS支持的概念模式或关系模式（或者称为数据结构）。本系统选用Access 2003 作为后台数据库，该数据库属于关系型数据库，即使用表结构表示系统中的所有实体及其联系。
要在Access中实现图3.7所示的全局ER图（系统概念结构），必须将其转换成关系模式。从ER图出发，导出关系模式数据结构遵循如下的两个原则：
第一，对ER图中的每个“实体”，都应该转换成一个关系，该关
第12页
系内至少要包含对应实体的属性，并根据语义关系确定关系的主键。
第二，对ER图中的“联系”，要根据实际联系的方式及数据处理的需要，或者将其作为独立的关系来处理，或者将关系的属性（如果有）纳入相关联的实体的属性中。
如果实体之间是1:n联系，且联系没有产生对系统来说非常重要的属性，一般将1端的主键纳入n端的实体关系中，但是如果联系中产生对系统比较重要的属性，且需要独立研究该属性，则要将联系转换成一个独立的关系。
如果实体之间的联系是m:n联系，且联系中的属性多或者比较重要，则要将联系作为独立的关系来处理，且在关系中要包含联系的属性和与联系相关联的实体的属性。
将ER图转化为关系模式：
1. 销售人员（工号、姓名、性别、联系方式）
2. 客户（客户编号、姓名、性别、联系方式、住址、备注） 3. 销售（汽车编号、工号、客户编号、出库日期、数量）
4. 汽车（汽车编号、品牌、型号、颜色、供应商、入库时间、数量、备注）
5.数据库设计
本系统使用Access 2003作为后台数据库，同时也使用Access
2003设计了一个前台界面，因此，在Access中，除了创建基本表对象之外，还创建了查询对象、窗体对象、报表对象。
第13页
5.1创建表对象
表对象是数据库最基本的对象，数据库中所有其它的对象都是基于表对象来创建的。表对象要根据逻辑设计阶段设计的关系模式来创建。在创建表结构之前，首先应该确定表中各字段的数据类型和约束，然后在设计视图或SQL视图中创建表对象。下面分别使用表格来表示各个表对象的数据类型和约束。 （1） 客户
在客户对象的六个字段中，客户编号能够唯一标识一个客户，所以将该字段定义为主键，姓名和联系方式两个字段在客户表中必不可少，所以定义为非空约束，而性别、住址和备注允许为空。如表：
（2）汽车
汽车编号能唯一标识一辆汽车，所以将汽车编号定义为主键，除了备注字段外的其他字段都必不可少，所以定义为非空约束，而备注字段允许为空。下表列出了汽车表结构的数据信息。
第14页
列名 数据类型 约束情况 主键 客户编号 文本（10） 姓名 性别 文本（4） 非空 文本（1） 允许空 非空 联系方式 文本（11） 住址 备注 文本（20） 允许空 备注 允许空