京公网安备 11010802034615号
经营许可证编号:京B2-20210330
很多数据分析师写过无数个SELECT查询,但当被问到“如何新建一张表来固化中间数据”“创建视图和创建物理表有什么区别”“视图的优缺点分别是什么”时,却常常陷入支支吾吾的困境。其实,SELECT只是从表中“取”数据,而CREATE TABLE和CREATE VIEW才是主动“建”数据载体的能力——前者是“用数据”,后者是“造工具”。
”
小林是刚进公司一年多的数据分析师,写复杂SQL是日常,颇受团队认可。在一次分析任务中,他发现业务系统导出的原始表中有大量重复订单、字段类型混乱、缺少日期索引,导致每次分析前都要重复做清洗和关联工作,效率大降。
技术主管建议:“你把清洗后的中间数据固化成一张表,下次直接用就行。”小林恍然:原来许多分析效率低下的根源,在于只会“取”不会“建”。而视图将复杂的查询逻辑封装为一张“虚拟表”,能极大简化上层取数。在CDA数据分析师的认证体系中,能否在实际工作中熟练创建和管理表与视图,正是“数据治理”和“商业洞察”能力的集中体现。
熟练掌握表和视图的创建,是CDA分析师从“被动取数人”走向“主动数据赋能”的必备技能。本文将聚焦于CDA一级大纲和实际工作中的核心要点,系统解析创建数据表和创建视图的本质差异、核心语法、实际应用与考试高频考点。
对CDA分析师而言,表与视图并非“二选一”的工具,而是“分工不同、协同配合”的搭档。要高效使用两者,需先明确其本质差异。
数据表是数据库中用于物理存储数据的实体结构。所有原始数据或经过处理的核心数据都以表的形式持久化存储。其核心特征是:
对分析师而言,创建表的核心价值体现在三个方面:
分析师常用表类型包括:
视图是基于一个或多个表的查询结果构建的虚拟表,本身不存储数据,仅保存查询逻辑。当分析师调用视图时,数据库会根据预设的查询逻辑,从原始数据表中实时提取数据并呈现。其核心特征是:
分析师常用视图类型包括:
创建表的过程是设计其存储规则和业务结构。基本语法结构如下:
CREATE TABLE [IF NOT EXISTS] 表名 (
列名1 数据类型 [列级约束] [默认值],
列名2 数据类型 [列级约束] [默认值],
……
[表级约束(主键、外键、唯一约束等)]
);
在创建表时,需要为每个字段明确数据类型与约束条件。常见的约束类型包括:
| 约束类型 | 关键字 | 作用 |
|---|---|---|
| 主键约束 | PRIMARY KEY | 唯一标识表中的每一行,值非空且唯一 |
| 外键约束 | FOREIGN KEY | 维护表与表之间的数据一致性 |
| 唯一约束 | UNIQUE | 保证某列的值不会重复 |
| 非空约束 | NOT NULL | 强制某列不能为空 |
| 检查约束 | CHECK | 定义合法值范围或表达式 |
| 默认约束 | DEFAULT | 未显式赋值时提供默认值 |
假设某电商平台需要创建一张订单固化分析表,用于后续销售趋势计算:
CREATE TABLE order_analysis_base (
order_id VARCHAR(50) PRIMARY KEY, -- 主键约束
user_id VARCHAR(50) NOT NULL, -- 非空约束
user_city VARCHAR(50) DEFAULT '未知', -- 默认值约束
order_amount DECIMAL(10,2) NOT NULL, -- 精度可控
order_status VARCHAR(20) CHECK (order_status IN ('已支付','未支付','已取消')),
order_date TIMESTAMP NOT NULL,
product_category VARCHAR(50)
);
在表创建后,可通过ALTER和DROP对表结构进行动态管理:
| 操作类型 | 语法示例 | 说明 |
|---|---|---|
| 修改表名 | ALTER TABLE 旧表名 RENAME TO 新表名; |
确保下游依赖同步修改 |
| 新增字段 | ALTER TABLE 表名 ADD 新字段名 数据类型; |
注意大批量表避免锁表 |
| 修改字段 | ALTER TABLE 表名 MODIFY 字段名 新数据类型; |
确认原业务是否依赖旧类型 |
| 删除字段/表 | ALTER TABLE 表名 DROP 字段名; / DROP TABLE 表名; |
操作不可逆,执行前做好备份 |
视图的创建语法是将SELECT查询封装为可复用的虚拟表:
CREATE VIEW view_name AS
SELECT column1, column2, ...
FROM table_name
WHERE condition;
视图的核心价值在于:
视图的优点:
视图的缺点:
假设某电商平台需要封装“用户消费画像”查询,方便分析师后续直接调用:
CREATE VIEW v_user_consumption AS
SELECT
u.user_id,
u.user_name,
u.city,
SUM(o.order_amount) AS total_spent,
COUNT(o.order_id) AS order_count,
AVG(o.order_amount) AS avg_order_value
FROM users u
INNER JOIN orders o ON u.user_id = o.user_id
WHERE o.order_status = '已支付'
GROUP BY u.user_id, u.user_name, u.city;
创建成功后,分析师只需执行SELECT * FROM v_user_consumption WHERE city = '北京';即可获取北京地区的用户消费画像,无需重复编写多表关联和分组汇总的复杂SQL。
在CDA考试中,有一类典型考题是识别语句的功能:
”
create view v_t1 as select id,name from t1;
这个语句的功能是创建一个名为v_t1的视图,视图中包含t1表的id和name字段。视图是一个虚拟表,基于SQL查询的结果集,不是更新字段内容的操作。这道题考察的是考生能否区分CREATE TABLE、CREATE VIEW与UPDATE等操作的不同功能。
| 对比维度 | 数据表(Table) | 视图(View) | 选择建议 |
|---|---|---|---|
| 数据存储 | 物理存储,占用磁盘空间 | 逻辑存储,仅保存查询语句 | 高频复用且数据稳定→表;实时性要求高→视图 |
| 数据独立性 | 独立存在,不依赖其他对象 | 依赖基础表,基础表变更可能导致失效 | 稳定结构→表;需动态适配→视图 |
| 数据操作 | 支持增删改查(CRUD) | 数据只读,无法直接修改 | 需修改数据→表;仅查询→视图 |
| 查询效率 | 直接读取数据,效率高 | 每次访问需执行查询,效率依赖逻辑复杂度 | 大数据量分析→表;简单查询→视图 |
| 使用场景 | 中间数据固化、数据共享、二次加工 | 复杂查询简化、数据权限控制 | 长期分析项目→表;临时查询或复用查询→视图 |
某电商平台需要每日统计“各城市近30天已支付订单的GMV”,用于运营早报推送。
为避免每日反复跨业务订单表进行大规模连接,首先生成一张固化表作为中间存储:
CREATE TABLE daily_city_order (
stat_date DATE NOT NULL,
city_code VARCHAR(20) NOT NULL,
total_gmv DECIMAL(12,2) NOT NULL,
PRIMARY KEY (stat_date, city_code)
);
为了方便运营同学直接取数,创建一张视图封装核心业务口径:
CREATE VIEW v_city_gmv_30days AS
SELECT
city_code,
SUM(total_gmv) AS gmv_last_30days
FROM daily_city_order
WHERE stat_date >= CURDATE() - INTERVAL 30 DAY
GROUP BY city_code;
后续运营早报系统直接查询视图即可稳定获取结果:
SELECT * FROM v_city_gmv_30days ORDER BY gmv_last_30days DESC;
这就是一套完整的“创建表固化中间数据 → 创建视图封装业务逻辑 → 上层直接调用”的表与视图协同实战流程。
”
很多数据分析师能写复杂的SELECT和JOIN,但当被问到“为什么要建这张中间表”“视图是否可以随意修改里面的数据”“底层基表结构被改对视图有什么影响”时,往往答不上来。
会写SELECT是“用数据”,会建表和视图是“造工具”。 创建表是在为数据仓储打下坚实的地基;创建视图则是在地基上铺设高效取数的管道。只有掌握两者的创建与管理,才能让数据真正体系化、可管理化、可复用化,让分析师从“重复写长SQL”的低效困境中解放出来。
在2025年新考纲的背景下,CDA一级明确要求掌握创建表与视图的操作逻辑——这不仅是考试大纲的考核要求,更是每一位数据分析师在真实工作中将“数据资产”转化为“决策能力”的必备技能。
下一步行动:
CREATE TABLE 和 CREATE VIEW 共同构成了数据分析师手中的“建设权”——构建稳健的数据骨架,封装可复用的分析逻辑,让数据真正成为资产。
”

数据分析咨询请扫描二维码
若不方便扫码,搜微信号:CDAshujufenxi
你有没有想过,手机里点外卖、刷社交软件、转一笔账,背后到底是谁在替你"记着账"? 答案其实很简单:数据库,以及跟它对话的那 ...
2026-10-07CDA数据分析师 出品 作者:李诗怡 一、数据分析四大思维 1. 对比思维:没有对比就没有分析 核心观点:单独一个数字没有意义,有 ...
2026-10-05Kimball 是方法,星型模型是它产出的形状。 很多人把"Kimball vs 星型模型"当成一道选择题——这本身就是个误会:Kimball 是动词 ...
2026-10-05写在开头 老板在微信上甩来一句: "帮我看下为什么销量跌了。" ” 你回工位,打开 SQL,开始写。查订单表、拉近三个月、按 ...
2026-10-03CDA数据分析师 出品 作者:李诗怡 1. 事实表 vs 维度表 对比维度 事实表 维度表 核心问题 记录“业务发生了什么事” 描述 ...
2026-10-02做数据聚合时,PySpark的groupBy()确实能完成统计,这也是它的本职工作。但它有一个根本性局限:每一组数据,最终只能返回一行 ...
2026-10-01热力地图是数据可视化中极具辨识度与实用性的空间分析图表,结合地理空间维度与数据密度特征,通过颜色深浅、色阶渐变直观展示数 ...
2026-09-30 很多数据分析师做过按月份的销售额趋势图,画过按天的流量折线图,但当被问到“时间序列和普通数据有什么本质区别”“季节性 ...
2026-09-30同样是“银行数据岗”,在国有大行总行数据中心、在一家城商行的零售部、在银行系金融科技子公司、在保险公司,工作内容、成长节 ...
2026-09-29在数据分析与统计学研究中,数据往往不是独立存在的,不同变量之间普遍存在相互关联、相互影响的关系。相关性统计分析是挖掘变量 ...
2026-09-29 导读:大多数人只把 dataclasses 当成偷懒工具,用来少写 __init__、__repr__ 这类魔法方法。但它的能力远不止于此。本文带 ...
2026-09-29 很多数据分析师能熟练地计算指标、搭建标签体系,但当被问到“画像到底在解决什么问题”“画像和标签是什么关系”“画像如何 ...
2026-09-29在MySQL数据库运维与业务开发中,行业普遍存在“数据达到千万级就必须分表”的说法。但在实际生产环境中,千万条数据并不是强制 ...
2026-09-28CDA数据分析师 出品 作者:李诗怡 1. 5W1H 分析法 定义:经典系统性思维框架,通过六个核心维度对问题进行全方位拆解与剖析,确 ...
2026-09-28 很多分析师在设计标签时思路清晰,但真到落地环节却面临“数据在手,不知如何转化为可用标签”的困境:或因加工方式选择不当 ...
2026-09-28CDA数据分析师 出品 作者:李诗怡 1. 用户标签体系 定义: 通过一系列高度精炼的特征标识,对用户属性、行为与偏好进行量化刻画 ...
2026-09-24Pandas是Python生态中用于表格数据处理的核心库,广泛应用于数据清洗、统计运算、报表输出、数据分析建模等场景。在处理极大数值 ...
2026-09-24随着数字经济快速发展,数据已成为核心生产要素,各行各业的业务沉淀、用户行为、设备运行、市场交易均产生海量数据。数据处理作 ...
2026-09-24 很多分析师每天和数据打交道,但当被问到“标签是什么”“标签和指标有什么区别”“标签体系如何设计”时,却常常答不上来。 ...
2026-09-24在时序数据分析中,大部分业务数据并非持续平稳变化,而是会在某些时间节点出现突然抬升、断崖下跌、趋势反转、波动异变等现象, ...
2026-09-23