Are Star Schema principals a good approach to modelling in Anaplan?

From my viewpoint and understanding:

It can help a lot to cut down the model size
It can make models more sleek and high performant
It will also add to the maintenance of highly complex models
It will add the greatest design value of Unified modeling

Would love to hear about these bullet points from community members. And happy to explain or discuss more on individual points.

Accepted answers

rob_marshall

@hemant04gulati ,

You are correct, the Star Schema is a very good way think about modeling within Anaplan. If you think of DISCO and the way you should build from left to right (Data -> Input -> System Modules -> Calculation Modules -> Output Modules), it has similar principals to the star schema.

Hope this helps,

Rob

JaredDolich

@hemant04gulati

Great question! And, what a terrific way to ease into the Anaplan architecture.

I agree with @rob_marshall

DISCO is a terrific way to explain the relational aspects (RDBMS) of Anaplan's Hyperblock technology. This would be table to table.

I have also found it useful to describe the "joins" in terms of an inner join and that Anaplan also requires the join to have the same format - typically a list format.

As for hierarchies using a star-schema mentality is a good one but Anaplan is nuanced. In some cases you want a "structured list" - this would be a star schema approach, where there is a one-to-many structure. Works great but there are pros/cons to this approach which you can learn about by reading more about the different list types.

Other times, like within a data hub, you'll use flat hierarchies. @rob_marshall and @DavidSmith have some really good articles on the data hub.

Finally, there are times, like with cost centers or chart of accounts where you need a ragged list where it's still one to many but the parent levels are not consistent. Anaplan will accommodate this as well.

I would suggest watching this short video on the Hyperblock. I found it really eye-opening. Pay particular attention to the indexing logic. It's very important that the lists in the "applied to" section be in the same order to take advantage of the indexing logic. You will learn all about this in the modeling level 2 certification course.

Great question @hemant04gulati

Jared

All comments

Misbah

@hemant04gulati

Explain Please!

hemant04gulati

Hi @Misbah

Would like to get a quick gist about, did you get a chance to build star schema-based models in the past? Otherwise, I can write a quick introduction to that approach.

Thanks!

Misbah

@hemant04gulati

For a larger audience write as detailed as possible. It will help our community.

I too haven't built any model based on that approach

Thanks,

Misbah

rob_marshall

@hemant04gulati ,

Hope this helps,

Rob

hemant04gulati

https://en.wikipedia.org/wiki/Star_schema

Star Schema Model

The star schema separates business process data into facts, which hold the measurable, quantitative data about a business, and dimensions which are descriptive attributes related to fact data. Examples of fact data include sales price, sale quantity, and time, distance, speed, and weight measurements. Related dimension attribute examples include product models, product colors, product sizes, geographic locations, and salesperson names.

A star schema that has many dimensions is sometimes called a centipede schema.[4] Having dimensions of only a few attributes, while simpler to maintain, results in queries with many table joins and makes the star schema-less easy to use.

Fact tables

Fact tables record measurements or metrics for a specific event. Fact tables generally consist of numeric values, and foreign keys to dimensional data where descriptive information is kept. Fact tables are designed to a low level of uniform detail (referred to as "granularity" or "grain"), meaning facts can record events at a very atomic level. This can result in the accumulation of a large number of records in a fact table over time. Fact tables are defined as one of three types:

Transaction fact tables record facts about a specific event (e.g., sales events)
Snapshot fact tables record facts at a given point in time (e.g., account details at month-end)
Accumulating snapshot tables record aggregate facts at a given point in time (e.g., total month-to-date sales for a product)

Fact tables are generally assigned a surrogate key to ensure each row can be uniquely identified. This key is a simple primary key.

Dimension tables

Dimension tables usually have a relatively small number of records compared to fact tables, but each record may have a very large number of attributes to describe the fact data. Dimensions can define a wide variety of characteristics, but some of the most common attributes defined by dimension tables include:

Time dimension tables describe time at the lowest level of time granularity for which events are recorded in the star schema
Geography dimension tables describe location data, such as country, state, or city
Product dimension tables describe products
Employee dimension tables describe employees, such as salespeople
Range dimension tables describe ranges of time, dollar values or other measurable quantities to simplify reporting

Dimension tables are generally assigned a surrogate primary key, usually, a single-column integer data type, mapped to the combination of dimension attributes that form the natural key.

Benefits

Star schemas are denormalized, meaning the normal rules of normalization applied to transactional relational databases are relaxed during star schema design and implementation. The benefits of star schema denormalization are:

Simpler queries – star schema join logic is generally simpler than the join logic required to retrieve data from a highly normalized transactional schema.
Simplified business reporting logic – when compared to highly normalized schemas, the star schema simplifies common business reporting logic, such as period-over-period and as-of reporting.
Query performance gains – star schemas can provide performance enhancements for read-only reporting applications when compared to highly normalized schemas.
Fast aggregations – the simpler queries against a star schema can result in improved performance for aggregation operations.
Feeding cubes – star schemas are used by all OLAP systems to build proprietary OLAP cubes efficiently; in fact, most major OLAP systems provide a ROLAP mode of operation that can use a star schema directly as a source without building a proprietary cube structure.

JaredDolich

@hemant04gulati

Great question! And, what a terrific way to ease into the Anaplan architecture.

I agree with @rob_marshall

DISCO is a terrific way to explain the relational aspects (RDBMS) of Anaplan's Hyperblock technology. This would be table to table.

I have also found it useful to describe the "joins" in terms of an inner join and that Anaplan also requires the join to have the same format - typically a list format.

Other times, like within a data hub, you'll use flat hierarchies. @rob_marshall and @DavidSmith have some really good articles on the data hub.

Great question @hemant04gulati

Jared

nathan_rudman

is there another way than this to model in any technology today ?

Quick Links

Can you help?

Unanswered questions

Excel date format for February 2030, 2031 and so forth don't align with Anaplan format
Hello, I’m running into a recurring issue when importing CSV files into Anaplan, specifically with dates in February for the years 2028, 2029, and beyond. Here’s what’s happening: In Excel, the date format is set to Custom (e.g., 2/26/2025). When imported into Anaplan, the date is interpreted as 26-Feb, where: Month = Feb…
RANKCUMULATE not working when adding additional dimensions to module
I have an issue where I am getting the expected result from RANKCUMULATE when using one dimension, but when I add an additional scenario dimension to the module, it doesn't calculate the way I'd expect. Here are some screenshots to explain the case: Module 1 - calculates cumulative total for list items in list "Age"…
Introducing Anaplan API Python SDK
Hey everyone, I wanted to share the Anaplan Python SDK with you. It's a Python Library that wraps all Anaplan APIs and makes it easier to interact with Anaplan programmatically. It is mostly designed with Data Integration Scenarios in mind, but it does support all APIs including ALM, SCIM, Audit, and Cloud Works. Please…