Enterprise Dimensional Model

Maintained by:

Background

The Enterprise Dimensional Model (EDM) is GitLab's centralized data model, designed to enable and support the highest levels of accuracy and quality for reporting and analytics. The data model follows the Kimball technique, including a Bus Matrix and Entity Relationship Diagram. Dimensional Modeling is the third step of our overarching Data Development Approach (after Requirements definition and UI Wireframing) and this overall approach enables us to repeatedly produce high-quality data solutions. The EDM is housed in our Snowflake Enterprise Data Warehouse and is generated using dbt.

As of 2021-April, the EDM solves for Go-To-Market funnel analytics and is actively being expanded to solve for Product Usage analytics. Example SiSense dashboards powered by the EDM include:

Primary Dimensional Modeling Artifacts

The Enterprise Bus Matrix consolidates all of our Fact and Dimension tables into an easy-to-use table and is patterned after the Kimball bus matrix.
The Enterprise Entity Relationship Diagram presents a unified entity-level view of the Fact and Dimension tables.
The Dimensional Modelling Development Process covers our modeling standards, including naming conventions.

The Enterprise Dimensional Model 'BIG PICTURE' Diagram

We use Lucidchart's ER diagram template to build Enterprise Entity Relationship Diagram source.

What Is Dimensional Modeling?

Dimensional modeling is part of the Business Dimensional Lifecycle methodology developed by Ralph Kimball which includes a set of methods, techniques and concepts for use in data warehouse design.

a logical design technique that seeks to present the data in a standard, intuitive framework that allows for high-performance access

Dimensional Modeling is business process oriented and can be built in 4 steps:

Choose the business process e.g. track monthly revenue
Declare the grain e.g. per customer
Identify the dimensions
Identify the fact

Fact and dimension tables

Dimensional modeling always uses the concepts of facts (measures), and dimensions (context). Facts are typically (but not always) numeric values that can be aggregated, and dimensions are groups of hierarchies and descriptors that define the facts.

In the simplest version fact table is a central table and is linked to dimensional tables with foreign keys creating a star schema. Star schema with dimensional tables linking to more dimensional tables are called snowflake schemas, multi fact tables schemas are called galaxies.

Why is it worth using dimensional modeling

Dimensional Modeling has a few flavors, but the overall design is industry standard and has been used successfully for decades
The FACT and DIM structures result in easy to understand and access data, suitable for business teams
Dimensional modeling supports centralized implementation of business logic and consistent definitions across business users e.g. one source of truth of customer definition
The design supports 'plug and play' of new subject areas and in fact the model grows in power as more dimensions are added

Our Very First Iteration - Solving for ARR and Customer Counts

The initial iteration was proposed in 2019-December and we deployed a model to support ARR/ Customer counts in 2020-May.

classDiagram fct_charges --|> dim_subscriptions fct_charges --|> dim_accounts fct_charges --|> dim_dates fct_charges --|> dim_product_details dim_accounts --|> dim_customers dim_subscriptions --|> dim_customers fct_invoice_items_agg <|-- fct_charges fct_invoice_items <|-- fct_charges fct_charges : +FK invoice_item_id fct_charges : +FK account_id fct_charges: +FK product_id fct_charges: +FK subscription_id, fct_charges: +FK effective_start_date_id, fct_charges: +FK effective_end_date_id, fct_charges: +FK product_details_id fct_charges : +PK charge_id fct_charges: mrr() fct_charges: rate_plan_name() fct_charges: rate_plan_charge_name() fct_invoice_items_agg: +PK charge_id fct_invoice_items_agg: charge_amount_sum() fct_invoice_items: +PK invoice_item_id class dim_accounts{ PK: account_id FK: crm_id account_name() country() } class dim_subscriptions{ PK: subscription_id FK: crm_id subscription_status() } class dim_dates { PK: date_id } class dim_customers { PK: crm_id customer_id } class dim_product_details { PK: product_details_id }

Useful links and resources

dbt Discourse about Kimball dimensional modelling in modern data warehouses including some important ideas why we should still sue Kimball
Dimensional modelling manifesto
Dimensional Modelling techniques by Kimball Group