1.项目介绍
众所周知，用户使用打车软件的出行体验越好，其今后持续使用打车软件的意愿就会越强烈，但在实际生活中，由于在不同的区域、不同的时段，有车辆需求的乘客数量不同，因此有可能出现处于空载状态的车辆过多以及乘客所在区域车辆供不应求的情况，就会对用户出行的服务体验感造成一定的负面影响以及会使用户使用打车软件的意愿有所降低。
因此，为了解决上述等情况，此打车系统能够准确统计出成都各个区域在不同时间段内的出行量，以便预测出在未来的某一时间段内哪些区域的出行需求量较大，并可以根据人们在打车软件中的用车请求指向性地提前对运营车辆提供一些引导，对车辆进行调度，以求最大程度上缩短乘客的等车时长，解决早晚高峰时期打车困难的问题，进而在更大程度上满足用户的用车需求，同时能够缓解交通压力，提升乘客的整体出行体验，从而加强用户的绩效期望。
2.需求分析
实现一个打车出行系统，其系统设计要求包括乘客信息管理、司机信息管理、打车公司信息管理、车辆信息管理、订单信息管理五部分。面向的用户分为乘客、司机、打车公司、管理员，因此针对不同的用户群体需要满足其特定的功能需求：
(1).乘客。乘客能够注册登录并对个人信息进行更改，发起订单匹配车辆开始行程，并且可以查询自己的订单信息，包含车辆信息、乘车人数、行程时间及地点等具体信息。
(2).司机。司机能够注册入职打车公司并对个人信息进行更改，接单完成行程，并且可以查询自己的订单信息，包含乘客信息、车辆信息、乘车人数、行程时间及地点等具体信息。
(3).打车公司。打车公司能够注册入驻并对公司信息进行更改，可查询本公司的司机详细信息及订单信息，统计司机人数和订单总数，了解公司的业绩情况。
(4).管理员。系统管理员具有对打车出行系统进行管理和操作的最高权限，能够查看后台的程序和数据，并能对不同用户设置和调整权限，保证数据的完整性和安全性。
3.数据库设计
3.1 系统概念模型(E-R图)设计
数据库设计的优劣不但会影响应用系统的运行效率，同时还会影响程序实现的效果。因此，设计合理的数据库模型不仅可以提高数据存储的效率，保证数据的一致性和完整性，也有利于程序功能的实现。
该打车出行系统主要面向乘客、司机、打车公司，因此包括乘客实体、司机实体、打车公司实体、车辆实体以及订单实体。
此打车出行系统的E-R图如下：

其各个实体间的关系图如下：

3.2 逻辑结构设计
E-R模型向关系模型的转换如下：
打车公司(公司编号，公司名称)
车辆(车牌号，车辆服务类型，车辆颜色，车辆型号，里程单价，时长单价)
司机(编号，姓名，性别，联系电话，车牌号，公司编号，入职时间)
乘客(编号，姓名，性别，联系电话)
订单(订单号，乘客编号，车牌号，乘车人数，起始地，目的地，开始时间，结束时间)
4.数据库实现
4.1 表
表是数据库中最重要的对象，表的设计和创建是数据库的前提和基础，对整个系统架构的设计尤为重要。现基于分析及需要，本打车出行系统共建立了乘客信息表、打车公司信息表、司机信息表、车辆信息表、订单信息表五张表。下面以乘客信息表、司机信息表和订单信息表为例来具体说明表的设计和创建过程。
乘客信息表应包含下列信息：乘客编号、姓名、性别、联系电话。通过create table passengers语句建表，设置乘客编号的数据类型为int，作为唯一主键，唯一且非空；设置姓名的数据类型为varchar，非空约束；设置性别的数据类型为char，默认值约束、检查约束；设置联系电话的数据类型为bigint，非空约束、唯一约束。
司机信息表应包含下列信息：司机编号、姓名、性别、联系电话、车牌号、公司编号、入职时间。通过create table drivers语句建表，设置司机编号的数据类型为int，作为唯一主键，唯一且非空；设置姓名的数据类型为varchar，非空约束；设置性别的数据类型为char，默认值约束、检查约束；设置联系电话的数据类型为bigint，非空约束、唯一约束；设置入职时间的数据类型为date，是司机与打车公司之间的隶属联系的属性；车牌号和公司编号均为外键，车牌号引用车辆表中的主键number，公司编号引用打车公司表中的主键id。
订单信息表应包含下列信息：订单号、乘客编号、车牌号、乘车人数、起始地、目的地、开始时间、结束时间。其中订单号作为唯一主键，乘客编号和车牌号均为外键。
本文从乘客、司机、交通情况等实际需求出发，分析并设计了基于SQL Server数据库的打车出行系统，此打车系统会根据人们在打车软件中的用车请求对车辆进行调度，进而在更大程度上满足用户的用车需求，力求最大程度上提升乘客的出行体验，加强用户的绩效期望。
在当前以服务型经济为主导的社会经济*下，对于打车出行系统来说，需要不断完善和优化软件功能，力求为用户提供更高质量的服务，最大程度上提升用户的出行体验，从而加强用户的绩效期望和使用意愿。