...
| 锚 |
|---|
| iGDp-1736931644497 |
|---|
| iGDp-1736931644497 |
|---|
|
接下来咱就来开启模型关系小课堂吧。
什么是关系
| 锚 |
|---|
| BTSP-1737009497438 |
|---|
| BTSP-1737009497438 |
|---|
|
像咱平时数据库肯定是会有很多张表、或者加工处理出来很多个查询，那么在数据模型中想把这些表和查询等关联起来，就需要设置它们之间的关系。
| 锚 |
|---|
| 1A1N-1737441976136 |
|---|
| 1A1N-1737441976136 |
|---|
|
那要怎么确定这些表和查询之间到底有没有关系呢，这个时候就需要从业务上去梳理梳理。以产品内置的订单模型为例：
...
| 锚 |
|---|
| Syjh-1737442340427 |
|---|
| Syjh-1737442340427 |
|---|
|
一种产品类别会有多个产品；
| 锚 |
|---|
| k0KW-1738993270438 |
|---|
| k0KW-1738993270438 |
|---|
|
一种产品可来源于多条订单明细；
| 锚 |
|---|
| uPnM-1737442428651 |
|---|
| uPnM-1737442428651 |
|---|
|
一个订单可对应多条订单明细；
| 锚 |
|---|
| J4HO-1738992921687 |
|---|
| J4HO-1738992921687 |
|---|
|
一位顾客能产生多条订单记录；
| 锚 |
|---|
| lba8-1739726837102 |
|---|
| lba8-1739726837102 |
|---|
|
| 锚 |
|---|
| Wt6p-1739383759424 |
|---|
| Wt6p-1739383759424 |
|---|
|
因此可以得到如下图的关系连线：
| 锚 |
|---|
| ELlt-1739726832205 |
|---|
| ELlt-1739726832205 |
|---|
|
每条关系都可以用一条线表示，并指示了俩端(1表示1端，*表示多端)
| 锚 |
|---|
| u9z8-1739381365054 |
|---|
| u9z8-1739381365054 |
|---|
|
| 锚 |
|---|
| ySAu-1738993993022 |
|---|
| ySAu-1738993993022 |
|---|
|
| 锚 |
|---|
| NM5L-1737442462032 |
|---|
| NM5L-1737442462032 |
|---|
|
这样，基于上述业务逻辑的梳理，我们就已经得知了订单模型中各表之间的联系，接下来，就可以在数据模型中深究关系的配置及原理了。
| 锚 |
|---|
| 1sV8-1737009669767 |
|---|
| 1sV8-1737009669767 |
|---|
|
关系组成四大要素
| 锚 |
|---|
| eekc-1737009672866 |
|---|
| eekc-1737009672866 |
|---|
|
那要在数据模型里构成关系，咱就可以了解下构成表关系的这四大要素：表(维表、事实表)、连接字段(列)、基数、筛选方向。
| 锚 |
|---|
| jd7w-1738995567679 |
|---|
| jd7w-1738995567679 |
|---|
|
| 锚 |
|---|
| toC7-1739001859651 |
|---|
| toC7-1739001859651 |
|---|
|
一：表（维度表、事实表）
| 锚 |
|---|
| Usqv-1737009798776 |
|---|
| Usqv-1737009798776 |
|---|
|
这里的表可以叫主键表、外键表，在数据模型中我们通常把他叫做维度表、事实表。我们经常能看到，数据模型里的表有的是蓝色有的是绿色，这就是咱用来初步区分维表和事实表的颜色标识。其中，
...
| 锚 |
|---|
| ojN1-1739002815095 |
|---|
| ojN1-1739002815095 |
|---|
|
表在数据模型中也会叫做查询，目前有9种类型可选，包含数据源表、SQL查询等。在模型视图中，"一"方代表维度表，"多"方代表事实表。
需要注意：由于是动态建模，在查询时根据勾选的字段，维表也可能会变成事实表。| 锚 |
|---|
| e2vu-1739002257970 |
|---|
| e2vu-1739002257970 |
|---|
|
二：连接字段
对关系的连接线段"双击"或者"右键编辑"，可以修改连接字段、基数和筛选方向。
一般关系中的连接字段是以表的主键或者外键来建立联系的，目前Smartbi会自动识别主键和外键，确定两个表之间关联字段，通过获取字段名，然后逐个匹配，查找别名相同的列且数据类型要一致，才会自动关联。
...
| 锚 |
|---|
| doDR-1739151982364 |
|---|
| doDR-1739151982364 |
|---|
|
| 锚 |
|---|
| Up6H-1739001861072 |
|---|
| Up6H-1739001861072 |
|---|
|
三：基数
| 锚 |
|---|
| xwkt-1739001861081 |
|---|
| xwkt-1739001861081 |
|---|
|
基数也就是1和*，能用来反映真实业务数据之间联系，数据模型中的基数类型有：一对一、一对多、多对一（不支持多对多）。
| 锚 |
|---|
| YRpW-1739155835359 |
|---|
| YRpW-1739155835359 |
|---|
|
基数的选择是决定模型关系设置是否正确的关键之一，很多小伙伴在前期错误的设置了基数关系，那后来数据动态变化了不满足基数选择就经常会出现查询数据错误的情况了。这就要求咱们在选择基数关系时，需要理解真实业务，判断真实业务之间是一对一、一对多还是多对多的联系。
...
| 锚 |
|---|
| QwYa-1739001861084 |
|---|
| QwYa-1739001861084 |
|---|
|
虽然产品目前并不直接支持多对多关系，但遇到多对多关系场景时，我们可以采用星型架构设计原则，而不是直接关联事实类型表。 一般可以通过添加维度表来实现， 然后，维度类型表通过使用一对多关系与事实类型表关联。 通过这种设计方法，可使用任何维度类型列进行筛选或分组，并汇总任何相关联的事实类型表。（具体示例见下篇-"示例3、多对多"）
| 锚 |
|---|
| HdLE-1739378137555 |
|---|
| HdLE-1739378137555 |
|---|
|
四：筛选方向
| 锚 |
|---|
| nLZr-1739002612097 |
|---|
| nLZr-1739002612097 |
|---|
|
筛选方向定义的是维度之间过滤方向，在模型视图中用箭头表示，A->B代表A中的维度可以筛选B中的数据，而B中的维度不可以筛选A中的数据。
| 锚 |
|---|
| ZzQB-1739378498949 |
|---|
| ZzQB-1739378498949 |
|---|
|
筛选方向包含了单向和双向，在这里筛选方向结合基数一起更好做理解：
...
| 锚 |
|---|
| 9nqm-1739729048246 |
|---|
| 9nqm-1739729048246 |
|---|
|
这样做的好处是：在查询时，会根据用户所选维度、度量、条件，从数据模型中，动态查找相关表及其子图，基于命中后的子图再查数，能排除其他无关表，避免出现肥模型每次查询很多张表关联查询性能慢的情况。
| 锚 |
|---|
| Q6q7-1739728446086 |
|---|
| Q6q7-1739728446086 |
|---|
|
因此查询性能的关键，就落到了命中的子图本身的查询性能，和整个数据模型关系不大或者说是固定消耗（除非模型超大，模型定义的解析会消耗较多时间)。
| 锚 |
|---|
| GW5h-1739380192812 |
|---|
| GW5h-1739380192812 |
|---|
|
模型关系设置的一些实际应用可移步到Smartbi进一步学习：https://my.smartbi.com.cn/thread-11464-1-1.html
