新用户初见 V11 里的数据模型，新奇得像打开了神秘世界大门，迫不及待想一探究竟。
老用户升级到V11 后，却像闯入陌生领域，对数据模型 "当家" 满心疑惑。肯定都在想：SQL 用得好好的，为啥要引入数据模型？它比 SQL 强在哪？要是必须用，该怎么掌握它？ 这满腹疑虑，今天就在这里为大家解个小惑，进入数据模型的世界。

为什么现在只有数据模型？
对于老用户来说，升级到V11后：诶嘿！怎么不能新建原生SQL数据集、业务主题呢？为啥只能新建数据模型了呢！
其实问题主要出在旧版本的设计上：

1. 概念太多记不住：以前产品里又是数据集又是业务主题，光名字就一大堆。根本分不清什么时候该用哪个，就像超市货架上摆满包装相似的调料瓶，厨房小白根本不知道该选哪瓶；
2. 操作入口像迷宫：各个功能的入口东一个西一个，就像家里遥控器按键乱排布，想开个空调都得把所有按钮试一遍，经常转了几圈都找不到正确入口。
3. 功能配合总打架：最头疼的是数据管理和界面展示混在一起，就像炒菜时盐罐糖罐放反了，总找不到。比如：

• 做即席查询时，用不了数据集；
• 做电子表格时，又用不了业务主题；

这些矛盾让新手完全摸不着头脑，就像拿到一副缺零件的拼图。
新版本用"数据模型"一招解决所有问题：

1. 操作简单：就像把所有工具收进一个万能工具箱，数据处理统一通过数据模型完成；
2. 接口统一：所有功能入口都归整到模型里，升级维护像收拾好的衣柜一样方便；
3. 自由组合：无论是即席查询、透视分析还是电子表格，都能直接调用模型里的数据，就像乐高积木随便拼搭都不会出错。

那前面我们大致了解了为啥新版本会有数据模型这么一个"大哥"存在，现在我们就来了解了解下这位大哥他能力到底有多强吧~

数据模型的定义

首先我们来了解下数据模型的定义。它是一个数据处理中间层，对不同来源的数据进行整合，定义维度和指标，进行数据加工、计算，为所有可视化组件提供标准、统一的数据结构。

数据模型的能力

能力1：接入、整合多种数据集
数据模型整合多种数据集类型，融合线上线下数据。包括数据源表、SQL查询、即席查询、导入文件等，并支持跨库数据增和。可以直接连接Oracle、MySQL、Excel文件等各类数据关联分析，满足不同用户的数据准备需求，提升数据分析的效率。

能力2：支持敏捷建模
Smartbi数据模型支持拖拽等简单操作即可快速生成度量、维度层次，如一键生成时间维、设置地理维等，同时支持多种模型类型，包括星型模型、雪花模型和星座模型。

能力3：计算能力提升并统一
数据模型对Smartbi产品数据准备和数据分析之间的关系进行了重新梳理，统一了表现层和数据层，统一了数据分析的计算能力，提供了丰富、强大的计算能力，不仅支持SQL计算、ETL分布式计算、MDX计算；还支持快速实现同环比时间计算、占比、排名、累计等；同时支持在计算中使用参数，动态获取结果。

能力4：高速缓存库MPP
数据模型同样支持抽取模式，将模型的数据抽取到SmartbiMPP数据库中提升查询效率，计算速度会更快。但同时数据也需要定期更新。

经过上面的了解，数据模型是否真的能够包罗万象，实现全领域接入并解决所有问题呢？答案显然是否定的。正如任何技术都有其局限性，数据模型同样存在无法有效应对的应用场景。让我们接着往下了解吧~

数据模型当前限制

1、目前不支持接入多维数据库，模型中接入不同的数据库表时需要切换成抽取模式；
2、数据源表就不支持映射参数；脚本查询、Java查询这些就不支持直连模式。
3、目前Smartbi暂未直接支持多对多的关系，如现实业务是多对多的关系，建议中间增加一张关系表，然后原始的两张表和这张中间关系表变成一对多的关系。
4、计算列不支持跨表创建，分组字段不支持计算列、度量等字段
呐，在我们对数据模型有个简单的了解后，大家肯定都很好奇，那我要怎么使用这个数据模型呢？我是不是把所有我要的字段、查询信息全部放到一个数据模型里面呢？这当然不是的，要用好数据模型，那我们还得先知道下基础的建模知识。

数据模型是围绕事实表和维度表的关系而进行模型的构建，首先我们先来看看什么是维度和指标。

维度其实就是观察问题的角度，是你用来"分类""分组"或"观察"数据的标签，就像看世界的不同"滤镜"。比如你想知道"北京地区的手机在2023年卖了多少"，这里的时间、地区、产品都是维度。
指标就是被计算的数值，通常是数字，比如总和、平均值等。比如你想知道"北京地区的手机在2023年卖了多少钱"，这里的"钱"就是度量（销售额的总和）。
那清楚了维度和指标的概念后，对应的维度表和事实表也就很容易理解啦~
维度表就是以合适的角度来创建的表，分析问题的一个角度：时间、地域、终端、用户等角度。
事实表是存储必然存在的一些数据，像采集的日志文件，订单表，都可以作为事实表。

当我们知道事实表，维度表这些概念了，但是实际业务中，给了我们一堆数据，我们怎么拿这些数据进行建模呢？这里就需要我们的建模四步走了：
1、选择业务过程：这一步需要我们定下重点，先想清楚老板最关心的是啥？
2、声明粒度：其实就是记得详细点，数据要细到每一笔交易；
3、确认维度：这一步就是一个打标签的环节，给每个数据贴分类小纸条，比如给谁买的？啥时候买的这些；
4、确认事实：最简单的理解就是只抓数字，只记住能算钱的数，比如买了多少杯，一杯多少钱。

总的来说就是我们在建模的时候可以："先盯问题 → 细记流水账 → 分类贴标签 → 只留算钱数！"
像记账：记清每一笔（细），按时间/商品分类（标签），最后算总收入（数字）

前面说的这么多是不是弯弯绕绕的？！没得事，我们先来看看一个简单的示例。
场景：一个成交量的交易记录，一个保有量的交易记录，"产品代码"列有部分重叠。

需要实现如下的效果：

清楚案例的场景和要实现的效果后，可能有的小伙伴就会在数据模型中直接将AB两表进行关联。

那实际上这样的处理会存在一定的问题：
1、查询时，不知道应选A表还是B的产品代码。
2、基数怎么变换结果也都是错的。
3、查询结果不正确.

而如果使用前面提到的维度建模的方式建模：将AB两表的产品代码字段抽出来作为一个单独的维表后，与AB两表分别根据产品代码字段关联后，优势就有很多啦。比如后续业务用户只需要根据产品代码维的维度进行查询，且查询结果也是正确的。另外就是开发人员在设置基数的时候更容易设正确；