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