作为一家分析机构，我们喜欢为客户提供自助式分析工具。能够让业务用户不仅探索我们准备好的仪表板，还能探索整个数据集的想法，是非常强大的。但业务用户在开始自助式分析时常常会遇到困难。
在本文中，我们将说明典型的实体关系数据模型在自助式分析中遇到的问题，并讨论如何通过使用不同的数据建模技术来改进自助式体验。
想象一下，我们有一个从 Google Analytics 获取的典型数据集。我们有关于用户及其事件的信息。通常，我们会为此类数据设置两个表：Users 和 Events。
示例用户数据集： 
示例事件数据集： 
为了满足自助式需求，我们通常通过主外键链接 EVENTS 表和 USER 表，并获得 EVENTS 表中的一些 USER 属性。
这种方法似乎是合理的，至少直到有一天，一位客户要求绘制 DAU（每日活跃用户）以供管理层会议使用。
“您可以自助完成”，——我们说。“只需进入 EVENTS 表，按天计算独立用户数”。
“但是”，——业务用户说，“如果我想绘制每日活跃用户，为什么我应该去看 EVENTS 表？我真的不明白！”
这就是公司自助式分析发展中的真正障碍——对工程师来说显而易见的东西，对核心业务用户来说不一定显而易见。
因此，我们决定找到一种比经典的实体关系模型更适合自助式需求的数据模型。
在对数据建模技术进行一些探索后，我们遇到了 Minimal Modeling（最小建模）方法，该方法将数据库分解为锚点（域中的主要名词）、锚点之间的链接以及属性。
Minimal Modeling 的要求之一是将链接表与锚点表分开。
因此，在重新建模我们的数据集后，我们得到了
-
锚点表（USER 和 EVENT）
-
以及一个单独的链接表
该链接表包含两个 id：user_id 和 event_id，以及事件发生的时间戳。 
而这里的技巧是：如果我们使用这个链接表作为自助式分析的主表，我们就可以将 USER 和 EVENTS 表链接到它。
因此，USER 和 EVENTS 表将在“汇总”侧边栏中享有相同的排名。
因此，如果业务用户需要绘制每日活跃用户指标，他不必猜测应该去哪里：是 USERS 表还是 EVENTS 表。他会转到链接表，作为入口点。
使用链接表构建的每日活跃用户： 
并且可以使用一个链接表来定义 USERS 和 EVENTS 的指标。这种拥有一个宽泛链接表라는想法可以被扩展：如果我们有 ORDERS、TRANSACTIONS 和其他域锚点，它们也可以链接到单个链接表中，所以它成为自助式需求的单一入口点。