#业务建模总览

语义层将底层数据表抽象为可复用的指标和维度，是业务建模页面的核心。下文介绍如何配置字段、公式，保证业务口径统一。

#整体建模方法论

做好业务建模，需要从数据源和指标两个层面进行规范设计。

#数据模型规范

推荐使用三范式建模或雪花模型（维度建模），其中三范式建模的效果最好。

关于三范式建模或雪花模型相关文章，可点此查看

#要点一：一个概念尽量只存在于一处

举例：如北京、上海这些地理位置，可以存到一张地理位置表中，其他所有表通过外键关联到此表，而不是每一张表中都有独立的地理位置字段。

#要点二：数据尽量清洗干净

举例：如果企业自身数据里面有一家子公司的公司名叫「北京」，那么会和地理位置的「北京」相冲突。当用户问「北京今年业绩」时，系统会有歧义。虽然系统会弹出二次确认让用户选择，但会影响用户体验。

#指标规范

数据中的指标指的是数据表中那些可计算、需要聚合的值，例如销售额、收入等。

#要点一：指标具备可加性

指标在各维度上的加总应该等于全体加总。

反面例子一：数据库里有 1～12 月份每个月的销售目标数据，另外还有一行是全年的销售目标数据，并且月度加总不等于全年目标。这样的数据结构会大幅增加实施难度。

反面例子二：数据库里有一个「近视率」指标，记录了每年在每个省份的近视率，还有一行每一年全国的近视率。在这种数据情况下，类似「长三角的近视率」此类问题无法回答。

正确做法应该是同时保存分子和分母，即每年在每个省份的近视人数以及总人数，近视率则使用系统的自定义指标功能配置动态公式。

注：系统也支持一些非可加性的指标，如观测类指标（余额类指标），详情请搜索 is_observation 参数。

#要点二：指标不要带上维度

观察以下表格：

在此数据结构下，主渠道收入 + 副渠道收入 = 总收入。其中主渠道和副渠道其实是数据维度，而不是指标的一部分。这个场景下只有一个指标，叫做「收入」。主渠道和副渠道应该是公司具体某一个渠道的分类属性。

正确的表结构应该改造为：

渠道表：

收入表：