从 Oracle 到 AI Agent:笔者亲历的数据分析二十年

二十多年前,笔者刚接触企业数据分析那会儿,Oracle 数据库、数据仓库还是很多大型企业项目绕不开的基础设施。那时候我们谈数据分析,首先想的往往不是“我要问什么问题”,而是:数据在哪?怎么抽出来?格式统一了吗?主数据整理过吗?
那时候做一个数据仓库项目,动辄一两年。最大的成就是什么?企业终于能把分散在 ERP、CRM、财务系统里的数据组织起来了。但代价也大——业务要一张报表,IT 排期一周。数据只能回答“昨天卖了多少”,至于“为什么卖了这么多”,得靠人自己猜。
二十多年过去了,笔者最近重新琢磨这个问题,突然发现:我们跟数据打交道的方式,正在发生一次比 Hadoop、云计算甚至自助 BI 更大的变化。
以前,是人学习怎么用数据库和分析工具。现在,开始变成机器学习怎么理解人的业务问题。
这个变化来得太快了,快到笔者发现很多 CIO 朋友其实还没完全意识到——他们的数据团队还在写 SQL、搭看板,而业务部门已经开始把 Excel 扔给 ChatGPT 问“帮我看看这里有什么问题”了。你说这事儿刺不刺激?

一、先把数据整理好——那个 Oracle 称王的年代

这就是数据仓库和 ETL 的时代。Oracle、Sybase 等是主角,核心工作就三件事:建模型、做清洗、统一口径。

笔者那会儿参与过一个移动运营商的数据仓库项目,光是对数据标准就开了两个月的会。财务口径和业务口径对不上,同一个“销售额”三个部门算出来三个数。你说 AI 来了能怎么办?数据先得是一家人,才谈得上“分析”这两个字。

二、数据突然太多了——Hadoop 来了,可业务人员使用数据有难度

互联网和移动互联网一爆发,日志、点击、设备、行为数据涌进来,传统数据库装不下了。Hadoop、数据湖应运而生。

这个阶段最大的变化是什么?数据分析的对象从“订单、客户、财务凭证”扩大到了“一切数据”。日志也能分析,图片也能存,行为轨迹也能查。

但麻烦也来了——这些技术门槛太高,只有数据工程师能玩得转。业务人员离数据反而更远了。笔者见过不少企业,花了几百万搭了数据湖,结果业务部门连怎么取数都不知道,最后还是把 Excel 发给 IT 帮忙导出。

这事儿说起来,有点讽刺吧:数据多了,能用的人少了。

三、看板满天飞,洞察呢?——自助 BI 有黄金点也有陷阱

PowerBI、FineBI 一来,自助分析成了。业务人员可以自己拖拽、钻取、做 Dashboard,不用再等 IT 写 SQL。

这个阶段最大的进步是“数据民主化”。看板铺天盖地,每个部门都有自己的驾驶舱。

但新的问题也冒出来了:看板越做越多,洞察依然稀缺。大家忙着做报表,却很少有人真正回答“所以呢?我们应该做什么?”笔者见过一个零售企业,BI 系统里躺了 300 多张看板,老板每周一看的还是那几张 Excel 表。

从一个极端走向另一个极端,数据分析这事儿,好像一直没找到最舒服的姿势。

四、2023 年那个瞬间——机器开始听懂人话

2023 年笔者第一次用 ChatGPT 分析 Excel 数据时,有一种很强烈的感受:自然语言,第一次真正成为分析界面。

以前是你去适应工具——学 SQL、学拖拽模型、学写公式。现在是工具来适应你。你直接问“上个月哪个品类利润下滑最严重”,它理解意图、定位数据、给出分析。

这不是自动化,这是交互方式的根本改变。数据分析不再是少数人的专业技能,变成了人人可用的对话能力。笔者当时跟一个做 BI 做了十年的朋友聊,他说了一句话:“我们这行,门槛没了。”

五、从“看”到“做”——AI 的下一步不是回答,是行动

到了 2026 年,笔者在上一篇《中国中小企业 AI 升级的五大风险与挑战》里也提过——AI 智能体正在从“回答问题”走向“主动发现并推动行动”。

以前的分析终点是一张 Dashboard,人看了之后自己去发邮件、开会、走流程。现在 AI Agent(智能体)开始具备规划、调用工具、分析验证、给出建议、触发后续动作的能力。

数据分析的真正终点,可能不再是“看到”了什么,而是业务行动被直接触发。

一张图把这条线串起来

笔者把这条演进路径画成了一条链:Database → 存好数据 → Data Warehouse/BI → 看懂数据 → Big Data/Data Lake → 分析更多数据 → Self-Service BI → 让更多人分析 → GenAI → 直接和数据对话 → AI Agent → 让 AI 主动分析 → Process/Action → 推动业务行动。

前四个阶段,本质上都在解决“让人类更好地看数据”。而从 GenAI 开始,我们进入了一个全新的领域——让机器理解人类的业务问题,并推动解决。

这个转折啊,笔者觉得比当年从 Oracle 到 Hadoop 的跨越还要大。因为前面的变化都是“工具升级”,这一次是“交互方式的重置”。

最后,留三个问题给正在思考数字化转型的 CIO等管理者

第一,你公司的数据基础,真的准备好让 AI 使用了吗? 如果数据还在 Excel 里、口径还不统一、质量还有问题,AI 再聪明也没用。关于这一点,笔者在上一篇《五大风险》里专门写了“基础风险”这一节,就不再展开了。

第二,如果员工以后不再打开十几个 Dashboard,而是直接问 AI,你现有的数据平台和 BI 体系应该如何变化? 这不是技术问题,是架构和治理问题。

第三,如果 AI 已经发现问题、分析原因并给出建议,下一步为什么还要靠人手工发邮件、找人、建任务、发起流程?

第三个问题是笔者最近想得最多的。笔者越来越觉得,AI 时代的数据分析终点可能不再是一张 Dashboard。它真正的终点应该是:Data → Insight → Decision → Action → Process → Feedback。

数据产生洞察,洞察辅助决策,决策触发行动,行动进入流程,流程执行结果重新成为数据。

如果这个闭环真正形成,数据分析、AI Agent 和 BPM 之间原本清晰的产品边界,也许会越来越模糊。这件事,可能才是 CIO 们在未来三年真正需要关注的方向。

数据库设计规范范例

数据库设计越来越成为现代软件设计必须的一部分内容。而我们从很多书本中得到的更多的是一些知识点。如何设计一个强大高效而又规范的数据库呢?如果工作中领导要求你制定一个数据库设计制度,你会怎么来写这个制度或流程?要想设计一个大的软件或平台,首先必须要有一个统一的设计规范。本文是一个简单的《数据库设计规范》范例,你可以做简单修改或直接拿来就用到工作中去。本文对广大刚接触数据库设计或刚工作不久的相关人员有更多指导作用。

范例共分以下几个部分:目的、适用范围、规范说明、标准词汇、命名规范、编码规范、数据字典书写格式 、E-R图的绘制模式、数据库后期维护的要求。具体范例如下:

1 目的
为了使软件开发过程有章可循,保证软件质量,加强开发管理。本规范为一套编写高效可靠的 数据库设计命名规范。它以安全可靠的软件工程原则为基础,使代码易于理解、维护和增强,提高生产效率。同时,将带来更大的一致性,使软件开发团队的效率明显提高。

2 适用范围
本适用于数据库模型的设计和ER图的创建过程,以及SQL语句,存储过程,触发器等开发,适用于相关的数据库开发管理人员、研发人员等。

3 规范说明
本规范与相关的适用范围的人员讨论最终确定,后期尽量保证少做变更,但也会根据实际应用的效果做进一步的优化与完善。

4 标准词汇
为使相关的设计文档可读性强,消除歧义,请使用标准词汇。
1. 表(Table)
2. 严格区分“表”和“库”,禁止“代码库”等不规范用法,而应使用“代码表”等词汇。例如:应命名为‘门诊信息表’,不能命名为‘门诊信息库’。
3. 字段(Field)
字段为行和列的交。严格区分“列(column)”和“字段”的用法。
4. 代码和编码
代码与编码是有区别的,编码作动词使用,由用户自己确定编码规则,例如:应称‘邮政编码’,不能称‘邮政代码’。代码是在业务中已存在的名词,不需要再确定编码规则,例如:应称‘股票代码’,不能称‘股票编码’。
5. 序号
避免使用“编号”等用法,如果是系统自动产生的值,都应称‘序号’。例如:‘流水序号’。如果是用户自已编的号,一律称‘编号’,不能称‘编码’。
6. 数据类型(Data Type)
指data type时,一律用“数据类型”,不要简称“类型”等。
7. 行(Row)
行和记录(record)含义相同,在文档中应尽量使用“行”。
8. 行数、列数
避免使用“记录数”、“字段数”等用法。

5 命名规范
5.1 基本原则
1. 所有数据库的实体命名都以字母、下划线或数字组成。
2. 有的数据库,有索引名长度18个字节限制,但考虑标准产品跨数据库的一致性,因此索引、主键、外键名统一遵循18个字节长度限制。
3. 使用可以准确说明数据表/数据列/函数/存储过程/触发器/序列/包/包体/作业的英文描述符。例如,采用类似 FIRST_NAME、PRODUCT_TYPE_ID这样的名字。虽然象 x1,y1 或 fn 这样的名字很简短,输入起来容易,但是我们难以知道它们代表什么、结果是什么含义,因而使编码难以理解、维护和改进。
4. 数据对象命名中,使用“_”连接符。如:PRODUCT_TYPE_ID、pub_user。
5. 采用该领域的术语。如果用户称他们的“客户” (clients) 为“顾客” (customers),那么就采用术语 Customer 来命名这个数据字段,而不用 Client。
6. 尽量少用缩写,但如果一定要使用,就要谨慎地使用。这意味着应该保留一个标准缩写的列表,明智地从中选取,并且在使用时保持一致。例如,想对单词“number”采用缩写,那么可从 nbr,no 或者 num 中选取一个,说明一下采用了哪一个(具体是哪个倒无所谓),并且只使用这一种形式。
7. 避免使用长名字(最好不超过 15 个字母)。虽然 PhysicalOrVirtualProductOrService 看起来似乎是个不错的类名,但是这个名字太长了,应该考虑重新给它起个短一点的名字。
8. 设计初首先对项目进行分析,设计子系统(或子模块的前缀),用于表、视图等名称的前缀。如:
aut_ 权限管理
rep_ 报表管理
pub_ 公共模块

5.2 具体数据对象命名规范

数据对象 最大长度 命名规范
视图 30 子系统前缀_标题_v如果是缩写则全部大写,否则用小写pub_user_v
30 子系统前缀_标题如果是缩写则全部大写,否则用小写pub_user  用户表rep_daily_bill账单日报表

 

表列 30 1.列名必须用一个或多个能表示其意思的英语单词来表示其中列名中不可包括“_X_”字符串。2.用户自定义定段N_X_00  (number)C_X_01  (char)

D_X_02  (date)

主键 18 PK_表名
外键 18 FK_表名_列名+被参照 (referenced) 表名(缩写)
索引 18 ID_表名_列名(缩写)
唯一索引 18 UI_表名_列名(缩写)
check约束 18 CK_表名_列名(缩写)
序列 30 SEQ_表名_列名(缩写)
存储过程 30 PRO_子系统前缀_标题存储过程名必须用一个或多个能表示其意思的英语单词来表示,每个单词首字母为大写,其他字母为小写。同时,前面要加前缀(PRO_);例如:PRO_pub_GetAllCustomer 
函数 30 _子系统前缀_标题函数名必须用一个或多个能表示其意思的英语单词来表示,每个单词首字母为大写,其他字母为小写。同时,前面要加前缀(fun _);例如:FUN_pub_ReturnCustomer 
30 PCK_标题
包体 30 PCK_BODY_标题
触发器 30 TRIG_规则1_规则2_表名触发器名将在后边有进一步的说明
JOB 30 JOB_名称

5.3 触发器(Trigger)命名规范
1. Insert触发器命名规则
BEFORE型:’TRIG_BE_IN_’ + 表名
AFTER 型:’TRIG_AF_IN_’ + 表名
2. Update触发器命名规则
BEFORE型:’TRIG_BE_UP_’ + 表名
AFTER 型:’TRIG_AF_UP_’ + 表名
3. Delete触发器命名规则
BEFORE型:’TRIG_BF_DE_’ + 表名
AFTER 型:’TRIG_AF_DE_’ + 表名

6 编码规范
6.1 代码缩进约定
列之间存在上下关系时,必须缩进4个空格(一个TAB)的间距;
一行有多列,超过80个字符时,基于列对齐原则,采用下行缩进;
where 子句书写时,换行时将and、or等写在换行首列,语句另起一行时,以保留字或者连接符开始,连接符右对齐;
例:

select /*+ ORDERED USE_NL(i p) */
u.name pnd_index_owner,
idx_name pnd_index_name,
ixp_name pnd_partition_name,
pnd_rowid,
pnd_timestamp
from dr$pending, dr$index i, dr$index_partition p, sys.user$ u
where idx_owner# = u.user#
and idx_id = ixp_idx_id
and pnd_pid = ixp_id
and pnd_pid != 0
and pnd_cid = idx_id
6.2 函数(存储过程)头头注释
编写函数文本–如视图、函数、触发器、存储过程以及其他数据对象时,必须为每个函数增加适当注释。该注释以多行注释为主,主要结构如下:
/************************************************************
*name : –函数名
*function : –函数功能
*input : –输入参数
*output : –输出参数
*author : –作者
*CreatedDate : –创建时间
*UpdateDate : –函数更改信息(包括作者、时间、更改内容等)–(更改记录多行,以最新记录在最前面)(基本成型时写更改信息)
************************************************************/
6.3 函数(存储过程)体内编写规范
当在函数体内有条件判断语法、循环判断语法、异常判断语法时,必须被BEGIN和END语法包含,例如:
IF <条件表达式>
BEGIN
<命令行或程序块>
END
ELSIF <条件表达式>
BEGIN
<命令行或程序块>
END

7 数据字典书写格式
例:
表名:sms_CP_info

字段名称

数据类型

空值

缺省值

规则

说明

CP_ID Number(4,0) N CP标识
CP_NAME Varchar2(200) N CP名称
CP_CODE Varchar2(40) N 企业编码

8 E-R图的绘制模式
例:
一个部门可能有0或多个雇员
一个雇员必须且仅属于一个部门

E-R图

E-R图

9 数据库后期维护的要求
1. 当数据库表或程序需要改动的时候,请务必做好文档的相关修改工作;
2. 当数据库表或程序需要改动的时候,请通知数据库管理人员完善数据库文档;
3. 数据变更要做好备份工作;
4. 要充分发挥好测试数据库的作用。