FAQ中心
页面树结构

版本比较

旧版本 1

changes.mady.by.user 潘家宜

保存于

比较

新版本 2

changes.mady.by.user 潘家宜

保存于

标识

  • 该行被添加。
  • 该行被删除。
  • 格式已经改变。

锚
3060-1621846615933
3060-1621846615933
还记得你第一次构建数据模型时的雄心壮志吗？想象着自己化身数据界的"神笔马良"，挥一挥鼠标，就能让杂乱无章的数据乖乖听话，变成一幅清晰明了的商业洞察图。
锚
FJFU-1738470665505
FJFU-1738470665505
然而现实总是骨感的，当你兴致勃勃地开始搭建，却发现：维度表主键重复？事实表数据缺失？关联关系一团乱麻？…… 恭喜你，成功解锁了数据模型构建的"隐藏关卡"——踩坑之旅！
锚
ylv4-1738470665507
ylv4-1738470665507
别担心，你不是一个人在战斗！这次，我们一起回顾那些年我们踩过的坑，一起笑看数据模型界的"乌龙事件"， 并从中吸取经验教训，让我们的下一次模型构建之旅更加顺畅！
锚
Rq5k-1739257625220
Rq5k-1739257625220
踩坑一：事实表不使用共享日期维表
锚
OwaU-1739257737538
OwaU-1739257737538
当处理包含多个日期列的事实表时，选择使用哪个日期列进行筛选变得尤为重要。若选择不当，可能导致日期序列的不连续性，进而造成查询结果中缺失某些天数。
锚
weGQ-1740622641438
weGQ-1740622641438
如下，我们直接使用销售表（sales)中本身的业务日期作为时间维度查询时，可以发现表中的日期是不连续的，缺少了6号、8号的日期数据。
锚
K4eg-1739351409980
K4eg-1739351409980
Image Added
锚
FMsV-1741312399319
FMsV-1741312399319
Image Added
锚
nXEZ-1739257839047
nXEZ-1739257839047
为了确保查询结果中日期序列的连续性，并且简化与日期相关的筛选逻辑，推荐的做法是创建一张共享的日期维度表。这张日期维度表不仅能够为报表提供所需的全部日期列，还可以包含额外的日期属性（如年、季度、月等），从而增强数据分析的能力并改善查询性能。
锚
DTfY-1739351551276
DTfY-1739351551276
Image Added
锚
0m2c-1741312613420
0m2c-1741312613420
Image Added
锚
rTat-1741312610918
rTat-1741312610918
当然有些细心的朋友在实践过程中，会发现为什么明明已经勾选了日期维表的日期字段了，可是还是出来的是不连续日期结果呢？这个时候，我们不要忘了还有个"压缩空行"的设置呢！
锚
EQpf-1741312878894
EQpf-1741312878894
什么是压缩空行？就是我们表中所有指标度量都为空的行会被压缩不显示。我们上面演示的连续日期示例中，4号、5号销量虽然为空，但是我们计算了累计值，所以即使没有关闭压缩空行，也可以显示连续的日期。如果我们表中有某些行指标数据都为空，又想显示连续日期，不要忘了关闭压缩空行的嗷。
锚
Zl5B-1741313289835
Zl5B-1741313289835
Image Added
锚
ZckZ-1737422678932
ZckZ-1737422678932

锚
wZ4X-1738477663661
wZ4X-1738477663661
踩坑二：关联了错误的字段
锚
6alp-1738478332328
6alp-1738478332328
在数据库设计或查询编写过程中，如果主外键字段别名不一致，很容易选错关联字段。订单明细表与订单表本应通过orderID进行关联，但一不小心却用了productID。这种情况不会直接报错，但它带来的后果是查询结果与实际情况完全不符，甚至一般情况下都无法查询出来数据。那么，如何避免这种关联字段设置错误的情况呢？
锚
uYY3-1738478306402
uYY3-1738478306402
Image Added
锚
QGJL-1738478495385
QGJL-1738478495385
这里有几个小技巧，可以帮助你确保关联字段的准确性：
锚
VlsO-1739171170701
VlsO-1739171170701
1. 深入理解数据：首先，深入了解每个表的数据结构和业务含义。明确每个字段的作用及其所代表的业务实体关系。知道每个字段标识的是什么，以及它们应该如何相互关联。
锚
0TTP-1739171176487
0TTP-1739171176487
2. 明确业务规则：接下来，清楚地定义不同表之间的业务关联规则。这包括识别哪些字段体现了一对一、一对多或多对多的关系，并确定对应的主键和外键是什么。
锚
2GAg-1739171178786
2GAg-1739171178786
3. 审查数据字典：利用数据字典或元数据文档作为你的工具书，比如利用Excel工具，创建好数据字典，查阅每个字段的具体信息，包括数据类型、来源、含义以及与其他字段的关联方式。
锚
wd7c-1739171180844
wd7c-1739171180844
4. 数据探索与预览：在建立关联之前，预览一下数据。检查字段的值是否符合预期，通过查看样本数据来验证关联字段是否能正确配对。
锚
2Xpz-1739171183804
2Xpz-1739171183804
5. 规范命名：最后，采用一致且具有描述性的字段命名规则。例如，如果主键和外键通常有相同的前缀或后缀，那么在关联时就能更轻松地找到正确的对应字段。
锚
ooUN-1739156290944
ooUN-1739156290944
踩坑三：数据本身有问题，维度数据不完整
锚
H4wb-1739156334962
H4wb-1739156334962
在进行数据分析时，可能会遇到这样一种情况：事实表中有对应的销售数据，但在维度表中却找不到相关的产品信息。例如，产品维度表中的产品编号仅有16、32、42、47和56，而事实表中却包含了额外的产品编号4。当根据产品名称查询销量时，我们会发现部分产品名称显示为空白，但数量字段却有实际的数据。这种情况在SmartbiBI工具中是正常的，因为它准确反映了数据的现状——即某些销售记录缺乏有效的维度信息。
锚
ORNg-1739156352904
ORNg-1739156352904
Image Added
锚
0DQD-1739157398985
0DQD-1739157398985

锚
T3Vp-1739156388015
T3Vp-1739156388015
Image Added
锚
R5jF-1739156606199
R5jF-1739156606199
这种空白并不是系统异常，而是数据本身的一种体现。当然，为了提高数据分析的质量和用户体验，我们可以采取一些措施来解决这个问题：
锚
FTR7-1739171574170
FTR7-1739171574170
1、识别并修正缺失的数据
锚
UbPm-1739171589412
UbPm-1739171589412
源头排查：首先，检查源头系统，找出为何某些产品编号没有进入维度表的原因。这可能涉及到业务流程中的某个环节出现了偏差。
锚
71el-1739171591928
71el-1739171591928
基于业务规则决策：一旦找到原因，根据业务规则判断这些缺失的数据是否应当被删除或替换为有效的数据。比如，如果产品编号4实际上是一个已停产的产品，考虑将其标记为"停售"状态而不是直接删除，以便保留历史销售数据的完整性。
锚
XWGP-1739171596038
XWGP-1739171596038
2、 利用ETL进行数据清洗
锚
AJZx-1739171598630
AJZx-1739171598630
数据处理：通过ETL对数据进行清洗。在数据加载到分析环境之前，先对其进行一系列的转换操作，如填充缺失值、标准化数据格式等。
锚
tf2b-1739171600421
tf2b-1739171600421
提升数据质量：ETL工具可以帮助我们自动检测并处理那些不完整或不一致的数据，确保最终展示给用户的是一份高质量的数据集。
锚
7c0s-1739156352908
7c0s-1739156352908
踩坑四：关系有多义性
锚
hrpn-1739157400453
hrpn-1739157400453
关系的多义性，是指当一张表触达另外一张表有多个路径。在多个事实表同时共享两个不同维度时，开启了双向筛选，会形成环路，也就是多个路径可选择，系统无法自动选择查询路径。
锚
ADd8-1740537912031
ADd8-1740537912031
如下：当下有销售表和目标表，期望可以实现如下两种查询场景：
锚
TgLC-1740563219182
TgLC-1740563219182
（1）可以选择产品表中的产品名称，查询目标销量、实际销量情况
锚
65qO-1740563222430
65qO-1740563222430
（2）年月日查询各个产品下的实际销量、目标销量以及目标销量的前期值
锚
ZCKF-1740620722550
ZCKF-1740620722550
Image Added
锚
FgHT-1740563220168
FgHT-1740563220168
通过日期与产品的构建计算列为主键关联查询时，提示关系路径"多义性"。如图中箭头指示，红色箭头表示"产品表"通过路径1直接可达"目标表"；绿色剪头则表示"产品表"可通过路径2，即从"产品表"可通过"销售表"再到"目标表"。这样生成了两条筛选路径，造成多义性。我们需要保持"一个原则"：1节点只能有一条路径到达相同的另外1个节点。
锚
Du89-1740620692383
Du89-1740620692383
Image Added
锚
Pfz3-1739157413994
Pfz3-1739157413994
当遇到这种情况如何解决？
锚
hNXp-1739157413996
hNXp-1739157413996
1、按需使用双向筛选：评估是否真的需要开启双向筛选功能。在数据模型中，一对一的筛选方向是默认开启双向的；而一对多/多对一关系的两个表，默认是一方的维度可以筛选多方的维度或数据，在一对多或多对一的关系中，如果期望多方的维度能直接过滤一方的维度或数据，就需要启用双向筛选。基数与筛选方向的更多说明，我们也可在上月《99% 的人都忽略了！强大模型的崛起秘密在于设置正确关系（上）》一文中再做了解。
锚
zctH-1740477907187
zctH-1740477907187
Image Added
锚
6s1m-1739172538303
6s1m-1739172538303
2. 抽取共享维表：考虑为共享维度创建一个独立的维表，如下，抽取公共的日期维度，通过公共的日期维表进行关联。
锚
ZzkW-1740478047773
ZzkW-1740478047773
Image Added
锚
CXRQ-1740563799016
CXRQ-1740563799016

锚
WqA4-1739947320881
WqA4-1739947320881
在这篇文章中，我们一起回顾了在数据建模过程中常见的"乌龙事件"，从缺失的维度表数据到错误的关联字段，再到复杂的多路径关系。虽然每个坑都可能让我们一时头疼，但通过深入理解业务需求、遵循科学的数据建模方法论，灵活运用工具和技术，我们总能找到解决问题的最佳路径。希望这些经验不仅能帮助大家避开类似的陷阱，还能让大家在未来的更多实战中中更加从容自信。数据建模的世界总是充满惊喜（和挑战），下个月我们将继续探讨更多踩坑历史，敬请期待——《模型界的"乌龙事件"：那些年我们踩过的坑（下篇）》！