作為一家分析機構，我們熱愛為客戶提供自助式分析工具。讓業務使用者不僅可以探索我們準備的儀表板，還可以探索整個資料集，這個想法非常強大。但是，業務使用者常常難以開始使用自助式分析。
在這篇文章中，我們將說明在自助式服務中常見的實體關係資料模型的典型問題，並討論如何透過使用不同的資料建模技術來改善自助式服務體驗。
想像一下，我們有一個從 Google Analytics 取得的典型資料集。我們有關於使用者及其事件的資訊。通常，我們會針對這類資料建立兩個表格：使用者和事件。
使用者資料集範例： 
事件資料集範例： 
為了滿足自助式服務的需求，我們通常會透過主索引鍵-外來索引鍵將 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 和其他網域錨點，它們也可以在單一連結表格中連結在一起，因此它成為自助式服務需求的單一入口點。