简介一份面向数据分析初学者与业务人员的实战型课件共94页系统讲解如何用Excel与SQL完成数据采集、处理、分析与可视化。内容涵盖数据分析概念与前景、Excel数据导入与常用函数、数据透视表与图表、SQL数据库基础及CRUD操作并延伸至排序、聚合、分组、分页、连接查询和子查询等核心查询技巧还补充了Tableau、PowerBI等可视化工具与电商数据分析案例。资源包内仅含1个PDF文件压缩后约22.55MB便于下载与移动阅读。已有696人学习/下载适合希望从事业务数据分析、数据挖掘或大数据分析方向的学习者也可作为学校或培训机构的课程辅助材料。整个目录按快速入门、Excel、SQL、数据可视化工具和电子商务案例组织由浅入深读者既可对照系统学习也可直接用于课件备课与实战演练。1. 这份94页课件把数据分析的完整链路讲清了Excel打底、SQL提效、BI收口做数据分析的人大概都经历过一个阶段手里有数据但不知道下一步该干什么。市面上讲Excel的书很多讲SQL的教程也不少但能把这两样串在一条线里、顺着“业务数据分析师—数据挖掘分析师—大数据分析师”这条路径讲下来的资料并不算多。这份94页的课件恰好补上了这个空缺。它不是一本工具书而是一张学习地图——从Excel的导入、清洗、函数、透视表、图表一路走到SQL的建库、CRUD、排序、分组、连接查询、子查询最后还收在BI工具和电商案例上。对打算转行做业务数据分析、或者刚入行想系统补一遍Excel和SQL地基的人这份课件值得照着过一遍就算你已经是熟手里面关于数据采集、数据清洗和查询优化的细节也常能帮你把平时习惯性略过的操作重新捋顺。2. 课件主线数据分析师的技能图谱是怎么搭出来的2.1 数据分析的四步流程从数据到决策课件在快速入门部分用了一个很典型的例子来讲数据分析的价值某款游戏的下载量很高但注册率很低这时候要判断是注册服务器的问题、注册流程过于复杂还是近期网络故障导致的。这个例子看着简单但它把数据分析的本质说清楚了——先收集数据再定位问题最后形成决策。数据分析的流程大体可以拆成四步数据采集、数据整理、数据分析、结论落地。课件把这四步挂在“业务数据分析师”这个职业目标下用的工具是Excel和SQL后期再叠加可视化工具。这个流程排布是有讲究的Excel负责处理小规模数据SQL负责从数据库里取数可视化工具负责把结果呈现给决策者。三者一环扣一环缺了哪一段分析报告都显得不完整。2.2 Excel、SQL、BI工具各自的分工边界很多新手容易犯一个错误试图用Excel干所有事。文件稍微大一点透视图卡半天更别说跨表关联和大量数据的聚合统计。课件的处理方式是把工具按场景拆开Excel适合做单次、小规模的数据采集和清洗SQL适合从数据库里取数并做规范化查询BI工具适合做交互式仪表盘和多维分析。这部分让我比较认可的是课件对“业务数据分析”和“数据挖掘分析”做了明确区分。业务数据分析主要用SQL和Excel做描述型分析数据挖掘分析则引入Python、SPSS这类工具做分类、聚类、协同过滤这类算法型分析。这个区分能帮助新人想清楚现阶段该学什么以及未来往哪个方向进阶。课程重点强调SQL和PowerBI也是因为它覆盖面广、上手周期短、在业务分析场景里出现频率最高。2.3 职业路径业务数据分析师到大数据分析师的跳跃课件在职业目标里写了三层路径业务数据分析师、数据挖掘分析师、大数据分析师。这三层对应的能力要求是递进的。业务数据分析师的核心技能就是Excel和SQL数据挖掘分析师要补统计学和Python大数据分析师则要接触Hadoop、Spark这类分布式计算平台。很多人在第一层和第二层之间卡住是因为只学了工具不会分析方法或者恰好相反。这份课件解决的是第一层的完整闭环。它用Excel和SQL把“取数、清洗、分析、呈现”串起来每一块都配了具体的操作知识点。后面涉及到的电商数据分析案例其实就是在模拟一个业务分析师日常的取数需求。与其一上来就扑向Python和Spark不如先把这条基础链路跑通这既是性价比最高的入门方式也是后续进阶的地基。3. Excel数据采集与处理从导入到透视表的完整链路3.1 认识Excel数据和数据导入字段、记录与文本型数字课件把Excel的基本单位梳理得很清晰工作簿是工作表的集合工作表是数据的集合字段是列标题记录是一行数据。这四层概念看着基础但它们是后续所有操作的前提。导数据之前最好先想清楚一件事这份数据是什么格式、以什么结构进来、里面有没有混入不该有的东西。常见的数据导入方式有几种直接打开csv或xlsx文件、从数据库导入、通过文本文件导入向导把txt数据按分隔符拆开。课件里强调的一个点我特别有感触如果把纯数字存储为文本格式会导致无法计算。比如某个列看起来是数字但单元格左上角有绿色小三角这时候SUM求和得到的往往是0或者结果明显不对。课程给出的解决方式是“某列*1”来快速转换类型这在处理大批量数据时确实好用。-- 如果是SQL里遇到类似问题也可以用CAST做类型转换 SELECT CAST(order_amount AS SIGNED) AS amount FROM orders WHERE order_date 2024-01-01;这段SQL的逻辑说明当数据源里金额字段误存为文本时MySQL里用CAST把它转成数值型才能正确参与聚合运算。其中AS SIGNED表示转为有符号整数也可以替换成DECIMAL(10,2)来保留两位小数。这个操作和Excel里“某列*1”的思路是相通的目的都是让数据回到正确的类型。3.2 Excel常用操作与函数不只SUM和AVERAGE课件的Excel函数部分没有停在SUM、AVERAGE、COUNT这类入门函数上而是把视角拉到了中级用户该掌握的范畴VLOOKUP类引用查找函数、逻辑判断函数、文本处理函数以及条件格式和自定义排序。这块内容的设计逻辑我觉得是对的——业务分析中真正高频的是“查找匹配”和“条件统计”而不是天天算平均数。引用查找函数的使用场景非常典型订单表里只有商品编号需要把商品名称匹配进来。VLOOKUP在这里就是标准的解决方案。需要注意VLOOKUP只能从左往右查如果要反向匹配可以用INDEXMATCH组合。我一般会在匹配前先把两边的匹配列都检查一遍格式尤其是编号列经常出现一边是文本一边是数字的情况导致匹配结果大面积错误。COUNTIFS、SUMIFS这类条件统计函数也值得重点练。一个表里登记了几千条用户反馈想看“来自某渠道且状态为已处理”的条数用COUNTIFS一条公式就出结果。这几个函数学会之后Excel在轻量级统计场景里的效率会高出一大截很多事情不用再先建透视表才能得到答案。3.3 数据透视表复杂数据分析的快速汇总路径课件把数据透视表定义为“进行复杂数据分析的有力工具”这个定位很准确。透视表的最大价值是不需要写任何公式拖拽字段就能完成分组汇总。实际使用中我习惯先把数据区域转成“表格”快捷键CtrlT再插入透视表这样后续新增数据后透视表能自动扩展范围不用每次手动改数据源。透视表里最常用的操作是行标签、列标签、值和筛选器四个区域的理解。行标签放分类字段值区域放需要汇总的数值字段值字段的汇总方式可以按需切换成求和、计数、平均值等。真正需要花时间的是“值显示方式”这一项里面的“父级汇总百分比”等功能在做占比分析时非常好用。做透视表之前有一个必须检查的步骤原始数据不能有合并单元格列标题必须是唯一的空行空列要先处理掉。这些预处理工作看起来琐碎但漏掉任何一个后面得到的汇总结果都可能是错的。3.4 图表呈现柱状图、折线图、饼图的使用边界课件把Excel图表归类为“数据可视化”环节的一部分强调用图表增强数据的展现力。选择图表类型时不应该随大流而是先想明白要传递什么信息。柱状图适合对比分类间的数值大小折线图适合展示时间序列趋势饼图适合表达占比关系但类别不能太多。散点图则用来观察两组数值之间的关联关系对应课件里提到的“浏览次数与销售件数关联”这类分析场景。图表看着简单有两个细节容易被忽略。一是刻度起点设置默认从0开始是最稳妥的如果截断就会放大视觉差异二是颜色数量不要超过太多一张图里塞进七八种颜色信息不仅没被简化反而更混乱。课件里提到的“数据可视化工具”除了Excel图表外还涉及胖BI类的产品——Excel图表适合快速出结果BI工具则适合把多个图表组合成交互式看板。4. SQL查询落地从CRUD到连接查询的实操练习4.1 数据库基础与数据类型先建出正确结构的表课件SQL部分的开篇是数据库概述、数据类型和常见操作。这个顺序安排是合理的如果没有建表规范后面的查询工作都会受影响。数据类型的选择是最容易出问题的地方之一。数值字段用INT还是DECIMAL日期字段用DATETIME还是TIMESTAMP字符字段用VARCHAR还是TEXT这些选择直接影响到存储空间和查询效率。-- 建一张订单表注意字段类型和主键设置 CREATE TABLE orders ( id INT AUTO_INCREMENT PRIMARY KEY COMMENT 订单ID, customer_name VARCHAR(50) NOT NULL COMMENT 客户姓名, order_amount DECIMAL(10,2) NOT NULL COMMENT 订单金额, order_date DATETIME NOT NULL COMMENT 下单时间, status TINYINT DEFAULT 0 COMMENT 状态0待支付 1已支付 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表;这段建表DDL的逻辑说明AUTO_INCREMENT设置自增主键VARCHAR(50)用于客户姓名的存储DECIMAL(10,2)用于金额以避免浮点精度问题DATETIME记录下单时间TINYINT配合COMMENT做状态标记。ENGINEInnoDB保证事务支持DEFAULT CHARSETutf8mb4避免中文乱码。课件里CRUD操作中“数据库常见操作”部分建议自己在本地环境把建库、建表、改表、删表的命令全部跑一遍这比只看不练扎实得多。4.2 排序、聚合函数与分组统计分析的标准姿势排序ORDER BY和聚合函数SUM、COUNT、AVG是SQL查询中使用频率最高的语法。聚合函数配合GROUP BY使用时要注意SELECT后面出现的普通字段必须出现在GROUP BY子句中否则在不同数据库上可能直接报错MySQL的ONLY_FULL_GROUP_BY模式会拦截或者返回不可预期的结果。-- 按月份统计订单金额和订单数 SELECT DATE_FORMAT(order_date, %Y-%m) AS order_month, COUNT(*) AS order_count, SUM(order_amount) AS total_amount, AVG(order_amount) AS avg_amount FROM orders WHERE status 1 GROUP BY order_month ORDER BY order_month DESC;这段查询的逻辑说明DATE_FORMAT把下单时间格式化成“年-月”字符串作为分组维度COUNT(*)统计订单数量SUM和AVG分别计算支付订单的总金额与客单价。WHERE条件放在GROUP BY之前过滤“已支付”状态。ORDER BY order_month DESC让结果按月份倒序排列便于观察最近几个月的趋势。分页查询在报表场景里也常用MySQL对应LIMITSQL Server对应OFFSET FETCH课件在“分页”一节有单独展开。4.3 连接查询、自关联与子查询多表取数的三种思维方式连接查询是SQL学习的第一个分水岭。INNER JOIN取交集LEFT JOIN保留左表全部记录RIGHT JOIN相反这是必须掌握的三种形态。课件里把它列为核心章节不是没有道理因为实际业务中“单表查询”几乎不存在。订单表、商品表、用户表天然分离分析时必须把它们拼回来看。-- 统计每个客户的订单总额展示客户姓名和消费金额 SELECT c.customer_name, SUM(o.order_amount) AS total_spent FROM customers c LEFT JOIN orders o ON c.id o.customer_id WHERE o.status 1 GROUP BY c.customer_name ORDER BY total_spent DESC;这段查询的逻辑说明LEFT JOIN以客户表为主表关联订单表确保没下过单的客户也能查出来订单金额为NULL。ON指定关联条件GROUP BY按客户分组汇总。有一个常见翻车点如果JOIN漏写关联条件两张表的记录会做笛卡尔积匹配数据量直接翻倍汇总数字全部失真。所以每写完一条JOIN语句先跑一遍COUNT(*)对比一下行数确认匹配关系正确再继续聚合。自关联是连接查询的特例同一张表自己跟自己关联。典型应用场景是查询员工和上级信息或者类目层级关系。子查询则适合“先缩小范围再查询”的场景通常可以用EXISTS或IN来替代部分连接查询。课件把这些内容都收纳进去说明它不是零基础科普而是朝着实战方向去铺垫的。4.4 备份恢复与数据库设计上线前就要想好的两件事数据库备份和恢复是课件里容易被速读略过的部分但在工程实践中它是绝对不能省的环节。备份有两种常见方式逻辑备份导出SQL文件和物理备份直接拷贝数据文件。针对业务分析师的日常取数场景至少要做到“先建库、再导数据、随时能恢复”。无论用哪款数据库产品或工具备份和恢复在投入生产环境前必须演练至少一次否则用的时候才第一次接触翻车的概率会极高。数据库设计章节更像一个预警表结构没设计好后面写查询会处处受限。课件这部分的重点是常识级约束——一张表做一件事字段含义单一主键明确必要的外键关系要建好。字段命名的统一也很重要别在订单表里叫customer_id在用户表里又写成user_id跨表关联时大概率会绕晕。5. 避坑指南按这份课件自学会遇到的五个高频问题5.1 SUM函数结果等于0列里全是文本型数字现象选中一列数字后状态栏的求和结果是0或者SUM公式返回空值。 原因这些单元格看起来是数字实际存储格式是文本广泛出现于从系统导入的数据。Excel里表现为左上角绿色小三角纯文本数字不参与数学运算。 解决选中整列后直接用“分列”功能或乘1的方式转换。操作方式是在空白单元格输入1复制它再选中数字列右键选择性粘贴选“乘”一次转换完。转换后检查一下SUM结果是否恢复正常。5.2 数据透视表新加数据后不刷新现象往数据源里追加了几行数据透视表怎么刷新都看不到新内容。 原因透视表引用的数据范围是固定的。比如当初选的是A1:C100后面加到C120新加的行数不在引用范围里自然不会被统计进去。 解决先选中原始数据区域按CtrlT转成“表格”再基于这张表插入透视表。之后每次追加数据只要在表格下方直接续写透视表刷新即可自动识别新范围。这个习惯我一般从第一次建表时就固定下来。5.3 JOIN查询结果行数翻倍数字全部翻了几番原因写JOIN时漏掉了关联条件或者关联条件写得太宽。例如两张表分别有200行按错误的ON条件匹配后可能得到几万行笛卡尔积SUM汇总自然失真。 解决每次写完JOIN先跑“SELECT COUNT(*) FROM 表1 JOIN 表2 ON …”核对行数和主表行数对比。如果不一致回头检查ON后面的关联条件是否完整、是否有多余条件生效。另外GROUP BY之后的HAVING条件要对齐聚合字段别拿原始字段做过滤。5.4 GROUP BY查询时SELECT多列报错或结果混乱现象执行分组查询时数据库直接报“ONLY_FULL_GROUP_BY”错误或者结果中某列显示的值不是该组内的预期值。 原因MySQL 5.7以上默认启用ONLY_FULL_GROUP_BY模式SELECT后面的普通列必须出现在GROUP BY里否则语法不合法。这是为了防止分组后某列取值不确定而产生的歧义。 解决要么把所有非聚合的SELECT字段都放进GROUP BY要么用ANY_VALUE()函数规避。更推荐前一种方式它会逼着你确认分组粒度是否正确从源头避免分析口径的混乱。5.5 UPDATE或DELETE没写WHERE条件一次性影响全表现象本来只想更新某一条订单状态执行后整张表的状态都被改了还没来得及回滚。 原因SQL语句没有WHERE条件或条件写得不对。一旦执行整张表的数据都会响应这是每个数据库新人必然会遇到的一次“血泪教育”。 解决在数据量大的表上操作之前先SELECT WHERE出来核对一下目标行数再相应地把筛选条件套到UPDATE或DELETE语句中。每次更新前可以先开启一个事务再执行确认无误后提交即使操作失误也有后悔药可吃。这种习惯要坚持形成肌肉记忆任何环境中都不例外。6. 进阶把电商案例改造成你自己的练手项目课件最后提到的电商数据分析案例被我改造成了一个可复用的练手模板。具体做法是找一份公开的电商订单数据几百行就够先在Excel里完成字段检查、去重、格式转换和缺失值标记把商品ID、订单金额、下单时间这些字段整理成标准格式再把这份清洗后的数据导入数据库用SQL完成三类练习——按品类统计销售额与销量、按月观察GMV走势、用连接查询找到每个用户最近的订单记录最后把SQL查询结果导出到BI工具里做成三个图表畅销商品排行、月度趋势、用户消费分布。这个模板覆盖了数据分析师在处理报表需求时的完整路径。一旦跑通后面遇到任何新数据都可以按这条流水线走Excel清洗—SQL取数—BI呈现。课件里提到的“内容类产品看PV/UV转化率、社交产品看留存、电商看客单价和复购率”说到底都是在复用同一套分析框架差别只是指标口径。比如做用户画像时把消费金额按“高、中、低”分三档建标签之后再谈协同过滤或推荐策略——课件中“将圆领深色推荐给某人”这类精准营销场景底层逻辑也是先做分组统计再落策略。如果你想把课件价值延伸到更远建议把电商案例里的业务问题自己改一遍。比如把“哪个品牌卖得多”改成“哪个品类退货率高”把“浏览次数与销量关联”改成“加购转化率的漏斗分析”。这样做的收获会比照原样看一遍大得多。我自己的习惯是笔记里专门留一个“踩坑记录”页凡是遇到数据异常的情况就写一行现象和原因。这样处理同类数据时可以先翻一遍笔记不少麻烦都能提前绕开。这份课件可以帮你把Excel和SQL的知识框架搭起来但真正值钱的永远是你自己复现、改造和踩坑的过程。希望帮到你。本文还有配套的精品资源点击获取