数据库大作业报告物流管理系统.docx

数据库大作业报告物流管理系统.docx

《数据库大作业报告物流管理系统.docx》由会员分享，可在线阅读，更多相关《数据库大作业报告物流管理系统.docx（24页珍藏版）》请在冰豆网上搜索。

数据库大作业报告物流管理系统

本科学生综合性实验报告

课程名称：

数据库系统原理

项目成员孙钰雷付欢匡雄

潘丽娟许毅刘国靖

班级计算机131

实验项目名称物流系统数据库设计

指导教师万常选

开课学期2015至2016学年第一学期

完成时间2015年11月1日

1需求分析

1.1背景说明

现代快递企业无论大小都是使用信息系统作为平台为客户提供服务。

但这种利用信息系统来服务客户的行为还远远没有达到合理利用的程度，其中一个主要原因是这些系统不是针对特定地区和企业部门开发的。

经济发展、科技进步和信息革命，将世界带入前所未有的全球化的时代。

集物流、信息流和资金流于一身的物流配送中心，在这全球化和市场化的时代里，又进一步促进了世界经济与贸易的发展。

迈向21世纪的国际物流技术的特征是信息化、网络化、智能化、柔性化、标准化和社会化。

物流配送管理系统专注于商品的到货、发货、保、搬运、运输等作业的计划、控制和反馈过程的信息搜集、汇总、查询和分析，达到提高物流配送效率，降低物流配送成本的目的。

1.2系统目标与系统边界

系统目标：

建立一个比较全面的物流信息网，为用户提供全面的服务满意的服务。

该系统联系了用户，卖家和运输部门，可以为用户和运输部门人员提供查询物品运到何处的详细信息。

1.3功能需求分析

1.3.1系统的功能描述

（1）主要的数据功能：

实现数据增加、删除以及更新;派送单查询、接收单查询、投诉单查询以及未派送的快件查询等查询功能；某一段时间内的数据进行统计；打印详细报表；基本资料维护及用户权限等；数据库的备份与还原。

（2）站点基本信息管理：

提供站点基本信息录入、维护与查询

（3）员工基本信息管理：

提供员工基本信息录入、维护与查询

（4）订单审核：

该系统是物流系统，每一份订单的生成涉及到物件的配送，资源的利用，所以每一份订单都应该由工作人员审核后生成。

（5）物件单查询：

物件单包括订单和派送单，订单生成后分由不同的人派送，形成派送单，查询订单可以知道该站点所接受的物件以及物件的具体信息；查询派送单可以知道某物品的送货人员以及派送物体的具体信息。

（6）分包：

站点A每天收到很多送往不同地方的很多快递，我们把送往地方相同的快递打包在一起方便运送和管理。

（7）追踪：

就是要确定在某个时间某物件到达的站点。

（8）计算价格：

对于运送的不同物品重量不一样的物品有不同的运送价格，该系统提供计算运费的功能。

（9）统计：

可以统计每天某站点运送的物件数量，方便计算物流量。

（10）路径规划：

提供一个连同两个站点的通路。

1.3.2系统总体功能图

总体业务描述：

发货人发货，业务员在收货时要对货物进行检查，即查看是否合格若是选择运送方式，业务员接收生成订单，将东西放入起始站点，若否则退回。

业务员接收物品后将货物进行包装和初步的分类后，即会生成路线信息。

后将货物送给下个中转站，每个中转站都会对货物进行扫描，查看货物是否丢失，在中会对货物进行整合和拆装，即是在运送过程中先对货物进行整合，在运送到一定的地方后，对货物进行拆装。

最后到达终点站。

到达终点站时要检查货物，并通知收件人，收件人检查货物是否合格，若合格则签字取走货物。

结束流程。

1.3.3主要业务流程描述

（1）订单审核：

员工登录系统，查看接收到的订单信息，核实了用户信息以及物品信息正确就按照时间关系生成新的订单。

（2）物件单查询：

a.客户查询：

客户登录系统，输入自己的订货单号，就可以查询到自己的物品到达了那个地方，以及自己物品的具体信息，查询之后登出。

B.员工查询：

员工登录管理系统之后，输入站点号，或者订单编号可以查询具体的站点运送的货物或者物品流通信息。

（3）分包：

员工确定物品的最终目的，把目的相同的物品进行打包。

（4）追踪：

用户登录之后，输入自己物品编号即可。

员工查询：

登录后选择“查询具体物品”或者“查询某站点运送物品”进行查询。

（5）路径规划：

确定起始地址与目的地址中较高级别的站点，路线就是先运送到较高站点，再运送到目的地；如果两者之间最高站点的级别是相同的就直接向目的地运送（仅限于一个省份内）。

（6）统计：

对于某个站点的订单数目进行累加。

（7）计算价格：

确定物品种类，根据不同的计算标准进行计算

（8）主要业务的流程图

1.4数据需求及业务规则分析

1.4.1数据需求描述

1.4.3业务规则描述

1.订单审核：

一个员工可以审核多份订单，一份订单只能由一个员工审核，他们之间是一对多的联系。

2.客户要在本公司运输包裹，则客户必须进行自己信息录入，并且客户的编号按照注册时间不同来生成。

同理接收包裹的用户也必须注册记录了自己的信息成为本公司的客户才能接收包裹。

3.站点信息管理：

站点按照省市区（县）镇分为4个等级，省为一级，市为二级，区或县为三级，镇为4级，其他的属性见数据字典。

每个站点的编号由由级别决定怎么编。

4.包裹单：

每个包裹的包裹单号唯一。

5.客户包裹单查询：

客户可以依据自己的包裹单号查询自己的货物；也可以根据自己的编号查询自己的所有包裹单。

6.员工：

员工可以查询近一个月或者一周内的货物运送情况。

7.分包：

根据直通线路的联系表，我们在每一个站点进行重新打包，打包的规则是运往的下一站是相同的，包括相同的运输方式，相同的代价。

8.追踪：

找到物品到达那个站点，用户只能登录用户系统，查询自己的物品到达那个站点，查询时，界面上会显示出自己货物到达各个站点的时间信息，距离当前时间最近的站点信息就是该物品到达的站点。

员工登录工作系统可以查询整个物流系统的信息，也可以查询某个用户的物流信息。

9.路径规划：

假设在江西省内：

判断两个地点是否是同一级的，若是就直接运送到相同等级的目的地；若不是，就先把货物运送到较高级的站点在运送到目的地。

寄件时如果选择航空服务则选择运输器类型为飞机的线路，如果本地无飞机，则先陆运往就近有飞机的城市。

因为跨省运输公路往往较长。

所以则物流管理系统中事先规划好了跨省运输的路径。

现在交通运输发达。

假设每个省份之间都有直达的线路。

因为特殊原因可能某条线路不能使用，路线表中给出别的线路备选和中转地被选。

10.统计：

只有员工可以进行统计站点的货物积累信息。

11.计算价格：

一个员工可以计算多种物品的价格，但是一种物品其价格只能由一个员工按照计算标准计算。

标准见附录。

1.4.4完整性约束规则描述

从数据需求描述和业务规则描述中，发现并抽取数据库必须满足的完整性约束规则，包括：

（1）码约束规则。

即需要指出实体集的码属性。

（2）关联约束规则。

即映射基数约束、参与约束和依赖约束等。

在E-R模型中，关联约束是通过联系集和/或弱实体集、联系实体集、依赖实体集等来反映；在关系数据库模式中，关联约束将转化为通过外码来反映。

（3）用户自定义完整性约束规则。

如属性取值约束、先修课程约束、选课人数约束、选课时间冲突约束、业务沟际关系约束等。

2概念设计

2.1确定基本实体集

2.1.1发现基本实体集

从业务的总体流程来看：

客户寄快递产生业务，中转过程中需记录站点信息和对应的员工的信息。

以及有哪位员工运送，运送到哪里的信息记录，所以运输器也是一个基本实体集。

所以基本实体集确定为：

员工，客户，运输器，中转站，包裹。

客户：

产生快递的原因

员工：

处理快递以及录入快递信息人员

站点（中转站）：

快递从起点到终点要经过很多个站点称为中转站，追踪的业务就需要准确了解快递到达那个中转站，所以要详细记录中转站的信息。

包裹：

客户运送的快递物品

运输器：

运送快递的交通工具

包裹单：

包裹与客户之间发生的联系

2.1.2定义基本实体集（数据字典）

数据字典

包裹表

属性描述

属性名称

类别

数据类型

实例

订单号

orderNo

主码

VarChar（20）

标签ID

labelID

外码

Varchar（20）

路径的编码

类型

type

Varchar（20）

重量

weight

float

包裹单表：

属性描述

属性名称

类别

数据类型

实例

包裹单编号

orderNo

主码

VarChar（20）

重量

weight

float

费用

charge

float

订单生成时间

datetime

datetime

运单类型

orderType

Varchar（30）

附加服务

other

Varchar（30）

寄件人姓名（客）

jjName

Varchar（12）

寄件人地址

jjAddress

Varchar（30）

寄件人电话

jjTelphone

Char（11）

收件人姓名

sjName

Varchar（12）

收件人地址

sjAddress

Varchar（30）

收件人电话

sjTelephone

Char（11）

员工表（Employee）

属性描述

属性名称

类别

数据类型

实例

员工编号

employeeNo

主码

VarChar（30）

员工姓名

employeeName

Varchar（30）

性别

sex

Char（4）

年龄

age

int

联系电话

telephone

Varchar（20）

家庭住址

homeAdress

Varchar（40）

部门

department

Varchar（20）

职位

position

Varchar（20）

表2-2客户表

属性描述

属性名称

类别

数据类型

实例

编号

customerNo

主码

Char（8）

姓名

customerName

Varchar（12）

性别

Sex

Char

（1）

联系方式

Telephone

Char（11）

地址

adress

Varchar（11）

站点表

属性描述

属性名称

类别

数据类型

实例

站点ID

transferID

主码

VarChar（10）

名称

conveyerType

Varchar（30）

地址

departurePlace

Varchar（40）

运输器表

属性描述

属性名称

类别

数据类型

实例

运输器编号

conveyerNo

主码

VarChar（20）

运输器类型

conveyerType

Varchar（20）

2.2局部概念建模

2.2.1局部概念建模

1）业务分析与业务实体集的发现

客户表：

客户要在本公司运输包裹，则客户必须进行自己信息录入，并且客户的编号按照注册时间不同来生成。

同理接收包裹的用户也必须注册记录了自己的信息成为本公司的客户才能接收包裹。

这里存储的客户并不区分接收者与邮寄者。

包裹单——客户：

他们之间有两个联系是客户—收货—包裹和客户—发货—包裹。

分别产生确认接收单和包裹形成表。

确认接收单属性：

客户编号，包裹单号，接收时间，接收地点，经办人员，接收人姓名

包裹形成表：

客户编号，包裹单号，快寄时间，快寄地点，经办人员

包裹单是有客户寄包裹产生的：

客户快递的包裹要有信息记录因此生成快递单表。

快递单是货物的标识，即一个包裹有一个快递单，许多客户快递的不同包裹怎么区分开来，就要靠快递单的快递单号，有了快递单的唯一标识我们可以在快递单上记录详细信息。

其具体信息见数据字典部分。

快递单产生后，公司根据快递的起点和终点规划路线，即路线规划功能。

路线的规划原理：

我们要实现路线的连通，首先把可以直接到达的站点连起来将其运输方式和代价存在一张表中，之后根据这个直接联系的表把包裹单表的起始地址和终止地址联系起来。

便有了两张表：

直通线路表盒运输线路表。

直通线路表：

起点，终点，运输方式，运输距离，所耗时间，运输代价，

运输线路表：

运输路线序号，总方式，总路程，总时间，总代价

运输线路存储的是不同直通站点的序号因此这里需要一个弱实体集：

途径路线

途径路线表：

直通序号，标号（按顺序）

员工——运输器：

员工和运输器之间多对多联系集，无联系属性。

在每一个站点员工都要向不同的站点进行派送货物，员工用什么工具运输，运输到哪里这个需要公司进行管理，因此有员工——运输器之间的联系。

员工——站点：

每一个员工都属于唯一一个站点，对于每个站点中，都会有多个员工服务于它，且每个员工只属于一个站点。

该联系集是用于物流公司的内部成员管理，有无关属性职务。

来表示每个员工的职位。

路线——站点：

路线是由多个站点连接而成，每个路线会有多个站点，而每个站点会在多条路线中出现

路线——中转站：

路线信息表和中转站之间多对多联系集，无联系属性

员工——货物——站点：

包裹进入站点之后，站点要进行接收，由此派生出一个接收单，而每一个包裹都有一个员工接收，所以在接收单上也会有一个员工的信息；

包裹出站时，站点中的员工要进行派送，因此派生出一个派送单，而每一个包裹都会有一个员工负责，所以在派送单上也会有一个员工的信息。

客户前往快递公司寄快递，必须留下自身的联系方式等基本信息由此构成客户表，而客户又

每个订单都会有多个订单状态信息表，用于记录包裹在各个时段的状态。

在实现查询功能和包裹发生异常时会用到

订单——订单状态

订单记录了快递的起始和终止地址，我们要实现追踪的目标就要把包裹那时那刻在那个地方的信息记录下来。

这里建立了一个订单状态表，他依赖于订单存在，记录了订单目前所在地。

监控：

实体集订单和弱实体集订单状态信息表之间的一对多联系集

包含：

实体集订单与货物之间的一对一联系集，无联系属性

包裹在运输过程中需要运输人员，员工和包裹是多对多的联系。

标签号就是路线标号，该联系集表示的是：

某员工在某条路线上运输某件包裹。

会有接单日期作为无关属性。

包裹——路线标号——员工：

实体集货物与员工与运输路线之间多对多联系集

标签号，货物编号，员工编号，接单日期，二维码

每条路线会配对固定的运输方式，每个员工也会配对固定的运输器用于运输包裹

路线——运输器：

路线信息表和运输器之间多对多联系集，无联系属性

货物到达每个站点，该站点就会把该包裹编号记录下来。

该联系集用于统计每个站点的日流量。

货物——中转站：

中转站和货物之间多对多联系集

中转站编号，货物编号，接货日期

2）定义业务实体集

所以业务生成的实体集有：

快递单，接收单，派送单，运输管理单等。

3）

局部E-R图

上图为客户的划分

发件人和收件人分别对订单进行生成和接收：

由订单状态依附于订单的弱实体集：

货物拥有路线信息：

路线信息和中转站和运输器发生联系：

中转站和运输器分别与员工发生联系：

记录那些货物进入某中转站:

根据订单状态信息表统计异常订单：

货物衍生出智慧标签：

2.3概念模型（E-R图）

2.3.1概念模型（总E-R图）

2.3.2检查是否满足需求

上述概念模型的设计能够反映基本的业务流程：

快递寄出——中转——接收这一基本流程。

也能够追踪到快递的运输情况：

如到达哪一站，由哪位员工接手等。

但对于系统想要实现的比较高级的功能，如路径选择，打包等，还需进一步完善系统。

整个系统实现了客户a向客户b寄送快的流程，对于一定假设条件下，这个系统是成立的。

在路径规划方面我们存在缺点：

我们规定的路线是确定的，不能根据天气，路况等现实的一些突发情况做调整，可能会影响快递递送的效率。

但是我们是实行等级制可以确保递送时间不超过3天。

2.3.3改进的E-R图

在2.3.1和2.3.2小节的基础上，画出改进后的总体E-R图。

3逻辑设计

3.1关系数据库模式设计

根据E-R图进行转化得到关系数据库模式，并需要指出每一个关系的主码和外码（即说明数据库的码约束和外码约束）。

关系模式的转化：

（1）

在包裹运输途中包裹的状态信息存在于订单状态表中，而当包裹出现不能正常送达的时候我们有一个异常订单进行统计如下图：

异常订单（AbnormalOrder）实体集：

AbnormalOrder（orderNo,labelID,abnormalTime,abnormalSpace,abnormalMessage）

订单状态信息（OrderState）实体集：

OrderState（orderNo,nowSpace,scanTime,lastStation,nextStation,isNormal,getArrived）

（2）

货物（Goods）实体集：

Goods（orderNo,labelID）

智慧标签（IntelligentLable）实体集：

IntelligentLabel（orderNo,labelID,code）

（3）

路线——中转站联系集

（中转站ID，订单号，标签ID，接单日期）

智慧标签——员工联系集

（员工编号，订单号，标签ID，接单日期）

员工实体集

（员工编号，员工姓名，性别，电话，住址，中转站编号）

中转站实体集

（中转站编号，地名）

（3）客户--订单

收件人——订单联系实体集

订单号，收件人电话，订单人姓名

发件人——订单联系实体集

订单号，发件人电话，发件人姓名

（4）客户——包裹

订单实体集

订单号，运单类型，始发地，目的地，费用，生成订单时间

弱实体集：

订单状态信息

订单号，所在地，扫描时间，上一站，下一站，是否正常，是否到达

（5）

路线——中转站联系集

（中转站ID，订单号，标签ID，接单日期）

路线——运输区联系集

（运输器编号，订单号，标签ID，接单日期）

中转站实体集

（中转站编号，地名）

路线信息实体集

（标签ID，出发地，中转站1。

。

。

。

中转站n，终点站）

运输器实体集

（运输器编号，运输器类型）

（6）

中转站——员工联系集

（中转站ID，员工编号，员工姓名）

运输器——员工联系集

（运输器编号，员工编号，员工姓名）

中转站实体集

（中转站编号，地名）

路线信息实体集

（标签ID，出发地，中转站1。

。

。

。

中转站n，终点站）

运输器实体集

（运输器编号，运输器类型）

3.2关系数据库模式优化

如果根据E-R图转化得到的关系模式已经是符合3NF的，则该节不需要。

3.3完整性约束的说明

对于一些基本的数据库完整性约束规则（如码约束、外码约束和属性取值约束等），需要在定义数据库的脚本中进行定义（见5.1节要求）；对于一些较复杂的数据库完整性约束规则，需要通过定义触发器来实现（见5.2节要求）。

因此，本节需要对1.4.4小节分析得到的所有完整性约束规则进行适当的说明，包括：

哪些已实现（需要指出在前面的什么地方通过什么手段实现的）？

哪些拟实现（需要指出在后面的什么地方通过什么手段来实现）？

哪些还没有实现？

4物理设计

4.1确定数据库的存储结构

根据对数据库中数据规模的调查和预测结果、数据库使用中频繁查询的调查和预测结果以及性能需求分析的结果，设计数据库的物理模型，主要包括存储结构和存取方法。

也可以考虑对关系模式进行适当调整，允许适当的数据冗余以减少频繁查询中关系表之间的连接运算的数量，以提高频繁查询的访问速度，满足系统的性能要求。

4.2确定数据库的存取方法

5数据库应用与安全设计

5.1数据库脚本

在定义数据库的脚本中应包括基本的数据库完整性约束规则的定义。

5.2数据库完整性设计

主要是通过触发器定义一些复杂的数据库完整性要求。

5.3数据库安全性设计

角色、用户与权限设置，使用视图保证数据安全的说明。

5.4存储过程设计

对一些重要的查询、统计分析和报表功能，需要设计其实现程序（即存储过程），一般都需要使用游标。

6数据库应用开发

蓝色部分是可选的。