ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

基于Django与Bootstrap的电商数据可视化分析系统设计及DeepSeek Agent实践

基于Django与Bootstrap的电商数据可视化分析系统设计及DeepSeek Agent实践 如果你正在纠结计算机毕业设计选什么题目尤其是电商、数据分析、可视化这个大方向我的建议非常明确就做 Python Django Bootstrap 的电商数据可视化分析系统。这个题目不冷门但正因为不冷门参考多、坑少、导师认可度高而且功能边界清晰一个人完全吃得下。再加上这两年大模型火得一塌糊涂往系统里塞一个 DeepSeek Agent 作为亮点模块答辩的时候既有技术深度也有话题热度属于典型的“面子里有里子”。这套系统到底做什么说白了就是采集或整理电商平台的商品数据 → 清洗入库 → 用 Django 做后端接口 → 前端用 Bootstrap ECharts 展示各种图表看板 → 再通过大模型 Agent 支持自然语言问答。听起来很花哨但拆开之后每一块都有成熟的技术方案并不像想象中那么难。我把整个项目的设计逻辑、核心代码、实操步骤和你可能踩的坑全部整理在下面照着做从零到跑通大概一周就够了。1. 项目拆解毕业设计里的“六边形战士”1.1 为什么电商数据可视化成了毕业设计热门每年计算机毕业设计选题电商类项目的热度常年排在前三。原因不复杂电商数据够大、够全、够真实。商品信息、价格、销量、评价、用户行为这些数据天然适合做统计分析也天然适合用图表展示。从这个角度来说“电商 数据分析 可视化”这个组合解决了毕业设计最难的核心矛盾——既要体现工作量又要有现成的数据来源。更关键的是这个方向对技术栈的覆盖面相当广。后端有 Django 的 ORM、路由、接口设计前端有 Bootstrap 的页面布局和 ECharts 的图表渲染数据层面要处理清洗、聚合、统计额外加大模型 Agent 还要写 Prompt、调 API、做意图识别。一个项目把 Python 开发、数据库、前端、人工智能四块全占了放在答辩 PPT 里就是四个章节的内容含金量直接拉满。1.2 系统的核心业务闭环这套系统的使用场景我建议这样设定一个电商运营人员进入系统后台先看到整体销售大盘——今日销售额、订单量、客单价、热销商品 Top10然后可以按品类、按时间范围下钻查看不同商品的销量趋势和价格分布再往下可以分析用户评价的情感倾向最后还有一个对话框直接问“上个月哪个品类的销售额增长最快”系统通过大模型 Agent 自动回答。整个业务闭环就是数据接入 → 数据仓库 → 统计服务 → 可视化展示 → 智能问答。单看每一个环节工作量都控制在“一个人能完成”的合理范围内但合在一起就是一个完整的企业级数据分析产品雏形。我在给学生的评审意见中经常强调毕业设计最重要的不是复杂度而是逻辑闭环。你做的不是一个 demo而是一条完整的数据流水线。1.3 DeepSeek Agent 带来的最大亮点这个项目标题里专门点了“deepseek agent”说明不是简单的“接了个大模型聊聊天”而是要求系统具备一定的智能分析能力。我的设计思路是用户在输入框里提问后端先做两层处理第一层是从问题中剥离出查询意图是查销量还是查价格还是查排行第二层是根据意图去数据库执行统计查询把查询结果连同上下文一起交给 DeepSeek 大模型生成自然语言回复。这种方案的本质是检索增强生成也就是 RAG 的简化版。大模型不直接面对数据库而是由代码先完成结构化查询大模型只负责“组织语言”。这样做的好处有两个第一避免了让模型生成 SQL 带来的不可控风险SQL 写错了是灾难第二回答结果的准确率大幅提高因为数据本身来自真实的数据库统计结果模型只是帮忙把数字转成文字。这一块在答辩时讲起来特别加分因为面试老师一定会追问“大模型在里面到底干了什么”你可以理直气壮地说它是语言组织层不是数据来源层。2. 技术选型与系统架构设计2.1 Django 不是唯一选择但它是省心选择很多人在 Flask 和 Django 之间反复纠结我在实际带项目时给出的建议是毕业设计优先选 Django。原因不是 Flask 不好而是 Flask 太“自由”了。你需要在它上面自己拼 ORM、拼 Admin、拼表单校验、拼用户认证这些在 Django 里全都内置好了拿来即用。Django 自带的后台管理就是一个现成的数据管理界面商品表、订单表直接注册进 admin演示时还能向导师展示“我可以直接在后台增删改数据”这是个非常实用的加分项。另外Django 的 ORM 让数据查询变得非常优雅比如统计每个品类的平均价格一行代码就搞定from django.db.models import Avg, Count, Sum from products.models import Product result Product.objects.values(category).annotate( avg_priceAvg(price), total_countCount(id), total_salesSum(monthly_sales) ).order_by(-total_sales)这种写法在答辩时非常直观导师一眼就能看懂你在做什么不会因为代码晦涩而影响印象分。而且 Django 的 MTV 架构天然适合前后端分离的过渡形态——你可以用模板渲染也可以用 JsonResponse 提供接口两种方式都成熟看项目进度需求灵活切换。2.2 Bootstrap ECharts可视化看板的经典组合既然标题里明确写了 Bootstrap前端方案就没有悬念。Bootstrap 负责页面框架栅格系统做多卡片布局开箱即用不需要自己写一堆媒体查询。配合 ECharts一个基于 JavaScript 的图表库可以轻松画出折线图、柱状图、饼图、热力图、雷达图。Bootstrap 和 ECharts 的组合好在哪一个管“样子”一个管“数据呈现”。Bootstrap 把卡片、导航、按钮这些组件全部标准化视觉上不会太丑ECharts 的图表自动处理坐标轴、图例、提示框还能响应式缩放。我实际做项目时的经验是ECharts 的配置项虽然多但常用的就那几个xAxis、yAxis、series、tooltip、legend。先把核心的五到六个图表类型练熟整个可视化看板就能搭起来不用一开始就去啃官方文档的全部细节。2.3 数据从哪里来三条路线的取舍数据来源是所有做数据分析毕业设计的同学最先卡住的环节。很多教程一上来就教爬虫但真实的电商平台反爬机制非常严格验证码、滑块、风控一个接一个刚入门的人很容易在这里消耗大量时间。我推荐三条路线按优先级排列第一条用开放数据集。比如来自公开渠道的电商商品销售记录这类数据通常已经做好了脱敏字段也比较规范适合直接入数据库。第二条自己写模拟数据生成脚本。用 Python 的 faker 库或纯 random 生成商品名、价格、销量、日期模拟数据的优点是能精确控制范围和分布演示效果最稳定。第三条爬取小规模公开站点数据。比如一些商品比价平台的公开接口或者静态页面量小、反爬弱适合作为爬虫功能的展示样例。我的建议是主数据用前两条路线保证系统稳定运行爬虫代码保留在项目里作为“数据采集模块”的展示但不要让它成为系统的核心依赖。不然答辩前一天数据源挂了你连演示都做不了那才是真正的灾难。2.4 系统整体架构与数据流转整个系统的架构并不复杂我拆成四层来说。数据层MySQL 作为主数据库存储商品、订单、评论等结构化数据。考虑到可视化统计的性能核心表建议加好索引尤其是时间字段和分类字段。服务层Django 应用内划分若干模块用户模块负责登录注册用 Django 自带的 auth 系统商品模块负责商品数据的 CRUD 和聚合查询统计模块负责各类指标的实时计算大模型模块负责 Agent 问答的接口调度。接口层所有页面的数据都通过 JsonResponse 动态返回ECharts 在页面加载时发起 Ajax 请求拉取数据。这里要注意如果不做前后端分离Django 模板渲染出的页面中ECharts 的数据可以嵌入在模板变量里但更推荐 Ajax 方式因为图表刷新不刷新页面体验好很多。展示层Bootstrap 搭建整体框架包含导航栏、侧边栏、统计卡片和图表容器接 ECharts 做数据可视化大模型问答界面放在独立页面聊天气泡样式直接用 Bootstrap 的样式微调即可。数据流向就是MySQL → Django ORM 聚合查询 → JSON 序列化 → ECharts 渲染 → 用户看到图表。Agent 的方向则是用户提问 → 意图识别 → 数据库查询 → 结果拼接 → DeepSeek API 生成回答 → 前端展示。两条链路互不干扰代码维护起来也很清晰。3. 核心模块实现从数据库到可视化看板3.1 数据模型设计五张表撑起整个项目很多毕设项目的问题不是功能不够而是表设计乱。我的习惯是宁可用五张结构清晰的表也不用一张大宽表。这个项目建议设计以下模型from django.db import models class Category(models.Model): name models.CharField(max_length50, uniqueTrue) class Product(models.Model): product_id models.CharField(max_length64, uniqueTrue) title models.CharField(max_length256) category models.ForeignKey(Category, on_deletemodels.SET_NULL, nullTrue) shop_name models.CharField(max_length128, blankTrue) price models.FloatField() monthly_sales models.IntegerField(default0) comment_count models.IntegerField(default0) rating models.FloatField(default0.0) created_at models.DateTimeField(auto_now_addTrue) class Order(models.Model): order_no models.CharField(max_length64, uniqueTrue) product models.ForeignKey(Product, on_deletemodels.CASCADE) quantity models.IntegerField(default1) amount models.FloatField() order_date models.DateTimeField() buyer_city models.CharField(max_length64, blankTrue) class Review(models.Model): product models.ForeignKey(Product, on_deletemodels.CASCADE) content models.TextField() sentiment models.CharField(max_length10, blankTrue) created_at models.DateTimeField(auto_now_addTrue) class UserQueryLog(models.Model): question models.CharField(max_length512) answer models.TextField() created_at models.DateTimeField(auto_now_addTrue)这个设计覆盖了商品、类目、订单、评论和大模型问答日志。comment_count 和 rating 是冗余字段直接存在商品表不需要去关联评论表做实时统计这是典型的空间换时间策略。UserQueryLog 记录大模型的问答历史这个表的存在一方面能演示 Agent 的工作记录另一方面在答辩时可以调出历史数据说明系统被实际使用过很有说服力。3.2 数据清洗的实操经验数据入库前一定要清洗这个步骤我建议单独写一个脚本data_clean.py不要在 Django 的视图里做。常见的清洗场景有这些缺失值处理价格为空、销量为空的记录直接删除或者用同一品类的均值填充。电商数据里偶尔会有价格为 0 的异常值那明显是无效数据同样需要过滤。重复值处理商品 ID 相同的记录取最新一条重复订单去重。用 pandas 操作非常简单import pandas as pd df pd.read_csv(products.csv) df df.drop_duplicates(subset[product_id], keeplast) df df.dropna(subset[price, monthly_sales]) df df[df[price] 0]字段格式统一价格统一转为浮点数时间统一格式化为%Y-%m-%d品类名称去掉前后空格和大小写差异。这些细节决定了后面统计结果的准确率如果你在清洗阶段偷懒可视化阶段出现的所有数字都会让人没底气。我在实际项目中吃过一个亏模拟数据生成的时候有个字段值在 1 到 999 之间随机生成后来统计客单价的时候发现出现了几千块的订单再回去排查才发现是某个品类被错误标记成了高价品类。所以清洗脚本跑完之后一定要抽几个字段做分布检查比如打印一下 price 的最大值、最小值、均值看起来不合理就回头查生成逻辑。3.3 可视化看板Dashboard 页面完整实现看板页是整个项目的门面表现形式大于逻辑复杂度。我的布局方案是顶部四张统计卡总销售额、总订单量、商品数、平均客单价中间两张大图表销量趋势折线图、品类销售占比饼图下方一排三张小图表价格分布箱线图、热销商品 Top10 横向柱状图、城市销量地图。先看 Django 视图部分from django.http import JsonResponse from django.db.models import Sum, Count, Avg from datetime import datetime, timedelta from .models import Product, Order def dashboard_data(request): today datetime.now().date() start_of_month today.replace(day1) total_sales Order.objects.aggregate(totalSum(amount))[total] or 0 total_orders Order.objects.count() product_count Product.objects.count() avg_price Product.objects.aggregate(avgAvg(price))[avg] or 0 # 近30天销量趋势 trend_dates [] trend_values [] for i in range(29, -1, -1): day today - timedelta(daysi) day_total Order.objects.filter(order_date__dateday).aggregate( totalSum(amount))[total] or 0 trend_dates.append(day.strftime(%m-%d)) trend_values.append(round(day_total, 2)) return JsonResponse({ total_sales: round(total_sales, 2), total_orders: total_orders, product_count: product_count, avg_price: round(avg_price, 2), trend_dates: trend_dates, trend_values: trend_values })前端页面中ECharts 的初始化逻辑如下function loadDashboard() { fetch(/api/dashboard/) .then(res res.json()) .then(data { document.getElementById(totalSales).innerText ¥ data.total_sales.toLocaleString(); document.getElementById(totalOrders).innerText data.total_orders; document.getElementById(productCount).innerText data.product_count; document.getElementById(avgPrice).innerText ¥ data.avg_price.toFixed(2); salesTrendChart.setOption({ tooltip: { trigger: axis }, grid: { left: 60, right: 20, top: 30, bottom: 40 }, xAxis: { type: category, data: data.trend_dates }, yAxis: { type: value, name: 金额元 }, series: [{ name: 日销售额, type: line, smooth: true, areaStyle: { opacity: 0.15 }, data: data.trend_values }] }); }); } salesTrendChart echarts.init(document.getElementById(salesTrend)); loadDashboard();这里有两个实战细节。第一折线图尽量加smooth和areaStyle视觉上更现代答辩演示时观感好很多。第二所有图表在窗口大小变化时应该调用chart.resize()否则从笔记本投到投影仪上图表可能被截断。加一行监听即可window.addEventListener(resize, () { salesTrendChart.resize(); categoryPieChart.resize(); top10Chart.resize(); });3.4 DeepSeek Agent 接入让系统真正“会说话”大模型 Agent 是本项目的压轴亮点我把它设计成一个独立的 Django 应用模块。使用 DeepSeek 开放平台的 API调用deepseek-chat模型。先安装依赖用requests就够了不需要额外引入openai库减少一层封装依赖。import requests API_KEY sk-your-key-here API_URL https://api.deepseek.com/chat/completions def call_deepseek(system_prompt, user_content): headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } payload { model: deepseek-chat, messages: [ {role: system, content: system_prompt}, {role: user, content: user_content} ], temperature: 0.3, stream: False } resp requests.post(API_URL, jsonpayload, headersheaders, timeout30) resp.raise_for_status() return resp.json()[choices][0][message][content]关键在意图识别这一步。我的做法是先把用户问题交给大模型做一次意图识别让它输出一个结构化的 JSON然后根据 JSON 中的参数去数据库查。但考虑到请求延迟和 API 费用的双重问题更轻量的做法是直接在视图里用关键词匹配加正则判断def parse_intent(question): question question.lower() if 排行 in question or top in question or 热销 in question: return top_products if 趋势 in question or 增长 in question: return sales_trend if 品类 in question or 分类 in question: return category_stats return general确定意图后在代码里执行对应的统计查询把结果拼接成文本再让 DeepSeek 把它润色成完整回答。比如查询“热销商品 Top5”def top_products(limit5): from .models import Product qs Product.objects.order_by(-monthly_sales)[:limit] lines [f{i1}. {p.title[:30]}月销量 {p.monthly_sales}价格 {p.price} 元 for i, p in enumerate(qs)] return \n.join(lines)然后把这段文本作为用户内容的一部分发给大模型def ask_agent(question): intent parse_intent(question) data_text if intent top_products: data_text 当前热销商品排行如下\n top_products() elif intent category_stats: data_text 品类统计数据如下\n category_stats() system_prompt ( 你是一个专业的电商数据分析助理。用户会提供真实的统计结果数据 你需要根据这些数据生成简洁、准确、友好的回答。不要编造数据。 ) reply call_deepseek(system_prompt, f用户问题{question}\n\n统计结果\n{data_text}) return reply这个设计最妙的地方在于统计结果是大模型唯一的信息来源回答里每一个数字都能在数据库中找到凭证。这样既避免了模型幻觉也保证了系统给出的答案经得起推敲。答辩时如果被问“为什么不让大模型直接生成 SQL”你可以直接回答大模型直接生成 SQL 存在查询失败的风险而结构化执行 语言润色的架构更稳健这也是 Agent 在企业级应用中的常见实践。4. 实操过程从零到跑通4.1 环境准备清单我建议用虚拟环境隔离项目依赖避免污染系统 Python。以下是我整理的最小依赖清单依赖版本建议用途Python3.10解释器Django4.2 LTSWeb 框架mysqlclient / pymysql最新MySQL 驱动pandas2.x数据清洗requests最新爬虫和 API 调用django-cors-headers最新跨域支持非必需安装环境时强烈推荐用清华 PyPI 镜像或者阿里云镜像速度快很多pip install django4.2 pandas requests pymysql -i https://pypi.tuna.tsinghua.edu.cn/simpleWindows 用户如果安装 mysqlclient 报错直接改用 pymysql然后在项目的__init__.py里加上两行import pymysql pymysql.install_as_MySQLdb()这个方法我已经帮至少二十个学生解决过环境问题能省下大量时间。4.2 Django 项目初始化与核心配置创建项目和应用django-admin startproject ecommerce_analysis cd ecommerce_analysis python manage.py startapp dashboard python manage.py startapp user_auth python manage.py startapp agent在settings.py中重点配置三块数据库连接、静态文件目录、已安装应用。我的数据库配置建议是用环境变量或配置文件读入不要在代码里写死真实密码。演示用的数据库账户建议单独创建一个只读权限的账号一方面更安全另一方面也显得专业CREATE DATABASE ecommerce charsetutf8mb4; CREATE USER demo_userlocalhost IDENTIFIED BY Demo2024; GRANT ALL PRIVILEGES ON ecommerce.* TO demo_userlocalhost; FLUSH PRIVILEGES;然后执行迁移python manage.py makemigrations python manage.py migrate python manage.py createsuperuser python manage.py runserver 0.0.0.0:8000迁移完成后把准备好的商品数据写入数据库。我建议写一个load_data.py的脚本放在项目根目录通过python manage.py shell load_data.py执行或者用 Django 的 custom management command这样数据导入可以反复执行不会因为重复导入而出问题。4.3 功能自测与验收清单项目跑通后不要急着写论文先把核心功能逐项验收一遍。我列一个检查清单用户登录注册是否正常未登录访问看板是否被拦截。看板页四张统计卡数据是否正确和数据库手动查询的结果是否一致。销量趋势图是否按日期显示正确切换日期范围是否刷新。热销商品 Top10 排序是否按月销量降序。品类占比饼图各分类占比是否合计为 100%。大模型问答输入“本月销量最高的商品是什么”回答中是否包含正确的商品名称和销量数。后台管理界面能否正常登录商品数据能否编辑保存。刷新页面是否存在 JavaScript 报错打开浏览器开发者工具观察 Console 面板。建议在验收时把每一步的截图保存下来这些截图就是论文“系统测试”章节的素材。我见过太多学生系统做得不错但没人截图最后写论文时只能临时补测既浪费时间又可能错过真实运行状态。5. 常见问题与避坑指南5.1 高频报错和排查方法整理几个这个项目里最常遇到的报错每一条都是我实际见人踩过的。django.core.exceptions.ImproperlyConfigured: Error loading MySQLdb module是第一批新手必遇问题。原因通常是没装 MySQL 驱动或者驱动没注册。如果已经装了 pymysql记住要在项目的__init__.py中执行install_as_MySQLdb()这个操作经常被忽略。AttributeError: NoneType object has no attribute split出现于调用 DeepSeek API 返回为空时。排查思路先用print(resp.json())看看完整响应内容很多情况是 API key 无效、余额不足或者temperature参数超出范围。另外注意timeout30不能少响应慢的时候 requests 默认会一直挂着页面就超时。ECharts 图表不显示但控制台没报错大概率是 DOM 元素获取不到或者数据格式不匹配。我在项目里踩过的一个坑是从 Django 返回 JSON 中的字段是trend_dates但前端代码里读的是dates两个名字对不上页面白屏。排查时先在浏览器 Console 中打印data对象看清楚字段名90% 的图表问题都能用这个方法解决。5.2 Visual Studio Code 调试配置的建议如果卡在服务端代码调试上我建议配置 VS Code 的调试器launch.json里直接指向 Django 的 runserver 即可{ version: 0.2.0, configurations: [ { name: Django Debug, type: debugpy, request: launch, program: ${workspaceFolder}/manage.py, args: [runserver, 8000], django: true, justMyCode: false } ] }配置好后在视图函数里打断点前端请求发过来就能在断点处停下逐行查看变量值。这个方法特别适合排查 Ajax 接口返回的数据跟预期不一致的问题。5.3 答辩准备高频问题提前演练答辩时导师大概率会问的问题我根据经验预测了这几个为什么选择 Django 而不是 Flask核心回答思路内置功能全ORM 方便自带 Admin 后台适合快速搭建数据管理类系统。ECharts 的数据从哪来要回答清楚Django 视图层通过 ORM 查询 MySQL序列化成 JSON前端通过 Ajax 获取ECharts 使用 setOption 渲染。大模型在系统里扮演什么角色强调它不是数据来源而是自然语言处理层数据库查询结果交由模型组织语言回答从而避免幻觉。系统有什么不足大方承认三个点当前只做了描述性统计没有做预测性分析用户量并发能力未做压测大模型 API 依赖外部服务调用延迟受网络影响。这个回答不仅不扣分反而显得你思考得很全面。5.4 论文写作的小建议论文章节结构建议直接对照系统架构来写第一章绪论写背景和意义第二章相关技术介绍第三章需求分析第四章系统设计第五章系统实现第六章系统测试。每章写的时候都用截图辅助说明比如洗完之后的数据样例截图、数据库表结构截图、看板页面截图、Agent 问答效果截图。有一个技巧系统实现章节里的代码不要全部贴大段核心代码重命名变量、加上注释配合文字说明每个文件的作用。导师真正关心的是你清不清楚这段代码在做什么、为什么这么做而不是代码有多长。写在最后我个人的体会是这类项目做成功的核心秘诀只有一个把每个模块的边界划清楚然后各个击破。不要想着一步到位做全所有功能先把基础的数据入库和看板跑通再一步步加品类分析、用户分析、大模型问答。每一步都有可见的成果进度感会让你更有动力代码维护起来也不至于一片混乱。最后再分享一个小技巧全部功能完成后写一个README.md把安装步骤、数据导入命令、启动命令、默认账号密码全部写清楚。这不仅是给导师看的也是给一个月后的你自己看的。相信我那时候你大概率已经忘记数据库密码填的什么了。有了一份详尽的 README不管是你自己维护还是别人接手跑起来体验都会舒服很多。
返回列表