电商订单系统课程设计报告.docx
《电商订单系统课程设计报告.docx》由会员分享，可在线阅读，更多相关《电商订单系统课程设计报告.docx（47页珍藏版）》请在冰豆网上搜索。
电商订单系统课程设计报告
《网络数据库技术及应用》
课程设计报告
题目：
电商订单系统
成员：
组长：
专业：
云南农业大学大数据学院
年月日
1.引言
电商所有模块中，订单系统作为最为核心的模块，决定了整个流程能不能顺畅的执行，起着承上启下的作用。
商品信息：
商品信息属于订单系统的上游端，所有订单都是从商品演进而来，从商品到订单，订单系统必须搜集相关的商品信息，包括店铺信息，商品id，商品规格，商品数量，商品价格。
获取到的商品信息将在订单详情页内展示，形成订单信息后供仓库方便拣货，包装。
用户信息：
用户信息包括购买用户的ID，收货人，收货地址，联系方式。
有些平台的用户成长体系是基于用户对平台的活跃度来计算的，例如京东，它有会员等级及积分卡等类似的成长标识，此时获取到的用户信息除了普通的信息字段外，还需要获取该用户的等级，该次购买后所获得的积分，以及该用户所在等级能在该订单上扣除的优惠等信息，具体怎么操作取决于公司的业务方向。
金额信息：
因为金额信息的特殊性，所以独立出来讲，理论上金额信息应归属商品信息。
金额信息的特殊性在于其不止一种金额，其涉及到商品金额，优惠金额，支付金额。
而优惠金额中涉及到的信息较复杂，像有自营和第三方入驻的电商平台，都会有商家优惠和跨店优惠，而这些优惠又分不同类型，例如现金扣减，消费券扣减，积分获取，礼品卡扣减，或者以上几种的组合使用。
想要涉及好这一块内容，需要根据目前自己公司的业务情况，列出所支持的优惠类型，再枚举出各种组合下的优惠类型，才能保证流程的完整性。
时间信息：
记录各个卡点下的时间，一是记录，二也是方便售后验证和客户分析。
订单时间是根据订单状态改变而改变的，比如我们常见的用户，下单未付款:
即展示订单创建时间，下单时间；待发货状态:
展示订单创建时间，下单时间，支付时间；待收货状态:
展示订单创建时间，下单时间，支付时间，发货时间；交易完成状态:
展示订单创建时间，下单时间，下单时间，支付时间，发货时间，完成时间；待退款状态:
展示退款订单创建时间，申请退款时间；交易关闭-用户取消:
展示订单创建时间，下单时间，用户取消时间；交易关闭-仅退款：
订单创建时间，下单时间，支付时间，退款申请时间，退款成功时间；交易关闭-退货退款（包含部分仅退款）：
订单创建时间，下单时间，支付时间，交易完成时间，退款申请时间，退款时间；时间信息看起来不重要，其实是订单系统一个重要的组成部分，原因大家可以思考一下。
订单信息：
订单信息在订单系统最为核心，订单信息最重要的又是订单状态。
很多公司都有订单状态机的说法，那到底什么是订单状态机，我个人的理解是在订单中，通过各种购物情景，触发订单状态，将订单的流转可视化，是订单状态机的一种具体呈现形式，而它实质就是在描述订单状态的转换。
电商购物中，订单状态分别有以下几种：
【待付款】【待发货】【待收货】【待评价】【交易完成】【用户取消】【仅退款】【退货退款】。
而我们一般会将后三种统一放在订单售后独立呈现，去方便平时商家操作的便捷性。
订单管理功能体现一：
订单的基础处理。
订单基础处理功能包含了订单信息筛选、订单合并、订单选快递、订单打印。
而想要完成这些这些基础又和新的订单处理工作，网络店主有两种途径可以选择。
一是加大人力投入，另外就是选择顺手合适的电商ERP系统。
经过对大多数店主的走访调查后不难发现，他们中的大多数人都是双管齐下，这样不仅可以提高订单处理效率，还能节省人力投入。
订单管理功能体现二：
订单发货和跟踪。
在提高订单装箱效率和发货效率上，如果订单数非常多，而网络店主和工作人员较少时，就必须一人身兼多职，否则可能就会因为发货不及时，引发买家催促和不满。
至于订单跟踪管理上，网络店主则尤其需要警惕那些出现异常情况的快递。
订单管理功能体现三：
给买家的订单提醒。
在很多网络店主的眼里，订单管理和客户管理紧密相连，而连接两者之间的突出表现就是来自订单运送状态给买家的提示。
而网络店主如果想要做好订单提醒，很多时候都会选择电商ERP系统等管理类软件来完成。
由于这类软件能够对对产生订单交易的买家给出订单发货提醒、订单派送提醒、订单签收提醒以及代替卖家给买家表示交易关怀。
当然，除了使用电商ERP系统表达对订单客户表达基础关心和提醒之外，一些比较用心的客户，还会利用电商ERP系统根据订单交易数额，给客户进行分类，方便对不同类型的买家表达更加具有针对性的关怀，借此培养客户忠诚度，提高订单买家的二次和多次购买率。
2.需求分析阶段
2.1引言
需求分析是设计数据库的起点，需求分析的结果是否准确地反映了用户的实际要求，将直接影响到后面各个阶段的设计，并影响到设计结果是否合理和实用。
目前停车场的管理方式比较落后，已经不能适应现代社会的实际需求，本系统的开发能给管理上带来新鲜的活力，提高管理的效率，具有较高的实用性和开发价值。
2.2任务
2.2.1需求分析阶段的目标
通过调查了解分析停车管理的现状，弄清用户对开发的数据库应用系统的确切要求，以及停车场管理的流程，系统的具体功能和数据库中数据信息。
2.2.2具体任务
（1）处理对象
系统处理的对象包括车辆信息、固定车位信息、自由车位信息、停车车辆信息以及收费记录等五个方面。
即
固定车位信息：
车位编号、车位位置、车牌号码、车主姓名、车辆品牌、车辆颜色、车辆照片、联系地址、联系方式、车位余额；
自由车位信息：
车位编号、车位位置；
车辆信息：
车牌号码、车辆品牌、车辆颜色；
停车信息：
车位编号、车牌号码、进入时间、离开时间、时间段、车位类型、在位情况、收费费率；
收费记录：
车位编号、车牌号码、停车时间、停车费用、发票编号。
（2）处理功能要求
整个系统具体包括三个子系统，分别为：
停车处理子系统、车位综合管理子系统以及收费子系统。
处理的功能包括：
车辆信息的查询以及更新；空闲车位信息的查询；固定车位信息的查询；进出车辆记录的更新和收费信息的查询与更新等。
（3）安全性与完整性要求
安全性可以通过视图机制来完成，对不同用户设置不同权限，不同的用户只能访问授权的视图，这样可以提高一定的程度的安全性。
还可以通过存取控制机制：
即定义用户权限，并将用户权限登记到数据字典中以及合法的权限检查来保障安全性。
完整性可以通过声明完整性，即在定义表时声明数据完整性和过程完整性，在服务器端编写触发器来实现。
2.2.3结果
（1）体会和收获
通过对现在的停车场管理状况的调查，发现停车场管理缺少合适的管理系统，并了解了一下管理的大致流程。
与此同时通过网络搜索查找现行的停车场管理系统，根据这两者综合来进行需求分析。
调查时需要较强的信息捕捉能力以及事后的总结与思考，同时学会用网络较快较准确地搜索到需要的资料是很关键的。
（2）业务流程图
见附录1
（3）数据流图
见附录2
（4）数据字典
数据项：
表2-1数据项说明
数据项编号
数据项名
数据项含义
与其它数据项的关系
存储结构
别名
DI-1
Cwno
车位编号
char（10）
编号
DI-2
Carno
车牌号码
char（10）
车牌
DI-3
Carname
车主姓名
char（10）
姓名
DI-4
Carcolor
车辆颜色
char（4）
颜色
DI-5
Carpho
车辆照片
bit
照片
DI-6
Caradd
联系地址
char（20）
地址
DI-7
Cartel
联系方式
char（20）
电话
DI-8
Carat
在位情况
char（4）
DI-9
Carin
进入时间
datetime
DI-10
Carout
离开时间
datetime
DI-11
Carmon
车位余额
float
余额
DI-12
Montime
收费费率
float
费率
DI-13
Moneypay
停车费用
float
收费
DI-14
Cwtype
车位类型
char（4）
DI-15
Cartime
停车时间
float
时间
DI-16
Piece
发票编号
char（20）
Dl-17
Carsb
车辆品牌
char（10）
车名
Dl-18
Cwpace
车位位置
char（10）
位置
Dl-19
Timetype
时间段
char（6）
数据结构：
表2-2数据结构
数据结构编号
数据结构名
数据结构定义
组成
DS-1
Fixed
固定车位信息
Cwno、Cwpace、Carno、Carname、Carcolor、CarsbCarpho、Caradd、Cartel、Carmon
DS-2
Free
自由车位信息
Cwno、Cwpace
DS-3
Stop
停车信息
Cwno、Carno、Carat、Carin、Carout、Timetype、Cwtype、Montime
DS-4
Moneynote
收费记录
Cwno、Carno、Cartime、Moneypay、Piece
DS-5
Car
车辆信息
Carno、Carsb、Carcolor
（5）处理逻辑描述
表2-3处理逻辑描述
处理编号
处理功能
处理过程
PR-1
判断用户查询涉及的功能模块
固定车位信息模块、自由车位信息模块、停车车辆信息模块、进出车辆记录信息模块、收费记录模块：
先确定查询所涉及的功能模块；然后，确定要查询的内容，确定查询数据流向；最后显示查询结果。
PR-2
判断用户修改要涉及的模块，同时把相应的修改数据传到相应的模块之中
固定车位信息模块、自由车位信息模块、停车车辆信息模块、进出车辆记录信息模块、收费记录模块：
先确定更新所涉及的功能模块；然后，把更新信息传送到相应的模块中；最后，进行相应的更新操作。
3.概念设计阶段
3.1目标
概念结构设计师是将需求分析得到的用户需求抽象为信息结构即概念模型的过程。
它是整个数据库设计的关键。
概念结构设计步骤分为两步：
第一步是抽象数据并设计局部视图，第二步是集成局部视图，得到全局的概念结构。
3.2设计过程
（1）选择中层数据流为切入点，通常选择实际系统中的子系统；
（2）设计分E-R图，即各子模块的E-R图；
（3）生成初步E-R图，通过合并方法，做到各子系统实体、属性、联系统一；
（4）生成全局E-R图，通过消除冲突等方面。
通过分析系统的业务流图与数据流图，得到系统围绕“车辆”与“车位”之间的相互关系。
3.3阶段成果
分E-R图：
全局E-R图：
E-R图属性如下所示：
车辆：
Car（Carno,Carsb,Carcolor）Carno是主码；
固定车位：
Fixed（Cwno,Carpace,Carno,Carname,Carcolor,Carpho,Caradd,Cartel,Carmon）；
自由车位：
Freed（Cwno,Carpace）Cwno是主码；
收费：
Moneynote（Cwno,Carno,Cartime,Moneypay,Piece）Cwno和Carno是外码；
停车：
Stop（Cwno,Carno,Carin,Carout,Timetype,Cwtype,Montime）Cwno和Carno是外码；
4.逻辑设计阶段
4.1目标
逻辑结构设计的任务是把概念结构设计阶段设计好的基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构。
逻辑结构设计时一般要分为3步进行：
将概念结构转换为一般的关系、网状、层次模型；将转换来的关系、网状、层次模型向特定DBMS支持下的数据模型转换；对数据模型进行优化。
4.2任务与结果
4.2.1数据组织
（1）将E-R模型转换为关系模型
转换的原则是：
一个实体型转换为一个关系模式。
实体的属性就是关系的属性，实体的码就是关系的码。
对于实体间的联系则有以下不同的情况：
一个1：
1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
三个或三个以上实体间的一个多元联系可以转换为一个关系模式。
与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。
一个1：
n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。
如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。
一个m：
n联系转换为一个关系模式。
与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。
3个或3个以上实体间的一个多元联系可以转换位一个关系模型。
与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。
具有相同码的关系模式可合并。
E-R图向关系模型转换的结果是：
车辆：
Car（Carno,Carsb,Carcolor）Carno是主码；
固定车位：
Fixed（Cwno,Carpace,Carno,Carname,Carcolor,Carpho,Caradd,Cartel,Carmon）自由车位：
Freed（Cwno,Carpace）Cwno是主码；
收费：
Moneynote（Cwno,Carno,Cartime,Moneypay,Piece）Cwno和Carno是外码；
停车：
Stop（Cwno,Carno,Carin,Carout,Timetype,Cwtype,Carat,Montime）Cwno和Carno是外码；
（2）模型优化
关系模型Car和Moneynote由于没有出现部分函数依赖和传递函数依赖，所以以上模型已经达到3NF。
但是关系模型Stop存在函数传递依赖CarinTimetype,Timetype-/->Carin
TimetypeMontime，因此应该将关系模型Stop转换为3NF，优化后的关系模型为“停车：
Stop（Cwno,Carno,Carin,Carout,Timetype）与费率信息：
Moneyt（Timetype,Montime）。
关系模型Fixed和Freed之间存在数据冗余，因此可以将两个关系模型合并为一个关系模型FFed,并添加识别信息，合并后的关系模型为
Ffed（Cwno,Carpace,Cartype,Carno,Carname,Carsb,Carcolor,Carpho,Caradd,Cartel,
Carmon）
模型优化后的关系模型为
车辆：
Car（Carno,Carsb,Carcolor）Carno是主码；
车位:
Ffed（Cwno,Cwpace,Cwtype,Carno,Carname,Carsb,Carcolor,Carpho,Caradd,Cartel,
Carmon）；
收费：
Moneynote（Cwno,Carno,Cartime,Moneypay,Piece）Cwno和Carno是外码，被参照表是Ffed和Car；
停车：
Stop（Cwno,Carno,Carin,Carout,Carat,Timetype）；
费率信息：
Moneyt（Timetype,Montime）。
（3）数据库模式定义
表4-1车辆信息
列名
数据类型
是否为主码
是否为外码
取值范围
可否为空
含义说明
Carno
Char
是
否
否
车牌号码
Carsb
Char
否
否
可
车辆品牌
Carcolor
Char
否
否
可
车辆颜色
表4-2车位信息
列名
数据类型
是否为主码
是否为外码
取值范围
可否为空
含义说明
Cwno
Char
是
否
否
车位编号
Cwpace
Char
否
否
否
车位位置
Cwtype
Char
否
否
否
车位类型
Carno
Char
否
否
可
车牌号码
Carname
Char
否
否
可
车主姓名
Carsb
Char
否
否
可
车牌号码
Carcolor
Char
否
否
可
车辆颜色
Carpho
Bit
否
否
可
车辆照片
Caradd
Char
否
否
可
联系地址
Cartel
Char
否
否
可
联系电话
Carmon
Float
否
否
100~200
可
车位余额
表4-3停车信息
列名
数据类型
是否为主码
是否为外码
取值范围
可否为空
含义说明
Cwno
Char
否
是
否
车位编号
Carno
Char
否
是
否
车牌号码
Carat
Bit
否
否
否
在位情况
Carin
datetime
否
否
否
进入时间
Carout
datetime
否
否
可
离开时间
Timetype
Char（6）
是
否
高峰、一般、低谷
否
时间段
表4-4费率信息
列名
数据类型
是否为主码
是否为外码
取值范围
可否为空
含义说明
Timetype
Char（6）
是
否
高峰、一般、低谷
否
时间段
Montime
Float
否
否
大于0
否
收费费率
表4-5收费记录
列名
数据类型
是否为主码
是否为外码
取值范围
可否为空
含义说明
Cwno
Char
否
是
否
车位编号
Carno
Char
否
是
否
车牌号码
Cartime
Float
否
否
大于0
否
停车时间
列名
数据类型
是否为主码
是否为外码
取值范围
可否为空
含义说明
Moneypay
Float
否
否
大于0
可
停车费用
Piece
Char
否
否
可
发票编号
（4）用户子模式定义
表4-6用户子模式定义
序号
视图名称
视图定义
视图作用
备注
V-1
Carinformation
车位号,车牌号
查询在位车辆信息
V-2
Carfixedtion
车位号,车牌号,车主,车名,车色,车照,地址,电话,余额
查询在固定车位停车的车辆信息
V-3
carfreetion
车位号,车牌号,车名,车色
查询在自由车位停车的车辆信息
V-4
Carinouttion
车位号、车牌号、进入时间、离开时间、时间段
查询车辆进出记录
作用与V-1不一样
V-5
moneytime
时间段、费率
查询及修改收费费率
V-6
Moneytion
总收费
查询停车场总收费
v-7
Carmoney
车牌号、缴费总额
查询每辆车的缴费额
（5）功能模块图
图9.系统功能模块图
5.物理设计阶段
5.1目标
物理设计就是为一个给定的逻辑数据结构模型选取一个最合适应用要求的物理结构的过程。
物理设计通常分为两步：
确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构；对物理结构进行评价，评价的重点是时间和空间效率。
如果评价结果满足原设计要求，则可进入到物理实施阶段，否则，就需要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型。
物理设计的内容包括：
为关系模型选择存取方法；设计关系、索引等数据库文件的物理存储结构。
5.2任务
5.2.1数据存取方面
由于经常需要判断是否有空余车位，所以要经常查询停车信息，因此在Stop表的Cwno上建立聚簇索引以提高查询效率。
为了方便查询各个车辆的收费记录，在Moneynote表的Carno上建立聚簇索引以提高查询效率
5.2.2功能模块图
（1）车位信息查询及更新模块图：
图10.车位信息查询及更新模块图
（2）停车信息查询及更新模块图：
图11.停车信息查询及更新模块图
（3）收费费率查询及更新模块图：
图12.收费费率查询及更新模块图
5.3结果
5.3.1存储过程
表5-1存储过程
编号
存储过程名称
定义
作用
P-1
Sof1
详见附录3-16
查询固定车位总数
P-2
Sof2
详见附录3-17
查询自由车位总数
P-3
Sof3
详见附录3-18
查询空闲自由车位数目
P-4
Sof4
详见附录3-19
查询车位总数
P-5
Sof5
详见附录3-20
在Moneynote中查询任意车辆的收费
P-6
Sof6
详见附录3-21
在Car中插入一元组
P-7
Sof7
详见附录3-22
在Ffed中插入一元组
P-8
Sof8
详见附录3-23
在Stop中插入一元组
P-9
Sof9
详见附录3-24
在Moneynote中插入一元组
P-10
Sof10
详见附录3-25
查询车辆Car信息
P-11
Sof11
详见附录3-26
查询车位Ffed信息
P-12
Sof12
详见附录3-27
查询停车Stop信息
P-13
Sof13
详见附录3-28
查询收费Moneynote信息
P-14
Sof14
详见附录3-29
删除一条收费Moneynote记录
P-15
Sof15
详见附录3-30
修改固定车位车辆余额Carmon
5.3.2触发器
表5-2触发器
编号
存储过程名称
定义
作用
T-1
insert_or_update_carmon
详见附录3-31
限定余额值必须大于等于120的触发器
P-2
tri_moneypay
详见附录3-32
限制修改MONEYNOTE中大于50的触发器
P-3
tri_del_mo
详见附录3-33
限制删除moneynote表中大于70的数据
6.数据库实施阶段
6.1目标
数据库实施阶段就是用DBMS提供的数据定义语言与其他实用程序将数据库逻辑设计和物理设计结果严格描述出来，成为DBMS可以接受的源代码，再经过调试产生目标模式，然后组织数据入库。
数据库实施阶段包括两项重要的工作，一项是数据的载入，另一项是应用程序的编码和调试。
6.2任务与结果
6.2.1建立数据库
（1）建立数据库、数据表、视图、索引等
（a）建立数据库定义语句见附录3-1；
（b）建立数据表定义语句见附录3-2至3-6；
（c）建立视图定义语句见附录3-7至3-13；
（d）建立索引定义语句见附录3-14至3-15。
（2）数据入库
系统包括共有5张基本表,因此事先在Excel中录入数据,然后使用SQLServer2000数据导入/导出向导功能,直接将数据导入到相应的基本表中。
7.数据库调试与测试
对收费停车场管理系统的具体功能进行测试，测试包括：
（1）测试各视图的功能，测试结果见附录4-1；
（2）
升级会员 