作为一家分析机构，我们非常乐意为客户提供自助分析工具。业务用户不仅可以探索我们准备的仪表板，还可以探索整个数据集，这个想法非常强大。但是，业务用户常常在开始使用自助分析时遇到困难。
在本文中，我们将说明自助服务中常见的实体关系数据模型的典型问题，并讨论如何通过使用不同的数据建模技术来改善自助服务体验。
假设我们有一个从 Google Analytics 获取的典型数据集。我们有关于用户及其事件的信息。通常，对于这类数据，我们将有两个表：Users 和 Events。
Sample user dataset: 
Sample events dataset: 
为了满足自助服务需求，我们通常通过主键-外键将 EVENTS 表和 USER 表链接起来，并从 EVENTS 表中获取一些可用的 USER 属性。
这种方法看起来是合理的，至少在有一天，我们的一位客户要求在管理会议上绘制 DAU（日活跃用户）之前是这样。
“您可以在自助服务中完成它”，——我们说。“只需转到 EVENTS 表，按天数计算不同的用户数”。
“但是”，——业务用户说，“如果我想绘制每日活跃用户，为什么我应该去 EVENTS 表？我真的不明白！”
这就是公司自助分析发展的真正障碍——对于工程师来说可能显而易见的事情，对于核心业务用户来说不一定显而易见。
因此，我们决定寻找一种比经典实体关系模型更适合自助服务需求的数据模型。
在探索了一些数据建模技术之后，我们遇到了 Minimal Modeling 方法，该方法将数据库分解为锚点（域的主要名词）、锚点之间的链接和属性。
Minimal Modeling 的要求之一是有一个与锚点表分离的链接表。
因此，在重塑数据集之后，我们得到
-
Anchor tables (USER and EVENT)
-
And a separate link table
此链接表包含两个 ID：user_id 和 event_id 以及事件发生时的时间戳。 
关键在于：如果我们使用此链接表作为自助分析的主表，我们可以将 USER 表和 EVENTS 表都链接到它。
因此，USER 表和 EVENTS 表将在“汇总”侧边栏中共享相同的排名。
因此，如果业务用户需要绘制每日活跃用户指标，他不必猜测应该去哪里：USERS 表还是 EVENTS 表。他会转到链接表，作为入口点。
Daily Active Users, built using a link table: 
USERS 和 EVENTS 的指标都可以只使用一个链接表来定义。拥有一个宽链接表的想法可以扩展：如果我们有 ORDERS、TRANSACTIONS 和其他域锚点，它们也可以在单个链接表中链接在一起，因此它成为自助服务需求的单个入口点。