第67天知识点：模型视图
FineBI6.0版本之后，新增了模型视图。
就我身边人使用之后的反馈而言，基本是两个极端： 要么喜、要么愁。
喜方很爱用这个功能，觉得拖拽即关联，非常高效便捷，越用越上头。
愁方是搞不懂关联背后的逻辑是什么，担心结果的准确性，索性完全不用。
不知道各位小伙伴使用过这个功能之后是什么体验呢？
今天我们就通过一个案例来简单了解一下模型视图背后的合并逻辑。
在正式开始之前，我们先带大家看一下模型中常见的1:1、1:N分别是什么样的关联关系？
（PS：N:N关系比较复杂，后面单独分享）
假如现在你是一家品牌零售店的数据分析师，你有三张数据表，分别如下：
「产品销售目标表」：记录了每个产品的销售目标。
「产品销售表」：记录了每个产品的销售额。
「员工产品销售表」：记录了每个员工的每个产品的销售额。
现在你需要通过这三张表计算出每个产品的销售目标达成率。
其实结果大家一眼就能看出来，但我们的目的并不是为了算出结果，而是了解如何计算出结果的？
假如你现在用的是「产品销售目标表」和「产品销售表」：
「产品销售目标表」和「产品销售表」里都有【产品编号】这个字段，且这两张表里这个字段都是唯一的，所以用最终得到的结果表计算销售目标达成率没有任何问题。
假如你现在用的是「产品销售目标表」和「员工产品销售表」：
「产品销售目标表」和「员工产品销售表」里都有【产品编号】这个字段，但「员工产品销售表」里这个字段并不是唯一的，A001出现了2次，所以最终得到的结果表中A001产品的销售目标出现了膨胀，也出现了2次，导致最后计算销售目标达成率时会有问题。
其实，这也是我们使用左右合并后会存在的问题。
那对于1:N这种问题，有什么好的便捷的解决办法吗？
这就要回到我们今天说的模型视图上来了。
1、解决数据冗余问题。
数据模型只是对原有的数据表之间建立了关联，并不会生成一张新的大宽表。
2、解决数据膨胀问题。
比如我们上面提到的1:N的例子，因为编号A001的目标产生膨胀，导致最后目标完成率计算错误。但如果直接使用数据模型，则会先将各产品的销售额相加，也就相当于将「员工产品销售表」先加工成「产品销售表」的过程，然后再用目标值表去匹配相加后的销售额，这样就可以得到正确的结果了。
我们来看一看具体操作步骤。
1、建立模型关系
拖拽「员工产品销售表」到需要配置关联关系的「产品销售目标表」上，即可生成连线。
2、编辑模型关系
建立模型关系后，会弹出编辑关系界面，这里我们可以编辑匹配字段以及关联关系。
当然，不用担心你该选择什么样的关联关系，因为在建立模型关系后，系统会根据数据情况自动选择最合适的模型关系。
3、制作组件
将「员工产品销售表」中的【产品名称】、【销售额（元）】，「产品销售目标表」中的【产品编号】、【销售目标（元）】分别拖入如下位置：
这时，本来两张独立的数据表，因为我们建立了模型关系，便可以直接得到如下的结果：
可以发现，既没有左右合并的一步步操作，结果表中的目标值也并没有出现膨胀。
以上就是模型视图的合并逻辑，也是它的最大特点：
-
只让参与到分析的字段和关联字段参与模型视图的合并
-
执行先聚合再合并
是不是想到了聚合函数？
拆分成步骤的话，则是：
1、系统判断用户在组件中拖入了哪些字段，只有拖入的字段和关联字段参与模型视图合并；
2、 将数据表先后按「关联字段」和「组件中拖入的维度」对表进行聚合；
3、将聚合后得到的表进行合并。
但模型视图也存在一些局限性，比如：
1、建立模型视图的数据无法发布到公共数据；
2、关联字段只能选择一个，如果需要多条件关联，只能在数据表中对关联字段先进行处理；
2、建立模型操作看似简单，但背后的合并逻辑理解成本比较高。
好了，今天的内容就分享就到这里。
感兴趣的小伙伴自己动手试试看哦~
| 
