A279-flask实现城市公共交通数据查询预测智慧系统
导出时间:2025/11/26 14:31:09
【购买前必看】
1、关于我们
深度学习乐园是由python哥全职技术团队组建运营【团队成员为:复旦大学博士、华东理工爱丁堡博士、格拉斯哥博士、纽约大学硕士、浙江大学硕士】。
我们只做python业务,精通sklearn机器学习/torch深度学习/django/flask/vue全栈开发。
2、关于项目
我们从2018年开始,就专注于深度学习sci、ei、ccf、kaggle等,至今已有7年,共发表过10多篇顶刊顶会。
官网累积了数百个项目,已有3000多学员付费购买,圈子内有口皆碑:www.zzgcz.com (更多高级私密项目无法对外,联系微信定制:zzgcz_com)
3、售后承诺
包远程安装调试,所有项目均在本地运行通过,大部分都有截图和录屏。
支持二次修改,所有项目都是我们自己写的,改起来也非常容易。
加急定制1-2天可完成,这就是实力证明,远程验收满意后再付全款!
所有客户终身售后。兼职的人家都有主业,谁愿意持续服务你?
注:此html可能格式或图片显示不全,请购买后查看docx文档
概述
- 课题背景
当前,全球信息技术呈加速发展趋势,信息技术在国民经济中的地位日益突出,信息资源也 日益成为重要的生产要素。随着信息技术的不断发展,城市信息化应用水平不断提升,智慧城市建设应运而生。智慧城市正是在充分整合、挖掘、利用信息技术与信息资源的基础上,汇聚人类的智慧,赋予物以智能,从而实现对城市各领域的精确化管理,实现对城市资源的集约化利用。 建设智慧城市在实现城市可持续发展、引领信息技术应用、提升城市综合竞争力等方面具有重要意义。
随着城市化的快速推进,城市规模不断扩大,动车数量的增加和城市行车环境的恶化让交通问题也日益凸显。公共交通是我国城市居民出行的重要交通方式,其拥有大运量、低成本和高效环保的特点,正日渐成为发展城市交通关注的焦点。目前,“优先发展城市公共交通”是世界各国公认的解决城市交通问题的最佳策略。对公共交通进行合理的调配不仅可以为公交集团节约成本、 创造更大的利益,更重要的是可以节约资源助力城市实现高质量可持续发展。
经济快速发展的同时,城市内的客流量也在逐渐增大,这使得合理精确地进行城市的公共交通调配成为了一个不小的挑战。城市公共交通是随客流、道路条件、天气、时间等不断变化的随机服务系统,实现高效的公交运营系统需要多方面的努力,能准确地做出公交线路客运量的预测 是实现公交运营调度优化的基础,是公交系统规划的关键,也是进行科学决策的重要依据。
为了应对这一挑战,智慧城市更加受到人们的关注。城市计算作为智慧城市的核心技术之一, 通过收集和分析城市运行数据,为城市管理者提供决策支持,从而优化城市资源配置,提高城市 运行效率。交通预测、流量预测以及需求预测作为城市计算的重要组成部分,对于提升城市交通系统的智能化水平具有重要意义。
- 应用目的
本项目旨在搭建一个城市公共交通(主要是公交车和地铁)数据查询预测平台,采集、处理、 分析城市公共交通数据,并在此基础上预测公共交通状况。公共交通是重要的城市基础设施之一, 而数据采集是公共交通系统管理和优化的重要手段。公共交通数据主要包括车辆位置、即将到站信息、乘客数量、交通速度等数据,这些数据都可以帮助管理部门、企业和乘客更好地管理、运营和利用公共交通系统。
一方面管理部门可以利用采集的数据实现公共交通优化。公共交通的优化需要管理部门对运营状况进行实时监控和数据分析预测,以便及时调整交通车辆调度、线路规划等。这些调整需要根据实时的数据信息进行决策,数据采集为决策提供必要的依据。管理部门能够通过数据分析,了解乘客出行需求的变化,优化线路和班次计划,提高公共交通系统的效率和服务质量,同时提高运营效益创造更多的运营收益。
另一方面乘客也利用采集的数据实现出行体验优化。对收集数据进行分析预测,让乘客能够快捷方便地查询城市的公共交通信息,了解到自己乘坐的公交车客流情况、到站时间、乘车位置、 预计到达时间等信,减少等待时间,提高整体出行便利度。
需求分析
- 用户需求分析
基于提供的课题背景和应用目的,我们可以从普通用户和管理者的角度分别进行需求分析,确保平台功能能够满足两类用户的需求。
- 用户信息管理功能
用户信息管理,包括普通用户的注册、登录、修改密码功能,以及管理员对用户的管理功能。
- 普通用户信息管理
注册:
- 用户可以通过提供用户名、密码、邮箱等基本信息,在系统中注册新账号。
- 系统应验证用户名和邮箱的唯一性,确保没有重复的用户账户。
- 注册成功后,系统会向用户提供的邮箱发送确认邮件,以完成邮箱验证。
登录:
- 用户通过用户名和密码登录系统。
- 登录时,系统应验证用户名和密码的正确性,若正确则允许登录。
- 验证密码时使用加密的散列函数进行匹配,不存储明文密码。
- 防止暴力破解的措施,例如多次失败后账户暂时锁定或使用CAPTCHA验证。
修改密码:
- 用户可以通过登录后的“账户设置”页面修改自己的密码。
- 用户需输入当前密码、新密码和确认新密码,系统验证当前密码正确后允许修改。
- 管理员信息管理
管理员账号无法注册生成,需要开发者在后台添加,登陆和修改密码功能和普通用户一致,除此外还拥有以下功能
查看:
- 管理员可以查看所有注册用户的列表,包括用户名、邮箱、注册时间、角色等基本信息。
- 管理员可以根据用户名或邮箱进行搜索。
添加用户:
管理员可以通过用户管理页面为系统添加新用户,指定用户名、密码、邮箱,系统应验证用户名和邮箱的唯一性。
删除用户:
- 管理员可以删除指定用户的账户。
- 删除操作需谨慎,系统应提示确认,删除后用户的相关信息将无法恢复。
- 普通用户对智慧系统的功能需求
- 公交信息查询预测
- 普通用户希望能随时查询公共交通工具的运营信息,包括静态信息和动态信息。静态信息包括:运营时间、票价、路线、发车时间到站时间等基本信息。动态信息包括:交通工具实时运营状态、拥挤情况、实时位置。
- 系统应具备预测功能,根据静态和动态信息预测公交或地铁的到站时间以及到达时间。用户希望能够获取交通工具的实时拥挤情况,帮助合理安排出行。系统还最好能预测拥挤情况,提前告知用户是否有可能出现延误或拥堵情况,帮助用户更好地安排出行,选择不拥挤的交通工具和出行时间。
数据可以基于车载传感器提供实时人数统计或基于历史数据进行预测。
- 出行路线规划推荐
- 用户可以输入起点和目的地,系统根据用户输入规划最佳公交路线,系统会提供多种方案供用户选择,显示换乘方式和所需时间。系统应能够根据实时公交信息动态调整路线规划,若某条线路拥堵或出现延误,系统应自动提供替代路线。
- 系统基于用户输入的起点和终点,结合交通工具的实时运营信息,为用户提供偏好最优出行路线。考虑路况、天气、交通拥堵等因素,智能推荐适合的交通工具和路线。
- 管理者对智慧系统的功能需求
- 公共交通流量监控
管理者可以通过平台实时监控各交通工具的客流量和交通状况,及时了解交通流量的变化。数据应包括车辆的实时位置、乘客数量、行驶速度等,确保管理者可以根据实时数据做出快速反应。
- 公共交通流量预测
基于历史数据和实时数据,系统应能够为管理者提供公共交通流量的预测,帮助管理者提前做好应对方案,优化调度。管理者可以利用预测数据提前调配车辆、调整班次,确保高峰期或特殊事件期间交通资源的高效配置。
- 线网优化
系统应为管理者提供线网优化建议,基于客流数据和出行需求,优化交通线路布局和站点设置。通过数据分析,管理者可以识别出低效线路,规划新的线路以更好地服务城市居民出行。
- 调度管理
管理者可以通过系统进行交通工具的调度管理,根据实时情况调度车辆、增减班次、调整路线。系统应支持调度管理的自动化和智能化,减少人为干预的时间,提升调度效率。
- 公共交通事件信息发布
系统应具备公共交通事件发布功能,在突发事件(如车辆故障、交通事故、天气恶劣)时,管理者可以通过平台发布相关信息,通知用户。该功能应能及时、广泛地将信息传达给所有相关用户,帮助乘客调整出行计划。
- 其他需求分析
- 数据需求
- 交通工具运营时间数据:包括各公交和地铁线路的运营时间表、首班车和末班车时间等。
- 实时交通流量数据:包括各线路、站点和交通工具的实时客流量、历史客流数据等。
- 票务数据:包括票价信息、售票记录等。
- 天气数据:包括当前和预测的天气状况,对交通流量预测有重要影响。
- 节假日信息: 节假日对交通流量有显著影响,系统需要考虑这些特殊日期的流量变化。
- 性能需求
- 高效的数据处理能力:系统应能处理大规模数据,快速响应用户查询,确保在高峰时段的 高并发访问下仍能保持稳定。
- 实时性:系统需具备实时更新和显示数据的能力,确保用户和管理者获取的都是最新的交通信息。
- 扩展性:系统设计应支持未来的扩展需求, 包括添加新的交通工具、增加新的数据源、升级数据处理算法、引入新的预测模型等。
- 数据安全:系统需确保数据的安全性和隐私保护,包括数据的存储、传输和访问控制。
- 权限管理:系统应实现不同用户级别的权限控制,确保普通用户和管理者只能访问和操作各自权限范围内的数据和功能。
- 用户界面需求
- 友好的用户界面:提供简洁、直观的用户界面,方便用户查询交通信息和管理者监控系统。
- 多种数据展示形式:支持表格、图表、地图等多种数据展示形式,帮助用户和管理者直观 理解数据和预测结果。
- 数据字典
- 数据存储条目
数据存储的信息完全包含在关系表设计部分,该部分在5.2节,为了避免报告冗余,提高可读性该部分省略数据存储条目。
- 数据流条目
用户发出的操作数据流条目较为简单,如注册、登陆、修改、添加、删除、查询等,这些不做解释,读者很容易理解,给出其他数据流条目如下:
- 预测操作
数据流名
| 预测
|
说明
| 将预测操作数据流传入智慧系统,进行预测
|
来源
| 普通用户或管理用户
|
去向
| 智慧系统中的预测处理部分
|
组成
| 时间+[站点|线路]
|
- 发布操作
数据流名
| 发布
|
说明
| 用于发布公共交通事件
|
来源
| 管理用户
|
去向
| 公共交通事件存储表
|
组成
| 公交事件
|
- 规划操作
数据流名
| 规划
|
说明
| 将规划操作数据流传入智慧系统,规划线路
|
来源
| 普通用户
|
去向
| 智慧系统中的规划处理部分
|
组成
| 时间+起点+终点
|
- 调度操作
数据流名
| 调度
|
说明
| 将调度操作数据流传入智慧系统,调度公交
|
来源
| 管理用户
|
去向
| 智慧系统中的调度处理部分
|
组成
| 时间+[智能调度|手动调度]+(调度计划)
|
- 路线优化操作
数据流名
| 路线优化
|
说明
| 将路线优化操作数据流传入智慧系统,优化公交线路
|
来源
| 管理用户
|
去向
| 智慧系统中的调度处理部分
|
组成
| 时间+[智能优化|手动优化]+(优化计划)
|
- 查询结果
数据流名
| 查询结果
|
说明
| 输出查询结构
|
来源
| 用户查询的数据表
|
去向
| 处理部分或用户
|
组成
| 对应查询表的表项
|
- 预测结果
数据流名
| 预测结果
|
说明
| 站点人流预测结果
|
来源
| 预测处理部分
|
去向
| 预测存储表
|
组成
| 人流预测表项
|
- 规划结果
数据流名
| 规划结果
|
说明
| 智能系统规划的多条路线
|
来源
| 规划处理部分
|
去向
| 用户
|
组成
| {规划路线表项}
|
- 反馈
数据流名
| 反馈
|
说明
| 反馈用户操作是否成功
|
来源
| 调度或优化处理部分
|
去向
| 管理用户
|
组成
| {规划路线表项}
|
- 数据处理条目
本部分给出最基本最关键的数据处理条目。
- 公交查询
处理名
| 查询
|
描述
| 实现数据查询
|
输入数据流
| 查询操作流
|
输出数据流
| 查询结果
|
处理逻辑
| 根据输入内容查找对应存储,输出查询内容
|
- 人流预测
处理名
| 预测
|
描述
| 预测站点或路线人流
|
输入数据流
| 预测操作流+查询信息
|
输出数据流
| 查询操作+预测结果
|
处理逻辑
| 发出查询操作,结果作为输入,进行预测
|
- 路线规划
处理名
| 规划
|
描述
| 根据预测,规划合适出行路线
|
输入数据流
| 规划操作流+预测结果
|
输出数据流
| 预测操作+规划结果
|
处理逻辑
| 发出预测操作,结果为输入,进行规划
|
- 交通工具调度
处理名
| 调度
|
描述
| 调度公共交通工具
|
输入数据流
| 调度操作
|
输出数据流
| 调度反馈
|
处理逻辑
| 可手动调度和一键调度,给出完成反馈
|
- 线路优化
处理名
| 优化
|
描述
| 优化或修改当先线路
|
输入数据流
| 优化操作
|
输出数据流
| 优化反馈
|
处理逻辑
| 可手动修改路线或一键优化,给出完成反馈
|
- 数据流图
- 顶层图
- 1层图
- 2层图智慧公交系统部分
可行性分析
可行性分析的目的是评估系统开发和实施的可能性,以确保项目能够顺利进行并实现预期目标。主要从技术可行性和应用可行性两个方面进行分析。
- 技术可行性
技术可行性评估项目实施过程中所需的技术要求、技术资源的可行性,确保项目能够顺利开发和运行。
- 数据来源:
以上海市为例,城市公共交通系统的数据来源可以分为多种类型,涵盖了静态和动态数据。主要的数据来源包括交通管理部门、公共交通企业、交通工具的传感器设备、第三方数据服务等。以下是各类数据来源的详细描述
上海市交通管理部门数据
- 数据类型:静态数据和动态数据。
- 数据来源描述:上海市的交通管理部门,如上海市交通委员会,定期发布公交线路、地铁线路、票价、运营时间等公共交通的基础信息。这些数据一般以API或文件格式发布,供公共服务平台使用。
- 获取途径:通过与上海市交通委员会的合作或访问其开放数据平台,能够获取最新的公交和地铁的静态信息。
- 数据内容:
- 公交和地铁的运营时间、票价信息、固定路线。
- 特定时段或线路的客流高峰信息。
- 站点分布信息,包括公交站点和地铁站点的位置坐标等。
上海公共交通企业数据
- 数据类型:动态数据和历史数据。
- 数据来源描述:主要包括上海市公交集团和上海地铁运营公司等交通运营单位,这些企业通过智能调度系统和自动化设备,实时监控并记录公交车、地铁的运行状态。
- 获取途径:可通过与公交企业的合作,或者利用公交企业提供的开放接口和数据文件,实时获取运营数据。
- 数据内容:
- 公交和地铁的实时位置信息,车厢内的乘客数量。
- 公交和地铁的速度、到站时间、发车时间、实际运行路线等信息。
- 线路的历史运营数据,用于客流量预测和交通优化分析。
交通工具上的传感器设备数据
- 数据类型:动态数据。
- 数据来源描述:上海市的公交车和地铁通常配备有GPS定位设备、客流量传感器、速度计、视频监控等设备。通过这些传感器,能够实时采集交通工具的运营数据,提供精确的定位、乘客数量、车速等信息。
- 获取途径:通过传感器集成系统,定期将采集的数据传输至云端服务器,并通过实时数据接口开放供平台查询。
- 数据内容:
- GPS实时定位,提供公交车或地铁的当前地理位置。
- 车厢内的客流量数据,基于传感器的实时人数统计。
- 实时速度,提供车辆的行驶速度,用于判断是否存在延误。
第三方数据服务
- 数据类型:动态数据和外部数据。
- 数据来源描述:上海市的第三方地图服务(如高德地图、百度地图)提供开放的API服务,能够获取实时的交通流量数据、道路拥堵情况、天气等外部数据。这些数据可以为公共交通的流量预测和路线规划提供外部参考。
- 获取途径:通过第三方地图服务的API,按需获取实时路况和天气数据。
- 数据内容:
- 上海市的实时路况和交通拥堵信息,便于公交路线的动态调整。
- 天气数据,能够影响客流量和出行需求(如降雨会增加地铁使用率)。
- 假期或重大事件期间的特殊交通信息(如活动路线、封路等)。
- 数据处理与实时监控技术:
- 系统需要处理交通工具的实时数据和历史数据。可以使用 WebSocket 或 消息队列(如RabbitMQ, Kafka) 来传输实时数据,如公交车位置信息、乘客数量、道路拥堵状况等,以确保数据的实时性。
- 数据分析和预测功能可以依赖于机器学习模型,比如基于时间序列的流量预测模型。对于复杂数据处理和预测,可以选择使用 Python 的 scikit-learn 或 TensorFlow 等机器学习库。
- 地图与定位技术:
- 系统可以集成 Google Maps API、Mapbox 或 高德地图 API 等第三方地图服务,以实现公交路线展示、站点分布和交通工具实时定位等功能。
- 通过 GPS 和移动互联网获取交通工具的实时位置信息,并展示在地图上,为用户提供实时公交信息。
- 应用可行性
应用可行性评估系统的实际应用效果、潜在的用户需求以及系统上线后的可用性,确保项目的实际价值和用户体验。
- 社会需求和用户基础:
- 随着城市化进程的加快,城市交通面临越来越大的压力,尤其是在高峰时段。公共交通作为主要出行方式之一,存在管理优化的强烈需求。用户希望通过一体化平台便捷地查询公交信息,合理安排出行时间。
- 系统的目标用户群体较为广泛,涵盖普通居民、通勤者以及交通管理部门的工作人员。平台能够显著提升出行体验、减少等待时间,并提高公共交通的管理效率。
- 功能的实用性:
- 平台功能设计针对公交车和地铁的实时信息查询、路线推荐、交通流量预测等用户需求,能够帮助用户合理安排出行。通过提供实时的到站提醒、路线规划等功能,系统能够提升用户的出行便捷性。
- 对管理者而言,系统的流量监控、流量预测、调度管理和事件发布功能可以优化资源配置,实现交通资源的高效利用,并增强城市交通的整体管理水平。
- 潜在的商业价值:
- 该系统在实现公共交通信息管理优化的同时,也具备拓展其他商业化功能的潜力。例如,通过平台发布公交和地铁的广告、推送出行活动等,可以实现一定的广告收入。
- 此外,系统的数据分析和流量预测功能对商业投资有潜在价值,可为交通工具扩展、站点布局提供数据支持。
- 社会影响:
- 通过提供实时公交信息和路线推荐服务,平台能够减少用户等待时间,促进绿色出行,减少私家车的使用频率,具有良好的社会效益。
- 系统的应用将提升公共交通的吸引力和效率,缓解城市交通压力,增强居民对智慧交通的信任度和使用意愿。
概念设计
- 实体
- 用户实体
用户实体存储系统用户的基本信息,属性描述如下:
·用户标识 (User_ID):主键,用于唯一标识每个用户
·用户名 (Username):用户登录名
·密码 (Password):用户登录密码
·邮箱 (Email):用户联系邮箱
·角色标识 (Role_ID):外键,关联角色实体
![]() |
图3.1 用户实体
- 角色实体
角色实体记录了系统中不同角色的信息,如管理员、普通用户等,属性描述如下:
·角色标识 (Role_ID):主键,用于唯一标识每个角色
·角色名称 (Role_Name):角色名称,如管理员、普通用户
·角色描述 (Role_Description):角色的描述信息
图3.2 角色实体
- 位置实体
位置实体用于记录位置信息,,属性描述如下:
·位置ID (Location_ID):主键,用于唯一标识每个位置的标识符。
·城市区域 (City_Area):记录位置所属的城市区域
·经度 (Longitude):记录位置的地理经度。
·纬度 (Latitude):记录位置的地理纬度。
图3.3 位置实体
- 载具实体
载具实体记录了系统中所有交通载具的静态和动态信息,属性描述如下:
·载具ID (Vehicle_ID):主键,用于唯一标识每个交通工具
·载具种类 (Vehicle_Type):外键,记录交通工具的种类(如公交车、地铁等)
·工作线路 (Route_ID):外键,记录载具的固定线路标识
·位置 (Location_ID):外键,实时更新的地理位置
·速度 (Speed):实时更新的速度
·乘客人数 (Passenger_Count):实时更新的载具内人数
图3.4 载具实体
- 站点实体
记录公共交通站点信息,包含属性如下:
·站点ID (Station_ID):主键,用于唯一标识每个站点
·名称 (Station_Name):站点名称
·类型 (Type):站点类型(如公交站、地铁站)
·位置 (Location_ID):外键,地理位置
·线路 (Route_ID):外键,关联经过该站点的所有交通线路
图3.5 站点实体
- 线路实体
记录交通线路信息,由于线路中途径点是多值属性,因此每一个属性要建立一个元组,同一路线ID下的所有站点依次序连接组成路线,包含属性如下:
·线路ID (Route_ID):主键,用于唯一标识每条线路
·线路名称 (Route_Name):线路的名称
·线路类型 (Type):线路类型(如公交线路、地铁线路)
·站点数目 (Station_Cnt):线路上站点总数
·站点ID (Station_ID):外键,站点标识
·站点次序 (Station_Orderc):标识站点在路线中的次序
·下一站路程 (Next_ Dis):到下一站的路程
图3.6 线路实体
- 载具信息实体
记录不同类型交通工具的票价信息和描述信息。属性描述如下:
·载具类型 (Vehicle_Type):主键,标识载具类型
·计费类型 (Fare_Type):计费类型(如固定计费、按里程计费、分段里程计费)
·票价 (Price):票价
·载具描述 (Vehicle_Info):载具的描述信息
图3.7 票价实体
- 客流数据实体
记录站点的特点时段的客流情况,也可以是通过模型预测的未来时段客流数据信息,站点、日期、时段为一个主键,属性描述如下:
·站点 (Station_ID):外键,关联站点实体
·日期 (Date):日期
·时间段 (Time_Slot):时间段
·进站人数 (Entry_Count):进站人数
·出站人数 (Exit_Count):出站人数
图3.8 客流数据实体
- 天气实体
记录天气相关信息,包括日期、位置、温度(最高/最低)、湿度、风力(最大/最小)、天气类型和空气质量。
·日期 (Date):日期
·位置 (Location_ID):外键,地理位置
·温度 (Temperature):最高温度/最低温度
·平均湿度 (Humidity):平均湿度
·风力 (Wind_Power):最大风力/最小风力
·天气类型 (Weather_Type):白天/夜间
·空气质量 (Air_Quality):空气质量指数
图3.9 天气实体
- 节假日实体
记录节假日信息,包括名称、开始日期和结束日期。
·名称 (Holiday_Name):节假日名称
·开始日期 (Begin_Date):节假日开始日期
·结束日期 (End_Date):节假日结束日期
图3.10 节假日实体
- 实体联系设计
- 用户角色联系
映射基数:多对一
联系描述:每个用户拥有一个角色信息,一个角色可以被多个用户拥有。
图3.11 用户角色联系图
- 用户查询/更改联系
联系描述:每个用户可以查询自己需要的数据实体,管理员也可以更改相应实体,由于该联系简单且涉及实体过多,这里简略介绍。
- 位置相关的联系
映射基数:一对多
联系描述:多个实体包含位置信息:站点、载具、天气 。每个实体实列都有唯一的位置信息,多个不同的实体实例可以同时位于一个位置。下图给出位置和站点的联系图。
图3.12 位置和站点联系图
- 载具和载具信息联系
映射基数:多对一
联系描述:每个载具拥有一个载具信息,一种载具信息可被多个载具拥有。
图3.13 载具和载具信息联系图
- 载具线路联系
映射基数:多对一
联系描述:每个载具有一个固定的工作线路,一条线路上可以运行多个载具。
图3.14 载具线路联系图
- 线路站点联系
映射基数:多对多
联系描述:每个站点可以属于多条线路,每条线路包含多个站点。
图3.15 站点线路联系图
- 用户角色联系
映射基数:多对一
联系描述:每个用户拥有一个角色信息,一个角色可以被多个用户拥有。
图3.16 用户角色联系图
- 站点客流信息联系
映射基数:一对多
联系描述:一个站点拥有多个时段的客流信息。
图3.17 站点客流信息联系图
客流信息与天气节假日联系
映射基数:一对多
联系描述:同一时段内站点客流信息对应唯一的天气与节假日信息,而同一天气与节假日可以对应多个站点客流信息。下面示例给出节假日和客流数据的联系
图3.18 节假日和客流数据联系图
- 全局E-R图
逻辑设计
关系模型设计
关系表设计
- 关系表设计
- 用户表(Users)
字段名
| 数据类型
| 约束
| 描述
|
lid
| INT
| 主键,自动递增
| 用户的唯一标识符
|
username
| VARCHAR(255)
| 非空,唯一
| 用户登录名
|
password
| VARCHAR(255)
| 非空
| 加密后的用户密码
|
email
| VARCHAR(255)
| 非空,唯一
| 用户的联系邮箱
|
role
| VARCHAR(20)
| 非空
| 用户角色
|
Registration_Time
| DATETIME
| 自动记录
| 用户注册的时间
|
- 公交信息表(Transit_Info)
字段名
| 数据类型
| 约束
| 描述
|
Transit_ID
| INT
| 主键,自动递增
| 公交信息的唯一标识符
|
Route_ID
| INT
| 外键
| 关联公交线路表
|
Vehicle_ID
| INT
| 外键
| 关联车辆表
|
Operating_Time
| TIME
| 非空
| 公交运营时间
|
Price
| DECIMAL(5,2)
| 非空
| 票价
|
Departure_Time
| TIME
| 非空
| 公交发车时间
|
Arrival_Time
| TIME
| 非空
| 到站时间
|
Real_Time_Status
| VARCHAR(50)
| 可空
| 公交车辆的实时运营状态,
|
Real_Time_Location
| VARCHAR(255)
| 可空
| 公交车辆的实时位置信息
|
Crowding_Status
| VARCHAR(50)
| 可空
| 公交实时拥挤情况
|
- 站点表(Station_Info)
字段名
| 数据类型
| 约束
| 描述
|
Station_ID
| INT
| 主键,自动递增
| 站点的唯一标识符
|
Station_Name
| VARCHAR(255)
| 非空
| 站点名称
|
Station_Type
| VARCHAR(20)
| 非空
| 站点类型
|
Area_ID
| INT
| 外键
| 关联区域表,站点所属区域
|
Latitude
| FLOAT
| 非空
| 站点的地理纬度
|
Longitude
| FLOAT
| 非空
| 站点的地理经度
|
Route_ID
| INT
| 外键
| 关联线路表,站点所在线路
|
Sequence
| INT
| 非空
| 站点在线路中的次序
|
- 线路表(Route_Info)
字段名
| 数据类型
| 约束
| 描述
|
Route_ID
| INT
| 主键,自动递增
| 公交或地铁线路唯一标识符
|
Route_Name
| VARCHAR(100)
| 非空
| 线路名称
|
Route_Type
| VARCHAR(20)
| 非空
| 线路类型("公交"或"地铁")
|
Area_ID
| INT
| 外键
| 关联区域表,线路所属区域
|
Start_Point
| VARCHAR(255)
| 非空
| 线路的起点站
|
End_Point
| VARCHAR(255)
| 非空
| 线路的终点站
|
Total_Stations
| INT
| 非空
| 该线路经过的站点总数
|
- 站点实时流量表(Real_Time_Monitoring)
字段名
| 数据类型
| 约束
| 描述
|
Monitoring_ID
| INT
| 主键,自动递增
| 实时监控记录的唯一标识符
|
Vehicle_ID
| INT
| 外键
| 关联公交车辆表
|
Real_Time_Location
| VARCHAR(255)
| 非空
| 实时车辆的地理位置
|
Passenger_Count
| INT
| 非空
| 当前车辆的乘客数量
|
Speed
| DECIMAL(5,2)
| 非空
| 当前车辆的行驶速度
|
Traffic_Status
| VARCHAR(50)
| 非空
| 当前路况信息"畅通"or"拥堵"
|
- 站点流量预测表(Traffic_Flow_Prediction)
字段名
| 数据类型
| 约束
| 描述
|
Prediction_ID
| INT
| 主键,自动递增
| 流量预测记录唯一标识符
|
Route_ID
| INT
| 外键
| 关联公交或地铁线路表
|
Date
| DATE
| 非空
| 预测日期
|
Time_Slot
| TIME
| 非空
| 预测的时间段
|
Predicted_Flow
| INT
| 非空
| 预测的客流量
|
Predicted_Crowd
| VARCHAR(50)
| 非空
| 预测的拥挤情况
|
- 交通事件表(Transport_Events)
字段名
| 数据类型
| 约束
| 描述
|
Event_ID
| INT
| 主键,自动递增
| 事件记录的唯一标识符
|
Event_Type
| VARCHAR(50)
| 非空
| 事件类型,如"车辆故障"、"交通事故"
|
Description
| TEXT
| 非空
| 事件的详细描述
|
Report_Time
| DATETIME
| 非空
| 事件报告时间
|
Affected_Routes
| TEXT
| 非空
| 受影响的公交或地铁线路,存储为JSON格式
|
Resolution_Status
| VARCHAR(50)
| 非空
| 事件解决状态,如"已解决"、"处理中"
|
- 调度管理表(Dispatch_Management)
字段名
| 数据类型
| 约束
| 描述
|
Dispatch_ID
| INT
| 主键,自动递增
| 调度管理记录的唯一标识符
|
Vehicle_ID
| INT
| 外键
| 关联公交或地铁车辆表
|
Dispatch_Time
| DATETIME
| 非空
| 调度时间
|
Route_ID
| INT
| 外键
| 关联线路表
|
Action_Type
| VARCHAR(50)
| 非空
| 调度类型,如"增班"、"减班"或"调整路线"
|
第三范式(3NF)满足
第三范式(3NF)要求数据库表在第二范式(2NF)的基础上,消除所有非主属性对候选键的传递依赖。也就是说,在3NF中,每个非主属性必须直接依赖于每一个候选键,而不是通过另一个非主属性间接依赖。
在所有的关系表中,关系属性仅依赖于其主键,没有传递依赖,因此该设计满足3NF要求。
项目管理
- 框架选择和开发平台
系统实现
