|
还记得你第一次构建数据模型时的雄心壮志吗？想象着自己化身数据界的“神笔马良”，挥一挥鼠标，就能让杂乱无章的数据乖乖听话，变成一幅清晰明了的商业洞察图。
然而现实总是骨感的，当你兴致勃勃地开始搭建，却发现：维度表主键重复？事实表数据缺失？关联关系一团乱麻？…… 恭喜你，成功解锁了数据模型构建的“隐藏关卡”——踩坑之旅！
别担心，你不是一个人在战斗！这次，我们一起回顾那些年我们踩过的坑，一起笑看数据模型界的“乌龙事件”， 并从中吸取经验教训，让我们的下一次模型构建之旅更加顺畅！
踩坑一：事实表不使用共享日期维表
当处理包含多个日期列的事实表时，选择使用哪个日期列进行筛选变得尤为重要。若选择不当，可能导致日期序列的不连续性，进而造成查询结果中缺失某些天数。
如下，我们直接使用销售表（sales)中本身的业务日期作为时间维度查询时，可以发现表中的日期是不连续的，缺少了6号、8号的日期数据。
为了确保查询结果中日期序列的连续性，并且简化与日期相关的筛选逻辑，推荐的做法是创建一张共享的日期维度表。这张日期维度表不仅能够为报表提供所需的全部日期列，还可以包含额外的日期属性（如年、季度、月等），从而增强数据分析的能力并改善查询性能。
当然有些细心的朋友在实践过程中，会发现为什么明明已经勾选了日期维表的日期字段了，可是还是出来的是不连续日期结果呢？这个时候，我们不要忘了还有个“压缩空行”的设置呢！
什么是压缩空行？就是我们表中所有指标度量都为空的行会被压缩不显示。我们上面演示的连续日期示例中，4号、5号销量虽然为空，但是我们计算了累计值，所以即使没有关闭压缩空行，也可以显示连续的日期。如果我们表中有某些行指标数据都为空，又想显示连续日期，不要忘了关闭压缩空行的嗷。
踩坑二：关联了错误的字段
在数据库设计或查询编写过程中，如果主外键字段别名不一致，很容易选错关联字段。订单明细表与订单表本应通过orderID进行关联，但一不小心却用了productID。这种情况不会直接报错，但它带来的后果是查询结果与实际情况完全不符，甚至一般情况下都无法查询出来数据。那么，如何避免这种关联字段设置错误的情况呢？
这里有几个小技巧，可以帮助你确保关联字段的准确性：
1. 深入理解数据：首先，深入了解每个表的数据结构和业务含义。明确每个字段的作用及其所代表的业务实体关系。知道每个字段标识的是什么，以及它们应该如何相互关联。
2. 明确业务规则：接下来，清楚地定义不同表之间的业务关联规则。这包括识别哪些字段体现了一对一、一对多或多对多的关系，并确定对应的主键和外键是什么。
3. 审查数据字典：利用数据字典或元数据文档作为你的工具书，比如利用Excel工具，创建好数据字典，查阅每个字段的具体信息，包括数据类型、来源、含义以及与其他字段的关联方式。
4. 数据探索与预览：在建立关联之前，预览一下数据。检查字段的值是否符合预期，通过查看样本数据来验证关联字段是否能正确配对。
5. 规范命名：最后，采用一致且具有描述性的字段命名规则。例如，如果主键和外键通常有相同的前缀或后缀，那么在关联时就能更轻松地找到正确的对应字段。
踩坑三：数据本身有问题，维度数据不完整
在进行数据分析时，可能会遇到这样一种情况：事实表中有对应的销售数据，但在维度表中却找不到相关的产品信息。例如，产品维度表中的产品编号仅有16、32、42、47和56，而事实表中却包含了额外的产品编号4。当根据产品名称查询销量时，我们会发现部分产品名称显示为空白，但数量字段却有实际的数据。这种情况在SmartbiBI工具中是正常的，因为它准确反映了数据的现状——即某些销售记录缺乏有效的维度信息。
这种空白并不是系统异常，而是数据本身的一种体现。当然，为了提高数据分析的质量和用户体验，我们可以采取一些措施来解决这个问题：
1、识别并修正缺失的数据
源头排查：首先，检查源头系统，找出为何某些产品编号没有进入维度表的原因。这可能涉及到业务流程中的某个环节出现了偏差。
基于业务规则决策：一旦找到原因，根据业务规则判断这些缺失的数据是否应当被删除或替换为有效的数据。比如，如果产品编号4实际上是一个已停产的产品，考虑将其标记为“停售”状态而不是直接删除，以便保留历史销售数据的完整性。
2、 利用ETL进行数据清洗
数据处理：通过ETL对数据进行清洗。在数据加载到分析环境之前，先对其进行一系列的转换操作，如填充缺失值、标准化数据格式等。
提升数据质量：ETL工具可以帮助我们自动检测并处理那些不完整或不一致的数据，确保最终展示给用户的是一份高质量的数据集。
踩坑四：关系有多义性
关系的多义性，是指当一张表触达另外一张表有多个路径。在多个事实表同时共享两个不同维度时，开启了双向筛选，会形成环路，也就是多个路径可选择，系统无法自动选择查询路径。
如下：当下有销售表和目标表，期望可以实现如下两种查询场景：
（1）可以选择产品表中的产品名称，查询目标销量、实际销量情况
（2）年月日查询各个产品下的实际销量、目标销量以及目标销量的前期值
通过日期与产品的构建计算列为主键关联查询时，提示关系路径“多义性”。如图中箭头指示，红色箭头表示“产品表”通过路径1直接可达“目标表”；绿色剪头则表示“产品表”可通过路径2，即从“产品表”可通过“销售表”再到“目标表”。这样生成了两条筛选路径，造成多义性。我们需要保持“一个原则”：1节点只能有一条路径到达相同的另外1个节点。
当遇到这种情况如何解决？
1、按需使用双向筛选：评估是否真的需要开启双向筛选功能。在数据模型中，一对一的筛选方向是默认开启双向的；而一对多/多对一关系的两个表，默认是一方的维度可以筛选多方的维度或数据，在一对多或多对一的关系中，如果期望多方的维度能直接过滤一方的维度或数据，就需要启用双向筛选。基数与筛选方向的更多说明，我们也可在上月《99% 的人都忽略了！强大模型的崛起秘密在于设置正确关系（上）》一文中再做了解。
2. 抽取共享维表：考虑为共享维度创建一个独立的维表，如下，抽取公共的日期维度，通过公共的日期维表进行关联。
在这篇文章中，我们一起回顾了在数据建模过程中常见的“乌龙事件”，从缺失的维度表数据到错误的关联字段，再到复杂的多路径关系。虽然每个坑都可能让我们一时头疼，但通过深入理解业务需求、遵循科学的数据建模方法论，灵活运用工具和技术，我们总能找到解决问题的最佳路径。希望这些经验不仅能帮助大家避开类似的陷阱，还能让大家在未来的更多实战中中更加从容自信。
数据建模的世界总是充满惊喜（和挑战），下周我们将继续探讨更多踩坑历史，敬请期待—— 《模型界的“乌龙事件”：那些年我们踩过的坑（下篇）》！ | 
