长途汽车信息管理系统【课程设计-java-数据库】

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

长途汽车信息管理系统

2021年12月

长途汽车信息管理系统

2. 3.数据库结构设计 2. 3.1.需求分析

(1)

系统管理对象

长途汽车信息管理系统涉及的人有2类,登录系统希望买票的乘客、系统管理员,管 理的事务有车辆、路线信息、订单信息、车票信息。

(2)

实体间联系

实体之间主要事务联系如下:

用户向管理员提出实名认证申请。

用户可查询相应的路线、车票、订单信息,可修改个人用户信息。 管理员审核实名认证信息,管理用户信息。 管理员维护车辆信息、增删改路线信息及车票信息

管理员可对车辆信息、车票信息、订单信息等进行统计分析。

(3) 功能需求

能够进行数据库的数据定义、数据操纵、数据控制等处理功能。

具体功能应包括:系统应该提供管理员对车辆、路线、车票、订单信息的添加、插入、 删除、更新、查询操作;同时实现用户对车辆、路线、车票、订单的查询,以及对个人用 户信息的修改、查询功能。

(4)

安全性与完整性需求

对于长途汽车信息管理系统而言,涉及的实体较多,要维护好不同实体表之间的管理 关系,涉及相应的外围程序,保证数据输入的完整性。同时要对注入信息进行识别并拦截, 防止数据库被恶意破坏。

图3. 3系统组成设计图

实名认证申请

2. 3. 2.概念结构设计

根据上文分析,本系统主要实体有乘客(用户)、管理员、车辆信息、路线信息、订单信息、车票信息。

主要涉及的实体间联系有:用户、车票信息与订单信息之间存在“订购”的联系,且一个用户可购买多种车票,一种车票可被多位顾客购买,故涉及的关系为多对多关系。车票信息与车辆信息之间存在“承载”关系,说明该车票所应搭乘的汽车,一类车票搭乘一辆汽车,汽车可承载多路车票的运行,所有车票信息与车辆信息之间为多对一关系。车票与路线之间存在“经由”关系,一类车票具有唯一确定的路线,一条路线可由不同时段的多种车票经由,所以车票信息与路线信息为多对一关系。

各实体所涉及的属性如下:

乘客(乘客ID,姓名,性别,联系方式,身份证号,登录密码)

车辆(车辆ID,车牌号,座位数,总里程,运行状态,投用时间)

路线(路线ID,始发站,终点站,总距离)

车票(车票ID,数量,始发时间,到达时间,车票价格)

订单(订单ID,生成时间,支付状况)

根据以上设计,可以得到实体联系ER图及概念模型图如图3.4和图3.5所示。

图3. 4实体联系ER图

图3. 5概念模型

2. 3. 3.逻辑结构设计

(1)概念模型转换为逻辑模型

完成了概念模型的设计,以下将利用概念模型转换为逻辑模型的六条原则,对上述概念模型进行处理。

根据设计原则一,将各实体转换为关系表,各表结构如下:

>乘客(乘客ID,姓名,性别,联系方式,身份证号,登录密码)

■.gender.contactJd.card)

>车辆(车辆ID,车牌号,座位数,总里程,投用时间)

■Bus(Bid,busNum)seats,total_dis)bir_time)

>路线(路线ID,始发站,终点站,总距离)

■Route(Rid,start_station,end_station,totalDis)

>车票(车票ID,数量,始发时间,到达时间,车票价格)

■Ticket(Tid,number,depart_time,arr_time,price)

>订单(订单ID,生成时间,支付状况)

■Porder(Oid,genTime,ispay)

根据多对一关系的设计转换原则,将车票与车辆之间多对一的承载关系,转化为将车辆的主键作为外键,吸取到车票信息中;同理,将车票与路线之间的多对一“运行于”关系,转化为将路线的主键作为外键,吸取到车票信息中。因此,“车票”的新结构如下:车票(车票ID,车辆ID,路线ID,数量,始发时间,到达时间,车票价格)

•Ticket(Tid,Bid,Rid,number,departjjme,air_timeprice)F K:Bid,Rid

根据多对多关系的设计转换规则,将乘客与车票之间多对多的“购买”关系,转换为一个新的“订单”表,并吸取“乘客”的主键及“车票”的主键作为“订单”表的外键。据此,“订单”表的结构如下:

>订单(订单ID,乘客1D,车票1D,生成时间,支付状况)

・Porder(Oid,Pid,Tid,genTime,ispay) FK:Pid,Tid

(2)关系模型定义

根据以上分析,该此数据库设计关系定义模型如下:

>乘客(乘客ID,登录密码,姓名,性别,联系方式,身份证号)

•.gender.contact.ld.card)

主键为Pid,属性间的函数依赖关系:

FD: {Pid,ld_card->pwd,name,gender,contact}

>车辆(车辆ID,车牌号,座位数,总里程,投用时间)

■Bus(Bid1busNum,seats,total_dis,bir_time)

主键为Bid,属性间的函数依赖关系:

FD: (Bid,busNum->seats I total_dis,bir_time)

>路线(路线ID,始发站,终点站,总距离)

•Route(Rid,start_station,end_station,totalDis)

主键为Rid,属性间的函数依赖关系:

FD: (Rid,start_station,end_station ->totalDis)

>车票(车票ID,车辆ID,路线ID,数量,始发时间,到达时间,车票价格) ,Ticket(Tid,Bid,Rid,number,depart_time,arr_time,price)

主键为Tid、Bid、Rid三个属性够成的表间依赖FK1:Bid依赖于bus表,FK2:Rid 依赖于route表。

属性间的函数依赖关系:

FD: (Tid,Bid,Rid,depart_time,arr_time ->number,price)

>订单(订单ID,乘客ID,车票ID,生成时间,支付状况) ■Porder(Oid,Pid,Tid,qenTime,ispay)

主键为Oid、Bid、Tid三个属性够成的表间依赖FK1:Bid依赖于Bus表,FK2:Tid 依赖于Ticket表。

属性间的函数依赖关系:

FD: (Oid.Pid.Tid.genTime ->ispay)

相关文档
最新文档