数据库实习报告 经典范例.docx
《数据库实习报告 经典范例.docx》由会员分享，可在线阅读，更多相关《数据库实习报告 经典范例.docx（47页珍藏版）》请在冰豆网上搜索。
数据库实习报告经典范例
信息工程学院
《数据库课程设计》论文
题目：
汽车销售管理系统数据库设计
学号：
2010012863
专业班级：
计算机科学与技术103班
姓名：
徐兵
指导老师：
孙健敏
完成日期：
2012年1月13日
汽车销售管理系统数据库设计
徐兵
（信息工程学院计算机10级3班）
摘要
此次课程设计的主要内容是设计一个利用数据库设计一个汽车销售管理系统，这个系统包括汽车进货、汽车销售、汽车库存管理等三大基本功能，其中汽车销售是最主要，也是最重要的功能；它包括了销售管理、采购管理、财务管理、以及员工管理等功能。
并且在视图以及存储过程中还提供了查询和更新的功能。
该系统的开发是由系统需求分析阶段、概念设计阶段、逻辑设计阶段、数据库实施、调试、测试等阶段组成。
其中需求分析阶段是此次数据库设计能够顺利进行的必要保障，所以需要花费比其他阶段相对较多的时间；而概念设计阶段的E-R图绘制过程是一个反复而精细的过程，需要一定的耐心和细心；最后的数据库实施、调试以及测试等阶段要编写许多SQL语句，这是对以前数据库所学知识的一个综合应用，同时也是对以前所学知识的一个巩固和提高，需要认真的思考和进行。
关键字：
汽车；需求分析；存储过程；数据库
引言
汽车销售管理系统项目开发背景：
目前，我国的汽车业销售管理大多沿用旧的管理模式，无论在仓储管理，还是在销售管理方面等其他方面都存在一些问题，这些无疑制约了汽车业的发展和腾飞，在传统的汽车业管理模式中，纸单据及手工管理是其主流方式。
这种方式具有数据可靠性差，运行效率低下，统计分析难度大的缺点，快速抽取对企业有用的统计信息的可能性很小。
对于买主来说，必须要到公司来对汽车进行察看、了解性能、商谈售价，最后再确定是否要购买，因为这些事情需要花费大量的时间和精力，对购车者来说很不方便，对公司的销售来说，每天要接待大量的购车者，也要花费大量的人力来应对，并且可能会由于汽车销售员的问题给消费者和公司带来不好的影响，在汽车销售完成后，要手工记录购车者的信息，以便提供售后服务，工作量大。
尤其在汽车行业越来越兴旺的近几年，想购买汽车的家庭也越来越多，这种传统的管理模式已不能适应当今汽车企业的发展趋势，特别是信息化时代的到来，采用先进管理模式来增强竞争力，迎接信息化革命是摆在汽车业面前很现实而且很重要的问题。
如何在效益、效率上取得提升成为关键问题，迫切需要一种能够快速完成以上各种需求的系统
汽车销售管理系统的目标：
本系统是为解决汽车销售公司的管理问题而设计。
随着经济的发展和国内汽车市场的不断扩大，某汽车销售公司定单成倍增加，各项业务更加细化，各部门分工更加明确。
而目前的人工管理方式显然已是不符合现代企业的管理要求。
基于整体考虑，本次课程设计任务就是设计一个管理系统，利用计算机来代替人工操作。
减轻了员工的劳动强度，提高了劳动质量和效率，减少了错误的发生。
本次设计，从需求分析，概念设计，逻辑设计，物理设计，到数据库的建立、运行，再到数据库的安全维护等各个方面进行了详细的分析设计。
并且值得一提的是，我认真分析了企业的业务需求，公司的主要职责和主要结构等信息，从而保证了设计出比较符合公司需要的管理系统。
项目开发意义：
目前大多数厂商忽略了汽车销售管理系统的重要性，而本系统专为具有一定规模和经济条件的大型汽车厂设计。
从进货管理：
车辆采购、车辆入库，销售管理到车辆销售、收益统计等，为每个环节明确分工，并通过可视化的软件支持，有效减小了人为差错的概率，代之以高效、便捷、准确的数字化服务系统，使汽车销售管理更加规范化。
根据所学的数据库原理与程序设计的知识，能够针对一个小型的数据库管理系统进行系统的需求分析，系统设计，数据库设计，编码，测试等，完成题目要求的功能，加深对数据库系统、SQL语言、存储过程、触发器的理论知识的理解和应用水平,通过设计实际的数据库系统应用课题，进一步熟悉数据库管理系统的操作技术，提高动手能力，提高分析问题和解决问题的能力。
从而达到掌握开发一个小型数据库的目的
1．需求分析
主要包括内容：
处理对象及组织；信息处理及系统功能；数据库系统性能需要，数据库系统开发环境需求等。
在阐述信息及其处理过程时，要辅助业务流程图、数据流程图及数据字典。
对上述三个问题可以以附录的形式详细罗列，但正文中必须指明做了哪些业务流程图、数据流程图和数据字典的规模。
1.1需求分析阶段处理对象及组织
系统的处理对象主要包括供应商基本信息、汽车基本信息、顾客基本信息、仓库基本信息、公司员工的基本信息等对象；并且还要处理报损单、订货单、销售单等外部对象；最后还要处理供应商与供应之间的供应关系，销售人员、顾客、以及汽车之间的销售关系等组织；
1.2信息处理及系统功能
1.2.1数据流程图
汽车销售管理系统的数据流程图如下图1.1—图1.5：
（1）顶层数据流程图：
（2）第一层数据流图
（3）第二层数据流程图—进货
1.进货：
（4）第二层数据流程图—销售
2.销售：
（5）第二层数据流程图——盘存
3.盘存：
1.2.2数据字典
包含数据项、数据结构、数据流、处理逻辑、数据存储定义（详见附录1）。
1.2.3系统功能
随着信息化技术的飞速发展，高效的汽车销售管理系统是当前信息化汽车公司管理系统之需要。
建立汽车销售管理系统可以提高汽车经销商管理公司的职员和汽车的效率，可以做到汽车信息的规范管理、快速查询和科学统计，从而减少管理方面的工作量，实现公司的信息化管理。
经过分析与总结得出，汽车销售管理系统有如下功能。
能够对销售信息进行有效的管理。
销售人员负责汽车的日常销售工作，需要掌握各种汽车的各次的销售情况。
通过本系统能进行销售分析和进货分析，还能进行销售管理，并且能进行业绩查询。
能够对客户信息进行有效的管理。
对汽车销售来说，客户信息也很重要，掌握了客户的信息，才能了解客户的需求。
通过本系统能进行客户信息编辑、客户信息查询，并且能打印客户信息报表。
并且还有对仓库盘存以及报损的处理。
上述的需求分析可以总结为如图1-6所示的功能结构图：
1.3数据库系统性能需要，数据库系统开发环境需求:
1.3.1检查硬件要求：
系统必须符合以下最低硬件要求：
1.至少有1024MB的物理内存
2.下面是说明安装时物理内存（RAM）和交换区（swapspace）的配置关系。
RAMSwapSpace
1024MB到2048MB1.5倍RAM
2049MB到8192MB等于RAM
大于8192MB0.75倍RAM
在/tmp目录中至少有400MB空闲磁盘空间
1.5GB到3.5GB的磁盘空间用于安装Oracle数据库软件，具体大小由安装类型决定
1.2GB磁盘空间用于数据库预配置文件系统存储（可选）
1.3.2.操作系统：
windowssever2003\xp\vista\win7
2．数据库结构设计
主要包括概念设计和逻辑设计两个部分。
2.1概念设计
概念设计阶段主要是将需求缝隙阶段得到的用户需求抽象为信息结构即概念模型的过程，它是整个数据库设计的关键;设计概念结构通常有四类方法：
自顶向下、自底向上、逐步扩张、混合策略。
概念结构是对现实世界的一种抽象。
所谓抽象是对实际的人、物、事和概念进行人为处理，抽取所关心的共同特性，忽略非本质的细节，并把这些特性用各种概念精确地加以描述，这些概念组成了某种模型。
一般有分类、聚集、概括三种抽象；
2.1.1分E-R图建立
阐述分E-R图建立的思想（以中层数据为切入点，按照分层次/分模块思想），用E-R模式描述。
分E-R图建立的思想是：
1.对需求分析阶段收集到的数据进行分类、组织（聚集），形成实体、实体的属性，标识实体的码，确定实体之间的联系类型（1:
1，1:
n,m:
n）,设计分E-R图；
2.作为“属性”，不能在具有需要描述的性质。
“属性”必须是不可分割的数据项，不能包含其他属性。
3.“属性”不能与其他实体具有联系，即E-R图中所表示的联系是实体之间的联系。
参照数据流图，分别画出分E-R图，如图2.1至2.3所示：
（1）进货时的分E-R图：
（2）销售时的分E-R图：
（3）盘存时的分E-R图：
2.1.2全局/整体E-R图
阐述全局E-R图建立的步骤，重点阐述消除冲突、冗余等过程。
如果E-R图规模较大，可以以附录形式列出。
全局E-R图建立的步骤：
1.无论采用哪种方式，每次集成局部E-R图时，都要分两步走：
（1）合并。
解决各分E-R图之间的冲突，将各分E-R图合并起来生成初步的E-R图。
（2）修改和重构。
消除不必要的冗余，生成基本的E-R图。
2.各个局部所应用面向的问题不同，且通常是由不同的设计人员进行局部视图设计，这就导致各个分E-R图之间必会存在许多不一致的地方。
因此，合并分E-R图时不能简单的将各个分E-R图画到一起，而是要着力消除各个分E-R图之间的冲突。
各分E-R图之间的冲突主要有三类：
属性冲突、命名冲突和结构冲突。
3.最后得出全局的E-R如下图2.4所示：
2.2逻辑设计
概念设计阶段是独立于任何一种数据模型的，而逻辑设计阶段则与现实结合起来，逻辑设计的任务就是将概念设计阶段设计好的基本E-R图转换为与项目所支持的数据模型相符合的逻辑结构。
具体任务包括将E-R图转换成关系模型、模型优化、数据库模式定义、用户模式设计。
2.2.1建立关系模式
E-R图向关系模型的转换遵循如下规则，一个实体型转换为一个关系模式，实体的属性就是关系的属性，实体的码就是关系的码。
对于实体间的联系则有不同的情况：
一个1：
1联系可以转换为一个独立关系模式，也可以与任意一端关系模式合并；一个1：
N联系可以转换为一个独立关系模式，也可以与n端实对应的关系模式合并；一个M：
N联系转换为一个独立关系模式，具有相同码的关系模式可以合并。
根据以上原则，对于该系统的E-R图进行转换，从而得到本E-R图向关系模型的转换如下：
//外部实体
供应商（供应商编号，供应商名，供应商地址，供应商状态，供应商电话）
最小函数依赖集：
R供应商={供应商编号->供应商名，供应商编号->供应商地址，供应商编号->供应商状态，供应商编号->供应商电话}
汽车（汽车型号，汽车品牌，汽车名称，汽车产地，汽车价格，汽车状态）
最小函数依赖集：
R汽车={汽车型号->汽车名称，汽车型号->汽车产地，汽车型号->汽车价格，汽车型号->汽车状态}
顾客（顾客编号，顾客姓名，性别，年龄，顾客地址，顾客联系电话）
最小函数依赖集：
R顾客={顾客编号->顾客姓名，顾客编号->顾客性别，顾客编号->顾客年龄，顾客编号->顾客地址，顾客编号->顾客联系电话}
仓库（仓库号，仓库容量，仓库电话）
最小函数依赖集：
R仓库={仓库号->仓库容量，仓库号->仓库电话}
公司员工（员工编号，员工姓名，性别，年龄，联系电话，员工属性）
最小函数依赖集：
R仓库管理员={员工id->员工姓名，员工id->仓库号，员工id->性别，员工id->年龄，员工id->联系电话，员工id—>员工属性}
//内部实体
报损单（报表号，管理员编号，报表日期）
最小函数依赖集：
R报损单={报表号->管理员编号，报表号->报表日期}
订货单（订单号，顾客编号，销售员编号，订单日期）
最小函数依赖集：
R订货单={订单号->顾客编号，订单号->销售员编号，订单号->订单日期}
销售单（销售单号，销售员编号，顾客编号，开单日期，支付金额）
最小函数依赖集：
R销售单={销售单号->销售员编号，销售单号->顾客编号，销售单号->开单日期，销售单号->支付金额}
退货单（退货单编号，顾客编号，开单日期）
最小函数依赖集：
R退货单={退货单id->顾客编号，退货单id->开单日期}
//相关关系模式
供应（供应商编号，汽车型号，供应量）//供应商——汽车之间关系
最小函数依赖集：
供应={（供应商编号，汽车型号）->供应量}
销售（顾客号，汽车型号，销售员编号，时间，销售金额）//销售人员——顾客之间的关系
最小函数依赖集：
销售={（顾客号，汽车型号，销售员编号）->时间，（顾客号，汽车型号，销售员编号）->销售金额}
2.2.2关系模式规范化处理
以上关系模式中的各实体和联系之间不存在非主属性对主属性的部分函数依赖，也不存在传递函数依赖，已经达到了3NF。
2.2.3用户子模式建立
根据需求分析，研究建立满足不同需求的用户子模式，子模式表示形式为：
子模式名（属性列表）
1、为进货部建立视图，目的是为了方便进货时做出迅速正确的决策：
空闲供应商（供应商编号，供应商姓名，供应商地址，供应商联系电话）
从供应商表导出
销售表（汽车型号，汽车品牌，销售员编号，时间，销售价格）
从销售表和汽车基本信息表导出
供应表（供应商编号，供应商姓名，汽车型号，供应量）
从供应商表和供应表导出
2.为顾客建立视图，方便顾客查询数据：
待售汽车（汽车型号，汽车品牌，汽车名称，汽车产地，汽车价格，汽车状态）
从汽车表和销售表导出
订单（订单号，客户号，客户姓名，订货日期）
从订单表、客户表导出
3.为销售部门建立视图，方便销售部门及时了解相关资料。
待售汽车（汽车型号，汽车品牌，汽车名称，供应量）
从汽车表、供应表两张表导出
所有车辆销售信息（车型号，厂商号，车辆状态）
从供应表和汽车表导出
用户子模式表2-5
编号
用户子模式名称
定义
作用
V-01
Supplier_view
空闲销售商视图
方便进货进货
V-02
Selled_view
销售状态视图
方便进货部查询销售情况
V-03
Provide_view
供应视图
方便进货部及时了解供货
V-04
Unscar1_view
代售汽车视图
方便顾客查询汽车信息
V-05
Book_view
订单信息视图
方便顾客查询订票信息
V_06
Unscar2_view
代售汽车视图
方便销售人员查询未售汽车
V_07
Record_view
所有车辆销售视图
方便销售人员查询销售记录
2.2.4关系模式逻辑结构定义
详细的逻辑结构定义见附录2。
3．数据库物理设计
3.1物理设计阶段目标和任务
数据库的物理设计是为逻辑数据模型选取一个最合适应用需求的物理结构的过程，在这个阶段中需要完成的任务是：
（1）确定数据库的物理结构，在关系数据库中主要是存取方法和存储结构；
（2）对物理结构进行评价，评价的重点是时间和空间效率。
3.2数据存储方面
3.2.1建立索引的原则
建立索引一般有以下三个原则：
（1）如果一个或一组属性经常在查询条件中出现，则考虑在这个属性上建立索引。
（2）如果一个经常作为最大值和最小值等聚集函数的参数，则考虑在这个属性上建立索引。
（3）如果一个或一组属性经常在连接操作的连接条件中出现，则考虑在这个属性上建立索引。
3.2.2建立索引
索引表3-1
所在表名
索引名称
索引类型
建立索引的项
供应商信息表
Supplier_index
唯一
SNum
汽车信息表
Car_index
唯一
CNum
客户信息表
User_index
唯一
Use_Num
订单信息表
Book_index
唯一
BFNum
销售信息表
Sell_index
唯一
User_Num,SeNum,CNum
4．数据库实施与测试
主要包括数据库实施和测试两个部分。
4.1数据库实施
4.1.1数据库及数据库对象建立
主要包括：
数据库、基本表、视图、索引、触发器以及存储过程；
对于具体的DDL语句以及相关代码，见附录3。
（1）建立索引：
CreateuniqueindexSupplie_indexonSupplier（SNum）;
CreateuniqueindexCar_indexonCar（CNum）;
CreateuniqueindexUser_indexonCustomer（User_Num）;
CreateuniqueindexBook_indexonBookList（BFNum）;
CreateuniqueindexSell_indexonSellForm（User_NumAsc,SeNumDesc,CNumDesc）;
（2）创建的视图如表4.1所示
视图表4-1
编号
用户子模式名称
定义
作用
V-01
Supplier_view
空闲销售商视图
方便进货进货
V-02
Selled_view
销售状态视图
方便进货部查询销售情况
V-03
Provide_view
供应视图
方便进货部及时了解供货
V-04
Unscar1_view
代售汽车视图
方便顾客查询汽车信息
V-05
Book_view
订单信息视图
方便顾客查询订票信息
V_06
Unscar2_view
代售汽车视图
方便销售人员查询未售汽车
V_07
Record_view
所有车辆销售视图
方便销售人员查询销售记录
（3）创建的存储过程如表4.2所示：
存储过程表4.2
编号
存储过程名称
作用
N1
Supply_Insert
向供应商基本信息表插入一个元组
N2
Car_Insert
向汽车基本信息表插入一个元组
N3
Customer_Insert
向顾客基本信息表插入一个元组
N4
Person_Insert
向员工基本信息表插入一个元组
N5
Book_Insert
向订单基本信息表插入一个元组
N6
Sell_Insert
向销售单基本信息表插入一个元组
N7
Return_Insert
向退货单基本信息表插入一个元组
N8
Person_delete
从员工基本信息表中删除一个元组
N9
Book_delete
从订单基本信息表中删除一个元组
N10
Return_delete
从退货单基本信息表中删除一个元组
（4）创建的触发器如表4.3所示：
触发器表4.4
编号
触发器名
作用
T1
DeCustomer
删除客户信息级联删除订单信息、退票信息
T2
DeSupplier
删除供应商级联删除所供应汽车型号
T3
AddSelllist
增加销售单级联增加相应的销售记录
4.1.2数据入库
系统包括11张基本表，在Excel中录入数据，然后使用PL\SQL数据导入功能，直接将数据导入到相应的基本表中。
4.2数据库测试
主要内容是对建立的数据库及数据库对象进行测试，详细的测试情况见附录4。
5．总结
将近两个礼拜的实习，在紧张的复习与考试过程中即将结束了。
在实习过程中遇到了很多问题，有时会为了解决一个问题而长时间停滞不前，但经过自己不断的思考、尝试问题都逐一的被解决了。
总的来说，通过这次课程设计的感触很多。
第一感觉就是理论和实践的差距远远大于人的想象；课堂上觉得很简单的东西，真到了要做的时候，会发现很难。
在这次实习之前我感觉数据库就像一种语言一样，学会它的语法就应该可以了，不过现在才明白数据库重点在于设计，设计的过程才是最有价值，最有意义也是最富有挑战性的。
通过这次实习，我收获了很多。
首先是在需求分析阶段，这个阶段的任务可以说是整个数据库设计任务量最大的阶段，我花了大量时间在业务流程图和数据流程图的创建上，不断的修改，不断的和指导老师交流。
在这个过程中真切的了解了业务的分析的重要性。
在概念设计阶段，主要的任务就是抽象出E-R图。
然后就是逻辑设计阶段了，这个阶段是要把让我头疼的E-R图的绘制，以及将绘制好的E-R图转换为关系模式，这一阶段我花费的时间相对较多。
经过不断的尝试和修改，很快就完成了逻辑结构的设计，得到了该建立的表。
这个时候到了数据库实施阶段了，以前我认为创建基本表、视图、存储过程、触发器是数据的重点，现在看来这些都是皮毛，这些都是数据库设计过程中最简单最基础的问题。
真正需要能力和时间的是前面的需求分析、概念设计、逻辑设计阶段，把实际问题抽象成计算机能够实现解决的问题才是最重要的，这是数据库可以实施的必要条件。
这次课程设计的任务，我基本上算是完成了。
通过和以前同学做出的系统比较以及自己的测试检查我知道我做出的系统不是很全面，即便如此，我还是从其中学到了很多技巧。
在以后的学习中，我会多实践，多练习，书本上知识的学习毕竟没有实践来的有效，并且在实践过程中同时也是对理论知识的应用和提高，并且最终都是对自己能力的一种提高和促进。
在此，我要感谢学院能够为我们安排这样一场实习，并且感谢有这么多优秀的知道老师及时给我们解决问题，同时也感谢在困难时及时帮助过我的同学们！
6．附录
附录1：
数据字典：
（1）数据项如表6.1所示：
表6.1
数据项编号
数据项名
数据项含义
与其它数据项的关系
类型
长度
取值范围
Da1
ProSumber
供应商编号
主码
varchar
10
Da2
ProName
供应商名称
varchar
10
Da3
ProAddress
供应商地址
varchar
30
Da4
ProState
供应商状态
varchar
10
Da5
ProPhone
供应商联系电话
varchar
15
Da6
Cnumber
汽车型号
主码
varchar
8
Da7
Csign
汽车品牌
varchar
6
Da8
Caddress
汽车产地
varchar
10
Da9
CName
汽车名称
varchar
10
Da10
CState
车辆状态
varchar
2
1~2个字节
Da11
CPrice
汽车价格
number
5
Da12
CusName
客户姓名
varchar
6
Da13
CusSex
客户性别
varchar
3
Da14
Cusnumber
客户编号
主码
varchar
10
Da15
CusAge
客户年龄
varchar
Da16
CusWplace
客户工作单位
varchar
20
Da17
CusPhone
客户联系电话
varchar
16
取值唯一
Da18
Gnumber
仓库号
主码
varchar
10
Da19
Bnumber
订单号
varchar
15
取值唯一
Da20
Bdate2
交货日期
date
Da21
Profits
利润
varchar
10
Da22
Fdate
保修期限
number
2
两位整数
升级会员 